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
