Yes, as Dahlia points out, LL could very well implement the NPC constant to mean something else, at which point we are
screwed. Retaining and improving the level of compatibility with LSL is a very important use case for some of us.
So rather than spreading the NPC constant to llDetectedType(), I propose to create OS_NPC instead, which is much less
likely to be used by LL (unless they really go out of their way). This constant name is in keeping with all the other
previously established OS_NPC* constants.
This would be used in llDetectedType() as well as with the existing llSensor(), llRepeatSensor() uses. NPC would remain
valid but would be deprecated. If and when LL uses NPC then it will have to change to mean whatever they establish it
to mean, unless that were somehow identical to OS implementation (which seems unlikely to me).
Another course of action would be to create parallel osDetectedType(), osSensor(), etc. whenever the OpenSimulator
behaviour can diverge from what is strictly allowed by LSL. As part of this, these commands would have to be available
by default. Even then, there is still a mixing with LSL due to the use of events such as sensor, unless one were to
also create parallel os events (e.g. ossensor). But I think the over-complexity outweighs the risks of doing some stuff
within the LSL namespaces.
On 12/07/12 16:43, Argus wrote:
I think Dahlia means the symbolic constant being the same. Dahlia pointed out
in the mantis that LL might be
implementing the symbolic constant NPC for something else...
Am 12.07.2012 04:19, schrieb Melanie:
Then it will be a case in point to use symbolic constants, not magic
numbers.
Melanie
On 12/07/2012 03:58, Dahlia Trimble wrote:
So what happens when LL defines "NPC" and it means something different that
what is defined in OpenSimulator?
And yes, I believe the probability is quite high that they will eventually
define it.
On Wed, Jul 11, 2012 at 5:01 PM, Justin Clark-Casey <
[email protected]> wrote:
That's a neat solution, Argus. Since the intention of
OS_NPC_SENSE_AS_AGENT was to provide compatibility rather than 'fool', I
think returning both NPC and AGENT flags would be perfectly acceptable.
Let's see if there are any other comments, otherwise I think we can
proceed along those lines. I'm still not that happy with extending
llDetectedType() but leakage has already occurred and I suspect its
inevitable.
On another note, I'm not sure what 'plausibility' checks you're referring
to.
On 11/07/12 13:04, Argus wrote:
I am fully aware of the open source factor and that in each open grid
everything can be changed, which is why one always
needs backend function to make sure no fals information is passed on to
the central service. One can however filter 99%
of the fals data in the local sim which helps the central service because
it does not need to process every single
plausability checks. In a multi grid environment with closed grids we
even have a lower chance of false data beeing
passed than in a open grid only environment.
We have the same situations in opensim were the simulator often does
some local plausability checks before it send
data to the gridservers. The gridservers again do a plausability check
combined with other methods which are not
available on the local sim. Only if all steps are plausable the data gets
processed further.
Anyway, I added a new patch for llDetectedType were NPCs always return
NPC and useing OS_NPC_SENSE_AS_AGENT will returns
AGENT + NPC. I think that is an acceptable compromize... I also added an
example script were the true NPC detection
always makes sense ;)
Am 11.07.2012 02:01, schrieb Justin Clark-Casey:
Argus, if your system relies on always reliably identifying unique
avatars then that is simply not possible in any
OpenSimulator environment where simulators are controlled by third
parties or where hypergrid travel is allowed.
Even if OS_NPC_SENSE_AS_AGENT did not exist, then people would be able
to compile a version of the code that did have
that functionality. This is not about ideology - it's about what is
physically possible!
Equally, it is perfectly possible to create duplicate HG details -
anything can be put in the agent data that comes
from a foreign grid ([email protected] or whatever). You cannot
rely on these to be unique either.
Without any central authority (like DNS, the secure certificate
infrastructure of something like Bitcoin block chains)
it is simply not possible to uniquely identify avatars.
I don't see this as much different from the web where one has to get
people to create unique accounts with passwords
in order to identify them later. Such a thing has to be done in some
authority system outside of OpenSimulator itself.
If your point is that without OS_NPC_SENSE_AS_AGENT then the vast
majority of systems would always present NPCs as
NPCs (rather than agents) then I would agree. In fact, in practice most
people won't use OS_NPC_SENSE_AS_AGENT anyway
as it's the option rather than the default. But you cannot rely on
uniquely identifying avatars on any environment
outside those that you directly control.
On a minor note, script functions that don't make any sense for NPCs
should behave as if the UUID they received did
not relate to a valid entity for that function.
______________________________**_________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/**mailman/listinfo/opensim-dev<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<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
_______________________________________________
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
