●検討中事項 ◎★ 重大な仕様上の問題: 現在のqrlmakerは、QRLライブラリに於いて「QRLチップの英語名が絶対的な基準」であるとして処理しているが、そもそも英語名が英語的にあるいは文法的に間違っていたらどうする? → QRLチップライブラリの英語名を修正すると、QRLセーブデータの互換性が途切れてしまう問題。 →→ どうしようもない。英語の添削してくれる人が欲しい。 ◎チップ画像サイズの変更。 最近の高精細なディスプレイの場合既存の画像サイズだと見づらい事に今更気付いたので画像サイズを大きくした。 → チップ画像を全部書き直し。 →→ 開始日:r1130 , 2022/07/24(日) →→ 進捗状況:2024/03/11(月) 現在で50%(93/185)完了。 →→→ サイズ4x3,残: 3。 →→→ サイズ5x1,残: 8。 →→→ サイズ5x2,残:25。 →→→ サイズ5x3,残: 2。 →→→ サイズ6x1,残:35。 →→→ サイズ6x2,残: 8。 →→→ サイズ6x3,残: 1。 →→→ サイズ7x1,残:10。 ◎メック情報の保持の仕方の仕様変更。 → 現在:情報取得チップを実行した瞬間の情報を得る。 →→ 問題:後述の未サーチ/失探、辺りとの整合が取れない。 → 予定:lua側の配列に情報を持ってしまい、そのターン開始時に丸ごと更新する。 →→ Suspend/Resume周りが地味に面倒。 ◎敵機のサーチ関連チップ。 → ターゲットメックに対して、未サーチ/失探/検出/撃破済み、の、判定チップ。 → メック情報取得チップにて、未サーチ/失探の場合は情報を得られなくする。 → 失探した時に、最後に探知成功した座標を取得するチップ。 ◎武器とか敵機とか味方機とかの取得チップ。 → 最も条件に合致する1つだけ取得よりも条件でソートした一覧取得の方がプログラム的かも。 → 既存の情報取得チップが1つだけの扱いになっているのを配列扱いに変更。 → ユーザ変数の型式に「複数機体」の型を追加する必要が有る。 →→ GUID_List, Mek_List が新規に必要。String_List, Part_List, Module_List, Weapon_List, Ammo_List も必要か? →→→ Suspend/Resume周りが地味に面倒。 ◎新規で作成した移動ルート検索アルゴリズム(A*)のブラッシュアップ。 → 機種や移動形態別の、移動不可地形判定。 → 機種や移動形態別の、既存物体に対する進入不可判定。 → 機種や移動形態別の、移動コスト算出。 → 目的地種別別の、ゴール地点判定。 → 目的地種別別の、ヒューリスティック算出。 → 移動ルート検索チップの追加。 → 移動パラメータ設定チップの追加。 →→ 移動ルート検索:前進/後進の移動コスト設定。 →→ 移動ルート検索:旋回の移動コスト設定。 →→ 移動ルート検索:移動内容の変更コスト設定。 →→ 移動ルート検索:段差回避(断崖に追加の移動コストを設定)。 →→ 移動ルート検索:炎回避(炎に追加の移動コストを設定)。 →→ 移動ルート検索:平地回避(平地にも移動コストを設定)。 →→ 移動ルート検索:森林優先(移動コストを負にはできないので、代わりに平地の移動コストを追加して、森林の移動コストを平地より小さくする)。 →→ 移動ルート検索:煙優先(移動コストを負にはできないので、代わりに平地の移動コストを追加して、煙の移動コストを平地より小さくする)。 ◎変形関連のチップ。 → 着目形態番号/指定形態/現在の形態番号の名称を取得。 → 着目形態番号/指定形態/現在の形態番号における形態を取得。 → 着目形態番号/指定形態/現在の形態番号における最高速度を取得。 → 着目形態番号/指定形態/現在の形態番号における最高 DC を取得。 ◎リペアアルゴリズムをどう実装する? ◎脱出判定アルゴリズムをどう実装する? → 標準の NPC の思考アルゴリズムだと、@ 側の NPC と、@ に敵対している側の NPC で、判定条件が違う事に気付いた。どうすんべ。 ◎環境設定ダイアログを追加。 → あんまりやる気無し。 [ End of File ]