<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"> 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."<br>
<br>
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.<br>
<br>
This is also a problem for others, it not only me who is having
issues with NPC detection.<br>
<br>
<br>
Am 08.07.2012 20:26, schrieb Dahlia Trimble:<br>
</div>
<blockquote
cite="mid:CAAQTD4XH26Mh437MajB0Bg30OWnU9=EDp+c6_zJ6XcV9peJseg@mail.gmail.com"
type="cite">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.<br>
<br>
<div class="gmail_quote">On Sun, Jul 8, 2012 at 3:14 AM, Argus <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:argus@archimuh.de" target="_blank">argus@archimuh.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi.<br>
<br>
I have a problem with the way that NPCs might be implemented
in llDetectedType. A patch can be found in Mantis 6066.<br>
<br>
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...<br>
<br>
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.<br>
<br>
<br>
<br>
Let look at our 3 avatar type, normal agent, liblibomv bot
and NPC's and how these can be used for identification.<br>
<br>
Situation 1) A closed grid with hypergrid disabled.<br>
<br>
- Normal agent = registered at grid, unique uuid + name within
grid, controled by human<br>
- Bots = basicaly same as agent, registered at grid, with
unique uuid + name within grid, but remotly controled by
software<br>
- NPC = NOT registered, unique uuid within grid, ANY fictional
OR existing name possible and like bots remotly controled.<br>
<br>
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<br>
<br>
Situation 2) Multigrid system with hypergrid enabled.<br>
<br>
- Normal agent = registered at grid, unique uuid + name within
grid, controled by human, surname changes with hypergrid, name
supplies griddata on hypergrid travels<br>
- 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<br>
- NPC = NOT registered, unique uuid within grid, ANY fictional
OR existing name possible and like bots remotly controled.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
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.<br>
<br>
a) No NPCs allowed for anyone - script does not need any NPCs
and all event can only be triggered by agents.<br>
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<br>
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.<br>
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<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
<br>
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 :(.<br>
<br>
Michelle Argus<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a moz-do-not-send="true"
href="https://lists.berlios.de/mailman/listinfo/opensim-dev"
target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a></pre>
</blockquote>
<br>
<br>
</body>
</html>