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
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.
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
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.
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.
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.
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
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
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.
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.
