Jump to content

HUD resetting on relog for unclear reasons


DarkklawZ
 Share

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

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

Recommended Posts

A HUD I have created is giving issues for some users, any time they relog. Either several variables are cleared to their default value, or the scripts inside reset entirely, this is still slightly unclear, especially since I cannot replicate the error on my end.

Strangely, this only happens to some people, and for those it does happen to, making sure there is no other HUD attached to the same attachment point seems to prevent it.
Anyone have a clue what might be causing this, and how I solve it?

In case it's relevant, this issue started appearing when I split up functionality over multiple scripts, communicating through link messages. The only time the script is actually supposed to reset is when the changed owner event is triggered.

Edited by DarkklawZ
Tiny clarification
Link to comment
Share on other sites

There are too many unknowns at play here, and we can't see the scripts themselves, so really all anyone can do is guess what's wrong.  On the surface, this sounds like a crosstalk problem, although you said nothing about any chat communication.  For example, it's reasonably common for scripters to create a private channel that is based on the user's UUID.  That seems unique enough until you consider that if the user is wearing objects for which each scripter has used that same trick, the objects can end up talking to each other.  For that reason, I have been taking the precaution of adding a different offset to the channel number each time I write a new script, as in

integer Chan = (integer)("0xF" + llGetSubString(llGetOwner(),0,6)) + 2954;

That's a wild stab at the sort of situation that might cause unexpected crosstalk, and it might explain why it only happens for some of your customers but not others.  It does not explain why it makes a difference whether your HUD and another one share the same attachment point, though. 

Since you can't replicate the error, I think your only chance is to enlist a couple of your afflicted users as guinea pigs.  Create a debug version of your HUD that is loaded with diagnostic statements, and ask the users to try it out and send you the entire output.  You'll have to do some careful thinking first, so you don't end up bothering your guinea pigs with a pile of test HUDs.  At a minimum, get the scripts to tell you who it thinks the owner is and what it hears each time it receives a message from another script.  Find out what values are in key variables when the user relogs or reattaches the HUD, too, so you can tell whether it is resetting or just forgetting some values.  If my own experience tells me anything, it's that the answer will probably be something that you never expected, and that you have been looking in totally the wrong place.

Link to comment
Share on other sites

the attach event is triggered when the hud is attached or detached and on login
the on_rez event is triggered on login and when attached from inventory
check all scripts what they are doing in this events.
if there are any state changes - state_exit and state_entry are triggered everytime.

I never encountered your problem with any of my huds so I doubt that there is any system related problem here.

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2536 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...