OpenSimulator:Future Release Discussion

Revision as of 05:19, 12 March 2008

A collection of ideas for additional functionality in OpenSim. Please add your thoughts - anyone may contribute.

3D grid structure

I have always wanted to see a grid where you could have regions not only to the north, south, east west of a region but also above and below. This would enable space above for orbiting space stations and the like and depth below for underwater worlds and tunnels. - Garth FairChang

Scripting

See the list of OSL Proposals.

Payment System

OpenSim will need to support micropayment. See Money for details on how this could be achieved.

Upload of existing 3D models

OpenSim should support common standards for 3D modelling. This would allow the upload of existing 3D models and make OpenSim immediately attractive for architects and project developers and their customers (walk through models).

Free-form Avatars

OpenSim should, at some point in time, support the design and animation of free-form avatars (e.g. animals, monsters, robots).

In-World console maintenance

Terrain manipulations, statistics and some SIM administration related tasks are not available using the Viewer - they are only available on the command line application console where OpenSim is running. It would be nice to have this same console available in-world, using an Instant Messaging window with the simulator itself, the same way as we do with thoses old command line terminals.

Externally Scripted Objects

A prim with the script contents something along the line of //external:somehost:someport. Have the simulator connect to this host:port and relay data from it to the prim. Example, have a simple library that maps the LSL functions to a simple binary protocol, which can be used from various programming languages, not neccessarily .NET, and have it act like a server. This would allow scripts to be hosted outside the Simulator while adding security, as no code would be running on the Simulator. People could code Prim scripts using C if they wished, and the library would simply send the LSL commands to the server for relaying to the clients. If this could go straight to the client then even better. The next step after that would be for the script to be able to send Prim data aswell. This also gives the possibility of using one running script on several different Simulators at once. - HashBox

Object Inventory Source Control

• This wish list feature starts with the premise that "I HATE working on scripting and objects within SL". Basically, allow users to checkout an object and its contents to an SVN repository. Work on the object and contents locally in whatever application they wish. Later, they can checkin the changes, and update the object inside the simulator.
• SubversionSharp

Arbitrary-sized regions

I am thinking stand-alone regions here, though being able to set a single arbitrary size for all regions on a particular grid might be useful to some (or rowspan and colspan-like attributes in the region table if someone was feeling really masochistic ;-).

Would require much client-side work too as the 256m sim-size is hard-coded in many places I believe (Rob Linden was lamenting this decision in a blog some time back and talking about slow steps to replace the hard-coding as bits of the client/server code came up for review as a matter-of-course, IIRC). Some of the quick positioning client-server comms protocols are probably byte-dependent too. Any ideas? ;-)

Very useful for my own free-standing simulator as I want a lot of area but not much built on it, and would rather avoid the inter-region comms overheads if possible.

Arbitrary origin would be nice too, so I could set (x,y,z:0,0,0) at the middle of my sim on sea level making my maths for several things I plan much simpler (yes, I want I want I want the whole world - and sundry satelites thrown in too!!! But not in any hurry ;-)

Tide Server

It might be interesting to support tides in OGS. It should be doable without any mods to the SL client and probably wouldn't be even a big project (possibly a good teeth-cutting project for someone who wants to get into OGS server coding but isn't confident to tackle parts of a big or critical server component).

A few things to consider:

• The tide server just periodically updates the water level in a grid's sims.
• Would need to be grid-wide or dis-synchronised tides would have ocean-edge alignment issues (so no rolling tides across huge grids, sorry) so it would be a server operating at the grid level talking to regions.
• Needs to be over-ridable as inland regions often use water level for things other than ocean and wouldn't want to follow the tides.
• By using plug-in servers, different complexities of tide can be implemented depending on grid needs.

Some example tide servers

• Null tide - simply a way to globally set sea-level in a grid. Takes a single sea-level value.
• Simple Periodic - set the max, min and period and starting time values and let it roll.
• Sun (and moon) locked - uses the position of the sun/moon to place tides realistically (presently rather easy as the sun and moon are always 180deg apart, but they might get unlocked from eachother later, extra suns/moons might also crop up long-term - presently it would be the same as Simple Periodic, but time-synced with whatever the day cycle is). Can day-cycles be enforced (or at least a default set) region-wide? Otherwise this would not be feasible.

SL Client compatibility

When the client sends a water-level request to the region, the region does one of two things:

• if the water level is -32768 (assuming this value is stored as signed32) or 65535 (if it is a u32) or whatever represents the most 'insane' value possible, then the region refers back upstream to the grid tide server, gets the present tide level, and returns that (sane) value to the client.
• if waterlevel set for the region is in the 'sane' range, that (region-local) value is returned without referring to the tide server.

(A region-server console command to set the water level outside what the current SL viewer allows is assumed).

Updating the tides.

(I assume the region is capable of informing attached clients when water level changes so that on-the-fly changes by region admins are reflected reasonably immediately in clients already).

• tide server periodically multicasts a tide update signal to all regions.
• if the region water level is in the 'insane' setting, it passes the update on to the attached (and neighbour-attached) clients.
• if the region water level is 'sane' it does nothing, leaving the region-manager's water-level alone.

One known Client issue

The 'extended' water off the edge of actual regions is a problem, as this is probably hard-coded into the client. Probably should have its own setting which can be either fixed per grid (or region for stand-alone) or track the tide server as per region water level.

Grid to Grid Travel

Going to each grid seems to require setting up an account there. Someone may specialize in 'passport authentication' allowing an avatar to hop from grid to grid (possibly with just a wallet and a small 'suitcase' inventory) as one would go from country to country in rl. Grids get control of who and how may pass through their grid.