So then would something in the LL protocol modules keep track of a localID/UUID relationship? LocalIDs are required for describing object hierarchies to the viewer. I thought they were also the primary reference for any in-scene object and UUIDs were more related to asset storage and scripted features.
On Fri, Jul 10, 2009 at 9:17 AM, Teravus Ovares <tera...@gmail.com> wrote: > It is feasible. It would just require a standard way of referencing > objects in all modules(URI?). unsigned integers are fast, small and > well supported. Potentially the binary data in a UUID could be fit > in the memory space and be just as fast. > > Regards > > Teravus > > On Fri, Jul 10, 2009 at 12:13 PM, Melanie<mela...@t-data.com> wrote: > > Well, the problem is that there are two ids for each prim, that need > > to be translated between. I don't now physics, because looking at > > that math makes my head hurt, so I don't. > > > > Is it at all feasible then, to not have a local ID? > > > > Melanie > > > > Teravus Ovares wrote: > >> One connected functionality here, is script engine events. These are > >> all done via localID. Additionally, physics collision events are > >> generated with 'localid' because most physics engines either have a > >> sequential numeric id for objects or have a means to store them. It > >> may not have a bearing on the derez event, however, I wanted to > >> mention them since 'moving localID out of core' was brought up. > >> It's not really a Linden concept really.. it's a Havok concept > >> that they adopted. > >> > >> Regards > >> > >> Teravus > >> > >> On Fri, Jul 10, 2009 at 11:58 AM, Melanie<mela...@t-data.com> wrote: > >>> Definitely +1. However, here's a thought: > >>> > >>> Could we not try to take this as a starting point for moving the > >>> localID to UUID conversion into the client view, e.g. make it a > >>> List<UUID> and translate LocalID to UUID before the call. I believe > >>> we should work on getting LocalID out of core, it's a Linden concept > >>> other viewers probably won't have. Having just ONE type of ID (the > >>> UUID) would make implementing other client stacks easier. > >>> > >>> Melanie > >>> > >>> > >>> MW wrote: > >>>> In the current OnDeRezObject event, only a single localID of a prim is > passed at a time. > >>>> > >>>> So if multiple objects are DeRezzed in one action, even though all the > ids are sent in a single packet. We have code in the ClientView that loops > through that list and for each id triggers the OnDeRezObject event. > >>>> > >>>> I propose moving that loop into the Scene handling of the action > (Scene.DeRezObject(...)) so that the event is only triggered once per > packet and if there are multiple prims to derezz in a packet, the scene code > can loop through them and deal with them as required. > >>>> > >>>> So current the delegate of the OnDeRezObject event is : > >>>> > >>>> public delegate void DeRezObject( > >>>> IClientAPI remoteClient, uint localID, UUID groupID, > DeRezAction action, UUID destinationID); > >>>> > >>>> I propose changing it to: > >>>> > >>>> public delegate void DeRezObject( > >>>> IClientAPI remoteClient, List<uint> localIDs, UUID groupID, > DeRezAction action, UUID destinationID); > >>>> > >>>> It has to be better to have only one event triggering rather than > possibly hundreds for the same user action. > >>>> > >>>> My next step (which I'm currently in the middle of in my local > version) is to handle the taking of those multiple prims into inventory and > only making a single inventory item, rather than the current method of a > separate inventory item for each prim. But that will be detailed in a > different proposal.. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > ------------------------------------------------------------------------ > >>>> > >>>> _______________________________________________ > >>>> Opensim-dev mailing list > >>>> Opensim-dev@lists.berlios.de > >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev@lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev@lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > >> > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
