Help, llSetPos causing random phantom on link object.

I am having an issue using llSetPos on a set of linked stairs. On my parent prim I am using a llDialog box that triggers a llMessageLinked and all the steps change their position accordingly. Problem is half the prims are losing collision detection and on a set of stair the result is rather interesting.

The most flustrating part about this is all sorts of random behavior I seem to be getting. Not all steps are effected while some are totally effected. Even weirder on some steps only some of the faces are effected. Also when rezzed that way is fine but the opposite state is the one thats bugged. I have tried to force some kind of solid state using everykind of status setting script I can think of to no avail.

I don't really what to use 16 listen scripts for all the steps so any help I could get on this would be greatly appreciated.

I had a similar sort of problem... trying to do something involving an avatar sitting on a child prim, then moving it with SetPos on the child prim. Result: the prim appears to move, but my avatar sitting on it remains where he was, sitting in mid air. The moved child prim goes phantom, can't even click on it to edit it. I reported it as a bug, haven't heard back. Don't have any sort of solution unfortunately, but would be interested to hear if anyone has a workaround.

I just tested that one and its very interesting. I also did llSetRot and when the pieces rotate you also don't move with them. I also tested llSetRot for the whole collision bug and all the surfaces worked fine. I would have guessed that they would have the same problem because the child prims are still being reorientated but that would make to much sense.

I really wish the llSetPos function wasn't so messed up with child prims. The effect the stairs have is very cool and it would be nice to walk up them without falling threw them halfway. For added enjoyment I have a picture of me falling threw them because I think it looks funny doing that little fall dance while a set of stairs is cutting you inhalf.

Has anyone noticed if using llSetPrimParams behaves any better for child prim repositioning?

I had a problem like this on a simple sliding door. It was part of a larger object. The problem wasn't the fact that would phantom, but that it would phantom if someone was clicking the living hell out if it.
I had to make an integer for when it was moving, if someone clicked and it was STILL moving, it would ignore them.
No phantom after that.
But... that was only a couple of meters....
Stuff does still turn phantom. Try reinforcing with SetStatus.

Try calling llSetPos in the parent after your child prims have adjusted themselves, that may give Havok enough of a kick to re-read their new positions.

Something like:
vector startPos = llGetPos();
llSetPos(startPos + <0, 0, 0.1>;
llSetPos(startPos);
==Chris

Slightly off the subject of phantoming, but this behaviour actually makes sense. When an avatar sits on an object, it actually becomes a child in the link set.

As you cannot nest link sets, it only makes sense that the avatar doesn't move when you move a child prim (no more than any other prim in the link set would move).

I suppose the inconsistency in this is that sit targets in child prims are specified relative to the child prim's location, but once the avatar sits and is "linked" into the link set their position from that point on becomes relative to the root prim.

Ah, ok, that does make sense. Shame, it makes what I was trying to do impossible (in that way) as far as I can see. (Further off topic...) I was trying to move the parent prim without (effectively) moving the child prim, by moving the child in the opposite direction. This works, but you can't carry an avatar doing that.

Jillian Callahan - llSetPrimParams caused no differance in behavior as far as I could tell.

Burke Prefect - This was actually the first things I tried back when this first started happening. I even tried llVolumeDetect(FALSE) just to cover all my bases.

Christopher Omega - I also tried this at first but I wasn't moving the parent just have it on zeros. I went back and added 0.1 and that didnt help and I can see this just creating a set of stairs I'll have to readjust everyday.

Ushuaia Tokugawa - Thanks for that explaination. Looks like we got one problem figured out

In the mean time I created the lamest freaking solution to it. I rezzed the stairs in the down position so when they go into its disc form thats now the buggy end. Then I created a solid transperant cap over the top that isn't linked and set it on a listen so when it hears the stairs go down it will go phantom. Like I said before I don't like this solution at all. I feel like I am just hanging a picture infront of a big hole in the wall. Sure it looks nice with the picture and all but you can't help but remember the dark soul swallowing void of truth lurking behind it.

I am still working on it and remain open for ideas on ways to get the problem to go away. I would like to thank everyone who has helped with suggestions so far and please keep them coming.

like so many things we do in life.


thanks for the new sig

You're welcome

I am sure as these stairs slowly take me from obsession to the brink of sanity more quotable ramblings will follow up until the point I am just a drooling shell of a man only able to utter "Staiiiiiirs" semi-coherently.

I look forward to more of your misanthropic wailing

Back on topic I tested llTargetOmega(<0,0,0.001>,PI,1) based on the same line of thoguht that it might force the game to remember wtf it should be doing. I instead got a spinny phantom carousel of doom.

The good news in all this is while going threw the list of functions to find an answer I found llPizza. I don't think this will solve the phantom problem but I can atleast enjoy a slice of pizza to help me forget all my troubles and woes. Horray for the greatest function ever! Who needs objects to remain solid when you can have pizza

Hate to necro this old topic but I have an important update about this bug.

IT'S FIXED!!

As of 1.7 this is no longer a problem. In the release notes under "Minor Features" there is a line that says - Added ability to rotate and position subsets of linked objects.

I have retested the stairs and they work great. Finally I can put this damn thing behind me and sleep at night knowing there is a bright new day ahead of us all. A day where objects can shift and move at will and not go ape shit and attack their creator. Oh beautiful day. Bring forth new inventions of morphing objects likes cars, houses, and love bots. Sweet sweet love bots. How you hide yourself as a innocent looking coffee table but transform on my command to fulfill my desires. Your such a slut arn't you you dirty little love bot. Yeah daddy like.

Anyway the problems solved.

When using llSetPos(llGetLocalPos() + <0, 5, 0>; (to move a child prim). The child appears to move relative to the rotation of the Parent. You 'see' it moving as you would expect it to, but in an unvisible way it actually moves relative to the local grid.

Try putting this in the child of a linked pair of boxes:

llSetPos(llGetLocalPos() + <0, 5, 0>;
llSleep(5);
llSetPos(llGetLocalPos() - <0, 5, 0>;

in a touch event (I added it to the touch event in the default script). It works as expected, but then rotate the linked pair 90 degrees. It APPEARS to move the child in a plane 90 degrees rotated from before, but invisibly to you it doesn't! The child actually moves in the same plane as before the rotation and only appears to move relative to the root prim's rotation. You can walk around and bump into the actual invisible location while walking through the box's apparent location as if it were phantom.

It just moves paret's axis along. If you want it to move its own axis along, use this.
llSetPos(llGetLocalPos() + (<x,y,z> * llGetRot()));

I tried Candy's example and got something similarly weird. This is definitely a bug.

So your saying that when it updates the position, visualy it works properly but when it comes to the bounding box it ignores the rotation of the root prim.

It doesn't ignore it (at least for me), but it does something wrong with it. I had root prim turned 90 degrees from ZERO_ROTATION, and the bounding box of the child prim was at 180 degrees from where it was when the root prim was at ZERO_ROTATION.

This got fixed pretty quickly! I can't reproduce the bug now, it seems to have been killed. Thanks Lindens!