As a developer, it’s difficult to physically simulate objects that move on rails. As described here, there’s no great approach aside from essentially setting cart CFrame but with physics. This means no physical interactions such as changing speed on slopes or bumping into objects on the track.
I looked into solving this with a chain of PrismaticConstraints that hand off the cart to the next node, but turns are linear and snappy. I tried using a smooth curve of nodes with distances of 0.1 between each, but physics gets weirded out when the cart passes over multiple nodes in a single physics step and movement doesn’t replicate correctly.
The only other way for me to solve this is to use Torque/VectorForce constraints to manually simulate the physics of the cart. Writing custom physics from scratch is not ideal – the issues of no collision / accelerator in the first approach are more preferable.
Use cases:
Self-powered minecarts / trains
Self-powered roller coasters
Patrol path “rails” for self-powered craft or creatures in air/space/water
Flight path for a battle royale bus that circles the map instead of flying straight through it
Fish that swims through a tank
Spacecraft patrolling around a space station
Pushable defense objective on rails
Potential Solution:
RailConstraint. Behaves similarly to SlidingBallConstraints, but the physics engine/netcode can predict where the connected object will be next, and handing the object off to each segment is done automatically. Locking orientation like a PrismaticConstraint is optional (e.g. green puffers from Metroid spin as they float around). Giving a constraint a table of objects (nodes) would prevent it from being replicated and become a UX challenge, so maybe PreviousNode/NextNode properties would do.
We will think about a design. Maybe we can come up with a system that constraints parts to a path described by a spline on a list of attachments. This should be actuated.
This feature would be very useful when used in combination with a ParticleEmitter and/or Trail. Having this feature would allow us to set up paths for our particles emitters to follow, while drawing a trail behind.
I remember seeing this in one of the RDC events a few years ago. While it’s not a super critically needed feature, it’d vastly speed up the creation of things like tramways, cable cars and metro systems.
I’ve been experimenting with rail systems in different ways the past year. I’ve always wanted to achieve a method that is reliable enough to let automatic trains follow a given schedule.
I’ve tried with CFraming a root part on a given path with a set of waypoints but the code behind it gets really complex when the network of tracks and waypoints expands. It even came to a point that i couldnt wrap my own head around the code i’ve written.
Second thing i’ve tried is using constraints. For straight lines of tracks a PrismaticConstraint does the job in keeping the train positioned and preventing it from derailing. The issue is when curves are involved which it is in most cases.
If this feature would ever roll out that would be a big help for what i would like to achieve.
I’ve been picking at making my own version of the RailConstraint for several years now. The farthest I have gotten was actually a functioning, reliable concept of physics parts on prismatic constraints that switch between nodes as it goes down the path. I have nearly perfected the concept of a physics node following a path (representing a train car bogey or roller coaster car) – but when you try to implement switching (coupling, decoupling) railcars, changing the network ownership of a railcar physics assembly, all while trying to replicate all of the constantly changing data to the server so a new client isn’t out of sync… it flies farther over my head than distant stars.
I stall out on every single version (probably 10 of them by now haha) I have created when I get to networking and syncing… and most of those versions were designed around multiplayer compatibility (at least as far as my knowledge and ideas allowed). I ran into the same problem of finally making a working product, and after a busy semester of classes not looking at it I have no idea what I even made despite my many comments I made to avoid it from happening.
I strongly second the benefits that a RailConstraint type object would have, especially for games that revolve around rails, such as train games and theme park/roller coaster games. The physics load would be significantly less than physics wheels-on-rail trains or slider/friction based trains, and it would also be infinitely more stable. Not to mention how much more simple it would be to make.