RailConstraint Physics Object


#1

Problem Statement:

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.


#2

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.


#3

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.