User Files from FatRatKnight

Spits out a list of RNG values in the future. I don't know what items go to what, as I have not investigated that, but I did colorize based on which threshold is hit from what I interpret in the disassembly.

Two columns.

The one on the right is the list of RNG the game will generate in the future, assuming Timer_Lagged runs every frame. If there is a lag frame, the numbers will appear to increment while shifting up the column. I expose the numbers as this will be a way to understand whether lag can be used to shift in the right RNG value at the right time, by aiming to either remove some or add some. Whether you have that much control over lag is another issue, however.

The left column shows what happens if exactly one RNG call were to happen immediately. As can be demonstrated, it doesn't have any effect beyond 16 frames, so it's only good if you plan to destroy a pair of enemies close together, or you can somehow time other random actions at that moment. No real testing was done to ensure the quality of this column, however.

Someone wanted help with RNG stuff. So, here it is. Since I don't know what else I can do to help, this will be the only script I make for Mega Man 5, until someone suggests something reasonable.

Exhibit #8. At one point, I was planning an April Fool's submission. That never happened.

Speaking of which, I even have a write-up somewhere. Let's see if I can't find it...

... Alas, I can't seem to find it. It may have been lost somewhere. Sad.

The script itself is a state machine that deals with detecting which object it wants to avoid. When it approaches the "target", it tries to avoid any planes that spawn in a bad spot with a rather bad timing. Hopefully, it is a robust enough algorithm to survive and hit the target indefinitely.

Exhibit #7. Something about Azure Dreams, now. Contains a bit of information about the RAM map, in particular, where the items are located and the RNG information. Incomplete item listing, but it has a structure to let you know what it doesn't know.

I recall using this to perfect my game, in that I pick up ridiculous amounts of stat-boosting seeds and such. If anyone plans to TAS the GBC version rather than the PSX one, I happen to have a little information on the RNG already. Take it!

Exhibit #6. Oh, Dungeon Magic. Yet another not-so-brilliant game I had the pleasure to try, but if you can get around the problems it has, it's still better than, oh... GBA Eye of the Beholder.

This was an extreme 100%-style run I was trying. More a perfectionist rather than merely picking up everything.

This is in case you haven't got enough of ridiculously fast running about and door opening animations, with a helping of slow store dialogue to go with it.

I highly recommend the map script to go with this, though.

Fifth exhibit.

Ah, another old script of mine. I'm not sure if I'll set myself up for DS TASing again, but here's one game I was analyzing and never told anyone about here.

Since I don't have things set up, I can't say with certainty what it was about. I do remember being able to switch between individual stats of individual planes, and I also remember tweaking the script to display my missile data and the closest distance to a particular target it managed to reach. Fun stuff to mini-TAS a part and hit something with a not-homing missile from very far away. No, I do not have it recorded.

Freedom Wings is another one of those games that aren't the greatest out there. Or even all that wonderful, really. You're not missing much by never picking up this game.

Fourth exhibit.

This is the data extraction script I've been using for that... One game... For the GBA. Actually, it's less of a script and more of a set of functions. I forget what I was using it for last, but I've adjusted the code every time I needed to get at another piece of information.

The code could be better organized, but anyone messing with this had better know a few things about lua before trying this script. I have put no provisions for others to use this, as it was strictly for me to use, and me alone. Oh, and anyone messing with this script should also have a really good idea about data structures, and a helping of some rather interesting intuition, since it was certainly non-trivial to work out what every one of those internal bytes in the game meant.

Not for the casual viewer. The more technical you are, the better. If you have no confidence in computer stuff, well, tough. You're looking at the wrong script. It's bleeding edge experimental stuff that can only be operated by someone willing to put significant time into it.

For use with VBA, though.

Third exhibit. Can't confirm whether it works right now. Dear, ye... This thing is ancient! This is before I started attaching local to most of my functions. Time to dust off some cobwebs.

Apparently I was working out wall detection, and even an attempt at an automatic way of keeping the player safer versus walls when playing normally. I'm not sure how much this is TASing and how much is casual enhancement, but hey. There are some good memories for me to find here. I recommend lua knowledge before testing the script, since again, I can't confirm it works right now.

Second exhibit. Apparently, I was making a visual compass or something. My guess for the numbers are about as good as yours, and I sure hope yours is any good, since I believe they relate to speed, position, facing, and momentum. The numbers on the bottom right may have something related to boosts, I'm pretty sure their purpose will be obvious when you try to boost.

The compass would be much better with some margin off to the side, or on a separate canvas, which VBA doesn't have. Any plans to port this to an emulator with such capability should look to adjust the display for that feature.

Currently backing up some of my things, but I may as well upload a few of them into a public spot. They may come in slowly as I find the more interesting things.

First exhibit is my R.C. Pro-Am TAS, which I still insist I have no plans to finish, despite having already done one lap on track 24 by now.

Sure feels like Super Sticky Tires is actually making it harder to deal with sharp turns. Thing is, turning rate is an average of 3 per frame (2-4-2-4 pattern), but the maxed out tires of the third vehicle type shifts momentum by 2 per frame (more precisely, 510/256). When your facing (turning rate) is far from your momentum (tire rate), further turning forces your momentum to shift fast enough to keep up. With a fast tire rate, it takes much longer to get to that exceeding point, to make use of that 3 average to shift momentum, and so it's much harder to properly hug corners.

Alas, my natural max speed gets to 103, just one MPH short of 104. The speed penalty of differing facing-momentum for these sharp turns hardly matters for my natural max speed, as I can easily maintain 96 MPH (game doesn't affect position in finer steps than 8 MPH). Then again, the high tire rate is useful for when I exceed 104 MPH, as it means the speed penalties don't dip my boosted speed back down so quickly. Trade-offs of a good tire, I suppose.

How amusing... I have no lua script to share this time. This is a rarity.

Time was not a primary goal of this run. Rather, it's a demonstration of what perfect aim and luck manipulation can do. No effort was made for fastest time (in fact, time was intentionally wasted for more ideal walls), and no effort was made in making interesting nothings in particular when I'm stuck waiting. Again, just a demonstration, playing with some idea for an NES game.

It appears there's a type of object limit that is very quickly reached where I'm stuck waiting to shoot for lengthy periods of time.