User talk:Susicat Oh
From Second Life Wiki
Additions to your userpage
Was looking through your userpage and found these mistakes/oversights:
- PRIM_POSITION does work on child prims, but PRIM_POS_LOCAL should be used instead anyway. Neither should ever throw a stack heap collision.
- llKey2Name isn't deprecated and llGetUsername isn't an end-all replacement. llKey2Name should still be used in most cases, as the data it provides can be easily converted into the equivalent username if need be. llGetUsername, however, can't be converted back into a legacy name (at least, not a correctly-capitalized one).
- Your section on semicolons is misleading; the semicolon doesn't force the if statement to return TRUE, it just cuts the flow short and the bracketed code (if any) is executed normally without regard for the if/while/whatever. For the while loop, you are literally executing nothing over and over again (unless a is already >= b, in which case the loop will be skipped) since the semicolon ends what amounts to be a null statement.
- Always use llTransferLindenDollars, not llGiveMoney, since it provides a return value to indicate whether or not the transaction succeeded (unless for some reason you don't need the return value, in which case using llGiveMoney will chop off a few extra bytes).
- Lists do not have a length limit at compile (as far as I can tell). Tested with a 200-element list of integers but I've worked with very large lists initialized at compile and have never seen any errors.
- llMessageLinked creates an entry in the event queue, which as you pointed out is limited to 64 events. Unless you are taking your sweet time processing them and you're sending them out at lightspeed, llSleep is unnecessary and potentially more harmful since it will delay processing in the main script significantly (6.4 seconds for every 64 messages, which can become a problem if that script also acts as the UI).
- llParticleSystem was supposedly fixed for some constants but PSYS_SRC_TARGET_KEY still requires a perfectly-typecast key to work. It's a longstanding bug that likely will never be fixed.
- Using llRound on llFrand with a range of 4.0 is bad practice since the chance of getting 0 or 4 is half that of 1, 2, or 3.
- You mentioned that "if the Notecard can never be edited why not just use constants in the script". I use this semi-hack for secure, high-capacity data storage - each line stores a good chunk of encrypted data that is never changed, and the script calls specific lines to load certain data. Since notecards can be very long in terms of lines and scripts cannot hold all of that data simultaneously, this is great for storing large amounts of data that is only used in small chunks; for example, I developed an encryption method that uses an extremely long key split up into 128-byte chunks, which are used in such a manner that they only need to be loaded one or two at a time. It's considerably slow, but since all the data is stored on the SL servers (none of it is accessible by the end-user in ideal conditions) it is rather secure, and avoids the obvious security flaw of keeping the notecard in the object's inventory.
- llGetWallclock is particularly useful due to the fact that it does observe DST (besides the obvious reasoning of "that's how SLT/PST works") because it can be compared to llGetGMTclock to determine whether DST is in effect or not.
- Nelson Jenkins 00:21, 4 May 2013 (PDT)