Difference between revisions of "User:Lum Pfohl/SL Trivia"
Jump to navigation
Jump to search
m (→SL Trivia) |
m (→SL Trivia) |
||
Line 49: | Line 49: | ||
# '''You can fly in a no-fly zone.''' There are two ways: 1) if you were flying when you teleported to that region, you can continue to fly while in that no-fly region. Once you touch down, you'll find you can no longer fly. 2) if you enable ADMIN OPTIONS - then you will be able to take off and fly at will in a no-fly region. | # '''You can fly in a no-fly zone.''' There are two ways: 1) if you were flying when you teleported to that region, you can continue to fly while in that no-fly region. Once you touch down, you'll find you can no longer fly. 2) if you enable ADMIN OPTIONS - then you will be able to take off and fly at will in a no-fly region. | ||
# '''The no-script zone over Orientation Island Public goes only to 100 meters in elevation.''' Above this height, your scripts will work. | # '''The no-script zone over Orientation Island Public goes only to 100 meters in elevation.''' Above this height, your scripts will work. | ||
# '''At high altitudes, you can fly wicked fast without flight assist.''' In fact, you'd fly TOO FAST and become uncontrollable. If there is a platform up in the sky - you'll fly skimming over the platform at blinding speeds, until you fall off the boundaries of the platform and begin to fall. | |||
# '''At high altitudes, 1 SL second != 1 SL second.''' The time interval passed to the llSetTimerEvent() seems to become meaningless. '''llSetTimerEvent(1.0)''' should cause a '''timer()''' event to fire every 1.0 seconds (or longer). Instead, it could be happening 2 or 3 or even 10 times every RL second! Even on a laggy sim - dynamics seem to change at higher altitudes. Why would an overloaded CPU find "second wind" at high altitudes - unless if certain scripts ran on the client? | |||
;Scripts | ;Scripts | ||
# '''Scripts can work in a no-script zone.''' By requesting (and obtaining) permission to take controls over (that is map movement keys to a function within the script), the script can work in a no-script zone. The problem is, this permission must be granted BEFORE entering the no-script zone. | # '''Scripts can work in a no-script zone.''' By requesting (and obtaining) permission to take controls over (that is map movement keys to a function within the script), the script can work in a no-script zone. The problem is, this permission must be granted BEFORE entering the no-script zone. | ||
# '''Scripts can compile from your Inventory.''' You can edit a script and compile it directly from your inventory. If there are syntax errors, it will tell you so. | |||
# '''Scripts will only run, when placed into an prim and rezzed in-world or as an attachment.''' Having scripts does not a monster make... Those scripts must have a vessel in which to run. A prim is such a vessel. The scripts are interpreted by the simulator. | |||
# '''Variables and states of scripts can be stored in the ASSET SERVER.''' That is, if a counter script is placed into the prim and it counts by 1 every second, that counter object can be taken into inventory and given to another resident, and rezzed a year later and it will continue (in theory) to count from where it left off... This is the state persistence magic of Object Oriented databases. It is quite a miracle of implementation, in my opinion. | |||
Revision as of 12:09, 18 December 2007
SL TriviaThese are things I've noticed about SL over the course of a year. In no particular order at this time:
Lum Pfohl 06:55, 29 November 2007 (PST) |
|