[Opensim-dev] llDetectedType and NPC's

Thu Jul 12 21:33:43 UTC 2012

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 <
>>> jjustincc at googlemail.com> 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 (justin at hg.osgrid.org 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
>>>>> Opensim-dev at lists.berlios.de
>>>>> 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
>>>> 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
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> 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