Zugg Software :: View topic - CMUD 230

Posted: Tue Jul 08, 2008 4:47 am

I find now that my scripts are duplicating variables when they are updated placing them in the session window's system folder while the variables in the same folder as the scripts are being ignored. Somewhere along the line the script manager is forgetting where the variables are and just creating new ones. These scripts have been running for weeks (some for months) without problems. The problem is occurring with scripts in different classes, not just a single class. What they have in common is that the target variables are being duplicated.

Beginner Joined: 24 Jun 2008 Posts: 16

This has become very bad again. It came up very frequently in 2.25 and 2.26, stopped happening up to 2.28, and now in 2.30 it is back to happening nearly every time the curing system is engaged. Tried using clean packages, fresh imports, etc.

Posted: Tue Jul 08, 2008 4:58 pm

I need to see more details of your script to reproduce this. Come on guys, you know how this works! Without a specific procedure to reproduce a problem, I can't reproduce it and fix it. My own scripts are working fine, so I have no idea what the problem is.

Are you using the mapper? The mapper should be the only thing using the System folder these days. But give me some specific examples of what is failing so that I'll have a chance of figuring this out.

Beginner Joined: 24 Jun 2008 Posts: 16

Not the mapper, it's off this package:

http://www.catlss.com/uploads/CAT2_-_2.81.zip

It's a curing system for Lusternia. Usually it has issues when it reproduces the variables to the main session, sometimes even a chat capture window, from the curing package. It stopped happening in 2.27 and 2.28, but when I changed to 2.30 it came back. Normally I could just delete the copy in the package and have it include the session in the package's curing, which would make it stop duplicating, but now it just keeps creating them back and forth.

Apprentice Joined: 03 Nov 2007 Posts: 132

Duplicate variables have plagued me with varying degrees of intensity since starting to script in cmud after 1.34. Some versions were chronic (like the one that I managed a procedured to duplicate variables by dragging classes around) and some it was just one offs here and there but it's always been present.

Honestly, at this point I am not certain it's possible to create an exact procedure for when this occurs as it seems able to occur anytime from the perspective of an end user and it's really not something that always repeats. It also doesn't create an access violation so we can't send in crash dumps. It just makes scripts and cmud unreliable.

It just seems like Cmud loses track of variables under conditions. What those conditions are, I couldn't tell you and this is after very heavy usage of the program with complex scripts on a combat intensive mud on a daily basis. It literally can occur with any type of script at any time under intense processing conditions. Is it possible that it has something to do with the threading? I really don't know at this point.

Posted: Tue Jul 08, 2008 7:09 pm

CMUD isn't using threading unless you are using the various #WAIT, #WAITFOR, etc commands. So that shouldn't have anything to do with it.

I understand your frustration, but it's equally frustrating for me since without a way to reproduce it, there is no way for me to fix it. CMUD is about 1.5 *million* lines of code. So I can't just randomly look through the code hoping to find a problem. I play MUDs almost daily and also use some complex scripts (although certainly nothing as complicated as required on IRE muds) and have never run into this problem.

I'm not saying that it doesn't happen to you just because it doesn't happen to me. What I'm saying is that it doesn't seem to happen "easily", which will make tracking down this problem very difficult.

Since the mapper is the only thing that uses the System folder in the current version of CMUD, I can't figure out any way to make this happen without the mapper. However, it was Anaristos who was saying that there were variables created in System folder, but it was Sintor who said he wasn't using the mapper. So with so many people posting about this, it's hard to get a clear view of exactly what is happening.

Malach: Saying that it has happened since 1.34 doesn't really help much since there were *many* beta versions of CMUD 2.x with various duplicate variable bugs. You can check the Version History for this, but I believe the last bug was fixed in v2.27. So yes, any version before 2.27 would have had this problem. v1.34 didn't have the more consistent scoping rules that were introduced in v2.x, which is likely the source of the problem.

Beginner Joined: 24 Jun 2008 Posts: 16

That's consistent with the behavior I had seen, where in 2.27 and 2.28 (I didn't try 2.29, as 2.30 came out fairly quickly) it had stopped behaving in that manner. In 2.30 the variables were duplicating rapidly on me again, as well as some other issues I had had around 2.25 (Some queues not firing, variables not getting set, etc).

Can it be caused by temporary alarms or regular alarms? I know that when I would often have issues with duplicates on the later versions it was during a time when the mud would lag and the herb queue retry timer would go off, often duplicating the variable. That was 2.27 and 2.28, in 2.30 and 2.25 it would just duplicate the variable regardless of any delay, as this is what I am currently experiencing again.

I did notice that my chat capture script which has a temporary .1s alarm delay before capturing started looping as a permanent alarm when it was loaded in 2.30, to the point where I had to disable it. Maybe something in alarms has changed or gone wrong.

Posted: Tue Jul 08, 2008 7:52 pm

I don't know how I could set a procedure to force this problem to happen. The one thing I do that I think may be causing this now is that, because previous versions of CMUD were duplicating variables, I got into the habit of manually creating any variables I would use in a script to make sure that they resided in the correct class folder. So when a script runs for the fist time CMUD needn't create variables because they are already declared. It could be the case that the variable lookup is missing the entries for some reason. However, the duplication occurs at some indeterminate execution of the script, not necessarily the first one. For instance, I found that my OnConnect script has been plagued with this problem, but not consistently. Also, I don't use #VAR or any related command (#ADD, #MATH, etc) to update the variables, I rely entirely on the varname = value syntax. As to the SYSTEM folder, duplicate variables always land there, AFAIK. Using the search function of the VIEW menu backs this up. IMO this is a leftover (the placement in the SYSTEM folder) from zMUD 7.21, where variable duplication was chronic, but for different reasons.

EDIT: One thing that bothers me is that when I look at the compiled code for the scripts in question, the variables are shown to be declared in classes that are not relevant to the script. Since the scripts and the variables are in the same class, that class should be the one shown in the listing.

Beginner Joined: 24 Jun 2008 Posts: 16

And on top of that I'm getting crashes left and right as the variables stack up. They are being created in any class that calls them, regardless of package. Sometimes 3-4 of them in the whole system. Add to that any time I get 3-4 I start getting this dump in the main window:

ERROR: Operator identifier expected requires two arguments
ERROR: Operator expression not allowed here requires two arguments
ERROR: Operator binaryint requires two arguments
ERROR: Operator binaryint requires two arguments
ERROR: Operator alarm pattern expected requires two arguments
ERROR: Operator AND requires two arguments
ERROR: Operator GE requires two arguments
ERROR: Operator INTMARK requires two arguments
ERROR: Operator unrecognized function requires two arguments

This exact package worked in 2.27 and 2.28 with no hitches, heh.

Apprentice Joined: 03 Nov 2007 Posts: 132

I'll do my best to come up with another procedure to get a duplicate reliably. I'm getting the feeling we're just fixing symptoms of a bigger problem though at this point.

Beginner Joined: 24 Jun 2008 Posts: 16

After just sparring and fighting a bit more, any time there's a minute CPU load (and this system is far beyond the recommended specs for cmud) it just clones a variable in whatever class, either in the same package or other packages, it is being called to. I tried it with a single package load and it was still copying them to various classes.

Posted: Tue Jul 08, 2008 10:12 pm

Beginner Joined: 24 Jun 2008 Posts: 16

Zug, I linked you to the package above. That's the exact package, scripts and all, that I'm running that produces the behavior. This, again, is the link:

http://www.catlss.com/uploads/CAT2_-_2.81.zip

It's a single package containing a curing system for Lusternia. What I mean by "being called to" is that any class which contains triggers, events, or functions that reference a variable apparently has the potential to clone said variable inside the class folder.

In essence, it means that there are various classes like a class for say, Elixir cures that deal specifically with elixir messages, whether or not you're trying an elixir cure so you don't just loop it, etc. Another class would have the Afflictions in it. In a basic system you would receive the affliction and check the ElixirTry variable to see if you are currently attempting an Elixir cure or off Elixir balance, then apply the cure or queue the cure accordingly. What happens is, when it checks ElixirTry, it will spawn ANOTHER ElixirTry in the affliction class or any class that checks against a variable not contained within said class.

I reverted and verified that this behavior is unique to 2.30, in that both removing and installing 2.27 and 2.28 then running the same package will have none of these symptoms, but the second I go back to 2.30 I have duplicates all over the place.

Posted: Wed Jul 09, 2008 4:48 pm

I know you gave me the package link before, but I have no idea how to *use* that package. If this is something that can be reproduced with a new Lusternia character, give me the instructions for using the package for a new character. Or try to post some #SHOW messages that will trigger the appropriate parts of the package to simulate what the MUD is displaying. I have no idea what the MUD displays with "elixir messages", so I have no way to test this offline.

Also, are you *sure* that just accessing a variable via @varname causes the duplicate, or is it only when the script tries to assign a new value to the variable via "varname = value" or "#var varname value".

I'm looking over all of the changes made in v2.30 and haven't found anything that would cause this yet.

But like I said above, it would be a lot more useful if you could run the Script Debugger and turn on the new Show Script Execution message at the bottom, along with the Show Variable changes message and then capture a log when you see this problem happen. That would show me the text being sent from the MUD and exactly which scripts in your package are running.

Posted: Wed Jul 09, 2008 5:27 pm

Also, I need to know if this problem occurred in v2.29 or not. You said that it works in 2.27 and 2.28, but you didn't mention 2.29. You can still get 2.29 at http://www.zuggsoft.com/files/cmud229_setup.exe

Posted: Fri Jul 11, 2008 3:05 am

Bumping this thread. I *REALLY* need to know if v2.29 also has this bug or not. If you have the problem with duplicate variables in CMUD, PLEASE test the 2.29 version linked above and let me know. If I can get a firm answer on this, then I might be able to try something to fix this for the next version. Otherwise you'll be waiting a couple of months on this.

Posted: Fri Jul 11, 2008 4:01 am

Yes, I did have this problem in 2.29. But since the script was crashing the application, I thought it was a byproduct of whatever the script was doing wrong.
One thing I noticed is that variables modified in a trigger script are more susceptible to duplication that others.

Posted: Fri Jul 11, 2008 5:05 am

OK, cool, then I think I might know what the bug might be. I was going crazy here because I couldn't find any changes in 2.30 that would cause this. But I found something in 2.29 that might, so that's why it was important to get the confirmation. Hopefully 2.31 will fix it and hopefully I'll be able to release it tomorrow for you.

Beginner Joined: 24 Jun 2008 Posts: 16

I can confirm it in 2.29 now as well, I was booked up on business the past couple days after posting, sorry. I loaded the package clean and sparred a couple times and it was doing the same thing in 2.29 with a fatal crash fairly quickly each time.

Posted: Fri Jul 11, 2008 6:06 pm

OK, I have a preliminary version of 2.31 that I'd like both of you guys to test. You can get it at http://www.zuggsoft.com/files/cmud231_setup.exe

Download that and let me know if it fixes the problem with the duplicate variables. It sounds like it's pretty easy for you guys to reproduce. The 2.31 version changes a "bug fix" that was applied to v2.29 that might be responsible for this.

If 2.31 works, then I'll clean up a few other loose ends and release it to the general public in a few days. Thanks for the help!

P.S. Please see the Version History for details on the other bugs that were fixed in this version.

Beginner Joined: 24 Jun 2008 Posts: 16

I'm stuck in a conference call for the next couple hours, I will install and test right after that.

Beginner Joined: 24 Jun 2008 Posts: 16

So far, so good. Couple tests down with no extra variables.

Posted: Sat Jul 12, 2008 7:14 pm

I have installed CMUD 2.31, however, I am unable to run it because it keeps failing with the following message:

C:\Program Files\CMUD231\cmd.db is not a valid SQLite database.

I got around the problem by running CMUD as an administrator under VISTA Home Premium SP1. However, I don't think that can be viewed as a long term solution.

I will post later on any problems I may run into.

EDIT: I have to run it strictly as test, attempting to use any of the session files from CMUDPro2.30 won't work. This is because of the change in SQLite. So the package for my session cannot be read or, at least, is not being read.

Wanderer Joined: 12 May 2007 Posts: 59

I have this problem sometimes too. But I've since gotten into the habit of explicitly defining #CLASS before I do any assignment and this seems to solve the problem.

Posted: Mon Jul 14, 2008 5:25 pm

Anaristos: Hmm, sounds like 2.31 is trying to open cmd.db in read/write mode, which Vista doesn't allow for files in the Program Files directory. I *really* hate that part about Vista...it's worse that any of the other UAC stuff in Vista in my own opinion.

Anyway, I'll fix that in the public release...for now just test it by running as Admin.

However, that shouldn't effect reading any of your session files. On Vista, your session files should be stored in the My Documents/My Games/CMUD area which *does* allow writing. I don't have any problem loading existing sessions, and it seems that Sintor was able to load his session, so I'm not sure why you'd be having this problem.

Make sure you don't have your session files stored in the Program Files area. That's a bit no-no on Vista.