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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
