[Opensim-dev] llDetectedType and NPC's

Tue Jul 10 00:08:41 UTC 2012

I agree.  Ideally, I think no LL function would be extended.  However, in terms of general mechanisms (e.g. event, 
sensors), extension has effectively already taken place.

On 08/07/12 19:26, Dahlia Trimble wrote:
> In general it's not a good idea to extend any "ll" function beyond the equivalent SL definition as there is no guarantee
> that LL may add any new functionality that may conflict in the future. If this were to happen it would be difficult to
> resolve the conflicts as there would be scripts in use that depend on the conflicting definitions. Also some scripters
> don't always use symbolic constants (a terrible practice but it does happen) so it's not just a matter of changing a
> conflicting value for  a constant and recompiling. If your solution is dependent on deviating from  the SL definition
> for any "ll" API call, it may be easier for all involved in the future if you can redesign it such as to avoid future
> incompatibilities.
>
> On Sun, Jul 8, 2012 at 3:14 AM, Argus <argus at archimuh.de <mailto:argus at archimuh.de>> wrote:
>
>     Hi.
>
>       I have a problem with the way that NPCs might be implemented in llDetectedType. A patch can be found in Mantis 6066.
>
>       In the events touch, collision and sensor one can use the function llDetectedType which return some basic infos on
>     what type of object/agent... has been detected by the event. To complete this function, we still need to add NPCs as
>     type. Sofar, so good...
>
>       NPC do however also have the possebility to be created using OS_NPC_SENCE_AS_AGENT. This was implemented sothat
>     NPCs would work with sensor events ( without changing the lsl script). At that time NPCs were not implemented to
>     llDetectedType which one could have easely used to change the lsl script to work with NPCs and/OR agents instead of
>     implementing OS_NPC_SENCE_AS_AGENT. The result is, that using OS_NPC_SENCE_AS_AGENT would return an agent when using
>     llDetected AND that there is NO way to know if the event was triggered by an agent or NPC without forcing the users
>     to enable osIsNPC for everybody,  and I do realy mean everybody. For me and some other projects I know of, this will
>     have fatal sideeffects.
>
>
>
>        Let look at our 3 avatar type, normal agent, liblibomv bot and NPC's and how these can be used for identification.
>
>     Situation 1) A closed grid with hypergrid disabled.
>
>     - Normal agent = registered at grid, unique uuid + name within grid, controled by human
>     - Bots = basicaly same as agent, registered at grid,  with unique uuid + name within grid, but remotly controled by
>     software
>     - NPC = NOT registered, unique uuid within grid, ANY fictional OR existing name possible and like bots remotly
>     controled.
>
>     If llDetectedType return agent for NPCs using OS_NPC_SENSE_AGENT we only could detect the NPC using
>     llRequestAgentData to see if we get a posetive respone via DATA_NAME (unless the region itself detects the online
>     NPC as agent and returns the NPC data, havnt tested that yet.) In any case, the uuid remains unique and can always
>     be used to identify a single agent/npc/bot
>
>     Situation 2) Multigrid system with hypergrid enabled.
>
>     - Normal agent = registered at grid, unique uuid + name within grid, controled by human, surname changes with
>     hypergrid, name supplies griddata on hypergrid travels
>     - Bots = basicaly same as agent, registered at grid,  with unique uuid + name within grid, but remotly controled by
>     software, surname changes with hypergrid, name supplies griddata on hypergrid travels
>     - NPC = NOT registered, unique uuid within grid, ANY fictional OR existing name possible and like bots remotly
>     controled.
>
>       The uuid - name relation is still unique WITHIN a grid, but the same uuid-name relationship can be used in
>     multiple grids by DIFFRENT users. However when hypergrid traveling the name changes and one can extract the agents
>     origin grid sothat one recieves a unique uuid+name+grid relationship. In a multigrid system were llDetectedType
>     return agent for NPCs using OS_NPC_SENSE_AGENT there is NO method using plain lsl to get the unique uuid+name+grid
>     relationship,  llRequestAgentData is not available in all grids from the hypergrid visitor. The names of NPCs are
>     NOT unique within a grid AND the uuid could already exist in another grid for an agent. The uuid alone CAN'T be used
>     to identify a single agent/bot/npc in a multi grid system which is hypergrid enabled.
>
>       Short summary: In a mutligrid system with hypergrid each agent/bot has a unique uuid - name - grid relationship
>     were 2 elements are needed for identification, in a single grid without hypergrid the uuid is enough to identify
>     each agent/bot/npc. In a multigrid system NPC have to be identified as NPC sothat one can identify the NPC using
>     uuid + grid.
>
>
>
>     As mentioned there is no plain lsl method for identification in a multiple grid system with hypergrid if
>     llDetectedType returns an Agent for NPCs using OS_NPC_SENSE_AGENT. In Opensim we do have OSSL function which could
>     be used to help to distinguish between a registered agent and a NPC, eg. osIsNPC. The problem is however, that a
>     multigrid system would have to have multiple scripts available for all sorts of ossl combinations.
>
>     a) No NPCs allowed for anyone - script does not need any NPCs and all event can only be triggered by agents.
>     b) NPCs allowed  for 1 or more users, osIsNPC not enabled - Our script CAN'T recognize an NPC, so the service has to
>     be excluded and may not be used on that region
>     c) NPC allowed for 1 or more users, osIsNPC enabled for those users - Our script CAN'T recognize an NPC if the
>     script is owned by someone not enabled to use osIsNPC, so the service has to be excluded and may not be used on that
>     region.
>     d) NPC allowed for 1 or more users, osIsNPC enabled for everyone - Our script can now use osIsNPC nowmatter who the
>     owner is, only now we can recognize NPCs
>
>     So if your offering a multigrid service, were we need 2 elements for identification, it is required to have atleast
>     2 script. 1 script for regions were noone can use NPCs and another were osIsNPC is enabled for everyone. This means
>     that atleast 2 scripts need to be maintained by the scriptor and a huge support team which has to personaly speak to
>     each customer to explain what script to use etc etc. Latest after 1 year the customer has forgotten everything and
>     changes the NPC settings, which messes up the agent identification or the region owner changes something without
>     notifying the parcelwoners because he himself only wants to try something.
>
>       Now if the script is in a hud, then we never know what region settings are configured on the region we visit. So
>     as we dont know anything about the settings, our entire uuid+name+grid relation is useless and we have NO method
>     atall for identification in a multigrid system with hypergrid enabled. All ossl that could be used for NPC detection
>     must be considered not avialble while NPC can be used by others.
>
>     One could create extra modules to help us, but latest if a closed grid is involved we are not able to run our
>     additional module. So thats also not an option.
>
>
>     Résumé: The only method that would help in a multigrid system is, if llDetectedType ALWAYS returns NPC nomatter what
>     settings is used and AGENT for any agent/bot. Enabling OS_NPC_SENSE_AGENT to alow llDetectedType to return agent
>     makes all 3rd party systems in a multigrid hypergrid enabled enviroment virtualy impossible to handle.
>
>
>     It was thus also my intention to get this issue solved prior to implementation of osNPCTouch, but for that it is to
>     late now anyway :(.
>
>     Michelle Argus
>
>
>
>
>
>
>     _________________________________________________
>     Opensim-dev mailing list
>     Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>     https://lists.berlios.de/__mailman/listinfo/opensim-dev <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
>

-- 
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc