Part.TouchedBeforePhysics

Name can be changed to whatever, but basically here’s why I want it and what it’s for:

Current System:

  • Car hits tree
  • Physics math is done
  • Touched event let’s user make the tree anchored false (this lets the tree now be knocked over)
  • The car is recoiled. It’s hit as if the tree was anchored
  • Car now has to make a second attempt to knock the tree over

Demo #1:

Proposed System

  • Car hits tree
  • TouchedBeforePhysics event lets user make the tree anchored false (this lets the tree now be knocked over)
  • Physics are calculated, which now know that the tree is not anchored
  • The car pushes through the tree as if it were unanchored this whole time.

Demo #2 (I just left all of the trees unanchored):

I’m using low torque/speed here so my velocity and energy isn’t too great, but you can still tell that it performs much better on the second Demo where the trees actually fall over and the car continues to drive into it, contrasting the hit and bounce nature of the first Demo, where the car loses all velocity because it’s physics react to hitting an anchored object.

I don’t understand the engine very well, but to my understand it’d work like this. Instead of going

Hit -> Physics Math -> .Touched Event

It’d go

Hit -> .TouchedBeforePhysics Event -> Physics Math -> Touched Event

76 Likes

Support, but as a temporary work-around, you might be able to give the car a slightly larger uncancollide hitbox

3 Likes

That’s the old school method that I’m trying to avoid. Another solution is to set velocity back to what it was pre-impact, but all of these solutions are full of edge-cases and rely on perfect conditions.

5 Likes

agreed, hence the support. An engine should give you freedom, not boundaries and hacks you have to work around.

Edit: would it be cleaner to pass .Touched a flag of if it’s pre-physics or not? It would remove the need for the awkwardly long connection name

4 Likes

Uh nah, wouldn’t this conflict with any game currently using .Touched the way it currently works? It would mean the event being fired before anything is actually touched, and no one has written scripts that check for a non-existent arg

2 Likes

.Touched:Connect(Function,ConnectBeforePhysics = false)

If you look here

You’ll see that .Touched isn’t changed in any way.

Maybe a workaround for now could be: run some code on Stepped (not RenderStepped, not Heartbeat) that uses GetTouchingParts on the car to find trees/etc, and then unanchor them as needed. If I have to believe this diagram (I’m fairly sure the pipeline hasn’t changed), Stepped connections should run right before the physics update:

And then once something like what you’re suggesting is implemented (if ever), you can just remove that code and use the new event instead. You probably won’t have to modify your car that way or leave trees unanchored. There may be a small performance hit from calling GetTouchingParts every physics update, but really it should be a minor cost that you probably won’t notice.

The point of feature request is to avoid all of these weird hacky ways of trying to do this and give developers the freedom to easily make a lot more unique physically simulated maps and gameplay elements.

4 Likes

Yes:

Just trying to help out with a cleaner workaround than what was suggested before (since getting features implemented can take a while), sorry if that wasn’t clear.

1 Like

No I was replying to Weeve, he was suggesting that instead of adding .TouchedBeforePhysics we just use .Touched instead, and I was suggesting that would break a lot of games and produce unexpected behaviour for anyone just wanting to use .Touched as it is currently used.

1 Like

The code I posted, which you seem to misunderstand the use of flags would make zero change to current touched connections, and is backwards compatible.

The only downside of what I’m proposing is that it will be one of the few/only connection to pass more than one arg in, which is a valid complaint as it’s a departure from the current style guidelines.

I fully support ScriptOn’s feature suggestion, I only think the syntax would be nicer if there was an invisible second connection hidden inside the connect function, which gets used when flagged to true

Weeve the code you posted would mean that each collision makes the .Touched event fire twice. This would absolutely break something

edit: nevermind, I understand what you’re getting at now. Is there any other event that has optional connect flags like what you are suggesting?

I definitely support this. :octopus:

1 Like

Not that I know of, which is why I mentioned that one reason to reject my idea would be it’s a style change :-/

I don’t think that this method would work properly in a distributed physics environment.

1 Like

Wouldn’t it simply just be a logic change? With distributed physics, the connection would only need to be fired before the local machine performs the physics, and the second connection fired after the local machine performs the physics. This would happen regardless on whether the physics information came from a server, or from the local machine itself

2 Likes

definitely need this in my #robloxdev life

Support

Hmm. I feel like just-in-time anchoring/unanchoring things from a Lua script is still a workaround, not really the physics simulation solution for the example use case. The purpose of anchoring is really to exempt things from physics reactions, to make it easy and computationally efficient to have something simply stay put. If you mean for something to be physically interactive, I think we should consider how else this could be modeled or specified that does not require a hook into the physics engine to basically turn physics on for the object the moment before it is hit.

My thought on seeing Demo #2, thinking of these as pillars/dominoes instead of trees, is that if this is the behavior you want, what is wrong with having the trees unanchored? Is there a demonstrable performance problem with this? Even trees whose center of mass is offset from their base could be made to stay upright by a variety of means, such as a heavy invisible base disc, or a weak body gyro, or even a bodygyro that disables if knocked sufficiently far off axis (e.g. dot product of the tree’s CFrame’s upVector and Y axis becomes less than some threshold amount just under 1) so that you could explicitly set how much force it takes to topple the tree.

1 Like

That’s just a single usage case.

I want to make a fence out of 20 pieces of wood that break apart when you ram your vehicle into it. I want to make a flying piece of concrete from a building drop on someone and have them ragdoll. That way the concrete actually falls as it should without weird humanoid issues.

There’s so many usage cases for this.

1 Like