WSN追加案: キーコード所持判定分岐の範囲の柔軟化・手札の追加
Issue #436
resolved
キーコード所持判定分岐に以下のような拡張を行う事を考えます。
具体的には、CW 1.50では「全て」「特殊技能」「アイテム」「召喚獣」からどれか1つを選択するようになっているところを、「特殊技能」「アイテム」「召喚獣」「手札」から任意の組み合わせを選択できるようにします。
ここで「手札」はバトル中の任意のラウンドで選択可能な戦闘行動の事を指します。バトル中でない場合は手札は存在しないので必ず失敗します。
この提案は、1.50にある、「対象にアイテムが含まれると実際には「手札」も対象になってしまう」という問題への対策も兼ねています。具体的には、この機能を実装した時、クラシックなシナリオで以下のように動作するようにします。
- エンジンは、クラシックなシナリオで「全て」「アイテム」が対象となっている時は、常に「手札」も対象に入っているかのように動く。
- クラシックなシナリオをWSN形式に変換した時は、「全て」「アイテム」が対象となっているキーコード所持判定分岐は「手札」も対象に加わるようにする。
- WSN形式からクラシックなシナリオへ変換した時の処理は他のWSN形式固有機能と同じ(できるだけ変換し、変換不能なら警告を出す)。
- クラシックなシナリオをエディタで編集している時、「全て」「アイテム」が対象となっているキーコード所持判定分岐は常に警告する。エディタに書いてある事と実際の挙動が違うので、この警告が必要です。
これで、シナリオ作者に対して情報を提供しつつ挙動の違いを吸収・解消し、従来は正確に行えなかったアイテムカードを相手の検索も実用可能になります。
Comments (52)
-
-
reporter
（手札としての）アイテムも含まれるということでいいでしょうか。
手札にありますから、当然含まれます。
手札カードの配布タイミングについては、これまでの調査でかなり明らかになっています。例えば特殊技能カード配付効果は、適用した瞬間にカードの実体を山札に置くのではなく、「特殊技能カードを引く」という情報を置く事が分かっています。これはゼロにした使用回数を配付効果の後から回復するなどの方法によって調査されました(実際にそれで動かないギミックがあったのが発端だったような)。また、使用したカードは手札から取り除かれますが、空いた部分には即座に他のカードが補充されるのではなく、次のラウンド準備時に山札から引く形で補充されるようです。行動不能になったキャラクターの手札は取り除かれるようです。
アイテムは検出されます。
これは手札が一切引っかからず普通のアイテム検索が動いているためだと思われます(手札の中のアイテムだけが検索される、とかでも結果は同じですが)。
不足している情報があったら、幸いな事に1.50のキーコード所持判定分岐で調査する事ができそうです。
XEditor上の現在アイテムになっている表記を現実の実装に沿うようにアイテム・手札と変え、名称はどうでもいいですが、アイテムのみを新設するのがもっともスマートに思います。
PCが所持できるカードはアクションカードを除くと特殊技能・アイテム・召喚獣の3種類で、それはCWのあらゆる箇所でそうです(各種イベントコンテントにおいてもそれらが並んでいます)。スマートだとしても、仕様としては一貫しておらず不自然になってしまいますから、私は賛成できかねます。
WSN2仕様 [すべて/技能/アイテム・手札/召喚獣/アイテムのみ]
これは任意の組み合わせを選べるようにするアイデアより汎用性が落ちています。比較するとメリットが無いように思います。
任意の組み合わせを選べるというのは、つまりチェックボックス方式にして、特殊技能と召喚獣と手札にチェックを入れるとかアイテムだけにチェックを入れるとか全てチェックを入れるとかできるようにする、という事です。
-
手札にありますから、当然含まれます。
含まれるということは、手札には常にすべてのアイテムがあるため、デフォが1.50仕様(手札・アイテム)という起点ではアイテムを切り分けるメリットはほとんどないということです。非戦闘時に必ず失敗する挙動は使い道が思い浮かびません。 「手札」にアイテムが含まれない場合は「手札のアクションカード・技能カード」に攻撃系カードがあるかみたいな検索ができるようになります。含まれる場合は武器アイテムや火晶石での検索妨害を除外できません。
これは手札が一切引っかからず普通のアイテム検索が動いているためだと思われます
普通のアイテム検索が二重に動いているのか、 戦闘不能時「アイテム・手札」のリストからそれ以外のカードが削除された結果か、我々には判断できません。 判断できないということは、新しく作られる「手札」で戦闘中アイテムを含むか、行動不能時アイテムが検索できるかの挙動は、本家系コードからの発展型とは異なる可能性があり、仕様の衝突を招くのでは？
CWのあらゆる箇所でそうです
CWの手札はアイテム、アクション、技能で召喚獣は含まれませんし、GETコンテントでは情報カードが挟まっています。まさにその手札の追加なので整合性がないというほどではないと思います。（XEditor上では並び順を入れ替えてもいいですし）
チェックボックス方式については、現段階で、微細な組み合わせができるようになっても二回判定するのとほぼ同等で 新しいことができるようになるわけではないというのと
#428、一貫しているものを後から分解する事は容易理論で、仕様衝突リスクと旧来型への移植性の悪さを厭わず実装するほどのメリットはないように見えます。 （WSN7ぐらいでPyが圧倒的な支持を得ている場合はいいと思いますが…）「アイテムのみ」についても、前身課題で挙げられたケースを見るに、同一の汎用KCを一方では存在フラグ、一方では発火用とした場合にピンポイントに問題になるだけで スキルには付けない、ユニークなキーコードにする、判定前に一度精神状態を変えて手札を飛ばす＋WSN2で効果KCを使うなどで対処可能な気もしますが、 一応「新しくできること」は増えますし、暫定上の拡張では最小限の被害になります。
-
reporter
すみませんが仰っている事がいまだによく分からない部分があります。以下のコメントは書き手の意図通りに読み取った上での反応ではないかもしれません。
含まれるということは、手札には常にすべてのアイテムがあるため、デフォが1.50仕様(手札・アイテム)という起点ではアイテムを切り分けるメリットはほとんどないということです。
1.50でのメリットは最初からありえません。1.50では元々アイテムを正しく検索できませんし、どんな対策を打とうと今後もできないと思われます。ですから、1.50を相手にする時は、エディタ側で表示通りに動かない事を警告するか、表記を改めてエンジンの挙動に合わせるしかありません。
ユーザがキーコードを設定できるカードは特殊技能・アイテム・召喚獣の3種類です。このうちの1種類だけ戦闘中に挙動が変わるというのは一貫性を欠きますから、表記を改めるやり方も一貫性を欠いている事になり、妥当ではありません。警告する方が誠実なやり方です。
判断できないということは、新しく作られる「手札」で戦闘中アイテムを含むか、行動不能時アイテムが検索できるかの挙動は、本家系コードからの発展型とは異なる可能性があり、仕様の衝突を招くのでは？
それはクローンエンジンのほとんど全部の事に言える事であって、そうした主張を受け入れてはCWPyが成り立ちません。
それはそれとして、実際にはそのようなリスクはほとんど無いと考えています。選択肢の集合があるとき、その中の1件を選択した結果の集合は、選択肢のあらゆる組み合わせの集合の中に包含されますから、既存のエンジンでどんな風に選択肢が増えようとも、それに対応する選択肢を増やせば対応できます。つまり、
仕様衝突リスクと旧来型への移植性の悪さを厭わず実装するほどのメリットはないように見えます。
こう仰られている事とは反対に、これは仕様衝突のリスクを回避するための最善の方法です。
WSN仕様→クラシックへの移植については、新しい機能であれば移植できないのは当たり前であって、「アイテムのみ」の選択肢を増やしたところで、それを使用しているキーコード所持分岐が変換できない事に変わりはありません。
しかし、前から気になっていたんですが、
GETコンテントでは情報カードが挟まっています。
これはなぜなんでしょうね？ 1.00-1.15までの更新履歴を見ても、後から召喚獣カードが追加されたというわけでもないようです(ちなみにその更新履歴では特殊技能・アイテム・召喚獣を一括りに「効果型カード」と呼んでいます)。
-
そうですね…あまり伝わらなかった感じがします。
「一貫性がない」というのは感覚的な話なので、自分はそれのみをもって判断するのには賛同しかねますが、 警告するか、改名するかというのはXEditorが1.50仕様クラシック形式に対して取るスタンスかと思いますので、意見はありません。
1.50仕様のメリットは、非戦闘時ではアイテムを検索でき、戦闘時ではアイテム∈手札を検索できるということです。 「手札にあるスキル・アクションカード」を検索するのに、 たとえば「癒身の法」を手札に持っているか検索することができますが、これにおいてアイテムも候補になることは問題になりません。 戦闘中に「特定のアイテム」を検索するのに、 たとえば「傷薬」を手札に持っているか検索することができますが、これにおいてスキルが引っかかってしまうことは問題になりません。 非戦闘時では手札がないので同じく問題になりません。
以上のことは正確性・一貫性を欠くことよりもシナリオ作者にメリットを与えているので、使用シナリオもあることですし、 NEXT側がこれを修正する動機は薄いのではないかと自分は考えます。 多分、意識の違いとして、元々「キーコード発火」が種別を区別していないので、自分やこの挙動を肯定しているシナリオ作者は元々ある「薬師スキル「傷薬」などの名前かぶりのスキル問題」の延長として考えていて、その上ではただ「手札も検索できる」というメリットがあるので、「アイテム検索が戦闘時不正確」になるというデメリットを長月さんらの意識とは反対に、大きな実害とは認識しがたいのだと思います。
そのままではないコンバート手法は、仕様として確定しているこれに対して別の概念を唱えるものなので、 それによって「新しくできること」が増えないのであれば、自分はそれをメリットと認識できず、そこまで拒絶するほどではないのではないか…という警戒感が勝ってしまいます。
それに対応する選択肢を増やせば対応できます。
たしかに、戦闘不能等で手札がない時にもアイテムを検知できる「手札(アイテム含む)」と戦闘不能等で手札がない時は同様にアイテムを検知できない「手札(アイテム含む)」が生まれても、両方を用意することで対応できます。 しかし、これは長月さんの仰った仕様衝突回避スタンスからすると、なるべくなら避けたい最終手段ではと思うのですが…
これはなぜなんでしょうね？
なぜでしょう…文言をよく見るとGetではばらばらですが、Blanchでは各コンテント名が「所持」に対して召喚獣のみ「存在」、Lostでは「喪失」に対して「消去」なので 独立・一時出現している性質を持つカードとして区別しているのかもしれません。
-
reporter
1.50仕様のメリットは、非戦闘時ではアイテムを検索でき、戦闘時ではアイテム∈手札を検索できるということです。
今回の提案では「アイテム」と「手札」を対象にする事によりその挙動を再現できる(非戦闘時には手札は失敗するのでアイテムだけを検索できる)上、アイテムだけを検索する事もできるというものですが、もしかしてそういうメリットが伝わっていないのでしょうか？
-
「アイテム」と「手札」を対象にする事によりその挙動を再現できる
ということは、1.50が元々そういう挙動なので、メリットになりません。
アイテムだけを検索する事もできる
ということは1.50仕様に「アイテムのみ」を付け加えることで実現できます。
そしてこの提案により新設される「手札(アイテム含む)」「アイテム」を検索することは1,50仕様の「アイテム」を検索することとほぼ同じです。新しくできることが増えません。 「手札(アイテム含まない)」なら少しだけ増えるのですが、仕様衝突リスクに釣り合うかは疑問です。
1.50互換を保つ以上、シナリオの進行に影響する挙動はすべて1.50側が正しいという視点からすると、 このアイディアは現時点ではスキル+召喚獣のようなOR条件が1回のコンテントで済むという少しのメリットに対して、 仕様衝突リスクがあり、現1.50系との仕様違いを複雑にするという大きめなデメリットがあるように見えます。
-
reporter
いや、すいません。主張の意味が分かりません。
ということは、1.50が元々そういう挙動なので、メリットになりません。
新しい選択肢を付け加える事はメリットにならないと仰っています。
ということは1.50仕様に「アイテムのみ」を付け加えることで実現できます。
メリットが無いなら新しい選択肢を付け加える必要はないはずです。
仕様衝突リスクに釣り合うかは疑問です。
下のように書いた部分は読んでいただけましたか？ 仰っている事は論理的に意味が通りません。
選択肢の集合があるとき、その中の1件を選択した結果の集合は、選択肢のあらゆる組み合わせの集合の中に包含されますから、既存のエンジンでどんな風に選択肢が増えようとも、それに対応する選択肢を増やせば対応できます。
-
説明不足であればこちらこそすいません。
1.50仕様「アイテム(+手札)」からアイテムと手札を分けることは仕様衝突を生みます。 特に「手札」を分けるのが危険です。切り離しパターンが複数(アイテム含む、含まない、含むが行動不能時判定不可等)あるからです。
新しい選択肢を付け加える事はメリットにならないと仰っています。
新しい選択肢がメリットにならないのではなく、提案で切り離されたうち、「手札(アイテム含む)」の方は新しい選択肢になっていないということです。 1.50仕様ではそれがデフォルトなので±0です。現在のPyは「1.50のアイテムKC所持分岐で出来ること」が出来ないので、アイテムのみを検索できるというメリットを差し引いてもマイナスと言えます。 1.50との違いは「非戦闘時に必ず失敗する」挙動を得られるということですが、これは使い道がほとんどないと前述しました。
メリットが無いなら新しい選択肢を付け加える必要はないはずです。
自分は必要ないと思っていますし、切り分けること自体に反対なのですが、 「アイテムだけを検索する」に需要があることは確かですので、それを実現するのであれば、 まだ、切り離すより部分的なコピー、Py側で新しい「アイテム(のみ)」を作った方がいいということです。 その新しい「アイテム(のみ)」については、仰るように、常に検索できるスキルや召喚獣と同じ挙動にするのが妥当ですので、仕様衝突するパターンがないためです。
下のように書いた部分は読んでいただけましたか？
はい。それについては以下のように書いたのですが、応答がないように見えます。 その部分に反応していることを読んだか訪ねられるということは相当お怒りなのか、逆に空目されているかだと思うのですが、前者であれば察しが悪くて申し訳ないです…。
たしかに、戦闘不能等で手札がない時にもアイテムを検知できる「手札(アイテム含む)」と戦闘不能等で手札がない時は同様にアイテムを検知できない「手札(アイテム含む)」が生まれても、両方を用意することで対応できます。 しかし、これは長月さんの仰った仕様衝突回避スタンスからすると、なるべくなら避けたい最終手段ではと思うのですが…
まとめると問題を先送りにして、現状では、1.50仕様にそのまま合わせておくのが一番よく、 (永遠にそのまま変えてはならないということではないです。1.50/NEXTが主流である限りは永遠になりますが) 「アイテムだけを検索する」の実現に強い需要があるならWSNで新しい「アイテム」を作るのが最善。 手札を分割するのは現状ではデメリットが大きいので強いメリットがなければ反対で、 それならばCWプラットフォームに混乱を呼ぶのを承知で現状維持の方がまだマシという感じです。
-
reporter
1.50仕様「アイテム(+手札)」からアイテムと手札を分けることは仕様衝突を生みます。 特に「手札」を分けるのが危険です。切り離しパターンが複数(アイテム含む、含まない、含むが行動不能時判定不可等)あるからです。
これがどうしても理解できません。行動不能時に手札が無いのは1.50の挙動からして自明です。その時はアイテムだけが探索されます(実際に1.50もそのように動きます)。
行動不能時に一切アイテムが探索できなくなる、というのなら仰る通りややこしい事になりますが、そういう事にはなっていません。が、仰られている事を読むと、どうもそのような挙動を前提として書かれているように見えます。だとしたら、そこが話がねじれている原因です。
ついでながら、もしそういう挙動があったとしても、行動不能者を除外するオプションを付け加えればやはり完全に再現する事ができます。
-
この提案では、「手札」のみにチェックが入っている時、アイテムも「手札にありますから、当然含まれます。」ということでした。また、非戦闘時では「バトル中でない場合は手札は存在しないので必ず失敗します。」という仕様です。 しかし、行動不能PCの手札がない時に限っては、「アイテム」にチェックが入っている時同様にアイテムを検索できるということでしょうか？ 「手札とアイテム」の概念は1.50で曖昧になっていますので、その切り分けは1.50に準じることができず、どうしても恣意的な決断になってしまいます。
もしそういう挙動があったとしても、行動不能者を除外するオプションを付け加えれば
いずれにせよ、仕様衝突のために価値の低いオプションが増え続けるのは可能な限り避けるべきで、この提案によって実現できるメリットはそれを超えうるものとは思えない、というこちらの疑問で話が止まっているように思います。
-
reporter
「手札」のみにチェックが入っている時、アイテムも「手札にありますから、当然含まれます。」ということでした。
その質問の文脈では行動不能時の事は訊ねられていないのでそうは答えなかったのですが、行動不能時に手札のみが対象であれば含まれません。なぜなら手札は存在しないからです。それが仕様ですから、将来WSN仕様に対応するエンジンはこの挙動に合わせなければなりません。
仮に他の仕様が作られ、それが「行動不能時には手札は無いが、アイテムだけは例外として手札だけが対象の時も探索する」というものだったとしたら、その仕様のシナリオをWSN形式に変換する時にアイテムのチェックを加えるだけで首尾よく対応できます。アイテムは必ず手札にも含まれるからです。
また、非戦闘時では「バトル中でない場合は手札は存在しないので必ず失敗します。」という仕様です。
一応念のために補足しておきますが、手札だけが対象であれば当然失敗します。アイテムも対象に入れれば、非戦闘時にはアイテムだけが探索されます。
いずれにせよ、仕様衝突のために価値の低いオプションが増え続けるのは可能な限り避けるべきで、この提案によって実現できるメリットはそれを超えうるものとは思えない、というこちらの疑問で話が止まっているように思います。
こういうことは権限を持っている側が言ってはいけないと思うのですが、すみませんが仕方無いので書かせていただきます。
私から見れば、「アイテムと手札」「アイテムのみ」こそ、その場しのぎの価値の低いオプション以外の何者でもありません。CW全体から見て一貫性が無い上に、利便性でもチェック式に劣ります。それを選択する理由がありません。
-
なぜなら手札は存在しないからです。それが仕様ですから、将来WSN仕様に対応するエンジンはこの挙動に合わせなければなりません。
はい。それが正しいと思います。故に上述されたような事実はこの件に関係がありません。その仕様は長月さんが「作る」ものでCWとCWプラットフォームに承認されている1.50には準じていない異質なものです。
こういうことは権限を持っている側が言ってはいけないと思うのですが、すみませんが仕方無いので書かせていただきます。 私から見れば、「アイテムと手札」「アイテムのみ」こそ、その場しのぎの価値の低いオプション以外の何者でもありません。CW全体から見て一貫性が無い上に、利便性でもチェック式に劣ります。
いえ、はじめからはっきりそれを露呈して頂きたかったのです。 「一貫性がない」ということは上述の通り、千差万別な長月さんの感覚的な話です。 これはどう理屈をつけても、その美意識を満たすためだけの無用な改変であり、前身課題を発展的に解決するどころか事態を悪化させます。
-
reporter
美意識云々の話は避けてください。その論法で相手の意見を否定できるとしたら、何を言っても「それはあなたの美意識だ」と言えば否定できてしまいます。それは論法自体が間違っているからです。話をこじれさせたい場合はともかく、そうでない時は使わない事をお薦めします。
念のための補足ですが、美意識自体はソフトウェアにとって最大限に大切なものです。私が言っても信用できないというのなら、古典「ソフトウェア作法」の冒頭の一章がコードスタイルの章である事や、コードコンプリートやリファクタリングといった名著が明快に示していますから、それを参照してください。
もう1つ補足しておくと、ソフトウェアに思想がないという事もありえません。「思想があってはならない」というのはそれ自体が思想であって、自己矛盾を起こしており成立不能です。
前身課題を発展的に解決するどころか事態を悪化させます。
なぜ悪化させるのですか？ ご指摘の懸念は全て当たらない事を示したはずです。
-
自分もできれば避けたいですし、こじらせたいわけではもちろんないです。 それでもCW由来の機能において美意識の混入を除外するのはCWPyがCWであるために必要なことです。 さもないと「なぜこうなっているのかわからない、多分バグだな、ここはこうしよう」という 論法がまかり通るためで、この件とごく一部のマイナー挙動においては現にそうなりつつあります。
Pyは歴史的に1.50を認めざるを得ません。歴史的にはPyの開発が先ですが、シナリオなどの1.50の資産を「使わせて頂いている」からです。Py向けに作られた資産は現時点でそう多くありません。 なので、それを覆すのには、美意識だけでは足りません。(アクションカード持ち帰りバグだとか、ユーザーにとんでもない不利益がある場合などを想定しています)
自分も念のため、「ソフトウェア開発」に美意識が必要なことは否定していませんし、 長月さんのそれに敵意を持っていたりだとか、1.50が何よりも優先されるべきと言っているわけではありません。 (であればこのようにメリット度外視で莫大な時間をPyに費やしてはいません) 法的・ライセンス的問題とは別に、1.50以下の資産を継承するにあたって、道義的に問題があると言っています。
なぜ悪化させるのですか？ ご指摘の懸念は全て当たらない事を示したはずです。
それによって現時点で最終的に示されたのは感覚的な裁量でしたので、当たらないことは示されていないように思います。
以前も書きましたし、Irakaさんも同様なことを述べられたと思いますが、 愛護協会1.28/1.50に歴史的問題があり、私家版エンジンも複数ある現在の状況で、共存を図ろうとしている人たちが作っているシナリオは 「NEXTとPyどちらの仕様にも衝突しない1.20-1.50仕様」です。 Pyが(1.50から見て)勝手に仕様変更・有用なバグを修正して(あるいは仕様を合わせず)「Py1系クラシック形式1.52仕様」みたいなややこしいものを作っていくほどに その規格の煩わしさは上がり、解説しにくくなり、1.50/NEXTだけなら取れる選択肢が閉ざされていきます。 (Irakaさんは判定で全てに繊細に対応することでその1.52仕様を上手く活用しようとしていますが、それを他の作者に強いることはできません)
Py独自仕様、XEditorが1.50仕様の思想と食い違うほど1.50との親和性が悪くなります。 そうなると1.50にいる共存派において、XEditorの習熟難度が上がっていき、制作ツールとしてXEditorおよびPyを選択肢に入れる動機が失われていきます。WSNが成立するにはまずXEditorに馴染んでもらう必要があるのに、そこで壁を作ってはすべてのことがおぼつきません。 これは二極化を呼びますので、圧倒的にユーザーが少ない現時点ではむしろ「Pyにはバグがある」という状況で放置しておく方がまだしもマシに見えます。
-
reporter
私がCWPyの目標として挙げた事柄について勘違いされていませんか？
私が目標として言っているのは、過去に作られたCWのシナリオを出来る限り問題なくプレイできるようにする事です。
これは1.50を完全に再現する事とイコールではありません。
たしかにそれも1つの方法ではありますが、1つしかないわけではありません。また、その方法はリバースエンジニアリング以外の方法では実現不能で、CWPyでは最初からそのアプローチを取ってはいません。その間には論理の断絶があります。私はCWを完全再現しようとしているのではありません。
また、出来る限りという前提がついている事に注意してください。例えば1.50ではエディタで普通にCWの宿データを破壊に至らしめるシナリオを作る事ができますが、そのシナリオでCWPyでも同じように宿が破壊されるべきとは考えていません。
それによって現時点で最終的に示されたのは感覚的な裁量でしたので、当たらないことは示されていないように思います。
どこがですか？ 具体的に示してください。具体例に関しては具体例で答えました。もし「いまだ見つかっていない未知の問題に対処できないかもしれない」というような話であれば、それは「アイテムのみ」でも同じ事です。
法的・ライセンス的問題とは別に、1.50以下の資産を継承するにあたって、道義的に問題があると言っています。
「効果系カードとして特殊技能・アイテム・召喚獣が1セットになっているのが元々のCWの仕様で、キーコード所持分岐という後付のもののためにそれを曲げるのは道義的に問題がある」と言われたらどう反論しますか？
その論法では同じ出発点から矛盾する2つの結論を導き出せてしまいます。論法が間違っているからです。その論法が通るとは思わないでいただけると、そうした説明をする必要がなくなるのでありがたいのですが。
Pyが(1.50から見て)勝手に仕様変更・有用なバグを修正して(あるいは仕様を合わせず)「Py1系クラシック形式1.52仕様」みたいなややこしいものを作っていく
今回のWSN仕様では現に1.50の挙動に対応する方法を書いているにもかかわらず、なぜそんな事を言えるのか疑問です。
Py独自仕様、XEditorが1.50仕様の思想と食い違うほど1.50との親和性が悪くなります。
シナリオのタイプに合わせて柔軟にUIを変える事もできますし、もっと分かりやすいUIを設計する事もできます。分かりやすくする努力は必要です。
それ以前に、今回のキーコード所持分岐の機能追加程度で、そこまでの大げさなUIの変更は発生しません。今回の話でそれを持ち出すのは無理筋です。
-
勘違いというより、自分はその「目標」は長月さんのルールであって、 それに基づいていようが、いなかろうが問題にはしていません。 資産を継承するにあたって尊大な態度であることは、目標に沿っているか否かにかかわらず咎められてしかるべきだからです。 宿の破壊云々はアクションカード持ち帰りバグというので例外的な例として上げたつもりです。
どこがですか？ 具体的に示してください。
本来は「ご指摘の懸念は全て当たらない事を示した」という時点でそちらがすべて具体的に示すべきだと思いますが、 「仕様衝突のために価値の低いオプションが増え続けるのは可能な限り避けるべき」「最終手段なのでは？」という再三の指摘に、 「私から見れば、」主観的に一貫性が無いというのと利便性でチェック式に劣るという美意識を示されただけです。
「効果系カードとして特殊技能・アイテム・召喚獣が1セットになっているのが元々のCWの仕様で、キーコード所持分岐という後付のもののためにそれを曲げるのは道義的に問題がある」と言われたらどう反論しますか？
「では1.50はCWではないと否定するわけですから、筋を通すには、その対応をうたうのをやめて、CWの現実を無視し、1.28以下のみをサポートして細々と独自路線を歩むしかないですね…」と答えます。
今回のWSN仕様では現に1.50の挙動に対応する方法を書いているにもかかわらず、なぜそんな事を言えるのか疑問です。
現時点のデイリービルドでこのPy側のバグが修正されていないですから、現段階ではそういうしかありません。Py1.52仕様対応シナリオとして、Irakaさんのシナリオがあります。
今回の話でそれを持ち出すのは無理筋です。
ですので、今回まで歩み寄る努力をしてきたつもりです。
-
reporter
勘違いというより、自分はその「目標」は長月さんのルールであって、 それに基づいていようが、いなかろうが問題にはしていません。 資産を継承するにあたって尊大な態度であることは、目標に沿っているか否かにかかわらず咎められてしかるべきだからです。
はっきり言って私は@akkwさんが随分尊大かつ高圧的で滅茶苦茶な主張を押し付けてくると感じていますし、それを既存のCWユーザや製作者をだしにして主張している事は自分の主張の責任をそれらの人々の押し付ける事であって最悪だと思っています。そのような主張は私を説得する役には立ちません。逆効果ですから、避ける事をお薦めします。
ただ、それと、仕様や機能の是非は関係ありません。
「仕様衝突のために価値の低いオプションが増え続けるのは可能な限り避けるべき」
そもそもその主張は間違っています。互換対象の仕様が、キーコード所持分岐の範囲を増やさなければWSN側も増やす必要はありませんし、もし相手の方が増えたとしたら、それは価値の高低は関係なくこちらも増やさなければなりません。
一見してそう思ったのでそこには具体的な反論が抜けてしまっていましたね。その点は申し訳ありません。
で、「アイテムのみ」は互換対象で範囲が拡張された時にオプションを増やさずに対応できるのかというと、できない事はお分かりいただけると思います。
「では1.50はCWではないと否定するわけですから、筋を通すには、その対応をうたうのをやめて、CWの現実を無視し、1.28未満のみをサポートして細々と独自路線を歩むしかないですね…」と答えます。
なぜですか？ 実際に対応できていますし、今も対応しようとしています。今後も、互換性問題が出てくるたびに、いかに整合性を保ちつつその問題を吸収して軟着陸させるか、という難問と取り組む事になるかと思いますが、それは何度も繰り返してきた事です。
シナリオ再生に関するこれまでの努力をまったく無視し、これからの努力も無視しなければ、そのような主張はできないはずです。
-
reporter
できる限り避ける努力はしたつもりなのですが、結局こういう展開になってしまいました。
そろそろもう1週間くらいクールダウンの期間を置いた方がいいでしょうか。
-
体調と精神状態があまりよくないので的はずれなことを申し上げるかもしれませんが、一点指摘したいことがありましたので発言します。
現状では、1.50仕様にそのまま合わせておくのが一番よく、 (永遠にそのまま変えてはならないということではないです。1.50/NEXTが主流である限りは永遠になりますが)
これは「主流ではない現在は1.50/Nextにおもねり、Pyの勢力が十分に拡大されてから態度を変えるべきだ」との主張に見えます。これはあまりに不誠実な態度だと思います。現在のCWPy開発およびユーザーに自由な発展を禁じ、機を見て今後獲得するCWPyユーザーを振り回せばいいと言っているように見えます。
私はこの件に関して、k4nagatsukiさんの手法を支持します。
#433にて私は「仕様を合わせるより、正式に手札内の所持判定を追加したほうがいい」と発言しています。この手法に難点を見出してはいません。実現されることを望みます。 -
＞長月さん
はっきり言って私は暗黒 騎士さんが随分尊大かつ高圧的で滅茶苦茶な主張を押し付けてくると感じています
私を説得する役には立ちません。
ええと、自分はそもそも長月さんを説得しようと思っていません。勿論CWをダシに譲歩を引き出そうとしているわけでも。 前身課題においても「長月さんの方針と相反するものであれば仕方ありません。自分が諦めます。」と言っています。 結局のところ、ご自身の美意識、エゴと言っても差し支えないかもしれませんが、 それによって確定されたものを覆そうとしている点、およびCW1.50環境に与えている悪影響を認めて頂ければ、それで自分は引きます。 そこをここまであやふやにされ、あたかも解決意思があるかのように示されたがため、このように無駄な言葉を並べる結果になっています。 進むにつれて、言葉が強くなってしまった非礼は詫びます。 しかし、最初から「ひどいバグ」とのことでこれを放置しているのは長月さん自身にも良くないと思っての言動であることを僅かにでも汲んで頂ければ幸いです。
「アイテムのみ」は互換対象で範囲が拡張された時にオプションを増やさずに対応できるのかというと、できない事はお分かりいただけると思います。
すいません、理解できませんでした。前文も含めて反論になっていないように見えます。無駄なオプションが増えること自体に抑止的になるべきなのは長月さんも常々仰っていることのはずですが…。
なぜですか？ 実際に対応できていますし、今も対応しようとしています。
しようとはしていますが、現時点でできていません。まず合わせてから、その状況を改善しようとするのではなく、 撤回して頂けた以上、蒸し返したくもないのですが、そういう言葉がでてくるということは恐らく本質的には撤回していないと見なして言わせて頂きます。 「合わせたくない」という悪態を先についていました。
＞Iraka.Tさん
「態度を変えるべきだ」とは言っていません。そもそも自分は永遠にこのままで問題ありません。 仮にCWの仕様を変えようとするなら、Lyna氏と関係を修復するか、PyがCWプラットフォームの中心になるかのどちらかです。後者の状態ではもはやそれは無害です。なぜなら他のエンジンは長い年月を経てうち捨てられ、Pyだけが残っている状態だからです。
-
reporter
結局のところ、ご自身の美意識、エゴと言っても差し支えないかもしれませんが、 それによって確定されたものを覆そうとしている点、およびCW1.50環境に与えている悪影響を認めて頂ければ、それで自分は引きます。
その主張自体が@akkwさんの美意識・エゴではないですか。私はそもそもその手の話には与したくありません(喧嘩になります)から、その点について話す事は本来ならば何もありません。今まさに話しているわけですが、これはその方向の話を持ち込まれたから仕方なくしているだけです(一度こちらの方から全部撤回してやめようと提案しましたが失敗しました)。相手がやめようと言えば、いつでもやめます。
それによって確定されたものを覆そうとしている
私はこの問題へ対応するべきでないという立場を11月12日の時点で捨てていますし、従って、
CW1.50環境に与えている悪影響
そんなものはありません。
しようとはしていますが、現時点でできていません。
できていない理由は、この論争のせいです。
「合わせたくない」という悪態を先についていました。
それが悪態に見えるのは悪意を持って見ているからです。言った本人がそんな意図を持っていません。そう見えるような発言をしたのが悪いという事であれば、そんな発言はいくらでも撤回します。
-
reporter
おっともう1つだけ。
無駄なオプションが増えること
対応先の仕様が範囲を増やすのであれば、こちらが増やさなければならないのは「対応のために必要なオプション」であって、無駄なオプションではありません。
-
現時点で「判定結果」というメジャーな挙動が異なる互換エンジンを配布し、Pyを含めたなるべく多くのエンジンに対応しようとする作者が作ろうとする「1.50仕様で手札のキーコードを検索する」というようなシナリオの存在を萎縮させています。またその解決を一週間遅延させ、「そんなものはない」としている事実にこちらの美意識・エゴは関係ないように思います。 この論争を理由としたところで、現状でできていないものは仕方ないです。 では一度停止するとして、修正または言い出しっぺはこちらなのでこちらが作業すれば1.50仕様をマージして頂けるでしょうか？
そう見えるような発言をしたのが悪いという事であれば、そんな発言はいくらでも撤回します。
前身課題ではこちらは「取られかねない」とそのように指摘したにもかかわらず、 「反論すると」などと仰られていたのでこちらの言い分に不服があるが相手にはしない、ということだと受け取りました。 取り合わず、はぐらかされ続けているように見えたので、ここまで続けることになりました。そうして頂けると助かります。
-
reporter
またその解決を一週間遅延させ、「そんなものはない」としている事実にこちらの美意識・エゴは関係ないように思います。
その一週間は私の頭を冷やすための期間だったわけですが、それはあまりにも挑発的・侮辱的な事を言われて怒ったせいですよ。怒る方が悪いというのなら私のせいですし、そうでないなら@akkwさんのせいです。
そんな事を言い争っても解決にならないのは自明です。再度の提案になりますが、お互いの発言を撤回して技術的な話だけをする事にしませんか。
では一度停止するとして、修正または言い出しっぺはこちらなのでこちらが作業すれば1.50仕様をマージして頂けるでしょうか？
いえ、この修正は今回のWSN仕様の拡張とセットで直します。それもセットで作業していただけるというのなら構いません。
-
「態度を変えるべきだ」とは言っていません。そもそも自分は永遠にこのままで問題ありません。
理解しました。では、暗黒騎士さんがそれについて気づいていないだけです。
仮にCWの仕様を変えようとするなら、Lyna氏と関係を修復するか、PyがCWプラットフォームの中心になるかのどちらかです。後者の状態ではもはやそれは無害です。なぜなら他のエンジンは長い年月を経てうち捨てられ、Pyだけが残っている状態だからです。
これについて間違いであると指摘します。現在には存在しない新たなカードワースエンジンが出現する可能性があり、それが主流となる可能性も無ではありません。Pyだけが残っている状態とは限りません。CardWirthPyはCardWirthのReadMe_1st.txtの定義に基づいてカードワースですが、CardWirthにはなりえません。CardWirthPyの仕様が変わっても、CardWirthの仕様が変わることはありません。
CardWirthPyはカードワースであり、WSNというシナリオの独自規格があります。CardWirthPyとWSNの自由な発展を禁止することはできません。CardWirthPyはオープンソースなフリーソフトですから、そのような権限は現在開発の中心にいるk4nagatsukiさんにすらないはずです。
もし、1.50の仕様を絶対の正義とし、不変であるべきという理念を持つのなら、その理念に基づく1.50クローンエンジンを暗黒騎士さんが主導し、開発、保守するべきです。その理念はk4nagatukiさんのCardWirthPyとは相容れないものであると見受けられます。
議題から逸れる話をしてすみません。これにて私は当分沈黙します。
-
挑発的・侮辱的な事を言われて怒った
えぇ…「ひどいバグ」は挑発的・侮辱的・見下し的と取られると客観的にも思うことはなかったのでしょうか？ それはそうと気分を害されたことには重ねてお詫びします。
再度の提案になりますが、お互いの発言を撤回して技術的な話だけをする事にしませんか。
いえ正直なところ、自分はこの提案を「技術的な問題は全く生じていないところに、 思想によって複雑性を持ち込もうとしているのではないのか」疑っていました。 現時点までの発言でそれが婉曲的にでも肯定されたように思われます。なので、それに対して異論がなければこれ以上議論する余地はないと思われます。 こちらは当初より「陰口と受け取られかねない言動を辞める」こと以外、なにも押しつけようとはしていません。そこはご理解下さい。
いえ、この修正は今回のWSN仕様の拡張とセットで直します。
では現時点では有害だというスタンスをこちらは崩すことができません。 WSN拡張には「こちらも思想的に」全く賛同していないので、そうなるとモチベはないのでお任せすることになると思います。
-
reporter
えぇ…「ひどいバグ」は挑発的・侮辱的・見下し的と取られると客観的にも思うことはなかったのでしょうか？
あれば言いませんでした。
「バグ」と言ったのは今でも正しいです。その挙動ではWirthBuilderの記述が嘘になってしまいます。ユーザに嘘の情報を提示するというのは、エディタの記述と実際の挙動のどちらが本当であれ、バグだと言うべきです。ここで、私はバグの定義として「提示された情報と実際の挙動が食い違う」というものを用いています。この定義には条件があって、「ユーザを騙す事がある(ゲームのような)ソフトウェアではない」というものですが、WBは明らかにそのようなソフトではありません。
ひどいというのは主観的な話ですね。それはそう感じられたのでしたら申し訳なかったです。
ただ、ことCWPyの開発に関しては、後にも先にも私はそういう意図をもって発言する事は可能な限り避けようとしています。今回そう取られてしまったというのは、人格に信用が無いという事ですね。それは今日の話の内容を見ても仕方のない事かと思うので、その点は私のせいかと思います。
現時点では有害だというスタンスをこちらは崩すことができません。
一応言っておきますと、この挙動を利用したシナリオを作ることは私は現在も今後も推奨できません(「しません」ではなく、「できません」)。なぜならCWNextの側で挙動が変わる可能性があるからです。メッセージの位置ずれバグなどへの対応を見るに、あちらの方は互換性を切り捨てるのに容赦が無い印象です。今回の挙動を利用して1.50・1.60向けに作っていたカードが将来のCWNextで動かなくなる可能性は高そうだと予想しています(追認される可能性も無いとは言えませんが)。
CWPy側で保証できるのは、「CWPyはこれから対応しますし、将来も動きますよ」という事だけです。
アイテムと手札を検索する、という事を安全に行えるのは、当面は新しいWSN仕様を使って作るシナリオだけという事になるかと思います(1.50仕様は前述のように将来の保証ができません)。このissueの提案はそのためのものでもあります。
-
＞Iraka.Tさん
もし、1.50の仕様を絶対の正義とし、不変であるべきという理念を持つのなら、その理念に基づく1.50クローンエンジンを暗黒騎士さんが主導し、開発、保守するべきです。
なぜご自身で引用された、
(永遠にそのまま変えてはならないということではないです。1.50/NEXTが主流である限りは永遠になりますが)
が抜け落ちているのでしょうか…。最大限理解しようと試みましたが、 敵対論者相手に、ご自身の美意識で聞こえの良い正論を言いたいだけに思えました。違うなら申し訳ありませんが、自分からは特になにもありません。
それとは全く別に、長月さんと相容れないことは完全に理解しました。
最後に。
数々の非礼を言って申し訳ありませんでした。今後自分がPyの方針について口を出すことはありません。 一応断っておきますが、この顛末によって、自分がPyに対して敵対的行動を取るだとかそういうことはありません。 wikiなど、ずいぶんとインフラに踏み込んでしまったので引き継いでくださる方がいればその方がいいかと思いますが… 自分が申し出たことですので、やめろと言われない限りはできる範囲で続けたいと思います。
-
reporter
あ、あと、
「陰口と受け取られかねない言動を辞める」
これは、努力はしますが、実際には不可能だと思います。
何しろ実際に陰口でもなんでもないつもりで書いた事が陰口といわれてしまっています。私も人間なので、もっと気をつけます、以上の事は言えないです。
出来る限りの努力はしていますし、今後もします。
-
reporter
それとは全く別に、長月さんと相容れないことは完全に理解しました。
CWのよりよい未来と抽象的に言えば、目指している所は同じではないでしょうか？
一度の論争で決別するというのは早まった事だと私は思います。私がそうしたように、ゆっくり考える時間を取られてはいかがでしょうか。
方針に口を出すのは悪い事ではありません。もちろんそれは議論になるので(相手も含めて)覚悟が必要な事ですが、方針というものは時と状況に応じて変えていかなければならないものです。私はその点については否定はしません(なんでもかんでも変えればいいってものでもないですが)。
この件で@akkwさんが今後口を出さないとかそのような対応をされる必要はありません。
自発的にそうしたいと仰るなら引き留める事もできませんが、いつ戻っても大丈夫です、という事はお伝えしておきます。
-
reporter
実装にあたって不明な点があったので1.50で調べました。あとは過去の調査結果で網羅できていると思います。
- 手札消去効果で手札が消えるか？ → カード交換を含め消えるようです。
- バトルイベント中に手札はあるか？ → 予期した通りカード交換を含めて無いようです。
-
reporter
まだありました。
- カードを山札からドローするタイミングはいつか？ → ラウンド終了時で時間経過処理が行われますが、その時に個別にドロー処理が行われているか、あるいは全ての処理が終わったあとで全員まとめて行われているか。中毒ダメージによる死亡イベントを利用して調べてみたところ、後者のようです。
以上に基づいてpull request #1644で試験実装を行いました。クラシックなシナリオも1.50と同様に動くようになっているはずです。
対応するエディタはcwxeditorの20161126版以降です。
-
キーコード分岐コンテント（キーコード所持判定分岐）の不具合報告です。
コンテントの適用範囲が
荷物袋または全体(荷物袋含む)の場合、それが含まれているWsn.1形式のシナリオを開始できません。読み込み失敗のダイアログの表示後に操作不能となりました。 シナリオプレイ中にCWPyを更新した場合は読み込めるものの上記条件のコンテントを読み込むと操作不能になりました（この場合はプロセスがゾンビ化。タスクマネージャから終了する必要あり）。- その他の形式のシナリオでは検証は行っていません。検証を行ったのはWsn.1形式だけです。
パーティの誰か一人や現在選択中のメンバは特に問題なく動作しました。- 問題箇所のツリーの利用数を
0にする等して無効化するとシナリオを開始できました。
Version : 1.1 / 2016-11-28 22:18:46 DateTime: 2016-11-29 18:16:05 Traceback (most recent call last): File "cw\thread.pyo", line 704, in run File "cw\thread.pyo", line 734, in _run File "cw\thread.pyo", line 743, in main_loop File "cw\eventhandler.pyo", line 96, in run File "cw\eventhandler.pyo", line 277, in lclick_event File "cw\sprite\card.pyo", line 1230, in lclick_event File "cw\event.pyo", line 557, in start File "cw\event.pyo", line 736, in start File "cw\event.pyo", line 793, in run File "cw\event.pyo", line 966, in action File "cw\content.pyo", line 1527, in action TypeError: has_keycode() takes at most 5 arguments (6 given) -
reporter
ありがとうございます。pull request #1652で修正しました。
荷物袋の検索で無条件にエラーが発生していました。なぜこんなテストケースを見逃したんだろう？
-
Wsn.1形式のシナリオにて、特に問題なく動作することを確認しました。
気の利いた事を言うのはあまり得意ではありませんが……、 荷物袋の方に検索を掛けるシナリオは中々お目にかかられませんので それで見逃されたのかもしれませんね（手札の問題もありましたし）。
CardWirthPy 1.1 Build: 2016-11-29 20:41:44 -
クラシックなシナリオにおいて正常に動作しないようです。
戦闘中、使用時イベント内で、アイテムのキーコード所持判定を行っても、手札内のキーコード（技能で検証しました）が判定されません。
非戦闘中、使用時イベント内で、アイテムのキーコード所持判定を行うと、次のようなログを吐いて操作不能になりました。
Version : 1.1 / 2016-12-01 22:09:44 DateTime: 2016-12-02 22:39:19 Traceback (most recent call last): File "cw\thread.pyo", line 704, in run File "cw\thread.pyo", line 734, in _run File "cw\thread.pyo", line 743, in main_loop File "cw\eventhandler.pyo", line 96, in run File "cw\eventhandler.pyo", line 277, in lclick_event File "cw\sprite\card.pyo", line 1247, in lclick_event File "cw\thread.pyo", line 1426, in call_modaldlg File "cw\thread.pyo", line 743, in main_loop File "cw\eventhandler.pyo", line 113, in run File "cw\eventhandler.pyo", line 618, in executing_event File "cw\character.pyo", line 903, in use_card File "cw\event.pyo", line 1253, in start File "cw\event.pyo", line 736, in start File "cw\event.pyo", line 793, in run File "cw\event.pyo", line 966, in action File "cw\content.pyo", line 1527, in action File "cw\character.pyo", line 415, in has_keycode File "cw\deck.pyo", line 228, in is_throwed AttributeError: 'Deck' object has no attribute '_throwaway'また、メニューカードのイベントで、全体(荷物袋含む)やアイテムのキーコード判定を行うと類似（
AttributeError: 'Deck' object has no attribute '_throwaway'）のログを吐いて操作不能になりました。開始エリアの到着イベントに全体(荷物袋含む)やアイテムのキーコード判定が含まれるとシナリオの読み込みに失敗します。 -
reporter
pull request #1658
ありがとうございます。
_throwawayの方は単純なバグですが、もう片方は興味深い現象でした。「使用したカードがいつ手札から取り除かれるか」という問題だったようです。1.50では手札に1枚だけある特殊技能カードを使ってそのカード自身を探した時に見つかります。エリアイベントや成功・失敗・死亡イベントでも検証しましたが、どうやら全てのイベントが終了するまで同様に見つかるようです。つまり手札から取り除かれるのは最後の処理という事になりますが、CWPyではその順序が逆になっていたので見つからない場合があったようです。
-
対応ありがとうございます。
_throwawayは解決されたようです。使用したカードについては、まだ小さな問題が残っていました。1.50では、そのラウンドの行動として選択したカードは、敵味方全員の行動が終わるまで取り除かれないようです。
エネミーに使用時イベントを設定したカードを持たせて検証したところ、カード交換などの手札消去効果、行動不能状態による手札の消去が起きても、1.50では取り除かれませんでした。
中毒による擬似ラウンド終了イベントが発生した段階では、取り除かれているようです。行動として選択しなかったカードは、手札の消去が起きると取り除かれているようです。
-
reporter
- pull request #1659
- pull request #1660
ありがとうございます。そのタイミングには気づきませんでした。
ラウンドが終了して時間経過イベントが発生するまでの間に防御カードなどの能力修正が消滅する事が知られています(それを利用して防御不能の攻撃をかけるというシナリオがあります)。たぶんこのタイミングで手札も取り除かれているのでしょう。
また、カード消去は「使用中のカード以外」を手札から取り除く効果と思ってよさそうです。使用中の手札はそのラウンドの終わりに消えるので、それで全部交換となるのでしょう。
行動不能状態による手札の消去が起きても、1.50では取り除かれませんでした。
これは私の方では確認できませんでした。睡眠・呪縛とも、使用中であっても手札が消滅します。どのような条件で検証したか教えて頂けないでしょうか。
-
https://bitbucket.org/IrakaT/mywirth/downloads/Verifier.cab
検証用シナリオです。エネミー所持カードの使用時イベントでキーコード「渾身の一撃」の有無を見ています。渾身の一撃を選択している場合、呪縛状態になっても渾身の一撃が検出されます。
-
reporter
ありがとうございます。
ラウンドイベントで呪縛した場合は渾身の一撃を使用していても「なし」になります。これはどういう事なんでしょう？ 渾身の一撃を選択しないと「あり」→「なし」へ変化するところからすると、イベント開始時の状況が固定されているというわけでもないようです。
-
おそらくですが、選択したカードが使用中として固定されるタイミングが、ラウンドイベントの後なのだと思います。
未行動の状態で行動不能状態に陥ると、固定されたカードがない状態ですべての手札が消去されてしまう。行動不能を伴わない手札消去は、行動の予定があるので消去してはならない、という例外処理がされているのではないでしょうか。たしか、古いバージョンのCWでは手札消去効果が行動キャンセルとして使用できたはずです。
もしかするとラウンドイベントで行動キャンセル効果を使用した場合も検証しなければいけないかもしれません。ちょっと今はもう遅いのですみません
-
reporter
敵の方が先に行動すると呪縛によって「あり」→「なし」に変わりました。使用後のカードがどこかに保存されていて検索対象に入っているという事なのでしょうか？
-
reporter
- 使用したカードはラウンドの終わりまで残る。使用前にカード消滅効果を受けたり行動不能になったりした場合はこの現象は発生しない。
- 使用回数が0になったアイテムでも、ラウンドの終わりまで残る。
- 時間経過イベントが発生する時点では、使用による残存カードは消滅する。
- 行動キャンセル効果はこの挙動に影響なし。単に行動しなかった場合と同じように動く。
検証するとこのようになりました。この挙動の再現は手許でできているので、問題なさそうならPull Requestします。
-
使用前にカード消滅効果を受けたり行動不能になったりした場合はこの現象は発生しない。
これについて、この現象が発生しないのは行動不能になった場合のみであるようです。行動前に手札消去効果を受けても影響はありません。ラウンドイベントとPCより早いエネミーの使用時イベントで確認しています。
内部処理の推測ですが、おそらくカードには「使用中（使用時ボーナスが発動）」と「使用済（使用時イベントとカード効果が発動）」の状態があり、「使用済」は常に「使用中」であるものとして扱われています。
この推測について検証シナリオを作成しました。使用時ボーナス防御+10のカードに使用時イベントを設定し、このカードを持たせたエネミーを複数配置する。使用時イベントを発動させる。使用時イベントは次のように動作する。
- カード剥奪コンテントで使用者から使用カードを取り除き、他一体のエネミーからも同カードを取り除く。
- 同カードを使用している（はずの）エネミーを選択する。
- 選択中エネミーに効果コンテントで体力回復最大値＋ダメージ直値1を与え、負傷の有無を見る。
- 選択中エネミーに効果コンテントでダメージ最大値を与え、再度3を行う。
- 選択中エネミーが2で選択されない状態にして、2に戻る。
結果、1.50と1.28において、「使用中」はカードを剥奪されたり、キャラクターが行動不能になると解除されます。「使用済」は、カードを剥奪した後も、行動不能になった後も解除されず、「使用中」扱い（使用時ボーナスが発動）でした。
「使用済」は特定のタイミングになるまで解除されないようです。特定のタイミングとは、使用回数の尽きたカードを取り除くときです。使用回数の尽きたカードが手元に残らないようにするためでしょうか。
戦闘中におけるこのタイミングは、「ラウンドが終了して時間経過イベントが発生するまでの間に防御カードなどの能力修正が消滅する」ときなのだと思います。なぜそうなっているのかはわかりません。
-
reporter
これについて、この現象が発生しないのは行動不能になった場合のみであるようです。行動前に手札消去効果を受けても影響はありません。
ちょっと頭が混乱気味になっているのですが、これはたぶん、「カード消去は使用中のカードだけは残す」という挙動で説明できると思います。
使用中と使用済の挙動については、たぶん仰る通りです。ラウンド中に「防御」がカシャッと表示されるのにはなんの意味があるんだろうなぁ、と思っていましたが意味はあったんですね(意図的な仕様かどうかはよく分からないのですが……麻痺しても有効な防御態勢とは？)。
「たぶん」連呼状態で少々自信薄なのですが、ここまで検証で分かった挙動を再現するバージョンをPull Requestしました(pull request #1662)。動きが合っているかどうか試していただけると助かります。
検証シナリオがテスト時に分かりやすくて非常に助かりました。ありがとうございます。
-
手元で検証シナリオを動かしたところ、同じ挙動になっていました。シナリオのほう、役に立ったようで何よりです。ありがとうございます。
混乱のない説明ができるようになりたいです…申し訳ない。
-
reporter
ありがとうございます。マージしました。
CWはところどころ異常にややこしくなっている部分があるので、正確を期そうとするとどうしてもこんがらがった書き方になってしまう場合があります。これはもう仕方ない事だと諦めています。
その方面で一番の難物はエフェクトブースター周りだったり。
-
cwxeditor 5.0α2 で
と設定して、cwxeditor 4.1 で開くと、
とアイテムだけが選択された状態になるということは、
#448も "coupon" と "couponnames"(”coupons”はメンバ選択分岐などで使用済み) は別のプロパティとして持っておいて、Wsn.1 以前のエディタで開いた時には最初の１クーポン名だけになる処理でいいですか？
あと、cwxeditor 5.0α2 では新規でシナリオを作成し、スキン選択した場合のシナリオのデータバージョンの初期値がWsn.1になっているのはいいのかと、
Wsn.2 の追加機能を使用した（上の画像のようにのカードの種類が、”effectCardType” （旧来の 全て・スキル・アイテム・召喚獣 のどれか）に該当しないチェック状態の場合やクーポン多岐分岐を置いているなども含む）場合にセーブ直前にシナリオのデータバージョンをWsn.2に変更する処理を加えたほうがいいのかなと思いました。
あとエディタを開いたあとでエンジンのData/Skinにコピーしたスキンが、スキン選択に反映されないので、スキンのリストを取得するのを概略の設定を開くタイミングでも入れたほうがいいかもと思いました。
ご確認してからでないと pull request 出来ない（一部はたぶん自分には実装不可の）ため、ここに書いておきます。
-
reporter
……
#448も "coupon" と "couponnames"(”coupons”はメンバ選択分岐などで使用済み) は別のプロパティとして持っておいて、Wsn.1 以前のエディタで開いた時には最初の１クーポン名だけになる処理でいいですか？それでいいと思います。新しい拡張されたデータを古いデータに変換する事は本質的に不可能なので、どんな風にしてもよいのですが、その方が多少は親切です。
cwxeditorの内部実装の話になってしまいますが、
Contentクラスのプロパティはできるだけ流用した方がいいです。そうした方が、イベントコンテントの変換でパラメータが失われにくくなるからです。例えばアイテム獲得をアイテム喪失に変換した時に、アイテムIDや範囲の設定はそのまま残ります。これは意図してそういう風にしています。しかし
couponsは得点の概念が含まれているのでそのまま流用はできませんね。
あと、cwxeditor 5.0α2 では新規でシナリオを作成し、スキン選択した場合のシナリオのデータバージョンの初期値がWsn.1になっているのはいいのかと、
これはWsn.2の仕様が決まっていないからです。将来動かなくなる可能性を承知して使う必要があるので、シナリオ作者には意識的に選択してもらう必要があります。
Wsn.2で動かないデータをWsn.1で使おうとした時の結果はシナリオ作者の責任で、cwxeditorとしては「警告まではした。あとは君らの好きにしろ」という立場です。シナリオ作者の意識の外でデータバージョンの変更など勝手な事をすると、余計にトラブルを招くので、そうした事はできるだけしないようにしています。
あとエディタを開いたあとでエンジンのData/Skinにコピーしたスキンが、スキン選択に反映されないので、スキンのリストを取得するのを概略の設定を開くタイミングでも入れたほうがいいかもと思いました。
これは問題なので、シナリオはスキン名も記憶するようにしたいところです。この辺の問題についてはcwxeditorの質問Issueに書きました。
-
reporter
- changed status to resolved
実装済みなので完了にします。
- Log in to comment
（手札としての）アイテムも含まれるということでいいでしょうか。また戦闘中手札は動的であり、戦闘不能・状態異常でカード交換や手札が変動するタイミングを厳密に見直す必要がありそうです。（完璧だったらすいません）1.50のアイテムKC所持分岐では「カード交換」は一度戦闘不能になるとそのラウンドの間は検出されなくなるようです。アイテムは検出されます。
キーコード所持分岐は多くカードギミックに使われる可能性があり、CW宿への持ち出し/持ち込みを想定しなければなりません。 前述の通り、XEditor上の現在アイテムになっている表記を現実の実装に沿うようにアイテム・手札と変え、名称はどうでもいいですが、アイテムのみを新設するのがもっともスマートに思います。（ゲームオーバーコンテントに敗北を追記したように）
1.50仕様 [すべて/技能/アイテム・手札/召喚獣]
WSN2仕様 [すべて/技能/アイテム・手札/召喚獣/アイテムのみ]
この問題が真に解決するのはCW1.60、CW1.70が確定する時です。1.50仕様の実害は汎用KCでのアイテムKC所持判定が戦闘中正確に行えないくらいなので仕様が汚くなる可能性を考えると、1.50を暫定的な仕様とするにしろ、しないにしろ、できれば追加は保留することが望ましいと思います。