llTargetOmega... what is client-side?

[Wulfie Reanimator]

This was prompted by something @Rolig Loon posted in another thread.

16 hours ago, Rolig Loon said:

Another one of those is the "detect that someone has looked at me in edit mode" flag, which would be handy if it existed.  Objects moving in llTargetOmega can sometimes be stopped by a casual bystander who is curious enough to inspect them in edit mode.  One way to restart them is to change some prim property -- use llSetText to display a short transparent text and then delete it, for example.  The trick is knowing when to tell the script to do that.  My own solution has been to put the llSetText in a timer event that fires every minute or so, whether llTargetOmega needs a kick or not.  As in your example, it's hokey but it works.  It would be nice if we had something better.

I believe what you're talking about is a much older bug that was fixed many years ago. Back then, some things were not as client-side as they should have been and you could even stop physical vehicles/projectiles by selecting them. This is no longer the case as far as I know. But now that I've gone and tested things, this got even weirder.

I created a little windmill (so cute!) with a llTargetOmega script in the child prim and logged in with two Firestorm viewers at once to observe it.
Selecting the object on the viewer I logged in with first: Object stops on both viewers. (left)
Selecting the object on the viewer I logged in with last: Object will not stop on the first viewer. (right)
Then I got an actual friend over to double-check.
Selecting the object on the viewer I logged in with first: Object stops for them and my last viewer. (left)
Selecting the object on the viewer I logged in with last: Object will not stop for them or my first viewer. (right)
Them selecting the object: Object will not stop for either of my viewers.

Here is a video demonstrating the effect with two side-by-side viewers, but the same applies to outside observers in-world. Ignore the jittering on the recording, that was caused by the encoding process.
https://puu.sh/Cfu73/aa54cc5e01.webm

Edit: I tried changing the order in which my viewers were logged in.
This time, I logged in with my alt first, then my main (this) account.

When my main selects the object: It stops for the alt.
When my alt selects the object: It doesn't stop for my main.

I figured that since the object is actually owned by my main account, the object stops for everybody when I (the owner) select it. But if someone else (alt, friend) selects it, it will not stop for anybody else.

Edited December 10, 2018 by Wulfie Reanimator

[Rolig Loon]

That's very odd indeed.  The logic of it eludes me ATM.  Thanks for running those experiments, though.

[Madelaine McMasters]

I've seen this behavior, and presumed that when the owner of an object selects it, it changes state in preparation for being edited (which should stop all viewer side processing). Nobody else can edit it, so there's no reason to stop viewer side processing when they select.

Try giving your alt edit rights and see what happens.

[Rachel1206]

As Madelaine wrote (owner with full perm  rights) and good design ensuring easy testing, debugging of animated objects, when script developing something.

 

[ellestones]

On 12/11/2018 at 5:32 AM, Wulfie Reanimator said:

I figured that since the object is actually owned by my main account, the object stops for everybody when I (the owner) select it. But if someone else (alt, friend) selects it, it will not stop for anybody else.

am pretty sure this is expected behaviour

is how physical objects interact also. Once upon time anyone could stop a physical object (boat, car, etc) by right-click edit.  After a long time LL changed that behaviour so that owner-only right-click edit would stop a physical object. I would think that LL would have changed the omega behaviour to similar-ish as they used to stop on right-click edit also, by anyone for everyone

Is slightly different, phys vs omega, as I think you are saying that omega stops for a non-owner but only on their screen ? Which i would think could be seen as expected behaviour in the omega case

 

 

[Wulfie Reanimator]

59 minutes ago, ellestones said:

am pretty sure this is expected behaviour

is how physical objects interact also. Once upon time anyone could stop a physical object (boat, car, etc) by right-click edit.  After a long time LL changed that behaviour so that owner-only right-click edit would stop a physical object. I would think that LL would have changed the omega behaviour to similar-ish as they used to stop on right-click edit also, by anyone for everyone

Is slightly different, phys vs omega, as I think you are saying that omega stops for a non-owner but only on their screen ? Which i would think could be seen as expected behaviour in the omega case

Everything you said is what I'm saying.

[steph Arnott]

Depends on which viewer one is using. Have not had the issue with Firestorm.