zxt:format_specification
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
zxt:format_specification [2021/08/06 08:29] – asie | zxt:format_specification [2021/08/11 06:21] (current) – Use propagating tag for ZAXMAKE/ZXTSPLIT links, instead of single version link. The propagation can be cancelled (even retroactively if needed) if changes are made that violate this specification. zzo38 | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== ZXT Extension Format Specification ====== | ====== ZXT Extension Format Specification ====== | ||
- | Version 0.XX | + | Version |
By Adrian " | By Adrian " | ||
- | The specification follows a MAJOR.MINOR numbering scheme. | + | Special thanks: endgame, GreaseMonkey, |
+ | |||
+ | The specification follows a MAJOR.MINOR.PATCH | ||
+ | |||
+ | * Changes to the MAJOR number are expected to introduce breaking changes, resulting in a change of the extension header magic number; | ||
+ | * Changes to the MINOR number are expected to introduce changes which don't break backwards compatibility, | ||
+ | * Changes to the PATCH number are expected to introduce changes which don't impact the meaning of the specification, | ||
+ | |||
+ | For example, a ZXT 1.1.x world which doesn' | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | Extending and tweaking the functionality of the ZZT game engines ((ZZT and Super ZZT)) has always been an undercurrent in its world development community. While many games relying on edited executables or TSRs ((Terminate-Stay Resident programs)) have been released in the past, they ran into key problems, keeping their count small and the idea unpopular: | + | Extending and tweaking the functionality of the ZZT game engines ((ZZT and Super ZZT)) has always been an undercurrent in their world development community. While many games relying on edited executables or TSRs ((Terminate-Stay Resident programs)) have been released in the past, they ran into key problems, keeping their count small and the overall |
* The lack of source code greatly increased the difficulty of performing non-trivial modifications. | * The lack of source code greatly increased the difficulty of performing non-trivial modifications. | ||
- | * The requirement for special batch scripts or modified executables, | + | * The requirement for special batch scripts or modified executables, |
* No consistent means of signaling required extensions was devised. For most worlds, this made them indistinguishable from ZZT 3.2-compatible ones for the end user or reimplementations, | * No consistent means of signaling required extensions was devised. For most worlds, this made them indistinguishable from ZZT 3.2-compatible ones for the end user or reimplementations, | ||
Line 79: | Line 87: | ||
If a .ZXT file is being loaded, a .ZAX file should be ignored - .ZAX files apply for .ZZT files, not .ZXT files. | If a .ZXT file is being loaded, a .ZAX file should be ignored - .ZAX files apply for .ZZT files, not .ZXT files. | ||
+ | |||
+ | The behaviour of multiple concatenated extension headers contained within one .ZXT or .ZAX file is undefined; distributed .ZXT or .ZAX files MUST NOT rely on it. | ||
==== Extension Header ==== | ==== Extension Header ==== | ||
Line 92: | Line 102: | ||
^ Offset ^ Type ^ Name ^ Description ^ | ^ Offset ^ Type ^ Name ^ Description ^ | ||
| 0 | u16 | flags | Extension flags; defined below. | | | 0 | u16 | flags | Extension flags; defined below. | | ||
- | | 2 | u32 | owner_id | Extension owner ID | | + | | 2 | u32 | owner_id | Extension owner ID. | |
- | | 6 | u16 | selector_id | Extension selector ID | | + | | 6 | u16 | selector_id | Extension selector ID. | |
- | | 8 | u8 | reserved_0 | Reserved. | | + | | 8 | u8 | reserved_0 | Reserved; must be set to 0. | |
- | | 9 | u16 | field_length | Field length. | + | | 9 | u16 | field_length | Field length. |
| 11 | u8[field_length] | field_data | Field data. Extension-defined. | | | 11 | u8[field_length] | field_data | Field data. Extension-defined. | | ||
Line 113: | Line 123: | ||
| 8 .. 15 | reserved | Reserved. | If set, an implementation MUST NOT continue parsing of the extension block. | | | | 8 .. 15 | reserved | Reserved. | If set, an implementation MUST NOT continue parsing of the extension block. | | | ||
- | It is important to note that the flags can be distinct from the ID pair; for instance, the same ZZT-OOP extension can be defined as " | + | It is important to note that the flags can be distinct from the ID pair; for instance, the same ZZT-OOP extension can be defined as " |
===== Extension IDs ===== | ===== Extension IDs ===== | ||
- | Extension IDs are allocated on a per-owner ID basis. | + | Extension IDs are allocated on a per-owner ID basis. Within one owner ID, selector IDs SHOULD be used in a "one per extension" |
==== Owner ID Ranges ==== | ==== Owner ID Ranges ==== | ||
- | * The range '' | + | * The range '' |
* The range '' | * The range '' | ||
* The range '' | * The range '' | ||
Line 148: | Line 158: | ||
* ZXT standard compliance concerns only the game engine' | * ZXT standard compliance concerns only the game engine' | ||
- | * An implementation MAY choose to be compatible only with ZXT worlds containing certain extensions. Compatibility with un-extended ZZT worlds is OPTIONAL. | + | * An implementation MAY choose to be compatible only with ZXT worlds containing certain extensions. Compatibility with un-extended ZZT worlds |
==== Engine Accuracy ==== | ==== Engine Accuracy ==== | ||
Line 192: | Line 202: | ||
* Use an ID inside the area of private use extensions while the extension' | * Use an ID inside the area of private use extensions while the extension' | ||
* Mark your public specification as " | * Mark your public specification as " | ||
+ | * If your extension is intended to work only with ZZT or Super ZZT, but not the other, it's a good idea to mention that explicitly in the specification. | ||
==== Engine Developers ==== | ==== Engine Developers ==== | ||
Line 209: | Line 220: | ||
* Some extensions may require data specific to save files, and implementations may wish to have the freedom to decide how to store them in this case; | * Some extensions may require data specific to save files, and implementations may wish to have the freedom to decide how to store them in this case; | ||
* Some implementations may store ZZT data in a custom format internally, and removing this requirement can make their code simpler. | * Some implementations may store ZZT data in a custom format internally, and removing this requirement can make their code simpler. | ||
+ | * Multiple concatenated extension headers may be used as a feature in the future - for example, for faciliating multi-patch application for ZZT worlds. | ||
===== Implementations ===== | ===== Implementations ===== | ||
+ | |||
+ | This is not a formal part of the specification. | ||
+ | |||
+ | ==== Libraries ==== | ||
+ | |||
+ | === ZXT 1.0.x === | ||
+ | |||
+ | * [[https:// | ||
+ | |||
+ | ==== Tools ==== | ||
+ | |||
+ | === ZXT 1.0.x === | ||
+ | |||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | |||
+ | ==== Engines ==== | ||
TBD | TBD |
zxt/format_specification.1628238589.txt.gz · Last modified: 2021/08/06 08:29 by asie