提案：メンバ/パーティー単位での別エンジン書き出しor取り込み

[権兵衛 七篠]

別名：｢花いちもんめ｣提案(を
現在のCWPyの宿に対して、
旧来エンジンのキャストデータをメンバ/パーティー単位で編入したい場合、
｢いったん旧来エンジンへ書き出してから、ファイル操作で編入して
その後宿をCWPyに再変換｣か、｢連れ込みNPCとしてシナリオを作成して編入｣
という手続きをとる必要があります。

これを改善し、｢メンバ/パーティー単位｣でも
キャストデータを編入する手段を確立することを提案し、
さらには｢メンバ/パーティー単位｣で他エンジン宿へ
キャストの｢派遣｣を行うことも提案しようと思います。

これら機能により宿やエンジンを越えた冒険者の往来を容易にするだけでなく
｢Pyから持ち出せぬ札を、派遣のさい一旦Py宿の
カード置き場に預けた上で、他エンジン宿でシナリオをこなし、
他エンジンで得たクーポンや手札カードも編入を通じて持ち帰る｣
といったプレイスタイルを確立することを企図します。
派遣の際に識別用クーポンを与えるなどすれば、
派遣先に持ち出せぬデータを持った冒険者がいても、
帰還の際に識別用クーポンを手がかりにPy宿の冒険者データと
つき合わせて併合し、｢宿ごと書き出し｣で生じるようなデータ損失を防ぐ、
といったことも可能にできないか、と思案します。
(データ整合性をつけやすくするためには派遣された冒険者について
Py上では帰還までロックしておいたほうがよいかも？
(ロックする場合｢貼紙を見る｣での｢現在進行中｣よろしく何らかの印をつけるか？))

具体的なインタフェースとしては、｢宿帳を見る｣の画面で
｢新規｣を｢追加｣に改め、新規登録のほか他エンジンの宿からの
冒険者メンバの引き抜き編入の機能を追加するほか、
｢拡張｣に｢派遣｣を追加することで他エンジンの宿への
冒険者メンバの押し付け派遣を実現する、といった実装を提案します。
パーティーの単位では、｢冒険の再開｣の画面で
｢編入/派遣｣に相当するボタンを用意する
(あるいは｢拡張｣というボタンを用意し、
｢編入/派遣/記録｣をボタンの下位に割り当てる？)形で、
同種の機能を実装できないか提案してみます。

実際の機能の実行においては
編入の場合、wchやwcp、またはwptやwplといったファイルの選択を行い
派遣の場合ですと、対象とする宿を選択する形になるかと思いますが、
このインタフェースは宿変換のそれを流用する形で問題ないかと愚考します。

以上が｢メンバ/パーティー単位での別エンジン書き出しor取り込み｣の
提案となります。
ゼイタク云えば元々のエンジンで宿帳や宿選択見るように
(つまりは｢キャラクター情報｣などを確認できる格好で)
選択できるのが理想ですが、
高望みはぜず、まずはファイルやフォルダ選択ダイアログを利用して
実装しても問題はないと思います。
(むしろwchやwcp、またはwptやwplといった
ファイルのD&Dで編入させろという話になりそう(何))

[権兵衛 七篠]

ぁ、Priority：minorで提案しておきます。
宿の丸ごと書き出し/読み込みと違って
たぶんこの話には
｢パーティーに欠員や交代が出る帰還｣やら
｢帰還冒険者のデータ併合処理の詳細｣だの、さらには
｢別エンジン宿以外に別のPy宿とも冒険者をシェアしたい｣とか
詰めるべき話はたくさんあると思うので.......

[k4nagatsuki]

ご提案ありがとうございます。

私には想像できていなかったのですが、宿の部分部分での変換には実は需要があるのでしょうか？ だとしたらいずれ対応する必要がありそうですね。

インタフェースについてご提案をいただいているのですが、これは今も存在する「転送」機能(宿の拡張機能内)のように一覧して選択する形が、たぶん扱いやすいんじゃないかなぁと思います。宿帳のような形だと、カード置場などの異なる形態のダイアログと行き来したりする手間がかなりありそうですし、技術的にも遥かに大変です。

また、宿のロード後に変換を行うというのもセーブ絡みの構造上技術的な困難が付きまといますから、変換・転送は宿はロードせずに行わなければなりません。

さらに、パーティは1ユニットで動かさなければなりません。CWのデータ構造上、内容を一部分だけ切り離す事がかなり困難だからです。特に冒険中のパーティはシナリオの状態やF9用のデータを持っており、整合性が取れている必要があるので、中身を一部だけ取り出すのはさらに著しく困難です。

色々と難しい部分を書きましたが、変換を部分的に行えるようにする(できれば既存の宿に転送できる)というのはいずれやりたくはありますね。実現には時間がかかるかもしれませんが……。

[権兵衛 七篠]

需要というか、そもそもの動機は個人的希望だったりします.....(ヲ
クラシックなエンジンの場合、wchやwcp、またはwptやwplといったファイルを
移動ないしコピーしてやることで宿のあいだの移動ができたんで
これを使ってオフ会なんかで参加者の持ちキャラをひとつ宿の下に集めて
混成パーティーを作ったりとかしていたのを、Pyでもやりたい、
というのがそもそもの動機だったりします。

本来エンジンの動いてないときにファイル操作でやってたことが
この提案の出発点なので、宿帳にいるパーティー編成でない冒険者とか、
あるいは｢冒険の再開｣で選択できる編成済みのパーティーの単位とかが
移動の基本であって、編成済みパーティーから何人かつまみ食いして
派遣するというのはできないという仕様であったり、
あるいはシナリオ遂行中のパーティーは派遣できないやら、
派遣先の宿が何らかのエンジンによって開かれている場合も駄目とか、
派遣を行ったらその時点で宿の状態は自動セーブされるとか、
そういった様々な制約ができるだろうことは、
個人的には織り込み済みというか、問題ないと思っています。
(一応セーブについては
｢｢＃t(または＃m)｣を｢(派遣先宿のフルパス)｣に派遣します。
派遣処理のため、現在の状況が自動で保存されます。よろしいですか？｣
みたいなダイアログを出したほうがよいかも。)

---

あとこの提案書いた事情としては、
札イベントkill(#405)の議論で、

Pyを普段使いし、Nextシナリオを遊ぶときにのみ宿を逆変換してNextに持ち込む、
という遊び方をするユーザーは（数まではわかりませんが）増えています。
それらのユーザーにとって、キャラクターに持たせるカードの需要は、
1.50までのもの（最適）＞Py仕様のもの＞＞Next仕様のもの（不要）です。

という発言があったんですが、
現状の宿丸ごと変換だと、書き出し先のエンジンで対応できない要素が
バッサリはつられて折角の新機能が無駄になるという気がするので、
部分変換でこのロスを回避または削減したいな、という欲張りな希望とか。

よそのエンジン環境へ、普段使いのPy宿冒険者送り込んでプレーするプレイスタイルは、
互換性の厳密な解決やマイナーエンジンへの対応とかあと大人の事情で
シナリオの互換対応がやれない一部エンジンのような場合に有効だと思うんで
ユーザーの利便のためにこうした遊び方を支援したい、というのもあります。
むろんPyで全部のエンジンのシナリオをプレイできるようになるのが理想なんですが
すべてに対応しようとすると何かしら妥協したり制約がついたりして
結局個々のエンジンや個別のシナリオに対しての完全な対応はできないと思うので
そうしたフォローからもれたシナリオやエンジンの救済や次善策として
こういう｢他のエンジンでプレイできる手段｣の充実や強化も大事かと愚考するのです。

---

Pyの宿同士だと｢転送｣で融通ができたんですね。
冒険者といわずゴシップやら終了印まで融通できる、という面では
宿ロードする前の画面から｢拡張｣ボタンで別エンジン宿との部分変換に
対応させるのも確かに一理あるかもです。

問題は自分みたいに｢転送｣機能の存在自体に気づいてない人が
結構いそうな気がすることでしょうか.....orz
自分自身言われてはじめて気づいたというか、
これ起動時の動作で｢最後に選択した拠点を開く｣とか設定していたら
何のことかまったくわからなかったかもです(汗

---

一応、宿帳や編成済み冒険者リストの画面から
機能呼び出す場合の利点を考えるとすれば、
起動時の動作設定にかかわらず日ごろ目にする画面なんで
見落としが少ない、というのもあるんですが、
｢ロード済み｣であるため、名前だけでなく
詳細を容易に確認できるというメリットもあるでしょうか。

加えて、派遣するメンバを選んでパーティーを再編成したり
(メンバによっては名前や解説文、あるいはクーポンの
文字コードで引っかかるパターンもあるかと思うのです。)、
どのパーティーがシナリオ遂行中で派遣不能なのか確認するとか、
手札カードをPyから持出し可能な装備に
持ち替えたりするといった調整もしやすい
(個人的には、持ち出しのできない手札カードについて、
派遣処理の際にリストアップされてカード置き場に預けるか、
派遣処理を中断するかといった確認が出るとうれしいです。)、
......みたいなところでしょうか。

ちょっと特殊な依頼に出かけるような調子で、
他エンジン宿に冒険者を送り出せたら最高かな、とは思う次第です。
逆に宿から出て操作する形ですとこうした手軽さは制限されるんで、
プレイヤーの側では、派遣するパーティーを固定する、
あるいは派遣しやすくするためにPy固有要素を極力避ける、
といった運用をすることも考えられます。

---

言い換えれば、プレイヤーの視点だと、宿選択画面での変換は
利便性がわかりにくいということなのかもしれません。
冒険者と彼らの使う手札カードだけでなく、
普段隠蔽されてる/目立たないデータを含めて融通ができる、
何より開発者に優しい(作りやすくてバグを出しにくい)、
といった意味では｢転送｣機能は優秀なのですが......(悩

[req]

自分もPT,PC単位での転送機能はあったら嬉しいです＼(^_^)／ CWPy専用、対応パーティメーカーを作ろうとして失敗しているので、 Pyの開発の一息つけたときにでもご実装をご検討ください。

[k4nagatsuki]

CWPyの範囲であれば、宿内のメンバやカードの転送機能は宿選択ダイアログの拡張メニューの中にありますのでご利用ください。

他のエンジンとのやり取りとなると、頑張ればできそうではあるのですが、色々やるべき事が溜まっているので（むしろ溜まっていく一方？）なかなか手を出せません。正直言っていつになるか分かりませんので、ゆっくりお待ちいただければと思います。

もちろんどのたか実装してくださるようなら大歓迎です。

[req]

いつも開発お疲れ様です(^o^) 今ちょうどtwitterで暗黒騎士さんと話していて、 長月さんの話が出てきていたところです。 長月さんtwitter別アカウントででも再開しないんですか？ CWPyのアピールなり開発状況なりどんどん熱く語って もらいたいし、それを聞きたい自分があるんですけどね✨

メンバーとパーティーまでだったら自分でもPythonとか ここのソース管理とか覚えなくても 外部ツール簡単に作ってみて対応出来そうな気もしてきました。 ただ、パソコンから開発ツール類をもう削除してたので、 まあ何か入れて試してみます。 余裕が出来たらここでの実装も試してみたいです！

アニメ見るのとかが忙しい？とかtwitter 見たりとか、 CWPy for Android 計画(ただAndroid にLinux 入れて CWPy する計画)とかあって 時間取れるか分かりませんけどね😉

[k4nagatsuki]

長月さんtwitter別アカウントででも再開しないんですか？

すみません、私は元々コミュニケーションを苦手にしている性格でして、個人間でやり取り可能なツールはストレスになってしまうのです。あのアカウントはどうしても連絡が取れないので仕方なく作ったもので(勢いで余計な事も語っちゃってるけど)、今のところTwitterを触る気はないです。

もちろんそれなりの情熱はありますが、それは必要な議論と行動で示していくつもりです。今後とも適当に見守ってやってください。

---

宿のデータ処理は、cw/yadodb.pyやcw/dialog/transfer.py辺りが参考になると思います。SQLiteによるデータベースを使ってメンバの一覧などを管理しているのですが、データの本体はXMLファイルで、データベースは便宜上の存在にすぎない(消しても動く)事を知っていれば、内容を理解しやすいと思います。

[req]

twitterの件了解しました。

自分も未だにコミュニケーションは得意ではないですし、 twitterは暇なときのタイムライン観賞用ツールとして２年間使ってました。

ここで書き込みあるとGmailに届いて通知が来る便利な世の中になったので、 長月さんとはここで連絡とればいいだけですもんね！

CWPy専用パーティメーカーはメンバー、パーティー一覧まではXML読み込んで、 画面に一覧表示出来ていた(コンテントなどのXMLがVisual Studio で読み込むには、要素・属性が複数だったり、複雑だったりして挫折しました) ので、XMLファイルの追加、削除、入れ替え、誤動作防止のためのデータベース削除とかしたら大丈夫ですか？

[k4nagatsuki]

大丈夫と言いたいところですが、実は部分的にそうではないです。カードの順序情報がデータベースにしかありませんから、整列条件を「なし」にした時の順番がリセットされてしまいます。また、次回の宿の読み込みがかなり遅くなります(DBを再構築するため)。

もしPythonを使うのであれば、一番簡単なのはyadodb.pyをそのまま流用する事です。操作後にupdate()メソッドを実行すればDBの内容が更新されます。他言語でも、このモジュールだけは移植した方が却って楽ができると思います。SQLiteはほとんど全てのプログラミング言語で操作できるはずです。

[req]

お早いお返事ありがとうございます😃

そうなんですね。了解しました。

あと早くPythonちゃんと読めるようにならないと！