User:Lum Pfohl/SL Trivia

SL Trivia

These are things I've noticed about SL over the course of a year. In no particular order at this time:

Avatar and UI

Pressing the SPACE BAR while you move of fly will make you go slow. A fun thing to do is to fly up, press and hold the SPACE BAR and disable flight (stop flying). You will fall and flail in slow motion until you touch down, light as a feather.
Typing /0 followed by your message text will suppress the Typing Anim. In addition to the DEBUG SETTING PlayTypingAnim, entering /0 before each message in group chat will signal SL to send your message to "Channel 0" - which just happens to be group chat - but you won't do the typing animation or have the associated clicking sound.
There is an SL glitch with the CROUCH button. Pressing and holding the CROUCH button (either PGDN or C) and tapping the FORWARD (UP ARROW or W) once will cause your avatar to "wig out." Keep the CROUCH button pressed for the entire period, and you will see your avatar move back and forth wildly until you eventually move off-sim. When you do, your hair attachment will come off!!! ahahahaha!
Linden Avatars do not show up on your Radar HUDs. Radar HUDs (and other avatar-sensing scripts) rely on the llSensor() and llSensorRepeat() functions. Linden personnel appear to be hidden from these functions, and thus would not be visible on any Second Life radar scripts. Lindens do appear on the mini-map. Because many of them hover over the land, they appear as green "T" symbols and can be discovered that way. I have to validate my claim, but so far it's proven true.
It is possible to hide your name tag from others. By cleverly placing an invisi-prim over your head, the Avatar Name Tag can be obscured from view on everyone's Client Viewers, making you "nameless."

Inventory

You cannot transfer more than 42 individual inventory items to another user at once. To transfer more than this amount, you must either break up the transfers into two or more chunks (like a folder of 80 items can be broken in to two folders of 40 each), or stuff the items into an object and transfer that one object.
You can open more than one Inventory window. Open your INVENTORY. In the Inventory Window is a menu option called FILE. Click FILE -> NEW WINDOW and a second Inventory Window will open. You can now perform independent functions on each window - drag/copy from one window to another. Great tip for managing your cluttered inventory!

Prims and Objects

You cannot enable physics for an object of more than 31 prims. There is much debate on whether this number is 32 or 31. I believe it's 31. Attempting to enable physics on an object of 32 prims gave the message Script can't enable physics for objects with more than 31 primitives
Rendition of Flexible Prims is a client side only function. That is, a flexible prim such as a skirt - is rendered completely on the Client Viewer. Each person's viewer can have a totally separate experience when viewing flexible prims, depending on their PC's load and lag conditions. Of course, having 10 flexible prims and having 1000 flexible prims will give different performance (which might be perceived as lag,) but the fact is that your PC is bogging down, not Second Life.
A Flexible Prim causes less server load than a Regular Prim. When a object's "Set Flexible Path" setting is enabled, the object becomes Phantom (that is, you can pass through it without collision). Because the server doesn't have to calculate object and agent collisions with these objects any longer, the computational loads on the server is actually alleviated.
A Particle Effect is a client side only function. Similar to the argument for flexible prims, rendition of the particles is purely a Client Viewer task. Again, everyone will see different particle effects, depending on the max number of particles they are set to see, how many particles are in their field of view currently, and whether they have particle rendering turned off.
A Particle Effect is a Property of an Prim. This may sound like "duh," but people just don't understand. A particle effect, is just like any other object property (size, color, shape, hollow, twist, etc.) The only difference is that the particle effect property is only accessible by a script - it can only be set, not read. Once set with the llParticleSystem() statement in LSL, retains that property regardless of whether a script is there or not. If a particle effect is set to "die out," over time - then it will do so - but the properies are still set. Conversely, if a particle has an undefined lifetime, the only way to "stop it," is to pass null parameters to the llParticleSystem() function via LSL.
A Hover Text is a Property of an Prim. Like particles, once set - it doesn't go away when the script that set it is deleted. It must be "set" to an empty string using LSL's llSetText() function.

Object Linking

When objects are linked, the PHANTOM property of the ROOT PRIM is copied to the entire object's prims. Here is a test: Create 4 boxes. Make one of the prims a PHANTOM object. Link all 4 boxes, with the PHANTOM box as your root prim. Your resultant object is completely phantom. Unlinking the object reveals that all 4 prims are now PHANTOM as well. You cannot have a "partially phantom" object.
When objects are linked, the TEMPORARY property of the ROOT PRIM will affect the entire object - even though those other prims are not temporary. Unlink the PHANTOM property, unlinking the object will reveal that the TEMPORARY property was not cascaded to the child prims. Still, watch out when you link a very expensive no-copy HOUSE with a TEMPORARY box as your root prim. Your house will disappear without a trace and that would be bad. :(
Objects which span more than 32 meters (from center to center of the extreme prims) cannot be linked. I'm sure there is some sort of workaround for this - like sub-linking objects such that their geometric centers are no more than 32 meters... Need to test more around this claim.
Linking Objects places a load on the ASSET SERVER. If I have 5 object - each an individual entry in the ASSET SERVER database, linking those 5 objects together will "re-arrange" the relationships amongst the objects. The resultant single object will be the root prim of the last-selected object. This "coalescing" of individual prims and objects under the heirarchy of a single prim places a load on the ASSET SERVER. That's why objects do not seem to link properly when there are ASSET SERVER ISSUES.
Taking an object created in-world then rerezzing it does not rez the original object. Instead, a COPY of the object is rezzed. Because a COPY is rezzed, further load on the ASSET SERVER is placed in making a clone of your original object.
When copying objects using the SHIFT-Drag Arrow method, the original object/prim is the one being moved around. While in EDIT mode on a prim, press the SHIFT key and move the Prim. A copy of that prim is made. The ORIGINAL prim is the one that is being moved. A COPY will be rezzed and left in the original position before the SHIFT-move copy function.

Land and Sims

There are 16 Help Islands. Ten of them are accessible by new residents. Help Islands 11 - 16, I have no idea what they're for.
There are 2 Help Island Publics. Help Island Public2 is situated immediately West of Help Island Public, and serves as an overflow site for HIP. It runs on a newer, faster hardware. However, when Help Island Public crashes (as it often does), residents trying to teleport there do not get rerouted to HIP2. Instead, they'll simply be told the region is not available. As such, HIP2 remains relatively unpopulated.
The two HIPs are not identical. The freebie store's vendors are configured differently. Also, if you view two two HIP's on the mini-map - you'll see a large black box over the sandbox in HIP2 that does not appear on HIP. That is because
There are sims which show up as icons in the MAP and www.slurl.com. When viewing the map, there are sims with recognizable features. The Star of David, Map of Texas, the words, Please Fix SL or Doctor WHO. It is actually amazing to think of of how this technology works. There are thousands upon thousands of sims. Each sim's object location (and even colors) are rendered quite accurately in the MAP and www.slurl.com sites. It's also great fun to browse the world map.
A SIM can become disconnected from the grid and still function. Residents on that disconnected sim will still be able to move about, chat and IM with each other. However, they will not be able to perform any of the following functions : Rez Objects, Teleport, Search, MAP, IM residents outside the sim or participate in any Group IM. If that resident logs off and attempts to log back on, they will receive the message "You have been moved to a nearby sim." Residents in the neighboring sim will simply see a vast ocean of "nothing" where you sim used to be. Linden Labs can often "rejoin" the sim to the grid without restarting it and things will continue as they did before.
A SIM has its own database, independent from the ASSET SERVER. This is a blessing in disguise, but is also a danger. The local sim's database is backed up every hour or so. Any items and objects you set out onto the sim is maintained and backed up by the sim. If a sim crashes, the last backup is read back and "rendered." By keeping a "backup" of your valuable goods in your inventory on the SIM, you can weather the Asset Server Inventory Loss syndrome. The flip side (and danger) is that if you set out a NO COPY object from your inventory onto the sim - the Asset Server marks it as no longer in your Inventory. The SIM is now carrying that object. If the SIM crashes before a backup is made - your object is gone for ever. Caveat emptor...
On the mainland, the ban lines extend to 150 meters. That is, you can fly over a parcel that you are restricted from. If you stop flying over that parcel and fall, you can bounce up and down as you are repeatedly thrown out by the land and fall back down...
The max height for a regular object is 768 meters. Setting an object's height above that number (either by dragging it or setting it directly) clamps the object at 768 meters. An avatar can go way above this. Using a tool such as NEO FLIGHT, one can fly up to 250,000 meters in a few minutes. There is absolutely nothing around and nothing to see. Or is there?
Objects can be found above 768 meters! I have seen motorbikes, cubes and such above 768 meters - prim litters in the sky. One conjecture is, if an object is made physical, it can move beyond 768 meters. Another conjecture is that if one is wearing an attachment and drops it at an altitude of over 768 meters. I have tried neither to verify. I have seen objects at 1500 meters!
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.
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 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.