Scripts in object reverting - whats up in SL?

Last night i worked on a scripted object (HUD) and got it to work - did some 20 minutes testing to verify the feature set worked fine, backed up, then went to bed.

This morning I attached the HUD and some features were no longer working. On checking the scripts it turned out that their contents weren't the same as I saved last night - they were earlier edits. Fortunately after having scripts failing to save with no error messages I had backup copies of them on my computer's desktop. Here is a link to a previous post on scripts failing to save:-

/54/c8/354890/1.html

Note, I do keep version numbers and each version does have comments about the work done so I'm not mistaken about the scripts reverting to older versions. Also I keep a written log and tick of features as they are implemented and tested.


QUESTIONS
What is happening in SL to cause script reversions and script saving to fail silently. The lack of error messages is really disconcerting. When is the system again going to start warning us of these problems.

We used the get the dreaded Asset Server problem message but it isn't appearing anymore. At least when that system error message appeared we new there were problem whereas now we can be scripting and not know our work will be lost.

By the way, most of my scripts were LSL and only one was Mono - the scripts failing to save problem seems to equally affect both script types.

Were you wearing the HUD when you edited it? I can't remember the details, but I'm pretty sure that under some circumstances changes you make to scripts in something you're wearing revert as soon as you detach it. That's certainly caught me a few times, with the result I now do all my editing of huds and the like with them on the ground (which is why I can't remember when it does and doesn't happen).

Thank you, yes i was wearing the HUD while editing.

I wonder what has changed because for most of the past 2 years I've edited HUDs while wearing them with no problems.

I'll try your method of editing the HUD on the ground - it would be great if it also removes the need for backing up every save to desktop.

I've had a quick look in the jira but can't find a great deal -- http://jira.secondlife.com/browse/VWR-10498 and http://jira.secondlife.com/browse/SVC-3579 -- and it looks to be intermittent. I last came across it a couple of months ago when I was working on some scripted jewelry for someone, and I wondered if it was because the prims were no copy, but certainly I found that working with the items rezzed on the ground was a reliable work-round.

When you log on the sim will fetch all the assets (attachments in this case) you were wearing when you logged off and rez them.

From that moment on your attachment's current state exists only on whatever sim you happen to be on.

When you kill the attachment (detaching it or logging off) the sim will check whether the attachment has changed since the last rez and create and upload a new asset representing its current state. After that's complete it'll update the inventory item which represents the attachment and change the asset UUID it points to.

If for one reason or another the above doesn't happen then the next time you relog or reattach the attachment and the sim fetches its asset from our perspective the script/item will have "reverted".

Or just think of it as editing a document: you only persist changes when you hit "Save" and if anything happens in between your last "Save" and your most recent change then all those changes are lost and your document "reverts" to whatever it was when you last saved it.

(In the case of saving a script inside of an attachment: the actual script will be uploaded and exists as an asset somewhere on the asset server - as far as I know anyway - but since the inventory item inside of the prim is what matters if it doesn't have the proper asset UUID because it "reverted" then you no longer have a way to still access those more recent revisions)

So if you edit an attachment and happen to later - during the same session - end up on a sim that crashes then that sim won't have been able to reupload the attachment and when you relog you'll find the attachment in its "last saved" state.

Similarly asset uploads can stall on the sim for whatever reason "Pending Uploads" higher than 0 and asset uploads appear to actually time out.

In the case of a prim that was rezzed the sim (ie you clicked "Take" or "Return" on it) has the option to just put it back (or leave it until after the asset upload and inventory item creation completes) but in the case of an attachment there's nothing for it to go back to.

Your options are:
- only ever edit the HUD while it's rezzed and keep in mind that a sim crash could still wipe out the last hour's work (Take Copy will help with that)
- "Drop" the attachment each time you want to actually persist changes (and then "Take Copy", wear the copy *in inventory* and verify that it's the last revision before deleting the rezzed prim). Do not ever wear the rezzed prim directly from the pie menu.

And always keep an eye out for any stuck "Pending Downloads/Uploads". If either of the two is not 0 (intermittent spikes are fine but they should come back down and hit 0) then don't rez, edit things, don't take, don't log off (or try to tp) if you changed anything about an attachment that you don't want to "revert".

Edited to add that if llGiveInventoryList() works for full permission scripts inside of an attachment (or remote script loading) then you could save a lot of hassle and just drop in the equivalent of an "auto-save" script.

I had exactly the same thing happen to me a month or so back. I would take an edited wearable back into inventory only to find that the script wasn't what I had saved previously when I reattached the object. It was extremely confusing because I'm not very sharp at scripting at all. I think I even posted some of the code to the 'Scripting Tips' forum not realising that it was from the previous version. I was in a real mess until I noticed what was happening.

Then it occurred to me that the scripts were set as Mono by default because I created them in the object and HUD as I worked. I didn't want Mono scripts in any case because the object was a wearable so I resaved the scripts as LSO. I didn't see the problem after that although I should say that I haven't worked on the item very much since then.

1. SL is not reliable
2. SL has lots of problems
3. LL may change anything, anytime
4. Or restart/rewind the sim
5. Goto 1.

= Do not trust anything in SL, ever. If you are trying to do some stuff that requires a stable or prefictable platform then SL isn't it. If you're a corporate paying US$50k plus to have this 'behind the firewall' then more fool you. If you're an educatioanl organisation then you deserve everything you find.

Simply put - unless you're doing it for the sheer fun of it, SL is not a reliable enough platform to be trusted. Any other questions?

Thanks Kitty for the very detailed technical explanation and your Options list - now it all makes sense - in a crazy SL kind of way.
Clearly I've been living in a fool's paradise this last couple of years and its only been luck that more of my work hasn't been lost.

From your list I've been doing nearly everything wrong and assumed that my backing up HUD objects while in inventory would save me but those script reversions were something I could never have imagined. I'll also keep a check on the "Pending Downloads/Uploads" and use them as an indicator as to whether the sim might be having problems.

Innula Zenovka was right about working on rezzed objects being safest.

Just hope NASA don't ask LL to make the successor to the Space Shuttle - imagine being the pilot/crew

Actually its pretty amazing SL seems to work so well and most of us don't have a clue about the potential problems in our wonderful 3D world.

You weren't doing anything wrong, SL is the one doing things wrong .

Asset uploads should just never fail (aside from extreme circumstances like "acts of God" ).

Are you dragging the scripts into your own inventory (ie out of the HUD and into your own inventory) after you save them? If that's the case then you're really fine that way (well, as long as you open the copy in your inventory to make sure it saved and updated properly).

If you do work on the prim while it's rezzed in-world and you want to be absolutely safe then I'd still suggest always using "Take Copy" instead of just "Take" (the whole process for rezzed prims is really the same as attachments).

What I do when I have been editing scripts in an attachment, or doing anything in an attachment, is go to a sim that has NOTHING happening on it (linden ocean sims are good), wait a couple of minutes, then explicitly detach the attachment and reattach it... and make sure that my changes stuck.

When you log out the sim does a bunch of stuff as well as handling attachments, and that can all time out. That's why sometimes you end up logging in to a sim other than the one you logged out from, let alone having all attachments properly put away.

No I didn't use this method but I will start using it - it sounds a lot quicker than my current method of copy and pasting to an external editor file and then having to track the backed up files.




I'll now start using Take Copy as well - before just I didn't appreciate how it makes a safe copy.


I've now started watching the"Pending Downloads/Uploads" as i work and its interesting that in some sims they are often non-zero for extended periods of time. Now i"m i working in a much faster sim and the "Pending Downloads/Uploads" are nearly always zero.

I believe that detaching is sufficient to save the state; "drop and take copy" is unnecessary. However, drop and take copy allows you to verify that it worked and (hopefully) give you recourse if it didn't.

But, I suspect that if the take copy doesn't show the updates, then the dropped copy won't either.

I frequently edit scripts in worn objects, and I've found simply detaching them in my workshop to be reliable. My workshops are never in horribly laggy sims, but they're not in Linden ocean, either.

It doesn't "make a safe copy". It just makes a copy, which can be useful.

When working on anything inworld, I often "take copy" just to save my work in case I mess up. Or in case SL messes up, but I mess up more often than it does.

When working on a worn item or HUD, I can't "take copy", so I detach, and copy/paste in my inventory. Attach the newest, and continue. When I'm happy with my work, I delete the older copies, which are below the newest one in my inventory. Occasionally I'll rename a copy if I suspect I might want to revert back to it -- if I'm about to try something I think might fail.

It depends on what ends up happening:

Ideally the timing works out to:
1) The item is detached
2) The sim uploads the new asset representing the current state and updates the inventory item
3) You reattach it to see if it changed alright

If you do 3) before 2) is complete then you don't get the new state (it's still pending) but an older one. When 2) completes it no longer matters because you won't have any way to get to that asset.

2) can take a relatively long time as well depending on how healthy the sim/grid is (the sim sends a message back to the viewer about it so you can tell if you want to) so in the general case it's a handful of seconds or less (before you can manage to reattach it) to 30 seconds and up if things are laggy or plain broken.

The reason I suggested dropping is because it's not supposed to involve the asset server in any way (as far as I understand things anyway): the sim you're on is the only entity in SL that has a copy of the latest state so if you "drop" it then it's a sim-local operation that doesn't rely on the rest of the grid.

"Take Copy" very likely does involve an asset operation but it should either succeed or fail to reach your inventory (which is fine since you still have the rezzed version).

I've found, that when dealing with LL, always make a copy before saving, or submitting... whether it's scripts, posts, or wiki edits.... ctrl-a, ctrl-c, alt-tab, ctrl-p... it's saved lots of heartache (FFox helps)

Just an update after a few days trying the various methods given above.

SL is having a real bad time this morning with scripts often not saving in Attachements even though the sim is very fast, no other avatars in it, no pending uploads/downloads.

For me the most reliable ways are either to copy the script to an external editor or else copy the script to your inventory.

The rezzing in-world and then use "Take Copy"*is just not working today.

So, now after every script save I'm immediately copying the script to my inventory - it hasn't failed so far - and is quicker than using external editor.