Kitely Forums

There are several issues here:
1) How permissions are defined and changed inworld.
2) How does Kitely Market decide which permissions to give a delivered item.
3) How the effects of item permissions change what can and can't be done by a script you own.

Issue 1:
Inworld permissions are changed in Kitely (and OpenSim in general) the same way they are changed in Second Life. Please read about how object permissions are changed when you modify a contained object here: https://community.secondlife.com/t5/Eng ... a-p/700129 please also note how Folded Permissions work (see: http://wiki.secondlife.com/wiki/Debug_Permissions)

As you'll note there are several ways in which permissions do not behave (in Second Life and OpenSim) as you might expect. We would have designed a different permissions system but that is how Second Life / OpenSim was designed and we aim to maintain compatibility with OpenSim when it comes to the basic logic behind object permissions.

In your first scenario you've made changes to permissions of items while they are inside other items, this can result in behaviors that are different from what you expect (again, as per the Second Life wiki). My suggestion is that you only set the permissions of your chair while it isn't inside the table and only then add it to the table's contents. In other words, if you want to avoid surprises don't use features that cause a delayed application of item permissions and if the change you're about to make is going to use the Slam Bit then avoid doing it (again, this is all by Second Life design).

Issue 2:
Kitely Market is not involved in any way when someone buys items inworld, that is handled exactly as it is in standard OpenSim 0.8.3 (i.e. in what is now the latest official OpenSim release). Meanwhile, the Kitely Market delivery system doesn't apply changes to permissions using the OpenSim code so if you want to test how things will work when people buy from Kitely Market you'll need to test it via Kitely Market not via an inworld transaction.

The Kitely Market delivery system uses the Next Owner object permissions that are actually defined inside the object when you add it to a listing. You'll note the exact state of those permissions in the Variation Items table in the product listing. If anything there doesn't match the Next Owner permissions you see in your inventory then your inventory probably includes items with Slam Bits set that will apply changes to your inventory items once those items are rezzed. You'll need to rezz the item to have the delayed permission changes applied then modify the item's permissions as you see fit and only then add it back inside another item or directly into your inventory. If you do it in another way then (a) you're ignoring the Second Life wiki's recommendations and (b) you're not going to get what you expect.

Issue 3:
Given the additional information you provided it sounds like you're encountering an issue that results from a delayed application of permission changes.

In your first scenario the rezzed chair behaved like the permissions you gave it while it was inside the table but the viewer displayed permissions that look different from what you expect (probably the ones the chair had before you made the change to its permissions). There is obviously a difference here between what the server allows you to do with the script-rezzed object (which sounds like the permissions you gave it) and what permissions the viewer displays (whose origin I don't have enough information to determine). In other words, you set the chair to be mod/copy/notrans and it behaves like mod while the viewer is showing something else. In other words, it sounds like the permission system is enforcing the permissions it should but the viewer is not displaying them properly (which is a problem but not with the permissions system).

In your second scenario it isn't clear whether the buyer of the item is the same avatar who created the item and/or the owner of the item on sale. Are you making sure to run this test with an avatar that is different from the owner and creator of the item that is being sold? If the buyer is the same as the seller then the buyer will have permissions that other buyers may not. It is very important that you extract all the relevant items, set their Next Owner permissions correctly and only then place them inside each other and take it into your inventory. Then add them to Kitely Market to see what Next Owner permissions that actually have and only if you see the permissions you expect to see then you should expect the Kitely Market delivered item have the current owner permissions you wanted it to have. (this is one way in which the Kitely Market Variation Items table can help you debug your items, you can see other ways here: https://kitely.atlassian.net/wiki/displ ... g+Products).

TL;DR You've shown that things don't behave as you expect them to but (a) your reasoning that it proves the permission system is broken may be wrong and (b) we haven't ruled out the way you're applying the permissions not being the source of the problems you're encountering. Please test using the Variation Items method I described above and, once you make sure the listed permissions are as you intend them to be, please test using the Kitely Market Test delivery feature.

Now, I have gotten things with my multichairs so that I can sell them on the market. The scripts have the perms copy/mod/notrans, which allows them to function properly, so the table rezzes chairs, the table and chairs talk to each other, and the table can move the chairs around in the circle as people sit or get up, and new chairs are rezzed or die. I have also determined that as long as the scripts are notrans, others cannot read the code, which is good.
HOWEVER:
I would like to introduce a product in which my scripts reside in prims I made, so that other furniture creators can make multichairs with their own designs, linking them to my prims as the root prims in the table and chair linksets, for sale on the market, etc, but which disallows people to read the script code. The scripts will change their behavior based on a notecard the furniture maker puts in the contents, which controls how many chairs are rezzed, what the chair is called, sit position and rotation, etc. The problem is that, apparently, unless the scripts themselves are mod, they won't function properly, as if you guys have set the mod permissions to cause nomod scripts to not be able to save anything to memory, to change the value of variables, etc. This prevents me from providing my scripts for sale to other content creators in a secure fashion. This is mandating that furniture makers come to me with their designs to be made into multichairs so that I sell them in my store on the marketplace, or in vendors I own placed in their stores inworld. This sort of limitation did not exist in SL, and I'm not sure why. I am very curious as to why making a script nomod makes it unable to store variable data in memory.

Mike Lorrey wrote:The problem is that, apparently, unless the scripts themselves are mod, they won't function properly, as if you guys have set the mod permissions to cause nomod scripts to not be able to save anything to memory, to change the value of variables, etc.

Permissions on scripts don't affect their ability to store variables - my own scripts are normally sold as no-modify and function fine. Can you be more specific about what you're attempting to do here?

Handy Low wrote:

Mike Lorrey wrote:The problem is that, apparently, unless the scripts themselves are mod, they won't function properly, as if you guys have set the mod permissions to cause nomod scripts to not be able to save anything to memory, to change the value of variables, etc.

Permissions on scripts don't affect their ability to store variables - my own scripts are normally sold as no-modify and function fine. Can you be more specific about what you're attempting to do here?

Well, as I mentioned earlier in the thread, my products are multichairs, i.e. you have a table with the controller script in it, and an example chair. The controller rezzes the chair next to the table, and rotates it around the table 180 degrees with the sit position facing the table. When an avatar sits on the chair, it creates a new chair in the original position across from the sitter. When the second chair is sat upon, a third chair is rezzed, and all three chairs are evenly distributed around at 120 degree intervals, four chairs redistribute to 90 degrees, etc etc etc up to whatever seat capacity I specify in the script. When an avatar gets up, the chair is deleted, and the remaining chairs redistribute evenly around the table. This is the PROPER functon of the script.

When I set the scripts to nomod, here is what happens: the first chair rezzes in the proper place but does not move around the table 180 degrees, the sit position is facing away from the table. If you sit on it, the second chair rezzes 90 degrees away from the first one, both facing in the same northward direction, i.e. not facing the table, so the chairs are not being redistributed, nor are they being rotated to face the table, nor do they delete when you get up. If you sit on the second chair, a third chair rezzes in exactly the same location. So, the table and chair do not talk to each other, nor is the controller moving them, nor is the controller remembering where chairs are or what to do with them.

Note: This malfunction only occurs when the multichair has been purchased, either through the market or inworld, and rezzed by the purchaser. They work fine for me in my possession, even if I buy it from myself.

Sorry, I should have been clearer. I mean, when you say:

you guys have set the mod permissions to cause nomod scripts to not be able to save anything to memory, to change the value of variables, etc.

what kind of variables are not being stored? And what do you mean by "etc"?

When describing to others problems with code, it's always helpful to narrow the problem down to the simplest case. You describe very well how the product malfunctions in practice, but without being able to see the source code it's very difficult for someone else to diagnose what's wrong with it based on that description. And since you doubtless don't want to share your source code (understandably so!) it would help greatly if you could provide a small, but self-contained and complete, example of code that doesn't work when the permissions are changed. The time spent whittling down a program into a small demonstration like that is well-spent if you want others to be able to understand your issue.

Some things to check meanwhile:

1. Do you make use of any os* functions in your scripts that require a certain threat level? For example, if your script attempts to move the chairs using osSetPrimitiveParams(), it will work for you fine - but if someone purchases it and then tries to use it on land that they don't own, it will fail and give an error message (see 3 below). I would start looking into this first - I think it's the most likely cause of a problem like you describe.

2. Does the script attempt to do something to other objects that requires modify permission, but the objects are set to no-modify for next owner? For example, if your script attempts to delete a notecard, but the notecard or the containing object are no-modify for the purchaser.

3. When the purchaser uses the item, do they get script error messages? I find that sometimes people don't understand what those messages are and ignore them.

4. Do you have an alternative account that you can use to purchase your product and test it? It's always useful to have one so that you can examine the permissions, etc of the purchased product.

Handy Low wrote:Sorry, I should have been clearer. I mean, when you say:

you guys have set the mod permissions to cause nomod scripts to not be able to save anything to memory, to change the value of variables, etc.

what kind of variables are not being stored? And what do you mean by "etc"?

When describing to others problems with code, it's always helpful to narrow the problem down to the simplest case. You describe very well how the product malfunctions in practice, but without being able to see the source code it's very difficult for someone else to diagnose what's wrong with it based on that description. And since you doubtless don't want to share your source code (understandably so!) it would help greatly if you could provide a small, but self-contained and complete, example of code that doesn't work when the permissions are changed. The time spent whittling down a program into a small demonstration like that is well-spent if you want others to be able to understand your issue.

Some things to check meanwhile:

1. Do you make use of any os* functions in your scripts that require a certain threat level? For example, if your script attempts to move the chairs using osSetPrimitiveParams(), it will work for you fine - but if someone purchases it and then tries to use it on land that they don't own, it will fail and give an error message (see 3 below). I would start looking into this first - I think it's the most likely cause of a problem like you describe.

2. Does the script attempt to do something to other objects that requires modify permission, but the objects are set to no-modify for next owner? For example, if your script attempts to delete a notecard, but the notecard or the containing object are no-modify for the purchaser.

3. When the purchaser uses the item, do they get script error messages? I find that sometimes people don't understand what those messages are and ignore them.

4. Do you have an alternative account that you can use to purchase your product and test it? It's always useful to have one so that you can examine the permissions, etc of the purchased product.

1. I am using solely lsl code that functioned perfectly in SL and I never had this sort of problem selling products with the scripts nomod. There's no os functions whatsoever.
2. The only thing the control script modifies is the chairs that it rezzed, which are mod/copy, and its only moving them and rotating them, and telling them to die.
3. The purchaser gets no script error messages.
4. I have an alt account that I've used to test it and this is how I am able to report this malfunctioning in detail.

In that case, I suggest whittling the code down to just the function(s) that misbehave, and sharing that with us. I'm sure we can figure out what's happening from that.

Handy Low wrote:In that case, I suggest whittling the code down to just the function(s) that misbehave, and sharing that with us. I'm sure we can figure out what's happening from that.

Yeah I think this is a good idea, isolate the issue and then throw the code in here.

By the sounds of this it doesn't sound like a permission issue at all since the chair is rezzing and from you have said the script inside of the chair is in there as well (If the object or the script didn't have the right copy permissions you wouldn't have one left in the main object). So to help with that we would need to know how exactly its communicating with all of the objects. I'm assuming its all via listen events so you might have to double check that if you are sending channels via on_rez or something simular that they are being consistent with the main objects listen channel and whatnot.

As for variables that are defined within the script and set should be stored. Unless you're loading this script in an object in world and adding a variable to it (like using a channel call to define it while its running and not hardcoding it inside) and then taking the object back into your inventory, there could be a chance that the stored variable would be lost. I have done some testing and sometimes when items are thrown through the hypergrid the script is started as if it was just compiled on the other end but every time I have seen this at least with objects being rezzed out by another object the on_rez call is still fired (Thought id throw this out there just in case this is how you're doing it).

As for broken permissions on kitely, I haven't had one problem with them so far and I have done things in a simular situation as you and have tested it extensively with my own grid I had running as well as alt delivery etc. I would love the export button to be able to be ticked if its not full perm inworld though! *hint hint Ilan wink wink wink wink wink* But other than that perms have been pretty strait forward.

Hi Kurtis,

Reading your comment I think it's important I remind anyone reading this thread that Kitely's export controls aren't connected to the viewer Export flag settings.

Exportability in Kitely is defined differently for items that were bought in Kitely Market than for items which weren't delivered from our marketplace. Items bought in Kitely Market use the Export setting in the product listing they were purchased from, while objects that weren't delivered from Kitely Market need to have Copy+Transfer permission to be exportable.

See: https://www.kitely.com/virtual-world-ne ... plemented/ and https://www.kitely.com/virtual-world-ne ... rmissions/

Oh I know Ilan I'm just meant it as a light hearted joke Its a box and I need to tick it!