Jump to content

HUD resetting on relog for unclear reasons

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

Link to post
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 post
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 post
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...