MOVING FULL PERM vs NO MOD NOTECARDS INTO HUD PRIM - GRRRR ISSUES!

[Pixels Sideways]

Hiiii

So I am trying to wrangle my insanely large inventory.

I have thousands of notecards, many which I can delete but need to look at them first.

To better manage this in the interim, I created a simple full perm cube with a full perm hover text in it to wear as a HUD.

So, for example, I can wear the HUD which I named after a shop - let's say Pixels Playhouse.

I edit my script inside to add the name to the hover text. 

I have 50 Pixels Playhouse notecards which are full perm.  I grab them all and slide them into my HUD, then delete them from my inventory . Voila! Chef's kiss.  I detach the HUD that now has all my note cards.  I've reduced my inventory by 49 items. I can reattach and add notecards as I receive them in the future.  This allows me to work in no rez areas if need be.   Plus I don't create duplicates by rezzing. 

What a nifty idea Pixels.  Yes, i thought so until I tried to do the same with notecards that are no mod.  I cannot slide from my inventory no mod notecards into the attached HUD's contents.

I can, however, rez the HUD prim on the ground and slide them into the prim with no issue.  But taking this back into my inventory means I now have this new version in addition to the previous version. What a PITA!  My inflated genius has been dashed onto the rocks of my hubris.

So whyyyyyyyy does SL mock block me re no mod or no mod/no copy or variations on perms when placing items - in this case notecards - in an attached HUD prim but has no issue moving same items into a rezzed prim?

Either I am not doing something with key combos or Linden Labs should fix this since this HUD storage box solution enables us to create and manage storage boxes and content without having to rez or duplicate the storage boxes.

Anyone know why this is set up like this and if there is something I am unawares of to make this work?  

If I could get this to work regardless of the item's perms. I would do this with other items in my inventory like textures which would significantly reduce my inventory and make is far more manageable.  I could even spend more time hanging out at your events while I work on my inventory!  Win/win!

If I can't get the no mod no copy items to move seamlessly into the attached HUD and I have to rez it, , I'd like to add some code to the script that aromatically updates the object name + adds the date/time.  I will ask about that on the scripting forum section unless someone wants to add it here.

Thank you.

xo  pixels sideways / Moon Mittens

Edited March 12, 2022 by Pixels Sideways

[Emma Krokus]

once all the new notecards are in your rezzed HUD, simply rename it - i typically do name of object followed by 2022_03_12 as an example - no need for a script

[Pixels Sideways]

 

 

Of course that would be the regular method.  I still want to be able to move my inventory content into the attached HUD without rezzing and if not, if I have to rez the HUD prim, I want the script to do the not so heavy lifting bc LSL can do lots of cool things. 

 

[Qie Niangao]

Something to try, which I do to add animations to an AO without having to detach it: Make another scripted, unattached object that listens for your attached HUD to tell it that HUD's key and for a new inventory item (a notecard in this case) to appear in inventory, then it copies the item to the attached HUD with llGiveInventory(). 

There may be some permissions trickiness or other niceties here, but something like this should work.

[Henri Beauchamp]

10 hours ago, Pixels Sideways said:

So whyyyyyyyy does SL mock block me re no mod or no mod/no copy or variations on perms when placing items - in this case notecards - in an attached HUD prim but has no issue moving same items into a rezzed prim?

.../...

Anyone know why this is set up like this

This is because inventory permissions and rezzed objects permissions are not inherited while an object is attached to you avatar.

For the inventory permissions to be updated with regards to what items are added to (or removed from) the object contents, SL needs for the sim server to transmit the object data to the inventory server, and this is done when you derez the object (or take a copy, when it is copy-ok) to your inventory.

Currently, and given how things work, allowing to add no-copy or no-transfer item inside a worn attachment which is itself copy-ok or tfr-ok would allow you to bypass the permissions (since the object in your inventory would not have its permission changed: you would then be able to copy or transfer it with the no-copy or no-transfer item inside). This is why SL forbids it.

There is however indeed a ”quirk” that I consider a genuine bug in SL permissions inheritance, and this relates to no-mod items added to the contents of a mod-ok object: currently, when you do that (with an object rezzed in-world), the object becomes itself no-mod when you take it back to your inventory; this is of course totally stupid and uncalled for, since a mod-ok object may perfectly contain no-mod items and nothing you can do with that object at the inventory level (like changing the object name, copying it or giving it away, as long it is copy-ok or tfr-ok) would change anything to the no-mod permission (or name, or asset data) of the no-mod items it contains. Note that as long as you are the object creator, you still can edit the inventory object permissions to make it mod-ok (for the next owner) again, but if you pass a copy to another avatar, then they will loose that mod-ok permission as soon as they rez the object in-world and take it back to their inventory, and they won't be able to make the inventory object mod_ok again.

Edited March 12, 2022 by Henri Beauchamp

[Qie Niangao]

10 hours ago, Henri Beauchamp said:

There is however indeed a ”quirk” that I consider a genuine bug in SL permissions inheritance, and this relates to no-mod items added to the contents of a mod-ok object: currently, when you do that (with an object rezzed in-world), the object becomes itself no-mod when you take it back to your inventory; this is of course totally stupid and uncalled for, since a mod-ok object may perfectly contain no-mod items and nothing you can do with that object at the inventory level (like changing the object name, copying it or giving it away, as long it is copy-ok or tfr-ok) would change anything to the no-mod permission (or name, or asset data) of the no-mod items it contains. Note that as long as you are the object creator, you still can edit the inventory object permissions to make it mod-ok (for the next owner) again, but if you pass a copy to another avatar, then they will loose that mod-ok permission as soon as they rez the object in-world and take it back to their inventory, and they won't be able to make the inventory object mod_ok again.

I must be missing a step here. This doesn't seem to happen when I try to replicate these steps (as I understand them). For starters, the viewer won't let me "edit the inventory object permissions to make it mod-ok (for the next owner) again" while the object is still in inventory, but maybe that wasn't the intent (of course it's still mod-ok if I rez it again). Anyway, the recipient can rez and modify the object (despite it being no-mod in Inventory).

Admittedly, my understanding of the whole "slam-bit" behavior of the SL next-owner permissions system has a short half-life: Every time I want to use it I have to re-read the wiki article on it and/or consult a "cookbook" notecard that describes how to use it in conjunction with wearing an item from in-world (not Taking into Inventory) to be able to adjust its Inventory permissions while attached, then detaching it into Inventory to delay slam-bit application of permissions until a recipient rezzes it.

[Henri Beauchamp]

18 minutes ago, Qie Niangao said:

the viewer won't let me ”edit the inventory object permissions to make it mod-ok (for the next owner) again” while the object is still in inventory, but maybe that wasn't the intent (of course it's still mod-ok if I rez it again).

For it to work in the inventory, the object itself must be mod-ok for you, and you must be the creator of all no-mod items you have put inside it (e.g. no-mod scripts you wrote).

Edited March 13, 2022 by Henri Beauchamp

[Qie Niangao]

6 minutes ago, Henri Beauchamp said:

For it to work in the inventory, the object must be mod-ok and you must be the creator of all no-mod items you have put inside it (e.g. no-mod scripts you wrote).

Guess I'm still missing something. If the embedded script I created is set no-mod only for Next Owner then the whole no-mod object is still mod-ok when taken into my Inventory. (Of course if I actually transfer the script so the Next Owner permission is applied making it really no-mod, transferring it back to its creator doesn't change that permission to make it mod-ok again.) I'm sorry, I'm still confused.

[Henri Beauchamp]

1 hour ago, Qie Niangao said:

Guess I'm still missing something. If the embedded script I created is set no-mod only for Next Owner then the whole no-mod object is still mod-ok when taken into my Inventory. (Of course if I actually transfer the script so the Next Owner permission is applied making it really no-mod, transferring it back to its creator doesn't change that permission to make it mod-ok again.) I'm sorry, I'm still confused.

Perhaps I have not been clear enough in my first post... Using a mod-ok object as the container, with it rezzed in-world:

1. Adding a no-mod item you do not own (e.g. a no-mod script made by someone else), makes the container no-mod for yourself when taken back to your inventory, while you still can modify it when rezzed in-world (of course the object is also made no-mod for ”next owner”), and you cannot change anything to its mod permissions from the inventory.
2. Adding a no-mod item you created (and therefore for which you got mod-ok permission for yourself) makes the container no-mod for the next owner when you take it back to you inventory (but then, you may change this ”next owner” permission from the inventory item properties floater).

[Qie Niangao]

6 minutes ago, Henri Beauchamp said:

Adding a no-mod item you created (and therefore for which you got mod-ok permission for yourself) makes the container no-mod for the next owner when you take it back to you inventory (but then, you may change this ”next owner” permission from the inventory item properties floater).

Oh thanks, now I think I understand what you mean, and that certainly does lead to confusion. I think my confusion here was that (as far as I know) the object still nonetheless arrives mod-ok transferred to the next owner, notwithstanding what it says in Inventory. At least when my test recipient got the item and rezzed it, the container was still modifiable—which seems counter to this point

13 hours ago, Henri Beauchamp said:

but if you pass a copy to another avatar, then they will loose that mod-ok permission as soon as they rez the object in-world and take it back to their inventory, and they won't be able to make the inventory object mod_ok again.

so probably there are circumstances I'm still overlooking.

Not sure what's become of our OP @Pixels Sideways though, so I'm feeling a little guilty they're not getting the help they wanted.

[Pixels Sideways]

Thank you Henri Beauchamp for the explanation.  And thanks to everyone who responded.

 

I see this as a fault in the SL system - whether razzed or attached to avatar or HUD, permissions should be consistent and always function the same way.  

When I add the no mod notecards to my razzed full perm prim and take it back into my inventory. the prim will become no mod as Henri pointed out and yet I can still add as a HUD and look at the contents.  I just can't add anything when the prim is worn..  So it should be able to do likewise - add any type of perm content if the prim is worn as a HUD or attached to my avatar.  Not sure if this is something @Linden Lab can fix/update. I'll submit a Jira if there is not one already.

The point of this is being able to consolidate inventory items into  prim boxes in areas where one does not have rez rights.  

Residents who have large inventories would understand what a game changing convenience this would be regarding inventory management.  Or anyone for that matter especially when one collects free gifts at events like the SL Shop n Hops, Advents, etc., and does not want to open right away and clutter and increase  their inventory.