Is it safe to call llSetLinkPrimitiveParamsFast on a non-existent link number?

Question

Consider calling llSetLinkPrimitiveParamsFast() with a link parameter that does not represent an existing link number, for example like this:

llSetLinkPrimitiveParamsFast(  -5, [PRIM_POSITION, <0.0, 0.0, 0.0>]);
llSetLinkPrimitiveParamsFast(1337, [PRIM_POSITION, <0.0, 0.0, 0.0>]);

In all my tests, this seems to silently fail without interrupting the script or throwing any errors. However, the documentation doesn't say anything about the expected behavior in that case and I could not find any other source elaborating on it.

• Is it safe to assume that this will silently fail and not break a script (in the future)?
• Is there any documentation on it I that I failed to find?

Answer 1

In first place, why would you want to call it with a non-existent link number? The function is going to silently fail if the link wasn't found, however take a look at LINK_THIS or similar LINK_ flags - they all have negative values, respectively -1 to -4. In future, if Lindens add another flag (can't see a reason why they would do so), which will likely be -5, it may break things. Same if they decide to rise the prim limit in a linkset which is 256. I would assume they are not going to change it anytime soon since with meshes it is very hard to reach such a number and they haven't really changed it in past.

Answer 2

Nonexistent link numbers that don't match the LINK_* flags will silently fail, as you saw. However, this may change someday down the line, and you don't want all of your scripts to suddenly dump a bunch of error messages to your users.

My solution is to use 0, then check whether it evaluates as false before running anything with it (any non-zero number evaluates to true). In a linkset, no prim is link 0 (root starts at 1). If llGetNumberOfPrims returns 1, you already know you have problems if you are looking for linked prims. But again, you do not want to add link 0's to any command regardless, since they then affect the root.

You could also use DEBUG_CHANNEL which evaluates as the max integer, which would almost certainly never be accessible as a link number if you really need to run through the linkset list without evaluating it. Avoid using negative numbers to identify null links.

Answer 3

For llSetLinkPrimitiveParams() or it's Fast counterpart, we simply need a value that is not currently a link number. But being future proof is nice so we try to choose one that will never be a link number. To be safe from future expansion of linkset limitations we can probably choose the highest 32 bit signed integer, 2147483647 (or 0x7FFFFFFF), and lucky us, there is even a constant for it in LSL:

llSetLinkPrimitiveParams( DEBUG-CHANNEL, [ ... ] );

But there is no double guessing Lindens. It was given that constant because the chat channel space was filling up fast and nobody had used it for existing content. It could eventually be employed for something else in link numbers too! So as an experiment in second dystopia I looked at using 0 because the root linknumber changes to 1 when linked at all. Yet that fails when the scripted prim could be unlinked. We need a variable that gives 0 when linked but 1 when unlinked;

llSetLinkPrimitiveParams( prim_count==1, [ ... ] );

If you have a function for counting your links anyway then using this will evaluate correctly both ways, if the count has not changed since. Unlinking will not always run the changed event before the prim flies off to the zero corner! So here is an alternative to DEBUG-CHANNEL that gets the current safe disposal value regardless of linkset, attachment, or seating:

llSetLinkPrimitiveParams( !( ( llGetObjectPrimCount( llGetKey() ) > 1 ) || ( llGetNumberOfPrims() > 1 ) ), [ ... ] );

Of course it's worth noting, if you only intend to use a dummy value there because all your parameters will declare links with PRIM-LINK-TARGET, then this is all without cause; That first link number will be discarded by the next link declaration anyway.