Pls
Trying to make up for server lag by setting your sticky projectiles backwards by a bit is a huge pain; a point of contact that returns what “intersection” of touching fired the event would be nice. (Vector3)
1 Like
It’s been requested before, and will continue to be requested until it exists. C’mon, Roblox!
For now your should be able to RayCast from the origin to the touched part and get the position.
The issue is that a point does not necessarily represent the actual contact manifold. Often it may be a line or a plane, rather than a point. Even if the API gave you a point it would still be an approximation, just like the raycasting solution suggested, which makes it a kind of inelegant solution.
Having a contact point would also not solve the “sticky projectiles” problem that you’re talking about, because often the projectiles may not actually have been close to touching at any point from the Lua API’s point of view, and thus you will not be able to get them nicely connected even if the API gives you back a point of contact, you would need it to give you back the local points of contact on each body as well, and you would need to possibly move one or both of those bodies back to the point of contact.
In fact, it wouldn’t solve most of the problems that you’re thinking of using it for very well. It would be nice to have in the API in some form for completeness purposes, but I don’t think it would be as useful as you’re thinking.
I’m well aware that it would not be perfect, but something would be better than nothing.
[quote] The issue is that a point does not necessarily represent the actual contact manifold. Often it may be a line or a plane, rather than a point. Even if the API gave you a point it would still be an approximation, just like the raycasting solution suggested, which makes it a kind of inelegant solution.
Having a contact point would also not solve the “sticky projectiles” problem that you’re talking about, because often the projectiles may not actually have been close to touching at any point from the Lua API’s point of view, and thus you will not be able to get them nicely connected even if the API gives you back a point of contact, you would need it to give you back the local points of contact on each body as well, and you would need to possibly move one or both of those bodies back to the point of contact.
In fact, it wouldn’t solve most of the problems that you’re thinking of using it for very well. It would be nice to have in the API in some form for completeness purposes, but I don’t think it would be as useful as you’re thinking. [/quote]
uh, yeah
I just want something which tells me “This was the position where it touched” or a rough approximation.
Because accounting for server lag with touched events is a disaster.
I want something on the left, as opposed to using raycasting and stuff on the right for whenever the .Touched event decides to actually fire.
The red shows the path of the thrown ball, and if it’s uncancollide it’ll go straight through the wall and travel for a bit before going like “oh crap, we touched something, quick stop at your current location” if I want it to weld or become anchored.
I used rays before at they’re a disaster with lots of moving objects. Even stagnant, they sometimes end up floating in the air or not detecting where its last “hitpoint” was, idk.
It just seems more logical to have it be like “missile.CFrame = CFrame.new(hitpos)” rather than making rays and using averages/ calculations to determine a best guess for this crap. All because .Touched is 2slow
You could always CFrame projectiles, thus being able to get the exact collision point, by ray casting in direction of velocity. For projectiles this would work perfectly, but not for objects, that can get affected by other moving bodies moving in from side.
“Because accounting for server lag with touched events is a disaster.”
You’re seeing that problem because the one simulating the object in question is not the server, so there will be an extra network hop worth of delay on all of the touched events for it. You need to listen for events on the same client/server that is actually simulating the object. But how do you do that?
If you put RocketPropulsion inside of the body in question, with some negligibly small force, and then call :Fire(), the instance that called :Fire() will force take ownership of the body in question for the duration of it’s lifetime. In that way you can forcibly make sure that the one listening for the Touched events is the one that is actually simulating the object.
Simulate your own projectile physics using raycasting and .Heartbeat! 
[quote] “Because accounting for server lag with touched events is a disaster.”
You’re seeing that problem because the one simulating the object in question is not the server, so there will be an extra network hop worth of delay on all of the touched events for it. You need to listen for events on the same client/server that is actually simulating the object. But how do you do that?
If you put RocketPropulsion inside of the body in question, with some negligibly small force, and then call :Fire(), the instance that called :Fire() will force take ownership of the body in question for the duration of it’s lifetime. In that way you can forcibly make sure that the one listening for the Touched events is the one that is actually simulating the object. [/quote]
I am creating the parts from a ServerScript that’s fired by a ServerEvent induced by a client. Will that RocketPropulsion workaround actually begin simulating the .Touched event more properly/ immediately? Cause that delay is what I’m trying to account for/ get rid of.
[quote]
I am creating the parts from a ServerScript that’s fired by a ServerEvent induced by a client. Will that RocketPropulsion workaround actually begin simulating the .Touched event more properly/ immediately? Cause that delay is what I’m trying to account for/ get rid of. [/quote]
When you see that delay it’s not because the server is just arbitrarily deciding to delay the .Touched event. It’s because the closest client is probably picking up physics for that object, so the “touch” actually happens on that other client, not on the server, and there is a delay between the touch happening and the event getting to the server.
The RocketPropulsion thing should fix the delay, and make the .Touched actually correspond with the physical touch from the server’s point of view… at least as closely as the two objects ever do come during one of the script execution frames (As I said before, the objects may never actually be touching at any of the instants that Lua code gets to execute)
[quote]
I am creating the parts from a ServerScript that’s fired by a ServerEvent induced by a client. Will that RocketPropulsion workaround actually begin simulating the .Touched event more properly/ immediately? Cause that delay is what I’m trying to account for/ get rid of. [/quote]
When you see that delay it’s not because the server is just arbitrarily deciding to delay the .Touched event. It’s because the closest client is probably picking up physics for that object, so the “touch” actually happens on that other client, not on the server, and there is a delay between the touch happening and the event getting to the server.
The RocketPropulsion thing should fix the delay, and make the .Touched actually correspond with the physical touch from the server’s point of view… at least as closely as the two objects ever do come during one of the script execution frames (As I said before, the objects may never actually be touching at any of the instants that Lua code gets to execute)[/quote]
Why not make all physics to a part that has TouchInterest in them behave in that unbroken RocketPropulsion method?
“Why not make all physics to a part that has TouchInterest in them behave in that unbroken RocketPropulsion method?”
Just because the current behavior isn’t doing what you want doesn’t mean that it’s broken, in fact, it will be correctly in more cases than it’s wrong. If your building breaks and creates some debris you don’t want a character half way across the map simulating it just because it was his script that broke it. Projectiles and Vehicles are the cases where you want that specific creation ~ physics owner relationship. Unfortunately the engine gives you no obvious way to mark things as such other than the RocketPropulsion hack.
stravant I tried out the ugly :Fire() hack and it is not working correctly for me. In my towtrucks I have a very weak rocket propulsion in the seat. When a player sits, the local script calls :Fire(). When a player gets out and in again, it is called again even though abort is not called. Even so, the physics are not switching to the client.
I’m trying to use the rocketpropulsion trick; can you pass an argument with FireClient()?
Cause I’m trying to but it’s not doing anything with the passed argument.
I got the propulsion stuff working; it just doesn’t work as intended. The object doesn’t freeze in place fast enough.
There’s a middle to a line and a middle to a plane
Have .Touched return that middle
Reviving this thread in case an intern sees this and wants to implement it.
Accounting for server lag is crazy and the ugly hack suggestions aren’t easy to implement for the average user or down right don’t work.
Please add this <: my cannons and fireballs have their Explosion positioned under the ground because of server lag
I actually talked to Khanovich about this on day two. He said it was impossible and then proceeded to explain for the next 25 minutes why it was impossible.
Long story short, stuff like this is so deep in the physics code that bringing it up to Lua would make it slower than flowing molasses on a cold day. Sorry, but it’s just not going to happen.
Darn, thanks. And thanks for the lightning fast response
Any easy workarounds discovered in the last 11 months? I’ll try constantly raycasting from the front face (the projectile doesn’t spin mid-air) and when Touched fires, use the last raycast hit position to position the explosion.
1 Like