Difference between revisions of "LSL Hacks"

From Second Life Wiki
Jump to: navigation, search
(if(~{{LSL Param|c}}) and if({{LSL Param|c}} != -1))
m (({{LSL Param|c}} = -~{{LSL Param|c}}) same as ++{{LSL Param|c}})
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 13:32, 7 August 2009

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

Pros

  • Faster
  • Uses less bytecode

Cons

  • Less readable
  • Will likely be removed in LSL3[1]

++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)

Footnotes

  1. ^ Plans for LSL3 are still being worked out, nothing has been finalized, no release date has been set, LSL3 may in-fact never happen.
  2. ^ The LSO LSL compiler does not produce optimized code.