Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006025opensim[REGION] OpenSim Corepublic2012-05-21 18:522013-01-05 00:58
Reporterslow putzo 
Assigned Tojustincc 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformanyOSanyOS Versionany
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0006025: Expand the function llRequestPermissions to always auto grand permission for an NPC
DescriptionExpande the llRequestPermissions statement to always grant the request without doing the dialogue. That would allow existing scripts to work, that ask for permission expecting the permission to be granded by the avatar. This would only happen for an NPC and not a normal avatar.

Since the NPC is not able to know it has received a dialogue menu request, it can never answer it. By giving an automatic grant, the "yes" answer would be assumed for NPC's and most existing scripts using this statement which are not in the prim the NPC is sitting on would work as if it had given the dialogue and received a yes answer.

TagsNo tags attached.
Git Revision or version numberOSgrid 0.7.4 (Dev) 4186fa1: 2012-05-07
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBasicPhysics
EnvironmentMono / Linux64
Mono Version2.8
ViewerImprudence 1.5 Beta 2
Attached Filespatch file icon 0001-Mantis-6025-llRequestPermissions-auto-grant-for-NPCs.patch [^] (2,546 bytes) 2012-05-22 22:16 [Show Content]

- Relationships
related to 0006441closedjustincc Reconsider mantis fix http://opensimulator.org/mantis/view.php?id=6025 [^

-  Notes
(0021481)
Talun (manager)
2012-05-22 22:15

I have created a patch that I hope will be acceptable.

The changes I have made only apply to NPCs.

The script requesting the permissions must either be owned by the NPC or, if the NPC was created as an "owned" NPC, the NPCs owner.

The changes do not affect the behavior of the implicit permissions when sitting etc, this only applies when permissions requested exceed the implicit permissions.
(0021482)
slow putzo (reporter)
2012-05-22 22:44

I am not able to test the patch as I only use the OSGrid distributions of the code.

I suspect if it does what you suggest, it will work.

My specific problem is the prim that the script is in is not the prim the NPC is actually sitting on. When it requests permission to animate, which results in the dialogue window, it never gets permission. If it was the prim the NPC is siting on the permission would be granted automatically without the dialgue window. I believe your fix will accomplish the same thing by auto granting NPC's permissions of YES.
(0021486)
Talun (manager)
2012-05-23 07:51

I tested this with an NPC and an avatar wearing an attachment that requested PERMISSION_TRACK_CAMERA, the NPC auto granted the permissions while the avatar was still prompted.

I also tested with a prim that would try animate using a given avatar key. This object was owned by the NPCs owner and the NPC again auto granted permissions and normal avatars were prompted.
(0021533)
slow putzo (reporter)
2012-05-26 00:44

Once this is incorporated into the released code it should open up all sorts of new possibilities for the use of NPC's.

Looking forward to being able to test it out.
(0021534)
justincc (administrator)
2012-05-26 00:45

Changing to patch included since I almost missed this from my weekly patch scan.
(0021536)
justincc (administrator)
2012-05-26 01:15

Applied as git master 0b72f773. Thanks Talun.
(0023174)
slow putzo (reporter)
2012-11-22 20:50
edited on: 2012-11-22 21:16

This fix requires the NPC to be an "owned" npc but for some reason when I make an owned NPC I am not able to sit on the dance balls rezzed by a dance stand. If I use "unowned" npc it can sit on the ball but the permissions are not granted when requested to animate the NPC.
 
Does it make a difference if the NPC is owned or not? Why not just give positive permissions to any NPC?
 
I do not know why I am unable to have an "owned" npc sit on the ball, maybe that is the real problem. It does not fail with any errors, the npc just does not move when the osNpcSit is issues.
 
The only difference I have made when testing is to change between owned and unowned. Everything else remains exactly the same.
 
Please reconsider the implimentation of this fix and include "unowned".

Here are some things to consider in the environment I am testing in.

The dance stand may or may not be owned by me.
The dance balls are unlinked objects rezzed by the dance stand for the avatars to sit on. They do not animate the avatar, but rather let the dance stand animate them by sending the dance stand their UUID. This means the object animating the NPC is not the object it is sitting on.

The NPC is wearing a controller and is rezzed by another object called the "Genie bottle".

The NPC may or may not have been created by me.
The controller it is wearing may or may not be owned by me.

The Genie bottle which rezzes the NPC may or may not be owned my me.

Because of the wide range of ownerships involved the NPC is created as unowned.

I did test with me as the owner of everything and made the NPC "owned" but it still could not sit on the balls rezzed by the dance stand. When it is "unowned" it is able to sit just fine, but can not be animated by the dance stand because it is not able to grain permissions to be animated.

Since I can not have it sit as an "owned" NPC I can not test if the permissions are granted in that configuration.

My project is making a Genie bottle which contains several different NPC Genies. The NPC wears a "Genie controller" which produces a menu for that specific Genie. You can send it around the sim and have it sit on different objects within a specific range of the Genie. It works just fine for objects that directly animate the Genie, but does not work for objects like a dance stand where it rezz'e the sit balls and then has the balls communicate back to the main controller telling the main controller what the UUID is for the avatar it is to animate.

When the main controller does this, a normal avatar receives the menu dialog to give permissions to animate the avatar by clicking on the "yes" or "no" button. Of course the NPC can not do that, and I see no reason to restrict the automatic granting to an NPC to only "owned" NPC's.

That adds a requirement that everything on the sim be owned by the same person including the NPC and anything they may be wearing that you want to interact with.

(0023356)
justincc (administrator)
2013-01-02 19:56

Okay, in git master 30e5e5c, I have changed the code so that unowned avatars should be also automatically granted permissions. This is consistent with the behaviour of all the OSSL NPC functions. Please tell me if this resolves your issues, slow putzo.

From what you've written, I suspect you're having issues sitting owned NPCs because some of the other scripts don't have the same owner as the rezzing script.

Using unowned NPCs is not great because they can be generally manipulated. It might be better to come up with a better approach in the future, maybe by giving an NPC a secret on creation that can then be passed to other scripts that should be able to manipulate it, rather than relying on the owner enforcement.
(0023379)
slow putzo (reporter)
2013-01-04 03:28

Justin,

Thank you so much for considering this change. It works perfectly, and the NPC's are busy using almost everything now on my sims.

The few things I still need to work out are most likely not opensim problems but rather bad scripting, or simply something not possible to do.

You can close this as I have fully tested it against the objects I was using when I made the original request.

Thanks again.

- Issue History
Date Modified Username Field Change
2012-05-21 18:52 slow putzo New Issue
2012-05-22 22:15 Talun Note Added: 0021481
2012-05-22 22:16 Talun File Added: 0001-Mantis-6025-llRequestPermissions-auto-grant-for-NPCs.patch
2012-05-22 22:17 Talun Status new => patch included
2012-05-22 22:44 slow putzo Note Added: 0021482
2012-05-23 07:51 Talun Note Added: 0021486
2012-05-24 02:51 justincc Assigned To => justincc
2012-05-24 02:51 justincc Status patch included => assigned
2012-05-26 00:44 slow putzo Note Added: 0021533
2012-05-26 00:45 justincc Note Added: 0021534
2012-05-26 00:45 justincc Status assigned => patch included
2012-05-26 01:15 justincc Note Added: 0021536
2012-05-26 01:15 justincc Status patch included => resolved
2012-05-26 01:15 justincc Resolution open => fixed
2012-11-22 20:50 slow putzo Note Added: 0023174
2012-11-22 20:50 slow putzo Status resolved => patch feedback
2012-11-22 21:06 slow putzo Note Edited: 0023174 View Revisions
2012-11-22 21:08 slow putzo Note Edited: 0023174 View Revisions
2012-11-22 21:10 slow putzo Note Edited: 0023174 View Revisions
2012-11-22 21:16 slow putzo Note Edited: 0023174 View Revisions
2012-11-24 03:14 justincc Relationship added related to 0006441
2013-01-02 19:52 justincc Status patch feedback => new
2013-01-02 19:56 justincc Note Added: 0023356
2013-01-02 19:56 justincc Status new => feedback
2013-01-02 23:28 justincc Status feedback => resolved
2013-01-04 03:28 slow putzo Note Added: 0023379
2013-01-04 03:28 slow putzo Status resolved => patch feedback
2013-01-05 00:58 justincc Status patch feedback => closed


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker