Difference between revisions of "NULL KEY"
(Undo revision 1180241, reads strange either way) |
m (<lsl> tag to <source>) |
||
| Line 7: | Line 7: | ||
Despite fitting the syntax criteria to be a valid [[key]], when fed to a {{LSLGC|Conditional}} as a key it executes as [[FALSE]]. | Despite fitting the syntax criteria to be a valid [[key]], when fed to a {{LSLGC|Conditional}} as a key it executes as [[FALSE]]. | ||
|examples= | |examples= | ||
< | <source lang="lsl2">integer isKey(key in) { | ||
if(in) return 2; | if(in) return 2; | ||
return (in == NULL_KEY); | return (in == NULL_KEY); | ||
}//returns 2 if it's a valid key, 1 if it's NULL_KEY</ | }//returns 2 if it's a valid key, 1 if it's NULL_KEY</source> | ||
< | <source lang="lsl2">// NULL_KEY itself is evaluated as FALSE only when it is casted as a key. | ||
default { | default { | ||
state_entry() { | state_entry() { | ||
| Line 20: | Line 20: | ||
else { llOwnerSay("Casted NULL_KEY is FALSE"); }// Correct. | else { llOwnerSay("Casted NULL_KEY is FALSE"); }// Correct. | ||
} | } | ||
}</ | }</source> | ||
|notes=In most situations NULL_KEY isn't needed; an empty string ("") will suffice. To take advantage of this certain practices have to be avoided. In many applications keys are checked against NULL_KEY to determine if they are valid; this is bad practice. | |notes=In most situations NULL_KEY isn't needed; an empty string ("") will suffice. To take advantage of this certain practices have to be avoided. In many applications keys are checked against NULL_KEY to determine if they are valid; this is bad practice. | ||
Latest revision as of 16:05, 23 January 2015
| LSL Portal | Functions | Events | Types | Operators | Constants | Flow Control | Script Library | Categorized Library | Tutorials |
Description
Constant: string NULL_KEY = "00000000-0000-0000-0000-000000000000";The string constant NULL_KEY has the value "00000000-0000-0000-0000-000000000000"
NULL_KEY is a string. However it is only really useful as a key.
Despite fitting the syntax criteria to be a valid key, when fed to a Conditional as a key it executes as FALSE.
Caveats
Related Articles
Functions
| • | llAvatarOnSitTarget | |||
| • | llDetectedKey | |||
| • | llGetNotecardLine | |||
| • | llGetLandOwnerAt | |||
| • | llGetPermissionsKey | |||
| • | llGetTexture | |||
| • | llListen |
Events
| • | attach |
Examples
integer isKey(key in) {
if(in) return 2;
return (in == NULL_KEY);
}//returns 2 if it's a valid key, 1 if it's NULL_KEY
// NULL_KEY itself is evaluated as FALSE only when it is casted as a key.
default {
state_entry() {
if (NULL_KEY) { llOwnerSay("NULL_KEY is TRUE"); }// Correct.
else { llOwnerSay("NULL_KEY is FALSE"); }// Never.
if ((key) NULL_KEY) { llOwnerSay("Casted NULL_KEY is TRUE"); }// Never.
else { llOwnerSay("Casted NULL_KEY is FALSE"); }// Correct.
}
}
Notes
Like any LSO string constants longer then 3 characters and used in multiple places in the code, they should be stored in a global variable. The result will be a considerable memory savings. This does not apply to scripts compiled with Mono. See LSL Constants vs Globals for more information about this and examples.
In most situations NULL_KEY isn't needed; an empty string ("") will suffice. To take advantage of this certain practices have to be avoided. In many applications keys are checked against NULL_KEY to determine if they are valid; this is bad practice.
LSL makes it easy to check if a key is valid. Simply use the key as the parameter for a conditional.
That is, instead of if(uuid != NULL_KEY), use if(uuid). if(uuid) will only return TRUE if it is a valid key that is also not a null key.
Deep Notes
All Issues
~ Search JIRA for related Issues
|
|
SVC-5772 | A | NULL_KEY is no longer a NULL_KEY when passed to a function |
Signature |
|---|
string NULL_KEY = "00000000-0000-0000-0000-000000000000"; |
Haiku |
|---|
|
My hopes for nothing
|