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

[Mo Hax]

In fact, I wonder if maybe we should at least look at serializing content in
JSON instead of XML. We already have JSON parsing thanks to Rob Smart. That
would be two thirds of the work already complete:

1) Fetch the JSON text with an HTTP request
2) Parse JSON with existing function
3) Rez objects with properties and location

But it might be a wash, since that would mean coming up with the
osObjectToJSON() functions or equivalent console command, maybe 'save-json'

Does this approach even have enough merit to consider? If so, maybe I will
make it something to look into in 2009.

On Sat, Jan 10, 2009 at 12:13 PM, Mo Hax <imohax at gmail.com> wrote:

> +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
>



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