This is an old revision of the document!
This is regarding a long-term idea that I had in mind, which could make railways look a lot more realistic, and would push advtrains towards being more visually aesthetic. It probably won't be implemented in the near future, if implemented at all.
The current track system is limited to the constraint that one track segment (i'm not talking about interlocking here but rather “track nodes”) spans exactly one node in any of the 16 directions. This means that all visual details regarding this single track segment must fit into the space of one meter.
This has some drawbacks:
A track segment should be allowed to be several nodes long, and define the exact relative positions and angles of its ends. The node position of the track segment should have no correlation with the actual position the train is positioned at, but instead the rail should define a set of points(a path) for the train to orient along.
Tracks would be defined in a “building kit”-like system, similar to how popular model railroad companies build their non-flex track assortments. Care needs to be taken that as many combinations as possible can be made with the offered track segments, and designing this is not an easy task.
Track construction would no longer work by placing nodes in the world regularily. Instead a special builder tool would allow to select unconnected track ends and allow the user to attach a fitting track segment there. The actual position of the track node should be conveniently hidden from the user.
It is yet to be decided whether those new tracks would be the same gauge as the current “advtrains gauge” or be changed to 1435mm standard gauge.
Using a larger gauge would allow to make trains larger in general, making them also more realistic, as current trains are pretty small in relation to Minetest players, but would also create more building work. But it would break compatibility with all existing trains and all existing tracks already built in worlds.
Keeping the same gauge would have no compatibility issues, and old and new tracks could be used similarily, requiring no migration.
This would be a major breaking change, and would rectify a major version increase.
Considering that I (orwell) currently have not enough time to work on such a large project, it won't be implemented in the near future. This is just a collection of ideas, open for discussion, which might eventually be implemented.