As far as I can find in the documentation, Windows/Media3D is right-handed and Unity is left handed, so flipping the z-axis makes some kind of sense. However, I still get weird results. My Corner variant geometry is incorrect, the point should be in the opposite corner, in most instances of SV_Prefab_Tier6, but in at least one place it is correct and in my generated pyramid blueprints, that works in game, they are all correct. Edit: The Y-axis appear to be up in both, so I don't think I need to swap them.
Ah, nice. Just posting about it made me find the issue. The geometry of Corner was indeed incorrect. Now it looks right in both SV_Prefab_Tier6 and my pyramid.
Added more geometry. Now I can make models in Wavefront OBJ format and convert to C# code to insert in EPBLab.
I have no plans for this at the moment. The command line tools should work on Linux already but the gui will not. I don’t really know how or if WPF can be made to run on anything but Windows. The epb command line tool requires mono and the ecf command line tool requires dotnet core. Converting epb to dotnet core is probably easy but EPBLab, the WPF application, is more difficult to port.
I see. Well as time passes more and more migrate from W7 to Linux, instead of Candycrush OS W10.Proton helps tons lately. Anyway, thank you.
As I was updating the block types and variants for A10 I realised that the weird thing about truss and window blocks, among others, has to do with the "parent block" or "TemplateRoot" as it is defined in Config_Example.ecf. For these blocks, there is only a total count of the parent block and not the individual trusses or windows. I am still not sure how to determine which blocks should get individual counts, for example "HullFullSmall", "HullThinSmall", "HullExtendedSmall", "HullExtendedSmall2", "HullExtendedSmall3", "HullExtendedSmall4" and "HullExtendedSmall5" appear to be counted individually even though they have a parent in "HullSmallBlocks" (380).
Can I use this tool to clear dead signal values? I had a oopsie when I used the copy/paste tool and now all my signal names are reserved but unusable.
I haven’t made any interface for changing signal names, but in theory that shouldn’t be too difficult to do. Currently it only reads the logic stuff. Tomorrow I can take a look at it to see how much work it would be.
Right now there is an issue if you copy/paste something with signal blocks, the signal logic is "dead". That means the logic still reserves the names, but the signal names don't do anything (and cannot be attached to signals).
I realised that my code can't even write the signal logic. It just wrote zero in a lot of length indicators. I am trying to amend that now. This might take a little while.
After more investigation and trying to make my code save more data I see that this will take a lot of time to get right. There are several sections of data that I don't understand the use for - I think that I see the data structure, but I don't know the semantics. I handle this by reading the data, if it exists, but not writing it when saving a blueprint. This means that running a blueprint through my program will "wash" away everything that I don't understand. The resulting blueprint should still be functional but some features of the original blueprint will be gone. If I were to simply add writing of the SignalSource data, it would be simple to change the names. However, since I don't write the SignalTargets or the SignalOperators (circuits), you will lose all that logic when passing the blueprint through my software. Even if I add those, there are still others, for example the BlockTags - these specify the text on LCDs among other things. I added code to write the SignalSources and that required a way to write tag lists, so I also added the BlockTags section - this uses a lot of the same code. Unfortunately, this broke something. I can no longer read the blueprint in game. I don't know exactly what went wrong, but I am investigating. One thing I saw is that the block references are somewhat different in the tag list. I read these as a bit pattern that yields X, Y and Z as eight bit integers as well as two four bit integers of unknown use. In the tag I set up in my example, these unknown properties have a value of 8, but as I write them, these get reset to 0. If this is the issue, I have to do more research trying to figure out what these values actually mean. I wish I had better news, but it seems as my program won't be an effective "washer" without significant data loss in quite some time. EDIT: Just saving a blueprint with a "lever" in it becomes unreadable by the game. It tries to read past the end of the file...
I think that my library can now save everything for file format version 20. This takes it one step closer to be able to do things like processing existing files, i.e. changing just one thing in the blueprint while keeping all the rest intact. Note that there are currently three more versions of the file format adding new stuff like custom palettes and filler blocks. My library can't write these yet. Loading and saving blueprints of version 21, 22 or 23 may result in data loss. Another potential issue is that my code changes the order of some things. This happens because I don't store them in an ordered manner - at least not the same order as the original file. I am pretty sure that this does not matter as the references are inherently unambiguous. Examples of this is signal targets that are always sorted alphabetically on the signal source name and tag lists that are sorted by the .Net Dictionary class. The bug mentioned above, about saving levers resulting in broken EPB files, was caused by the value I named Unknown05. When I created a blueprint with a lever, I also added the appropriate devices in the device group list but my code always set Unknown05 to 4. Now I know that this value defines what fields are present in the group entries. >=4 means that the shortcut field is present. >=5 means that a new unknown field (currently named u3) is present. So my code now forces this value to 5. This discovery made the weird tests against build number unnecessary.
Just showing some progress on the block geometry: I have some funky normal issues that become apparent on some of the block shapes. I think that this is because I still don't do the right-handed to left-handed coordinate system conversion correctly.
I am not sure what you mean. As in a pre-compiled binary? As far as I am concerned it is already “out”. I suppose that I could upload a binary release to github if people want that. However I can’t really test it since all my computers have developer libraries installed and are therefore not representative of “everyone’s” systems.
I see. Well then it may remain out of reach of those who do not compile often or they don't compile at all (99% of players). Thank you.
Yes, I understand this. My initial intent was not really to make a polished user interface. My interest is mostly about figuring out how the file format works and provide a library resource for other developers that may have specific applications in mind.
