I'm not sure how to continue developing the truckfile format. There are 2 possible approaches:
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:
Now that I actually wrote it all down it doesn't seem like such a huge change, what do you think?
- 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: