Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008534opensim[REGION] Script Functionspublic2019-05-25 09:542019-05-27 10:05
Assigned ToBillBlight 
StatusresolvedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0008534: Suggestion: Add LSL function osDetectedSize
DescriptionIn an attempt to build a self-driving NPC, I wanted to find out the size of a sensed object. llDetectedSize doesn't exist, and osGetPrimitiveParams for size always returns ZERO_VECTOR for objects not owned by the script owner, in this case the NPC.

Sensor detected sizes are required in order so that NPCs can avoid objects. It's not enough to know where they are, you have to know how big they are. Probably the rotation is needed too, but that's already available.

I propose osDetectedSize, because it seems to me that the omission of llDetectedSize is just an oversight. A sample implementation patch is enclosed.
Steps To ReproduceDo not apply the enclosed patch.
Additional InformationThe supplied version has no usage restriction other than OSSL enablement.
I also have a short test script.
TagsNo tags attached.
Git Revision or version numberPatch is diff from current master.
Run Mode Grid (1 Region per Sim)
Physics EngineBulletSim
Script Engine
EnvironmentMono / Linux64
Mono Version5.x
Attached Filespatch file icon detectedsize.patch [^] (4,059 bytes) 2019-05-25 09:54 [Show Content]
? file icon Test_DetectedSize.lsl [^] (843 bytes) 2019-05-25 09:56

- Relationships

-  Notes
CrasherRob (reporter)
2019-05-25 10:53

Implementation test region available on request via irc #opensim-dev.
BillBlight (developer)
2019-05-25 11:11

Patch Included
BillBlight (developer)
2019-05-25 15:00

Patch now on Dev Outreach on osGrid for testing.
CrasherRob (reporter)
2019-05-26 09:53

Don't accept this proposal unless you actually think osDetectedSize would be used.

1) It turns out that this doesn't actually do what I need it to do for linked objects.
2) llGetBoundingBox (which I had forgotten about) does pretty much exactly what I think I need, doesn't have any nasty restrictions, and already works.
3) osDetectedSize was just one of the things I need for a self-driving NPC. I need additional functionality in that I need some way to allow NPCs to raise their permission level.

I have an idea on how to get that, and am willing to attempt to implement it. However, osDetectedSize "seemed like a good idea at the time" but doesn't any more. So I'd like you to examine this proposal first.

External interface changes:
osNpcCreate with options:
1) Modify the options so that OS_NPC_CREATOR_OWNED and OS_NPC_NOT_OWNED are bit masks. CREATOR_OWNED overrides NOT_OWNED.
2) Add a new option, OS_NPC_SELF_OWNED, which gives the NPC and therefore the scripts in all of its attachments the same permissions as its creator.

For *ALL* ossl functions, modify the threat level checker: If the owner of a script is a self-owned NPC, use the NPC's creator rather than the NPC itself for permission checking.

OS_NPC_SELF_OWNED cannot be the default and a warning needs to be documented. This option should only be used when the associated NPCs are strictly controlled by the script owner. Otherwise, for example, a clone on touch script would essentially allow anyone who could touch the object to exploit this function gaining all the owner's ossl permissions.

That's just one thing that can go wrong and there may be more I haven't considered, which is why I'd like this idea examined before attempting to implement it.
melanie (administrator)
2019-05-26 13:42

An "owned" NPC already has the parcel permissions of it's owner and in fact the LSL permissions of the owner should have been used to check NPC script perms in the first place. The UUID of NPC is ephemeral and should not be used for any permissions checking.
The idea was that an owned NPC is, for all intents and purposes, it's owner as far as rights are concerned, while an unowned NPC is no one at all. Because of that, no additional type of NPC is needed.
It is incumbent on the script creator to use an identity that has only the needed rights as the owner of the prim creating the NPC. If that is not the case, interesting times could come.
However, I would suggest that certain script functions like osConsoleCommand etc (or whatever it's called) would be disabled for NPC in the first place, and also one could see how a NPC being created inside a touch or collision event maybe should get the permissions and ownership of the person touching the prim, rather than those of the prim owner.
The prim owner, if it is really desired for the prim owner to own the NPC instead of the person touching the prim, could create the NPC via link message to easily circumvent this behaviour.
CrasherRob (reporter)
2019-05-27 08:12
edited on: 2019-05-27 08:15

Maybe I've been chasing ghosts. The original scripting problem that didn't work for me was osGetPrimitiveParams. This doesn't work when run from an NPC because it refuses to work if the script owner isn't the same owner as the target uuid.

This problem (for me) occurs in LSL_Api.cs GetPrimitiveParamsEx. It returns an empty string because the script owner's UUID (the NPC's) doesn't match the prim's owner. I haven't found any calls to GetPrimitiveParamsEx other than that one. I don't know why this restriction exists. Perhaps it can be removed?

melanie (administrator)
2019-05-27 08:25

The restriction exists because the function can be used to spy out the parameters for prims so sompletely that an object can be copied that way, without having copy permission. You should probably use a rezzed prim to hold a script the NPC can interact with that can perform such queries on the NPC's behalf. Ideally, NPC should not carry scripted attachments, the prim that controls the NPC should do all the work.
CrasherRob (reporter)
2019-05-27 10:01

OK, unless you really think osDetectedSize is a good idea (I don't any more,) please resolve this with some sort of "won't fix" code.

There are alternate ways, such as a relay script of obtaining the size of objects from a sensor method. In any case the bounding box, obtained via llGetBoundingBox, is likely to be more useful information in this case.

As an aside, it might be better in some cases for an NPC to at least partially control itself. Listen and sensor events need to be detected close to an NPC and relaying this information to a controller delays real time events and adds to the sim load. Besides that it's just an interesting experiment. Start coding and see what happens.

Thanks for all of your help and advice.
BillBlight (developer)
2019-05-27 10:05

Patch will not be included , due to functionality desired being available with other LSL functions.

- Issue History
Date Modified Username Field Change
2019-05-25 09:54 CrasherRob New Issue
2019-05-25 09:54 CrasherRob File Added: detectedsize.patch
2019-05-25 09:56 CrasherRob File Added: Test_DetectedSize.lsl
2019-05-25 10:53 CrasherRob Note Added: 0035249
2019-05-25 11:11 BillBlight Note Added: 0035250
2019-05-25 11:11 BillBlight Assigned To => BillBlight
2019-05-25 11:11 BillBlight Status new => patch included
2019-05-25 15:00 BillBlight Note Added: 0035251
2019-05-26 09:53 CrasherRob Note Added: 0035252
2019-05-26 13:42 melanie Note Added: 0035253
2019-05-27 08:12 CrasherRob Note Added: 0035255
2019-05-27 08:13 CrasherRob Note Edited: 0035255 View Revisions
2019-05-27 08:15 CrasherRob Note Edited: 0035255 View Revisions
2019-05-27 08:25 melanie Note Added: 0035256
2019-05-27 10:01 CrasherRob Note Added: 0035257
2019-05-27 10:05 BillBlight Note Added: 0035258
2019-05-27 10:05 BillBlight Status patch included => resolved
2019-05-27 10:05 BillBlight Resolution open => no change required

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker