Changing The Blueprint Format: The Suggestion That Breaks Everything™

    Kimiro

    Metacreative Construct / Existentialist
    Joined
    Jun 10, 2015
    Messages
    35
    Reaction score
    18
    This suggestion is somewhat straight-forward, so this will be brief.

    The present system for saving block data in a blueprint (to the best the wiki has been updated and my own understanding) uses 24 bits, like so: 100110011001100110011001

    Bits 0-10 store the block ID (11 bits, 0 to 2047)
    Bits 11-17 store the block HP (7 bits, 0 to 127)
    Bit 18 stores the activation state (1 bit, 0 to 1)
    Bit 19-23 stores the block orientation (5 bits, 0-31)

    I propose that the system is switched to an 8 character hex-based save format, like so: f4b0b33f

    Block ID (0-4095)
    Increased potential block ID's available. More potential decorative blocks, animated blocks, colors of hull/armor etc. You could have a hundred or more of colors of hull, standard, advanced and crystal armor and still have loads of block ID's left over, especially when implemented with...

    Orientation (0-255)
    24 possible orientations for every block PLUS the additional option of up to 10 variants per block. Each block could have 10 different possible configurations/shapes on top of the orientation. This could allow for a concatenation of existing blocks somewhat (e.g. all the shapes of a block of Blue Hull could use 1 block ID with the shape determined by the multiple of the orientation - 00-23 could be full block, 24-48 could be the wedge etc.). This also means that every single block could, by default, have the option of a full block, wedge, 3 kinds of slab, corner, hepta, tetra and possibly something like an inside corner block, meaning adding in custom blocks could be simpler since the alternate shapes would be pre-defined - you just have to provide a texture for each face of a cube and the game could handle the rest, making the additional shapes for you.

    Activation State (0-15)
    Non-binary activation state means things like logic-controlled AI modules could become possible. It also means that logic could operate on a 4-bit signal strength system, in a manner not too dissimilar from MineCraft's Redstone, allowing for even more possibilities with logic.

    Block HP (0-255)
    An increase over present values. Additionally blocks without an activation state could use that bit as an additional value for HP, meaning basic blocks like Hull could be tougher without requiring an armor value.

    Obviously this would break every existing blueprint so some sort of converter would have to be made, but yeah. That's the gist of the idea.
     
    Last edited:

    jayman38

    Precentor-Primus, pro-tempore
    Joined
    Jul 13, 2014
    Messages
    2,518
    Reaction score
    787
    • Purchased!
    • Thinking Positive
    • Legacy Citizen 4
    I have to disagree with this suggestion. This goes from a 3-byte system to a 16-byte system. :eek:
    We're already nervous about a move up to 4 bytes.

    If I were to make an immediate change, I would go ahead and up the count to 4 bytes, and merge the orientation bits with the Block IDs, so each orientation would be its own Block ID. Not every block needs all 24 different directions, and 24 orientations within a 32-bit dataspace is wasteful, so this would increase Block IDs into at least the 5-digit count, and the game could be reprogrammed, so that the change from orientation to Block ID could be handled behind the scenes. (Maybe within a new XML configuration file.)

    I like multiple activation states.

    So, if I had my way:
    8 bits HP
    4 bits activation
    20 bits Block IDs (at least 260,000; even if every last block was given all 24 orientations, it's the equivalent of almost 11,000 Block IDs in the current orientation system.)
     

    NeonSturm

    StormMaker
    Joined
    Dec 31, 2013
    Messages
    5,110
    Reaction score
    617
    • Wired for Logic
    • Thinking Positive
    • Legacy Citizen 5
    I propose that the system is switched to an 8 character hex-based save format, like so: f4b0b33f
    I have to disagree with this suggestion. This goes from a 3-byte system to a 16-byte system. :eek:
    We're already nervous about a move up to 4 bytes.
    1 hex char is 16 possibilities or 4 bits. 8 hex-chars are 32-bit or 4 byte!!

    If I were to make an immediate change, I would go ahead and up the count to 4 bytes, and merge the orientation bits with the Block IDs, so each orientation would be its own Block ID. Not every block needs all 24 different directions, and 24 orientations within a 32-bit dataspace is wasteful, so this would increase Block IDs into at least the 5-digit count, and the game could be reprogrammed, so that the change from orientation to Block ID could be handled behind the scenes. (Maybe within a new XML configuration file.)

    I like multiple activation states.

    So, if I had my way:
    8 bits HP
    4 bits activation
    20 bits Block IDs (at least 260,000; even if every last block was given all 24 orientations, it's the equivalent of almost 11,000 Block IDs in the current orientation system.)
    I would make orientation a part of hp instead. 8 orientation bits would save 2-3 hp bits.
    8 sub-blocks which share ID (so same armour, colour, …) would increase the amount of hp to 4 or 8 times (to repair, use the shape from blueprints)
    Wedges use 6/8 sub-blocks, ramps 4/8 diagonally, corners 4/8 in a corner-cross)​
    Furthermore, logic could use these 8 hp bits for logic as long as the block is full-hp (a 9th bit is "1/on") and taking damage would disable this "advanced logic".
    Edit: 1'xxxx'xxxx would be logic,
    Edit: 0'ssss'ssss would be sub-blocks (8x full hp + partial hp bits)​
     
    Last edited:
    Joined
    Jul 30, 2015
    Messages
    11
    Reaction score
    1
    • Purchased!
    how about adding meta data? like for factories and storage autopull setup?
     
    Joined
    Jun 24, 2015
    Messages
    385
    Reaction score
    59
    I'll begin by saying that that was pretty well thought out, and if it were up to me (be glad it isn't) they'd be switching to this right now.


    However, you did make one error.
    Block HP (0-255)
    An increase over present values.
    (If this isn't a simple typo, ex: you left out some numbers in the 0-to-# section, then: )

    Nope! HP currently *does* go right on up to 255, exactly one block in the game uses it. The faction module.
     

    Kimiro

    Metacreative Construct / Existentialist
    Joined
    Jun 10, 2015
    Messages
    35
    Reaction score
    18
    I'll begin by saying that that was pretty well thought out, and if it were up to me (be glad it isn't) they'd be switching to this right now.


    However, you did make one error.

    (If this isn't a simple typo, ex: you left out some numbers in the 0-to-# section, then: )

    Nope! HP currently *does* go right on up to 255, exactly one block in the game uses it. The faction module.
    Honestly I don't actually remember posting this thread at all, so errors don't surprise me. That said however, the wiki does seem to agree with what's posted in the OP, at least with regards to the latest changes.

    Also, having read the OP and the rest of the thread, another thing does seem to occur to me: I think the potential performance issues could be resolved if each block was stored in a sort of... Array. Like...

    #ff7382fe
    11,22,33; 11,-22,33; 27,18,99

    #fe72f387
    45,19,22

    Unfortunately this means that damaging blocks would bloat the array rather heavily, but conversely it would drastically reduce the size of the BlockConfig and require fewer lookups in there (since each shape wouldn't require an entry in there, just a single one for the block category defining max HP, armor, name, ID, mass and texture faces).

    Possible alternative to avoid bloating the array on damage is to give each block 4 coordinates rather than 3 - the 4th "temporal" coordinate could store the HP bits.
     

    NeonSturm

    StormMaker
    Joined
    Dec 31, 2013
    Messages
    5,110
    Reaction score
    617
    • Wired for Logic
    • Thinking Positive
    • Legacy Citizen 5
    Do you differentiate between "Structure of Arrays" and "Arrays of Structures"?
    AoS:
    1. 0x00 int, 0x04 *string, 0x08 byte
    2. 0x10 int, 0x14 *string, 0x18 byte
    3. 0x20 int, 0x24 *string, 0x28 byte
    inline: int,*string,byte,int,*string,byte,int,*string,byte
    SoA:
    • int
      • 1: 0x00, 2: 0x04, 3: 0x08
    • *string→string
      • 1: 0x10, 2: 0x14, 3: 0x18
    • byte
      • 1: 0x20, 2: 0x21, 3: 0x22
    Mixed:
    AoS for int,byte but a separate array for *string→string references
    Split SoA is more efficient for a pipe which feeds arguments to the same operation.
    Grouped AoS is more efficient for a stream of objects to stream processors.

    The GPU is a stream processor, te CPU prefers the opposite for less memory accesses (only load data which is needed by the current operation).

    I see a higher efficiency gain from switching from ray-casting to polygon-casting. To not process every pixel, but outlines of shapes with equal content.
     

    Kimiro

    Metacreative Construct / Existentialist
    Joined
    Jun 10, 2015
    Messages
    35
    Reaction score
    18
    Do you differentiate between "Structure of Arrays" and "Arrays of Structures"?
    AoS:
    1. 0x00 int, 0x04 *string, 0x08 byte
    2. 0x10 int, 0x14 *string, 0x18 byte
    3. 0x20 int, 0x24 *string, 0x28 byte
    inline: int,*string,byte,int,*string,byte,int,*string,byte
    SoA:
    • int
      • 1: 0x00, 2: 0x04, 3: 0x08
    • *string→string
      • 1: 0x10, 2: 0x14, 3: 0x18
    • byte
      • 1: 0x20, 2: 0x21, 3: 0x22
    Mixed:
    AoS for int,byte but a separate array for *string→string references
    Split SoA is more efficient for a pipe which feeds arguments to the same operation.
    Grouped AoS is more efficient for a stream of objects to stream processors.

    The GPU is a stream processor, te CPU prefers the opposite for less memory accesses (only load data which is needed by the current operation).
    I see a higher efficiency gain from switching from ray-casting to polygon-casting. To not process every pixel, but outlines of shapes with equal content.
    So... An SVG-esque way of saving ship data?
     

    NeonSturm

    StormMaker
    Joined
    Dec 31, 2013
    Messages
    5,110
    Reaction score
    617
    • Wired for Logic
    • Thinking Positive
    • Legacy Citizen 5
    So... An SVG-esque way of saving ship data?
    Scaleable vector graphics? SVG is a ratio "like 1/10 of width" whereas IDs, HP and stuff is "counting up"
    This and that I don't know "esque" makes it impossible to answer your question.

    Polygon-casting can be similar to SVG, but I would compare it to "throwing shadows" of vision but using outlines instead of pixels.​