nodeSnap: the new truck file editor

Max98 said:
Hello everyone,
I just wanted to ping this so yall know it's still alive, as for the editor itself, a lot of things have changed.
When I started writing the importer for jBeam files, I noticed a big limitation in the editor's way of dealing with n/bs, and it required some heavy changes to the architecture etc...

So, I decided to do some researching and dive back into the code.
But since IMO the last release was kind of buggy, I'm taking a lot of steps back and removing some features to actually fix the 'base' once and for all, and then I'll be putting the other features back, that just means the next release would be pretty basic compared to the one already released, but it will be much faster.

An other thing I have to say, when I started writing nodeSnap, I was too consumed to implement as much features to make Truck files editing easier, that entangled the editor to the truck format and caused some problems later on, now the editor has it's own format in JSON at the cost of just editing nodes and beams only, nothing more, nothing less. (You will have to set_beam_default by yourself)

Some major points to note here:
  • The way VueJS handled data and did things was a bottleneck and costed a lot of performance for this kind of application, so I switched to React JS, and gained a huge bump to performance and probably fixed the memory leak problem (not confirmed yet, but I've been using it, and I didn't notice this problem).
  • Switching from Electron to Tauri also fixed an other major problem: application size. With this, I managed to get down from 163 MB (60ish MB compressed) to just 8 MB uncompressed!
  • Tauri also provides native coding using Rust out of the box, I did not use this yet for performance gains, but I'm planning to profile the whole application and move some code from JS to Rust. (Rust is a language comparable to C++ in performance)
  • I have implemented a simple plugin system with plugins written in JavaScript (not typescript) that will allow manipulation of the loaded n/b and do some other stuff... currently still brainstorming about what we could do this with.
  • Implemented a selection box system that will allow you to select many nodes with the mouse and perform actions.. (move, delete, scale..?)
  • nodes2 supported out of the box
  • jBeam format will be supported of the box, conversion between truck format and jBeam possible in both ways (again, just n/b)
If you have any issues to report or suggestions, it's about time!
Click to expand...
Excellent progress! It is always nice to hear that these new editors are still getting some love!

Things to note.

Since this editor is designed to work on both platforms, it may be a good idea to have any RoR export just export as nodes2 only. Even if the truck is imported as a classic nodes vehicle, it should probably still export as nodes2. The functionality is identical in every aspect except that nodes2 just uses strings for the node names rather than numbers... even if you decide to just leave the old numbers intact. So if you are modifying a truck (outside of the editor) and want to remove a node... there is no need to go back through the truck and rename EVERY node after that plus going through and updating every node name in every beam because they all got renumbered... with nodes2, just delete the node, then search the file for that node name and delete every beam that connected to it... done. No renaming anything, no digging through and spending hours basically just rebuilding the truck from the ground up... moding RoR before nodes2 was a royal pain if you made a mistake back in the day.

Honestly, I never understood why this change in functionality wasn't just added into the nodes section of the game rather than reinventing the wheel and making an entirely new section... but its too late now and we are far too deep to do anything about it, so while nodes and nodes2 could be made to be identical so solve that issue, neither can be removed due to how many mods use one or the other (or both as that is also an option).

This will also make your conversion system much easier as if you go from JBeam to RoR and the user for some reason wants to use nodes, you lose all the node names that were made to identify what on earth the thing was in Beam, and then your system would have to renumber every node and every beam... which isn't that big of a pain... but if you could just take the entire nodes section from the JBeam and change it to nodes2 for the .truck file and just export it (a little more than that but you know what I mean) it would make things much simpler.
 
Hi @Max98,

It's awesome to hear the project is going and maturing. The bulkiness of Electron always made me uneasy, migration to Tauri (as the sole emergence of Tauri) is fantastic news. Just for the record, here's a GitHub link: https://github.com/Max98/project_nodeSnap/tree/mk2_dev because it's under a branch, I only found it on second look, the repo main page looks pretty stale.

I know what you mean with the 'set_node/beam_defaults' and generally the mechanics of truck fileformat. I battled it myself ever since I joined the project. I tried creating a blender-style builtin editor but the "line-by-line parsing with global state" mechanic of truck format was in my way. I forced my way through by writing a truck parser which inverted the logic, parsed 'set_*_defaults*' to separate objects and then linked them to individual nodes and beams. Oh, and same thing with 'section/end_section', I inverted that too. It all caused far more problems than it was worth, for several next years half the mods were broken, in the end the RigEditor never got finished and I kept finding out additional flaws in my approach. Now after all the years I'm giving up and I'm going to restore the parser to the original mechanic. Just a few days ago I merged https://github.com/RigsOfRods/rigs-of-rods/pull/2829 which wiped a lot of old dust from my failed code and in next step, I'll restore the sequential handling.

I'm not familiar with jBeam and until now I had no motivation to look at it. But if your project introduces a metaformat which abstracts both (the way I understand it), it may be interesting to know. Anyway, I assume jBeam has some kind of 'presets' for node and beam parameters, just handled differently that set_*_defaults, so your metaformat will eventually introduce such mechanic too.

Just about a year ago I found out how powerful was the combination of 'nodes2' and 'section/end_section' in the original parser. I tried to describe it technically here https://github.com/RigsOfRods/rigs-of-rods/issues/2881, but the gist is: while 'nodes' get their numbers statically, so you can't just put 'section/end_section' somewhere in between and add more, with 'nodes2', you can - and it seems they were designed specifically for this purpose. nodes2 get their numbers assigned at spawn, depending on selected sectionconfig. But beams are attached via names, not numbers, so the variable number doesn't matter in any way. I was blown away when I figured this out. Unfortunately, it was never documented and I was unable to figure it out from the code at first, only now when forced to study it with patience and humility. Ironically, it provides exactly the kind of flexibility I tried to archieve with my 'inverted' parser. It's Karma I guess.

TL;DR: At this point I'm intimately familiar with the truck format, it's strenghts and it's quirks, so if you need assistance transforming it to/from your internal representation, just get in touch. I won't have time to test nodeStap in the next 2 weeks, but eventually I'll take a look.

Be of cheer!
 
I am not perfect, but I am pretty well versed in both .truck files and JBeam files... so that goes for me as well. If you ever have any questions about what does what you can hit me up either here or on the Beam forums (same name).
 
You must log in or register to reply here.
Back
Top