[Opensim-dev] llDetectedType and NPC's
Justin Clark-Casey
jjustincc at googlemail.com
Wed Jul 11 00:01:49 UTC 2012
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.
On 10/07/12 22:21, Argus wrote:
> Yes, opensource also means nothing can be trusted 100% and that anyone can do whatever they want to fool the entire
> world. Most users do however want a running system for everyone, so those people will not deliberatly mess around, but
> thats all going off topic anyway.
>
>
>
> Ok, Examples... I will go through some simple ones and increase the difficulty degree with each example....
>
> Very basic scripts:
> -----------------------
>
> Example 1: Giver script
> Very basic and common scripts are givers triggered by touch which also send a message to the owner to inform them that
> someone recieve an item. NPCs cant recieve items sent by llGiveInventory so we can exclude NPCs using llDetectedType and
> prevent the message also beeing sent.
>
> Example 2: IM messengers
> All the offline/online IM messengers sont need to respond to touches via NPCs
>
> Scripts that gather infos:
> -----------------------
>
> Example 3: Visitor lists
> All the visito lists that use sensor do not need to count NPCs which are using OS_NPC_SENSE_AS_AGENT
>
> Example 4: Huds and other gimmics
> Some huds and other gimmics show who is near by, e.g. a hug animation gimmic. These normaly also do not need to show NPCs
>
> Statistic scripts:
> -----------------------
>
> Example 5: Voting station
> Voting stations such as the one by oliveira in Osgrid count the unique touches to rank the places by popularity. NPCs
> definatly do not need to be counted. Due to the easy and fast method of creating hundreds of unique NPCs the NPCs can
> be used to manipulate votes. Bots are much more complex to use and need to go through the grid registration. Comparing
> bots with NPCs, then bots will extremly rare tool for manipulations.
>
> Multigrid systems in hypergrid.
> -----------------------
>
> Example 6:
> Now this is were the very complex situation starts with the multigrid and hypergrid stough. I will add sections
> A,B,C.. to make it easier in the discussions which will follow...
>
> I am going to extract a very "basic" part of one of my projects which includes a Rentbox and much more. I will add
> sections A,B,C.. to make it easier in the discussions which will follow... Giving script code example for this is not
> easy, so I will have to try to explain the prosedure a bit.
>
> A)
> I am going to extract a very "basic" part of one of my projects which includes a Rentbox and many more inworld tools,
> all of which is connected to webtools for easy offline management etc etc.. One part of my rentbox is, that it offers
> the inworld dialog boxes in multiple languages. If a unknown avatar touches the rentbox, then the avatar can select a
> language via a dialog box. If the avatar is known and previously already selected a language, then the dialog box
> automaticaly selects the last chosen language which is saved on a webserver for that avatar. Sofar that should be clear
>
> B)
> The entire system is running in multiple grids, eg OSgrid, and these also include closed grids such as SL and
> GermanGrid. Some grids are hypergrid enabled and allow traveling between these grids. As my system is hypergrid
> compatible, the last selected language is also automaticaly available in foreign grids. Lets say a hypergrid visitor
> from GermanGrid has selected german as language at a Rentbox in German grid, then they also will have a german dialog
> when touching a rentbox in osgrid.
>
> C)
> The automatic recognition of the last selected language requires that the avatar can uniquely be identified, otherwise
> it would mean that everyone needs to reselect the language every time they touch a rentbox. In a mutigrid hypergrid
> enabled enviroment without NPCs we have the following basic data stored:
>
> Gridtable
> +----------------------+--------------------------------+
> | Gridname | hg last name of avatar |
> +----------------------+--------------------------------+
> | OSGrid | hg.osgrid.org |
> | GermanGrid | login.germangrid.de |
> +----------------------+--------------------------------+
>
> Avatar language table
> +----+----------------------+--------------------+--------------------+----------------+
> | id | Gridname | Avatar uuid | Avatar name | language |
> +----+----------------------+--------------------+--------------------+----------------+
> | 1 | OSgrid | uuid-1 | Avatar 1 | en |
> | 2 | OSgrid | uuid-2 | Avatar 2 | en |
> | 3 | GermanGrid | uuid-3 | Avatar 3 | de |
> | 4 | GermanGrid | uuid-4 | Avatar 4 | en |
> | 5 | GermanGrid | uuid-5 | Avatar 5 | en |
> | 6 | OSgrid | uuid-3 | Avatar 6 | de |
> | 7 | OSgrid | uuid-4 | Avatar 4 | en |
> | 8 | OSgrid | uuid-6 | Avatar 5 | de |
> +----+----------------------+--------------------+--------------------+----------------+
>
> D)
> Now lets look at the avatars with the id's 7-9
>
> Case id 7: the Avatar uuid "uuid-3" can exist in other grids, eg. GermanGrid id 3
> Case id 8: The Avatar name "Avatar 4" can also exist in another grid, eg GermanGrid id 4
> Case id 9: The Avatar uuid "uuid-6" AND Avatar name "Avatar 5" can also exist in another grid, eg GermanGrid id 6
>
> Each avatar is however uniquely registered in each single grid and each uuid and each avatar name cannot be reused
> multiple times within each grid.
>
> E)
> Now lets asume our Rentbox is standing in OSgrid. If:
>
> 1) Avatar with "uuid-1" and "Avatar 1" touches the rentbox, we know its the avatar with id 1 which has english selected
> and its a local avatar from osgrid
> 2) Avatar with "uuid-3" and "Avatar.3 @login.germangrid.de" touches the rentbox, we know its the avatar with id 3 which
> has german selected and is a hypergird traveler from GermanGrid
> 3) Avatar with "uuid-3" and "Avatar 6" touches the rentbox, we know its the avatar with id 7 which has german selected.
> The uuid is not unique in all grids, but the name didnt change to a hypergrid name!
> 4) Avatar with "uuid-7" and "Avatar 7" touches the rentbox, this is a new avatar so we add it to our db and ask for the
> language
> +----+----------------------+--------------------+--------------------+----------------+
> | 9 | OSgrid | uuid-7 | Avatar 7 | ? |
> +----+----------------------+--------------------+--------------------+----------------+
>
> So the name change from hypergrid visitors makes it possible to reliably identify the avatar eventhough the avatar uuid
> and/or avatar name is not unique in all grids. If one only searches by uuid or name, then multiple avatars would be
> returned.
>
> F)
> User friendly tools like a rentbox to offer functions to add Tendants by name were the uuid is not known. Based on the
> fact that avatars have a unique name and a unique uuid the identification via name + grid is possible in a mutigrid
> system. We might not always be able to add a new avatar with a uuid immidiatly e.g. due to script delays, but we can
> update that information
>
> So now lets add a tendant with the avatar name "Avatar 7" from OSgrid. Lets also asume that the grid is very buizy and
> scripts are slow in getting the uuid so we addthe agent without a uuid for now. Remember, avatar uuid + names are
> unique, so what can go wrong?
> +----+----------------------+--------------------+--------------------+----------------+
> | 9 | OSgrid | ? | Avatar 7 | ? |
> +----+----------------------+--------------------+--------------------+----------------+
>
> G)
> Now lets add NPCs to our table. NPC are currently imprisoned to the region of creation. Lets again take a rentbox in
> OSgrid which gets touched by a NPC.
>
> 1) we add NPC with NPC uuid "uuid-7" and NPC name "NPC 1". The NPC name does not deliver any grid data, so the NPC is in
> the same grid as our rentbox= OSgrid.
> +----+----------------------+--------------------+--------------------+----------------+
> | 10 | OSgrid | uuid-7 | NPC 1 | ? |
> +----+----------------------+--------------------+--------------------+----------------+
> We added a new user, so please select the language before continuing...
>
>
> 2) we add NPC with NPC uuid "uuid-8" and Avatar name "NPC.8 @login.germangrid.de". The NPC name is a typical hypergrid
> name, so the NPC is from GermanGrid. Ups, a NPC currently cant teleport anywere, especialy not hypergrid.
> +----+----------------------+--------------------+--------------------+----------------+
> | 11 | GermanGrid | uuid-8 | NPC 8 | ? |
> +----+----------------------+--------------------+--------------------+----------------+
> We added a new user, so please select the language before continuing...
>
>
> 3) we add NPC with NPC uuid "uuid-9" and NPC name "Avatar 1". The NPC name does not deliver any grid data, so the NPC is
> in the same grid as our rentbox= OSgrid. Ups, "Avatar 1" is already in use in OSgrid. Who is a NPC and who is a agent?
> +----+----------------------+--------------------+--------------------+----------------+
> | 12 | OSgrid | uuid-9 | Avatar 1 | ? |
> +----+----------------------+--------------------+--------------------+----------------+
> We have 2 x "Avatar 1" in OSgrid, one with english selected (id 1), and another with no language selected (id12) As the
> uuid is unique, we asume its id 12, so please select the language... Unfortunatly as of now we cannot offer name based
> services for "Avatar 1" because we have 2 entries.
>
>
> 4) we add NPC with NPC uuid "uuid-5" and Avatar name "Avatar.5 @login.germangrid.de". The NPC name is a typical
> hypergrid name, so the NPC is from GermanGrid. We already know this avatar with the id 5. Big ups, we won the jackpot by
> having the same uuid and name. While we are at it, how about we cancel the current lease...
>
>
> 5) we add NPC with NPC uuid "uuid-10" and Avatar name "Avatar 7". The NPC name does not deliver any grid data, so the
> NPC is in the same grid as our rentbox= OSgrid. Great, we were faster than the script retrieving the uuid for "Avatar 7"
> in F, lets update it. Pitty "Avatar 7" with the id 9 actualy isnt a NPC
> +----+----------------------+--------------------+--------------------+----------------+
> | 9 | OSgrid | uuid-10 | Avatar 7 | ? |
> +----+----------------------+--------------------+--------------------+----------------+
> We added a new user, so please select the language before continuing...
>
>
> H)
> A Rentbox is much more complex then the language settings when touching. We have hovertext with names, owners functions,
> staf related functions, tendants, commisioning, addon modules, banning systems etc etc which all require a possetive
> identification.
>
> I)
> If lsl offers the possebility to detect an NPC as a NPC only, and agents as agents only, then one can atleast add the
> type to our avatar table in C or ignore NPCs.
>
> Due to hypergrid the scripts also can travel through hypergrid and land on other grids. Other grids or even regions
> might not be running on newer OS versions with all ossl/NPC functions/constants implemented so the scripts need to rely
> on the smalest available functionset.
>
> Up till now lsl was "dictated" by LL and there was no possebility in OS to create exeptions from LL, not even adding
> true grid data to the header of http_requests. For me and other scripters in multiple grids the smalest reliable
> functionset thus always has been the lsl implemented functions in opensim were the script could be copied 1:1 to SL
> without changes. All scripts using OSSL or which require specific settings are good for the advanced users. Just imagine
> telling someone in SL using a hippo rentbox that one needs to do modifications to the sim and someone forgot to add a
> single function and everything broke, yippi
>
> NPCs are now the big exeption. It would be logical that SL scripts need to be changes to fully work with NPCs, but
> instead one changed the NPCs and lsl sothat sl scripts work with NPCs while ignoring the diffrences between NPCs and
> Agents/Bots.
>
>
> Hope that helps...
>
>
>
>
>
>
> Am 10.07.2012 02:30, schrieb Justin Clark-Casey:
>> Argus, I'm a little confused. Some of what you say seems to concern NPCs going to other regions via Hypergrid. But
>> OS NPCs are bound to the region they are instantiated in. Possibly they may be able to cross to regions in the same
>> simulator in the future, but they will never be able to go to other simulators, let alone Hypergrid.
>>
>> So I'm assuming you're talking about reliable NPC detection in a Hypergrid situation. Ultimately, this is impossible
>> because the OpenSimulator operator can always change the code to return what they like. So it doesn't matter what
>> function the script uses - it can always be fooled.
>>
>> I don't personally object to extending llDetectedType() to return NPC, though NPC was a poor choice of constant name
>> imo since it could clash with Linden developments in the future. I also don't object to some config value to stop the
>> use of OS_NPC_SENSE_AS_AGENT on a particular simulator. But being able to use NPCs with existing scripts is very
>> useful in some contexts so if llDetectedType() is to be extended it must accomodate that option for consistency with
>> everything else.
>>
>> Perhaps you could provide a concrete example. Not a whole script but described functionality for some real in-world
>> tool.
>>
>>
>>
>
>
> _______________________________________________
> 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
More information about the Opensim-dev
mailing list