Drop Object, Edit Object, Take Object - Permissions Borked!

what's up with this?

now i know that inventory permissions are different from in-world permissions. if a fully mod/copy/transfer object has any non-mod and/or non-copy components, the inventory permissions tell me it is no touchy. even though it technically isnt.

but i'm talking about when you have an object in your inventory, and it is full mods (or no transfer at most). then after putting it on the ground and editing it, you take a copy back, and suddenly, it's no-mod and/or no-copy.
and not JUST in inventory. you throw it back down, thinking, "oh, there's just a script in there that's no mod, no big deal" but you right click to edit, and it tells you: 'you do not have permission to modify this object.'

why does this happen, and how can it be prevented?

Permissions can be delayed. There's a KB article somewhere, but basically permissions only take effect when the object is rezzed in world. If you change the permission on an object whilst it is in the inventory or worn, that permission is delayed, and will only take effect when the object is then rezzed.

If you are creating attachments it is always a good idea to drop the attachment before you start selling or giving it away. I'm guessing that this is an object from someone else, who didn't do this.

Matthew

so back to the question i had months ago...

what is the proper order for setting proper permissions?

1: set in-world permissions.
2: set inventory permissions.

or

1: set inventory permissions.
2: set in-world permissions.

???

The issue is what I'd call, "permissions conglomeration".

When you take an object into inventory, SL conglomerates all the permissions that you (and the next owner) have on any part of that object. Or to be precise, it conglomerates all the permissions that you _lack_, and those will be the permissions that you _lack_ on the object in inventory.

So, if you put a no transfer script inside a full perms object, then pick it up, it will be no transfer. This is well known. The most obvious problematic example is if you put a no modify script inside a full perms object, it will show up in your inventory as no modify, even though you *can* in fact modify the prim model because that isn't the no-modify bit. This causes a few glitches (you can't rename it in inventory, but you can rename it if you rez it) but we're still basically tuned into sanity FM.

Where it becomes weird, freaky and bizarre is this. Permissions conglomeration happens ONLY AT THE MOMENT YOU TAKE AN OBJECT INTO INVENTORY. Which means that if you take the object into inventory and then CHANGE the permissions somehow, it will continue to have those changed permissions in inventory.. but the moment you REZ it, all of the permissions for its component parts will come into force. Ok, fine.. but also, the moment you TAKE it (and if it was no copy, that's the only way you'll be getting it back into inventory), THE CONGLOMERATION PROCESS WILL RERUN, possibly resulting in your LOSING some permissions you previously had!

For example. I make an prim object and I set it "next owner: no copy, yes transfer". Then I put a script inside it, and I set the script "next owner: yes copy, no transfer". I then take the object. This makes conglomeration run, so when I look at properties from inventory, I will see: "next owner: no copy, no transfer". It has conglomerated the permissions that were LACKING. I then check the "next owner: transfer" box, granting transfer permission, and give the object to you. I can do this because conglomeration will not run again until the object is picked up from in-world. Until that happens, because I made the object, I can set the next owner permissions however I want.

You will be able to transfer the object.. as long as you don't rez it. But when you *do* rez it, suddenly, SL will notice that there's a no-transfer script inside there. And when you pick it up, the conglomeration process will run again, and you'll have a no-copy no-transfer object. (However, if you rez the object in the world and take the script out, it'll become just plain no-copy again.)

So the answer is.. you have to set both inventory and world permissions and check that both are in sync with what you want

just checked 1 of my rez boxes after reading this and what a suprise...

all the objects inside the rezzer have their permission screwed and can`t even be changed (grayed out) untill rezzed, change them, take to inventory, add to the rezzer again and they`re screwed AGAIN
i`ve had it with this crap, good reason not to buy anything as everything is screwedup
why bother to try and make products when u can`t get the permissions right when u want to allow modify on objects just not the scripts, it keeps changing no matter what heh

knew they f`edup the permissions system with the 1.17 build(screw group building over with permissions) but didn`t knew it went this far

Okay.. did you check them right after you took them into the inventory?

*growls* I have a similar problem with just one of my objects, my empty hatbox that I use to put my merchandise in to load into vendors/warehouses.. and for some farking reason, it sets itself to NO PERMS upon being taken back into inventory, no matter what perms I had it on when I take it out to load. Strange, huh?

yea, take the rezzer out, check object inv permissions, half of them set wrong
rez the building, reset permissions, take to inventory, set permission *again*, add to the rezzer, take rezzer back, rerez the rezzer, permissions fucked again

so the backup rezzer for the house i built for a friend is as useless as her current house is with no modify (still under my name) and not to mention i can`t even start my own lil store with cheap simple 2048/4096 builds as the permissions can`t be set right

so as this is getting worse and worse, i`m done with the sarcastic jokes and just flat out say:
Linden Labs, you are a bunch of unskilled retarted coders with a screwed up client, unstable asset servers, pathetic excuse for support and think we are complete morons, you can`t even fix the billing system so fixing the client and server is like comparing an horse with an maglev train

maybe i should stop reading the forums and stay clueless like most are...wouldnt have known about this atleast heh
wonder how many products ppl have on sale and think they have the right permissions wich is screwed the moment some 1 is rezzing their product

wished i didn`t have an island and tenants i want more for in the future or i`d take an vacation... till sl v816.142.64.95.7

The only answer I have found for this is to redo the rezzer (or in my case, hatbox). Scrap it and start over. *sigh* Which is stupid, because the old hatbox was fine except for that.

even better, the last building i took into a rezbox is only a couple of days old, redo and it will be screwed still with objects in an object with scripts and diff permissions on each

retards

Yumi, great post. You covered almost all possibilities. But there is one additional oddity:



You will still be able to modify the object, even if it shows (no modify) now, because you had mod perm before. But if you trade the object, the next owner will completely lose the permission.
If you put 3rd party scripts without modify perm into a sales object, the customer will receive a no-mod copy that is really not modifiable, even if you were able to modify it despite the script.

just woke up but befor i went to sleep, guess what happend...

the friend of wich the house i built for was partially deleted 2! days ago by accident, dispite the fact it has been 2 days ago, after she deleted part of the house, she tried to use the rezbox to rerez the house and nothing happend as the objects are no copy/no mod/no transfer

so it allread affected me befor making a post after "re-discovring" the issue as she thought i`d be insulted with hearing parts got deleted by accident (that`s why u make an backup) and hear it from some 1 else 2 days after and have to fix it myself as ll fuckedup

sure ain`t helping with the mood regarding LL....morons