Can't find it on Wiki: MovieRules.
My question is simple, am I allowed to set whatever values (bizhawk+nes) or there's an artificial limit (meaning we aren't allowed to write programs before the TAS even starts)?
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
I Am Not A Judge, but personally I think as long as it sounds like something the machine could plausibly boot up with it's okay.
e.g. picking the starting values of uninitialized RNG = ok.
Didn’t adelikat make it possible to change those values for BizHawk, because he needed it for a Cheetahmen submission? So long as it’s a possible state (you’ll have to prove that I guess) it’s ok.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
I'm a big believer that any state that is possible to start with should be allowed.
If you have a game in mind, I've been looking for an excuse to build something like this. (Currently in BizHawk you only have a way to set specific register values on the cart itself, done specifically for Cheetahmen II)
Just do it, submit it and then look at people discussing this problem and possibly finding solutions. (This was my plan all along!)
I think you don't have to rely on emulator features for that, just use a lua script that runs once and activate it at frame 0 and then tell people in the submission text that this is necessary.
(don't let it be judged by Nach)
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
If you can't prove that your precise selected combination of start up RAM choice is a valid one, I say reject it.
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.
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.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Derakon wrote:
Here, have an infinite multiverse. I'm sure my RAM startup values are in there somewhere.
Don't be sure of anything, thanks to bit propagation there are more invalid states than there are valid ones (mathematical proof and elaboration). People seem to be utterly clueless on this point.
Derakon wrote:
How do you prove that a given state is valid?
Take apart the hardware and examine it.
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.
Here, have an infinite multiverse. I'm sure my RAM startup values are in there somewhere.
Don't be sure of anything, thanks to bit propagation there are more invalid states than there are valid ones (mathematical proof and elaboration). People seem to be utterly clueless on this point.
Okay, fair enough. Though to be pedantic, in an infinite multiverse, somewhere there's a console that had the right combination of ionizing radiation strikes to initialize the RAM to the desired pattern. This is so far beyond "astronomically unlikely" as to be a complete joke, but infinite multiverses are weird that way.
Derakon wrote:
How do you prove that a given state is valid?
Take apart the hardware and examine it.
So a validity proof requires achieving that state on hardware? That seems rather strict. What if you're reasonably confident that a state is possible, but it has low odds (like 1 in 10,000)? Do you have to keep power-cycling the console until you manage to get the state you want?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Derakon wrote:
So a validity proof requires achieving that state on hardware? That seems rather strict. What if you're reasonably confident that a state is possible, but it has low odds (like 1 in 10,000)? Do you have to keep power-cycling the console until you manage to get the state you want?
No, you need to make new consoles infinitely and power cycle each of them all the time, also you'd better not make them all in one place from the same details, because that's how their known difference was achieved. Then, maybe in 1000000000000000000000000000 years you'll get your brilliant state and prove it's happens.
On the other side, in TASing we usually consider something possible until it's proven to be impossible. And even then there's a room for doubts and hope :D
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.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Derakon wrote:
Derakon wrote:
How do you prove that a given state is valid?
Take apart the hardware and examine it.
So a validity proof requires achieving that state on hardware? That seems rather strict.
Since the vast majority of states are invalid, and we've selected a fair identical starting point for TASs, if you decide to tweak things in your favor, then it is upon you to also prove such starting point is valid. TASing is supposed to be about what is possible with the game and its system given the perfect player, not about what you can do if you modified the beginning to an impossible state given the circuitry in question.
Derakon wrote:
What if you're reasonably confident that a state is possible, but it has low odds (like 1 in 10,000)? Do you have to keep power-cycling the console until you manage to get the state you want?
Odds aren't relavent. If it's possible, then it's possible.
The way RAM works, there is a pattern to initialization, some bits will always mirror or oppose the same other bits at each initialization time. You don't need to prove the state in question happened in one in a million power ups, you need to show the lines in the RAM is connected in such a way that the state you've chosen doesn't violate any of the relationships that require mirror and opposition between all the bits in the state.
Edit:
Alternatively, you can show that the game in question after decompiling it (or similar) only happens to look at the bits in question that you're setting, so we can ignore researching the others bits. Then you simply need to prove the validity of the state of the bits you're setting in their relationships to each other and their ability to be 0 or 1 randomly.
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.
After a brief discussion with Nach on IRC, I realise we (two at least) totally don't share the same views. Now I would like to get the discussion back from the probabilities to the original topic:
Am I allowed to set whatever addresses to a specific value or do we have an artificial rule like the "Don't use password to skip the end" or something like Nach's (good) observation: (it's) "beyond the scope of play"(ing)?
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Every game comes out of the factory with a clean SRAM (either wiped to 00/FF or with some specific values the game expects). You have to start with that. (You may start with arbitrary values if you can provide a TAS that creates these values.)
Anything else is like hacking the game or using cheat codes.
Okay, fair enough. Though to be pedantic, in an infinite multiverse, somewhere there's a console that had the right combination of ionizing radiation strikes to initialize the RAM to the desired pattern. This is so far beyond "astronomically unlikely" as to be a complete joke, but infinite multiverses are weird that way.
There's also a universe where - right at the beginning of every boss fight - ionizing radiation strikes and changes the memory cell containing the bosses' HP value to 0. Let's allow gameshark codes!
Nach wrote:
If you can't prove that your precise selected combination of start up RAM choice is a valid one, I say reject it.
Just out of curiosity, has this been proven for the default state of the accepted emulators?
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
creaothceann wrote:
Every game comes out of the factory with a clean SRAM (either wiped to 00/FF or with some specific values the game expects). You have to start with that. (You may start with arbitrary values if you can provide a TAS that creates these values.)
Anything else is like hacking the game or using cheat codes.
Assuming it has SRAM. I've also seen Electronic Arts Games come out of the box with SRAM initialized to 0xEA, which I doubt the game is necessarily expecting.
But everything else you said is absolutely correct.
Tub wrote:
Nach wrote:
If you can't prove that your precise selected combination of start up RAM choice is a valid one, I say reject it.
Just out of curiosity, has this been proven for the default state of the accepted emulators?
I can't speak for every emulator. I do know some emulator authors have ensured their emulators start from a valid clean slate.
For the few emulators that this hasn't been done, the least I can say is that everyone has the same starting point, and it's not a free for all with no care given at all, and the starting state selected by the emulator isn't one specifically designed to influence particular games in particular ways.
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.
There's also a universe where - right at the beginning of every boss fight - ionizing radiation strikes and changes the memory cell containing the bosses' HP value to 0. Let's allow gameshark codes!
No no no, using gameshark codes is clearly cheating, but ionizing radiations can happen naturally.
We should allow ionizing radiations to be implemented in the inputs part of movie files, and of course create a tag and category for runs that use it, to keep things fair ^^.
It would look like that in the end:
SNES Super Metroid (JPN/USA) "100%, IR" in 00:00.016 by Alpha&Omega.
With the tag:
-uses ionizing radiations to save time
I'm a big believer that any state that is possible to start with should be allowed.
Personally I'm not so sure. I'm a big believer that games should be completed as fast as possible via gameplay, not via poking the hardware by other means.
Of course initial RAM state is in that fuzzy line between the two. It's, however, something that's done even before the game starts, and thus is not part of playing the game, which is why personally I lean towards it being outside the scope of "actual" speedrunning.
On the other hand, the number of games where this can be used is so small that in the end it isn't such a big deal.
The way RAM works, there is a pattern to initialization, some bits will always mirror or oppose the same other bits at each initialization time. You don't need to prove the state in question happened in one in a million power ups, you need to show the lines in the RAM is connected in such a way that the state you've chosen doesn't violate any of the relationships that require mirror and opposition between all the bits in the state.
Edit:
Alternatively, you can show that the game in question after decompiling it (or similar) only happens to look at the bits in question that you're setting, so we can ignore researching the others bits. Then you simply need to prove the validity of the state of the bits you're setting in their relationships to each other and their ability to be 0 or 1 randomly.
Okay, thank you for the clarified ruleset. Not that this is ever likely to be personally relevant, but it's good to know that there's a sensible policy in place. :)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
