I know this is unrelated to the current conversation, but...
Since SMW is playable on Super Smash Brothers Brawl, is it possible to use ACE there to control brawl?
I know this is unrelated to the current conversation, but...
Since SMW is playable on Super Smash Brothers Brawl, is it possible to use ACE there to control brawl?
Only if there's a bug in the emulation.
After all, there's no risk of an ACE TAS unleashing a virus on your Windows or Linux machine just because it can rewrite the game the emulator is emulating.
Wow, that amount of ignorance pisses me off!
I explained quite well that the 1-level-skip glitch in MM1 doesn't corrupt memory and a few posts later it's again called memory corruption with no proof.
Dyshonest, you're a troll. End of story.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Wow, that amount of ignorance pisses me off!
I explained quite well that the 1-level-skip glitch in MM1 doesn't corrupt memory and a few posts later it's again called memory corruption with no proof.
Dyshonest, you're a troll. End of story.
Okay, do tell me again, as I'm hard at reading Engrish, how is it NOT memory corruption again? The memory is, very clearly, not working properly if it's calling for the end of level, and no longer showing graphics properly.
SMW was in Brawl? O_o How do you play it there?
You press B to jump, A to spinjump, Y and X to run, left and right to move, down to duck and slide, up to look up and enter doors. R and L shoulder buttons to scroll the screen. Start to pause and Select to spawn an item (such as an orb or a cloud) from your itembox.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
Dyshonest wrote:
How do you access it, I mean? I don't recall SMW being contained in Brawl. How was it unlocked?
Brawl has a demo mode ("Masterpieces"), which includes trials of classic games from some of its core franchises, such as Super Mario Bros., Kirby's Adventure, etc. Super Mario World can also be unlocked and played there. To unlock it, play on the Yoshi's Island stage over three times.
Dyshonest wrote:
feos wrote:
Wow, that amount of ignorance pisses me off!
I explained quite well that the 1-level-skip glitch in MM1 doesn't corrupt memory and a few posts later it's again called memory corruption with no proof.
Dyshonest, you're a troll. End of story.
Okay, do tell me again, as I'm hard at reading Engrish, how is it NOT memory corruption again? The memory is, very clearly, not working properly if it's calling for the end of level, and no longer showing graphics properly.
What part of this quote is hard to read/Engrish?
feos wrote:
The 12-minute run makes NMI occur during the normal bank-switching routine, not letting the game execution return to the proper bank, and forcing it execute the wrong bank's functions. That "wrong" function is counting up the score, like the level has ended. And then it actually ends. Everything is already in the game, and what happens isn't even memory corruption, it's just a simple bug being abused.
The glitch does not corrupt memory. It just causes a function call from the wrong area. That is not memory corruption. The graphics messing up is just a side effect, and has no bearing on the game's internal functionality. (The only difference it makes, aside from visual appearance, is that the graphics rendering causes a bit of extra lag in some places).
It seems you like to apply terms to movies that aren't accurate. First Mega Man was ACE, then it's memory corruption, and in fact it's neither - and this is just one example. It's hard to be convinced by your arguments when you keep using terms contradictory to ours, giving your own definitions for runs that use memory corruption or arbitrary code execution, and arguing about these terms to people who know the technical background behind these runs while you do not. And even when it's explained to you, you ignore it and keep arguing.
By this point I doubt anyone who was involved in this discussion is still taking you seriously anymore.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
The 12-minute run makes NMI occur during the normal bank-switching routine, not letting the game execution return to the proper bank, and forcing it execute the wrong bank's functions. That "wrong" function is counting up the score, like the level has ended. And then it actually ends. Everything is already in the game, and what happens isn't even memory corruption, it's just a simple bug being abused.
So nothing memory-related at all is being corrupted to trigger such abnormalities in the game's memory?
ACE is triggered by memory corruption. Unless the game, for whatever reason, specifically allows you to execute arbitrary code, it has to be triggered via things like memory corruption (buffer overflow, etc).
So yes. I will continue to use the terms interchangeably because it doesn't really matter which you pick. When memory corruption is controllable/severe enough, it turns to ACE.
Using the above logic, I guess the ACE isn't really ACE either. After all, it's triggered the exact same way. It's just calling for a "hidden" game function.
[05:54:23 PM] <legendarymudkip> ACE = programming something into the game that wasn't in the original code, ACE is NOT executing code in the game when it should'nt have been. Otherwise every glitch would be ACE.
Will this do for you, Dyshonest? ~_~
Dyshonest, by your definition of ACE, any single glitch is arbitrary code execution and memory corruption. For example, take the walljump in SMB. In order for it to happen, the Y speed has to be 0. But hang on, aren't you in the air? Is that not the memory not being what it's supposed to be? MEMORY CORRUPTION. The jump code is executed in the air, ARBITRARY CODE EXECUTION.
By your definition of ACE and memory corruption, every glitch is ACE and MC.
Current TAS:
[SNES] Jelly Boy
[NES] Street Fighter 2010
[05:54:23 PM] <legendarymudkip> ACE = programming something into the game that wasn't in the original code, ACE is NOT executing code in the game when it should'nt have been. Otherwise every glitch would be ACE.
Will this do for you, Dyshonest? ~_~
And how do you start to write code and execute it without involving serious memory-related problems like corruption? The game isn't a compiler.
The processor executes commands from the ROM. ACE is not when you make the ROM send something from it when it wouldn't normally at that point. ACE is when you make the processor execute your OWN commands that you wrote yourself.
Current TAS:
[SNES] Jelly Boy
[NES] Street Fighter 2010
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
Dyshonest wrote:
So nothing memory-related at all is being corrupted to trigger such abnormalities in the game's memory?
Nope. The only thing that's different from usual is that the function is called when the bank hasn't finished switching yet. It calls the same function pointer it usually would, it's just not what it expected it to be.
Dyshonest wrote:
ACE is triggered by memory corruption. Unless the game, for whatever reason, specifically allows you to execute arbitrary code, it has to be triggered via things like memory corruption (buffer overflow, etc).
This is not necessarily true. Suppose a glitch similar to this was used to call some place in RAM, it's possible to get arbitrary execution even though the method doesn't involve memory corruption. Avoiding memory corruption like this wouldn't be a very practical method though.
In the case of the 12 minute Mega Man run, the game calls a function from ROM, which is normally intended to be called at some point. That's not arbitrary code execution.
Dyshonest wrote:
So yes. I will continue to use the terms interchangeably because it doesn't really matter which you pick. When memory corruption is controllable/severe enough, it turns to ACE.
This line just confirms to me you're not to be taken seriously. You say you use the terms interchangeably, and in the next sentence you point out the relation between two terms, which means they're not identical and hence can't be used interchangeably.
Also, not all memory corruption is "controllable enough". Unless you can manage to reach input RAM or other easily modifiable memory, memory corruptions won't get you anywhere.
Dyshonest wrote:
Using the above logic, I guess the ACE isn't really ACE either. After all, it's triggered the exact same way. It's just calling for a "hidden" game function.
It's not calling a "hidden" game function, it's calling a function that's generated on the fly by the TAS. That's why it's called arbitrary code execution.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
In the case of the 12 minute Mega Man run, the game calls a function from ROM, which is normally intended to be called at some point. That's not arbitrary code execution.
...and having it call the ending is suddenly different?
Also, not all memory corruption is "controllable enough". Unless you can manage to reach input RAM or other easily modifiable memory, memory corruptions won't get you anywhere.
Controller input isn't necessary for ACE either.
See: SoTN, Pokemon, etc.
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
Dyshonest wrote:
In the case of the 12 minute Mega Man run, the game calls a function from ROM, which is normally intended to be called at some point. That's not arbitrary code execution.
...and having it call the ending is suddenly different?
Yes, because the run that calls the ending has to construct its own code to do that. The method used in the 12 minute run could call some specific functions, like "end this stage" in some stages, or "spawn water stream object" in Ice Man's stage, but not "go to ending".
In order to do that, the 30 second run goes through quite a few more hoops: using the delay glitch to spawn a glitch object, which calls to some object RAM, which is specifically laid out in the run to form code to jump to controller input, and from there on it calls the ending. That is ACE, because it uses data such as object positions to set up as bytecode.
Dyshonest wrote:
Also, not all memory corruption is "controllable enough". Unless you can manage to reach input RAM or other easily modifiable memory, memory corruptions won't get you anywhere.
Controller input isn't necessary for ACE either.
See: SoTN, Pokemon, etc.
I wrote:
input RAM or other easily modifiable memory
By "other easily modifiable memory", I meant things like the inventory for SotN and Pokémon Yellow, certain Pokémon stats in Pokémon Gold, or object X/Y positioning in Mega Man and the old Super Mario World run. All of these TASes work by setting up a block of memory in such a way that it forms a set of assembly instructions that do what the author wants (and then calling it).
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
let me act like you for a little bit
lalalaalalala can't hear you not listening lalalalalalala going to have my own flawed views and aint nobody gonna change 'em lalalaalalalalala hyperbole lalalalalalala
Yes, because the run that calls the ending has to construct its own code to do that. The method used in the 12 minute run could call some specific functions, like "end this stage" in some stages, or "spawn water stream object" in Ice Man's stage, but not "go to ending".
In order to do that, the 30 second run goes through quite a few more hoops: using the delay glitch to spawn a glitch object, which calls to some object RAM, which is specifically laid out in the run to form code to jump to controller input, and from there on it calls the ending. That is ACE, because it uses data such as object positions to set up as bytecode.
What prevents it from calling for the end of the game, exactly?
If that very glitch is what's capable of spawning the ACE-enabling glitch object (which is never even seen in the video), that allows controller input to be read as bytecote (which is similarly not seen very well. I only saw eight button presses, SURELY that's not all that had to be pressed?), obviously it is more powerful than you think.
I think this is still comparable to Pokemon. It is no different than allowing save corruption to give overpowered Pokemon/corrupt things and get no battles ever/etc, but NOT allowing ACE to jump to the ending.
or object X/Y positioning in Mega Man and the old Super Mario World run.
Getting everything to line up just right when you can't actually control them isn't very easy, now is it?
I'm aware for these types of TASes bots are used, but still. >_>
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
Dyshonest wrote:
Yes, because the run that calls the ending has to construct its own code to do that. The method used in the 12 minute run could call some specific functions, like "end this stage" in some stages, or "spawn water stream object" in Ice Man's stage, but not "go to ending".
In order to do that, the 30 second run goes through quite a few more hoops: using the delay glitch to spawn a glitch object, which calls to some object RAM, which is specifically laid out in the run to form code to jump to controller input, and from there on it calls the ending. That is ACE, because it uses data such as object positions to set up as bytecode.
What prevents it from calling for the end of the game, exactly?
There is no known way so far to call any (useful) functions aside from the ones I mentioned above. Either calling the ending is out of the delay glitch's range, or it has just not been found yet. Either way, it's currently not possible to use the glitch to call the ending.
Dyshonest wrote:
If that very glitch is what's capable of spawning the ACE-enabling glitch object (which is never even seen in the video), that allows controller input to be read as bytecote (which is similarly not seen very well. I only saw eight button presses, SURELY that's not all that had to be pressed?), obviously it is more powerful than you think.
The delay glitch is really just a catalyst for another glitch (whatever the glitch object does). Delay glitch itself can't call any more than a select few functions in ROM, such as "end stage" or "spawn an object". It's the glitch object that calls to RAM, which can be used for ACE.
Delay glitch is powerful, sure, and can lead to other, even more extensive glitches, but it by itself cannot do ACE. That's what makes it a separate category.
Dyshonest wrote:
I think this is still comparable to Pokemon. It is no different than allowing save corruption to give overpowered Pokemon/corrupt things and get no battles ever/etc, but NOT allowing ACE to jump to the ending.
So to you, it makes no difference whether a run just modifies memory, or executes it?
Noted, but I don't think a lot of people agree with you, given what I've read in this thread.
Dyshonest wrote:
or object X/Y positioning in Mega Man and the old Super Mario World run.
Getting everything to line up just right when you can't actually control them isn't very easy, now is it?
I'm aware for these types of TASes bots are used, but still. >_>
In the context of a TAS, it is easy. Manipulate some objects to move around, and make sure they're at the right position at the right frame. Doesn't sound very complicated, does it?
In fact, I'm pretty certain the SMB3 ACE run didn't use any bots to move the objects around. In fact, people are doing the same things in unassisted runs for SMB3. That should say something about how doable it is (although it depends on the game).
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Joined: 11/13/2006
Posts: 2795
Location: Northern California
Dyshonest wrote:
It is no different than allowing save corruption to give overpowered Pokemon/corrupt things and get no battles ever/etc
Not getting battles has nothing to do with any form of corruption, save or memory or otherwise. That's just simple luck manipulation.
I actually have an honest question/point for once and not some pseudo-psychological manipulation bullshit for my own enjoyment. The 96 exit SMW run uses glitches that you would consider memory corruption, namely null sprites and stunned sprites. These were used to lead to ACE before the chuck-eat method was found, and they quite obviously aren't used to the same effect in the 96 exit run. Since you're arguing that all memory corruption is ACE and there shouldn't be room for more than one memory corruption category, does that mean the current 96 exit run shouldn't exist alongside the ACE run?
If so, what 96 exit run WOULD exist alongside the ACE run if things were up to your standards? Would it have to be completely glitchless or just avoid anything that you consider memory corruption? And if not, would a hypothetical 96 exit ACE run obsolete it? And why would you let it stay around if it was using memory corruption, since there's already a run like that?
I'm just confused because your logic contradicts itself here. Your suggestion calls for the 96 exit run to both exist (as a 100% category) and to be removed (for using memory corruption, which is ACE, which would be redundant).
Also, something I just thought of: If this suggestion of yours was put into effect, how would it work in the context of the site? Would every judge have to agree that a movie corrupts the memory or uses a glitch that could lead to ACE? Or would only a single judge have to make that decision?
The former would ruin the entire point of the judging system. Your suggestion could be parsed as "skip everything or skip nothing, nothing in-between". Technically, group decisions on every movie could count as "skipping nothing" and single-judge decisions could count as "skipping everything", so fringe cases would be the in-between that isn't allowed on the site anymore. Every run would take longer to judge in this case and it'd be a bigger hassle for everyone involved.
If the judging system was kept the same, though, with only a single judge deciding what falls under the new policy and what doesn't, wouldn't that be even more of a hassle? The judges already disagree on a lot of matters, such as tier placement, so introducing a whole new gray area for disagreements would just create far, FAR more tension.
Consider it hyperbole if you want, but I think something like that could very well happen. It's simple enough to decide on something that you think would work, but you really do have to consider the long-term effects of any suggestion you're going to make and not just write everything off as a hyperbolic hypothetical scenario.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
It is no different than allowing save corruption to give overpowered Pokemon/corrupt things and get no battles ever/etc
Not getting battles has nothing to do with any form of corruption, save or memory or otherwise. That's just simple luck manipulation.
I think he's referring to the latest Pokemon Silver run, which uses ACE to warp to the final boss and skip the battle.
The 96 exit SMW run uses glitches that you would consider memory corruption, namely null sprites and stunned sprites. These were used to lead to ACE before the chuck-eat method was found, and they quite obviously aren't used to the same effect in the 96 exit run. Since you're arguing that all memory corruption is ACE and there shouldn't be room for more than one memory corruption category, does that mean the current 96 exit run shouldn't exist alongside the ACE run?
This raises a question similar to the problem with first-gen Pokemon TASes. I considered doing an improvement to the no warp glitch run of Pokemon Blue, which would be a "no arbitrary code execution" run. The problem is that given what we understand of the game's code, we know now that the glitches used in that route involve getting the game to load certain RAM values which can be manipulated semi-arbitrarily to get unusual random encounters. Rather than arbitrary code execution, it's arbitrary data loading. The Pokemon ACE glitch doesn't involve memory corruption, but memory manipulation, and this seems like a bit of a grey area for a "no arbitrary code execution" route.
