Future: how to define N/B in truckfile

Status
Not open for further replies.

only_a_ptr

Infamous Developer
Administrator
Developer
Joined
Jan 31, 2018
Messages
167
Location
Prague, CZ
I'm not sure how to continue developing the truckfile format. There are 2 possible approaches:

  • The classic approach: Truckfile is parsed from top to bottom, nodes are generated on-the-go. Named nodes (nodes2) and generated nodes (*wheel*) get numbers assigned. To attach a beam/prop/flexbody/etc... to these nodes, you must know the generated number. Some sections support node names, but not all. If you add/remove one node -> all numbering breaks (except if you add another 'nodes[2]' section after everything). Simple and crude.
  • The RigEditor approach: All nodes get user-assigned alphanumeric ID. Wheels also get user-assigned alphanumeric ID (like 'fr_wheel', 'fl_wheel') and generate node-IDs in form 'nodeID@wheelID' (like '5@fr_wheel', '22@fl_wheel'). All sections must support these node IDs. If you modify nodes in any way -> everything still works. Order in truckfile doesn't matter anymore. A Blender-style N/B editing tool can be added into the game.

At the moment, RoR is somewhere in-between: it fully supports the classic approach, but it internally converts the truckfile to the RigEditor approach because it's technically meaningful: You can check invalid node IDs, you can have unlimited N/B, the code is far more pleasant to maintain (predictable order of processing).

Personally I see the classic approach as messy and obsolete and I suggest the following additions to the truckfile:
Code:
; Version 4 changes behavior of the parser
;     * all ordering rules ('A' must be before/after 'B') are irrelevant.
;     * forbidden sections: nodes2
;     * modified sections: nodes, beams, wheels, wheels2, meshwheels, meshwheels2, flexbodywheels, slidenodes, flexbodies/forset
fileformatversion 4

; Syntax: alphanumeric_ID, posX, posY, posZ, options
; To upgrade 'nodes', just rename the section
; To upgrade 'nodes2', you must find all references to their generated numbers
;                    (slidenodes, flexbodies, etc...)and replace them with name references using new syntax. Then rename the section.
; Naturally, each ID must be unique. Special characters like '@' are forbidden.
nodes

; works as usual, but only uses alphanumeric IDs
beams

; works as usual, except all node references use alphanumeric IDs
; There is extra parameter on the end: ID=my_wheel (optional)
; -> all nodes get IDs generated as `11@my_wheel` - this is how you connect beams (or whatever else) to the node.
; -> without this extra parameter, you won't be able to link to generated nodes!
wheels
wheels2
meshwheels
meshwheels2
flexbodywheels

; as usual, except you must define nodes using `railgroup` section, the inline definition list will not be supported anymore.
slidenodes

; as usual, except the `forset` subsection won't support ranges anymore
flexbodies
forset

Now that I actually wrote it all down it doesn't seem like such a huge change, what do you think?
 
Last edited:
I mean... the Rig Editor approche sounds like the best one to me. Also, if the whole file would now be read this way... couldn't we just upgrade the regular Nodes section to run like Nodes2 does and just remove Nodes2 all together? I say this because, in theory, if it reads the nodes section but then upgrades it to be read like the Nodes2 section anyways, then what is the point of having Nodes2 anymore?

I always thought the addition of Nodes2 was kinda stupid as upgrading a Nodes truck to Nodes2 is literally as easy as adding a 2 to the name. Since it was that easy, it shouldn't have broken anything in any older truck that uses regular Nodes, and in fact, every older truck I have ever tried the conversion in basically went through completely unscathed.

That's just my opinion... obviously now we would need, at the very least, to just be able to accept both names as a node section just for compatibility purposes, but I definitely think Nodes2 is kinda pointless and Nodes should just be upgraded to Nodes2 functionality seeing as the phraser would read it like that now anyways with the changes you seem to be proposing.
 
But instead of adding fileformatversion 4 to a truck file, wouldnt it be a better idea to save it in TOML or YAML ?
It would make it a lot easier to write external tools for editing truck files since you don't have to write a custom parser for importing/exporting the truck files
 
... couldn't we just upgrade the regular Nodes section to run like Nodes2 does and just remove Nodes2 all together?
That's exactly what I'm doing... fileformatversion 4 forbids use of 'nodes2', it's written on the top of the draft. However, older fileformatversions must keep working as before.

But instead of adding fileformatversion 4 to a truck file, wouldnt it be a better idea to save it in TOML or YAML ?
It would make it a lot easier to write external tools for editing truck files since you don't have to write a custom parser for importing/exporting the truck files
I planned and discussed such changes years before, but it turned out developing the necessary tools doesn't always work out (RigEditor is still not functional). Also, the response of modding community was never too positive. This time I'll simply make an incremental change in the truckfile which modders can handle manually. When I actually ressurect RigEditor, I'll start thinking further.
 
Last edited:
Status
Not open for further replies.
Back
Top