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 or 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." It is possible to hide your group tag from everyone. There is a setting in Preferences which will prevent the active group tag from displaying on anyone's screen. It is possible to hide your group affiliation from your profile. There is a setting in your GROUP INFO dialog box which will keep the group from appearing there. The group will still appear in your MY GROUPS display, so you can activate / administer it at anytime. It is possible to zoom into an Avatar's head. Inside, you'll see eyeballs, teeth and a tougue! Here's how. Using your Camera Controls, focus your camera on your face. Then, press and hold ALT and the Left Mouse Button and move the mouse forward. You'll break right past the face until you are peering inside your own head. Normally, your avatar does not emote so these teeth and tongue are not shown. My friend Dahlia Trimble once thought of putting an animated squirrel in a wheel and embedding that into the Avatar's head... 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! Clearing Cache also clears your Inventory Listing. When you relog and open your Inventory, you'll find you have nothing to your name - until the download of the items complete. Additionally, the Inventory listing download will not occur until you open up the Inventory window. If you close it before the download is complete, it will resume when you open the Inventory window again. You can drag multiple folders into prims. Doing so creates a "package," as everyone knows. But the folder names are not preserved. When the package is unpacked using the OPEN -> COPY TO INVENTORY function, a new folder with the name of the prim (the package) is created and the items are placed in there. You can place packages inside packages. This is like zipping up a zip archive. There seems to be no limit as to what or how many these things can hold. Luna Idler, a resident of the Calleta Infohub passes out a Newbie Helper Kit that contains more than 1000 items (packaged in many sub-packages). 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 load 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. It is possible to upload a sculpted prim texture map that is not compressed by JPEG-2000 However; this is a hack - probably done via the magic of open source. This leads me to believe that JPEG-2000 image compression is done by the client and the image is simply stored in the Asset Server. I have a 10-star single-prim sculpted object which uses such an uncompressed map. Just as textures viewed at distances lose their resolution, sculpted objects turn into blobs at distances. This is easily demonstrated with the 10-star sculpted prim. At close ranges, the 10 stars appear to be sharp, crisp and beautiful... When the Camera is zoomed out, the texture map seems to lose resolution and the whole thing turns in to a blob. Zooming back in, everything is sharp and crisp again. Linking Prims & Objects 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. A corollary is that if you have a PHANTOM object linked to a NON-PHANTOM object, the PHANTOM object loses its PHANTOM property. When prims and 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. Object will also not link if they're much closer than 32 meters apart. Here's a test: rez two 0.5 m x 0.5 m x 0.5 m cubes, 4.5 meters apart and attempt to link them. The link will fail with the message, Link failed: prims too far apart. Move them such that they're 4.3 meters apart and they'll link successfully. I'm still looking into this relationship... Linking Objects places a load on the ASSET SERVER. If I have 5 objects, each being an individual entry in the ASSET SERVER database, then 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 black section over the Freebie Store in HIP that does not appear on HIP2. That is because the Freebie Store on HIP is damaged and is missing part of the roof. HIP was damaged back in October 23, 2007 The platform was deformed, the bridges were missing and many other aspects were out of place. I am not sure what had happened there, but it was repaired by October 24, 2007. If you get stuck under the lava at OI, there is a prim you touch to get back out. A nice twisted cube prim prominently displays the hovertext, Stuck under the lava? Click me. Clicking it puts you back onto the bridge. 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 the latter up to 2000 meters. Beyond 2000 meters, dropping an object simply results in the object "disappearing." Objects rezzed above 768 meters cannot be moved. It just won't. Can't edit it and move it left, right, up nor down. Whaddya think of that? Amazing things happen when you sit on an object above 768 meters! Fly up to, let's say 1500 meters and WEAR a BLACK STREAK BIKE (a motorcycle) in a script-enabled, build-enabled land. Right click and sit on the bike to ride. See what happens! 1) you'll crash the browser trying to sit on the bike 2) you'll sit on the bike and nothing will happen until you stand and you'll fall to -200,000 meters! 3) you'll sit on the bike, and it'll begin to fall and move forward at the same time, crossing hundreds of sims and going deeper and deeper into the ground. I stopped mine after I crossed 14750 meters EAST (that's 57 sims) and went to -100,000 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. Some functions cause the script to block for a certain number of seconds. Functions such as llEmail() and llRemoteDataReply() delay the scripts for 20.0 and 3.0 seconds respectively. This is probably done to prevent a single prim from monopolizing the entire resource bandwidth, and the mitigate the risks of spamming. You can overcome some of these limitations by segregating the llEmail() and llRemoteDataReply() functions into several separate slave scripts that will be called by the main script in a round-robin fashion using llMessageLinked(). As one call is made, the first slave script will block, while the other slave scripts are free and ready to perform the actions. The main script can continue to operate without blocking either. I am a big proponent for the use of llEmail to communicate between objects and avatars and the real-world. Scripts can send email to your home email address. And, they can receive emails from the outside world too. They can send and receive emails amongst themselves. If the receiving script is blocked, or the sim in which it is residing is offline, the email messages are queued on the secondlife sendmail servers until they are polled and read. How handy! This makes for a semi-robust networked vending system. Strange Phenomena Sitting on an object sometimes takes you to location 0,0,0 of the simulator. It is an unsettling experience, but sometimes you find yourself in Limbo - maybe with other avatars around. You cannot move, you cannot stand, you cannot sit. You can chat - and the people around in normal SL you can see you and talk with you. You just cannot see them. This condition usually clears up after a minute or two. Sitting on an object in an impossible place can take you to negative altitudes. Using your Camera, you can get inside and under objects and right-click something and sit on them. Attemping to sit on objects object where clearly there isn't room for you to do so might send your viewer to negative altitudes and you might be looking up at the sim and people above you. Standing from an object that extends into another sim is hazardous to your health! Well, not really. But it is interesting to see what happens. You can try this at the Hangeul Welcome Center. There is a circular bench directly in the middle of where the 4 sim corners of the Welcome Center touches. This circular bench is located in the Hangeul sim. Stand in Hangeul, and right click and sit on the bench (and you can) on the side where it extends into one of the three other sims. When you stand, you might find you're "stuck" there for several minutes - then all of a sudden everything around you disappears and you find yourself high in the sky, then you might find yourself tucked behind another bench in the sim you stood up in. The trick is to stand up from an object that extends into another sim... Lag Textures Cause Lag I've got a whole write up about this here. Giant Prims Cause Lag Giant prims cannot normally be constructed in Second Life. They were perhaps built with a hacked version of SL which had disabled the 10.000 meter constraints on the dimensions. Again, because of their size the simulator must calculate a lot of things, such as collisions of a physical object or avatar with those prims. The larger the prim the larger the collision area and more calculations needed...? Scripts Cause Lag Scripts run in a prim and when rezzed on the simulator, the simulator takes responsibility for its execution. When there are hundreds, even thousands of scripts, each script is given a "time-slice" for execution. Obviously this occurs in addition to everything else the simulator must do. There seems to be no limit on the number of scripts a prim can have... Torus Prims Cause Lag This is only hear-say. I guess due to their complicated shapes the simulator has an extra-hard time coping with the collision mathematics. I once rezzed 3200 tortured torus prims over Linden Weapons Testing Sandbox -- the sim didn't seem any more laggier than usual. Lum Pfohl 06:55, 29 November 2007 (PST)

Lum's Quick Links Click to Enlarge My SL Stuff My User Profile Newbie Helper Kit Newbie Must Knows Troubleshooting LSL Goodies Build Goodies SL Trivia OpenSim Stuff External Wiki Contributions DMP1/DMS1 DMP1/DMS1 Programming Related topics Main Page Volunteer Portal The Tao VTeam Blog edit