Inventory changes

Just come across something strange. When dragging a script into a prim with a script that's looking for inventory changes, the changed event is not called. However it is called if you manually remove a script from the prim. It is triggered if you drop an object or something else into it.

Has anybody else noticed this? Or know of anyway around it?

Interesting. Just tested, and no changed event whatsoever (let alone CHANGED_INVENTORY) seems to be called when a script is added in this manner.

That said, workarounds are timer events to check the number of scripts in the prim, link messages, listeners, etc, etc, etc. Just depends on how you want to do it.

Interesting, though.

Well I want to ensure that nobody drops a script into the object that shouldn't be there, and this surely must be the most efficient way of doing that. I suppose what would be good to know is if this is something recently broken and used to work? It has to be a bug as it's inconsistent with the changed event being called if a script is removed from the object, which it is.

You are correct, this behavior is a bug. changed( ) has been bugged for awhile now, certain texture, color, or scale changes wont trigger their CHANGED_* constant counterpart. LSL functions that change the object also don't trigger the changed event.

LL needs to add some consistancy to changed():
ALL scaling operations (even those done with llSetScale()) should trigger a CHANGED_SCALE
ALL texture operations (even those done with llSetTexture) should trigger a CHANGED_TEXTURE
ALL inventory operations (even those done with llRemoveInventory) should trigger a CHANGED_INVENTORY

etc.
I think the changed event has been b0rk3d since I got here, during the beta (v0.5)
==Chris

I bug-reported this back in October or November.

Thanks Christopher and Apotheus. So it appears that this is a known issue and has been for a long time now. OK, I'll work around it. If it hasn't been fixed yet it's pointless waiting to see if it will be.

I am looking into this. Also, I would like to get some feedback about how the changed event is used.

Currently, calling something like llSetColor repeatedly (applying the same color) triggers the changed event every time. To me, it would make sense if the changed event *only* triggered if there was an actual color change. I would like to 'fix' this behavior.

So... is anyone currently relying on the changed event to trigger everytime a llSet* call is made, even if there is no actual change?

The only problem that immediately comes to mind about changing that behavior, Don, is for those scripts calling the changed event as a link in their script. For example:

state_entry()
{
llSetPrimitiveParams([PRIM_SIZE,<1,1,1>]);
}

changed(integer change)
{
llSay(0,"Current Scale is: " + (string)llGetPrimitiveParams([PRIM_SIZE]));
}

touch_start(integer total_number)
{
llSetPrimitiveParams([PRIM_SIZE,<1,1,1>]);
}

Worst-case, this would force people to just make function, timer, or state calls instead, and I see it as relatively moot in light of getting the change function to be actually called in the first place. Besides. It wouldn't be half as sudden as the collision changes a few patches ago.

While you're at it, I believe changing the name of inventory to the same name triggers a CHANGED_INVENTORY event. Not positive since it's been a week since I've tested, but also worth pursuing.

Please don't remove the "changed but not changed and I'm going to fire anyway" thing.

Why remove options from LSL? Maybe someone in the future would like to use that particular functionality. Maybe someone does so now. Hell, maybe someone coded "badly" and uses it now and doesn't even realize it.

Whatever the case, removing things that could potentially be used in the future (and I can think of one or two uses for changed events firing when nothing is actually changed) is not a good idea. (Please, instead give us things like llLandAutoReturns(), llLandIsNoScript, llLandSize(), llLandAvailablePrims, llLandTotalPrims, llLandUsedPrims, llDetectedCollisionPoint, and other such things.)

would be nice if there was a changed event filter, as most of the time we are only looking for the change of just one attribute.

llSetChangedEventFilter(integer flags)
would default to -1

I believe changed( ) should only fire when the objects properties actually undergo a change. Does applying the same colour to an object change the object at all? - No.
==Chris

No, it doesn't change anything on the object, as we perceive it. But a call was made that changes the properties of the object... simply the change was to the exact same parameters as it already had. I suppose it depends on what you call 'change': perceivable change, or property-level change.

Ie. if I have a white prim, and call llSetColor(<0, 0, 0>, ALL_SIDES);, it'll change the color parameter of all sides to be black. But this is no different whatsoever as calling llSetColor(<1, 1, 1>, ALL_SIDES);... it changes the color parameter of all sides to be white. It doesn't matter if the sides were already white... it's still resetting the color parameters. So in that sense, yes, a change has occurred.