Talk:Changed

CHANGED_REGION and CHANGED_TELEPORT not in default state

This caveat went on the change page.

If there is no changed event in the default state, the changed event will not be triggered in other states for CHANGED_REGION or CHANGED_TELEPORT. An empty changed state in default corrects this.

I cannot reproduce it with this script. It works OK with the teleport and a walk over a region line for me, both on LSO and on Mono. <lsl> default {

   state_entry()
   {
       llOwnerSay("default state_entry");
       state other;
   }

}

state other {

   state_entry()
   {
       llOwnerSay("other state_entry");
   }

   changed(integer change)
   {
       if (change & CHANGED_TELEPORT)
       {
           llOwnerSay("got CHANGED_TELEPORT");
       }
       if (change & CHANGED_REGION)
       {
           llOwnerSay("got CHANGED_REGION");
       }
   }

   touch_start(integer num)
   {
       llOwnerSay("reset on touch");
       llResetScript();
   }

} </lsl> Is there a script that can show the trouble? Maybe it is better to put that on the JIRA than on here if it can happen. --Cerise Sorbet 05:55, 21 February 2010 (UTC).

Tested: Made fresh script and using the above had the following returned in chat when teleporting and walking between regions -

Object: default state_entry

Object: other state_entry

Object: got CHANGED_TELEPORT

Object: got CHANGED_REGION

Connecting to in-world Voice Chat...

Connected

Object: got CHANGED_REGION

Connecting to in-world Voice Chat...

Connected

-- Fred Gandt ^{(talk|scripts|contribs)} 06:21, 21 February 2010 (UTC)

I had planned to promote it to JIRA and convert it to a bug entry but since there is no repro... no need. -- Strife ^{(talk|contribs)} 18:59, 21 February 2010 (UTC)

New caveat seems less helpful than confusing

This new caveat - Always test the value of change, even if your script doesn't seem to need it now. New CHANGED_* triggers are added once in a while, and a script can do surprising things when unexpected events suddenly come in. doesn't make sense to me. CHANGED_* indicates a flag of a partially unspecified nature, not a trigger and I am confused by when unexpected events...come in. What is an unexpected event and how does it come in? I also don't consider the advice (I believe it to be advice after interpretation) to be a caveat. -- Fred Gandt ^{(talk|contribs)} 21:43, 22 July 2011 (PDT)

Really now.

An unexpected event is an event that was not expected. un·ex·pect·ed - : not expected : unforeseen That is something that happens when scripts are written with bad assumptions built in, like an assumption that what triggers an event or an event flag will never change or get expanded.

A new CHANGED_* trigger is a new thing that can make a CHANGED_* flag flip. trig·ger - something that acts like a mechanical trigger in initiating a process or reaction. It could be a new flag, or it could be a new condition that triggers an existing flag.

A caveat is cautionary advice.

ca·ve·at -

a : a warning enjoining one from certain acts or practices

b : an explanation to prevent misinterpretation

c : a modifying or cautionary detail to be considered when evaluating, interpreting, or doing something

--Incoherendt Randt 22:28, 22 July 2011 (PDT)

Full of yourself for a noob aren't ya? -- Fred Gandt ^{(talk|contribs)} 01:42, 23 July 2011 (PDT)

I don't understand what the caveat means. Obviously you check to see what's changed before you do stuff -- if (change & CHANGED_*) rather than just if (change) -- but that's common sense rather than a precaution against LL adding a new flag, because obviously I don't want the event to fire when just anything changes (the colour, for example).

But I don't see how I'm supposed to test for the value of something that doesn't yet exist.

If I want to check for CHANGED_OWNER, what does the caveat mean I should be doing other than checking for if(change & CHANGED_OWNER)? And if I have a script that doesn't seem to need test for any changed event at the moment -- I'm setting some hovertext, for example -- what sort of changed event does the caveat mean I should include? Innula Zenovka 08:01, 23 July 2011 (PDT)

Mhmm. May have taken some pissing about but it definitely reads better now. Teamwork! Whoot! The wisdom of crowds is a wonder to behold. -- Fred Gandt ^{(talk|contribs)} 16:43, 23 July 2011 (PDT)

It does read better. -- Strife ^{(talk|contribs)} 14:15, 25 July 2011 (PDT)

CHANGED_INVENTORY description not entirely accurate.

The description of the CHANGED_INVENTORY flag states "Prim inventory has changed (owner adding inventory only)". I believe this should be updated to state "Prim inventory has changed (owner adding/removing inventory only)" because a changed event is triggered when the owner removes inventory as well. Arron Rainfall 06:47, 20 January 2013 (PST)

Technically speaking if you have access to modify an object, it will trigger CHANGED_INVENTORY as long as said mod rights haven't been granted by llAllowInventoryDrop. -- Strife ^{(talk|contribs)} 19:15, 22 January 2013 (PST)

More CHANGED_INVENTORY issues

CHANGED_INVENTORY is said to have a scope of PRIM, and not to be triggered if caused by a script action. However I'm seeing CHANGED_INVENTORY being triggered in a root prim script when I manually add a notecard to a child prim. It is also being triggered if the root script gives a copy of an inventory item to the child prim. This was on Second Life Server 13.02.04.269945. Omei Qunhua 08:41, 17 February 2013 (PST)

Oh, I see that lslWiki says "when inventory is changed in another prim in the linked object." ... but in that case the scope should say "object", not "prim" ? Omei Qunhua 09:14, 17 February 2013 (PST)

It seems that including a dummy changed event in a script in the child, prevents the changed event in the root prim script from firing, when the root gives inventory to the child. Thanks to Pedro for the suggestion Omei Qunhua 15:07, 17 February 2013 (PST)