moving_end(): Is it just me?

I seem to get inconsistent results from this event. Sometimes it triggers when I move the object, sometimes it doesn't. A while ago I did fairly extensive testing, and it absolutely did not trigger in response to a call to llSetPos(). Now it does. Sometimes. Is it just me? Am I missing something?

That's been my experience too, that it's very inconsistent.

Unfortunately I have no solution or suggestions, in my case I was able to work around it to some extent.

I've used it with good results when the object is moved using inworld build tools. Inconsistent results when the object is moved via script. Perhaps it's a timing issue?

Yeah, I've never had any problems with it responding to the build tools, but now I am. The thing that troubles me most is its inconsistent response to llSetPos(). I'm working on a set of objects which, when any one is moved, it broadcasts the change to the others, and they move accordingly. If moving_end() is triggered by llSetPos(), it's easy enough to set a flag to have it not broadcast those moves. But if moving_end() *doesn't* get triggered, that flag doesn't get reset, and the next manual move gets ignored. And if I don't use a flag and moving_end() *does* trigger, I run the risk of moves cascading.

I'm going to do some more testing to see if I can determine the parameters of the issue a little better, then file a bug report.

I'm kinda not suprised considering how setPos works, it ignores intervening space... does it also have the same behavior when entering coordinates in the edit window?

you could abuse the timer and test getPos when it's the same trigger your code that you'd use in move end? not a nice solution, but I bet it's more reliable

So does a move with the build tools, as far as the server is concerned. Move info isn't relayed from the client until the arrow is released.

Yes, it's the same behavior.

Yeah, I thought of that, but really want to avoid that, especially since I'm already using the timer for somethiing else, so I'd have to interleave the events. This is supposed to be just a simple little tool to help me with builds. Quite frustrating.

Anyway, I've reported the issue; please vote for it:

you could abuse the OTHER timer... since they built a nice repeat timer into sensor, it's just as effective as a timer... just tell it to look for something it won't find... like it's own object key...

as for the 'same behavior' remark I meant did you find the same thing happening (end move not firing) when numbers where entered in the edit window (vs moving by the handles which for some reason does work)

An interesting idea. Seems it would be less efficient, though, since it would essentially be the same as putting a call to llSensor() inside a timer() event, when there's no need for a sensor sweep.

Yes, I understand. I get the same inconsistent behavior, whether I use the move handles or enter numbers in the edit window. Sometimes it triggers, sometimes it doesn't.

I was thinking a range of zero, might limit any effeciency issue, I've only abused it this way once, and used a larger interval...


good to know, as you can see I thought it WAS working consistently for the move handles... thanks for the clarification