[Opensim-dev] Asset Referencing [Was: UUID]

Melanie melanie at t-data.com
Tue Jun 24 12:16:38 UTC 2008


I'm totally inside the SL box in respect to the user/creator experience. 
I am expecting large amounts of products to come to OpenSim, and those 
creators don;t want to relearn things.

Great if we find a way to solve problems differently and better than LL 
did, behind the scenes, but I'm s strong proponent for keeping the user 
experience for users of the SL viewer 100% compatible.

Meaning, no script changes, no new fields. Nothing to confuse creators 
who already ask "Why should I go through all this effort just to bring 
my products to your grid?"

These agreements/alliances are fragile already.

Again, the potential loss is not comparable to the cost of a few more 
gigs of storage.

Melanie


Stefan Andersson wrote:
> Um, still thinking inside the SL box...
>  
> Whenever an object is 'cloned' as in given or sold, the references can go with it, but the references doesn't necessarily have to be part of the inventory.
>  
> So, the content producer can establish 'soft references' to the objects that his script would be able to reference (how this would be done in the viewer gui, I don't know - but thinking outside the box, Tribal Net has a separate management gui - or maybe an OSSL command like 'UsingAsset'?) that would be copied to each clone of the object.
>  
> So, every object would then have a reference list to all 'possible' references without actually having them in object inventory.
> Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 
> 
> 
> From: stefan at tribalmedia.seTo: opensim-dev at lists.berlios.deDate: Tue, 24 Jun 2008 11:11:06 +0200Subject: Re: [Opensim-dev] UUID [Was: Proposal to eliminate the name, description and invType fields from the
> 
> 
> Actually, no. What I meant was that in that case, the _content_creator_ would have to have the items in his inventory (and probably set to something like 'anyone can copy'... ;) )The moment he takes them out of his inventory, they are gone. Which, incidentally, probably is the kind of control you'd want anyway. If you want some kind of 'system' assets, they could be given to a system user. Continuing on the 'detailed keeping track' the _scripted_change_ would also update the references, so that the object itself would then keep a reference to the texture. By the way, the same track-keeping thing would go for objects; that would mean that the moment a user is gone, truly unused objects can be reaped from assets and inventory. This is not proposing a solution, merely trying to think outside the SL box.Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 
> 
>> Date: Tue, 24 Jun 2008 10:09:34 +0100> From: melanie at t-data.com> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] UUID [Was: Proposal to eliminate the name, description and invType fields from the assets db]> > Hi,> > Stefan Andersson wrote:> > Hell, in that scenario we could even say 'you can't reference an asset > > you, or an object of yours, do not have a reference to' - which will > > probably make SL-molded content producers wet their pants.> > That would mean that if I make a texture-changing bit of furniture, > I would have to pack all textures into it's inventory? Content > creators are at the moment extremely happy to not have to do this! > The ability to reference textures and sounds by UUID is a > fundamental one, removing it would break every texture-changing > object and every fountain and door (since they don't contain the > actual sounds, either)> > Melanie> > _______________________________________________> Opensim-dev mailing list> Opensim-dev
@lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev



More information about the Opensim-dev mailing list