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:

• Each curved rail viewed individually has a curve radius of about 4m, including switches. Even when building larger-radius curves, it is not possible to make them look “smooth”
• Thus the overall minimum curve radius is also 4m, and cannot be constrained to be larger
• All components of a switch must be arranged within that 1m, which makes switches look cramped. This could become a problem with monorail switches, which are rather “turnbridges” than switches and would look awful.

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.

• The node position of the next/previous connected rail can no longer be conveniently guessed. It has to be cached in the nodedb.
• Creating this many track models by hand is not feasible. A program to generate track meshes is required, ideally it would generate the track meshes directly from the track registration description.
• Large parts around the path system need to be adapted to clear out the assumption that node_pos always equals advtrains.round_pos_floor_y(path_pos), and another mechanism needs to be added to determine the node position given a path item.

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.

There will be several ideas and opinons regarding this. They are listed here, at this section:

Sorry about this wall of text, this probably isn't going to get much visibility, but I've been doing a lot of thinking over an extended period and I felt the need to dump it all out.

This idea bears a lot of similarity to orwell's idea as explained above, but I would like to explore some areas.

Model railways are pretty comparable to advtrains in a lot of ways. They are both played with for fun, and they both still have sharper curves than most real railways. There are a variety of manufacturers of model railway track for different scales and gauges. These come in pieces that can be snapped together. We could take inspiration from the product catalogues of some of those manufacturers and build our own 'advtrains set track'.

This would be quite model-heavy, probably even more so than the current line-up. It would also let us fix the sleepers that sit under the crossings so that they do not overlap. We could also build double slip switches easily (the current space constraints make that quite hard, even if a node was mode for it, and I have a prototype…).

An an example of a poor implementation of this kind of system can be found in the Traincraft/Trains in Motion mods for Minecraft. All track blocks start and end on straight, so there are no diagonals like advtrains. The tracks in this mod are as follows:

• Different lengths of straight track.
• Sharp, Medium and Wide 90 degree curves.
• Turnout to two parallel tracks which continue for a long time - can't recall if both left and right-hand turnouts are available. Yards have to be built by chaining many of these and using a lot of space. Also the frog has a huuge gap.

Note in particular no diagonals, only wibbly-wobbly - the workaround is you can use their trains on minecart tracks and those have the usual zig-zag that works to travel in a straight line on a 45 degree angle. No diamond crossings whatsoever which means no realistic junctions whatsoever - not even a two-track T-junction is possible.

All in all we can only say that the Traincraft system, as directly copied, would be a feature downgrade. A successful set track implementation must therefore include everything we already expect from advtrains or more.

The set track system would fit into the nodedb format without issue, but the adjacent track node finding code would have to change to accommodate custom adjacent directions per registered node. It still may be worth exploring if it's worth changing the nodedb format - with migration code of course. For example, if the nodedb also recorded the connections that a track node has. This may make pathfinding quicker to compute by removing adjacency calculations; on the other hand, a correct implementation needs to make sure the node's connections are always correctly encoded and updated in the nodedb to match that node's definition.

I want to stress that I don't see this type of system as realistic for the Minetest engine but it's worth exploring it anyway and discussing the challenges with it.

Another route would be to take ideas from the Rails Modpack for Medieval Engineers, which has custom curvature within limitations of minimum radius and is physics-based.

I'm not sure how the medieval engineers engine and this mod work together to store the rail information, but it almost certainly wouldn't be compatible with the nodedb format.

Inside the Minetest engine the height at each end of each track segment would have to be an integer, which is quite different to Medieval Engineers' small voxel terrain. I do not think we would realistically be able to support curvature on the horizontal plane and slope at the same time in a track segment with this system.

I'm also not how we could put these segments into the Minetest engine with some combination of nodes and/or entities. Nodes can only show a static simple shape, so they would work for straight tracks and predefined slope tracks. We would probably have to use invisible nodes that manage a series of entities. Each entity would be a sleeper or a small section of track or perhaps both in one model file.

We have to be careful with entities because (1) they have a serious performance penalty with the current Minetest engine and get_objects_inside_radius (2) if we do it wrong and the entity-track doesn't show the tracks the train is travelling on, players are going to get really really confused. Well, aside from when they already are because the terrain loading often can't keep up on a loaded server so the advtrains track nodes don't show up either. We can all attest that the blocks load before the entities though, given how if you teleport to a railway station you first see the blocks then the trains load, or similarly if you teleport to an animal farm the animals come after the nodes.

Visual correctness: The custom curvature system also presents major problems to visual correctness given the features we expect from advtrains of diamond crossings, turnouts and the potential for double slip switches. If we allowed freely placing intersecting curved sections, we would end up with a jumble of sleepers and track that looks like it's going to derail any train that goes over it. I know that in real life diamond crossings almost never cross at exactly 90 degrees, with the exception of trams; the angle between tracks varies quite a lot at different crossings. Intersecting custom curves may also be tricky to check for collision - I will admit I'm not an expert on how collision is currently done in advtrains (for example, I can't answer the question: Will two trains that are too close but moving through unloaded mapblocks actually collide, or only when their Lua entities actually exist?)

To preserve visual correctness, we would realistically have to include a static set of all of these components - diamond crossings, turnouts and double slip switches - similar to what we have, also similar to the set track approach. Then at the end of custom curved track sections, the track would have to be aligned at the right angle so that it goes into the component. The track placer would enforce this of course.

I have explored the possibilities of larger track segments that align to the voxel grid, i. e. the “set track” approach.

The currently available 16 angles are fine, they align to the grid every 2m, and are compatible with moreblocks table saw shapes. But the voxel grid is quite restrictive for the possible curve radii.

I have drawn 26.57° and 45° curves in Inkscape, and scaled them up in various sizes, to see which radii fit well on the voxel grid. Of course, no radius fits without some stretching. But stretching is possible well enough even with quadratic bezier curves, so it should not be an issue if the result looks fine.

I have chosen radii of 5.5m, 14.5m, 18.5m, and 35.5m. (The half metre is caused by straight tracks ending on centers of node edges.) I have drawn turnouts with the 18.5m radius, diamond crossings, and an additional set of “tram tracks”, which use only 5.12m radius and 45° angles.

I have also added sleepers to all track segments, and tried to avoid overlapping sleepers as far as possible. Turnouts and crossings use parallel sleepers, aligned to the “more major” axis. Many diamond crossovers and similar track layouts are possible with only parallel sleepers.

Because curves now consume more than one node, it is more difficult to do small lateral movements within one track. Two adjacent curves move at least 3m laterally, if this is too much, the lateral movement must be propagated until a single curve is needed anyway.

Therefore I found it necessary to add off-center diamond crossings (to avoid the need for lateral adjustments when 26.57° tracks meet), and dedicated S curve tracks. Compared to plain curves and turnouts, the amount of additional nodes is small.

The result of my work is now available as Inkscape SVG file. To implement these track segments, more than 100 individual meshes need to be created. I think someone should write a script collection to create these meshes. Like this:

1. An XSLT or Python script to convert an Inkscape drawing to a numeric description of rails, sleepers, switch blades, frogs, guard rails, and slide chairs. This should probably be divided further.
   1. Assign roles (rail, switch blade, …) to individual SVG elements.
   2. Stitch rail elements together to get a continuous run (switch blade → rail → frog → rail).
   3. Calculate positions of switch blades in diverged state.
   4. Calculate positions of slide chairs.
2. A Blender Python script to create a mesh from the numeric description.
   • Be careful about UV mapping, so all track nodes can use the same texture. (A human could not do this >100 times without mistakes.)
   • Make sure to use different materials (texture slots) for rails and sleepers. This will very likely be useful at some time.

The script approach allows to change the level of detail later, without discarding a lot of work. For example, someone may think that guard rails and frogs are useless, or that slide chairs are important.

Do the tram tracks come without sleepers? I feel that tram tracks should be metal rails driven straight into the ground, as you can see in below reference image (of points at St Peter's Square in Manchester, and some straight sections just around).

• 1
• 2
• 3
• 4

What i think is a good idea is versions of these rails without sleepers and those with sleepers, for tram systems and ballastless track.

No, my proposal would have sleepers on all track nodes. To make tram tracks, you would put the tracks 1/8 node deeper, using https://github.com/minetest/minetest/issues/12352. This allows to use all track nodes both with and without sleepers. — doxydoxy 2022-09-13 10:21

I agree with the set state concept, but was wondering what everyone's opinion on 15-degree track is? I think that having 0, 15, 30, 45, 60, and 75 degree track pieces would help make curves look more consistent and allow certain alignments that would look weird otherwise. Considering the scale of these changes, I think integrating 15-degree track would make sense.

It gets a no from me due to combinatorial explosion. Adding two more angles of track doesn't just add straight track segments, it adds basic turnouts, y-turnouts and 3-way turnouts at that angle. It also adds diamond crossings that cross each other at that angle. The crossings are a particularly bad problem. According to my calculations there are 28 possible shapes with our current system (though some are omitted due to being too shallow of an angle, so we have more like 20). Angles wouldn't be a problem with a large track segment. But with a 15 degree system, there are 66 different combinations. Diagram:

This would increase the amount of time needed to manually make them, making more obvious we should have an algorithm that generates the track shapes. But even if they're made by algorithm, each one adds to the media file size of advtrains, for shapes that maybe nobody will ever see. Finally, it's a block game, not a train simulator: I think we should be content to even have the 30 degree system, since carts don't even really have a true 45 degree system. If you want a good game with voxel terrain and a good track system, try something like Railroads Online, not Minetest. –Blockhead 2022-08-22 02:47 (UTC)

(Sidenote, afaik Railroads Online is not voxel-based internally and certainly isn't in-game, it's free placement.) I think adding the necessary turnouts would not be much of an issue, I estimated file size based on the existing models and came to a total of 494KB for all straights, curves, and switches, which would only increase the models folder from 3.62MB to 4.11MB, which isn't too bad in my opinion. On the other hand, I hadn't fully considered the number of crossing pieces and I agree with you that it's an excessive amount of models that won't see much use. I went by hand and calculated how many crossovers would be required, advtrains right now has 17 crossing models, and with 15 & 75 degrees this increases to 41 models. When I estimated the file size change it came out to around 2475MB bringing the net file size to 6.59MB, a bit less than double the current size. I am not convinced this is necessarily a deal breaker, especially considering the number of models set-state track would take. However, this would definitely necessitate the creation of a model creation script. The other option would be to not add the crossings, just the straight, curved, & switches. In my opinion, even though this is inconsistent, it is no more so than the current missing angles, as we effectively have a 15-degree system with 2 angles missing rather than a 30-degree system. –BreadBox64 2022-08-23 04:40 (UTC)

Besides the combinatorial explosion mentioned by Blockhead, I think there is no real visual advantage. First, the current angles are 0°, 26.57°, 45°, and 63.43°. If we add another one at “15°”, that would mean 14.04° (1:4) or 11.31° (1:5). Then we could argue whether there should be more angles between 26.57° and 45°, e. g. 33.70° (2:3). Second, these angles will look nice at places where a single track line transitions to double track (like in front of a station). But they are less useful than 1:2 for open line, because no blocks can be shaped in 1:4 or 1:5 slopes. — I think additional angles (for smooth transitions) can be useful as add-on. Without providing turnouts from 14.04° to 26.57° and so on, and without diamond crossings. Similar to the tram track set visible in my proposal, which serves specific uses but is not as complete as the track set otherwise. — doxydoxy 2022-09-13 14:11