Getting the initial position of a duplicate object

[animats]

I'm trying to get the initial position of a duplicated object. I need to rez some related objects that can't be child prims, because they are keyframe animated.

When an object is rezzed, the new object gets an on_rez event, but not a script reset. When an object is duplicated, with shift-D, the new object gets a script reset, but no on_rez event. OK.

If you call llGetPos() in the state_entry event of the default state, on a duplicated object, you get the position of the original object. llGetPos() does not return an updated position until user editing mode is exited. A timer event still sees the old position until edit mode exits.There's no event for "end of edit mode", although there's a "changed" bit if size changes. There's no  move_end event for edit-type moves. So it's tough to get the new object's position.

The best workaround I can think of is to start a periodic timer on state_entry. If the position changes, the user moved the object after duplication or creation. If the position doesn't change in a minute or two, shut down the timer. Kind of hokey, though.

[Rolig Loon]

It is kind of hokey, but it works.  When I have two objects that cannot be linked but need to keep the same position relative to each other, I use exactly that method.  Run a timer in the main object that pings every minute or so to tell the other object where it is and force it to realign if the main object's position has changed.  You can also have it do a sanity check to be sure that the other object is still there and, if not, rez a new copy in the proper spot.

[ellestones]

with dragcopy, the new copy is at the position of the original object and it is the original that is dragged/moved

with KFM enabled then when the dragcopy is completed, the moving_end event in the original object should fire. The script in the copy at the original position being reset like you have observed

[Rolig Loon]

26 minutes ago, ellestones said:

the moving_end event in the original object should fire

The important word is "should."  Unfortunately, as the LSL wiki says,

"This event's behavior is undefined for non-physical movement (llSetPos, movement via build tool, etc.) although these movements will often trigger it."

I've found that this undefined behavior often means that the end_moving event does not trigger if you have moved the object with your edit tool. You can't rely on it.

Edited December 9, 2018 by Rolig Loon

[animats]

17 minutes ago, Rolig Loon said:

The important word is "should."  Unfortunately, as the LSL wiki says,

"This event's behavior is undefined for non-physical movement (llSetPos, movement via build tool, etc.) although these movements will often trigger it."

I've found that this undefined behavior often means that the end_moving event does not trigger if you have moved the object with your edit tool. You can't rely on it.

Yes. I have a test cube which displays all the relevant events, and moving_end does not fire after an edit move. If you turn physics on and off, though, it fires.

No combination of the available info indicates "end of editing". A "changed by build tool", like the "changed size" flag, would have been nice. That would tell scripts "I was just edited manually, go recheck and adjust everything". Another one of those "not enough info" gaps in LSL, like not being able to be sure your avi can enter an area before actually entering on a vehicle, or not being able to read the object return time for an parcel from LSL.

[Rolig Loon]

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.

[animats]

2 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.

Someone who'd built a big wind turbine showed up at Server User Group once to complain about that. His wind turbines kept stopping and he didn't know why.

[Rolig Loon]

4 minutes ago, animats said:

Someone who'd built a big wind turbine showed up at Server User Group once to complain about that. His wind turbines kept stopping and he didn't know why.

That would be it.  I have had windmills stopped that way and I have talked to enough scripters with similar stories to recognize the problem. I now regularly add that little bit of kickstart code to any object like that, on general principles.  A small script with nothing more than a timer event that flips llSetText on and off regularly is all that it takes.

[Wulfie Reanimator]

13 hours ago, animats said:

Someone who'd built a big wind turbine showed up at Server User Group once to complain about that. His wind turbines kept stopping and he didn't know why.

13 hours ago, Rolig Loon said:

That would be it.  I have had windmills stopped that way and I have talked to enough scripters with similar stories to recognize the problem. I now regularly add that little bit of kickstart code to any object like that, on general principles.  A small script with nothing more than a timer event that flips llSetText on and off regularly is all that it takes.

Also.. your suggestion, Rolig, may be exactly why that person's wind turbine was resetting for no apparent reason. Prim property changes. Not someone selecting them.

Edited December 10, 2018 by Wulfie Reanimator

[Rolig Loon]

5 hours ago, Wulfie Reanimator said:

Also.. your suggestion, Rolig, may be exactly why that person's wind turbine was resetting for no apparent reason. Prim property changes. Not someone selecting them.

No, that's backwards.  The windmill doesn't reset when selected.  It freezes, as you would expect it to when selected in edit mode, but does not resume rotation when it is unselected.  Kicking it by changing a prim property doesn't reset the script either.  All it seems to do is jiggle the server to send an update signal to your graphics card, which has the effect of telling it to resume llTargetOmega.  In my experience, you don't need to be the object's owner or have mod perms to stall the object.  You simply need to be curious enough to select it with the edit tool.  The problem is maddeningly inconsistent.  The object doesn't always stall when selected, but often enough to be annoying.

[animats]

3 hours ago, Rolig Loon said:

The problem is maddeningly inconsistent.  The object doesn't always stall when selected, but often enough to be annoying.

There's a bug where the viewer and server get out of sync on object updates. That's the bug which causes doors to look open while being closed in the physics sense.  What it looks like is viewer side; collisions are server side. Object update messages keep them in sync. There's a bug a few months old in this area. This came up at Server User Group last week.

Edited December 11, 2018 by animats

[animats]

On 12/9/2018 at 2:04 PM, Rolig Loon said:

It is kind of hokey, but it works.

Yes. I have a moving sidewalk with one prim driven by keyframe animation. The scripting for assembling it properly it after rezzing, moving, resizing, or duplication is 5x more complex than the scripting that makes the sidewalk move.

Incidentally, the size of something being keyframed animated cannot be changed without stopping the keyframe animation first. The documentation says you can't change the size of an object with physics on, but that extends to keyframed, too.

[steph Arnott]

You are aware the the duplicate is the one that does not move and the original is the one you moved?