I'll quote myself to start off with:
We think the maps consist of:
- mesh layered on top of heightmap
- textures painted on the mesh
- individual objects such as trees, houses, tractors, traffic signs and mailboxes. As far as I know someone had to place every last one of these on the map by hand. Even the trees.
- "game logic layer" which includes zone coordinates, urban sectors, roads, reinforcement routes
- and some extra stuff that doesn't need to be on top of the map but needs to be included, such as default camera angles, zone point values and so on.
There probably is pathfinding pre-calculated somewhere in there.
When mapper creates a map, he does so at the most detailed level (let's call it level 1). Then Eugen "bakes" the map. The map is first divided into squares of some arbitrary size. The mapping tools then calculate matching points on level 1 and level 2 squares and effectively pre-renders the next level map square, somewhat similar to how Google Map zooming works. This process is repeated for map levels 3, 4... N-1 and then it's probably just a flat file at level N. I think it's called "baking" because when you bake something, it rises. Geddit? Coder humor!
The baking process then divvies up this information based on whether it was baked (zoom layers, textures, K-D trees mapping the points between levels) or non-baked (game logic), dumps it into appropriate files and encodes it into bytecode. This serves the additional purpose of making map zone changes cheaper to distribute as the file size difference is huge.
While creating a map editor that allows you to plop objects on a textured 2D map isn't that hard, the whole Wargame map making process is a bitch to replicate (especially if you don't know the exact zoom level values). It's technically very neat as the result is a very responsive, very low-demand way of showing huge amount of map information.
What we can (almost) do:
- edit sector values
- edit reinforcement routes
- edit starting sectors
- remove sectors
What can reasonably be hoped for:
- editing sector sizes and placement
What's not gonna happen:
- full fledged map editor which allows user to create a map from scratch.
Why won't there be a map editor?
Because creating a new map is a humongous task. As detailed above, not only would the mapper have to create a heightmap, mesh and game logic layer, he'd also have to create, texture and place all the little objects that litter each map. This is practically a full-time job. There are commercial tools for parts of the process, but they're expensive and not necessarily meant for consumer use. I also believe that even if the whole mapper tool that Eugen uses was made available, it wouldn't be used to create a single completely new map for Wargame. It might be used as a basis for a whole new game or certain other business applications, though.
Why can't we edit heightmap?
Because that requires changes in the mesh, and once mesh is changed the whole map needs to be baked again. We've been guessing if there was a way to edit hillside into flat ground, but it's probably way more work than it is worth to figure that one out.
Why do you say "almost"?
Nice that you asked! We're close and would appreciate a bit of help to crack the final nut. This is your chance to prove you're a hardcore hacker!
You can use the existing mod tools to go into Steam\steamapps\common\Wargame Airland Battle\Data\WARGAME\PC\2100001553\2100001570 and open Datamap.dat in the editor. Export the map\scenario\_10vs10_02\leveldesign.scenario file and open it up in a hex editor.
The first bytes go like this:
Code: Select all
53 43 45 4E 41 52 49 4F 0D 0A 11 A8 9D 66 B0 B1 FC 30 10 EF AF FD A4 39 9E E6 00 00 04 00 00 00 03 00 00 00 58 3F 04 00
or in ASCII like this:
Code: Select all
The bit we're interested in is right after SCENARIO:
Code: Select all
0D 0A 11 A8 9D 66 B0 B1 FC 30 10 EF AF FD A4 39 9E E6 00 00
0D 0A seem to be always same. So do the null bytes at end. What's between looks like a MD5 checksum, but we haven't been able to match it with anything thus far. If it is a checksum it needs to be rewritten at editing time or the game will crash with an error. It might also be something else, in which case we'd need to know what it is and how to generate it (or if we're very, very lucky if we can just safely ignore it).
The rest of the bytes seem to be offsets into the file. While these tend to stay the same, exact format description doesn't hurt.
I want to edit zone placement!
Get crackin' on the same file. AREA seems to limit zones. The format, as far as we know:
each zone contains 8 blocks of data, each block seperated by the word AREA, the first block is a string containing a guid, no2 is 12 unkown bytes, no 3-5 looks like small ints, 6 is the vertex list, 7 is the ordering of the verteces, 8 is as far as I can tell always 0, a zone is ended by the word END0 (zero)
so the vertex data is a bit dodgy
the first 4 bytes describes how many verteces there are
the next for bytes is always 4 less
each vertex is described by 20 bytes
and the 4 first is probably the x value, next 4 is the y value and the last 4 is the Z value
what the other 4 is is a mystery
Vertexes are absolutely essential for doing anything with the zones. Working this out would help out immensely.
I have a feature request!
No. These come first.
I work for Eugen Systems and...
I'd love to get assistance from you guys. Is it a checksum and how is it calculated?
Credit for working out the maps goes to Gronank who has spent an incredible amount of time working on them, and enohka whose work makes figuring out things a lot easier.