[#VWR-70] Script, created in attachment, is lost after viewer crash.

1. Second Life Viewer - VWR

Script, created in attachment, is lost after viewer crash.

Created: 24/Jan/07 08:55 AM Updated: 01/Mar/09 01:28 PM

Component/s:

Inventory

Affects Version/s:

1.13.1.5

Fix Version/s:

None

Environment:

Windows

Issue Links:

Relates

This issue is related to by:

SVC-3579 Attachments reloaded from stale versions on rewear (was: stale globals on attachment rewear)

MISC-1137 Meta Issue: Usability

Linden Lab Issue ID:

SL-33528

Description

« Hide

Steps to reproduce:

right-click on attachment
choose 'edit'
press 'New Script' button
enter the script
save and close script and edit windows
verify that the script works
crash the viewer
relog

Result: the script has disappeared
Expected result: the script is either saved in the attachment or recoverable from Lost&Found folder

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Lex Neva added a comment - 24/Jan/07 11:28 AM

I think you'll find that this same thing happens if the region itself crashes. Attachments are somewhat fragile in that any modifications to them aren't saved to your inventory until you take the attachment off. If you crash, maybe that's causing your attachments not to save. If this is the case, that's definitely a bug.

I believe at least the case of a region crash is a known issue internal to LL.

Workaround: always take off your attachment to "save" it. Alternately, work on it on the ground. I know it's a pain :/

[ Permlink | « Hide ]

Lulu Ludovico added a comment - 01/Feb/08 02:53 PM - edited

Whilst Keex's description and steps to reproduce are problems on the creator-side (and Lex's workaround works quite well), there is a much greater negative impact on the user experience on the customer-side.

I make heavily-scripted attachments that record several stats of the avie. Since SL crashes a lot, especially while tp-ing, it is very common for me to get customers complaining to me that the stats don't stick, and they get rolled back.

To reproduce:

make a script that constantly generates and stores some highscore, e.g. time worn.
put script in attachment.
detach attachment to "save the script and settings"
wear attachment for say 6 hours. Verify the highscore is 6 hours.
crash the viewer.
relog. Highscore is reset to 0, the time of detaching.

ROLEPLAY IMPLICATIONS

This is a much bigger problem than meets the eye. Imagine you're playing an MMORPG like Everquest 2. You crash, and your avie gets rolled back a few levels and lost the loot you've gained in the last few hours of dungeon crawling. Definitely not fun, and no customer will accept this sort of experience - and guess what, you don't get this experience - their asset servers are constantly being updated. So why is it that Second Life customers are expected to "detach" their attachments to save their stats each time? When their stats change quite often (like highscore), this is impractical. Furthermore, many customers use a third party viewer (Marine Kelley's Restrained Life Viewer) that prevents them from detaching the attachments. So this is not an option.

One of the major challenges of Second Life is what to do in this world. Scripted attachments contribute a lot to the roleplay aspect.

SUGGESTION

So what is needed is a more permanent and responsive save - all items in attachments and script states (yes the script variables that store highscore etc. get rolled back!) should be saved on crashes. I understand that constantly saving to the asset servers is impractical as they are already under tremendous load now. Perhaps what can be done is this:

1. Sim constantly polls for whether avie has crashed (if avie didn't teleport, or didn't move to an adjacent sim, or log out successfully, avie must have crashed). Sim would know when avie is on another sim as the other sim will request the avie's data. As I understand it, the sim would know when avie is logging out as the sim also attempts to save the avie's data on logout.

2. When crash is detected in (1) above, avie's stats are automatically saved to asset servers.

This would make Second Life a more resilient place and make it a viable roleplay platform.

[ Show » ]

Lulu Ludovico added a comment - 01/Feb/08 02:53 PM - edited Whilst Keex's description and steps to reproduce are problems on the creator-side (and Lex's workaround works quite well), there is a much greater negative impact on the user experience on the customer-side. I make heavily-scripted attachments that record several stats of the avie. Since SL crashes a lot, especially while tp-ing, it is very common for me to get customers complaining to me that the stats don't stick, and they get rolled back. To reproduce:

make a script that constantly generates and stores some highscore, e.g. time worn.
put script in attachment.
detach attachment to "save the script and settings"
wear attachment for say 6 hours. Verify the highscore is 6 hours.
crash the viewer.
relog. Highscore is reset to 0, the time of detaching.

ROLEPLAY IMPLICATIONS This is a much bigger problem than meets the eye. Imagine you're playing an MMORPG like Everquest 2. You crash, and your avie gets rolled back a few levels and lost the loot you've gained in the last few hours of dungeon crawling. Definitely not fun, and no customer will accept this sort of experience - and guess what, you don't get this experience - their asset servers are constantly being updated. So why is it that Second Life customers are expected to "detach" their attachments to save their stats each time? When their stats change quite often (like highscore), this is impractical. Furthermore, many customers use a third party viewer (Marine Kelley's Restrained Life Viewer) that prevents them from detaching the attachments. So this is not an option. One of the major challenges of Second Life is what to do in this world. Scripted attachments contribute a lot to the roleplay aspect. SUGGESTION So what is needed is a more permanent and responsive save - all items in attachments and script states (yes the script variables that store highscore etc. get rolled back!) should be saved on crashes. I understand that constantly saving to the asset servers is impractical as they are already under tremendous load now. Perhaps what can be done is this: 1. Sim constantly polls for whether avie has crashed (if avie didn't teleport, or didn't move to an adjacent sim, or log out successfully, avie must have crashed). Sim would know when avie is on another sim as the other sim will request the avie's data. As I understand it, the sim would know when avie is logging out as the sim also attempts to save the avie's data on logout. 2. When crash is detected in (1) above, avie's stats are automatically saved to asset servers. This would make Second Life a more resilient place and make it a viable roleplay platform.

[ Permlink | « Hide ]

Thomas Shikami added a comment - 01/Feb/08 09:37 PM

Please state how to reproduce this bug, especially the crash viewer part. I used task manager to kill the process (1.18.6.4). IMHO this bug is misfiled or already resolved as the viewer has nothing to do with what state an attachment is in and if it's saved.

I couldn't reproduce this bug, I know about another kind of bug where a crashing region causes loss of the state in attachments, sadly, this is a won't fix thing.

[ Permlink | « Hide ]

Argent Stonecutter added a comment - 06/Mar/08 07:46 PM

The problem is that attachments are handled by the sim and changes to them are not saved back to inventory unless you explicitly detach them.

You don't even have to crash. Just dragging a folder onto your avatar can be enough to make the modified attachment lost. The problem is that the viewer is responsible for making the save happen... I believe the sim should perform the save when the prims are detached for any reason... the avatar leaving the sim, logging out, detaching, anything. That will solve this problem for viewer crashes, for lost teleports, for dragging a folder to your avatar, etcetera...

[ Permlink | « Hide ]

Jorgen Friis added a comment - 06/Dec/08 09:25 PM

Just wanted to say that this problem still exists. Created a script in a HUD attachment on a private island, scripted it to the point of testing. Went to mainland to find a test location and the viewer crashed. Logged back in to discover that the script was no longer in the HUD attachment object, or anywhere to be found in my inventory.

I knew that HUD object positions are lost on a crash unless you have a clean logout or detach it, but I was unaware this applied to scripts inside HUD objects as well.

Second Life 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release)