yw05
Member
Posts: 142
Joined: Tue May 07, 2019 12:59
GitHub: yw05
IRC: y5nw
In-game: ywang
Contact:

### Re: Request for comments: Vertical vehicles like linetrack

orwell wrote:
Tue Jun 08, 2021 10:29
Tue Jun 08, 2021 08:58
Hi advtrains experts.. I know that advtrains can be a decent basis for other vehicles too, as in linetrack. But I was wondering if it's possible to build vehicles that travel arbitrary distances in the vertical axis? Currently the train tracks (and linetrack (if that still works/was ever properly implemented)) as far as I know NEED to be either flat on the horizontal axes or defined in terms of a gradient for slope tracks. Does this make it infeasible to build, for example, elevators (wonkavators?) or hot air balloons? If so, how ingrained in advtrains is this limitation?
Straight vertical travel is currently impossible due to how "track directions" work. Every track node has at least two connections (the ends of the track node; for normal tracks there are 2, for switches 3, for crossings 4), and each connection has two values:
• The direction number, a number between 0 and 15
• The y level of the connection
The direction numbers are purely horizontal (x and z). Slopes are handled in a way that an "y level" of >=1 is considered "next node is 1 y position higher". It's currently not supported to have a gradient steeper than 1m up/down per 1m horizontal (because to find downward slopes, the pathfinder only looks at the position one node below and not further)

EDIT: What would work is an elevator that goes back and forth between two horizontal positions - nothing prohibits that both track connections point to the same direction.

To change that, we would need to rewrite the way connections work and the code that generates the path from the tracks in the world (which is mostly in path.lua). Also, I'm not sure what the wagon placement logic would do if you would pass it a purely vertical path, I'm quite sure there will be a division by 0 somewhere.

EDIT 2: Hmmm, it should not be that complicated to add an alternative format for the "connection table" for vertical travel, and handle that special case in path.lua. This leaves only the problem with the wagon placement - but for elevators it would probably be better to have "wagons" not tilt at all (like it used to be pre-5.0)

EDIT 3: like this:

Code: Select all

at_conns = {
[1] = { vertical = -1, dir = 0 }, -- points downward
[2] = { vertical = 1, dir = 0 } -- points upward
}
-- "dir" is horizontal angle to transfer into path_dir array so wagons can orient horizontally
Also, coupling. First we couple JR E231 engines onto freight wagons, then we couple ferries together, and soon we will have https://www.youtube.com/watch?v=xVgxeuK7i90 :P (not hot air balloons though, sadly)

loppi
Member
Posts: 23
Joined: Sat May 29, 2021 11:30
Location: Niedersachsen

i have one question: how to add sounds to trains?
i have installed rubberducks moretrains mod,and sadly i noticed that my favourite trains,the mt silberling and the old german diesel,dont have a sound. i have some diesel sand electric sound and i want to add it! but how to? 😒
"ich liebe industrie!"
"i love technic!"

Member
Posts: 75
Joined: Wed Jul 17, 2019 10:14
GitHub: Montandalar
Location: Land Down Under

loppi wrote:
Thu Jun 10, 2021 16:52
i have one question: how to add sounds to trains?
i have installed rubberducks moretrains mod,and sadly i noticed that my favourite trains,the mt silberling and the old german diesel,dont have a sound. i have some diesel sand electric sound and i want to add it! but how to? 😒
Currently custom sounds are only possible with custom_on_velocity_change callbacks written in lua. See the source code of some of the trains that have sound like the subway wagon, the JRE E231 and also the boat from linetrack for examples. Also if you want to share your sounds, please make sure that any sound files you contribute are licensed with a creative commons license or similar so that it's legal for it to be included.

loppi
Member
Posts: 23
Joined: Sat May 29, 2021 11:30
Location: Niedersachsen

so i can just copy the subway sound and put it in the diesel file?
i will try it,thanks.
"ich liebe industrie!"
"i love technic!"

VanessaE
Moderator
Posts: 4633
Joined: Sun Apr 01, 2012 12:38
GitHub: VanessaE
IRC: VanessaE
In-game: VanessaE
Location: Western NC
Contact:

So, a few of us were building-out the the rail network on my Traintable server, and one of the players wanted to start a tunnel descending into an underground rail system.

We built the tunnel, laid rails, made everything look nice. The rails descend at a rate of 1m per 3, the shallowest grade the mod has.

But when you place a wagon near the top, on level track just ahead of the slope, and accelerate forward, the wagon stops at the edge and won't go any further. The in-cab display reads "[LZB] [000]" which I take to mean the track safety system stopped the wagon because it thinks there's 0 meters of track ahead.

I tried this with a few other kinds of trains, even a handcart. One person tried a minecart also (the advtrains one of course). All behave the same.

Here is the tunnel:

If I place the wagon directly onto the slope, even just one meter in from the top, the wagon will descend as intended, and the in-cab display correctly indicates that there's plenty of track ahead (around 65m from the top). Similarly, if I place the wagon on level track at the bottom of the grade, I can drive it all the way up the hill and back onto level track at the top without a problem.

What do I need to do to correct it?

Two other things:

A) I'd like to request a slope that'll fill-in those "stairsteps" at the sides. I might suggest simply widening the existing N/S/E/W slope models, since you often can't place anything in the spaces next to the tracks anyway without making trains think there's an obstruction. Sometimes gravel slopes (moreblocks/stairsplus) will fit, but since they're at most 2m long, they look kinda bad next to 3m-long rail slopes.

B) I'd like to request that collision detection be reigned in a bit, so that slabs can be placed vertically next to tracks to create the look of a maglev or similar. For example:

The "Japanese" train juuuuuuust barely fits -- it may not look like it, but there's a minuscule gap on both sides. On a somewhat "broader" usage, consider this three meter wide platform with thin fences on the edges:

Here, there's an ample gap between the train and the fences, but it can't move because it thinks the track is obstructed. BUT, if I move those fences out by one meter and then flip them around so that they're just barely further out, it works. For example, here I've left one segment of the fence at the position I'd have preferred it at, while the rest has been moved and flipped around:

This works (that one fence segment notwithstanding). Although it looks similar to the "proper" way, it's also more cumbersome to build this way, since you need to first put down something for the fences to place on/against, then remove that extra bit once the fences are in place, and may not look right with some fence types that have a "front" and a "back" side.
Attachments
Screenshot_2021-06-21_04-34-54.png
Screenshot_2021-06-21_04-29-44.png
Screenshot_2021-06-21_04-17-05.png
Screenshot_2021-06-21_03-48-14.png
Screenshot_2021-06-21_03-31-38.png
You might like some of my stuff: Plantlife ~ More Trees ~ Home Decor ~ Pipeworks ~ HDX Textures (64-512px)

yw05
Member
Posts: 142
Joined: Tue May 07, 2019 12:59
GitHub: yw05
IRC: y5nw
In-game: ywang
Contact:

VanessaE wrote:
Mon Jun 21, 2021 08:36
So, a few of us were building-out the the rail network on my Traintable server, and one of the players wanted to start a tunnel descending into an underground rail system.

We built the tunnel, laid rails, made everything look nice. The rails descend at a rate of 1m per 3, the shallowest grade the mod has.

But when you place a wagon near the top, on level track just ahead of the slope, and accelerate forward, the wagon stops at the edge and won't go any further. The in-cab display reads "[LZB] [000]" which I take to mean the track safety system stopped the wagon because it thinks there's 0 meters of track ahead.

I tried this with a few other kinds of trains, even a handcart. One person tried a minecart also (the advtrains one of course). All behave the same

Here is the tunnel:

If I place the wagon directly onto the slope, even just one meter in from the top, the wagon will descend as intended, and the in-cab display correctly indicates that there's plenty of track ahead (around 65m from the top). Similarly, if I place the wagon on level track at the bottom of the grade, I can drive it all the way up the hill and back onto level track at the top without a problem.

What do I need to do to correct it?
In case you built it with WorldEdit, try:

Code: Select all

/at_sync_ndb
/at_reroute
And start the train again.

Also, try to reverse the train and see if it helps (especially when you place trains at the end of a track).

The tunnel looks nice btw (or is it just the texture pack?)
I'd like to request a slope that'll fill-in those "stairsteps" at the sides. I might suggest simply widening the existing N/S/E/W slope models, since you often can't place anything in the spaces next to the tracks anyway without making trains think there's an obstruction. Sometimes gravel slopes (moreblocks/stairsplus) will fit, but since they're at most 2m long, they look kinda bad next to 3m-long rail slopes.
Sounds like someone should make a mod with 33% slopes.
I'd like to request that collision detection be reigned in a bit, so that slabs can be placed vertically next to tracks to create the look of a maglev or similar. For example:

You can simply add the slabs to the "not_blocking_trains" group for now, but I can expect that to be abused.

IMO a possible implementation in advtrains would be to call a "blocks_train"-ish function in node definitions. That could get more complicated, though.

Regarding maglev trains, @orwell: IIRC the assets directory has some nice models, including maglev trains and tracks, which IMO can be added to the basic_trains modpack or possibly a separate maglev train modpack.

loppi
Member
Posts: 23
Joined: Sat May 29, 2021 11:30
Location: Niedersachsen

where is this "not_blocking_trains" file?
i want to add stone walls and fence rails
"ich liebe industrie!"
"i love technic!"

yw05
Member
Posts: 142
Joined: Tue May 07, 2019 12:59
GitHub: yw05
IRC: y5nw
In-game: ywang
Contact:

loppi wrote:
Mon Jun 21, 2021 17:32
where is this "not_blocking_trains" file?
i want to add stone walls and fence rails
It's not a file. It's a group in the node definition.

Alternatively, you can add the itemstring (something like "default:stone") to the nonblocknodes table at the end of advtrains/trainlogic.lua, which automatically registers certain nodes as ones that do not block trains.

VanessaE
Moderator
Posts: 4633
Joined: Sun Apr 01, 2012 12:38
GitHub: VanessaE
IRC: VanessaE
In-game: VanessaE
Location: Western NC
Contact:

In case you built it with WorldEdit, try:
And start the train again.
The tunnel, rails, platform, and landscaping were all built by hand.
Also, try to reverse the train and see if it helps (especially when you place trains at the end of a track).
First thing I tried. It's as if the train senses the start of the slope and just goes "Nope!"
The tunnel looks nice btw (or is it just the texture pack?)
Thanks :-) The texture pack is HDX-256, by the way.
I'd like to request a slope that'll fill-in those "stairsteps" at the sides. I might suggest simply widening the existing N/S/E/W slope models
Sounds like someone should make a mod with 33% slopes.
While that's certainly easily done, it makes more sense to goad orwell or someone else to just alter the existing slope models to take advantage of the fact that they already always overlap their neighboring nodes. They presently occupy a 1.5 meter space, so just extend them to the full width needed to cover what's under them.

Make their gravel sections 3 meters wide, and tile the gravel texture so that the textures line-up properly in the space between the rails where the models would overlap (assuming two rails spaced 1m apart, on a 5m wide roadbed, as in my screenshots), to prevent Z-fighting.

I did a quick test in Blender. It can be done very easily with access to the original work files. Working from the distributed OBJ files is also doable, but is much more cumbersome since materials/groups information is lost at that point. Here's what one of them looks like, altered as I suggest:

I'd like to request that collision detection be reigned in a bit, so that slabs can be placed vertically next to tracks to create the look of a maglev or similar.
You can simply add the slabs to the "not_blocking_trains" group for now, but I can expect that to be abused.
Exactly why I figured this should be considered a collision detection issue. What if someone lays the slabs flat? Then they definitely *would* be obstructing the track.
Attachments
Screenshot_2021-06-21_19-21-34.png
You might like some of my stuff: Plantlife ~ More Trees ~ Home Decor ~ Pipeworks ~ HDX Textures (64-512px)

yw05
Member
Posts: 142
Joined: Tue May 07, 2019 12:59
GitHub: yw05
IRC: y5nw
In-game: ywang
Contact:

VanessaE wrote:
Mon Jun 21, 2021 22:50
In case you built it with WorldEdit, try:
And start the train again.
The tunnel, rails, platform, and landscaping were all built by hand.
Also, try to reverse the train and see if it helps (especially when you place trains at the end of a track).
First thing I tried. It's as if the train senses the start of the slope and just goes "Nope!"
That's weird. I don't think anything in particular changed since 2.3.1.
Sounds like someone should make a mod with 33% slopes.
While that's certainly easily done, it makes more sense to goad orwell or someone else to just alter the existing slope models to take advantage of the fact that they already always overlap their neighboring nodes. They presently occupy a 1.5 meter space, so just extend them to the full width needed to cover what's under them.

Make their gravel sections 3 meters wide, and tile the gravel texture so that the textures line-up properly in the space between the rails where the models would overlap (assuming two rails spaced 1m apart, on a 5m wide roadbed, as in my screenshots), to prevent Z-fighting.
That might work as well.

Another solution I see (at least with 50% slopes) is to design a type of track that can be placed on top of the slopes, except I'm quite sure that would break a "few" things.
I'd like to request that collision detection be reigned in a bit, so that slabs can be placed vertically next to tracks to create the look of a maglev or similar.
You can simply add the slabs to the "not_blocking_trains" group for now, but I can expect that to be abused.
Exactly why I figured this should be considered a collision detection issue. What if someone lays the slabs flat? Then they definitely *would* be obstructing the track.
Which is why I suggested allowing nodes to have some sort of function to detect train collision as an alternative to "not_blocking_trains". That would be quite some work, though.

IMO the real solution should be (along with the "not_blocking_trains" group) comparing the train model and the nodes it goes through to check for collisions. However, I don't think MT provides such a mechanism.

VanessaE
Moderator
Posts: 4633
Joined: Sun Apr 01, 2012 12:38
GitHub: VanessaE
IRC: VanessaE
In-game: VanessaE
Location: Western NC
Contact:

IMO the real solution should be (along with the "not_blocking_trains" group) comparing the train model and the nodes it goes through to check for collisions. However, I don't think MT provides such a mechanism.
Well, while I also don't think Minetest has a generic API call to check for collisions, it should be possible to do it in Lua, as you can already read a node, get its definition to find its collision box, and look at its param2 to determine its rotation.

So it should be trivial (if you're good at maths, which I am not :-) ) to poll the nodes ahead of the train while it's moving, to determine if the train's bounding box (I wouldn't use the entity's actual collision box) overlaps any of them.

You'd only bother checking the 8 nodes [*] in front of the engine or behind whatever's at the back end of the train [**], and you'd only do this check every so often, say a few times per second per moving engine car (then you could back the whole train off if a collision is detected), so it should be pretty easy on the CPU.

[*] the two nodes flanking the tracks just ahead of the engine, plus the three nodes in a sideways line just above them, plus the three nodes above those, so the 3x3 square in front of the train, minus the node the tracks occupy.

[**] if the sides of a train would collide, then the front or back end would have already done so, so there's no point in checking things to the side of the engine, let alone the cars coupled to it.
You might like some of my stuff: Plantlife ~ More Trees ~ Home Decor ~ Pipeworks ~ HDX Textures (64-512px)

yw05
Member
Posts: 142
Joined: Tue May 07, 2019 12:59
GitHub: yw05
IRC: y5nw
In-game: ywang
Contact:

VanessaE wrote:
Tue Jun 22, 2021 10:36
IMO the real solution should be (along with the "not_blocking_trains" group) comparing the train model and the nodes it goes through to check for collisions. However, I don't think MT provides such a mechanism.
Well, while I also don't think Minetest has a generic API call to check for collisions, it should be possible to do it in Lua, as you can already read a node, get its definition to find its collision box, and look at its param2 to determine its rotation.

So it should be trivial (if you're good at maths, which I am not :-) ) to poll the nodes ahead of the train while it's moving, to determine if the train's bounding box (I wouldn't use the entity's actual collision box) overlaps any of them.
That sounds plausible to me at least, but IMO that should be its own mod.

(And I wonder how many mods we will end up writing for advtrains. We have serialize_lib already.)
You'd only bother checking the 8 nodes [*] in front of the engine or behind whatever's at the back end of the train [**], and you'd only do this check every so often, say a few times per second per moving engine car (then you could back the whole train off if a collision is detected), so it should be pretty easy on the CPU.

[*] the two nodes flanking the tracks just ahead of the engine, plus the three nodes in a sideways line just above them, plus the three nodes above those, so the 3x3 square in front of the train, minus the node the tracks occupy.

[**] if the sides of a train would collide, then the front or back end would have already done so, so there's no point in checking things to the side of the engine, let alone the cars coupled to it.
Now let me introduce slopes (and my handwriting that is not as good as you might expect). Sometimes there would be more than 8 nodes that need to be checked ...
+ Spoiler
I'm currently too lazy to draw curves (etc). Perhaps I will add that later.

Also, there is linetrack with ferries, and we might have double-decker wagons in the future.

TL;DR: IMO node collision should be checked for every node (at least the front of) the train potentially overlaps with.

Anyway, I can not yet tell whether my understanding of mathematics is sufficient to implement such collision checks (and I also need to look into the object/model file formats), and I am not sure whether orwell currently has the time to implement it. :(
Attachments
Untitled-1.png

Member
Posts: 75
Joined: Wed Jul 17, 2019 10:14
GitHub: Montandalar
Location: Land Down Under

### Re: VanessaE's request for collision

VanessaE wrote:
Mon Jun 21, 2021 08:36
...

But when you place a wagon near the top, on level track just ahead of the slope, and accelerate forward, the wagon stops at the edge and won't go any further. The in-cab display reads "[LZB] [000]" which I take to mean the track safety system stopped the wagon because it thinks there's 0 meters of track ahead.
...

What do I need to do to correct it?
This is a well-known bug we have experienced often on the linuxforks server. If ywang's advice didn't work, you will just have to remove the tracks, run the train through an alternate path, place them back where they're meant to go. Oh, and make absolutely sure there's no nodes secretly blocking your path you haven't noticed yet.
VanessaE wrote:
Mon Jun 21, 2021 08:36
Two other things:

A) I'd like to request a slope that'll fill-in those "stairsteps" at the sides. I might suggest simply widening the existing N/S/E/W slope models, since you often can't place anything in the spaces next to the tracks anyway without making trains think there's an obstruction. Sometimes gravel slopes (moreblocks/stairsplus) will fit, but since they're at most 2m long, they look kinda bad next to 3m-long rail slopes.
Your new model idea makes a fair bit of sense, but I'm not sure about diagonal slopes. There's a lot of potential overlap with surrounding terrain. On LinuxForks, our fork of moreblocks includes gravel slopes in 1:2 and 1:3 gradients called gravel slope 2a, 2b, 3a, 3b and 3c. With careful placement these work nicely on both straight and diagonal slopes to give a smooth look. You can see these nodes on linuxforks just north of Apple Grove or Nimbyton stations.
VanessaE wrote:
Mon Jun 21, 2021 08:36
B) I'd like to request that collision detection be reigned in a bit, so that slabs can be placed vertically next to tracks to create the look of a maglev or similar. For example:

The "Japanese" train juuuuuuust barely fits -- it may not look like it, but there's a minuscule gap on both sides. On a somewhat "broader" usage, consider this three meter wide platform with thin fences on the edges:

Here, there's an ample gap between the train and the fences, but it can't move because it thinks the track is obstructed. BUT, if I move those fences out by one meter and then flip them around so that they're just barely further out, it works. For example, here I've left one segment of the fence at the position I'd have preferred it at, while the rest has been moved and flipped around:

This works (that one fence segment notwithstanding). Although it looks similar to the "proper" way, it's also more cumbersome to build this way, since you need to first put down something for the fences to place on/against, then remove that extra bit once the fences are in place, and may not look right with some fence types that have a "front" and a "back" side.
The case of these fences from cottages on LinuxForks server is something we take for granted as inevitable. It's pretty straightforward to place such an arrangement with a digtron, which doesn't require you to arduously rotate stuff with a screwdriver.
VanessaE wrote:
Tue Jun 22, 2021 10:36
IMO the real solution should be (along with the "not_blocking_trains" group) comparing the train model and the nodes it goes through to check for collisions. However, I don't think MT provides such a mechanism.
Well, while I also don't think Minetest has a generic API call to check for collisions, it should be possible to do it in Lua, as you can already read a node, get its definition to find its collision box, and look at its param2 to determine its rotation.

So it should be trivial (if you're good at maths, which I am not :-) ) to poll the nodes ahead of the train while it's moving, to determine if the train's bounding box (I wouldn't use the entity's actual collision box) overlaps any of them.

You'd only bother checking the 8 nodes [*] in front of the engine or behind whatever's at the back end of the train [**], and you'd only do this check every so often, say a few times per second per moving engine car (then you could back the whole train off if a collision is detected), so it should be pretty easy on the CPU.

[*] the two nodes flanking the tracks just ahead of the engine, plus the three nodes in a sideways line just above them, plus the three nodes above those, so the 3x3 square in front of the train, minus the node the tracks occupy.

[**] if the sides of a train would collide, then the front or back end would have already done so, so there's no point in checking things to the side of the engine, let alone the cars coupled to it.
Trains move as fast as 20 or even 30 m/s. It's fast enough that if the server hardware is having a hard time keeping up then the mapblocks won't load. Compound the fact that advtrains needs those mapblocks for your proposed collision system, and only bad things can happen.

I would make the structure gauge collision pre-computed when the track is placed and updated when any nearby node updates - unless that needs an expensive on-tick callback or something. This computation could only possibly work for nodebox nodes, not mesh nodes. Most of the shapes in the technic CNC machine are meshes not nodeboxes, so that rules out compatibility with them, leaving moreblocks, mymillwork and possibly a few others.

In addition to the straight tracks case that you outlined, you would also would need to account for curves and slopes and trains on curves going up a slope. To be properly realistic, the calculation on curves would need to account for the wagon length as well as the normal 3 metre clearance.

Newly-placed train cars would also need to be pre-calculated to let us know if they are valid placement. Your definition of 'the engine' seems to imply the 'front of train'. Remember that there might not be a locomotive at the back of the train - and the train's direction can change at any point if the train stops and is reversed. So then with your 'engine-only' system, you could place nodes behind the locomotive which don't collide at the time of placement, reverse the train, and it would be stuck. It's better to make the train stuck at the time of placement as it currently does - imagine lining a tunnel wall and it not sticking the train in place, only for it to later come back and bite you later when you reverse the train and it can't move!

As for hiding the tracks to give a 'maglev look' - I suggest you should just make custom tracks. The end result will be much better.

VanessaE
Moderator
Posts: 4633
Joined: Sun Apr 01, 2012 12:38
GitHub: VanessaE
IRC: VanessaE
In-game: VanessaE
Location: Western NC
Contact:

yw05 wrote:Now let me introduce slopes (and my handwriting that is not as good as you might expect). Sometimes there would be more than 8 nodes that need to be checked ...
I get that there may be more nodes to check than I suggested when going around a curve or negotiating a grade, but the mod is *already* checking all those nodes -- after all, the train is hitting *something* isn't it? I'm just suggesting to take those nodes' collision boxes into account, so as not to treat a thin fence as if it's a block of stone.
Blockhead wrote:Your new model idea makes a fair bit of sense, but I'm not sure about diagonal slopes
Honestly I don't much care about the slopes that go off at angle. Just fixing the NSEW ones would be enough; the angled ones can be dealt with using regular gravel slopes -- considering the limits imposed by a blocky landscape, I don't think angled slopes can be made to look all that great no matter what you do.
Blockhead wrote:As for hiding the tracks to give a 'maglev look' - I suggest you should just make custom tracks. The end result will be much better.
Absolutely not. Based on my own experience in my own mods, I don't advise use of "custom" nodes when it can be avoided, as players like to actually *build* stuff, which would include constructing the channel that would provide most of the maglev look.

I mean, it's okay to have a custom node that would just be the "tracks" (well, the lines of electromagnets) under the train, but a model that's a whole section of "track" with the enclosing walls is right out. That spoils creativity, and would require many custom models to account for curves and slopes, when existing slabs or other nodes would do. Maybe I'd build one out of concrete, but someone else wants to use white baked clay (turns out this is a popular choice for builds that shouldn't have much "texture" to their walls). You'd have to define dozens of nodes for each possible material, and you'd still end up leaving something out.

All of that aside, the "maglev" idea was merely an example, as was the wooden platform, as I was thinking more along the lines of generally-narrow throughways, nevermind the technology used to make the train move. I mean, real life subways are sometimes really narrow on routes that go through areas that don't need much in the way of worker access (let alone pedestrians or riders), whether underground or elevated. I seem to recall Chicago's "El" is like that in some areas. A more extreme example would be something like an in-game equivalent to Elon Musk's Hyperloop, or even just a recreation of the (failed) Beach Pneumatic Transit system in New York, which both need close spacing to look right. I probably should have built one of these for my screenshots, but I didn't think it would have been needed.
Newly-placed train cars would also need to be pre-calculated to let us know if they are valid placement. Your definition of 'the engine' seems to imply the 'front of train'.
That's just a terminology issue. Whatever it is that's at the leading end of a train in motion, whether it's an engine pulling a line of cars, or a caboose or just some rolling stock being pushed backward from the other end, there's *always* a "front" car of some kind, and that's the only one that needs collision checking. "Front" does not imply "engine", it only implies "the thing that will collide first".
It's better to make the train stuck at the time of placement as it currently does - imagine lining a tunnel wall and it not sticking the train in place, only for it to later come back and bite you later when you reverse the train and it can't move!
No! Don't overcomplicate the collision handling! It creates too many corner-cases and will almost always consume more CPU than simpler handling, and then you can leave it up to the players to make their rail networks look "proper". I mean, we don't do those kinds of things with other moving entities like animals or cars, and trains are already confined to a predictable path.

A train that's always stuck because the mod is limiting players' creativity for the sake of collision detection is a useless train, and just annoys the player, possibly to the point that they stop using trains. Who cares if a train fails to collide with something in some edge case? Just let the damn thing pass on through and leave it to the player to make it not look stupid. I mean, this is a just game, and there's a fine line between realism and irritation.

Hell, just check the 1x1 column of nodes directly ahead of the "lead" car, even if it's going up or down a slope or around a curve. There's nothing to be gained in checking dozens of surrounding nodes.

So, either simplify the collision handling to make fewer checks at the expense of some things not colliding when they "should", or make it take into account the apparent shapes of the nodes it looks at (by their defined collision boxes) so that things stop colliding when they shouldn't, because based on my players' actual use and their complaints, what's being done now is broken.
You might like some of my stuff: Plantlife ~ More Trees ~ Home Decor ~ Pipeworks ~ HDX Textures (64-512px)

### Who is online

Users browsing this forum: Emojiminetest, VanessaE and 13 guests