User Files from FatRatKnight

Additions include:

Hopefully the fancy numbers and boxes look pretty enough. The orange hexadecimal values by the cyan decimal timers is the RNG value used for determining what spawns. For fairy encounters, it depends on what terrain you're walking over (D0 F0 E0 F0 F8 FF), and it needs to be that value or higher for a fairy to appear. Theoretically.

The directions of existing spawns are color coded: Green means they will unquestioningly go that direction, while orange means they'll only go that direction if not aligned vertically or horizontally with Link.

Still tweaking my prediction algorithms. Currently, the piece of code that predicts the next encounter appearance is inefficient, as it will run through hundreds of RNG calculations every frame. Or, for that matter, while you're sitting there paused, as gui.register runs lua code several times per second when paused. I plan to inject timestamps and a bit of memory to avoid recalculating what we already knew a frame ago.

However, the active display is encouraging. I haven't detected further errors, so here's my current prediction script.

Oh, and one more thing. The script is set up to detect moments the RNG is reset. It'll print, to the Output Console, the RNG value and global timer every time it happens, as these are probably our sync points. Probably good information to know, as if these are identical to some previous trial, then you are almost certainly going to have identical luck. If these are the only constraints to the effects of RNG, then there's 2688 possibilities.

Still a prototype. I'm using integer versions.

Added a snippet of code that attempts to identify world map locations where an exit will drop you off at. One would hope this lets you know where you're teleporting to. Numbers in the bottom right may be of assistance. Additionally, for room exits, I invert the colors if it's 0x3F, and instead show a number from 0 to 3. That's the selector for our world map thing.

Then again, I don't have much experience with these glitches about somehow making use of alternative exits, so I haven't checked how viable the numbers I'm showing are. Also, there is a *known* failure with my script when we're talking about the Maze, as for some reason, the standard 0x3F I expect to see isn't showing up, yet it exits to the overworld. I have things to look at.

Work-in-progress script. I'm playing around with various designs and thoughts as I run the debugger to get information.

Included is something that tracks Link's position, gives two numbers for enemies and one number for enemy projectiles (Link's sword beams and fire shots aren't included). The numbers are damage to Link if he's hit, and how many strikes it will take to defeat an enemy at current attack power.

I also have HUD stuff at the top of the screen. Still working things out and making them pretty enough. I haven't even removed the TASEditor piece in the script, so pressing controller buttons will toggle the TASEditor stuff if that's running.

I've experimented with some registerexec and registerwrite code. One piece is enabled as of this WIP.

Finally, I have my script respond to when you press space by dumping out a list of exits and apparently related numbers. I'm not particularly inclined to disable that bit of code.

This script just spits out what room you're in, and the four destinations of that room. Look near the experience.

Numbers are in hexadecimal. Don't like them? Edit the script and change the several DrawNumx inside the bottom function into DrawNum.

Where is my sanity?

Here's v3, which is exactly as fast as v2, but does random stuff on a different screen. I'm sure the population don't mind me playing around with the taxes. After all, there's no military unrest, or something.

I don't know how I filled up the long delay waiting for the attack ship to arrive, but I found a way. This might be mildly entertaining. Maybe. At least 10 times that of v2, anyway. Keep in mind that I probably moved the exponent from -4 to -3.

If I make a v4, perhaps I should question my submitting without first consulting the forums.

Test run. Did not attempt to maximize frame savings. This is what it looks like when easy is done. Shorter wait, but alas, where's the splashy ending?

By the way, this was how I discovered that you can win without needing something intact on the attacker's side.

Well, new ending strategy: Crash tank into building. Deals 5 damage.

I'm trying to figure out how I managed to miss this. Maybe I just wasn't inclined enough.

Added frame markers.

Largely the same as the previous version, otherwise.

An off-by-one error fixed. I hope.

Also, I experimented with an item seeker code. It will indicate how long you'll have to wait for some item, with the frame count shown as the number, and the color that indicates the item. There is one more number, with an inverted white, that indicates how "out of sync" the two timers are.

I've also recolored the items. Red(s) and orange(L) are the energy drops. Blue(s) and cyan(L) are the weapon drops. White is the extra life.

It is difficult to work with an RNG predictor where there are three factors in its output: Frames passed, lag frames, and whether an RNG call was made recently. The more fancy I try to make it, the more I realize there are factors out of control I can't readily predict.

I can probably add controls to the item seeker so that you can specify a specific "out of syncness" of the timers, but that generally assumes you can get things to lag appropriately. I can try a lag tracker, a good pair up with TAS Editor, but now we assume things will lag exactly how they do when you change the timing of your shots. Then, of course, there are other factors that may use the RNG, and a call will adjust the RNG output for the next 16 frames.

I'm questioning the validity of that "second column" that I threw in there in v1, since it seems a different RNG call is made that adjusts it differently when an enemy needs to think or something. It's still here in v2, though.

But I like the canvas. Well, aside from the fact it acts slow on my laptop, anyway. This display runs rather smoothly here on FCEUX rather than the floating BizHawk canvas.

I still have not identified which color goes to what item, but I can assure you that the different colors go to different items. If I take the time to look, I'll update this description. I've spent said time to transplant the script to FCEUX without nasty hiccups.

I made a quick change and am uploading it right away. Quick tests show its working well enough.