雑多な報告・連絡用Issue(part7)

Issue #329 resolved
k4nagatsuki repo owner created an issue

簡単な報告だけするために新規にIssueを立てるのは躊躇する事があるという意見をいただいたので、返信を書くだけで済むように雑多連絡用としてこのIssueを立てておきます。

軽い連絡や報告など、自由に書き込んでください(ただし返信にはBitbucketのアカウントが必要)。

スレッドが長くなりすぎた場合はクローズして次の汎用Issueを立てます。


このIssueは#302 雑多な報告・連絡用Issue(part6)の続きです。

Comments (220)

  1. k4nagatsuki reporter

    先ほど0.12.4α4をリリースしました。

    月刊程度のペースでリリースすると言っていたα版ですが、事情があって、私の独断で先月と先々月のリリースを止めていたので、3ヶ月分のリリースとなります。

    その事情とは、ある機能についてある方から内々にご意見をいただき、その話し合いが今なお続いているというものなのですが、内容を公にしたくても、そうする合意もまだ取れていない状態です。相手がいる事ですので、私個人の判断で勝手に公開するわけにはいきません。本当に申し訳ないのですが、具体的な説明については今しばらくお待ちください(最後まで非公開のままというのはできれば避けたくはあるが、ないとは断言できません……)。

    また、実は11月の時点で「そろそろβを」と考えていたのですが、同じ事情でまだリリース関係の身動きが取れない状態です。申し訳ありませんがこちらもしばらくお待ちいただければと思います。

  2. Y Sakaguchi

    こんばんは、α版リリースお疲れ様です。お話合いとやらの内容が悪いものでないといいのですが…。

    それはさておき、報告です。

    PARANOIAというシナリオでアルファ=コンプレックス様というキャラを仲間にしたのですが、彼女?がパーティ内にいる時だけデバッグモードでの冒険者の編集が出来なくなるようです。

    キャラ設定的には物凄く「らしい」挙動で笑ってしまったのですが、PCデータからエンジン側にそういう妨害的な干渉が出来てしまうという点で興味深かったので、エラーログ添付の上で報告しておきます。

    具合の方はもう大丈夫でしょうか? どうぞお大事に、ではでは。

  3. k4nagatsuki reporter

    ありがとうございます。pull request #1301で修正しました。

    キャラクター編集ダイアログの改造時にうっかり@レベル上限が常に存在する事を前提にしてしまっていました。連れ込みキャストはそれを持たない事がほとんどなので、だいたいのキャラクターがエラーになってしまっていたと思います(しかしよりによってコンピュータ様で発覚とは……)。

    ご心配をおかけしてすみません。無理せず程々にやっていこうと思います。

  4. Y Sakaguchi

    こんばんは、毎度お疲れ様です。

    エラーの修正を確認しました。あまりにも挙動とキャラ性が合い過ぎていたので、エンジン側のバグという可能性を失念してしまいました(笑)

    ともあれ直って良かったです、ではでは。

  5. 暗黒 騎士

    どうもまだ体力の計算に食い違いが起こっている感じです。

    CWおよびEditorでの出力ではLV10の時、

    • 生命力8、精神力5のPCの体力は90((4+4)*11+2.5=90.5)
    • 生命力9、精神力5のPCの体力は96((4.5+4)*11+2.5=96)

    になるはずですが、Pyで新規作成・再計算などしたキャラはどちらも90になっているように見えます。 (男性、若者、勇将型、醜悪、田舎育ち、貪欲のキャラを作り称号999点を与えてテスト)

    character.py 
    maxlife = int((vit / 2 + 4) * (self.level + 1) + minval / 2)
    

    計算式は合っているはずなので生命力が奇数で/2で割られた時点で小数点が切り捨てられてしまっているのかも?

  6. Liar_cw NA

    Google検索を電卓代わりにして計算してみましたが、 暗黒騎士さんの仰るとおりのようです。

    int型には整数しか入れることができないので、 どうやら計算式の時点で既に小数点以下は切り捨てられているようですね。

  7. k4nagatsuki reporter

    ありがとうございます。pull request #1308で合わせました。

    途中で浮動小数点数が発生する計算と整数のみの計算が混在していたので、CW内では常に整数計算が行われるという思い込みのもと後者に合わせてしまったのですが、判断ミスでした。ちゃんと調べる癖をもっとつけないといけません。

  8. 暗黒 騎士

    お疲れ様です。修正を確認しました。

    intとfloatってそういう違いがあったんですね。勉強になりました。

    pull request #1304のcreate.py のbreakを消したのが戻っているようですが、これはいいのでしょうか?

    追記:自己解決。投稿した瞬間、位置が違うのに気付きました。失礼しました…

  9. k4nagatsuki reporter

    ご確認ありがとうございます。

    このbreakは、もともとその位置にあるべきものだったのです。抜けるループが間違っていただけです。外側のループを抜けるべきところ、内側のループを抜けてしまっていました。

    別にbreakしなくてもスキンのデータが誤っていない限り正しく動くのですが、一応補っておいたのをまとめてcommitしました。

  10. 暗黒 騎士

    アガーター荒原というシナリオで到着メッセージ「アガーター荒原近くの村に到着した」が表示される前~瞬間にF9すると、宿に帰還してからもそのメッセージが表示されっぱなしになり、操作不能になることがありました。タイミング的な問題のようで、タイミングよく押すのが大変ですが再現はできるっぽいです。

    Version : 0.12.4 Alpha 4 / 2016-02-11 19:45:17
    DateTime: 2016-02-12 16:17:16
    Traceback (most recent call last):
      File "cw\thread.pyo", line 622, in run
      File "cw\thread.pyo", line 652, in _run
      File "cw\thread.pyo", line 664, in main_loop
      File "cw\thread.pyo", line 868, in update
      File "pygame\sprite.pyo", line 399, in update
      File "cw\sprite\message.pyo", line 623, in update
    ValueError: <SelectionBar DirtySprite(in 1 groups)> is not in list
    
  11. crowstar

    同じバグかどうかはわかりませんがF9キーを連打していると宿に戻った後にも緊急避難コマンドが出て、
    その時の選択に関わらず操作不能になるというバグがあります。(タイミングはシビアですが再現性はあります)
    確認を取ったのはゴブリンの洞窟と交易都市リューンの2シナリオですがおそらくどのシナリオでも発生すると思います。

    Version : 0.12.4 Alpha 4 / 2016-02-11 20:36:05
    DateTime: 2016-02-12 18:16:50
    Traceback (most recent call last):
    File "cw\thread.pyo", line 622, in run
    File "cw\thread.pyo", line 652, in _run
    File "cw\thread.pyo", line 657, in main_loop
    File "cw\eventhandler.pyo", line 120, in run
    EffectBreakError

    Version : 0.12.4 Alpha 4 / 2016-02-11 20:36:05
    DateTime: 2016-02-12 18:17:17
    Traceback (most recent call last):
    File "cw\thread.pyo", line 622, in run
    File "cw\thread.pyo", line 652, in _run
    File "cw\thread.pyo", line 664, in main_loop
    File "cw\thread.pyo", line 868, in update
    File "pygame\sprite.pyo", line 399, in update
    File "cw\sprite\message.pyo", line 623, in update
    ValueError: <SelectionBar DirtySprite(in 1 groups)> is not in list

    Version : 0.12.4 Alpha 4 / 2016-02-11 20:36:05
    DateTime: 2016-02-12 18:20:21
    Traceback (most recent call last):
    File "cw\thread.pyo", line 622, in run
    File "cw\thread.pyo", line 652, in _run
    File "cw\thread.pyo", line 657, in main_loop
    File "cw\eventhandler.pyo", line 113, in run
    File "cw\eventhandler.pyo", line 588, in executing_event
    File "cw\frame.pyo", line 819, in stop
    AttributeError: 'SystemData' object has no attribute 'f9'

    ※枠で囲む書き方がわからずこんな書き方ですみません

  12. k4nagatsuki reporter

    ありがとうございます。pull request #1327で対処しました。連打の方は原因の究明が甘いかもしれません。再度発生したらお知らせください。

    プログラムコードやエラーログは、行頭に空白を4つ入れるか、``で囲えばそのように示す事ができますので、ご利用ください。

  13. Y Sakaguchi

    こんばんは、いつもお疲れ様です。

    先ほど宿屋画面でPCの装備欄から邪魔な傷薬を荷物袋へ移動させようとしたら、いきなり操作不能になりました(ので、閉じるボタンで終了しました)

    エラーログが出てたので添付しておきますね。ではでは。

  14. k4nagatsuki reporter

    ご報告ありがとうございます。ご迷惑をおかけして申し訳ありません。

    エラーログの内容を見たのですが、どうも原因が判然としません。どうやらエラーはカード交換ダイアログを開いた時に選択中のカード(画面上に半透明で表示されるもの)が存在しなかったために発生したようなのですが、そのような状況にはならないはずですし、操作とも合いません(荷物袋相手にカード交換を行う事はできません)。

    考えられるのは、なんらかのバグでカード交換ダイアログのエラーが出たがそのまま動き続け、その後の別の操作(荷物袋への移動)でとうとう操作不能になったというような状況でしょうか。

    とりあえず、pull request #1331でチェック処理を入れて、カード交換ダイアログオープン時に選択中カードが無ければ処理をスキップするようにしました。しかし根本的な解決ではありません。今後、カードの移動や売却を行おうとしている時に、半透明の選択中カードが見当たらなくなるような事があったら、お知らせください。

  15. 暗黒 騎士

    おそらく今日の変更の影響だと思うのですが、CardWirthPy 0.12.4 Alpha 4Build: 2016-02-28 20:46:46にて「デザインを変更」を押してもデザイン変更ダイアログが開かれないようになりました。

    Traceback (most recent call last):
      File "cw\dialog\charainfo.pyo", line 851, in OnLeftUp
      File "cw\dialog\create.pyo", line 1974, in __init__
      File "cw\dialog\create.pyo", line 2086, in __init__
      File "cw\dialog\create.pyo", line 773, in set_imgpathlist
      File "cw\util.pyo", line 971, in sort_by_attr
      File "cw\util.pyo", line 954, in _sorted_by_attr_impl
      File "functools.pyo", line 87, in __lt__
      File "cw\util.pyo", line 944, in logical_cmp
    TypeError: zip argument #2 must support iteration
    
  16. Y Sakaguchi

    こんばんは。先程ほしみさんの【非公認種族登録所】で種族自動診断をしていたところ、「診断結果が出ました」とメッセージが出たっきりフリーズしました。再度やっても同じ結果になったので、ログ添付の上で報告しておきますね。

  17. k4nagatsuki reporter

    ありがとうございます。どちらもpull request #1355で修正しました。

  18. Y Sakaguchi

    修正お疲れ様です。

    無事、フリーズは発生しなくなりました。ありがとうございました。

  19. k4nagatsuki reporter

    ご確認ありがとうございます。

    どちらも割と簡単に発生してしまうバグだったのですがなぜ自分で見つけられなかったのやら。助かりました。

  20. k4nagatsuki reporter

    0.12.4α5をリリース。β版については2月頭から状況が変わっていません。どうにかなりそうになったらお知らせしますので、申し訳ありませんがしばらくお待ちください……。

    別の話ですが、Bitbucketのプラットフォームのアップデートのトラブルで、一部リポジトリのダウンロードファイルが破壊されたとの事です。cwxeditorは影響を受けたとの連絡があり、実際に新しい方のファイルが壊れていました。念のためこのリポジトリも確認しましたが、全て無事のようです。当たり前ですが、怠りなくバックアップを取っておいた方がよさそうです。

  21. hand.onlooker

    アイテムカードの命中判定が行動力の影響を 受けないのではないかという記述を見かけました。 私の検証ではスキルしかしていなかったので、 もしかすると修正が必要かもしれません。

  22. k4nagatsuki reporter

    ありがとうございます。これは対応する必要がありそうですが、ちょっと落ち着いて調査しなくてはいけません。さしあたり、issue #345を立てました(プラットフォームの更新のおかげかissueへの自動リンクが復活してますね)。

  23. 暗黒 騎士

    CAB圧縮されたシナリオが貼り紙に表示されないようです。たとえばメレンダ街はデフォルトで圧縮されていますが、解凍しないとフォルダ以外表示されません。試しに賢者の選択をLZH、ZIP、CABで圧縮してみたところ、LZH、ZIPの方は表示されるのを確認しました。

    自分はこの機能を使っておらず今までPyの仕様かと思ってスルーしていたのですが、Readmeのサポートしているシナリオ圧縮形式にCABがあるのを見つけたので一応報告しておきます。例によって自分の環境だけでしたら仕様ということでいいかと思います。

  24. k4nagatsuki reporter

    CWPyはWindowsXP付属に付属しているはずのMicrosoftのexpand.exeを使ってCABシナリオを展開しています。環境によっては存在しないのでしょうか。

    コマンドプロンプトなどでexpandと打ってみた時、コマンドやバッチファイルとして認識されていないというようなメッセージが出た場合は、存在しないか、実行パスが通っていません。しかしそのプログラムが無いと色々問題が出そうなので、無いわけがないという気もするのですが……。

  25. k4nagatsuki reporter

    コマンド文字列の文字コードなどの問題でしょうか?

    コンソールからcwpyを実行した時、CABファイルのある場所を走査した時に何か出力があるかと思うのですが、それはいかがでしょうか。

  26. 暗黒 騎士

    そういえば…! cardwirth.pyから起動した時はずっとこのスイッチ-Iとtahomaの謎の警告が出ていますね。

    warning: Tahoma has no vrt2/vert feature.
    warning: Times New Roman has no vrt2/vert feature.
    Microsoft (R) File Expansion Utility  Version 5.1.2600.0
    Copyright (C) Microsoft Corp 1990-1999.  All rights reserved.
    
    スイッチ -I は認識されません。
    
  27. 暗黒 騎士

    ありがとうございます。しかし警告の内容が変わっただけで表示されないようです。

    Microsoft (R) File Expansion Utility  Version 5.1.2600.0
    Copyright (C) Microsoft Corp 1990-1999.  All rights reserved.
    
    scenario/ask/賢者の選択.cab: 'Summary.wsm' に適合するファイルはありません。
    
  28. k4nagatsuki reporter

    試していただきたいのですが、例えばコマンドラインで以下のようにした時に展開は行えるでしょうか。

    expand "賢者の選択.cab" -f:Summary.wsm "."

    上記のコマンドが失敗する場合、CABファイル内でのSummary.wsmのパスが賢者の選択\Summary.wsmの場合は、以下のようにすると上手くいくかもしれません。

    expand "賢者の選択.cab" -f:"賢者の選択\Summary.wsm" "."

    それがうまくいくようなら、そうするように変更してみます。

  29. 暗黒 騎士

    あ、フォルダごとでは駄目だったのですね。後者で展開できました。

    D:\CardWirthPy\Scenario\Ask>expand "賢者の選択.cab" -f:Summary.wsm ".
    "
    Microsoft (R) File Expansion Utility  Version 5.1.2600.0
    Copyright (C) Microsoft Corp 1990-1999.  All rights reserved.
    
    賢者の選択.cab: 'Summary.wsm' に適合するファイルはありません。
    
    
    D:\CardWirthPy\Scenario\Ask>expand "賢者の選択.cab" -f:"賢者の選択\Su
    mmary.wsm" "."
    Microsoft (R) File Expansion Utility  Version 5.1.2600.0
    Copyright (C) Microsoft Corp 1990-1999.  All rights reserved.
    
    賢者の選択.cab  .\Summary.wsm に展開しています。
    
  30. k4nagatsuki reporter

    上手く行かないので調べてみたのですが、どうもexpandのバージョン6だとXP付属の5の反対に前者が成功して後者は失敗するようです。なんでそんなことをするんだろう? 本当に意味がわからない。どうも*.wsmならどちらでも上手くいくようなので(なんでだ?)、それを使うように変更してみます。

  31. k4nagatsuki reporter

    バージョン5と6の仕様の違いで詰んだかと思いましたが、たぶん対応できたと思います。お試しください。

    https://bitbucket.org/k4nagatsuki/cardwirthpy-reboot-k4nagatsuki/downloads/CardWirthPy_test_20160306b.zip

    ただしCAB圧縮したWSN形式のシナリオには対応できませんでした(概略がSummary.xml単体で完結しないため)。すごく頑張れば何とかできるかもしれませんが、これはもう勘弁して下さい……。

  32. 暗黒 騎士

    お疲れ様です。メレンダ街もばっちり回れるようになってます! 1.28だと重かったりキャッシュが残ったりしてすこぶる不安定でCABは倦厭してたんですが、意外に早くて良い感じですね。

    *.wsmなら

    ワイルドカードならディレクトリごと精査してくれるみたいな感じですかね?融通きかない仕様変更癖いい加減にしてほしいですねマイ○ロソフト…。

  33. k4nagatsuki reporter

    ご確認ありがとうございます。pull request #1368でマージしました。

    どうもバージョンによって-fオプションの挙動が全然違うようです。5だと-f:*で全てのファイルを展開するとディレクトリ構造が消滅してしまいます(-f:dir\*のようにするとサブディレクトリdirのファイル内のみ展開できる)。ともあれどうにかなってよかったです。

  34. k4nagatsuki reporter

    先程0.12.4α6をリリースしました(本当)。βリリースが遅れている件についても、近いうちに報告したり進展させたりできるようになると思います(本当だといいな)。

    いい加減#299のスキンごとに色とフォントの設定を上書きできるようにする件をやらないと……。

  35. k4nagatsuki reporter

    あちこち触れ回るようで気が引けるのですが連絡として。

    issue #294で、昨年から続いていた「評価条件」機能についてのやり取りを全文公開しました。これまでβリリースが行えなかったのは、このやり取りが原因です。議論が続いている間はこの機能を載せたままβリリースはできず、さりとて一時的に外すにせよその根拠として議論の存在を公開せねばならず、公開のはっきりとした了解は得られず、という状態が続いていました。

    しかし今回の公開で動きが取れるようになりましたので、近いうちにリリースへ向けてのIssueを立てる事にします。今回はWsn.1が入るという比較的大きな変更があるので、やるべき事はいつもより多くなるはずです。あらかじめ網羅・整理しておきたいです。

    というかそれらについて予め書いておいたテキストがあったはずなんだけどいつの間にかファイルごと消えてる……恐。

  36. Ufuku

    issueを作成するほどかわからないのでこちらで失礼します。 今まで攻略Wikiにある、種族追加スキン(中世ファンタジー)を使っていたのですが、 0.12.4 Alpha 6で新規宿を作り、そのスキンに指定したところ、そのままフリーズしてしまいます。 標準Classicスキンだと普段どおり拠点画面、新規キャラも作成できました。 ちなみに以前のAlpha 5からそのスキンを使っている宿ではフリーズが起きていません。 その際のエラーです。お手数おかけします。 Version : 0.12.4 Alpha 6 / 2016-04-01 18:27:11 DateTime: 2016-04-03 05:22:33 Traceback (most recent call last): File "cw\thread.pyo", line 687, in run File "cw\thread.pyo", line 717, in _run File "cw\thread.pyo", line 726, in main_loop File "cw\eventhandler.pyo", line 113, in run File "cw\eventhandler.pyo", line 618, in executing_event File "cw\thread.pyo", line 1690, in set_yado File "cw\thread.pyo", line 2696, in change_area File "cw\data.pyo", line 295, in change_data AttributeError: 'NoneType' object has no attribute 'getfind'

  37. k4nagatsuki reporter

    ご迷惑をおかけして申し訳ありません。

    これはスキンのデータバージョンと実際に存在するデータが矛盾しているための問題のようです。Skin.xmlだけ上書きしたために矛盾してしまったのでしょう。

    α6では、CWNext1.60のように新規宿では宿帳と終了の2つのカードのみが出るようになっているのですが(issue #324)、そのために宿のエリアが1件追加になっています。この追加はスキンのデータバージョン「9」で行われ、「8」以下のスキンは自動的にアップデートされるようになっています。攻略WikiのSkin.xmlのデータバージョンは「9」になっているので、それを実際に「8」以下のスキンに上書きしてしまうと、行われるべきアップデートが行われず、エリアが欠けた状態になります。結果、エラーが発生します。

    これを解消するには、いくつか方法が考えられます。

    • 欠けているエリアを手動で追加する。<CWPy>/Data/SkinBase/Resource/Xml/Yado/03_YadoInitial.xmlを、<スキンのフォルダ>/Resource/Xml/Yado/03_YadoInitial.xmlにコピーしてください。
    • エラーの出るスキンのSkin.xmlをテキストエディタなどで編集し、<Skin dataVersion="9">(dataVersion="10"になっているかもしれませんが、やる事は同じ)を、<Skin dataVersion="8">に書き換えてCWPyを再起動する。これでスキンのアップデート処理が行われます。バージョン8~10のアップデートの内容上、おそらくデータに矛盾が発生するような事は無いと思います。
    • 新規スキンや最新のClassicスキンに種族追加を導入し直す。

    このいずれかを行えば問題は解決すると思います。


    それはそれとして、もっと根本的な問題があるのでどうにかしなくてはなりません。

    1. Skin.xmlを単独で配布して上書きして使うと、今回のようなデータバージョンと実データの矛盾が発生してしまいます。これをどうするか。
    2. 実際に必要なエリアが欠けている時に開発者にしか分からないエラーを吐くのではなく、プレイヤーに分かるようなエラーを出すか、自動修復を試みるべきでは?

    1.については、Skin.xmlにデータバージョン情報が含まれている以上、Skin.xmlだけではなく他のリソース(SkinBaseに含まれるもの)もまとめて配布して矛盾が起きないようにするか、Skin.xmlの仕様を変更して種族・特徴・メッセージなどを別ファイルで定義するか、などといった処置が必要そうです。2.は、迂闊に自動修復をすると、スキンが実際にどういう状態になっているか特定する方法が無い以上余計なトラブルも起こしそうです。

    どうしたものでしょうか。@GanmaShadowさんの意見もお聞きしたいです。

  38. k4nagatsuki reporter

    pull request #1399

    さしあたり、自動アップデートで追加されるべきデータが欠けている場合は、そのようにエラーダイアログを表示するようにしました。

    ついでですが、Windowsの標準メッセージダイアログは、Ctrl+Cで内容をコピーする事ができます(アプリケーション独自で出していたりして、できないダイアログもかなりありますが)。いつかCWPyのダイアログでもできるようにしようと思って忘れていたのですが、それも思い出したのでpull request #1400で追加しておきました。

  39. Y Sakaguchi

    あららら、余計な手間を取らせてしまったようで申し訳ありません;

    そして異種族スキンを御利用いただきありがとうございます(正直、サンプルは自分しか使ってないだろうと思ってました;)

    こちら側で出来そうなのは対処1の前者ですね(後者は、プログラム音痴の私からは手間も難易度も想像つかないので何とも…)

    • メリット:他のxmlファイルも書き換えた状態で配布出来る事(手元にある現代伝奇スキンは探偵云々の用語を全部書き換えてるため、フォルダ構造ごと一緒に配布した方がたぶん親切)
    • デメリット:種族データを修正する度にいちいちUP用の該当ファイルを上書きして圧縮保存し直す必要があり、割と面倒。

    実際にはスキン更新はひとまず終了予定なので、最初にxml関係のフォルダを抽出するだけで大した手間にならないから良いかな、と。

    対処2の場合、個人個人でスキンの状態がまちまちになりかねず、新バージョンのスキンを上書きした場合にトラブル起こすかもしれないなあ…と(素人考えながら)思いました。

    ともかく一番合理的に解決できそうな手段を取らせてもらおうと思います。何が良いでしょうか?

  40. 暗黒 騎士

    やはり新規宿に入った時のみという稀な状況のためにエリアを強制的に増やしてしまうのはメリットが少ないように思えるのですが、03_YadoInitial.xmlをクラシックスキンに同梱するにとどめ、「03_YadoInitial.xmlがあれば認識、スキンに見つからなければ新規には作らず01_Yado.xmlを読む」という条件を設定するのは難しいでしょうか?

  41. k4nagatsuki reporter

    新規宿のあの機能を実現するにはエリアを追加するのが最もましな方法だったので、機能を諦めるかエリアを追加するかという事になります。諦めるよりはエリアを追加して実現したかったので現状のようになっているわけですが、そこに想定外の事故が起きてしまいました。

    エリアが存在しない場合はSkinBaseから読み込む事は技術的には可能ですが、新しい問題が発生してしまいます。スキンの構造は自由度が高く、例えばメニューカードのイメージなどをスキン作者が自由に設定できます。例えば「宿帳」のイメージをClassicなどとは異なるファイル名で指定している場合、SkinBase03_YadoInitial.xmlは、そのままでは正常に表示されない可能性があります。スキンの自動アップデートはその部分を修正する処理も行っていますが、これを毎回読み込むたびに行うと将来のパフォーマンス問題になりますし、将来の設計変更で機能しなくなる虞もあります(この問題を避けるため、スキンのアップデート処理は「5」→「6」→「7」……のように順番に行うようにしています)。

    ちなみにアイコンやメッセージなど比較的単純な部品は、そうした問題が発生しにくいか容易に対処できるので、無かった場合はSkinBaseを参照するようにしています。

    ついでにいうと、将来的にスキンを読み込むソフトはCWPyだけではなくなるかもしれません。周辺ツールが作られるかもしれません。その時、初期宿エリアが存在したりしなかったりする可能性があるというのは、そうしたソフトの設計者の負担を増やしてしまいます(私も既存データを扱うツールの作成で散々痛い目を見させられていたりする)。


    現在のスキンのデータ構造を知っている者としては、少なくともXMLファイルだけは単独で配布はせず、全体をまとめて配布していただけるとありがたいです。

  42. Y Sakaguchi

    とりあえず、Skin.xmlとResourceフォルダの中身をセットにしたものをサンプルとして提出します。

    念のため新規のスキンに上書きしたところ、無事に動作しました。ReadMeの記述などこれで問題ないのであれば、後ほど攻略Wikiのファイルも順次差し替えたく思います。

  43. k4nagatsuki reporter

    ありがとうございます。

    ReadMe.txtですが、他のスキンへの上書きを前提としているので、複写先のReadMe.txtを上書きしてしまわないよう別のファイル名にしたほうがよいかもしれません。

    また、Resource/Xmlフォルダの下のファイルがClassicスキンのものになっているようです。これは文章にgroupAskの著作権がありますので、普通のクリエイティブコモンズでは配布できません。Data/SkinBaseの中身を使用してください。こちらはCWPyのReadMe.txtにある通り、Public Domainです(ってこれもCC0にしといた方がよさそうだな)ので、使用者が自由なライセンスをつける事ができます。

    また、ActionCardの下にある.v6のついたファイルは自動アップデート時のバックアップファイルで、不要です。

    ざっと見た限りで指摘できるのはこれくらいでしょうか。お手数をおかけしますが、修正いただければ幸いです。

  44. k4nagatsuki reporter

    ありがとうございます。これで問題ないと思います。

    あと付け加えるとすると、ReadMeのファイル名はスキン名を反映したものにした方が分かりやすいかもしれないくらいですが、些細な事なのでどちらでもいいかと思います。

  45. Ufuku

    修正作業お疲れ様です。

    無事フリーズしなくなりました。ありがとうございました。

  46. 暗黒 騎士

    WSN形式でステップ値名(Step-0など)に空欄を入れた場合、メッセージコンテントでの$ステップ名$がそのまま表示されてしまうようなのですが、これは仕様になりますか?

    クラシック形式に変換した場合は1.50/Pyともに正常に再生されるようなのですが…

  47. k4nagatsuki reporter

    これは値を返す関数が、ステップが存在しない場合はNoneを返すのですが、XMLのパーサが空のテキストを勝手にNoneにしてしまうためです。以前は結構同様の問題が出ていたのですが今更発生するとは思いませんでした。助かります。pull request #1423で修正。

  48. k4nagatsuki reporter

    すみません、ちょっと私の方の事情で色々とあってしばらく反応がペースダウンすると思います(cwxeditorの方も)。

    バグから順にできるだけ対応していきますのでゆっくりお待ちいただけるとありがたいです。

  49. saki_cw

    遅くなりましたがβ公開お疲れ様です。

    フォークしてソースを修正し、プルリクエストを送る、という作業を練習がてら行ってみました。 間違い等あれば教えてください。

  50. k4nagatsuki reporter

    ありがとうございます。直に修正していただけると私の方ではレビューするだけでよいのでとても助かります。

    URLが古い情報のままで大変失礼しました。こうした修正がβ2に間に合って何よりでした(今までのリリースは全部間違っていた事になるけど……)。

    今後とも何かありましたらよろしくお願いします。

  51. saki_cw

    なるほど。議論が必要ない部分は直に修正した方が良いのですね。 まだPythonはよく分かってませんが、触っていきたいと思います。 こちらこそよろしくお願いします。

  52. k4nagatsuki reporter

    そうですね。今回のような明白な間違いや、歴然としたバグなどは、直接修正していただけると私は楽ができて非常にありがたいです。今後ともお気の向いた時によろしくお願いします。

    末尾の改行の件は、すぐ直せるような事だったのでお気になさらないでください。どうもBitbucket付属のエディタには問題があるみたいです。

  53. Panda Gruel

    シナリオ選択のウィンドウを「×」ボタンで閉じると、宿画面で「貼り紙を見る」メニューが選択状態になったまま止まってしまうようです。

    使用しているOSはwindows10pro 64bitです。

  54. k4nagatsuki reporter

    ご報告ありがとうございます。#383の関係で手入れした結果バグが入ったようです。

    pull request #1488で修正できたと思うので、最新のテスト版をお試しください。

  55. Panda Gruel

    修正確認しました。

    ついでであれこれ弄ってみたのですが、シナリオの一覧表示→貼り紙表示へ変更する時に些末ながらバグがあるようです。

    • シナリオの表示を一覧表示にする
    • シナリオフォルダやwsnファイルが入っているフォルダ(仮にフォルダAとする)を選択状態にする
    • 一覧表示を貼り紙表示に切り替える
    • 通常、フォルダA内にあるシナリオのタイトルが表示されるはずだが、この操作を行った場合はフォルダAの名前しか表示されない

    一時的に表示されないだけで、貼り紙のページをめくったりすれば正常な表示になります。 また、表示されてない状態でもフォルダAの中を「見る」と普通にシナリオが表示されますので、特に困る事はないです。

  56. k4nagatsuki reporter

    ありがとうございます。pull request #1489で修正しました。

    このバグいつからあったんだろう? 最初からだったりして。

  57. Y Sakaguchi

    こんばんは。今日は特にバグが出たわけではないのですが、Pyを終了する時に続けてエラーログが出たため報告します。

    C:\(省略)\Documents\CardWirthPy\CardWirthPy.exe\cw\sprite\card.py:928: FutureWarning: The behavior of this method will change in future versions. Use specific 'len(elem)' or 'elem is not None' test instead.

    何か、処理方法が変わるから最新テスト版を使ってください……みたいなことを言われてるっぽい?

  58. k4nagatsuki reporter

    ありがとうございます。これは私もすぐ引っかかって修正しました。

    最新のテスト版では出ないと思うのでお試しください。

  59. salt

    こんばんは、

    メッセージログをマウスホイールで遡る途中にフリーズが発生しましたのでお知らせします。

    (一部シナリオでしか起こらなかったのでシナリオ構成の問題かもしれません)

    Version : 1.0 Beta 2 / 2016-06-19 14:06:37
    DateTime: 2016-06-20 00:54:34
    Traceback (most recent call last):
      File "cw\thread.pyo", line 683, in run
      File "cw\thread.pyo", line 713, in _run
      File "cw\thread.pyo", line 718, in main_loop
      File "cw\eventhandler.pyo", line 113, in run
      File "cw\eventhandler.pyo", line 618, in executing_event
      File "cw\thread.pyo", line 2740, in change_area
      File "cw\data.pyo", line 461, in start_event
      File "cw\event.pyo", line 547, in start
      File "cw\event.pyo", line 714, in start
      File "cw\event.pyo", line 766, in run
      File "cw\event.pyo", line 874, in action
      File "cw\content.pyo", line 3300, in action
      File "cw\thread.pyo", line 1461, in show_message
      File "cw\eventhandler.pyo", line 727, in run
      File "cw\eventhandler.pyo", line 775, in lclick_event
      File "cw\sprite\statusbar.pyo", line 1249, in lclick_event
      File "cw\eventhandler.pyo", line 429, in f5key_event
      File "cw\thread.pyo", line 1524, in show_backlog
      File "cw\thread.pyo", line 840, in input
      File "cw\thread.pyo", line 993, in proc_animation
      File "cw\sprite\scrollbar.pyo", line 75, in update_lazyscroll
      File "cw\eventhandler.pyo", line 1414, in update_sprites
      File "cw\sprite\message.pyo", line 840, in create_message
      File "cw\sprite\message.pyo", line 523, in __init__
      File "cw\sprite\message.pyo", line 344, in create_charimgs
    AttributeError: 'SelectWindow' object has no attribute 'spcharinfo'
    
  60. k4nagatsuki reporter

    ご迷惑をお掛けして申し訳ありません。issue #387での作業にミスがあって、メッセージ無しの選択肢のログ表示がエラーを起こすようになっていました。

    pull request #1496で修正しました。最新のテスト版では直っているはずです。

  61. 山田玉矢

    お疲れ様です.描画処理の仕様の問題かもしれませんが報告致します。 [セル移動]を行った際の描画速度がNEXTに比べて遅く,特に複数セルを同時に移動した場合ちらつきが発生します.背景の置き換えや描画は比べて高速なので,少し疑問に思い報告致しました.

  62. k4nagatsuki reporter

    ご報告ありがとうございます。

    仕様としては、セル移動とその他の背景処理にそこまで差が出るような処理量の違いはありませんし(置換した方が処理量は多いはず)、ちらつきが出るような構造にもなっていないはずです。

    何かバグがあるか、背景切替方式が最速になっていないなどの設定ミスがあるか、JPY1が絡んでいるといったような問題があるのかもしれません。

    申し訳ありませんが、手許では現象を再現できませんでした。具体的にどのような場合に問題が起こるのか教えていただけないでしょうか。

  63. 山田玉矢

    背景切り替え方式は背景再配置内で[アニメーション無し]を選択しております. 背景処理に関してはあくまで体感的に早いと感じているだけでかもしれませんが, セル移動の速度に関して違和感を覚えたので報告した次第であります. 単に私の環境に原因があるのかもしれません.

    簡単なサンプルシナを作成致しました.5つのセルを10pixずつ49回移動して戻すというシナリオですが 私の環境でPYでは処理完了迄に約17秒,NEXTでは3秒という結果となります. http://fast-uploader.com/file/7022158166639/ [pass:cw]

    PYエンジンは[ver.1 β2 (Reboot)]を使用しております.

  64. 暗黒 騎士

    お疲れ様です。横からですが、サンプルシナリオプレイさせていただきました。 自分の環境でもPyでは17秒前後でちらつきがあるように思えます。(Windows7 64bit メモリ16G)

    NEXTではアニメなし・最速で画面の拡大で大きな差が出るようです。 拡大なしでは3秒、1.5倍では6秒、2.0倍では9秒前後でした。ご報告まで。

  65. Liar_cw NA

    私の方でも検証を行ってみましたが、やはりお二人とほぼ同じ秒数がかかりました。
    試しに A-1番のみを再配置(移動)するようにしたところ、3~4秒で処理が完了しました。
    どうも再配置処理が連続したときに問題があるのかもしれません。

    • PC数1人。画面拡大なしで約16秒。
    • PC数1人。画面1.5倍拡大、2倍描画でも約16秒。
    • PC数1人。画面拡大なし、1番のみ動作させると約3~4秒。

    CWNextについては、検証は行っておりません。

    cardwirthpy_20160620
    CardWirthPy 1.0 Beta 2
    Build: 2016-06-20 06:37:21
    

    それと別件になりますが、検証中に気になった点をいくつか。

    1. エリアいる時に、エディタでそのエリア設定の背景を変更(このテストシナリオの場合、MapOfWirtgをBlackに変更)してもすぐには更新されなかった(再更新、背景更新を行っても変化なし)。F9やエリアを移動(デバッガから同エリアへ移動)をするなどしてファイルを再度読み込む必要があった。

    2. 背景移動(再配置)中にエディタの起動に失敗する。

    0457追記:1.について補足させていただきました。

  66. k4nagatsuki reporter

    皆様ありがとうございます。

    調べてみましたが、@mjkttaroさんの最初のご指摘通り、背景描画に関する仕様上の問題のようです。そして、CWNext側に問題があります。

    CWには元来、フレームレート(1秒間に何回画面を描画するか)の概念が無く、背景セルの描画にかかる速度は環境によって不定でした。たしか1.50辺りで「セルアニメが速くなりすぎるから待機時間を入れる」というような話があったと記憶しているのですが、背景の再配置処理にはその待機時間を入れ忘れたようです。その結果、CWNextはこの処理を能う限り全速力で行います。

    背景変更でわざわざ待機時間を入れた事からも分かるように、この仕様には問題があります。環境やタイミングや描画内容によって「全速力」の速さは異なるため、背景再配置でセルアニメを行うと、環境によって様々な速さで描画される事になります。ある環境では作者の意図より速くなりすぎますし別の環境では遅くなりすぎます。ついでにCPU使用率も高くなりF9も効かなくなります。

    処理時間に余裕が無いため、セルの数を増やしたり、画面サイズを大きくすると、ダイレクトに速度に影響します。@akkwさんの実験で画面を大きくした時に描画時間が変わったのはそのためです。以上により、作者の意図通りの速さでアニメーションを描画する事は、まったく不可能となります。

    CWPyでは、背景の更新は常に30fps(1秒に30回までの描画)で行います。この速度は、1.28時代に作成されたいくつかのセルアニメで実験してみて、「60fpsでは速すぎるし40fpsでも速い、30fpsだとちょうどいいようだ」という感じで決めました。1秒間にCWの画面サイズを30回描画、というのは、今時のPCではかなり余裕があります。そのため、「全速力」と比べるとかなり遅く描画する事になります。CWNextよりCWPyの方が描画速度が遅く見えるのはそのためです。ちらつきのように見えるのは[1]~[5]が上から順に1点ずつ動いているからです。

    (余談ですが私の環境では画面サイズを「2倍」に設定すると30fpsでも処理が遅延する事があります。今回のものとは別の問題ですが、そのうちなんとかしたいなぁ。)

    参考までに30fpsでの検証シナリオの描画速度を計算してみると、5枚のセルを50回(49回と書かれていますが実際には50回のようです)×2回移動する処理があるので、以下の式で最終的にかかる時間が出せます。

    1/30×5×50×2 = 16.66666....

    この速度は17秒程度という検証結果と一致します。描画の遅延は発生していないと考えてよいでしょう。


    以上により、これは、

    1. バグではなく仕様の問題であり、
    2. CWPy側の仕様に問題は無い

    という説明をしましたが、それでめでたしとはもちろんいきません。今は1.60仕様とWSN形式の相互変換を行う事はできませんが、将来行う事を考えると(それが可能だとして)、この仕様の相違は問題になります。どういう風にこの問題を吸収するか、しかも描画速度の不定性の問題を解決した形で、という事を考えておかなければなりません。

    とりあえず「描画で待機時間を入れない」というようなオプションを背景関係のコンテントに入れるとして、その実現方法はどうするべきか。

    • 背景関係以外のコンテントがあったら画面を更新するようにする? しかしイベントツリーの形状によっては上手くいかない。
    • 一定数背景操作が重なったら更新するようにする? これはCWNextの現状に近い感覚で更新処理を行えそうだが、シナリオ作者から見ると仕様の掴みどころが無いし、予想外の動きをする虞がある。

    といった感じで考える必要があります。

    いずれにせよ、Wsn.1はすでにβ段階に入っていますので、対応するとしたらWsn.2か、それより後になるかと思います。

  67. k4nagatsuki reporter

    すいません忘れてました。

    • エリアいる時に、エディタでそのエリア設定の背景を変更(このテストシナリオの場合、MapOfWirtgをBlackに変更)してもすぐには更新されなかった(再更新、背景更新を行っても変化なし)。F9やエリアを移動(デバッガから同エリアへ移動)をするなどしてファイルを再度読み込む必要があった。

    CWでは、背景セルはメニューカードなどと違ってその場その場で完全なデータが保存される事になっています。BGMと同じ扱いです。デバッガで状況を保存・復元した時、背景も復元されるのはそのためです。これはセーブ&ロードで背景の状態をおかしくしないためにも必要な仕様です。

    ですから、最初にエリアを開いた時にMapOfWirth.bmpが表示されたのであれば、新たなエリア移動や背景変更が行われない限り、その表示内容が変更無く続きます。今いるエリアの設定が変更されてもです。これは背景が「そのエリアへ移動した時」に変更されるからです。ですので、その挙動は仕様になります。

  68. Liar_cw NA

    > 背景セルの挙動

    言い方が悪いかもしれませんが、思いついた時に斜め上の行動(β期間なので不具合探し)をしないといけないと思っての報告でしたが、仕様でしたか。失礼しました。

  69. 山田玉矢

    調査いただきありがとうございました.寧ろ計算通り動いている事がわかり安心致しました. セル移動の最高速化は一般的には需要がそれほどないとは思いますので,もし対応していただけるとしても 無理せずにゆっくりと思い出したときにでも実装されることをこっそりと願っております.

  70. k4nagatsuki reporter

    @Liar_cwさん

    いえ、ありがとうございます。神は細部に宿る、ではないですが、バグは普段使わないコードに宿るものです。「いざという時しか使わない緊急復元処理にバグがあって」というような話もよく聞きます(ジェイコム株誤発注事件でも取消処理がバグって被害が拡大したんでしたっけ。洒落にならん)。

    ですので、色々な事を試していただけるのはとても助かります。

    @mjkttaroさん

    ありがとうございます。今後も気になる事があったらぜひご報告ください。よろしくお願いします。

  71. kuina

    最近、使い始めたのですがいつの間にか驚くほど進化していたのですね。 これからはこちらを使わせていただこうと思います。

    さて、私が何か思い違いをしているのではないか不安なのですが、 背景置換で対象セル名称と同じセル名称に置換すると 同じ処理を次にした時に全てのセルが消えてしまいます。

    ついでに、要望なのですが、 ステップ代入でPCの各ステータスを代入できたら 店シナリオの適性診断などで便利だと思うのですがどうでしょうか。

  72. k4nagatsuki reporter

    ありがとうございます。どんどん使い勝手を上げていきたいと思っていますので、要望や提案があればぜひ仰ってください。

    さて、背景置換なのですが、これは

    1. 同一の名称を持つセルを全て削除して
    2. 削除された最初のセルと同じ位置に新しいセル群を置く

    という動作をします。これは元になったCWNextの同機能と同じ挙動です。

    したがって、例えば

    1. 「A」という名前の1枚のセルを
    2. 「A」という名前の3枚のセルに置換すると
    3. 次の「A」を置換した時に3枚とも消えてしまう

    事になります。

    しかし3.の時点で2.とまったく同じことをしたのであれば、「A」という名前の3枚のセルが再び配置される、従って画面の様子は変わらない、という事になるはずです。消えてしまうというのは奇妙で、バグかもしれません。

    手許で試した限りでは再現できなかったのですが、どのような操作をしたのか教えていただけないでしょうか。

    ついでに、要望なのですが、 ステップ代入でPCの各ステータスを代入できたら 店シナリオの適性診断などで便利だと思うのですがどうでしょうか。

    ありがとうございます。#277に機能案の一覧があるのですが、そちらに追加しました。

    個人的には、数値隠蔽のCWでは、具体的な能力値を取れるよりは「その能力値での適性が白丸~黒丸のどれになるか?」というような分岐コンテントがあったのではないかと思っています(それも一覧に入れています)。店シナリオではそちらの方が便利かもしれません。

    また、ステップではなくて文字列や数値を扱える本当の変数がほしいところですが、それはたぶん簡単ではないでしょう。

  73. k4nagatsuki reporter

    すいません、手許でセル交換の問題が再現できました。たぶん1枚だけ交換すると問題が発生するのですね。

    これから詳細に調べてみますが、たぶんバグなので、修正する事になると思います。

  74. salt

    仕様だと思うのですがちょっと引っかかったので一応ご報告しておきます。

    デバッグモードではじめからレベルを上げたPCを作成して、 デバッガやステータス表示画面からクーポン編集すると初期レベルの1~2に変更されます。

    キャラクター情報編集の方にあるステータス再設定関連が効いてるのだと思いますが クーポン編集画面だけ見てると何が起きたのか分かりにくい感じがしました。

    それからPC右クリックからだと該当PCのみ再設定されるのに対して デバッガからだと一人だけクーポン編集してもパーティ全員再設定されるようです。

  75. k4nagatsuki reporter

    ありがとうございます。たしかにレベルに関するその挙動はあまりよくないですね。デバッガから作成して初期レベルと所持クーポンが一致しない場合は_<名前>クーポンを付けて点数を調節した方がいいでしょう。

    しかし_<名前>クーポンに関しては過去に何か問題があったような気がします。ちょっと調べる必要がありそうです。

    それからPC右クリックからだと該当PCのみ再設定されるのに対して デバッガからだと一人だけクーポン編集してもパーティ全員再設定されるようです。

    手許では、

    1. デバッガから称号編集を開く
    2. 編集対象欄で誰か一人を選択する
    3. 称号を変更する

    という操作をしても、指定した一人以外は編集されないようです。しかしレベルの調節は全員に入ってしまいます。仰っているのはこの事でしょうか。ただ、このレベルの問題についてはキャラクター情報ダイアログあら称号を編集した時と同じ挙動をするようです。

    いずれにせよ、誰か一人を編集した場合はその一人のレベルだけが調節されるべきですね。修正します。

  76. crowstar

    たしか_<名前>クーポンですと、同名の連れ込みNPCが影響するイベントがある場合、
    イベントの処理で誤動作が発生する可能性があったとかだったような気がします。
    簡易作成キャラ専用の隠蔽クーポンを用意して、そこに点数をつけるのはどうでしょうか。

  77. k4nagatsuki reporter
    • pull request #1498
    • pull request #1500
    • pull request #1501

    とりあえず_得点調節にしてみました。あまり深く考えたわけではないので問題があるかもしれません。問題を思いついたらご指摘ください。

  78. salt

    お疲れ様です、変更確認しました。問題?があるとすればこの辺りでしょうか。

    1. コンバートデバグ宿の引き継ぎPCなどがクーポン調節でレベル変動する
    2. 1.50系デバグ宿との仕様違い(レベル変更の操作以外ではレベル変わらなかったような)

    >PC右クリックからだと該当PCのみ~というのは仰る通りレベル調節のつもりでした。

  79. crowstar

    更新お疲れ様でした。簡易作成のバグの方も含めて変更されているのを確認しました。

    1.コンバートデバグ宿の引き継ぎPCなどがクーポン調節でレベル変動する
    2.1.50系デバグ宿との仕様違い(レベル変更の操作以外ではレベル変わらなかったような)

    1.20~1.50までのデバグ宿とは仕様が異なりますのでそこら辺はどうするべきか・・・
    自分ならPyの仕様に合うように、Pyにコンバートした際に「_得点調節」で得点を調節して
    逆コンバートの際には「_得点調節」を消去する、とかでしょうか。

    それと、これは余談ですが皆さんどうやってデータをダウンロードしています?
    自分はダウンロードの項目でダウンロードしているのですが、1回で8~10分くらい時間がかかるので、頻繁な更新の時には時間がかかるという・・・

  80. k4nagatsuki reporter

    いっそデバッグ中は称号の操作でレベルが変わらないようにするか、称号編集ダイアログに「得点に合わせてレベルを調節する」というようなオプションをつけた方がいいかもしれません。それなら_得点調節もいらないでしょう。どうでしょうか。

    自分はダウンロードの項目でダウンロードしているのですが、1回で8~10分くらい時間がかかるので、頻繁な更新の時には時間がかかるという・・・

    あまり頻繁になるようなら、いっそPythonと関連ライブラリをインストールして開発環境を整え、ソースコードから実行した方がいいかもしれません。ビルドされたバイナリよりは、ソースコードの差分の方が遥かに軽いです。

    もちろんそうした事に慣れていない場合は少し難しいと思うのですが、それは質問していただければサポートできます。

  81. salt

    デバッグモードと通常モードが共用なので、簡易作成PCが通常のシナリオプレイでレベルアップする場合もありそうです。

    _得点調節を持たない簡易作成高レベルPCだと経験クーポンのみでレベル算出されてレベルが動かない(低下はしないが成長も遅い)状態になるので、デバッグモードとの切り替え時点か「レベルに合わせて得点を調節する」オプションで_得点調節を配布する、などはどうでしょうか。

    コンバートで思い出したのでこちらもご報告を。 1.50→Pyの宿変換でコンバートできない(画像が壊れている?)スキルカードを所持するPCが消失します。

    カードをPCが所持しているとパーティ加入・宿帳待機どちらもPC消失。 荷物袋の場合は変換不能カード消失、カード置き場ではカード残りました。

  82. k4nagatsuki reporter

    デバッグモードとの切替時点で何かするのは、あまり筋がよくないように思います。Ctrl+Dを2回押しただけで、他に何もしなくてもPCのデータが変わってしまう事になるからです。

    得点に合わせたレベル調節は、称号編集ダイアログだけで発生するものだったと思います(ですよね? 何か忘れていないか?)。ですから、そこだけピンポイントに対応した方がよいでしょう。

    そして称号を編集した上でレベルも上げ下げしたいという場合は、どちらかといえば少ないはずですし、うっかりレベルへ反映させるのを忘れていたというような場合でも、もう一度ダイアログを開き直すのは容易ですから、「レベル調節もする」というチェックボックスをチェック無しの状態で置いた方がいいのではないかと考えました。

    そしてこの機能があれば「称号を編集したらレベルが下がってしまった」という問題は発生しなくなりますから、システム側のクーポンを増やしてまで得点調節をする必要も無くなります。


    1.50→Pyの宿変換でコンバートできない(画像が壊れている?)スキルカードを所持するPCが消失します。

    CWのPCデータは所持カードと一体化しているため、容易に分離可能な逆変換と違って、エラーが発生した場合はPC単位で弾くようにしていたと思います。

    そして、一部が壊れたデータは、CWでは読み込めるとしても、確実に正常化できるとは限りません。というより、壊れ方は予想がつかないので、HTMLのエラー訂正と同じで、あるソフトでは偶然正常に動いても別のソフトでは上手く行かない、という事がありえます。無理に変換したら後々トラブルの元になるかもしれませんので、原因が確実で問題なく訂正できると分かっているエラー以外は変換不能となります。申し訳ありませんがご了承いただければ幸いです。

    しかし、カード置場の場合はカードが残るというのも不可解です。変換エラーは出ていないのでしょうか? だとしたらまったく別の問題があるかもしれません。

  83. salt

    あ、もう一度デバッグモードでレベル変えれば良いのですね。 「レベル調節もする」チェックボックスがあれば確かに迷わなくなりそうです。

    確認したところカード置場のほうもエラーメッセージが出て該当カードは弾かれました。 確認用にデータを変更させていたので同名のカードが残っていたみたいです、お騒がせしました。

  84. crowstar

    CWのPCデータは所持カードと一体化しているため、容易に分離可能な逆変換と違って、エラーが発生した場合はPC単位で弾くようにしていたと思います。

    そういうことでしたら、コンバート時のメッセージに注意書きを書いておくのはどうでしょうか。
    たとえば、「※キャラクター保護のため予めキャラクターからカードを全部外しておくことをお勧めします」といった感じです。

  85. k4nagatsuki reporter

    pull request #1502

    それぞれ対応しました。

    • 称号編集ダイアログでレベル調節をオプション化しました。
    • コンバートでエラーが発生するというのは普通の状況ではないので、実際にエラーが発生してから「所持カード破損の可能性・外すと成功する可能性」を通知するようにしました。

    β期間中に変更しすぎでは?と自分でも思ったのですが、これらはバグではないものの問題のある挙動だったという事で、お許しを。

    いずれにせよ今月は内部変更の大きな修正が入っているので、来月頭の正式リリースはできないと思います。

  86. Iraka.T

    終了済みシナリオを表示しない設定で、シナリオを張り紙にドロップして開始し、クリアした後に「張り紙を見る」とログを吐いて停止します。応答なしではないのですが、ウィンドウを閉じるしかない状態に。

    #!
    
    Traceback (most recent call last):
      File "cw\frame.pyo", line 1212, in FilterEvent
      File "wx\_core.pyo", line 4987, in GetEventType
    wx._core.PyAssertionError: C++ assertion "item.IsOk()" failed at ..\..\src\msw\treectrl.cpp(1287) in wxTreeCtrl::IsSelected(): invalid tree item
    Traceback (most recent call last):
      File "cw\frame.pyo", line 604, in OnSCENARIOSELECT
      File "cw\dialog\scenarioselect.pyo", line 272, in __init__
      File "cw\dialog\scenarioselect.pyo", line 988, in set_selected
      File "cw\dialog\scenarioselect.pyo", line 1308, in draw
      File "cw\dialog\scenarioselect.pyo", line 1479, in _draw_impl
      File "cw\dialog\scenarioselect.pyo", line 2060, in select_treeitem
      File "wx\_controls.pyo", line 5392, in GetItemParent
    wx._core.PyAssertionError: C++ assertion "item.IsOk()" failed at ..\..\src\msw\treectrl.cpp(1333) in wxTreeCtrl::GetItemParent(): invalid tree item
    Traceback (most recent call last):
      File "cw\dialog\scenarioselect.pyo", line 1298, in OnDestroy
    AttributeError: 'ScenarioSelect' object has no attribute 'bookmarkmenu'
    
  87. k4nagatsuki reporter

    ご報告ありがとうございます。これは一覧表示の時のみ発生する問題ですね。一覧の中に存在しない(表示できないので)シナリオを無理に選択しようとした結果エラーが発生しています。

    pull request #1505で修正しました。最新のテスト版をお試しください。

  88. Iraka.T

    お疲れ様です。修正確認しました。なるほど、私は張り紙と一覧を同時に表示していたために問題が発生したのですね。

  89. k4nagatsuki reporter

    ご確認ありがとうございます。

    そういえば同時表示でも問題が出ますね。ちょっとChangeLogの記述が甘い事になるので折を見て直しておきます。

  90. Iraka.T

    wsn.1形式で作成した、前提クーポンを必要とするシナリオが、条件を満たしてもクーポン不足で開始できません。

    同じシナリオをクラシック形式で保存した場合には開始できるので、私の設定ミスというわけではないと思われます。

    エンジンとエディタのどちらに問題があるのか判断できないので、こちらにて報告します。

  91. tachi gigas

    恐れ入ります。

    クラシック形式とWsn形式で前提クーポンの格納形式が異なるため発生するようです。現行のCardWirthPyではクラシック形式のみ正常に判断します。現象を下に書きますが、この場合はエンジンとエディタどちらで修正するのがいいのでしょう?申し訳ありませんが、k4nagatsuki様の判断を仰ぎたいと思います。

    以下、技術的な話です。

    クラシック形式では前提クーポンはCRLFで区切られていますが、Wsn形式では文字列の「\n」で区切られています。そのため、cw\dialog\scenarioselect.pyの1735行目

    for coupon in header.coupons.splitlines():
    

    for coupon in header.coupons.split("\\n"):
    

    にすればWsn形式では正常に動きます。その代わりクラシック形式では反応できなくなります。

  92. Iraka.T

    クーポン文字列には「\n」を含めることが可能であるはずなので、それを区切りとして使用している状態は好ましくないのではないでしょうか。

    修正するべきはエディタのような気がします。

  93. k4nagatsuki reporter

    ご指摘ありがとうございます。これはCWPyが元々持っていたXML内の文字列の取り扱いの仕様によるものです。CWPyは当初から、改行の入る文字列をエンコードして\n\\nに置換するという原則でデータを取り扱っていました。

    もちろん内部的にはエンコードされた文字列をデコードする処理を持っていますが、そのデコードが正しく行われていないのでしょう。cw.util.decodewrap(header.coupons).splitlines()とする必要があります。

    さらに、クラシック形式のシナリオを変換するときに、前提クーポンを「エンコード済み文字列」としなくてはなりません。前提クーポンの変換処理はcw.binary.summaryの辺りにあります。ちょっと今日は作業は無理なので明日以降なんとかします。

  94. k4nagatsuki reporter

    pull request #1506

    修正しました。Pull Requestの内容を見ると分かる通り、上に書いた問題の原因は部分的にしか正しくありません。シナリオ情報をシナリオDBに登録するとき、必要クーポンはデコードされている必要があるのですが、WSN形式に対しては誤ってエンコード済みのデータを入れていた事が問題でした。

    最新のテスト版をお試しください。なお、シナリオが更新されないとシナリオDBの登録データも更新されないため、問題のシナリオを上書き保存するか、シナリオDBの再構築を行わないと問題が継続してしまうかもしれません。

  95. tachi gigas

    対応ありがとうございました。不具合は見当たりません。

    自分だったら、wsnかクラシック形式かで判定してそれ毎に分岐させるところでした。見識の甘さが恥ずかしい。

  96. Iraka.T

    対応ありがとうございます。問題なくシナリオを開始できました。

    「必要クーポンが複数指定されていると」ということですが、私の確認したかぎり、一つでも指定すると開始できませんでした。おそらく、複数行文字列に対しては、各行末尾に自動的に改行コードが追加されてしまう仕様になっているのではないでしょうか。

  97. Iraka.T

    問題なく、と言ったばかりですが、問題を見つけました。これはシナリオの形式を問わずです。

    必要クーポンが複数指定されていて、必要数が2以上のシナリオが、1種類を複数人が持っているだけで開始できてしまいます。たとえば必要数2で「_♂」「_♀」が指定されたシナリオは、男女両方を含むパーティでなければ開始できないはずですが、現在のCWPyでは同性のみ2人以上のパーティで開始できます。

  98. tachi gigas

    恐れ入ります。

    今見たら「シナリオ出現条件を満たすには対象のクーポンを全部所持していなければいけない」が条件から抜けていますね。昨日の時点で気付けよと思いました。

    pull request #1507 で修正を申請します。よろしくお願いします。

  99. tachi gigas

    と思って何となく調べてみたら何か違いますね。1.50での検証になります。多分連投になります。ごめんなさい。

    • 必要クーポンがAとBで、必要数が2の時、AとB両方持っている必要があります。
    • 必要クーポンがAとBで、必要数が1の時、どちらか一方持っていればいいです。
    • 必要クーポンがAとBで、必要数が3の時、AとBを複数人持っていても表示されません。

    この事より、必要数はクーポン1個につき1つ加算されるべきで、クーポンを持っている人数を加算して比較している現行Pyの仕様が問題みたいです。

  100. tachi gigas

    pull request #1507 を書き直しました。お手数をおかけしますが、よろしくお願いします。

  101. k4nagatsuki reporter

    ありがとうございます。思いもよらぬところに仕様差があるものです。

    今マージしたところなのですが、今までの慣例では、この手の仕様差の修正は変更のところに「CWと仕様を合わせた」という感じで書く事になっているので、私の方でそのように変更させていただきます。

  102. Iraka.T

    お二方とも対応ありがとうございます。意図した条件でシナリオが開始できるようになりました。

  103. tachi gigas

    ChangeLogの記載場所が異なっていたとは、失礼しました。全く、締まらないですね。

    正直シナリオ開始条件にまさかのOR条件があるとは思っていませんでした。続編シナリオに利用されるシステムなので活用は難しいでしょうが…。このゲームは深いです。

  104. Iraka.T

    また1.50とのレアな仕様差を見つけたので報告します。

    #!
    
    $Cast = 1
    
    getcast $Cast
    selrandom npc, 0, 0, none
    sif true
    getcoupon M, ":Temp", 0
    effect M, [paralyze, value, 10, all], none, 0, 5, none, unfail, "", 100, 1
    losecast $Cast
    getcast $Cast
    selrandom npc, 0, 0, none
    sif true
    brcoupon M, ":Temp"
    if true
        msg none, "1.50"
    elif false
        msg none, "Py"
    fi
    

    コンテントによって同行NPCにクーポンや状態の変化を生じさせ、その同行NPCを離脱、再加入させます。1.50では離脱前に変化したクーポンや状態が残留しており、Pyでは消滅しています。

  105. k4nagatsuki reporter

    ありがとうございます。

    これはちょっと(かなり?)厄介な問題です。同行キャストの状態についての仕様は1.30~1.50辺りにかけてしきりに変更されており、何がバグで何が仕様かも判断がつきません。例えば1.50であっても、データ構造上、同行NPCの状態を保存する事はできませんから、セーブ&ロードを経ると状態は元に戻ってしまうはずですが、果たしてこれは仕様でしょうか。

    ちょっと今は時間が無くて試せないのですが、以下のような事を確認する必要があります。

    • 他のバージョンのエンジンだとどうなるか?
    • キャストを外し、イベントを一旦終了し、他のイベントで加入した後はどうなるか?
    • セーブ&ロードするとどうなるか?

    さらに、一度外した同行者の状態を保存しようとすると、内部的に結構面倒な仕様を追加しなくてはなりません。そうした事をするには、今は時期がかなり悪いです。

    これまで、こうした厄介な部分に対しては、「そのせいで動かないシナリオがあるなら対処する」という方針で対応してきました。例えば互換モードで1.28相当の同行者状態復元の挙動を再現しているのは、1.50以降で状態が復元しなくなったためにギミックが動かなくなったシナリオが現にあったからです。今回の問題はどうでしょうか。

  106. crowstar

    クーポンだけですが同行NPCのクーポンがどうなるのか試してみました。

    ver1.20・ver1.28・ver1.29 そもそもクーポンがつかない
    ver1.30 中断してもゲームを終了しない限り残る・離脱~再加入までにキャンプ画面に入れば消える
    (逆を言えば離脱~再加入までにキャンプ画面に入らないと消えない)
    ver1.50・NEXT 中断したら消える・離脱しても残る(離脱~再加入までにキャンプ画面に入っても残る)

    また、どのverでも同行NPCを連れ込んだ際にはクーポンはリセットされることを確認しました。

  107. Iraka.T

    現状、この仕様差のために動かないシナリオの存在は関知していません。私がこの仕様差を見つけたのは、私がNPCに一時クーポンを与えて台詞分けをしてみようと試み、念の為に仕様差の有無を確かめたためです。

    他エンジンでもユーザーの操作によって消えるのであれば、条件によらず消えてしまうPyの仕様が美しいように感じますし、対応の必要性は感じません。検証不足でお騒がせするだけの報告をしてしまってすみません。

  108. k4nagatsuki reporter

    Issue #391を作成し、コメントを丸々引用させていただきました。ご容赦ください。

    いつ何時これによって動かないシナリオが出ないとも限りませんし、問題提起していただけたのはありがたい事です。ありがとうございます。

    しかし同行者周りの仕様(とバグ)は私の想像以上に混乱していますね。下手をすると一旦宿から出て別の宿でシナリオをスタートしたらNPCの状態が残っているなんてパターンもあり得るかもしれません。

  109. 暗黒 騎士
    Traceback (most recent call last):
      File "cw\binary\cwyado.pyo", line 611, in write_card
      File "cw\binary\beast.pyo", line 298, in unconv
      File "cw\binary\effectmotion.pyo", line 109, in unconv
    TypeError: int() argument must be a string or a number, not 'NoneType'
    
    Traceback (most recent call last):
      File "cw\binary\cwyado.pyo", line 630, in convert
      File "cw\binary\cwyado.pyo", line 618, in write_card
    TypeError: int() argument must be a string or a number, not 'NoneType'
    

    攻略wikiの件、加筆ありがとうございました。 取り急ぎ手元の宿では12.4βの頃作った自作付帯能力で所持しているとパーティ丸ごと変換できない、カード置き場に置くと「カードの変換に失敗しました」となる現象が起こっていますね。 内容は、カードの効果では所有者対象の回復、使用時イベントで埋め込み召喚獣を5個の中から選ぶもので、画像形式は全てPNG、パスは指定になっているはずです。 当時他のカードでも確認していた気がするため、仕様だと今日まで誤認していました。 (@GanmaShadowさんにも仕様だと教えてしまった気がします。申し訳ないことをしました…)

  110. 暗黒 騎士

    すっかり忘れていましたが仕様と言えばもう一つ、@GanmaShadowさんの異種族スキンでは初期クーポンに@レベル上限+15を与えることで、本来の@レベル上限より手前に別の@レベル上限を作られることを利用して、レベル上限15の強種族を作られていらっしゃいます。 当初は上限12の種族も作られていましたが、神仙型では逆に下がってしまうのですべて15にされたそうです。

    @IrakaTさんの吸血鬼バリアントも参考になされたのかと思いますが、これらは正規のテクニックとしてしまって問題ないでしょうか?

  111. k4nagatsuki reporter

    初期称号について。これは問題があります。同じ名称のクーポンが複数あるデータというのは設計上の想定外です。今はたまたま大丈夫でも、将来何が起こるか分かりません。どちらかというとデータを壊す問題に近いので結構致命的です。

    さしあたりpull request #1522で修正しました。この問題と#401の問題はかなりまずい(イベント構造によっては事実上プレイ不能になる。なんで気づかなかったんだろう?)ものなので、早めにバージョン1.1を出した方がよさそうです。

    逆変換の問題については、少しお待ち下さい。どうしてパーティごと変換できないのかが分かりません。

  112. k4nagatsuki reporter

    カード個別のエラーの原因は分かりました(おそらくWSN形式で呪縛解除や精神正常化を入れるとエラーになる)が、それでパーティまるごと変換できなくなるという問題が再現しません。手許ではテストした限りでは正しく荷物袋から取り除かれます。

    パーティ側のデータに別の問題があるのでしょうか?

  113. 暗黒 騎士

    ASK宿に該当付帯能力のXMLだけを移してカナン一行のカナンの右腕に持たせてセーブ後変換しましたがカナン一行は変換できませんでした(上) XMLを移すだけでは画像が空白になるため、付帯能力を持っている宿の別パーティのPCに持たせてセーブ後変換でもそのパーティは変換できませんでした。ので多分カードの効果が原因なのかと思いますが(あと思い当たる節としては指定先が存在しないスタートへのリンクで選択肢のキャンセルを作っているぐらいでしょうか)

    データをお送りした方がいいですかね?(厨2全開なのでかなり恥ずかしいですが…)


    おお、最大値を取るということは上限11~14の種族も気兼ねなく作れるようになったということですね! 種族と特殊型で加算方式にするのがいいのかな(でもスキンの互換性が…)と考えてましたが、確かにこっちの方がスマートです。

  114. k4nagatsuki reporter

    すいません、確認なのですが、荷物袋にある場合は問題ない(問題のカードだけが取り除かれてパーティは残る)のでしょうか?

  115. 暗黒 騎士

    はい。荷物袋にある場合は「カナン一行の(付帯能力)は変換できませんでした」と表示されますが、パーティそのものは残ります。 (あ、所持しているとという書き方が紛らわしかったですね。申し訳ありません)

  116. k4nagatsuki reporter

    そういうことであれば何も疑問はありません。その変換失敗は2つの問題が複合して起きた結果のようです。

    • 機能未サポート以外の内部エラーで変換に失敗した
    • PCの所持カードの変換で機能未サポート以外のエラーを適切に処理できていなかった

    下のテスト版をお試しください。これはあえて内部エラーの問題は残してあります(エラーログも出ます)が、それによってパーティ全体が失敗するという事はなくなっているはずです。

    https://bitbucket.org/k4nagatsuki/cardwirthpy-reboot-k4nagatsuki/downloads/CardWirthPy_test_20160807a.zip

  117. 暗黒 騎士

    修正お疲れ様です。「カナン の所持する 付帯能力 は変換できませんでした」という表示に変わり、パーティが変換されるようになるのを確認しました。

  118. k4nagatsuki reporter

    ご確認ありがとうございます。pull request #1523で修正をマージしました。内部エラーの問題も解消しているはずです。

    ちょっと1.1リリースについてのお知らせを1リリースのIssueとwikiに書いてきます。まだ致命傷だからドラゴンボールがあれば大丈夫。

  119. k4nagatsuki reporter

    ありがとうございます。検証用シナリオがあるとすぐに問題を確認できるのでとても助かります。

    カードの使用中にパーティが隠蔽・表示されると使用中のカードもPCと一緒に下がったり上がったりするのですが、その処理が召喚獣にも適用されてしまっていたのが原因です。pull request #1526で修正しました。

  120. Iraka.T

    修正確認しました。対応ありがとうございます。検証用シナリオもお役に立ったようで何よりです。

  121. Iraka.T

    JPY1リファレンスを眺めていてdirtype=7の存在に気づいたのですが、

    filename=Data\Resource\CARD_NORMAL.bmp
    dirtype=7
    

    これをPyエンジンでは

    filename=Data\Skin\(スキン)\Resource\Image\CardBg\NORMAL.bmp
    dirtype=7
    

    と読み替える実装はできないものでしょうか。

  122. k4nagatsuki reporter

    そうしたほうがいいかと思ったんですが、よく考えるとData/Resouceフォルダ内の画像は存在が保証できません。そうしたファイルをシナリオから使うことは非常に困難であるように思います。また、パスの読み替えは、互換性のためやむをえない事もありますが、将来の事を考えると筋の悪いやり方なのでできるだけ避けたいところです。

    そもそもエンジンの位置からの相対パス指定という方式自体が非常に筋が悪いです。公式リファレンスにその機能が載っていないのはそのためではないでしょうか。

    指定方式の内容を考えると、エンジンのパスではなく使用中のスキンのパスとして取り扱うようにした方がいいような気もします。ちょっと考えさせてください。

  123. Iraka.T

    でしたら、filenameでスキンリソースを指定できるエイリアス名など定義していただけると嬉しいです。スキン内のファイルパスはXMLで変更できてしまうので、シナリオ作者は対応しきれないでしょう。

    Data/Resouceフォルダ内の画像は存在が保証できません。

    はい。ですが、「デフォルトの画像」「Data/Resouce内を参照するJPY1」「前述二種を重ねるJPY1」があれば、画像の欠けにはならないので、実用できるのです。

  124. k4nagatsuki reporter

    カードの台紙などは、デフォルトの画像はCWだと実行ファイル内のリソースとして存在しますが、それをシナリオ側から参照する方法は無いように思います。

    スキン内のファイルパスも同様で、画像が固定された名前で存在する保証というものはありません。アクションカードで攻撃と渾身の一撃と会心の一撃に同じ画像を使っているスキンも作れますし、宿の画面のカードイメージのファイル名がClassicスキンとまるで一致しないスキンも作れます。

    つまりCWでもCWPyでもそれらのイメージを確実に参照する方法はありません(せいぜいシナリオ内にファイルを置く事しかできません)。それを行う場合はまったく新しい仕組みが必要であるように思います。

    ただ、ちょっと今頭が働いていないので、何か勘違いしているかもしれません。

  125. k4nagatsuki reporter

    存在しない場合はシナリオ内に置いたファイルを使用するという事ですね。たしかに実行ファイル内のリソースが差し替えられていない限りは動きそうです。これは実際に使用されているテクニックと考えてよいでしょうか?

    ただ、依然としてこの方法は作者の意図したように表示されるとは限りませんし(しかも環境依存で問題が起きても気づきにくい)、dirtype=7自体の筋の悪さを考えると、このためにパスの読み替えを組み込む事には私は依然消極的です。その読み替えは、将来作られる仕様の制約という、技術的負債になってしまいます。シナリオに置かれたファイルが表示されるところまでは保証されている事を考えると、リスクを負ってまで実装するべきかどうかは迷うところです。

  126. Iraka.T

    この技を使用しているシナリオの存在は確認していません。ですが、私は今後使用するかもしれません。その際には、不本意ですが、ReadMeにPy非推奨と記すことになると思います。(不本意なら技の使用をやめればいいと思われるかもしれませんが、私はやりたいことが可能であるのに実行しないことのほうが我慢なりません)

    この件に関する対応が消極的になられることは理解しました。私は希望をお伝えするというできることをしたまでですので、この希望が通らずとも構いません。感情の問題で、惜しくは思いますが。

  127. k4nagatsuki reporter

    そのテクニックはエンジンによっては上手く動きません(実行ファイル内のリソースが差し替えられている場合)ので、注意書きにはその事も含めておいた方がよいかと思います。これを確実に動かす場合、シナリオ作者はプレイヤーに使用するエンジン(またはスキン)を指定する必要があります。

    正規に用意された仕組みではない事が、確実に動かない理由の一つです。上の方にもちょっと書きましたが、正規の仕組みを用意すれば動作を保証する事は可能です。もちろんそのためには仕様を決めるプロセスを経ねばならないのですが。

  128. Iraka.T

    そうですね、1.50またはNextのバイナリ改造などしていないエンジン、及びカード台紙が1.28と同一のPyスキン推奨、その他非推奨ということになるのだと思います。

    dirtype=7が当時何を思って実装されたのかはわかりませんが、筋が悪くとも、Data/Resourceフォルダの出現で可能性を増している要素であると感じられます。それが、1.50互換を謳うPyでは無に帰すというのが、私には惜しく思えます。(内部の醜さや危険性が重大事であるという理解は、私にはできていないようです)

    もしPyでdirtype=7でのData/Resource内参照に対する仕様を決めるとなったときには、利用したいユーザーの一人として意見を述べます。今相談するべきかどうかの判断も私にはできませんので、機会を待ちます。対応は、これを利用したシナリオが登場してからでも遅くはないと思います。

  129. k4nagatsuki reporter

    まずはっきりさせておきたいのですが、dirtype=7は仕様に存在しません。公式の仕様からいうと、未定義動作です。今動いたとしても、将来も動くという保証はありませんし、他のCWエンジンが開発された時も動かない可能性があります。

    その上で現状の実装を受け容れて仕様として取り込むとしても、仕様上全ての環境で確実に動くことはありません。理由は上の方に書いた通りです。

    そして、対応するためにパスを読み替えようとすると、リスクが発生します。具体的には、読み替え前のパスを実際に使用する事が不可能になります。それをカバーするには新しく余計な仕組みが必要になります(読み替えを行うかどうかのフラグを設けるとか)。そこに仕様の混乱と制約が発生します。これはCWPy自身にとっての厄介事になるのみならず、CWPyの他にCW互換エンジンが開発されるような場合にも(私はその具体的な試みを幾つか知っています)実装上の問題を増やす事になります。その責任を負うのはもちろん仕様を決めた者、つまり私ですが、実際には負う事ができず(混乱の解決方法を提供する事ができず)持て余す可能性があります。それはまず許されない事です。

    そこで、私はそもそもそうした読み替えを行うべきかどうかよく考える必要が生じます。その考えの結果が、「シナリオ内のファイルが表示されるところまでは保証できるし、シナリオ内にファイルが無い場合はまったく保証できないから、そもそも対応しない方がよい」という事になります。私が互換性と言った時、それが1.50エンジンと100%同じように動くという事を意味しない事に注意してください。例えば1.50はCABアーカイブ内のシナリオのJPDC撮影イメージを保存する事ができませんし、宿Aで撮影したイメージを宿Bで表示できたりしますが、それは明らかに妥当な挙動ではないので、CWPyではそうした事はできないようになっています。

    それにつけてもCWの仕様(というか実装)はこの手の問題が多すぎて困りますね。正直頭がおかしくなりそうです。

  130. 暗黒 騎士

    クラシック形式(データバージョン4)は基本的に1.28~1.50が想定されており、Pyのスキンで複数resourceファイルを持つ構造は想定されないのでWSN形式ではパス読み替えはせず、データバージョン4のみ、現在のスキンを参照する処理にすればそこまで負債は残らないと思うのですがどうかなと。(音声のリソースオーバーライド機能と同様にメリットと実装の手間が釣り合わなければ、まずはシナリオの増加を待つとして)

    またIraka.TさんのシナリオがPyを想定したクラシック形式になるなら@CardWirthPy Version.1.0@BloodWirth所持分岐して filename=Data\Skin\BloodWirth\Resource\Image\CardBg\NORMAL.bmp などと決め打ち対応してしまうのもありかなぁと思いました。見当外れなこと言ってたらスイマセン。

  131. k4nagatsuki reporter

    そういえば今まで明言した事はなかったような気がするのですが、私は、同じようにシナリオを作ったのであれば、クラシック形式とWSN形式で挙動の差異が発生しないように努力しています。これは、「クラシックなシナリオをWSN形式に変換したらいきなりバグった」というような問題を避けるためです。これはある意味原則の一つですが、どうしてもやむをえない場合は破っても仕方がないかなぁ、とは考えている程度には軽いものです。が、今回の件でそれを覆していいものかどうかは疑問です。

    Pyのスキンで複数resourceファイルを持つ構造は想定されないので

    これは実はそうでもありません。特殊エリアなどから参照するイメージはスキンのどこにでも置くことができます。Resouce/Image/Cardなどは、まったく違うパスに置いても動きます。これは私が開発を始める前からの仕様で、これによってイメージの配置やファイル名に柔軟性が生じています。これを固定化するような仕様を入れると、スキンの設計が制約をこうむってしまいます。

  132. Iraka.T

    スキンのリソースに関しては、各エリアのXMLが参照しているパスにファイルがあればいいわけなので、たとえば01_Yado.xml02_Yado2.xmlでカード画像を別のものにするなどもできますね。

    逆に、メニューカードや技能カードの台紙を統一するなら、同一画像をコピーせずXMLが一つのファイルを参照するように設定することもできます。ユーザーが画像を差し替えようとした時に混乱が大きくなると予想したため、BloodWirthではこの手法を使っていませんが。

    よって、読み替えを実装するにあたっての問題が単純ではないことは理解しておりますし、k4nagatsukiさんが実装すべきでないとお考えである以上、それを強引に覆そうとは思いません。残るのは、1.50で使える手法がPyで使えないという現象を発見して惜しく思う、私の感情の問題だけです。これはPyの問題ではありません。

  133. 暗黒 騎士

    あ、いえ現実的な話として、クラシック形式データバージョン4で作られる99%強のシナリオでは 1エンジン・1スキンで、Pyのようにスキンで複数resourceフォルダを切り替えることは想定されていないということです。 Pyの仕様を意識するならWSNで作るかと思います。

    dirtype=7でresourceフォルダを参照する技術が定着してシナリオが増えると、結局のところPyでも郷に入れば郷に従えとい うことでそれに合わせざるを得なくなっていくかと思います。後手対応ができるので別に焦る必要は無いですが、 @レベル上限二重生成を念のため予防したように、スキンの仕様を変えるならほとんど出ていない今の方がいいとは思います。

  134. k4nagatsuki reporter

    上の方に書いた通り、このカード画像参照は偶然上手くいっているだけで、正当に用意されたテクニックではないはずなので、私としては使用はお薦めしません。程度の差こそありますがF9ゴシップバグの同類だと思います。将来の保証はありません。

    では正当な方法は何かというと、それはカード台紙を参照する新しい仕組みを仕様として提案し、そのリリースを待って使用する、というような事になるかと思います。それを待たずに使う場合、シナリオ作者が責任を負うべきですが、結局その責任をフォローするのは将来のエンジン開発者の仕事になってしまうはずです。

    個人的には、カード台紙を参照するような場合は、エンジンからの相対パスなどではなくてそれ自体をきちんと指定できるようにするべきだと思います。例えばエディタで「麻痺時のカード台紙」を指定できるようにするというような。

  135. Iraka.T

    それで思い出しましたが、リソース画像を背景画像に参照する、とはまた別の件で、キャストサイズのメニューカードが作れたら嬉しいとは思ったことがありますね。通常メニューカードも、規格外のカード画像がキャスト同様にセンタリングされたらいいのに、とも。これは提案しようかと思って本当に単純に忘れていただけなのですが。

    リソース画像を参照する仕組みをWSNでの新しい仕様として検討していただけるなら、私もそちらへ考えを切り替えることができます。

    私がdirtype=7での発見をWSNの新しい仕様として提案できなかったのは、これが1.50で実現可能だったからで、今できることをまだできない別の手法で実現するという発想ができなかったためだと思いますので。

  136. k4nagatsuki reporter
    • カード台紙などのスキンリソースをイメージファイルのように選択・表示する
    • キャストカードサイズのメニューカード

    上記を#277の一覧に追加しました。ちなみにキャストサイズのメニューカードは実はCWの頃から一部に存在しています。「仲間を外す」の解散カードや、カード移動時に表示される売却やごみ箱などがそうです。ですので技術的には簡単です。そのうち実行すると思いますが、すぐに議論を始めたい場合はIssueを立ててしまって構いません。

    ちなみにカードイメージの配置方法については、以下のアイデアがすでにリストにあります。個人的にはWsn.2までに実現したいです。

    • カード画像の配置方法の指定(中央寄せ・左上合わせ)(#336)
    • カード画像の位置をずらして設定できるようにする(左上を基準にX座標±nなど)
  137. Iraka.T

    ああ、カード画像の複数指定が実装されていますし、座標指定ができると小さなパーツを組み合わせられるようになっていいですね。

    issueを立てるのはお任せいたします。忘れていたことですから、すなわちすぐさまやりたいことでもありませんので、着手中のシナリオ制作を進めながら待ちたいと思います。

  138. k4nagatsuki reporter

    どうもBitbucketのDownloadsに上がったファイルが全面的に落とせない状態になっているようなので、お知らせに攻略wikiを通じてのミラー配布の案内を書きました。

  139. 暗黒 騎士

    わ、本当ですね。

    XEditorについては保留していましたが、よく考えると片手落ちですので同様にミラーさせていただきますね。 (しかし4正式版x64版しか落としてなかった…) ライセンス的に問題ないかと思いますが、拙かったら教えて下さい。

  140. k4nagatsuki reporter

    問題無いです。

    復旧したようですので、お知らせを過去ページヘ移動しました。ミラーがあってとても助かりました。ありがとうございます。

    それとは別になんか通知メールが全然来ないな……。

  141. Iraka.T

    1ラウンド目に一部のPCの行動が自動選択されない場合がある、という問題が発生しうるようです。

    再現方法を調べてから報告したほうがいいと思ったのですが、どうしても私の製作中シナリオでしか再現できず、その原因もどこにあるのかよくわかりません。必要とあらばこのシナリオをアップロードすることはかまいません。

    _1の縁_20160829_144501_in_贄の町ジェルトファ.png

  142. k4nagatsuki reporter

    これは初めて見る現象ですね。バトル開始イベント内で何か起きているのでしょうか?

    問題のバトルやイベントの内容をちょっとずつ削っていって、再現しなくなる所があれば、そこが原因です。できればそこを調べて教えていただけないでしょうか。

  143. Iraka.T

    再現条件がわかりました。バトル内のイベントでなく、戦闘呼び出し時にパーティが隠蔽状態だったことに原因がありました。

    $battle
    
    hideparty
    gobattle $battle
    
  144. k4nagatsuki reporter

    調査していただきありがとうございます。

    どうやら、自分自身を対象にした行動が、PCが隠蔽状態の時に対象無しで無効と判定されていました。pull request #1538で修正しましたので、よろしければご確認ください。

  145. 暗黒 騎士

    以前はこうはならなかったかと思うのですが、「仲間を外す」で、たとえば6人から1人パーティにした際、ステータスバーの中止ボタンが表示されっぱなしになっているようです。(フォーカスが別のカードに合った時に消えるので無害と言えば無害?)

    CardWirthPy 1.1 Build: 2016-09-01 21:48:34

  146. k4nagatsuki reporter

    ありがとうございます。pull request #1542で修正しました。

    再描画がされていないだけで、実際にはスプライトは消えていますね。押す事はできません。たぶん1.0リリース前後でステータスバーの表示周りに手を入れた時にバグが入ったのでしょう。

  147. 暗黒 騎士

    ツイッターの方が検証していらしたのですが、

    [init]
    filename=xxx.bmp
    

    というjpdcを宿サイズで表示させるとCWでは宿の全画面が表示されるのに対して、Py1では二重実行されてマトリョーシカ的な表示になるようです。12.3bでは正常なのでおそらく87e2559 あたりの変更の影響ではないかと思います。

  148. k4nagatsuki reporter
    • pull request #1549 JPDCマトリョーシカ
    • pull request #1550 paintmode

    ありがとうございます。それぞれ修正しました。


    JPDCの問題は、CWPyではセーブ&ロードで背景が変化してしまう事を避けるために操作可能になった時点でJPDCの再撮影処理を行うようにしているのですが、この処理が不要なときにも発生してしまっていたという問題でした。

    今回の問題は直ったと思うのですが、検証中、エリア自体にJPDCイメージを直接置くとエリア移動前の背景を撮影するためにセーブ&ロード時に復元するのが無理、という問題を見つけてしまいました。まだJPDC周りは根の深い問題があります。気長に取り組む必要がありそうです。


    paintmodeの問題は修正しました。これは次の2つの要因が絡んでいる問題でした。

    • JPY1アニメーションの直後に背景切替が発生する事が想定外というシナリオがあまりにも多いので、CWPyでは「アニメーションがあった場合」を条件に背景切替方式を無視するようにしています(今考えるとこの仕様も問題がある気がするなぁ……)。
    • CWPyではJPY1ファイルの実行結果をキャッシング(内部メモリに保存)して次回以降高速に表示できるようにしています。しかしアニメーションを行った場合や背後のセルに対して乗算・加算・減算処理を行う(つまりpaintmode=0以外)場合はキャッシングができません。そういう場合はキャッシング無効というフラグを立てるようにしています。

    そして今回の問題は「キャッシング無効」のフラグを「アニメーションあり」の判断に流用してしまったために発生しました。

  149. Iraka.T

    paintmodeの問題の修正を確認しました。対応ありがとうございます。

    エフェクトブースター周りはややこしい問題が多いですね。

  150. Iraka.T

    貼り紙と一覧を同時に表示している場合、フォルダを選択して表示しているときに、+ -の部分をクリックすると奇妙な動作をするようです。

    • 貼り紙表示はクリックしたフォルダのものになる
    • Folder.bmpは読み込まれない
    • 一覧での選択は移動しない
    • 貼り紙クリックや「見る」ボタンで、一覧で選択しているフォルダの中へ移動する
    • フォルダでなくシナリオを選択しているときには発生しない
  151. k4nagatsuki reporter

    ありがとうございます。pull request #1522で修正しました。

    フォルダの選択を変更していないにもかかわらず、ツリー上で展開したフォルダの内容の名前リストが誤って表示されていました。

  152. crowstar

    提案なのですが、トップページのダウンロードの部分でミラーのダウンロードも可能にしてはどうでしょうか。
    私の回線が悪いのかどうかはわかりませんが、ここからのダウンロードではダウンロード速度がかなり遅く
    とてもではありませんがダウンロードするのが厳しい状況です。
    ミラーからであれば大分マシな速度となるので、ここからではダウンロード速度が遅い人のために
    トップページからミラーのダウンロードも用意してあった方が良いと思います。

  153. k4nagatsuki reporter

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

    そうですねぇ、Bitbucketプラットフォームはお世辞にも安定して速度も出るとは言いがたいので、「1.1(ミラー)」のような感じでリンクを張った方がよさそうです。

    問題は誰がそれを保守するかなのですが、現在存在するミラーの管理者は@akkwさんなので、そのアップロードを待ってから私などがwikiを編集するか、@akkwさんがアップロードと同時に編集するか、という事になるのですが、どうしたものでしょうか。

    @akkwさんにお願いできるとありがたいのですが、手間を増やす事になるので、難しそうであれば私がやります。

  154. 暗黒 騎士

    わかりました。どう考えても長月さんの雑務は減らした方が良いので自分がやるべきですね。

    書式などに問題があったら適当に直して下さい。

  155. crowstar

    ミラーとのリンクが追加されているのを確認しました。
    素早い対応ありがとうございます。

  156. k4nagatsuki reporter

    ありがとうございます。助かります。

    今のCWPyは本当に何人もの方に支えられていますね。ありがたい限りです。

  157. Iraka.T

    ふと思ったのですが、致命的な問題が発見されていてアップデートを推奨している過去のリリース版を、ダウンロード可能にしておく必要はあるのでしょうか?

  158. 暗黒 騎士

    アプデで逆にバグが入っていることもあるので検証をする上では有用かと思います。

    ただ、ライトユーザー向けではないので1.0のミラーは必要ないかもですね。外しておきます。

  159. k4nagatsuki reporter

    @akkwさんの指摘通りですが、実際にはDownloadsにあるのでwikiからリンクを張るのは無用な混乱を招くだけかもしれませんねぇ。他のソフトが同じ理由で複数のバージョンを並べてダウンロード可能にしてあるのは、古いバージョンのアーカイブまでライトユーザがたどり着くのが容易でないというような別の理由がある気がします。

    CWPyにはそういう理由は無いので、後で外しておきましょう。

  160. Iraka.T

    ありがとうございます。一般ユーザー向けではない目的だろうとは思っていましたが、Wikiのホームに並べてあるのが不思議だったので。

    確たる何かがあってのことなら、せめてダウンロードリンクの付近に旧バージョンの危険性を知らせる文言があるべきかな、などとぼんやり考えていました。

    BitbucketのWikiもデザインに融通がきくなら、私ももう少しできることがあるのですけれど。

  161. k4nagatsuki reporter

    トップページへの旧バージョンへのリンクは外しておきました、

    最近は開発に興味のない方に訊ねられたら攻略wikiの方を先に紹介するべきなのかなー、と思っています。どう考えても私が書いた部分はうまくない……。

  162. Iraka.T

    Bitbucket自体がかなりそっけないですし、サイドバーには専門用語が並んでいますし、文言以前の問題で一般ユーザーの抵抗感を掻き立てる部分があるんですよね。


    ところで、BloodWirthがギルドの新着から消えて、ダウンロード数の増加がおさまったのですが、スキン単体版がおよそ80、Py同梱版がおよそ60ダウンロードです。1.1のダウンロード数が現在316ですから、その2割近くの数がBloodWirthからPyに手を出してくれたようです。

    そのうちどれだけのユーザーが気に入ってくれたかは全く不明ですけれど、試みとしては大成功と言える気がしました。

  163. k4nagatsuki reporter

    私のシナリオもそこそこダウンロードされているようですし、まだまだギルドの影響力は健在ですね。

    吸血鬼人気と、BloodWirthのページ自体のセンスのよさも効いているはずです。

  164. 暗黒 騎士

    久々に初心者的な質問ですいません。

    ようやく落ち着いてきたので新しい環境にpythonを入れ直そうとしているところ、 2.7.12が6月終わり頃にでていたようなのですが、2.7.11を入れた方がよいのでしょうか?

  165. k4nagatsuki reporter

    あ、すいません。私の方ではもう2.7.12で動かしています。ReadMe.txtは書き換えたのですが、wikiの方の更新を忘れていました。

  166. 暗黒 騎士

    こちらこそすいません、Readme見るべきでしたか。了解です。コミットをpythonで検索すると7f0fba7がでたので最新が11かと思いました。

  167. 暗黒 騎士

    ダイアログの移動ボタン(RLMOVE&UpDownなど)の形状を変えたくて、あらためて比較していて気がついたのですが、 1.28/1.50ではボタンを押し続けると0.5秒間隔程度で連続クリックしているような状態になりますが、 Pyでは一回で止まってしまうので少し操作性が悪くなっているように思います。

    これは直せない理由があるのでしたっけ? 簡単そうならチャレンジしてみたいと思うのですが…

  168. k4nagatsuki reporter

    理由は無いです、というよりその機能の存在を初めて知りました。

    数値編集欄では、すでにボタンを押し続けると連打状態になるという機能を実装していますので、それを参考に機能を追加するのは難しくないと思います。具体的にはこの辺りのコードです。チャレンジは大歓迎です。よろしくお願いします。

  169. 暗黒 騎士

    ありがとうございます!ちょっとボタンの方は行き詰まってしまった(単純にstyle = wx.NO_BORDERに変えるとフォーカスで色が変わらなくなり、CWにはトグル風のアニメがあるがPyにはなく、トグルボタンにするとNO_BORDERが効かない…)ので当面はこれを頑張ってみます。

  170. Iraka.T

    「毎ラウンド」のイベントで獲得したカードが使用できないことがあります。(このイベントでカードを獲得することはまれでしょうが)

    行動選択はできるのですが、実際に使用されません。アイテムと召喚獣で現象を確認。技能は検証しておりません。

    事前にカード所有分岐を行ってから獲得した場合は正常に動作します。

  171. k4nagatsuki reporter

    ご報告ありがとうございます。

    すみません、手許で添付したようなシナリオを作って試してみたのですが、再現しません。単純に毎ラウンドで取得するという以外に何か条件があるのか、それとも非常に低確率なのでたまたま再現しないだけでしょうか。

  172. Iraka.T

    どうやら獲得直前に剥奪コンテントがあることが再現条件の一つのようです。パーティの全員からすべて剥奪した直後に獲得すると、その戦闘中は使用できないカードになります。

  173. k4nagatsuki reporter

    なるほど、分かりました。それは仕様です(たまに言ってみたいフレーズ)。

    使用を予定していたカードが無くなると、そのカードの使用は中止されます。同じカードを配ったとしても、それはカードの種類が同じというだけであって、使用しようとしていたカードと同一の個体というわけではありません。従って、改めて新しい方を使うという事はありません。

    念のため1.50で試してみましたが、そのように動くようです。

  174. Iraka.T

    仕様でしたか。ありがとうございます。お騒がせして申し訳ありません。

    ある条件のもとで消耗品を補充するというようなギミックを組む場合、ラウンド終了イベントを擬似的に組んで処理をするか、一人ずつ処理をする必要があるということですね。

  175. k4nagatsuki reporter

    そうですね、今のCWの仕様ではちょっと工夫が必要かと思います。

    カードの使用回数を回復させる仕組もそのうち作った方がよさそうですが、実はCWには召喚獣カードの最大使用回数というデータが無い(現在の使用回数しか記録されない)ので、また仕様を考える時に悩む事になりそうです。

  176. 暗黒 騎士

    さっき初心者の方に案内しようとして気付いたのですが、スキンはNEXTのexeからも作ることが出来るんですね。

    それで、そのNEXTに宿がある場合、NEXT宿のショートカットが自動で作られて、次にスタートから宿選択ダイアログを開いた瞬間、NEXT宿が圧縮されているためか読みに行ってフリーズするっぽいです。1.50とNEXTの区別がついていない初心者の人は結構多いのでこれ課題的にはcriticalなんじゃないでしょうか。 (どうりで時々、Pyでスキン作ろうとしてバグったからNEXTに戻ったなどと言ってる方を見るわけですね…)

  177. k4nagatsuki reporter

    ありがとうございます。

    私のところで試すとフリーズしないのですが、文字化けしたデータが発生しますね。どこでどうなってるんだろう? 調べてみます。

    そこでエラーが起きないようにする必要もありますが、そもそもショートカットを張らないようにする必要もありますね。

  178. 暗黒 騎士

    あ、正確には自分も最初は見れたのですが、一覧表示で二回ぐらいNEXT宿をクリックしてみたところ、挙動がもっさりし出して、 タスクマネージャーから強制終了するしかなくなり、次回以降は上記したようになりました。

    全てのショートカットを消すと元通り動くようになりました。

  179. k4nagatsuki reporter

    pull request #1571

    対処しました。1.1のコードからブランチして1.2を出すレベルの案件ですかね。個人的には案内を出せば充分かも、という気持ちもあるのですが。

  180. 暗黒 騎士

    お疲れ様です。

    WSN2の実装もはじまってややこしくなっていますし、これのみではきりがないので出さなくていいと思います。(ただ前回のような長期化があるのであればどこかのタイミングで累積アップデート的なものは出した方がいいかもとは…)

  181. k4nagatsuki reporter

    Mercurialでは(というかバージョン管理システムは)ある時点のコードから分岐を作る事ができるので、コードが入り混じる心配はしなくていいです。重大な問題なら1.1をベースにそれだけ修正したリリースを出す事は可能です。少し面倒ですが。

    とりあえず今回は、wikiの冒頭にお知らせを出しておきましょう。

  182. Iraka.T

    フォントを変更していて気づいたのですが、多くの項目で斜体にすると太字が効かないのは、意図あっての仕様なのでしょうか。

  183. k4nagatsuki reporter

    フォントにもよると思うのですが(フォントによっては太字と斜体の組み合わせを用意していない場合がある)、例えばどのような項目・フォントで効かないのでしょうか。

    太字が確実に効くといえるのは実はメッセージ(PCが喋ったりするやつ)だけで、これはCWとの整合性をとるために、本来フォント側で用意している太字を使わず自前で横2列に並べる方向で太くしているためです。

    テキスト描画の問題は場合によってはシステムコールレベルまで下りていかないとならないので解決できない事があるかもしれません。もうちょっとアプリケーションからの制御が効くといいのですが、たぶん仕様上難しいんでそうね。

  184. Iraka.T

    貼り紙等ダイアログ内のテキストに関しては太字斜体になるようです。

    それ以外、メインウィンドウでレンダリングされる部分では、ほとんど(検証しきれていませんがおそらくすべて)の項目で太字斜体になりません。Arial等、確実に太字斜体が用意されているフォントでも、斜体を指定すると太字が無視されるようです。

  185. k4nagatsuki reporter

    幸いな事にアプリケーション側のバグでした。pull request #1572で修正しました。

    普通ならちょっと設定を変えるだけで起動と同時にエラーで落ちるような性質のミスだったのですが、ほとんど奇跡的なほど細い隙間を通って太字と斜体が同時に指定できないという程度の発現の仕方をしていたみたいです。恐ろしい事もあるものです。

  186. Iraka.T

    致命的な問題にならないからこそ発見が遅れたのでしょうね。

    フォント設定に関してもう二点、バグというべきなのかわかりませんが、少し戸惑う挙動なのが気になっていたことを。

    チェックボックスをクリックすると、まずテーブルセルにフォーカスが入り、もう一度クリックすることでチェックが変化しますよね。このとき、「適用」ボタンが有効になりません。フォーカスアウトするか、再度クリックしてチェックの状態を戻すと有効になります。

    フォント名を変更しようと思った時に、テーブルセルにフォーカス→選択リストにフォーカス→選択リストを開く、と3回クリックが必要になるのが少々煩わしいです。(テーブルセルにフォーカス→チェックボックスを変更の2クリックも煩わしさはある)

    GUIライブラリの仕様でどうしようもない部分なのかと思っていたのですが、この際なので言ってみます。改善できるならできたほうがいいでしょうし。

  187. k4nagatsuki reporter

    それは私も当初から気になっていたのですが、解決できなかった部分です。

    改めて取り組めば改善できる可能性も無いとは言えないので時間のある時にやってみますが、あまり期待しないでいただけるとありがたいです。

  188. k4nagatsuki reporter

    pull request #1580

    あまりいいやり方ではありませんが、真偽値の欄はエディタを開いた時点で適用ボタンを押せるようにしました。

    何がよくないかというと、F2などで値を変更せずにエディタを開いた時でも適用ボタンが有効になってしまう事です。しかし操作の快適性を考えるとこちらの方がましでしょう。

  189. Iraka.T

    チェックボックスの対応ありがとうございます。変更したのに適用できないよりはずっと快適だと思います。


    Traceback (most recent call last):
      File "cw\frame.pyo", line 1216, in FilterEvent
      File "wx\_core.pyo", line 4987, in GetEventType
    wx._core.PyAssertionError: C++ assertion "item.IsOk()" failed at ..\..\src\msw\treectrl.cpp(1287) in wxTreeCtrl::IsSelected(): invalid tree item
    

    再現性がよくわからなくて報告しづらかったのですが、アプリケーションを終了する時に時々エラーが出ます。上のログを吐いたのは昨日のことなのですが(バージョンをメモするのを忘れました)、すべて同じ問題なのかはよくわかりません。

    cardwirthpy_20160926b.zipを利用中にも終了時にエラーが起きまして、その時のログには以下のメッセージが追加されていました。

    Traceback (most recent call last):
      File "cw\setting.pyo", line 1562, in timerfunc
    TypeError: stoptimer() takes exactly 1 argument (0 given)
    Traceback (most recent call last):
      File "cw\setting.pyo", line 1562, in timerfunc
    TypeError: stoptimer() takes exactly 1 argument (0 given)
    

    再現性がわからなくてもログを吐いたときは報告したほうがいいでしょうか。(よくサボってログを貯めるせいで見ているものが本当に今吐いたものなのか自信をなくす人)

  190. k4nagatsuki reporter

    pull request #1581

    後者のエラーはすでに直っていると思いますが、前者のエラーは前々からしばしば見られる困りものです。というのは、これはアプリケーション側から見るはずのないエラーだからです。

    AssertionErrorというのは、アサーションと呼ばれるコードのチェックに失敗した時に出てくるエラーです。アサーションというのは、例えば「この処理はマイナス値同士の掛け算をやるから、結果は絶対にプラスになるよね」というような事をコード上に書いて、万が一その条件を満たさなかった場合にはエラーとする事で、「処理にバグがある」という事が明白に分かるようにしたものです。

    で、このアサーションエラーがどこから出ているかというと、GUIライブラリのwxPythonのC++のコードの中から出ています。つまりライブラリ内にバグがあるという事です。ライブラリが更新されない限り、アプリケーション側からできるのは問題を回避する事だけです。

    というわけで、回避用のチェック処理を少し増やしてみました。これで事は改善するかもしれませんし、しないかもしれません。するといいなぁ、と思うのですが。


    エラーログがあったらできるだけ報告していただけるとありがたいです。それだけで問題を特定して直せる場合があります(もちろん特定できない場合もあります)。

  191. Iraka.T

    わかりました。ログが書き出された場合にはなるべく忘れずに報告をするようにします。

    エラーの説明もありがとうございます。これも解決が困難なものだったのですね。

    終了時にこのエラーが出ることで、ユーザーが困るような現象が起きる可能性はありますか? 私は困ったことがない(エラーを目にすることで不安を感じる以外には)のですが。そこそこの頻度で見るので、どこかに説明があったほうがいいと思っていました。

  192. k4nagatsuki reporter

    このエラーについては今までのところ何か実際の問題が起きたとは聞いていません。ショートカットキーなどの割り込み処理のところでエラーが出ているので、実際にその部分の処理が中止されても実害は生じないはずです。

    しかし、この問題、私の持っているいくつかの環境ではまったく起きないです。起きるところではそこそこ起きるようなのですが、どれくらいの方の環境で起きているんでしょう?

  193. 暗黒 騎士

    ログをAssertionで検索するとXP時代の自分とtakuto氏(読むにXPを使われていたようです)しか報告していませんね。 自分は今の環境では再現していないのでIraka.TさんがXPまたは32bitOSであればレガシー環境由来といえるかも知れません。

  194. Iraka.T

    Windows10 64bitなので、レガシー環境に限らないようです。

    環境の特殊性を挙げるなら、マウスやトラックパッドをほぼ使わずペンタブで操作していることがありますね。(ホイールに相当する操作をすると問題があるのですが、説明して解決していただくのはおそらく困難なので、私がPythonを勉強するべきだと思いつつ)

    あとは、あたかも常駐ソフトのように何時間も放置することがあるくらいでしょうか。

    再現の条件がわからないといったとおり、必ず起きるというわけではなく、何日も見ないことがあれば、先日のように連日だったり、一日に何度も見たこともあります。

  195. k4nagatsuki reporter

    今回のエラーの内容からするとどうもシナリオ選択周りでエラーが起きたようなのですが(ダイアログを閉じたあとで消滅済みダイアログからイベントが発生した?)、過去に見たエラーログも含め起こる箇所は様々のようです。具体的にどうしたら発生するというものではなさそうですね。

    今回のチェック追加で出なくなれば万々歳なのですが。

  196. k4nagatsuki reporter

    pull request #1584

    すいません、チェック式の1つが間違っていて「キーイベントだけ通す」が「キーイベントだけ通さない」になっていました。

  197. 暗黒 騎士

    冒険の再開ダイアログで拡大率によって看板がめり込むようになってるようです(画像はgroupASK)

    (報告とは関係ないですが)たぶん斜体と太字が同時に効かないバグが修正された影響で、所持金のフォントをほぼCW完全一致の表示にできるようになってますね。Py1で心残りだった部分なので嬉しいです。

  198. k4nagatsuki reporter

    ありがとうございます。pull request #1585で修正しました。

    カードサイズの値が直に書かれていたので定数を使うように直したのですが、スケール指定が抜けてました。

  199. 暗黒 騎士

    お疲れ様です。修正を確認しました。

    メッセージログについても行間を詰めている場合に頭が途切れる場合があるのを見つけたのですが、多分これもその影響でしょうか…(元からだったかもしれない)

  200. k4nagatsuki reporter

    すいません、なんかパンク状態みたいなんでしばらく休ませてください。

    今週は密度が高すぎた。

  201. k4nagatsuki reporter

    軽いやり取りとかpull requestの対応くらいならできると思います。

  202. 暗黒 騎士

    修正を確認しました。無理させてしまったようですいません……。

    季節の変わり目ですのでどうぞお体お大事に。

  203. hand.onlooker

    Py1.1で、ロードするとセーブ時に鳴っていたBGMが消えてしまいます。 シナリオは1.50仕様のクラシックシナリオです。

  204. tachi gigas

    恐れ入ります。

    CardWirthPy_1.1.zipBuild: 2016-08-15 00:24:45、cardwirthpy_20160929b.zipBuild: 2016-09-29 23:25:04、以下の1.50シナリオで、設定ファイルを変更しない場合と初期化した場合とでテストしましたが、セーブ&閉じる&ロードしてもBGMは再生されました。

    • itsuka様「話が長い子爵の護衛」(MP3)
    • 自作「リューン港東区誰得通り」(MIDI。すみません、適当なシナリオが思いつきませんでした…。)
    • かのじ様「銅杖の枷」(デフォルトMIDI)

    今k4nagatsuki様が不在なため、恐縮ですが、現象が発生したPyの詳細なビルド日時(設定画面の左下にあります)と発生したシナリオとシーン、よろしければ再現性についてご教示願えますでしょうか。

  205. hand.onlooker

    すみません、主張を撤回します。tachigigas様のレスを見て、 設定を初期化してテストしなおしたところ、再生されました。 ご迷惑をおかけしました。

  206. tachi gigas

    承知しました。

    ということは、実は設定のどこかに原因がありそうですが、情報不足ですね。再現した際は、情報の提供をよろしくお願いします。原因究明ならお手伝いができるかも知れません。

    そろそろこのIssueも長くなりましたね。part8の季節でしょうか。

  207. k4nagatsuki reporter

    回復してきたのでぼちぼち復帰します。

    Issueにある事は、ほとんどはとりあえず措いておいても問題は無いはずなのですが、どうも私は翌日に課題を残すと気持ち悪く感じる性格で、これまではできるだけ早く対応する事を心がけていました。

    先週は、それでついに無理が出た感じでした。睡眠時間を削り始めたらさすがにまずいと痛感しました。ですので、今後はできるだけ無理しない方向で行きたいと思います。

    Issueの中で、緊急の対応が必要ないもの・時間をかけて取り組む必要があるもの・私が何かする必要が無さそうなもの・実現困難でモチベーションも薄いもの・その他優先度が低いものなどは、放置気味になるかもしれません。これは私が私の身を護るための事ですので、何卒ご容赦ください。

    「これがずっと放置されてるのはおかしくない?」というものは適当にコメントなど入れて揺さぶっても構いませんし、「じゃあ俺がなんとかしてやるよ/やったぜ」というのはもちろん大歓迎です。

    議論なんかも、意見が対立したらお互いに積極的に妥協点を探りにいくなど、落着へ向けてそれぞれが努力していただけるとありがたいです。

  208. k4nagatsuki reporter

    そろそろこのIssueも長くなりましたね。part8の季節でしょうか。

    そういえばそうですね。

    issue #420を立てました。今後はそちらにお願いします。

  209. Log in to comment