PlatinumMaster / SwissArmyKnife

A tool for editing various Generation V formats.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Map Editor always in "WB"-mode

gonhex opened this issue · comments

Wrong offsets if there are more or less than one permission section.

What should the correct behavior be? I need a container with more than one permission section so I can test it.

Pseudocode of the header:

struct header {
    u16 magic;  // "WB", "GC", "RD" or "NG"
    u16 sectionCount;  // 2, 3 or 4
    u32 sectionOffset[sectionCount];  // first is model, last is building table, 0-2 per. in between
    u32 fileSize;  // offset EOF
};

You can use these two maps for testing. One has 0 and the other 2 permission sections:
exampleMaps.zip

MapContainer.cs has only "WB"-support.

I see. In that case, I'll take care of the other formats.

Here is an "RD" chunk - seems to be the same as WB in the cases I've observed. The difference in usage is that this chunk type allows hybrids of grid and rail data in a map (for rails only, NG/NoGrid chunks are used, while grid-only chunks are mostly WB or GC if multiple collision layers are needed).

8_1002.zip

The permission section of "RD" type maps works different. Instead of 8 bytes per tile there are 24 bytes. They are used in combination with files from an other NARC to place buildings (and maybe NPCs, too) which depend on flags in the game progress.

Here is an "RD" chunk - seems to be the same as WB in the cases I've observed. The difference in usage is that this chunk type allows hybrids of grid and rail data in a map (for rails only, NG/NoGrid chunks are used, while grid-only chunks are mostly WB or GC if multiple collision layers are needed).

8_1002.zip

Thanks, I'll integrate support for the next version.

The permission section of "RD" type maps works different. Instead of 8 bytes per tile there are 24 bytes. They are used in combination with files from an other NARC to place buildings (and maybe NPCs, too) which depend on flags in the game progress.

I see. It doesn't look like any additional files will need to be parsed in order to work with this, but if it makes it easier I'll look into adding this into future iterations of the tool.

Bear in mind that these changes will likely be integrated after the cross-platform version of the tool is made, so I'll add support for sections and a disclaimer that this will only work for "WB" map containers for now.

This issue has been fixed for the next version of the tool, which should release soon.