Difference between revisions of "LSL Hacks"
Talarus Luan (talk | contribs) |
|||
| Line 71: | Line 71: | ||
'''Cons''' | '''Cons''' | ||
*Will fail on hardware that doesn't support two's compliment (unlikely LL will ever use such a platform). | *Will fail on hardware that doesn't support two's compliment (unlikely LL will ever use such a platform). | ||
*Harder to understand. | |||
*? <!--Might be slower? Not been speed tested at time of writing this.--> | *? <!--Might be slower? Not been speed tested at time of writing this.--> | ||
Revision as of 14:32, 7 August 2009
| LSL Portal | Functions | Events | Types | Operators | Constants | Flow Control | Script Library | Categorized Library | Tutorials |
Hacks
A page dedicated LSL Hacks, those things that make your code so much better but at the same time so much worse.
llMessageLinked key parameter as string
| VM: LSO | Discover: Unknown |
Instead of passing a valid key as the forth parameter of the llMessageLinked function, an string value can be used. When the link_message event is triggered, the key can be typecast to a string (implicitely or explicitly) without any value degradation.
<lsl>llMessageLinked(LINK_THIS, 10, "Hello", "World!")</lsl>
Pros
- Allows for a second string to be sent to the receiving scripts
- Faster then splitting a single string into two.
Cons
- May no longer be a valid key value.
llGetListLength(myList) and (myList != [])
| VM: LSO | Discover: Strife Onizuka |
- Instead of using
llGetListLength(myList)you can use(myList != []). - Instead of using
-llGetListLength(myList)you can use([] != myList).
Pros
- Faster
- Uses less bytecode
Cons
++c and c++
| VM: LSO | Discover: Not Applicable |
In LSO LSL (as opposed to Mono LSL) ++c is faster then c++ because of how the bytecode is generated[2]. There are very few applications where ++c can't be used instead.
Pros
- Faster code.
- Saves 6 bytes and 2 instructions.
Cons
- None
(c = -~c) same as ++c
| VM: LSO | Discover: Strife Onizuka |
For the same instruction cost of (++c), (c = -~c) can be substituted giving a 4 byte saves.
Pros
- Saves 4 bytes of bytecode.
Cons
- Will fail on hardware that doesn't support two's compliment (unlikely LL will ever use such a platform).
- Harder to understand.
- ?
Testing key validity
| VM: LSO & Mono | Discover: Strife Onizuka |
By passing the key value to a conditional, if it is valid and not a NULL_KEY then it will execute the true branch.
<lsl>integer isKey(key in) {
if(in) return 2; return (in == NULL_KEY);
}</lsl>
Pros
- Fast
- Easy
- Painless
Cons
- None
if(~c) and if(c != -1)
| VM: LSO | Discover: Unknown |
Instead of using if(c != -1) you can use if(~c). This applies to all conditionals.
Pros
- Faster (60%)
- Uses less bytecode (6 bytes, 1 instruction)
Cons
- Harder to understand
- Only for Integers
(myList = []) and (myStr = []) Hack
| VM: LSO | Discover: Strife Onizuka |
This hack works equally well for both strings and lists.
Instead of using myList = myList + addition you can use myList = (myList = []) + myList + addition which will in certain situations reduce memory fragmentation. Memory fragmentation can result in what appears to be a memory leak. This works because LSL execution is Right-To-Left, it frees the value stored at the variable's memory location after copying it to the stack but before storing the return back to the location; the result can be better memory compacting.
Pros
- Possibility of reduced memory fragmentation
Cons
- More costly in bytecode and slower
- Doesn't work in LSLEditor (LSLEditor uses Left-To-Right order of execution).
- No real benefit when used in Mono
- Possibility of slightly increasing memory fragmentation
Notes
- Be sure to test it both ways around before using this.
- This can also be used with any function.
llDeleteSubList((myList = []) + myList, x, y)