>I said "I believe" I've tried it and it seems to work as you explain. ;)
2018-08-12 21:31 GMT+02:00 Haravikk <[email protected]>: > >> On 12 Aug 2018, at 16:58, Ethan A. Gardener <[email protected] >> <mailto:[email protected]>> wrote: >> On Sun, Aug 12, 2018, at 11:03 AM, Haravikk wrote: >>> >>>> On 12 Aug 2018, at 09:52, Luisillo Contepomi <[email protected] >>>> <mailto:[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. > > I know. > > I said "I believe" because I was trying to give the benefit of the doubt, as > what Luisillo said can be true, especially of other asset types, but isn't > always true of objects in particular. It is for possible for a cube to never > become an asset, for example if the region it is in crashes without saving, > or is deleted without returning anything to user inventory, all such objects > simply cease to exist. Any textures applied to those objects however would > remain in the asset server. > >>> 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." > > While I kind of agree, it would mean a pretty big departure from vanilla LSL > which OpenSim was being made compatible with at the time. I mean you could > reasonably argue OpenSim should never have tried to support LSL in the first > place since it's a terrible language that never should have been in Second > Life either, but what's done is done! > > That said, I wouldn't say UUIDs are unreliable, just that you need to know > when it's appropriate to use them; they're fine for non-transferable objects > so long as the asset exists in an object/user inventory somewhere, i.e- you > shouldn't use the UUID unless you know where the asset it references actually > exists, and you shouldn't at all for anything transferable that could end up > on another grid. > > Cases where referenced assets have vanished on SL were I think times when LL > were trying to solve the exact same problem, and hadn't considered scripts > references at all, but LL and a lack of thought given to scripting has been > the status quo from day one 😏 > >>> 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. > > Yeah, you'd have to inspect every single script and every script VM in every > single inventory, object inventory, and in world object inventory in every > region on a grid, and even then some regions could be offline (e.g- OS Grid > where you can join or leave at any time). If you're certain that you don't > need to preserve such items, or the problem is bad enough that you don't care > to, then it's reasonable to skip such a step; I was just trying to highlight > why an asset can exist in the asset server without existing in an region or > inventory, and still be unsafe to delete. > >>> 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. > > Sure, it's not the sole reason, but even a price as low as L$10 is a > deterrent to uploading things excessively. It's essentially the same > principle as charging 5p for plastic bags to cut down on plastic bag > pollution, it's not much but it's surprisingly effective. > >>> 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! > > Is this such a case though? > > Even so, asset cleaning isn't really going to limit that kind of growth much; > unless a grid is accumulating a similar amount of unused assets each month > then at the end of the day you're still talking about a huge volume of new > assets being the real problem there. > > At that kind of level though, 1tb a month is 12tb a year, a 12tb hard drive > is around $400 now. With the right kind of setup it wouldn't cost a lot more > than that to add storage, or swap older drivers for newer, larger ones to > keep ahead of it. Not ideal, and you'd better hope someone's helping to cover > those, and other costs, but it doesn't have to be the end of the (virtual) > world. 😀 > _______________________________________________ > Opensim-users mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users _______________________________________________ Opensim-users mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
