Hophoolio is basically correct. "Hexing" is short for "hex-editing", which refers to modifying a file that is not normally easy to read. But around here it's devolved into "going back in a movie file and changing the input after it has been created". Depending on the game, this may be more or less feasible. In a simple game, for example, you might discover an improvement on level 3 after finishing level 15, go in and change the level 3 input (and move the input for the entire rest of the movie up a bit), and still have the movie work. Games with lots of random events tend to not work so well for this, though, because changing level 3 means that level 4 is slightly different, which means that your input there is no longer valid -- say, an enemy decides to jump instead of duck, and now you run into him instead of going around him.
SM64 is not hex-friendly, so you have to get the input right the first time. Any improvements found later will require starting over from the point of the improvement.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
SM64 is not hex-friendly, so you have to get the input right the first time. Any improvements found later will require starting over from the point of the improvement.
Very wrong, there is very little in the way of random elements. Most of the time via hexing you can get random elements to sync or become more favourable.
Joined: 9/21/2009
Posts: 1047
Location: California
Mitjitsu wrote:
Derakon wrote:
SM64 is not hex-friendly, so you have to get the input right the first time. Any improvements found later will require starting over from the point of the improvement.
Very wrong, there is very little in the way of random elements. Most of the time via hexing you can get random elements to sync or become more favourable.
That's not very accurate. A ton of new strats would need to be altered due to the places where enemies spawn. Eg, the new chain chomps gate strategy. i tried hexing that onto a new .m64 and during the slidekick, i hit a goomba. And we were talking about a 120 star tas anyway. What Derakon meant is that you cant be 80 stars in and then go hex the 5th or 6th star.
does anyone really know what manipulates the randomness? Like, does number of frames taken before a level count? does number of frames between 2 levels count? or does it nullify itself on entering a new level? frames spent on star selection screen and such... if we knew approxmately what causes the levels to desynch on hex editing, we could maybe manipulate the luck to be the same...
e.g. if it is the time spent between levels and the time spent on start selection screen... that would mean that if we want to hex edit the start, we also have to exit the same picture as the one before the star we want to hex edit in. e.g. I made a 100 coin tas that is 4 frames faster than the one used in the 100% speedrun... but since I had an unoptimized route between the levels before entering the level, it makes my 100 coin tas waaay slower, or useless, since we cannot hex edit it.
shouldn't be too hard to test?
I bet alot of you tasers know what usually manipulates luck, better than me so...
From my understanding the situation is as follows.
There are 60 or so stars in SM64 that have no random elements interfering. These 60 stars are hexable, and this is why the game is 'hexable'. The part people seem to be missing is that these hexable stars interfere with the randomness.
There is some sort of either universal timer or extremely random RNG controlling enemy behavior. Since variables are 32 bits, the repetition of a sequence of RNGs could take hours of gameplay. There are probably on the order of 4294967296 RNG possibilities. To say you could get a 100 coin star with many enemies to synchronize by copying and pasting is laughable.
Say that you want to make a 120 star TAS, and you hex in the first star of the run. Then you TAS the second star (which for example is 100 coins or involves random elements.) Now someone improves the first star by one second. You hex in the first star. Now the second star desynchronizes. The only way to get it to synchronize may be to wait one second after the first star for the RNG to get back to the same point (maybe this isn't even possible.) Now in order to preserve the gains you must redo the second star and all other subsequent random stars in the run because the randomness has been altered.
Basically after the first 100 coin star the run does, anything hexable will most likely destroy that effort.
But there is good news. With all the improvements coming all the time, as the length of the run approaches zero, the likelihood of the run being produced approaches 1. =)
Basically you'd have to redo all the stars that are affecte by randomness after the star that has been improved. The hex-friendly ones can always be hexed in. So to make it easier to improve existing runs, wouldn't it be smart to do those stars where it is liklier that an improvement will be found in the future as late as possible and the tedious ones to redo as early as possible? (Of course speed would have to come first.) Just a thought.
Also, if you do the non-hex-friendly ones before the hex-friendly ones per stage, you don't have to redo any of the non-hex-friendly ones in that stage if an improvement for a hex-friendly one is found.
I think it far more likely that a run would be completed if the runners simply said "Okay, as soon as we're done with this star, that's it -- any improvements to that star will have to wait for a new run." The run would be known to be less fast than it could be if the runners had infinite patience, but oh well. I don't think the rate of newly-found improvements is going to slow down anytime soon.
EDIT: "start" => "star"
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
From my understanding the situation is as follows.
There are 60 or so stars in SM64 that have no random elements interfering. These 60 stars are hexable, and this is why the game is 'hexable'. The part people seem to be missing is that these hexable stars interfere with the randomness.
There is some sort of either universal timer or extremely random RNG controlling enemy behavior. Since variables are 32 bits, the repetition of a sequence of RNGs could take hours of gameplay. There are probably on the order of 4294967296 RNG possibilities. To say you could get a 100 coin star with many enemies to synchronize by copying and pasting is laughable.
Say that you want to make a 120 star TAS, and you hex in the first star of the run. Then you TAS the second star (which for example is 100 coins or involves random elements.) Now someone improves the first star by one second. You hex in the first star. Now the second star desynchronizes. The only way to get it to synchronize may be to wait one second after the first star for the RNG to get back to the same point (maybe this isn't even possible.) Now in order to preserve the gains you must redo the second star and all other subsequent random stars in the run because the randomness has been altered.
Basically after the first 100 coin star the run does, anything hexable will most likely destroy that effort.
But there is good news. With all the improvements coming all the time, as the length of the run approaches zero, the likelihood of the run being produced approaches 1. =)
Nice, someone who actually understands things, unlike Mitjitsu.
So am I crazy, or does it seem a little crazy to anyone else how similar the new glitchy wallkick is to the wall jump in 2D Marios? I mean, the execution, the precision, the effect...
I don't know if Snark reads this board, but if not then this is to nahoc and anyone who has worked with him, but I am loving the most recent TTC star runs, the glitchy wall kicks are taking over, but they are awesome to watch.
Question: What ever happened with http://www.youtube.com/watch?v=YI8BCg5Rj78 route I know someone else had of this vid to but completed with a slow ending. Did it turn out impossible/ and ending couldn't be worked out to beat the current route?
Joined: 9/21/2009
Posts: 1047
Location: California
TheRealOne wrote:
I know someone else had of this vid to but completed with a slow ending. Did it turn out impossible/ and ending couldn't be worked out to beat the current route?
I know someone else had of this vid to but completed with a slow ending. Did it turn out impossible/ and ending couldn't be worked out to beat the current route?
is it possible to somehow land on top of the wall? or kinda glitch inside it? it would save the time from the fall
Noob Irdoh: I think people just comment on the YT vids rather than here
edit: actually rewatching the vid the fall is really quick so it doesn't lose time
Regardless of all of the discussion of hexing, is someone making a collection of TAS WRs for each star? It seems like once we have a route and the best strategies for each star, TAS'ing the whole thing becomes a more straightforward project. (I'm willing to help out if it seems like a good idea and nobody else has taken it on yet.)
But the problem is that the single star WRs rely on certain random elements, and the optimal all stars run has to optimize as many of them as possible.
Joined: 9/21/2009
Posts: 1047
Location: California
I don't understand why this conversation about luck and a 120 star run has to come up every few pages over and over again..
On another note, here is a good place to see unofficial WRs. Not sure if it has been posted before, but:
http://www35.atwiki.jp/sm64tas/
I have a bit of a mad suggestion for a 120 star TAS.
My idea is that you take the current records from a fixed date, and use those to compile a 120 star TAS. Accept no further improvements if they can't be added as you are working on it, but ones that can be added as you go, obviously include them. Then, next year on the same date, a new 120 star TAS can be worked on, using the records gained from that year. This way, it gives people incentive to work on an individual star or series of stars, and have their work compiled into the yearly 120 star project.
Since about half of the stars are hexable, that's half of the work done for you. The rest will obviously be have to done manually. However, I see this approach as the best compromise between people who want to see a new 120 star TAS (like myself) and those people who want to work on an improvement to a star or stars.
It is just a thought, and one that might work given the amount of interest in TASing this game.
My idea is that you take the current records from a fixed date, and use those to compile a 120 star TAS. Accept no further improvements if they can't be added as you are working on it, but ones that can be added as you go, obviously include them. Then, next year on the same date, a new 120 star TAS can be worked on, using the records gained from that year. This way, it gives people incentive to work on an individual star or series of stars, and have their work compiled into the yearly 120 star project.
Derakon wrote:
I think it far more likely that a run would be completed if the runners simply said "Okay, as soon as we're done with this star, that's it -- any improvements to that star will have to wait for a new run." The run would be known to be less fast than it could be if the runners had infinite patience, but oh well. I don't think the rate of newly-found improvements is going to slow down anytime soon.
:)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
