|
|
|
[
Permlink
| « Hide
]
Ellla McMahon added a comment - 08/May/09 08:27 AM
Although not a complete solution to your issue, please see a possible work around in some situations; Knowledge Base article How to use Undo
Hello, thank you very much i know the Undo function. But it doesnt help in some situations and not work correct. I really miss my copy function, its helpful for other operations and things too.
Qarl removed the ability to copy worn items in an attempt to fix VWR-6110.
However, it didn't fix the problem of vanishing attachments, see Baron's repro at VWR_6110 and also Maybe if that problem is fixed, the ability to copy worn items can be brought back. hm - this is problematic. but first, let me see if i'm understanding you:
you wear some hair. you edit the hair. you copy the hair while it is being worn. the new copy does NOT contain the edits you previously made. hm - that sounds like incorrect behavior... probably the very same behavior that's causing content loss in VWR-6110... Qari, you have it a bit off.
The bug is this: When an item in Inventory is worn (bolded, white), it CANNOT be copied. If you right click in the inventory list, the option to copy is greyed out in the context menu. If you press CTRL+C to copy then CTRL+V, nothing happens. If you remove the item (unbolded, normal color), you can copy it from within the inventory just fine. It's a pain because any of us who make edits to an attachment, like hair, are usually wearing it when we want to make changes. We go to make a copy for backup, then start editing the current copy. Right now, the attachment has to be removed first, which, if you're in public and want to sneak in some tweaks, can be a bit startling to others Hope that clarifies! aha. i think i got it now.
the problem is: copying a worn object is causing content loss. if you want all the programmatic details - i can happily share them with you - but they're quite tedious. so, we've intentionally removed this functionality. i understand that it's annoying to temporarily remove your hair before copying it - but weighed against the threat of content loss, i think you'll agree this is the best action. It seems a lot of the changes to the new viewer are motivated by something like this:
"This button doesn't work, so let's remove the button." Why does copying a worn object have to cause content loss? As I understand it, when you attach an item, it fetches that item and attaches it. At that point, there shouldn't be a relation between the attached item and the one in your inventory, aside from highlighting it so you know it's attached. When you detach it, it should save in place of the old one. The expected behavior is that you can copy an already-worn object to get an older, "backed up" copy of it. The issue isn't that it's an inconvenience to remove the object before copying it, it's that removing that object saves any bad edits that were made with no way to revert (since Undo is problematic and often messes an object up even worse). While people should make backups of objects before attaching them, if they plan on making edits, it often doesn't occur to them that a small edit might break their object until it happens, at which point there used to be a safe, easy way to restore it. Ephyu - actually, that's not true. a worn object in your inventory is "connected" to the item in-world - as you change the item in-world, it changes in your inventory as well.
As I said, "there shouldn't be a relation between the attached item and the one in your inventory."
If that's the case, how is the previous behavior explained, where copying a worn object reverted all changes made since attaching, as if you'd made a copy beforehand? I also know that even now, I can change an item that I'm wearing, take it off, put it back on, and have everything reverted, even if I WANTED to save those changes when I detached it. Is there any reason for the worn object to be related to the one in inventory until detached (at which point it should reliably save, as if taking rezzed copy into its place)? The presumed benefit of having a worn object actively change the one in inventory is that things would be more reliably saved, but this benefit isn't seen. I also imagine that if worn objects truly do save all changes to inventory (or attempt to), that this would create a lot of unnecessary communication with the inventory servers. Ephyu - yes, i hear what you're saying. the reasoning for this behavior (for better or worse) is for sim-transversal. anytime you move from sim to sim (via teleport, crossing, logout/login, etc.) your attachments are saved to your inventory for transmission.
imagine if you had to save your attachments every time you logged out. Wouldn't it be better to only save them in certain cases, rather than (supposedly) all the time?
I'm thinking on detach, on region crossing, on region shutdown/crash (when possible), logout, and maybe a few other cases, but shouldn't it be a case of saving and updating when needed, rather than constantly? And if it IS required that an inventory copy of the attachment always be preserved, wouldn't some kind of temporary "attached" assets be a better move, to prevent damage to the originals? I'd always thought region crossings were handled in such a way, having all your attachments saved as temporary assets for redownloading, rather than the original assets being modified.. but if it works that way, is this why going offworld, crossing regions, or teleporting during severe sim/asset server strain can result in destroyed attachments? blinks confuzzled
"a worn object in your inventory is "connected" to the item in-world - as you change the item in-world, it changes in your inventory as well." When did that change? As far as I always knew:
Case in point: change an attachment, tp around as much as you want, end up on a sim that crashes => asset never gets reuploaded => when you relog the attachment will have the state it had when you last attached it (ie none of your changes since got updated) "so, we've intentionally removed this functionality. i understand that it's annoying to temporarily remove your hair before copying it - but weighed against the threat of content loss" I'm not sure if you're understanding why being able to copy/paste a worn attachment without first detaching it is entirely necessary. Scenario:
This is vital functionality, please do not remove it. Changing title to be more clear...
> Case in point: change an attachment, tp around as much as you want, end up on a sim that crashes => asset never gets reuploaded => when you relog the attachment will have the state it had when you last attached it (ie none of your changes since got updated)
yeahbut, Kitty, this just isn't true. (i'm also wondering how you managed to test, given that it requires you crash a sim. teleporting causes all attachments to resave (which is why teleporting when you have tons of attachments is so slow.) this also breaks your use case, in that you can't undo changes after a teleport. so what you're describing is a "super undo" which only works on attachments (not regular objects) and only works as long as you don't teleport. given how weird that is, i don't think it's something we want to support. i understand that the behavior you describe (not being "attached to the inventory") might be the best way for the mechanism to work - however, that's not currently the case - and is a serious engineering task to change it now. actually - i'm wondering why our undo function doesn't work on textures. it seems that this is the proper fix for your problem (and many others): make undo work for texture changes as well as position/rotation/scale changes.
> Wouldn't it be better to only save them in certain cases, rather than (supposedly) all the time?
maybe / probably. but like i said above - that change is a big engineering effort, for a sorta weird behavior. the best fix here is to let you use the ctrl-z button to undo bad changes - right? (a whole slew of editorial comments withheld)
Qarl, undo will only undo a few steps back in your editing, and then only if you have not closed your edit window. It will not fix something you did way back and discover it was wrong now that you've moved something else. And, if you have changed color or texture, undo will not work regardless (at least not for me). Furthermore, with your attachment highlighted while in edit mode it is sometimes virtually impossible to see the effects of your changes (especially texture and color changes) without exiting edit mode. (And this issue applies to non-attachment editing as well) Please re examine this change. "this also breaks your use case, in that you can't undo changes after a teleport."
Using 1.22: According to you it should be a sphere (the state it had at the time of the last teleport), but in fact if you actually try the steps you'll find that it's the original prim in the state it was when you first attached it. If you attach the "original" it'll be a cylinder (the state it had at the time of detach), ie the asset UUID of the inventory item only gets updated at 1) detach or 2) log-off... with the understanding that the sim is in good working order (hence my comment to a sim crash, actually the far more common case is a sim with stuck pending downloads/uploads which doesn't upload the attachments in time and when you relog all changes have been lost, including any changes in script state which is very annoying). Unless I'm missing something I don't see why the use case of copy/pasting a worn attachment to undo accidental (or the very frequent failure of the "Undo" feature to actually undo anything) is invalid. It does work. A more useful undo would definitely be appreciated I think.
Re: attachments and simcrashes Kitty - but it DOESN'T work - the asset retains a pointer to the inventory location where it is worn - when copied both assets point to the same location, and when saved one of them is destroyed (the second overwrites the first.) that's the reason this was disabled, right?
i'll take your word for the TP issue - that behavior may have changed since last i looked. regardless, copying worn objects causes content loss, and there's no easy way to fix it. so given the choice of content loss or re-enabling this form of undo, i'm going to chose leaving this disabled. i think you all would agree, right? in a perfect world we'd fix this, i agree. but it's hard, we don't have infinite resources, so we make choices. "Kitty - but it DOESN'T work - the asset retains a pointer to the inventory location where it is worn - when copied both assets point to the same location, and when saved one of them is destroyed (the second overwrites the first.) that's the reason this was disabled, right?"
But isn't that just a manifestation of an entirely unrelated bug? 1. rez a prim The problem doesn't seem to be step 3, but step 2. Attaching a prim that's rezzed in-world is the step that frequently leads to content loss, and whether or not you copy it doesn't really seem to matter? llAttachToAvatar shows the exact same behaviour: half the time the inventory item doesn't actually make it into your inventory (or at least not in a way that will survive a relog) since it ends up orphaned outside of the avie's inventory. If you relog, you still have the attachment right there, but it won't be anywhere in inventory until LL does its yearly "shake the inventory servers, see what comes out orphaned and restore it to the Lost and Found" routine which just seems that rather than things getting "lost", they simply end up "misplaced" in a way that can be fixed manually if need be. I still don't see how the ability to copy a worn attachment leads to content loss in cases where the attachment was attached from inventory rather than world? Attaching in-world rezzed prims frequently does lead to content loss, so if anything should be fixed/disabled it should be that. Kitty - hm. you have a good point. i'm digging into the code again soon... i'll get a definitive answer for you.
Ohhh! I noticed this but didn't realise it was a 1.23 issue and disregarded it. I remember before when I used to work on HUDs, I'd realise I forgot to backup the original and then I'd copy it before the changes were saved by detaching, but I noticed in 1.23 it wouldn't let me copy it (I thought it was bizzare but didn't realise it was an actual issue at the time.)
Voting, as I just described, I've already been affected by this issue and didn't even realise it until reading about it here! "Kitty - hm. you have a good point. i'm digging into the code again soon... i'll get a definitive answer for you."
Thankies for taking the time to look into this again, Qarl — I'd also like to point to an issue that's related to this change that I ran into this weekend: I was working on adjusting a necklace that attached to chest and then wanted to make a copy to attach to spine. Since I couldn't copy the attachment while wearing it, I detached it, copy/pasted and wore the "original" again to use as a reference for placing the spine one. However, the "original" had reverted to it's pre-adjusted state (and so had the copy), because a detach followed by an attach don't seem to be "serialized" (= the attach can happen before the detach points the inventory item to the new asset). While this isn't a new problem, since you now have to detach, then copy and then reattach the original it's likely going to occur more frequently. Ideally the viewer would wait for the sim's SaveAssetIntoInventory message before allowing a copy operation and before allowing you to reattach the item because any kind of lag will result in either copying or attaching a previous version and loosing any changes between the last attach and last detach. Historically (I'm talking dark ages), when a sim crashed it would eat attachment edits... heck it might even eat regular object edits. It was annoying as heck if you were writing scripts. It was especially annoying if your script triggered the sim crash. Good times. ^_^
Attaching a patch to revert to pre-v1.23 behaviour and allow to copy worn attachments.
Granted, the copy is always the copy of the attachment as it was before being worn, but this quirk was actually used by many power-users (me included) as an "undo" feature (i.e. when you mess up something while editing an attachment, or when the Mono engine fails to deserialize the scripts properly on rezzing, you still can recover the untouched attachment by copying it). Qarl, I do understand your point of view (possible content lost, though as long as the original attachment is not deleted, there is no loss at all, just possibly outdated copies), but removing such a feature is not only annoying for the mundane users (who will not even modify their attachments but still want to be able to copy a bunch of worn items into another outfit folder), but also for the power users. I do need this feature or another mean to undo the modifications on a worn attachment. Beside the reversal patch I attached, other possibilities would be:
The attached patch will be used in the next Cool SL Viewer release. Henri explains the issue well - power users are missing their "undo" feature.
Possibly related, I came across a blog post http://vextramessing.blogspot.com/2009/06/nice-little-secret.html "...1) 'wear' an object (such as on your right hand, which is the default wearing location), then ... it will NOT update it's permissions to reflect the permissions of the added contents (and until it is rezzed will reflect the permissions of the object before you put the new contents in)! So, you could, for example, make an object that is transferable, and/or copyable, but which would lose these permissions after it's rezzed on the ground by someone you give it to (or someone they give it to)..." @Sylvie
This security issue has been solved in the recent server versions (IIRC it was solved in v1.25). It is now impossible to add no-tfr or no-copy items to the contents of a tfr-ok or respectively copy-ok item which is attached to your avatar. Well, i am using the recent version of the viewer now. And the copy function is still without any function. I am using subfolders with my fav. outfits and to do that i really need the copy function back.
Example: I am exploring my inventory (15.000 Items) and i did a nice combination of clothes and attachments. Before the copy function was removed, i typed "worn" into the search window of my inventory. Now i could see all my actually worn items, attachments and clothes. With old viewer i just drag them, copy them, and paste them to the new subfolder of my outfits. Done ... Now i cant do that anymore. I need to detach first (btw i hate the new pie menu too, where is my detach button now) and after detach i can copy it to the subfolder. But if i detach it, its not worn anymore, so the search function "worn" in my inventory browser dont work anymore too and the item is gone. I need to search it again. This is so bad, i really cant work with that new viewer. So i switched to snowglobe, in the hope to get my copy function back, but its the same problem. After 2.5 years loyal using the original LL Viewer, today i will switch to 3rd party Browser and give up the 1.23.x viewer of LL. For me its so sad, i am a heavy power user and highly professional in SL and i need this function so much. @Qarl, i tried different ways to provokate an inventory loss, like you described. I never had an inventory loss, the only way you can loose parts of your inventory is with "No Copy" items. You know how to do that 
Please give us the copy function back. Thank you very much Larissa, your comment made me think ...
It's still possible to make a copy of a worn item, using the "Make Outfit" feature in edit appearance-mode. OK, I opened another JIRA on this. I'm closing it and putting the description here.
Qarl: the behavior you're saying is strange and unnatural is a normal and routine part of my second life and I want it back. The data loss scenarios I've seen are NOT due to copying something while worn, they're due to WEARING a copy of something without detaching the original, because different mechanisms of detaching objects work differently. You can lose content by attaching a second object to the same point as a modified attachment without ever having copied any attachments, anywhere. This needs to be fixed so that no matter HOW you detach an object, it's detached, atomically, and completely, before anything else is done with that attachment point. It doesn't need to be partially fixed by breaking other stuff. Per VWR-6110, the ability to copy an attachment while you're wearing it has been removed from viewer 1.23. In 1.22 and earlier, I have to go through this process at least once a week: 1. Move the wrong prim. As far as I'm concerned, removing this capability is a showstopper for upgrading beyond 1.22. Raising to "critical" because this is the final straw for me, there's no way I can go beyond 1.22 without this being fixed.
Prior to the last 1.27.nnn server roll this week I was able to right-click/copy/paste items in inventory while the items are attached.
Today on a 1.27.latest.borkage SIM the only right-click menu items I have (NOT pie menu, I'm in the inventory pane) are DETATCH and PROPERTIES. I have verified in four different viewers that my menu appears to be broken. 1. Attach an item (skirt, for example) This has nothing to do with on-the-fly editing and seems to have been broken in the last server roll. Argh. @Aphrodite
This has nothing to do with the sim server version, but with the viewer: v1.23 forbids copying attached items. Simply use a v1.22.11.0 viewer, or get the Cool SL Viewer v1.23 (http://sldev.free.fr/ If you have the situation that you changed e.g. a script in a HUD, saved it but then you recognize that you want to fallback to the previous version, a work-around is:
just let the viewer crash (kill it by TaskManager). In most cases the changes of the object are NOT saved to asset server. (btw this behaviour is in my eyes a bug, again, and is partially described in This might be a good candidate for Snowglobe
This is fixed on the server side in version 1.32, so the viewer patch will not be necessary for much longer
That's good news Rob, thanks for the update.
The attached patch removes the code that was added to v1.23 to prevent any worn item to be copied.
This is NOT a server side issue, and even with v1.32 servers, you are still unable to copy a worn attachment with the official v1.23.5 viewer. The patch is therefore still needed (tested and verified today with v1.23.5.136262 viewer and v1.32.0.136920 sim server). I think Rob means the patch that disabled copying worn items in the inventory dropdown.
It's still possible to copy attachments using "Make Outfit" in edit appearance mode. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Fix Pending
Critical
Can't copy a copyable item while it is worn
