llSetLinkPrimitiveParams & local teleport?

What is the current status of llSetLinkPrimitiveParams as a means of moving avatars about? Experiments yesterday seemed to suggest it doesn't now work over more than 10 meters. Is this correct, do people know, and, if it is, is there a work-round?

What I'm trying to do is this: avatar touches my (quite large) device, gets animated while the device does various cool things, and then vanishes in a puff of smoke. I don't want the avatar to go very far... 15 or 20 metres would be fine. I don't, though, want the device briefly to vanish along with the avatar and then reappear, and I do need the delay between the animation starting and the avatar being moved. That seems -- to me, though I'm probably missing something obvious -- to rule out solutions based on llSetPos or playing with the sit target.

Any suggestions? The animation doesn't need to be anything complicated -- I just want to hold the avatar there while things happen around him.

llSetLinkPrimitiveParams, llSetPrimitiveParams and llSetPos can only move the object or prim 10m far from current pos. The workaround is to move object in steps. WarpPos is a script that moves objects and prims anywhere in the sim in less than a second but im not sure if it still works with mono since it used a hack on llSetPrimitiveParams. But u can use that script compiled in lsl2 and just have it for that moment of "poof".
Here is the link: http://lslwiki.net/lslwiki/wakka.php?wakka=LibraryWarpPos

WarpPos works like a dream with Mono too

Last I knew it was limited to about 300m like a sit target, but that was weeks ago. I hope they haven't nerfed it even MORE.

I think being able to move a seated agent big distances via llSetLinkPrimParams was a mistake by LL - they didn't intend for it to behave that way - that residents noticed and started treating as a feature.

Some of us essentially requested that it BECOME a feature when it was discovered the function worked differently in different server versions. But oh well. http://jira.secondlife.com/browse/SVC-1433

See also:

http://jira.secondlife.com/browse/SVC-2931
http://jira.secondlife.com/browse/SVC-2745
http://jira.secondlife.com/browse/SVC-2543
http://jira.secondlife.com/browse/SVC-392
http://jira.secondlife.com/browse/SVC-704

It's reported in the changelog for server 1.25 that avatar repositioning will be limited with link distance rules.

https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Beta_Server/1.25

p.s.
I think it should be limited by sittarget distance not link distance rules.

Non-obvious special cases are asking for trouble, IMO. Some Linden, somewhere down the line, is going to just 'fix' it again.

I'd rather they did llTeleportAgent..

Honestly I can not see why it should be a mistake, that llSetPrimitiveParams(list rule) can be used the way it is in WarpPos.
All llSetPrimitiveParams() does is to execute the the list of rules from the beginning to the end

Because, from my point of view, llSLPP should be used to change the params of one item in a link set and not violate the rules of object linking.

Something like warppos is fine since it's moving a whole object around and not changing the rules just because an avatar is sitting on that object.

llTeleportAgent (http://jira.secondlife.com/browse/SVC-212) would be better. Not necessarily easy for LL to implement but still better.

I don't see the sittarget distance as being related to the link distance limit. They are two separate aspects of the simulator (and, yes, I realize that the avatar "simply becomes another link" on a linkset when he/she sits down, but that is still quite different, since an avatar is involved).

The link distance limit is there for probably some very good reasons (one I can think of right away is people linking tiny, invisible prims hundreds of meters apart and using them to grief). I don't think I want to see that limit made useless simply with a script.

Now, if they could limit it somehow so that it was only on avatars that it worked, then maybe. However, personally, I wish they would get rid of the need for all these stupid hacks and just give us llTeleportAgent(). Assign it a permission flag and be done with it. Intrasim TPs would just be the same as an unlimited llSetPos on the avatar. Intersim TPs would use a loading screen like the map teleport, but without the map coming up. More like what happens when you click on a secondlife:///app/teleport/Region/x/y/z link in chat.

O.o

Boy, I would like to see the explanation for that one.

OK, so that "magic number" is either an infinity or NaN, and thus breaks the distance compare, causing it to accept the value, but then gets replaced with the "normal" destination value, since it also breaks the distance compare because the position is set to infinity.

Cute trick.

I think you misread Strife's post. He was talking about avatars only, and his point is that if we can set a sit target and sit, then we should be able to reach the same result by sitting and then moving the avatar. I agree 100%, and I agree with you that this shouldn't be applied to non-avatar elements in the link set.

For example, if we set a sit-target just outside the link limits, but within sit-target limits, and want to adjust the avatar slightly (perhaps just rotating), we should be able to. But if link limits are enforced, it won't be possible.

http://wiki.secondlife.com/wiki/PosJump

Yep it is infinity. You can use values less then infinity but the object won't "jump" instantaneously.

There was an interesting discussion about it on the Scripters mailing list about a month ago. Kelly popped in and mentioned that he would be in favor of giving us llTeleportAgent instead of trying to keep this trick from breaking. It was mentioned by several people that we would also need a llTeleportObject function to completely replace this hack.

OK, I probably did, as I saw the postscript when I noted the point; still, I think that is an important reinforcement, plus the note about ending this hack foolishness once and for all, and just giving us the requested functionality (requested since, oh, forever).

Hopefully, Kelly means what he says and will deliver, but it's been a long time in coming, so I won't hold my breath on it. :-/

It's NOT a non-obvious special case. At least, not one that wasn't already present. Can an avatar be linked to an object? Yes, by sitting. Can an avatar be linked to an object WAY outside the bounds of where a normal prim could be given an avatar's shape and size? Yes, with llSitTarget() it can be up to 300m away (or thereabouts, since I think each AXIS is constrained rather than the overall distance). Can an avatar be moved around once linked to the object? Yes, with llSetLinkPrimitiveParams(). Can an avatar be moved around at the NORMAL link limit for an avatar in a link set? Well, no. WHERE'S the exception again?

BTW, I don't quite agree that a llTeleportAgent() would be sufficient replacement, since that would presumably not keep the avatar linked afterwards. There are plenty of applications OTHER than teleporting for which moving an avatar around in the linkset beyond 10m or so is useful. Games, choreographed avatar movement, non-teleport transportation systems, dynamically updated group seating, etc.

Oooops I said Kelly and it was actually Soft:

"This relies on a different bug than WarpPos did. The check for
WarpPos-like behavior was added in to keep WarpPos alive, which adds
some ugly special case code to the simulator. Maintaining this as well
would require more special case code after the underlying code is
fixed. I'd push for an llTeleportAvatar instead of pushing for a hack
that duplicates WarpPos."

But alas, the jira entry for llTeleportAgent has 311 votes and still remains unassigned:

http://jira.secondlife.com/browse/SVC-212

Habanero?

There ya go, Hewee..

Yep! Just wish I was as hot as a Bhut Jolokia thou

Have you ever had one of those?

I have something growing in a pot on my balcony that looks like a jalapeno and is hotter than a Habanero, I suspect it has something to do with my cats watering it never heard of a Bhut Jolokia though. My seeds are a mix from South America and Portugal, I may have inadvertently caused a hybrid.

We had some thai bird peppers show up in our garden one year. That was interesting.