I've started messing around with the game more and am getting a better grip on some mechanics and on reading the script. One question though: what are the values on the upper right of the radar? They're the one thing I don't exactly know atm.
EDIT: Also it appears that the speed value in the script seems to bug out when you do a rocket start. Not sure exactly why. Maybe it's a case of reading too many bytes for that specific variable.
EDIT2: I was right. Made a minor change to the script to fix:
http://tasvideos.org/userfiles/info/39586042232192577
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
I'm not entirely certain about the five numbers myself, other than they're probably related to the machines currently loaded. The game allows up to 5 machines (player occupies one of them), and they are colored to match the plus signs on the radar. I've selected those numbers to see if they're a good enough indication to tell if the machines are loaded.
Haven't yet put in the time to analyze those machines, though. Mines are the ones you want to identify quickly, so I'll make my focus there.
I have done a sync test, by getting a copy of your verification's first track and running it again after winning Pawn Expert. The copy worked flawlessly. This indicates a possibility that you can just work on later tracks and expect a sync after improving an earlier one. Just a possibility, though.
Yep, I was reading too many bytes for the speed. Sorry about that.
Thanks for the info on the machine numbers and on the sync test! I had a feeling that it would be hex friendly given everything else but good to see confirmation on it.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Thanks for all your work on stats and on making the lua script so far. By the way would you have any interest in working on Grand Prix Legends and Climax as well? I would like to take a look at them once I finish with this game but any help would be appreciated there as well.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Okay, more stuff in script. Ghost recording for radars. The recorder has zero intelligence, and is generally there so you can more easily compare stuff you did not too long ago. Since I already have the framework, it wasn't hard to add in.
Oh, and a frame timer letting you know how long until you land, at the longest.
As for more scripting on other GBA F-Zero game, I will give no guarantee. If I do, consider it a bonus. I have memories of this game, but not the others.
Fair enough. Was mainly curious because they run on a similar engine and have much of the same techniques.
EDIT: A little confused about the ghost recording and how it works. Can you explain how to have a ghost play?
EDIT2: Also how compatible is it with TAStudio? I saw you mention it not working with pausing or something. Now that I think about it, using it with TAStudio might be a little redundant given branches but maybe the real time players will find it useful.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
I was looking at the Icarus Circuit TAS posted on fzerocentral (the top B4 JKT TAS here) and asked in the FZero discord about the initial bump after the rocket start:
MemoryTAS - Today at 1:57 PM
I'm so confused at what the Icarus Circuit TAS even does to get the initial bump after the rocket start
Wish I had access to their movie file (.vbm)(edited)
MemoryTAS - Today at 2:05 PM
I can't tell if it's something track specific or what
Is it even possible to still get in contact with the person who made it?
Yazzo - Today at 2:16 PM
JKT made that tas, but i haven't seen him in years. TBK though who also made tases is still around though, but haven't seen him here in a while
the key to getting those bumps is to "remove" the CPU check-mark behind you
MemoryTAS - Today at 2:17 PM
I see
Yazzo - Today at 2:17 PM
i assume it means one cpu is overtaking another
and thus having more speed which gives you the bump
MemoryTAS - Today at 2:19 PM
thanks
Could you potentially add detection related to this to the script?
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
The ghost recording is a script thing that marks positions of the player while the red REC is visible. Turn this red REC off by holding M and frame advancing exactly once. Turn it back on by doing that again. With it on, the ghost will always be reported with the player, but with it off, the script will stop updating its internals and show what it has.
Basically, have REC on, run some movie you've done, turn REC off, then try to TAS some improvements. The radar will report your old positions with the X.
So, that whole "wallhit" thing where CPU seems to catch up faster... Trying to define what parameters I'm looking for. I can experiment a bit until I get a new effect, then do some searches, but I'll see what I can find.
I guess what I might be asking for is some way to tell what further distanced CPUs are doing.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
.bk2 I was messing with. Mostly what I want to ask is if this is the type of hit you want. One where we leave the collision with a high speed. The start itself isn't what I'm asking, but the part where we collide. Haven't seen any obvious speed changes on the Training CPU itself, however.
It also briefly attempts some speed limiting in the following curves, to prevent that hysteresis from kicking in. Something else I experimented with when it caught my attention.
Oh I wasn't talking about the strength of the hit. I think you got confused about which TAS I was referring to. I was talking about the Icarus Circuit TAS Bishop 4. The file was "b4_jkt_14459fun.mp4" I was confused as to how they got a CPU to appear without seeming to slow down at all in the opening.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
So, basically spawning a CPU car really close behind the player, going fast enough to push us. And the movie does so repeatedly.
There should be enough in the script to tell when this happens, by the fact there is a + where there was emptiness just a frame ago, and if that happened outside radar view, a major change in the segment watch. As for predicting or manipulating it in advance, I don't have any particular inspiration to follow to script that. I'm pretty sure it's a chain of spawns in the opening, though it is hard to tell from the video alone.
EDIT: Now that I think about it, I can script up something similar to the ghost recorder, tracking every position other than the player, and giving an alert if there were any changes since the last time you got back to that frame. It still wouldn't predict, but it will notice even 1/256 pixel difference in behavior. If CPU drives different at all from player interaction outside of collisions, it might be useful to get this detection.
One more update to the script, and now it'll alert of any changes in CPU behavior, by recording what happened on that frame, and when you rewind back to before that frame and do different stuff, if they did different stuff. The ghost recording in the script is also changed a bit.
Not been wanting to analyze much since my last post, so I'm giving script stuff to help that analysis instead.
Pawn Master, first lap in 24"21. This high precision took a while to get.
Been trying out my script to get an idea of what is working right. The detection I'm using for determining whether machines have changed positions has a steep learning curve to understand what it's doing. The other parts that are working seem to help me make decisions on whether it's a good idea to take another bump.
Anyway, I don't have plans on TASing this myself. I still want to give support, though.
Hey there, had a quick look at that lap. Looks quite smooth already. A solid start utilizing what we call the "jimmy bump" there instead of that random mess from that B4 video you were were discussing earlier. I'm not sure how JKT did that but it certainly ruins the aesthetics of those opening seconds (even if it's faster). I know TAS is about going as fast as possible but this doesn't look like fun to figure out.. maybe you will though ;)
Anyway, back to your lap: the transition between drifts around the 4-5 second mark seems a bit abrupt. It looks unusual to me as a console player but I see you were going for big drifts which is always a good thing in this game! I really like how you drifted into the narrow path between rail and that first mud patch and then straightened out the JV, looked perfect. You can get another 600+ bump between the motion plates, you're extending your drift there which won't let the machines behind you catch up. Bascially you're too fast for your own good. Another one of those big bumps there and the lap can end up around mid 23".
Memory, I dropped you a lengthy PM on FZC (in case you are TheMG there)
Nice to see a console speedrunner taking a look here and checking our progress. I'm guessing you tried my scripts to see what information I've been trying to expose.
4-5 seconds in, I was drifting right the whole time. The momentary turn to the right was to nudge my momentum into avoiding slamming into the wall, and the rightward drift was to keep enough distance from said wall.
There probably is an extra bump I could take. Just that I didn't see any obviously good bumps I could take while deep in TASing. I didn't like the feeling of slowing down too much, yet that's probably what we need to do for one more good bump. That one bump just before the jump has an ideal CPU placement, one where it is very obvious the gain outweighs the minuscule cost, but I just didn't like the larger sorts of cost later.
Good to get a praise, at least. Obviously, as a TAS, this won't impinge on the unassisted WR, but it does give indication how close you guys are to the limit. Once Memory comes back, I hope to see my opener beaten.
I want to talk about drifts a bit, though you probably already know all about it, except maybe the exact numbers behind it. The drifts apply a constant speed to the left or right of whatever direction you're facing, which can add to or subtract from your momentum, depending on where your momentum is relative to facing. Jet Vermillion has the highest drift speed of 128 km/h, probably part of the reason it clears tracks so fast, yet it also has the worst momentum-facing allowance of 45 degrees. So let's have our JV speeding along at 595 km/h, and we're also drifting at this allowance. Our true speed is more like 691 km/h in this situation. If we could go the full 90 degrees, it would be 723 km/h.
Let's just not snake on a straightaway, and get to our normal maximum rather than boosted maximum. Call 455 km/h our normal speed, and since we're not snaking, our 128 km/h drift is 90 degrees from our momentum. Our true speed is about 472 km/h. If we're 45 degrees, it just about 553 instead. Even if, snaking to the 45 degrees amount, we're 20 degrees away from where we need to actually go (our momentum is constantly trying to match our facing, causing arcs instead of straight lines, except in some circumstances involving wall hits, but that applies extra friction), that's still 519 km/h in the direction we want. Snaking looks effective at these quick numbers, and it clearly showed in practice.
But you already know the power of drifting. This might still be an interesting read, getting details from someone who looked deeper into the game, I hope.
On the scripting side, I was thinking about that track image underlay. 4096x4096 image, except cropped and rescaled to fit the window, centered on where you're at. That is a bit beyond what I am willing to do at the moment.
I'll be working on more sophisticated position tracking functions, including having it persist between selecting a different movie (selecting a movie triggers core reboot. Core reboot will also reset the whole lua VM. This reset kills all lua variables I set up. Therefore I must use file I/O to have anything persist, such as old player positions from the movie you're trying to compare). The recording is for the sake of the script, not the movie files produced by BizHawk, so that comparisons of an older run are more convenient.
Hi, this is BPA from F-Zero Central - thank you TBK for the heads up on this thread. I haven't had a chance to see the videos posted yet, but I'm happy to see this project is happening. Memory and FatRatKnight, would it be okay to PM you? I have questions :)
Regarding the TAS on B4 that JKT made: I have a memory of him saying the rapid CPU bumps were a result of a cheat code he left on.
I'm fine with PMs, though I generally prefer the questions get publicly asked, but I won't hold you to it. Ask away, through whatever method you want.
Rapid bumps from a cheat? Well, that would explain that. At least we'll have a good excuse if we later can't replicate it.
4-5 seconds in, I was drifting right the whole time. The momentary turn to the right was to nudge my momentum into avoiding slamming into the wall, and the rightward drift was to keep enough distance from said wall.
I think we call these "adjustments". Those happen if we deviate off of our ideal path. It'll come down to ideal driving lines that are paired with optimal drifts. A very short drift to "adjust" tells you there is something wrong, so there needs to be a better setup of drifts so this doesn't happen. But hey, maybe there is a fastest way where such an adjustment drift is part of it.. could always be. But from my exerperience very, very short drifts are just for "damage control" as you kind of described, you had crashed into a wall otherswise. Last word is that this game needs drifts with smooth transitions into the others, and everyone one of them should be part of gaining time.
Ideal lining/drifting in this game is also a topic for itself I believe but it might fade more into the background if this really turns out to be more about GP than TR.
FatRatKnight wrote:
I want to talk about drifts a bit, though you probably already know all about it, except maybe the exact numbers behind it. The drifts apply a constant speed to the left or right of whatever direction you're facing, which can add to or subtract from your momentum, depending on where your momentum is relative to facing. Jet Vermillion has the highest drift speed of 128 km/h, probably part of the reason it clears tracks so fast, yet it also has the worst momentum-facing allowance of 45 degrees. So let's have our JV speeding along at 595 km/h, and we're also drifting at this allowance. Our true speed is more like 691 km/h in this situation. If we could go the full 90 degrees, it would be 723 km/h.
Let's just not snake on a straightaway, and get to our normal maximum rather than boosted maximum. Call 455 km/h our normal speed, and since we're not snaking, our 128 km/h drift is 90 degrees from our momentum. Our true speed is about 472 km/h. If we're 45 degrees, it just about 553 instead. Even if, snaking to the 45 degrees amount, we're 20 degrees away from where we need to actually go (our momentum is constantly trying to match our facing, causing arcs instead of straight lines, except in some circumstances involving wall hits, but that applies extra friction), that's still 519 km/h in the direction we want. Snaking looks effective at these quick numbers, and it clearly showed in practice.
more can be found here: https://www.nintendo.co.jp/n08/afzj/champ/hikken/index.html
Hehe, we know a lot about drifts for sure but not from this technical side you're showing. I've been aware of that 128 speed addition during a JDT (where the machine is positioned sideways, which is that 90° I suppose) and only under that circumstance can it reach the highest speed possible? and the lower that angle the less the JV can make use of it's drift speed? Too bad 90° can't be reached through normal driving, only certain instances allow it to get close to it, and also completely to it. JDT is the only trick that can make it go 90° sideways but it doesn't last long as the speed drop is immense. 2nd next thing might be some skewed mine hits where it goes to 70°-80° (total estimate.. lol) and then there are some jumps that both involve JDT-like moves beforehand that also leave the machine somewhat sidways in midair (almost no speedloss during those extreme angles even with JV! was an interesting fact when I figured it out). JV otherwise loses a lot of speed at such angles through allowance friction.
Edit: applied some of FatRatKnight's terminology
Also:
BPAFZMK wrote:
Regarding the TAS on B4 that JKT made: I have a memory of him saying the rapid CPU bumps were a result of a cheat code he left on.
Actually the same thought came into my head while I tried remembering what was up with that, that's probably also the reason he didn't release it officially I think and called it "fun". The opener in it is about 1 second faster but most likely cheated then. Good to have this bs off the table then!
Momentum-facing allowance. If you attempt to turn beyond that point, the steering fails for that frame, acceleration does not apply, and some extra friction is added. You can go beyond this allowance through methods other than steering, and it'll cause a similar slowdown. Note that The Stingray's allowance is above 90 degrees, but turning beyond 90 degrees will still cause a loss in speed despite staying within allowance.
I have also noted the coasting friction (not holding the accelerator) and allowance friction (turning too sharp) are disabled while in the air. The "boost maintenance" friction still applies, if you're above your speed limit.
... Now I'm trying to count all possible frictions. Braking, coasting, turning allowance, boost maintenance, rail, dirt...
On a side note, there are a few machines that can go 90 degrees, notably Wind Walker (90 exact) and The Stingray (112.5), but Hot Violet also has 90 degrees allowance. It's just much, much harder to get to that 90 degrees with Hot Violet due to the non-Blast Turn balance shifting momentum so fast.
Our focus here will most likely be primarily on GP. Not sure about plans on the Championship circuit, though.
Sorry I've disappeared for a while. I got busy and distracted with other things. Feel free to pm me or whatever. Also good to know why I was having such trouble getting similar results to the Icarus Circuit TAS.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Okay, more ghosty stuff with the script.
This time I'm displaying recorded history of all machines. And thanks to saving straight to a text file, it is capable of letting you run a movie, then running a different one to compare. It will always save on script exit if possible, but if the script errors out because of some mistake on my part, it won't save.
I am sort of hoping the script turns out to be useful stuff. I'd advise keeping the script on record mode if you're moving on to some parts of the run you haven't done yet, so the script will constantly update trails. If you're going back to retry something, make sure your best is done in record mode, then shut off the record mode and go back for changes.
Alright, I'm now feeling as though the script is less basic and more sophisticated. Hope the trails are pretty enough.
EDIT: 23"65
Wanted to see TBK's advice in action. Sorry, it's nowhere near the 600 speed, but 563 km/h ain't bad.
I'm starting to wonder if I should track down the collision detection, and display that on the script. I suspect distance calcs, checking if you're too close to someone, and if so, just how much overlap there is. Possibly hit-circles or something.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
I've poked about in RAM Search for a bit, and there's only a pair of memory locations I find remotely sensible:
EWRAM:12D60[Size=0xCC][Count=5] Machine data
+9E,1u - Which split did you take on the track?
+A2,1u - Lap segment
I have managed to get a pair of situations between two states that...
* My x,y coordinate is identical
* My facing is identical
* Speed and momentum are also identical
* I got to this location in the same amount of frames
Yet, collide into the wall, we fly off into a different direction.
I checked for different EWRAM values. Throughout the entirety of EWRAM, two bytes are located in the input history block I identified earlier (A2C0, A2C1), one is part of the rather short player trail (12D81), and one I just identified as which split you took (12DFE). Only those four bytes are any different, and I highly doubt the former three have anything to do with it.
After some careful searching in IWRAM, I ended up empty. Zero results. My search has found only one relevant byte that's different throughout the entirety of RAM.
So my theory is this: Depending on what segment you're in, and which split the game thinks you're in, hitting a wall will adjust your momentum to go toward some magical spot. The game does a pretty good job at updating what segment you're in. It appears less vigilant in updating what split you're in.
I was running my scripts and ramming the Jet Vermillion alongside a wall, and saw that my momentum after these rapid wall hits were getting steeper and steeper angles, until suddenly after some point it's all gentle again. Making a guess, there's some magic pixel the game wants you to go toward, and will change your momentum to go directly there after a wall hit. Once I spotted my segment address changed, that was when the angle got all gentle all of a sudden.
The consequence of an incorrect split means that the magic pixel is on that split over there, so your momentum goes toward that. Even if it means shoving your machine through the wall to get there.
I have noted this split value doesn't update when taking damage on the rail. While parts of the track default to putting you into split 0 where there are no splits taking place, this won't update on a rail. Whether there are any spots that have an erroneous split 1 destination is uncertain.
Anyway, it is an interesting little bug. Whether it'll have any helpful conditions is another matter.
