klensy/wt-tools

Unpacking Wrplu Files

Yay5379 opened this issue · 13 comments

I have found so information that should be helpful for developing a parser for wrplu files. I don't know how to make a parser but I will still be able to look for more details about the structure of wrplu files. I will post updates here when I find anything new.

  1. the sequence of bytes that comes before a vehicle is \x01\x20\x01
  2. the sequence of bytes that comes immediately before three float 32 numbers that represent the position of a vehicle is \x11\x00\x01\x60
  3. the sequence of bytes that comes before a streak award is \x02\x58\x78\xf0

Note: if you want to help find more details on the structure of wrplu files make sure you decompress your wrplu file before looking for structures.

i could attempt to extract said values that have a known identifier from a sample file, can you provide one that is already unpacked?

@FlareFlo Here are a few wrplu files that I decompressed.
decompressed wrplus.zip

I went and pulled all floats from the first file to maybe have a look at them as such:
floats.txt
i will try and see what the other parameters lead to

using this script i threw together

	fn extract_wrpl_1_floats()  {
		let file = fs::read("./samples/decompressed wrplu_1").unwrap();

		let mut floats = vec![];
		let float_mask = &[0x11, 0x00, 0x01, 0x60];
		for (i, window) in file.windows(4).enumerate() {
			if float_mask == window {
				let all_floats = &file[(i + 4)..((i + 4) + 3 * 4)];
				let parsed_floats = all_floats.chunks(4).map(|bin|f32::from_le_bytes([bin[0],bin[1],bin[2],bin[3],])).map(|x|format!("{x:<15}")).collect::<Vec<_>>();
				floats.push(parsed_floats.join("\t"));
			}
		}
		fs::write("floats.txt", floats.join("\n")).unwrap();
	}

Just by position alone we can tell that there are multiple vehicles within this sequence.

I looked at the file and there are over 30,075 sets of coordinates and out of those only 9 sets appeared to be some sort of garbage data that resulted in a really long number. But my theory was correct that the replay files did contain a sequence of coordinates that represented the movement of vehicles.

Unfortunately, i did not see a clear pattern in offsets for the other byte sequences

@FlareFlo Update: I have found a clear pattern for one of the byte squences.
\x02\x58\x78\xF0\xStreak id no. (8-Bit Integer)\x3E\xPlayer id no. (8-Bit Integer)\x00\x00\x00\xString Length (8-Bit Integer)/xString

The 8-bit integer string length is the amount of bytes that make up the name of the streak while the streak id no. is just a number. The player id no. is based upon the order usernames are listed in the rez.blk file with player id x00 being the author of the replay.

Update: I have found a clear pattern for one of the byte squences. \x02\x58\x78\xF0\xStreak id no. (8-Bit Integer)\x3E\xPlayer id no. (8-Bit Integer)\x00\x00\x00\xString Length (8-Bit Integer)/xString

The 8-bit integer string length is the amount of bytes that make up the name of the streak while the streak id no. is just a number. The player id no. is based upon the order usernames are listed in the rez.blk file with player id x00 being the author of the replay.

great, i will look into pulling some of that data out of the sample you sent

@FlareFlo any updates on pulling data from the samples?

apart from the already extracted data i did not find any additional information :/

new replay example.zip
UPDATE: they completely changed the structure of wrplu files with the addition of rewindable replays. I manually separated a wrplu file from the full replay file because none of the unpackers work anymore and I found some interesting stuff. I also found out about a hidden debug feature that you can enable in your config.blk file to export the positions of air units to a text file. I attacked a zip file containing the replay, decompressed wrplu, and a folder with the air unit positions.

STR-T commented

@Yay5379 Do you know if it's still possible to find x, y, z coords in the new replay files? I made a simple usermission with static coordinates to try to figure this out, but I can only find unit/object position floats once at the very start of the replay. I've found this pattern repeated throughout the replay file. I think it might contain the coordinates but I've had no luck reading them so far.

One thing I could figure out is that the 4 bytes starting at the 11th byte of each block represent match time and update roughly every 50ms. 9B A4 A8 41= 21.080, B6 fC A8 41 = 21.123, etc.
bookmarks

@STR-T I moved this issue to kotiq/wt-tools as it is more up to date with more things I found.