• パセリ主催なろう企画

    2020-01-10 00:51
  • 広告
  • Ocarina of Time - Kokiri Forest Credits Warp 動画詳細文和訳

    2020-01-05 13:252

    時オカのプログラムやTAS、RTAについて、何も知識がない人が
     https://www.youtube.com/watch?v=YlADOm4G6pM
    の動画詳細文の文章を暇つぶしに訳しました。
    任意コード実行により、EDに直接ワープする動画になっています。
    誤訳があるかもしれませんが、雰囲気を楽しんでいただければ幸いです。
    (いずれ、きっともっと知識ある人が訳してくれるでしょう…)

    ・なるべく自然な日本語にするために、かなり意訳。原文から言葉をつけ足したり端折ったりしてます。重大な間違いがあったら、コメントで指摘してくれれば幸いです。(修正します)

    ・SRMって?
    →なんか、リンクが手に無を取得するやつ、らしい。

    ・actorって?
    →たぶん、リンクが手に持つ物のことをactorって呼んでいます。

    ・たぶん、1回でロードされる場所一つ一つのことをroomって呼んでいます。とりあえず、そのままroomとしました。(単に、場所と訳してもよかったかも)

    ・crawlspaceって?
    →たぶん、足場の下の空間のことだと思うんですが、よく分かんないのでcrawlspaceのままにしています。

    ・culledは、なんか透明な何かを持ってる状態のことです。単に、非表示状態と訳しましたが、既に違う訳があれば、教えていただければ幸いです。

    ・buildsは、単にプログラムって訳しました。コンパイルやリンクやビルドの違いが分からん人にとっては、この訳が分かりやすいと思います。訳した通り、N64版、iQue版、GC版では、プログラム自体が異なっており、バーチャルコンソールではN64版のプログラムをエミュレートしているらしいです。

    ・nativelyって?
    →エミュとか使わずに、ふつーにプログラムを実行すること、だと思います。訳した通り、N64版とiQue版ではnativelyにプログラムを実行しているみたいです。一方、GC版とバーチャルコンソール版では、エミュでプログラムを実行しているみたいです。(なお、上述の通り、GC版とバーチャルコンソール版では、エミュレートするプログラム自体は異なるみたいです。)

    ・オペコードって?
    →Wikipedia参照(https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%9A%E3%82%B3%E3%83%BC%E3%83%89)。プログラムがどんな命令を実行するのかを指定するコードのこと、らしい。

    ・functionは、プログラムに関連する用語として使われているっぽいので、たぶん、機能ではなく関数と訳すべきだと思いました。

    ・ヒープメモリって?
    →プログラム中で一時的に使用するメモリの種類の一つ、らしい。詳細は、ヒープメモリやヒープ領域でググってください。

    ・0x●●って?
    →●●は、十六進数での数字ですよ、ということを表しています。0x01~0x09は十進数では1~9で、0x0Aは十進数では10です。0x0Bは十進数では11、…、0x0Fは十進数では15、0x10は十進数では16となります。

    ・「one-time」な青ルピーって?
    →よく意味が分かりませんでした。

    ・Chinese cheat boxって?
    →この記事の1コメが情報をくれました。iQueのことを指すそうです。iQue版の時オカは、中国語を使っていることとラグが少ないことから、N64, GC, Wii/Wii U VC版の走者より優位に立つことができ、そのため、iQue自体がChinese cheat boxと呼ばれているらしいです。(希少価値が高いことも理由の一つかもね、とのことです)

    ・WWTって?
    →Walking While Talkingの略で、話しかけながら歩くグリッチのことらしい。

    ・jumping to the seed's rotationの文章の訳は?
    →分からんやったちん!w

    ・他にも質問があるんですが?
    →たぶん答えられません。特に内容面に関しては。時オカのプログラムやTAS、RTAについて、何も知識がない人が暇つぶしに訳しただけなので。


    以下、訳
    ―――
    In this video, I use stale reference manipulation and arbitrary code execution to wrong warp into the credits from the very beginning of the game, in Kokiri Forest. This cuts the amount of time needed to beat Ocarina of Time any% lower than it has ever been before.
    この動画では、ゲームの最序盤、すなわちコキリの森でEDへのwrong warpをするために、stale reference manipulation(SRM)と任意コード実行(ACE)を使用しています。コキリの森でのEDへのwrong warpにより、時のオカリナをany%でクリアするのに必要な時間がこれまで以上にカットされました。


    The reason this is possible is because of "Camera Lock SRM", a new kind of SRM which was originally discovered by Hylian Freddy of the Ocarina of Time 3D community, and researched further by Blini and Fig.
    コキリの森でのEDへのwrong warpは、「カメラロックSRM」―新しい種類のSRM―によって可能となりました。これは、時のオカリナ3DコミュニティのHylian Freddyに発見され、BliniとFigによってさらに研究が重ねられたものです。


    In general, to achieve SRM, we want to move Link one room to another while holding or picking up an actor, so that the actor unloads but Link is still pointing at the part of memory where the actor used to be loaded. The reason that we can't simply pick up a rock and walk over to the Great Deku Tree's room to achieve SRM, is that whenever a holdable actor's main update function runs, it will check whether it's being held or not. If it is being held, the actor sets its own associated room to -1, a value which means that the actor should not unload no matter what room Link is in.
    一般的に、SRMを行うには、actorを持ちながら、もしくは持ち上げながら、リンクがroomからroomへと移動する必要があります。そうすれば、actorは置かれずに、actorが置かれるはずだった場所のメモリを、まだリンクが指し示すことになります。単純に岩を持ち上げて、デクの樹サマの中へ行くことではSRMができない理由は、持つことが可能なactorのメインアップデート関数が働いているときは、actorを持っているか持っていないかを常にチェックしているからです。もし持っているなら、それに関連するroomが-1にセットされます。-1の意味は、リンクがroomにいようがいまいがそのactorをロードすべきだという意味です。


    Separately, whenever an actor is far from the camera view, it becomes "culled", meaning its draw and update functions do not run. If we can pick up a rock and immediately cull it, and keep it culled the entire time as we walk over into a differerent room, it will never set its room to -1, and will unload, thereby achieving SRM. Using the Walking While Talking glitch to lock the camera near the crawlspace far from Link, we can achieve exactly that.
    actorがカメラ画面から遠く離れると、そのactorは「非表示」状態になります。つまり、そのactorの表示関数と、アップデート関数が実行されなくなります。もし、岩を持ち上げ、それをすぐに非表示状態にし、異なるroomへ歩く間その状態を保てば、移動先のroomは-1にはならず、ロードされません。それにより、SRMを行うことができます。会話中に歩くというグリッチ(WWT)を行い、リンクから遠いcrawlspaceの近くにカメラを固定すれば、SRMを行うことができます。


    Once SRM is achieved, our goal is to leverage that into ACE, and use that to immediately warp into the credits and beat the game. It's worth taking a moment here for a moment to discuss why we're playing on the Chinese iQue version of OoT, the strangest and most obscure release of the game. Essentially, Ocarina of Time has been released on four platforms:
    - Nintendo 64: The original builds of the game, running natively.
    - iQue: A console unique to the Chinese market, which shares some hardware with the N64 but also has unique characteristic. The builds for this version were created a few years later, but still run natively.
    - GameCube: Yet another set of builds of the game, that are only possible to run via a Nintendo-made emulator. This emulator dynamically transforms all N64 code it runs into GC code via Just-In-Time compilation (JIT).
    - Virtual Console: Available on Wii and Wii U, this likewise emulates the game via JIT. However it emulates the original N64 builds of the game.
    SRMが成功すれば、それをACEへと繋げ、ACEを用いることでEDへ即座にワープしてゲームをクリアすることが最終目標です。ここで、なぜ我々が中国語iQue版―最も奇妙かつよく分からないバージョン―の時オカでプレイしているのかについて議論しておきましょう。本質的には、時のオカリナは4つのプラットフォームでリリースされました:
    - Nintendo 64:オリジナルのプログラムであり、N64上でnativelyに実行されます
    - iQue:中国市場に特有のゲーム機で、ハードウェアの一部はN64と同じですが、iQue特有の特徴も持ちます。iQue用のプログラムはN64用の数年後に作られましたが、これもiQue上でnativelyに実行されます。
    - GameCube:さらにもう一つの別のプログラムであり、任天堂製のエミュレータを通じてのみ実行することが可能です。このエミュレータは、Just-In-Time(JIT)コンパイルにより、N64用のコードをGC用のコードへとリアルタイムに変換します。
    - バーチャルコンソール:WiiとWii Uで使用可能で、これもGCと同様に、JITによりゲームをエミュレートします。ただし、N64版のプログラムをエミュレートします。


    Achieving arbitrary code execution on GC and VC is all but impossible. The reason for this is how the JIT works: rather than only look at the current N64 instruction being executed, it will "look ahead" and try to detect an entire valid function, and compile the whole function at once. If it sees any invalid opcodes before it reaches a return instruction, the game will just crash (thanks KrimtonZ for researching this). Setting up an entire valid function in manipulable memory on the heap is not likely to ever be possible.
    GCとVCにおいて任意コード実行を行うことは不可能も同然です。この理由は、JITの動き方に関係します:現在実行されているN64の命令だけを見るだけではなく、実行されるであろう命令を「前もって見る」ことで、有効となるであろう関数を検出しようとし、その関数全体を一度にコンパイルします。もし、return命令にたどり着く前に有効ではないオペコードを確認すれば、ゲームはクラッシュすることになります(これを研究してくれたKrimtonZに感謝いたします)。ヒープ上の操作可能なメモリにおいて、有効な関数全体をセットアップすることは、不可能でしょう。


    The N64 and iQue, on the other hand, look at one opcode at a time and do not have this issue. The difference has to with heap memory allocation. The N64 builds of the game, being the oldest ones made, include certain debug information in the header of each block of memory that gets allocated on the heap, making each block have a header of size 0x30. The iQue and GC builds removed this debug info so that the header size is only 0x10. Because of this, the arrangement of blocks in the heap will follow different patterns on N64 versus iQue/GC, and a heap manip that works with 0x30 headers will not work with 0x10, and vice versa.
    一方、N64とiQueでは、一回につき一つのオペコードを参照するため、このような問題がありません。この違いは、ヒープメモリの割り当て方に関係しています。4つの中で最初に作られたN64版では、ヒープに割り当てられたメモリのそれぞれのブロックのヘッダの中に、ある種のデバッグ情報を含んでいます。これにより、それぞれのブロックのヘッダサイズは0x30となっています。iQueとGC版はこのデバッグ情報がなくなっており、そのためヘッダサイズは0x10しかありません。このため、ヒープ中のブロックの配置は、N64版とiQue/GC版では異なるパターンとなり、0x30ヘッダでは機能するヒープ操作は、0x10では機能しません。逆も同様です。


    At least theoretically, finding heap manips that lead to ACE is equally possible regardless of 0x30 or 0x10. But right now, despite a fair bit of heap manip research by me, Blini, and Tharo, we currently have several viable manips for 0x10 and none for 0x30. So for the time being, the iQue - being the only version of the game with 0x10 headers and no JIT - is the fastest possible way to beat the game. Long live the Chinese cheat box.
    少なくとも理論的には、0x30か0x10かにかかわらず、ACEに繋がるヒープ操作を見つけることは可能です。しかし、今現在では、私やBlini、Tharoがヒープ操作の研究を結構行ったにもかかわらず、0x10では実行可能なヒープ操作が見つかりましたが、0x30では見つかっていません。そのため、現在のところ、iQue―0x10サイズのヘッダを持ちJITがない唯一のバージョン―がゲームをクリアする最も速いものとなっています。Chinese cheat box万歳。


    Breakdown of the video:
    3:35-11:35 The setup section. There are four mandatory prerequisites before we can get into the SRM itself. We need nuts to be able to trigger WWT; Ocarina, which lets us manipulate camera while WWT is active; and slingshot, because it lets us fire a seed at a semi-arbitrary angle that lets us write a custom opcode onto the heap. We also need to move Mido out of the way, which requires sword/shield/rupees. Finally, it's worth mentioning I don't get any of the "one-time" blue rupees in the main room of Kokiri Forest, as that could potentially affect the heap manip later.
    動画の内訳:
    3:35-11:35 セットアップ。SRMを行うために、四つの準備が必須です。WWTを引き起こせるようになるために、デクの実が必要です。オカリナは、WWTがactiveのときにカメラを操作するために必要です。パチンコは、semi-arbitraryの角度にデクの種を飛ばすことで、ヒープにcustomなオペコードを書き込むために必要です。またミドをどけることが必要で、そのため剣、盾、ルピーが必要となります。最後に、後々のヒープ操作に影響を与える可能性があるため、コキリの森のメインのroomでは、「one-time」の青ルピーは取得していないことに言及しておきます。


    (description too long, check pastebin for the full thing: https://pastebin.com/tc6x2Uhi)
    (あまりにも長いため、内訳を全部知りたい方は、pastebinをチェックしてください:https://pastebin.com/tc6x2Uhi)

    ―――
    以下、pastebinに書かれてある、続きの訳
    (一番重要な箇所だけど、致命的な誤訳ありそうで怖い)
    ―――

    11:40-12:05 With the specific choice of ACE and that I'm going to be using, it's necessary to save and quit so that the last viewed cutscene will be the title screen to prevent a crash later. We also need to load Kokiri Forest from the Deku Tree room so the heap manip and ACE will work. These are not hard requirements, though.
    11:40-12:05 この後使用する任意コードを選択するために、セーブ&リセットが必要です。そうすることで、最後に見たcutsceneがタイトル画面となり、この後クラッシュするのを避けることができます。ヒープ操作とACEが機能するために、デクの樹サマのroomからコキリの森をロードする必要もあります。これらは、絶対に必須の条件というわけではありませんが。


    11:32 For the heap manip, collect the rupee and break the specific rock that I do here.
    11:32 ヒープ操作のため、ルピーを集め、動画で行っている通り、特定の岩を壊しています。


    12:52-13:25 Trigger WWT. With the help of ocarina camera adjustments, load the rock circle and break the three rocks that I do.
    12:52-13:25 WWTへと繋がる部分です。オカリナを構えることによるカメラ調整を利用して、円状に並んだ岩をロードし、動画の通り3つの岩を壊しています。


    13:25 This part is trickier than it looks. Walk to where the westmost circle rock should be. Use the ocarina to bring the camera close, as culled actors can't be picked up. Exit the ocarina. When the camera zooms out again, it needs to go in the direction it does for me, otherwise things won't work. During the zoom, you need to press A to trigger the grab BEFORE the camera is far enough for the rock to cull, but Link needs to actually execute the grab AFTER the rock culls. Also, to even get into position to be able to grab the rock at all, you may need to have Link be moving while the camera zooms out.
    13:25 このパートは、見かけよりも難しい部分となっています。まず、岩が円状に並んでいるところで、最も西のところに歩きます。非表示のactorは持ち上げられないため、次に、オカリナを構えることでカメラをリンクの近くに持ってきます。そして、オカリナを構えるのをやめます。カメラが再びズームアウトしたとき、特定の方向へ向かう必要があります。さもなければ、EDへのワープはできなくなるでしょう。ズーム中、カメラが遠のいて岩が非表示になる前に、つかむ動作を行うためにAボタンを押す必要があります。しかし、リンクは、岩が非表示になった後につかむ動作を実行する必要があります。また、岩をつかむことができる場所へ移動するために、カメラがズームアウトしている最中にリンクを移動させる必要があるかもしれないです。

    13:30-13:57 With the culled rock in hand, navigate semi-blindly all the way to the Deku Tree's room. Do not at any point come close enough to the camera for the rock to become visible, and don't fall in the water either.
    13:30-13:57 非表示状態の岩を手に持ち、リンクがほとんど見えない状態でデクの樹サマのroomへと移動します。このパートでは、岩が表示されないようにカメラが岩に近づかないようにし、水の中に落ちないようにします。

    13:59 We have now achieved SRM, and Link is now pointing at unallocated memory. With the heap manip we used, we're pointing at what WOULD be the draw function pointer of the green rupee we collected earlier, but since we collected it, we're pointing at free memory instead. If we go back and approach the circle of rocks, a rock will load in the same location, and we'll be modifying its draw function pointer. At this point we have to be extremely careful: if we ever actually turn the camera close enough for the rock to become visible, the draw function will run and the game will crash! So we need to keep it well off camera. But at the same time, if we go far enough that the rock unloads entirely, our SRM will be useless. So our movement and camera is highly limited here.
    13:59 このとき、SRMが実行され、リンクは割り当てられていないメモリを指しています。実行したヒープ操作により、先に集めた緑ルピーを表示する関数のポインタが指し示されているはずです。しかし、我々はそれらを集めたため、代わりに自由メモリを指しています。もし、岩が円状になっているところに戻ってくれば、同じ場所に岩がロードされ、その表示ポインタを修正するでしょう。このとき、非常に気を遣う必要があります:もし、岩が表示されるほどカメラを近づけていれば、岩を表示する関数が働きだし、ゲームはクラッシュするでしょう!そのため、カメラは十分離れたところにキープしておく必要があります。しかし、それと同時に、もし岩が全くロードされないほど離れたところに移動してしまうと、SRMは無駄になってしまいます。そのため、リンクが移動する範囲とカメラが移動する範囲は非常に限られたものになっています。


    14:20 Link needs to have an exact angle to set the draw pointer to the value we actually want it to be. This step, and this step alone, probably makes this whole method not really possible for a human at this time - the game still technically thinks we're in Walking While Talking mode, and as a consequence, disables our Z button. Getting an exact angle without using Z is not really something a human player can do at this time, let along while still having to be very careful with the camera to prevent crashes. In any case, the specific value we set the draw pointer to points at another spot of free memory, one that we're just about to shoot a seed into.
    14:20 drawポインタが欲しい値にセットされるような正確な方向にリンクが向いている必要があります。このステップがあるために、現在のところ人間にはコキリの森からEDへのWrong warpが事実上不可能となっています―ゲームは未だ機械的に、我々がWWTモードになっていると思っています。そしてその結果、Zボタンが使えなくなっています。Zボタンを用いずに正確な方向を向くことは、現在のところ人間ができることではありません。ゲームのクラッシュを防ぐために、カメラ操作には常に気をつけておきましょう。とにかく、表示ポインタにセットした値は自由メモリとは別の場所、パチンコを打とうとしている場所を指し示しています。


    14:26-14:41 Set Link's angle to somewhere between 21DE8800-21DE880F like I do, and press C to start readying a seed. Then press B almost immediately to cancel the seed on the first frame of its existence (the timing on this is easier than it sounds). This will form the seed's angle into a jump instruction that points to a block of memory that contains the value of controller 1 and controller 3 inputs. (Yes, iQue supports multiple controllers, although the required multitap is not cheap.) Now that we've done that, the moment we make the rock visible, its draw function will run start running every frame - jumping to the seed's rotation, which jumps to our controllers. This is extremely powerful - we can now run as much arbitrary code that we like, by changing our controller inputs as we like!
    14:26-14:41 動画で行っているとおり、リンクの角度を21DE8800-21DE880Fの間のどこかにセットし、Cボタンを押してパチンコを打ち始める構えに入ります。そしてほとんど同時にBボタンを押すことで、パチンコを打つ構えに入った最初のフレーム(このタイミングは、思ったより簡単です)で、パチンコの構えをやめます。これにより、パチンコを構えているときに向いていた向きが、コントローラ1とコントローラ3の値を記憶しているメモリを指し示すジャンプ命令へと変化します。(iQueでは複数のコントローラの使用が可能です、それに必要なマルチタップは安くはないですが。)これを成し遂げたので、岩が表示される状態にし、その瞬間、岩を表示する関数が動き始めます―jumping to the seed's rotation、これは、コントローラにジャンプすることになります。これは本当にパワフルなことです―我々は、コントローラの入力を変えることで実行したい任意のコードを実行できるようになったのです。


    14:42-15:07 Set up controller 3 to simply contain a jump to a return instruction. Make the rock visible, while making sure that controller 1 doesn't input an instruction that will crash! Then set up controller 1 to input the instruction "addiu $gp, $r0, 0xFFF6" - which is MIPS for "load 0xFFF6 to the GP register". The GP register is absolutely unique in that Ocarina of Time never uses it at all! This means that unlike other registers, if we load a value into it, that value will remain there forever, and we can keep using it in later frames! So now we just need to GP to the "current cutscene" location of memory, which we can do on iQue by giving controller inputs that form the instruction "sh $gp, 0x7F4A($at)". The instant we do that, the cutscene triggers.
    14:42-15:07 コントローラ3は、単にreturn命令へのジャンプを含むようにセットアップします。そして、岩が表示されるようにします。その際、コントローラ1ではクラッシュするような命令を入力しないようにしましょう!そして、コントローラ1で次の命令を入力します「addiu $gp, $r0, 0xFFF6」―これは「0xFFF6をGPレジスタにロードせよ」というMIPSになっています。GPレジスタは時のオカリナが唯一全く使用しないレジスタです!これは、他のレジスタとは異なり、もしある値をそこへ入力すれば、その値はそこへ永遠にとどまり続け、後のフレームにおいても使い続けることができるのです!そのため、我々は単に、GPレジスタを「現在のcutscene」の位置のメモリにすればよいのです。iQueでは、これはコントローラで命令「sh $gp, 0x7F4A($at)」を作るような入力を行うことで可能です。これを行った瞬間、cutsceneが始まります。


    15:08 The game is now trying to run cutscene FFF6 for Kokiri Forest. But when we set the cutscene value in this way, it doesn't actually load the cutscene - instead it executes leftover data from the last cutscene in memory, which is the title screen. This causes Link to get warped far out of bounds and void out. But that's actually exactly what we want, because voiding out reloads the scene and the proper data for cutscene FFF6, thereby giving us...
    15:08 ゲームは、コキリの森に対応するcutscene FFF6を再生しようとします。しかし、このようにしてcutsceneの値をセットしたとき、ゲームはcutsceneをロードしません。―その代わりに、 メモリに残された最後のcutsceneのデータ(タイトル画面)を実行します。これにより、リンクは境界のずっと外へとワープし、奈落の底へと落ちていきます。しかし、それこそが我々が行いたかったことなのです。なぜなら、奈落の底へ落ちることで、場面がリロードされます。今の場合、cutscene FFF6に対応するデータをリロードします。これにより起こるのが…


    15:18 KOKIRI FOREST CREDITS WARP.
    15:18 コキリの森EDワープ


  • バン枠・。・表

    2019-10-13 08:175

    ことの発端は、lv322350718 の368コメ「・。・表がほしい」

    ということで、作りました。バン枠・。・表

    ただし、ニコニコのブロマガでは、
    絵文字をいれるとその先が消される仕様なので、
    Google Driveに・。・表を置きました↓
    https://docs.google.com/document/d/e/2PACX-1vRsKnHQiDafnjC-HPd8Adq-t0P9rjedsUyMqgJQplwRTXdmlx3h0Al7meH7zPOBN6UC3zDZzbDcybSk/pub

    この記事は、・。・表の間違い等の指摘を受け付けるためのものです。

    □偉大なるバンのコミュニティ
    メイン:co3219615
    サブ:co3856130