PathLink: 砂塵の彼方 > 徒然日記 > シナリオ

エントリー

カテゴリー「シナリオ」の検索結果は以下のとおりです。

[CardWirth] 「データバージョン4&Wsn.2混在不可例」 1.00

少し前に公開した「複数PCの名前を一度に表示するサンプル」から、データバージョン4とWsn.2の混在が不可能な例外に関する部分を切り離して、別のサンプルシナリオとして公開しました。とりあえずやったことを晒してみましたが、自分で見ても、何がしたかったのか良く分からない感じになってましたので。

分離した残りの部分は、後日、「CW1.30&1.50新機能代替サンプル(忘れられた実験室)」の一部を追加し、少し手を加えて、『名呼びサンプル詰め合わせ』に衣替えしてアップする予定です。

データバージョン4&Wsn.2混在不可例 ver.1.00
DLはこちら

[CardWirth] 「複数PCの名前を一度に表示するサンプル」 1.01

混在可能なWsn.2新機能の例を入れ忘れてました。
1つ前の記事に書いた、メッセージのセンタリングです。Wsn.2専用メニュー「混在テスト」内にあります。


複数PCの名前を一度に表示するサンプル→ver.1.01
DLはこちら

[CardWirth] 「複数PCの名前を一度に表示するサンプル」 1.00

2~3日ほど前。
だらだらとTwitterの画面を眺めていた自分の目の前を、複数PCの名前を1つのメッセージに云々……というツイートが流れていきました。
ぼんやりしていたので、詳細も、どんな流れだったかも思い出せません。半分寝ぼけた頭で、そう言えば昔は出来なくて困っていた人がいたなと、考えました。

今はNextで指定番号のPC名をメッセージに表示する特殊文字 $??Player1~6$ があるし、ステップの「特殊文字を展開」機能と合わせて使えば簡単です。
PyでもWsn.2で $??Player1~6$ によるPC名の表示ができるようになったし、ステップの特殊文字展開もあるので、Nextと同じやり方で全く問題ありません。
たぶん、以前は無理だったが簡単になったとかいう話だったんだろうな……。

と、そこで思い出したのが、HANDさんの「バージョン混在サンプル」です。
ひょっとして、NextやWsn.2対応エンジン(Py2(など))では一度に複数人の名前を呼ばせつつ、それ以外では良い感じに誤魔化した代替セリフを入れる、みたいなことができるのじゃなかろうか。

そう思ってやってみた結果、今回考えた方法では無理でした。
Next仕様との混在は可能でしたが、Wsn.2仕様を混在させた部分は上手く動きません。

【結論】

  • Nextだけ複数PCの名前を呼ぶCW1.50・Next・Py三種対応シナリオを作ることは可能。
  • Pyでもやりたければ、今のところ専用シナリオ(WSN形式)一択?

以上です。
最初にどのエンジンでも動く複数PCの名前を一度に表示するサンプルを目指して作り始めたので、そのままの名前で出してますが、今の内容では、Wsn.2で他の仕様との混在が上手くいかない例のサンプルと言った方が正確かもしれません。Next仕様との混在例としてならご利用頂けます。

※※※
上手く動かないというのは、どういうことかというと:

テスト用として作成したサンプルでは、Wsn.2対応エンジンではPackageフォルダ内にあるXML形式のパッケージが読み込まれますが、パッケージ内のセリフに含まれる文字列 $??Player1~6$ は、特殊文字として扱われません。そのため、セリフコンテントに「$??Player1$」と書いてあれば、PCの名前ではなく、そのまま「$??Player1$」と出力されます。

これは、バージョン2以降のPyエンジンが $??Player1~6$ を特殊文字として扱うかを判断する際、シナリオのサマリに書き込まれているシナリオデータバージョンを見ているためです。
XML形式のパッケージにもデータバージョンの情報は入っていますが、シナリオの土台がデータバージョン4のためサマリからシナリオのデータバージョンが読み取れず、Wsn.2シナリオと解釈されません。

ざっと見た感じでは、他にも、独自のシステム称号(@効果対象 など)周りがシナリオ側のデータバージョンチェック対象になっているようでした。クラシック形式やWsn.0、Wsn.1でも入力できてしまう部分に対しての、安全策なんでしょうかね。
一方で、Wsn.2対応ツールでXML形式で編集中でないと使えないものに関してはチェックが無いようです。簡単なところでメッセージのセンタリングを試してみたのですが、他の仕様と共存させても問題なく動きました。
(※混在ができない例外サンプルも作っています。良かったらどうぞ。)

うーん。意外な落とし穴が。
ともあれ、やってみた結果を晒します。


複数PCの名前を一度に表示するサンプル ver.1.00
DLはこちら

[CardWirth] 「カードの世界」1.01

不具合の修正や内容の調整を行いました。
内容は、以下の通りです。

カードの世界→ver.1.01
・初期イベント直後に宿に戻ると一時称号が残る不具合を修正
・大きな区切りを次に進める際、確認を入れるようにした
・必須アイテムの破棄対策
・付帯技能に関する説明の修正
・その他微調整
DLはこちら



以前に書いた修正予定のうち、予定通り実行したのは次の2つということになります。

  • 説明を次に進めるかの選択時に、もう一段階確認を入れる。
  • もう一段階が面倒な方のために、以後確認無しで先に進むオプションを追加。

約4年も放置していてすみませんでした。
ストーリーにあたるものの修正がどうしても上手くいかず、それはもう諦めることにしました。


【一旦確定して取りやめたもの】

●説明メモにおけるキーコードの表現を「キーワード」から「タグ」に変更
そのカードが何なのかを表す単語群ということで「タグ」の方が良いのでは、というご指摘を受けていました。
キーコードとは何かということなら「タグ」の方が分かり易いようにも思いましたが、どのように働くのかの説明がメインのため既存の「イベント発火用キーワード」の表現を残しました。

●PC右クリックメニューで見えるものについて軽く説明追加
「理の呪文」パートの右クリックの説明で、PCの経歴に関してなどもっと詳しく書いて欲しいというご要望がありました。
ただ、後から行うホールドの説明でPC詳細の閲覧を促す部分があり、見張りの場面でPC経歴欄の説明もあります。実際に見てもらえば分かるのではないかということで、微妙に表現を変えただけに落ち着きました。
一方、シナリオ内の他の部分で言及されない敵の詳細に関しては少し記述を追加しました。

●ストーリーにあたるものを修正
当初考えていたことを勘の良い人なら分かる程度に出せないかと考えていましたが、上手く表現できませんでした。
既に4年も経っていることもあり、修正はしないことにしました。

※※※
4年前のメモに、ご要望があって修正をしなかった部分について、なぜ行わないか書いてあって、改めて記録の大事さを痛感しました。
記録がなければ一から検討し直す羽目になり、もっと時間がかかったはずです。

このシナリオは、これで一応完成ということにします。
技能やアイテムの使い方以外にも早い段階で知っておいた方が良いことがあるかと思いますが、これはあくまでカードの使い方説明シナリオです。当初の予定を超えて拡張し、何のためのシナリオか分かり辛くなっていくよりは、足りない部分があっても今の形の方が良いと考えます。
もちろん、バグの修正は随時行います!

[CardWirth] CW用「エンジン識別サンプル」 1.06

前バージョン以降の私家版エンジンの更新に対応しました。
このサンプルは、これでだいたい完成です(今後大きな変化があれば別ですが)。


[現時点で識別可能なエンジン]
正規版
・CW1.20/1.28/1.29/1.30/1.50
私家版
・CardWirthNext1.60
・CardWirthPy(Reboot)0.12.1/0.12.2/0.12.3/1/1.1


エンジン識別サンプル→ver.1.06
・CardWirthPy0.12.3、1、1.1の識別に対応
DLはこちら

[CardWirth] 【重要】サンプルシナリオ中のカードデータ・素材について

サンプルシナリオに含まれるカードデータの利用に関して、拍手コメントでお問い合わせ頂きました。大事なことなので、エントリの方で返信させて頂きます。

お問い合わせは、サンプルシナリオに含まれる技能やアイテムなどのカードをリソースとして利用可能かということでしたが:

────────
当サイトのサンプルやリソースは、イベントの組み方説明を目的としたものです。
配布パッケージに含まれるカードデータや画像・音声・楽曲などの利用はご遠慮ください。
(※readme.txtなど他の付属テキストで利用を許可している場合は除きます。)

なお、サンプルシナリオ、リソースシナリオとは、シナリオに付属するreadme.txtの「形式」の項に「サンプルシナリオ」または「リソースシナリオ」と記載されているシナリオを指します。
────────

切り貼り用として準備したイベントデータ(例えばCW1.30/1.50新機能代替サンプルなら「2_素材庫」フォルダ内のエリアやパッケージのイベントビュー内容や環境変数)を、あなたのシナリオにコピー&ペーストして頂くのは全く問題ありません。

ただ、カードや素材には自作ではないものも含まれるため、インポートや素材の抜き出しも可とすると、何かの手違いで自作以外のものが使われてしまう可能性が生じます。あなたが大丈夫でも、次の、またその次の誰かがということを考えると、最初から使えない設定にしておいた方がより安全と考えました。
また、使い方に「あなたのシナリオにコピーして下さい」などと書いていないものは、そもそも動作見本専用に作成していて、他での利用を想定していません。

そのようなわけで、すみません。考えましたが、この結論になりました。
後日、サイトに掲載している規約文書やシナリオ付属のテキストにも反映させます。


(5/30追記)
「配布物の取扱いについて」を更新しました。

[CardWirth] 各種エンジンにおけるセリフコンテントの仕様の違い

CW1.30/1.50新機能代替サンプル内の特定のPC【A】が別のPC【B】の名前を呼ぶサンプルが、Pyでは上手く動かないという某所での会話から、セリフコンテントの、と言うかその後方の選択肢の扱いがエンジンによって異なることが判明しました。

時間が無い方のために、結論だけ先に書いておきます。

話者が持つ称号がコンテント内に含まれるセリフパターンの称号条件のいずれにも一致しない時、

  • セリフの表示が飛ばされるのは各エンジン共通だが、セリフ後方の分岐(選択肢として表示される部分)の扱いが異なる。
  • CW1.20~1.50/Next1.60では必ず分岐の一番上の枝に自動で処理が進むが、Py0.12.2では何らかの文字列が設定された選択肢が1つ以下の場合のみ一番上に自動で処理が進む。


何言ってるのか良く分からんと言う方は、以下の例をご覧いただくと分かると思います。

例えば、

セリフ(誰も持っていない称号が条件)「うんたらかんたら」
├【】→メッセージ「1」
├【2に進む】→メッセージ「2」
└【3に進む】→メッセージ「3」

というイベントがあったとします。【】の中は選択肢ラベル(OKとかYesとかNoとか入っているあれ)です。

これをCW1.50、CWNext1.60、CWPy0.12.2でそれぞれ実行すると、

●CW1.50/Next1.60
・セリフ「うんたらかんたら」は表示されず、メッセージ「1」が表示される。

●Py0.12.2
・セリフ「うんたらかんたら」は表示されず、[どれか一つを選択してください。] 2に進む/3に進む との選択肢が出現。

と実行の結果が異なりました。
正規版やNextではセリフは表示されずに1番上の分岐に進みましたが、Pyでは空のセリフ+選択肢と同じ扱いになっています。


そこでもう1つ、以下のようなイベントを試してみました。

セリフ(誰も持っていない称号が条件)「うんたらかんたら」
├【】→メッセージ「1」
├【2に進む】→メッセージ「2」
└【】→メッセージ「3」


前のと何が違うかというと、3番目の選択肢ラベルが空白になり、文字列が設定された選択肢が1つに減っています。そして、このイベントを実行した場合は、どのエンジンでもメッセージ「1」のみ表示されるのです。

今度は、Pyでもセリフ後方の分岐構造が無視されました。
Pyでは、表示が行われなかったセリフ後方に意味のある選択肢が存在しない時(=何らかの文字列が設定された選択肢が1つ以下の時)は分岐が無視され、そうでない時はメッセージなしの選択肢として扱われます。
他のエンジンでは、後方がどうなっていようと、全ての場合で分岐が無視されます。


そこで、冒頭の結論部分です。

話者が持つ称号がコンテント内に含まれるセリフパターンの称号条件のいずれにも一致しない時、

  • セリフの表示が飛ばされるのは各エンジン共通だが、セリフ後方の分岐(選択肢として表示される部分)の扱いが異なる。
  • CW1.20~1.50/Next1.60では必ず分岐の一番上の枝に自動で処理が進むが、Py0.12.2では何らかの文字列が設定された選択肢が1つ以下の場合のみ一番上に自動で処理が進む。

と、なってました。
某所での会話に参加していた方が、Pyの開発者さんにこの現象を報告されるそうなので、いずれ修正されるかもされないかもしれません。


なお、特定のPC【A】が別のPC【B】の名前を呼ぶサンプル(CW1.30/1.50新機能代替サンプル)ですが、名前を呼ぶセリフ直後の選択肢で、何かの文字列が設定されたものを1つにすれば問題なく動きます。
↑の言い方で分かり辛ければ、セリフが表示される時に選択肢がつかないようにする、とお考えください。



※※※
なぜこうなっているかを考えると、たぶん、シナリオ作成者が明らかに選択肢作りたかったんだろうなという時に選択肢表示してくれる親切機能の結果というのが、最も妥当な推測だと思います。仕様である可能性が高く、影響も特殊な条件下に限られるので、私は報告する決断に至れなかったかもしれませんね。。
ともあれ、今後別の何かを発見した時のために、余裕のある時にBitbucketに登録しておきますか。


(5/26追記)
この件について、メモ箱の私家版エンジン情報に追加しました。

[CardWirth] CW用「エンジン識別サンプル」 1.05 不具合修正

CardWirthPy v.0.12.2(Reboot) 正式版の識別に対応しました。

これまでPyの識別に使っていたCW1.50との仕様の違いが0.12.2正式版で無くなったため、当サンプルの過去バージョンでは正確な識別ができなくなっています。お手数ですが、本日公開の最新版(v.1.05)を新たにダウンロードして頂きますようお願い申し上げます。

Py0.12.2正式版でCW1.50に合わせられた点については、1つ前の準備メモに書いています。
興味がある方は、そちらも併せてご覧ください。


[現時点で識別可能なエンジン]
正規版
・CW1.20/1.28/1.29/1.30/1.50
私家版
・CardWirthNext1.60
・CardWirthPy(Reboot)0.12.1/0.12.2


エンジン識別サンプル→ver.1.05
・CardWirthPy0.12.2正式版の識別に対応
DLはこちら

※※※
その他、修正過程で新たに分かった事などを、メモ箱の関連記事に反映させました。
私家版エンジンの識別方法 / CW1.50の対象消去バグについて

[CardWirth] CW用「エンジン識別サンプル」更新のためのメモ

CardWirthPy バージョン0.12.2の正式版が公開されていたので、拙作「エンジン識別サンプル」が正しく動くかどうか確認しました。サンプルは各エンジン各バージョンの正式版が識別できる事を目指していますので、これで問題なければそのまま公開を続けられます。

しかし、識別の結果は「CW1.50」でした。
同行NPCの称号が、クーポン分岐で検出できなくなったようです。これは困った──

と思ったら、ChangeLog.txtに「称号判定分岐でCardWirthPyのバージョンを判別できるようにした」の一文が。課題一覧にそんな話が出ていましたが、正式版で実装されていました。CW1.29の「@MP3」と同じく、エンジンバージョンを示す@称号を実際の所持状況と関係なく検出できるとのことです。

ということは:

  • Py0.12.1は、これまで通りクーポン分岐による同行NPCの称号検出で見分ける。
  • Py0.12.2以降は、称号「@CardWirthPy Version.0.12.2」が検出できるかどうかで見分ける。仮想クーポンが実装されたバージョンを指定しておけば、その後全てのPyをPyと識別可能。
    バージョンについては、各バージョン毎に設定される「@CardWirthPy Version~ Only」で見分ける。

とすればPy0.12.2正式版対応は完了、のはずです。
これから修正に取りかかります。

※※※
CW1.50と識別されるようになった原因は何なのか、ChangeLog.txtで探しましたが、影響していそうな項目は見当たりませんでした。

クーポン分岐に関連する変更には「クーポン選択分岐やカード所持分岐で対象がいなかった場合の挙動をCardWirthに合わせた」がありますが、直前の0.12.2 RC3までは同行NPCの所持称号で選択して、効果コンテントによる各種状態の変更や称号やカードの付与ができていましたので、「対象がいなかった場合」にはあたりません。

他に可能性があるかもしれないのは「フィールド全体で対象を選択した時、選択中のメンバが優先選択される」ですが、これは前段階で別の手段によって同行NPCが選択できている前提の話になり、クーポン分岐から開始する実験で必ず指定称号を持っているNPCが選択されるのとは、違う現象のようです。

ともかく、0.12.2 RC3→0.12.2正式版の更新で、同行NPCが持っている称号をターゲットにクーポン分岐を行っても、必ず失敗するようになりました。そこは間違いありません。

※※※
CWPy0.12.2正式版における変更点の1つに、「CardWirth 1.50では同行キャストに対象消去の効果が無いため、それに合わせた」がありました。これは、Nextの見分けに使っている、対象消去後のNPCをランダム選択で選択可能なバグと関連する部分です。
どのように修正されたのか、実際を見てみたところ、以下のような結果になりました。

CW1.50では対象消去した同行NPCを(が):
・キャンプで閲覧できる→Py0.12.2も同じ
・キャスト存在分岐で検出できる→Py0.12.2も同じ
・ランダム選択で選択できる→Py0.12.2も同じ
・戦闘では動かない→Py0.12.2では戦闘中も動いている

CW1.50で戦闘中の行動が封じられているところ以外は、同じ動きになっていました。
対象消去後のNPCの動きついてメモ箱に書いた部分も、サンプルと同時に修正予定です。


【!】同行NPCを消したければ「キャスト離脱」で!
サンプルとは関係ありませんが、大事なことなので書いておきます。

対象消去後のNPCの扱いについては、現在存在するエンジンの最新版全て(CW1.50、CWNext1.60、CWPy0.12.2)に明らかにバグと思われる動きが存在します。
また、対象消去後の挙動が、CW1.50と各私家版で異なっています。
(→詳細

ストーリー的に対象消去が正しい(例:パーティーに取り憑いた幽霊が聖なる力で祓われるなど)場合でも、キャスト離脱で離脱させた方が無難です。

[CardWirth] CW用「エンジン識別サンプル」 1.04 不具合修正

前バージョンまで、Pyが互換モードで動作中は、正しく識別ができませんでした。

  • CW1.28を時限称号への対応で見分ける場合、確認した全てのバージョンがPy0.12.2 (Reboot)と識別されていた。
  • CW1.28を状態異常判定バグの有無で見分ける場合、確認した全てのバージョンがCW1.20と識別されていた。

これは何故かというと、「互換モード=互換指定したバージョンと全てにおいて同じ動きをする」のではないからです。前回更新時は、その詳細について詳しくは調べていませんでした。

今回、サンプル内で識別に用いている仕様の差やバグについて、1つずつ互換モードでの動きを確認しました。
以下は、その結果です。

【互換モード時、指定したエンジンの動きが再現されたもの】

  • CW1.20の状態判定分岐バグ(中毒が麻痺/石化の判定に引っかかる類のあれ)


【互換モードでも通常モード時と同じ動きだったもの】

  • 時限称号の時間経過による消滅
  • 仮想システムクーポン「@MP3」の検出
  • CW1.30以降の状態判定分岐の拡張分(少なくとも混乱と沈黙は互換設定によらず検出可能)
  • CW1.20の、睡眠者に絶対成功(成功値修正+5)で攻撃した場合、対象が目覚めないバグが修正済み


【そもそもCW1.50とは挙動が異なっているもの】

  • 対象消去した同行NPCをランダム選択で選択できない(※CW1.50に合わせて、できるように修正されるようです)
  • フィールド全体対象のクーポン分岐で同行NPCの称号を検出可能


互換モードで何が変わるのか細かく調べれば、どのエンジンに互換の設定で動いているのか判別可能かもしれませんが、今のところやるかどうか未定です。
互換モードの使い道を考えてみると、

プレイヤーが最新エンジンでは不具合が出るシナリオを遊ぶ際に利用
→シナリオに何かしなくても、適切に互換設定すれば多分動く。

シナリオ作者が過去の仕様やバグを利用したシナリオを作る際に利用
→こちらも互換設定が適切なら恐らく問題なく、Pyであることが判別できれば十分。
→正規版やNextに対しては、対応していない時メッセージを表示するなどの対応が可能。

なので、互換の設定まで見分けなくて良いようにも思います。


[現時点で識別可能なエンジン]
正規版
・CW1.20/1.28/1.29/1.30/1.50
私家版
・CardWirthNext1.60
・CardWirthPy(Reboot)0.12.1/0.12.2


エンジン識別サンプル→ver.1.04
・CardWirthPyが互換モードで動作中も正しく識別できるよう修正
DLはこちら

※※※
修正過程で新たに分かった事を、メモ箱の関連記事に反映させました。

ページ移動

ユーティリティ

2018年12月

- - - - - - 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 - - - - -

エントリー検索

エントリー検索フォーム
キーワード


翳の回廊(絵置き場)の一部を
TINAMIのスペースに置かせて頂いています。

pixivでも何かやっている……かも。

新着コメント

Re:Re: CWBBS[26]-14
2015/06/23 from simoom
Re:Re: CWBBS[26]-14
2015/06/22 from ああ
Re:Re: CWBBS[26]-14
2015/06/22 from simoom
Re:Re: CWBBS[26]-14
2015/06/21 from 権限がありません
Re:Re: CWBBS[26]-14
2015/06/21 from あ

過去ログ

Feed