Zugg Software :: View topic - cmud randomly creating duplicate variables/triggers misfiring

Newbie Joined: 13 Dec 2009 Posts: 6

I'm unsure how to approach asking for help with this issue, since I'm not entirely sure how it's coming about.

With duplicate variables, I understand it's a threading issue, and that when a variable is inaccessible in another thread it creates another copy (?). As soon as this happens, the client seems to randomly work/fail in regards to which triggers will stop firing/etc. I haven't found any pattern to it. For one example, at times when I open the package editor while triggers are firing at least every other second, it will cause this issue to arise (but I can't seem to get it to happen consistently). Closing and restarting CMUD after deleting the duplicate variables seems to fix the problem.

Recently I've had issues with some triggers temporarily failing to work for a while and then returning to working condition, without me doing anything (for example, in a single combat, the same combat message (exactly), getting triggered one time and not the other. The trigger failing isn't happening frequently exactly, but since I use a lot of triggers to sort data between windows, it's very noticeable when one fails. The solution I used for duplicate variables doesn't seem to be working for this problem (I can see triggers get flaky right after a fresh start sometimes).

This is CMUD 2.37, on Vista32.

One of my thoughts is that I could possibly have too many triggers? I make liberal use of enabling/disabling classes to control how many are in use, and I don't ever experience lag from excessive triggering, but for example, my last trigger had 'priority="57650"'. Seems like a pretty high number.

Really, I'd be happy with some sort of way to clean up my package if it's been corrupted or something too. But without any consistent way of causing the problems, I don't know if it'd really be working or not.

Wizard Joined: 22 Mar 2007 Posts: 2320

What you really need to do is avoid the threading problem. As long as you have threading problems, this is going to crop up.

Start by examining every trigger, alias, etc. that uses #WAIT or any related commands. Decide whether you really need that #WAIT or whether you can achieve your purpose in a different way. If you decide you absolutely need #WAIT, figure out whether the trigger is using any variables that could be changed or accessed by any other triggers or commands. That is what is causing your problem, of course. It is possible to avoid these conflicts even when using threading, with the #SECTION command. But it needs to be used sparingly, sectioning only as little code as possible, or you lose the entire point of threading.

If you need help, post the specific code that you want to change, and tell us explicitly what you want to do with it. Include any other bits of code that may be interfering with it.

Newbie Joined: 13 Dec 2009 Posts: 6

I do have one #wait situation that I have to figure out a way to remove, but this is only for one guild (ie. I have classes for each guild such that only one class is active at a time, so most of the time this situation isn't even available). I really can't even open the package editor anymore without risking this issue popping up again.

I'm considering re-evaluating my package and making it more modular (multiple packages devoted to specific aspects) so I can try to isolate issues better, but if this is some kind of separate issue, then I risk simply recreating it.

Are there problems that arise from threading issues that don't originate from the wait commands? The only fairly consistent way I have of pulling it out is when I work with the package editor, and even that isn't an on-demand reproducible effect...

Wizard Joined: 22 Mar 2007 Posts: 2320

The only time you will have multiple threads is if you use the #THREAD command or any of the #WAIT... commands.

Can you describe your setup a little bit more? It may give clues to why you are new variables created. Do you have multiple sessions? Multiple windows? Are the commands that create the variable defined in the main window? A different window? A separate module? Are the unwanted duplicate variables appearing under the main window? Somewhere else? Do you have multiple commands that migh create the variable, or only one?