On Sun, Aug 12, 2018, at 11:03 AM, Haravikk wrote: > > > > On 12 Aug 2018, at 09:52, Luisillo Contepomi <[email protected]> > > wrote: > > > > When you build a cube in a region and after you delete de cube will > > remain in database forever or until you erase it manually > > > > Best regards, > > Luisillo > > I don't believe this is quite true; when you create an object in a > region it exists only within the region where it is located, if you > "delete" it then it is transferred to your inventory, if you then delete > it from your inventory as well then it should be gone for good.
You believe, or you know? In technical fields, the difference can mean everything. > When you > rez an object in a region you are actually copying it, as each copy gets > its own UUID. In this sense pure objects (no contents) are nothing but > copies, so they only occupy space for as long as a copy exists in world, > or in inventory, once those are gone, the object is gone forever. I know about copies, yes, thanks. > > Where assets get tricky are things like textures, sounds, animations, > notecards and scripts*; these are applied to objects by GUID and fetched > from the asset server when needed, so even if you delete an object that > contains your only references to these items they don't immediately > disappear but instead remain on your asset server, because figuring out > if an asset is indeed unused at this point is difficult (it would > require a huge amount of extra callbacks to the asset server to keep > track of new/deleted references and would go out of sync if a region > crashes and is restored from backup). Here I think I can see the difficulty. I'd have to strain my brain to really understand it, though. Maybe I'll chart it out on paper or something. > > The problem with trying to flush them out is that even if an asset is no > longer linked directly to an object or present in a user's inventory, it > is still possible for a script to reference them by GUID. Using vanilla > LSL for example it is possible to apply textures, trigger sounds and > fetch notecards using a GUID. Um... this is where I think the OpenSim project should have taken the position, "UUIDs alone are unreliable." In Second Life in 05/06, I remember concluding that if you want a scripted item to last, you should put everything it needs into the object itself. My conclusion was perhaps bourne out 2 or 3 years later, when teleporters scripted to use the UUID of a TV-snow texture made by Cubey Terra were found to be blank instead. What about the hypergrid, will an asset keep the same UUID when transferred? > > The only way to safely flush out textures, sounds and notecards (and > animations if you allow GUID fetching of these) would be to scour every > object, script and notecard on your grid for possible GUIDs, but even > then this is only safe if you don't allow scripts to contact external > services (as a user could store GUIDs in an external database for > example). The relatively popular Boehm garbage collector for C and C++ can operate in exactly this way, but I'll admit that a grid database is an awful lot bigger and slower than the memory of one computer program. > > This is I think why in SecondLife it costs L$10 per upload, as it stops > users going overboard with uploads, this is also the reason why images > are stored at limited sizes, sounds and animations are limited in length > etc. Hmm. The upload fee was explained as, "An economy needs sources and sinks. The upload fee is one of the sinks." They may have had multiple reasons, I suppose. All the other limitations might be explained as trying to limit their bandwidth. Textures have the additional problem of taking up memory in the graphics card, a big problem in the early '00s as graphics cards had relatively little memory couldn't decompress images on the fly. It may still be a problem: a 2GB graphics card can be a big help, but that might be some other factor. > > At the end of the day though the question is; how limited is your > storage really? The only cost of unused assets is in a bit of wasted > hard storage, but storage is pretty cheap, so unless your grid is > growing beyond your ability to match it then you might be trying to > solve a problem where the solution could be more destructive than the > problem itself 😏 I'm told that by the end of InWorldz, its asset server was growing by a terrabyte every month! There's nothing "more destructive" about trying to limit that kind of growth! > _______________________________________________ > Opensim-users mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users -- The lyf so short, the craft so long to lerne. -- Chaucer _______________________________________________ Opensim-users mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
