Mo Hax 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.
Yeah, this is a weakness of inventory archives, though of course there are out of band ways of getting around it (upload via a website, etc.) > > 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) I think that this is a neat idea Mo! It's kind of the 3d equivalent of displaying a web page in-world - point your script at an url and rez whatever 3d objects it describes instead. Oh, and probably highly dangerous in any public world :) (and hence would be marked as highly hazardous) but might allow some cool stuff in more controlled environments. > > 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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > -- > Mo Hax > http://imohax.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev -- justincc Justin Clark-Casey http://justincc.wordpress.com _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
