Zugg Software :: View topic

Wizard Joined: 17 Jun 2006 Posts: 1201

I posted about this before with the last version at http://forums.zuggsoft.com/forums/viewtopic.php?t=28072.

However, for some reason at completely random times(meaning it doesn't happen all the time and therefore wouldn't be one of my triggers) it is sending weird stuff to the MUD. Not only does it send the value of the status bar sometimes while other triggers are going off, but just sends numbers when I hit a macro or something.

This time I hit a macro. All that is in this macro is an alias followed by a value, in this case "todo attack".

Posted: Sun Sep 02, 2007 5:24 pm

Check to see if the Auto Append option is turned on for your Alias. There are still some bugs with the Auto Append option that sometimes causes it to send numbers.

We've talked about the status bar issue in the other thread. There is no way that CMUD can magically send the contents of your status bar to the MUD, so there must be something corrupted in your settings that is causing this. It doesn't sound like you have started your settings from scratch like we already suggested.

Wizard Joined: 17 Jun 2006 Posts: 1201

Zugg here is something that just happened.

I entered the command SW which I have to an alias that will reset all rites I have put down (since I moved there are no longer rites in the room I am in).

The value of SW is:

southwest
rites = ""
castingdemons = 0
castinghealing = 0
castingcleansing = 0

I entered SW, it sent southwest to the mud, and CMUD crashed. This is the bugreport.

callstack crc : $6ee76593, $11138f3c, $11138f3c
count : 2
exception number : 1
exception class : EAccessViolation
exception message : Access violation at address 00405BA4 in module 'cMUD.exe'. Write of address 00000008.

Main ($310):
00405ba4 +028 cMUD.exe System @LStrAsg
00935366 +01a cMUD.exe PRealStr 748 +5 PRealNode.Copy
00d47d89 +11d cMUD.exe CodeExec 2458 +27 HandleLocalAssign
00d492da +6b2 cMUD.exe CodeExec 2821 +109 TCodeExec.InternalExecute
00d411d1 +06d cMUD.exe CodeExec 469 +9 TCodeExec.Expression
00d45244 +014 cMUD.exe CodeExec 1670 +1 BoolExpression
00d473f1 +50d cMUD.exe CodeExec 2274 +64 HandleCom
00d4918f +567 cMUD.exe CodeExec 2798 +86 TCodeExec.InternalExecute
00d41110 +08c cMUD.exe CodeExec 447 +12 TCodeExec.Expression
00d3882e +086 cMUD.exe PrefDat 10534 +10 TCacheNode.GetCaption
00d353f3 +0bb cMUD.exe PrefDat 9079 +15 PrefRec.InternalGetCaption
00d354ed +00d cMUD.exe PrefDat 9118 +1 PrefRec.GetCaption
00ca4a78 +0ac cMUD.exe MAIN 9936 +18 TMUDForm.CompileStatus
00ca4bf5 +079 cMUD.exe MAIN 9962 +5 TMUDForm.UpdateStatBar
00ca1d3e +022 cMUD.exe MAIN 8718 +1 TMUDForm.StatMes
00ca1eea +122 cMUD.exe MAIN 8767 +37 TMUDForm.MUDSockInfo
00a26180 +018 cMUD.exe zsock 675 +2 TClientSocket.DoInfo
00a25ca3 +00f cMUD.exe zsock 515 +1 TClientSocket.Send
00c8e39a +072 cMUD.exe MAIN 2543 +5 TMUDForm.SendRaw
00c914ea +3ce cMUD.exe MAIN 3487 +58 TMUDForm.SendStr
00c917ed +211 cMUD.exe MAIN 3531 +26 TMUDForm.RecordSendStr
00c47e36 +00e cMUD.exe CodeThread 982 +0 TRunCodeThread.DoRecordSendStr
0047d901 +101 cMUD.exe Classes 9339 +22 CheckSynchronize
00c470cc +08c cMUD.exe CodeThread 393 +11 MsgWaitForSingleObject
00c47208 +024 cMUD.exe CodeThread 446 +4 WaitForThread
00c996b0 +118 cMUD.exe MAIN 5720 +33 TMUDForm.ExecThread
00c9a023 +3eb cMUD.exe MAIN 5893 +44 TMUDForm.NewProcessStr
00c9935a +026 cMUD.exe MAIN 5636 +2 TMUDForm.ProcessStr
00c98e22 +092 cMUD.exe MAIN 5511 +12 TMUDForm.ParseCommand
00ca70c3 +223 cMUD.exe MAIN 10747 +34 TMUDForm.Command
00ca83c2 +25e cMUD.exe MAIN 11092 +37 TMUDForm.FormKeyDown
00cceaee +012 cMUD.exe MAIN 19470 +1 TMUDForm.UserInKeyDown
0050b5a0 +030 cMUD.exe Controls 7026 +1 TWinControl.KeyDown
008bf576 +012 cMUD.exe RVScroll 548 +1 TRVScroller.KeyDown
0086e17d +011 cMUD.exe RichView 1842 +1 TCustomRichView.KeyDown
0084a754 +090 cMUD.exe RVEdit 1625 +14 TCustomRichViewEdit.KeyDown
0050b618 +06c cMUD.exe Controls 7043 +10 TWinControl.DoKeyDown
0050b646 +012 cMUD.exe Controls 7052 +1 TWinControl.WMKeyDown
0084a62d +1d5 cMUD.exe RVEdit 1591 +36 TCustomRichViewEdit.WMKeyDown
00505c9e +036 cMUD.exe Controls 4552 +5 TControl.Perform
0050c3c9 +0dd cMUD.exe Controls 7471 +18 TWinControl.CNKeyDown
00505f93 +1df cMUD.exe Controls 4645 +53 TControl.WndProc
00509cc2 +18e cMUD.exe Controls 6342 +33 TWinControl.WndProc
00509894 +034 cMUD.exe Controls 6237 +3 TWinControl.MainWndProc
0047fef8 +014 cMUD.exe Classes 10966 +8 StdWndProc
7e4196c2 +00a USER32.dll DispatchMessageA
00c4700f +0af cMUD.exe CodeThread 360 +10 ProcessMessage
00c4711a +0da cMUD.exe CodeThread 405 +23 MsgWaitForSingleObject
00c47208 +024 cMUD.exe CodeThread 446 +4 WaitForThread
00c99911 +175 cMUD.exe MAIN 5775 +32 TMUDForm.ExecThread
00c9f925 +455 cMUD.exe MAIN 7847 +87 TMUDForm.ExecTrig
00c9d827 +e53 cMUD.exe MAIN 7116 +282 TMUDForm.HandleTrigger
00c9c4f4 +00c cMUD.exe MAIN 6675 +1 TMUDForm.UserOutNewLine
00a6be65 +039 cMUD.exe term 8313 +3 TTerm.DoTriggerLine
00a6bed8 +048 cMUD.exe term 8324 +4 TTerm.TriggerNewLine
00a6b139 +645 cMUD.exe term 8013 +95 TTerm.PutText
00a6b6d1 +049 cMUD.exe term 8121 +2 TTerm.Add
00c89bad +0b1 cMUD.exe MAIN 1378 +8 TMUDForm.OutputStr
00c89e49 +09d cMUD.exe MAIN 1447 +15 TMUDForm.NextMUDLine
00c8a270 +020 cMUD.exe MAIN 1517 +4 TMUDForm.DoNextLine
00505f93 +1df cMUD.exe Controls 4645 +53 TControl.WndProc
00509cc2 +18e cMUD.exe Controls 6342 +33 TWinControl.WndProc
00526da0 +478 cMUD.exe Forms 3098 +103 TCustomForm.WndProc
00509894 +034 cMUD.exe Controls 6237 +3 TWinControl.MainWndProc
0047fef8 +014 cMUD.exe Classes 10966 +8 StdWndProc
7e4196c2 +00a USER32.dll DispatchMessageA
0052ee48 +0ac cMUD.exe Forms 6873 +13 TApplication.ProcessMessage
0052ee8f +00f cMUD.exe Forms 6892 +1 TApplication.HandleMessage
0052f12a +0a6 cMUD.exe Forms 6976 +16 TApplication.Run
00db3d88 +088 cMUD.exe CMUD 337 +18 initialization
7c91312f +069 ntdll.dll RtlUnicodeStringToAnsiString
7c812b94 +0b6 kernel32.dll GetVersionExA

error details:
entered a command to go southwest

Posted: Mon Sep 03, 2007 5:22 pm

OK, the error details show my that when it tried to update the status bar, it got an error compiling it.

I think your status bar definitions are messed up. You should go through each one and make sure they each compile. My guess is that you've got some sort of syntax error in one of your status bar entries, probably related to using something that looks like a local variable assignment (something with a $ in it?)

So post your status bar definitions so we can look at them.

Wizard Joined: 17 Jun 2006 Posts: 1201

Posted: Tue Sep 04, 2007 12:16 am

That seems to compile just fine. Works great on my system here, although the yellow-on-black color of the last item seems to continue to the end of the status bar, so I'll look into that.

Do you have any other scripts anywhere that use the #ST or #STWIN commands?

Do you have *any* other status bar definitions? According to the crash dump that you posted, the status window definition that caused the crash contained some sort of CMUD command call. And I don't see any command call in the status definition that you posted. Still makes me think that you have a corrupted status bar definition somewhere in your settings.

Wizard Joined: 17 Jun 2006 Posts: 1201

Posted: Tue Sep 04, 2007 5:14 pm

Well, then I really can't help with your problems until you create a new blank package and start from scratch creating your settings. Because according to the crash dump that you gave above:

Wizard Joined: 17 Jun 2006 Posts: 1201

Is there an easy way to do this? I have like 50 class folders and some of those have like 50 sub class folders all of which contain numerious triggers, aliases, variables, macros, functions and so on. Why do my settings keep getting corrupted? I guess I will just wait until I have a LOT of time to go through everything and enter them one by one. Crying or Very sad

Posted: Tue Sep 04, 2007 10:28 pm

My guess is that your settings got corrupted a long time ago and have kept getting worse and worse. That's the downside to Beta testing. It's sort of like beta testing an online game and getting your beta character wiped. You aren't supposed to be beta testing just to get your hands on the latest version...you are supposed to be beta testing to help me find and solve bugs in the software. If you wait for the public version, then you should be able to Export your settings to XML and them import them into a new package. But in v2.02 there are still problems with XML import, so this won't work yet.

If you want to try and find out where the bad script or corrupted settings are, you can try disabling all of your class folders and then re-enable them one by one until the problems with the status bar start appearing again.

Wizard Joined: 17 Jun 2006 Posts: 1201

By the way, this is the same exact package I used in 1.34, and I had no problems with it. Is it getting corrupted when I open it into 2.02? I save a backup of my packages when I change things and always keep a backup in a different directory. When I installed 2.02 I copied my backup into the packages folder and then used it. When I deleted everything after uninstalling 2.02 I still have my original package that I just reloaded back into 1.34.

I understand the point of beta testing, and I certainly do want to help out. I just want to figure out if it is me or a bug. Unfortunately it looks like it is me.

Posted: Wed Sep 05, 2007 12:41 am

I'd like to figure out if it's a bug too. That's why I suggested disabling your classes to try and narrow down the problem. Loading it into 2.02 shouldn't cause any corruption, but 2.02 might be sensitive to something because of the new threading code that wasn't a problem in 1.34. That's why it's always important to check the compatibility report to make sure everything is compiling properly. But until you get the problem narrowed down, there isn't much that can be done since it sounds like you have too many scripts to post, which means that your settings are pretty complicated.

Wizard Joined: 17 Jun 2006 Posts: 1201

Hehe, well yeah I do and they probably are. Every time I am in the game I think of something new to add or change to make it better. Also I am not an expert, but I think you are right, because I was thinking it seemed like it has to do with the new threading but am not qualified enough to figure out what it would be that is causing it to be sensitive. I had to press escape a few times for what seemed like absolutely no reason. Another thing I noticed is my alarms seemed to cause problems. I use quite a few alarms for things.

I think I will wait until the next update and then try again while using your advice and disabling the classes and try and narrow it down. Thanks for your help.

Posted: Thu Sep 06, 2007 5:18 pm

One other idea you can try is using the #THREAD command to view what threads are "stuck" in the background. Usually this command will list a single thread (the thread running the #THREAD command itself). But if you have any other threads that are still running, you will see them listed along with the trigger or script that they are running. So that might help you track down something.

When using Alarms, it's important to remember that in v2.0, the threading system allows multiple alarms to fire and run at the same time. In the past, if Alarm A and Alarm B fired, Alarm A would be completed before Alarm B was executed. In v2.0, Alarm A and Alarm B both run simultaneously in different threads. So, if you have multiple alarms that are writing to the same variables, then you might end up with thread locking, or other problems.

Just keep in mind that at any point in your alarm script, Windows might run part of another script. For example, imagine the following code:

Wizard Joined: 17 Jun 2006 Posts: 1201

Would it be better to use #wait now?

Posted: Fri Sep 07, 2007 4:34 pm

I imagine not - the problem remains the same. If something that's waiting starts executing again while the second script is between the if and the show, you'll get the same problem.

This complication is a big one - it potentially affects anyone who uses wait or alarms, which puts a big dent in what was almost a seamless move to multithreading. Is there something you can do to prevent people from having to use critical sections like this, Zugg?

Posted: Fri Sep 07, 2007 5:55 pm

This is the nature of having threads. If two scripts are going to be running at the same time, then there will always be issues if you try to write to the same data from both threads. There isn't any "magic" to get around this. Multithreading is never seamless.

We had another thread about the details and issues of multithreading over in the main CMUD forum a few weeks ago (that's where we initially discussed needing something like #SECTION). As I said in that thread, the main purpose for #WAIT is to do *simple* stuff like:

command1;#WAIT 1000;command2

where you are just trying to send multiple commands to the MUD with a wait time between them. When you start getting more complicated than this, and start accessing global variables, then you have to start worrying about the threading.

These issues aren't actually just issues with threading. With a multitasking operating system like Windows XP, even in old versions you could have two alarm scripts running at the same time in some cases. Older versions of Windows (eg Win98) didn't do this, but Windows XP and Vista have true preemptive multitasking and using any command in zMUD/CMUD within an alarm that would allow windows messages to be processed could cause similar issues. At least in CMUD there are now mechanisms like #SECTION to deal with these issues properly.

The best way to deal with these issues is to use #SECTION to protect access to global resources, or to use Local variables whenever possible to avoid any problems. And it's really only going to be a problem with complicated scripts, but I mentioned it above because we already know that oldguy2 has a complicated script setup.

Anyway, back to the original issue: Fang is correct: using #WAIT isn't going to help. #WAIT causes parallel threads to be created, so you end up with the same issues.