*>I believe Stefan made a tool to split Mega's up into normal OAR's* --- In fact, Stefen suggested the idea and changed its ZOE Zonja to version 2.0, tu support megaregions ( http://zonjacapalini.wordpress.com/2010/02/13/splitting-megaregions/) >*Any ideas as to how terrain files will be stored in the next version of OAR? One big r32 file with the terrain data for the whole Mega region? Or break it up and store the individual terrain files for each region?* ** *--- *That depends on whether the viewer the option of state / regions, to edit textures in altitude for each region or only for megaregión, (I say thinking Naali). If you only allow editing for all megaregión, not much point in breaking the ground for each region, I think. If we think in other viewrs, the "hybrid" system is a nice option.
--- About the numbering and characteristics of the new version of the OAR and what is doing Adam about the the new refactoring, and the newer format, i'm sorry but I haven't any information. Alberto 2010/2/16 Mark Malewski <mark.malew...@gmail.com> > > *> I suppose than **be conducted **cleaning and, perhaps documentation, * > > Yeah, OARS certainly needs some "cleaning" and I'm glad to see that it's > being refactored. Once it's done, I'd be more than happy to help with the > documentation and tutorials. > > *> The main obstacle in Opensim for the proper functioning of OARS is > that * > *> the SceneObjectGroups has a lot of code garbage accumulated in the* > *> actual format* > > Does the current OAR file structure even properly support Mega Regions? > Can you even rebuild a MegaRegion stored in the current OAR format? I > believe there are still some issues with the terrain files, eh? > > I believe Stefan made a tool to split Mega's up into normal OAR's, but yes > there are quite a few "issues" that still need to be addressed with OAR. > > Any ideas as to how terrain files will be stored in the next version of > OAR? One big r32 file with the terrain data for the whole Mega region? Or > break it up and store the individual terrain files for each region? > > Or create some "hybrid" system that stores BOTH (the mega region terrain, > and the individual region terrain files)? Then just use one or the other, > depending on how the OAR is used? (i.e. If using MegaRegion, then use > MegaRegion terrain if it's present, if not then use the individual region > terrains?) > > So will this refactoring lead to a completely new OAR version? An "OAR > 3.0?" (a new third generation version of OAR). > > As Adam gets closer to completing the OAR refactoring, let me know all the > changes and I'll begin to update the documentation for it. I'd like to > create an updated User Guide for OAR 3.0. I have a very old OAR User Guide > laying around somewhere (that is still based on the original OAR 2.0) and it > would be good to sit down and completely update/rewrite the guide based on > the new OAR 3.0 changes/updates. > > I believe it would a useful document for both OpenSim and RealXtend users. > I would just need to know exactly what is changing, and what commands are > being changed, and also what tools exist (currently) for OAR editing, etc. > > Whoops, I guess it's 0.2 (not 2.0). So will this new version be a 0.3? > Shouldn't we use whole numbers when we make such large changes to the OAR > structure? (like use a 1.0, 2.0, 3.0 for major revisions?) the use > incremental numbers (3.1, 3.2, 3.3) for minor updates? > > http://opensimulator.org/wiki/OAR_format_0.2 > > Do you have any information on the new refactoring, and the newer format > that Adam is laying out? We may need to create an OAR_format_0.3 page (just > copy the 0.2 page and use it as a template for the 0.3 page, and then just > use it as a temporary "scratch page" as we document changes, so we at least > have something for when people ask about the new format. > > Is OAR 0.3 scheduled for OpenSim 0.7 RC? or maybe OpenSim 0.8 RC? Any > ideas as to how long the OAR refactor will take, or when/what version it > would be implemented into? Do you have any details about the new OAR 0.3 > structure (and any command changes?), or is it simply all in the "early > planning" stages? > > Mark > > > On Mon, Feb 15, 2010 at 5:52 PM, Gustavo Alberto Navarro Bilbao < > sombra.albe...@gmail.com> wrote: > >> The main obstacle in Opensim for the proper functioning of OARS is that >> the SceneObjectGroups has a lot of code garbage accumulated in the actual >> format, and needs a good cleaning. Now than Adam Frisby is going to start >> to change the refactor, I suppose than be conducted cleaning and, perhaps >> documentation, >> >> Alberto >> >> 2010/2/15 Mark Malewski <mark.malew...@gmail.com> >> >>> >>> *> We haven't done a quick fix for that now, because the whole scene >>> code* >>> *> and how they are saved to OARs etc will change in the refactor that >>> Adam* >>> *> F. is starting* >>> >>> We definitely need an improved "OAR+" or next generation OAR format for >>> RealXtend + OpenSim. Also can we make sure that scripts (assigned to >>> objects) in both OpenSim and realXtend are saved as part of the OAR+ format >>> as well? >>> >>> This way users that load up OAR's from other people don't have to worry >>> about any missing script problems, or "broken scripts" in saved/loaded >>> OAR's? A lot of users had been complaining about loading up saved OAR's and >>> having their scripts missing/broken from the OARs (scripts not assigned to >>> the objects in-world). Not sure if scripts are not saved (per object) in >>> the current OAR format, but it would be good to make sure that ALL scripts & >>> settings assigned to a particular object are properly saved and properly >>> assigned to individual objects in the new OAR+ format. >>> >>> Mark >>> >>> >>> On Mon, Feb 15, 2010 at 6:15 AM, Toni Alatalo <ant...@kyperjokki.fi>wrote: >>> >>>> On ma, 2010-02-15 at 12:18 +0100, Gustavo Alberto Navarro Bilbao wrote: >>>> > Would it be possible for the OAR than work with meshes?. It would be >>>> >>>> Yes, there are not many things that are alltogether impossible in >>>> software :) >>>> >>>> We haven't done a quick fix for that now, because the whole scene code >>>> and how they are saved to OARs etc will change in the refactor that Adam >>>> F. is starting / has recently started(?) for OpenSim core, exactly to >>>> get new features like rex data better integrated. I think in that new >>>> component model the components are responsible for telling how they >>>> should be saved etc., and that OARs would then work for the components >>>> that implement the rex data too. That should start happening within some >>>> months now. >>>> >>>> A quick fix before that might be quite simple, but is not planned now. >>>> >>>> ~Toni >>>> >>>> >>>> -- >>>> http://groups.google.com/group/realxtend >>>> http://www.realxtend.org >>>> >>> >>> -- >>> http://groups.google.com/group/realxtend >>> http://www.realxtend.org >>> >> >> -- >> http://groups.google.com/group/realxtend >> http://www.realxtend.org >> > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org > -- http://groups.google.com/group/realxtend http://www.realxtend.org
