Map files, JSONs, and flashpoints

[Icewraith]

Looking through the map files, there’s a pretty clear similarity between the layer and .json contract files.

There’s a few things I’m wondering might be possible:

1: Adding extra mechs to the spawners in both the layer and .json files. I saw cWolf’s mission control mod can do 5 and 6 mech drops and I wondered if perhaps the layer lancedef won’t freak out if you tell it to add an extra mech. (Tweaking only the .json won’t work because there are clearly four slots in the layer, but what if you also tweaked the layer?)

2: Keeping the same lance spawn points but cut-and-pasting in the logic from three way battle layers/jsons to enable things like targetally lances becoming hostiletoall in Target Acquisition.

3: Cut-and-pasting most of one layer (and .json) into another and changing the zone numbering to avoid duplicates.

The other thing I’m trying to figure out is a way to have secondary mission objectives translate into flashpoint decisions. Ideally the only primary objective would be “get to the extraction point”, the “withdraw” button would be disabled, and completing secondary objectives would enable/disable conversation options.

After the mission, there would be a conversation led by a flashpoint decision tree where only the outcome achieved by the secondary objectives was selectable. So you’d see something like:

[Flashpoint Decision:Flawless Victory]. “Ladies and gentlemen, we pulled it off.”
[FP: Badguy and hostages died] “Well we got Badguy but we lost the Hostage convoy on the way out.”
[FP: Badguy and hostages lived]. “We got the hostages out, but Badguy is still out there.”
[FP: Evaced] “This definitely isn’t the outcome we wanted, but at least we got some of our materiel back.”
[FP: Abject Failure] “...Damn.”

The first one would complete the FP with a huge/rare reward, the second with a much less impressive reward, the last three would give you the option to go after Badguy again in a more standard assassinate mission and try to improve/salvage your contract result, or complete the flashpoint (with a moderate reward for outcome three and barely any reward for the last two).

Ideally I would be able to track successes across multiple flashpoint missions without having to get too crazy on the branching, but still allow the player’s choices to determine the outcome of the flashpoint.

 

[ronhatch]

The maps are one of those things I've never fully understood... any chance you could share some context?

Off the top of my head, here are the main things I'm wondering:

• Where are the files you're looking at? (I'm guessing you're talking about the data/maps set of files, but that format is opaque to me.)
  
• What tools are you using to examine them?
• Is there a resource already out there that you used to learn how this works?

Feel free not to take the time to write any of that up if it ends up being a long answer... but I figure I can't be the only one that could use a head start on understanding this part of the system, and the more of us that know how to poke at things, the better.

 

[Icewraith]

The maps are one of those things I've never fully understood... any chance you could share some context?

Off the top of my head, here are the main things I'm wondering:

• Where are the files you're looking at? (I'm guessing you're talking about the data/maps set of files, but that format is opaque to me.)
  
• What tools are you using to examine them?
• Is there a resource already out there that you used to learn how this works?

Feel free not to take the time to write any of that up if it ends up being a long answer... but I figure I can't be the only one that could use a head start on understanding this part of the system, and the more of us that know how to poke at things, the better.

I literally just opened up the layer-specific files in notepad++ for the low highway fire mission (under maps) and three way battle and compared them with each other. I also looked at a three-way battle .JSON and downloaded The Raid to get a look at a fire mission .JSON.

If you look at the map structure, there are several files corresponding to a particular encounter layer and then a single terrain file at the bottom. One of the layer-specific files looks like it’s used to calculate line of sight (something about ray tracing). It’s complete gibberish when opened but it’s well spaced gibberish iirc, and the file size for fire missions is slightly larger than the others, which is what you might expect if you stuck a giant destructible building in the middle of your map.

Layer files:
It’s pretty clear that map locations are an alphanumeric string (also maybe not a String-string, I didn’t count the characters or see if it used anything above f) that probably converts to the map grid or a supergrid the map grid is laid on top of (you know those objective zones that JUST miss certain map pips?). I think it was even in a gibberish-gibberish of suspiciously similar size format, again suggesting coordinates like x-y.

The layer files recognize player, employer, Target, employerally, targetally, hostile to all, and neutral owners, and the lance ai and relation to an objective are defined in the layer file. I think the main thing the contract parser does to turn .txt files into .JSONs is point things at the appropriate object IDs from the layer files.

If you look at a sample contract.txt, .json, and map layer file it’s pretty clear where the hooks and overrides are being set.

I’m fairly confident that the right set of cutting and pasting in a layer file lance call out could at least result in changing the allegiances of various lances.

I’m less confident about the wholesale cutting and pasting of entire objectives from one layer file to another, mainly because I didn’t look to see if there was an obvious pattern to how object ids were called out in the layer file.

This is also dependent on notepad++ correctly interpreting the non-human readable information and putting it back exactly as it was.

 

[ronhatch]

I think I'm tracking with what you did now... I had to grab Notepad++ myself to see how it displays the binary data (I'm a Linux guy, so I use vim as my editor).

If I open (for example) BattleTech_Data\StreamingAssets\data\maps\mapgeneral_highway_vlow\mapGeneral_highway_vLow_encGeneral_Battle_LayerData.bin in Notepad++, there are a bunch of control code characters listed as white text on black boxes. Using square brackets to mark those codes, the first line of that file starts out [BS]Battle 1"[SI][BS]øŒŸ–[STX][DC2][BEL]Include*[DC4][BS]. Is that what you're seeing?

Because that's a binary file, and typically some of the data for this sort of format includes field length information and that sort of thing. Changing even a single character can make the entire file unreadable. I mean... the text portions are certainly of interest and comparing them as you've done is a good start for understanding what's going on... but the non-text part of the file is critical information if we want to start making changes. It's possible that the format is some sort of Unity thing, but it's also possible that it's an in-house format specific to the game.

Edit: Though changing text is at least moderately safe, as long as there isn't any checksum on the data. Looks like most text doesn't end with [NUL], though... which means the length of the text is encoded somewhere else (perhaps right before it, but maybe not). So changing text is NOT safe if you change the length. For some things, that might not be a problem... for others, yeah... good luck.

 

[Icewraith]

I think I'm tracking with what you did now... I had to grab Notepad++ myself to see how it displays the binary data (I'm a Linux guy, so I use vim as my editor).

If I open (for example) BattleTech_Data\StreamingAssets\data\maps\mapgeneral_highway_vlow\mapGeneral_highway_vLow_encGeneral_Battle_LayerData.bin in Notepad++, there are a bunch of control code characters listed as white text on black boxes. Using square brackets to mark those codes, the first line of that file starts out [BS]Battle 1"[SI][BS]øŒŸ–[STX][DC2][BEL]Include*[DC4][BS]. Is that what you're seeing?

Because that's a binary file, and typically some of the data for this sort of format includes field length information and that sort of thing. Changing even a single character can make the entire file unreadable. I mean... the text portions are certainly of interest and comparing them as you've done is a good start for understanding what's going on... but the non-text part of the file is critical information if we want to start making changes. It's possible that the format is some sort of Unity thing, but it's also possible that it's an in-house format specific to the game.

Edit: Though changing text is at least moderately safe, as long as there isn't any checksum on the data. Looks like most text doesn't end with [NUL], though... which means the length of the text is encoded somewhere else (perhaps right before it, but maybe not). So changing text is NOT safe if you change the length. For some things, that might not be a problem... for others, yeah... good luck.

Screwing around with this you’d obviously want to make a copy and mess with that. I’m not confident messing with individual parts of a given callout, but what I think might work is pasting entire sets of known good callouts between layer files.

 

[ronhatch]

Screwing around with this you’d obviously want to make a copy and mess with that. I’m not confident messing with individual parts of a given callout, but what I think might work is pasting entire sets of known good callouts between layer files.

I'd give it very low odds of working, but on the other hand... experimenting is a huge part of how we figure this stuff out, so go for it and let us all know what you discover.

 

[PaulCl]

Looks like most text doesn't end with [NUL], though... which means the length of the text is encoded somewhere else (perhaps right before it, but maybe not).

Looks like the length is right before the string. (1) "[BS]Battle 1" - [BS] is presumably backspace, which is ASCII code 8, and "Battle 1" is eight characters. (2) "[BEL]Include" - the BEL character is ASCII code 7, and "Include" is seven characters.

 

[ronhatch]

Looks like the length is right before the string. (1) "[BS]Battle 1" - [BS] is presumably backspace, which is ASCII code 8, and "Battle 1" is eight characters. (2) "[BEL]Include" - the BEL character is ASCII code 7, and "Include" is seven characters.

Hmm... yeah. There were a few spots that on an initial glance didn't look plausible to me, but actually calculating it I'm not seeing any strings that don't have the length in the byte preceding. Part of what threw me off is that I would have expected a two-byte length instead of just a single byte.

In any case, now that I look closer I'm also seeing an example of "h" (ASCII code 104) preceding "Assets/Level Design/Maps/mapGeneral_highway_vLow/mapGeneral_highway_vLow_encGeneral_Battle_LayerData.bin", which does turn out to be 104 characters.

 

[ronhatch]

By the way... in case anyone following along wants to speculate on what other information is encoded in there, here's a screenshot of the start of the same file opened in a hex editor:

(I mean, really... go ahead and open up your own copy with a hex editor. But I figured posting this might have a chance to get people that don't even know what a hex editor is started on thinking along those lines.)