Alright I’ll just suck it up and use CFrame. It will probably be a lot easier than any other way. Thanks for the help guys.
3 Likes
Okay, I was wrong, CFrame is not my solution, for reasons you stated. I need players to be able to ride in the minecart. How do you tween the BodyPosition to do this?
3 Likes
I’d say make a node path for the train, then just have a bodyposition in the train that you progressively change the position of to the node, once the magnitude of the train and the node are below a certain point (i.e. it’s reached the next node along) change the bodyposition’s position to that of the next node along.
3 Likes
What about turns? That seems like it’d be pretty complicated.
2 Likes
It shouldn’t have a problem actually going round a turn, but to make it face a certain direction you would probably want to use BodyGyro
1 Like
I have a Minecart in my game, and looked at a bunch of approaches while working on my project.
Don’t:
Physically model the Minecart based on real-world mechanisms:
Real-world mechanisms work because of real-world laws of physics. When you model mechanisms based on their real-world counterparts, you run the risk of it breaking down when those laws aren’t the same in Roblox. You also take on all limitations of the real-world mechanism e.g. cart will derail if moving too fast / may derail if mass not micromanaged to reflect real-world counterpart.
Use CFrame:
Moving objects like characters use physics to move around – they’re not built to work with objects moving with CFrame. You lose a lot of awesome functionality like interpolation and bodies following the moving part horizontally, and experience problems like bodies clipping through moving parts or getting flung far away because a part teleported into them. There are ways to mitigate this, but implementing custom physics with CFrame is a major hack. It doesn’t provide any real benefits, and is a massive headache.
Use legacy body movers:
Old physics objects like BodyGyro/BodyPosition are no longer being actively supported and can have unpredictable behavior.
Solution:
To dictate where the minecart should travel, I use the node system suggested by @SteadyOn earlier. If you look at the track below, you can see green dots. These are attachments which I use to designate the next node the cart should travel to:
To move the Minecart, I use AlignOrientation/AlignPosition. These are normally used for keeping an object in-place rather than moving it, so I connected them to a proxy part which I move with CFrame. The proxy part being moved in the following video is pink, and the minecart is attached to that pink part with AlignOrientation/AlignPosition.
With this, you get the control of CFrame, but the benefits of physics simulation at the same time. In the following in-game (with latency) video, the minecart’s network ownership is set to the player sitting in the cart. The video is recorded from the perspective of the player standing on the cart.
Note that because the minecart’s location is being controlled by CFrame, it does not speed up or slow down on slopes. This was intentional for my use case, as I wanted to be able to build tracks without worrying if the minecart had enough speed to get to the end – it just goes the same speed always and predictably. If you wanted a more accurate physics simulation, you could probably use a different set of constraints.
152 Likes
Thanks so much! Especially for all the details.
2 Likes
I know I won’t stop asking so many questions, but how did you get the cart to always stay above the node? I’ve been messing around for over an hour and can’t replicate that. It usually drags a bit behind before moving which makes it look weird. It’s also getting stuck after a short time again.
1 Like
The attachment for the pink part, which follows the nodes, is at its center, but the attachment for the minecart is below the root part the AlignPosition connects to:
The AlignPosition keeps the root part’s attachment in the same position as the pink part’s attachment, and since the root part is a stud above its attachment, it gets held a stud above the pink part.
7 Likes
Alright, thanks. What exact settings does the AlignPosition have? Like I said, mine lags behind my node.
You need to enable RigidityEnabled on both the AlignPosition and AlignOrientation.
4 Likes
Thank you, again. Now the cart works perfectly until I sit in it, in which case it flings around everywhere. I tried using custom physical properties to make players weightless when they sit in it to no avail.
Sorry if this is getting annoying, but once again some help would be appreciated.
Can you upload a rbxl file here with the cart? I can take a look at it.
I’m sure you have better things to do but some help with this would be amazing. I’m kinda out of ideas at this point.
Oops, I missed your last post. There are a couple things going wrong here.
Issue #1:
Your minecart is clipping with the track, causing instability. If you enable the physics analyzer (Test tab) and run the game, with or without the player sitting in the minecart, you’ll notice it picks up on an overconstraint:
Clicking on “Issue 0” with select the offending part, which in this case is clipping with the rail. The rail wants to push the cart out since it’s not physically possible for an unanchored object to clip with another, but the AlignPosition is forcing the cart back. Because these two are fighting, we get an overconstraint – instability. It’s probably more severe with players in the cart due to humanoid behavior, but it happens without players as well (you can notice it slightly jittering around).
Solution #1:
You’ll notice that the flinging only happens on rotation (e.g. cart flips forward), but not position. This is because you haven’t enabled RigidityEnabled for the AlignOrientation. You’ll need to enable this anyway for when your minecart is travelling in more than a straight line, so switch it on. Once enabled, the cart will no longer fling around because the constraint is locking its orientation. HOWEVER, this only solves the symptom of the problem – you need to address the clipping as well.
Solution #2:
Add minecarts to a collision group that can only collide with player characters. This will mean they are never clipping with anything, but players will be able to fully interact with the cart physically. I suggest doing this with any moving platform (e.g. minecarts, elevators, etc) due to subtle instability with the PGS physics solver which can cause any body to be slightly offset from where it’s constrained to be (e.g. I had an elevator that got pushed a fraction of a stud off its PrismaticConstraint and then couldn’t fit through a hole in the ground)
Solution #3:
Instead of using a collision group, you could just disable collisions for parts of the minecart touching the rail. For my minecart, all of the transparent parts are CanCollide=false:
There’s nothing to clip with the track. You can do the same with your wheels, which will stop the clipping without needing to use collision groups. There’s also another issue you need to resolve before using this though: your minecart is too close to the track. In the image above, you can see there’s a lot of space between the cart and track (red line). Your minecart is being pulled into the track (see Issue #2).
Issue #2:
Your attachments are set up so the minecart is held above the rails:
but when the game runs, it gets pulled down into the track:
This happens because ApplyAtCenterOfMass is enabled for your AlignPosition. This is not something you want to enable for this implementation. Once disabled, the minecart is again correctly positioned above the rail
Final product:
Minecart.rbxl (27.9 KB)
28 Likes
Thank you so much man. I didn’t even know a physics analyzer existed, I probably would have given up if you didn’t help me. I will take all your advice and hopefully have a cool minecart for my game!
11 Likes
Hey guys, I noticed a link to this topic from the Physics suggestions one. If you’re interested in moving a cart along a track using physics you might want to take a look at an old abandoned roller-coaster project of mine (wait for the track to calculate and draw, you’ll be put on the cart automatically) Test-Coaster
The basic technique is to pretend PrismaticContraints can curve by constantly deleting and recrating them with a new location/orientation based on where the cart currently is on the track, the physics engine automatically maintains momentum and does the right thing.
I’ve un-copylocked the place but be warned it’s very much a WIP and the code was never meant for public consumption, so it’s a bit of a mess. The relevant logic is in StarterGui/CoasterScript between lines 592-642. If you don’t want to wait for the track to draw every time you run the place comment out lines 579-580.
I highly suggest against trying to use this code, I won’t mind if you do, but you’ll be much better off re-creating this techinque in your own way. Besides you’re probably going to want to get it to work with NWSpaceks bezier tool since I never released mine. (he probably has a getPointAtDistance function for his curves, I would think)
SOME TIPS:
You can have more than one cart on the track at a time, and they’ll even collide convincingly, but do NOT try to conenct them together with any kind of constraint, even a rope, they will explode. Sorry, no multi-car trains using this technique.
It works best if your cart has a high mass.
Keep the distances your cart moves between re-alignments very small so the re-alignments aren’t noticeable.
Pre-cache the points along the track for speed. Yes, the entire track. Memory is cheap.
15 Likes
I have one question though.
Is it really possible for your cart to not derail even if you go like 300+ speed
Of course since EchoReaper’s system uses CFraming to move a proxy part (see post 17) which is only moved to the next node on the track.
Then they use physical constraints to align the cart to the proxy part.
1 Like