Make llDetectedRot and llGetObjectDetails(id,[OBJECT_ROT]) return accurate results for avatars even when they're neither sitting nor in mouselook.
tracked
Q
Quartz Mole
LSL doesn't seem able to read avatars' rotations with any degree of accuracy unless they're seated or in mouselook. Allowing scripts to read avatars' rotations under all circumstances would make it possible accurately to rez objects using the avatar's frame of rotational reference and to track their direction of travel. It would also make llCastRay useful in many more circumstances.
Log In
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Bleuhazenfurfle Resident
I think this is coming? We're supposed to be getting attachment position information (albeit a little delayed, because it's coming from the viewer), and presumably (hopefully) better rotation information will be a part of that.
That
is
still coming, isn't it? It's not yet another shelved idea that'll never eventuate?Vincent Nacon
Bleuhazenfurfle Resident Wouldn't surprise me if this got moved to LUA scripting.
Bleuhazenfurfle Resident
Vincent Nacon: Is possible, though can imagine a few ways how it'd likely go, and I can't imagine any of them working out better than doing it as a built in feature. Easier, sure (and we do know LL like the easy way out), but not better — especially not for them, not unless they have something else fairly significant up their sleeve to go with it.
And I especially don't see the point (other than using Lua as a prototyping platform before they commit a feature to proper code), unless they reverse their apparent stance on Lua
not
being positioned as a companion to LSL… As an LSL companion script it could work quite well; a small Lua script delivered with the object could quite readily have access to the whole avatars worth of position information, in real time, and send just the bits needed back to it's companion script in directed messages (preferably a bridging version of link message, maybe KVP style with frame batching, or something), at the rate and resolution required, saving on both bandwidth and script time (you'll get some generic scripts that just send back more than is needed, but anyone doing a custom script will more likely shun the additional typing). This is much the same argument I've made about moving input control forwards to client-side Lua, where it can follow the inputs with much lower latency, and send back pre-processed parcels ready for the script to consume.On the other hand, more than one script might be wanting that same information, so you'll get the same information being sent back multiple times, and it may have been better to do it as an internal feature as was planned. And I don't see Lua being given access to the kinds of features that would allow it to have any advantage over a built in feature.
I'm just hoping my fear back when the feature was suggested — that it'll be too large a firehose of information — isn't what's held it up (if it is, have scripts request the information, sum those requests at the sim, and pass that along to get only what's needed, perhaps?), and that this request was just a, "hey, you remember that thing you were working on? We've just hit a thing where we could do with it being bumped up the TODO list a little"…
Vincent Nacon
Bleuhazenfurfle Resident Yeah, I'd be happy to take however it's done, it's long overdue to have this sort of function.
I'll admit that I'm actually leaning toward LUA scripting for this solution, but I'll take this if they feel this is the way to go for them.