●検討中事項

◎★ 重大な仕様上の問題：
現在のqrlmakerは、QRLライブラリに於いて「QRLチップの英語名が絶対的な基準」であるとして処理しているが、そもそも英語名が英語的にあるいは文法的に間違っていたらどうする？
→ QRLチップライブラリの英語名を修正すると、QRLセーブデータの互換性が途切れてしまう問題。
→→ どうしようもない。英語の添削してくれる人が欲しい。


◎メック情報の保持の仕方の仕様変更。
→ 現在：情報取得チップを実行した瞬間の情報を得る。
→→ 問題：後述の、未サーチ／失探、辺りとの整合が取れない。
→ 予定：lua側の配列に情報を持ってしまい、そのターン開始時に丸ごと更新する。
→→ ターン開始時に、着目メックから全メックに対して、未サーチ／失探／検出／撃破済み、の、情報を検索してターン中は保持する。
→→ 「未サーチ」の場合は、一切情報を得られない。
→→ 「失探」の場合は、フラグを立てて最後に得られた情報を更新しない。
→→ 「検出」の場合は、全情報を更新する。
→→ 「撃破済み」の場合も、全情報を更新する。
→→ それを全メックに於いて実施する。
→→→ Suspend/Resume周りが地味に面倒。


◎敵機のサーチ関連チップ。
→ ターゲットメックに対して、未サーチ／失探／検出／撃破済み、の、判定チップを追加。
→→ メック情報取得チップでは上記の状態に応じて得られる情報を変える。
→→ 「未サーチ」の場合は、情報を得られなくする。
→→ 「失探」の場合は、最後に探知成功した情報を取得する。
→→ 「検出」の場合は、従来通り。
→→ 「撃破済み」の場合も、従来通りかな。


◎武器とか敵機とか味方機とかの取得チップ。
→ 最も条件に合致する１つだけ取得よりも、条件でソートした一覧取得の方が、プログラム的かも。
→ 既存の情報取得チップが、情報１つだけの扱いになっているのを、配列扱いに変更。
→ ユーザ変数の型式に、「複数機体」の型を追加する必要が有る。
→→ GUID_List, Mek_List が新規に必要。String_List, Part_List, Module_List, Weapon_List, Ammo_List も必要か？
→→→ Suspend/Resume周りが地味に面倒。


◎新規で作成した移動ルート検索アルゴリズム（A*）のブラッシュアップ。
→ 機種や移動形態別の、移動不可地形判定。
→ 機種や移動形態別の、既存物体に対する進入不可判定。
→ 機種や移動形態別の、移動コスト算出。
→ 目的地種別別の、ゴール地点判定。
→ 目的地種別別の、ヒューリスティック算出。
→ 移動ルート検索チップの追加。
→ 移動パラメータ設定チップの追加。
→→ 移動ルート検索：前進／後進の移動コスト設定。
→→ 移動ルート検索：旋回の移動コスト設定。
→→ 移動ルート検索：移動内容の変更コスト設定。
→→ 移動ルート検索：段差回避（断崖に追加の移動コストを設定）。
→→ 移動ルート検索：炎回避（炎に追加の移動コストを設定）。
→→ 移動ルート検索：平地回避（平地にも移動コストを設定）。
→→ 移動ルート検索：森林優先（移動コストを負にはできないので、代わりに平地の移動コストを追加して、森林の移動コストを平地より小さくする）。
→→ 移動ルート検索：煙優先（移動コストを負にはできないので、代わりに平地の移動コストを追加して、煙の移動コストを平地より小さくする）。


◎変形関連のチップ。
→ 着目形態番号／指定形態／現在の形態番号の名称を取得。
→ 着目形態番号／指定形態／現在の形態番号における形態を取得。
→ 着目形態番号／指定形態／現在の形態番号における最高速度を取得。
→ 着目形態番号／指定形態／現在の形態番号における最高 DC を取得。


◎リペアアルゴリズムをどう実装する？


◎脱出判定アルゴリズムをどう実装する？
→ 標準の NPC の思考アルゴリズムだと、@ 側の NPC と、@ に敵対している側の NPC で、判定条件が違う事に気付いた。どうすんべ。


◎環境設定ダイアログを追加。
→ あんまりやる気無し。


[ End of File ]