Truck file format: new feature suggestions

[ohlidalp]

Greetings.
This thread is for suggesting changes and new features to the rig definition file format, aka 'truck' fileformat: https://docs.rigsofrods.org/vehicle-creation/fileformat-truck/

Just to be perfectly clear - I'm never going to stop supporting the truck file format or any part of it. I never intended to, although I might have created that impression. If an incompatible change ever needs to be made, I'll introduce a new `fileformatversion` for it. So relax and read on.

I've just had a very good chat about this with Max98 on Discord - coincidentally he suggested a feature that I've had in mind for a while. With his permission, I'm reposting the chat here for further discussion and questions.

Max98 — 02/09/2022
hey ptr, I wanted to ask, if ror going to support multiple truck files for one vehicle one day?
only_a_ptr — 02/16/2022
hi, do you mean creating a vehicle by combining parts in several .truck files? Yes, I'm definitely doing that in a foreseeable future, I had an idea of an "import <truckfile>" directive in truck file which would (at spawn time) combine the content of the imported truck file with the existing content. Only named nodes would be supported, tho, and I need to figure some way to create mass-distribution groups, because currently mass is set in globals and you probably want each truck file to define it's own mass for it's nodes.
Max98 — 02/16/2022
Perfect
only_a_ptr — 02/16/2022
I need to finish this first, tho - https://github.com/RigsOfRods/rigs-of-rods/pull/2829 - because presently sectionconfig & named nodes don't work as they should
Max98 — 02/16/2022
Also, does RoR generate@id numbers for nodes2?
only_a_ptr — 02/16/2022
absolutely, it cannot work otherwise
but it generates them on spawn time, depending on what precedes them
that way you can theoreticaly have section/end_section parts with variable node counts. The following named nodes just end up with different numbers, but thats fine
at least thats how it worked in 2013, but then I broke it. I only figured it out last year because that feat is undocumented and nobody used it to full extent
Max98 — 02/16/2022
Interesting
I always thought it would lookup for nodes with their name instead of their index
only_a_ptr — 02/17/2022
It does. I guess I confused you - it looks up using names on spawn, but you can always use the assigned number, too. IIRC some sections didn't process names at all (flexbodies, props or camera rails, IDK right now). when simulated though, it's all numbers (or pointers)
gotta go , I'm glad you're into the multi-truckfile idea, I'll know who to talk to when I try coding it
Max98 — 02/17/2022
Honestly, if you'd ask me, I guess RoR needs a new truck format
Not really "new" but like remastered
It keeps all the parsing as is and everything, but for eg, no more numbred nodes
an other file for just the 'global' things and 'slots' (slimiair to beamng)
etc
only_a_ptr — 02/18/2022
I had the same thoughts back in 2013-14, but out of necessity I got so familiar with the current one I don't feel the need anymore
I'm actually remastering it as we speak - specifically undoing my clever shared_ptr tricks from 2013-14 and making it sequential like it was, see updated code at https://github.com/only-a-ptr/rigs-.../rig_def_fileformat/RigDef_File.h#L1547-L1619
the only elements left to do are set_node/beam_defaults
next I'll make named nodes supported everywhere, which will make it possible to add various-sized N/Bs in sections.
and finally I'll add the possibility to import other truck files, with named nodes
Max98 — 02/18/2022
That’s what we need

 

[ohlidalp]

One thing I'd like to fit into the upcoming release is the ability to combine multiple truck files into one. Following https://github.com/RigsOfRods/rigs-of-rods/pull/2922 it'll become technically trivial, just implement a directive such as

; Tip: the scale params can have negative values to flip the N/B around.
; import filename posX, posY, posZ, rotX, rotY, rotZ, scaleX, scaleY, scaleZ
import mycomponent.truck ....
import mycomponent.truck ....

the main truck file and the compoentns would be parsed separately, only on spawn would the components be swapped-in as requested and processed the same way as the main truck file, only ignoring some keywords (description, sectionconfig, section/end_section, globals, minimass). The only tricky parts are 'globals' and 'minimass' - each component would needs it's own "mass group" which would be calculated separately. Also, the 'component' files would have to use only `nodes2`.

 

[ohlidalp]

I'd love to be able to define custom wheel N/B. All existing wheel types are lacking in some area:

• Stability, be it expansion at speed or bad handling - commonly adressed by using external tools to add additional support beams to existing wheels.
• Special features - for example 'wheels2' have pressure simulation, others don't.
• Graphical fidelity - Each wheel type does graphics differently, some generates 'cab mesh' of sorts, some combine it with prop-style meshed rim. Modders often employ a trick: they set the generated mesh's material to transparent and manually fit a flexbody in the wheel.
• Detail - internally there's a limit for 50 wheel nodes.

The design I have in mind would remove all automation from the wheel definiton and let the user build the N/B from the ground up:

; makes the following N/B a wheel N/B
; (you can issue it multiple times to specify which nodes will be braked/propulsed, rim/tire etc...)
; params: like wheels/wheels2, to be specified.
set_wheel_defaults ...

; as usual
set_beam_defaults ...
set_beam_defaults_scale ...
set_node_defaults ...
set_default_minimass ...

; as usual
nodes
; ...

; generates a ring of named nodes (prefix + 0...N) around given position
; add_node_ring prefix, posX, posY, posZ, rotX, rotY, rotZ, radius, count
add_node_ring ...

; as usual
beams
; ...

; generates a series of beams between consecutive nodes
; (nodes that end up one after another on spawn, depending on sectonconfig etc...)
add_beam_strip startnode1, startnode2, count, stride1, stride2

; ends the wheel definition block.
set_wheel_defaults end

Naturally, you'd want to define a wheel model once and re-use it multiple times. I think the best mechanism for that would be my `import` directive outlined above.

Some old research on the topic: https://github.com/RigsOfRods/rigs-of-rods/issues/1274 - contains an old design which doesn't rely on `import` but instead has `wheel_def/end_wheel_def` and doesn't let you freely use `set_*_defaults`.