2018-03-18 05:34:14 +00:00
|
|
|
# Set format information
|
|
|
|
|
|
|
|
|
|
`*.set` files seem to act as a palette of objects for a [`.map`](maps.md) file.
|
|
|
|
|
The map file loads a set, and can then reference objects by a small number.
|
|
|
|
|
|
|
|
|
|
Since a maximally-filled map file seems to be able to reference 91,000 * 4
|
|
|
|
|
objects, this is a necessary optimization for 1998-era hardware.
|
|
|
|
|
|
2018-03-18 17:27:32 +00:00
|
|
|
Complete parser implementation [here](../../internal/sets.md).
|
2018-03-18 05:34:14 +00:00
|
|
|
|
2018-03-18 17:27:32 +00:00
|
|
|
## Structure
|
2018-03-18 05:34:14 +00:00
|
|
|
|
2018-03-18 17:27:32 +00:00
|
|
|
These files are plain-text. A `template.set` is handily included:
|
2018-03-18 05:34:14 +00:00
|
|
|
|
|
|
|
|
```
|
|
|
|
|
set template
|
|
|
|
|
|
|
|
|
|
Defs
|
|
|
|
|
|
|
|
|
|
40 40 40 80
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
dirt
|
|
|
|
|
h_dirt
|
|
|
|
|
rocks
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
blank #
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
blank
|
|
|
|
|
# ...
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
The files are of varying lengths. `template.set` is 220 lines, `map10.set` only
|
|
|
|
|
83.
|
|
|
|
|
|
2018-03-18 17:27:32 +00:00
|
|
|
Whitespace and comments (`#`) are ignored. We have the following lines:
|
2018-03-18 05:34:14 +00:00
|
|
|
|
2018-03-18 17:27:32 +00:00
|
|
|
* Set description (informational only)
|
|
|
|
|
* `Defs` literal
|
|
|
|
|
* 4 space-separated numbers - count of entries in each of four subsections:
|
|
|
|
|
* Surface
|
|
|
|
|
* Left
|
|
|
|
|
* Right
|
|
|
|
|
* Center
|
|
|
|
|
* A list of sum(counts) .asn/.obj filename prefixes, sometimes with comments
|
2018-03-18 05:34:14 +00:00
|
|
|
* They all seem to end with a comment of some sort, e.g. `# meaningless comment`
|
|
|
|
|
|
2018-03-18 17:27:32 +00:00
|
|
|
The groups in the `Defs` section are equivalent to the four types of object
|
|
|
|
|
referenced in each map cell.
|
2018-03-18 05:34:14 +00:00
|
|
|
|
2018-03-18 17:27:32 +00:00
|
|
|
The `.MAP` files reference these tiles as palette entries. Each cell in the map
|
|
|
|
|
has an object index and frame number. I *suspect* the object index is relative
|
|
|
|
|
to the correct section of the palette. TODO: check this.
|
2018-03-18 05:34:14 +00:00
|
|
|
|
2018-03-20 12:02:07 +00:00
|
|
|
The references to objects can be qualified like `_N`. When pointing to an object
|
|
|
|
|
with multiple sprites in it, this seems to instruct WH40K_TD.exe to assemble the
|
|
|
|
|
sprites into one logical sprite with some height.
|
|
|
|
|
|
|
|
|
|
Example: pillar.obj. Only referred to as `pillar_2` in .set files. It has 6
|
|
|
|
|
frames: 2x bottom, middle and tops of pillars. All 6 sprites are shown
|
|
|
|
|
individually when referenced as `pillar`, but only 2 sprites, with a blue
|
|
|
|
|
height indicator (presuambly), are shown when referenced as `pillar_2`:
|
|
|
|
|
|
|
|
|
|
|  | |[pillar.obj as pillar_2](img/pillar_2_sprites_meta.png) |
|
|
|
|
|
|
2018-03-20 12:14:12 +00:00
|
|
|
When referenced as `pillar_3`, the middle section is rendered twice, rather than
|
|
|
|
|
once. Only 2 sprites are shown, and the blue "height" indicator increases from
|
|
|
|
|
4 to 5.
|
|
|
|
|
|
2018-03-18 17:27:32 +00:00
|
|
|
## Remaining questions
|
2018-03-18 05:34:14 +00:00
|
|
|
|
|
|
|
|
Do positions in the palette have special meaning? e.g. is a particular range
|
|
|
|
|
always reserved for walls?
|
|
|
|
|
|
|
|
|
|
Are there any special values that don't appear as files in the `Obj/` directory?
|
|
|
|
|
`blank.obj` exists, so I expect not.
|
|
|
|
|
|
|
|
|
|
Once the map format is fleshed out a little more, can investigate by creating a
|
|
|
|
|
map with a single object from the set in it and seeing what line that works out
|
|
|
|
|
to be.
|
