A while back now I mentioned some problems we were running into with the keyframed movement system. While this is somewhat improved - possibly as a consequence of the impending arrival of pathfinding on the Grid as a whole - there are still issues, especially with region restarts. The lifts running up and down my tower in Burroughs still freeze when the region restarts, and are a little erratic in resuming function.
So, by way of experiment, I rigged one to sort itself out when the restart hits. Basically, this is run off the "changed" event, because one of the things it picks up is the starting up of the region. (I have an explosive device in Steam SkyCity, in fact, which counts the number of times the sim has restarted. And then explodes.) So, this one lift, now, when it detects a restart, shuts down keyframed movement, uses the old warpPos trick to go to its starting point, and then starts keyframing going again. In theory, then, the next time a restart hits, this thing should go right on moving as normal.
I mentioned all this to Tali, and she said, "WarpPos? You do know llSetRegionPos is live now, right?"
Well, this is why Tali is an accomplished creator and I am a dumb blonde; yes, I did know, but it had temporarily slipped what passes for my mind. So I turned back to the lift...
... and I thought to myself, hang on, this is an excellent moment to run some comparisons, here.
WarpPos is not an LSL function, it's a trick developed by sneaky programmer types; it works by calculating a number of steps between where you are and where you want to be, and using llSetPos to move an object along those steps - the trick being that, due to a quirk of the implementation, all these repeated calls to llSetPos are executed in the same physics frame, thus making the transition effectively instantaneous.
The newer llSetRegionPos actually does move an object, straightforwardly and simply, from point A to point B (if both points are in the same region). So there is not a lot of use for warpPos any more, unless you're going outside a sim... but...
The much-published warpPos user-defined function has an error margin of 0.01 meters. In the documentation, llSetRegionPos is given an error margin of 0.1 meters. Now, this may be simply LL covering their backsides with a generous allowance for errors, but - I thought - it might be interesting to see how the two compare in practice. So I edited a second lift and set that to use llSetRegionPos.
So, it will be interesting to see how the two compare. The ideal result would be for both lifts to handle the sim restarts normally - but it is possible that, with the wider margin for error, the llSetRegionPos one will drift, gradually, out of position over the course of weeks. (It is also possible, or even likely, that they will both hit an unsolved keyframing bug and fail to restart properly. Well, we shall see.)
An experiment in progress! I may have results in, oooh, a month or two.
New functions demand new workarounds and exploits!
ReplyDelete