Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006066opensim[REGION] Script Functionspublic2012-06-27 10:522014-07-29 13:41
ReporterMichelle Argus 
Assigned ToMichelle Argus 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionmaster (dev code) 
Target VersionFixed in Versionmaster (dev code) 
Summary0006066: Patch adding NPC to llDetectedType()
DescriptionThis Patch adds the ability to detect NPCs using llDetectedType(). llDetectedType works in touch, collision and sensor events.
Steps To Reproducedefault
{
    touch(integer ts)
    {
        if(llDetectedType(0) & AGENT)
        {
            llSay(0, "A avtatar touched me");
        }
        else if(llDetectedType(0) & NPC)
        {
            llSay(0, "A NPC touched me");
        }
    }
}
TagsNo tags attached.
Git Revision or version number6d3ee8bb39d47ed7b32e8905fa0b2fc31c5a9f80
Run Mode Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineBasicPhysics
EnvironmentUnknown
Mono VersionNone
Viewer
Attached Filespatch file icon 001-[Patch] Add-NPC-to-llDetectedType.patch [^] (1,063 bytes) 2012-06-27 10:52 [Show Content]
patch file icon 002-[Patch] Add-NPC-to-llDetectedType.patch [^] (2,004 bytes) 2012-07-11 01:25 [Show Content]

- Relationships
child of 0006063closedjustincc [PATCH] an implementation of osNPCTouch 

-  Notes
(0021704)
justincc (administrator)
2012-06-27 17:43

This is why I didn't like 0x20 for NPC. There's a good chance the Lindens are going to use it for something else and then all scripts using this will be in trouble. I know it's already being used for llSensor(), which I believe was a mistake.
(0021707)
Michelle Argus (reporter)
2012-06-28 00:14

Right, i agree with you justin, and yes, i copied it from the existing NPC constant.

 Suggestion: we raise the NPC constant to a extremly high value which will be unlikely to be implemented by LL.

 Currently there are not so many NPC scripts around yet that will break and hopefully most of the existing script will be using the constant NPC instead of the value itself.

I would suggest 0x16000000 (also in the sensor)
(0021711)
justincc (administrator)
2012-06-28 14:46

Well, I think there are two choices here. Either (1) change NPC now or (2) if Linden use this value for a different constant then assign that a different value.

Both of these assume that people are properly using code constants instead of magic numbers. I'm not sure which action is better. I prefer (1) because that has a chance of resolving the issue rather than having some future situation where a Linden created LSL constant is always different from the value used by OpenSimulator.
(0021713)
Michelle Argus (reporter)
2012-06-28 15:03

Right, I also prefer changing it now. I will make a new patch incl. the other NPC used...
(0021714)
justincc (administrator)
2012-06-28 15:04

Michelle, I would recommend waiting a little while for any other comments first.
(0021715)
Michelle Argus (reporter)
2012-06-29 07:15

Ok, we wait....

 I would however also recommend to wait with implementing osNPCTouch. The implementation of NPCs in llDetectedType can prevent some unwanted "griefing". If osNPCTouch is implemented prior to NPC in llDetectedType we have OS versions were scripts have no possebility to recognize if a agent or npc is touching the object.
(0021716)
melanie (administrator)
2012-06-29 10:07

This is a bit flag value, so it must be a single bit, not 3 bits as you suggested above. Changing the constant would effectively break all scripts already compiled with that constant. So, hard -1 on changing it. I believe it's much less painful to change a possibly conflicting Linden constant, should one come into existence. They, however, still have 8 and 16 to assign before reaching 32. Somehow I doubt they will add that many more types.
(0021718)
justincc (administrator)
2012-06-29 16:03

8 and 16 are already effectively assigned, being SCRIPTED and AGENT_BY_USERNAME respectively. They may not be returned by sensors but they are part of the common enum sequence already used by other functions so 0x20 will be next for the Lindens.

I take the point about this constant already being in compiled OpenSim scripts, so I suppose we will simply have to use a different enum for a future conflicting Linden value. This will just demonstrate to people the importance of using named constants rather than magic numbers.

Michelle, your patch will also need to account for the case where the user has chosen for the NPC to be detected as an agent rather than as an NPC. Examples of this are in SensorRepeat.doAgentSensor(), npcData.SenseAsAgent. This will mean using the NPC module.
(0021721)
Michelle Argus (reporter)
2012-06-29 18:02

big -1 on npcData.SenseAsAgent. With SenseAsAgent we have no possebility to reliably detect true agent.

- Griefers will tend to hide their NPCs as an agent.
- No method available to ignore NPCs due to commands that dont work on npc, eg givers, dialogs, debit permissions (might be excluded anyway)...

Suggestion would be to use the constants NPC + OS_NPC_NOT_OWNED / OS_NPC_SENSE_AS_AGENT / OS_NPC_CREATOR_OWNED and the normal lsl behavious from SL. Problem then are coliding constants:

AGENT = 1;
AGENT_BY_LEGACY_NAME = 1;
AGENT_BY_USERNAME = 0x10;
NPC = 0x20;
ACTIVE = 2;
PASSIVE = 4;
SCRIPTED = 8;

OS_NPC_CREATOR_OWNED = 0x1;
OS_NPC_NOT_OWNED = 0x2;
OS_NPC_SENSE_AS_AGENT = 0x4;
(0021763)
justincc (administrator)
2012-07-06 14:42

To answer point 1, I would say that allowing someone to create an NPC in the first place already gives them griefing ability (e.g. they can rez one with a name that belongs to someone else, bump them into other people, etc.). This is why they have a High threat level.

Equally, there is nothing to stop someone using libomv to login a 'genuine' avatar and do any action that could be done by a real person (except pass a Turing test, I guess). So I don't see much gain in security.

To answer point 2, the osIsNpc method will always reliably indicate whether a UUID belongs to an NPC or not, even if OS_SENSE_AS_AGENT was defined.

The OS_NPC_SENSE_AS_AGENT option was introduced for scenarios where one wants to allows NPCs to act with other existing objects without having to reprogram them to recognize NPCs. This may occur in OpenSimulator uses other than public grid (e.g. as a standalone installation for a specific 3D application).

Therefore, for consistency with sensors, if llDetectedType() is to be extended outside Linden specifications to indicates NPCs, then I think it must also handle the OS_NPC_SENSE_AS_AGENT option.
(0021768)
Talun (manager)
2012-07-06 16:51

I had a thought on osIsNPC, could it be allowed it to execute without error and with no restrictions so that scripts could always reliably detect NPCs without the need for content creators to maintain multiple versions for cases where OSSL is turned off or the script owner is not configured to use OSSL?
If always allowed it would give no clues about OSSL availability generally.
(0021769)
melanie (administrator)
2012-07-06 16:54

No. OSSL has the threat level and disables to give the grid operator ultimate control. Weakening that is the tin end of the wedge.
(0021775)
Michelle Argus (reporter)
2012-07-08 03:29

I wrote to the mailing list. I cannot support OS_NPC_SENSE_AS_AGENT to result in NPC beeing detected as an agent because it will make identification in a multigrid system impossible.
(0021780)
dahlia (administrator)
2012-07-08 17:24

I don't agree with the use of "NPC" as a symbol. I've heard several Lindens discuss the eventual inclusion of animated mesh objects into SL and it's not uncommon now for associating the name "NPC" with soon-to-be-released pathfinding objects. I also don't agree with the assumption that any of the bits in a bitfield are fair game when the definition of these bits are out of our control. There is no guarantee that the owner of the definition will choose consecutive bits as future features are added.

At bare minimum a symbol should be chosen that has little probability of conflicting with future SL implementations, perhaps "OS_NPC" rather than "NPC".
(0021781)
justincc (administrator)
2012-07-09 17:31
edited on: 2012-07-09 17:34

I think NPC was a poor choice of symbol as well. The Lindens could easily use this value - OS_NPC would have been much less likely to clash.

Unfortunately, 'NPC' already exists now for setting up sensors.

(0021782)
Talun (manager)
2012-07-10 01:37

I doubt that any script in SL or OS checks llDetectedType in a touch events since touch can only be done by agent.

Since an NPC touch can only be achieved via a scripted object a case could be made for type SCRIPTED to be returned, only for touch events though.

A reasonable value since done by a script with no new constants and scripts would be valid in both SL and OS

The other value I had in mind was 0
(0021784)
Michelle Argus (reporter)
2012-07-11 01:37

I added the new patch 002 which replaces 001. The llDetected type will now always return NPC when a NPC is beeing used. When using OS_NPC_SENSE_AS_AGENT it will additionaly add AGENT to the type.

Example for a giverscript:

default
{
    touch_start(integer touches)
    {
        integer type = llDetectedType(0);
        if(type & AGENT)
        {
            if(type & NPC)
            {
                llWhisper(0, llDetectedName(0) + " is a NPC created with OS_NPC_SENSE_AS_AGENT");
            }
            else
            {
                llGiveInventory(llDetectedKey(0), "Primitive");
                llInstantMessage(llGetOwner(), llDetectedName(0) + " has recieved a Primitive");
            }
        }
        else if(type & NPC)
        {
            llWhisper(0, llDetectedName(0) + " is a NPC whithout OS_NPC_SENSE_AS_AGENT");
        }
    }
}
(0021785)
SignpostMarv (reporter)
2012-07-11 01:46

I always thought that NPCs would've been AGENT & SCRIPTED e.g. 0x09, since a) they're agents, but b) they're driven by scripted sources as opposed to external influences (e.g. humans, libOMV bots or other software of varying degrees of sentience).
(0021786)
Michelle Argus (reporter)
2012-07-11 02:06
edited on: 2012-07-11 02:13

Per LL definition SCRIPTED is a scripted object. A NPC is not a object.

http://wiki.secondlife.com/wiki/LlDetectedType [^]
http://wiki.secondlife.com/wiki/SCRIPTED [^]


Besides, we already have the constant NPC implemented and using NPC makes it clear to everyone that we are not dealing with a normal object.

EDIT: A NPC or agent which is wearing a scipted AO can also be scripted.

(0021787)
SignpostMarv (reporter)
2012-07-11 02:17

Ah. I'm also guessing that scripts looking for SCRIPTED before AGENT would break when attempting to act on the assumption that the thing in question is a prim :s
(0021788)
Michelle Argus (reporter)
2012-07-11 02:57

The last example on the SCRIPTED wiki confused me a little, so I had to try it in SL.

In SL the behaviour is
- a object which has a script in its inventory is SCRIPTED
- a agent which is wearing a scripted object is not SCRIPTED

As NPCs are basicaly handled as avatars in opensim, they are not an object which can have scripts in their inventory.
(0021862)
Michelle Argus (reporter)
2012-07-21 09:24

Justin, might be good to get this implemented before 0.7.4 ;)
(0021877)
justincc (administrator)
2012-07-23 15:58

I actually did this on Friday in git master ecf7bb2 but haven't announced it yet.
(0021886)
Michelle Argus (reporter)
2012-07-25 01:23

thx justin, closing this mantis then...

- Issue History
Date Modified Username Field Change
2012-06-27 10:52 Michelle Argus New Issue
2012-06-27 10:52 Michelle Argus File Added: 001-[Patch] Add-NPC-to-llDetectedType.patch
2012-06-27 10:53 Michelle Argus Status new => patch included
2012-06-27 10:56 Michelle Argus Relationship added child of 0006063
2012-06-27 14:14 Michelle Argus Steps to Reproduce Updated View Revisions
2012-06-27 14:14 Michelle Argus Additional Information Updated View Revisions
2012-06-27 17:43 justincc Note Added: 0021704
2012-06-28 00:14 Michelle Argus Note Added: 0021707
2012-06-28 14:46 justincc Note Added: 0021711
2012-06-28 15:03 Michelle Argus Note Added: 0021713
2012-06-28 15:04 justincc Note Added: 0021714
2012-06-29 07:15 Michelle Argus Note Added: 0021715
2012-06-29 10:07 melanie Note Added: 0021716
2012-06-29 16:03 justincc Note Added: 0021718
2012-06-29 18:02 Michelle Argus Note Added: 0021721
2012-07-06 14:42 justincc Note Added: 0021763
2012-07-06 16:51 Talun Note Added: 0021768
2012-07-06 16:54 melanie Note Added: 0021769
2012-07-08 03:29 Michelle Argus Note Added: 0021775
2012-07-08 17:24 dahlia Note Added: 0021780
2012-07-09 17:31 justincc Note Added: 0021781
2012-07-09 17:34 justincc Note Edited: 0021781 View Revisions
2012-07-10 01:37 Talun Note Added: 0021782
2012-07-11 01:25 Michelle Argus File Added: 002-[Patch] Add-NPC-to-llDetectedType.patch
2012-07-11 01:37 Michelle Argus Note Added: 0021784
2012-07-11 01:46 SignpostMarv Note Added: 0021785
2012-07-11 02:06 Michelle Argus Note Added: 0021786
2012-07-11 02:13 Michelle Argus Note Edited: 0021786 View Revisions
2012-07-11 02:17 SignpostMarv Note Added: 0021787
2012-07-11 02:57 Michelle Argus Note Added: 0021788
2012-07-21 09:24 Michelle Argus Note Added: 0021862
2012-07-23 15:58 justincc Note Added: 0021877
2012-07-25 01:23 Michelle Argus Note Added: 0021886
2012-07-25 01:24 Michelle Argus Status patch included => resolved
2012-07-25 01:24 Michelle Argus Fixed in Version => master (dev code)
2012-07-25 01:24 Michelle Argus Resolution open => fixed
2012-07-25 01:24 Michelle Argus Assigned To => Michelle Argus
2014-07-29 13:41 chi11ken Status resolved => closed


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker