[Opensim-dev] llDetectedType and NPC's

Gudule Lapointe gudule at spekuloos.be
Tue Jul 10 21:57:10 UTC 2012


Solution exists:

	osIsNpc(key npc)

(sorry: trying to make it short)

--
http://www.speculoos.net/
secondlife://speculoos.net:8002/
Speculoos, the belgian cookie-flavored metaverse

Le 10 juil. 2012 à 23:21, Argus a écrit :

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20120710/62607186/attachment-0001.html>


More information about the Opensim-dev mailing list