|   |  次のページ

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ステートの処理順

7/28
22:34 (N-Fox) ちょっと質問ですが、ヘルパーステ固定記述の上にがめちめ抜け記述突っ込んだりしたらステ固定が働かなくなったりするんでしょうか
22:35 (N-Fox) どうも自分の混線に自分のヘルパーが取られてる感じになっててやや困り気味なのです
22:37 (YANMAR) しますねぇ
22:37 (YANMAR) ステコンってのは上から下へ、って処理なので
22:37 (_609z) self,changeは実行するとそれより下が実行できない
22:37 (YANMAR) 下に書かれた奴で上書きされるので、条件次第ではがめちめが優先しちゃいます
22:38 (YANMAR) じゃなかった、きゅーずさんの言う通りで
22:38 (YANMAR) ステ抜けした時点でー2だろうが読み込まないので、書き順が重要なのです
22:38 (YANMAR) 一般的にヘルパー固定はがめちめより上に書いた方が良いです
22:39 (N-Fox) 例えばですけど、selfだけどtriggerallでishelper(xxxx)指定されてた場合
22:39 (N-Fox) その下にある!ishelperやishelper(yyyy)のselfは影響を受けなかったりする感じです?
22:39 (YANMAR) いえ、そのトリガーの順番じゃなく
22:39 (YANMAR) ステコンの順番っすね
22:40 (YANMAR) [State -2, gametime式ステ抜け]
22:40 (YANMAR) type = Selfstate
22:40 (YANMAR) trigger1 = sysvar(0) != gametime
22:40 (YANMAR) value = 40
22:40 (YANMAR) ignorehitpause = 1
22:40 (YANMAR) [State -2, 被弾用ステ固定]
22:40 (YANMAR) type = Selfstate
22:40 (YANMAR) trigger1 = ishelper(130)
22:40 (YANMAR) value = 130
22:40 (YANMAR) ignorehitpause = 1
22:40 (YANMAR) 例えばー2にこの順番で書かれてた場合、優先するのはがめちめの方です
22:41 (N-Fox) ほむ
22:41 (_609z) 極端な例だと
22:41 (_609z) [state -2, ]
22:41 (_609z) type = selfstate
22:41 (_609z) trigger1 = ishelper
22:41 (_609z) value = xxxx
22:41 (_609z) ignorehitpause = 1
22:41 (_609z) [state -2, ]
22:41 (_609z) type = varadd
22:41 (_609z) trigger1 = ishelper
22:41 (_609z) var(0) = 1
22:41 (_609z) ignorehitpause = 1
22:41 (_609z) こうするとしたのvaraddは実行できない
22:42 (N-Fox) なるほど・・・・
22:42 (YANMAR) なので、良くも悪くもって感じですかね
22:42 (YANMAR) 先にヘルパーを固定してステ抜けさせておけば
22:42 (YANMAR) 本体用のー2処理とかさせずに済むので動作が軽くなったりも
22:43 (YANMAR) 混線やトムキラーが動かないって時は
22:43 (YANMAR) 大抵本体の無敵やアーマーを読み込んじゃってる時かな
22:43 (N-Fox) ishelper(xxxx)のselfstateとishelper(yyyy)のselfstateならお互いに影響を与える(下にある方が読み込まれない)ことはないです?
22:44 (YANMAR) 同じトリガーなら上が実行されて、下が読み込まれないという処理に
22:44 (N-Fox) わかりましたです
22:45 (YANMAR) なので-2、-3をチェキ
22:45 (N-Fox) とりあえず、がめちめ抜け記述をstatedef -3手前の一番下まで降ろしとけば大丈夫か
22:45 (YANMAR) -3>-2>-1>個別って処理順なので、その辺りも
22:45 (YANMAR) んですな、がめちめは基本的にしたに
22:45 (YANMAR) 本体用の常時監視も下に
22:47 (N-Fox) ということは
22:48 (N-Fox) ヘルパー用常時監視(即死ステ取得変数など)→ヘルパー固定→本体用常時監視→がめちめ抜け みたいな並びにしちゃえばよさそうですか
22:49 (YANMAR) ですです
22:49 (YANMAR) そのヘルパーにやらせたいことがあったら
22:49 (YANMAR) ステ固定より上に置かないと駄目なんす
22:51 (N-Fox) わかりました、ありがとうございます
22:52 (YANMAR) 常時監視の処理順は誰しも通る道なので仕方無いと思うw
22:52 (N-Fox) 混線でアーマー貫通砲してたら、一度自分のアマ貫で自殺したでござる
22:52 (YANMAR) 混線は全範囲だからのぅw
22:54 (_609z) タゲステno
22:55 (_609z) のtiggerにtriggerall = target,teamside != teamsideを入れたら
22:58 (N-Fox) とりあえず、今は孫ヘルパー使ってないから
22:58 (N-Fox) root,nameで自分を弾いてなんとかしてる
22:59 (YANMAR) 弾き方はいろいろっすなぁ
22:59 (YANMAR) 混線耐性って言っても色々あるしのぅ、アマ砲食らうならhitby消すとか
23:00 (_609z) hitby、不完全nothitby削除でなんとかなる
23:00 (YANMAR) hitfalldamageも消す
23:00 (YANMAR) lifesetはnameのお守りか、その直前にname指定セルフで抜けるとか
23:00 (_609z) ヘルパー奪われないようにするのが一番やけどな
23:01 (YANMAR) ヘルパー押し付けまで想定するなら本体保護とかだけど、基本的にヘルパーステ抜けが鉄板
23:01 (YANMAR) p2getp1state当身とか考慮するとやっぱり本体保護が一番ではある
23:03 (YANMAR) 特にがめちめは鉄板じゃないからのぅ
スポンサーサイト

タッグ戦でのライフ、パワー最大値

6/1
21:43 (_609z) 雷神とのタッグ戦のときの都古ちゃん何があったんだろうな
21:43 (YANMAR) あれは相手側が何かしてたと思う
21:44 (YANMAR) 常時タゲライフ食らってたし、タゲステかも
21:44 (_609z) タゲステ耐性あるんだけどなー。アニメ式ステ抜けしてるし
21:44 (_609z) なんか穴があるのかな
21:45 (YANMAR) やり方次第で抜け先が40とかだとああなりそう
21:45 (YANMAR) あまりにも常時だと挙動おかしくなるからのぅ、死なないだけで
21:45 (_609z) 悔しいのう
21:45 (YANMAR) タッグは恐ろしいんや…
21:46 (_609z) タッグ特有のバグとかあるしなー
21:46 (_609z) やっほい
21:46 (YANMAR) Lifemaxが半減するのが一番困る
21:47 (emeru) それが怖くてLifeMax値の割合でライフ減らしてる←
21:48 (_609z) 都古ちゃん設定によっては自爆しそうだな
21:50 (emeru) タッグの時ってpowermax値ってどうなんだろーね
21:50 (_609z) 先頭のキャラの値だったはず
21:50 (emeru) あー・・やはりそうなるのかぁ・・
21:50 (YANMAR) それもこまるんるん

着地するタイミング

5/29
21:06 (Ryusei) 着地するタイミング、(Vel Y+Const(movement.yaccel ) > 0 && ( Pos Y + Vel Y )>=0 )じゃないと合わないのか
21:16 (Ryusei) Pos y >= 0 && vel y > 0 だとずっと思い込んでた((

リンク1:着地処理[lunaの倉庫]
リンク2:着地するタイミング[MUGEN神キャラ置き場]

当たっているはずのprojのprojcontacttimeが-1になる

4/25-26
22:58 (Oracle) 当たっているはずのprojのprojcontacttimeが-1になる要因って何があるかなあ
23:03 (Ryusei_) 攻撃での消滅などのリセットがなければ命中後ずっと感知らしい
23:06 (Oracle) projremove=1だけど-1になるときとならん時があるのよね。
23:08 (Ryusei_) いっぱいだしてるとかは・・・ないか
23:09 (Oracle) 一個なんよねー
23:09 (Oracle) カウンタがリセットされる要素もないしなー・・・
23:10 (Ryusei_) 0にしたらどうなん
23:10 (Ryusei_) projremove
23:11 (Ryusei_) ヒットして消失したせいでリセットされてるのかもしれないし
23:11 (Oracle) それだと絶対に成功しないんだよねー
23:11 (Oracle) 成功するときとしないときがあるってのが一番の謎なんだ
23:12 (Ryusei_) ふーむ
23:17 (Ryusei_) http://31kei.blog88.fc2.com/blog-entry-792.html
23:17 (vesper) [URL] 境界の影projcontacttime
23:18 (Oracle) ほむほーむ
23:18 (Oracle) ほむ。
23:18 (Ryusei_) http://chiku2gonzalez.hatenablog.com/entry/20110213/1297601051
23:18 (vesper) [URL] Proj*Time系トリガーの怪 - chikuchikugonzalezの雑記帳
23:18 (Ryusei_) http://ameblo.jp/insanity-blue/entry-10883746129.html
23:18 (vesper) [URL] projcontacttimeの仕様|カオスな雑談
23:19 (Ryusei_) 役に立つかどうか分からないけど 貼ってみた
23:21 (Oracle) 多分解決できそう
23:21 (Ryusei_) やったね!
23:23 (Oracle) やったよ!
23:25 (Oracle) ありがとうりゅうせいちゃん!
23:27 (Ryusei_) いったい何が原因だったんだろう
23:36 (Oracle) しょーじきよくわかんない
23:36 (Oracle) projcontacttimeの射程を[-1,1]に直しただけだからなー
23:39 (Oracle) ひとつは敵本体のprojが私の二つ目の被弾ヘルパーに当たってることかなー
23:40 (Oracle) 敵本体のprojは優先度が高いのかも
23:41 (Oracle) そうだとすれば、ヘルパーproj被弾、projcontacttime1、本体proj被弾、projcontacttime=-1になるんだよねー
23:41 (Oracle) というか多分そう。どうしようもない(
23:42 (Oracle) ああ、違うごめん
23:45 (Ryusei_) ふむ
23:46 (Oracle) えーとさ
23:47 (Oracle) 多分だけど、projcontacttimeって、他のprojがヒットすると-1になったりするよね?
23:47 (Ryusei_) IDが一緒なら
23:47 (Oracle) えー
23:48 (Oracle) ID一緒じゃなくてもおきないのかー・・・
23:49 (Ryusei_) あんま仕様はようしらないんや( projようわからんことおおいし
23:50 (Oracle) 多分これなんだよなあ・・・
23:51 (Oracle) SAIKEI氏のブログのが答えだと思う
23:51 (Ryusei_) ふむ
23:52 (Oracle) 複数のproj同時ヒット時に-1になる現象
23:52 (Oracle) 同じヘルパーにヒットしてるなら、多分後ろに出したprojが優先される
23:52 (Oracle) でもこれが異なるヘルパーに当たってた場合、後ろにいるヘルパーの状態が優先される
23:53 (Ryusei_) めんどくさい仕様だな
23:53 (Oracle) 前のヘルパーにミラージュ式のprojが被弾、その後その後ろにいるヘルパーに相手のprojが被弾。その結果ミラージュ式で出したprojのprojcontacttimeが-1になったんだろう
23:54 (Oracle) これ被弾なくしゃ問題ねーんだが
23:54 (Oracle) アノマロやってるから被弾消したらあかんのじゃ。
23:54 (Ryusei_) hitにしても結局は同じか
23:55 (Oracle) 全部-1だろうね
23:55 (Oracle) projのパラメータも地味にクソ面倒な仕様じゃからのう
23:56 (Ryusei_) (´;ω;`)
23:56 (Oracle) ;;
23:57 (Oracle) さてめもめも
23:57 (Oracle) 引用にさいけいしの頂戴しよう
00:25 (Oracle) ビンゴ
00:25 (Oracle) やっぱり被弾順序だ
00:25 (Oracle) ミラージュproj受けヘルパーの位置をアノマロ被弾用と逆にしてやったら直ったわ
00:31 (Oracle) でもこれって、結局イタチごっこに近いからなあ
00:32 (Oracle) どうやっても-1になる状況があるし、もうprojcontacttimeのトリガー自体取っ払うことにした

凍結状態でのinvisible

4/6
20:31 (emeru) 凍結状態の時って何でAssertSpecial読み込んでくれないんだろうか・・・
20:32 (Momizi) え?そんな仕様知らない
20:33 (emeru) んとねぇ・・何だかこの わけ分からん現象に躓いてるん(
20:33 (Momizi) 少なくとも凍結中にあさーと読み込まなかったらうちの子イントロ永続できてない気がする
20:34 (Momizi) い、イグノアの綴り間違ってるとか(震え声
20:34 (emeru) んと、凍結に入る前は大丈夫なんだけど 凍結状態に入ると何故か読み込まぬ (explodなどは普通に読み込んでくれる
20:35 (Momizi) ちなみに何のフラグ?
20:35 (emeru) invisible
20:36 (Momizi) ふむ。そういえば凍結維持でinvisible使ってないのよね。トランスで対応してるし
20:37 (Momizi) インビジブルは確かに凍結怪しいのかな。仕様上的に
20:39 (Momizi) あ、そんなことないか。黒い子は普通にインビジブル使ってるわ
20:40 (emeru) 普段はインビジブルは使わずに、凍結状態に入ったときのみインビジブルを使う感じです
20:41 (Momizi) ふーむ
20:41 (Momizi) それはやったことないな
20:41 (Momizi) トリガーはhitpausetimeかな
20:41 (emeru) ですっ
20:42 (Momizi) ちなみに無条件にした場合はきちんと凍結中も消えるのかな
20:42 (emeru) ですねーっ 消えたまま
20:43 (Momizi) 凍結タイミング的な問題でステート読み込んだ時にhitpausetimeがなかったりは?解除->インビジブル->凍結付与とか
20:43 (emeru) 凍結時はライフを0にしているので
20:48 (emeru) そして何故かtransは読み込んでくれる・・・と
20:48 (Momizi) 最悪トランスで対応かな。原因はわからん(
20:50 (emeru) ふむ、トランスで代用できた
20:51 (emeru) 全く同じトリガーなのに・・・なんでインビジブルは発動しなかったんだろ・・・不思議でならぬ・・・
20:51 (emeru) まさかAssertSpecialはignorehitpause=1無効とかそんな訳ないよねぇ(
20:52 (Momizi) そんなのあったら黒い子は酷いことになってる
20:52 (Momizi) ありえるとしたら凍結したFで状態固定されてる、かな
20:53 (Momizi) 未凍結中:not invisible -> 凍結 -> その状態維持。
20:54 (Momizi) 未凍結中:invisible -> 凍結 -> その状態維持(invisible状態)
20:54 (Momizi) みたいな
20:54 (emeru) あー・・・なるほど だとしたらtransやexplodは読みこんでinvisibleは発動しないのも納得
20:54 (Momizi) それだったらトリガー無条件時凍結有無関わらずinvisible状態になるしね
20:55 (Momizi) あくまでも机上の空論だけど
20:55 (emeru) だとすると・・・他のフラグでもやってみるか
20:56 (Oracle) ああ・・・それか
20:56 (Momizi) 知っているのか雷電
20:56 (Oracle) それさ凍結した瞬間の状態に固定される
20:56 (Momizi) あ、やっぱりか
20:57 (Oracle) 同じく引っかかって調査して結論出した
20:57 (Oracle) これに対応したい場合
20:57 (Oracle) transを使って対処しましょう
20:57 (emeru) あー、やっぱりtransしかないのかぁ・・・サンクスですっ
20:57 (Momizi) ここまでのエメル氏との会話内容が4行でまとめられた(
20:57 (Oracle) 一番最強の手段ですわ
20:58 (emeru) 一番確実な手段ですな
20:58 (Oracle) invisibleよりも確実で解除も容易
20:58 (emeru) さー、これで凍結時にもアニメが動くぞー 

loseフラグ

4/2
23:19 (Myon_) ちょっと質問なんですけどもNOKO未使用時に1Fのみlifeが0になって回復してもloseフラグって立ちますよね?
23:20 (Myon_) hitpausetimeも0の状態で
23:24 (Oracle) いいや
23:24 (Oracle) 行動終了時にlifeが0であるか次第
23:25 (Oracle) 行動終了前にlifeが0になろうが、最後に1でもあればloseフラグは立たない。
23:26 (Oracle) 0Fじゃなくて1Fか
23:26 (Myon_) 行動終了のタイミングって個別ステートを読み込み終わったときですよね?
23:27 (Oracle) selfstateやchangestateを読み込まない個別ステートで終わりますね
23:27 (Myon_) ですよね・・・ということはこっちは問題ないのか
23:29 (Myon_) 一応もう一つ確認取りたいのですけど
23:30 (Myon_) 常時trigger1=1でライフを-1している場合って同F内で-2減ったりとかはしないですよね?
23:31 (Oracle) 普通は無いね
23:31 (Oracle) 二度読み込むような仕組みが無い限りは
23:31 (Myon_) ですよね
23:33 (Myon_) じゃあやっぱりあちらが問題っぽいですね ありがとうございました

コマンドと内部AIはCtrlに無関係

4/1
01:33 (Oracle) 意味わかんねぇ・・・
01:34 (vesper) ん?
01:38 (Oracle) ctrlが0ならcommand入力されないんじゃないのか・・・
01:39 (vesper) 入力されるよ
01:40 (Oracle) マジかぁ
01:42 (vesper) ctrlの状態には関係なかったはず。
01:42 (Oracle) まじかぁ
01:42 (Ryusei) Ctrlなしで動くしな コマンドは
01:42 (Ryusei) なしでも
01:43 (Ryusei) おのれ!AI製作者の天敵の内部AIめ!
01:43 (Ryusei)  

Stateループ

3/26
00:09 (Digest) ChangeStateで別のステートに飛ばした場合、全て1Fで処理されるのですか?
00:09 (Oracle) はい
00:09 (GGG) だね
00:10 (Digest) ほむ、ありがとうございます。なら問題ないかな、、
00:10 (blue-eyes) ループなるものが起こるのもそのためだったり(
00:11 (Digest) 同ステート内なら1Fで処理出来るのは知ってたんですが、他のステートの場合もなのかなー?と思ったのでね。
00:11 (blue-eyes) なるほど。。
00:13 (blue-eyes) 昨日の白夜の親辺も、70013と変更ステートとを往ったり来たりするようになってるんです
00:13 (blue-eyes) もちろん、1Fの間に
00:14 (Momizi) 1Fで移動しなかったら迷子センターの存在意義も準ステート固定の存在意義も(
00:14 (blue-eyes) ただし、その1F中のステート移動の回数が2500櫂を超えてくるとエラー起こしてヒャッホウするんですけどね(
00:15 (GGG) まぁそこらへんはちゃんと変数なり使って(ry
00:15 (Digest) (よし、2byte目以降も対応させなければ)
00:15 (blue-eyes) 白夜は2P側に配置されると制御用変数を親変更で弄られてクラッシュすることが(
00:15 (Momizi) リセット分+2Byte分でとりあえず3ステートあればできるかな
00:16 (blue-eyes) 無論クラッシュすることは想定の範囲内でリミッター変数つけてるんですが、
00:16 (blue-eyes) たまーにリミッター変数復元してきやがるキャラがいるのでエラー落ちが絶えない(
00:16 (Momizi) 私ステチェンばっかするのに移動回数記録してないからいつかループ起こすと思ってる(
00:17 (GGG) たぶんループで止まることはないんじゃないかなとは思うが・・・

pos y>0で強制的に立ち状態

3/23
23:14 (emeru) んん? 地下に潜りたいんだけどなんか勝手にpos y>0で強制的に立ち状態になるな・・・ナンダだこれ
23:16 (vesper) http://mugenbinran.web.fc2.com/error.html#02 これのStateDef52とStateDef140の仕様による無限ループによるフリーズ。 に書いてるやつじゃなかったっけな?
23:16 (vesper) [URL] 不具合・対策まとめ【MUGENの便覧】
23:17 (Ryusei) 単にphysicsがAじゃないのかね
23:18 (vesper) Physics = A && Pos y >= 0 && Vel y >= 0 で statedef 52に飛ぶやつじゃないっけ?
23:18 (Ryusei) それであってるはず
23:18 (emeru) くぅ、また内部処理か!!!
23:18 (Ryusei) というかそれしか思い浮かばん
23:18 (vesper) あってたかw
23:18 (Momizi) デフォコモンの内部処理移動多すぎぃ!
23:19 (vesper) これコモン関係無かったようなw
23:19 (Ryusei) AIよりマシでしょ(知らんけど
23:19 (Ryusei) というかコモン関係ない気がw
23:19 (Momizi) せやな
23:19 (Momizi) physics=N以外に設定する事ないからしらなかったや(適当
23:19 (Ryusei) せやな
23:20 (emeru) おお、うまくいったサンクスですっ
23:20 (vesper) よかった

コメントリストを開閉する

RoundState=3の高速終了

3/9
18:55 (Oracle) roundstate=3の高速終了条件ってどっかに載ってたような気がするんだけど
18:56 (Oracle) どこに載ってたか分かる方いますかね
19:07 (YANMAR) luna氏のブログにあったような…
19:07 (YANMAR) http://lunatic284.blog90.fc2.com/blog-entry-16391.html
19:07 (vesper) [URL] lunaの倉庫 // Roundstate=3
19:10 (Oracle) おお、ありがとうございます
19:10 (Oracle) 試合終了じゃなくてroundstate=3で探せばよかったか

空中で立ち、無限に落下

3/2
00:23 (N-Fox) うーん……またCommon関係のミスか
00:24 (N-Fox) 稀に着地せずに無制限に落ちていくのと、空中で立ち状態になって落ちてこないのと
00:24 (YANMAR) 困ったら52にセルフしよう
00:24 (YANMAR) 何かと空中に浮くってのあるから、ジャンプ消すってのもそれなりにアレなんよねー
00:24 (Momizi) 着地せずに落下は作ってる途中でよくあるやつや(
00:25 (Oracle) 空中立ち状態は技のトリガーミス
00:25 (YANMAR) pos yとかで適当に0とかに飛ばせばw
00:25 (Myon_) 自分もそれによく悩まされましたね
00:25 (Oracle) 着地無制限が不明だな
00:25 (N-Fox) トリガーミスか……
00:26 (Oracle) 空中で立ち状態攻撃振っちゃったりするとそうなる
00:26 (Oracle) あとはステ抜けあたり
00:26 (YANMAR) statetype=Aだかがいくなくないんだっけ
00:28 (Oracle) いろいろ原因あるからなあ
00:49 (N-Fox) ふむ……まあ、無制限に落ちるにしろ空中で立ち状態攻撃振るにしろいずれ何とかしないと
00:51 (YANMAR) 52に飛ばして、52にpossetで0,0とか入れておけば
00:52 (N-Fox) んー……なんというか、場合によってはsffの調整しなきゃならんのでめんどくさいなあと
00:52 (YANMAR) sffとかairまではやらんでいいような
00:53 (N-Fox) なんというか、アニメによって座標が違ったりするので
00:53 (N-Fox) ものによっては直さないといけないという

StateNo移動原因

2/19
22:16 (_609z) ちょっとだれか手助けを...
22:16 (N-Fox) 相変わらずAI起動しちゃうん?
22:16 (_609z) MUGENのね
22:22 (N-Fox) 常時ステ固定? も無駄だったんだっけ
22:23 (_609z) んーと、G神奈に専用組みたくて記述みてみたら固定するとだめっぽかったから
22:24 (_609z) 固定はずしてみたらRoundState=2に入った瞬間「MUGEN側」のAIが起動して動いちゃう
22:25 (N-Fox) ただの思いつきだし別に気にしなくていいんだけど、同じアニメの別ステート2種類用意して時間経過でステート変動とかダメなのかな
22:30 (_609z) あー、なんだこれ、MUGEN側のAIきったら勝手にchangestateしやがった。なんてこったい
22:32 (_609z) というかー2で条件満たしてるのにctrlが付いてるってww
22:36 (_609z) マジクソだわ
22:36 (_609z) どうやったらいいんだろう
22:49 (DRM) AI作成の時にやってることなんだけど、-3ステートにSelfStateを置いてる
22:50 (DRM) Value=PrevStateNo
22:52 (DRM) 内部AIで移動するステートは10、11、12、20、40、45、120なはずなので
22:57 (_609z) ありがとうございます。解決しました
22:59 (N-Fox) おめおめ

参考:不具合・対策まとめ StateNo移動原因[MUGENの便覧]

死んだヘルパー

2/13
01:00 (Myon_Phantasm) そういえば前から気になっていたんですけど死んだヘルパーって消したほうがいいんですかね?
01:00 (Momizi) 消した方が良いというか自分で消えないっけ
01:01 (simotsuki) 消えんじゃろw
01:01 (Momizi) ヘルパー殺したことないんだよなぁ・・・
01:01 (Momizi) あ、普通に探査であったわ
01:01 (simotsuki) そのまま普通に使えますよん
01:01 (simotsuki) 一回だけステート勝手に動いちゃうかもだけど固定なら関係無いし
01:02 (Myon_Phantasm) 混線とかで間者が死んでもデストロイしてないからどうなのかなーって思って
01:02 (Momizi) んー、でもアーマーヘルパーとか仮に死んだら実質論外化するよね(
01:02 (Myon_Phantasm) アーマーはよっぽどのことがない限り死なないと思います
01:02 (simotsuki) ヘルパーの方のgethitvarはライフ0でも普通に機能するんでね?
01:03 (simotsuki) タメした事ないけどw
01:03 (Momizi) どうだったかなぁ
01:03 (Momizi) というか、間者が死ぬってよっぽどじゃないかな・・・
01:04 (Myon_Phantasm) 最近になって混線ステートに間者のライフをmaxにするようにしたけど前は回復させてなかったのでw
01:05 (Momizi) 何で死んでるのかわからんが、あり得るとしたら当て判定アニメ調査時当身喰らって超即死?または喰らい判定調査時にアーマー無しで大ダメージとか
01:05 (Momizi) 混線でタゲライフはしたことないわ(
01:05 (simotsuki) 死体を再利用するのだ…。なんたる鬼畜
01:05 (simotsuki) なんかの撃破条件とかになってなかったっけ。ヘルパー殺すヤツw
01:05 (simotsuki) 修正されたかもわからんけど
01:06 (Momizi) 奪ってlifesetで良いしなぁ
01:06 (simotsuki) ステ抜けがaliveになっててさ
01:06 (simotsuki) トリガーね
01:06 (Momizi) ふむ・・・
01:06 (simotsuki) 丁度もみもみはおらんかったかもわからん
01:07 (Momizi) 混線のタゲライフねぇ・・・重複混線だからなぁ・・・
01:07 (Momizi) 追加するとしたらかなり回り道しなくちゃだな
01:07 (simotsuki) ま、普通はやらんよなw
01:07 (simotsuki) 余計に死んでなんか死体がごろごろしてるのも見え悪いし
01:08 (Momizi) ノーマルは特にそうやなw
01:08 (Momizi) まぁ、考えておく。まんざら無駄でもないだろうし

reversaldefとhitdefの上書き

2/8
23:20 (_609z) どうすっか。reversaldefとhitdefが同じステートにあった場合ってどっち優先なんだ?reversaldef?
23:20 (Momizi) 一番最初の方だったかと
23:20 (Myon_kari) 上に書いてあるほうじゃないのかな?
23:20 (Momizi) リバサhitdefの順ならリバサ優先
23:20 (Momizi) 逆ならhitdef
23:21 (Momizi) hitdefで取るならリバサの条件にnumtarget付ければおk
23:21 (N-Fox) 上から読み込むから先に読み込んだほうらしいよ
23:21 (_609z) ほむ。逆にしてみるか
23:21 (lunatic__) もう殆ど忘れたけどこれって上書きしないんだっけ
23:21 (Momizi) ステート移動しても確かされなかったような
23:21 (rakurai) え、そうなの?
23:22 (Momizi) したらそっちになるっけ
23:22 (rakurai) ステ固定先に落下即死当身しててソレ発動してて困った覚えあるんだが
23:22 (Ryusei_) hitdefpersistが1なら
23:23 (Momizi) あぁ、hitdefpersist次第か
23:23 (rakurai) あ、それか
23:23 (Oracle) または凍結
23:23 (Ryusei_) あと、reversaldefとhitdefが同じステにある場合 最後の方が優先される
23:23 (rakurai) そうだよね
23:23 (Momizi) あれ、最後だっけ(
23:23 (rakurai) そうじゃなきゃ自分今まで全部間違ってることになる
23:24 (Ryusei_) 上から順に読むからね
23:24 (lunatic__) 試したけど普通に上書きされるね
23:24 (_609z) ナンダトー?!
23:24 (N-Fox) 後で読み込んだほうかあ、ってことは後に読んだほうが上書きする形なのか
23:24 (Momizi) 忘れ過ぎである
23:24 (Ryusei_) だから上にあっても下にある方が上書きされる
23:25 (rakurai) 全キャラ修正する羽目になるかと思ってちょっと焦った
23:25 (Momizi) すまそん

重複並列混線、numtarget=2になって、target,idをリダイレクトすると、直前の被弾ヘルパーと直後の被弾ヘルパーの時がある

2/1
21:36 (pkrs) 重複並列混線、numtarget=2になって、target,idをリダイレクトすると、直前の被弾ヘルパーと直後の被弾ヘルパーの時があるんですが
21:37 (pkrs) 直前じゃないと失敗してるってことですかね
21:40 (Oracle) いんや
21:40 (Oracle) あ、すまん多重と勘違いした
21:41 (pkrs) 重複並列にする意義、直前のヘルパーの情報をリダイレクトする為だと理解してるんですけど
21:42 (Oracle) そうね
21:42 (pkrs) なので直後だと無意味ってことですよね
21:42 (Oracle) 探査の為だけにあるね。直前のタゲになってないとダメ
21:42 (pkrs) んーF4で試行するだけで変わってしまうので謎…
21:42 (Oracle) んで原因なんだが、正直よくわからん。gametimeで変化する
21:42 (pkrs) あーそうなのか
21:42 (Oracle) gametime%2、gametime%2=0でタゲ取りしてみてくれ
21:42 (Oracle) どっちかで上手くいく。
21:42 (pkrs) なるほど
21:41 (pkrs) 重複並列にする意義、直前のヘルパーの情報をリダイレクトする為だと理解してるんですけど
21:41 (Oracle) そうね
21:41 (pkrs) なので直後だと無意味ってことですよね
21:42 (Oracle) 探査の為だけにあるね。直前のタゲになってないとダメ
21:42 (pkrs) んーF4で試行するだけで変わってしまうので謎…
21:42 (Oracle) んで原因なんだが、正直よくわからん。gametimeで変化する
21:42 (pkrs) あーそうなのか
21:42 (Oracle) gametime%2、gametime%2=0でタゲ取りしてみてくれ
21:42 (Oracle) どっちかで上手くいく。
21:42 (pkrs) なるほど
21:43 (Oracle) 並びとしては、target,id、parent,idになってればおーけ
21:44 (pkrs) あ、!(gametime%2)で上手く行った
21:45 (pkrs) ああ違う、(gametime%2)でだ
21:46 (pkrs) target,id、parent,idの並びの話、親変更も導入した時のケースです?
21:47 (Oracle) そうね
21:47 (Oracle) あ、すまん親変更使ってる時点の話してしまったな
21:47 (pkrs) まだ単体なのよね
21:47 (pkrs) 入れたらチェックしてみます
21:47 (Oracle) 後ろタゲ、前タゲだね
21:47 (pkrs) target,id、parent,idの並びの話、親変更も導入した時のケースです?
21:47 (Oracle) そうね
21:47 (Oracle) あ、すまん親変更使ってる時点の話してしまったな
21:47 (pkrs) まだ単体なのよね
21:47 (pkrs) 入れたらチェックしてみます
21:47 (Oracle) 後ろタゲ、前タゲだね
21:56 (pkrs) 混線被弾ヘルパーの削除、何をトリガーにするといいかな
21:56 (pkrs) movetype=hは不安定すぎるよね
22:00 (Oracle) 混線の展開方法にもよるが
22:00 (Oracle) まあそうだな、全てタゲが取れているかチェックするならば
22:01 (Oracle) 展開した混線の数を記録、タゲ取れたヘルパーはprojで通知、proj数と展開した混線ヘルパー数一致でフラグ立てて、そのフラグを確認して削除かな
22:02 (pkrs) ふむ
22:02 (Oracle) これならまずどんな混線タイプでも大丈夫だろう
22:02 (pkrs) 1P側は鬼巫女X相手でも問題なく展開できてるから、2P側の堅牢化だなあ
22:04 (Oracle) 2P側で親変更できるように展開するの難しいんだよなあ
22:05 (Oracle) 1P側のヘルパー配置次第で、領域確保ヘルパー削除の後に割り込まれてしまうからなあ
22:05 (Oracle) 逆に親変更を考えなければ問題ないんだけどなあ
22:06 (pkrs) 親変更なしなら安定するのか
22:07 (Oracle) 親変更なしだったら1P側のヘルパーの空き確認して展開するだけだからなあ
22:07 (Oracle) 親変更しようとすると一度親を作らないといけないから、混線前に削除する必要があるのよね
22:07 (Oracle) その削除のときに間に相手ヘルパーがいると、先に出されて狂っちゃう
22:08 (pkrs) ふーむ
22:13 (pkrs) 混線被弾ヘルパーの削除、普通にhelper(*),numtargetでリダイレクトすれば良かったね
22:13 (pkrs) 条件不成立時はtargetdropしてるので、確実
22:13 (Oracle) 実はそれで私もやってるんだが
22:14 (Oracle) 2P側を考えるといくつヘルパー展開してるか分からんから
22:14 (Oracle) 2P側でも大丈夫な方法を考えた。
22:14 (Oracle) が、一番目の混線のターゲット確認だけでもいけそうやな
22:14 (pkrs) どんなです
22:15 (Oracle) いや前述した通りだよ。展開したヘルパー数を記録して比較する方法
22:16 (pkrs) ああ、そなのか
22:16 (Oracle) 未分化ヘルパーで行ってる場合は一番目の混線ヘルパーが分からないから、数で比較してたのよね
22:16 (pkrs) 自分は普通に連番ヘルパーでやってるからなー
22:16 (Oracle) 私も連番ですね。
22:17 (pkrs) 未分化ヘルパーって同じishelpr(2)とかのを分岐させるのじゃないの?
22:21 (Oracle) そうそう
22:21 (pkrs) あれ、これであってたのか
22:21 (Oracle) ヘルパーに最初から役割を与えず、試合の中で最適な役割を与える方法だね
22:21 (pkrs) 情報を参照するときは、PlayerIDリダイレクト?
22:22 (Oracle) そうだね
22:22 (pkrs) うへー鬼巫女Xとかが導入してたって聞くけど、変態記述っぽいな…
22:22 (Oracle) うーん、私もやる気にはならない
22:23 (Oracle) でも混線ヘルパーのエフェクト用の未分化はやってるなあ
22:23 (pkrs) エフェクトとか技用ならまあ
22:23 (pkrs) 常駐はさすがに
22:23 (Oracle) 全体のシステムではとてもじゃないがやる気にはならん
22:23 (pkrs) 常駐というか、システム
22:23 (Oracle) エフェクトではやるべきだね。これやっとくと演出作りやすい
22:24 (pkrs) 演出用未分化は、むしろ常套手段ですね
22:24 (Oracle) 実はすこーしまえまでやってなかったんですよねー(
22:24 (pkrs) そなのか
22:24 (Oracle) 比較的最近になってその構造に着手して完成させましたね
22:25 (Oracle) 今は更に汎用的にするために試行錯誤して終わったところだな

演算子の優先度

12/30
21:48 (emeru) んー? ビット演算と四則演算って、ビット演算の方が優先なのかしらん
21:49 (YANMAR) こば
21:54 (SAIKEI) =、:=よりも優先度が低い ビット演算
21:56 (emeru) なるー・・
21:57 (emeru) ありです、、逆だったか・・ふむぅ

life、defence設定

9/9
16:16 (Momizi) 削り用のダメージにdamage+fall.damage=enemy,lifeになる設定入れたけどこれ何か効く相手いたかね(
16:16 (Momizi) gethitvar(damage)>life関係のトリガーは突破できる気がするんだが
16:20 (Oracle) 現在いるかはわからないけど
16:21 (Oracle) 一人通るのがいた
16:21 (Momizi) ほむ。いたのか(
16:22 (Oracle) あー
16:22 (Oracle) オーバーフローだりぃですの
16:23 (Oracle) 防御100未満になるとダメージコントロールが難しい
16:23 (Momizi) ふむ
16:23 (Momizi) あれややこくて嫌い(
16:23 (Oracle) ややこしですね
16:23 (Momizi) defence1変わっただけで全然違うからぬ
16:24 (Oracle) defence1とかハゲる
16:24 (Momizi) パンドラあたりがそうだっけか
16:24 (Oracle) そうね
16:25 (Momizi) 紙装甲ならぬ神装甲(
16:25 (Oracle) 実際そう
16:26 (Oracle) defenceの計算間違えると100未満の攻撃が0になるからね
16:26 (Oracle) 最強は0だな
16:26 (Momizi) 0ってできたっけ?エラメでないっ気
16:26 (Oracle) でない
16:26 (Oracle) 出るのはlife
16:26 (Momizi) lifeか
16:29 (Momizi) lifeは1でもタッグで落ちるんだっけ課
16:30 (Oracle) そうそう
16:32 (Momizi) あれデフォだと確かlife/2されるはずだからぬ
16:34 (Oracle) たぶんそれで内部値0扱いされてるんだろうねー
16:35 (Momizi) だろうねー

StateDef11、StateDef51

7/21
23:17 (Momizi) 140ステートからのガーステ化入れたのはいいけど, def11とdef51の存在忘れててひどい目にあった
23:17 (YANMAR) あったなーw
23:18 (Momizi) 特にうちの子全員statetypeがS以外になることないから記述見ても問題なくてさらに混乱してた(
23:18 (Momizi) 偽装でのみstatetype変えてた弊害がここに・・・
23:19 (YANMAR) 11と51は使わないようにしてるかステート番号かえるかしてるなぁ
23:20 (Momizi) 今作ってるキャラはRくなーや筆頭タイプだから一通りのコモンステート作ってるからぬ。仕方ないね
23:20 (YANMAR) 筆頭は51が前ジャンプ、52が後ろジャンプとかにしてたような…w
23:20 (Momizi) あぁ、タイプ言うても内部はまったく違うと思う(
23:21 (YANMAR) あーなるw
23:21 (Momizi) 本体Explod化してる上にステートは毎度恒例の関数化してるからね(
23:21 (Momizi) 関数化というか呼び出し式というか
23:22 (YANMAR) 迷子センターの発展系みたいな感じかな
23:22 (Momizi) 後はモーション再現は全部gethitvar(damage)で行ってるかな
23:22 (Momizi) 処理をできるだけステート分割して呼び出せば大体どこでも使えるような感じかな。説明しにくいけど
23:23 (YANMAR) 何となくは分かるけど、そういう形式かー
23:23 (YANMAR) まどっちとかは本体動作に依存しないようにしてたなぁ
23:24 (Momizi) 簡単に言ったら演出用のステートと内部的な処理を行うステートを完全に分割してるっていったらいいのかな
23:25 (YANMAR) なるほどのぅ
23:25 (Momizi) 例えばしゃがみ動作しながら強制死の宣告用ステート呼び出せば強制死の宣告が打てる。みたいな
23:28 (Momizi) -2->迷子ステート->実行したい処理(例えばヘルパー生成)->迷子ステート->実行したい処理->迷子センターと繰り返してから->演出用ステートってな感じの構造かな
23:29 (YANMAR) 迷子センターを軸にって感じかー、うーんややこいw
23:30 (Momizi) 元々が専用対策しやすい構造考えてたらこうなったもんだしね(
23:30 (Momizi) 専用の時必要な処理だけ呼び出せばいいからかなり便利
23:31 (YANMAR) 最初が大変だけど後から追加するには良さそうねぇ
23:31 (lunatic__) 自分も鬼巫女Xはそんな感じかなぁ -1人用してるけど
23:32 (lunatic__) -1利用
23:32 (Momizi_y-) 逆に-1が仕事してない(
23:32 (YANMAR) statenoも偽装して本体動作で攻撃とか移動とか一切しないようにしてるから
23:32 (YANMAR) ほぼー1で専用だなぁ
23:33 (Momizi_y-) 専用キャラ毎にステート用意して, そのステートを主軸に必要な処理用ステート呼び出すようにしてるかな
23:34 (Momizi_y-) だから大体専用は1ステートで完結してる
23:35 (Momizi_y-) あっちこっちにname指定入れると見にくくなるし変更が大変なのよね・・・
23:37 (lunatic__) 専用は専用変数に数字入れてその数字参考に状態変数切り替えて足りない分だけステコン足してる感じかなぁ
23:41 (Momizi_y-) 変数化も考えたんだけどよりわかりやすさ重視で今の感じに落ち着いた感じかなぁ
23:43 (Momizi) 複雑に記述すると自分でも分からなくなる(

ガード条件

7/7
23:01 (Ryusei) ライフ無かったらガードできないのか・・・
23:02 (Ryusei) 初めて知ったわ・・・
23:04 (Ryusei) まあ、当たり前か(

コマンド

1/13
01:41 (DRM) 方向キーの記述でFUとUFって同じ?
01:42 (vesper) 前にコマンド関係を調べてた時に、FUだとFって扱いになってた。
01:42 (DRM) $Uって記述するとどっちも含まれる?
01:42 (vesper) 含まれるね
01:43 (DRM) thanks

20:39 (DRM) ~UでフラグONにしたいのに、8押しっぱでも他の方向キー押しちゃうとONになっちゃうなぁ
20:39 (DRM) どうにかならないのかなぁ
20:40 (vesper) ん?
20:40 (blue-eyes) 斜め上を押した場合でもスイッチが入る、ってことですか?
20:40 (blue-eyes) ↑を押したまま→への入力を行ってもスイッチが入ってしまう、と?
20:41 (DRM) その通りっすね
20:41 (vesper) →が入ってる場合をトリガーで弾くのではダメなの?
20:41 (DRM) 駄目やねー
20:42 (DRM) 空中ジャンプをAirJump.Num=0で制御したいんだけどねぇ
20:42 (DRM) なかなかうまくいかない
20:43 (blue-eyes) ↑が入力された瞬間にのみフラグが入るようにしたいのに
20:43 (vesper) あ、この聞き方だとどっちか分からなかった。 トリガーで弾く方法は使えない?上手くいかない?
20:44 (blue-eyes) ↑入力中に→の入力が入ってもフラグが入ってしまう・・・ということなんですかねぇ
20:44 (DRM) 多分使えない>vesperさん
20:44 (blue-eyes) 前ジャンプを考慮して↑+→をフラグ入力候補として扱ってる、なんてことはありません?
20:45 (vesper) ふむ
20:46 (Ryusei_) 空中ジャンプのステでvaraddでの方法はダメですかぬ?
20:47 (emeru) それって command!="holdfwd" はダメなの?
20:48 (blue-eyes) ジャンプステートの1F目でフラグセットってのが一番早いんでしょうけど・・・そういうわけにもいかないんですか?(
20:49 (DRM) 全部うまくいってないね
20:49 (vesper) command =$F とか作ってそれ使ってemeruさんの上げたトリガーで弾くってのを考えてたんだけど、それが使えそうにないってのがイマイチ状況がわからぬ・・・
20:49 (blue-eyes) ジャンプ1Fでのフラグセットでも対処できませんか・・・一体どういう状況なんだろ・・・
20:50 (DRM) ん~
20:50 (DRM) [State フラグ : 空中ジャンプ]
20:50 (DRM) Type = VarSet
20:50 (DRM) Trigger1 = (Var(59) & 1)
20:50 (DRM) Trigger1 = Command = "Air-Jump" && Command != "holdfwd" && Command != "holdback" && Command != "holddown"
20:50 (DRM) V = 0
20:50 (DRM) Value = (Var(0)|16)
20:50 (DRM) で、
20:50 (DRM) [State ]
20:50 (DRM) Type = SelfState
20:50 (DRM) TriggerAll = (Var(59) & 1)
20:50 (DRM) TriggerAll = (Var(0) & 16) && Var(6) <= 4
20:50 (DRM) TriggerAll = StateType = A
20:50 (DRM) TriggerAll = Command = "holdup"
20:50 (DRM) Trigger1 = Ctrl && !(StateNo = 110 | StateNo = 115)
20:51 (DRM) Trigger2 = MoveHit && StateNo = [600,699]
20:51 (DRM) Value = 45+(Var(0):=(Var(0)|16)-16)*0
20:51 (DRM) Air-Jumpが~U
20:52 (blue-eyes) U押しっぱなしの間はフラグセットをしないようにするって方法がいけるんですかねぇ・・・変数がさらにひとつ必要になりますけど
20:55 (blue-eyes) ↑キー押しっぱなしの間はV1の値を0にし続け
20:55 (blue-eyes) 押してない間はその値は毎F増え続ける
20:56 (blue-eyes) で、↑キーを押した瞬間、そのときのV1の値が2以上の場合のみ、ジャンプフラグを成立させる・・・とか?
20:57 (DRM) fm・・・
20:54 (emeru) Air-Jumpとトリガーを分けてもダメかな
20:54 (DRM) トリガーを分ける?
20:55 (emeru) Trigger1 = Command = "Air-Jump"
20:55 (emeru) Trigger1 = Command != "holdfwd" && Command != "holdback" && Command != "holddown"
20:56 (DRM) それ何の意味があるんや・・・【´・ω・`】
20:57 (vesper) DRMさんがはったのってvar(0)|16をリセットするのはジャンプ出来たとき以外にもあるんだよね?
20:58 (DRM) あ、StateNo=40とStateNo=45&&!Timeでリセットしてるな・・・
20:58 (blue-eyes) 私のキャラでは、これに近い方法で制御してるシステムがいくつかあります、ボタン押してる途中に他のキーを入力を無視するシステムを導入してるのもいます
20:59 (vesper) なら、ジャンプ入力が立ちっぱなしってわけでもないのかなぁ。
20:59 (DRM) 他のキーは無視かー
20:59 (blue-eyes) 2年ほど前に作ったへぇボタンなんかがそれです(
21:00 (blue-eyes) どのボタン押しても反応する代わり、1つのキー押してる間に他のキー押されても反応しないシステム、ですね
21:00 (blue-eyes) これなら↑押してる途中に→押されても反応しなくなるはずなんですが。。。
21:00 (vesper) そういや、単純にSelfstateの方にtriggerall=Command != "holdfwd" && Command != "holdback" && Command != "holddown" ってダメ?
21:01 (DRM) SelfStateに追加しちゃうと前ジャンプと後ジャンプできなくなるんじゃ
21:02 (vesper) あれ? 垂直ジャンプだけしか許さないのかと思ってたw
21:02 (DRM) ごめんw
21:02 (DRM) 前後アリや
21:02 (Ryusei_) 前後ありか・・・Selfstateと同じ条件とか考えてたが・・・
21:02 (emeru) アニメで判断するとか
21:03 (DRM) あ
21:03 (DRM) OK、出来たわ
21:03 (DRM) oh...
21:03 (blue-eyes) おろ、おめです
21:03 (Ryusei_) おめっす
21:03 (vesper) おめです
21:03 (emeru) おめですっ
21:03 (DRM) 4と6押しながら8押しても空中ジャンプしねぇ・・・
21:04 (blue-eyes) あらら・・・
21:04 (blue-eyes) 今度は逆パターンに反応できない感じですか・・・
21:04 (Ryusei_) Command != "holdfwd" && Command != "holdback"があるからだろうぬ・・・
21:05 (DRM) アイヤー
21:05 (DRM) どうしましょ
21:06 (Ryusei_) selfstateに書いてある条件を空中ジャンプフラグに入れてもダメなのかぬ?
21:07 (blue-eyes) 実際のところ、ジャンプフラグに直接関係するのは↑のキーだけなんですよね?
21:07 (blue-eyes) 本来なら
21:07 (DRM) ダメだぬ>リュウセイさん
21:08 (DRM) そうですね>青眼さん
21:08 (emeru) 思ったけど、無限に空中ジャンプできるようにしたいんかな
21:08 (DRM) まぁそうだねー。回数制限は別個で付けてるけど
21:08 (blue-eyes) だとしたら、やはり↑キーが押しっぱなしになってるかどうかをみるフラグ変数を新たに作ったほうがいいような気が・・・
21:08 (vesper) 自分はDRMさんのしたいことが把握出来てない( 空中ジャンプフラグを立てるのは8のみを押してる時だけだけど、ジャンプ方向は前後ありってこと?
21:09 (emeru) ヴェスタが無限空中ジャンプ搭載してるけど、私の場合はソレ専用のステートを作ってる
21:09 (DRM) ~Uだから8を離した時やで、フラグがONになるのは
21:09 (DRM) ジャンプ方向は前後アリ
21:09 (blue-eyes) ・・・それか(
21:09 (vesper) あ、チルダか、勘違いしてた。 了解です。
21:10 (blue-eyes) Uを押した瞬間にフラグONのほうがいいのでは?
21:10 (emeru) うん、チャンと3方向にジャンプできますよっ
21:10 (DRM) ヴェスタちゃんは後で見てみます
21:10 (Ryusei_) 押しっぱのほうだと勘違いしてしまった・・・
21:10 (vesper) おしっぱは/か。
21:11 (blue-eyes) 状況がよくわからない・・・なぜ↑を離したときにスイッチをONにするんだろう・・・
21:11 (vesper) すっかり取り違えてた。 あと普段の自分のジャンプ操作の仕方から。
21:12 (DRM) 単純に、空中ジャンプするなら事前に8離してるからやな
21:12 (blue-eyes) あーなるほど、Uを離すことで追加ジャンプの準備ができたことを把握する、ということですか
21:13 (DRM) 押した瞬間だと何か不具合があったからこうした気がする・・・がよく覚えてない(
21:13 (DRM) そうだね
21:13 (vesper) 最初のジャンプの離した時にフラグを立ててってことかぁ。今更把握。
21:14 (blue-eyes) で、↑を押しっぱなしにしてる途中で→の入力が入ってもなぜかフラグが切り替わってしまう、と?
21:15 (DRM) 最初はそうでした。でも何とか解決して、今度は4or6押しっぱで8押してもジャンプ出来ない症状になった
21:16 (blue-eyes) なるほど。。
21:16 (vesper) 現在のステートとか貼ってもらえます?
21:17 (DRM) 空中ジャンプのステート?
21:17 (vesper) さっきのが解決したということはどこか変えたのかなぁ、と思ったので。
21:19 (DRM) ああ、何かCommand != "holddown"追加したら何故か出来た
21:19 (DRM) よくわからん(
21:19 (Ryusei_) 謎過ぎるだろうw
21:19 (blue-eyes) ↓を除外したら・・・・?これまた謎ですねぇ(
21:20 (vesper) 青眼さんの言うようにフラグの方にです?
21:20 (DRM) そうやね
21:20 (DRM) SelfStateの方は変えてない
21:20 (vesper) ということは雑談に貼ったのからは変わっていないです?
21:21 (DRM) 変わってない
21:21 (vesper) ふむふむ。ありです
21:21 (Ryusei_) あれ、雑談で貼ったフラグの奴ってCommand != "holddown"
21:21 (Ryusei_) 変わってないのか・・・
21:22 (DRM) そういやdownだけないなーって思って付け足したやつ貼ったんや(
21:22 (DRM) それで更新したらうまくいった、謎だった
21:23 (emeru) あー、私も経験ある(
21:24 (emeru) コマンド系統のフラグの立ち方がイマイチ分からぬこの頃
21:25 (DRM) しかしこのままだと左右押しっぱで空中ジャンプ出来ないなw
21:25 (blue-eyes) 私はそんな感じのことはほとんどないですねぇ・・・
21:25 (Ryusei_) Command != "holddown"以外のholdを外しての空中ジャンプか・・・
21:26 (blue-eyes) 変数制御を相当数使ってるので、あまり悪影響が出にくいんですかねぇ。。。
21:26 (vesper) 左右押してるとフラグは立ってるのにジャンプ出来ないって事?
21:27 (DRM) フラグ立たない、全部除外してるから
21:27 (blue-eyes) そもそもフラグが立たないとなると・・・
21:27 (vesper) ずっと左右押してるとフラグは立たないと思うけど、そうでいうことではないよね?
21:27 (DRM) そういうことなんだよなーw
21:28 (DRM) だからこの方法やっぱり直さないといけない
21:28 (vesper) あ~、原因は解ってるけど、左右ジャンプもしたいってことかぁ
21:28 (Ryusei_) 左右押してるから ~U  が起動してたりして(   ないか
21:28 (emeru) 私どんな方法でやってたかなー ちょっと見てくる
21:29 (DRM) ~Uって8離したらって意味なのに、何で8押しっぱで他の方向キー押したらフラグ立つねん
21:29 (emeru) あったった
21:30 (emeru) ~8 ってさ  ニュートラル状態で8を押した時って意味だよね
21:30 (simotsuki) DRMさんが離した瞬間にフラグオンにするのって
21:30 (vesper) 8を離した時 >emeruさん
21:30 (simotsuki) ジャンプした瞬間に空中ジャンプにならないようにする為?
21:31 (DRM) それが一番の目的
21:31 (Ryusei_) 他のキー入れてたら離れるからじゃないのかぬ
21:31 (Ryusei_) 押してたら
21:32 (vesper) 方向キーは他の方向キーを押すと一旦離した判定される? もしくはDRMさんがキーボードで3キー押してキーボードの同時押し限界でおかしくなってるとか?
21:32 (DRM) 他の方向キー入れると、押しっぱなのに離れるの?
21:32 (simotsuki) 他に目的あるならダメかもだけど特定のアニメに行くまでは空中ジャンプ出来ないようにするとかじゃダメかな
21:32 (blue-eyes) 地上で押した場合のみ空中ジャンプ扱いにしなくなるってのが一番手っ取り早そうですけど。。。
21:33 (DRM) だめやなー>しもさん
21:33 (simotsuki) ふーむ
21:33 (Ryusei_) なんかそれしか今のところ考えれないかな・・・自分は・・・>方向キーは他の方向キーを押すと一旦離した判定される
21:34 (emeru) 単純にStatetype!=A は?
21:35 (Ryusei_) 間違ってたらすまぬ・・・
21:38 (vesper) なるね。 方向キーは他の方向キーを押すと一旦離した判定される
21:38 (DRM) チーン
21:38 (blue-eyes) そうだったんですか・・・知らなかった(
21:39 (DRM) やはり押した瞬間を判断するしかないかねぇ
21:39 (Ryusei_) なるのか・・・
21:39 (vesper) aは大丈夫だったから、多分方向キーだけの要素のはず。
21:40 (DRM) 困った仕様だ
21:42 (DRM) あー、ギリギリしもさんの方法でも行けそう・・・ちょっと改造すっか
21:43 (emeru) ボタンを離した時に空中3方向ジャンプ・・・か・・・ ヴェスタでちょっと実験してみよう・・
21:43 (blue-eyes) しっかしこれはまためんどくさい仕様ですねぇ
21:43 (vesper) コマンドに余裕があるなら、Air-Jump_UFの~UFとAir-Jump_UBの~UBも作って、Trigger2 = Command = "Air-Jump_UF"&& Command != "holdfwd" && Command != "holdback" && Command != "holddown"とかつくれば行ける?
21:43 (emeru) ん、地上ジャンプもボタンを離したタイミングなので?
21:44 (simotsuki) コマンドは色々メンドイね~
21:44 (simotsuki) 相手飛び越した時の空中ジャンプとかも直すの結構面倒だった
21:44 (simotsuki) そのままだと想定の方向に飛んでくれない
21:45 (vesper) ジャンプ自体は押した時だよ。 空中ジャンプできるフラグが立つのが、その前のジャンプキーを離した時って作りだと思う。 >emeruさん
21:45 (emeru) あれ、そんな面倒だっけ(
21:45 (emeru) んじゃ一旦離してニュートラル状態にしてから また3方向ジャンプ。。か
21:46 (DRM) だめやった>vesperさん
21:46 (vesper) あ
21:46 (vesper) いや。 う~ん。 だめだったかぁ。
21:47 (emeru) あ、それならヴェスタの急降下っつー技に近いかも・・・
21:49 (DRM) てか
21:49 (DRM) 4or6押してる時に8押しても認識されない・・・
21:50 (DRM) あ
21:50 (DRM) だから$Uなのか(
21:54 (DRM) ~$Uでも~Uでも結果としては変わらないよな・・・くっそー
21:55 (emeru) $Uって中々面倒(
21:55 (blue-eyes) Uを離した後2Fの間だけ猶予を与えるとかは(
21:56 (vesper) 方向キーは他の方向キーを押すと一旦離した判定される だけじゃない。 方向キーは他の方向キーを離しても一旦離した判定される(
21:56 (DRM) もうそんな感じにするしかない
21:56 (blue-eyes) 自分で言ったったは良いけどこれ絶対めんどくさいよなぁ(
21:56 (DRM) めんどくせーw 何だその仕様w
21:56 (blue-eyes) めんどくせぇ(
21:56 (vesper) ということで雑談やつでやると、他のキーを離し時も除外してやる必要があるかもw
21:57 (DRM) こらもう青眼さんやしもさんが教えてくれた通りにするしかないですわ
21:57 (blue-eyes) やはり押した瞬間に頼るしかない感じですか・・・
21:58 (emeru) 空中でボタンが離れた時に空中ジャンプ・・・ですよね
21:58 (vesper) いや違う
21:58 (vesper) 空中ジャンプできるフラグが立つのが、その前のジャンプキーを離した時。
21:58 (vesper) ジャンプするのは次に上方向を入れた時。
21:59 (emeru) 例えば空中状態で~Uが成立するとジャンプ 見たいな
21:59 (simotsuki) そいや
22:00 (simotsuki) holdupって試してみた?
22:00 (simotsuki) ジャンプステートでholdupじゃなければフラグ立てるとか
22:02 (emeru) それならさ command=~U,U じゃダメ?
22:02 (DRM) それはやってなかった>しもさん
22:03 (simotsuki) もしかしたら他押してもホールド系なら持続するかも。私もやってないから分からんけどw
22:03 (DRM) そもそも~Uが使えないんだからダメだね>エメルさん
22:04 (emeru) 無限空中ジャンプする誰かの記述見た方が早いと思うの(
22:04 (emeru) 私はGM諏訪子を参考にしましたが
22:04 (simotsuki) DRMさんのキャラ独自の何かがあるから困ってるんでないのw
22:05 (DRM) 特別な作りじゃないよw
22:05 (DRM) 普通のキャラ
22:05 (simotsuki) ふーむ
22:06 (DRM) ちょっと整理がめんどくさかったからさっきの遠慮したけど、そうも言えない状況になった
22:06 (emeru) ウチのヴェスタの動きとどう違うのかが知りたい(
22:09 (emeru) そして見つかるヴェスタの不具合(
22:23 (DRM) まだ出来てないけど、皆さんありがとうございました
22:24 (vesper) ~はよく分からん所あるみたいね。 いえいえ~。
22:24 (DRM) まさか1時間半も議論することになるとは思ってなかったw
22:26 (emeru) 一応聞くけど、その動作で変数は未使用?
22:26 (DRM) 回数制限用に。もしかしたらフラグにも使うかもしれない
22:26 (emeru) ふむ、了解っ
22:28 (emeru) 案外単純に作った方が成功するかもしれない
22:29 (DRM) せやねー
22:29 (DRM) もうTimeでも良いのかもしれん
22:33 (emeru) ウチの子も空中ジャンプ回数制限つけようかなぁ・・・
22:34 (emeru) しかしなぁ。。機動力がウリだし回数制限は・・・うむむ・・・
22:47 (vesper) これで行けるかも。 Trigger1 = Command = "Air-Jump" && Command != "holdup" && (Command != "~UF" && Command != "~UB" || Command != "~U")
22:49 (vesper) カッコの||より前が8から7や9にレバー移動した時のフラグ立つのを防止、||の後ろは7や9から8にレバー移動した時のフラグ立つのを防止
22:49 (vesper) KFMの空中ジャンプに似せたつもり。
22:54 (DRM) 試してみるマン
22:55 (vesper) あ、Air-Jumpは~$Uにしてる
23:03 (DRM) おお、すげえ
23:03 (DRM) ありがとうございます!
23:03 (vesper) いえいえ~
23:35 (vesper) あ、勘違いしてたかも
23:35 (vesper) Trigger1 = Command = "Air-Jump" && Command != "holdup"だけで済むかも
23:36 (vesper) こっちで試した感じではかわってない。
23:38 (vesper) 「方向キーは他の方向キーを押すと一旦離した判定される」 は起きるけど、「方向キーは他の方向キーを離しても一旦離した判定される」は流石に起きないや。 てか後者が起きたらキーの方向指定が生きてないことになるか。
23:38 (DRM) マジだ(
23:42 (vesper) Trigger1 = Command = "Air-Jump" だけにすると、↑キー押してる時に↓キー押すと反応してしまうのに、Trigger1 = Command = "Air-Jump" && Command != "holdup" にすると同様に押しても反応しなくなる謎(
23:48 (vesper) && Command != "holdup" を && Command != "/U" && Command != "/UF" && Command != "/UB"にしてやると、下キーを押すと反応するから $のせいなのかなぁ。 下キーが入力されてもフラグが立たなくなるのは。

1/18
22:42 (vesper) この前のコマンドの話だけど、command=~$Uのコマンドは 入力をUからUFにした時に離れた判定される理由は、 $Uが単にU,FU,BUの判定を同時に見てるだけだからかな。
22:43 (vesper) U→UFになる際にUが離れると判定が出て~Uが反応してしまうって感じで。

-Gethitvar(damage)/10

11/17
19:19 (Oracle) -Gethitvar(damage)/10
19:19 (Oracle) これって/10されてから-かな
19:20 (hitachi) -してから/10じゃないかな
19:21 (Oracle) お・・・じゃあ・・・
19:21 (Oracle) チェックしますかね・・・
19:21 (hitachi) -(-2147483648)/10 のLifesetで死ぬし
19:22 (hitachi) 10で割ってからだとマイナスしたら+のLifesetni
19:22 (hitachi) Lifesetになるから死ななくなる
19:24 (Oracle) ああ、そうですね

土煙のエフェクト

7/30
23:06 (mapelao) makedustの土煙のエフェクトって、内部処理で勝手に出る感じ・・・だよね?
23:10 (ni-san) うn
23:12 (mapelao) ふむん。。となると、土煙がドバドバ出てるのは、どっかでヘルパーが被弾してるからなのかな。。
23:12 (mapelao) 情報ありですm(__)m
23:15 (mapelao) 土煙出てる原因分かりました。一応報告までに、
23:16 (mapelao) bindtorootで、pos=0,-root,pos yにヘルパーをくっつけてたんですが、
23:16 (mapelao) 地上で本体がちょこまか動くと、pos y=0のまま被弾ヘルパーが地面引きずられるみたいで、
23:16 (mapelao) このせいで土煙が出ていたようです。
23:16 (hitachi) ああなるほど
23:17 (hitachi) なんか歩いてたら土煙出てることがあったけどそれが原因か
23:17 (mapelao) pos=0,-root,pos y-1にしたら、土煙消えたw

projとhitdefが同一Fで当たった時の処理

7/2
00:42 (simotsuki) projとかhitdefとかって
00:43 (simotsuki) 同一Fで複数のものが当たった時どうゆう順番で処理されるか誰か分かる…?
00:44 (hitachi) gethitvarとかは手前の領域から出したやつが優先ってエメル氏が言ってた気がする
00:46 (simotsuki) とかっていうのはpausetimeとかground.velocityとかの事ですか?
00:47 (hitachi) 自分で調べたわけじゃないからそこまで細かくはちょっと
00:47 (simotsuki) なるほど

01:34 (simotsuki) ちょいprojとhitdefが同一Fで当たった時の処理調べてみたけど
01:35 (simotsuki) どうにも基本的には後から出した物が後に処理されてるみたい
01:35 (simotsuki) ただprojとhitdefだとどうにもhitdefが先に処理されてる模様
01:46 (ni-san) うn
01:46 (ni-san) でないと筆頭がダメージ受けナイからのw
01:47 (simotsuki) 筆頭は普通にhitdefを当て身出来たら仰け反ってるだけじゃありませんでしたっけ?
01:47 (ni-san) ちなみにproj同士は同時ヒット記述認識しますよn
01:48 (ni-san) あーと筆頭を例に出したのは
01:48 (ni-san) hitdefとprojリバサしようとするとhitdefが優先されるんす
01:48 (simotsuki) いや、projリバサ出来ないじゃないですかw
01:48 (ni-san) リバサじゃねえ
01:48 (ni-san) おばライド
01:49 (ni-san) 筆頭にはないけど(死
01:49 (ni-san) オバライドとリバサを展開するとリバサが優先される
01:49 (ni-san) で筆頭がそれを使ってるのは本体じゃなくて
01:49 (ni-san) みらくる
01:49 (ni-san) の所得でそれをやってるはず
01:50 (ni-san) オバライドでアニメ所得して リバサで確定させる
01:50 (simotsuki) リバサが優先されるのってリバサが元々当たり判定よか優先度高いからじゃないです?
01:50 (simotsuki) もしそうじゃなかったら無敵つけないと当て身出来なくなっちゃいますし
01:51 (ni-san) その関係でhitdef優先なんじゃねいかなーと予想
01:51 (simotsuki) ふむむ
01:52 (ni-san) あんまりくわしいことはわたしもわからんw
01:53 (simotsuki) うーんよくわかんねw
02:20 (simotsuki) 今度じっくり調べよ。意味不明な所がいくつも出てきおった

ステートやファイルの読み込みと処理順

6/13
21:55 (teki) あれ、闇人七夜さん、[Statedef -2]が2つある。それでも動くんですね。
21:58 (YANMAR) どういう処理になるんだったっけ…
22:00 (ryusei_) def ファイルの st の順番によって変わる
22:01 (YANMAR) とすると元からあるsystem.cnsの方が読み込まれてないのかな
22:02 (ni-san) こばーん
22:02 (ryusei_) stは若い順から読み込むから statedef のが被ってるのがあると若い順から適応される
22:03 (ryusei_) http://mugenbinran.web.fc2.com/tips.html#order
22:03 (vesperAFK) [URL] 豆知識【MUGENの便覧】
22:03 (teki) なるほど。
22:03 (ryusei_) ここの 【読み込みと処理順】 を見れば早かった気がした

movetype!=Hかつlife=0でaliveが0になる時にfall=1になって5030

4/14
20:18 (hitachi) うん?hitfall関係なしにmovetype=Hだと5030に移動しないのか?
20:57 (hitachi) んん?いろいろ弄ってるうちによくわからんことになってきた…
20:59 (hitachi) roundstate=3の時はlose=1になってるのに4になったらlose消えてるし
21:00 (hitachi) movetype=H維持とか絶対参考になるデータないだろうしなあ
21:47 (hitachi) life=0で5030に飛ぶ条件がよくわからんなあ
21:48 (hitachi) movetype=Hの時以外はhitfall=1でも飛ぶし
21:50 (vesper) ん?5030に飛ばない時もあるの? 1回確認しただけだからちゃんとは知らないんだけど。
21:54 (hitachi) life=0でaliveが0になる時にfall=1になって5030に飛ぶのですが
21:54 (hitachi) movetype=Hにすると5030に飛ばなくなるんです
21:55 (hitachi) 時止めはやってない状態でも同様です
21:55 (vesper) ほうほう。
21:56 (vesper) ヒット時の吹き飛びアニメをそのまま表示するためかなぁ?
21:56 (hitachi) じゃないですかねえ
21:59 (hitachi) hitfallとかstatetype=Lは関係ないようです
21:59 (vesper) ふむふむ。
21:59 (hitachi) とりあえずわかってるのはそのくらいです
22:00 (vesper) 了解です。ありでした~

MoveType=HかつHitFall=1の場合の内部AIの動作

4/9-10
01:38 (vesper) 31日の1件追加しました
01:41 (DRM) ああ、5120の話か・・・w
01:41 (vesper) うん、
01:42 (vesper) 一瞬ってのは分からなかったしなぁ。 あ、ラベル数増やして実験しようと思ったけど忘れてたなぁ。
01:44 (DRM) fm・・・
02:22 (vesper) 126ラベル登録してもliedown.time=600は最速で21Fが見れたぐらいかなぁ。 平均は30Fは超える。40Fも超えるかも?
02:24 (DRM) まーじでぇ
02:27 (DRM) Time=11くらいで起き上ったんだがw
02:27 (DRM) kfm
02:27 (vesper) 600でも?
02:27 (DRM) Yes
02:28 (vesper) え、普通のKFMが?
02:28 (DRM) うんw
02:28 (DRM) Watchモードね
02:30 (DRM) 6000にするとTime=26で起き上がる(
02:31 (vesper) ぬぬぬ
02:31 (DRM) わけわからんばいw
02:36 (DRM) 何かMUGEN本体の設定でもあるのか・・・?
02:38 (vesper) ん~、cfgのDifficultyって8です?
02:39 (vesper) こっちでKFM試しても90Fはかかること多いなぁ
02:40 (DRM) 4でした
02:42 (vesper) う~ん、これは違うみたいだなぁ
02:42 (vesper) 新鮮なMUGENを仕入れてくるか(
02:44 (vesper) 調べ方って5110に
02:44 (vesper) [State ]
02:44 (vesper) type=null
02:44 (vesper) trigger1=var(3):=var(3)+1
02:44 (vesper) を入れて確認で大丈夫なはずだよなぁ
02:44 (DRM) 多分・・・ 自分はデバッグのTimeしか見てない(
02:45 (vesper) ←いちいちコマ送りするのが面倒な人
02:45 (DRM) まぁやるときゃやるさw
02:48 (DRM) それでもやったけど、変わらないな・・・
02:53 (vesper) mugen-hiを新たに解凍してそれで実験したけど、やっぱりかなりかかる
02:53 (vesper) 3桁も結構いく
02:54 (vesper) 最速27だけど、ダントツ状態。
02:54 (DRM) まーじか・・・
02:54 (DRM) ちょっと明日自分も試してみよう

23:21 (vesper) そういえばDRMさん、5110の試しました?
23:21 (DRM) あー、試したよ。変わらなかったw
23:22 (vesper) ありゃ。
23:22 (vesper) う~ん、なんで違うんだw
23:23 (vesper) KFMの5110に
23:23 (vesper) [State ]
23:23 (vesper) type=null
23:23 (vesper) trigger1=var(3):=var(3)+1
23:24 (vesper) を入れて5110のステートに何Fとどまるかを確認する実験。
23:26 (vesper) [date]のliedown.time = 60 を600にしたところ、自分の場合は3桁とかになるのに、DRMさんの場合20ほどで5120に移動する不思議。
23:26 (vesper) あ、自分の場合でも3桁は遅いほうだけど。
23:27 (vesper) コマ送りしなくても分かるよってだけですからねぇ、↑の変数を確認する理由はw
23:27 (DRM) まぁ一応ねw
23:28 (vesper) まぁ、そんな訳で他に実験した方いたら大体の平均と最速を知りたい所w
23:30 (DRM) 是非知りたいw

01:20 (vesper) ふと思いついて実験
01:21 (vesper) ひょっとしてDRMさんってfall=1の攻撃当てて5110に送ってる?
01:23 (DRM) その可能性は大
01:23 (vesper) 自分はchangestateで直接5110に送ってたんだけど、ひょっとしたらそれが原因で差が出てるかも?
01:24 (vesper) こっちで試しにfall=1を当てて5110に送った場合は20台で5120に行ってるっぽい。
01:25 (DRM) oh...
01:25 (DRM) なったw
01:25 (DRM) 倒れたぞ
01:27 (vesper) ん、changestateだと長くなる?
01:27 (DRM) そうですねー
01:27 (vesper) と言うことはfall=1で送られた場合はまた別のパラメータの影響なのかぁ
01:27 (DRM) 大体、LieDown.Time=60でTime=20~40くらいに起き上がる
01:28 (vesper) こっちでもそうだったかな?
01:28 (vesper) たしか。
01:28 (vesper) [State ]
01:28 (vesper) type = HitDef
01:28 (vesper) trigger1 = time=1
01:28 (vesper) attr = S, NA
01:28 (vesper) fall = 1
01:28 (vesper) ちなみに当てたHitdef
01:29 (DRM) Fallの有無が原因だったのか・・・
01:29 (DRM) カンフーアッパーだったからFallあるな
01:29 (vesper) 有無というか5110に行くのって普通Fall=1の攻撃食らった時じゃないかなぁ?
01:30 (vesper) 投げでもあるかもだけど。
01:32 (DRM) しかしあれだな。検証方法について最初に伝えておくべきだったな・・・w
01:33 (DRM) 攻撃食らわして5110が普通だから、それでやってるものだと思ってしまっていたw
01:34 (vesper) CPUで待つのが面倒だったから横着した結果がこれである(
01:35 (vesper) ん~と、通常の打撃の場合はDRMさんのような結果で、投げの場合は自分のような結果になるみたいですね
01:36 (DRM) ですな
01:39 (ni-san) movetypeHを経由するかどうかじゃぬ?
01:39 (vesper) 5110自体がHではあるんですけど、それより前のステートってことです?
01:40 (vesper) ちょっとやってみます。
01:40 (ni-san) うn
01:42 (vesper) ん~、関係無さそう?
01:42 (vesper) [statedef 210]
01:42 (vesper) movetype=H
01:42 (vesper) [state ]
01:42 (vesper) type = changestate
01:42 (vesper) value = 5110
01:42 (vesper) trigger1 = time=2
01:43 (vesper) ってステートに飛ばしてから5110に飛ばしてみましたが変わらないですね。
01:43 (ni-san) ないかー
01:57 (vesper) hitfall状態は関係ないみたいだなぁ。210にhitfallset入れてみたけど短くならない。
02:04 (vesper) 今のところfall=1で送るのと、targetstateやchangestateで直接送るのとでは前者のほうが圧倒的に短くなる、。
02:05 (vesper) 5110に行くまでは5070→5071→5110
02:21 (vesper) う~ん、分からん事増えた(
02:21 (vesper) fallつけてもキー入力での短縮割合は変わらない。違いはどこから来てるんだろ・・・。

4/14
19:50 (vesper) やっと5110から高速で5120に移行する原因が分かった
19:50 (DRM) おお
19:50 (vesper) 内部AIはHitFall=1だと通常の50倍ぐらい動く
(注:50倍はx+yの率です)
19:51 (vesper) だから高速に時間短縮して起き上がる。
19:51 (DRM) 50倍w
19:51 (DRM) 張り切りすぎだろw
19:51 (vesper) まぁ、そのくらい動かないとrecover押せないからねw
19:52 (vesper) 多分ラベル押しの方は頻度変わらない。
19:52 (vesper) まだ細かくは調べてないけどね。
19:53 (DRM) 面倒な仕様だな・・
19:54 (vesper) あと、Fall=1の攻撃が、ステート奪ってHitFall=1にした後直接5110に送った場合より時間が短くなるのは、どうも5100と5101ステートのボタン押しも時間短縮になるのが原因
19:55 (hitachi) 今内部移動防止のためにmovetype=Hとhitfall=1にしてみてるんですけど
19:55 (vesper) ひょっとしたら5100-5110全部ボタン押しで時間短縮かも?まだ調べてないけど(
19:56 (hitachi) 確かに攻撃頻度がめっちゃ上昇してる
19:56 (vesper) ちなみに、起き上がりの時間短縮条件はstatetype=Lもいるから注意ねw
19:57 (DRM) StateType=Lもか。
19:58 (DRM) MoveType=H&HitFall=1で内部AIが働く。その場合はStateType=Lは関係ない?
19:59 (vesper) たぶん? 自分はまだ見てないです。
20:00 (DRM) 自分もちょっくらまた調べるかの。
20:05 (hitachi) statetype=Lは関係ないですねえ
20:52 (vesper) ダウン時間の短縮はstatetype=Lかつmovetype=Hを満たした時から始まるみたい。
20:53 (vesper) ダウン時間自体は5110でカウントだけど。
21:22 (hitachi) Hじゃないとhitfallsetできないんじゃなかったっけ
21:28 (vesper) movetypeに関わらずhitFallは1になるみたいですね。

4/21
23:23 (vesper) ぬー、通常に比べて3倍内部AIが動いてるみたいだけど、AIフラグ用に利用してもほぼ効果が無くて悲しい。。。
23:57 (vesper) IRCでは前にも言ってたけど、MoveType=HかつHitFall=1の場合の内部AIの動作について追加しました。 http://mugenbinran.web.fc2.com/AIFlag.html#19
23:57 (vesper) [URL] 内部AIとAIフラグについて【MUGENの便覧】

StateNo=5120への移動

3/31-4/1
23:31 (DRM) 5120へ移動する条件って何だ・・・?
23:32 (ni-san) ふっとび?
23:32 (ni-san) いやダウンだっけ
23:33 (ni-san) ダウン後の起き上がりだったかなぁ ちょっとまってね
23:33 (ni-san) 5120 起きあがり動作
23:33 (ni-san) うn
23:34 (ni-san) 5110でほっといたらここいくはず
23:34 (DRM) どういう条件でですか?
23:34 (simotsuki) 確かtimeだったと思う
23:35 (DRM) 5110で一定時間経過ですか
23:35 (simotsuki) 以前常時ステ抜けで5110に行ってたらそのまま移動しなかったから
23:35 (simotsuki) それと一部のコマンドを押すと早く起き上がるっぽい
23:35 (simotsuki) だからAI戦だと相手の起きる速さが安定しない
23:36 (DRM) 一瞬で起き上っちゃうんだけど、何でだろう
23:37 (ni-san) 5120がないとか
23:37 (DRM) 5110に移動した後
23:37 (ni-san) Lじゃないとか
23:37 (ni-san) アニメないとか
23:37 (simotsuki) うーん、早くっていってもさすがに一瞬では起きないはずw
23:38 (DRM) う~む
23:41 (DRM) オキさんが記事書いてた
23:41 (DRM)http://oki6761.blog23.fc2.com/blog-entry-1492.html
23:41 (vesper) [URL] 熄の箱庭 戯言~禍霊夢の憂鬱~
23:41 (DRM) けど、オキさんの言うDownTimeって何だ・・・?
23:43 (simotsuki) mugen本体に設定されてるとか?
23:43 (vesper) 経過timeじゃないかな? LieDown.Timeは[date]での設定された最大値のことだからそれと分けてるのだと思う。
23:45 (DRM) う~ん、でも5110でTimeが1経過すると5120に移行しちゃうんだよなぁw
23:46 (vesper) LieDown.Timeは1より大きく設定してるんです?
23:46 (DRM) 60ですね。一般的
23:47 (vesper) う~ん、なら5110のアニメの長さってどうなってます?
23:48 (DRM) だけど5とかに伸ばしてもダメだった
23:48 (vesper) う~ん、じゃあこれも違うのかぁ
23:50 (vesper) 自分も試してみよう
23:54 (simotsuki) うーん、分からん
23:55 (simotsuki) どの攻撃受けても1Fで起き上がる?
23:56 (DRM) う~ん、たまに5110のAnimが終わった時に起き上がってる気がする
23:57 (DRM) あれだ、5110のアニメにならない時だけすぐ起き上がってる気がする
23:58 (simotsuki) コマンドで早くなってるヤツの事なのかな~。でもそこまで早いとは感じないし
00:00 (vesper) 5110にnullしか無いキャラはliedown.time=0なら即5120に移動。liedown.timeが1以上なら移動しないなぁ
00:01 (DRM) アニメ指定も無し?
00:01 (vesper) うん
00:02 (DRM) 起き上がるなぁw
00:02 (DRM) 因みに今やってるのジェネさんですね
00:02 (simotsuki) 現行版でもなる?
00:03 (DRM) なると思う
00:03 (simotsuki) 記述忘れてないといいけど…w
00:04 (DRM) 起き上がらなくなったw
00:07 (DRM) MoveType=Iだと起き上がらないのか・・・?
00:07 (DRM) MoveType=H以外だと起き上がらないな
00:09 (DRM) AnimTimeとかは関係なさそう
00:09 (vesper) MoveType=Hの時のみliedown.time経過で5120移動?
00:11 (vesper) MoveType=Hにしたらliedown.time経過で5120に移動するようになったけど、何か条件揃うと即移動するのかなぁ?
00:12 (DRM) LieDown.Time大きくしたら寝転がったままになったな・・・
00:12 (DRM) 60→600
00:12 (vesper) こっちは60なら60Fかかるから、何かで短縮されてる?
00:14 (DRM) 600にするとTime=20くらいまで寝てる
00:15 (vesper) 30分の1かぁ
00:17 (DRM) 因みに今までのこと全部Watchモードでの話よ
00:17 (simotsuki) ふむ
00:20 (DRM) トレーニングモードだと確かにLieDown.Timeが反映されるね
00:22 (DRM) あ、もしかしてコマンド云々で起き上がりが速くなるってそういうことなのー!?
00:23 (vesper) Type=Lならキー入力で短縮されるっぽい?
00:23 (vesper) S,C,Aだと確認できてない。
00:23 (simotsuki) うーん、やっぱコマンドの事かもしれないなw
00:23 (simotsuki) ウォッチなら勝手にコマンド入るし
00:23 (vesper) うん
00:23 (DRM) 異常に早くないか?w
00:24 (simotsuki) そこそこ早くはなるよw
00:24 (DRM) うっそ~ん
00:25 (DRM) 協力どうもありがとうございました。
00:25 (DRM) 別ステート作るしかないか・・・
00:27 (simotsuki) あいさ~
00:27 (vesper) 最大値がliedown.timeで、時間内に一定回数キー入力で起き上がるとかなのかなぁ?
00:28 (DRM) まぁ最大値は恐らくLieDown.Timeでしょうね~
00:28 (simotsuki) 以前その仕様でかなり頭悩ませた覚えがある
00:29 (DRM) ん~、5111にしたら問題無く寝転がってくれるな
00:29 (simotsuki) とりあえずこうゆうのは記述にしておいて欲しかったw
00:30 (simotsuki) 仕様として組み込まれると面倒さ~
00:30 (DRM) レバガチャで早くしようってんで内部処理になったんかね~
00:32 (DRM) とりあえず新技やっと組み込めるわ~
01:36 (vesper) ん~、movetype!=Hで残り時間はリセットされるのか。
03:49 (vesper) 残り時間はキーを押すまたはキーを話す際に3/4倍になる。 押しっぱなしは関与しない。
03:52 (vesper) 細かくは押したときは
03:53 (vesper) (残り時間-押した時の経過フレーム+1)*3/4
03:53 (vesper) 離したときは
03:54 (vesper) (残り時間-押した時の経過フレーム)*3/4
03:54 (vesper) になってるなぁ。
03:54 (vesper) コマンドの通常と~の仕様の違いのせいかもしれないけど。
03:54 (vesper) DRMさんのLieDown.Time=60で即移動はコマンドだけではないみたいだなぁ。。。

参考:不具合・対策まとめ > StateNo移動原因[MUGENの便覧]

内部処理によるステート移動

3/21
21:05 (hitachi) 内部処理で52に飛ぶ条件ってなんでしたっけ
21:06 (YANMAR) pos y < 0
21:06 (mapelao) physics=aでpos y>=0とかじゃなかったかな
21:06 (YANMAR) 不等号逆かも
21:06 (YANMAR) >=かー
21:06 (hitachi) どうもです
21:06 (hitachi) 内部処理さん空気読んでくれないですかねえ
21:07 (mapelao) ねー。凶悪系には内部処理がうざくてしょうがない
21:07 (YANMAR) どれだけ内部処理に抗うかだからねぇ
21:07 (mapelao) 勝手に歩くのとかは防ぐことできても、こういうのはassertspecialでもどうにもならん絶望
21:08 (Sance_) Physics=Nでいい
21:08 (YANMAR) physics=aを使わないようにだね
21:08 (Sance_) というか、ぶっちゃけPhysicsイラネ
21:09 (Sance_) physicsの処理って摩擦、落下速度、着地だけだったと思うし
21:09 (dry_ice) 週一回にあるメンテ
21:10 (YANMAR) 摩擦とか落下とかは自分で計算しちゃってるなぁ
21:10 (hitachi) なにー今度は50に飛んだよー
21:10 (Sance_) 空中ジャンプ?
21:10 (mapelao) 自動計算あるから便利のはずなのに、神にとってはループの地雷にもなるクソ仕様っすな
21:10 (Sance_) いや、じゃんぷか
21:12 (Sance_) ジャンプに移行する内部処理はどうしようもないです・・・w
21:12 (misty) 2万か・・・じゃあかなり迷惑だな・・・
21:35 (vesper) 遅いですが52に飛ぶ条件はhttp://mugenbinran.web.fc2.com/error.html#21
21:35 (vesper) [URL] 不具合・対策まとめ【MUGENの便覧】
21:36 (vesper) だからphysics=aでもvelyが負(上に移動)なら飛ばないはず。

KO判定

1/15
23:14 (okihaito) 内部移動OFFにしたい…
23:15 (hitachi) わかる
23:15 (hitachi) 5030移動のせいで常時time偽装が…
23:15 (okihaito) 5030って死んだ時にしか行かなくね?
23:16 (hitachi) 真Alive偽装中に5030になるせいでtime偽装が解除されてしまうのが
23:17 (okihaito) aliveついでにtime増やせば良いんじゃ?
23:18 (okihaito) もしくは凍結とか
23:19 (okihaito) 凍結中内部移動offなったかな…うろ覚えだわ
23:19 (hitachi) 凍結させるとAliveが0にならないですからねえ
23:19 (okihaito) いや凍結中なら超即死があるじゃない
23:20 (hitachi) なんかAliveが0だとその場でKOになるみたいなんです
23:20 (okihaito) それが普通だね
23:21 (okihaito) …真って事だから%n、捏造じゃないんか?
23:21 (hitachi) life=0で個別終了時にAliveが0になってもそのフレームの最後まではKOの判定がないみたいなんで
23:22 (hitachi) でも個別終了時にalive=0だとKOになるっぽいんですよ
23:24 (hitachi) たぶん内部処理的にAlive=0ならloseKOを1に→life=0ならaliveを0に→Alive=0なら5030に移動みたいな処理順になってるのかと
23:24 (okihaito) life=0による内部処理のalive変動ほ全プレイヤー処理後でしょ
23:25 (hitachi) 真Alive偽装は個別でlife=0で自殺→ヘルパーで蘇生って流れでやってます
23:26 (hitachi) Alive操作で自殺すると蘇生してもKOになるんです
23:27 (okihaito) 最前ヘルパーと最終ヘルパーでalive操作した方が良くね?
23:28 (hitachi) 敵本体がenemy,aliveで参照する時に0になってるのが必要なんで
23:29 (hitachi) !enemy,aliveのNoko突破が肝なんだと思ってるんで
23:30 (okihaito) 最終ヘルパーから自殺でもKO出るんか?
23:31 (okihaito) 個別処理終了時にalive=0だとKOなんだろ?

MUGENのバウンド時強制無敵、特殊statedef

1/14
10:59 (vesper) なんか特定条件化で5200ステート行くと、内部処理でムテキングになるとか?
11:00 (simotsuki) ん?そうだったっけ?
11:02 (simotsuki) 5100辺りなら分からなくもないんだけどw
11:03 (vesper) 地上受け身を受け身狩りされて再度地上受け身を取ると多発するのだとか。 地上受け身に無敵がない場合、無敵が付与されるものの解除がされないとか
11:05 (vesper) 読みにくいけど、地上受け身に無敵が無いと起こるものみたい。 んで、受け身から無敵を無くしたいならNotHitByをtime=0でさせとけばいいらしい
11:05 (simotsuki) うーん、それは複数のキャラでなった?
11:07 (vesper) う~ん、聞いた話だけど確認されてるのは1キャラです
11:08 (simotsuki) ほう~
11:09 (simotsuki) mugenも特定番号のステートで変な機能付与されてる事あるし
11:09 (simotsuki) ちょっと調べてみるかねィ
11:18 (simotsuki) 受け身多分なって無いと思うw
11:19 (vesper) ふむ
11:19 (vesper) 聞いた話だから細かい所分からんのよね
11:21 (simotsuki) ちょっと完璧に再現できたかは怪しいから絶対とは言えないけどね
11:22 (simotsuki) 後、確かmugenには地上受け身は確か無くて
11:22 (simotsuki) 5200は低空の空中受け身だと思うから、そのキャラの仕様が関係してるっていう可能性があるかも
11:25 (vesper) 一応nothitbyやhitbyは常時監視やそのステートにはないのに起こるらしいから、流用したことで変に噛み合ったのかなぁ
11:27 (simotsuki) 何か記述ミスか、それとも未知なる仕様か
11:27 (simotsuki) そうゆう意味不明な仕様を調べるのは好きだから興味はあるw
11:36 (simotsuki) ぬーこっちで再現出来ないのが悔やまれる
11:40 (simotsuki) ん?このキャラ空中受け身を地上受け身に変えてるのかw
11:47 (simotsuki) ん~?
11:50 (simotsuki) あ~もしかしたら原因分かったかも
11:51 (simotsuki) ちょっと想像の域を出ないんだけど
11:51 (simotsuki) 地上受け身を受け身狩りされて再度地上受け身を取ると多発するのだとか。 地上受け身に無敵がない場合、無敵が付与されるものの解除がされないとか
11:52 (simotsuki) これってもしかして数回バウンドした後で付与される無敵を
11:52 (simotsuki) リセットされるタイミングを無視してステート移動して
11:52 (simotsuki) そのまま無敵になってるんじゃないかな
11:54 (simotsuki) 記述見た所-1で独自にステートに飛んでるみたいだからその可能性はあると思うんだよねん
11:54 (vesper) ふむぅ。lunaさんが記事にしてた4回バウンドで無敵のやつかなぁ?
11:55 (simotsuki) 4回だか3回だか忘れたけどダウンした後何回か追撃でダウンさせられると無敵になるんよね
11:55 (simotsuki) ここが北斗キャラがバウンドする時にステート奪わなきゃいけない最大の理由さw
11:55 (vesper) バスケ不可になるもんねw
11:56 (simotsuki) その無敵がどうゆう風に管理されてるか分からないし継続するってのは聞いた事は無かったけど
11:56 (simotsuki) その何度か攻撃を受けるって状況的に
11:56 (simotsuki) 有り得ると思うぜよ
11:57 (vesper) 確かに
11:57 (simotsuki) ただこれ確認の仕様が無い気がするんだよねw
11:57 (simotsuki) 結局想像の域を出無くなっちゃうw
11:59 (vesper) 確認取れないとそうなっちゃうかぁw
11:59 (simotsuki) この無敵は内部処理だからの~。永久防止用だろうけど有難迷惑w
12:01 (simotsuki) む、いや確認出来るかも
12:02 (vesper) 自由度の高いコンボゲーだと結構邪魔になりそうだねw お
12:06 (simotsuki) 出来た
12:06 (simotsuki) 予想通りだった
12:07 (simotsuki) バウンド回数で無敵になった後にnothitbyやhitbyを介さないとその無敵が永続する
12:08 (simotsuki) hitbyとnothitby使えば解除できるっぽい
12:08 (simotsuki) これ面白いから記事にしとこw
12:09 (vesper) ふむふむ。
12:12 (vesper) そういえば、あとBKさんが5150の仕様を纏めてた。 5150の仕様(現時点でわかっているもの):p2系統のトリガーが反応しなくなる、振り向き処理が行われなくなる、time=0でtarget破棄処理(永続ターゲットバグに対しては無効)、相手側のMugen内部AIのcommand処理がされなくなる。 TeamMode=simulかつ!aliveでtime>0の時にScreenBound valu=0状態になる ただし、これらの仕様はhitpausetimeがあると無効化される
12:13 (vesper) 長すぎた(
12:15 (simotsuki) 120~155、5100、5150は特別なステートっぽいからねw
12:15 (simotsuki) 後52もか
12:16 (simotsuki) 一応0,11,51もそうか
12:18 (vesper) 0,11,51,52も特殊な内部処理があったりするの?
12:22 (simotsuki) 0、11,
12:23 (simotsuki) 51はただの140からの帰還用だから微妙かも。52は速度Yとposyが0以上で状態がAだったら強制的に移動させられる先ってくらい
12:24 (vesper) ふむふむ
12:27 (vesper) あとは特殊な処理は無さそうだけど、10、20、40のコマンド入力で自動移動と、5900も試合開始時にいるstatedefって意味では特別なのかなぁ
12:28 (simotsuki) それもあったね~
12:39 (simotsuki) あ、そいやさっきの4回バウンドだけど
12:40 (simotsuki) 2回で無敵になったよw
12:40 (vesper) 2回なのかw
12:41 (vesper) http://lunatic284.blog90.fc2.com/blog-entry-5386.html 自分が言ってたのはこの記事ね
12:41 (vesper) [URL] lunaの倉庫 // 地面でのバウンド限界を決める無敵について
12:41 (vesper) というかさっき貼っとけという話しである(
12:43 (simotsuki) 回数が違った理由は分からぬゥ、けどこっちは一度バウンドさせてからもっかい跳ねあげたから
12:43 (simotsuki) そこら辺が理由なのかも
12:44 (vesper) ふむ、ヒット数とはまた別の条件なのかな
12:44 (vesper) 1回目ダウン食らってからの時間とか
12:52 (simotsuki) statetype=Lになった回数とか?
12:52 (simotsuki) いつかちゃんと調べるかな。ちょっと今はやる気にならんけどw

参考:MUGENのバウンド時強制無敵[キャラ製作記録]

 |   |  次のページ

 検索フォーム


 全記事表示リンク

 全記事表示(500件ずつ)


 プロフィール

vesper

Author:vesper

IRCチャンネルの
#凶悪MUGEN
#凶悪MUGEN_雑談
のログからMUGENに関するものを編集・公開しています。
修正した方が良い箇所があった場合は知らせてもらえると助かります。
MUGEN界隈からはリンクフリーです。
その他からのリンクはご遠慮ください。
このブログをリンクに追加

IRCへの入り方などは
IRCに関する記事
をご覧ください。

簡易凶悪MUGEN IRC情報
・ホスト名
 [irc.friend-chat.jp]
・ポート番号
 [6664]
・チャンネル名
 [#凶悪MUGEN]
 [#凶悪MUGEN_雑談]
 (以下はお好みで)
 [#凶悪MUGEN_艦これ]
 [#凶悪MUGEN_スマブラ]
 [#凶悪MUGEN_麻雀]
 [#凶悪MUGEN_緋想天]
 [#凶悪MUGEN_アカツキ]
 [#凶悪MUGEN_小説]
 [#凶悪MUGEN_絵チャ]

・推奨IRCクライアント
 LimeChat2


 カテゴリ

記述の子カテゴリは目安程度に考えてください。

 最新コメント


 最新記事


 カウンター

累計の閲覧者数:

現在の閲覧者数:

 RSSリンクの表示


他ブログ更新情報(最新70件)

仕様上、下記のリンク一覧でサイトリンクにあるサイトはこの一覧に出ません。

Twitter


基礎リンク集


リンク

サイトに断り書きがない限りリンクさせてもらっています。
リンクしてほしくない場合はお気軽におっしゃってください。

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。