Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
I spawn a third fairy. This files starts from a fresh state rather than a save state with hacked RAM. We have the fairy. What I did this time was to generate a list of possible starting RNGs that would get me R[2]=15 after no fewer than 905 RNG rolls, the theoretical fastest time. Now, with a target gTimer of either 18 or 20, this gives two possible gTimers for any given RNG count, meaning two possible spawns where I hope the west group is omitted. I found a target I like at 933 RNG calls, which works out to an initial R[2] of 46 and gTimer of either 6 or 8. I got a decent group spawn at gTimer=8. From there, I just ran my recursive function to find R[2]=46 and gTimer=8 from the numerous transitions after P6. It took me a while to realize you delayed a while for the last bridge, so I ended up TASing the same bits over and over until I spotted the extra delays you used for manipulation. There were enough leftover frames from removing this delay to do the manipulation. ... I hate getting sick, by the way. Wasn't really able to think well for a few days. Still, here's a fairy. I've got one more fairy to theorize a spawn for.
Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
I now have a fourth fairy. Any doubts should evaporate around now. Once again, I generated up a list.
R2 Fra d
31 829 4  gTimer= 9
31 830 4  gTimer=10
72 859 4  gTimer= 0
72 860 4  gTimer= 1
72 861 4  gTimer= 2
72 862 4  gTimer= 3
72 863 4  gTimer= 4
37 870 4
37 871 4
71 872 4
 0 877 4
 0 878 4
51 886 4
51 887 4
19 890 4
23 900 4
R[2], frames until spawn (delaying at side-scrolling screen if necessary for 21-frame steps), and direction the fairy will travel on its first step (must be east). Actually, it would show 0, 4, 128, or 132 for direction, but I wanted to look at the number myself to make sure I don't mess up. I've only filled out gTimer manually to know what timing to go for. Once I got something working, there wasn't need to fill out the rest of the table. I picked R[2]=72, even though it takes longer than R[2]=31, as picking 31 meant Link takes a fireball to the face. If that didn't happen, then 31 would be the best choice. Since I'm stuck delaying anyway, being slowed by the fireball after Link passes that enemy isn't a big problem. Getting this last fairy took approximately 1 second. I don't want to say we're done with this place. I just wanted to go forward and see if that last fairy is possible, and it definitely is. The encounter between fairies looks real iffy how I did it, so I imagine we should figure out the best path. I have no idea how to script something up to deal with this, so manually checking the 12 possible gTimer starts by delaying at the first fairy may be desired.
Arc
Editor, Experienced player (766)
Joined: 3/8/2004
Posts: 534
Location: Arizona
These fairies are beautiful. http://tasvideos.org/userfiles/info/34282145847103301 I cut 32 frames off of the wait (in the final fairy file) at the non-fairy trap. This result is also 23 frames faster than what is in the currently published movie. I don't know if it's as good as it gets, but I could say the same thing about any part of the overworld.
Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
Hey, even the manipulation likes your savings! I think we're now at 287 frames saved with the Valley of Death fairies, though lately my arithmetic has proven distressingly unreliable. I blame sickness. Ran my script (and whoops, marked the wrong gTimers. Should be 18-2, not 0-4. Distressingly unreliable mental arithmetic, I say) and we have better savings now. No longer I pass a 21-frame block, although we are technically one frame away for a rather flimsy chance to beat the next 21-frame block. The chance exists -- We just need R[2]=0 R[2]=12 (EDIT: Distressingly unreliable. I'm hating this fail) when we trigger the encounter, if we somehow save that one frame. I think all that's left to do at this point is finish up the Great Palace with this and call it a good day. Might be a good idea to mention that fairies have 1/256 chance to spawn in the Valley of Death, 3/4 chance the west group spawns, and 1/4 chance of any particular direction in their random pathing. The last fairy has approximately 1-in-1365 chance of appearing in the west spot and subsequently moving east as its first step. The first fairy in the Valley of Death has proven suitably less likely as we also need to manipulate unwanted groups out of our path and additionally out of the screen before the fairy can spawn, and we have further to travel for its drunken path to be where we need it.
Arc
Editor, Experienced player (766)
Joined: 3/8/2004
Posts: 534
Location: Arizona
Wonderful. I'll get it cleaned up and redo the Great Palace. I'm making rapid progress in the warps movie as well so that I can submit both movies simultaneously. Assuming no unexpected surprises, give me maybe a week.
Kung_Knut
He/Him
Joined: 8/10/2016
Posts: 85
Location: Sweden
Arc wrote:
Wonderful. I'll get it cleaned up and redo the Great Palace. I'm making rapid progress in the warps movie as well so that I can submit both movies simultaneously. Assuming no unexpected surprises, give me maybe a week.
Dear god, I may be the most nonbelieving atheist on earth, but if you do exist and have fatal plans for me, pleeeeeeeeeease let me live just another week!
Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
This is the problem I spot with R[2]=31. If there's a way to bypass that fireball as regular Link, I'd love to know the TASing technique to do so without waiting too long (we'd miss the fairy chance) or changing the RNG (we'd manipulate away the fairy chance, too). Aside from that, I have nothing new to report. Hope to see the submissions come by on time!
Arc
Editor, Experienced player (766)
Joined: 3/8/2004
Posts: 534
Location: Arizona
http://tasvideos.org/userfiles/info/34301879018722255 I killed the skettlar so there's no fireball and you can walk full speed to the left.
Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
Alas. That was done on R[2]=72 (getting the fairy no sooner than 859 frames). Skettlar acts on the RNG, and I need it on R[2]=31 (getting the fairy no sooner than 829 frames), and hacking in that value has the movie fail. The fireball just comes out too early. The biggest attraction to R[2]=31 is the fact the fairy can potentially show up earlier. Try starting from the RAM-hacked movie. The problem should be real clear, although TASEditor doesn't like save state anchored movies. An old lua script of mine might work if you still need something like TASEditor, though I've ignored it since, well... TASEditor happened. Can't say if it's still good after any internal changes in FCEUX.
Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
I want to explain in detail how the RNG really works. Not necessarily for your benefit, but for anyone who wants to someday replicate what I did and spawn fairies and predict things. ... Except that I seem to be at a loss at words. I can't really figure out a good terse explanation, so I will go verbose on any details that come to mind to compensate. I'll probably miss a few details anyway. RNG begins at 051A. I will call this R[1]. The following bytes are R[2] through R[9]. I have a script that detects when a screen transition occurs, by basically setting a breakpoint on a specific instruction and printing a message. When R[1] resets, which is what that instruction does, that leaves R[2] to R[9]. However, none of R[3] through R[9] is used for new RNGs, and R[1] has already reset, so only R[2] has any impact. And one bit out of R[2] (0x01) is not used at all for new RNGs, leaving the other 7 bits (0xFE) as the only effect left. In my script, I divide R[2] by 2 and report a number from 0 to 127. Obviously, I also have a piece of code to calculate future RNGs. One thing I've been doing is simply counting frames from when R[1] is last reset to when the RNG becomes important. The frame count is less about FCEUX's (or another emulator's) frame count, but more whether the game updated its own timers. Once I have a minimum frame count to important event, then I can pick out an initial R[2] and do fancy calculations to see if the right things happen. Presumably, we can delay an arbitrary and precise number of frames as desired, so if the minimum is 705 frames, and none of the 128 R[2] works, we can check at 706 frames, or 707, and so on. Where the gTimer (Global Timer, 0500) comes in is the fact it is persistent between screen transitions, and the fact some events use this and the RNG together. There are two types of overworld spawns: Ones that run down its clock regardless of what you do (gTimer spawn, 0516), and the other ticks down based on you moving about (Step Timer spawn, 0026). Notably, the gTimer spawns use the gTimer, so the only way to adjust when they happen when we're already deep in monster territory is to either wait in 21-frame blocks at the last side-scrolling screen or delay when we enter the last side-scrolling screen. This delay prior to the side-scrolling screen will also affect the RNG, as it runs through a calculation step each frame, and you also get a different R[2]. So, for the gTimer spawns, there are 2688 initial starting conditions, gTimer and R[2] together, where you can adjust what you get. Again, you can always delay in 21-frame chunks to get to the next gTimer thing. There is also the aTimer (Area Timer, 0012). I name it such as it resets the same time R[1] resets, on a side-scrolling screen transition. Actually, not quite the same time (37 or 38 frames apart, by my count)), but as we have no control over this, it is not considered important for a lot of things. Still, by delaying a frame before we transition in, we have a different gTimer, and therefore a different relation between gTimer and aTimer. The aTimer is critical for spawn movements, as they will only decide a new direction when aTimer modulo 16 is zero. The groups will pick a direction based on what internal slot they fill, selecting out R[2] to R[9] based on the slot. Indeed, on your last screen transition, if you have the same R[2] but different gTimer, it is possible that enemies will pick the same directions. So anyway, in my scripting, I try to count out how many RNG calls (a script watches gTimer for this), then once I know how many from last transition to important event (or multiple events in sequence), figure out whether the minimum calls can work or if I need to add delays. In my sample for the last fairy we spawn, the earliest I can get a west fairy spawn that immediately travels east is at 829 and 830 frames, both requiring R[2]=31 at time of screen transition. At 831 to 858 RNG calls, not a single one of the R[2] possibilities exist that fit my criteria, so I keep re-rolling that RNG until the next shot comes up. 859, we have R[2]=72. There are other things than just that fairy that uses the RNG, as evidenced by the Skettlar, and those things need to work out if that possibility is going to work at all. Side note: If you need a "from start" movie that has R[2]=31 at that spot, I can make one easily enough. Anyway, once I know the number of RNG calls, I can figure out my initial gTimer. When gTimer underflows from 0 to 20, it decrements a counter for the gTimer spawn. So, a gTimer spawn will always trigger at the same moment gTimer is 20, not counting terrain that denies spawns. gTimer decrements every frame, but we need to go backwards, so add our call count (829 from my sample), modulo 21, and we have a gTimer of 9. So, with R[2]=31, I would also want gTimer=9. 830 is also a possibility, which is gTimer=10. The reason why there are consecutive gTimers that work with the same R[2] is probably an artifact of the RNG the game uses, and it happens to have a sequence of 9+ bits all 1s being shifted through the "spawn fairy" part, and the directions traveled depend on aTimer and will only pick every 16th RNG call. Pathing is critical for the fairy encounters at the Reflect Trek, and we're also highly constrained in screen transitions since our last restart. Since the aTimer has 37 or 38 frames to run before R[1] resets, my RNG calls counter is actually 37 or 38 frames behind the aTimer. So when triggering an important encounter, I add 37 or 38 to the RNG calls to figure out where the aTimer is sitting, and figure out when the decision is made. If I know in advance what slots things will spawn in, I will know their exact path. Things just get plain messy if there are multiple spawns and the important one is the last one of them, where the other spawns may or may not disappear off the screen edge by then, and it's really hard to tell which slot our important fairy will show up in. Still, with constraints known, a program can trim out useless possibilities, and there are a lot of them where fairies don't spawn, so we have a better shot at manually checking what's left. I guess thanks for reading this verbose explanation, but if I can figure out something smaller and simpler, I'll try it again with that thought.
Arc
Editor, Experienced player (766)
Joined: 3/8/2004
Posts: 534
Location: Arizona
I see only three options for getting through that screen. There's the full speed walk via skettler kill as the 0 frame baseline, which doesn't work. The fairy is +4 frames, but it will lose 29 frames later to open the menu. The fastest possibility with a rear flame dodge is -2 frames. In the hacked movie, Link leaves the cave at 663 and a fairy appears at 848. If I leave the cave 6 frames later at 669, I still get the same fairy spawn. Exiting at 678 is the last frame the fairy spawn works. What's the 1 frame problem? In the warps movie, I'm in P5. I like how Reflect/P4 turned out. Gooma with Attack-3 will be a pain. P6 should go according to plan. Rebonack II at Attack-4 is the most dreaded task remaining. Volvagia shouldn't be a problem.
Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
My conclusion is that what we have now, the R[2]=72 fairy spawn, is the best we've got. We're currently worrying over something we don't need to right now. The main problem here is that we can't manipulate luck at all when it comes to the Skettlar flame. If we want the 829 RNG calls fairy (hacked fm2), we get the forward flame. The 859 RNG calls fairy (main fm2) picks an RNG where we have the rear flame instead, which isn't bad because we need to wait anyway thanks to the fact we need 859 RNG calls. Of course, the published run gets no flame, but this was with an R[2] that didn't cause any convenient fairies to spawn. You want our current fairy to appear, you get the rear flame. You also must wait in the side-scrolling screen for a bit, too. So the problem is in RNG limitations. Fairy spell solution for R[2]=31 is only good if it saves two "frame rules" over R[2]=72. From my end, this does not appear to be the case with our route. If an improvement down the road somehow shows up, and is having trouble manipulating R[2]=72 in a timely fashion, they can still use R[2]=31 as a reasonably fast backup and eat the menu time later. Again, we've already got the best input file we can with the route we have. No amount of RNG trickery is going to make it faster, only what we do with the RNGs we are dealt with. I say just focus on finishing up what you have now and think about the last fairy in detail later. I do not expect to save any more frames with the setup we have. In case you need it, here's a full movie from start to R[2]=31. It definitely can get the fairy faster than our current movie, but we lose out due to menu time. Again, unless you know a way to get around that specific fireball, or can theorize a way without manipulating luck (killing the 829 RNG calls fairy if we use a different R[2]) there's no reason to worry about trying to improve on this.
Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
Now that I have a bigger knowledge base on how RNGs work, and a better script and all that, I got annoyed how quickly I gave up on the extra fairies at the Reflect Trek. Those things need an extra look. Well, after fixing up my formulas again and again, I've looked at making the west desert fairy travel east for its first three steps. I'm scanning by straight up RNG calls. Results:
West desert fairy
Spawn RNG >= 0xF0, west must exist, fairy travel east, east, east.
r[2]= 27 gTimer= 8 calls= 303 ( 314)
r[2]= 88 gTimer=16 calls= 479 ( 490)
... Not pretty. When I say "Short enough delays", it seems the second fastest west fairy is almost 3 seconds slower than the fastest west fairy. We need something exactly 303 RNG calls out, so that dictates our gTimer, and only one specific R[2] can do it. It will indeed be the stuff of miracles if we can not only get R[2]=27 and gTimer=8 (1 out of 2688 possibilities), but do so with an RNG that had already spawned a prior fairy. The trip to the town is fairly unpredictable, so if anyone works out that maze of RNGs, I'd love to know if it is possible. My later search only confirmed the absurdity. Okay, so that's a bust, most likely. What about coming back from town? We want an east fairy traveling west for its first three steps. What have I got?
East desert fairy
Spawn RNG >= 0xF0, east must exist, fairy travel west, west, west
r[2]= 91 gTimer=18 calls= 250 ( 266)
r[2]= 91 gTimer= 2 calls= 255 ( 266)
r[2]= 30 gTimer=18 calls= 271 ( 282)
r[2]= 30 gTimer= 5 calls= 279 ( 282)
r[2]= 30 gTimer=20 calls= 294 ( 298)
r[2]= 84 gTimer= 9 calls= 325 ( 330)
r[2]= 84 gTimer=10 calls= 326 ( 330)
r[2]=124 gTimer=10 calls= 326 ( 330)
r[2]=100 gTimer= 9 calls= 367 ( 378)
Sweet. We have more possibilities. The best one with R[2]=91. My prior searches must have been flaky. I'm still not liking my unreliability from before. The numbers in parentheses are the calls until the random direction is decided, which I needed to see while working out the formula. I've actually cranked my script out to a ludicrous 2000 frames, but none of the R[2]/gTimer pairs I got from delaying our current fairy matched any of those possibilities. This does tell me we have to try out different sorts of fairy spawns, and I'm not sure how to simulate the difference in RNG calls for any given fairy path. Obviously, an east fairy immediately going west will be quicker than one that wanders about, so we don't have consistent timing. In any case, this second look is making that third fairy in the Reflect Trek actually look viable. It'll give me something more to do, and we've proven the run syncs just fine after P4 with any changes we make. You'll be short one small kill for P4, though. Not sure how that affects the route.
Arc
Editor, Experienced player (766)
Joined: 3/8/2004
Posts: 534
Location: Arizona
Fairies at 3 out of 4 traps would be great. The small-6 count would be fine as long as 2 small enemies die at the non-fairy trap. In the warps run, I'm in P6. Gooma went fine. It's a more entertaining fight because now he takes 36 hits instead of 16. The same will be true of Volvagia.
Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
Well, not a lot of luck in my search. I haven't found any R[2]/gTimer pair that allows me to precisely time an encounter and enter the first fairy encounter (exiting town) with the right R[2]/gTimer pair for the consecutive fairy to appear. Most RNG's just don't let it happen at all, and for the some that show promise, the fairy pathing gets in the way. In one case, I'm two frames away to an ideal encounter when the fairy flies out of reach. I can keep looking, but this means delays get worse with each iteration. All the fastest spots aren't helping. My text file. I started marking "no" when I realized I could check if the RNG can produce something reasonable assuming the fairy path was perfect. And if it came up empty, I wouldn't need to TAS getting the fairy manually.
r[2]=  1 gTimer= 1 calls= 716 ( 731)v>v^v<<^<^  --~857, Path works, gTimer bad
r[2]=  4 gTimer=12 calls= 706 ( 715)v^>v^<vv><  -- 899, Path works, gTimer bad
r[2]= 34 gTimer=10 calls= 704 ( 715)vv>><<<<^v  --????, Used in movie, RNG bad
r[2]= 46 gTimer=17 calls= 711 ( 715)<<>vvv^>v^  -- 864, Path works, gTimer bad
r[2]= 47 gTimer= 8 calls= 723 ( 731)v^v<v^^v>^  -- 851, Path works, RNG bad
r[2]= 47 gTimer= 9 calls= 724 ( 731)v^v<v^^v>^  -- 851, Path works, RNG bad
r[2]= 51 gTimer= 8 calls= 723 ( 731)v><<v<v>v^  -- 851, Path works, gTimer bad
r[2]= 53 gTimer=14 calls= 708 ( 715)<v^<v>v>^v  -- 884, Path works, RNG bad
r[2]= 55 gTimer=10 calls= 704 ( 715)>>^<v<vv^<  --~883, Path works, RNG bad
r[2]= 55 gTimer=12 calls= 706 ( 715)>>^<v<vv^<  --~883, Path works, RNG bad
r[2]= 55 gTimer=13 calls= 707 ( 715)>>^<v<vv^<  --~883, Path works, RNG bad
r[2]= 55 gTimer=14 calls= 708 ( 715)>>^<v<vv^<  --~883, Path works, RNG bad
r[2]= 65 gTimer=11 calls= 726 ( 731)<>v<><v^v^  --~885, Path works, gTimer bad
r[2]= 68 gTimer=20 calls= 714 ( 715)v>>v<^v<>v  -- 867, max at 898, need 900
r[2]= 70 gTimer= 2 calls= 717 ( 731)v>v<vv^><<  -- 880, Path works, RNG bad
r[2]= 70 gTimer= 3 calls= 718 ( 731)v>v<vv^><<  --No
r[2]= 70 gTimer= 4 calls= 719 ( 731)v>v<vv^><<  --No
r[2]= 79 gTimer=18 calls= 712 ( 715)<>>>vv^<v>  --No
r[2]=105 gTimer=13 calls= 728 ( 731)<>v>v>v<^>  --No
r[2]=105 gTimer=14 calls= 729 ( 731)<>v>v>v<^>  --No
r[2]=114 gTimer=13 calls= 707 ( 715)<v^<>><v>v  --Test this (long pathing. fail)
r[2]=114 gTimer=14 calls= 708 ( 715)<v^<>><v>v  --No
r[2]=114 gTimer= 0 calls= 715 ( 731)v^<>><v>vv  --No
r[2]=116 gTimer= 9 calls= 724 ( 731)v><^vv>^v<  --No
r[2]=116 gTimer=15 calls= 730 ( 731)v><^vv>^v<  --No
Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
More bad news. I examined the second iteration. No viable prospects there, either. I also learned I need to make a tweak to my script, since if a spawn happens on (aTimer AND 0x0F) == 0, they will react immediately, not 16 frames later. One item in my list is erroneous in that it fails to display the first step (r[2]=114 gTimer=16 calls= 731 ( 747)^<>><v>vv>). Here's the bad news listed out. This time, the numbers indicate number of RNG calls to make r[2]= 91 or 30 happen. I've only manually checked two of them, but alas, the fewest RNG calls I could make were not low enough for the target calls. I've also shown cases with very high RNG calls, which means I wait long enough to go well beyond the displayed directions I have in my list. I have not examined those in detail, due to... Well, high delay.
r[2]=  0 gTimer=14 calls= 750 ( 763)v>v<v^vv>>  ====912, too south for my taste
r[2]= 20 gTimer= 7 calls= 743 ( 747)^^>vvv^v<v  ====913, lowest is 919. Fail.
r[2]= 39 gTimer= 2 calls= 738 ( 747)>><vvv>v>v  ====984
r[2]= 43 gTimer=10 calls= 746 ( 747)>vv<>^<^>^  ----890, path looks bad...
r[2]= 44 gTimer= 7 calls= 743 ( 747)>vv^^vv>v>  ====947
r[2]= 55 gTimer= 7 calls= 743 ( 747)^<v<vv^<>v  ----955
r[2]= 90 gTimer=16 calls= 731 ( 731)v^<<v>vv^<  ====901, lowest is 914. Fail.
r[2]=114 gTimer=16 calls= 731 ( 747)^<>><v>vv>  ----901, path looks bad...
r[2]=114 gTimer= 0 calls= 736 ( 747)^<>><v>vv>  ----901
r[2]=114 gTimer= 2 calls= 738 ( 747)^<>><v>vv>  ----950
This fairy just does not want to help us.
Arc
Editor, Experienced player (766)
Joined: 3/8/2004
Posts: 534
Location: Arizona
Sounds like that third fairy isn't going to happen. Heck of an effort, though. And the fairies we have are marvelous. For some good news, the warps movie is finished. It is one smooth gem, let me tell ya. Very pleased with it. Here's the schedule I'm hoping to keep: 18 Oct: Finish warps movie ✓ 19 Oct: Finish warpless movie ✓ 20 Oct: Prepare for submission ✓ 21 Oct: Dual-submission party ✓ So Kung Knut, hide out in your bunker for just a few more days.
Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
My search for the third fairy has stopped. My search space has given no helpful results, and there's still a few potential spots to look through. There's no certainty that it'll even give the fairy we're looking for, the RNG is relatively limited (128 R[2] possibilities on transition, and we need gTiners to line up precisely). I'll still be around, in case someone else wants to take up the search. No guarantee we'll get anything.
Kung_Knut
He/Him
Joined: 8/10/2016
Posts: 85
Location: Sweden
I personally think that it a bit disrespectful to talk about other categories in the submission threads after all that hard work, so I'm posting a question I have here instead: Are any of the new techniques used in your warps and no warps runs also applicable in the glitched 5-minute run?
Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
On the Overworld manipulation half, I can't say the RNG manipulation will give much help for the major skips run. Might as well answer my half. Arc has more familiarity with the other techniques, of course. But on the RNG front, I don't see anything obviously useful to the 5-minute run.
Arc
Editor, Experienced player (766)
Joined: 3/8/2004
Posts: 534
Location: Arizona
Kung Knut wrote:
Are any of the new techniques used in your warps and no warps runs also applicable in the glitched 5-minute run?
The warp-glitch run could use the encounter glitch on the bridge after exiting Glitch Town the first time (frame 1700). It could also use the encounter glitch on the bridge to Saria (frame 10000). So it looks like there are about 3 seconds of time saved.
Editor, Skilled player (1502)
Joined: 7/9/2010
Posts: 1317
FatRatKnight wrote:
But on the RNG front, I don't see anything obviously useful to the 5-minute run.
There could possibly some frames to save by changing the exit delay to another exit, the current one uses one frame at the second healer glitch and six? in the room before the red knight to manipulate the red knight. I don't know if it could do lag removal on the overworld.
Favorite animal: STOCK Gt(ROSA)26Sortm1.1(rtTA,EGFP)Nagy Grm7Tg(SMN2)89Ahmb Smn1tm1Msd Tg(SMN2*delta7)4299Ahmb Tg(tetO-SMN2,-luc)#aAhmb/J YouTube Twitch
Editor, Skilled player (1158)
Joined: 9/27/2008
Posts: 1084
Well, that is an idea. Any condition where luck is required is best handled by picking as many possible screens to delay at as possible. Note that the last time a restart is done resets both the RNG and Global Timer. No amount of manipulation will affect the initial conditions after a reset, so you'd only have to count the transitions since the last restart, and find the earliest one of that set that can be used to manipulate the thing you need, without breaking other stuff that went right, of course. As for lag management, it's hard to be certain. Delay a frame here and you remove a lag later. Net gain is zero frames in that simplified case, but it will also affect later RNG, and the gTimer is also different. Thankfully, the points where we need to change our delays has been identified, so if there's luck involved, we'll know where to scatter our delays without tearing our hair or closest equivalent out.
Active player (432)
Joined: 4/21/2004
Posts: 3516
Location: Stockholm, Sweden
Arc, might aswell complete a 100% run while you are on a roll :P
Nitrogenesis wrote:
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
Arc
Editor, Experienced player (766)
Joined: 3/8/2004
Posts: 534
Location: Arizona
AngerFist wrote:
Arc, might aswell complete a 100% run while you are on a roll :P
Maybe. It's a large time commitment. Also doing 100% kinda sucks for the person doing the TAS. The most popular 100% speedrun category is all keys, no warps, no restarts. Not a very exciting TAS, I don't think. It would require overworld fairy manipulation again. With no restarts, if you made a slight mistake early in the movie, you'd desync everything afterward if you went back and fixed it. If you allow warps and restarts, there's no longer a good reason to exclude scroll-lock, since it doesn't ruin the game in 100% the way it does under any% rules. So you're playing a lot with the screen graphics glitched.