Physics collision issues

Greetings!

I’m relativity new to the Roblox Engine, so I think this might be a bit of a trivial question, but currently I don’t know where to approach this problem. I was playing around with trying to build a pinball machine and I started out by creating two flippers, which are both unions made of three parts, and a simple pinball. However, as I try to implement ways to make the pinball bounce off the flipper when the two come into contact, I run into this issue:


I have a few guesses of why it might be this way. For one, the flippers are unions, and I heard that unions have issues at times (not sure what). For another, there was one post online that I remember reading which emphasized needed to make server and local copies of parts to reduce lag within certain games, and this is all basically server sided (besides a local script which fires events saying when to move the flipper). Finally, I’m thinking that it might be because tweens may not be the best for physics based calculations or events.

In case more info is needed, I have included the .rblx file here: Pinball.rbxl (37.8 KB)

Any help would be appreciated!

2 Likes

The flippers act like this because your changing the CFrame of the Unions. When changing CFrames roblox doesn’t interpolate the part that was changed as it treats it as if you are teleporting that part.
Using constraints should be able to solve your issue. I’m not an expert on them but it looks like HingeConstraints are the best for this.
Constraints (Rotating Attachments) - Tutorial on the DevHub

1 Like

It’s possible to still do it with just Tweens or CFrame by figuring out the exact RotVelocity and Velocity to give to the Unions, just the way the physics engine would if the flippers were simulated using Constraints.

RotVelocity would have to be a vector whose direction is the axis of the flipper’s rotation and whose magnitude is the rotation speed in radians. So if you tween by CFrame.Angles(0, 0, math.rad(45)), then the direction would be flipper.LookVector and the magnitude would vary based on the tween type, but for Linear, would just be math.rad(45) divided by the time the tween takes. (flipper.CFrame.LookVector * math.rad(45) / tweenLength)
Velocity is a little tougher; it’s supposed to be the movement of the center of the flipper’s bounding box. For Linear, the Velocity’s direction would be perpendicular to both the axis of rotation and the vector between the flipper’s center and the hinge’s position: flipper.LookVector:Cross(flipper.Position - pivot.Position). Its length would be proportional to the rotation speed and the distance between the pivot and the flipper’s center (not sure how many pis go there).

Phew.
It really is best to just drop the CFraming/Tweening and even any and all RemoteEvents, and just simulate the entire thing on the client.
Create the ball and flippers on the client, or assign network ownership to the player.

This is assuming each pinball board is single-player.
Multiplayer pinball would require setting ownership of the ball to nil (auto-assign), or possibly having a complicated smoothing scheme and invisible collision balls and a visible display ball. But there is little reason to keep the flippers server-owned (unless you’re changing their positions locally for immediate feedback). You may want to verify the balls’ and flippers’ positions to catch exploiters.

1 Like

It really is best to just drop the CFraming/Tweening and even any and all RemoteEvents, and just simulate the entire thing on the client.

I’m not quite sure I understand this part - if you were to create a local copy on the client, wouldn’t you still have to use CFraming/Tweening/Constraings in order to move the flipper? The reason why I tried to make it all server-based was because I was taking exploiters into consideration, but I guess I could just make a server copy on top of a local version that’s invisible to the client in order to confirm collisions and stuff to prevent exploitations.

You seem awfully worried about exploiters.

Does the game have any reason to exploit?

  • Is the game multiplayer (on one board with multiple players)?
  • Does it have a leaderboard, badges etc.?
  • Can other players see your board?
  • Is there any way an exploiter could ruin things for others by just teleporting the ball and flippers anywhere, anytime?

If you answered “no” to all of these, i.e. it’s just a singleplayer pinball board, then you have no reason to worry about exploits in the first place and can even generate the entire board on the client and not do a single exploit check. Space Cadet doesn’t ping Microsoft’s servers for permission to move a flipper whenever you push a button; it’s all on your computer. The point of a server is replicating things to other clients; if what’s on your screen doesn’t matter to anyone else, then there is no need to interact with the server.

If there is some kind of damage an exploiter can do, then you’re still best off simulating a lot of things on the client, so that the controls are snappy (instead of waiting for a server round trip to show you the flippers moving)
Note that the Studio Play does not simulate lag, so your place will work fine in Studio but have nasty input lag in a live game.

Use constraints, so that you don’t need to figure out any Velocities.
Let the player own the flippers, so that you don’t need to send a remote event each time you flip and so the controls respond immediately. (Ball spawning still needs a remote)
Make a localscript actuate any constraints/movers on the flippers.

On the other hand, constraints (unanchored parts) might let exploiters spin the flippers around as they please. So Tweens are still on the table if you wish for increased security.
Tween the flippers both locally and on the server, so the player can immediately see a response.
Send the remote event as you did in your test place so the server can move them.
Ignore what I said about Velocity: all that’s needed is to set RotVelocity on the Anchor part. But figuring out the current rotation speed of the flipper is still hard.

1 Like

Does the game have any reason to exploit?

Ah yeah that’s a good point I haven’t considered. I guess I’ve been so accustomed to seeing people continually pushing to try to make your games as anti-exploitable as possible that I’m trying to stay extraordinarily safe, too. Thanks for the help!

1 Like