OpenSimulator:Future Release Discussion - Revision history

LaeMing: Some additional ideas on 3D security.

2014-06-10T10:26:58Z

Some additional ideas on 3D security.

LaeMing: feature provided by hypergrid - request cleaned from proposals page

2014-06-09T05:00:51Z

feature provided by hypergrid - request cleaned from proposals page

LaeMing: feature request covered by hypergrid and above portal-prim request. Cleaned from request page

2014-06-09T05:00:12Z

feature request covered by hypergrid and above portal-prim request. Cleaned from request page

LaeMing: feature provided - request cleaned from proposals page

2014-06-09T04:58:12Z

feature provided - request cleaned from proposals page

LaeMing: /* One known Client issue */

2014-06-09T04:54:15Z

‎One known Client issue

LaeMing: /* Grid to Grid Travel */

2014-06-09T04:50:47Z

‎Grid to Grid Travel

Makopoppo at 10:46, 4 June 2011

2011-06-04T10:46:28Z

LaeMi: Suggestion removed by proposor as current development (arbitrary-sized regions) nullifies the need in her case (if someone still desires this, reinstatement and taking over ownership OK)

2009-08-08T21:53:56Z

Suggestion removed by proposor as current development (arbitrary-sized regions) nullifies the need in her case (if someone still desires this, reinstatement and taking over ownership OK)

LaeMi: Cleanup: Remove item "Arbitrary Region SIze" as it is under development right now

2009-08-08T21:48:37Z

Cleanup: Remove item "Arbitrary Region SIze" as it is under development right now

LaeMi: Feature suggestion for different avatar physics behaviour when below sea level.

2009-01-24T05:20:52Z

Feature suggestion for different avatar physics behaviour when below sea level.

← Older revision		Revision as of 10:26, 10 June 2014
Line 14:		Line 14:

	One security feature, is the ability to "hide" objects within a security region from users that don't have access rights. Much like barriers in SL, these 3D security regions would just not show up in the viewer, and the user would not have rights to enter the area. It would interesting if you could do this on a primative level, an object that is only viewable by people/objects with the proper permissions. (The engine could detect collision based on bounding box)		One security feature, is the ability to "hide" objects within a security region from users that don't have access rights. Much like barriers in SL, these 3D security regions would just not show up in the viewer, and the user would not have rights to enter the area. It would interesting if you could do this on a primative level, an object that is only viewable by people/objects with the proper permissions. (The engine could detect collision based on bounding box)
		+
		+	LaeMing adds:
		+
		+	An alternative might be to add volume-based permissions to prims themselves, so - for example - you could define a transparent phantom prim, and anything spacially within this prim is subject to its security settings (can enter space, can see/interact-with contents, etc.). This would allow arbitrary sized/shaped security regions (I often would like to use cylindrical/spherical security zones, given the chance!).

	== Portal Primatives ==		== Portal Primatives ==

← Older revision		Revision as of 05:00, 9 June 2014
Line 51:		Line 51:

	Useful in adding a max ceiling to a region. If it was possible, ability to create a "region box" with as stated earlier, an arbitrary origin. Thinking a little further, a "region sphere" would be interesting.		Useful in adding a max ceiling to a region. If it was possible, ability to create a "region box" with as stated earlier, an arbitrary origin. Thinking a little further, a "region sphere" would be interesting.
−
−	~~==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.

	==Universal Location Addressing==		==Universal Location Addressing==

@@ Line 47: / Line 47: @@
 * 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.
 * [http://www.softec.st/en/OpenSource/ClrProjects/SubversionSharp/SubversionSharp.html SubversionSharp]
 ==The ability to set region bounderies==

@@ Line 29: / Line 29: @@
 == Payment System ==
 OpenSim will need to support micropayment. See [[Money]] for details on how this could be achieved.
 == Free-form Avatars ==

@@ Line 131: / Line 131: @@
 * 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.
 ==Client Side Weather System==

← Older revision		Revision as of 04:50, 9 June 2014
Line 62:		Line 62:

	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.		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.
−
−	LaeMi adds - I am waiting eagerly for integration of realExtend's avatar server which should cover this - the graphics enhancements of rex are of less interest to me as I am not a 3D designer and so have limited use for meshes, but rex has a good number of other very useful features like this too. (Rex integration is being worked on right now AFAIK).

	==Universal Location Addressing==		==Universal Location Addressing==

@@ Line 25: / Line 25: @@
 == Scripting ==
-See the list of [[LSL_osFunctions|OSL Proposals]].
+See the list of [[OSSL Proposals]].
 == Payment System ==

← Older revision		Revision as of 21:53, 8 August 2009
Line 91:		Line 91:

	The client can then get the required information regarding port numbers, protocols, and so on from SVR records embedded in the FQDN DNS Zone. This way clients are immune to changes in the physical hosting of the simulators. The data encoded in the SVR record could also give clues as to the protocol versions, abilities and restrictions of the destination. -Kelannim		The client can then get the required information regarding port numbers, protocols, and so on from SVR records embedded in the FQDN DNS Zone. This way clients are immune to changes in the physical hosting of the simulators. The data encoded in the SVR record could also give clues as to the protocol versions, abilities and restrictions of the destination. -Kelannim
−
−	~~==Macro-level (Grid-wide) location Coordinates==~~
−
−	A set of OS-functions that work just like llSetPos, llGetPos, etc. but use 32-bit coordinates. The low-order 8 bits get used as intra-sim coordiantes as per usual, the high-order 24 bits determine which sim on the grid is being referred to. Some extra commands like osCoord2Key to get the key of the region containing the coordinates, osCoord2Name, etc. are possibilities.
−
−	*Minor modification, have the int read as 16bits=region_coords, 8bits=sim_coords, 8bits=sim_sub-coords. To paraphrase Mr. Gates, 64k sims in each direction should be enough for anyone ;-P

	==Scriptable 'bodyparts' (Shape, Hair, Eyes etc)==		==Scriptable 'bodyparts' (Shape, Hair, Eyes etc)==

← Older revision		Revision as of 05:20, 24 January 2009
Line 191:		Line 191:

	Texturing as per sphere/cylinder/torus, so this does not - even if maxed out to be sharp-edged - replace a real box which can have one texture per face.		Texturing as per sphere/cylinder/torus, so this does not - even if maxed out to be sharp-edged - replace a real box which can have one texture per face.
		+
		+
		+	==Simple Underwater Avatar Physics==
		+
		+	Simulator physics '''option''' for:
		+
		+	When Avatar_position+(Avatar_Height/2) (ie. their head) is below simulator water level, they are put into fly mode. When they are more than Avatar_position+(Avatar_Height/3) (approx shoulder level) below simulator water level, they get a low positive gravity value (buoyancy) applied to them (use the page-down key to swim down against it). 'Swim' into waist-shallow water and Page_Down into land to stand again. No special client-side swim animations, etc. - they would be nice, but fly mode animations are good enough for a start and don't require client-side changes.
		+
		+	(Yes, it can theoretically be done with scripted attachments, but I prefer the efficiency of the physics engine doing it directly).