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.
Last active
November 25, 2025 23:00
-
-
Save JimmyCushnie/bebea37a21acbb6e669589967f9512a2 to your computer and use it in GitHub Desktop.
Author
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
Author
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
01indicates an input peg,02indicates an output peg, and the other values for that byte are undefined/reserved.
Author
This gist has moved! Find the file spec on the wiki now: https://wiki.logic.world/wiki/Blotter_File_Format/v7
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.