AI製作関係スレ　その２

1：MUGEN名無しさん：2010/07/18(日) 15:05:37 ID:AP4BZlNs: AIについて語るスレです。
AIについての質問とか見つけたネタを書いてくカンジです。

前スレ
AI製作関係スレ
ttp://jbbs.livedoor.jp/bbs/read.cgi/internet/1117/1232180149/
49：MUGEN名無しさん：2011/03/21(月) 10:31:50 ID:5NogkGjo: >>48

ステートが無限ループしてるね。
[statedef 131]辺りのチェンジステートを調べてみると良いよ。
50：48：2011/03/21(月) 13:26:03 ID:VDMryTbI: >>49
ありがとうございます。
原因はChangeStateのところに、
Trigger2 = EnemyNear(Var(57)),StateNo = Helper(99999),Var(0)(中段攻撃記憶)
Value = 130

Trigger2 = EnemyNear(Var(57)),StateNo = Helper(99999),Var(1)(空中下段記憶)
Value = 131

このように、学習したステートを利用してガード変更していたのですが、
変数に数値が代入されていない際の対策をしていなかったのでループしてしまっていました。
どちらにも代入されていなかったら、両方とも0ですものね。
51：MUGEN名無しさん：2011/05/23(月) 11:23:41 ID:Z1nFIlkA: 最初に適当に作ったＡＩが妙に味がある動きをしていて、
そこから距離計算とか有利不利とかきちんと計算してさらに強いＡＩにしようとすると
何か動きがつまらなくなることってあるよね
52：MUGEN名無しさん：2011/05/23(月) 21:08:03 ID:AY2sQ51U: サクラカ氏が作るAIは大抵前者らしいな
53：MUGEN名無しさん：2011/05/25(水) 21:11:40 ID:sxp0R4aM: 適度にぶっぱとかいれないと単調になりがちだよね
54：MUGEN名無しさん：2011/06/17(金) 13:46:34 ID:o1b2HBi.: StateDef40の記述に以下のような記述を入れているのですが、AIが無駄にジャンプしてしまいます。

[State 40, 2]
type = VarSet
Trigger1 = var(59) = 0
Trigger1 = command = "holdfwd"
sysvar(1) = 1

[State 40, 3]
type = VarSet
Trigger1 = var(59) = 0
Trigger1 = command = "holdback"
sysvar(1) = -1

var(59)はAIスイッチです。もちろん、AIの記述には40にchangestateする記述は入れてません。
無駄にジャンプするのは見映えが悪いので無くしたいと思っています。
55：MUGEN名無しさん：2011/06/17(金) 19:50:19 ID:Upop9tps: >54
var(59)=0はAI無効（プレイヤー操作）ってことだよな？
なら逆にAI操作時の記述が必要ってことだ。

後はwikiや製作者のサイトを調べてみたほうがいいと思うよ。
他の人の記述見るのも手だけど、理解するのが大変かもしれない。
56：MUGEN名無しさん：2011/06/17(金) 20:29:13 ID:OvOhwVCU: 確かに人の記述は人によっちゃ魔術書か何かに近いレベルの難解な記述とかあるもんなぁ
57：MUGEN名無しさん：2011/06/17(金) 20:41:43 ID:o1b2HBi.: >>55
書くのを忘れていましたが、AI専用のジャンプステートは既に用意してあって、
そこを呼び出してジャンプさせるようにしています。
相手が近距離でダウンしてるときしかジャンプしないようにさせているのですが、
ダウンしていなくてもぴょんぴょん飛んでしまうのでここで質問しました。
P2StateType = Lで相手がダウンしているとき、ですよね？
58：MUGEN名無しさん：2011/06/17(金) 21:22:16 ID:GMMHtEVs: >>57
基本的なことなんですが
方向キーでする基本動作の歩き(20)・屈み(10)・ジャンプ(40)・ガード(120)はMUGEN側で処理されてるんです。
それらはChangeState記述を書いてなくてもCtrl=1などの状態で方向キーを動せばそのステートへ行くので、
MUGEN側のAIを起動させている場合も(MUGENのAIから)方向キーが入力されればジャンプなどをします。
なのでAIがその記述をしていないのにジャンプするという現象が起きるわけです。
ちなみに>>54のsysvarのvarsetは前後ジャンプ指定の記述です。

ニュートラル状態からCtrl=0で処理させようとなると試合開始の認識などが若干面倒なので、
操作処理のジャンプの時(!Time&&Ctrl=1&&StateNo=40)に屈みステートなどへChangeStateしたり、
Ctrl=1のダッシュ中などだけCtrl=0で維持させるといった処理でそうしたジャンプを抑制する方法があります。
前者はAI記述の最後尾に書いて制御し、後者はステートにtype=ctrlset,value=0の処理を追加して
技側を(Ctrl || StateNo=***)という感じで条件制御させればいいかと。
59：MUGEN名無しさん：2011/06/17(金) 22:06:10 ID:o1b2HBi.: >>58
回答ありがとうございます。
wikiなども参考にしながらやってみます。
60：MUGEN名無しさん：2011/06/18(土) 21:39:29 ID:jG/lVq.Y: 自分はstate0でctrl=1になったらAI専用立ちステートに飛ばしちゃうな
これだと不具合起こるんだろうか
61：MUGEN名無しさん：2011/06/19(日) 13:22:14 ID:EfW1Fcn.: 0番ステートの中にCtrl=1&&RoundState=2&&AIフラグでChangeState→AI用立ちステならフライング系の不具合はないかと。
ただ他のステートでも制御してないと、屈み攻撃後の屈み状態(11)から立ち上がり(12)中にジャンプとかはありそうですが。

Ctrl=0制御関係全般に言える事なんですが、
他のCtrl=1のステートもCtrl=0にするなりAI用ステートで制御するなりしないと完全制御できないので大変かと。
Ctrl=1全部をAI用に制御する場合Ctrlの代わりとなる記述をまとめる必要があったりします。
AI用ステートを500xx番とかの括りにしてStateNo=[50000,500xx]で纏めたり、Ctrlの代わりにVarで制御するとか。
Ctrl代わりの情報を使わない方法としてはAI用ステートの中で動作制御をするとかありますけど、その場合
Time!=0条件とかを入れておかないと終了フレームで次の動作を開始したり本来無理な動作をやらかす可能性が。
あとCtrlが戻ったりする動作ステートの中から動作制御するのは、記述が分散して調整が面倒です。
面倒なので完全制御にこだわらず基本的な挙動だけCtrl=0制御するのもありですけど。
不具合としてはCtrl=0制御の場合、試合が終わったらCtrlを戻してやらないと試合終了合図が遅れるとかあります。

あと半分相手のバグの話だけど、Ctrl=0制御だとMUGEN側のAIからのガードが出来なくなるはずなんで、
方向キー操作のガードでないとガードできない状態の攻撃（半分バグ）には一切無防備になってしまうはず。
自分側の不具合以外を上げると、Ctrl=0制御だと相手側のAIがEnemy,Ctrl=0で状況を誤認する場合がありそう。
相手が挑発中とか回避動作中とか溜め動作中とかに誤認し続けるみたいな。相手のミスな気もしますが。

色々と面倒なので自分は最低限勝手なジャンプをさせない程度でいいやと思ってます。
62：MUGEN名無しさん：2011/06/19(日) 16:59:39 ID:fGihNZv.: 攻撃後の屈みについてはノーマークだった、教えてくれてありがとう
63：MUGEN名無しさん：2011/07/03(日) 13:55:53 ID:xf0O4fY6: 方向キーでしかガードできないものはどうせ偶然でしかガードできないんだから無視していいと思うけどね

でも専用立ちステートは変な数字にしてほしくないな
コモンやKFMを基準に考えれば200未満が通常の移動・待機ステートなんだからそこに収めて欲しい
じゃないと回避とかの特殊なMoveType=Iステートが推測できなくなる
まあ俺がCtrl=0＆＆MoveType=IのうちStateNo=[0,120)くらいを嘘硬直として認識してるだけなんですけどね

ただ、AIの都合だけ言わなくても、ステートは基本（KFM）に沿った数字にして欲しいがね
被超必KOカットインとかは3000以上のステートの攻撃でやられた場合、なんて条件になるからそこを外れるとやりづらい
これの場合、EX技なんかの強化必殺技はどうするか迷うところだが
64：MUGEN名無しさん：2011/07/10(日) 19:40:48 ID:leYxo.eY: ちょっと違う話するけど、
ダッシュの時に1F目のアニメのまま滑走することがあるんだけど、どうすればいいかな
ちなみに厨忍氏のサイトに載ってる方法は試したんだけど駄目だった
65：MUGEN名無しさん：2011/07/10(日) 21:20:31 ID:iOpADiBk: 状況がよく掴めないけど、ctrlの条件でダッシュ連打してるとか？
ダッシュステートがctrl=1のキャラもいた気がする
66：MUGEN名無しさん：2011/07/10(日) 22:30:42 ID:leYxo.eY: たぶんそうだと思う
ダッシュステートはctrl=1だった
stateno!=[100,101]をトリガーに組み込んだんだけど駄目だったんだ
67：MUGEN名無しさん：2011/07/11(月) 01:31:19 ID:B4fMOWDk: 自己解決したかも
AI時のみダッシュステートをCtrl=0にして、AI行動のトリガーに

triggerall=Ctrl||stateno=100

と記述するようにしたらなんともなかった
ただこれって不具合でないかな？
68：MUGEN名無しさん：2011/07/30(土) 19:50:56 ID:WdSKJcmI: helpertypeがplayerになってる飛び道具の対策って皆さんどうしてます？
triggerにenemynear,ishelper = 0を入れているのですが、AIがそのヘルパーに向かって技を振ってしまいます。
69：MUGEN名無しさん：2011/07/31(日) 09:43:06 ID:5I21l7zs: >>68
HelperType=Player自体が特殊なもの(AIを殺しにきてるもの)なので、
余程入れ込んで作ってない限り対策してないと思います。

対策としてはEnemyNearやEnemyのリダイレクトはヘルパーを一切感知できないため、
それを逆手に( Pos X - EnemyNear,Pos X ) * Facing * -1の距離数値(擬似P2Dist X)に
向きやStateTypeを感知してConst(Size.Ground.Front)だとかを減算・加算する方式で、
相手本体の位置を認識させて、上手いこと動かすのが一番分かり易い方法ですかね。
その場合「相手本体が後ろに居る」とかを充実させる必要もありますけどけど。
（P2***タイプの情報はHelperType=Playerも(StateNo=5150(死亡ステート)の相手を除いて)認識するので、
相手StatetypeなどもP2StateTypeでなくEnemyNear,StateTypeとかで認識することになります。）

ただHelperType=Playerは「攻撃の当たる分身」の場合もあるのですが、
飛び道具かそうでないかの確実な認識にはその相手ヘルパーを
IDを調べてPlayerID(xx),リダイレクトで感知して
hitdefattr情報を入手して～ということまでしないと無理かと。

AIを作る側としてはHelperType=Playerは分身以外に使って欲しくないのが本音です。
70：MUGEN名無しさん：2011/08/09(火) 03:30:09 ID:mzq5aRog: 70
71：MUGEN名無しさん：2011/08/12(金) 12:23:23 ID:3QApvRMs: p2nameを使っちゃうのは？
helper指定して出ている間は攻撃振らないようにしちゃうのがカンタン
なんじゃないかな
まあそのhelperが常時発生してるなら使えないんだけど
72：MUGEN名無しさん：2011/09/17(土) 01:38:47 ID:yTMaV9kM: AI製作について語りたいから来てみたけど・・
あまり書き込まれてない？
>>67
自分の場合、ダッシュは
Statedef -1　に動作開始条件を、
飛んだ先のステートで終了条件を書いてる。
73：MUGEN名無しさん：2011/09/19(月) 13:32:06 ID:eGOoZPwo: >>72
>>67のやってることは半分それじゃないかな。

いつまでも続けられる＋いつでも止められる＋Ctrl=1タイプのラン型ダッシュは、
AIに制御させる場合、Ctrl=1のままだと色々調整が難しいから
>>67のようにダッシュステートをAI時にCtrl=0にしてしまって、
AI側にあるCtrl=1の動作条件にTriggerAll = (Ctrl||StateNo=100)で
ダッシュステート加えてしまう方式が一番安定するんじゃないだろうか。記述に手間かかるけど。
ただその場合「ダッシュステート内のChangeState（ダッシュ終了処理）で立ちステートへ」戻す時、
ChangeStateのオプションとしてCtrl=1を入れとかないとCtrl=0で立ちステートに戻ってしまうんで、
Ctrl=1を入れるかダッシュステート内のChangeStateをAI時に使わないようする必要があるけど。

自分も動作開始を-1(AI記述)でダッシュステートをCtrl=0に、
Ctrl=1動作条件にダッシュステートを加えてるけど、
自分の場合Var使って終了条件そのものは-1で調整してる。
その方が細かい調整をしたい時に、一々そっちのファイル開かなくて済むから。
ちょっと特殊なのとしては、Ctrl=0の状態を「ダッシュの出始め数F」だけにして、
AIはCtrlのみのままで【ダッシュ開始直後に他の動作をできないようにする】ようなものもあるけど、
他の人はどんな具合で調整してるんだろうか。
74：MUGEN名無しさん：2011/09/23(金) 23:48:25 ID:cdMy6nIw: 色々考えてみたけどCtrl=0にするのが一番いいな。
75：MUGEN名無しさん：2011/09/26(月) 22:06:48 ID:TNRBPrp.: 学習機能つけている人いる？
76：MUGEN名無しさん：2011/09/27(火) 18:40:39 ID:nw0NZSmE: >>75
自分はガード中下段の記憶装置と対当て身投げの記憶装置を全部のAIにつけてる。
どっちもテンプレート使いまわせて対応も中下段は立ち屈み指定の切り替えて、
対当て身投げは状況判断Varで攻撃しないよう制御して終わり目を狙って攻撃する感じ。
ただそれら以外の細かいのはほどんど手を付けてない。面倒そうで。
77：MUGEN名無しさん：2011/09/29(木) 01:56:12 ID:nP7iLijo: 俺はガード不能とコンボ失敗と攻撃失敗の学習機能を付けている。
コンボ失敗は失敗したらそのコンボを使わないというもの
ガード不能と攻撃失敗は失敗直前の相手のStateNoを記憶して
次からその技を出された時は別の対応してる。
攻撃失敗（ジャンプとゲージ溜めも含んでる）はちょっと面倒だけど
記憶するプログラム書けば他のAIでも使えるし便利です。
ただ、自分のはVar一つで２つのStateNoしか記憶できないので
かなりVarを消費しました
78：MUGEN名無しさん：2011/09/30(金) 00:27:12 ID:BFrcSfE.: 敵攻撃f学習(未完成)、中下段学習、コンボルート失敗学習の３つかな
システム上コンボが安定しないキャラなもんで最後のは特別
普段は前者二つだけで済ませてる

今度は当て身用に、相手の攻撃判定の大きさ等をある程度測定、学習する
機能をつけたいんだが、厨忍氏のQ&A参考にしてもさっぱりわからん……
79：sage：2011/09/30(金) 05:13:21 ID:uiv.vhk.: >>78
厨忍氏のQ&A
攻撃が当たった時に相手のStateNoと距離と
攻撃開始してからの時間を記憶。
距離が長くなれば更新しているみたいだね
80：MUGEN名無しさん：2011/09/30(金) 08:59:19 ID:uiv.vhk.: >>78　厨忍氏のQ&A
varの偶数値にStateNo、奇数値に当たるまでの時間
fvarの偶数値に距離X、奇数値に距離Yを記憶している。
var(47)は順番に保存するためのカウンタ。
81：MUGEN名無しさん：2011/09/30(金) 14:55:12 ID:p7FsDtTE: ttp://homepage3.nifty.com/andil/mugen/AI_atemi.txt
前スレで話題が出たときに作ったヘルパーを使った当身投げ用の記憶装置。
2年前のなんで色々と型落ちしてるけど、参考になれば。
10個分(Var各4個)までの技しか記憶できないものの相手の攻撃に当たったら
相手のStateNo,Time,ID,相手とのX距離Y距離(本体が動いた分も補正),etcまで覚えて
複数の記憶からX距離の近しい方を参照するようにする機能も。
（突進系の技とかは相手との距離で命中するタイミングがずれるので）

実際の使い道ではシールド持ちキャラのAIへ、bitに改良してStateNo,Time,X距離、
ID,攻撃回数,失敗回数,直前のStateNo,直前のMoveTypeまで記憶させて
最大20個分の技を覚えられるようにしてるのを使ってる。(Var各2個)
今それを元にループ処理を加えて新しいAIに搭載準備中。

細かい調査が不要ならStateNo,Time,X距離の記憶だけでいいだろうけど。
攻撃の発生Fを認識させて色々と利用しちゃうと凶悪になるけどね。
相手の攻撃にあわせて始動無敵の技を重ねるとか。
82：MUGEN名無しさん：2011/10/01(土) 05:27:09 ID:nh/r5i2k: 飛び道具でループコンボをつくろうとして
trigger1=var(55):=var(55)+1
のような記述を入れてみたのですが数値が代入されません
勝手に初期化されたのか、トリガーの一番下にかいてあるのかいろいろ疑ってみたのですがやはり代入できません
打撃技だと問題なく代入されるのですが、飛び道具だとこの記述は使用できないのでしょうか？
83：MUGEN名無しさん：2011/10/01(土) 13:01:19 ID:8X3lUDWc: んなこたない
他のトリガーでミスってるんだろう
84：MUGEN名無しさん：2011/10/01(土) 13:58:25 ID:tEuzyBeY: >>82
代入のしくみが良く分らないならこれを見てみよう。
ttp://homepage3.nifty.com/andil/mugen/Var.txt
85：MUGEN名無しさん：2011/10/01(土) 15:03:43 ID:7rHsflRE: >>82
もしかしてtrigger1=var(55):=var(55)+1の前に「MoveHit,MoveContact」系のトリガーが入ってるんじゃないだろうか。
そうなら「攻撃があたった」という条件の為にMoveHitだとかにしたのかもしれないけど、
MoveHitとかは自身の攻撃しか認識できないので、飛び道具はHelper型ならHelper(*HelperID*),MoveHit=1だとか、
Projectille型ならProjHitTime(*projID*)=1だとかの参照方法で認識させる必要がある。
ただHelper側はMovetype=Aによる処理の前後でもしかしたらそれでも上手くいかない場合があるかも。

Helper型用でもっと確実なのは、Helperのステート側にParentVarAdd(親のvarに加算)をする加えるとか、
もしくは飛び道具を出すステート(始動用,ループ用両方)へのChangeStateをValue=**** +(var(55):=var(55)+1)*0にして、
相手の状態も条件にしてループするとかかな。Valueだとかの:=は「処理が行われる際に代入される」ので。
86：MUGEN名無しさん：2011/10/02(日) 04:37:47 ID:sUWrMYD6: >>84
を熟読してようやく解決できました

>>85
の解説も非常に参考になりました、お二人様ありがとうございました
87：inae：2011/10/02(日) 12:49:45 ID:8ADYXSVM: 主に以下のような感じで浮かせ技を作ろうと思っているのですが、
trigger1 = time = 16
trigger2 = time = 22
trigger3 = time = 30
animtype = Diagup
ground.velovity = -1.5,-8
air.velocity = -1.5,-8
fall = 1
空中の敵に当てると問題無いのですが、
地上の敵に当てると浮かずにダウンしてしまいます。
何が原因でしょうか？
88：MUGEN名無しさん：2011/10/02(日) 13:35:55 ID:794g7uFo: >>87
キャラ作成のスレで聞いて
89：MUGEN名無しさん：2011/10/02(日) 16:51:14 ID:794g7uFo: 質問です。helper(ID),～って相手のヘルパーも参照できるんですよね。
相手のヘルパーIDと重なった時は自分のヘルパーを参照するのですか？
90：MUGEN名無しさん：2011/10/02(日) 20:28:44 ID:H0U0Ivpk: >>89
Helper(ID),で他のキャラの出したヘルパーは参照できませんよ。
Helper,で参照できるのは自分が大本となっているヘルパー、
自分が出したヘルパーの他、そのヘルパーから射出したヘルパー(その子も可)などだけです。
なのでパートナーのHelperも同様に参照できません。安心してください。

ただ参照する方法がないのではなく、PlayerID(*ユニットID*),ならば敵味方関係なく参照できます。
そうした参照方法を多用して相手のヘルパーを探す場合、自分のヘルパーでないことも確認する必要があるのですが、
他のキャラが同キャラの場合は、PlayerID(xx),Name="xxxx"などが一緒になってしまう問題があります。
そこでPlayerID(xx),IsHelper(xx00+ID)という風な処理にすることで、確実な判断が可能になるわけです。
※ちなみにPlayerID(xx),TeamSide=TeamSideだけの判断では「パートナーの」と混同する可能性が出てきます。
（それ以外にもヘルパーのIDを記録して照合する方法もありますが、手間的にはHelperIDに+IDしてしまう方が圧倒的に楽）
そうした理由から射出するHelperIDに自身のIDもくっつけるという手法を用いている人たちがいるのでしょう。
私もそういうのCNSを覗いてHelperIDは重なるとマズいのかなと思ったわけですけど、
テスト用にいじってるKFMを使ってテストして調べて大丈夫だと確認しました。
91：MUGEN名無しさん：2011/10/03(月) 18:15:56 ID:YTHbDy/E: >>90
自分のヘルパーだけでしたか。
なら、持ち越さなくていい数値はヘルパーに管理させても問題なさそうですね。
詳しく説明していただきありがとうございます。
92：MUGEN名無しさん：2011/10/05(水) 07:53:33 ID:29s/I0cE: 記述がわかりやすくて参考にしやすい作者のAIなんてありますか？
93：MUGEN名無しさん：2011/10/05(水) 12:39:34 ID:xq0bvpUQ: どういうAIを作りたいのか、何を知りたい・何の参考にしたいのか、初心者かどうか
もう少し情報くれないとちょっと答えづらいな

デフォAIは基本的な記述でマイルドに作られることが多いし、初心者さんがAIに慣れるには良いかも
人それぞれ癖や好みがあるから、色々なAIを見るのが良いと思う
俺がぱっと思いつくのはPotS氏、GM氏、Gal129氏、rei氏、別府氏かな
94：MUGEN名無しさん：2011/10/05(水) 14:57:20 ID:29s/I0cE: 参考にしたいものはいろいろありますが、主に攻撃がヒットして浮いた敵まで走ってタイミングよく技を出して拾う、という一連の動作が知りたいです
今のところ平成㌢氏の説明書を参考にしてEnemyNear,vel yや時間調節用のvalue = 0などを使っていますが、
最初の浮かせる攻撃がヒットした時の打点が高すぎ・相手との距離が離れすぎて拾うタイミングがズレ、最悪の場合受身を取られて反撃されたり
相手によって体が小さい・重いなどの理由で追撃に失敗したりしてどうしても精度の悪さが気になります
それでよく作りこまれてる製作者のAIをのぞいてみたのですが、やはりそこはしっかりしてるようで
あまり馴染みのない記述がビッシリと書かれていて理解に苦しんでいるところです
95：MUGEN名無しさん：2011/10/05(水) 15:50:27 ID:xq0bvpUQ: ここで書くのは結構しんどいですねw
とりあえず大雑把にいきます

・重力計算をする
相手が重かろうが計算が正しければそんなに空振りません
地上コンボの場合は摩擦計算をお忘れなく

・追撃の種類を増やす、受身を取られる場合は追撃しない

・浮かせる攻撃を当てる際に追撃のことも考えておく
→浮かせる攻撃が当たる条件以外に当たった後の動きを予め計算し、
　受身可能時間となるまでに追撃範囲に入るかを計算する

・相手の喰らい判定の変化を考慮して計算する
→空中では足元が薄くなったり、絵に合わせて判定が動いたりします
　その分を考慮して余裕を持ったy方向のヒット条件を考えます
　立ち状態の腹～胸の高さは空中でも喰らい判定に入ってると予想して
　p2dist y（足元）にconst(size.mid.pos.y)を加えた位置を狙うようにする、など

「時間調節用のvalue = 0」とは０番ステートでしょうか？
立ちにせよ歩きにせよ、AI専用ステートにした方が管理が楽です

もう少し細かく、ということであれば捨てアドでも用意していただければ
96：MUGEN名無しさん：2011/10/05(水) 20:50:30 ID:29s/I0cE: 返事遅れてすみません、ご丁寧にまとめられていてとてもわかりやすいです
お言葉に甘えて、捨てアドの用意が出来ましたので記述の流れなんかを簡単に書いて頂けると助かります
mugenaisuteado@yahoo.co.jp
97：MUGEN名無しさん：2011/10/05(水) 22:47:01 ID:w3LoBL32: >>95-96
相手の吹き飛び中の当たり判定について零れ話を。メールの方では話してるかもしれませんが。
「吹き飛び状態」の時、相手の体は体の中心当たりを基準に「斜め～横」になりますが、
その時当たり判定の横は「衝突判定(Const(Size.Air.Front))」より広いが良くあります。
特に体の大きい相手は横にしても大きくはみ出すことが多いので、Const(Size.Head.Pos.Y)<-70くらいを目安に、
P2Dist X-Const(Size.***.Front)+Enemy,Const(Size.Mid.Pos.Y)/3程度、縮める計算をした方がいい場合もあるようです。
>>94のようなタイプだと大差ないかもしれませんが、吹き飛ばし直後に追撃するタイプの場合、
大きさの違いによる空中と地上の衝突判定の設定差のせいで追撃の判断に違いの出ることもありました。
（実際には当たるはずなのに、当たらなさそうな場合の判断をしてしまう、など。）
98：MUGEN名無しさん：2011/10/05(水) 22:52:32 ID:Ojx0C6.g: 相手の差は後回しにして
まず一つずつ調整するのが良い。
そんなにいっぺんに質問したら答えにくい・・
99：MUGEN名無しさん：2011/10/07(金) 19:54:24 ID:RAl2LVQw: >>94
自分が作っているAIはぶっ飛んだ相手を拾ってコンボするのが中心です
P2Bodydist XとP2Bodydist Yを使えば
ある程度は当たり判定が分ると思います。
あとはVel XとVel Y を使って相手が地面に落ちるまでの時間を計算して
相手を拾っています。
100：MUGEN名無しさん：2011/10/07(金) 20:20:55 ID:poxUzhlI: >>96
この間メールしたものです
あの後追記と訂正のメールを送ったのでメールチェックお願いします
101：MUGEN名無しさん：2011/10/13(木) 20:56:29 ID:LCa1Rrg2: アーマー感知ってどうやるんでしょうか？
102：MUGEN名無しさん：2011/10/16(日) 13:19:53 ID:ddy/BLhA: ヘルパーのID取得して、
それが相手にダメージを与えるヘルパーかそうでないヘルパーか
判断する方法ってありますか？
Movetype=A以外になにかありますかね？
103：MUGEN名無しさん：2011/10/17(月) 22:38:32 ID:FcHNB.JQ: 102　自己解決しました
104：MUGEN名無しさん：2011/10/20(木) 19:40:46 ID:rAfY..xw: 91だけどヘルパーが出せなかったら非常に困るのでやめます；；
105：MUGEN名無しさん：2011/10/21(金) 01:05:07 ID:1lZxIxbo: >>104
開幕に出しておくならHelper数が上限に引っかかって出せないって可能性は少ないですよ。
それこそHelperを占有する特殊な相手か、上限設定が極端に少ない場合くらいで、
どちらにせよ意図的に封じられなければ開幕にHelperが出せないってことはほぼ無いし、
意図的に封じているってことはまともに戦うような状態じゃありません。

開幕にHelperを出して常駐させて色々するってのは色んなAIでやってて、
AI動作の条件自体がHelper側で制御されてるものもありますので、
通常の対戦だけを考慮するなら開幕にHelper出して使うのは大丈夫かと。１、２個くらいなら。
106：MUGEN名無しさん：2011/10/21(金) 21:46:56 ID:aZsHFk2E: なるほど・・
開幕にヘルパー出せなくする相手の事まで考える必要はないんですね。
ありがとうございました
107：MUGEN名無しさん：2011/10/23(日) 18:38:10 ID:/LdUnZPo: 敵のProjの情報ってあまり取得できないのでしょうか？
敵のStateNoとProjが当たるまでの時間で位置が分るくらいかな？
Projってだいたい等速だよね？
108：MUGEN名無しさん：2011/10/25(火) 01:15:29 ID:EKMY.lIA: >>107
自分のProj情報も射出点を記憶して計算させないと分からないくらいだから
Projを正確に感知するのはP2Name使っても難しいんじゃないかな。

>>81のやつのような要領で開始からの位置を細かく記憶させても、
飛び道具の大半は等速とはいえ、一応Projは速度係数や加速度も設定できるし、
特殊な使い方をしてる場合(アーマー時の攻撃判定とか2FProjとか)もあるんで
単純に計算させるとAIが見誤っちゃう可能性があって、難しいと思う。
（っていうか基本的な飛び道具の処理はHelperでするのが主流になっちゃってますし、
特殊な処理にしか使われてないんじゃなかろうか。）

ただ単純単体のProj飛び道具ならProj射出中本体のGuard.Distが無くなる仕様だとかを考えて、
HelperでInGuardDistの範囲を感知し続けて計算してX座標の位置くらいならいくらか分かるかも。
でも２個以上出されてたりHelperのGuard.Distが重なってたり、処理が特殊だと上手く感知できないけど。
109：MUGEN名無しさん：2011/10/28(金) 01:54:16 ID:.2F19OAU: >>108
ありがとうございます。InGuardDistは使えそうですね。
これを使って色々試してみます。
110：MUGEN名無しさん：2011/10/30(日) 23:24:36 ID:dyHFN2fA: 攻撃を食らった時に何の攻撃に当たったか分かりますか？
飛び道具とか敵が2人いた時にどっちの攻撃に当たったかとか
111：MUGEN名無しさん：2011/10/31(月) 18:35:04 ID:BuBzDPxg: 攻撃を当てるとP２トリガーの対象が攻撃当てた相手になった気がするんで
enemy,movecontact
enemy,p2stateno=stateno
enemy,p2movetype=H
enemy,p2dist x=(pos x-enemy,pos x)*enemy,facing
とかで判別できないかな？
味方が同時ヒット喰らってるとダメそうなので
自分と味方のgethitvar系の数値を比較するといいのかも

同様のやり方でヘルパー飛び道具についても推察できると思うので
精度は敵の相方やヘルパーについての情報と重ね合わせて上げて頂くってことで

それと多段ヒットする飛び道具はmovecontactが立つと思うんだけど
単発物はヒットしてすぐに消滅ステートに入ってmovecontactが判別に使えないケースが
その場合は飛び道具と判定したIDのmovetype=Iをmovecontactの代わりにしたりでどうにか
112：MUGEN名無しさん：2011/10/31(月) 22:46:01 ID:QqE6sQR2: ヒットと同時に消えるタイプのHelper飛び道具のヒット認識について気づいたこと。
キャラの処理順はMovetype=Aが先に処理されるのでMoveContactでステート移行or消滅するタイプは、
本体からだと自分のMovetypeがA(攻撃中)でないと先に動かれるからMoveContact認識できないけど、
一番最初に出しておいたMovetype=AのHelperからなら、MoveCotnactの処理をする前に認識できるかも。

処理はMovetype=Aのユニットから＋IDの若い順なので、
早めに出してMovetype=Aにしておけば後から出したMovetype=AのHelperよりも早く処理ができるので、
その処理位置なら確実にHelperの処理を認識できるんじゃなかろうか。
ただ本体と認識用Helperの処理関係の管理とか、HelperをGuard.Dist=0にするとか面倒だけど。
113：MUGEN名無しさん：2011/11/05(土) 00:04:50 ID:XkIKGzk.: やっぱ色々面倒なんですね・・
ありがとうございます。
114：MUGEN名無しさん：2011/11/12(土) 10:43:03 ID:UQkZ.Wuk: Fvarの仕組みが分る人いますか？
９９９９９９９（7桁）までは安定するという事だけわかっています。
確かにこれ以上大きくすると不安定になるけど
キャラによって狂いだす値が違うし意味が分らない
しかも安定７桁というのが１０進数だし・・
fvarの上位ビットが小数点の位置情報と思ったけど違うみたいだ・・

とりあえず23bit(最大8388607)まではビット演算で使っていますが
この範囲ならビット演算でも正確な数値を返しますかね？
fvarにビット演算しない方がいいって事はないですよね？
115：MUGEN名無しさん：2011/11/14(月) 00:27:41 ID:CRpzGU6Q: >>114
自己解決。
仕組みまでは分らないけどビット演算やっても問題ないね
116：MUGEN名無しさん：2011/11/14(月) 03:04:03 ID:CRpzGU6Q: >>112について調べてみた
処理順は
キャラとヘルパーが全員Movetype=Iだったら↓
P1→P2→ヘルパー（早く出現したものから）
だけど、Movetype=Aが先に処理されるんだよね↓
P2(A)→ヘルパー(A)→P1(!A)→ヘルパー(!A)→ヒット判定
ヒットによって自分がMovetype=Hになるのはヒット判定処理時。
HitDefやHitOverrideによるステート移行はヒット判定処理時。
ヒットした瞬間に消えるヘルパーは
ヒット判定処理時にMoveCotnactになり、
もう一度自分に処理が回ってきた時にMoveCotnactを認識して消滅するタイプと、
ヒット判定処理時にHitdefでステート移行してそのまま消滅するタイプがある。
これであってますかね？
117：MUGEN名無しさん：2011/11/14(月) 13:08:45 ID:Hnu3iuX.: 処理順について細かいこというとIDの順(出現順)というよりメモリの並び順(デバッグの表示順と同じ)だった気がする
本体同士ならID順で安定だと思うけど、ヘルパーだと出入りがあるためそうとは限らない

A B C　順に生まれた三つのヘルパーがあり、左から処理しているとする(IDも左が若い
A C　Bがdestroyselfすると真ん中のメモリが空き家となる
A D C　その状況で生まれた新しいヘルパーDは空き家に入り込んでCより先に処理される

この場合はIDの大きいDがCより先に処理される
DがCの子だったりすると最初のフレームだけ順番が違ってくるだろうけどね

早期にmovetype=Aのヘルパーを出すとしても
>>112のように後から出たmovetype=Aのヘルパーより先に処理されるかは
一番若いアドレスのヘルパーでないと保証されないと思う
P1最速(もしくは消さないヘルパーの後)で出すか、他にヘルパーが存在しない状況で出さないと穴ができるんじゃないかな
118：MUGEN名無しさん：2011/11/14(月) 22:23:34 ID:CRpzGU6Q: >>117
ありがとうございます
119：MUGEN名無しさん：2011/11/19(土) 23:02:54 ID:T7BaVEXI: >>117　今更だけど
IDの若い順じゃなくて、書いてある通りユニット番号の若い順だってこと忘れてました。
開始直後であっても。それが起きる状況としては、
2P側以降であり＋1P本体から一時Helperが射出されていることで、現実的には
１．開始と同時にイントロ演出などのHelperの射出→退場による空き発生
２．AI用の画面端認識の一時処理Helperなどが本体側から射出されている
という場合が考えられる、のかな。１はかなり多くても、２は少ないと思いたい。
イントロを飛ばした場合は一旦リセットされるので細かい演出が無ければほぼ穴は発生しないかな。

とにかく確認したい場合はまず、「開始直後(RoundState=0)に射出」しておいて、
定期的に新しいHelperを出して、ParentVarAddとParent,Var(xx)で
処理の順番を確認してより遅い方を消失させてしまう、といった方法なら、
時間がかかるかもしれないけど、ある程度確実に配置できるかも。

確認には本体がVarSetで指定のリセットして、
確認用のMoveType=AのHelperに(Time>0で)、本体のVarを確認してParentVarAddする。
次のMoveType=AのHelperから同様に本体のVarを確認して、!=0ならDestroySelfをする。
といった感じかな。互いに本体の認識をするだけだけど、
HelperIDは念のために別々にしておいた方が記述は面倒だけど参照に不備が出なくて済むかと。
120：MUGEN名無しさん：2011/12/03(土) 00:42:40 ID:j/6ElHu2: >>119
詳しく説明していただきありがとうございます
121：MUGEN名無しさん：2011/12/12(月) 03:27:14 ID:CcCdOtQM: 厨忍氏のサイトにある技のステート、発生、距離を記憶する記述を参考にしてAIに組み込んだのですが、
正常に動作はしているものの
TRIED TO ACCESS NON-EXISTEN PLAYER WITH ID～
というエラメが画面左上に流れ出しました。
変数や記述に間違いがないか確認しているのですが中々解決できず、
またPlayerIDExist(○)の記述を足したらエラメ自体は消えたものの、
今度は正常に動作せず相手の技を記憶してくれなくなりました。
どなたか解決方法を知りませんか？
122：MUGEN名無しさん：2011/12/13(火) 15:42:12 ID:WUzWsfzI: 記述のせてくれなきゃなんとも
123：MUGEN名無しさん：2011/12/14(水) 04:22:17 ID:0E7LpZMk: >>121
自己解決しました。失礼しました
124：MUGEN名無しさん：2011/12/15(木) 05:58:56 ID:reZ3E8uo: 落下して何F後に地面に落ちるか計算したいのですがよく分りません。
必要な数値はPos Y , Vel Y , 1F毎に増加するVel Yの値・・かな？
1F毎に増加するVel Yの値はVel Yを監視しておけば分るかな。
何F後にPos Yが0になるかを計算したいです。
私が考えた式は (1F毎に増加するVel Yの値⇒VelAddY　とする)
0 = PosY - (VelY + VelAddY*F) *F　(Fを求めたい)
となったのですがあってますかね？
125：MUGEN名無しさん：2011/12/15(木) 16:26:46 ID:reZ3E8uo: >>124
自己解決しました。
0 = PosY - (VelY + VelAddY*F) *Fではなく
0 = PosY + (VelY + VelAddY*F) *Fでした。
126：MUGEN名無しさん：2011/12/23(金) 01:46:49 ID:zLj8D4MM: 聞きたいんだけど
キャラ本体の作者さんにAIの制作許可もらうのってAI作り始める前に作者さんに聞きに行ってる？
AI作ってからそれを見せてこんなん作ったけど公開していいですか、って聞いてる？
前者のほうがAI作る側としては助かるけど、演出とか性能のちょっとした改変もしたいってのがあって
でも相手が海外の人だからそのへんの細かいニュアンスとか俺の英語の文章力じゃ伝えられん･･･
127：MUGEN名無しさん：2011/12/25(日) 23:22:36 ID:wmc0zwyg: 自分はある程度製作して、公開が実現できそうになったら連絡してる。
その際、近日公開したいと思っているということ、作者さんが作成・公開自由
という旨をおっしゃっていない限り公開して大丈夫かということ、他気になる点
(改変/調整等)を聞く感じ。
一応、必要であれば現状のAI実物をお渡しします、って付け加えてる。

公開ダメって言われたら素直に諦めます。
あと英語は俺にも無理じゃ。自分でベンキョーするか、エキサイト先生に頼むか
野生の英会話塾に頼んでくだされ。
128：MUGEN名無しさん：2011/12/26(月) 01:23:25 ID:cBs9S0HU: ステージのtensionの値を判断する事は出来ますか？
129：MUGEN名無しさん：2011/12/27(火) 02:53:59 ID:usaEIaM.: >>127
そっかーありがとう
やっぱある程度見せられる物は用意しといたほうがいいかもね
まあでもいきなり実物送りつけて見てくれってのもぶしつけだわな
まずはメールで理解してもらえるよう頑張るわｗ
130：MUGEN名無しさん：2012/01/06(金) 17:19:14 ID:c2s/zTf6: すみません、初めてAIを製作していまして、
飛び道具を感知してグレイズするために、まず
「試合開始直後の敵ヘルパー数」を変数に記憶させている（つもり）
なのですが上手くいきません。
何が問題でしょうか。

;敵ヘルパー式飛び道具感知
[State -2,ヘルパー式飛び道具感知用]
type = VarSet
trigger1=RoundState=2
trigger1 = GameTime <= 1
var(57) = EnemyNear,NumHelper
131：MUGEN名無しさん：2012/01/07(土) 02:36:55 ID:qjrBKcrA: >130
GametimeってRoundState=2からじゃなくて
RoundState=1から進んでるから条件に入らないからかな。
var(57)=0のときのみ代入するとかそっちのほうが分かりやすいと思うよ。

間違ってたらごめんね。
132：MUGEN名無しさん：2012/01/07(土) 03:20:32 ID:nMaqr.iM: >>130
GameTimeは「mugenを起動してからの試合画面のフレーム数」なので、
試合開始前だけでなく、前の試合も含めたGameTimeになってるはずです。
開始時のヘルパーの数を安定して取得したいなら、>>131の方も言ってるように、
Trigger1=RoundState=2&&Var(57)=0;とかいう感じで代入する方が分かりやすいと思う。

ただ開始時のヘルパー数を確認するだけじゃ「エフェクト」か「飛び道具」か判別つかないから厳しいような。
それこそ相手のヘルパーをPlayerIDで参照して確認するとかそういう技術と併用しないと…

一番簡易的な飛び道具認識としては
「P2Movetype!=A&&InGuardDist（相手が攻撃でない＋ガード可能範囲＝飛び道具かも）」っていうのがありますよ。
あとは難しいけどAI用にヘルパーを出してInGuardDistの位置と相手の位置を確かめて判断するって方法とか。
133：130：2012/01/07(土) 10:00:07 ID:bsP51QvM: >>131,>>132
お二方、ありがとうございます。
なるほど…GameTimeはそういうものだったんですか。
まさかデバッグで１番最初に出ている奴だったとは…この海のry

・「var(57)=0のときのみ代入」
この方法で無事に記憶させることが出来ました。
ありがとうございます！

・「エフェクト」か「飛び道具」か判別つかないから厳しい
エフェクトはExplodで作るもの！！(ｷﾘｯ

・「P2Movetype!=A&&InGuardDist」
そのアイデア頂きました！

とりあえずはイメージどおりに動いてくれているので、
更なる強化が必要になったらリダイレクトな方向に作ってみます。

これで、
「キャラをDLして魅力に気付き、AIを作ろうと思ったらすでにキャラ対で脱落していた
な、何を言っているかry」
という悔しさを晴らすことが出来ます。
ありがとうございました！
134：MUGEN名無しさん：2012/01/08(日) 01:42:33 ID:.WxKxK1Q: >>132
GameTimeは起動の時間を表してたのか、勘違いしてた。
補足含めて色々ありがとう。
135：MUGEN名無しさん：2012/01/09(月) 19:21:12 ID:bYWWkTjk: 自分は飛び道具？ってやつはenemy,hitdefattrとInguarddistでやってるなぁ
それと予め自分の90ドットくらい前に常駐helper置いといて

trigger=enemy,movetype=A
trigger=!enemy,hitdeattr=SCA(飛び道具はhelper等にhitdefが付いて本体には無い)
trigger=!inguarddist
trigger=numhelper(#####)
trigger=helper(#####),inguarddist

って感じにしてる。これなら近すぎる飛び道具に反応しちゃう事もないし
Explodとかで判別すると飛び道具見てから飛び込むけど、出る前に既に飛び込んでる、
ってのが個人的に理想だから
これにその他変数等入れて精度とか判別手段増やしてる

正直欠陥だらけなんだけど、意外なほど機能してる現状
まぁ一番はやっぱ相手のhelper情報取得しちゃう事なんだけどね
136：MUGEN名無しさん：2012/01/09(月) 20:26:18 ID:tYIA7OOE: 自分は>>132の最後に言ってたHelperのInGuardDist位置と相手の位置を比べるのを使ってる。
自分の前の+50,100,150,200のInGuardDistをHelperのVarに代入して、
50のInGuardDistが真で100が偽＋相手が100より遠い　＝　相手本体のGuardDist以外がある？
みたいな感じに、100真・150偽＋150より遠い、150真・200偽＋200より遠いって並べてる。

ただこの場合「タッグ戦で挟まれている場合」も、反応しちゃうし、
相変わらず打撃判定とかの飛び道具やら分身やらは認識できないんだけど。
137：MUGEN名無しさん：2012/01/13(金) 00:22:02 ID:GQSUZEZw: >>136
それってヘルパー4つ使ってるの？
138：MUGEN名無しさん：2012/01/15(日) 00:28:44 ID:n88hnp4E: >>137
一つだよ。HelperをPosSetとTurnで本体に座標と向きを合せて、
PosAddでX=50した直ぐ下でInGuardDistをVarに代入×４回。
本体からは、Helper(xx),Var(x1)=x&&Helper(xx),Var(x2)!=xという感じで判断。
（実際の記述はbit演算なので、一つのVarで済ませてるけどイメージはそれと一緒。）

Vel系は「そのユニット(本体/ヘルパー両方)の処理の終わった時点」で座標が動くけど、
Pos系は「その処理が行われた時点」で内部的な座標が動いてる。んでもって、
InGuardDistは「現座標で相手のGuard.Dist(Attack.Dist)内にいるかどうか」の情報なので、
最中にPosが動いていればその動いた先でのInGuardDistの判定を返してくれるのよ。
なので、Helperは一つで十分。

問題としてHelperをMovetype=A(+Attack.Dist=0)にしないと情報が常時1F遅れる。
（mugenの仕様でMovetype=Aだと処理が先になる→本体がMovetype!=Aの時はそのフレームでのInGuardDistを教えてくれる。
そういう情報は1F遅れても大差無いので、自分は気にせずMoveType=Iで処理させてるけど。）
139：MUGEN名無しさん：2012/01/15(日) 04:21:34 ID:OjXEphOs: >>138
ありがとうm(_ _)m
１Fで何回でも移動できたのか・・・
最後のPosSet,PosAddしか見ないのかと勘違いしていた
つまり、PosAdd x=1(-1)の命令を書きまくったら
飛び道具の動きに合わせてヘルパーを移動させる事もできるね(Guard.Dist(Attack.Dist)の数値分離れるけど)
Projの監視は諦めていたけどXの位置と速度はある程度分りそう
古いゲームキャラとかはProjをよく使ったりするから対策しておきたかった
自分が作っているAIのキャラは近づけないと何もできないから・・・
いい情報、感謝。
140：MUGEN名無しさん：2012/01/17(火) 22:49:44 ID:HHH2xls6: >>139
実際にやるとしたらPossetでX=170に動かして、var(x1),var(x2)を0にしてから
[Statedef xx020]
type=s

[state xx020, posadd]
type = posadd
trigger1 = 1
x = -1

[state xx020, posadd]
type = varset
Trigger1 = InGuardDist
trigger1 = var(x1) = 0 && var(x2) = 0
var(x1) = floor(Pos X)

[state xx020, posadd]
type = varset
Trigger1 = !InGuardDist
trigger1 = var(x1) && var(x2) = 0
var(x2) = floor(Pos X)

[state xx020, changestate loop];ループ処理
type = changestate
trigger1 = pos X > -170 ;画面の反対端-10に到達していない
value = xx020

[state xx020, changestate];ループ処理後
type = changestate
trigger1 = 1
value = xx000 ;戻す
みたいなループ記述で処理させないと記述量が大変になるけど。
見比べたい場合は前Fのx1,x2は別のvarへ移しておく感じね。

あとProjについて補足ですが、「Projを射出している最中は本体からのAttackDistが出ない」みたいです。
InGuardDistの範囲を監視して、移動方向とかを認識する場合、
Helperの飛び道具だと相手本体からのAttackDistが重なるので調べ切れない部分が出ますが、
Projの飛び道具だと基本的にそれが無くなるので、比較的調査しやすいかも。
141：MUGEN名無しさん：2012/01/18(水) 18:59:46 ID:iORmuHpQ: >>140
なるほど、ありがとうございます。（わざわざ例を書いてくれて・・）
changestateで1F何回でもループできるの初めて知った・・
これで自分のAIの容量がだいぶ減らす事が出来そうです。
やっぱHelperやProjに関してはまだまだ初心者だ・・

Helperの飛び道具監視はPlayerIDでやってます。
ちょっと気になる点がありますが、
「Projを射出している最中は本体からのAttackDistが出ない」
というのはMovetype=Aになっていない場合ですかね？
Movetype=AのステートでProj出す時はAttackDist出ますよね？
142：MUGEN名無しさん：2012/01/18(水) 23:25:43 ID:hI8DKtHo: >>141
Proj射出中の本体のAttack.Dist＞MoveType=Aでも出ないんです。
Proj自体からAttack.Distが出てるので普通困ることはないのですが、
Projを飛び越したりくぐったりした後、Projが消える前に相手の攻撃に対してレバーを後ろに倒すと、
通常ならガードする範囲でも、ガードモーションにならず、後ろ歩きになってしまうんですよ。
（Ctrl=1でCommand="holdback"の状態なら、ガードステートで待機してなくても、攻撃を食らった際にガードしますけど。）

ちなみにステートのループについては「2500回」が限度で、
それ以上のChangeState処理をするとエラーでMUGENが落ちちゃいます。
（　１つの本体orヘルパーが、１フレーム中に、2500回です。
複数のヘルパーが2000回以上処理してても、一つのキャラで2500回を超えてないと落ちないはず。　）
ループ処理のミス以外でループ上限に引っかかってMUGENが落ちるのは余程ループさせてないとなりませんけど。
143：MUGEN名無しさん：2012/01/19(木) 00:21:44 ID:syi1YjrU: >>140
>>135の人間だけど、自分もすっげーべんきょーになった
やっぱある程度できて面倒になったから、ってのはダメだな
試行錯誤に終わりはない。上に上に目標立てねば
正直未だに1F内でそういったことが順番に行われているっていうイメージが
掴めなくて、なかなか理解しきれんのだけど、頑張って見よう。うん

>>141
>>142の人も言ってるけど、基本的に飛び道具ってのはProjないしHelperにHitdef
およびAttack.distがついて、本体からはMovetypeに関わらずなにも出ていない…はず
144：MUGEN名無しさん：2012/01/19(木) 02:21:26 ID:B71Qe7t6: >>142
試しにテストしてみたけど
どうやら新MugenだとAttack.Distが出るみたいです。
旧MugenだとAttack.Distは出ませんでした。

2500回ですね。分りました。
改めて処理速度の速さに驚いた。
145：MUGEN名無しさん：2012/01/19(木) 03:05:04 ID:IKdgut2o: >>144
あー新Mugenでは確かめてませんでした。自分、旧mugenしか使ってないので；
新mugenではProj出してる間でも出てるようになってるのかぁ…。
146：MUGEN名無しさん：2012/01/24(火) 00:43:16 ID:uMwmBXZ2: 飛び道具どころか出の早い通常攻撃もガードしてくれないぜ！www

それはさておき、
いつの間にか空中に立つバグが発生するようになってしまいましたorz
地面にめり込んだりもします。グギギ…

AIを書いてるステートのstatetypeは調べたんですが…
何か心当たりのある方は御教授ください。
147：MUGEN名無しさん：2012/01/24(火) 11:45:13 ID:QOn/U3S6: >>146
>空中立ち
空中立ちの主な原因はStateType!=A/=Aの間違いだけど、
空中立ち＋めり込みとなるとガードステート記述の間違いかも。
ガード動作から空中で立ったり、めり込んだりしてる場合はそれです。
ガードの中下段切り替え用に、State,140や120からStatetype=A状態からでも
StateType=CやSへ切り替えたり、地上ガードにChangeStateするようになっちゃってると両方起こる。
（空中で地上ガード→空中立ち状態　落下中に地上ガード→落下速度はそのままで地面より下へめり込む）
昔やらかしたそれくらいしか心当たりないんで、それ以外は分からないけど。

>出の早い～
動作の確率が高すぎて刺さっちゃってるんじゃないかな。
相手の動作が遅い場合は反対に差し込めてるけど、相手の方が早いと食らってるとか。
動作に!InGuardDist挟んで動作を制限するとガードしやすくなるかも。ただし完全制限はオススメできないんで
TriggerAll = !InGuardDist || Random < 200 ;とかみたいにある程度の確率で動作もする感じで。
148：146：2012/01/26(木) 01:40:02 ID:xRfW9x4c: >>147
情報ありがとうございます。
コマ送りで調べてみたところ、まさしくガードステートでした。
無事バグを消すことに成功しました。

出の早い技についてですが、確率を下げたところ、上手い具合になってきました。
が、一番防ぎたい技は上手く防げない…
何でかと思ってその技のCNSを見たら、
飛び道具でしたよwww　エフェクトかと思ってたよ、チクショウww

ここの所話されている対飛び道具記述で頑張ってみます。
ありがとうございました。

AI製作関係スレ その２