Hi Mike - sorry about the delay. You can't use a prim name in llSetPrimitiveParamsFast() etc, so the best practice is to store the link number in a variable and use that. No need to use lists, just an integer for each key prim. I usually have a function that cycles through the prims in the linkset, ...

There's no need to redesign the whole object just because of this bug! As Ilan says, you just need to use the name of the prim instead of the link number. Name each prim with the number it represents, and use something like this (at its simplest, and untested since I'm not logged in): string name = ...

Thanks Ilan. Much appreciated - it would be so much better if we could use osMessageObject like this. It's an insanely useful and efficient function.

It does seem to be client-side, at least according to this thread in the Firestorm JIRA . And it's not just Firestorm, but all viewers, and it's at least 7 years old. In fact, it's likely that the number shown never was reliable. They mention that if a linkset is re-rezzed the link numbers are OK. T...

Thanks, Ilan. It looks like each object is going to have to have a listener open, then.

I'm surprised to discover that osMessageObject(), which has a threat level of "low" according to the OpenSim docs, apparently cannot be executed by a visitor to a world. The error I'm getting is: [05:28] System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invoc...

Of course - in a normal script it would be madness not to. But sometimes when developing or debugging it's useful to be able to know quickly the link number of a given prim, and it would save time here and there if we could just rely on the edit floater's reported number instead of having to drop in...

Ilan, there definitely is a problem with this. I too have to drop a script into objects which tells me which link number is which, because the number shown in the viewer edit window is frequently wrong. I never rely on it in OpenSim, and haven't for years (it's a long-standing bug).

Mike Lorrey wrote:I'm also curious as to who set the 4 meter maximum size for particles, and if its possible to change this in the OS ini file.

Particles are entirely a client-side (ie viewer) effect, so it's beyond the scope of the OpenSim server to be able to change this.

In that case, I suggest whittling the code down to just the function(s) that misbehave, and sharing that with us. I'm sure we can figure out what's happening from that.