流れる時の中で

主にmugenの凶悪キャラを制作しております

スポンサーサイト 

--/--/--
--. --:--

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

[edit]

CM: --
TB: --

page top

ヘルパーID調査 

2015/01/26
Mon. 23:55

さて, 先日消えてしまったヘルパーID調査の記事を頑張って書き直しましょう・・・。
最初の方だけちょっとだけ生き残っていたのでそのまま流用しております。



今回は, 前回のリダイレクト偽装の解説からの延長でヘルパーID調査の方法を自分なりにまとめた記事になります。
製作者向けな記事になりますので, 視聴者層の方にはちょっとわかりずらい話かもしれません。





ヘルパーIDというのは, IsHelper(XXX)などのように記載されるIDの事ですね。
ヘルパー生成時に設定するIDがそれにあたります。

で, このヘルパーIDを仮に取得してできることって, 考えてみると現状リダイレクト偽装くらいなんですよね・・・。
(Enemy(0),Helper(XXX),sysvar(0)のようなリダイレクトはできませんし)
逆を言うと, リダイレクト偽装を汎用で行おうと思ったら必須な処理でもあるので, 覚えといて損はないのかもしれません。


今回は, 鈴々に実際記載している記述を載せておきます。
あくまで我流ですので, もっと効率的な方法があるかもしれません・・・。
(そもそもこの辺りは殆ど製作者によって方法が違ってくると思いますが)

まず, 基本的な情報を載せておきます。

鈴々で実際に行っているヘルパーID取得の方法は, 混線ヘルパーを用いて実際に自分が所持しているターゲットヘルパーのヘルパーIDを調査するものです。

それから今回使用している変数の内容は以下の通りです。
var(1) - 雑用変数1(毎Fリセットされる一時記憶or計算用変数)
var(2) - 〃 2

sysvar(0)&2 - ヘルパーID調査中フラグ
sysvar(4)   - ターゲットヘルパーのヘルパーID


それでは実際に記述を見ていきましょう。

[State ,ヘルパーID調査]
type=VarSet
trigger1=PrevStateNo!=StateNo
var(1)=ifelse(sysvar(4)<0,0,sysvar(4))
ignorehitpause=1
//まず初めに, 今回どこから調査を開始するかの設定をします。
//初回の場合は0(実際には1からですが理由は後ほど)から, 調査の途中であればその値を引き継ぎます。
//注意点として, 調査用に同一ステートをループさせるためトリガーにPrevStateNo!=StateNoの記述を
//忘れずに追加しておきます。


[State ,ヘルパーID取得]
type=VarSet
trigger1=Target,IsHelper(var(1):=var(1)+1)
trigger2=Target,IsHelper(var(1):=var(1)+1)
trigger3=Target,IsHelper(var(1):=var(1)+1)
trigger4=Target,IsHelper(var(1):=var(1)+1)
trigger5=Target,IsHelper(var(1):=var(1)+1)
trigger6=Target,IsHelper(var(1):=var(1)+1)
trigger7=Target,IsHelper(var(1):=var(1)+1)
trigger8=Target,IsHelper(var(1):=var(1)+1)
trigger9=Target,IsHelper(var(1):=var(1)+1)
trigger10=Target,IsHelper(var(1):=var(1)+1)
sysvar(4)=var(1)
ignorehitpause=1
//ここで, 実際にヘルパーIDの調査を行っていきます。
//trigger1=Target,IsHelper(var(1):=var(1)+1)という記述では,
//ターゲットヘルパーのヘルパーIDが1(初回の場合)かどうかの判断をしております。
//仮にターゲットヘルパーのヘルパーIDが1だった場合, トリガーは満たされ, sysvar(4)=var(1)
//つまり, sysvar(4)にターゲットヘルパーのヘルパーIDを記憶させます。
//逆にターゲットヘルパーのヘルパーIDが1でなかった場合, trigger2にて同じ処理を行い次の値(この場合は2)に
//移ります。
//これを繰り返すことにより, ターゲットヘルパーのヘルパーIDを調査して行きます。
//ちなみに今回はtrigger10までしか記載していませんが, 鈴々の記述ではtrigger100まで用意しております。
//(つまり, 1度の調査で100IDの調査を行っています。)


[State ,ループ処理]
type=ChangeState
trigger1=!Target,IsHelper(var(1))&&var(2)<20
persistent=256
value=StateNo+0*(var(2):=var(2)+1)
ignorehitpause=1
//続いて, 上記ステコンを複数回繰り返す為にループ処理を行います。
//鈴々の場合, 1度の調査で100*20=2000IDの調査を行っています。
//注意点として, ループ回数の増加はそのままmugen上での動作が重くなることに繋がりますので,
//現状での重さと相談しながら増やしましょう。


[State ,ヘルパーID調査中フラグ]
type=VarSet
trigger1=!Target,IsHelper(var(1))
sysvar(0)=(sysvar(0)|2)
ignorehitpause=1
//ループ処理を含め, ID調査終了後もターゲットヘルパーのヘルパーIDを取得できなかった場合,
//現在ヘルパーIDの調査を実行中だというフラグを立てます。
//このフラグにて, 調査ステートへの移動や取得の有無などの判断を行っていきます。


[State ,現在調査が終わっている所まで保存]
type=VarSet
trigger1=!Target,IsHelper(var(1))
sysvar(4)=var(1)
ignorehitpause=1
//上記ステコンと同じく, ID調査終了後もターゲットヘルパーのヘルパーIDが取得できていなかった場合,
//ヘルパーID保存変数に今回ID調査終了時の値を保存します。
//これにより, 次回調査時に最初のステコンで値を引き継ぐことができます。
//注意点として, この値を間違ってリダイレクト偽装に使用しないことですね。
//それからこれは記述の書き方による違いですが, ID調査のステコンをnullに変え,
//このステコンをtrigger1=1で一括でsysvar(4)=var(1)の処理を行うことも可能です。
//私はわかりやすくこのような形をとっていますが・・・。


[State ,調査が終わったら調査中フラグリセット]
type=VarSet
trigger1=Target,IsHelper(var(1))
sysvar(0)=sysvar(0)-(sysvar(0)&2)
ignorehitpause=1
//最後に, 無事にターゲットヘルパーのヘルパーIDを取得できたら調査中フラグをリセットします。



以上が, ヘルパーID調査用ステートとして同一ステートで行っている処理になります。
後は最終ヘルパーやらで混線ヘルパーのsysvar(4)と(sysvar(0)&2)の調査フラグを参照し, 随時変数に格納していきます。
それから注意点として, ターゲットヘルパーが消失(または入れ替わり)した場合は, sysvar(4)変数と(sysvar(0)&2)のフラグを初期化するのを忘れずにしておきましょう。


最後に, 鈴々の調査ステートへの移動ステコンを載せておきます。
この移動により調査ステートに移動するわけですが, 鈴々の場合最大24近い混線ヘルパーが常駐しています。
この24ものヘルパーが全て同時にこのステートを読み込むと, それだけでとてつもない重さになります。
なので, 鈴々の場合かなり条件を絞っております。参考程度にどうぞ。

[State ,ターゲットのヘルパーIDを取得していなければ調査ステートへ]
type=ChangeState
trigger1=PlayerIDExist(Target,ID)
//ターゲットが存在するか
trigger1=Target,TeamSide!=TeamSide
//ターゲットが敵かどうか
trigger1=!Target,IsHelper(9585858)*!Target,IsHelper(9585859)*!Target,IsHelper(16816800)*!Target,IsHelper(16816805)
//ターゲットが間者ヘルパーor探査ヘルパーではないか
trigger1=!Target,IsHelper(sysvar(4))
//ターゲットヘルパーのヘルパーIDを取得していない
trigger1=Floor(sysfvar(0))>10
//sysfvar(0)=ターゲット取得からの経過時間。
//出し消しの多いヘルパー(入れ替わり式の時止めヘルパーなど)に対して行っても意味が薄い為, ある程度猶予を持つ

trigger1=GameTime%12=(sysvar(2)%12)
//sysvar(2)=混線ヘルパー自身のヘルパーID
//意味合い的には, 12Fで1周とし1Fに2ヘルパーずつ交代で調査させる。
//ただこの場合, 調査が必要なヘルパーの有無が分からいので結構なロスにはなってると思います。

persistent=256
value=StateNo+1
ignorehitpause=1



というわけで, 時間は空きましたがなんとか再度記事を書くことができました!
結構わかりやすく注釈入れたつもりですが, まだわかりづらい部分が多いかも・・・。
それから, これはあくまで私個人のやり方なので, 他の方とは結構違うかもしれません。(後無駄が多かったり)
それでも記述の参考に少しでもなれば幸いです。
スポンサーサイト

[edit]

CM: 0
TB: 0

page top

リダイレクト偽装 

2015/01/23
Fri. 08:49

IRCログ倉庫を漁っていたら何となく目に留まったので久々に製作者向けというか, 知ってると動画なども楽しめるかもしれないネタ。

リダイレクト偽装とはどういったものなのかを解説して行きたいと思います。

この技術に関してまず述べるとしたら, 不遇, というかそういったイメージが個人的には強いです。
その理由として第1に, 親変更によってその優位性が薄れた部分が大きいでしょうか。

詳しい解説は後ほどしていきますが, このリダイレクト偽装によって可能な事の一部が親変更によって可能になりました。
加えて導入が結構面倒であり, 意外と上位陣でも汎用で搭載しているキャラは結構絞られたりします・・・。
(かくいう私も公開したキャラに汎用で搭載した経験がないです)

が, この技術からの派生であるアーマーキラーは汎用性もそれなりにあるのでどちらかというと, こちら目的で導入されることが多いと思います。
ただ, その優先度が低くなり後回しにされることが多いかもしれません。
しかしながら, 汎用殺傷力を高める上では決して欠かすことのできない技術であることも確かだと思います。




というわで, 実際に解説に移って行きましょう。

まず初めに, 「リダイレクト」という言葉の意味から見ていきましょう。

1.リダイレクトとは
みなさんご存じ, Mirror Cube SquareことMCSは, ヘルパーアーマーという構造を持ちます。
どういったものかというと, 本体の代わりにヘルパーが本体の「被弾」の部分を受け持つ構造の事を指します。
もう少し詳しく言うと, ヘルパーが「被弾」した際に, 本体のライフ用の変数を変動(MCSの場合は回復)させます。
後は本体のライフを常時このヘルパーの管理しているライフ用変数を参照してそれに合わせます。

では, 本体がヘルパーの変数を参照するにはどうしたら良いのでしょうか?

・・・・・・そこで登場するのが, リダイレクト(キーワード)と呼ばれるものです。
例えば, ヘルパーアーマーの役割をしているヘルパーを仮にIsHelper(150)とし, このヘルパーのsysvar(0)に本体のライフ管理の役割を持たせているとします。

この場合, 本体のライフをIsHelper(150)のsysvar(0)という変数に合わせる時のLifeSetステートコントローラーは以下のようになります。

[State ,ライフ管理]
type=LifeSet
trigger1=!IsHelper
trigger1=NumHelper(150)=1
value=Helper(150),sysvar(0)
ignorehitpause=1


Helper(150),sysvar(0)
つまり, ヘルパーID150というヘルパーのsysvar(0)の値を返す。
この, Helper(XXX),YYYという参照の仕方が所謂リダイレクトと呼ばれるものの正体です。

同じような形式で,
Root,YYY / Parent,YYY / Enemy,YYY / EnemyNear,YYY / Partner,YYY / PlayerID(XXX),YYY / Target,YYY
というものがありますが, こちらも同じくリダイレクト(キーワード)になります。
(但し, 今回のリダイレクト偽装ではこちらの形式は出てこないのでそーなのかーくらいの意味で知っておいてください)

このリダイレクトで参照できるパラメーターは多岐に渡り,
sysvar(X),sysfvar(X),var(X),fvar(X)などの変数
Vel X,Vel Y,Pos X,Pos Yなどの速度, 位置
LifeMax,Life,PowerMax,Powerなどのライフ, パワー
HitPauseTime,Timeなどのヒットポーズタイム, タイム
などなど上げてもきりがないほど。
というよりも, 自分自身で参照できるものは殆どこのリダイレクトによっても参照することができます。



2.リダイレクト偽装とは
以上の事を踏まえて, 実際にリダイレクト偽装についてみていきましょう。

先ほども例に出しましたこちらのステートコントローラー
[State ,ライフ管理]
type=LifeSet
trigger1=!IsHelper
trigger1=NumHelper(150)=1
value=Helper(150),sysvar(0)
ignorehitpause=1


もしも仮に, Helper(150),sysvar(0)=0
つまりヘルパーID150のヘルパーのsysvar(0)を0にできた場合どうなるでしょうか?

答えはライフが0になる, ですね。
この, Helper(150),sysvar(0)をこちらの任意値にするのが今回のリダイレクト偽装の大本になります。



3.リダイレクト偽装の解説
では, 実際にどのように値を偽装するのかを見ていきましょう。

まず大前提として, 相手のヘルパーが奪えることが必須条件になります。
技術的には混線と親変更の間位に位置する技術かもしれません。

さて, 散々リダイレクトの利便性を説明してきましたがここでとある疑問が出てきます。

もしもヘルパーID150というヘルパーが複数存在した場合, 一体どのヘルパーが参照されるのか。
つまり
sysvar(0)=0のIsHelper(150)と
sysvar(0)=10のIsHelper(150)とが存在した時, Helper(150),sysvar(0)のリダイレクトによって返ってくる値は一体どうなるのか?ということです。


答えは, ヘルパー領域の小さい方のヘルパーが優先される, です。
ヘルパー領域という言葉だとわかりずらいかもしれませんが, ヘルパーには予め最大で56個の席が用意されています。
この席に, 仮に1番から56番までの番号を振ります。
1
2
3
4
(中略)
55
56
といった具合に。


そこに, 今回のように2つの同じヘルパーIDを持つヘルパーが入ったとします。
1 Helper(150)
2 Helper(150)
3
4
(中略)
55
56
(ヘルパーは基本的に出された順番に, 空いている小さい番号席から配置されます。)

この状態でHelper(150),YYYというリダイレクトを実行した場合, 参照されるHelper(150)というのは
番号の小さい方, つまり1番の席に入っているHelper(150)になります。

ここで話は戻りまして。
リダイレクト偽装という技術がヘルパーが奪えること前提という話は解説の最初で説明したと思います。
例えば, Helper(999)というヘルパーが奪えたとします。
このとき, Helper(999)というヘルパーにHelper(150)というヘルパーを生成させたとします。
結果, 相手はHelper(150)というヘルパーを2つ保持していることになります。

つまりどういう事かというと, このHelper(999)というヘルパーに生成させたHelper(150)というヘルパーの席を
相手が元々出していたHelper(150)というヘルパーの席よりも小さい番号の席に出すことができれば,
仮に(元々出ていた)Helper(150)というヘルパーが奪えなくても値を偽装することができるのです。

これが, リダイレクト偽装の内容になります。


リダイレクト偽装を文章で説明すると,

リダイレクト参照時, ステート奪取不可能な(システム系)ヘルパーの代わりに, 別のステート奪取可能なヘルパー(ないし本体)から同一IDヘルパーを生成させ参照させる技術, といった所でしょうか。(意味がよくわからない・・・・orz



4.リダイレクト偽装実装までに
さて, これでリダイレクト偽装がどういった技術かが(何となく)分かったと思います。

でわ, 実際にどうやって敵のヘルパーよりも小さい番号の領域(席)にヘルパーを出していくのでしょうか?
これが, リダイレクト偽装の1つの山場でもあり, 製作者の見せどころではないでしょうか。
今回はあくまでリダイレクト偽装の解説であり, テンプレート的なものでは無いためこの辺は割愛します。

というのも, ここを細かく説明していっても製作者以外にはまずついていけない内容になる(一応製作者だけでなく視聴者向けの解説記事のつもりな)ので・・・。後, かなり長くなりすぎますorz

それから, 2つ目の山場(見せ場)としてヘルパーIDの取得というものがあります。
今回はヘルパーID150というヘルパーと限定して説明してきましたが, 仮に汎用でリダイレクト偽装を行おうと思ったとき, このヘルパーIDは参照することができません。

その為, まず第1として相手が生成しているヘルパーのヘルパーIDを取得することが必要になります。


また最初の方でちょこっと出しましたが, リダイレクト偽装からの派生でアーマーキラーという技術があります。
親変更のある今, リダイレクト偽装=アーマーキラーという意味合いが強くなっている気がします。
このアーマーキラーに関しましては, また後日間違われやすいアーマー拉致と一緒に解説して行きたいと思います。


長くなりましたが, 久々に神ランクで使用されている技術の解説をしてみました。
かなり読みづらかったり, 分かりづらい部分が多いかと思います・・・・。これは正直私の文才能力の低さが原因ですorz

もしも疑問や間違っている部分がありましたらコメント頂けると幸いです。

これで少しでもこの手の技術に興味を持ってくれる方が増えると光栄です!!


[edit]

CM: 0
TB: 0

page top

11月24日コメント返信分 

2012/11/24
Sat. 13:11

非公開コメントでの質問でしたが、他にも似たようなこと思ってる方もいるかもしれませんので、記事にしておきまする。


まず始めに、親変更に対する耐性の回答から。

まず、親変更自体は前回説明した通り、孫ヘルパーの親を敵ヘルパーに変えてしまう技術でしかありません。
質問は恐らくその後の変数弄りの部分なのでしょうが、一応親変更自体の対策も不可能ではありません。

というのも、前回説明した通り通常の親変更はIDが特定値でなければ成立しません。
なので、こちらのヘルパーが親変更不可能なIDに調整してあげれば防ぐ事ができます。
もっとも、ここまでやっているキャラは私は知りませんが…
全領域親変更の場合は諦めましょう。

で、本題の変数弄りの対策の話。

最初に結論を述べると、こちらは恐らく防ぐ手段はありません。

が、それに対する対策はいくつか存在します。

1つ目に、親変更で弄れる変数は通常のvar,fvar変数だけなので、重要なものはsysvar,sysfvarを使う方法。
一番いいのはヘルパー変数使わない事ですが、耐性だけならまだしも演出殺傷力を求めるとどうしてもそういう訳にはいきません。
なので、弄られる心配のないシステム変数に弄られたくないものを代入しましょう。

2つ目に、ヘルパーの変数を弄られたのを感知する方法。
毎フレーム決められた値を代入し続け、その値が変化していたら弄られていると判断する。

この後の対策は人によりけりですが、変数を信用しなくしたり、あまりお勧めしませんが論外化したり。
対策という意味では微妙な部類な気もしますが。

3つ目に、変数を毎フレーム最初に初期化する方法。
ただし、値を持続的に保持しておくことはできないので、そういう値はやっぱりシステム変数に頼るしかありません。

と、思い付く限りの対策をのせてみました。

私のキャラの例を上げると、ヘルパーの通常変数で使用しているのは基本的には何かしらの記憶用です。
即死返し用のステートだったり、GameTime式ステート抜け貫通用の値だったり。
勿論弄られると困る値ではありますが、親変更持ちにそれらが通用するかと言われたら…な部分もありますしね。

注意点としては、ヘルパーの変数を弄られるとmugenが停止したり落ちたりしないように心掛けることでしょうか。
勿論、弄る方が悪いわけではありますが。



続いて、本体親変更に関して。

親変更と名前が付いていますが、こちらは親捏造を利用した技術になります。
上の通常親変更との違いは、親とする対象を敵のヘルパーとするか敵本体とするか、だったような気がします。

これにより、敵の子ヘルパーを奪うことなく敵本体の通常変数を弄る事が可能です。



こちらは恐らく、防ぐ手段はありません。
ヘルパーと違って、本体のIDは固定ですので親変更のようにはいきません。


対策としては、通常の親変更と同じことが言えますので省略。

ただ、やはりヘルパーと違って本体の通常変数はそれなりに重要な値を代入する事が多くなるのも事実です。

システム変数も通常変数と比べると数がかなり少なくなりますし、この辺の対策は1つの腕の見せ所でもあるのではないでしょうか。




さて、簡単ではありますがいかがだったでしょうか。
まだ解りにくかったり不明な点がありましたら、お気軽にどうぞ。

[edit]

CM: 0
TB: 0

page top

偽装まとめ 

2012/11/23
Fri. 02:48

うちのアンジェが偽装いぱーいてことで、エディさんの為にも色々まとめておきます。

前記事書いた後に寝付けないしそのまま偽装記事も書こう!

そう思い立って書き始め、出来上がったのは朝の3時。
明日朝から仕事なのにぃ…orz



基本的に、捏造未満でできるこもので実際に誰かしらが搭載してるもの、私がそのうち入れたいものです。

正直偽装って利用性あるのってものが多いですg(ry

- Alive偽装

生存フラグであるAlive値を偽装します。
基本的には、Alive=1:生存 Alive=0:死亡を差します。
Alive=0になると、lose(負け)フラグが立ちます。
また、Alive値はプラス値だけでなくマイナス値にもできます。
(マイナス値ではloseフラグは立ちません)

Alive値はステコンオーバーフローによって変更します。
基本的に超即死や蘇生も同じ原理です。
(Alive値を0に書き換えるのが超即死、Alive=0からAlive!=0に書き換えるのが蘇生)

Alive偽装は、Enemy,Alive=1やEnemy,Alive>0など、こちらの生存を特定値だけで見ているキャラに有効です。

例えば、
trigger1=Enemy,Alive=1;敵が生きていたら

という条件でNoKOを発動している場合、Alive値を2や-1などの値に変えることで突発することができます。

Alive値は任意値に変えることができるので、デバッグなどでAlive参照してみるとキャラによって面白い値だったりします。
興味がある方は是非とも。

- PalNo偽装

パレットカラーを示すPalNo値を偽装します。
基本的にはPalNo=1:1P PalNo=12:12Pの様に1から12までの値が使われます。

PalNo値はAlive値と同じく、ステコンオーバーフローによって書き換えます。

PalNo偽装は、Enemy,PalNo=1などこちらのカラーによって弱体化や特殊処理を行うキャラに有効です…
が、実際に有効なキャラが居るのかは不明。
いや、実際には居るんですが…結構特殊な偽装だったり他の偽装込みだったりするので何とも言えない部分も…

このPalNo偽装ですが、Alive偽装と違い注意点があります。
1つ目に、PalNoをトリガーに使用できないこと。
カラー差のないキャラにはあまり問題ないことかもしれませんが、カラー差のあるキャラはそれなりな対処が必要となります。
2つ目にPalNo値はラウンド(1ラウンド目から2ラウンド目のように)移行してもその値を引き継ぎます。
つまり、PalNoを100に偽装して次のラウンドに移行するとPalNo=100のまま次のラウンドに来てしまう訳です。
こちらもカラー差のあるキャラは対処が必要となります。

PalNo値もAlive値同様任意値に変えることができます。

余談。
結構前に記事にしたことがありますが、PalNo=0は一応可能です。
まぁ、利用性0に等しいんですがね…

- 速度偽装

速度を示すVel値を偽装します。

こちらはステコンのみで偽装できますが、速度の変数化や管理が必要となります。
後、ヘルパー本体や本体Explodのような本体が透明な構造じゃないと酷いことになります。

主に速度耐性を持つキャラなどに有効です。

- 位置偽装

位置を示すPos値を偽装します。

こちらも速度偽装同様。
あっちこっちに移動するので本体が本体してると酷いことになります。

こちらの位置に依存する条件でダメージが変化するキャラや、ヘルパーを生成するキャラなどに有効です。

- Time偽装

キャラがステート移動してからの時間を示すTime値を偽装します。

Time値はステートを移動すると初期化され、そのステートに留まり続けることで毎フレームTime値が加算されます。
準ステート固定構造などはTimeが0から変動しなくなります。

また、Time偽装はステコンオーバーフローによって書き換えるのが可能です。
只し、ステートを移動すると初期化されるため、そのステコンオーバーフローステートを最終ステートとする必要があります。

余談になりますが、Time偽装を行うとガーステ準ステート固定ができなくなるため、本体ターゲットを取られる構造でガーステを利用したい場合、Time偽装用のステコンにガーステ生成(ステコンオーバーフロー)を複合させることが可能です。

主にTimeが動く事が条件なキャラや、特定値でライフ減るキャラに有効です。

- ライフ偽装

キャラのライフを示すLife値を偽装します。

基本的にはライフを任意値にするだけ。
真ライフなどを変数化する必要がありますが。

ただし、この方法だとLife=0の偽装ができません。

そこでヘルパーと行動順を利用した方法。
始めにヘルパーに本体のターゲットを永続的に保持させ、ヘルパーで本体のライフを0にして敵に参照させ、本体で元に戻します。

敵の行動に依存するのと、ほぼ1P側限定となりますが。

Alive偽装同様、Enemy,Life>0などでNoKOしてたりライフ一定値以下でダメージ受けるキャラなどに有効です。

- 凍結ライフ偽装

上のライフ偽装と意味合いは同じですが、やってることは異なるので分けておきました。

ヘルパー利用のライフ偽装とは違い、凍結中にはLife=0が成立してもAlive=0にならないのを利用したライフ偽装になります。

ヘルパー利用型は精度が、凍結型は凍結耐性が必要になるのでどっこいどっこいな感じがします。
でもどっちもあると心強いかもしれません。

最近だと凍結ライフ偽装を対策したライフ偽装必須キャラなんかもチラホラ…

- StateType偽装

キャラの状態?を示すStateTypeを偽装します。

基本的に、StateType=A:空中 StateType=S:立ち StateType=C:しゃがみを差します。

利用性はかなり微妙な気がする偽装。
棒立ちとかでなければ普通に変動しますしね。
偽装できるから偽装する、という位な気も…

こちらの状態によってダメージを受けるキャラに有効です…
が、居るのかは不明。

- Ctrl偽装

コントロールできる状態かを示すCtrl値を偽装します。

StateType偽装同様利用性はかなり微妙です。
以前1キャラだけ有効な気がするキャラが居ましたが…
偽装できるから偽装s(ry

こちらのCtrlが0ならダメージ受ける…という条件のキャラも面白そう(

- StateNo偽装

現在のステートを示すStateNo値を偽装します。

基本的には最終ステートを任意ステートにするだけです。
ただし、必要なステートを予め用意しておくことが必要です。

また、ガーステ準ステート固定が利用できないため、本体ターゲットを取られる構造でガーステを利用したい場合、140ステートを利用したガーステ化が必要です。

こちらが特定ステートの時にダメージを受けるキャラなどに有効です。

- Anim偽装

現在のアニメを示すAnim値を偽装します。

IRCで軽く聞いた所、まだ搭載しているキャラは居ないみたいです。
今後導入したい偽装その1。

基本的にアニメを任意値にするだけですが、本体が本体しているキャラだと酷いことになります。
また、そうでなくてもAnim値とAnimElemなどを変数化して管理する必要があります。

しかも、面倒な割りにかなり微妙な偽装です。
ネガゼロみたいにこちらのAnimを指定してくる敵に対して普通に動いてるように見せる…くらいしか使い道なさそうな…

専ら専用用で。

- 時止め状態偽装

以前になんとなーく思い付いた偽装。

Time偽装、速度偽装、位置偽装、アニメ偽装の延長のような偽装。

時止めを食らってるのかを確認する時に参照するであろう、Anim、AnimElem、AnimElemTime、Vel、Pos、HitPauseTime、Timeを一定フレーム一定値にすることで時止めを食らっているように偽装するもの。

主に、敵の状態監視込みで強制死の宣告を使用するキャラに暴発させるためにと考えた偽装。
恐らく現状はそれ以外にはまったく利用価値がない気がしますが。

本体Explod前提な上にまだ実際に試してないのでどこまでうまくいくのかは不明。
でも面白そうなのでできれば導入してみたい偽装。



とまぁ、思い付く限り並べてみただけでも何と10個。
何か抜けてるような気がしますし、考えればまだまだ思い付くかもしれません。


やっぱりライフ偽装が抜けてた…orz
一応12個です。多分。

正直考えている時が一番楽しいです(
鬼穣子のうちのアンジェ用の専用台詞じゃないけど、本当に何を信用したらいいのか…w


おまけ

上では書かなかったけど一応こんなんもあるよ、と。

- MoveType偽装

キャラの行動状態を示すMoveType値を偽装します。

MoveType=A:攻撃 MoveType=H:喰らい MoveType=I:どちらでもない。
Lとかもありましたが。

専用では一部使えるキャラが居るのですが、汎用となると凍結維持とかの兼ね合いもあって利用できない状態な偽装。
頑張れば入れられるのかもしれませんが。

Enemy,MoveType=Hがダメージ条件に入っているキャラも居たりするので利用性は無しにあらずではあります。

[edit]

CM: 1
TB: 0

page top

全領域親変更 

2012/11/23
Fri. 00:03

要望があったのでできるだけ解りやすく簡潔に。

まず前提として2つ関わりのあるお話から。

1つ目に、プレイヤー(本体、ヘルパーそれぞれ)にはそれぞれIDというものが割り振られています。
このIDはプレイヤー本体は基本的に1P、2P(カラーではなくプレイヤー側)などで固定の数値が
ヘルパーは生成された順番にIDが割り振られます。
また、ヘルパーが削除され、新たに同じヘルパーが生成された場合は新たなIDが割り振られます。

2つ目に、一般的に全領域親変更と呼ばれるのは、正式には全ID領域親変更であり似たようなものに全ヘルパー領域親変更があります。
(実際にこの名称使われてるかは微妙ですが一応区別化の意味で)

全ヘルパー領域親変更は一部では完全親変更とも呼ばれるもので、全(敵)ヘルパーに対して親変更できるものの事を差します。
所謂開幕完全並列混線と同じです。
構造ゆえに、基本的に完全並列混線全てに親変更ヘルパーを兼用させているのがこれにあたります。
たまに全領域親変更=この完全親変更と勘違いされることがありますが、まっく異なるものなので気を付けておきましょう。

これを踏まえた上で実際に全領域親変更のお話し。

そもそも、通常の親変更というのは欠点があります。
それは、最初に説明した(親となる敵ヘルパーの)IDが一定値でないと親変更できないとうものです。
これを説明すると、ステコンオーバーフローのお話しになり難しい話が続くので細かいことは省略しますが。

とりあえず、親変更というのはIDが一定の値でなければ成立しません。
これを解決する為に親変更ヘルパー(混線ヘルパー)展開時にIDを調整する処理を行っています。

この調整というのがまた(計算やら何やらで)大変で、私の親変更セットではmacbeth氏の方式を利用させていただいています。

話は戻りまして、全領域親変更の説明。
で、このIDの値に左右されずに親変更しようってので生まれた(多分)のが、全領域親変更です。
どの領域まで弄るかで変わって来ますが、基本的にはIDが60000ちょっと越えるくらいまでの値であれば親変更が可能になります。

通常の親変更ですと、調整をしなかったりIDが増えたりすると(IDが親変更不可領域で)親変更が不可能になってしまうのですが、全領域親変更ではその心配が激減するということですね。
(IDが60000越える事なんてそうそうないですし、仮に越えたとしてもそこまでやってたら親変更では倒せないんじゃってのが)

そんな便利な全領域親変更ではありますが、それなりな欠点もあります。
ID値を弄って特定値にするためにも、どうしても必要なステコンオーバーフロー用ステートが増え、容量にすると20MBを越えてしまいます。
(元々親変更に必要なステコンオーバーフローステート1つでも結構な容量になるのにそれが130個ほど必要になるのでどうしてもこんな容量に…)

容量が大きくなるだけならそこまで気にすることはないのですが、これがイコールでキャラ選択時の読み込み時間の長さに影響してしまいます。
環境にもよりますが、全領域親変更ONとOFFなのでは読み込み時間が30秒から1分前後増えます。

その為に、この全領域親変更を搭載したくてもできなかったり、スイッチ形式でON/OFF設定できるようにされていたりします。

基本的には調整さえしっかりやれば精度にそこまで差は出てこないのですが、安定性を求めるとやはり全領域親変更の方が信頼できるのかもしれません。

ケースバイケースな部分もありますので、結局はその人によりけりです。




長くなりましたが、全領域親変更と通常の親変更の違い、少しでも理解いただけたでしょうか。
至らない部分もあると思いますが、ご不明な点や間違ってる部分がありましたら誤字脱字合わせてコメントいただければ幸いです。


次回は要望とかなければ偽装関係のまとめをちょっと。
(主に個人的なまとめ様に)

[edit]

CM: 0
TB: 0

page top

2017-08

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