Zugg Software :: View topic - Variable Scoping Issue and a Couple Minor Issues

Novice Joined: 18 Dec 2006 Posts: 47

I haven't been following all the discussions here as closely lately, so I apologize if these have been covered, but I'm extremely frustrated with cMUD currently.

I have noticed an issue where when triggers start firing quickly, CMUD isn't able to maintain the state of existing variables, and instead just creates new ones with the same name... as this most commonly effects my "Afflictions" table, this gets to be a big problem.

I used to keep my Afflictions variable in a class. It is only modified by two alliases, 'afflict' and 'unafflict' which set the state of each affliction in the table to 0 and 1. Now, this variable is read by many triggers / aliases / etc, but only those two things will update it.

In a relatively small fight, I rarely have any problems with this getting into a bad state, however when multiple people are fighting in the same area, and a lot of text is being processed, this will break like clockwork. Invariably when my curing would freeze up, I'd check back later and find an extra Afflictions variable at the root of my package, which was being updated with the affliction states. The variable in the class was still set to all 0's and it appears all the other triggers were still reading it, as my healing aliases wouldn't register any afflictions.

I read and read, and tweaked and tweaked but could not make this stop. Finally I figured, if you can't beat it, join it, and I deleted the Afflictions variable in the class, and just let it use one in the root of the package that it created. This too does not make it happy however, as just now I had to delete 58 instances of the Affliction variable out of the root of the package after a lengthy fight (in which my curing shut down... again).

I'm at a loss at what to do next. Has anyone else seen something like that? I've blamed my system from day one, and not cMUD, but as I said, I only have two aliases that modify this, and they work fine until the text comes quickly. I'm not sure what else it could be.

Along those same lines, I also notice that when porting my system between my desktop and laptop I get similar oddities (many extra duplicate triggers and variables created in the package root). All I have to do to recreate this is save my package into a file (I always use a new filename to prevent some corruption issues I'd got bit by before). I then send this file over to the other machine. Delete my pkg file, make a copy of the file I just copied over, rename it to the correct pkg name, then launch cMUD.

Everytime this happens I have duplicate triggers and variables created in the project root. Having upwards of 2000 instances is not uncommon.... so then I have to delete all those out before I can start working.

I've also noted that whenever I port the package across machines, my preferences are always lost... however these get lost fairly frequently. I always disable auto-reconnect, however it seems to turn itself back on every day or two, no matter how many times I disable it.

Argh.

Any are of these things known? Any ideas? I'm about ready to give up, and I've got way too many hours invested in this to want to do that.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Novice Joined: 18 Dec 2006 Posts: 47

Thanks for the reply Matt.

If you have any suggestions as to what worked for you, I'd be happy to try them.

The two aliases that affect this variable are:

afflict {
#addkey Afflictions %1 1
}

unafflict {
#addkey Afflictions %1 0
}

I can see how passing one of those a bad argument may add a bad key, but I don't understand how they could result in multiple instances of the afflictions variable.

Apprentice Joined: 11 Aug 2006 Posts: 100

Have you tried using the //ModuleOrWindow/Class1/Class2/varname syntax?

Novice Joined: 18 Dec 2006 Posts: 47

I didn't try that before, no, but now the variable that's causing me the most consternation is at the root of the package, so there should be no need to reference it as you note in your example.

Additionally the extra instances of this variable are all being created at the same level (the package root) as the original variable, so CMUD is already working in the right directory, it's just ignoring instances of that variable name that already exist and creating new ones which are identical versions of the original table, only with a different state.

I suppose that's important to mention, and I forgot to in my OP.

All of these additional variables which contain the table of afflictions contain the ENTIRE table of afflictions. If this was purely a scoping issue I would expect to see variables which only had one or two table entries. This is not the case, every entry is included in every instance of the variable, even though only a handful of the 50 or some odd entries would have been affected by the afflict and unafflict aliases.

The more I think about this, the more this would seem to point to an issue with CMUD, as it seems to be not only creating a new instance of the variable, but copying the contents of the previous instance to the new instance as it does.

Wizard Joined: 17 Jun 2006 Posts: 1201

That's odd. It should work fine since it would be adding the same exact instance of a key on afflict and unafflict. Is there some weird instances of different spelling going on somewhere being carried over? For example paralyzed and paralysed, you would end up with two different versions. However, #addkey is supposed to be unique and "Any existing value for the given key is replaced with the new value" according to the help file. Yet you stated they are identical so I don't see where the problem could be. Otherwise, I would say it is somehow in relation to how you are retrieving the %1.

Novice Joined: 18 Dec 2006 Posts: 47

oldguy... that still wouldn't explain multiple variables... just multiple spellings of keys within said variable.

I just encountered another instance of this, this time simply by opening the settings editor while triggers were firing.

There was nothing going on that would would cause affliction, I was just doing a simple repetitive action where the same (unrelated) trigger was firing every couple seconds. I opened the settings editor, and things instantly went haywire, with 16 instances of the Afflictions variable created (with one disabled) before I could get triggers shut off.

No one else has had this happen?

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Not in over a year and that was in Zmud. Back then if the class containing the variable was disabled then the #addkey might place the variable anywhere. Which usually turned out to be the default class for execution at that moment.

My suggestion? Place the two aliases that change those values into the same class as the variable.

And make a user defined function to test the value of the variable. Something like.

#func gAfflictions %db(@Afflictions,%1)

Then call that function to get the values. This is slower than doing the @Afflictions.blind check for example but it will help with the testing.

Novice Joined: 18 Dec 2006 Posts: 47

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Then it sounds like you have some corruption somewhere in your package. Try deleting your spares and running the compatibility report again. This recompiles things and gets everything pointed where it should if possible.

Did you log the session you mentioned above? If so, I sometimes use this method to track down these sorts of things.

If you copy a selection of text, "This can be a LARGE block." paste it into a variable then use "#show @varname" in the command line can you get the variable to make more copies?

Provided all of that works you could try to narrow down the problem further for us. Or if we can't help you could then try sending your package to Zugg.

Also, are you placing things in the root of a package? They should NOT be there. Settings are meant to be inside either a module or a window. I know how it goes if I can do something without the program complaining then it must be O.K. to do it, not always.

Novice Joined: 18 Dec 2006 Posts: 47

Per your suggestions Arminas:

- I ran the compatibility report, everything checked out with the exception of two aliases I purposely commented out so that I can't run them accidentally. They farm a bunch of data and lock up CMUD for a good four or five minutes in the process.

- I log all my sessions, but the log of the event I mentioned isn't anything noteworthy. The same action had been occurring over and over for half an hour with the same messages being displayed before this mysteriously starting making multiple copies. As I said, I believe it was caused by opening the settings editor.

- I tried #SHOW @Afflictions a bunch of times, but wasn't able to get any duplicates to form by doing that.

- The only things that are in the root of the package are these affliction aliases and variable... which I purposely moved there out of the Curing class as the multiple instances CMUD creates kept showing up there, I thought I could 'trick it into working' if I moved the correct instance there. Aside from that, a few temp triggers are created by alarm statements there, but nothing permanent.

- I'd be happy to send this Zugg if he'd be willing to take a look at it, but I have a feeling he has more pressing issues than trying to debug this entire package.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

As I mentioned the very act of deleting the duplicates and running the compatibility report could solve some problems.

Have you had the duplicate issues SINCE running the compatibility report?

Ok, so you think that the reason that the error occurred was that you had the editor open when triggers were firing. Did you try the #show with the editor open?

I know you said the lines that fired SHOULD NOT have caused any changes in the variable that was affected. I understand that statement but when looking for bugs one often finds that SHOULD NOT can mean STILL DOES.

I just re-read your original post. Did you ever run the compatibility report, and thus recompile, after making those copies?

Novice Joined: 18 Dec 2006 Posts: 47

I've only made one switch back and forth between machines so far, and I made sure to run the compatibility report right away. So far after doing that, I haven't had any duplicates of the Affliction variable.

So far so good, I'll keep an eye on it.