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.
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.
Moreblocks uses meshes for some of its shapes, like slopes, but like node boxes, all mesh nodes in Minetest have to use boxy collision info set in the node definition, similar in format to a node box. Therefore the logic used to check a mesh node would be identical -- to the point that you simply don't bother to look if it's a mesh node, as it won't matter. When present, a collision box in the node def always overrides the collision info that's provided by the node box, regardless of drawtype, so if a node has a both a node box and a collision box defined, just ignore the node box, since that's how it works for player collision detection (and some other stuff too, like particles and I think animals/mobs).
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! 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, you could 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, and players will almost certainly not complain if it looks like something "should" collide but doesn't.
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".
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.
---
Bottom line: either simplify the collision handling to make fewer checks, at the expense of trains not colliding with things when they seem like they "should", and let players deal with making sure that this doesn't become an issue (since it's just visuals anyway), or make the collision handling take into account the the nodes' defined collision boxes, so that things stop colliding when they definitely shouldn't, because based on my players' actual use and their complaints, what's being done now is broken.
If that means moving collision handling into a separate mod that can be swapped-out according to how complex or simple a server admin wants the collision detection to be, well, so be it.