ALL Scripts locked

[Gemifer Saphir]

Ok so this is the 2nd time I have lost everything in the past 2 months remind you I have been heer since 2007 and 'had' quite a collection. But I get dropped from server logged out, then NOT 1 of my scripts work. Mesh Body is all deformed because the auto deformer that allows me to do my own shape is broken. I have no face as the mesh head script is locked out, I have no more AO's as they are locked and the only way to fix this I have found so far is to re submit a request for a replacement once again then start all over from scratch yet again remaking all outfits and folders. It costs me over 50,000L a month ago to replace 'some' items I needed. Not going that route again. So, does anyone know or understand what is going on and how to fix this?

[Klytyna]

It sounds like client side inventory list damage, yet again... You get lagged, and logged out ort crash, you log back in and your ao wont work, huds dont respond, stuff looks weird or tristed...

 

Viewer seems to have borked your inv list on a bad shutdown, simply rebuying the borked stuff wont fix your inv file.  It's like trying to  cope with a sinkhole on your land by refilling it with sand...

 

Probability says you are using firestorm? Their viewers have a track record for this sort of thing exceeding others, so they have a special page on their website explaining steps to try and correct this.

 

http://wiki.phoenixviewer.com/fs_missing_inventory

 

 

 

 

[Qie Niangao]

Firstly, anything that has Mod permission should be able to simply have scripts reset, or worst case, set running (although that's kind of a different thing, and shouldn't be necessary).

So in particular, any AO should be resettable that way (because who would sell a no-Mod AO, right? that would be totally useless).

Now, the g*dd*mn Mesh bodies and heads. They are no-Mod FOR NO GOOD REASON and their creators should be excoriated every time we customers are in any way inconvenienced by their superstitious stupidity. So please do that first, then get a redelivery and go through all the agony of setting them back up for all your customizations. And then always only ever wear a copy of your customized Mesh avatar components. Then you'll have a fresh copy still in Inventory if something trashes one that you're wearing.

You really should never need to re-purchase anything. If you have lost something that's no-mod and doesn't offer some means of redelivery, send that creator all the ire you can muster, never buy anything from them again, and spread the word by any means available. Drive them out of business if at all possible.

As to what causes this, it's hard to be sure. Historically, scripts have been "wedged" by griefers who manage to cause math errors (caused by "orbiters" for example) or stack-heap collisions (in scripts that allocate memory at runtime in response to something the griefing script can manipulate), but I'm sure there are other ways it can happen, too.

[ETA: If these problems apply to scripts that were only in Inventory, not rezzed on the avatar, then Klytyna's hypothesis of Inventory corruption would apply. But it's not obvious to me why that should apply to scripts inside Inventory assets, not the assets themselves. *scratches pointy head*]

[Nova Convair]

Makes no sense.

Scripts only run on the server and are loaded from asset servers. They are not on the viewer and not in the viewer cache.

Therefore they can't be affected in inventory.

By my opinion the OP's story is missing something and contains speculations and maybe misinterpretations and not only observations.

If there will ever be new facts with proof I'll be interested though.

 

[Klytyna]

---

Qie Niangao wrote:

[ETA: If these problems apply to scripts that were only in Inventory, not rezzed on the avatar, then Klytyna's hypothesis of Inventory corruption would apply. But it's not obvious to me why that should apply to scripts inside Inventory assets, not the assets themselves. *scratches pointy head*]

---

Items "rezzed on the avatar" ARE in your inventory too, as to why a bout of inventory corruption affects what it affects, who knows, I've had worn items that looked fine but couldn't be detached, I've had items that seemed ok in inv but wouldn't attach, I've had items even whole folders, once lost 2/3rds of my inv, and I've had scripts working but poses fail, or scripts not working too, inv damage is weird, see, whats INSIDE the object is part of the inv data too, so it can get corrupted. And doing inv fixing solved these problems for me. These days I keep 3 copies of my customised AO, one to wear and two to copy and wear if the worn one borks...

 

Other than that I agree with what you posted.

[Qie Niangao]

Right. Just to clarify, I can accept the possibility of inventory corruption applying specifically to the set of items that are worn.

What I'm skeptical about is scripts inside unworn Inventory items being somehow broken by Inventory corruption, independent of the item that contains them. (As Nova says, that sorta makes no sense, considering what a "script" actually is.)

[Klytyna]

---

Qie Niangao wrote:

Right. Just to clarify, I can accept the possibility of inventory corruption applying specifically to the set of items that are worn.

What I'm skeptical about is scripts inside

unworn

Inventory items being somehow broken by Inventory corruption, independent of the item that contains them. (As Nova says, that sorta makes no sense, considering what a "script" actually is.)

---

Ah right... Yeah near as I can figure it, it's not that the contents are broken, it's that the container is broken so the viewer doesnt know that the contents are there, or cant look them up properly to find out what they do. so hypothetical example, it looks at a broken 'ao' object, figures there something in it called 'mainmenu' notices its flagged as an lsl, but cant seem to pull the uuid out of it to go find THAT mainmenu script amongst 24000 others, so erm, yeah not running that cos i dunno how... out of cheese error - redo from start.

 

Remember, SL stores info about scripts that are not in worn items, from when they WERE worn. If i unlock and take off my oc scripted collar, and wear a different one for a week, the state of memory variables etc for the old collar is STILL there, stored someplace, stored as part of the data on the scripts in that object in my inv, and the scripts will pick up where they left off if and when i decide to rewear it in the future

 

So either that info is stored as part of the inventory data for the script or it's stored on an asset server and indexed to that copy of that script but the inv data contains the index lookup.

 

This is just hypothetical musings on a weird happening i've seen where a scripted object just gets fubared, and you dont even know it is till you try and use it.

 

EDIT: Plan B...

You have an OC Barbed collar in your inv you wear it it's borked, why... inv corruption of the object record, problem goes like this...

 

Client: my user has worn an oc barbed collar  generic uuid blah specific object reference erm...

Server: look pal if you dont know exactly WHICH of the 178,000 oc barbed collars it is, i cant find it, find its script state and run the damn thing, I dont even know which version of oc it is...

Client: Sorry, doing my best here, uniqie reference 487, isthat supposed to be a 6, i cant read my own handwriting...

Server: Thanks for calling server support, your call will be held untill you hang up, kthxbai!

[Nova Convair]

Nothing is stored in your inventory. It countains zero data. It's just a copy of a list of uuids and names.

Your viewer works with a local copy for speed increase and data transfer reduction. If that list ever gets damaged, well - clear cache and get a new copy. But that does not involve any data.

The data is stored on asset servers - and of course with that many data stored over a long time you can expect a defect here and there. Depends on how good LL stores and maintains it and how often they take backups in case of a hd or server failure. That does not explain the op's case though. 

All data wanders through your viewer cache, so if you have bad ram/ssd/hd that will have some visible impact. But there is one exception: scripts do not go through your cache (if you dont have written them yourself) they go to the sim server. The scripts are stored including their present state and data. But again - on the asset servers. If one fails - yeah - can be corrupt data. If all fail but only for one avatar - well that makes no sense here when you want to explain that with server or cache issues.

 

[Klytyna]

---

Nova Convair wrote:

Nothing is stored in your inventory. It countains zero data. It's just a copy of a list of uuids and names.

Your viewer works with a local copy for speed increase and data transfer reduction. If that list ever gets damaged, well - clear cache and get a new copy. But that does not involve any data. 

---

Correct...

---

Nova Convair wrote:

The data is stored on asset servers - and of course with that many data stored over a long time you can expect a defect here and there. Depends on how good LL stores and maintains it and how often they take backups in case of a hd or server failure. That does not explain the op's case though.  

---

Also correct...

---

Nova Convair wrote:

But there is one exception: scripts do not go through your cache (if you dont have written them yourself) they go to the sim server. The scripts are stored including their present state and data.  

---

See, here is the error... YES the script is stored on the asset server, YES the simulation server runs the script after pulling it down from the asset server, when your client tells the simulation server you've worn a hjud, BUT...

 

In order for the simulation server to know exactly which scripts to pull from Assets and run, which version and which stored script running state, that are UNIQUE to the particular copy of the hud you are wearing, your client has to tell the simulatiuon server EXACTLY which unique instance of that hud, of all the thousands in sl, is the one you are wearing. client side inventory list damage means the client cant tell the simulator, which then does not know what to pull from the asset server and run 'server side', until your client is forced to reload the inventory list index data directly from the asset server by erasing the corrupted copy.

 

Analogy... You lose the post-it note with the PIN number for your debit card, all your money is in the bank, how do you get money out of the ATM if you cant remember your PIN? Opps time to do PIN Recovery, because the ATM isnt going to say "Sorry i cant find YOUR money, but here is some very similar money belonging to somebody ELSE"

[Nova Convair]

---

Klytyna wrote:

---

In order for the simulation server to know exactly which scripts to pull from Assets and run, which version and which stored script running state, that are UNIQUE to the particular copy of the hud you are wearing, your client has to tell the simulatiuon server EXACTLY which unique instance of that hud, of all the thousands in sl, is the one you are wearing. client side inventory list damage means the client cant tell the simulator, which then does not know what to pull from the asset server and run 'server side', until your client is forced to reload the inventory list index data directly from the asset server by erasing the corrupted copy.

 

In your inventory there is an uuid for the hud. ONE uuid for the hud. The contents of the hud is not in your inventory. To see that content you need to rez the hud. Then the content of the hud has the uuids of the stuff inside - but that happens on the server and not your client.

So if you ever get a corrupted uuid to your hud you will not be able to rez a hud at all.

If you rez an object and drag some stuff into it and check the uuids of it's inventory you will notice that this uuids are different to the uuids in your inventory. Why? Because the uuids in the objects inventory are temporary uuids that are used by the sim server. If one of the uuids in your inventory gets corrupted now - that has no effect since the uuids in the objects inventory are different ones. They are independent and stored on the sim server as long as the object stays rezzed. Your viewer has absolutely no influence on that uuids.

Besides of that - you want to say that the OP's uuids are corrupted in the (unrezzed) objects inventorys - but only the scripts uuids are affected and nothing else? That sounds like a very adventurous theory for me.

This gets a bit too technical too. I need more insight into the server code to add anything so I will shut up from now on

 

[Klytyna]

---

Nova Convair wrote:

Besides of that - you want to say that the OP's uuids are corrupted in the (unrezzed) objects inventorys - but only the scripts uuids are affected and nothing else? That sounds like a very adventurous theory for me. 

---

 

1. No...

2. Learn to read...

3. Because the client cannot tell the sim-server which uniqwue copy of the hud is being used, the sim-server cannot retrieve the data on the contained scripts from the asset-server, and is thus unable to run them.

4. If you have nev er had a scripted item fail to fuction after inventory damage, in all your years, you have been bloody lucky. Pat your self on the back.

---

Nova Convair wrote:

This gets a bit too technical too. I need more insight into the server code to add anything so I will shut up from now on

 

---

....

 

[Qie Niangao]

---

Klytyna wrote:

---

Nova Convair wrote:

Besides of that - you want to say that the OP's uuids are corrupted in the (unrezzed) objects inventorys - but only the scripts uuids are affected and nothing else? That sounds like a very adventurous theory for me. 

---

 

1. No...

2. Learn to read...

3. Because the client cannot tell the sim-server which uniqwue copy of the hud is being used, the sim-server cannot retrieve the data on the contained scripts from the asset-server, and is thus unable to run them.

4. If you have nev er had a scripted item fail to fuction after inventory damage, in all your years, you have been bloody lucky. Pat your self on the back. 

---

I don't think I have. Now I haven't had nearly the inventory corruption problems that others have experienced, so probably I am "bloody lucky" but I also am not sure I'd recognize this problem if it arose.

I have had scripts lost to asset "rot" over the years -- where they just don't exist anymore, like they were inappropriately garbage-collected or something. I forget now what those errors look like (if I could remember the ancient objects that contained those scripts, I could recreate the error messages I guess), but I remember them being pretty explicit about what had gone wrong.

Certainly I've had scripts in no-mod objects broken permanently by griefing while they were attached. I suspect this happens pretty often. But I realize the discussion has moved on to another situation that I may have never encountered, but again, I'm not sure I'd recognize it if it happened.

The thing with the servers not recognizing which unique version of an object is being used... that's confusing. I mean, it's only by successfully dereferencing the unique IDs that it even knows the name of the object -- it resolves the specific instance to discover the class, not the other way around (although it may know type -- an animation vs a script vs a sound, etc.). There's a failure mode that may be related (or... the same?) where an outfit contains a bogus link that can't be dereferenced, so when the viewer tries to invoke those, they're just gone and it fusses profusely.

Of course there are IP replacement assets that break objects expecting to use the original infringing content, but that doesn't seem very relevant here.

And hmmm... I remember there was a time when viewers loading inventory would regularly fuss like crazy about missing gestures (or some such nonsense). I never much paid attention to that because I despise gestures, but maybe those old errors were related to this.

[Theresa Tennyson]

---

Nova Convair wrote:

---

Besides of that - you want to say that the OP's uuids are corrupted in the (unrezzed) objects inventorys - but only the scripts uuids are affected and nothing else? That sounds like a very adventurous theory for me.

This gets a bit too technical too.

I need more insight into the server code to add anything so I will shut up from now on

 

---

Insight doesn't seem to be that important when it comes to contributing to this particular thread.

[Klytyna]

---

Qie Niangao wrote:

The thing with the servers not recognizing which unique version of an object is being used... that's confusing. I mean, it's only by successfully dereferencing the unique IDs that it even knows the name of the object -- it resolves the specific 

instance

to discover the

class

, not the other way around (although it may know

type

-- an animation vs a script vs a sound, etc.). There's a failure mode that may be related (or... the same?) where an

outfit

contains a bogus

link

that can't be dereferenced, so when the viewer tries to invoke those, they're just gone and it fusses profusely.

---

I'm thinking about script states...

With a texture for example, an instance of a texture is just a straight instance, find the asset yes/no, if yes the texture is the if no blank, simple. Same is true for a script that has never been run.

 

But... If I write a script, say an RLV based RP chat renamer,  and i give a copy to you and we both rez a prim, pick it up, wear as a hud and drop the script into it... while the SCRIPTS are just identical instances, the STATES are different, we both use the menu, you're stores 3 variables, key AvKey,  int Gender, string Chatname, as 555-210-2060, TRUE, "Hunk Studly", mine stores 161-376-9857, FALSE, "Candy Hunt".

(Yeah for the pedants out there, I know those are not real SL avatar UUID's, I couldn't be bothered typing two full length fake uuids, so sue me)

 

On the asset servers our copies of the scripts are just instances but the stored script states are unigie, so the objects containing scripts with those states become sort of unique, if you and i have copies of a commercial hud, the uuid for the hud is the same, the uuid for the script in side is the same, but your copy of the hud is not the same as my copy of the hud, and if your client cant tell the servers which copy of the hud you are wearing... how does it know which one to look up and run scripts for?

[Qie Niangao]

I've honestly lost the point of this thread, so I wish the OP would have returned to tell us what the real experience was; I suspect we're all off on a tangent irrelevant to whatever prompted the initial post.

But anyway, in case it matters: A script instance is both the program and its state. Perhaps confusing this, there's a bit of magic that sims do to share identical script programs in Mono memory, but that's all very specialized, misses as much as it hits, and doesn't affect the scripts themselves.

Also, there is all kinds of craziness involved in updating the asset underlying attached scripts -- well known to scripters who've lost work after editing a worn script.

So yeah: there are multiple reasons why scripts in worn attachments may get broken, besides being wedged by execution errors. But no amount of breaking those will have any effect on any scripts that were not worn when the breakage occurred. (And at this point, I'm not sure anybody is claiming it would; we may all be agreeing while poking at different parts of the same elephant. I can't tell anymore.)

[Whirly Fizzle]

---

Gemifer Saphir wrote:

Ok so this is the 2nd time I have lost everything in the past 2 months remind you I have been heer since 2007 and 'had' quite a collection. But I get dropped from server logged out, then NOT 1 of my scripts work. Mesh Body is all deformed because the auto deformer that allows me to do my own shape is broken. I have no face as the mesh head script is locked out, I have no more AO's as they are locked and the only way to fix this I have found so far is to re submit a request for a replacement once again then start all over from scratch yet again remaking all outfits and folders. It costs me over 50,000L a month ago to replace 'some' items I needed. Not going that route again. So, does anyone know or understand what is going on and how to fix this?

---

It appears to be a reproducible bug - see BUG-41379 - Script (running) state is lost when logged out during forced teleport