llCastRay

SprSrsNoFun brought up an aspect of the llCastRay():llCastRay seems to not function properly once you get to a certain velocity.

The object with the script that executes llCastRay() starts to return somewhat random results once it reaches a certain speed. This is one of those real time problems that involve timing of the script, server, and physics engine. Since the server’s script and physics engines are asynchronous they are not in lock step. So, when the script fires the function may be in a different frame than when the physics engine sees it fired. One may not get the results they expect.

Simon Linden said it this way, “Well, your llGetPos() might execute on one frame, and the ray cast on another, after things have moved.”

Andrew answered, “SprSrsNoFun, the problem you’re seeing is that the script engine is running asynchronously with the physics engine. That is to say, the moments your script gets to run is spotty, and not necessarily synched with the physics engine.

Basically, the script can be put on hold at any point in its operation and revived some indeterminate time later. So you may compute the object’s position to use in your raycast, but by the time the raycast call is made the object may have moved a lot or only a little bit. It depends on how much time the script engine gets to run its scripts and which scripts get run in which order.

If something earlier in the frame took up more time than usual then the script system may get fewer milliseconds to run than the previous frame. Hence, the scheduling of your scripts really is randomly associated with the physics steps.”

Lomoco Binder suggested, “Something I can see that might fix this is; if there was a llCastRayLocal, where the input vectors are relative to the object doing the cast, so when the raycast is being performed by the server, the position it’s using is always up to date?”

Andrew agrees, “Yes Lomoco, that would work. The RC would then be able to compute the world-frame position in real-time.”

I suppose that means it is near-real-time now.

Summary

If you are not into real time programming this can get over your head pretty quickly. It is a geeky tech thing. Think of the problem as two people driving 2 cars. They are visually trying to get through traffic and stay side by side. One driver has few distractions and can concentrate on traffic and driving.

The other driver is texting, putting on makeup, trying to comb her hair, check her nails, and keep her skirt from ridding up all while driving… in other words a fairly common morning rush hour event. Every so often she catches up and gets the car beside the other car. But, she might miss a light and have to wait, her lane may slow, and any number of things can happen to get her out of position.

Now imagine they do all this driving and can only see each other once per minute.

llCastRay is like a kid in the back seat of one of the cars. He has a water gun and is trying to squirt the other car. He can’t see out to see the car. But, he can hear if the water hits. If it hits he knows the car is there. So, while the car is supposed to be there all the time, the car representing the script engine never really knows for sure where it is or where the other car is. The driver in the physics engine car has an easier time staying on pace and being where he/she is supposed to be.

The faster traffic goes the less likely the squirt gun with hit. The slower traffic goes the more likely the kid will get a hit.