2017.07.  12345678910111213141516171819202122232425262728293031 2017.09.
残像移譲バグ

根本的な原因は不明のままだけど
とりあえず意図的に起こせるようになったので起こし方を

1.ヘルパーを出しそのヘルパーに残像を使わせる
2.そのままF4
3.本体が残像を使う(誰でも良い)
4.ヘルパーを出してその射出した瞬間にヘルパーに残像を使わせる

4の段階で本体の残像がヘルパーの残像になります
そしてその状態でさらに本体が残像を再使用すると
その本体の残像がヘルパーの残像になります

バグった両者の残像アドレスはうさみみで見てもやはり同期しており
どちらがafterimage系ステコンを使ってもアドレスが同じな為両者に干渉されます

何故同期してしまうのかは謎_(:3」∠)_
極稀に意図せぬプレイヤーの残像が付いちゃう事は前々からあったけど
意図的に起こせたのは初めてかな?
何でこうなっちゃうかは誰か任せた

【追記】
3の行程は本体でなくとも良く
最初の残像実行者とその次の残像実行者が同期してしまうので
ヘルパーAが残像を使い、ヘルパーBを出して直後に残像だとバグ発生でヘルパーAの残像がヘルパーBになってしまう


( 2017.08.10 ) ( MUGEN ) ( COMMENT:0 ) ( TRACKBACK:0 )
でばふろ

DBOFとりあえず自作の任意コード実行させられました
今までは任意コード部分は組めてもそれの呼び出しができなかったり何処に帰れば良いのかさっぱりだったり
DTCtext上では問題無いのに起動しなかったりと躓いてばかりだったけど
ようやくここまで到達 小さくも大きな一歩と言えるでしょう

修復込みでは一番最初の読み込みでしか働かんので
毎回読ますにはどーすりゃ良いか休憩がてら考え中('、3_ヽ)_
全く思いつかんぬ 修復しないとデバッグ表記の一部がバグったりMUGEN閉じた時にエラメが醜いのよね

どうでも良いけどDBOAとも略されてるけど
Aの部分は何の略なんだろうか


CommentList

( 2017.08.05 ) ( MUGEN ) ( COMMENT:6 ) ( TRACKBACK:0 )
%fCALL

やり方解ったし処理落ち比較も確認したし私用テンプレも完成したし
コードステコン差替えていきますかぁ

くそだりぃ_(:3」∠)_
でもまだ1ステコード本格的に使ってるのがSIとMainyuさんだけで良かったかな


CommentList

( 2017.07.29 ) ( MUGEN ) ( COMMENT:4 ) ( TRACKBACK:0 )
真田さんSS 不具合について

記述見直してみたら盛大にミスってますねこりゃ…

次回更新時にはまとめてキャラupするけどそれまで待てないって人は
次の修正を独自に加筆してくだしあ

option.txtにて
「コンボ数減少」で検索してそのすぐ真上にvarsetステコンがあるので
varsetとhitaddステコンの間に
[State ]
type=lifeset
trigger1=fvar(10)
value=sysvar(1)
ignorehitpause=1
を追記

次に「回復?」で検索してそこのvarsetのトリガーが「sysvar(1)< Life」になってる筈なので
そこを「sysvar(1)>=Life」に修正


以上で想定してた強さに直ります(´-ω-`)
真田さんは蓄積するレジストをどうにかやり抜けつつ削りで倒すのが想定してた耐性なのですが
記述ミスで投げと毒でしか死ねない状態になってました
通常の削りダメですら減らないので全く想定外の耐性状態ですなぁ
毒や強制宣告で勝つこと自体はできてたので気づかなかったわ ごめんなさい

クソ脆い筈の撃抗0でもラストが妙に硬い(減らない)のは
受けたダメージが現在Life以上だとmoveH回避する仕様で
トドメ自体は内部処理ダメージではなくステコン命令による死亡だったんだけど
肝心のステコン命令が記号逆でダメージ無効だったので死ねないって事になってました

上記修正では後者の記号の逆転が本命です
前者は記号修正だけだと毒ですぐ死ぬのでその耐性ですね



出場大会は今のところ禍ケシェしか知らんけど
上記修正を行うとキサラギ戦やロバ戦でも勝敗結果変わって既に敗退してるレベルで強さが違うので
選手調整が狂うと思いますがそれでも修正するかどうかは投稿主に任せます
私としては修正しようがしまいが構いませぬ( ˇωˇ )


CommentList

( 2017.07.07 ) ( MUGEN ) ( COMMENT:6 ) ( TRACKBACK:0 )
禍福は糾える縄の如し

禍福は糾える縄の如し by rion on pixiv




あぁ~~禍たん愛おしいんじゃ~~❤❤


CommentList

( 2017.06.23 ) ( MUGEN ) ( COMMENT:3 ) ( TRACKBACK:0 )
varrandom

0~1000ではなく
最小値~最小値+32767の乱数だったわ

おまけに最小値-2147483648だとフリーズする
またひとつエラーを見つけてしまったわ

んで-2147483647で不動となり
最小値-2147483640だと最大-2147483633(差7)
だったことから32767の範囲内だと勝手に纏められる様子

fvarとかには使えないしやっぱり欠陥ステコンだのう

【追記】
フリーズするのは最大、または最小が-2147483648と2147483647のケースでのみみたいだ
それ以外なら-2147483648の固定で普通にMUGEN動いた
何でだろうな_(:3」∠)_


CommentList

( 2017.06.05 ) ( MUGEN ) ( COMMENT:3 ) ( TRACKBACK:0 )
親捏造とか

http://samsara01.blog.fc2.com/blog-entry-20706.html

呼ばれた気がした

あくまで私の主観での話になるけど分類分けするとしたらそうね…

親捏造
親変更の応用 Parentを上手い具合に弄り本来弄れない所をParentVarで弄る
例えば1アドレス分ずらすとparentvar,var(0)の指定なのにvar(1)の所が代入されるとかそんな感じ
親変更の性質上ヘルパー必須なので下準備が面倒くさい上に落ちやすいのもあって
無理して使う必要は無い代物でしょう

主に参照弄り(参照ずらし)がメインでありそのずらすモノがparentなら特に親捏造って認識ですね
ずらせるものはtargetとかrootとかpowerとかあるので参照ずらし全てが親捏造って言われるとそれは違う感じ

%n
DTCでお手軽確実に代入する アドレスさえ知っていればokなのでとても簡単
デバッグキーに関してはアドレス取得すら要らない
とはいえ代入行為のみではやれる事は限られてくるので痒いところに手が届かない
persistent弄りも一応此処に分類
アドレスメモが充実している製作者程強い(ง 'ω' )و
単純な代入ならコードよりも簡潔に済むので今でもよく使う
親捏造と言いつつ実際には%nしか無いってキャラもザラ

コード
アセンブラ記述のものはそれが%nによるものだろうとバイナリ文字によるものだろうとコレ
新たに命令を作り、実行してるようなものなので便利すぎて死ぬ
DEPに弾かれるのが玉に瑕 でもわざわざDEP有効にしないやろ
コード自作できるようになるまでのハードルの高さは随一だがご安心下さい
おバカさんな私でもできた代物です( ˇωˇ )
意欲さえあれば難しくはないよ
%nをある程度触ってないとコレはとっつきにくいかも_(:3」∠)_

アドレス取得
%n捏造のより強い干渉に必要なもの を取りに行く行為
方法は様々だがコードで取得するのがお手軽で確実
無論persistent弄りを含めた%n、コード無しで取得する事も一応可能なのだが
神のレギュレーションがアウト傾向なふいんきなので
撃破挑戦とかする神キャラには搭載されてないか封印されてる

というかいい加減神レギュ明記して欲しいよね 誰か纏めたり意見だしあえ
persistent弄りやオバステF1は普通にもうOKだと思ってます 私はね


CommentList

( 2017.05.13 ) ( MUGEN ) ( COMMENT:7 ) ( TRACKBACK:0 )
よーりょーとがしつ

手持ち禍たんのSFFが100MBを超えてしもうた_(:3」∠)_

アニマを高画質版に変えただけなんですけどね

動画出演としては画質優先だけど
デバッグとかDLとかのお手軽さでは容量の方優先したいよね
そんな理由もあって基本的に容量>画質を心掛けてるんだけど
使う側としては容量ちと重くても画質良い方が嬉しいものなのかしら?


CommentList

( 2017.05.11 ) ( MUGEN ) ( COMMENT:4 ) ( TRACKBACK:0 )