Difference between revisions of "Blueprint File Format Metadata"
SgSkallagrim (talk | contribs) m (→meta.smbpm) |
SgSkallagrim (talk | contribs) m (→Tag 2) |
||
(15 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
=meta.smbpm= | =meta.smbpm= | ||
− | A metafile can contain a huge abundance of information about a blueprint. | + | A metafile can contain a huge abundance of information about a [[Blueprint File Formats|blueprint]].<br /> |
Storage content, position and volume and shop prizes. | Storage content, position and volume and shop prizes. | ||
Also wireless logic connections, transporter, jump drive/inhibitor, scanner, shipyard, warp gates, race gate positions and targets, information about power, shields, display content, some block amounts, AI configurations. | Also wireless logic connections, transporter, jump drive/inhibitor, scanner, shipyard, warp gates, race gate positions and targets, information about power, shields, display content, some block amounts, AI configurations. | ||
− | + | And location and rotation of docked entities and stuff that is yet unknown. <br /> | |
The file is written using Big-endian.<br /> | The file is written using Big-endian.<br /> | ||
− | A metadata file with of version v0 to v3 is considered to have positions relative to a core at (8, 8, 8). A blueprint might contain Smd files with a core at (16, 16, 16) and still have a metadata of v3 or lower. In that case all positions of the metadata file need to be adjusted for positions to be consistent. | + | A metadata file with of version v0 to v3 is considered to have positions relative to a core at (8, 8, 8). A blueprint might contain Smd files with a core at (16, 16, 16) and still have a metadata file of v3 or lower. In that case all positions of the metadata file need to be adjusted for positions to be consistent. |
==Header of file== | ==Header of file== | ||
Line 16: | Line 16: | ||
==Data== | ==Data== | ||
After the version comes a tag. There are 7 known tags that indicate how the bytes that come after them are read. | After the version comes a tag. There are 7 known tags that indicate how the bytes that come after them are read. | ||
− | The end of a file is reached if tag id '1' is read, or at the end of the tag id '2' data bytes. | + | The end of a file is reached if tag id '1' is read, or at the end of the tag id '2' data bytes.<br /> |
A version followed by a 1 byte is the shortest possible metadata file. | A version followed by a 1 byte is the shortest possible metadata file. | ||
Line 43: | Line 43: | ||
|} | |} | ||
− | ===Tag 2=== | + | ===[[Blueprint File Format Metadata Tag 2|Tag 2]]=== |
A collection of several Information. Is at the end of a metadata file and replaces tag '1'. | A collection of several Information. Is at the end of a metadata file and replaces tag '1'. | ||
The tag byte is followed directly by a [[tag structure]]. | The tag byte is followed directly by a [[tag structure]]. | ||
A tag structure is defined by various tags that indicate a specific data structure. | A tag structure is defined by various tags that indicate a specific data structure. | ||
− | For example '-13'/'13' indicates a list of [[tag payloads]]. | + | For example '-13'/'13' indicates a list of [[tag payloads]].<br /> |
− | + | This is a summary of one possible structure: | |
13: 'container' | 13: 'container' | ||
{ | { | ||
-13: {} // List of storage blocks and their contents | -13: {} // List of storage blocks and their contents | ||
− | 3: 'shipMan0' 0, // | + | 3: 'shipMan0' 0, // Location of Docking Modules, seems unused since > v0.1616 |
-13: {-6: 50000.0, -6: 0.0, } // Power, Aux Power | -13: {-6: 50000.0, -6: 0.0, } // Power, Aux Power | ||
6: 'sh' 1000.0, // Shield | 6: 'sh' 1000.0, // Shield | ||
− | -13: { } // shop info for stations, an unknown int64 | + | -13: { } // shop info for stations, for ships: "1: 'ex' 0" up to v0.19498, an unknown int64 after that |
− | + | 13: 'a' { } // Logic (Buttons, Delay blocks) | |
− | -13: {} // position and content of Display Modules | + | -13: {} // position and text content of Display Modules / Inner Ship Remote |
-13: {} // A short list of block ids and their amount | -13: {} // A short list of block ids and their amount | ||
-1: 0, // Warp gate info, unless it is a ship | -1: 0, // Warp gate info, unless it is a ship | ||
Line 73: | Line 73: | ||
} | } | ||
13: 'AIConfig1' {} // AI configuration, same as in tag '5' | 13: 'AIConfig1' {} // AI configuration, same as in tag '5' | ||
− | -13: { } // | + | -13: { } // Hot-Bar Items |
-1: 0, // Race gate info, unless it is a ship | -1: 0, // Race gate info, unless it is a ship | ||
-13: {} // unknown | -13: {} // unknown | ||
Line 119: | Line 119: | ||
|} | |} | ||
+ | ====Wireless logic==== | ||
For Metadata version 2 and higher wireless logic connection are listed here. | For Metadata version 2 and higher wireless logic connection are listed here. | ||
− | |||
{| class="wikitable" | {| class="wikitable" | ||
! Purpose !! Data type | ! Purpose !! Data type | ||
Line 143: | Line 143: | ||
| Position (to) || int64 | | Position (to) || int64 | ||
|} | |} | ||
+ | The (x, y, z) positions are encoded into the int64 values. The bits 0-15 are x, 16-31 is y and 32-47 is z. Bit 48 to 63 are always 0. | ||
+ | ====Docked entities==== | ||
For every version there will be a list of docked entities. | For every version there will be a list of docked entities. | ||
Line 170: | Line 172: | ||
{ | { | ||
-1: 0, // Unknown, meta version 5. Some older v5 do not have it | -1: 0, // Unknown, meta version 5. Some older v5 do not have it | ||
− | -8: MAIN_ENTITY_SHIP_Label, // Label | + | -8: 'MAIN_ENTITY_SHIP_Label', // Label |
-10: (16, 17, 16), // Position of Rail | -10: (16, 17, 16), // Position of Rail | ||
-2: 662, // Block Id, Rail Basic | -2: 662, // Block Id, Rail Basic | ||
− | -1: 10, // Orientation | + | -1: 10, // Rail Orientation |
− | -1: 1, // Orientation | + | -1: 1, // Rail Orientation |
− | -1: 100, // Hitpoints | + | -1: 100, // Rail Hitpoints |
} | } | ||
-13: // Docked entity | -13: // Docked entity | ||
{ | { | ||
-1: 0, // Unknown, meta version 5, sometimes | -1: 0, // Unknown, meta version 5, sometimes | ||
− | -8: DOCKED_ENTITY_SHIP_Label, | + | -8: 'DOCKED_ENTITY_SHIP_Label', |
− | -10: (16, 15, 16), // Position of Rail Docker in the | + | -10: (16, 15, 16), // Position of Rail Docker in the coordinate system of the docked entity. |
− | -2: | + | -2: 663, |
− | -1: | + | -1: 14, |
-1: 1, | -1: 1, | ||
-1: 100, | -1: 100, | ||
Line 210: | Line 212: | ||
{ | { | ||
-1: 1, | -1: 1, | ||
− | -8: Ship, | + | -8: 'Ship', |
} | } | ||
-13: | -13: | ||
{ | { | ||
-1: 2, | -1: 2, | ||
− | -8: false, | + | -8: 'false', |
} | } | ||
-13: | -13: | ||
{ | { | ||
-1: 0, | -1: 0, | ||
− | -8: Any, | + | -8: 'Any', |
} | } | ||
} | } |
Latest revision as of 10:15, 18 February 2017
Contents
meta.smbpm
A metafile can contain a huge abundance of information about a blueprint.
Storage content, position and volume and shop prizes.
Also wireless logic connections, transporter, jump drive/inhibitor, scanner, shipyard, warp gates, race gate positions and targets, information about power, shields, display content, some block amounts, AI configurations.
And location and rotation of docked entities and stuff that is yet unknown.
The file is written using Big-endian.
A metadata file with of version v0 to v3 is considered to have positions relative to a core at (8, 8, 8). A blueprint might contain Smd files with a core at (16, 16, 16) and still have a metadata file of v3 or lower. In that case all positions of the metadata file need to be adjusted for positions to be consistent.
Header of file
Purpose | Data type |
---|---|
Version | int32 |
Data
After the version comes a tag. There are 7 known tags that indicate how the bytes that come after them are read.
The end of a file is reached if tag id '1' is read, or at the end of the tag id '2' data bytes.
A version followed by a 1 byte is the shortest possible metadata file.
Purpose | Data type |
---|---|
Tag | byte |
Tag | Data |
---|---|
1 | End of file |
2 | A collection of several Information. Is at the end of a metadata file and replaces tag '1'. |
3 | Position and orientation of entities docked to a Turret Docking Unit or Docking Module |
4 | Position and orientation of entities docked to a Rail and wireless connections |
5 | AI configuration, also contained in tag 2 |
6 | Rail Docker position and orientation. |
7 | Storage/Factory block positions and their volume |
Tag 2
A collection of several Information. Is at the end of a metadata file and replaces tag '1'.
The tag byte is followed directly by a tag structure.
A tag structure is defined by various tags that indicate a specific data structure.
For example '-13'/'13' indicates a list of tag payloads.
This is a summary of one possible structure:
13: 'container' { -13: {} // List of storage blocks and their contents 3: 'shipMan0' 0, // Location of Docking Modules, seems unused since > v0.1616 -13: {-6: 50000.0, -6: 0.0, } // Power, Aux Power 6: 'sh' 1000.0, // Shield -13: { } // shop info for stations, for ships: "1: 'ex' 0" up to v0.19498, an unknown int64 after that 13: 'a' { } // Logic (Buttons, Delay blocks) -13: {} // position and text content of Display Modules / Inner Ship Remote -13: {} // A short list of block ids and their amount -1: 0, // Warp gate info, unless it is a ship -13: { 13: 'ACD' { } // Wireless logic 13: 'TR' { } // Transporter 13: 'A' { } // Turret Docker. probably outdated since > v0.1867 13: 'A' { } // Entities docked probably outdated since > v0.1867 13: 'J' { } // Jump Drive 13: 'JP' { } // Jump Inhibitor 13: 'SC' { } // Scanner 13: 'SYRD' { } // Shipyard } 13: 'AIConfig1' {} // AI configuration, same as in tag '5' -13: { } // Hot-Bar Items -1: 0, // Race gate info, unless it is a ship -13: {} // unknown -13: {} // unknown }
Tag 3
This tag is followed by a list of information about docked entities.
Purpose | Data type |
---|---|
Number of docked entities | int32 |
Entity Position and orientation of entities docked to a Turret Docking Unit or Docking Module
Purpose | Data type |
---|---|
String length | int16 |
relative folder path | String[length * char] |
Position | int32 |
Size | [float, float, float] |
Style | int16 |
Orientation | byte |
Tag 4
Tag 4 starts with 2 vectors of float values. Metadata files with version two or higher will follow that with a list of Wireless_Logic_Module connections. And lastly, every version will have a list of positions and orientations of entities docked to a Rail.
Purpose | Data type |
---|---|
Unknown | [float, float, float] |
Unknown | [float, float, float] |
Wireless logic
For Metadata version 2 and higher wireless logic connection are listed here.
Purpose | Data type |
---|---|
String length | int16 |
Entity label | String[length * char] |
Number of wireless connection entries | int32 |
Wireless logic module entry:
Purpose | Data type |
---|---|
String length | int16 |
Label | String[length * char] |
Position (from) | int64 |
Position (to) | int64 |
The (x, y, z) positions are encoded into the int64 values. The bits 0-15 are x, 16-31 is y and 32-47 is z. Bit 48 to 63 are always 0.
Docked entities
For every version there will be a list of docked entities.
Purpose | Data type |
---|---|
Number of docked entity entries | int32 |
Docked entity Entry:
Purpose | Data type |
---|---|
String length | int16 |
Relative folder path | String[length * char] |
Tag structure size | int32 |
Tag structure | [Tag structure[size]] |
This is a tag structure example
-13: // Main entity { -1: 0, // Unknown, meta version 5. Some older v5 do not have it -8: 'MAIN_ENTITY_SHIP_Label', // Label -10: (16, 17, 16), // Position of Rail -2: 662, // Block Id, Rail Basic -1: 10, // Rail Orientation -1: 1, // Rail Orientation -1: 100, // Rail Hitpoints } -13: // Docked entity { -1: 0, // Unknown, meta version 5, sometimes -8: 'DOCKED_ENTITY_SHIP_Label', -10: (16, 15, 16), // Position of Rail Docker in the coordinate system of the docked entity. -2: 663, -1: 14, -1: 1, -1: 100, } -16: [[1.0, 0.0, 0.0, 0.0], [0.0, 1.0, 0.0, 0.0], [0.0, 0.0, 1.0, 0.0], [0.0, 0.0, 0.0, 1.0]], // Unknown matrix -16: [[1.0, 0.0, 0.0, 0.0], [0.0, 1.0, 0.0, 0.0], [0.0, 0.0, 1.0, 0.0], [0.0, 0.0, 0.0, 1.0]], // Unknown matrix -10: (16, 18, 16), // Position of Rail Docker of docked entity in the main entity coordinate system -16: [[1.0, 0.0, 0.0, 0.0], [0.0, 1.0, 0.0, 0.0], [0.0, 0.0, 1.0, 0.0], [0.0, 0.0, 0.0, 1.0]], // Unknown matrix -1: 0, // Unknown -1: 0, // Unknown -1: 0, // Unknown
Tag 5
AI configuration, also contained in tag 2 This tag is followed by an integer indicating the byte size of the Tag structure after it.
Purpose | Data type |
---|---|
Tag structure size | int32 |
13: 'AIConfig1' { -13: { -1: 1, -8: 'Ship', } -13: { -1: 2, -8: 'false', } -13: { -1: 0, -8: 'Any', } }
The tag structure contains three Tag payload lists. Each list starts with a byte representing:
Byte | Meaning |
---|---|
0 | Target |
1 | AI Type |
2 | Active |
The byte is then followed by a string:
AI types: "Ship", "Turret", "Fleet"
Target: "Any", "Missiles", "Selected Target", "Astronauts"
Tag 6
Rail Docker position and orientation.
Purpose | Data type |
---|---|
Number of Rail Docker entries | int32 |
Rail Docker Position and orientation of Rail Docker blocks.
Purpose | Data type |
---|---|
Position | [int32, int32, int32] |
Block id | int16 |
Orientation 1 | byte |
Orientation 2 | byte |
Hit points | byte |
Tag 7
Storage/Factory block positions and their volume
Purpose | Data type |
---|---|
Position | int64 |
Volume | Double |
The (x, y, z) position is encoded into the int64 value. The bits 0-15 are x, 16-31 is y and 32-47 is z. Bit 48 to 63 are always 0.