【MUGEN凶悪】M.G.T.【FT-009(RF)】


負けるだろうが、さ~てウィッチ相手にどれだけ粘れるかな~

対 S軋間
即死での専用済みなので
S軋間がとある技を出してくれるのを待つだけですね

対 エグゼリカ(パッチ入り)
こっちのエグゼリカを見ると3DS版DQM2思い出すなぁ
それプレイしながらコツコツ専用してたので
パッチ入りエグゼリカの専用はそっちの思い出も半分くらい詰まってるんだよね

残機を減らせばいいんだけど、残機ごとに減る条件が違っているので
実質条件が99個あるような物なんだよね

対 サリエル
海外の殺傷力検定の相手として出てたキャラですね
その辺の相手は今では倒せるように調整済みなので(ry

対 旧鬼巫女
1ラウンドだけならそう怖くない
問題なのは2ラウンド目以降なんだよね。色々な要素があって(メロンは特に問題ないはずだけど)

対 深淵蛟理不尽モード
更新で専用の不具合が発生して条件満たせなくなったっぽいかな?これ
専用搭載したての頃は1P側、2P側両方でしっかり撃破確認してるし

対 ドールマスター
海外の殺傷力検定の相手として出てた相手なので(ry
こいつはMUGEN落ちがホント厄介なんだよなぁ

対 本気を出したリュウ
とある技(零の領域)で倒せるように調整してるんだけど
それだす前に終わっちゃった(´・ω・`)
耐性強化ONは未対応なのでそれ出てたら危なかった

対 天国(幼女)
天国(幼女)とはどういう相手だ?いつ戦える?(MUGEN脳)

対 ルナティック
相当前に専用したけど、即死で倒すのは結構厄介な相手だったっけなぁ

対 アルファゼロ
もしやとは思ったがやはり11Pか。細かい条件はアルファゼロのテキストに書いてあるのでそっちを見てね
ライフ25以下になってからの回復をどう突破するかが肝
記述の穴っていうかダメージ判断条件が甘いので
色々なルートで無理矢理突破可能です(3種類把握してるけど他にもいろいろあると思う)

対 クールビューティー秋姉妹
専用済みなので問題ないですね

対 雷霆暁
本体hitdefは本体のタゲを取らせるという意味でしか撒かない為
頻度がかなり低いんだよねぇ。故にこういう本体hitdefじゃないと削れないキャラには弱い

むしろアルファゼロ位の頻度でもアレくらい削れる事にびっくりだよ


という訳で結果は準優勝ですね
流石にウィッチは強かった

コメント

非公開コメント

名実ともに男神(男性神)最強になりましたなぁ
大会お疲れ様でした

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

>>名実ともに男神(男性神)最強になりましたなぁ
他の男神達は本戦に出場すら出来ませんでしたからねぇ…w
まぁでも汎用殺傷力ではアルファゼロを上回ってる男神がまだいるので
真の男神最強はまだ先かな

>>管理人のみ
var(X)||Y は

trigger1=var(X)
trigger2=Y

これと同じ意味ですね。主に記述の簡略化の為に使用してますね
こうしないとtriggerが物凄く増えたり、ややこしくなったりしますし

例としては||この記述を用いると
trigger1=!(var(X)&4096)&&!(var(Y)&128)
trigger1=(var(X)&512)||(var(X)&1024)||(var(X)&2048)
trigger1=var(X):=(var(X)|4096)

||この記述を用いないと
trigger1=!(var(X)&4096)&&!(var(Y)&128)
trigger1=(var(X)&512)
trigger1=var(X):=(var(X)|4096)
trigger2=!(var(X)&4096)&&!(var(Y)&128)
trigger2=(var(X)&1024)
trigger2=var(X):=(var(X)|4096)
trigger3=!(var(X)&4096)&&!(var(Y)&128)
trigger3=(var(X)&2048)
trigger3=var(X):=(var(X)|4096)
こうなったり


「リミカの様にhitdefを使っていてもターゲットにならないようにする」ですが
リミカ自体は普通にタゲ取られるし、ステ抜けも用いてます

恐らく一番の違いは「タゲを取られても、タゲを取られてないかのように動作させてる」という部分ですね
これは記述になれない内はかなり難しいし
記述を加えるのも、動作の確認、修正も面倒なので
(ステ抜けの様に『常時監視にいれて終わり』ではなく『全個別ステートを書き換える必要がある』)
まだ最初の内は手をつけない方がいいですね

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

>>管理人のみ
例えがややこしいのはすみません(´・ω・`)
意図は伝わったみたいなので良かったですが

取られてないように見せるために全個別ステに入れるのは
部分的には正解ですが、それだけで解決する様な単純なものではないです(爆

最低限必要なのは
・ステ抜けをするという事は、「ステ抜けする度timeがリセットされる」という事なので
timeの代わりになる記述が必要
(animelemで代用できなくはないが、他にもっといいトリガーがあるのでお勧めしない)

自キャラではanimelemtime(1)やanimelemno(0)等を使用してます

・「今現在のanimを用いてるステートに正確に返す」為に
元のステートの判断材料となる記述が必要

自キャラでは変数を用いて判断してますが
他にもanimとstatenoを統一してanimで判断したり等があります

この二つかな?

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

流石にここら辺の構造全体に関わる話は
実際にデバッグしてみないと原因の特定は相当厳しいなぁ…心当たりが多すぎる的な意味で(´・ω・`)
ここら辺はデバッグのやり方や、記述の処理をイメージできないと
原因の特定や解決法を見出せないからねぇ
(特にこれなんて不具合が当たり前の様に発生するから)

とりあえず思い当たった原因を並べると
・凍結が原因で処理がおかしくなる(ignorehitpause=1がない)
・ステ抜けするたびanimの処理がリセットされる所為で、凍結時はキャラが消える
・まだ構造がステ抜けに対応しきれてないので、ステ抜けするたび不具合が生じキャラが消える
・そもそも記述の処理がまだ不十分(不完全)で、普通に不具合でanimが表示されない
こんな感じになるかな?

とりあえずこの構造が出来ていれば
「常時監視で常時ステ抜けしてても普通に動作する」ので

常時監視で常時ステ抜けをして、何もしてこない相手(棒立ちKFM等)で動作に支障がないか確認

(ここで動作に支障があれば、構造自体がまだ不十分)

その後、常時当身を取って来る相手に動作に支障がないか確認

(ここで動作に支障があれば、凍結関係に不備あり)

こんな感じでデバッグするのがお勧めかな?




ちなみに宣告とか強制宣告で負けるのはそれとは全く関係なく別の要因です
タゲを取られた状態で死の宣告に耐えるにはガードステート(stateno120~155の事)にある
「targetlifeaddやtargetstateなどを受けなくなる」仕様を使います
故に、死の宣告に耐えるなら試合終了後ガードステートに移動させるようにすればいいですね
(強制死の宣告はそれだけではダメですが…)

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

ほむ、情報としてはまだ不足だけど
原因は結構特定されてきたかな。やっぱ実際にデバッグした方が(ry

アニメが進んでるのにanimtime変数が止まってるなら
その辺が原因っぽいかな?
こういう場合はまず記述を読み込めているか、読み込めているなら
どこの記述に引っかかってステコンが機能してないか
調べる事ですね

こちらがやってる手法としては
[Statedef -2]
[State ]
Type=DisplayToClipboard
trigger1=!ishelper
Text="gametime %d"
Params=gametime
IgnoreHitPause=1
↑これで値が増加し続けてれば時止めは受けてない


[State ]
Type=AppendToClipboard
trigger1=!ishelper
Text="\n mae:%d"
Params=var(X)
IgnoreHitPause=1
↑問題のステコンを読み込む前の変数を確認

[State 問題のステコン]
type=varset
trigger1=--------
trigger1=--------
var(X)=var(X)+1
ignorehitpause=1

[State ]
Type=AppendToClipboard
trigger1=!ishelper
Text=" ato:%d"
Params=var(X)
IgnoreHitPause=1
↑問題のステコンを読み込んだ後の変数を確認
[State ]
Type=AppendToClipboard
trigger1=--------
trigger1=--------
Text=" yomikomi:%d"
Params=var(X)
IgnoreHitPause=1
↑問題のステコンのトリガーが問題ないか確認
こんな感じで問題のステコンをデバッグ用のステコンで囲み
記述を調べる感じですね(代入を使えればもっと細かく調べられるけど)

ひとまずこれで…
・ステコンが機能してれば、他の記述でこの変数をリセットしてる可能性あり
・最初のgametimeが増加してなければ、時止めを食らってる
・最初のgametimeのデバッグしか読み込めてない時は
このさらに上の記述にあるステ抜け等で読み込めてない
・デバッグ上の変数が増加してないなら、問題のステコンのトリガーが機能してないので
一番下のデバッグのトリガーを一つずつ少なくする等で、問題のトリガーの把握
上記の事がわかるし、こういった原因追究が出来ますね




死の宣告耐性については
再現ゴジはそもそもタゲ取られない構造(本体hitdefを使わない&本体常時無敵)なので、死の宣告は食らいませんね
まぁこれも対策と言えば対策になりますが…
そっちのキャラは(恐らく)タゲ取られた上で耐える方法を効いているだろうし除外でw

リミカの方は一見普通に動いてて、ガードステートに籠ってないように見えるけど
準ステート固定を使っているだけでガードステートを使用してますね
(常時ガードステート等に送っても普通に動作させる事。常時ステ抜けと似たような物です)

一般的にはタゲ取られた上で耐える方法は
「ガードステートの仕様を使う」しかありません(断言しとく)
(例外として1P側限定で最終ヘルパーを使ったライフ管理があるけど)
アルファゼロ11Pですら一時期記述ミスでガーステへ移動しなかった時期があり
その時に死の宣告で即死されてますね

ガードステートを使う以外に「ガードステートの仕様」を発生させる方法がもう一つあり
そっちならばガードステートを使う必要ないですが
結局ガーステか、「ガードステートの仕様」を発生させたステートに固定させる必要があるので
どちらもほぼ同じですね

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

ふむ、時止め受けてるのは確認出来たか…
時止め受けてる最中はanimは進まないはずだから原因はそれだけではなさそうだね
(原因は一つとは限らないので)

まぁこういうのは地道に一つずつ修正していくしかないね
不具合を修正して更にデバッグすると、新たな不具合が見えたりするなんて事もよくあるので
(そして全ての元凶である根本的な不具合が、ただの記述ミスだったというのもよくある話)

本体の時止め耐性は

[State ];時止め耐性
type=pause
trigger1=!ishelper
trigger1=roundstate<2
time=2147483637
movetime=2147483637

ignorehitpause=1

[State ];時止め耐性
type=superpause
triggerall=!ishelper
trigger1=roundstate<2
anim=-1
time=2147483637
movetime=2147483637

darken=0
unhittable=0
ignorehitpause=1

これで赤文字で書かれてる時間分得る事が出来ますが
特定条件(攻撃を受けたりする事。アーマーでもダメ)で耐性が解除されてしまうので注意が必要です
(更に、このままだと相手も時止め耐性持ってない限り止まってしまうので
ヘルパーで時止め解除するのを忘れずに)


勝利演出、敗北演出をしたいなら準ステート固定を用いたり
ヘルパーに勝利演出、敗北演出をさせたり
ガードステートに勝利演出、敗北演出を両方入れればいいです
(リミカGeやアルファゼロは準ステート固定、リミカはヘルパー型、強化パッチブロリーはガーステ型を用いてた)

本体タゲ取られるキャラだと死の宣告耐性の為にガーステ固定にした所為で
勝利演出、敗北演出に困るっていうのはよくある(ry
(完璧にやりたいというなら勝利、敗北判断タイミング等含め)

「ガードステートの仕様」を発生させる方法はそれで合ってますね
一応入れて置いて損はないかな
(凍結時はガードステートにいても「ガードステートの仕様」は発生しないので
こっちの方法を使う必要があるから)
凍結解除がしっかりしてればほぼ必要ないけれど

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

問題児勢の場合だとまたちょっとややこしい事になるけど
突き詰めれば同じ時止め解除法で行けますよ

というかヘルパーの時止め解除は
最初だけなら本体よりも「安全」かつ「簡単」かつ「相手に不具合を与えず」時止め耐性を付加できます

やり方は
[State ];分身ヘルパー1
type=Helper
triggerall=!IsHelper
trigger1=NumHelper(1001)=0
name="Vegeta1"
id=1001
Pos =40,-270
postype=left
stateno=9999
Helpertype=player
keyctrl=1
ownpal=1
ignorehitpause=1
supermovetime=2147483647
pausemovetime=2147483647


赤字の部分を追加するだけです(再現ゴジは時止め耐性を付加させない為にあえて入れてない)
本体と同じ条件で解除される上、再び付加させるには本体と同じ事をしないといけないのがネックですが


ヘルパーが多いと管理が大変かもしれないけど
特定ヘルパーのみ(時止め解除ヘルパーなど)が使うステートを作って
特定ヘルパーはそこに籠らせたりすると楽ですよ

まぁ今回はデバッグが目的なのでヘルパーは無視して
本体だけに時止め耐性付加でもいいんじゃないでしょうか



「ガーステを利用する」のは必須だけど
方法はこれだけとは限らないから色々試してみればいいんじゃないかな

当時の強化パッチブロリーも意図的にガーステの記述を残してた上にヘルパー型の発想はなかったから
ガーステの元々の記述全てにroundstate<3のトリガーを追加
そして待機演出にroundstate=3、勝利or敗北演出にroundstate=4のトリガーを入れた記述を丸々ガーステに入れたりと
結構無茶苦茶したっけなぁ…

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

リミカが空中で止まったりするのは
空中浮遊するキャラだからで、それとは関係ないですね
高カラーの旧リミカが相手を倒した後に技を中断するのは
完全にそれが理由ですけど

強制死の宣告はぶっちゃけると
試合後にnokoやってれば防げます(爆)
それ以外だと時止め耐性をつけるとか、そもそもタゲ取られないようにするとかありますけど
あえて時止め耐性を入れてないならば、やはりnokoがベストかな
(つかそれしか方法はないんだけど)

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

強制死の宣告をnokoで防ぐ場合、『タゲ取られた(ステート奪われたら)noko』だと不十分ですね
noko外す=即死する と言う感じになるので、nokoをずっと維持する必要があります
『roundstate!=2でnoko』なら大丈夫ですね

なお、これは『強制死の宣告』だからこそ耐えられる方法であって
『死の宣告』にはこの方法は使えないので(ry


「タイムアップ寸前」を把握する方法があればよかったんだけど…残念ながらないんだよねぇ(´・ω・`)
あればホントによかったんだけど…(遅延化の把握とかその辺で)

なのでデフォルトの99秒の時の「遅延化が一切発生しなかった場合の、試合終了までかかる時間(6028F)」を参考にして
6000F経過したら強制宣告を使う用にするという感じでやってます

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

        ∧∧
       ヽ(・ω・)/   ズコー
      \(.\ ノ
    、ハ,,、  ̄
     ̄
↑今の心境


まぁヘルパー動かすタイプで混線周りを防ぐのは大変か
(見た目を捨てるならともかく)

てかLゴジータ2.9みたいなAIでも根本的な解決にはなってないぞw
あれは見た目を捨てて(本体のみ特定ステに籠って)色々な即死を防ぐタイプだから…

まぁそれも耐性が不十分だから穴なんて多数あるけど

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

本体がある程度干渉される構造なら
その辺の感知の労力を省略できるからね。誤感知とかもヘルパーに比べれば少ないし
本体の耐性がしっかりしてる事が前提だけど

見た目を捨てていいなら本体は常時監視で常に特定ステートに飛ばす
ステート固定でよさそうだね

つかそれ早く言ってくれれば
「タゲを取られても、タゲを取られてないかのように動作させてる」為の全個別ステへの記述とか相当簡易化できたんだが
実質特定ステートのみしか使わないから『特定ステートのみ書き換え』で済むし、その分不具合も減るしデバッグも楽になるし

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

モード別か…それって演出も丸々変わるのかな?
そうでないなら耐性は(突き詰めれば)動く場合と動かない場合でもほとんど差が無いから
どっちかに統一した方がいいと思うよ。記述もゴチャゴチャするし
(記述の難易度は大幅に差があるけどw)

まぁ戯言だと思って好きなようにやるのが一番だけどな(爆)

自分が使ってる即死ステートのstatenoを習得したくない場合は
そのstatenoに限り習得しないように記述するしかないかなぁ

triggerall=stateno!=XXXX ← 習得したくないstateno

こんな感じで



本体だからまだマシだけどヘルパーに習得させる上に
上記のような対策をしてないと
気が付いたら習得したstatenoが全部自身の混線statenoだったとか
自身の混線による自爆が酷いんだよなw

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

モード分けする意味…そういう気分だったからとかでw(個人的には一番大事)
巨大オロチに全く意味のない技を多数入れてるのも気分だからな!

まぁ真面目に言うと耐性強化という名目で一応ある…かな?
上位カラーや各種スイッチで耐性が強化されるキャラとか結構見かけるし
突き詰めれば一緒というツッコミは置いといてな! 籠らない方はあえて耐性に穴をあければ差別化とかも出来るし…


親変更の一般的な対策はsysvar、sysfvarに保存だね(他にもいろいろあるが)
親変更の対策は即死とMUGEN落ち等の不具合の対策以外は無視してるなぁ
使用してる変数がどうしても足りないから、親変更の影響は免れないから
「親変更持ちなんて即死通じないだろうから、即死関連が機能しなくなってもいいや」という感じで開き直って(ry

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

時間があったらね。やっぱ一番の問題は時間がない事なんだよなぁ…(´・ω・`)

親変更搭載はまだ早い…と言いたい所だけど
構造的にいえば親変更は一番最初にやった方がいいというジレンマ
(それでリミカは一度記述を消去してリメイクしたし)
もしかすると一番最初にやった方が後々楽になるかもなぁ…

まぁ個人的には親変更はあくまでも混線の補助(ヘルパーが奪いやすくなる程度)で
主な即死攻撃は混線からになるので、順々に勉強するのがベストだと思うが

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

なるほど、そこまでできてるなら下地は十分かな
まぁそこの知識はあってもアドレス書き換えの知識がないなら相当苦労するだろうけど
(むしろ親変更の場合はこっちの方が重要)

アドレス書き換え…凍結状態で大量のステコンを読み込ませる事で値を書き換えてしまうバグ
            超即死とかステコンオーバーフローと一般的に言われてるが、俺はアドレス書き換えと言ってた
            ちなみに親変更はアドレス書き換えの中でも難しい部類の技術(てか色々と応用が必要な物)


親変更の影のIDはデバッグではどうしても表示できないから
そこはまず練習として、デバッグ表示可能なaliveを使って色々実験して土台を作ったっけなぁ…

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

「超即死」や「蘇生」の本質が『alive弄り』という感じかな

超即死   … 相手のaliveを『1から0』に書き換える
超即死改 … 相手のaliveを『本来ありえない膨大な値から0』に書き換える
       本来ありえない膨大な値については下記参照

蘇生    … 自身のaliveを『0から1など』に書き換える

そしてアドレス書き換え共通の仕様で
-2147483648~2147483647の範囲で自由に書き換えできるので
aliveやpalnoなどをアドレス書き換えで本来出来ない筈の値にする事も出来ます
特定の値(通称『128の壁』)は通常の方法だと書き換え出来ないから、別の方法を用いる必要がありますが…


親変更はこのアドレスの値を自由に制御できるようにするのが
まず最低条件ですね
これだけでも最初は結構難しくて、ある程度の知識や慣れが必要なんだよねぇ(´・ω・`)

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

ステートループってどれの事を言ってますか?(・ω・ )
上記のでステートループが明確に関係してるのは超即死改のみだけど…
(親変更を0Fで行う場合は関係あるが、親変更自体はステートループがなくても可能)

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

ガードステートにいるヘルパーを奪うには
『相手がヘルパーを出した瞬間にタゲステする必要がある』ので
そういやつのステ抜け貫通用の為
『相手がヘルパーを出した瞬間に親変更を成功させる必要がある』→『親変更を0Fで行う必要がある』
という感じなので、ある意味では必須と言っていいですね
(最上神のほとんどのキャラがやってるし)

その辺にこだわらなければステートループで0Fで親変更を成功させる必要はないです


親変更の最初のテスト相手は旧鬼巫女12Pは結構適しているかな
ステートループなしの親変更でも大丈夫だし
親変更が成功すれば特定の変数に特定の変数を代入させるようにすれば

親変更が成功 → 旧鬼巫女即死

という感じにデバッグ出来てわかりやすいですし
(ただし、それなしだと旧鬼巫女即死は結構厄介だが)

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

どの辺でつまずいてるのかあまり把握してないけど…
親変更は段階的に

1 親が存在しないヘルパーを作る
※親が存在してるかしてないかはplayeridexist(parent,id)で確認出来る

2 相手のヘルパーが親になるまで待つ
※相手のヘルパーが親になった時点で、parent,のリダイレクトは機能するようになる

3 アドレス書き換えで影のIDを親のIDに書き換えると
  parentvarset、parentvaraddが機能するようになる


こんな感じなので、相手のヘルパーが親になった状態(親変更一歩手前の状態)まで出来てないなら
アドレス書き換えは後回しにして、まずはそっちを先だね
(ここら辺ならある程度は教えられるかな。説明がわかりやすいかどうかは別にして)

相手のヘルパーが親になった状態まで出来てるなら…
あともう一歩なので頑張れ!(`・ω・´)
(こっちは経験や知識がものをいうから
アドレス書き換えの法則位しか教えられない…というか教えようがないんだよなぁ…)

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

ふむ、てことは相手のヘルパーが親になった状態(親変更一歩手前の状態)まで出来てて
影のID合わせか、相手が出すヘルパーのIDの調整のどちらかに苦戦してる感じかな?

ひとまず影のID合わせに言える事は
変数とDisplayToClipboardやAppendToClipboardを駆使して状況を把握する事…かな
やみくもにやっても状況が分からず、成功させるのは難しいから
どうデバッグするかが重要やで(・ω・ )←ついさっきまで親変更のシステムの不具合等に四苦八苦しながらも改善してた人

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

いや、『影のID』を『親のID』と同じにすればです
(正確には『影のプレイヤーID』を『親のプレイヤーID』と同じにすれば、かな)
この『影のID』の所為で親変更の難易度が高くてややこしい事に…
参照さえできれば難易度もうちょい下がったのにな

まぁとにかく、ヘルパーIDは親変更とは全く関係ないですね

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

影のIDがホントにねぇ(´・ω・`)
記述ミスがあっても、デバッグ出来ない所為でどこがどう間違ってるのか
本当に把握しにくいからねぇ

探してみると親変更テンプレとかが結構あるから
それらを見てやった方がわかりやすいと思うよ


親変更の有無では大幅に違いますね
(正確には親変更による「gametime貫通」の有無だけど)
混線の搭載が前提になるけど、これがある事でヘルパーを奪えるようになる相手が大幅に増えます

個人的には混線の有無と同等くらいの差があると思ってますね
混線と同じく、親変更の有無が一種の境界線を握っているという感じで

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

No title

相手のgametime式ステ抜けを突破する為の技術を「gametime貫通」と言ってますね
(相手の変数を監視、計算して、相手のgametime式を導き出し
次Fになると思われる変数をあらかじめ代入して突破する)
「gametime式ステ抜け貫通砲」と一般的には言われてるのかな?

まぁ本体のgametime貫通が出来てれば(神ワルド11Pを即死出来る位の殺傷力があれば)
それをヘルパーの親変更にも用いればいいだけだから、そこまで難しくないかな
出来てないなら…ご愁傷様

旧リミカ12Pが上位神止まりだった最大の要因が、親変更を持ってなかった事だからねぇ
プロフィール

かませ

Author:かませ
その時その時でハマるものが変わります
現在サモンナイト6をプレイ中
クリアしたのでただいまトロコン目指して
無限回廊攻略&周回プレイ中

リンクフリーのような気がする
たとえそうじゃなかったとしても心が繋がっていれば無問題

訪問者数
最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
検索フォーム
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QRコード
TweetsWind