Demo analysis tool

[GoneAway]

I've been working on a tool for analyzing demos. It can print out header details for you, dump the frames in a human readable format, and calculate a bunch of stats. Some of these are simple flags, like checking for sr50 on turns, or turbo. Others are more detailed, like the frequency of different turn values, or the rate of sr50 usage. We've been testing it out a lot in the discord so now it's time to post it here. It currently supports vanilla, boom, and mbf.

 

You'll need ruby installed to run it, as it is just a script.

https://github.com/kraflab/lmp

 

I am going to start working on more sophisticated features to try to detect anomalous runs that might be cheated, but most heuristics currently in the analysis are just indicators; they aren't guarantees.

 

You could also use it to look at your own demos to see what you might be able to work on, since it prints out sr40/50 rates, or just for fun to see how your stats have changed over time.

 

It supports aggregation, so you can even give it a whole bunch of files at once and it will print out the combined stats.

 

If you find any issues or have any feature ideas, let me know.

[Grazza]

Yay, I got it to work, even though half an hour ago I'd never heard of Ruby. I'll check some demos with it and let you know if anything seems off.

[Dingir]

Nice code!  Already tested on some interesting .lmps...  ;)  Hope you will keep improving this!

[Linguica]

Quote

In the future, this could provide some heuristics for detecting cheating, although such things are difficult to be certain about. Right now it detects turbo and sr50 on turns, which are definitive measures.

 

but but but!!

 

 

[Looper]

27 minutes ago, Linguica said:

but but but!!

Is that a confession? 🤨

[GoneAway]

Looks like the tool is messed up on longtics demos right now, so will fix that tonight most likely.

 

Edit: longtics should be fixed, but still need to figure something out with cl-1 demos

Edit2: all working now, turns out the header in mbf has 32 player bytes instead of 4 - thanks vita for debug

Edited February 1, 2019 by kraflab

[Opulent]

Nice.  You are always improving stuff.

I'm sure you already know about JC's DOOM/Boom demo format analyzer and BOOM LMPC; both parse Boom-engine-based demos.

 

Shame it is tied to Ruby; I bet you could port it to Python so it would be self-contained.  Python, Perl, TCL, Ruby, ... they are all pretty similar as parsing languages.

I don't see anything about the demo footer or the emulation....

Might I suggest expanding DF's VIDD tool.  If you aren't familiar, it drew a line based on the coordinate path of the player's movements through time.  One of my tools does this too, but it is just the data, not an overlay like VIDD was.  UberDemoTool_Viewer in Quake-Live is similar.

[GoneAway]

I'm not sure what you mean about not being "self-contained". Afaik you can turn a ruby script into a standalone exe if you want to, is that what you meant? I'm not sure how python would make a difference in this case 😅

 

I've done some graphs of player position / angle as inferred from the demo and it's interesting to look at but since it doesn't account for what actually goes on in the game I didn't pursue it far.

 

Yes, I haven't looked into the footer yet. I also don't have coop support yet (the tool works but it will assume it is one player so the results won't make sense). I will probably work on those next.

[Opulent]

Yes, self-executing.  I didn't know Ruby had that ability.  Certainly any demo analysis is worthless for certain things or certain types of demos.  

If I was one of these expert players who persevere to optimize every motion in a demo, I would probably enjoy seeing the path that a player takes on a speedrun, or to compare two maxdemo routes, etc...

[GoneAway]

Ya, I'm not saying I won't do it eventually, just giving some reasoning behind the prioritization on that front.

 

Btw for anyone using this tool that thinks they have found something fishy: I definitely recommend bringing it up in the discord for discussion instead of opening up a thread / etc. We've done a lot of "debugging" on suspect frame data and have learned a decent amount that explains stuff that looks bad but is actually fine.