Better import/export system #15

New issue

Open

opened 2021-10-03 00:33:51 +02:00 by williamjcm · 2 comments

williamjcm commented

2021-10-03 00:33:51 +02:00

Owner

Once #13 is effectively done, I'll be able to add a massively improved import/export system, allowing stuff like importing/exporting styles, weapons, armour configurations, etc...

williamjcm added the

enhancement

label 2021-10-03 00:33:51 +02:00

williamjcm self-assigned this 2021-10-03 00:33:51 +02:00

williamjcm added this to the v1.3.0 milestone 2022-01-06 21:34:51 +01:00

williamjcm referenced this issue

2022-01-06 21:40:05 +01:00

Build viewer/editor #13

williamjcm commented

2022-02-16 11:46:35 +01:00

Author

Owner

Format description:

Filename format:
- Custom style: <Build_name>_<Frame/Armour/Weapon/Global>Style_<Style_name>.style.mbst
- Armour piece: <Build_name>_<SlotName>.armour.mbst
- Weapon: <Build_name>_<WeaponType>_<Weapon_name>.weapon.mbst
Some "magic bytes". MBSTSTYLE, MBSTARMOUR, MBSTWEAPON.
Size of the object data. 8 bytes (std::size_t).
CRC-32 checksum of the object data. 32-bit (4 bytes) obviously (std::uint32_t).
Object data as a key-value storage:
- Key size is one unsigned byte, corresponding to an enumerator value.
- The value is variable-length. Strings are stored in the same way as in the save files (length of string, followed by the string itself, null terminator included in both cases).

If value types get changed from one game version to the next, values get deleted, or new ones get added, old keys will stay but will be handled differently to preserve compatibility with older exported files. New keys will be added to the end of the enums.

TODO:

Look into storing more than one weapon/armour/style per file (batch export/import).
Bundle armour parts with used custom/global styles, and weapons with used global styles.
When importing armour/weapon with bundled styles, choose where those styles get imported and remap them.

Format description: - Filename format: - Custom style: `<Build_name>_<Frame/Armour/Weapon/Global>Style_<Style_name>.style.mbst` - Armour piece: `<Build_name>_<SlotName>.armour.mbst` - Weapon: `<Build_name>_<WeaponType>_<Weapon_name>.weapon.mbst` - Some "magic bytes". `MBSTSTYLE`, `MBSTARMOUR`, `MBSTWEAPON`. - Size of the object data. 8 bytes (`std::size_t`). - CRC-32 checksum of the object data. 32-bit (4 bytes) obviously (`std::uint32_t`). - Object data as a key-value storage: - Key size is one unsigned byte, corresponding to an enumerator value. - The value is variable-length. Strings are stored in the same way as in the save files (length of string, followed by the string itself, null terminator included in both cases). If value types get changed from one game version to the next, values get deleted, or new ones get added, old keys will stay but will be handled differently to preserve compatibility with older exported files. New keys will be added to the end of the enums. TODO: - [ ] Look into storing more than one weapon/armour/style per file (batch export/import). - [ ] Bundle armour parts with used custom/global styles, and weapons with used global styles. - [ ] When importing armour/weapon with bundled styles, choose where those styles get imported and remap them.

williamjcm modified the milestone from v1.3.0 to v1.4.0

2022-03-06 10:06:19 +01:00

williamjcm changed reference from ~~master~~ to the-road-to-1point4

2022-04-15 21:00:44 +02:00

williamjcm added a new dependency 2022-04-16 01:11:51 +02:00

#23 WIP: The Road to 1.4

williamjcm referenced this issue

2022-04-24 17:04:53 +02:00

WIP: The Road to 1.4 #23

williamjcm removed a dependency 2022-11-21 08:28:18 +01:00

#23 WIP: The Road to 1.4

williamjcm removed this from the v1.4.0 milestone 2022-11-21 08:34:22 +01:00