User:Susicat Oh
Background:
Name Susicat Oh
Born June 07
Time in SL 5 years in 2012
Aim of this page is to provide simple plain English explanations of LSL commands and functions with examples where I can.
Trip ups, idocyncracies and folbles.
An undefined key may not be held as 00000000.. undefined keys as varialbes are held as empty NOT 000000... as such if you need to test for NULL_KEY be sure to set the variable to NULL_KEY as required.
llSetPrimitiveParams([PRIM_POSITION,dest]);
This needs to be in the root prim or will fail. In a child prim not only does it fail it can throw "stack heap collision"
sensor returns the 16 closest detedcted "items" in order of closest to farthest they are
numbered "sensor( integer num)" as 1 to 16. this function will NEVER return a zero!! of you
need to test for zero use no_sensor as a zero scan will not trigger a sensor event..
Also note llSensorRemove() not only shuts down the active sensor set up with llSensorRepeat BUT will ALSO kill the sensor found data.
as such
sensor(integer num_detected) { llSensorRemove();
is futile as the senor data will get wiped.
sensor(integer num_detected) { code funtions what ever your trying to do etc. .... ... followed by llSensorRemove(); }
will work fine.
Also note if your using a single sweep one-off type scan look at llSensor. Using llSensorReapeat() then shutting it off immediately is a waste of byte code.
llList2Vector and llList2Rotation do work as documented (or have been fixed) the poblem with them stems from the fact that
sometimes numerical data passed between scripts is usually passed as strings the recieving script accepts the string,
you then add it to a list. The data then sits in the list as a STRING!! not a numeric value. if you llDumpList2string
you will see something with looks like a numerical value, feels like a numerical value BUT its a string!! You need to be
on your toes all the time when transfering data types and remember to typcast correctly.
llSetpos does not work in attached prims Linden are aware of this and are fixing it
llKey2Name avatar MUST be on line AND in the sim or a child avatar of the sim, or a NULL_KEY is returned.
use llRequestAgentData and dataserver to get round this.
- child avatar is diffined as avatar on a neigboring sim which can be seen from the sim the script is in (less than 35M from sim boundary).
llkey2name is now only legacy.. as of Dec 2010. Use llGetUsername( key id ) instead..
Also be aware of llGetDisplayName( key id ); you are reminded that displaynames are not unique and easily changed, using them in ANY security script is a really bad plan!! Use llGetusername(id) or do it with avatar keys!!
I would suggest using llRequestDisplayName(id) it will raise a dataserver event but gets round the issue of avatar not in sim.
Newer people in SL will have the second name "Resident"
This one does actually work as documented BUT you need to be clear what it returns.
key llGetCreator(); returns the creator of the prim! NOT the script! key llGetInventoryCreator(string <inventory name>); returns the creator of inventory item ie script author or texture creator etc..
change & CHANGED_INVENTORY does not trigger for llAllowinventorydrop or llRemoveinventory documented else where on wiki
changed_Inventory will work when the prim owner edits the prim manually (adding a texture editing a notecard)
Use CHANGED_ALLOWED_DROP instead which will trigger when inventory is added via llallowinventorydrop
the llRemoveinventory issue has been acknowledged by Linden who are "working on it"
On the subject of llAllowInventoryDrop it allows any one to add anything to the prim. Its up to you to figure out the validity of who dropped what.
DATA_ONLINE returns binary integer TRUE/FALSE BUT!! the dataserver event can only accept strings
as such dataserver(key queryid, string data) data will be a "1" (online) or "0"(offline) as a string. attepting to use dataserver(key queryid, integer data) will force a syntax error when you try to complie.
Adding a semi colon to if statements as if( a ==B); will cause the test to return TRUE everytime handy for debugging but may have you scratching your head for hours.
on the subject of ; in the wrong place...
while (a < b);
with a semi-colon will stall the script. It will compile it will not error the script will just sulk!
llGiveMoney(key,amount); key MUST be an avatar and amount MUST be an integer greater than zero passing a float or a zero will error.
side note for give money profit split
integer to float and division
integer a = whatever; integer b = whatever; float c = a/b;
May yield c = zero due to internal integer rounding in LSL which will cause llGivemoney to throw invalid amount error.
use float a = money_amount; float b = percent_split; integer given = llRound((money_amount/100) * percent_split); llGiveMoney(id,given);
I have tripped up on this more than once!
List length limit at compile is 72 elements BUT once compiled list can be added list huge = list1 + list2; will work fine
The only real limit is script memory.
llDialog
The problem is that the client font is proportionally spaced not fixed with font soo this is best guess guide.
Question text is circa 35 characters per line Its ok to use \n and \t for new line and tab At more than 8 lines you get a scroll bar. Whatever you do question text MUST be greater than none and LESS than 512 characters.
Buttons Labels MUST be strings Cannot be empty or NULL sting (spaces are permitted) cannot exceed 24 characters Long button labels will be truncated in the display to circa 12 characters (remember its proportional spacing) in practice aim for max 10 chrs. Similar button labels which get truncated will look the same in the display aviod "sitting here pose 1","sitting here pose 2" as truncation whill show them as the same, the script knows they are different and will work correctly but the human user will not see a difference.
llMessageLinked
This will appear to stall or not work if messages are sent to quickly you need to allow the processing time of the recieving script.
slow things down with llSleep(x) in practice 0.1 is normaly enough.
llParticleSystem the list option PSYS_SRC_TARGET_KEY,NULL_KEY will compile but crashes the script.. Use PSYS_SRC_TARGET_KEY,(key)"" as a work round.
money event is not capable of telling if a "correct amount" was paid it will return amount and the payers key but thats it.. its up to you to test amount
if(amount paid == price) { deliver item }
The money event can be in any prim and will work as "pay this prim" just fine BUT llSetPayPrice(integer,[list]); for the pay dialog box MUST be in the root prim. If llSetPayPrice is in a child prim it will fail silently. Its ok to have it in the root as all money events in the object will be updated automatically.
it is NOT possible to pay a worn attachment.
Events
There is a 64 event limit on any given state. Events are processed on a strict first in first out order (FIFO) The only thing that can jump the que is state_entry
The event que is 64 events after that events are discarded untill there is free space in the que. Thats why if you are sending batches of LinkMessage( some of them get lost or never arrive.
Side note: The word "event" is an LSL keyword and will syntax error if used.
keys as 36 character UUIDs can be type cast to string and back fluidly just be aware of type casting when performing key functions.
HOWEVER having been given a key there is no way of testing if its an avatar, texture, group, sound, animation or whatever. Your expected to know!!
list tmp = llGetObjectDetails(id,[OBJECT_OWNER]);
if(llList2key(tmp,0) == id) { key is an avatar; } if(llList2key(tmp,0) == NULL_KEY) { key is NOT an avatar; }
thats the best I have for now
Integer rounding.
integer a = llRound(llFrand(4)); returns values in the range 0 - 4 inc.
integer a = llFloor(llFrand(4)); 0 - 3 inc
integer a = llCeil(llFrand(4)); 1 - 4 inc
On Rez reset fails when taken from inventory for the first time.
Never got to the bottom of this as reseting scripts manually in world or shift drag copying clears the fault.
Current thinking is that you use CHANGED_INVENTORY reset and may be a permission request like permission money.
What may be happening is you are setting up next owner permissions which triggers your CHANGED_INVENORY reset then in your haste you take back to inventory without granting the money permission. As a result the object sits in inventory without money permission being granted and just hangs in limbo. It has asked for money permisson once and cannot ask again without a reset, the section of code that does the resetting cannot be executed as permission has not been granted thus preventing the script advancing through to the code to get to the reset routines.
Solutions
1/ Add an on-rez reset to the same state (usually default) as the money request. 2/ Always remember to set it up correcly before taking to inventory. 3/ Test rez the item to be sure it does initalise correctly. 4/ Slap your self for being stupid. 5/ All of the above.