Replay logging

[Duplode]

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.

(OFF: I ran 32-bit Linux until about a month ago, first out of ignorance when I was a Linux newbie, and then due to laziness to do a full reinstall  )

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.

At least that means anyone with DOSBox can run it regardless of the host OS 

Once we've got a clearer view of the gamestate content, and I don't think that will take Duplode long,

I will do my best 

[dreadnaut]

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

Er... Windows 7? And it dumps bin files alright, if you ignore the video driver complaining.

Changing the target platform would be nice, but we'll need to test it properly and make sure that no bugs depend on some architecture "feature" or limit. Can't lose those bugs I misread :-p

I noticed the "abnormal termination" so I guessed the fast "error" way out of the program loop, but with the speed at which you produced the tool, it's just fair!

[Duplode]

As Stunts Cartography advances, I am slowly returning to the original task we set up in this thread. Here is a rough roadmap of what to expect:

• Now that there is a map annotation system, the next step is adding lap traces a fourth kind of annotation, with an option to overlay cars over the trace. With that done, creation of animation frames, like the ones I used to make the Z70 video, will be at an arm's length - all that it will take is adapting the animation code I wrote in February to fit the rest of the program and changing the drawing engine so that it doesn't redraw the full map if the track has not changed (so that rendering the frames doesn't take half an hour).
• That is half of the task - the other half being generating the traces with repldump (i.e. dstien's tool, published a few posts above). For that, I plan another program (probably separated from the Cartography viewer) which extracts the coordinates and angles from the raw output of repldump and writes them into a sensible format, which will then be read by Cartography.
• Finally, there is the issue of making repldump reasonably easy to use. I believe our best bet is running DOSBox with a dosbox.conf set on autorun to execute repldump with a specially-named replay, coupled to something like a .BAT (or bash) script which makes it work by copying files to the right places. Wiring it all should allow for generating the trace coordinates in a single step; than it would be just a question of loading them into Cartography and following your heart's desires.

[Chulk]

We should have a live race again so we can use this to check results (besides, I miss those meetings and races)

[Duplode]

We should have a live race again so we can use this to check results

Excellent excuse  That Silverstone track is still waiting!

[Duplode]

I have uploaded the code I am using to process repldump output to this repository. The coordinate extraction program is likely to be incorporated by Stunts Cartography once it stabilizes. If you have the Haskell platform (and the Chart-cairo dependency mentioned in the readme) you can easily make exploratory plots of game state data. For instance, the following GHCi session...

Code Select Expand


Prelude> :l Plots.hs
*Plots> foo <- parseFile "070ZGUT.BIN"
*Plots> writePlot frame [fst3 . pos1 . player, snd3 . pos1 . player, thd3 . pos1 . player] foo


...will read the 070ZGUT.BIN repldump output file and write a chart with the three player position coordinates plotted against the replay frame number to test.png.