Fantastic work! Also, not to detract from the other features you added, but that last feature that allows you to just slap a node down on the mesh surface is insanely cool! Well done! Looking forward to more progress!
I 100% agree. Will make jbeaming a much faster process as there will be less trial and error of node placement etc.
jibbim slep. OT: This looks amazing. im definitely gonna try it out and maybe make a mod (idk) once its done, notepad++ can take a break lol
Update #5 Things Added: GUI makeover Got rid of unpleasant Unity UI Now using Dear ImGui for pretty much all GUIs (except one button and one UI text element) Now can generate JBeam Files, Parts, Beams, Triangles, and Scope Modifiers This means you can create JBeams from scratch now! (though I still haven't added an exporting functionality) Now can delete JBeam objects Now imports all Beams and Triangles, regardless if its dependent nodes aren't imported (e.g. beam's nodes are defined in another JBeam file) In the JBeam inspector, any missing nodes will be highlighted in red text Now imports JBeam Table Row Modifiers and Scope Modifiers (learn more here: https://documentation.beamng.com/modding/vehicle/intro_jbeam/jbeamsyntax/#out-of-bounds-modifiers) JBeam items will always reflect Table Row/Scope Modifiers Moving an item around in the hierarchy will update its inherited Modifiers For example, if you place a node below a Scope Modifiers item, the node will inherit the Scope Modifiers. If you then move the node above the Scope Modifiers item, the node will no longer inherit the Modifiers. You can override Scope Modifiers by adding Table Row Modifiers to an item (e.g. Node, Beam, Triangle).
Fantastic work! This is turning out VERY well! The only thing I will note (and this is super minor) is that currently in the stack you have everything listed, which is fine, but the Scope Modifiers just say "Scope Modifier" in your list. Once you click on it, all the information about it pops up in the list on the right, but that could end up being slightly confusing in terms of actually remembering what each of those scope modifiers does. Now, you may already have this planned, and if so you can just ignore this, but perhaps you could have a line after "Scope Modifier" just listing which scope modifier it is. So like... "Scope Modifier {nodeWeight}" just so you know what that one does. You can click on it to find out what the actual value is if you want to find it in your other menu. Or... perhaps you could have the info come up as a popup when you hover over the "Scope Modifier" in the list. These are just suggestions and are not really necessary as you already have all the information available exactly as you have it... I am just trying to think of the easiest way to get that information to the user.
Yeah I think I'll make a popup when hovering over the scope modifier item to preview what the scope modifier values are. I'm also thinking of combining scope modifier items in sequence as one scope modifier item and exporting them as such, since one scope modifier item can contain multiple modifiers and to shorten the sections' lists (I noticed inconsistency in the JBeam files where sometimes multiple scope modifiers would be defined in one item/line and other times they would be defined in multiple items/lines of one modifier per item). But I'm just thinking if you think it'd be a good idea or if there's any reason why it might not be a good idea to do this.
Well, as far as formatting goes and how the game reads the code, this... Code: ... "nodes": [ ["id", "posX", "posY", "posZ"], {"nodeWeight":1.668}, {"nodeMaterial":"|NM_METAL"}, {"collision":true}, {"selfCollision":true}, {"group":"Body"}, {"frictionCoef":0.05}, //lower floor ["b1ll", 1.09300, -1.08056, 0.53692, {"selfCollision":false}], ["b1l", 0.53663, -1.08583, 0.53100], ["b1r", -0.53663, -1.08583, 0.53100], ["b1rr", -1.09300, -1.08056, 0.53692, {"selfCollision":false}], ... and this... Code: ... "nodes": [ ["id", "posX", "posY", "posZ"], {"nodeWeight":1.668, "nodeMaterial":"|NM_METAL", "collision":true, "selfCollision":true, "group":"Body", "frictionCoef":0.05}, //lower floor ["b1ll", 1.09300, -1.08056, 0.53692, {"selfCollision":false}], ["b1l", 0.53663, -1.08583, 0.53100], ["b1r", -0.53663, -1.08583, 0.53100], ["b1rr", -1.09300, -1.08056, 0.53692, {"selfCollision":false}], ... Would actually execute exactly the same. The only reason that a lot of times the Dev's appear to make them in lists rather than just one long line is literally just because it is easier to read. Which when you are constantly coming back and making changes like the Dev's do, it is rather important to have all the information front, center, and easily digestible. One thing I would like to note is that this is code off one of my projects and not a Dev vehicle... I am sitting at work and this was just the easiest attainable code I had. EDIT: Side note, perhaps the way you could make your list shorter is by changing Stack Modifier to Stack Modifiers, making it another level of dropdown, and then under the dropdown you could directly list each of the modifiers under that Stack. This way the list could be shortened, the stack could be directly edited by just selecting Stack Modifiers and then changing anything you want directly in the side panel like you already have, or if you drop it down to see all the modifiers, you could directly click on the modifier you plan to edit and have that auto scroll to that particular section in your menu on the right... In my head that made much more sense so I hope that came across well. EDIT 2: Actually, there is a spot where they frequently throw everything on one line... Note: This is the end of a Beams section... Code: ... ["b13rr", "b14r"], ["b14r", "b13"], ["b13r", "b14"], //--BLEED DEFORM LIMIT TO OTHER PARTS-- {"deformLimitExpansion":1.2}, {"beamPrecompression":1, "beamType":"|NORMAL", "beamLongBound":1.0, "beamShortBound":1.0}, ], ... So what they are doing here is basically setting some of the Modifiers back to their normal values so that they don't bleed over into other parts later down the line. Usually your not making special, tricky, changes to these values, so readability isn't really a concern. Also note that they specifically list {"deformLimitExpansion":1.2}, separately as that is the one value that they are setting to something other than a normal value on purpose specifically to bleed the value into other parts that might not otherwise have this value listed in their files.
sorry if i missed this, but will you be able to rename nodes? (and have them automatically change throughout the jbeams)
Yup I've implemented that where renaming a node will update the referenced node in beams, triangles, etc.
