Quote: "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."
The implementation of NPCs are causing the deviations from SL while
all my scripts are based on the SL definitions and also run 1:1 in SL.
If there would be a possebility to solve this issue, I also would
redesign my application, but sofar I havnt found any relyable method for
NPC detection other than llDetectedType returning NPC even when using
OS_NPC_SENCE_AS_AGENT. Even in our Opensim code we find the name changes
for hg visitors implemented as detection with the deffrence that NPC are
excluded via the opensim code.
This is also a problem for others, it not only me who is having issues
with NPC detection.
Am 08.07.2012 20:26, schrieb Dahlia Trimble:
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
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
