Jump to content
  • 0

Scripts stop working


Red2Blaze
 Share

You are about to reply to a thread that has been inactive for 2311 days.

Please take a moment to consider if this thread is worth bumping.

Question

Lately my HUD scripts seem to die out one after the other, i do not know if its also the other scripts, but i all ready lost a AO, and 2 Mesh Body HUDs (so i have no belly now in my martriya one :( )

I try any fix i was able to come up with, like detaching, and reattaching, restarting the scripts (using Firestorm viewer) dose not seem to help, they are just not responding, or if they are i cant seem to see it or use it, its a real pain and i do not know what to do, slowly it seem to effect more and more, and i do not know what is making it happen or how to fix it

 

Fixes i try so far:

Clearing Cash

Restarting Scripts

Reattaching

Wearing the same HUD but a deffrent copy (worked once, but seem like it only some times work)

 

Any help with be a belly saver

Thanks

Link to comment
Share on other sites

Recommended Posts

  • 1

I assume that you have tried the obvious step of going to a different region or at least to a different parcel where you are sure that scripts are not disabled by the owner.  If you've turned off scripts on your own parcel, turn them back on.  If you have them turned on for group members only, be sure that you are wearing the group tag.  In general, there are few good reasons for disabling scripts, because that will turn off a lot of things that you really want to keep running.

Otherwise, you have tried the common solutions (except clearing your cache, which does absolutely nothing but possibly make matters worse).

  • Like 1
Link to comment
Share on other sites

  • 1

Oh, my.  I know I said that I was assuming that you had already tried that, but I was really hoping that you hadn't, and that it would solve things when you tried.

There aren't many possibilities left.  In fact, there's only one that I can think of.  A HUD can't change anything all by ltself.  Your Maitreya HUD, for example, sends a signal to scripts in your Maitreya mesh body when you click on a HUD button.  It's like the remote that you use for a TV or stereo at home.  The HUD may be working fine, but the receiving script may be messed up. That's not easy to do, but some people believe that they should reduce their avatar's script count by deleting all of its scripts.  If you have done that, or anything that by accident, the solution is to rez a new copy of the body from the original box it came in and wear that.  (This is why you always save the backup copies, just in case.)  The new copy's scripts should be fine.  In fact, rez a new HUD while you;re at it.  Couldn't hurt.

Edited by Rolig Loon
typos, as usual
  • Like 3
Link to comment
Share on other sites

  • 1

You say "restarting", but there isn't a "restart" option. You can set a script to NOT RUNNING or RUNNING. Getting to those controls on a no-mod script is VERY tricky.

If you recompiled or reset, you likely broke the script. So, avoid doing those. You will need a new HUD. I know Slink provides a 're-delivery' terminal so people can get new copies of what they have purchased. I suspect most others do the same.

Because of the way Appliers work, a RESET or RECOMPILE generally kills them. Some HUD's are similar. What they are doing is holding a bit of information in memory. You can detach a script and it will retain its memory. Doing anything that clears that hidden bit of information from memory permanently breaks the Applier/HUD. There is no way to repair it. Get a new one. This is why copies are important.

If a HUD does not work, it often is the region you are in. If you log into a place where you cannot run scripts, a number of HUD's will never start even after TP/region change. A relog or remove and attach sequence in a place where you can run scripts is needed to wake them up. I generally log into my 'home' to avoid that problem.

Rolig is right on with the removing scripts point. I keep a 'master' copy of my mesh body and use a 'working' copy of the body to wear. The same with the HUD. I can always make a new copy from the master and try it to see if my everyday copy is broken. But, I have seen nothing that kills HUD's or Appliers... other than users. Well, upgrades. Using the wrong HUD with the a different version body is a problem.

So... while you may be convinced the HUD is dead, if you haven't RESET it, the problem is likely elsewhere.

  • Thanks 1
Link to comment
Share on other sites

  • 1
14 hours ago, Nalates Urriah said:

You say "restarting", but there isn't a "restart" option. You can set a script to NOT RUNNING or RUNNING. Getting to those controls on a no-mod script is VERY tricky.

Hmm, when I am working on scripts I use the "Restart" button quite often. Are you saying the button only works on full-rights scripts, or the button is only available in some viewers?

  • Thanks 1
Link to comment
Share on other sites

  • 1
38 minutes ago, Red2Blaze said:
5 hours ago, Love Zhaoying said:

Hmm, when I am working on scripts I use the "Restart" button quite often. Are you saying the button only works on full-rights scripts, or the button is only available in some viewers?

You talking abut 1

I am talking abut 2

And i think she is right abut 1 been only for scripts you can edit

Go it!

  • Thanks 1
Link to comment
Share on other sites

  • 1
36 minutes ago, Red2Blaze said:

You talking abut 1

I am talking abut 2

And i think she is right abut 1 been only for scripts you can edit

 

If i understand  you right

FirestormOS-Releasex64_2017-03-27_20-14-21.png

The only difference between those two options is that one of of them resets the particular script you have open, and the other resets all scripts in the object.  Neither one will reset scripts if you don't  have mod perms. I wish I could figure out what you are doing, though.  It's a real puzzle.

Link to comment
Share on other sites

  • 1
7 minutes ago, Red2Blaze said:

[ .... ]

I am not really sure if i need to try to connect support abut it, see if they can find something out

You probably won't have any more luck there, but give it a shot. You don't have access to technical help in support cases unless you're a Premium member, of course.  I've been scripting in SL for ten years, and Nalates really knows her way around the technical side of SL too. I can't imagine how to make HUDs behave like yours are.

  • Thanks 1
Link to comment
Share on other sites

  • 1

FirestormOS-Releasex64_2017-03-27_20-14-

 

I dug through Firestorm this morning. There is no RESTART. You say you often RESTART the scripts by clicking RESTART... All the buttons you can click that I find are reSET. So, I am left wondering if you are running Firestorm in English or another language and that is where we are having a miscommunication. Whatever the buttons are labeled, the code behind them does the same thing: RESET. (http://wiki.secondlife.com/wiki/LlResetScript)

To protect textures from theft, Slink saves the UUID in script memory. HUD's and various other scripts use similar tricks. Those that do will be killed by a reset. The script has NOT stopped working, it just cannot accomplish what it is supposed to and appears to do nothing. A script telling an object to switch to the NULL texture is not an error, so no error notice. The object can't switch to a NULL texture so it quietly does nothing.

We have tens of thousands of people using Firestorm, the same AO's, the same HUD's, the same whatever... and not having this problem. So, the problem must be in your computer or your actions. If the rest of your computer is working normally, that pretty well eliminates it.

That leaves your behavior/actions. Lag contributes to people thinking something is wrong and taking action to correct a non-existent problem, which then creates a problem. Lag may initially cause you to think you have a non-responsive HUD. Clicking RESET does nothing to remedy lag.

What may happen is you click a HUD control. The viewer sends that instruction to the SL servers. Commands and status information for SL is transmitted via UDP, a quick simple protocol that has no error correction or resend features. The command can get lost and never get there. Most likely it is slow getting there. The server may be lagging to add to the problem or not. The status update that changes the render in your viewer may get lost coming back to you or more likely just be slow. By, slow I mean seconds. SL will struggle to maintain a connection and may do so even when lag is intermittently reaching 10 seconds. If you have clicked reSET before the update gets to you, the result is unpredictable. Your render may change and appear related to the reset-click only because they happen at the same time on your viewer. But, they are unrelated because of the lag. The render update is triggered by a click happening seconds before and you clicked just as it arrived. So, it appears the later click did the trick... and you mentally connect them for a rational reason.

I suggest you change your thinking. It would be extremely unlikely that you are the only one experiencing a slow moving contagion of HUD deaths. Get a working HUD, AO, whatever. Assume it will remain working and something else is getting in its way. Leave the HUD or AO alone. Or may be change regions and attach and detach the HUD/AO. Bur do NOT reSET the HUD or AO. I suggest you contact the one that made the device and talk to them to see if the device can be reset without killing it. Other wise, just don't.

With Firestorm I have noticed the built in AO coming on randomly and messing up my worn AO. I doubt the FS AO is turning itself on. A bad set of key presses or a missed click is the more likely cause. But, I didn't notice what I did to turn it on, so the FS AO appears to be self starting. If you have AO conflicts, your AO will often appear to have stopped working.

FS has RLV. I have no idea how many times I have had to log off FS and relog with a Linden or other viewer to fix something. RLV often blocks a HUD's actions. For that reason a number of RLV players I know buy and wear clothes that do NOT require alpha layers. Once they are captured HUD's may not work and having parts of a mesh body alpha'd-out is a mood killer. To get things cleaned up after an RLV session can be a pain. Check your viewer's RLV setting. Taking off a RLV Relay won't clear the blocks it has put in place. You may have to remove it and relog.

All this stuff, HUD's, AO's, etc., works. But, there are a ton of gotchas. You just have to find which one is biting you.

  • Thanks 1
Link to comment
Share on other sites

  • 1

Do you have originals of the HUD's? I mean the original unused HUD that came with your body.

Since you have been clicking RESET, I am not surprised they stopped working.

AFAIK, you are the only one having this problem.

I honestly believe you are right and the HUD's are dead. Reset kills HUD's dependent on variables held in memory.

  • Thanks 1
Link to comment
Share on other sites

  • 1

So after some time searching for a solution, as I was having the same issue. I beleive I have found one!
It seems simply (though time consuming) taking the scripts out, deleting the old, and putting the scripts back in the effected objects, solved all my problems.

I had everything from about 4 HUDS to the fitted mesh body I was wearing all needed to be re-scripted. Luckily doing so, all my items are back to working order. I hope this helps out!

  • Thanks 1
Link to comment
Share on other sites

  • 1
4 hours ago, Shyahla said:

It seems simply (though time consuming) taking the scripts out, deleting the old, and putting the scripts back in the effected objects, solved all my problems.

That seems like a time-consuming process and one that's likely to cause errors if you mess up anywhere (and it assumes that you have mod perms so you can do it at all). If you're going to go to all that trouble, why not just take the backup copy of your HUD and use it instead of moving the scripts around? Or maybe I'm misunderstanding what you are suggesting ....

  • Thanks 1
Link to comment
Share on other sites

  • 1

E

48 minutes ago, Red2Blaze said:
On 11/24/2017 at 7:05 AM, Lindal Kidd said:

If the scripts are shown as Not Running, you should simply be able to check the box to set them to Running...you should not have to remove and replace the scripts.  Yeesh, what a chore...and very prone to error.

When the script is mod sure

But when its not i am unable to active it

Exactly.  That's why I suggested that the only solution left to you is to replace the disabled HUDs with your backup copies.

  • Sad 1
Link to comment
Share on other sites

  • 1
On 11/24/2017 at 3:01 AM, Red2Blaze said:

Well found the issue and reset of the scripts was not related the HUD is suppose to just return to default I think

You are correct that a reset returns a script to a default state. The problem is what the programmer designed the default state to be. There is no universal default state for all scripts.

I make Appliers. Almost all of the Appliers for Slink, Maitreya and others use the same basic workflow to protect their and my work. The script is given to me by Slink, Belleza, or whoever in a startup state. It is waiting for me to tell it how to use my HUD's buttons and where to paste the textures I am using, tattoo, skin, clothes, etc.. I tell it that information by writing information into a notecard according to instructions provided. With the HUD rezzed on the ground and with the Slink, Maitreya, or whatever Applier script loaded, I drop in my notecard. The Applier reads the card and pulls the information into memory then deletes the note card. Thus the UUID of my texture which could be taken from the card is hidden. The Slink maker protects their communications with their product and commerce moves ahead with a minimum of trust required between all parties.

If you reset one of these Appliers, all the information from my card is cleared. The applier is then in a "default" state waiting for a card to be added. For the end user it is non-functional, appearing broke. Certainly not the default state an end user would likely expect.

For various reasons other scripts do similar things. Some scripts are designed with solely the end-user in mind and can be reset without issue. My point is you cannot anticipate with any certainty what the "default" state will be.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 0
46 minutes ago, Rolig Loon said:

I assume that you have tried the obvious step of going to a different region or at least to a different parcel where you are sure that scripts are not disabled by the owner.  If you've turned off scripts on your own parcel, turn them back on.  If you have them turned on for group members only, be sure that you are wearing the group tag.  In general, there are few good reasons for disabling scripts, because that will turn off a lot of things that you really want to keep running.

Otherwise, you have tried the common solutions (except clearing your cache, which does absolutely nothing but possibly make matters worse).

 

Ya i did try that, did not seem to help sadly

 

O.o il not clear the cache again next time, seen someone say some where it needs to help

Edited by Red2Blaze
Link to comment
Share on other sites

  • 0
23 hours ago, Rolig Loon said:

Oh, my.  I know I said that I was assuming that you had already tried that, but I was really hoping that you hadn't, and that it would solve things when you tried.

There aren't many possibilities left.  In fact, there's only one that I can think of.  A HUD can't change anything all by ltself.  Your Maitreya HUD, for example, sends a signal to scripts in your Maitreya mesh body when you click on a HUD button.  It's like the remote that you use for a TV or stereo at home.  The HUD may be working fine, but the receiving script may be messed up. That's not easy to do, but some people believe that they should reduce their avatar's script count by deleting all of its scripts.  If you have done that, or anything that by accident, the solution is to rez a new copy of the body from the original box it came in and wear that.  (This is why you always save the backup copies, just in case.)  The new copy's scripts should be fine.  In fact, rez a new HUD while you;re at it.  Couldn't hurt.

I do not think its the body it self, as the color of the body in the HUD dose not change, its honestly dose not seem to do anything

Today it also happen to my horse AO... it just stop responding, cant make it do anything, going to see if tomorrow it will change and return to work or if i can get one that dose work some how

3 hours ago, Nalates Urriah said:

You say "restarting", but there isn't a "restart" option. You can set a script to NOT RUNNING or RUNNING. Getting to those controls on a no-mod script is VERY tricky.

If you recompiled or reset, you likely broke the script. So, avoid doing those. You will need a new HUD. I know Slink provides a 're-delivery' terminal so people can get new copies of what they have purchased. I suspect most others do the same.

Because of the way Appliers work, a RESET or RECOMPILE generally kills them. Some HUD's are similar. What they are doing is holding a bit of information in memory. You can detach a script and it will retain its memory. Doing anything that clears that hidden bit of information from memory permanently breaks the Applier/HUD. There is no way to repair it. Get a new one. This is why copies are important.

If a HUD does not work, it often is the region you are in. If you log into a place where you cannot run scripts, a number of HUD's will never start even after TP/region change. A relog or remove and attach sequence in a place where you can run scripts is needed to wake them up. I generally log into my 'home' to avoid that problem.

Rolig is right on with the removing scripts point. I keep a 'master' copy of my mesh body and use a 'working' copy of the body to wear. The same with the HUD. I can always make a new copy from the master and try it to see if my everyday copy is broken. But, I have seen nothing that kills HUD's or Appliers... other than users. Well, upgrades. Using the wrong HUD with the a different version body is a problem.

So... while you may be convinced the HUD is dead, if you haven't RESET it, the problem is likely elsewhere.

In Firestrom Viewer you have restart in the object under content tab, in the edit/build area

I am not sure, going to play around and see, but from what i can see it seem to slowly spread from one HUD to the other, but maybe i am just doing something wrong, il try to do it again with more order, and see if i can find a reason

Also abut the non-script area, well it happen to me a few times in the same Sim that has no non-script area as much as i know, it also allow rez

Today it happen in a SLM sim to my Horse AO, there is no non-Script area there

I really cant figer it out, but honesty as no one else seem to have it, i am guessing its likely really something i am doing or i don't know

Link to comment
Share on other sites

  • 0
5 hours ago, Love Zhaoying said:

Hmm, when I am working on scripts I use the "Restart" button quite often. Are you saying the button only works on full-rights scripts, or the button is only available in some viewers?

You talking abut 1

I am talking abut 2

And i think she is right abut 1 been only for scripts you can edit

 

If i understand  you right

FirestormOS-Releasex64_2017-03-27_20-14-21.png

Edited by Red2Blaze
Link to comment
Share on other sites

  • 0

So tested now, the House AO is completely dead, cant turn it off, cant turn it on, its just completely stuck

So i open a new box and the new AO works, but thing is i want to find a way to stop it from happening, even if i had backup for all my HUDs its a pain to fix outfits over and over every time the HUD will get broken

Link to comment
Share on other sites

  • 0
6 minutes ago, Rolig Loon said:

The only difference between those two options is that one of of them resets the particular script you have open, and the other resets all scripts in the object.  Neither one will reset scripts if you don't  have mod perms. I wish I could figure out what you are doing, though.  It's a real puzzle.

So it just says that it restarts it but dose not really do it? well that is a bummer...

I am not really sure if i need to try to connect support abut it, see if they can find something out

Link to comment
Share on other sites

  • 0
1 hour ago, Rolig Loon said:

You probably won't have any more luck there, but give it a shot. You don't have access to technical help in support cases unless you're a Premium member, of course.  I've been scripting in SL for ten years, and Nalates really knows her way around the technical side of SL too. I can't imagine how to make HUDs behave like yours are.

I think i am a premium memmber

And ya i do not think its a problem with the HUDs them self, had them for a while with no issue, then lately there going one after the other..

Link to comment
Share on other sites

  • 0
On 3/28/2017 at 7:57 PM, Nalates Urriah said:

FirestormOS-Releasex64_2017-03-27_20-14-

 

I dug through Firestorm this morning. There is no RESTART. You say you often RESTART the scripts by clicking RESTART... All the buttons you can click that I find are reSET. So, I am left wondering if you are running Firestorm in English or another language and that is where we are having a miscommunication. Whatever the buttons are labeled, the code behind them does the same thing: RESET. (http://wiki.secondlife.com/wiki/LlResetScript)

To protect textures from theft, Slink saves the UUID in script memory. HUD's and various other scripts use similar tricks. Those that do will be killed by a reset. The script has NOT stopped working, it just cannot accomplish what it is supposed to and appears to do nothing. A script telling an object to switch to the NULL texture is not an error, so no error notice. The object can't switch to a NULL texture so it quietly does nothing.

We have tens of thousands of people using Firestorm, the same AO's, the same HUD's, the same whatever... and not having this problem. So, the problem must be in your computer or your actions. If the rest of your computer is working normally, that pretty well eliminates it.

That leaves your behavior/actions. Lag contributes to people thinking something is wrong and taking action to correct a non-existent problem, which then creates a problem. Lag may initially cause you to think you have a non-responsive HUD. Clicking RESET does nothing to remedy lag.

What may happen is you click a HUD control. The viewer sends that instruction to the SL servers. Commands and status information for SL is transmitted via UDP, a quick simple protocol that has no error correction or resend features. The command can get lost and never get there. Most likely it is slow getting there. The server may be lagging to add to the problem or not. The status update that changes the render in your viewer may get lost coming back to you or more likely just be slow. By, slow I mean seconds. SL will struggle to maintain a connection and may do so even when lag is intermittently reaching 10 seconds. If you have clicked reSET before the update gets to you, the result is unpredictable. Your render may change and appear related to the reset-click only because they happen at the same time on your viewer. But, they are unrelated because of the lag. The render update is triggered by a click happening seconds before and you clicked just as it arrived. So, it appears the later click did the trick... and you mentally connect them for a rational reason.

I suggest you change your thinking. It would be extremely unlikely that you are the only one experiencing a slow moving contagion of HUD deaths. Get a working HUD, AO, whatever. Assume it will remain working and something else is getting in its way. Leave the HUD or AO alone. Or may be change regions and attach and detach the HUD/AO. Bur do NOT reSET the HUD or AO. I suggest you contact the one that made the device and talk to them to see if the device can be reset without killing it. Other wise, just don't.

With Firestorm I have noticed the built in AO coming on randomly and messing up my worn AO. I doubt the FS AO is turning itself on. A bad set of key presses or a missed click is the more likely cause. But, I didn't notice what I did to turn it on, so the FS AO appears to be self starting. If you have AO conflicts, your AO will often appear to have stopped working.

FS has RLV. I have no idea how many times I have had to log off FS and relog with a Linden or other viewer to fix something. RLV often blocks a HUD's actions. For that reason a number of RLV players I know buy and wear clothes that do NOT require alpha layers. Once they are captured HUD's may not work and having parts of a mesh body alpha'd-out is a mood killer. To get things cleaned up after an RLV session can be a pain. Check your viewer's RLV setting. Taking off a RLV Relay won't clear the blocks it has put in place. You may have to remove it and relog.

All this stuff, HUD's, AO's, etc., works. But, there are a ton of gotchas. You just have to find which one is biting you.

You are correct sorry its Reset

I all ready try to move sims, re-wear the HUD, re-log, log in deffrent time

I was assuming it may have been lag, but dose not matter when i do it, or if there is lag or not, or anything else, the HUDs just seem completely dead, the AO dose not do a thing, no animation, no change of color to turn it on or off, not menus opening, its just not doing a thing

 

I assume i am not alone on these, but i just cant figer out why it happens

So far it happen as said with 2 AO's the Lara Mesh body HUD, and one more HUD i cant remember right now

I honestly think they are dead, if i can il make up a video or something to just show what i mean

Link to comment
Share on other sites

  • 0
On 4/6/2017 at 1:41 AM, Nalates Urriah said:

Do you have originals of the HUD's? I mean the original unused HUD that came with your body.

Since you have been clicking RESET, I am not surprised they stopped working.

AFAIK, you are the only one having this problem.

I honestly believe you are right and the HUD's are dead. Reset kills HUD's dependent on variables held in memory.

Well found the issue and reset of the scripts was not related the HUD is suppose to just return to defualt i think

 

Any how the issue is not the scripts are dead but disabled, it happen to an modfible script i had so was able to see the active box was ticked off

 

Seem like i am not the only one now

Any how it happen with a few objects all ready i luckly do have copys of it even that its a real pain as a RPer i got tons of copys of it that i need to replace hopfully done all of them i just hope it will not return again

Link to comment
Share on other sites

  • 0
On 11/24/2017 at 3:05 PM, Lindal Kidd said:

If the scripts are shown as Not Running, you should simply be able to check the box to set them to Running...you should not have to remove and replace the scripts.  Yeesh, what a chore...and very prone to error.

When the script is mod sure

But when its not i am unable to active it

Link to comment
Share on other sites

  • 0
On 11/26/2017 at 7:35 AM, Rolig Loon said:

E

Exactly.  That's why I suggested that the only solution left to you is to replace the disabled HUDs with your backup copies.

I know its a real pain :(

Just hope Linden find what makes that happen and can maybe block it, so ill not have to do it again when ill be done

2 hours ago, Nalates Urriah said:

You are correct that a reset returns a script to a default state. The problem is what the programmer designed the default state to be. There is no universal default state for all scripts.

I make Appliers. Almost all of the Appliers for Slink, Maitreya and others use the same basic workflow to protect their and my work. The script is given to me by Slink, Belleza, or whoever in a startup state. It is waiting for me to tell it how to use my HUD's buttons and where to paste the textures I am using, tattoo, skin, clothes, etc.. I tell it that information by writing information into a notecard according to instructions provided. With the HUD rezzed on the ground and with the Slink, Maitreya, or whatever Applier script loaded, I drop in my notecard. The Applier reads the card and pulls the information into memory then deletes the note card. Thus the UUID of my texture which could be taken from the card is hidden. The Slink maker protects their communications with their product and commerce moves ahead with a minimum of trust required between all parties.

If you reset one of these Appliers, all the information from my card is cleared. The applier is then in a "default" state waiting for a card to be added. For the end user it is non-functional, appearing broke. Certainly not the default state an end user would likely expect.

For various reasons other scripts do similar things. Some scripts are designed with solely the end-user in mind and can be reset without issue. My point is you cannot anticipate with any certainty what the "default" state will be.

I am aware of that, how ever in the case of the HUD's that i talk about here, i am pretty sure thinking about it form the scripting side, that there is very little chance they will do it like that

AO over all restart when they startup at least the type i had (you get messages about the loading the notecard info)

And the body may have that, but over all i think that at least as long as there no castum items inside like something apply it needs to be fine, or at least function in some way so i world have at least known that it fixed the issue

Thanks for the info any how, i get what you mean there, and ya shoud have likely been more cerfual with that

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2311 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...