Replay logging

[zaqrack]

DAMN YOU CHINA for blocking youtube AND my VPN.
I hope I can check the video soon.

[zaqrack]

DAMN YOU CHINA for blocking youtube AND my VPN.
I hope I can check the video soon.

some DNS hacking helped AWESOME work!!!

[CTG]

DAMN YOU CHINA

Beware, Zak McKracken, the Chinese CIA (how do they call it anyway?) is watching you!

It's the MicroMachines version of Gutix' ZCT 70 replay.

[dreadnaut]

Dumping Stunts' memory with dosbox's debugger, I seem to find the gear/surface string at 0000:37684 consistently, which would place the player vector at 375C6.

Could it be easier to dump data inside dosbox?

[Duplode]

Could it be easier to dump data inside dosbox?

It probably is if you, unlike me, know how to operate a DOS debugger properly  The problem with DOSBox's debugger is that there seems to be no way to dump a running log of a location in memory while the game plays. I imagine that a more sophisticated debugger should be able to do that, though for me it was quicker to use the scanmem hack given the aforementioned ignorance. (And please do tell us if you know a better tool, or how to make one!)

Dumping Stunts' memory with dosbox's debugger, I seem to find the gear/surface string at 0000:37684 consistently.

Indeed; that kind of shows up in scanmem too - in my tests the final three digits of the 64-bit address I get with it appear to be always 694 due to, I believe, contingent facts about how DOSBox allocates memory.

[dreadnaut]

It probably is if you, unlike me, know how to operate a DOS debugger properly 

So far from reality, I've never used it before! It took me half an hour to get a dump of the memory and just as much to find the saved file!

I was thinking more of a dos TSR program, dumping the contents of the correct memory location to disk. However, I don't have much experience in writing those either. At that point, it might be easier to modify dosbox and add the feature.*

* quick look at the code: no, it's probably not

[dstien]

Now that's just awfully awesome!

I tried another approach at dumping the data, and ended up with a restunts based tool. It's in the repo as repldump. It basically initializes the game engine with a replay, steps through each frame, performs update_gamestate(), and dumps the entire 1120 byte gamestate structure to a file for every iteration.



Usage
Put the attached repldump.exe in your Stunts folder and run repldump.exe replname in a 16-bit DOS environment, such as DOSBox. The replay must be located in the same folder, and the file extension must not be included in the command. The program will then read replname.rpl and write replname.bin. The result file has the following format:

Code: [Select]

uint16 numFrames;
uint8 gamestate[numFrames][1120];

I also attached an example C program for parsing this file. Take the struct declarations with a grain of salt. I suspect that some of the field names are at best misleading. But all in all this info should enable us to compute penalty time, detect DNF, provide analysis, and maybe find the cause of some bizarre bugs.

[Duplode]

Whoa!

The post above is the most important in this thread by far. For those of you not familiar with the restunts technical context: the innocent-looking tools attached to it aren't just a way to extract the coordinates in two simple steps, getting rid of all the annoying hacks I had been using. Rather, what you can see above is, for the first time ever, the game engine being used to run a replay outside of Stunts. Dstien hinted at some of the possibilities that opens above and elsewhere. In particular, earlier I said "The tools described above likely won't be convenient to use for a while". Now that "while" might get significantly shorter

Three cheers for Dstien! Next to him, I'm just a pipsqueak. 

[zaqrack]

we live in exciting times! 

[CTG]

The day of my real retirement is getting closer and closer.

[Friker]

... the game engine being used to run a replay outside of Stunts ...

I just didn't want to tell it loud.

Ok, this means some simulating can be applied...

[dreadnaut]

Brilliant job dstien!

First feature requests then   Dump only the last state of the simulation, and maybe dump to stdout so I can pipe it into other programs.

I'd also like to point out how great this thread is, how it started simple and to the point

Is there a possibility to make an automatic statistic program? Only with reading the replay?

how it was there all along

How much code from restunts is reusable? Could the replay engine (i.e., the fast forward button) be used to run replays?

and how high it soared in less than a week!


edit: also, at least on windows the program could run in the standard 16bit environment, without dosbox; the only issue is that it switches to graphics mode. Would it be possible to make it a console program?

[BonzaiJoe]

The day of my real retirement is getting closer and closer.

Unlike other future events?

[CTG]

The day of my real retirement is getting closer and closer.

Unlike other future events?

There's the point.

(retirement is not a necessary one)

[dstien]

First feature requests then   Dump only the last state of the simulation, and maybe dump to stdout so I can pipe it into other programs.

edit: also, at least on windows the program could run in the standard 16bit environment, without dosbox; the only issue is that it switches to graphics mode. Would it be possible to make it a console program?

Do you run a pre-Vista 32-bit OS? Didn't expect it to run natively on any platform released in this century.

The reason why the program acts a little flaky is because I chose to link it to entirely unmodified original Stunts code to ensure there were no possible regressions from our ported code. The main stunts initialization function does a whole lot of stuff besides loading data. Like changing the video mode and hooking up interrupt callbacks. To halt the program after closing the output file handle I just invoke Stunt's fatal_error() function to unwind it all. I plan to add another build target so that we can use repldump with both stock code and our ported code, then we can easily test the restunts code automatically by comparing the output from the two programs. This will also enable us to use a ported init function that sets up only the bare minimum for a properly behaving command line program and implement more features. There's a lot of code that remains to be ported, so the build target will remain 16-bit DOS only for the foreseeable future.

Once we've got a clearer view of the gamestate content, and I don't think that will take Duplode long, we could probably set up a web service that takes care of the processing and parsing so that phpStunts don't need to depend on an x86 hypervisor and little-endian data parsing.