Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion Goto page 1, 2  Next
Anaristos
Sorcerer


Joined: 17 Jul 2007
Posts: 821
Location: California

PostPosted: Tue Jul 08, 2008 4:47 am   

CMUD 230 - Variables being duplicated
 
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.
_________________
Sic itur ad astra.
Reply with quote
Sintor
Beginner


Joined: 24 Jun 2008
Posts: 16

PostPosted: Tue Jul 08, 2008 4:52 pm   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Sintor
Beginner


Joined: 24 Jun 2008
Posts: 16

PostPosted: Tue Jul 08, 2008 5:24 pm   
 
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.
Reply with quote
Malach
Apprentice


Joined: 03 Nov 2007
Posts: 132

PostPosted: Tue Jul 08, 2008 7:02 pm   
 
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.
_________________
Intel Core2 Quad CPU @ 2.4 GHZ with Windows Vista Home Premium and 2 GB Ram
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Sintor
Beginner


Joined: 24 Jun 2008
Posts: 16

PostPosted: Tue Jul 08, 2008 7:20 pm   
 
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.
Reply with quote
Anaristos
Sorcerer


Joined: 17 Jul 2007
Posts: 821
Location: California

PostPosted: 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.
_________________
Sic itur ad astra.
Reply with quote
Sintor
Beginner


Joined: 24 Jun 2008
Posts: 16

PostPosted: Tue Jul 08, 2008 8:32 pm   
 
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.
Reply with quote
Malach
Apprentice


Joined: 03 Nov 2007
Posts: 132

PostPosted: Tue Jul 08, 2008 8:33 pm   
 
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.
_________________
Intel Core2 Quad CPU @ 2.4 GHZ with Windows Vista Home Premium and 2 GB Ram
Reply with quote
Sintor
Beginner


Joined: 24 Jun 2008
Posts: 16

PostPosted: Tue Jul 08, 2008 8:43 pm   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Jul 08, 2008 10:12 pm   
 
Quote:
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

The class name shown in the compiled code is *not* the class that contains the variable. It is the name of the "current class context" at the time that the code was compiled.

Sintor: With all of those errors, you need to create a separate post about them and post the script that you are running to get this. But if you have duplicate variables with the same name in the same class, then CMUD *is* going to crash and won't work properly until the duplicates are removed.

However, the problem Anaristos posted did not indicate that duplicate variables were being created in the same class...his variables are being created in the SYSTEM class. So if your variables are being duplicated in the same class as the existing variables, then it is a different problem entirely.

Yes, Alarms might be causing this. Like I said, I need to see some sample code here. At this point I have nothing to go on. Someone needs to post the XML dump of their scripts, along with a dump of text received from the MUD. Then I can try loading the script here and replay the MUD text to see what is happening. That's the kind of detailed information that I need to have any hope of tracking this down.
Quote:
it just clones a variable in whatever class, either in the same package or other packages, it is being called to

What do you mean by "being called to". I don't have any clue what your scripts look like or what kind of package or class structure you are using. You need to be a lot more specific about this. How is the variable being "called". Is it some Alias or Trigger that is assigning a value to the variable? How exactly is the variable being assigned? If it is a trigger, how does it get triggered? If it's an alarm, what causes the alarm to fire.

I don't have any character on Lusternia to test this. I have no idea how to use the package that you posted above.
Quote:
I tried it with a single package load and it was still copying them to various classes.

What do you mean by "various classes"?? Are you getting multiple copies of the same variable in the same class? If they are being created in other classes, tell me more about the other classes when where they are used in your script. Anaristos is getting them in the SYSTEM class...are you also getting them in the SYSTEM class? Or other classes?

Please give me more specific information. I can't read your minds!

What would be really useful is if you guys could turn on the Script Debugger and try to catch an instance where the variable is being duplicated so that I can see what script is running when it happens. There is a new message in the Script Debugger that will display the name of each script that is executed, and a message that will show when a variable value is changed.
Reply with quote
Sintor
Beginner


Joined: 24 Jun 2008
Posts: 16

PostPosted: Tue Jul 08, 2008 10:33 pm   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Anaristos
Sorcerer


Joined: 17 Jul 2007
Posts: 821
Location: California

PostPosted: 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.
_________________
Sic itur ad astra.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Sintor
Beginner


Joined: 24 Jun 2008
Posts: 16

PostPosted: Fri Jul 11, 2008 5:36 am   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Sintor
Beginner


Joined: 24 Jun 2008
Posts: 16

PostPosted: Fri Jul 11, 2008 7:34 pm   
 
I'm stuck in a conference call for the next couple hours, I will install and test right after that.
Reply with quote
Sintor
Beginner


Joined: 24 Jun 2008
Posts: 16

PostPosted: Fri Jul 11, 2008 9:57 pm   
 
So far, so good. Couple tests down with no extra variables.
Reply with quote
Anaristos
Sorcerer


Joined: 17 Jul 2007
Posts: 821
Location: California

PostPosted: 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.
_________________
Sic itur ad astra.
Reply with quote
emnaki
Wanderer


Joined: 12 May 2007
Posts: 59

PostPosted: Sun Jul 13, 2008 3:21 am   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net