llSetLinkPrimitiveParams() on Avatar Distance Restricted in Havok 1?

I built a nifty teleporter system using llSetLinkPrimitiveParams() to move sitting avatars to destinations. It works great in a Havok 4 Beta sim (1.18.6.78103), and I can go all the way across the region with it. In the release server version (1.19.0.79136, Havok 1) it will only move the avatar a few meters, and depends on the size of the prim the script is in (generally about 7-12m). Any attempt to move the avatar farther doesn't move it at all (but may still rotate as desired).

I thought using this function on an avatar was supposed to have the same constraints as a sit target (300m). I don't see any JIRA issues dealing with this specifically. Have I missed something? Has anyone else run into this? Thank you.

EDIT: Fixed server versions.
EDIT: Based on investigation in-world and in JIRA for history and related issues, I don't think this has to do with Havok 1/4. I believe it is actually a difference between the 1.18 and 1.19 codebases.

It probably has link-distance constraints, since the function wasn't originally designed for use with avatars, that's just a coincidental usage. Assuming that's the case, you wouldn't get any more than 32m of TP distance.

Here is a test script. It works in Havok4 Beta Server 1.18.6.78103 sims. It does NOT work in the newly updated Second Life Server 1.19.0.79136 sims. I've tested 2 of the former and at least 4 of the latter.

Since llSetLinkPrimitiveParams() functionality on sitting avatars was specifically restored to allow for moving them after sitting (essentially allowing for dynamic sit targets), this should have the same restrictions as llSitTarget(), not the normal link-set distance restrictions (i.e. those imposed on llSetPos() in child prims). I'm filing this as a new defect in JIRA.

See https://jira.secondlife.com/browse/SVC-750?focusedCommentId=29031#action_29031

vector SIT_POS = <0.0, 0.0, 1.0>;
rotation SIT_ROT = ZERO_ROTATION;

vector TARGET_POS = <0.0, 0.0, 50.0>;


default
{
    state_entry()
    {
        llSitTarget(SIT_POS, SIT_ROT);
    }
    
    changed(integer changes)
    {
        if ((changes & CHANGED_LINK) && llAvatarOnSitTarget() != NULL_KEY)
        {
            llSetLinkPrimitiveParams(llGetNumberOfPrims(), [ PRIM_POSITION, TARGET_POS ]);
            llUnSit(llAvatarOnSitTarget());
        }
    }
}

The script starts working again for a default cone prim (0.5m in all dimensions) once TARGET_POS.z is decreased to approximately 5.95. If the size of the prim is increased in all dimensions to 2m, the script works until TARGET_POS.z is approximately 8.95. So it is definitely behaving more like a traditional prim link distance, not a sit target.

Please see:

https://jira.secondlife.com/browse/SVC-1433

Your votes are appreciated. Thank you.

It sounds like that Havok 4 servers have bug (not Havok 1). llSetLinkPrimitiveParams shouldn't allow movement beyond link limit.

Isn't "llSetPrimitiveParams" used normally for teleporter scripts?
http://lslwiki.net/lslwiki/wakka.php?wakka=LibraryTeleporter

I agree, and I've left a comment on the JIRA as such.

As I stated in the JIRA issue, I don't think this actually has to do with Havok 4, and I shouldn't have named the thread that way (but did so before I looked into the issue more fully). I think it has to do with the fact that the Havok 4 Beta servers are still running in the 1.18 codebase, and this functionality was changed (broken IMO) in 1.19.

No, this script shouldn't work, thats the whole reason WarpPos was invented, to get around the fact that it *won't* work. So place me in the 'H4 server bug' camp.

It should for AVATARS, for the same REASON "WarpPos" works: there's no other way to do what it does in LSL, and since what was technically a bug wound up allowing it to be done, the bug was kept as an enhancement to functionality.

The functionality this deals with is changing where the avatar is positioned (i.e. essentially changing the sit target) after the avatar sits down. This is in fact the reason that using llSetLinkPrimitiveParams() on avatars was added BACK IN by Soft Linden, even though this use was not intended in the first place. So limiting it further than the restrictions on llSitTarget() is DEFINITELY A BUG. Unless maybe you also want to call the 300m limitation on llSitTarget() a bug? Should we limit that back to ~30m at this point?

As for the follow-up script I posted in the JIRA issue for moving a child prim, it SHOULDN'T work, and in fact it DOESN'T. The point is that if it were a bug in Havok 4 that allowed avatars to be moved to sit target magnitude distances, it would more than likely do the same for prims, and it doesn't. That indicates there was special logic for avatars, allowing them to be moved as freely as you can move the static sit target. And now that has been broken in 1.19.

I'd like to see where, in the JIRA or from a Linden, it was indicated that the function was supposed to move 'as freely as you can move the static sit target.' It never was. It was only restored from not working to working within link limits.

As you will. You're free to not vote, of course. Personally I think it is pointless to consciously provide functionality that allows dynamic changing of sit targets when...well, it can't change sit targets as they exist today.

I guess you don't understand what everyone is saying. It's not broken in 1.19 because it never worked in the first place. If it's working in H4, thats a *new* behavior. I'll leave the argument as to wether it's a bug or a feature to the people who thrive off that. If it provides something new and useful, great, lets keep it. The issue is your terminology. something can't be broke if it never used to work. You should be saying "wow, check out this new functionality in H4!"

sit target != link distance

one shouldn't assume that one will work with the same limits as the other

treat an av as a prim and you will get the same limits, seems like it works correctly to me.

Er, not quite. warpPos pre-dates llSetLinkPrimitiveParams. It was intended to get around the 10m-per-call limit on llSetPos for unlinked prims or entire linksets, not the variable-depending-on-prim-size link distance issue here.


Er, no, it deals with changing where a *prim* is positioned within the linkset... the prim in question just happens to be an avatar. It has absolutely nothing to do with the SitTarget.

Question: On the servers which allow apparently unlimited avatar repositioning via llSetLinkPrimitiveParams, is prim repositioning also unlimited, or subject to link distance? In other words, are avatars treated differently than prims, and if not, then perhaps the link distance limitations just haven't been implemented yet. I'd be surprised if avatars were treated differently, given statements by Lindens that the function wasn't consciously intended for avatars.

I think you may be missing that I am speaking SPECIFICALLY of the use of llSetLinkPrimitiveParams() ON AN AVATAR. Note that this use of the function was disabled completely, and then re-enabled in 1.18--where it allows for long distances--because it is the only thing that allows you to dynamically change sit target and because it was already in use quite a bit for this very application (you can get the whole history of this from the SVC-750 JIRA issue I linked to above).


On servers where long-distance avatar positioning works, the prim repositioning is still limited as usual for link sets. Where you can position an avatar 100m off easily, a comparably sized prim will fail if it is over 7m or so away.

Hence what I said: "the prim in question just happens to be an avatar."


llSetLinkPrimitiveParams doesn't do anything to the sit target, it just moves and/or rotates the avi-prim.


I am aware that it was being used to move and/or rotate one or more avatars via script (I was working on just sych a system myself), but I was unaware that it allowed positioning the av at greater than link-distance distances, or that it was being used by anyone else for this purpose. Are there statements to that effect that I'm not seeing in my admittedly cursory skim of SVC-750?

has this got any thing to do with it - From the notes on the 1.19 release candidate viewer

Yes, it was disabled, but both before and after it was never meant to go outside of link limits. Also, as said, it doesn't actually change the sit target.

It is in fact very useful for teleporters, which with this functionality can be a very simple sit, dialog choice, move (without temp rezzed prims or the need to make a choice before sitting). It is also very useful for scripted movement of avatars like in sports, dancing, games, and other things. Unfortunately I wasn't aware of SVC-750 until recently, and wasn't aware the distance limits had been messed with because I do most of my development in a private sandbox (that I wasn't even aware was participating in the Havok 4 beta until last week), so I didn't comment on it myself.

Ah. Interesting. I actually see SVC-750 listed in yesterday's release announcement Maybe it is that what I have noticed is, in fact, the functionality people were complaining about in SVC-750, and they didn't realize you CAN move the avatar when it is really close to the prim. Hmm. I don't understand why that has to do with a viewer release though; the functionality is all in the server.

http://blog.secondlife.com/2008/02/04/new-release-candidate-viewer-1190-rc0-available/

But, apparently, an av is NOT treated the same way, when sitting.

I see the OP's point. If you can set a sit-target further than the link distance, and sit on it, and you're linked but farther than the link distance would allow, then the link set violates the link limits. If this violation is allowed for avatars when they sit, it would be consistent to also allow it for avatars using llSetLinkPrimitiveParameters().

I don't know whether I'd call it a bug, but in my judgement, llSetLinkPrimitiveParams() should allow us to set things any way we could get them manually, and evidently it does not.

That note is bogus. SVC-750 was resolved back in Nov of 2007. It was a server fix, not a viewer fix, and for whatever reason, every time they announce a new RC client, they mention it. People keep telling them to remove the reference, and surprise, they don't listen.

What I missed was the letters 'link' in there I thought he was trying to move using llSetPrimitiveParams which does not work,and is why WarpPos was invented. Right answer, wrong argument.

to be honest, if anything is buggy here, it's sit targets

but the odds of that being "fixed" are somewhere on the order of "not bloody likely", since
A) it doesn't cause any errors that we know of, and
B) It'd break 70%+ of the teleporters in existence (we won't count ones that obey link distances)

I don't think asking LL to duplicate buggy behavior is going to work, but be my guest.

it'd require them to add yet more special handling for avatars to ignore link limits that are in place for the set prim params call, which isn't going to be high on anyones list of things to do, nevermind that the functionality is already nominally in place by dynamically setting the sit target (granted it only works for the next av to sit).

but who knows, you could get lucky, and someone at LL could be bored enough to do it... and hopefully not break the existing function call or expose another security flaw.

What would break existing teleporters?