We need to do something new because of all the metadada associated
with this kind of content, but we don't need to reinvent the wheel
from scratch:
http://linuxcommand.org/man_pages/tar1.html
There's more options in tar than one would care to implement here, but
they are certainly a good starting point. The main difference is that
files don't have a whole lot of metadata, therefore tar is relatively
light in terms of filters. But it does have the --exclude=PATTERN
which is very rich.
On Nov 27, 2009, at 4:49 AM, Len Brown wrote:
I totally get the z1 to z2 approach. I had a situation a while back
where I'd been doing a lot of experimental building up around 3,000
to 4,000 meters and had kind of forgotten about that stuff up there
and focused on some ground-level builds. Well, when I made an OAR I
thought it was a bit big and then remembered the 5,000 or so prims
I'd "abandoned" up above. If I could have just backed up a certain
elevation section then I could have backed up the stuff on the
ground and left the other stuff up above out of the backup. Would
make for a much cleaner and consistent restoration in a new region
later.
So definitely +1 to the idea of backing up based on Z coords, if
that is at all a possibility for future consideration...
- Len W. Brown
[email protected]
On Fri, Nov 27, 2009 at 5:47 AM, Zonja Capalini <[email protected]
> wrote:
A cool use case that comes to my mind immediately (but I don't know
whether it's easy or not :-)) is
the relocation of airboxes. I remember having to relocate a 10000+
prims airboxed city in SL,
and it was a real pita. Moving all objects manually was out question
because it would have been
too time consuming, and mass-selecting 10000 prims is buggy, to say
the least -- additionally,
the viewers are very stupid in that respect, because mass selection
does not select Linden
plants and trees. I ended up by mass-selecting anyway, then manually
moving up the
airboxed city (which caused of course incredible lag), and then a
lot of smaller objects
had escaped the selection and had to be moved manually, etc.
It would be great if the load/save oar pair would allow for the
following:
1) Saving everything in a sim between z1 and z2 meters (effectively
storing one aixbox
level only), and
2) Load the previous oar with an offset of z3 (i.e., all objects
would get their previous
z plus z3, which could be positive or negative).
As I mentioned previously, I don't know if this falls under the
"easy" case category or not :-)
Indeed, once one starts to think in the direction of saving anything
less than a whole
sim, the relocation problem appears immediately. What if I save a
building in a partial
oar but I want to have it load-merged in a different position? Of
course this can also
be done with linksets, but large linksets tend to be unmanageable --
or with coalesced
objects, but the same problem applies, and besides they are not
currently implemented
by Opensim. I think partial oars can fill a hole here, but at the
price of implementing
relocation in the load-merge operation (and possibly some form of z-
rotation too).
/Zonja
On Thu, Nov 26, 2009 at 9:12 PM, Justin Clark-Casey <[email protected]
> wrote:
Cool easy things with real world use cases get highest
priority :). And of
course it's all dependent on what time I have available :)
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
