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

Tue Jun 24 13:34:50 UTC 2008

Hi,

please note, I didn't say "Be 100% SL compatible"

I said "Create a 100% SL compatible user experience for _users of the SL 
client_"

It leaves all avenues to do things differently internally, and expose 
things in different and more sophisticated ways to users of other clients.

That is an important distinction. It just means we should not make it 
impossible to _mask_ things to the SL client, so that the SL client user 
experiences OpenSim like he experiences SL.

Melanie

Stefan Andersson wrote:
> Oh, sorry; I meant _I_ was still thinking inside the box - I replied to my own post. But now I remember we had that conversation before.
> Of course, keeping track of references is an added burden, but again, what is the actual use case(s) we're trying to solve here?
>  
> In the case of that tree and of the content creator, there are solutions, of course. The question is whether it's even worth trying to find a solution for it.
>  
> And, why should we go with how SL worlds are built up in regards to prims/parcels/regions/assets - much of how the SL virtual world looks like today stems from that particular business/incentive model - something that simply won't apply to a lot of OpenSim cases.
>  
> If SL has hit a wall when it comes to their centralized and promiscuous proliferation of assets we should learn from that.
>  
> (It's not just storing terabytes of binares, it's sifting thru megarows of data to even locate it)
>  
> We can't give everybody everything - and we do have a point in time here where we can decide for ourselves that we quite simply will not do things the SL way, if that way has proven to be problematic.
>  
> If we're saying that we will be 100% SL compatible, then we cannot be anything more (or less) than an open source SL clone with sugar sprinkled upon it. And I cannot believe that's how the metaverse will be built.
>  
> Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 
> 
> 
> 
>> Date: Tue, 24 Jun 2008 13:16:38 +0100> From: melanie at t-data.com> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] Asset Referencing [Was: UUID]> > 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 'clo
ned' 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> _______________________________________________> Opensim-dev mailing list> Opensim-dev at 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