User talk:Dexter0

Hi, I'm dexter0. I specialize in Mac/iOS development with Objective-C and am mostly interested in the on disk representation of minecraft worlds.

Schematic 2
The original schematic (referred to as Schematic 1) format has served the Minecraft community well for the past two years. Recent updates the storage format used by the official client have added capabilities that can not be matched by the current Schematic format. Since the primary purpose of the Schematic format is to provide a lightweight method for moving parts of one Minecraft world into another, it is imperative that the format be able to match the capabilities of the Minecraft world format (to be referred to as the official format).

Schematic 2 is a proposed update to the existing Schematic format designed to bring the format back up to capability parity with the official format. The current format proposed here (should [untested as of now]) maintains backwards the ability to be read by software supporting Schematic 1.

List of Requirements
The Schematic 2 format as defined here meets the following requirements.
 * Support block codes up to 12-bits in length.
 * Define a NULL block code which represents a block that will be ignored upon importing the schematic into a world or another schematic.
 * Provides storage for metadata as well as additional data not directly relevant to the format but which may be useful for mods or tools.
 * Support extensions to the format in a way that does not break compatibility.
 * May be read by software supporting the Schematic 1 format.

Storage Format
Schematic 2 defines how the stored data must relate but does not define how the data must actually be represented on disk. Of course, to maintain backwards compatibility, NBT will be used for serialization and deserialization.

Structure
Schematic 2 relates data as a node tree. Nodes are defined as part of the spec or an extension. They contain data (referred to as attributes) required by their spec as well as additional data (if allowed) and related child nodes. Every piece of data in a node is associated with an identifier which is defined as part of that node's spec. Child nodes are identified by their identifier which is part of the child node's spec. Thus there can be more than one child node with the same identifier but they will always refer to the same node type.

All nodes must contain the following property
 * LastModified (long): Unix timestamp of the last point in time the node's attributes were modified.

Protocols
A protocol is a collection of properties which a node that adopts said protocol is must contain for the node to be valid. In practice this is a formalism, Schematic 2 does not define any way for a node to declare support for a protocol. Rather it is inferred from the node type. Protocols are a convenience for tool and extension developers.

TODO
Optional Attributes, Extensions, Compatibility

Schematic 2 Core
This is the core specification of Schematic 2.


To be adopted by node types which contain block data.

Attributes
 * Width (short): Size along the X-axis
 * Length (short): Size along the Z-axis
 * Height (short): Size along the Y-axis
 * Blocks (Byte array): Block codes, 8-bits per block.
 * BlockAdd (Byte array): Block code upper bits, 8-bits per block.
 * Data (byte array): Block metadata, 8-bits per block. Only the lower 4-bits should be used if the schematic is to be imported into official maps.
 * TileEntities (list): List of compounds defining tile entities. Same as official format.


To be adopted by node types which contain entity data.

Properties
 * Entities (list): List of compounds defining entities. Same as official format.

Root
This is the root node of the file.


 * Identifier: Schematic
 * Child Of: None (root node)
 * Adopted Protocols: ,
 * Optional Attributes: Allowed (some suggested ones below)
 * Name (string): A name for the schematic.
 * Author (string): Author of the schematic.
 * Attributes
 * Version (byte): Should always be 2.
 * Materials (string): Same as Schematic 1. For backwards compatibility.  Schematic 2 clients should never use the contents of this property.

Schematic 2 Extensions
Extensions are child nodes that are not part of the Schematc 2 core specification but are supported by one or more applications. It is expected that all extension data is preserved when a file is saved even if the application does not support that particular extension. Certain extension nodes may only be attached to specific parent nodes as defined by the extension's spec.

To prevent conflicts, all extensions must use a reverse domain name for their identifier.

Preview
The purpose of this extension is to allow previewing systems of modern operating systems (such as QuickLook on OS X) to present a preview of the schematic file without requiring a complete load of the schematic as well as subsequent tasks which may be computationally expensive such as creating an offscreen OpenGL context to render a image. Instead, this extension stores data that can be used as a preview of the file. Examples of such data may be an image of the structure contained within, or perhaps MIDI data if the schematic contains a note block creation.


 * Identifier: com.dexter0.preview
 * Child Of: Root
 * Adopted Protocols: None
 * Optional Attributes: Not allowed.
 * Attributes
 * Type (string): MIME type of the Data.
 * Data (byte array): Data used for the preview. To be interpreted as specified by the Type.