Hi there. I've been interested in TASing this game and I thought I was doing pretty good after I had done the first two rounds of the first minigame's trophy, then I saw that video posted above from the japanese guy. Obviously I'm not manipulating the rng nearly enough.
I don't think I have the patience to go to such lengths, trying to manipulate the rng blindly like that so it got me thinking, what if we found certain data within the ram like AI information and where the next ball is going to come out of, etc. A lua script could be made after that to render on the screen this data and it would cut down on the fiddling a whole lot.
I spent about an hour looking for valuable data 2 days ago but I was unfortunately unsuccessful in all of my searches. I'm gonna try again tonight and hopefully find something
edit1:
So tonight was a productive night. First, here is the result of my researches
http://pastebin.com/a1HA1Y7A. I was able to find some interesting information from the ball managing system as you can see, as well as addresses from the first ball slot (which are not in this research document, I added them in a watch and was too lazy to update the document)
There are some cool things I found. First, where the next ball will spawn is determined the very frame a ball is scored. This frame can be determined by finding the addresses for the score of the players (not the rendered score! the actual score in memory) and find the frame it decrements. At that frame, a value is set at the address 0C1F16 which turns out to actually be equal to the side of the player that was scored, and does not actually tell us which corner the next ball will spawn but which side's corner it will spawn (so 2 options)
The next frame, the ball is created in memory at its spawn corner so this address isn't that useful in the end if we draw the balls on a TAS minimap.
However, this is where things start getting kind of sketchy: At first it seemed that the first ball slot is always positioned at the same offset in memory. Once I had that, I started looking for the second ball and when I found it, calculated the offset between the two (from the X position as the anchor) and I thought I could find the other slots just by offsetting by that many bytes but for some reasons, the resulting addresses did not seem to match with data from the third, fourth, etc. balls on field.
I was able to confirm this by using the ram search and found that the X and Y position of the third ball were curiously shifted a bit below. Furthermore, the addresses I had for the X,Y of the second ball did not correspond to any ball later on in the game, and neither did the addresses of the first ball.
So the ball structs seem to get shifted around and it doesn't seem like they follow each other in memory either. So I hit a wall as of now and I'm still trying to think of an idea. I tried to search for pointer references to these structs in memory but couldn't find anything.
Here is a picture of the TAS minimap as of now
http://i.imgur.com/w2YZBzc.png (don't mind my messy watches)
edit2:
Today was a productive day! I studied a bit of assembly for the first time (with MIPS instruction set of course, the one used by the playstation) and learned how to use the r3000 debugger that comes with pSX 1.3. From there, I reverse engineered my way into finding where the struct for a ball begins. It turns out that it begins 32 bytes before the X value is defined; In other words, 4 dwords earlier. (pun unintended!!) Using that knowledge, I was able to find that the address 0x05A978 contains a pointer to the latest ball spawned on the field. I tweaked my lua script to take that in account and this is the result
A minimap that shows the field and balls
From there, I can start programming the projected path a ball will take and then perhaps reverse engineer the enemy AI and find addresses describing future movements, but this is obviously much easier said than done.
That is the fastest I got gives me Brio and Rilla Roo with the RNG.
The question is, slow & fast character or slow & slow character.
Also, should it be brio and not coco. Coco is the faster moving character (same speed as Crash) and if input to move up needs to be added then Rilla Roo become Dingodile.
Thoughts.
Yes, I know speedrunnners use the more brute characters in their runs.
Edit: Waiting Times
0 Frames Brio and Rilla Roo
2 Frames Cortex and Coco
9 Frames Rilla and Coco
11 Frames Brio and Cortex
Frames:
0 - N.Brio
2 - Coco
4 - Cortex
6 - Rilla Roo
8 - Coco (then loops)
With delay during the select screen it's the same still.
6 frames is better to lose than changing characters as it wastes more time.
But doing something prior to hitting X changes the order. (I Placed 2 frames of Up and got Cortex)
Edit: Adding 4 Extra frames of input on first menu gets Rilla Roo.
The 4 extra frames are the arrows at the very beginning (before the first X)
Link to video
