Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Acumenium wrote:
FractalFusion wrote:
Acumenium wrote:
"63 A button presses" (the current theorized minimum without ACE)
I know it's easy to mix up games, but I'm not aware of anything in SMB1 that can be termed "ACE" in any way, even if we tried to stretch the definition of ACE beyond all reason.
Super Mario Bros., like many NES games, likely has an ACE vulnerability in the form of a DPCM attack, like its sequel's sequel, Super Mario Bros. 3.
Well that could be the case if the game actually used that DPCM thing and actually coded in some workaround for the issue it has (the game polls input once per frame, so no it didn't, so it's immune to this sort of attack).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
[3662] A2600 Dragster by MrWint, Omnigamer in 00:08.39
This movie seems to wrongly claim to be console verified: the console verification link appears to verify the obsoleted TAS, not the current one (and the video description even links the obsoleted TAS, also the verification happened before the current TAS was even made so I don't know how the heck someone messed that up lmao).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
FractalFusion wrote:
CasualPokePlayer wrote:
Oh, and this end up being another thing Toto can do and Graveler (probably) can't :P
Not sure what you mean by this. I thought the main reasons for not using Graveler was that Geodude/Graveler is too slow and needs Quick Claw (which the Toto line doesn't need) and the moveset produces too many super effective / not very effective messages.
I mean Self-Destruct abuse on Graveler is not exactly a great combo, and note that Sludge is a physical move and quad-resisted and needs to drop Graveler to 1 HP + poison (well, suppose higher HPs are possible, but each addition HP is 4 more steps which is 64 frames so around a second per HP). Ultimately, it ends up slower to deathwarp with Graveler (although I suppose it's probably not enough where it's slower outright, so it's more "another thing Toto can do great that Graveler can't" /shrug)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
UnopenedClosure wrote:
Against the Koffing at the end of Slowpoke Well (about 21 minutes in), you've manipped it into using and hitting Poison Gas on you. I know that in other generations, the fastest option is usually for the computer to use a weak damaging move against you. Is that not the case here?
The shake from damaging moves + HP bar drain is very slow. So slow in fact, it is avoided wherever possible. Moves missing is generally fastest, along with stat up/down moves getting hit (missing those moves causes a long delay which makes missing them not worth it). For Poison Gas, it's an odd case as it's a status move with no animation attached, so it ends up being the fastest for it to hit.
FractalFusion wrote:
Oh, and before I forget, I noticed that deathwarping from Radio Tower did make it into this version of the TAS. Prior to that, we weren't so sure whether it was faster.
Yeah, it accounts for most of the timesave in this TAS. I knew for sure it was faster in Crystal at the very least (the Electrode Self-Destruct thing works much better there), but Gold is just another beast due to just having that extra Pokemon (doesn't help that it's a shiny). It's ultimately very worth it despite the setup.
Oh, and this end up being another thing Toto can do and Graveler (probably) can't :P
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
"If the Program Counter being manipulated by a limited-address RAM editor touches any RAM currently visible in the limited-address RAM editor and associated pointer calls ("ID 59 for the Game Corner"), it is ACE."
1. What?
2. Are you saying the Program Counter is touching underflowed inventory? I'm not sure if you've realized this, but it does not, and that is a fact that can easily be verifed (and you cannot change that fact no matter how many times you assert it). Again, what happens under the hood cannot be deduced from a video. You can deduce ACE easily with a lua script, although it's very clear you have not.
"but rather executes routines ("Game Corner prize counter") from arbitrary points in memory"
The Game Corner code used here is the same Game Corner code in ROM. That isn't changing here. We're just forcing the game to use Game Corner with an invalid ID (which it gets based off of the sign ID, just like how the game also does it with valid Game Corners), which happens to source prize data in underflowed inventory.
"CPP keeps ducking the issue regarding "payload size" but it's entirely true. This isn't ACE to him because the payload is a small but heavily modified routine in the game (the Game Corner). If he made Pong though, it would be ACE."
If the payload size is "0" then the payload is non-existent. If it is at least "1" it exists.
"some unknown (to this thread, I've seen it linked 0 times, maybe it's elsewhere but that's not on me to find out) .lua script that "detects ACE" as if it's some quantifiable measure."
I said it's trivial to make such a lua script. I never said it yet existed. And yes, it is very easy to quantify. Simply detect any execution of RAM, sans the OAM DMA routine, in which case that should be allocated 3 writes per power cycle (one for bios, one for game's memory clear, and one for the game actually putting OAM DMA code in there).
"Instead, you create two new terms no one has ever heard of and likely never will again, and assure us that this run "is not any of those either", being arbitrary ROM execution (what does this even mean?) and "arbitrary memory corruption""
At most, they are "new" terms to TASVideos, although they've been in the Pokemon Speedrunning community for a long while. Regardless however, the concept of them is quite literally in the rules (and has been since the last publication): http://tasvideos.org/MovieRules.html#FullCompletionCriteriaMustBeReachedThroughInGameActionsOnly
"Arbitrary code execution of ROM data, and memory corruption tricks to write to arbitrary memory are also not allowed."
"no, it does not. If the trainer name doesn't end, like this one, no SRAM is saved."
You realize the game doesn't actually check for the trainer name when it saves, right? It only checks that for loading.
"I also find it highly disingenuous to be comparing these glitches to anything like the Mew/Long-Range Trainer Glitch, which load a battle with a Pokemon based on the Special of the last one fought, and a level (ranging from 1 to 14) based on the Attack stage of the same Pokemon. There's nothing particularly arbitrary, and the glitch itself has very limited scope of function, unlike this, which has a lot of freedom, and just a few more swaps allows full freedom."
Right, and the special of the last thing fought can be arbitrarily controlled, whether just finding the right trainer or just getting a Pokemon with that stat yourself and using a Ditto to get it into enemy memory. And of course some glitch Pokemon/trainers you can encounter could give ACE. So by your own logic, doesn't this mean by using this glitch differently you can gain full freedom? Ultimately, these glitches with the right setup can very often end up with "full freedom" as the result. Perhaps the setup for such is super unreasonable and slow, but possible.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ais523 wrote:
and the Game Corner ID is set to 59, which by luck happens to have prize data in underflowed inventory and price data in SRAM.
Huh, this makes me think that there's another category of "arbitrary X exploit" beyond code execution, ROM execution and memory corruption (and script execution, for the people who count that). What's going on here is incredibly similar to ACE, but using a data pointer rather than a code pointer in order to make the game's routines pull data from an area under user control.
I guess you could call that Arbitrary Function Data Manipulation, although I would say this really isn't something that should be disallowed. For one, it's restricted towards the specific function that data pointer is used in (so that itself would likely heavily restrict it, so not really on the same level of ACE). Second... well you could kinda invalidate every glitched CEA run this way, due to how expansive this can apply to. Let's say Brock Through Walls? This can arguably apply, as that gains control of where the game gets autoinput data from. Let's also say Text Pointer manipulation, that would also arguably count. Heck, let's throw in a wrong warp where you could get the warp values under your control with item underflow and change them to whatever you want. How about we also include trainer escape where you control the next encounter!
I suppose the circumstances are different for each, but they all gain control of the data that these functions use. In the end, it's restricted towards that functions limitations, could be useless, could be useful, also could be ACE/ARE/AMC (which of course those get banned), but it shouldn't be something that inherently invalidates a run.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
"At that point, what makes using ACE to trigger the credits (Super Mario World, Donkey Kong Country, etc.) actually "ACE"? I mean, you're just triggering an in-game function, aren't you? It's not like it's "total" control."
You're executing code you've made in RAM. Therefore, it is ACE.
"I would also like to point out that Pokemon can and often does run code (when using ACE) from SRAM. Is this still "ACE"? Or is SRAM not actually RAM?"
I literally defined RAM some time ago for this argument and SRAM fits the book perfectly fine.
"that seems to be triggered by some use of an item"
Can you not read? The item used is an item that happens to jump to the overworld loop. It's effectively just a faster way to close the menu. That's it. Actually using the Game Corner is as simple as pressing A in the overworld (just like a sign/NPC!). The item can be removed entirely from the TAS and it would still be able to use the Game Corner just fine.
"I'm sorry, but what part of this isn't ACE?"
Well, for one, it doesn't involve code execution in RAM.
But how about I explain this differently. First, to clarify, when I said "Game Corner" earlier, I meant the prize menu that appears. Now, how does the game actually handle the prize menu within the actual Game Corner. Internally, it just creates signs in each booth which have their IDs point to each prize table. They're just as much "signs" as the "signs" created in this TAS. Now, when the sign ID is 59, the game ends up reading unrelated ROM data to figure out where the prize data is located (in fact, arguably), and by chance it points to underflowed inventory. Thus all the prizes end up corresponding there: The first prize corresponding to Repel's item ID, the second corresponding to Repel's quantity, and the third corresponding to "8 8"'s item ID.
At no point in this process does it involve executing some custom code created, thus, there is no ACE involved.
"(if it's not ACE, it's not ACE, the lengthier the "defense" against accusations goes the more flimsy the reasoning behind it not being it, looks)"
I mean, again, a lua script can trivially be made to check for ACE specifically, said lua script will not detect ACE. Still waiting on which frame I could just look at the tracelogger and apparently find ACE you claim exists.
"can't save"
It does save. In fact, all the save routines are executed the same as a typical completion. Now, the game can't actually load the save since it considers the save file as non-existent, but that's a different thing.
"this isn't even creating one"
It did create a save.
Also, to clarify, all "saving the game" is is just the game copying memory from WRAM into SRAM then checksuming the data (then storing the checksum). That's it. Is that done in this movie? Yes? Then the game saved.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ais523 wrote:
(most glitches can't corrupt quite every address, e.g. because you need one to hold the cursor).
I suppose this is true. In practicality, the only glitches that can chose any memory address to corrupt would be corrupt some pointer the game refers to to write someplace. Which there is one noted in the TAS that had to be avoided, so it's not entirely impossible.
Also, on trainer escape, I was more referring to "trainer escape into go fight glitch mon that just suddenly gives ACE" which is possible.
Also, from what I understand, the rule against corrupting memory for progress is just "it doesn't count towards progress" (basing my understanding from the judgement note of the movie this obsoletes). If you set every flag/etc with in game methods, it counts as progress, but otherwise it doesn't count as progress. Note with your reasoning, you can essentially say "you are not allowed to crash the game" (like this movie does) as that can (and does in this movie) corrupt Pokedex flags, but even so it's effectively moot since the player is forced to revert back to the previous save before the corruption.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ais523 wrote:
But the WRAM is a large and important area of memory that stores almost (but not quite) everything that affects gameplay
"important" is subjective. For this game, this could be argued due to nearly everything using it, but not all games are like this. There are several games in fact that just use SRAM as effective WRAM, making it just as important.
In contrast, "arbitrary" can be objectively defined. If any memory visible to the CPU is corruptible with a glitch, then you can "arbitrarily" corrupt memory with that glitch.
These terms are used for the Vault, which is meant to be objective, not subjective.
ais523 wrote:
We don't call a glitch "not arbitrary memory corruption" just because it isn't capable of altering the ROM (which is after all a type of memory).
You can still try to write to ROM, and that could end up being linked up to a memory mapper (so that I/O is corruptible). Although even then that's still just semantics, AMC referring to RAM specifically is implied.
ais523 wrote:
(The glitch could be used to set Pokédex flags directly, for example; the author explicitly refuses to use it to do so, in order to meet a 100% definition, but it would have been powerful enough to do so if necessary, and it's used to do a lot of other things in the game. SDA used to have a rule along the lines that "if a glitch you use is capable of doing X, you can't use it in a no-X category, even if you actually use it to do something other than X", and I think this is a similar case.)
You do realize by taking this to an extreme you effectively ban a ton of glitches (to the point where you probably can't do a true CEA run), right? Let's say the old classic trainer escape glitch. That could be used for ACE. Should that be banned? Or let's take underflowed inventory, that could be used for ACE, should that be banned? Or let's take (nearly every glitch), that could be used for ACE, should that be banned?
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
I just dumped my Gold Glitchless TAS on a dev build yesterday, so it's probably not affecting Gambatte's input scripts? Unless this change was very recent. Although for this game, I'll note I used a different script, instead just hooking onto FF00 writes (which apparently worked best for capturing the inputs lol), and debugging input boundary issues: https://cdn.discordapp.com/attachments/842947491435118622/846109779595100230/timestamps.lua
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
mklip2001 wrote:
Also, do you have a double jump? You seem to use it quite rarely. I think I saw it once in World 2.
There isn't a double jump in this game. The "double jump" you saw was probably just me landing on a hidden platform and jumping again (some of those green bricks in the background sometimes actually have collision).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Dacicus wrote:
Is it faster to take damage rather than avoid it at 3:12 and 4:14?
Oh, those times I just couldn't figure out how to not take damage without just stop holding right for some time. They don't lose time in the end as I make sure to pick up hearts to get back to full health for the boss.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Alyosha wrote:
I'm starting to look at the console desync in Castlevania The Adventure (JPN, GB)
Runs made in GBHawk also desync on console.
Unfortunately, trace logs deviate between Gambatte and GBHawk even before there is any input. The immediate reason is that gambatte returns STAT mode 0 for 4 cycles in between vblank and the start of mode 2 on scanline zero.
This behaviour can be verified to be incorrect (at least on GBP) with the test ly00_mode1_2-C.gb. I tried it on my GBP and it passes there, so this needs to be fixed before I can dig any deeper into it.
I made an issue for this in Gambatte speedrun.
I've done some work looking into this, and was able to hack a "fix" for that test, which ended up failing 41 tests in the testrunner lol. I ended up actually looking into these failures to see if any of them happen to fail on GBP, and found 3 of such: https://cdn.discordapp.com/attachments/842947491435118622/845700752252993577/Screenshot_20210522-093144.png
The regressions here I might be able to get away for this game, but even then, a good fix still needs to come.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Acumenium wrote:
Okay, we should probably cover something again then. What defines "executing RAM"?
The Program Counter ("PC") points to read/writable memory or I/O, which will cause the CPU will execute code from RAM. That is the objective definition for "executing RAM."
"Using the limited RAM editing capabilities of an underflowed inventory/party to create or trigger new functions (Invalid Game Corner with a fully editable reward table) isn't it?"
1. No.
2. This doesn't create a "new function." This triggers an already existing function with the wrong arguments essentially, which has the result you see in the TAS. As a note, you cannot arbitrarily control this invalid Game Corner, you have to use whatever ones that are already per-determined in ROM (which one invalid one happens to source prizes in underflowed bag space and take prize money from SRAM).
"The underflowed inventories are literally a form of RAM editor. Very limited in scope---as I said earlier I think it's somewhere in the 480 range for what both combined can access, and there may be overlap, but the point still stands."
Well what do you think "memory manipulation" is? I don't get how this is a point.
"they're effectively executing arbitrary code"
No, they're not.
"New routines that didn't exist in the RAM"
I'm not sure why you keep saying "routines." Routines are code, and thus are meant to be executed. You are saying this TAS is inserting code into RAM and is executing it. It's not, and that can be objectively proven so, and you have not proven otherwise.
"thanks to it such as the (invalid) Game Corner and its prizes that can be altered based on a RAM address corresponding to the Repels."
Again, this isn't some function created in RAM to go create the Game Corner. It's a sign created, which has its text script point to someplace that has the text script ID which corresponds to the Game Corner, and the Game Corner ID is set to 59, which by luck happens to have prize data in underflowed inventory and price data in SRAM.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Acumenium wrote:
I think, as the delineation mentioned in this thread by the run creator (CPP) was arbitrary and makes it seem as if ACE is only when a program is a certain size or if it hijacks the entire RAM (which I already proved is not how ACE is defined).
I never said that. I literally told you if any RAM is executed, it is ACE (with the minor exception of code intentionally placed by the game into RAM and executed is not ACE, unless said code is at all corrupted by the player and executed, in which case it does become ACE. The only code that can fall under this exception would be the OAM DMA routine the game places into FF80-FF89 of HRAM, which is not modified at all). This run does not violate this, despite your baseless claims that it does.
"it's calculated manipulation to run specific routines---you know, code execution?"
If you're saying that memory is manipulated then that manipulated memory is executed, then you are objectively wrong.
If you are talking about "memory is manipulated then code in ROM doesn't something unintentional" that can really end up just covering a ton of glitches. You can argue the previous run is covered under this too. As a reminder, the save corruption is not required to perform the FTL (Invalid Game Corner) strategy, it is performable without save corruption, save corruption just makes this faster.
"This is most definitely running customized routines (programs), they just aren't very big."
If you are going to keep making this claim, can you at least provide any sort of proof? Looking at the encode is not going to tell you what happens under the hood. Either go download the movie file, tell me which frame I could pull up the tracelogger and find ACE, or stop asserting this.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
"It is up to the Judges to make sure the layperson understand this as they're effectively the ones "marketing" the runs to the laypeople, the public."
No? It's not their responsibility to do PR for every run (if anything that's the publisher's job, although not really in this case). And whether or not this run is ACE or whatever isn't an issue of PR, it's an issue of "does this follow movie rules."
"Looking up the term "arbitrary code execution":
> In computer security, arbitrary code execution (ACE) is an attacker's ability to execute arbitrary commands or code on a target machine or in a target process."
Well, that is correct. But, where are these arbitrary commands/code going to come from? The only place such could be written would be RAM, oh, that ends up being "executing RAM." Which this run does not do. Heck you could make a lua script to go check really, that's not that hard to figure out.
"Put it this way: is using 8F still ACE in Pokemon Red 3DS or no, because it can't access the 3DS firmware?"
Is using 8F still ACE in Pokemon Red Gambatte or no, because it can't access the PC firmware?
"target process" is the key here. The target process being the emulated instance in both cases.
"We can't verify that here as it never saves to anything."
It does save, the game just thinks the save doesn't exist since the name is not terminated correctly. But save is there.
"This is very interesting. So at no point are you swapping around items that correspond to RAM values, then running an otherwise not possible routine, based on the RAM modified?"
The modified RAM is not executed.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Acumenium wrote:
How is this differing from ACE/ARE/AMC?
I did read the submission description. All it does is proudly boast that it does not use ACE/ARE/AMC and gives zero explanation on how this run is somehow different. If someone who actually knows what these terms or glitches are still has questions reading the description, it's profoundly bad for a layperson who doesn't. Your submission text should give a clear explanation on what you are doing and how you are doing it---and you do this with the glitches used, you know, swapping memory addresses around, changing memory values, running custom routines based on what was swapped around...
Jumping to the overworld loop is a fancy way of saying:
- Memory is rearranged to change current room's "overworld loop" to act as the Game Corner
- Memory is rearranged to change what Pokemon are available from the Game Corner, via modifying one memory address that handles the reward
So again, how is this not ACE/ARE/AMC?
If the savefile can't be loaded due to an empty name, shouldn't this be rejected? This is no different than it crashing mid-credits or looping on the HoF which has come up for runs before. Although via totally-not-arbitrary-memory-editing you could just give yourself a name before the Elite Four warp.
Frankly your condescension is really grating. I can see the original submission text right here: http://tasvideos.org/forum/viewtopic.php?p=504335#504335
At no point do you mention the money thing. At no point. You didn't edit it in either: http://tasvideos.org/7054S.html
Additionally, I see no mentions of what ACE is, and how this run isn't ACE, just that it isn't.
Whether or not these runs are "ACE" or not and whether that invalidates the run gets determined by judges, not laypeople. Most "laypeople" would frankly not understand what constitute as ACE, as most just see ACE as either "super glitchy thing" or "create pong or tetris" and not understand what it means at its core (executing RAM w/ caveats).
"- Memory is rearranged to change current room's "overworld loop" to act as the Game Corner"
I quite literally told you the Game Corner is a glitched invisible sign, and this is explained in the submission text. "jump to the overworld loop" quite literally means jump to the code which is after closing the start menu (which is in ROM). That's it. It's just a slight optimization so the start menu doesn't need to be closed, the Game Corner works regardless of this item (which as a note, this item is not used when getting 'M, as your cursor jumps back to the top of the bag so it's faster to just close the start menu like normal). And no that does not count as ACE/ARE/AMC, as this glitch item's pointer is a constant (i.e. the pointer is in ROM) that points towards ROM.
"- Memory is rearranged to change what Pokemon are available from the Game Corner, via modifying one memory address that handles the reward"
That's just like what the previously published run did with LWA (well, changing it so different Pokemon are caught depending on Master Ball quantity, same principle anyways), and that was not considered AMC (because the memory manipulation was limited, thus not arbitrary).
"At no point do you mention the money thing. At no point."
Never said I did, I said the save file's state was explained. The money doesn't matter towards the save file's state so it's irrelevant to explain in the submission.
"This is no different than it crashing mid-credits or looping on the HoF which has come up for runs before."
It is different, the game does do its end game save routine (which the crashing mid-credits and looping on the HoF were critically missing). While the save is fucked anyways, the game does run all the save routines as it normally should at the end, thus this does count as a proper completion.
"running custom routines based on what was swapped around"
This is not done. Custom routines imply player modified RAM is executed, which it isn't. If you want to keep arguing it is, well the tracelogs won't lie in the end.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
FractalFusion wrote:
CasualPokePlayer wrote:
Arbitrary Code Execution: If the PC (Program Counter) touches any RAM currently visible on the system bus, it is ACE.
What about glitches that cause the Program Counter to enter RAM, but the author does not quite have the control to modify that part of memory? (This is mostly hypothetical, since a game that is broken enough to have such a glitch will almost certainly have a glitch that leads to the type of ACE which I was talking about.)
In principle, this is never the case. Supposedly with all known ways to modify that memory you cannot execute some total control thing, but this does not mean some new way can't come along to allow it. You end up saying, "well this is not ACE until new trick comes along then it is ACE". RAM is modifiable, and in principle you can probably modify it to whatever want.
FractalFusion wrote:
I'm pretty sure the existence of these two correlate with the existence of Arbitrary Code Execution.
I'm actually not sure if anyone used these terms seriously before.
They exist because Pokemon Speedrunning community really (i.e. blame lucky), and ARE (which fun fact, is exactly what the "save glitch" TAS does; the "save glitch" TAS technically does not use ACE) and AMC are actively avoided in this submission as the submission text will note.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
FractalFusion wrote:
Acumenium wrote:
ACE itself is achieved via rearranging and redirecting memory addresses in a way that it runs a program based on it... which this is doing.
From my understanding, ACE is a very narrowly defined type of game-breaking state (distinct from other types of game-breaking states), based on what is being done (and not what *can* be done). ACE is a state where any desired sequence of values the author so chooses is promptly written to any desired addresses in RAM, and is immediately executed thereafter (or such equivalent power). Usually "promptly" is understood to be in the order of at least one byte per frame.
Or just:
Arbitrary Code Execution: If the PC (Program Counter) touches any RAM currently visible on the system bus, it is ACE. "RAM" is definable as any memory or I/O (Input/Output, which isn't RAM per se, but in spirit of ACE it can act like such) which is R/W (Read/Write). However, code put into RAM by the game and executed is exempt from this, unless this code is at all modified by the player and executed, which then it becomes ACE.
And if you want to go ask about the other two ACE-level glitches (ARE/AMC), here's definitions for them here too:
Arbitrary ROM Execution: If a glitch can cause the PC touch any byte in ROM currently visible on the system bus, it is ARE. "ROM" is definable as any memory or I/O given by the game medium which is Read Only.
Arbitrary Memory Corruption: If a glitch can corrupt any byte in writable memory or I/O currently visible on the system bus, it is AMC.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
RetroEdit wrote:
Signing up with a team of (in alphabetical order):
- CasualPokePlayer
- InputEvelution
- psx
- RetroEdit (myself)
My other team members will probably make posts confirming this at some point.
Visually perhaps, but how it's technically done is nowhere alike. This movie does not setup any ACE payload (i.e., it does not setup anything that jumps to RAM), rather it just does a ton of memory manipulation (which given the currently published movie, memory manipulation is allowed for 100% categories as long as it is not arbitrary memory manipulation(/corruption)) to just setup an invalid game corner to farm Pokemon.
Is there any particularly difference between arbitrary code execution and rearranging and redirecting memory to do things in a specific way? I feel like "memory manipulation" is just "ACE, but self-limited".
The same glitches are used to start both, so they appear the same.
ACE itself is achieved via rearranging and redirecting memory addresses in a way that it runs a program based on it... which this is doing. You made a payload that when using a certain glitch item, loads a glitchy Game Corner, which reads other parts of RAM (your inventory, specifically, it seems a Repel item count?) to determine what the prize is.
Defining ACE to just be "when you make Tetris or Pong" seems arbitrary in itself, and thankfully it appears I am not wrong with this specific part from what I've seen some Judges like Mothrayas say in other threads. I don't see at all how this run isn't ACE.
I do have one other question, is this save file okay? I know you can eventually fix the "255 Pokemon" and even buggy boxes, but the money seems blanked out. Is it a very high but playable number? Or is it 0? Or is it not actually usable anymore?
"Limited" is the exact point on why limited memory manipulation is allowed. The reason ACE (along with ARE/AMC) is banned is due to the fact you can in principle do anything with it, rendering any sort of restriction like "100%" moot. If it's limited, by principle you cannot just do anything with it, thus this mootness does not apply.
Also, can you please actually read the submission text? All this "glitch item" does is jump to the overworld loop. That's it. It's just an optimization so the start menu doesn't have to be closed to interact with the Game Corner (which is a glitched invisible sign that is set up to act like a Game Corner).
"Defining ACE to just be "when you make Tetris or Pong" seems arbitrary in itself, and thankfully it appears I am not wrong with this specific part from what I've seen some Judges like Mothrayas say in other threads. I don't see at all how this run isn't ACE."
Well that is not how I would define ACE at all, here is my own definition:
Arbitrary Code Execution: If the PC (Program Counter) touches any RAM currently visible on the system bus, it is ACE. "RAM" is definable as any memory or I/O (Input/Output, which isn't RAM per se, but in spirit of ACE it can act like such) which is R/W (Read/Write). However, code put into RAM by the game and executed is exempt from this, unless this code is at all modified by the player and executed, which then it becomes ACE.
This is not done, and therefore there is no ACE involved with this run. Again, the entire setup is explained in the submission text, which you did not bother to read apparently.
Also the save file state is explained in the submission text. The money is probably some high number (I don't know, I don't care, it doesn't affect loading the save file anyways). Also, the submission text explains the Game Corner ends up overwriting the party count (we don't have "255" Pokemon anymore) and name (as explained in the submission text, this means the save file can't be loaded since the game uses a valid name as a "check if save file exists". If it was a valid name anyways, it would load the save file just fine with the completed dex, so probably doesn't mean anything for validity of the run.)
