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.

Yo! Items! Taking 1st place every track is also a goal.

Of course, a run that actually aims for fastest time instead of picking up all these things should beat this run by at least a few frames. For whatever reason, I chose to shoot some car at the start of some tracks, even though this can never save time, aside from specifically taking time to set up the yellow/orange car's absurd speed. I'm not actually expecting this particular run to be published, but it's something I felt like doing in my spare time.

Do enjoy this demonstration, though.

Before I forget, Config => Video => Drawing Area => NTSC first line = 0 & NTSC last line = 239 is apparently expected of this game.

Numbers.

... Okay, I'll give more than one word.

Left: Position
Middle: Facing and momentum
Right: Speed and maximum speed
Bottom-left: Checkpoint identifier

And the stuff on the upper-left part of the screen is CPU car speeds.

... I still can't bring myself to be chatty. I'm recovering slow, and it's hard to stretch my mind.

Break time! How well can I race the first course of the game? I make a very comfortable distance between myself and the CPU cars.

Alas, this is one of those "go on forever" games. I am aware of Dimon12321's TAS, and the point where it stopped, the third time it collected the NINTENDO letters, seems to be a good spot. This sample should show what sort of improvements one can make over that TAS.

Let's see... Any tricks, uh... Here's one:

The game very slowly adjusts your momentum to match your facing, and while they are far apart, your maximum speed is reduced. But there is a limit to this difference, and turning past this limit instantly affects your momentum. So turn hard to make the curve, then steer back to straighten yourself to minimize lost speed.

I am curious if TAS can race these things indefinitely, or whether the supply of ammo will prove decidedly finite against the cheat-fast CPU cars later on. In any case, here's a small TAS while I stall my write-up for Gauntlet.

https://youtu.be/CsuVDfzdRLI - Thanks solarplex!

Did I mention I hate being sick? While recovering, a second sickness hit. Awful, I say. But my life story isn't what you want to hear.

I've beaten [392] NES Gauntlet by nesrocks in 12:24.65 by 2675 frames. As usual of any submissions I want to make, I want to put subtitles in first. That, and I have a submission text to make, as well.

... I'll get around to it when I'm feeling more in a mood to write. Being sick doesn't help with that.

Too lazy to post a room-by-room breakdown of frame counts. FODA's world 2 was pretty robust, though. (I'm calling it 'world', although it's probably a bad term for a cluster of approx. 20 rooms)

Notable differences include spending a potion to get rid of some massive lag, fetching two keys from secret walls and skipping one different key, and fetching a potion allowed by the spare key. I haven't really found any other convenient potions in my mapping, though. Killing that lag by potion apparently saved over three seconds.

Seems I'm getting closer to improving yet something else. Oh, how fun.

This maps things really, really well. I hope. Since the script knows of the basic walls, and that it also knows of all map objects, this should cover everything there can possibly be in the stage.

Hit space to get a map sprawled out into the Output Console, as well as an object listing. I use "B" for whatever reason, to have the script spit out potential exits. I can confirm that room 98 really has no exits.

This doesn't actually peek into the ROM, only whatever is loaded in RAM. So I still need to reach the room in question to map it, and it still wouldn't get all the variations of it (treasure room exits, for the most part). Still, this gives me a near-perfect knowledge of each room so I won't miss any detail.

I did believe I wouldn't make a significant improvement. Alas, my belief failed me.

Let's see... What tricks have I learned...

As for each level:
r01 - (-002) I saved two lag frames. I did also save a not-lag frame, but lost it somehow...
r05 - (-031) I go to the right after breakable wall. Also lets me line up a stylish shot.
r09 - (-003) Lag. Everywhere. Yah. Honestly, I was lazy here, but I'm still faster.
r10 - (-013) Shot the secret wall from a better angle. Also phased through Death.
r11 - (-117) Skipped the key. This will cost me, however.
t13 - (-006) According to my notes, FODA lagged the treasure room. How?
r14 - (+028) I pick up the earlier key. Faster than r11 key by less than 5 frames, apparently. Other key skipped.
r17 - (-043) The upper panel is skipped. I get the key blocked off by a secret wall, faster than r14 corner key.
r18 - (-006) Not sure what I did different.
t19 - (-002) These two frames were due to the pre-transition input.

r20 - (-017) I thought for a moment. Each dragon head has 100 HP. Elf arrow does 1 damage, 2 with Extra Shot. It costs about 300 frames to get Extra Shot. I doubt I can shoot a head with less than 2 frames per arrow.

188 frames for the first world, plus another 17 frames for the first level in the second. Measurements are done by finding the first non-lag frame after the room fade-in transition.

As far as scripting goes, I actually have very little need of an active script. The only numbers I'm using are the ones shown in this script and my X,Y coordinate. I don't see what other information would help. Well, other than a suite of complete mapping functions, anyway.

... I am not fixing the filename typo.

Most of this script is the DrawNum function. The tiny bit at the bottom of the code is the interesting part.

All it does is try to find objects on screen and paints hexadecimal numbers: ID number of object and the spare number the object may use. It does, however, spot all the walls that might disappear when shot or a flashing tile is touched.

In other news, foda's run syncs just fine in FCEUX. There's a surprising detail in that dragon is immune to damage if currently throwing fire.

I have no clue why I just analyzed this game. I don't believe I'll make notable improvements.

This may be the final version, depending on whether I try to improve my TAS later.

Not a lot was added, though. I did figure out the numbers behind bouncing off cars, and now I color things fabulously. Also, the script has its separate calculations to work out the piecewise function behind steering speed. And lastly, I think I found some more precise info on the road curve, but that still needs further work.

Anyway, to recap this HUD:

Top: CPU car info

Right: RNG list; If it's not inside the cycle, a new list is shown

Game HUD, left side:

Game HUD, left of tachometer: Info about curves. Needs analysis.
Game HUD, below tachometer: Left/right position and sub-position; Steering power
Game HUD, right of tachometer: Car bounce speed and subpixel
Game HUD, below speedometer: Speed and sub-speed
Game HUD, below progress meter: Distance traveled, distance lost, distance left

The last number on the right side is the course ID. And the extending line between HUD and road display is a visual representation of how much of the current course is done.

This is my shorter input entry. Not my style. I prefer a faster ending.

The input file may be 382 frames shorter, but it takes 152 more frames to reach the ending.

Now, this is to avoid anyone silly enough to trim frames off my actual submission and spark some sort of heated debate. I trimmed it off first, now don't go taking it.

Can't let my work finding out a few memory addresses go to waste.

This script attempts to identify where the objects are going to land, what's currently filling the slots, and the up-to-date player positions. For whatever reason, I've also identified P1 and cooperative scores. Of unusual note, "clear" and nil are used, as nil in FCEUX's gui.box fill just happens to select out a translucent shade that looks perfect for what I need. An accident gone right.

An FCEUX script, which I find its emulation isn't enough for Krazy Kreatures. Nuts, I say. Still, translating a script to BizHawk is probably easier than rediscovering the memory addresses from scratch.

Break time! How high can I score in Klux? Watch as I make use of an unusual scoring trick where I rapidly drop and pick up a piece during the end tally!

It has come to my attention that FCEUX does not properly emulate this game. In the main mode, the animations of animals, things, people, and monsters aren't emulated. However, BizHawk does emulate it just fine, so if I want to mess around more, I will make use of BizHawk in the future.

By the way, as .fm2, this is an FCEUX file. I dodge the animation failure by picking a mode that has no animations to begin with.

I chose to get to the ending as fast as I know how, rather than ending input early. I will be sure to produce an 'end input early' movie to avoid someone being silly with "I beat you faster by trimming off the end frames."

This should beat Saturn's run by a pretty fair margin. If I choose to submit this run, I'll be sure to fill it with subtitles first.

Rerecords:

Note that this file has a bunch of rerecords added, since I messed up somewhere and didn't keep the original .fm3 intact, so I used what I had stored in an .fm2 to restore this movie. As a result, the rerecords of my second attempt on course 1 is added to this file.

Rerecords: 1319+1169 for course 1, 2018+1423 for course 2 so far.

Course 2 isn't complete, since I got frustrated with traffic. While I did beat my previous course 1 time by over three seconds, it turns out the game is not as sync stable as I hoped -- Keeping the rest of the run intact, it desyncs halfway through course 4. Memory search does not turn up any different addresses other than score and X sub-position of lane-changing cars. Either it's something silly like the timing of the Program Counter or lane changing cars are my worst enemy.

Anyway, I may continue on this. For now, I at least have a complete run somewhere.

Aims for maximum score in course 1; Doesn't give a snap about real time, however.

This is a demonstration of the pause trick for stopping timers. The time remaining never declines, so I can do silly things like never bother to turn and crash all the time. Since the entire traffic of course 1 uses non-zero timers, you never see them, but some would show up in course 2 had I continued.

This is primarily why I chose to pick fastest real time rather than high score, since the pause trick messes with traffic, and banning it means a less optimal traffic layout.