Issue with CFrame train

Help and Feedback Scripting Support
#1

Hi, I’m working on a train system and currerntly the train system I’ve got now is physics based and it works great but its not that smooth or is bouncy at times so I’ve been trying to move to a CFrame train. This CFrame train is a bit differen’t from most CFrame trains you’d see, this one isn’t node based, this one has more of a “curve sensor”, essenitaly what I mean is just like a physics train, it still has bogies that turn and collide with the rails heres my plan:

  1. Anchor the train
  2. Leave bogies unanchored as they use HingeConstraints and still need to rotate
  3. Use a Heartbeat or RenderStepped event to make the train move forward and this event will also make the train rotate based on the bogies orientation

So far heres the progress:
CFrame Train.rbxl (76.2 KB)
When testing, you’ll need to enable the script thats inside ServerScriptService.

It has a couple issues though, and the main issue I want solved is when the train goes fast the main engine will end up making the bogies derail from the track and then the whole system fails. How could I fix this? Do I need to move from a heartbeat event to a stepped event since it fires prior to a physics simulation? I think the issue is maybe the engine passes before the bogies turn, therefore derailing it.

If my idea using physical bogies to detect when the train turns isn’t very good idea and you have a better idea let me know!

I do not want to use a node based CFrame system for the following reasons:
Its harder to know when the train needs to switch track -Future feature
I need to add nodes everytime I build the track.

I don’t want to use loops to loop through differen’t sections of the train to find a curve either and this won’t be possible in the future for me because I plan to make the rails one whole mesh in blender instead of having mulitple meshes to make up a curve.

Any help appreciated! Thanks.

#2

Bump bump, anyone able to help please?
Its been 15 hours since this post and there has been no replies.

#3

Bumpy bumpy, again, I’m still needing help! Please!

#4

Sorry for bumping this up to the top.

I do suggest you use node based CFrame trains, instead of bogies and stuff like the chassis you described, as it could lead to potential derailments.

I think this may be irrelevant, but I’ll share it anyways. My method of making nodes were to use a node layer, so essentially a physics based train that lays down nodes using a coroutine.wrap function so that the WaitForChild() function wouldn’t permanently yield. As for junctions, you can use raycasts for junctions, that then could switch the next node. Though one of the disadvantages with the node layer is that if you plan on doing further extensions you need to either manually add the last node, or redo the whole route from the terminal, but I’d say it’s much better than using nodereferences.

Why? because if you have to use Node References, and you reroute part of the route, as in the middle of the route, now you have to rebuild the node references all over again, from my experience at least, because it interpets the new node references as NOT parts that it should go through, but parts that it should skip, then once it reaches its actual destination, the next node would be the rerouted node, so that’s why i prefer using Node Layers for CFrame train nodes. If you want a node layer, i can give you the script for it. I’m always happy to help!