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! P.S: copied from the ror forum.
Well, the set_beam_default and the modifiers in the beams sections of a JBeam are actually one in the same. A way I saw a VERY old editor get around this is they would make sections of nodes and beams called "groups" (in their editor... not the same as the groups that JBeams use now adays). You would then apply properties to these groups which would be exported as a set_beam_defaults section as the first line of that group (in a .truck file obviously) and the group name would just be nothing more than a comment designating what the group was. This same principle was also used on shocks and hydros to give them their properties as well. Seeing as you are making an editor from the ground up, what you could do is just set these as some sort of variables. Both variables would serve the same purpose in RoR or Beam (like spring, damp, so on and so forth) and would just be exported in their respective formats depending on what file type you choose. I'm not saying you have to do this... but it might be a way to go about adding this functionality if you so choose to do so down the road.
For the core code, I won't be implementing this, like I said, I want it to be just for dealing with n/bs. But this is possible using the plugin system, The Editor loads the jBeam format, and stores it in memory, it takes nodes and beams and converts them to the editor's format for editing and when done, it converts them back to jBeam and just replaces the nodes and beams in the memory and save the jBeam, everything else stays there, and the plugin system has access to that jBeam in the memory, has access to the editor's format, and has access to make windows and their own GUI etc... So in theory, it is possible to actually do what you are saying at the plugin level
I think I understand what you are saying... Just so you know where I am coming from here... I have basic programing understanding... I am very good at the math and have a good grasp on the concepts... just not so great at the language. So... when you state that your editor is dealing "exclusively" in just the nodes and beams does this mean, judging by your description, that it will exclusively deal with the nodes and beams sections and basically just "hold on" to everything else in the file until you are done editing it, and then when its time to export, it will just drop everything back in while only (basically) updating the nodes and beams sections? If so then yeah, I wouldn't have any issue with that. In my mind that should work perfectly fine. That is a similar manner to how the REALLY old Editorizer used to work... kinda. You could add set beam defaults into it, but if you saved and then reloaded the same file it wouldn't import any of it, so all that information would be lost regardless. That is a much bigger deal in a .truck file than in a JBeam file though as in a JBeam, you are usually only dealing with one component of a car while in a .truck file you were dealing with the vehicle in its entirety. Losing all that data can be a massive pain on the RoR side, but on the BeamNG side... ehhh not so much. I can definitely see how importing these parameters can be a bit of a pain though. Nodes, piece of cake... you have the name and the 3 coordinates boom. Beams? Same deal... 2 names to connect... boom. Dealing with set_beam_defaults and all its parameters which may or may not come in the same order, or on the JBeam side, the even more random nature of the Advanced Beam Properties can be a pain to attempt to account for. There was a goofy modification made to the Editorizor one time (I have no idea how to go about finding the thread anymore... it might not exist) where to keep from losing the set_beam_defaults, they were imported into the node list as a comment. If you wanted you could change what the comment said which would, in turn, basically just manually set up the set_beam_defaults. Then, on export, it would just export them as a comment just like it imported them. It wasn't perfect, but it at least kept you from losing all that work. Again, this was a bigger deal back in the RoR days, but still. Edit: I went in and "attempted" to read the code to see how you are going about importing everything and how your are storing stuff. Again... I am no expert coder... I am... at best... elementary. From what I can tell it looks like you are importing the nodes into an array, which is what I would do as well as that's the easiest way to store the information. The issue comes when you come to one of the set_node_befaults or set_beam_befaults as... well... it has all the wrong information. I am assuming there is a filter somewhere in the loop to skip these lines when it gets to them... but I missed it. The only way I can see to "possibly" import something like this would be to use that filter to set some variables like spring and damping. Each time it runs across a new set_XXX_defaults it could update these variables with new numbers. These then would be added to the nodes/beams arrays as just extra information so each individual node/beam would have extra information individually stored. Granted... that's not the hard part. The hard part is how do we get it back out in a proper manner. You could just export the information on every single node/beam... as that's an option... but it would look horrific in the file and who knows how that would run in game. Would probably take a lot longer to load. It would almost need a filter to detect when the parameters change, and when they do, it takes those new parameters, exports a line with the new parameters, and then carries on exactly as it was with exporting the nodes/beams... but again this can be a pain to deal with. I am just spit balling ideas though. You don't have to do any of this at all as at the moment I see this more of a development tool... like... when your starting from scratch, you use this to set up your n/b structure first... everything else gets added after... and for that it works perfectly.
The current RoR importer loads set-xxxx-defaults just fine, it actually pushes them to an array and sets the nodes/beams as childrens by their IDs (the editor assigns and ID to a beam) As for jBeam, it's much easier since jBeam is just a modified JSON format, so the editor is already aware of them but does nothing to them. This is where the plugin system comes in, it takes that information and provides a user to either modifiy it, or create a new one and asign it to a group of nodes/beams.
Just saying since Node.js 14 LTS will stop maintenance at April this year, could I use newer versions like 19 or newer?
