FC2ブログ

 |   |  次のページ

0F親変更

12/24
21:53 (KonTon) 0F親変更って具遺体的にどういうトリガーならできるのです?
21:54 (KonTon) トリガーというかんーなんでしょう・・・
21:54 (emeru) 相手がヘルパーを召喚したそのフレームで親変更を仕掛ける事です
21:55 (KonTon) ふむ… それはIRCたどってたら分かったのですが、どうしてかできないっていう…
21:55 (KonTon) うーむ
21:56 (emeru) 1F遅れる感じ?
21:56 (KonTon) タゲステを試合始まって300F以内はしてるのです!
21:56 (KonTon) 1F遅れてるのでしょうかぬ…
21:56 (KonTon) 常時親変更gametime貫通してるのですがががが!
21:57 (emeru) 要因は色々考えられるけども・・
21:57 (KonTon) ほむ…
21:57 (KonTon) できれば全部教えて頂きたかったり(
21:58 (KonTon) できればで大丈夫なのです!
21:59 (emeru) 1.影のIDを合わせていない 2.gametime貫通の調査ミス 3.親変更ヘルパーのmovetype
21:59 (KonTon) ほむ…
21:59 (emeru) 思いつくかぎりではこの三つかなぁ
22:00 (KonTon) 出た瞬間にIDは調整しなきゃだめですよね?
22:00 (KonTon) えーっと
22:00 (KonTon) 十徳ナイフで見てて
22:01 (KonTon) 例えばID= 100ノヘルパーが出てきた瞬間にはもう親変更ヘルパーは
22:01 (emeru) そうですねー
22:01 (KonTon) のparent,ID=100になってなきゃだめですよね?
22:01 (KonTon) ちょっと遅れたら不可ですよね?
22:02 (KonTon) ふむ…
22:02 (emeru) 遅れても親変更を仕掛ける事は可能です
22:03 (emeru) ただ0Fで親変更を仕掛ける意図は、ガードステートにgametime固定されたヘルパーを奪うこと
22:03 (KonTon) ほむ…
22:05 (KonTon) movetype = Iですよね?
22:05 (emeru) ですですーっ
22:05 (KonTon) あ!
22:05 (KonTon) いけましたのん!
22:06 (KonTon) やっぱり原因は遅かったからか…
22:06 (KonTon) エメルさんは
22:06 (KonTon) 試合開始直後何Fくらいタゲステしてます?
22:07 (KonTon) それともしてないです?
22:07 (emeru) 大技を発動したタイミングのみタゲステしてますねー
22:08 (KonTon) ほむ!
22:08 (KonTon) 了解しました!
22:08 (KonTon) ありがとうございました!!!
22:08 (emeru) いえーっ
22:15 (KonTon) エメルさん!
22:15 (KonTon) まだいますかね?
22:19 (emeru) はいなっ
22:19 (KonTon) プレート氏のキャラって0F貫通多いじゃないですか!
22:19 (KonTon) それが開幕で奪えないっていう…
22:20 (emeru) あー・・
22:20 (emeru) 確かヘルパー固有のgametime調査だったっけかぁ
22:20 (KonTon) 専用でparentvarsetしてるのですががががが…
22:20 (KonTon) 専用組んでるので大丈夫な気が…?
22:21 (KonTon) あれ?
22:21 (KonTon) もしかして処理準的に専用って下に置いたほうがいいのですかね?
22:22 (emeru) そうですねー
22:22 (KonTon) parentvarset trigger1 = 親変更がめちめ
22:22 (KonTon) のしたに
22:22 (KonTon) parentvarset trigger1 = parent,name = ・・・
22:22 (KonTon) みたいな!
22:23 (emeru) そうですねぇ 専用対策のフラグも立てて 誤爆も避けておくと尚良いです
22:24 (KonTon) そうします!

リンク:0F親変更[MUGEN神キャラ置き場]
スポンサーサイト



親変更

7/20
21:52 (_609z) 親変更すごい苦戦する
21:53 (_609z) 同期と固有の共存がむずかしい
21:54 (_609z) 共存できたと思ったら0Fが死ぬ
21:56 (_609z) どうやったら安定するんだろう
21:57 (emeru) 私はもう同期だけかなー
21:57 (emeru) 固有じゃないと貫通できないのって知る限りでは某製作者しか居ないし
21:58 (_609z) でも汎用としては使いたい
21:58 (emeru) んー、だとすると・・
21:59 (emeru) 最初の0Fは固有で、次のフレームではtargetstateを切って、固有の調査って流れかな
22:00 (emeru) ん、ちがう
22:00 (emeru) 最初の0Fは『同期』で、次のフレームではtargetstateを切って『固有』の調査って流れかな
22:00 (_609z) ふむ
22:00 (_609z) 変数使ったほうがいいかな
22:04 (emeru) そういえば、gametime変数の調査は何個記憶してますかね
22:05 (_609z) 同期5固有7です
22:08 (emeru) 固有多いと何かと便利かな・・
22:10 (_609z) 共存はできたが0Fが死んでる
22:11 (_609z) おかしいな。さっきまで0Fできてたのに
22:11 (emeru) 固有はできてる感じですかね
22:11 (_609z) できてます
22:12 (emeru) 0Fの時にtargetstateしてる?
22:12 (_609z) wow固有0Fできてるw
22:12 (_609z) 同期0Fが死んでるな
22:13 (emeru) んー、じゃあ 変数リセットしてないのかな
22:13 (_609z) 時間が短いのかな
22:14 (emeru) アレはヘルパーで出たり消えたりしてるので
22:18 (_609z) やっぱり同期0F死んでる
22:20 (emeru) ヘルパーが変わったり親ヘルパーが無いときはリセット掛けてますかね?
22:21 (_609z) リセット?がめちめ変数をリセットですか?
22:22 (emeru) 同期貫通用taegetstate → 固有貫通用targetstate
22:22 (_609z) あー、2つタゲステ作るのか
22:23 (emeru) 一々分けているのは 同期で貫通していると 親ヘルパーがgametime変数を代入してくれないんですな
22:25 (_609z) んー、だめだ
22:26 (_609z) triggerが悪いのかな
22:29 (emeru) 試しに、固有貫通用のtargetstateを切ったらどんな感じですかね
22:37 (_609z) だめだー
22:37 (_609z) なーんでかなー
22:38 (_609z) 0Fじゃないのは出た瞬間奪ってるんだがなー
22:39 (emeru) triggerが原因なのかねぇ・・
22:40 (_609z) triggerは変わらないと思うが
22:40 (_609z) triggerが原因だったら普通のもできないはず
22:42 (_609z) うちの娘おかしい
23:01 (_609z) 普通の同期は出た瞬間奪ってるのに0Fは奪えない。この差はなんだ
23:07 (_609z) くそぉ
23:26 (_609z) うおおおできたーーー
23:26 (_609z) 原因がひどすぎた。
23:27 (Jakobish) おめでとうございます

影のID

3/19
23:45 (Digest) もう成功する気がしない、、、(親変更)
23:45 (Momizi) ん、影のIDの調整段階だっけ
23:46 (Digest) ですね。影IDを0逃げるした段階で足踏みしてます
23:46 (Digest) 0にした段階(
23:47 (Momizi) 次は現在の親のIDに合わせる、ですね
23:47 (Momizi) 1Byte目を(Parent,ID%256)に, IDが256以上なら2Byte目を((Parent,ID&256*256-1)/256)に
23:48 (Digest) んむ、ありがとうございます。
23:48 (Momizi) 0にしてるなら1Byte目が100ならpersistent=128をえーっと28回ループかな
23:49 (Digest) うあ、ループ回数指定した方が良いのか。
23:49 (Digest) 一致するまでループって形にしてましたね。
23:49 (Momizi) うん?
23:49 (Momizi) 一致って何基準で判断してるん?
23:50 (Digest) 親IDと自分の1byte目が一致するまで、って感じですね。
23:50 (Momizi) それ参照できます?(
23:50 (Digest) 親IDの1byte目と(
23:50 (Momizi) 影のIDはパラメータでもリダイレクトでも参照できないですよ
23:51 (Momizi) Parent,IDとは別領域なので。一応
23:51 (Digest) と、取り敢えず搭載してきますね(逃)
23:51 (Momizi) お、おう・・・
23:51 (Oracle) 色々不十分やな
23:52 (Momizi) 十徳が便利すぎるんやな(
23:52 (N-Fox) 未だ手探りということでせう
23:52 (Oracle) やる気のあるうちに色々な情報を記録していけるとよいですね
23:52 (Momizi) 十徳が影のID見れちゃうせいで参照できるって思っちゃうのかな?以前は参照できないからこその難易度だったし
23:52 (N-Fox) 俺は即死返しなんとかしないとなー。実験対象中々いないけど
23:53 (Digest) さも当然に影IDを表示する十徳が悪い(※違います)

親変更

3/19
00:01 (Digest) ん、oracle氏ちょいと質問です
00:02 (Oracle) うむなんだね
00:03 (Digest) 現在親変更ヘルパーのIDを0にした後、1byte目と2byte目が0以上128以下の場合親変更ステートに飛ばしているのですが、
00:03 (Oracle) うむ
00:05 (Digest) 6689にpersistent=128、次のステートは6690にpersistent=128で一致するまでループさせれば問題ない、、、はずですよね?
00:06 (Oracle) persistent=128のステートはnull?
00:06 (Digest) ChangeStateです。
00:06 (Oracle) おーk
00:06 (Digest) ん、ありがとうございます。
00:06 (Oracle) なら0-128間でもできるな
00:07 (Oracle) んでさ
00:07 (Oracle) ループ用のchangestateはあるよな?
00:07 (Oracle) persistent=128でループさせてないよな?
00:07 (Digest) えっ?(
00:07 (Oracle) えっ?
00:08 (Digest) えっと、もしかしてアウトですかね?(
00:08 (Oracle) しらん
00:09 (Oracle) persistentが0-255で弄るアドレスが示す値が0のときに実行される
00:09 (Oracle) 256はそれらを無視して実行される
00:09 (Oracle) persistent=128で実行した場合、そのアドレスが示す値が128になる
00:09 (Digest) うあ、別途loop用のステコン作ってきます。
00:10 (Oracle) それ以降はそのステートを通る度に1ずつ減っていく
00:10 (Oracle) 0になれば再び実行できるようになる
00:10 (Oracle) OK?
00:10 (Digest) おーけーです。
00:10 (Oracle) 試しにaliveでもいいからやってみ
00:10 (Oracle) nullは実際に動かして数値の変化見たほうが早い
00:11 (Digest) 了解です。

影のID

3/15
21:24 (Digest) んー、影のIDを0にしてから弄れば良いのかな?
21:25 (Oracle) うむ
21:25 (Digest) ほむ、ありがとです。
21:25 (Momizi) 0にしてから規定値に弄る方法と最初から規定値の為に何ループさせるかで分かれるのかな。どっちも最終的には同じ意味だけど
21:25 (Oracle) ああ、それいきなりやるとこんがらがるだろうからやめたほうがいいね
21:26 (Oracle) 規定ループは処理速度としてはオススメだけど、最初はやらんほうがいい
21:26 (Momizi) ミスったら以後全部みするからねw
21:26 (Digest) うあ、やっぱり0から弄るべきですか。
21:26 (Oracle) 最初は根底を教えておけばいいさ
21:27 (Oracle) そのうち気付いたら自分でいじれる様になる
21:27 (Digest) 頑張ります b
21:27 (Momizi) 弄る->変な値になる->その値把握できな->どうしようもないって事になる
21:27 (Momizi) 把握できない
21:28 (Momizi) 最初に完全に0にする場合だとその時は失敗して変な値になっても次に弄る時は0からだから問題ない
21:28 (Digest) 1バイト目を参照する方法は&128、ですかね?
21:28 (Momizi) %256
21:29 (Momizi) Parent,ID%256
21:29 (Digest) うあ、やっぱ違った。
21:29 (Oracle) &255でもおーけ。
21:29 (Oracle) %と/使ったほうが整理しやすいから
21:30 (Digest) %256で挑戦しよう
21:30 (Momizi) 2Byte目:((Parent,ID&256*256-1)/256) 3Byte目:((Parent,ID&256*256*256-1)/256) 4Byte目:((Parent,ID&256*256*256*128-1)/256)かな
21:31 (Digest) ありです。よし、挑戦するか。
21:32 (Oracle) おい
21:32 (Oracle) 256じゃない
21:32 (Oracle) 65536と1677216だ
21:32 (Momizi) コピペしたから変えるの忘れてるわ(
21:32 (Oracle) そういうのだめ
21:33 (Momizi) 2Byte目が/256で3Byte目が/(256*256)4Byte目が/(256*256*256)やね
21:33 (Digest) 了解ですw
21:33 (Oracle) 1677216じゃなくて16777216でしたすまぬ

親変更

3/7
00:10 (Myon_) 親変更って相手ヘルパーと同IDのヘルパーを自分で出してぬるぬるで親IDを相手に変更するって解釈で合ってます?
00:10 (hitachi) いや違う
00:11 (hitachi) 自分の親を記憶している部分を相手のIDと同じになるようにステコンオバフロで弄るということ
00:12 (Myon_) 自分の親を記憶している部分=親IDじゃないんですか?
00:14 (hitachi) 親ヘルパーのIDとは別に本来の自分の親のIDを記録している箇所があるというのはわかりますよね
00:14 (Myon_) わかります
00:15 (hitachi) その記録されてるIDを現在の自分の親になっているヘルパーのIDにしてやるということです
00:18 (Myon_) 十徳で見れる親IDというのは親ヘルパーのIDのことで合ってます?
00:18 (hitachi) 十徳の親IDは本来の親IDのことでこれを弄るのが親変更です
00:19 (hitachi) 現在の親IDはparent,IDで参照できるものです
00:19 (Myon_) なるほど つまり本来の親IDを調べる必要があるのか
00:20 (hitachi) 本来の親IDは普通に参照することができないので
00:20 (hitachi) ヘルパーを配置する時点で変数か何かに記録させなきゃいけません
00:25 (Myon_) 親ID検索ってanim取得みたいに総当たりで探す感じですか?
00:25 (hitachi) いえ
00:26 (hitachi) http://hitachi5300.blog.fc2.com/blog-entry-293.html
00:26 (vesper) [URL] @ひたちがゆく! 親変更解説基礎編
00:26 (hitachi) これ見たほうが早いと思いますが
00:27 (hitachi) 現在の親IDそのものはparent,IDで参照できます
00:28 (lunatic__) 親変更前に実験的に作られたparent偽装ってのを使って調べてる
00:33 (Myon_) 親変更用のヘルパーって普通に混線で使っているヘルパーでいいんですよね?
00:33 (hitachi) いえす
00:54 (Myon_) 今までの混線でタゲられる方のヘルパーから親変更ヘルパーを吐いて変数にID記憶させるんですよね?
00:54 (hitachi) そこも少し変えないといけないんですけど
00:55 (hitachi) その前に親変更そのものの理解が重要です
00:56 (hitachi) まずはテストキャラで実験やって親変更チェッカー倒せるようにしてみてください
01:14 (Myon_) とりあえずコピペ搭載のkfmで親変更チェッカー1P撃破確認
01:15 (_609z) おめ
01:17 (Myon_) 親IDが0~127に変わってることぐらいしかわからないな
01:18 (_609z) 今やってるのは半領域親変更ていうやつ
01:20 (Myon_) 混線で使ったタゲ取られ用の被弾ヘルパーって必要ない感じなのかな
01:21 (_609z) 必要ないね。ただ、本来の親だからちょっと重要
01:24 (Myon_) ぬるぬるする方のヘルパーって本体で吐いたらダメなのかな?
01:27 (_609z) 親変更は相手のヘルパー変数を弄るための技術で本体から吐いたヘルパーは意味が無いよ
01:27 (Myon_) そうだった本体で吐いたら意味ないな
01:30 (Myon_) 混線で例えるとタゲ取られていた被弾ヘルパーがタゲステするほうのヘルパーを吐いてる感じ?
01:32 (_609z) 本体が吐くのはタゲを取られるヘルパーでそのヘルパーが吐くのは混線ヘルパー
01:32 (_609z) ようは混線ヘルパーは親変更ヘルパーでもある
01:35 (Myon_) なるほど
01:38 (Myon_) 今は親変更ヘルパーを吐いたらデストロイしてるけどこれを今まで通りタゲ取った後にデストロイすれば混線も出来るわけか
01:41 (_609z) んーと、流れとしては
01:42 (_609z) 生成ヘルパーと占有ヘルパーをだしてヘルパーを占有
01:43 (_609z) 生成ヘルパーが親変更可能領域になるまでデストロイと生成を繰り返す
01:43 (_609z) 可能領域になったら混線を展開する
01:44 (Myon_) 可能領域?
01:45 (_609z) 十徳見れば判るけどhelper,IDって生成とデストロイを繰り返すと1づつ増えていくんだけど
01:46 (_609z) 親変更はIDによっては出来ないこともあるからIDを調整するためにデストロイと生成を繰り返す
01:47 (_609z) あ、ごめん
01:47 (_609z) ミスってた
01:48 (_609z) いや、会ってた
01:49 (Myon_) 出来ないIDのIDってヘルパーIDのこと?
01:50 (_609z) あ、playerIDだ。
01:51 (Myon_) プレイヤーIDによっては出来ないこともあるのかー

親変更

3/6
22:02 (dry_ice) やばい
22:02 (dry_ice) 神オロチ倒せんw
22:03 (YANMAR) 親変更搭載時あるあるだなw
22:03 (dry_ice) 親変更切ってるんだけども…
22:04 (hitachi) よくある
22:04 (dry_ice) 神オロチに変数いじりはダメですしねぇ
22:04 (YANMAR) 親変更搭載はオンオフでどうこうって話じゃないような
22:04 (YANMAR) 先ず親変更ベースに混線書き直すところからだし
22:04 (dry_ice) げぇー
22:05 (hitachi) 親変更に対応できるように構造を買えた結果狂うのは誰もが通る道
22:07 (dry_ice) つか邪眼意思も倒せぬ
22:07 (_609z) 狂いすぎw
22:07 (hitachi) 混線がおかしくなってるんだな
22:07 (YANMAR) 混線回復からだね
22:07 (dry_ice) まじかぁ…
22:08 (dry_ice) ういっす
22:08 (teki) 構造的には先に親変更を搭載して、そこから混線がスマートなんですが、
22:08 (teki) そもそも混線の搭載を習得しないと意味がないからジレンマにw
22:08 (YANMAR) 技術難易度から言うと、ねw
22:08 (YANMAR) トムキラーと混線の関係に近いw
22:08 (dry_ice) ですよねー
22:09 (emeru) 親変更取得時は混線回復が課題だったり(
22:09 (_609z) ←最初から親変更前提で混線展開してた人
22:09 (dry_ice) これなにミスってんだろ…
22:09 (_609z) これのおかげで親変更搭載しても混線が大丈夫だった
22:09 (dry_ice) ←そもそも親変更が何か未だに理解できてない奴
22:09 (dry_ice) いいのぅ
22:10 (YANMAR) 理解できてないならミス以前の問題かと
22:10 (hitachi) もみもみの親変更セット見よう
22:10 (hitachi) リメイクでとてもわかりやすくなってるから
22:10 (dry_ice) ですよねぇ…>ヤンマーし
22:10 (hitachi) 親変更とは何か、なら自分の解説を熟読するといい
22:11 (YANMAR) 上の通り、親変更が土台になっててそこの上に混線を敷くイメージだから
22:11 (teki) 親変更セットで遊んだり、親変更なし筆頭の記述をお借りして遊んだりした後でキャラ作成をしたので、自分も最初から親変更搭載を前提でした
22:11 (YANMAR) 先ず混線ヘルパー各種をどこで出すか、が重要
22:12 (YANMAR) 親変更準備して成功したら、そこから混線という流れ
22:12 (dry_ice) どこで出すか…?
22:13 (YANMAR) 今までは混線の生成とかー2で出してたと思うけど、そのタイミングなりステートなりを従来から変える
22:14 (dry_ice) あー、タイミングですか
22:14 (YANMAR) 親変更前だとダメ
22:15 (dry_ice) んん?親変更前っていうのは親変更をするってことですかね?(もしくは開幕親変更?
22:16 (YANMAR) 前じゃ駄目って言ってるでしょ
22:17 (hitachi) ヘルパー展開→親変更完成→混線ターゲット取得→混線完成
22:17 (hitachi) こういうこと
22:20 (dry_ice) ん?え?
22:20 (dry_ice) ヘルパー展開は和kル
22:21 (dry_ice) わかる
22:21 (dry_ice) 親変更完成ってどういうこと・・・?
22:21 (hitachi) 親変更ができるヘルパー配置がってこと
22:22 (hitachi) まず必要な常駐と最終出してそれ以外はダミーで埋めなきゃならんの
22:22 (YANMAR) 親変更って、ID合わせたりで実行可能になるまで準備必要でしょ
22:22 (dry_ice) 親ヘルパー(ターゲット)から子ヘルパー(タゲ取り)出すってやつのことだよね…?
22:22 (YANMAR) その準備最中に混線はやっちゃいけないってことで、親変更の動作確認してから混線を行う必要があるってこと
22:23 (hitachi) ああすまん自分とヤーさんで指してる内容が少し違ってるみたいだ
22:23 (dry_ice) 動作確認だと…
22:23 (hitachi) 混乱の原因になるから自分は黙ってるわ
22:24 (YANMAR) 何か難しく考えすぎてるか日本語の理解かどちらかな気がする
22:24 (teki) 子ヘルパーを出す前に、親変更のための必要な手続きがありまして、その手続きが完了してから子ヘルパーを出すイメージ。
22:25 (dry_ice) なるほど
22:25 (YANMAR) 親変更準備(ヘルパー出したりID合わせたりぬるったり)>親変更完了>混線ヘルパー出す>混線完了、という流れ
22:25 (YANMAR) 混線ヘルパーってのは殴ったり生成したりのアレ
22:26 (dry_ice) あ、やばい
22:27 (dry_ice) 自分全然違うことしてたかもしんね
22:28 (dry_ice) 混線完了後に親変更の準備(ヌルヌルさせる)させるとばっかり思ってた
22:28 (YANMAR) それじゃ親変更が遅いってことですなー
22:29 (dry_ice) げぇ…
22:29 (YANMAR) その方式だと混線と親変更別々にヘルパー用意したり、肝心の親変更gametime貫通やっても混線で奪えない無意味の代物になる
22:30 (dry_ice) まじかぁ…orz
22:31 (YANMAR) 親変更「だけ」やるのはまぁいいのよ、そっからが本番
22:32 (dry_ice) おうふ…
22:32 (YANMAR) ただ人によっては面白いかもしれない。殺傷力を戻すってのが強くてニューゲーム、もしくは転生っぽくて(ryy
22:32 (dry_ice) あれ、でもヌルヌルさせるためにはhitpausetime必要っすよね?
22:32 (YANMAR) いるねー
22:33 (dry_ice) え?あれ?
22:33 (dry_ice) (どうやってヌルヌルさせるんだ)
22:36 (dry_ice) そこらは自分で考えるしか無いか…
22:38 (YANMAR) テンプレもあるし、実際の記述はそこ参考に
22:38 (YANMAR) ただ理解はした方が良いかと
22:38 (YANMAR) その為のテンプレだしねぇ
22:39 (dry_ice) ですか…
22:39 (mapelao) 親変更を理解するためのコツは、一つの解説を読み解くんじゃなくて、様々なヒトの言説をひと通り読んで全体像を理解することなんですよね
22:40 (mapelao) どんなに詳しく完璧に解説されていたとしても、最初のうちは全然理解できないんですよね、私もヘブンズさんのを熟読してよく分からんかったから、他の人の親変更の解説をいくつか参考にしてたし。
22:40 (teki) 手続きが必要なのは親ヘルパーの方なので、親の方の手続きが済んだら、子供が親をhitpausetimeつきで殴って消去させる、という流れのはず。
22:41 (teki) …字面だけだとひどい表現な気もします(笑
22:41 (dry_ice) www
22:41 (mapelao) ホントは怖いmugen凶悪
22:41 (teki) 勝手にひとの家の子供になって親の情報を抜き取る凶悪さ。
22:42 (mapelao) オレオレ詐欺だこれ!!
22:42 (YANMAR) 喫茶でオフってた時もこんな会話してたような…w
22:42 (dry_ice) あかんw
22:42 (mapelao) あ~話しましたね~w 冷静に考えると怖い親変更w
22:43 (hitachi) 赤の他人どころかそのへんの犬とか捕まえて親にしちゃう親捏造
22:43 (hitachi) 怖すぎる
22:44 (_609z) おお、こわいこわいww
22:47 (dry_ice) うん、一度分けるか…

親変更

3/4
22:22 (N-Fox) 親変更セット的な意味で
22:22 (Momizi) あぁ、公開しました(今更
22:25 (Momizi) 今回は何と・・・罠が無いよ!(親変更セット
22:25 (Ryusei) マジかよ
22:26 (Ryusei) 4領域までやってるんだっけ
22:26 (Momizi) 4領域までかぁ
22:26 (Momizi) そこまでやるなら1ステートで1~4Byte弄った方が良いかも
22:27 (Ryusei) ふ~む
22:27 (Momizi) そのうちやろうかと思ってたのよね、それ
22:27 (Momizi) 6689個目~6672個目までpersistent=128のigenorehitpause=1にして
22:27 (Momizi) トリガーでその領域弄るか管理すると良いよ
22:28 (Ryusei) まくべぇが3領域やってたからてっきりもみもみも4領域辺りもやってるのかなっと思っていってしまったでござる
22:28 (Momizi) 必要性感じなかったからねw
22:28 (Momizi) ただ、青眼氏にトリガー管理の話聞いて良いなぁって
22:28 (Ryusei) 2か3で十分だからね(
22:28 (YANMAR) とりあえずドラちゃんの親変更桁あわせ辺り見て貰ったらいいんじゃないかな(投げ槍
22:29 (Momizi) ふむ。それくらいなら
22:29 (Ryusei) がんばれ がんばれ
22:29 (Momizi) 私もちょっとやってみるか・・・というか、正直4桁目はデバッグ無理やで?(
22:29 (N-Fox) ふぁいとー
22:29 (Momizi) 256*256*256=16777216になるまでヘルパー生成とか死ぬ
22:29 (Ryusei) せ、せやな・・・
22:30 (Momizi) 仮に親変更テストキャラ相手に毎F25ヘルパー出せるとして
22:31 (Momizi) 大体671088Fかかるらしい
22:31 (Ryusei) (
22:31 (YANMAR) いらん子やなw
22:31 (Momizi) あって3領域やなぁ
22:31 (Momizi) ついでに積むくらいなら良いけど。デバッグはできん(
22:32 (Momizi) まぁ、机上での数値があってるかくらいなら見るけど
22:32 (dry_ice) てか俺通常(半領域?)親変更しかできてないんですが(
22:32 (dry_ice) 128の壁はいまだ分かってないでござる
22:32 (Momizi) 全領域も通常分かれば簡単よ
22:32 (dry_ice) えぇー
22:33 (Momizi) 128にしたいなら6689個目でpersistent=128のchangestate通ればおk
22:33 (_609z) mgk
22:33 (Momizi) 129にしたいなら6689個目でpersistent=129のchangestate通ればおk
22:33 (blue-eyes) 目的の値をもったpersistentを与えればそのままその値になります
22:33 (dry_ice) ふむ
22:33 (_609z) ふむふむ
22:33 (Momizi) そんな感じで1ずつ増やして行ったpersistent=Xのステートを128個用意すれば良い
22:33 (blue-eyes) どうでしたっけ、127もこの方法で行けるんでしたっけ?(
22:34 (Momizi) いけるよ
22:34 (blue-eyes) ということは究極的には
22:34 (blue-eyes) 0-255のを全て作れば通常型もくそもない(
22:34 (Momizi) 読み込み時間が犠牲になるがな
22:34 (blue-eyes) はい(
22:34 (lunatic__) サイズが倍になるよ、やったね(
22:34 (Momizi) 今最小いくつだっけ、20MBくらい?
22:35 (dry_ice) うわぁ…
22:35 (YANMAR) シンプル!
22:35 (_609z) 重くなるww
22:35 (Momizi) 全領域もトリガー管理で4領域目まで弄れるからその辺は良いんだけどね・・・
22:36 (Momizi) persistentさんは0から256までの数値以外は0として扱ってるのかな。よくわからんちん
22:38 (Momizi) せめて255でpersistent=128を通ったら-1してくれればこんなことには・・・
22:39 (dry_ice) うひぃ
22:40 (Momizi) あ、4領域目デバッグする方法あったよ。Alive等でテストすればおk

全領域親変更

3/3
01:40 (Momizi) 親変更セットの解説書いてて気づいた。全領域親変更って1Byte目に対してしかしてなかったんやね(
01:41 (Momizi) 2Byteも全領域化してたらヌルステコンだけで50MBになるわ
01:41 (YANMAR) あーw
01:41 (Momizi) つまり全領域親変更でも2Byte目まで対応だと多分最大256*128=32767までしか対応できない
01:41 (Momizi) 256*128-1=32767
01:42 (Momizi) でっていう
01:42 (YANMAR) そんだけあれば(ry
01:43 (Momizi) 50MBだと読み込み何分になるかなぁ・・・
01:43 (blue-eyes) ひとつの記述にまとめるのもありかと思いますよ、ignore値に書き換えられるのはそのステコンが実行された場合のみなので
01:43 (blue-eyes) そのステコンに入ってきた時点でその桁をずらすかを記憶しておいて、それによって目的の桁だけ実行するようにするとか。。。
01:44 (blue-eyes) どの桁を
01:44 (Momizi) あー、確かに
01:44 (Momizi) 6689と6690に同じpersistent値持たせてトリガーで制御すれば良いのか
01:44 (blue-eyes) そういうことになりますね
01:44 (blue-eyes) 私の場合は6689-6692全てに適応させてますが。。。
01:45 (Momizi) いや、流石に4Bytemいらへんやろ(
01:45 (Momizi) 4Byte目
01:45 (blue-eyes) あいにく不安症なものでして(
01:46 (Momizi) 167,216以上になる時点で何分経過してる事か・・・
01:46 (blue-eyes) 考えたくもないなぁ(
01:46 (Momizi) あ、違うや
01:46 (Momizi) 3Byteまでで256*256*256-1だから16,777,215以上や
01:47 (Momizi) その頃にはPC死んでそうやな・・・
01:50 (blue-eyes) [state ];シンクロトリガー
01:50 (blue-eyes) type=changestate
01:50 (blue-eyes) trigger1=var(20)=1
01:50 (blue-eyes) value=70013
01:50 (blue-eyes) persistent=137
01:50 (blue-eyes) ignorehitpause=1
01:50 (blue-eyes) [state ]
01:50 (blue-eyes) type=changestate
01:50 (blue-eyes) trigger1=var(20)=2
01:50 (blue-eyes) value=70013
01:50 (blue-eyes) persistent=137
01:50 (blue-eyes) ignorehitpause=1
01:50 (blue-eyes) [state ]
01:50 (blue-eyes) type=changestate
01:50 (blue-eyes) trigger1=var(20)=3
01:50 (blue-eyes) value=70013
01:50 (blue-eyes) persistent=137
01:50 (blue-eyes) ignorehitpause=1
01:50 (blue-eyes) [state ]
01:50 (blue-eyes) type=changestate
01:50 (blue-eyes) trigger1=var(20)=4
01:50 (blue-eyes) value=70013
01:50 (blue-eyes) persistent=137
01:50 (blue-eyes) ignorehitpause=1
01:50 (Momizi) var(20)が何Byte目か管理してるのねん
01:51 (blue-eyes) これが、白夜の対137専用の全領域ステートの6689-6692でして、ここに飛び込む前のループステートにあたる70013(?)にて、どの桁を弄るかをV20に記憶させてる訳ですね
01:51 (Momizi) んー、この方法使ったら通常親変更ステコンオバフロ1つでできるな・・・
01:54 (blue-eyes) 少なくともそれぞれの桁用に用意する必要はないですね、127なら127用に作るのは1つで十分です
01:54 (blue-eyes) 128なら、か(
01:54 (Momizi) せやな
01:55 (Momizi) ループ処理みすると怖いけどまぁ、しっかりやれば
01:55 (blue-eyes) 白夜が2P側にいるとたまに相手の親変更でループミス起こしてエラー落ちしますけど(
01:56 (Momizi) あるあ・・・・あかん(
01:56 (blue-eyes) まぁ原因が相手の親変更での変数修復が原因だと分かってるのでいい加減直さないと(
01:56 (Momizi) 2P側考慮してヘルパーに対する親変更感知導入しないといけないんだけどめんどくてまだしてねぇ(
01:58 (blue-eyes) 感知そのものはできるんですが、それを通常変数でやったのは流石にまずかったかしら(
01:58 (Momizi) あぁ、だから修復されると感知できんのかw
01:58 (blue-eyes) はい(
01:58 (Momizi) システム使おう(
01:59 (blue-eyes) SVがまだ余ってるか今度確認しとこう(

リンク:全領域親変更[MUGEN神キャラ置き場]

影のID領域

3/2
22:54 (Momizi) 影のID領域弄る時のchangestate可能領域って6709個目あたりだっけ?
22:55 (hitachi) 自分は未使用領域の6609を推奨してるけど6605でもたぶん問題ない
22:56 (Momizi) ん、6709?
22:56 (hitachi) helpertype2バイト目の6702でもたぶん大丈夫
22:56 (Momizi) ふむ・・・
22:56 (hitachi) ああ間違えた6700だ
22:57 (hitachi) 6600じゃない
22:57 (Momizi) できれば安全パイ取りたいし6709にしておくか
22:58 (hitachi) 全くなんで1プレイヤーあたり4kB近い未使用領域を作ったんだか
22:58 (Momizi) そんなにあるんか
22:59 (hitachi) palno(1993)からhelperID(6685)までは未使用のはず
22:59 (Momizi) あー、そのせいであの位置なのね

親変更時のParent,IDの2Byte目

3/2
00:09 (Momizi) 質問、というより確認だけど
00:10 (Momizi) 親変更時のParent,IDの2Byte目保存するときFloor(Parent,ID/256)って2Byte目の値だけではないよね?
00:10 (Oracle) そうっすね
00:10 (Momizi) おけおけ
00:10 (Momizi) 解説入れてるからテキトーかけないから確認したかっただけ
00:11 (Oracle) (parent,id&65535)/256しないとだめじゃな
00:11 (Momizi) せやな
00:11 (Momizi) その辺はあのbit演算のお蔭で大分理解できてるぞw
00:12 (Oracle) ないす
00:12 (Momizi) ヘブンズさんの場合2Byte目まで対応だから/256で良いだけやな

親変更

2/26
23:04 (Momizi) ふむ。やっと親変更のID調整の仕組みと全領域になんであれだけのオバフロステコンいるのかが分かった(
23:05 (Momizi) 129以上の値持ってる時に読み込むと強制的に0になるのが厄介なんやな
23:06 (Momizi) だからpersistent=129から256までの値を持ったステートがいると
23:07 (_609z) へぇ
23:08 (lunatic__) これね、いじるところがもっと近いならまだ良かったんだけどよりによってあの位置だからねぇ
23:08 (Momizi) ですねー
23:09 (Momizi) Alive領域とかにあるなら約1/12くらいまで軽くなるし・・・
23:17 (Momizi) ふむ。これpersistent=の後に何書いても問題ないのかね。文字列書いても落ちないし・・・(内部的にはpersistent=0扱いみたいだけど)
23:24 (Momizi) ふーむ。とりあえずこれで親変更セットのリメイクはできるな。頑張ってみるか

親変更

2/17
23:36 (dry_ice) ひたち氏ー
23:38 (hitachi) 何?
23:38 (dry_ice) あの親変更の記事あるじゃないですか(ひたち氏のブログの
23:38 (hitachi) うん
23:39 (dry_ice) [state ループ回数計算]
23:39 (dry_ice) type = varset
23:39 (dry_ice) trigger1 = sysvar(0) != parent,ID
23:39 (dry_ice) var(0) = sysvar(0)-parent,ID +128*(parent,ID>sysvar(0))
23:39 (dry_ice) ignorehitpause = 1
23:39 (dry_ice) この記述どこに置くやつなの?
23:39 (hitachi) 親変更のnull突入前
23:40 (hitachi) nullを何回ループさせるかを計算して
23:40 (hitachi) その回数だけnullを通すので
23:40 (Swtr) (独自記述とか憧れるけど私には無理だな(確信))
23:41 (N-Fox) 最初はコピペだろうと理解すればいいのです
23:41 (dry_ice) ヌルヌルステートにイラれるためのchangestate前に置くのか
23:41 (hitachi) そそ
23:42 (dry_ice) sysvar(0)-parent,ID +128*(parent,ID>sysvar(0)) ここの記述の意味って何ですか?
23:43 (dry_ice) 128がちょっとわからん
23:44 (_609z) persistentだっけな
23:44 (hitachi) 128の壁です
23:45 (dry_ice) あー、persistentか

0F親変更

2/14
01:30 (_609z) 5pに挑戦しようとしたが0F親変更とはなんぞ?
01:31 (emeru) 相手がヘルパーを出したそのFで相手に親変更を仕掛けること
01:31 (_609z) ふむ
01:32 (Anoth-blue-eyes) ヘルパーが召喚され、そのヘルパーのターンが回ってくるよりも先に親変更を完成させるんです
01:32 (Anoth-blue-eyes) ガードステートに篭られると通常はもう混線が効かなくなるんですが
01:33 (Anoth-blue-eyes) 召喚された瞬間であればまだステート移動が行われていないので
01:33 (Anoth-blue-eyes) この一瞬の隙を突いて親変更であらかじめステ抜け変数に定められた値を代入することで
01:33 (Anoth-blue-eyes) ガーステに篭られることなくヘルパーを奪うことができるというわけです
01:34 (_609z) なるほど。ってことはがめちめした瞬間奪えばいいなかな
01:34 (Anoth-blue-eyes) ですね、でもこれで本当に重要なのは
01:35 (Anoth-blue-eyes) ヘルパーが召喚されたその1Fで親変更を成功させないといけないところなんです
01:35 (emeru) 1Fでも遅れるとアウトなのがなぁ・・(
01:35 (_609z) すんごいシビアなのか...
01:36 (Anoth-blue-eyes) シビアというか、親変更の超精密なコントロールが求められ、親変更の原理などを真に理解してるかどうかが試されます
01:36 (_609z) おう...こりゃきついな。
01:37 (Anoth-blue-eyes) ループが必須なので・・・まぁこれができれば、親変更の精度はほぼ100%になると思います
01:38 (_609z) あ、いまの状態だと無理だ。
01:38 (emeru) 説明だけなら簡単なんだけどのー・・・ 言うは易し行うは難し・・
01:38 (Anoth-blue-eyes) ゑ(
01:38 (_609z) ぬるぬるでループしてないんですよね...
01:38 (Anoth-blue-eyes) 私も、1Fの習得にいたるまで相当時間かかりましたからねぇ・・・Cミストでさえループ型ではないですし
01:39 (_609z) ぬる→ループ準備→ぬるの繰り返しなんですよね
01:39 (Anoth-blue-eyes) ループ準備をぬるの中にも組み込みましょう(
01:40 (_609z) いまの現状だと。
01:40 (_609z) できる限りやってみるか。
01:40 (Anoth-blue-eyes) ファイトですー
01:41 (emeru) がんばです!
01:41 (emeru) 0F親変更取得すれば かなり幅が広がってくるからのーっ
01:42 (_609z) よっしゃー!燃えてきたぜぇ!
01:44 (Anoth-blue-eyes) ループ時の挙動と制御方法がわかるようになるので
01:44 (Anoth-blue-eyes) 凍結解除とかの制御もかなり楽になると思いますよー
01:45 (Anoth-blue-eyes) 逆に言えば、凍結解除とかと制御方法が同じ、とも取れますが。。。
01:45 (Anoth-blue-eyes) カラー偽装と復元のときはかなりお世話になったなぁ・・・この方法
01:46 (Anoth-blue-eyes) 特にこの方法が活きるのはalive偽装のときでしょうか。。。

0F親変更

1/29
03:10 (pkrs) 0F親変更の、0Fって何が0Fですか?
03:10 (pkrs) リック氏の親変更テストキャラ5Pと7Pに、「ガードステート固定なので0F親変更が必要です」とあるけど
03:10 (pkrs) 対象ヘルパーが呼び出された0Fで親変更を実行することで、ガードステートが読み込まれる前に、TargetStateが通るようにすることで良いのかな
03:12 (Ryusei) その通りであってたはず ヘルパーが出したフレームはガードフラグは立ってないので
03:12 (Ryusei) 出たフレーム だ
03:12 (pkrs) なるほど、ありがとうございます

親変更での変数保存先

12/15
20:21 (emeru) 親変更で弄った変数を元に戻す(モチロン、gametime貫通も併用
20:22 (Ryusei_) 構造分からんからあまりいえないが 混線ヘルパーに保存すればいいかな
20:23 (emeru) その混線ヘルパーにgametime貫通用に変数を割いちゃってます((
20:23 (Ryusei_) ん~親変更の場合さすがに混線ヘルパーぐらいしか保存は無理かな・・・
20:23 (emeru) だよねぇ・・
20:26 (Ryusei_) 俺のやり方は混線ヘルパーに保存してsys系で色々と判断、gametimeの感知は別ヘルパーで取得 という形にしてる
20:27 (Ryusei_) まぁ、後は間者ヘルパーを掴んでる混線ヘルパーに変数割いちゃう方法もあるかね・・・
20:30 (Ryusei_) ん~
20:30 (Ryusei_) ダメだこれ以上思い浮かばん
20:30 (emeru) 一応・・・ヘルパー固有のgametime貫通を金繰り捨てれば保存はできるんだけど これが無いと不安でねぇ・・
20:30 (Ryusei_) 他のヘルパーには移せないの?
20:32 (Ryusei_) まぁ、移した際にいつもの殺傷力になるのかどうかが問題だが(白目
20:32 (emeru) 常駐ヘルパーが7つあって、うち一つは相手本体用だから6つは保存が利く
20:33 (Ryusei_) その6つなら大丈夫じゃないの?
20:34 (emeru) そだねぇ・・けど後4つ足りない(
20:34 (Ryusei_) ん?wヘルパーに対して10個取得するのか?q
20:35 (emeru) 親変更で参照するヘルパーは10個です (変数節約の溜めに後ろは多重
20:36 (Ryusei_) ああ、
20:36 (Ryusei_) ・・・混線の名前を忘れた(
20:37 (Ryusei_) 思い出した、並列混線だ  並列混線じゃないのか~
20:37 (Ryusei_) あ~
20:38 (Ryusei_) そういやエメル氏は容量重視だったの思い出した(
20:38 (emeru) 全部参照しようとするとどうしても30以上ヘルパー出す事になってねぇ・・(
20:39 (Ryusei_) まぁ、そこらへんはエメル氏が判断するしか(
20:40 (emeru) んー、何とかするしかないかぁ・・fvarは諦めるとしてvarだけども何とか・・
20:41 (emeru) explodやprojを参照する方法も思いついたのよねぇ
20:47 (Ryusei_) 並列、多重を使う混線なら、保存するヘルパーは3~7個ぐらいでいいと思うよ
20:47 (Ryusei_) おれはてっきり全部並列かと思ってたからぬ
20:48 (emeru) どうしても軽さ重視になっちゃうぬ
20:48 (Ryusei_) 3個以上あれば何とか殺傷力はあるはず・・・多分

親変更

7/4
20:04 (dry_ice) 親変更について教えて欲しいです(
20:05 (dry_ice) あれって自分のヘルパーを相手のヘルパーの子にするっていうことですよね?
20:06 (dry_ice) んでそっからparentvarsetで変数弄りを行うってことですよね
20:06 (simotsuki) 正確には自分のヘルパーの親を相手のヘルパーに変更する
20:06 (dry_ice) この認識であってますか?
20:07 (dry_ice) あ、そっちか>ヘルパーの親を相手のヘルパーに
20:07 (simotsuki) うん、それでOK
20:07 (dry_ice) これって混線でやるんですかね?
20:08 (simotsuki) うーん、分ける事も出来るし一緒にする事も出来る
20:09 (dry_ice) うーん?
20:09 (simotsuki) まぁ一緒にした方がヘルパー数的にいいんでないかな
20:09 (dry_ice) あぁ、ヘルパー数が節約できるのか
20:09 (simotsuki) とりあえず親変更自体は混線はいらないはず
20:10 (dry_ice) fmfm
20:10 (dry_ice) 親変更セット(淡水氏の)をkfmにぶち込んで実験したですけどもいまだわからないんスよね
20:10 (dry_ice) んー
20:11 (simotsuki) あれって領域調整出来てるんだっけ?
20:11 (simotsuki) なんか親変更は全領域のが楽な気がする
20:12 (dry_ice) 領域もいまだわかってねぇっす・・・
20:13 (dry_ice) そもそもどうやって自分のヘルパーの親を相手のヘルパーに移すのかすら・・・
20:13 (dry_ice) null使うってのはわかってるんですが・・・(これも怪しい
20:13 (simotsuki) ステコンオーバーフローは使うw
20:13 (dry_ice) あ、それは使うんですね
20:14 (dry_ice) うーん・・・親変更セットもうちょい見たほうがいいかな。・・・
20:14 (simotsuki) もうやったの前すぎて忘れてそう
20:15 (dry_ice) www
20:16 (simotsuki) 確か親の管理してる値が255×255とかで管理されてた気がするからステコンオーバーフロー使ってその二つを無理矢理相手のヘルパーの値にすると弄れたんだった気がする
20:16 (simotsuki) 256だったっけ。まぁ細かい事はええんや
20:18 (simotsuki) 後親の位置を合わせんとね
20:18 (simotsuki) 最初のヘルパー出す段階で。
20:18 (dry_ice) 親のIDってやつですか?
20:19 (dry_ice) 混線作る前ですか
20:19 (simotsuki) いや、それはIDは関係無いかな。IDってのはその256だか255の方
20:19 (DRM) 一般には影のIDと呼ばれてるものやな
20:19 (dry_ice) 影のID・・・?
20:19 (dry_ice) やべ、ごちゃごちゃになりそうだ(
20:20 (DRM) ヌルヌルで弄るやつを影のIDって呼んでる
20:20 (dry_ice) 256ってのは256進数のことなのか・・・?
20:20 (simotsuki) 領域が二つあるからメンドイなw
20:21 (simotsuki) 混線と似たような意味の領域と全領域を使わずにIDを変化出来る範囲って意味の領域とw
20:21 (dry_ice) うへぇ・・・w
20:22 (dry_ice) 混線と似た領域っていうのは席取りのやつ見たなものかな・・・?
20:22 (simotsuki) そんな感じ
20:23 (dry_ice) 全領域使わないID変化ってのは・・・ステコンオーバーフローのこと?
20:23 (simotsuki) 親変更するヘルパーの親が居た領域に相手のヘルパーをこさせる
20:24 (simotsuki) いや、全領域でも全領域じゃなくてもステコンオーバーフロー自体は使うよ
20:24 (dry_ice) あら
20:24 (simotsuki) 全領域じゃない場合は親変更出来る影のIDを弄れる範囲が狭まる
20:24 (dry_ice) なるほど
20:25 (dry_ice) 限定された領域した影のIDしか弄れないってことなんですね(全領域じゃないと
20:26 (simotsuki) そうなるね。まぁ最初の方で決めるならそんなに問題は無い
20:26 (dry_ice) fm・・・
20:27 (dry_ice) 最初から弄るのと後から弄るのではやり方が微妙に違うって思えばいいですかね?
20:28 (simotsuki) あぁ、ごめん。最初の方で決めるならそんなに問題無いってのは忘れてイイヨw
20:28 (dry_ice) え、あ、はいw
20:30 (dry_ice) うぬぬ・・・ イマイチ分からない・・・
20:30 (simotsuki) まぁそりゃそうだw
20:31 (dry_ice) あ、そうだ nullステコンは特定数でいいんですかね?(要はループとかの記述は必要?
20:32 (simotsuki) ループもいるよ。全領域を文字通りの数にすればいらんけど
20:32 (DRM) (アカン)
20:32 (dry_ice) どんだけの記述量になるんだ・・・?(
20:33 (simotsuki) 54Mくらいでなんとかなるんじゃないか。多分w
20:33 (dry_ice) 全領域っていうぐらいだからすさまじい量が必要になると思うんですが
20:33 (dry_ice) wwwwwwwwwwwwwwwww
20:33 (dry_ice) そんな必要なのかよwwww
20:33 (simotsuki) まぁ全領域でも全部やってる人は多分いないじゃろw
20:34 (dry_ice) わぁお・・・
20:34 (simotsuki) 128以下は全部はいらんし
20:34 (dry_ice) 128ってのは?
20:34 (simotsuki) 127だっけ。ここもなんか曖昧だわw
20:35 (simotsuki) なんか影のIDって128だか127以下は1ずつ減らせるから全部を書く必要はないんだよね
20:35 (simotsuki) それ以上だと何故か1ずつ減らせないから全部書かなきゃいけない。それが容量がバカみたいに増える原因
20:36 (DRM) ヌルヌルで弄る=影のIDを1ずつ減らすって意味ですな
20:36 (dry_ice) あ、そうなの? 
20:37 (dry_ice) てっきり親変更のヘルパーのIDを弄るものだと思ってた
20:37 (dry_ice) 親変更をする
20:37 (simotsuki) うーん、なんつったらいいんだろ
20:38 (simotsuki) とりあえず親を決めてる領域を弄るのだよ
20:38 (simotsuki) 考えるな、感じるんだ
20:38 (dry_ice) えー?
20:39 (dry_ice) ヘルパーを弄るんじゃなくて領域を弄るのか?
20:40 (simotsuki) 領域って言い方が悪かったか。親を決めてる256×256の数字を弄る
20:40 (DRM) しもさんの言う、256*256の数字が影のIDだよ
20:41 (DRM) そういうものがあって、それを弄ると親変更が出来る
20:42 (simotsuki) これ中々説明がムズイな
20:42 (simotsuki) 最初ワシもまるで意味が分からんかったし
20:43 (dry_ice) ふむ~
20:44 (Oracle) 説明難しいよねぇ
20:47 (Oracle) parentvarが使える為の条件に親が存在していることと、影のidがparent,idと一致している必要があって
20:47 (Oracle) 親が存在しないといけないからまずヘルパーで領域を確保して親を作る
20:48 (Oracle) その親の領域に入ってきたヘルパーは、parentリダイレクトで参照できるけどparentvar系は実行できない
20:49 (Oracle) その原因が影のidの不一致で、そいつをステコンオバフロで親のidに合わせてやればparentvarを実行できるようになる
20:50 (Oracle) んで影のidは参照不可能だから、parent,idを記録しておいて、その数字を元にステコンオバフロで弄る必要がある
20:56 (simotsuki) なんかOTHKをこれから挑戦する人にOTHKについての説明をする時と似た感覚
20:56 (dry_ice) ぐぬぬ・・・
20:56 (dry_ice) 難しいな
20:56 (simotsuki) オラクルさんの説明は分かりやすく見える
20:59 (dry_ice) 親の領域に入ってきたヘルパーっていうのは相手ヘルパーであってますかね?
21:00 (simotsuki) そうだよ
21:00 (dry_ice) なるほど
21:02 (dry_ice) うーん、これを記述でやるのか・・・
21:06 (dry_ice) parentリダイレクトで参照っていうのはID記憶するためですかね?
21:12 (dry_ice) てかそれしかねぇな
21:12 (dry_ice) すいません、今の質問無しで
21:19 (dry_ice) ぬぐぐ・・・
21:28 (dry_ice) 混線の種類とかも考えたほうがいいですかね?現在は並列完全混線なんんですが
21:33 (Oracle) いんや混線の形は別に問題ない
21:34 (dry_ice) なるほど
21:34 (dry_ice) つーことは領域の方をどうにかした方がいいのかな・・・?(結構適当なママ
21:36 (dry_ice) 混線の領域に時止ヘルパー入り込んでるし・・・(
21:47 (dry_ice) うーん・・・
21:47 (dry_ice) 最終ヘルパー空いてるのもどうにかせんとなぁ
21:48 (dry_ice) 最終ヘルパーって大体マーキングヘルパー置くんですかね?
21:49 (simotsuki) 人によるでないか
21:50 (DRM) 後に5つぐらい置く人もいるしね
21:50 (simotsuki) 一応私はタゲ取りようのヘルパーと自分をタゲ取ったヘルパー2個置いてた気がする
21:51 (DRM) 自分は最終、情報収集、タゲ取りの3つかなー
21:51 (dry_ice) 自分をタゲとったヘルパー?
21:51 (DRM) 自分のタゲ取って、自分を管理するんやで
21:51 (dry_ice) ほへー、そんなことも出来るのか
21:52 (DRM) 向き弄りとか速度弄りとかへの対処
21:53 (simotsuki) まぁなんにせよ、最終はあると色々便利
21:53 (dry_ice) 情報収集って探査とかのたぐいですかね?
21:54 (DRM) それもあるし、それ以外も
21:55 (dry_ice) それ以外って言うと即死ステート取得のやつですか
21:56 (DRM) それ以外はそれ以外よ。色々あるってこと
21:56 (dry_ice) ふむ・・・?
21:56 (DRM) やっていくなら後々必要になるかもしれないから、まだいいよw
21:56 (dry_ice) はーいw
21:57 (dry_ice) まぁ、今のとこはタゲヘルパーでも置いとこうかなと
21:57 (simotsuki) 基礎…基礎を磨くのです…
21:57 (simotsuki) 基礎厨
21:58 (dry_ice) 超即死返しとか本体hitdefステート返しとかも覚えたいです(
22:00 (dry_ice) 超即死返しはオロチキラーの発展・応用、本体hitdef返しはOTHKの発展・応用と思っていますがあってますかね?
22:05 (DRM) 何とも答えにくい質問だなw
22:07 (simotsuki) 超即死返しは相手によるんじゃなかろか。Aユウキとかは割とあっさりいけた気がするし
22:07 (dry_ice) ふむふむ
22:07 (simotsuki) 本体hitdef返しってこれはもうどれかっていうか探査の一部じゃないのかw
22:08 (Oracle) まあオロチキラーの発展の一つではあるかな
22:08 (dry_ice) 探査にはいってしまうかー
22:11 (Oracle) 本体hitdef返しと混線OTHKは違うからね
22:12 (dry_ice) あら、そうなのかー(混同してた
22:13 (dry_ice) どっちみち探査はまだやれないだろうし超即死返しとか、混線の精度上げてこうかな―
22:14 (dry_ice) 後は親変更の理解
22:30 (dry_ice) ヘルパー整理するかぁ

親変更

3/9
23:26 (hitachi) ver1.0系列の普通KFMの親変更が重かったのは理由がある
23:27 (hitachi) persistent弄りを利用して1桁目をあわせてたんだけど
23:28 (hitachi) persistent弄りを利用すると以下3バイトが0になるから
23:28 (hitachi) 値の変動の有無関係なしに親変更nullを大量に読む必要があるという
23:29 (hitachi) それが完全並列で最大24個のヘルパーがやるから…すごく…重いです
23:30 (Oracle) ガクガクじゃないか
23:31 (hitachi) それをアドレス全部取得して全ヘルパーが%nで親変更するようにしたのが2.0系列で
23:31 (hitachi) 結果めっちゃ軽くなった
23:32 (hitachi) ついでに容量も減った
23:37 (Oracle) ふむふむ

全領域親変更

6/21
20:42 (teki) あ、そういえばお聞きしたかったですが、いわゆる「全領域」というのは、デバッグで言う、「1:自分」「2:相手」「3~:全領域」ということなんでしょうか?
20:42 (Momizi) デバッグの時はまぁ、切るかなぁ。まったく関係なければだけど
20:43 (Momizi) よく聞かれる質問だぬ
20:44 (Momizi) あった
20:44 (Momizi) これ参考になるかにゃ。http://awmm.blog3.fc2.com/blog-entry-571.html
20:44 (vesperAFK0) [URL] 全領域親変更 - 流れる時の中で
20:44 (emeru) 全領域かー 持ってないなー・・
20:45 (Momizi) 128の壁越えるだけだから難しくはない。ただめんどいだけで
20:45 (ryusei_) 記述がな・・・
20:46 (Momizi) 数万行のステコンオバフロステートを128個書かないといけないからね。コピペでもめんどい
20:48 (teki) おお、記事拝見しました。情弱ですいません、勉強になりました。
20:48 (Momizi) ケータイから書いた記事だからすっごい見にくいw
20:48 (ryusei_) 変数化できたらいいのにね!
20:48 (Momizi) persistentがね。
20:49 (Momizi) 全領域の話になると必ず出てくるよね、persistentの変数化(
20:50 (ryusei_) もう自分用にテンプレ化できたら問題ない気がしてきた
20:51 (Momizi) んだね。ただ人様の参考にしてもかなり改変がめんどい
20:51 (ryusei_) ぬるめーかーつかえばいいんじゃね
20:51 (ryusei_) あれ、なにかとつかえるし
20:51 (Momizi) 使ってるよん
20:51 (Momizi) ただ行数多すぎて稀に固まる(
20:51 (ryusei_) 他の記述にも使えるし
20:52 (Momizi) ステコンオバフロは基本的にぬるめーかーで書いてるかなぁ
20:52 (ryusei_) たまーにしかExplod占有ステコンにしかやってないな・・・>他の記述
20:52 (Momizi) コピペでステコンこぴってても絶対途中で数わからなくなる自信あるし(
20:53 (teki) あの数ですからねw
20:53 (Momizi) 後は混線用のヘルパー生成記述とかもぬるめーかー使ってる
20:53 (Momizi) @機能がかなり便利
20:54 (ryusei_) 便利やな
20:55 (ryusei_) 本当に

参考:連番作成[MUGENの便覧]

0F親変更

1/20
22:58 (eta) 質問すみません、0F親変更って一体何なんでしょうか?
23:01 (okihaito) 出したばかりでまだ行動してない敵のヘルパーに親変更を仕掛ける事
23:03 (eta) 開幕混線的な感じでしょうか?
23:05 (okihaito) 開幕混線とはまた違うと思う
23:09 (eta) なるほど、0F親変更は試合毎に必ず100%成功しますか?
23:09 (okihaito) 全領域ならね
23:10 (okihaito) 弄れるIDなら成功する
23:10 (okihaito) 絶対成功させたいなら全領域にしないとダメだね
23:12 (eta) 親変更チェッカーで5pの0F親変更が即死出来るときと出来ないときがあるんですが
23:13 (eta) 領域外だからなのでしょうか
23:13 (hitachi) 即死できない時のID見たらわかるはず
23:14 (hitachi) たぶん領域外なんだと思うけど
23:18 (eta) 分りm下見てみます、ありです

親変更

1/15
00:00 (eta_) 親変更をやる前に
00:01 (eta_) これはやっとけみたいなのがあれば教えて下さい、汎用でこれは最低限倒せみたいなのもあればお願いします
00:02 (YANMAR) 邪眼とgametime貫通あるなら親変更に挑戦して良い頃合だと思います
00:03 (eta_) わかりました、ありがとうです
00:32 (eta_) 親変更は何か混線みたいに種類ってありますか?
00:33 (YANMAR) 通常、全領域、完全の3種程度?
00:33 (okihaito) 全領域か否かくらいじゃね?
00:33 (YANMAR) 通常と完全は混線と同じように考えていいです、56領域どこに出てても親変更仕掛けれるような
00:34 (eta_) 全領域と完全の違いを教えて欲しいです
00:34 (YANMAR) 全領域は対象のヘルパーIDがどうだろうが親変更を仕掛けれます
00:35 (DRM) 全領域って紛らわしいなーって前から思ってるんだけど、全IDとは誰も言わない
00:35 (YANMAR) 領域ってヘルパーの領域ってのにも解釈できちゃうしね
00:35 (ryusei_) あれ全領域は全IDと一緒の扱いじゃないの?
00:36 (emeru) そういや全領域は積んでないなぁ・・・
00:36 (okihaito) そもそもparentをちゃんと理解してんのかね
00:37 (okihaito) そこらへんしっかりしてないと親変更はきついとおもう
00:37 (ryusei_) emeruさんの場合軽さ重視だから全領域いらないと思うぬ
00:37 (eta_) 難しいですね・・、雷神の親変更を参考にしようと思うのですが雷神はどの種類ですか?
00:38 (YANMAR) 完全親変更になるのかな
00:38 (emeru) 全領域が軽ければ積むのにのぅww ウチの低スペPCめw
00:38 (YANMAR) 全領域ではないです
00:38 (okihaito) 全席対象くらいか
00:38 (eta_) ありがとです
00:39 (okihaito) スペック関係無しなレベルだと思うが
00:39 (okihaito) 邪眼みたいなもんだし
00:40 (eta_) 後、開幕完全並列混線を維持したまま完全親変更はできますか?
00:40 (YANMAR) できます、というか完全並列から親変更に移行すれば自然とそうなります
00:40 (okihaito) parent調整してたら混線そのままでいけるよ
00:41 (eta_) そうですか、わかりました

親変更でのSelf

12/29
14:37 (ryusei) 親変更でのオバフロはSelfとかはダメなんですかぬ?
14:38 (blue-eyes) selfでも行けるとは思いますがchangeでも大差ないはずです
14:38 (ryusei) オバフロというかアドレスでの弄るさいだ
14:38 (ryusei) fm いけるのか~
14:38 (blue-eyes) ただ、まぁ私自身よく分からないのでchangeを使ってます
14:39 (ryusei) 誰かがSelf使ったらダメとか言ってた記憶があったので>アドレスでのオバフロ
14:39 (blue-eyes) 私の記憶では、ステート移動をトリガーとするらしいので、selfでも問題ないってことだった記憶が
14:40 (ryusei) fm~なら勘違いかぬ
14:40 (blue-eyes) でもまぁ、一応changeをお勧めしますね どうせ相手が入りこんできたらその時点でエラー確定ですし
14:41 (ryusei) 確かオバフロは一番上にチェンジステコン入れても防げないだっけ?>エラー
14:41 (ryusei) ステコンオバフロ
14:41 (blue-eyes) 無理です、そのステートに入った瞬間にエラー吐きます
14:42 (ryusei) ん~ならステ番号変えるかぬ
14:42 (blue-eyes) というかその程度で治るなら苦労しない(
14:42 (ryusei) たしかにwそれだったらみんないれてますからねw

3領域目まで全領域親変更の容量軽量化

12/2
16:40 (simotsuki) あー
16:40 (simotsuki) 妙に容量でかくなると思ったらこれみんな2領域目は全領域にしてないのか~。ってか普通に考えたらそこまでイランなw
16:41 (YANMAR) そこまでいかないからのぅw
16:41 (simotsuki) 無駄な事してしまった
16:42 (simotsuki) 時止め解除を被弾式にすれば3万2000もいかないかw
16:51 (simotsuki) ぬー全部書きなおしだ
17:11 (mapelao) 3領域目まで全領域にしてるけど容量気にならないんだけど(
17:12 (mapelao) 書き方の問題じゃないかね
17:20 (simotsuki) ん、これ3領域目までやったら普通に60M超えてしまう気が
17:20 (mapelao) いやいや
17:20 (simotsuki) もしこれをかなり圧縮出来たんだとしたらそれは相当な発見かと思いますけどw
17:20 (mapelao) ちょっとCNS一部さらしますね
17:21 (mapelao) 別に特別なことはやってないんで
17:21 (mapelao) [state ]
17:21 (mapelao) type=selfstate
17:21 (mapelao) trigger1=sysvar(0)=6
17:21 (mapelao) value=604000
17:21 (mapelao) persistent=129
17:21 (mapelao) ignorehitpause=1
17:21 (mapelao) [state ]
17:21 (mapelao) type=selfstate
17:21 (mapelao) trigger1=sysvar(0)=5
17:21 (mapelao) value=603000
17:21 (mapelao) persistent=129
17:21 (mapelao) ignorehitpause=1
17:21 (mapelao) [state ]
17:21 (mapelao) type=selfstate
17:21 (mapelao) trigger1=sysvar(0)=4
17:21 (mapelao) value=602000
17:21 (mapelao) persistent=129
17:21 (mapelao) ignorehitpause=1
17:21 (mapelao) これの上の方で、
17:22 (mapelao) [state ]
17:22 (mapelao) type=changestate
17:22 (mapelao) triggerall=(sysfvar(0)=256002.0&&sysfvar(0)!=0.0)=0
17:22 (mapelao) trigger1=1
17:22 (mapelao) value=320000
17:22 (mapelao) persistent=256
17:22 (mapelao) ignorehitpause=1
17:22 (mapelao) こんなのがあったり。
17:23 (mapelao) 要するに、sysvar(0)の値で3領域目から徐々に弄ってって、
17:23 (mapelao) 1番上の領域をそろえてく的な。
17:25 (simotsuki) それってトリガー満たさなくても上の値弄っちゃわないですか?
17:25 (mapelao) ですよ。でも、
17:25 (mapelao) 下の値をまず調整してから、
17:25 (mapelao) 上の値を調整してくので
17:26 (mapelao) 一番下の方にある3領域目をまず弄って、
17:26 (mapelao) それから3領域目を弄らないようにして2領域目を弄る
17:26 (mapelao) で、最後に1領域目弄ってEND
17:28 (simotsuki) ん~?ちょっと理解が及ばんw
17:29 (mapelao) ありゃ
17:29 (mapelao) んー・・・
17:29 (simotsuki) とりあえずやりたくなったらその時また教えて下され~
17:29 (mapelao) あ、はい。了解です
17:29 (simotsuki) 今は理解出来るとこまででやってみますぜい
17:29 (mapelao) がんばです?
17:30 (mapelao) がんばです
17:30 (simotsuki) うい~

19:53 (simotsuki) ちと聞きたいんだけどDRMさん、全領域親変更って2領域目もやってる?
19:54 (DRM) やってない~
19:54 (simotsuki) そっか~
19:54 (DRM) 容量ヤバいっすw デバッグする気にならんw
19:54 (simotsuki) あーやっぱそうなるよね?w
19:55 (simotsuki) mapelaoさん曰く特に容量増やさずに出来るらしいんだけど
19:55 (DRM) ナンヤテー
19:55 (simotsuki) いまいち理解出来んかったのよね
19:56 (hitachi) その話どこでしてたの?
19:56 (simotsuki) 雑談ですよ~
19:56 (hitachi) 親捏造利用でもないと無理だと思うんだけどなあ
19:58 (DRM) 何をすればできるんだろうか
19:59 (simotsuki) ちと私がそこまで親変更にまだ詳しくないから深くは聞けなかったんさ~
19:59 (hitachi) persistentの変数化?
20:00 (hitachi) は親捏造利用じゃないと無理だし
20:00 (simotsuki) あーいや、多分1領域目とほぼ同じ容量で2領域目以降も出来るって話かと思います
20:00 (hitachi) ああそっちか
20:01 (hitachi) トリガーの条件が満たされないとpersistentをアドレスに書き込まないから
20:02 (hitachi) 1つのステートに1~4領域目用のchangestateを入れても大丈夫ってことだと
20:08 (simotsuki) ん、親変更の領域はそうなのですか
20:08 (simotsuki) aliveとかはトリガーの成立有無関係無かったから全部トリガーは無意味かと思ってた
20:12 (simotsuki) それともpersistentの問題…?うーんここら辺は良く分からぬ
20:13 (kamase) aliveでもトリガー成立しないとpersistentの値は書き込まれないよ そうじゃないとアルファゼロの恋星の専用対策が機能しないw
20:17 (simotsuki) うーんとトリガー成立せずともaliveは書き変わったっぽいのですが、この場合はaliveだけ書き変わってpersistentは変化なしって事で良い感じですか?
20:22 (kamase) 成立しない場合は恐らく0を書きこまれると思う アドレスの値を調整するならchangestateを入れて4領域目→3領域目→2領域目→1領域目の順にトリガー成立させる必要があると思う
20:25 (hitachi) どこだっけかなーdrab氏のブログにpersistentの処理に関する記事があったと思うけど
20:26 (simotsuki) なるほど
20:30 (simotsuki) ちと聞きたいのですがアドレスを128以降にする為のchangestateってそれでステートってちゃんと移動しましたっけ?
20:33 (kamase) 凍結の仕様の所為で移動しない場合もありますが、基本的には移動しますよー
20:34 (simotsuki) ふむふむ。ありがとうございます
20:38 (hitachi) http://blog-imgs-54-origin.fc2.com/d/r/a/drabs/winmugen_persistent.txt
20:38 (vesper_AFK) [URL] No Title
20:38 (simotsuki) って事はmapelaoさんの言いたかった事は上でかませさんが書いたみたいに4合わせたら次は3を弄りつつchangestateで次を読み込ませないようにして~次は2、1って感じで
20:38 (hitachi) これ…だっけ…?なんか他にもあった気がするけど
20:38 (simotsuki) 合わせていくってことかな?
20:38 (hitachi) そんな感じじゃないですかね
20:38 (simotsuki) なるほど~
20:40 (kamase) そのやり方は実はdrab氏が書いたやり方だったり(大いに参考になりました
20:43 (simotsuki) 普通に移動するなら私もそれで2領域目もやってみよかなw

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

親変更

10/31
00:11 (eta_) すみません、親変更とはこちらの自己完結で干渉せずとも相手ヘルパーの変数を弄る事が出来るんでしょうか?
00:11 (rakurai_) イエス 通常変数オンリーだけどね。
00:12 (eta_) それって防ぐ術はあるんでしょうか?
00:13 (YANMAR) ヘルパー通常変数を使わない、しか対策はないです
00:13 (YANMAR) 全領域が見つかる前はID調整で回避できたんですけどねぇ
00:13 (rakurai_) 相手の親変更を受けたら出し直してーって出来なくもない ・・・重いか
00:15 (YANMAR) 重要変数は使わないようにして、殺傷力に関わる奴とか代入するのは使う感じかしら
00:15 (YANMAR) 親変更使ってくる相手にどのみち即死通らないしw
00:15 (eta_) そうなのですか?2P側が神最上位で相手が1P側で親変更持ちだとやはりヘルパー変数めちゃくちゃに?
00:15 (rakurai_) 親変更持ちで即死効く相手・・・
00:16 (rakurai_) ・・・凍結当身が効く相手イタヨーナ
00:16 (YANMAR) 非道魔女が過去にいけたかな
00:16 (YANMAR) 探査持ちなのにヘルパー奪えてあゆあゆキラーだったかな
00:16 (ni-san) ガネクロくらいじゃね
00:17 (eta_) じゃ2P側なら殺傷力維持は諦めるしか?
00:18 (ni-san) アキラメロン
00:18 (rakurai_) 混線をある程度維持しつつ、ヘルパー埋まらないように努力だね、2P側は。
00:18 (ni-san) 最終ヘルパーもまずとれんしのう
00:20 (eta_) そうですか・・・残念です、まぁ親変更使うようなキャラが1P側とか即死出来そうもないし別に気にしなくてもいいのかな、ありです
00:21 (ni-san) 2P側で親変更して相手を倒すとかはもう完全に趣味の領域だと思っていいかと
00:21 (mapelao) あー・・・やっぱりそんなに難しいものなんですね・・・
00:22 (mapelao) p2側からの親変更って・・
00:22 (ni-san) 相手のほうが先にヘルパー出す以上
00:22 (ni-san) まず領域に入らんですからねえ
00:22 (rakurai_) 全領域にすれば・・・
00:22 (ni-san) 2P側じゃ親変更で倒せないのもいた気がする
00:22 (rakurai_) ・・・それでも親の位置に出さないとダメだから無理か

親変更

9/28
01:26 (simotsuki) DRMさんの記事でちょっとだけ親変更理解出来た気がする~
01:26 (DRM) 今ちょうどコメしたw
01:27 (DRM) 参考にしてくれてどうもです
01:27 (simotsuki) あの記事かなり分かりやすかったっすわぁw
01:28 (simotsuki) 知りたかった事がほとんど書いてあった感じ
01:29 (DRM) ミステイクからのヒントって記事かな?
01:29 (simotsuki) ですです
01:30 (DRM) あれ過去ログ探しても無かったので、良い機会だなーと思って書いたんですよね~
01:31 (simotsuki) うむ~。大分助かったw
01:31 (DRM) お役にたてて何よりっすw
01:31 (simotsuki) 親変更部分だけが分からないならあの記事見れば誰でも理解できそうw
01:33 (DRM) そうかなw それなら嬉しい【*´∀`*】
01:35 (DRM) しかしループとPersistentの関係は親変更の関門だねぇ
01:35 (simotsuki) ふむ…
01:37 (DRM) 何で256で割ったり、その余りを求めたりするのかがなかなか理解しづらい
01:37 (simotsuki) む、256で割るのとその余りを出す理由はもう平気さ~
01:38 (simotsuki) 親変更セット見てそこまでは理解出来た感じ
01:39 (simotsuki) ってか一般論の事かw

親変更

8/16
22:40 (hitachi) changestateならpersistent = 128の壁を突破できることはわかったんだが…うーん…
22:47 (hitachi) うーむ…persistent = 255でいいんだよ…なあ…?
22:47 (okihaito) 256じゃね?
22:48 (hitachi) 256でやったら4ビットじゃオーバーフローして0000になりませんか?
22:48 (okihaito) ループの話じゃ無かったのか ごめわ
22:48 (hitachi) 4ビットじゃない2ビットだ
22:49 (hitachi) 全領域親変更に
22:49 (okihaito) 128以降はそれぞれ用意するしか今の所手がないねー
22:49 (hitachi) 挑みたいのですが今ひとつ書き換えの性質が掴めない
22:50 (momizi_y-) 全領域は通常+128~255全部
22:50 (hitachi) ああpersistent= 128~255のchangestetteを全部用意するのか
22:50 (momizi_y-) です
22:51 (okihaito) 容量バカでかいから困りもの
22:51 (hitachi) 単純しかしくっそめんどくせえw
22:51 (qeg) persistentに変数使えないのって最悪
22:51 (okihaito) うむ
22:51 (momizi_y-) 頑張っても25MB前後ですからねぇ
22:51 (okihaito) 20Mは絶対超える
22:52 (momizi_y-) 頑張らないと30mb越えますが…w
22:52 (hitachi) ああこれはmacbeth氏が4領域目は趣味と評するだけのことはあるなあw
22:52 (YANMAR) 2領域あれば充分だしのぅ
22:52 (momizi_y-) 4領域目は正直わりにあわない

親変更

8/14
19:27 (hitachi) 今度は2500ループがあああああ
19:43 (hitachi) いよっしゃあああああああああああああああああああああああああ
19:44 (ni-san) どうしましたw
19:44 (hitachi) ついにAliveを任意の値に書き換える実験に成功した
19:44 (hitachi) あとはこれをparent,IDに変えるだけで親変更じゃああああああああああああ
19:45 (ni-san) そうだっけ?(;´∀`)
19:45 (hitachi) …たぶん
19:46 (hitachi) もしかして書き換えるのをAliveじゃなくて親のIDにするだけじゃないの?
19:47 (Momitan) そうですよ。陰のidも弄る必要ありますが
19:49 (hitachi) いやあテンプレみてもよくわからんかったから自分なりの解釈で適当にやってたらここまで到達するのにえらい時間かかった
19:50 (Momitan) あのテンプレ正直黒歴史にしたい(
19:50 (ni-san) 作りなおそうぜw
19:50 (Momitan) 簡単に言うがめんどいんだぞー。
19:51 (ni-san) うn
20:34 (hitachi) 親変更テンプレのNull見てたんですけど
20:35 (hitachi) 親IDの領域からずいぶん離れたところにchangestateがあるのはなんでですか?
20:36 (Manju-) あれねー、あの辺危険地帯なので近場でチェンジができぬ。
20:36 (hitachi) なんか弄っちゃいけないものでもあるんでしょうか
20:36 (Manju-) 確かrootとかが密集してたと思いますん
20:37 (Manju-) 捏造に使うのもあの辺ですからねー、不用意に弄るとすぐ落ちますん
20:39 (Manju-) まぁ、アドレスに関しては私は殆ど手をつけてないのであまり深くは言えませんが。
20:39 (Melt_nemu) あの辺はヘルパーの参照先を弄るものばかりだからね
20:40 (Manju-) アドレスはそのうち詳しく見てはみたいんだけどねぇ。抜け出せなくなりそうだから放置してる
21:07 (hitachi) いよっしゃああああああああああああああああああああああああああああああああああああああ
21:07 (hitachi) http://blog-imgs-55.fc2.com/h/i/t/hitachi5300/mugen0.png
21:07 (YANMAR) おめー!
21:08 (hitachi) 長かった、ここまでめっちゃ長かった
21:12 (hitachi) さあ次は本キャラにこれを移植だ
21:14 (Manju-) 親変更のめんどさは他の殺傷力と両立させることだってじっちゃんがいってた
21:15 (hitachi) 何、移植の際の拡張性は考えて作ってある
21:16 (hitachi) がしかしこれやりたいことやってると変数足りるかなあ
22:00 (hitachi) うおあああああなんじゃこりゃああああ
22:00 (hitachi) めっちゃくっちゃ重くなったあああああ
22:26 (hitachi) よしよしちゃんと移植しても動いたな
22:27 (hitachi) しっかし元の親のIDが127超えてると親変更できないのがめんどいなあ
22:32 (hitachi) 本体親変更って普通の親変更の要領でIDをenemy(0),IDに書き換えるだけじゃ駄目なんですか?
22:32 (Melt_nemu) そうですね
22:33 (hitachi) 駄目なんですか
22:33 (okihaito) 敵本体をparent参照できないと意味ないんじゃないかな

親変更

8/10
22:09 (okihaito) 変数未使用で親変更とかできませんかね?
22:09 (okihaito) Explod保存とかの面倒事はなしで
22:10 (rakurai) animelemtime(1)とか利用してみる?
22:10 (okihaito) アニメか…
22:10 (Rick) ElemNoを100000くらい用意しないとね・・・
22:11 (okihaito) それ一つでできるのか?
22:11 (Rick) 親変更に必要な変数は2つくらい必要かな・・・
22:11 (rakurai) んー条件分岐を考えたらanimを複数用意した方がいい
22:12 (Rick) だからElemNoを100000用意したものを複数作ればビット代わりになる
22:12 (okihaito) 2つでできるのは確認済み
22:12 (okihaito) ふむー
22:13 (okihaito) アニメ変数代用か…処理どれくらいだったかなー
22:14 (okihaito) つかelem100000も居るのかな

全領域親変更

7/17
17:17 (macbeth) しかし
17:17 (macbeth) 全領域親変更持ってるキャラで2領域目以降もやってるキャラほんと少ないなぁ…
17:18 (mapelao) 若干処理が面倒くさいからですかねw
17:19 (mapelao) 3領域目以降はともかくも、2領域目は普通に要りますよね?
17:20 (mapelao) 自分は、出し消し対策で3領域目も一応入れてますけど。
17:20 (macbeth) 2領域目まで全領域で対応しておけばID65535まで対応できますねぇ
17:20 (macbeth) 2領域目までアレは大体は十分かと
17:21 (macbeth) まぁ3領域目までやればまず間違いなく試合中に親変更ができない状態になることはないですけどね
17:22 (ryusei_) fm 4領域目か・・・
17:22 (ryusei_) 3領域目
17:22 (macbeth) 流石にID16777215を超えるようなことはまずないはず、多分
17:22 (macbeth) ってか超えるまで誰が見るというのだ(;´Д`)
17:22 (mapelao) ですよねーw
17:23 (macbeth) まぁ大体は2領域目まで対応してれば問題なし、3領域目もあれば万全、4領域目は趣味
17:23 (macbeth) うん、4領域目は趣味だよ多分(
17:23 (ryusei_) 趣味か~
17:23 (macbeth) まぁ全領域を入れる過程で4領域目まで対応できる構造にはしたんだけど
17:23 (macbeth) 正直いらない気がして(
17:24 (macbeth) 1677万個もヘルパー出し入れする時点でまず大惨事な気がするんだ(
17:26 (mapelao) 毎フレーム24個ヘルパー出し入れしたとしても、約70万フレームかかるwww
17:26 (ryusei_) 逆に考えるんだ!出し入れしてたら重くなってしまうということを!
17:26 (macbeth) ちなみにIDを3万フレーム進めるのに私のPCではデストロイループを使って10秒くらい必要
17:27 (macbeth) 仮にデストロイループを使って1677万進めると仮定すると5590秒かかるらしい
17:27 (mapelao) 30000/56で約535フレームですね
17:28 (macbeth) ヘルパーの出し入れって結構重いから現実時間に換算するともっとかかるのよね(
17:28 (mapelao) やめろォ!想像したくねえwなんという地獄だ。。
17:28 (mapelao) 一時間以上はかかりそうですねえ
17:29 (Muen) ~~~ッッッ
17:29 (macbeth) 私のPCだと約100分かかるらしいw
17:29 (GGG) うわぁw
17:29 (mapelao) fps10とすると、5590*6/3600で9時間以上の死闘だwww
17:30 (Muen) うぇw
17:30 (macbeth) それを考えると、何が悲しくて4領域目まで考えにゃならんのだという結論にねw
17:30 (mapelao) まあ論理的に完全だから、4領域目まで補完したいって気持ちは分からなくもないですけどねえ。。
17:30 (macbeth) というより
17:31 (macbeth) 3領域目まで対応すると大体4領域目まで対応できるからおまけ感覚というか
17:31 (mapelao) あー。。
17:31 (macbeth) 気持ちの問題というか好みの問題というか、結局は趣味の問題というか…w
17:32 (mapelao) 自分は、変なアドレス弄りたくないから、4領域目をpersistent=0のchangestateに利用してますねえ。
17:32 (mapelao) 256
17:32 (mapelao) だった
17:32 (macbeth) 私は何個ずらしてたかなぁ
17:32 (macbeth) あそこら辺、割と危険地帯だから危ないのよねぇ
17:33 (macbeth) 親捏造用のメモリも近くにあるし
17:33 (macbeth) rootの管理もあったはずだから油断すると落ちる落ちる

親変更軽量化

4/30
01:38 (macbeth) とりあえずパッと見は普通の親変更に見えるけど…
01:38 (okihaito) 敵がヘルパー出したときちょびっと重くなるんだよね
01:39 (okihaito) 試合前の読み込みの重さ以外だと気になるのはそこだけ
01:40 (macbeth) ふーむ
01:40 (macbeth) うーん、これ以上軽くするとなると親変更のnullをもっと分割するしか…
01:41 (macbeth) とりあえず親変更部分の記述を見た感じだとかなり効率化されてると思いますねぇ
01:42 (okihaito) そうなの?前とあんまり変わらないんだけど
01:42 (okihaito) null分割かー・・・やった事ない分よくわからんのよねぇ
01:42 (macbeth) それは多分
01:43 (macbeth) 影のIDのリセットのループのせいじゃないかな
01:43 (macbeth) 記述自体は効率化されてるけどそれで相殺されてるんだと思う
01:43 (okihaito) んーと リセット部分を必要以上に読み込んでると?
01:44 (macbeth) いや、リセットの関係で結果として前と変わらない量を読み込んでるんじゃないかなぁと
01:46 (okihaito) ふーむ…? 今の記述から改良できそうな点とかありますかね?
01:46 (macbeth) 32、64、96、128で分割してるのをさらに細くするとか…
01:48 (okihaito) んー ということは読み込む回数や巡るステートを要チェックしないとなぁ・・・ コピペだからここら辺わからなくて辛いわー

 |   |  次のページ

 検索フォーム


 全記事表示リンク

 全記事表示(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


基礎リンク集


リンク

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