[Opensim-dev] Ways to bundle a building/content for sharing with others

Mo Hax imohax at gmail.com
Sat Jan 10 17:13:20 UTC 2009


+1 Ai, we need a improved way to save reusable, complex content in singular
files that can be passed between sims. Whatever results from such an effort
will likely play nicely into REST transfer of such things between OpenSim
grids.

Up to now the methods you describe are the only methods and do not allow the
casual OpenSim user any way to put such content into their inventory
requiring, instead, sim administrator intervention. I think that will remain
that way for some time to come because anything else requires some sort of
viewer customization.

I know others have created LSL scripts to transform XML from a notecard into
an in-world object like some of the SL tools available for sale do. So far I
know of none that actually use save-xml, xml2, oar output however.

One approach I have been meaning to explore, but have lacked the time and
skill, is creating an OpenSim module or special scripted function that would
accept XML from xml, xml2 or oar as input, perhaps even directly from a
notecard (but that could be a lot of dataserver hits) and automatically
build out the represented object in world. In fact, there is already a
suggested OSS function to do this from a URL pointing to such XML:

osRezFromURL(string url, vector pos, vector vel, rotation rot, integer
param)

A whole family of osRezFrom*() functions would perhaps be best, each with
different imposed lag penalties to avoid overloading XML sources. I cannot
see such functions, with the parsing and possible network calls, ever being
used to rez objects more than once every 0.2 seconds, the usual delay for
similar things in LSL. Maybe something like the following:

osRezFromXML(string xml, vector pos, vector vel, rotation rot, integer
param)
osRezFromXML2(string xml, vector pos, vector vel, rotation rot, integer
param)
osRezFromOAR(string oar, vector pos, vector vel, rotation rot, integer
param)

I admit I like rez from URL best in the long run since it takes care of the
ugly issue of getting the XML/XML2/OAR into the string argument in the first
place, too many dataserver calls to read such a thing from a notecard I
would think. But before layering all the network fetching code having a
function that simply does the parsing and rezzing would be work enough to
write.

On Sat, Jan 10, 2009 at 6:34 AM, Ai Austin <ai.ai.austin at googlemail.com>wrote:

> This might be a question for Justin as he has worked on the OAR
> mechanism and load/save-xml console commands....
>
> It would be useful to be able to take some content, such as  a
> building or developed area, and to be able top save that in a  form
> that can be downloaded or shared with others to get the same content
> in heir own opensim setup.  save-xml, save-xml2 preserve the whole of
> a sim region keeping creatorid, ownerid, lastownerid and prim uuids
> as they were, and save-oar pr serve the whole of the contents of a
> sim region including the terrain height map.
>
> The mechanism I have used to make a building available to different
> Opensim setups, or in different areas of our own build is to use one
> of two mechanisms...
>
> a) save-xml on a sim region that ONLY contains the required content
> (I use a sandbox region just for this purpose), and note how many
> prims were in the region as a check.. I edit the creatorid, ownerid
> and lastownerid manually (i.e. change UUID for 3 X number of prims).
> Then on restore I use the load-xml with -newuid flag to ensure new
> UUIDs are used for the newly loaded prims.  I then check the required
> number fo saved prims did come back in.
>
> b) save-oar on a sim region that ONLY contains the required content
> (I use a sandbox region just for this purpose).  load-oar into an
> empty sandbox region (as the terrain will change).  Then take the
> contents into inventory - with the disadvantage that relative
> positioning of parts is lost.  or link teh whole build and take into
> inventory to be moved where you wish with the disadvantage that major
> linked parts in a modular build are lost.
>
> As you can see, the save-xml and save-oar are VERY clise to what is
> needed, but are really for archiving within one Opensim set rather
> than transfer of modular assets to others.  I think a mechanism to
> save-oar with a  flag to say -noterrain, and/or a mechanism to
> load-oar -noterrain that can ignore any terrain included in the
> OAR  and a way to say -add so that the objects in te oar are added to
> the current region, rather than everything being replaced would be
> close to what is wanted.  A way to make sure that all UUIDs in the
> new content are suitable for the target environment (Prim UUID,
> texture UUIDs, creatorid, ownerid and lastownerdid) may be needed if
> the OAR mechanism does not already do that.
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>



-- 
Mo Hax
http://imohax.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090110/3d8d196f/attachment-0001.html>


More information about the Opensim-dev mailing list