Blotter File Format.md

The Blotter File Format spec has moved!

Hello!!! This gist used to contain the spec for the Blotter file format (save files used by Logic World). But that info is now hosted on the Logic World Wiki.

Go to the wiki instead: https://wiki.logic.world/wiki/Blotter_File_Format/v7

Please keep in mind that this is still subject to change before release. It might not, but also it might.

Changes since Draft 0:

• A list of mods, with versions, which affect the save is now present
• Peg indexes now use ints instead of bytes, as the game now supports >255 inputs/outputs per component
• Input exclusivity is no longer stored, as exclusive inputs have been removed from the game
• If a component does not have custom data, -1 can be written for the byte count instead of 0. This indicates null rather than an empty array.
• Improved some formatting

Quick question: would you mind if projects implementing BlotterV5 include a copy of this readme and is there a license or copyright notice that should also be included?

I hereby release this document & the file format itself into the public domain.

            DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE 
   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 

  0. You just DO WHAT THE FUCK YOU WANT TO.

Knock yourself out :)

quality licence.

I am very fond of WTFPL, it perfectly captures my attitudes towards open source and towards software in general.

Joho, I just wrote my own parser for this file format for the first time.

And I stumbled across some issue, which makes parsing be much more bloated for me.

We have the Circuit-State section in this file, which can live by its own without issues. It does not depend on anything.
But wires and components do depend on it. Sadly they appear before Circuit-States in this format.

In my project (OpenTUNG), circuit states have a different form. I choose an Object Oriented solution here.
That means, that there are no CircuitStateIDs at all. I only care for the Output-Pegs states (on/off) and generate the rest of the network with only these. That would normally be a quick lookup into the circuit-states + the simulation post processing/validation.
But these have not been loaded yet. The file also does not provide me any means to skip to there quickly.
So I have to either skip all the component once, by reading them. And then processing/loading them again later.
Or create a temporary data structure for each output-peg to update its powered state later on.

Either way, this is overhead, which I would not have, if Circuit-States are listed before Components.

So maybe consider this when BlotterV6 gets released, it would make the parsing for some third-party parsers much more easy.

---

Another question:
Do components need more pegs than 65K? I think even for modding, that might be a bit over the top.
So if there are no plans to compress the file by default, one could shrink the peg count down to 2 bytes. That is 4 less bytes per wire and component. But for small worlds we are only talking about KB optimizations. So its just an idea.

Changes in Blotter v6 (used since Logic World v0.91):

• Instead of saving component local positions as three floats, we now save component local fixed positions as three ints
• Subassembly files may now have multiple root components

Changes in Blotter v7 (used since Logic World v0.91.2):

• The first byte of a serialized Peg Address is no longer a boolean with true indicating an input peg and false indicating an output peg. Instead, a value of 01 indicates an input peg, 02 indicates an output peg, and the other values for that byte are undefined/reserved.

This gist has moved! Find the file spec on the wiki now: https://wiki.logic.world/wiki/Blotter_File_Format/v7