Nick007J, thanks for clarifying. I don't have all the details and while your post wasn't a technical description, because of your technical details I have a better idea of what is happening now.
I understand your points, but do want to assert that it's not the possibility of code execution that determines ACE, it is the actual execution of arbitrary code. And as you pointed out, sometimes ACE is slower than a higher level exploit to reach game end state. This isn't unique to GTA:VC.
The TAS community is generally running games on bare metal platforms (consoles without a dedicated operating system), and so far, we have always referred to ACE as directly executed CPU instructions. The term is fairly new after all and new exploits are still being found in games so this may change. The argument could be made that ACE need not be raw host CPU instructions, but could also be instructions for an interpreter or convoluted state machine. But the issue here is that unless that interpreter is Turing complete, even with arbitrary input, can this "code" be considered to have the same parity as machine instructions?
Historically, we've called runs that manipulate memory to alter a state machine or script interpreter simply "memory manipulation" or "memory corruption" depending on the exploit. This is even when it creates entirely new interpreted script events. But all games that we've been able to do with this with have been very limited in scope and have not been Turing complete machines. If GTA:VC could be one, perhaps we can coin....ASE (Arbitrary Script Execution) ? (just joking...mostly...)
Hi, I am from the TAS community. My NES / SNES robot was used to introduce the wider world to TAS console verification at GDQ events. Relating to this topic, my robot was used to display various ACE runs, such as the AGDQ'14 Snake & Pong demo, the AGDQ'15 Pokemon Plays Twitch demo and the AGDQ'16 Super Mario Maker All Stars runs.
I apologize I am late to the discussion but I wasn't aware of this until now.
As someone from the TAS community, and with my understanding of this glitch, I can say confidently that we absolutely would not call what is used for the glitched run an ACE run.
ACE is not just a meaningless buzzword. This is a technical acronym that stands for "Arbitrary Code Execution." This term was coined by the TAS community specifically to address the difference between a glitched run that does not execute arbitrary user code (up to and including executing unexpected but not arbitrary code), against those that do.
To be clear: The first word - arbitrary - is very important and a distinguishing factor. In an ACE run, arbitrary code is executed - that's what the term means. Not just any code, but arbitrary code. You can do anything (theoretically, if given enough instructions) beyond this point. If during a run memory is corrupted, the stack is corrupted, unexpected but present code is executed, or generally unreachable code is executed, but no ARBITRARY CODE is executed, then it is not an ACE run.
Thus the defining point of ACE is the executable payload. And there is none for this run.
With the rising popularity and knowledge of ACE speedruns has come the misuse of terminology. To put it simply: just because something weird happens doesn't mean it is ACE. Likewise, just because something technical happens doesn't mean it is ACE either. Bringing this up has little to do with purism, zealotry or ruining people's fun, so much as it is the simple calling out the incorrect use of a name. It reeks of buzzword bait and simple mindedness. I hope I am wrong and this is merely a misunderstanding.
When I first saw an ACE of this, I was wondering what code was being executed. I was disappointed to see that there is no executable payload with this glitch.
ACE is a technical term, just as "stack underflow" would be. Just because something is the way it is now, does not mean it should always be that way. Please, use the correct term.
