input after suicide creates tons of broken objects that get read from $0B in RAM and then the pointer jumps over $B addresses each time (object descriptor line length), thinking he reads from ROM. giving him needed values is pretty much possible. especially creating objects by direct input (that is stored in $15 and $16). but some objects need special attribute values, that aren't read from descriptor lines, but loaded other ways. finding the ways to load the needed values, and figuring out the very values and addresses - will take time until this submission is obsoleted
Nach: I've taken a few days to mull over the situation here, and was mindful of everyone's comments in the forum, as well as on IRC.
The previous run found a shortcut in level 3 which essentially leads to a buffer overflow. Instead of abusing that glitch to its fullest, it simply took the data initially written there and skipped a single level. This run now fully abuses that glitch by writing new data and using it to skip 14 levels straight to the final boss fight room.
Now entertainment wise, I vastly prefer the previous run, and even find that run star worthy. However since the same initial glitch is used, even if not fully abused, the precedence in this situation is to have the faster run obsolete the other, despite a drop in entertainment.
In general, based on what we now know about Battletoads, I find that this game deserves 3 main branches.
Glitched (this branch) - fastest completion, even if not very entertaining, skips as much as possible.
1p warpless - so you can see how quick the game can be beaten without being able to fully beat up the enemies, and make use of team attacks, and without skipping anything.
2p warpless - which in theory is the fastest way to beat the game without massive glitches, and significant skips, showing off the full game.
Of course another branch for an absolutely crazy playaround would also be acceptable.
I've found this run to live up to our standards, and the feedback overall was very good. Based on the precedence, I am accepting this run to obsolete the previous.
Nach: Since the previous movie is terrific, and many have asked for it, to give it the recognition it deserves, I have starred it, as short as that may last. This run should not be published with a star. A moon would be fine.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Put it this way, don't use any glitch that you know can be abused like that in a no warps run.
In any case, we're not going to obsolete a no warps run by one which does use warps.
Edit:
I personally agree with you about negative precedence and losing awesomeness. I don't like it. Until we have other rules in place though, I will be supporting whatever rules and precedence we do have.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
When I find a glitch and investigate it, I have a huge inspiration to put it into a run for all. Now I need to keep myself back, fearing that this trick may be considered banned for gameplay-based branches.
And thus, I repeat once again.
The object counter WAS NOT PROVED to be able to cause heavy breaks. What will you do to a warpless run using it, if the glitched branch succeeds to use it (probably among the other glitches).
And finally, I think I have what to say in a thread in General forum, to discuss that quiet "rule".
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.
The previous run found a shortcut in level 3 which essentially leads to a buffer overflow.
No. The cause of the glitch is not buffer overflow, but wild pointer. The essence of the jet glitch is described here (in Russian though).
Nach wrote:
Instead of abusing that glitch to its fullest, it simply took the data initially written there and skipped a single level.
No. Previous run didn't simply took the data. Both runs create objects by deliberately corrupting memory. It's just that previous run didn't modify properties of several objects, and only created LevelEnd object by writing data to its ID (by setting $16 to 0x7F when the broken pointer was pointing at the address).
New run first creates object 0x79 (rat boss) to let it set some properties before actually creating 0x7F.
This process is only half-studied, and most of the work in this run is done through bruteforce (exhaustive testings of various inputs while monitoring memory through Lua displays). It's probable that there's even faster way to write necessary data to the addresses, but further investigations would be more effective if the game is disassembled, which is actually what feos and people were doing recently. A lot of other glitches arise in the process, but since they are very unlikely to finish the game faster than this jet glitch, there's little to no motivation to investigate them. Basically, this is the clear case when speed kills creativity. Here's this killer-glitch, and other glitches are not worthy to develop, since they will never be faster than this one.
While this "greedy algorithm" of TASing behavior sounds reasonable, it is narrow-minded, because you never know what could happen if you chose a circuitous route.
But to clarify feos question about the ObjectCounter glitches (e.g. stick glitch).
In this game there are other ways to corrupt memory and deliberately create objects, not just by abusing wild pointer.
For example, you can create a stick object in level 4 even in realtime by changing player Y during specific lag frames.
Since the category of the glitch is basically the same as the glitch used in this run (memory corruption), does it mean that feos should avoid using all memory corruption glitches from now on? Or only the jet glitch (plot-based limitation of glitch)?
You know, instead of creating the stick he could probably create a 0x7F object (but since it's happening in level 4 and not 3, it still would not beat the record).
And even if he knows the glitch can be abused to gain speed instead of entertainment (skip the level instead of playing it with an object that is not supposed to exist in this area) - why can't we consider it a speed-entertainment tradeoff and let it be?
BTW, I'm suggesting to change the screenshot to this one:
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.
Hi guys, I randomly found this TAS while surfing youtube. So let me write some stuffs...
Post #325204 - yes, -1 and -2 (FF and FE) is truly the "end of game" object for 2players, in both roms (J and U) and yes it's "looks like" only level 3 is possible to spawn this. 12th slot... I only saved the addresses but yes it's somewhere in the end, maybe from 9th slot to 13rd.
Post #325349 - Wrong. I did manipulated the memory by pressing different inputs on the so-called "controlling frames" that's different on J and U roms and produces different effects (different objects gets spawn). This happens because there are minimal "memory value differences" and it goes through different calculations.
So I have two questions.
1. Did you optimize both the section after spawning the correct object and destroying it and also optimize the length of cutscenes?
2. Did you tried using the reset button? I tested it many times and everytime I had the conclusion that it's not properly emulated (both fceux and bizhawk), not to mention the 513 bug which also a problem.
If I will have anytime (maybe next year?), I will launch up IDA since I'm more interested in the reset bug (which doesn't need to abuse the jets).[/post]
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
So I have two questions.
1. Did you optimize both the section after spawning the correct object and destroying it and also optimize the length of cutscenes?
2. Did you tried using the reset button? I tested it many times and everytime I had the conclusion that it's not properly emulated (both fceux and bizhawk), not to mention the 513 bug which also a problem.
1) Not fully understand your question, but when it comes to optimizing, I only did it in order to not wait until the object "end of level" (ID = 0x7f) disappears through out of time range (Timer = 0xff equal max range).
2) I tested. I don't know what bugs you mean about?, but I think that I know emulator, which complies with the seeming "console reset" (I haven't checked it).
Here you have an exception if you're interested? see this:
https://feos-tas.googlecode.com/svn/trunk/DJ-stuff/Movies/bt_u-lvl3_3489.fm3
This ended up in Vault. And since we have a ruleVault tier wrote:
It is possible for a faster movie to be published in this category while a slower but "more entertaining" movie is published in another tier.
I see no problem with unobsoleting what was considered "suboptimal".
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.
