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
basicly you are wondering what are the tolerance limits for the collision solver when it makes a decision to ignore geometry or skip simulation frames