Finish the Set/ implementation
This commit is contained in:
@@ -81,7 +81,7 @@ remake.
|
||||
* `*.TXT`
|
||||
* [`Obj/`](obj.md)
|
||||
* `*.obj` # must be visual data of some sort, one per placeable map object?
|
||||
* `Pic/`
|
||||
* [✓] `Pic/`
|
||||
* `*.pcx` # Standard .pcx format
|
||||
* `RandomMaps/`
|
||||
* `*.chk` # multiplayer. worry about these another day
|
||||
@@ -89,7 +89,7 @@ remake.
|
||||
* `Save_G/`
|
||||
* `*.sav` # savedata, gzip-compressed, custom format
|
||||
* `*.txt` # Seems to be a copy of one of Maps/*.txt
|
||||
* [`Sets/`](sets.md)
|
||||
* [✓] [`Sets/`](sets.md)
|
||||
* `Data.chk` # checksums? Mentions all the .set files
|
||||
* `*.set` # plain text, related to maps. Editor has a concept of map sets, which these must be
|
||||
* [✓] `SMK/`
|
||||
@@ -119,4 +119,4 @@ Phew.
|
||||
* [`Maps/*.txt`](maps.md#associated-txt-file)
|
||||
* [`Sets/*.set`](sets.md)
|
||||
* [`Sounds/wh40k.ds`](sounds.md)
|
||||
* `Wav/*.wav`
|
||||
* `Wav/*.wav`
|
||||
|
@@ -6,11 +6,11 @@ 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.
|
||||
|
||||
Complete parser implementation [here](../../internal/sets.md).
|
||||
|
||||
## Structure
|
||||
|
||||
These files are plain-text.
|
||||
|
||||
We handily have a `template.set`, which looks like:
|
||||
These files are plain-text. A `template.set` is handily included:
|
||||
|
||||
```
|
||||
set template
|
||||
@@ -45,25 +45,26 @@ blank
|
||||
The files are of varying lengths. `template.set` is 220 lines, `map10.set` only
|
||||
83.
|
||||
|
||||
So it's a line-based format that goes:
|
||||
Whitespace and comments (`#`) are ignored. We have the following lines:
|
||||
|
||||
* Set description
|
||||
* Blank line (optional, missing in `GEN_JUN.set`, `GEN_WAS.set`, others)
|
||||
* `Defs`
|
||||
* Blank line
|
||||
* 4 space-separated numbers, variable between sets
|
||||
* At least one blank line, sometimes 2
|
||||
* A list of object names, sometimes with # comments on the right hand side
|
||||
* 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
|
||||
* They all seem to end with a comment of some sort, e.g. `# meaningless comment`
|
||||
|
||||
Questions:
|
||||
The groups in the `Defs` section are equivalent to the four types of object
|
||||
referenced in each map cell.
|
||||
|
||||
What are the `Defs` for? Is it `Defaults` or `Definitions`? The values are
|
||||
quite variable between files.
|
||||
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.
|
||||
|
||||
Is whitespace significant in the list of objects? First assumption is no.
|
||||
|
||||
Is it a simple 0-indexed palette or do maps embed an absolute line number?
|
||||
## Remaining questions
|
||||
|
||||
Do positions in the palette have special meaning? e.g. is a particular range
|
||||
always reserved for walls?
|
||||
@@ -74,4 +75,3 @@ Are there any special values that don't appear as files in the `Obj/` directory?
|
||||
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.
|
||||
|
||||
|
Reference in New Issue
Block a user