llSetLinkPrimitiveParams() on Avatar Distance Restricted in Havok 1?

Forcing sit targets to obey link distance constraints.

This isn't right; sit targets would still be able to go to ~520m total distance and they have nothing to do with the function in question. What should obey link constraints is llSetLinkPrimitiveParams when used on avatars or on any prim. This function doesn't change the sit target anyway.

Teleporters use llSitTarget or llSetPrimitiveParams (for WarpPos). No existing teleporter uses llSetLINKPrimitiveParams.

Anyway, it's patently ridiculous to look at functionality that suddenly came into existence by accident in a newer, unreleased version, then claim the old functionality on the current version is a bug. That makes no sense whatsoever, and that's what this whole thread is about.

Not true. You're so sure you've been exposed to every teleporter written by every scripter in SL? Wow. I'd be happy to demonstrate mine. It works very well, and is incredibly user friendly. You simply sit on a single-prim teleporter and select your desired desination once the menu pops up. You are sent there instantaneously, without trying to move the teleporter, or rezzing anything, or requiring you to select a location with an extra touch, or anything of the sort.



Not true again. The functionality is present in an OLDER VERSION. This is 1.18 functionality, not Havok 4 functionality. It is broken in 1.19 servers. The reason it works in Havok 4 beta sims is that THEY ARE STILL BASED ON THE 1.18 CODE BASE; they have not been updated yet to 1.19.

OK sorry, I thought you were arguing against the OP's point, saying that his proposal would break existing teleporters.

I wasn't arguing that llSetLinkPrimitiveParams changes the sit target (I stated exactly the opposite earlier in the thread), I was merely clarifying Void's statement that sit targets are the odd behavior in the system, since they allow an avatar as the exception to link distance, though it is unlikely to be corrected given the prevalence of sit-hack teleporters dependent on this behavior.

If there are limitations on the distance between linked prims due to the physics engine, does having a "sitting" avatar up to 520m away from any given prim in the linkset affect that at all? When sitting, is an avatar's mass added to the linkset, or somehow affect other physics calculations? I have virtually zero experience with the physics engine, so I really don't know.


If a sit target can place an avatar up to 520m from the prim, why should llSetLinkPrimitiveParams applied to an avatar be held to tighter restrictions? I think it'd actually be a nice feature, and would allow actual secure sit-hack-type teleporters, rather than the present systems which, at most, can restrict who can activates them, but not who uses them.

Hmm. Okay. Maybe this IS a Havok issue at this point. The long distances are still working in Havok 4 Beta sims, even though thay have been updated to the 1.19.0 code base now. I know they worked before the llSetLinkPrimitiveParams() functionality was disabled on avatars at some point though.

but you can restrict who uses them if you use warppos.

I think there is even more confusion because sittarget doesnot actually move an avatar, but rather the sim places the av AT the sit target, which is why changing the sit target doesn't actually move the av sittin on it. sit target merely tells the sim the first place that should be used to place an av, and how to positio them there (otherwise the sim enters a default mode which calculates bonding boxes and edges based on the place clicked)

interesting side note, the sim knows where you click on an object, but it's not exposed in lsl.

True, but that requires moving the TP object. I'm thinking of dirt-simple one-prim no-rezzing stationary TP's.


Of course, since it is exposed to the other users in certain debug modes. Actually, I think it's calculated on the client, then transmitted to the Sim. Hence, when entering a new area, you can't touch or get tooltips on objects which have yet to rez in your viewer, (since the client doesn't know where they are yet) though your av will collide with them (since the sim does).

Ah, But remember! How many times have you TPed to a sim and gone flying around while everything was still rezzing and you find you have flown into a building. So it isn't a matter of your client doesn't know where objects are yet. The simulator hasn't recieved updates as to the position of your av yet and hence no collisions.