--メモとか色々


--[課題]
--●使えるカードを増やす(っていうかちゃんとカードを使う)
--	現状、問題なく使ってるのはフレアアップのみ(他はデタラメしよう)という状態
--	実装するなら
--		スキカ:ゲイザー
--		スペカ:ギガフレア、八咫烏ダイブ
--		シスカ:霊撃、ガ反、能力up系
--	この辺を優先？
--	カードをデタラメじゃなしに使用するなら、また専用処理を用意しなければ
--●コンボルートを増やす
--	現状、「AAA>フレアアップ>J8A」「AA>6A>2C>J6A」の二つの流れしかない
--	後者は6AからJ6Aまでがセットなので、2C>J6Aは6Aから繋げないと拾わない(2C>追撃の条件を個別に与えていないため)
--	今でも色々取りこぼしているし、ゲイザー使い出すと益々ルートが増えるだろうし、、、手を付けるなら本腰入れないと
--●コンボなどで見られる怪しい仕様
--	「条件を満たす(あるモーションになる、nフレーム経過する、etc.)まで待つ。但し途中で途切れたら(被弾、距離変化、etc.)中断」
--	これを実現しようと、所々に怪しいループがちらほらと……実はちゃんと機能しないこともあったり
--	無駄な入力の防止に役立ちそうだし、なんとかしてSetInputみたいにちゃんとした関数としてまとめたい
--●暴発(22、66、6236)
暴発対策実装してみました。

--●攻撃の種類、立ち回り
--	コンボ以外の攻撃行動は、全て「攻撃」で一括りにしている
--	本来なら「牽制」「固め」「切り返し」などに分かれるべき
--	それをしないのは、お空の立ち回りがよく分らないから……AI作るまで触った事すらなかったよ！
--	プレイヤースキルが可哀相な人なので、wikiや他人のリプレイ見ながら頑張るしかない
--●キャラ対策
--	基本の立ち回りが分らない人に、キャラ対策なんて分るはずがない！
--	私は当分手を付けない予定
--●観賞モード？乱数ファイル作成？
--	結局何がやりたいのかというと、
--	「対戦時でもリプレイ再生時でも、同じ試合ならAIが完全に同じ動作をする」
--	これがデバッグに関する一つの目標で、観賞もーどや乱数ファイルはそのために用意したもの
--	適当に実現すれば、動作検証に役立つかと思って試行錯誤
--	現実はというと、処理落ちしたりフレームが飛んだりして全く目標の機能を果たしていない...orz


霊夢溜3Aの判別は、enemy_actとenemy_imgを併用すればなんとかなると思う。
クラッシュ下段まで溜めるとenemy_imgが100前後から130前後になるので、これで判別できるはず。
尤も私はキャラ対策なんて(ry


[暴発対策]
22C暴発は、1Cや3Cと入力すれば回避できるらしい。これは助かる。
殆どの暴発対策は、「直前に1FだけD入力」でなんとかなるっぱい。

例:6>6AがDAに化けるのを防ぐ
--function test_66A()
--	--##邪魔な6入力##
--	key_on(front);
--	yield();
--	key_off(front);
--	yield();
--
--	--##11F以内の処理##
--	(省略)
--
--	--##本命の6A入力##
--	key_reset();
--	
--	if (暴発対策が必要) then
--		--1FだけDを入力
--		key_on(ACT_D);
--		yield();
--		key_off(ACT_D);
--	end
--	
--	key_on(front);
--	key_event(ACT_A);
--end

・暴発対策が必要かどうかを、状況によって判定すべきか？
正確に判別するなら、
	キー入力状態を毎回保存して、十数フレーム前からの状態推移をチェックする
	→これからのコマンド入力とキー状態推移を比較し、暴発が起きるかどうか判別する
とする必要がある？
コマンドや技によってそれぞれ条件が異なるので、とってもめんどくさそう...
なので簡易版の判別として、コマンドに関係なく
	このフレームで入力しようとしているキーが、1F前に入力されていたかどうか
を採用しようと思う。
このフレームで入力しようとしているキー(以下key)の入力状態は、
現在のフレームで何も入力処理(key_reset,key_onなど)を行っていない状態で
get_key_statやget_key_mapを用いれば判る。
暴発の恐れがない状況でも対策処理を実行するので、普段の入力が遅れるというデメリットがある。
しかし遅れるといっても精々1Fなので、気にしない方針で。
入力反映のラグが約2Fであること、処理が間に合わず頻繁に1Fとぶことを考えれば誤差の範囲だろう。




[お空2C、J2Cなどについて]
・攻撃判定のある範囲はどうなっているか？
get_obj_dataを使って2Cなどを調べると、攻撃判定のあるオブジェはが1つしかない事が分かった。
常に2番目のオブジェが攻撃判定を持つらしい。19~73F

get_hitareaから2C攻撃判定の各頂点を軽く調べると、
	obj_back 	176	206	236	267	297	327	358	388	418	449	509	540	570	600	630	691	721	752	782	812	843	873	903	934	964	994	1025
	obj_up   	178	196	213	231	248	266	283	301	318	336	371	388	406	423	441	476	493	511	528	546	563	581	598	616	633	651	668
	obj_front	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191	191
	obj_down 	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84	84
前・下座標が固定、後・上座標が上昇
後<前なのは最初だけ(というかそのせい)で、以降は前<後という謎仕様

攻撃判定の矩形も斜めになっているのもAI(作者)泣かせ……
そのまま素直に↑の各頂点を結んだ長方形で範囲を考えると、恐ろしい事になる。
前方をほぼ埋め尽くす脅威の広範囲……んな訳あるか!!


・get_obj_dataの番号
i番目のデータ
i=0	id=990,oid=26767776,img=472
i=1	id=990,oid=26766760,img=172	,oxs=oys=0

i=2	id=803,oid=26649408,img=190	--攻撃判定あり

i=3	id=803,oid=26761680,img=188
i=4	id=803,oid=26765744,img=188

i>5	id=803,oid=26******,img=189	--多分"やじり"みたいなやつ


・ふれーむでぃすぷれー
お空2C,6Cなどに関するしーくえんす(?)番号の予想
763-768,835,836,929,930

・実態(予想)
多分2Cとか6Cは

 　　　  ^^      ^^
[制御棒]<○□□■○>
 　　　  vv      vv

	○	:ビームの両端にある玉
	■	:後ろにすごく長い攻撃判定をもつビームのグラフィック(一部)
	□	:攻撃判定を持たないビームのグラフィック(一部)、■の攻撃判定の上に被さっている
	^,v,<,>	:周りに飛び散る"やじり"みたいなやつ

こんな感じになっているんじゃなかろうか
