[Tool] TSR File Analyzer and Replayer

[Mike Nike]

but if you could somehow find a way to play a video without the graphical part, it should be possible to generate some output file from a video in a matter of seconds.

well, if the client version of tsr files have so many position updates like i get from the output.txt in -d 3 mode, that would be great.

replaying the video in an own replayer with reduced gfx is possible, of course. that would allow creating an online based replayer with a somewhat okayish framerate. i also thought about the possibility to catch the sent packages you get from the clients as server over the open ports. that way we could actually create a way to have a good framerate for a livestream.
if there have been any livestreams so far, in TS, i guess the framerate was slow due to the whole screens pixels had to be sent, right?

or do you mean, that you want to replay an alternative tsr format with the TS replayer ingame? but i wonder how you wanna do that without gfx..so you probably didnt mean that..

[Tijny]

well, im on my way...
eh, first 6 bytes of msgtype 500: in my tsr i have 7 184 0 0 0 29
2nd byte=184 -> 1.84 version of ts? but the others?
and byte 13-16: 0 0 1 238 -> some code for clocktime? 21.45oclock it should be

Actually, sorry... 0 0 1 238 is the length of the next message, the message type is included in the length.

"7 184" (or 0x7B8) is a magic number that means it's a server video, "7 213" (0x7D5) would be a client one. "0 0 0 29" is a primitive version number, that has nothing to do with the normal version numbering. After this comes the year (2 bytes), month (2 bytes) and day (2 bytes).

or do you mean, that you want to replay an alternative tsr format with the TS replayer ingame? but i wonder how you wanna do that without gfx..so you probably didnt mean that..

The plan was to modify the TS executable so that I could generate an output file containing all positions from a .tsr video with the click of a button, without having to watch the whole video. This would be fast, because the graphics rendering takes up most of the processing power. But as I said, I'm not sure if this is at all feasible to do.

[Mike Nike]

well, modifying the TS executeable might be a nice add, but not necessarily necessary.
though people downloading the modified version could easier work with videos and wouldnt need to download a seperate tool in addition.
and the navigation to the video wouldnt need to be implemented by a tool. i guess the button would be in the video you are currently replaying?

but the navigationcode is not that hard, depending on the libraries the coding language has.
in my case, i might actually might have to do some work with blitzbasic, but i dont mind.

so far i can only import files in the TSR-Replayer.exe folder.
my next step would be to select a tsr's name in a filepath.

but very cool would be the 3rd step:
- selecting a ts folder (or autodetecting all ones)
- autoreading all important "header"-values from each tsr file in them (thumbnailing track images might take too much time, but that would be possible as well)
- filter the searchresult by mod, trackhash/name, nr of players, nr of driven laprecords would take too much time (but this could be an additional major method to autocut all laprecords xD), tracksizes, carselections, laps driven, length of video or something similar ...

a lot of autocut a whole bunch of videos could be done there, including a really fast way to go through all pb goals done in any video.
eventually clicking a "scene" and autorating it, maybe with an additional selection of "scenetype" in a dropdown (which is default set to the most likely selection in most cases i think)

in any case, i would personally bet on the following at the moment:

A) Ande might not publish the code (opensource it) so soon to make it worth waiting
B) Ande is not implementing all the replayer function we might want to have to make it worth waiting

although in some parts i am actually demotivated and skipped developing stuff because i hoped/feared there will be certain updates which make my developments kinda useless



edit:

i had a deeper look into my reduced output.txt..
from 5mb to 1.3mb by winrar and 1.0mb with 7z..while after crunching the numbers i come to around 0.5-1.5mb using selfwritten compression.
compared to a 0.08mb tsr file that still sucks a lot...and i rly hope we can easily extract positions from tsr files (without the need to write it into a seperate output file, since loading it in variables in the tool is enough; i doubt loading a tsr file would take much longer than extracting a reduced output. but oh well, for some purposes it can come in handy to have a little less loading time while needing higher disc usage)


edit2:
seems like the "collision avoidance" lines are by far not matching the real amount of collisions and are kinda useless for statistics. sometimes car/car car/ball collisions are counted, sometimes not. car/wall ball/wall collisions arent even counted at all, if i saw it right..

so, i might have to go the hard way and write some functions to determine who collides who.
way too tough is gonna detect if someone "blocked" another car, but dunno yet. some blocktypes are holding back with the a**, some are like in soccer, arm to arm, some are sidepushes..
partly its tough to find out who is the blocker and who gets blocked.

[Tijny]

After some fiddling I am now able to run a TSR video in a modified TS executable with the graphical environment stripped away, and the game produced 500MB worth of -debug 3 data in a matter of seconds. This means the proof of concept works, but the more difficult part will be to inject my own code that will log the data in a more hard-disk friendly (and performance-friendly) way. As for how big these output files are going to be, I'm afraid you cannot really go below 1 kByte/player/second if you want to store all positions without losing precision.

[Mike Nike]

hmm?

there are max 50 ticks/second, right?

so 20 Byte for position handling/player/frame, right?

for just positions (including angle) you got something around:
X=1..4000
Y=1..4000
Rotation=0..255

so, 12+12+8 =32 bits=4 bytes if you wrap it together.
but even if not, you still can easily go for 3 ints = 12 bytes

for my compression i am working with deltaPositions and deltaDeltaRotations with a look on the most frequently bit-ranges of those deltas.
so i get some kinda 4-16 bits for deltaX and deltaY, average-ing in around 5 bits, probably.
while for the deltaDeltaRotation i just need around +-1.5 bits in average, as far as i could see.
though with certain formulas there can be saved a lot more, i.e. for the rotation when circling, there can easily be steady structure in the deltaDeltaRotation (example 0 1 1 0 1 1..). with the deltaPositions a certain x=m*y function is often visible in longer lines, so you can basicly just go ahead and declare functionStart and End Positions and just save the offsets of the line the car takes, which are only a few times off the expected line.

and in the end, if youd have the game code and could calculate the nextFramePosition, you just need to save the intFrame and offsets bit-array in the inputkeys, which should save the most space, i think..
disadvantage though, if you want to jump into a video, you cant rly jump right into the middle of it, since you need to load the positionvariables first by calculating them.
while with a higher disk space usage you could openfile and go to the offset and pre-thumbnail the middle of a video or whatever % your progressbar has, you are previewing a video at the moment.

[Tijny]

That's why I said "without losing precision" - which you do when you store positions as integers. Although, 2 bytes per axis should provide more than enough precision in the vast majority of use-cases, giving an epsilon of approximately 1/16 units... that's actually not bad at all. I also intended to store speed, heading and z-position at first, but that's probably not necessary either.

[power79]

if you need to know something specific, just ask, but I hope to have helped you on your way at least.

I am bit amateur with this so I run into problems right away.

For test purposes I tried quickly to make algorithm that goes through the file. Everything goes fine until it reads message type 9(race state update?). Message length is 60 so i read 56 bytes after message type bytes. But after that is byte 40. In one recording there was bytes 40 96 and after that started new message type 9. In other file there were more bytes after 40 until next message length.

How I'm supposed to know when the next 4 bytes are length of the next message and when they are something else? What is that byte 40 and how I know when next message starts after it?

Also do you know where are the fuel and damage settings located in the file? Is it possibly in those 12 "unknown" bytes?

Thank you.

[Tijny]

if you need to know something specific, just ask, but I hope to have helped you on your way at least.

I am bit amateur with this so I run into problems right away.

For test purposes I tried quickly to make algorithm that goes through the file. Everything goes fine until it reads message type 9(race state update?). Message length is 60 so i read 56 bytes after message type bytes. But after that is byte 40. In one recording there was bytes 40 96 and after that started new message type 9. In other file there were more bytes after 40 until next message length.

How I'm supposed to know when the next 4 bytes are length of the next message and when they are something else? What is that byte 40 and how I know when next message starts after it?

Also do you know where are the fuel and damage settings located in the file? Is it possibly in those 12 "unknown" bytes?

Thank you.

Well, my explanation was incomplete, apologies for that.

If the first byte of a 'length' sequence is non-zero, it signifies either a short time message or a short control message (this was in my original post). The length of a message like that is always 2 bytes, that's what I forgot to mention.

If you also want to know about these short messages in detail, read on:

A control message is identified by a non-zero most significant bit (i.e. my_byte & 0x80 != 0, where & is the bitwise AND operator), the 5 least significant bits of the same byte indicate the id of the player whose controls are updated, and the next byte tells you the control states for said player. (I don't know which bit stands for which control.)

A short time message is simpler, the first byte is always 64 (or 0x40 in hex) and the second byte simply says how many frames went without any messages. In other words, it advances the race time by `20 * second_byte` milliseconds.

Hope that helped!

[power79]

Thanks, Tijny! It works now. Next I just need to start "decrypting" those messages...

[power79]

A control message is identified by a non-zero most significant bit (i.e. my_byte & 0x80 != 0, where & is the bitwise AND operator), the 5 least significant bits of the same byte indicate the id of the player whose controls are updated, and the next byte tells you the control states for said player. (I don't know which bit stands for which control.)

Well this was easy to figure out by testing:

Code: Select all

$10 = Fire            0001 0000
$08 = Break           0000 1000
$04 = Accel.          0000 0100
$02 = Right           0000 0010
$01 = Left            0000 0001

There are few message types you haven't mention:
Message types 23 and 40. They appear once in beginning of fuel race (fuel/damage settings?)
Message 24 appears during fuel race (damage/fuel values for drivers?)
Message 8: aborted race?

I don't expect you to give full documentation but if you could give a tip how to crack message structures (like you have done to message type 5)?

Thank you again! And sorry to Mike for hijacking his thread.

[Tijny]

There are few message types you haven't mention:
Message types 23 and 40. They appear once in beginning of fuel race (fuel/damage settings?)
Message 24 appears during fuel race (damage/fuel values for drivers?)
Message 8: aborted race?

I don't expect you to give full documentation but if you could give a tip how to crack message structures (like you have done to message type 5)?

Well, Ande gave me the documentation of message type 5 a long time ago, which made things a whole lot easier. I did crack a few message types by myself though, which was mostly trial and error at the time. For example, I would try different server settings, and see which values changed in the video.

It's also useful to have an idea which byte sequences might represent floating point numbers; TS uses them in race state messages, and also for fuel and damage. Floating point numbers are stored in the raw 32-bit representation according to the IEEE-754 standard, and these can often be recognized by a first byte that approximates 0x40, followed by three "random" bytes.

[power79]

Thank you Tijny for all your help! I have cracked quite a lot info from the different messages (not quite everything). I think I have enough data to make my first TSR tool. I post it here if I manage to finish it.

I did come up few more questions if you don't mind.

1. Message 9 (Race state update) seems to have 2 different angle(radians) values for cars. What is that second angle value?

2. Client videos have different structure for at least fuel and coordinates/angle/speed values(no floating point numbers) compared to server videos. Can you lighten me how those client values should be read?

Here's one correction to documentation you gave earlier:

Well, Ande gave me the documentation of message type 5 a long time ago, which made things a whole lot easier.

int starting_grid: `player_count` bytes

int car_data_length: 4 bytes
int player_count: 4 bytes
car_data = {
int car_hash: 8 bytes
int car_name_length: 4 bytes
int car_name: `car_name_length` bytes
} × `player_count`

Documentation missed that bolded value. At least it is there in files that I have tested. Also "car_name" is a string not an integer but that was just a typo for sure.

[power79]

Ok. Here is first version of my TSR Reader.

It basically just reads tsr file and shows you the drivers and you can select driver and see their laptimes and fuel/damage value after that lap.

You can also select a lap and convert that one to tsr file. You can't convert first lap of the race, I had some problems with it. Maybe later.

Also it doesn't seem to be perfect conversion as there are sometimes small jumps in the video, probably needs more adjustment. Maybe later.

Converted laps also have all players included in video. It would be possible to have only selected player driving but doing that would require more time that I have. Maybe later.

I made it in very lazy programming style so there's not much error checking etc. so don't play with it too much. Of course you should report all crashes so I might get them fixed at some point.

Windows program. No need to install, just unzip and run the exe file.
http://www.kolumbus.fi/arilai79/TSR_Reader.zip

[Whiplash]

Nice. Having separated option "Best Lap to TSR" would be useful.

[Mike Nike]

Awesome work, power!

Bug: i converted a rec from me (video has lap 1, 10, 11 of spinner) -> lap 11, but when i started the replay, it showed lap 1 (freezed frame) with 16777.215c lap.
So, maybe videos cannot be cut, which have been already cut once?
I tried again, this time with lap 10.
Same again, but the lap said: 1006632.960c
Seems accurate wankingsession, almost 280 hours! and the "c" for "chucknorris can drive a c lap in a 1-player-race"

[power79]

File updated:
http://www.kolumbus.fi/arilai79/TSR_Reader.zip

Now the extra jumping of videos should be fixed. It was a small timestamp bug. Also now you can convert first lap of race too.

So, maybe videos cannot be cut, which have been already cut once?

Yeah. Cut videos have multiple video begin and end tags. They are kind of just many videos copied together. My program can only handle one video at the time. I need to think how I could change that without huge changes to my code. Also incomplete laps etc. probably won't work either. Like I said, very lazy programming.

edit: Ok. Now it should handle the first cut of video that includes many cuts.

[power79]

Ok. Another update. Same link.

Now it should work also with new TS beta versio (tyres+draft). I found one bug that happens if you convert more than one lap. So for now convert button gets disabled after one conversion. You can just open file again and convert other lap if you need to. I don't have time to fix that bug right now.

Nice. Having separated option "Best Lap to TSR" would be useful.

Well, best lap is already the default selection in the drop down box. And it is also in different color in the lap list. So that should be enough i think.

[Whiplash]

Well, best lap is already the default selection in the drop down box. And it is also in different color in the lap list. So that should be enough i think.

Best lap of all players, you amateur. Anyway, best lap of each player has awful color. Make it pure blue or red, and make it bold.
Also, it's kinda bad that I can't copy the list of laps. Right click seems not to work there.

[power79]

New update:
http://www.kolumbus.fi/arilai79/TSR_Reader.zip

- Many bugs fixed
- Now program should be able to handle cut videos (for Mike)
- Fastest lap is in bold (for Whiplash)
- Greyed laps don't have full information recorded so they won't be converted
- Race settings (fuel,damage,tyre,draft) are exported to text file (rc.txt)
- You can convert range of laps (for example: from 25 to 34, all to one tsr ofc)
- You can choose which players are included in converted video

I don't have patience to test that much so there's probably huge amount of bugs. Specially in the conversion process. Also race settings possibly have some wrong values. Just report them and I try to fix them at some point.

[power79]

Seems no one cares about my TSR_Reader.

Well, I managed to "crack" Ande's AI lap information format and figured out how to create AI lap from recording (using -d 3 output.txt info, tsr file doesn't update information often enough). Noticed also that you can increase AI lap accuracy by making the update intervals smaller (AI rec has 0.2s intervals). With highest accuracy (0.02s) AI drives same lap time every time, though it's not exactly same as recording (was actually 0.017s faster in my test). And when I got stuck to obstacle in recording, AI didn't manage to get unstuck even with highest accuracy so there's also that.

Just thought letting you know. I was going to create some kind of record chasing ghost for my rally server but I think I forget that now as you can't get 100% accuracy for the lap.

[Whiplash]

I care. And you still didn't make it to analyze the best lap of all players, which I miss the most. Now I always have to list each player to see who's having the best lap of all.
Btw, bold is OK, but the color sux. Put the pure f*** clean blue.

[power79]

Updated.

I care. And you still didn't make it to analyze the best lap of all players, which I miss the most. Now I always have to list each player to see who's having the best lap of all.

When you load tsr file it now selects player who has fastest lap of race.

Btw, bold is OK, but the color sux. Put the pure f*** clean blue.

Blue is reserved for tyres, but I changed it to brown(ish).

[Whiplash]

I changed it to brown(ish).

O boy now it's even harder to notice. O.K., just put it to be black bold this time. That would be good enough .
Btw, I suggest you to bold those green and red percentage numbers whenever they are bigger than in previous lap. On that way you'll mark the laps when somebody visited the pit.
So, here are examples:
laps
...
10. 44.774 14% 44%
11. 44.872 11% 39%
12. 47.204 9% 32%
13. 55.137 34% 94%
14. 43.760 31% 90%
15. 43.178 29% 84%
16. 44.465 26% 80%
...
27. 46.609 20% 76%
...

Sometimes only the red or blue will be bold (if a player didn't refuel by holding a "fire" key). So, we will easier to see when and why he visited the pit.
And, also, one more thing:
- I need ability to copy text of those laps. Now I can't do it. Or, maybe you could make an option like save as... Saving it as txt or even as web page would be cool.

Anyway, good to see fastest lap finally!

[power79]

Ok. I changed the format style of lap list. I hope it's better. Also you can copy the list to clipboard now.

[Whiplash]

Oh, great! It rox now!