Second Life (SL) is an immersive, three-dimensional (3D), on-line, interactive, multi-user, real-time, building/chatting, virtual reality (VR) environment. Overhyped buzzwords aside, SL is basically a 3D multi-user level editor.

Compared to Active Worlds (AW), SL is, generally, light years ahead. However, AW supports DirectX, OpenGL, and software rendering; SL only supports OpenGL. AW has better lighting (before SL 1.9.1 for the most part but AW still can do spot lights while SL can only do point lights). AW 4.1 has particle effects with more options than SL. AW allows external models while SL is limited to propietary primitive building (no vertex-polygon modelling). Any AW citizen can run a world (SL "simulator") which can be much larger than an SL sim at a fraction of the cost! Also, AW isn't run by a dictatoral, oppressive company as Linden Lab is who develops SL (though AW has had its share of stupid pet developer antics as documented on my AW history).

See how SL compares to other 3D games. See Links for another person's comparison.

• starting: SL can't even start (since SL 1.7) on Windows (and possibly other OSes) if the user profile directory name has an extended ASCII character in it. Mine is "Eep²" and I've had to run SL under the administrator account ever since and it's annoying since it requires entering in the admin password and running SL under different credentials. Yes, I could switch users and login as admin but that's even more annoying! FIX THIS BUG ALREADY, LL! I wonder how many European SLers this has pissed off... Fixed in SL 1.9.1.13 (only 6 months later)!
  • This "special character in username path prevents SL from starting" is deadly--I've seen many, many occurrences of it.

    Just wanted to add that pending rigorous testing to make sure this bug has been squashed flatter than a classic video game sprite, it should be fully resolved shortly and included in a future set of release notes.(Torley Linden, 4/19/06)

  
  

• bandwidth: SL is very bandwidth-wasteful!
  • cache: The cache redownloads recently downloaded files way too often (and it's even worse since SL 1.9) and it doesn't remember textures, object info (name, description, etc), etc very well. Textures are almost always mindlessly redownloaded every SL session, even with a max cache size of 1GB. SL constantly asks the server for info on every tooltip when it should remember the last known retrieval and simply update it if it changes (like AW does)--leaving the current version as is with no "Retrieving..." text in the fields.

    
    

  • updates: There's no reason the entire 20MB (now ~25MB with the addition of the Gekko web browser engine) client needs to be redownloaded every time a new version is released unless something has changed that actually affects the entire client and all of its files. There is a large ..SecondLife\app_settings\static_data.db2 file that could just be patched instead of redownloaded, for example (and, of course, secondlife.exe). All the character directory files aren't necessary (at least textures and LLM files--whatever they are) for minor changes (GUI, no less) to chatting. AW has used a patcher since at least 1997--and it's only 3MB total (aworld.exe: 780K vs. secondlife.exe: 11.6MB)! Other benefits of a patch system:
    • no new desktop/Start menu icon with a different name ("Second Life Siva" vs. a renamed "Second Life Preview", for example)
    • no need to reoverwrite colors.ini and keys.ini files with customized parameters (yes, supposedly, custom_keys.ini is supposed to work but I have yet to get it to work and not be overwritten/deleted during a reinstall/patch)

    
    

  • uploads: SL allows uploads of images/textures, sounds, and BVH animation. It would be better if SL also supported ZIPped WAVs, like Active Worlds does, which can retain seamless looping (which tends to get broken when WAVs are compressed into MP3/OGG format (which SL uses the latter of). SL already supports compressed JPG/TGA uploading so images aren't really an issue, though it would be nice to have masked textures optionally separate, also like Active Worlds, so they can be applied to ANY texture:
    • increases usability without having to manually add a mask to EVERY image in an external image editor
    • saves bandwidth from having to upload another image with a different mask each time

  It's just about being efficient and not being unnecessarily wasteful.

  
  

• open-source:
  • LL has discussed how and whether a free software or an open-source transition for SL would be possible, and many LL employees are ultimately in favor of it, while some are skeptical. In any case, there is a bit of work necessary to do before such a move, and we've all agreed that now is not quite the time to throw a lot of effort into it. Yet at the same time many of us (including myself) believe that SL will indeed be dwarfed eventually by an free/open metaverse if LL does not go that route.

    The main obstacle in my mind is the protocol that SL currently uses. It has evolved into something unlike what we originally thought it would, and now has obvious shortcomings that we are scheming on fixing. I'm afraid that if we were to open it all up now it would snowball into an unmanigable mess like the open Netscape project before it was scrapped and reborn as Mozilla. The only way I think Free/OpenSL would work would be if LL were to clean up and stabilize the protocol so that it was easily extensible, then release a sample client implementation, and eventually the servers (which really aren't ready for a sparsely distributed system yet).

    An open, distributed, shared network was part of the plan from the very beginning when Philip was telling me about it over lunch that first week I came down to San Francisco, and as far as my opinions sway it is still part of the plan.

    My recommendation: stick around and see what happens -- it might be interesting.

    Incidentally, the back end of SL is becoming increasingly dependent on free or open-source (FOSS) software. Each simulator node now runs a squid, uses libcurl, and a few other FOSS components. It is possible that future nodes will be running MONO and jabber as well. It would seem a shame (it seems to me) to not contribute something back to the whole happy wonderful world of FOSS, preferably FS. (Andrew Linden, 4/6/05)

  • I'll speak for my own gut here, allowing that I'm sure this will be a long and interesting discussion in the years to come:

    My intuition is that open source and open standards are the only way to go for SL long term - for us to reach the whole world in the way that the web has will probably only happen under this sort of model.

    I don't think becoming more open would be a bad business move for LL, because there are so many central services that we can offer for a fair price - once SL goes to truly global scale those charges can create a very large and sustaining business.

    Pragmatically, there are things that need to happen to make this possible:

    We have to preserve some sort of system to protect the rights and permissions of content. This means that in some manner the servers must become untrusted - a 'man-in-the-middle' from a crypto perspective. Today, the SL servers are totally trusted - if you owned a server you could take all the money and copy all the objects of anyone who walked into it. I can imagine that long term you get a notice on entering insecure servers, and you can choose what objects and how much money you want to 'carry' when you go in. Coding this is going to be a big change, and lots of work.

    Additionally, as also discussed here, we need to make the protocols between servers very simple, so that folks can start from scratch with server code if they like. HTTP got really widespread in part because it was really simple - you could write a basic server in a few hours. Ideally something like SL needs to be comparably simple - you should be able to write a 'hello world' server and connect it to the grid very easily.

    Projects like OSMP are great, and something that helps us understand what priority we should give to these changes. Ideally I'd like to see the metaverse get built as quickly as possible, which means that everyone is working on interoperable code and content. If big projects get underway that are challenging SL in scale and capability, it means that we are doing something wrong - not being open enough fast enough. (Philip Linden, 4/6/05)

  • If LL ever releases portions of SL as FOSS, then SL will be an even more exciting and interesting platform than it is currently. I think that such a move is likely to happen, but not today.

    I think one of the things Philip was saying in regard to OSMP and VU was:

    "If a FOSS metaverse approaches SL's feature set before SL goes FOSS then LL loses the race." (Andrew Linden, 4/7/05)

  • OpenCroquet is an interesting open-source project. It is an ambitious system and by design has more flexibility than SL. Nevertheless, the existence of OpenCroquet does not relegate SL for the history books just yet. Both SL and OC are largely experimental in the sense that they are not feature complete, are only beginning to show their potential, and may very well be fundamentally non-optimal for whatever a final metaverse might look like.

    I may have misinterpreted Philip's statements in my rewording since I made my version seem a bit more prophetic and sudden. In the long term the future of persistent virtual worlds is bright. If SL ultimately fades from view it will only be because whatever replaced it was much better -- whatever it is, I think it will be FOSS which is why I think LL should ultimately move SL in that direction if we want SL to remain a contender. (Andrew Linden, 4/7/05)

• abuse/griefing
  • PvP abuse report log needs time/date/location (discuss): The PvP (player vs. player) abuse report log (Help > View PvP Abuse...) just lists the person and abuse action ("bumped with a script", "hit you with their avatar", etc) but doesn't give the date/time/location of the abuse, making it annoying to figure out what happened if there are even more than 1 of the same abuse. Sure, one can report each abuse to find the date/time/location of the abuse but that is annoying.

  • suspension/banning: When someone is suspended/banned from SL, they can just get right back in with an alternate account (alt). SL should suspend/ban by IP address and even network card MAC address. While still not foolproof, it will make it harder for some griefers to get back in right away at least. Storing a special registry key and/or a file somewhere on the griefer's computer (that isn't easily detectable) to indicate they have been suspended/banned would help, too.

• mouse control customization: While keyboard camera controls can be customizable, mouse camera controls (or any controls) cannot. For example, to focus the camera on something, the alt+left-click. Zooming in/out requires holding left-click while moving the mouse up/down, but rotating the camera requires holding ctrl and moving the mouse around. Most PC mice have more than one button so they should be configrable too. More intuitive mouse camera control would be to use the right mouse button for rotation (once the camera is focused on something, of course)--and hold down both left and right mouse buttons to pan the camera.

• FOV annoyances: The camera's FOV (field-of-view) changes when the camera zooms in on a prim/object close enough. While this can make editing easier at times, it should be optional since, on rotating objects, the camera can change FOV so much it's disorienting. Also, using the zoom in/out View menu options (which just change camera FOV), there is a bug: pressing ctrl+8 7 times to zoom the FOV out freezes the 3D viewport pane. There's also an issue with the keyboard repeat with the FOV zoom/reset keys not always working but I can't reproduce it.

• full-GUI 1st-person view: Mouselook (SL's current 1st-person view mode) hides most of the GUI and only allows clicking objects to activate "touch" events. SL should have a proper, full-GUI 1st-person view where everything (object selection/editing, inventory management, IMs, etc) can be done like in 3rd-person view. This can be somewhat simulated by hacking the camera in settings.ini or with SL 1.9's camera functions, but SL just needs an optional, togglable, full-GUI 1st-person view.

• reset (discuss): The camera should, optionally, not reset the zoom when moving (walking, flying, etc), and/or clicking on one's avatar, and/or when start/stopping flying, and not reset the rotation (pitch) when coming out of mouselook mode.

• sitting
  • rotation while sitting on:
    • prim: The camera is locked vertically and can't be rotated when click-dragging on the av, unlike when sitting on the ground.
    • prim/ground: The camera keyboard horizontal rotation keys invert. Also, holding the up arrow moves the camera closer and eventually into 1st-person view but holding the down arrow doesn't get out of it.

  • limb distortion: When the camera is focused on something (vs. on the avatar), and escaped out (reset), the avatar's limbs screw up and slowly (about 30 seconds) correct themselves.

Havok 2+
• As to the Havok-2 project... it has been going slower than I had hoped. The main thing we're trying to accomplish is to eliminate the "deep-think" problem (which is described elsewhere in these forums and is the cause of 99% simulator crashes). We've discovered that deep-think's are still possible in Havok-2 if we are not careful about how we describe the shapes of objects to the physics engine. Fortunately we know how to solve it and that is what we're working on right now. We gave an internal Havok-2 demo to the rest of the office last week where we showed the progress on that front.

  When Havok-2 is initially released it won't have many new features. We'll be happy if we manage to prevent deep-thinks and make things run a little faster.

  Once Havok-2 is happily doing everything the old physics engine used to do we'll start working on adding new features. Some of the features we'd like to get done are: more complex dynamic objects, better vehicles, new shapes, fixed joints and constraints (hinge, point-to-point, etc), new constraints such as ropes and chains, better collisions between avatars, colliding attachments, and more advanced script sensors such as raycast queries. New features will be released when they are done. (Andrew Linden, 7/17/05)


Ageia (physics processing unit--PPU)

• Ageia is definetly some interesting stuff. Some things to keep in mind:
  • This technology is not available yet and first-generation anything is rarely reliable/accurate/etc. It is likely to be quite a while before a version of this technology is available that we would feel comfortable relying on.
  • Integrating a physics engine is not trivial work. Ageia would require a complete reworking of how we deal with and connect to the physics system. As evidenced by our work moving to Havok 2 from Havok 1, this is not something that is easy or can be done quickly.
  • We have a lot of servers. Adding new hardware to all those systems is a prohibitive factor. There would have to be an immense benefit to warrent such a move. Especially if you consider from the previous points the time frame such an event would occur and our current simulator growth rate. And I don't even want to think about the social issues of only having this hardware in some sims much less the technical issues for passing an object from a simulator with one physics engine to one with another.

  The short answer is that we will of course keep our eyes on this technology but it is not currently planned for use in Second Life. (Kelly Linden, 3/11/05)

• The PPU technology is targeted at gamer desktop applications so its probably going to be an expensive expansion card that gamers can buy to enhance their systems and take advantage of accelerated physics for games that support it (specifically games that do a lot of physics on the local machine -- at the moment SL does all physics server-side).

  In the short term (1-2 years) I doubt SL will be jumping on this technology since the PPU systems will probably evolve quickly, be unstable, and/or be expen$ive. We'll probably wait and see.

  Cell-CPUs and multi-core CPUs could prove to be a competing technology to the PPU -- potentially making a dedicated PPU add-on card obsolete (anybody remember math-coprocessor cards?). We know these technologies are coming, will be ubiquitous, and that the manufacturers will be looking for killer apps that will drive people to upgrade. Games have traditionally been a huge driver of demand for faster technology, so Intel, IBM, AMD, etc will be probably be interested in writing physics SDKs that are optimized for using their CPUs.

  In the medium term (2-5 years) SL could probably start doing some physics simulations on the client for fluff effects and reducing the need for updates from the server. For this stuff SL might be able to take advantage of any PPUs on resident's home machines.

  In the long term (5 - 20 years) the PPU, Cell, and multi-core technologies serve to carry Moore's Law into the next generation. The general consensus is that we're approaching the beginning of the end for speed boosts from smaller microcircuitry fabricaton, but that doesn't necessarily mean Moore's Law is going to fail -- paradigm shifts in technology (can anyone say Cell, stacked CPU cores, PPU, embedded programmable gate arrays, optical computing, quantum computing?) will probably continue carry computing speeds forward. We at LL are counting on Moore's Law to remain true for several more cycles. (Andrew Linden, 3/11/05)




• collision: Animations don't affect avatar collision.
  The animation state of the avatar has nothing to do with its collision proxy. Sometime after the next generation of physics engine has been installed we will look into colliding the limbs of the avatar with the rest of the world. (Andrew Linden, 5/4/05)

  
  

• object mass (discuss): Primitives have a set mass that is just too light. Mass doesn't change much unless:
  • more prims are linked together
  • a prim is: cut (path, profile), hollowed, twisted, hole size, tapered, detal radiused, or revolved

  llSetForce and llSetBuoyancy can fake more mass but the physics engine, Havok, tends to make the prim/object "bouncier"--takes longer to settle into place as it vibrates/shakes/jitters around, and even stops at an angle when not fully touching a surface--it's odd. Prim mass should be adjustable via a llSetMass function.

  
  

• flexible prims: Flexi objects can be effected by sim wind, you can set a modifier for the wind force on a per object basis. (Kelly Linden, 4/4/06)
  • LOD twitch: Flex prims twitch/reset when their LOD changes.
    Steve Linden, 6/12/06, 21:20 via IM: As for LOD causing flex objects to twitch, that's hard to avoid. There are fixes, but we probably won't get to work on them for a while.

  
  

• springs:
  This is definitely one of the features that will go in post Havok-2.

  The main problem right now is not the load on the physics engine that springs would produce, but maintenance of the collections of objects of the springy objects. That is, keeping track of the sets of objects that are connected to each other by springs. Havok-1 does not maintain such lists so we would have to write the maintenance code -- Havok-2 automatically maintains such lists.

  This is a feature that is actually near and dear to Philip's heart. A loooong time ago, before Havok, we had some springs in our simple physics engine. One problem we had was stability -- if you do simple simulation math and throw a lot of springs together you end up with instabilities. Havok uses implicit methods for solving their "springs" which are a little bit more expensive, but much more stable. (Andrew Linden, 2/16/05)

One of the problems with our current UI system is that it is all hardcoded to some degree and is very difficult for even us to change... time consuming. So we really want to make it easier on ourselves. And, in the process, open up the ability to skin and modify the UI by the residents. The plan is to make the UI more data driven so it loads some config files (XML) and builds the UI based on what they say. If it was totally data driven, then much of what you want could be done. But not all... like detachable windows would be extra stuff, and would have to come later. (Andrew Linden, ~9/18/05)

...there are a lot more UI changes for textures/materials coming in the future, and I'm sure it'll be much more intuitive when we get it all sorted out. (Yedwab Linden, 4/17/06)

[16:32] Robin Linden: If you wait a bit, you can use XML and redesign the UI yourself and sell it. They're working on it now but I don't know the planned release date yet. (6/22/06 IM)

• axis transform handles/"gizmos" (the red/green/blue translate/rotate/scale axis controls; name suggestions)
  • auto-center (vote, discuss): I find it annoying having to move the camera to see the axis transform handles/"gizmos". There should be a way to have the handles automatically stay centered in the current zoomed-in view if they will go out of view. When zoomed out, recentering isn't necessary since the handles will be in view, but having to rotate the camera to even SEE the handles, when building up close, gets annoying!

  • always-visible (discuss): Whenever the camera is moved with the alt key, the axis transform handles disappear, making it hard to keep things lined up as the camera moves. An option is needed to always keep these on.

• dockable/tabbable windows: SL allows various parts of the UI windows (inventory, chat history, IM, minimap, object editor, script editor, etc) to snap to other windows and the screen edges, but they cover up part of the 3D pane, obstructing the view, and making the whole interface seem claustrophobic. I think a better, optional, design would be to have the 3D pane resize according to how the windows are docked (like most Windows UIs work). This is how Active Worlds' interface works (mostly) and it keeps things uncluttered (but could still use some improvement). SL's bottom toolbar (IM, Chat, Friends, Fly, Snapshot, Find, Build, Mini-Map, Map, and Inventory text buttons--which I think should, optionally, be icons with tooltips to greatly reduce the toolbar's width and perhaps positioned elsewhere) already exhibits this behavior but it's not enough. Transparent windows help, but the active window loses it and becomes solid.

  For example, my screen resolution is 1024x768 and I have the inventory, IM, and minimap windows open all the time and even with the inventory window at its minimum width and the IM window 5 rows high, this blocks a good bit of the 3D pane--worse with the object editor and chat history windows open. Since the inventory window can easily become very long, it is a prime candidate for dockability and 3D pane adjustment. The object editor window is expandable enough to warrant dockability too.

  Check out Active Worlds 4.1 (used in Wells Fargo's Stagecoach Island) to see how this would work--and with dockable/hideable window tabs , and maximum 3D pane . Obviously, with a proper, skinnable interface, it wouldn't have to look like Windows (though I prefer that style). SL's interface colors are fairly customizable but it's a pain.

  
  

• focus tabbing: Most of SL's windows don't support fully focus-tabbable controls for edit fields, checkboxes, pull-down lists, table lists, buttons, etc. This is such a basic facet of GUI design it's pathetic I even have to mention it here. SL 1.8.2.7 messed up the object editor's focus tabbing, but it still only tabs through text-entry fields and not other window controls. This is especially annoying in the Find window where, after typing a user to search for, hitting tab to, presumably, get to the "Online" checkbox, just mindlessly highlights the search string instead. Stupid. And tabbing from the result list puts the focus back to the text-entry field but hitting tab from there doesn't even return to the result list! Even more stupid. Tabbing should move from window section to window section--this means ALL controls.

• text-entry field character counter: For text-entry fields with limited character length (like the profile), a character number counter could be implemented.

• wordy script menu options: In the Tools menu there are some wordy options that could be optimized a bit:
  • Recompile Scripts in Selection -> Recompile Selected Scripts (saves 5 characters)
  • Reset Scripts in Selection -> Reset Selected Scripts (saves 5 characters)
  • Set Scripts to Running in Selection -> Run Selected Scripts (saves 15 characters)
  • Set Scripts to Not Running in Selection -> Stop Selected Scripts (saves 19 characters) or Stop Running Selected Scripts (saves 10 characters)

  Or, as Strife Onizuka suggests, a submenu named "Scripts in Selection..." (but I'd suggest "Selection Scripts" to save 3 characters or "Selected Scripts" to save another character) with entries: "Start", "Stop", "Reset", and "Recompile".

  
  

• Chat (+ History)
  • change "Mute resident" button text to just "Mute": It also mutes non-residents (objects).

  • new message indicators: If SL is minimized or in the background, new chat messages give no indication. New chat history messages should optionally flash SL's taskbar icon when SL is minimized or in the background.

  • shorten "History", "Say", and "Shout" button space around text: To allow text-entry field to be wider. Optionally, use icons with tooltips to get even more space.

  
  

• IM
  • add tooltipped icons: "Profile..."/"Close" buttons should be made into tooltipped icons. "Close" is redundant anyway; use the titlebar "X" button--or just remove "Close" and keep "Profile..." (which shouldn't appear in group chats or have "..." since it isn't editable, per se, and would reduce button width).

  • more column headers
    • group/user name: For users; groups could have total # users in group online.
    • online/offline status: A checkmark instead of "(online)" which takes up more space and clutters up the list (like the inventory object permissions/worn status)

  • multiple tabs: If there are enough multiple tabs to cause the [ < ] [ > ] arrow buttons to appear on either side, they won't disappear when a tab is closed (that no longer causes them to go beyond the IM window width) until about 15 seconds later (and only if a tab is selected).

  • new message indicators: The current IM session's tab and SL's taskbar button will only flash if the current IM session's tab is in the background. New IM sessions will flash the new IM session's tab and SL taskbar button (if SL is minimized or in the background). New IMs in the current IM session's tab should optionally flash its tab and SL's taskbar button when SL is minimized or in the background.

  • remove "Start"/"Close" buttons: Double-click group/user to start a chat and use the titlebar "X" icon to close windows.

  • remove redundant titlebar: When an IM session is started, remove the redundant titlebar with group/user name and "undock window"/close icons (which can be put in the main IM window titlebar). The extra toolbar reduces text lines and is particularly annoying when the IM window is very short (so it doesn't suck up even more of the screen than all the other unintuively hidden windows do).

  • separate groups and users: Tabs? Gets annoying having to scroll down past groups to get to users every time SL is run.

  • unnecessary text:
    • remove "New" from "New Instant Messaging" title: Just "Instant Message" suffices.
    • remove "New IM" bottom tab when no chats are open: It doesn't do anything anyway.

  • alternate design: Combine IM and "Friends" window for IMs and resize it like the inventory window, dump the excess space between buttons (use icons instead), lose the "Close" button, and show online users at top like IM window. User-specific buttons could appear when a user is selected and stay hidden, or disabled when a group is selected (or, instead of "Profile", open the group info ("Info" icon) window.

  
  

• Find: The "Find" window should be resizable, have full focus tabbing, and remember previous search strings (in a pull-down list) across SL sessions.

  
  

• Inventory
  I believe better inventory tools will be forthcoming. I might have seen a demo of multi select/delete working a few weeks ago ;-) Also, someone is working on a export/import system where you would be able to make local backups of stuff that you created and own, but that won't be in 1.7 (or if it IS in 1.7 it will be incomplete).

  I would expect the free inventory theshold to be adequate for most people's needs, however I don't know the average size of inventory, nor what the inventory size distribution curve looks like. I'm sure that if we were to try to implement such a system whoever was in charge of setting the values and costs would try to pick reasonable values. You know the phenomena where 10% of the population use up 90% of the resouces? I supect the inventory size distribution would exhibit that behavior.

  Someone who wanted a large inventory might opt to just pay for the extra storage. I'd also expect the price of such a service to be affordable enough to be used by many while still providing incentives that would convice many others to maintain a reasonable inventory (i.e. removing V1.03 of ObjectFoo when they are currently working out the bugs on V3.25).

  Anyway, this isn't on the roadmap that I know of, just something that we've discussed and are thinking about.

  ...

  The main reason why [saving inventories locally vs. on the server] would not be possible is because not all of your inventory is fully permissive -- we would only be able to store stuff that is 100% owned by you. However, if we did allow you to store your own creations locally, then you could then modify them locally and possibly re-upload the result as a new item. (Andrew Linden, 6/29/05)

  • animation: Since SL 1.6, the inventory takes longer to scroll when moving things and it slide-animates when opening/closing a folder. SL 1.9 introduced silly folder arrows (see below) that take forever to animate when a file is held over them waiting for the folder to open. Why make SL lag even more for such unnecessary animation effects? An option is needed to disable that fluff crap and put SL's inventory back the way it was in 1.5 when it was faster and more responsive.

  • auto-sort on creation/edit (discuss): When an inventory item is created/renamed, an option is needed to automatically sort the item by name or date depending on the setting--and keep the item selected. It's annoying having to do it manually after each rename.

  • colors: The dark grey open folder backgrounds (and white outlines around them) are also too bright and detract from seeing the inventory's contents. A colors_base.ini setting for this would be sufficient.

  • folder arrows: For some reason, LL decided to change the standard Windows +/- closed/open folder indicators with larger Mac-style white arrows. However, these are too big and bright on the black/dark inventory pane background and detract from seeing the inventory's contents. The bright yellow folder icons are bad enough without these folder arrows causing the inventory to look even more cluttered.

  • gestures: Can't (de)activate more than 1 at a time. Lame.

  • longer rename field: When an inventory item is renamed, the field is too short (21 characters), making it annoying to rename longer names.

  • "Inventory Item Properties" window: This window should, in theory, be the exact same size and have the same contents as the object editor's "General" tab, but it doesn't.
    • object/prim count: It's annoying having to rez the object before it will show the object/prim counts in its properties. The object editor "general" tab lists these so why not the inventory item properties?

  • reduce/enlarge height when folders are closed/opened: To eliminate excess empty space.

  • reduce width to maximum folder/file name width: Optionally within user-resized width--if inventory window width set to 200 pixels, don't resize beyond that but only within it.

  • remove excess space around "Show All" and "Filters" buttons: Or, better yet, create icons and use the titles as tooltips to make the buttons even smaller.

  • split into 2 panes: folders and files to make navigation easier and significantly reduce vertical scrolling.

  
  

• Map
  mini-map: The mini-map colors should either be redesigned or be customizable like other interface elements already are. It's hard to see lime green (avs) on turquoise (one's objects), for example.

  
  

• media controls: The "Music control" and "Movie control" media windows should be movable.

  
  

  Object Editor: For comparisons, mouseover tabs for my versions and click tabs for original versions (only "General" and "Features" change, currently). Top (Mode) Pane: Bold the selected mode's text and put a horizontal line in between the mode icons (menu options) and text and other options. Edit Move the object coordinates "popup" (X: ###.### Y: ###.### Z: ###.###) data from the top center of the 3D pane to the object edit window (to left of "More >"/"< Less" button, for example) so it can't be covered by other windows. The chat background opacity setting should also apply to it (if it's left where it is--but at least move it up flush with the top of the menubar). Tab Pane General: Reduced wordiness ("can", "when", etc) and made it more efficient and intuitive. Description: Note the lack of the redundant "(No Description)" text. It's obvious, if the field is blank, there is no description...the same should be for other inventory items (textures, sounds, animations, gestures, etc); gets annoying having to clear it all the time, only to have it reappear later, randomly. Photo: Add a photo of the object that the resident can add from their inventory (and not be charged L$ for it). "Creator", "Owner", "Group" buttons: Convienent resident profile (or group info) access and reduces the need for separate buttons. "Aquired", "Created", "Modified": The inventory item properties window has the "acquired" date/time but the others are needed too. Permissions: Section clearly outlined and organized appropriately Sit/Touch Text: This section is a quick way to change the sit/touch text without having to use the llSetSitText and llSetTouchText functions. Obviously, a script will override these settings. Object: Rename to "Prim"? Remove "Edit object parameters:": It's obvious this tab is about editing object parameters; this text is unnecesary. "Hover Text": This section is a quick way to add hover text without having to use the llSetText function. Obviously, a script using this function will override these settings. script-specific controls: Disabled "s" rotation field and checkboxes Features: Remove "Edit object parameters:": It's obvious this tab is about editing object features (despite them not actually being in the "Object" tab); this text is also unnecesary. Light: Color - make preview image the same size as in "Texture" tab and add a "Same as Primitive" option to use the prim's color (which will then disable/greyout the light color preview image. Smooth Rotation (°): Since llTargetOmega is a client-side effect, and since "flexible path" and "light" are already here (and have comparable LSL functions to control them), I figure smooth rotation should be too (and smooth movement eventually when it's added to SL--hint, hint, LL...). Texture: Repeats per Meter: Lose the "Apply" button; just automatically apply the change like every other setting. Align: Expand with full text ("Align Media Texture") to remove duplicate "align" text and put "(must load first") on the same line--if this text is even necessary since the button is disabled until the texture is loaded anyway. Smooth Animation: Like "Smooth Rotation" above, this section is for another client-side function, llSetTextureAnim. While more complex than llTargetOmega, it's still implementable in the object editor. Content: Change the "New Script..." button (which opens up the script window) to "<< New Script" which expands the object editor to include the GUI script editor (see below). A separate particle editor will then expand off the script editor.

  
  

  Script Editor GUI Editor: This design is similar to my redesign of the Active Worlds Object Properties window but far more complex: a dynamic, intuitive, well-designed graphical user interface to create a script without having to learn complicated programming-level syntax and structure by using a branching tree layout to represent code blocks--without writing any code. The script editor window is an extension to the object editor and will pop (not slide) out on the left. Since many script functions mimick object editor functions, the object editor tabs can be utilized for most functions (which will enable/disable controls relative to the selected script mode--see below). Another way to present scripting is to start out with what the user wants to do (set something, get something, etc) then ask when that will happen (on rez, when touched, if the object hits something, etc). With just simple language, higher-level functionality can be translated down into lower-level code. Of course, more complex scripts will most likely require code-level editing but for many simple scripts, this GUI editor should suffice. Window layout: title bar (window name, context-sensitive help that opens up to the appropriate LSL Wiki web page, and minimize/close buttons), menu bar (with "Source..." option in "Edit" menu to view the script's source code), status bar, 3 panes: Code block tree Branches: (like the inventory with icons) colored for each state, event, function, and flow control statement, and single entries for groups of local/global variables (scope-position-dependent). Punctuation: Braces {}, semi-colons (;), brackets [], commas (,), and other punctuation are unnecessary since automatic branch indentation shows program flow and UI controls will handle multiple items (as in lists). The underlying code will still use punctuation, of course. Example: default state entry Set Text touch start if (condition) statement else Automatically resizes relative to contents. Supports standard multi-select context menu options: cutcopypastedeleterenamemove (+ drag-and-drop) Script parameters/values: pull-down lists, buttons (normal, radio), checkboxes, text-entry fields, color/texture pickers Status/buttons: Errors, tooltip info (since it can stay visible longer and won't have linewrap issues), and expanded tree entry info (i.e. click on a function and the status area shows all of its parameters in code form). Categorization: The LSL Wiki already categorizes everything so I will use that as a starting point. Functions: Remove "ll" from names and focus on a more intuitive naming scheme (spaces between words, complete words: "Params" to "Parameters", etc) to make it easier to figure out what one wants to do: Get Script NameInstant MessageParticle SystemSet Prim ParametersSet TextureTrigger Sound (limited) Group them by different types: get/set, remove, start/stop, etc. Provide a way to switch between alphabetical and categorical lists. Obvously, the underlying LSL functions will remain named the same. Events: Remove the underscore (_). Functions/Events: Sort by category like: agent/avatar, camera, communication, collision, etc. Script flow/mode: Different modes will allow the script editor to remember and store each entry in the tree. Once an entry is complete, the <-' (enter) button is clicked to add it to the tree. tree entry: Select a line/branch in the tree to have its parameters/values loaded into the right pane. state: Because scripts use states, that is usually the first thing the user will select. Obviously, default is the first state and will be assumed--hence, the user won't need to do anything to begin in this state. The user can simply begin choosing things to do (events, functions, etc). However, a text-entry field for a custom-named state should be here. event: Sort type (alphabetical, categorical, etc)-selectable pull-down list function: When a function is selected, the window controls update (hide/show/change) accordingly: constants pull-down list contents change according to function, etc. Examples llSetText: Takes a string text, vector color, and float alpha. Select "set text" from the function list. Enter the text in the "text" field (or choose from the "variable" pull-down list). Click the "enter" (<-') button to add the entry to the tree. llSetTexture: Takes a string texture name and an integer side. Select "set texture" from the function list. Because a standard texture picker image button is more intuitive than having to type a texture name, the object editor "texture" tab) will be used to select the texture. (A text-entry field is still present but shouldn't be necessary with a well-designed texture/key picker). Since ALL_SIDES is a constant, only it needs to appear in the constants list. However, since it is a fairly common constant, it can just be represented by an "all sides" checkbox instead. Or, even better (and more intuitive) use the "select texture" mode in the object editor: for all sides, the entire prim is selected; for a specific side(s), the prim's sides are clicked on and the script editor will save each side into a list (or multiple calls since this function can't handle a list type for side). llRot2*(llGetRot()): click the radio button next to the position axis Variable type: Normally, instead of having fields named for types like integer, float, vector, the UI controls will change relative to the function. See below for examples. However, a variable type pull-down menu is still present. key: Since a key is used mostly as a target, the "key" field is directly under the "target" pull-down list (which has standard target keys for the object, object owner, script owner, and an inventory item--which will show another pull-down list of any items in the prim's inventory). list: A table of list entries can be shown instead of (or as an additional option to) showing a list as [1,2.0,<1,2,3>]. type name value integer name1 1 float name2 2.0 vector name3 <1,2,3> rotation: All rotation is automatically converted to Euler by default but the quaternion "s" value is also present. string: Uses the "text" field exclusively but since anything can be converted (typecast) to a string, a function or variable can be selected too. vector: Uses object editor's "Object" tab's "position" field which changes name according to what the vector is for: position, direction, velocity, force, impulse, target, etc. Euler format rotation (which is a vector) is handled as described above. Scale has its own separate fields like normal. name: Text-entry field for custom variables. global: Checkbox for a global variable (which will put it in the "global variables" branch). "Script Search" window: There's no indication if no result is found. The window needs a status bar (perhaps use the main script window's bottom status pane) to indicate no results found. Needs an option to match on whole word only. Regular expressions would be nice too. width: Can't be narrowed less than a certain width so it takes up even MORE of the screen than it did prior to SL 1.9. Fixed in SL 1.9.1.9 (1 month later)! However, it still can't be as narrow as it used to be... (and is 2 pixels wider in SL 1.10.4).

  
  

• Particle Editor: See particles.

  
  

  Profile: For comparisons, mouseover tabs for my versions and click tabs for original versions. inconsistent text field sizes: On the "2nd Life" tab, the "About" field holds 500 characters yet is shorter than the "1st Life" tab's "Info" field, which only holds 250 characters. Oddly, the "My Notes" tab's only text field doesn't state how many characters it can hold yet is the longest text field but goes beyond the width borders of the other tabs (as does the "Picks" tab's UI elements). These improvements maximize text field space: all tabs: Move other-resident profile buttons ("Show on map", "Instant Message...", "Rate...", "Pay...", "Offer Teleport...", "Mute") down to overlap "OK" and "Cancel" buttons for a resident's own profile. Mouseover image's buttons to see this. 2nd Life: Shorten "ratings" section and list multi-column (especially since negative ratings are no more). This will break up the list of received ratings ("behavior", "appearance", and "building") vs. given ones but it's not that big a deal. Interests Change "I Want To" to "Desires" to be consistent with "Skills" (vs. "I Can Do" or something stupid like that). Expand text fields for these sections to use the full window and add character limit. Replace "Modeling" with "3D Modeling" to skill option since "modeling" is often confused with photoshoot/runway modeling. 1st Life Add second photo since there's enough space. Expand text field to use the full window. My Notes Center text. Expand text field to use the full window and add character limit.

• axis transform handles: See interface.

• edit particles: The particles that emit from an avatar's hand when editing something can be very distracting--especially when zoomed in and even more especially when working on particles (and still even yet still more especially when zoomed in close!). An option is needed to disable these completely (without mindlessly disabling all particles). Also, the particles should simply scale down to 0 as they move towards their target.

• floating point rounding errors (discuss): SL's full of them, from grid position irregularities to the object editor dialog, which is particularly annoying when it decides to round cuts and other prim parameters. Of course that started happening with the dreaded SL 1.7 release, too, I think.

  
  

• integrated modeller: If SL is going to be accepted in the mainstream it must support object importing. Otherwise, it remains propietary and, essentially, worthless. This is what happened to Active Worlds (AW) and its use of RWX (RenderWare script) from Criterion, who dropped support for RWX in RW3. Criterion replaced RWX with DFF but I heard even THAT format will be discontinued. The point is: propietary formats suck. 3DS (3D Studio) is a common format that's been around for at least a decade or 2. For SL not to at least support that is just stupid and foolish. SL doesn't have to allow physics in imported models (right away) or even anything simple like changing overall color/texture (like AW does) but even those would be trivial.

  The problem is: SL has an integrated "modeller" but it just sucks. SL tries to do too many things. While I would love to see an integrated 3DS Max-level modeller in SL, until LL and Autodesk (3DS Max's developer) team up, I doubt that'll happen anytime soon (but it should--and it will in another app eventually).

  Obviously, collaborative modelling is where 3D is heading towards, as is evidenced by 3DS Max's continued addition of asset management sharing. It's only a matter of time before multiple users can model simutaneously, creating the scene in real-time--just like a movie set. The integration of movies and 3D animation will only push this even further. Pixar's RenderMan may already have this capability, but Maya and Max (both now owned by Autodesk) are used extensively and are more popular.

  Will Autodesk eventually buy LL/SL and integrate some of its features? Who knows. But collaborative environment editing is the future so LL better get on the ball and position itself now before it's left in the dust like AW...

  
  

• primitives limitations (discuss): Why only primitives? Objects can be as simple as a single polygon or as complex as an infinite amount of polygons--it all depends on the modeller. But the problem with primitives is all of the wasted, covered polygons which unnecessarily contribute to decreased framerate. For example, butting up 2 cubes together covers 2 sides (4 polygons). Also, since 2 cubes are now together, their sides (2 polygons per face x2 = 4 polygons) can be reduced further (only 2 polygons), eliminating more polygons.

  Creating walkways (sidewalks, roads, paths, etc) by butting up cubes wastes a lot of polygons--and the undersides are usually unnecessary, too. SL can really start lagging with all of the wasted polygons and it would at least be nice to be able to delete and merge primitive polygons/faces/sides/whatever. Also, why no way to specify the number of sides of a primitive? Spheres, torii, cylinders, cones, etc are very wasteful of polys... Puzzles are fine but building LEGO-style is a very wasteful method of 3D modelling if it's not designed to be efficient and optimized for rendering.

  SL needs to optimize its primitive parametric modelling to remove hidden/covered sides/faces and allow for finer control over how many polygons a primitive can have--particularly for more complex shapes like spheres, torii, etc (and cuts/twists).

  Supposedly, SL is planned for an "ambitious overhaul of the primitive set" (Andrew Linden, 3/13/6).

  "Larger prims will not be happening soon." (Andrew Linden, 5/11/05) :/

• client-side vs. server-side: SL needs more client-side functions for most, if not all, functions. Not everything needs to be server-side. Everyone doesn't need to have everything in-sync with everyone else. Movement, rotation, scaling, prim parameters, sun/moon movement, lights, etc, could all be animated much smoother if client-side (and no stupid delays!). Active Worlds does this and it works well--and AW4 even has a new "global" command where everyone (in visible range, of course) sees/hears the same smooth effect. Interpolate server-side values so the client always sees things smoothly.

  
  

  particles particle editor: Scripting is fine but there's no reason a GUI particle editor can't be created. It would (optionally) automatically change the particles in real-time (since they are a client-side effect) when a parameter is changed without having to hit the "save" button all the time to see changes. However, saving the parameters would then upload them to the asset server (which is slower) for everyone to see. angle diagram: Because visualizing radian angles can be...annoying, a simple circle diagram shows the angle. Better yet, dump radians and just use degrees (but still keep the diagram). alpha/transparency fade in and out (vote, discuss): Particles should fade in and out without having to use scale tricks (since that restricts particle scaling). A new llParticleSystem constant, PSYS_PART_MID_ALPHA, could be added for the MIDdle alpha to allow smooth alpha/transparency particle fading both in and out. Separate fade in/out times (separate from particle age) would be cool too; Active Worlds has these parameters. middle scale: Like with alpha fading in and out, particles should have a PSYS_PART_MID_SCALE since only one of the scale parameters (PSYS_PART_START_SCALE and PSYS_PART_END_SCALE) can be <0,0,0> while the other can't be less than <.03125,.03125,0> or particles won't even render. Start/middle/end scale times would be great too. type: SL particles can only be one type: sprite (always faces the camera no matter what the angle). However, there are other types that can be supported (and that Active Worlds supports) like facer (similar to sprite but always faces the avatar, not the camera), flat panel (a depthless, 0-thickness plane that can be rotated into any position), and a model (prim/object in SL terms, that shouldn't count against parcel/sim prim count, of course, since particles only last a certain amount of time). use camera position: Center particles on each user's camera, like Active Worlds has: "Normally particles appear within a box as defined by the emitter's volume (see below). However, you may enable this option to move the spawning area from the emitter to the camera. The effect will be that particles will seem to come from all around the user, wherever they go. This is ideal for creating weather effects." (source)

• script editor: See UI.

• llTargetOmega synchronized rotation: Since this function is client-side, it quickly gets out of sync if the prim the script is in is selected (which can stop or slow the rotation, depending on which prim is selected) or if SL is minimized or the used switches to another app.

• general improvements
  ...more generalized clothes layers (so that avatars aren't limited to just undershirt, shirt, and jacket), better animation tools, better hair, and cloth dynamics. (Andrew Linden, 11/19/05)

• appearance
  • height: Avatar shape can't be under ~2m. Why? They should be able to go down to 0 and completely invisible if desires. Taller too.
  • cuff flare: Clothes > Pants > Cuff Flare isn't tight enough with 100 "Pants Length" (long) and 100 "Pants Fit" (loose). The cuffs are still too flared.

• attachments: more attachment points
  I think the attachment system is currently maxed out in its present design, but I suspect that Richard Linden has a plan for making it better. (Andrew Linden, ~9/18/05)

• camera issues: See Camera.

• unsitting: Changing clothes unsits an avatar.
  This is a bug... of sorts. What is really happening is that all modifications of the avatar go through a particular path in the code that also tries to rescale the avatar's size. The reason all of the avatar changes are grouped together in one spot is that back in the day we didn't have drag-and-drop outfit changes -- the only way to change your clothes was to go into Appearance Edit mode. Since you can change your size in Appearance Mode and back then we didn't have code to handle resizing the avatar while it is sitting you would be forced to stand first.

  It is fixable. We'll try to work it into the schedule. (Andrew Linden, 6/7/05)

• decentralized grid
  As to hosting simulator engines on private hardware, I think that will happen, but it is one of those things that is years away. All of this other stuff (MONO API, data-driven UI) has to happen first and most people don't have enough outgoing bandwidth to support their own sim today anyway but you can be sure that the bandwidth capabilities will happen. Trusted protocols will be needed. We do have plans to decentralize SL. We only have so much room in our colocation facility and there aren't many colos bigger than the one we're in. (Andrew Linden, ~9/18/05)