Zugg Software :: View topic

Posted: Thu Nov 29, 2007 9:13 pm

Everything in CMUD has a priority assigned to it (it's one of the fields in the database), but not everything *uses* the priority value. The XML only shows the priority if CMUD uses it. Priority for Variables doesn't make any sense and CMUD doesn't use it.

In the old un-readable XML dump (like in v1.34), it was dumping the raw database records, so you'd still see the priority field in there.

Apprentice Joined: 03 Nov 2007 Posts: 132

Well, I'm at a loss for anything further to do with this package to stop the access violation and list out of bounds errors. I've send you the package and the instructions on duplicating the problem Zugg. I'm starting to think it has something to do with Vista since apparently all the weird Vista stuff happens to me! We'll see though.

Wizard Joined: 17 Jun 2006 Posts: 1201

Well it almost sounds like I wrote this post because this is all of the same stuff that happened to me and why I just gave up. When I asked if people were doing serious testing in IRE muds everyone said oh yeah we do, but that is not what I am getting out of this thread... I think it boils down to the multi-threading and complex alarms. I tried using #Section too and had no luck. Using #wait sucks, and I really couldn't figure out any way other than using alarms without making it too slow. In fact I ended up deleting all of my afflictions and defenses databases and just made single variables for each affliction and defense because it is much faster, even if I did end up with like 50 or 60. Everyone can say you don't have to be a programmer, but with multi-threading and being able to take advantage of it and use it properly you almost do it seems.

Apprentice Joined: 26 Apr 2007 Posts: 113

I've got to agree with some of the frustration, however, I have found since I started using a different package that a lot of my problems are gone. I've not made my package big enough to aggravate any of the old problems yet, so I'm not so sure.

Multithreading is the cause of a lot of it, in my opinion, but I think the reasons Zugg implemented it are completely valid.

Yes, I play an IRE mud primarily, I haven't given up on the program yet, though. Fang, Vijilante, etc, say they play IRE muds regularly and run a wide range of scripts comfortably, so I'm putting a bit of faith in that it's something wrong on my end of things.

My posts have been scarce recently because of long work hours, but I'm happy to keep chipping away at Cmud to see if it can be worked out. Yes, it's annoying to go from being one of the better fighters in a game to keeling over to people I'd have never died to before, but I'm confident the client has every potential of being far better than Zmud in every way.

As for multiple variables, I've had the problem once or twice (not at all since I started using a new package.) I'm assuming that you, like me, use #VARIABLE var1 value. Have you tried simply using var1=value? I know I had problems in 1.34 where #VAR was being a pain but var1=value worked fine.

Posted: Fri Nov 30, 2007 10:06 am

Apprentice Joined: 03 Nov 2007 Posts: 132

Here is something new that I've noticed that might be a clue to someone more CMUD saavy than myself. When I get these AV errors, pointer errors, and list index out of bounds errors, some of my database records get cleared out. These are permament records that I don't write to at any point in any of my scripts. They are just read from very very often. Sometimes after an error they all will be cleared out. Sometimes just a couple of them. It is possible that they are just being read from at the time that the error gets thrown and so some weird memory thing clears them out but thought I'd mention it. Going to try deleting them and rebuilding them and see if that makes a difference

EDIT: Rebuilt them, no difference. Here's another question though. Let's say I have one thread that is looping through a stringlist doing something to each value of that stringlist. Let's say I have other threads that are deleting items from that stringlist as well as adding them to them. Might this cause some access violation errors if the forall loop tries to access a record in its loop that is no longer there?

Posted: Fri Nov 30, 2007 5:40 pm

Apprentice Joined: 03 Nov 2007 Posts: 132

Sections seem to simple on the surface but whenever I try to apply them in my scripts I end up terribly confused. But if it wouldn't throw the AV error I won't worry too much about it right now. Just searching for possible causes

Posted: Fri Nov 30, 2007 6:09 pm

Yes.. that would be a problem.. that would be a bit of code that would need to have a #section around it because your #FORALL may be trying to access something that isn't there.

I realize you don't want to post your code, but maybe even some code snippets will give some insight to what you are trying to do.

Apprentice Joined: 03 Nov 2007 Posts: 132

Well, Zugg's example pretty much has it.

I have triggers that will call up an event that will add an item to a list. I have triggers that will call up an event that will delete an item from that same list. And I have one function that is called by an expression trigger/alarm (kind of up in the air since I keep changing things trying to track down these AV errors.) that loops through that list, compares it to a static list and then sends the %i value off to a different function.

All are very short scripts and very fast so in theory there should be no parallel thread problems but I can put sections in the events and the function without too much difficulty.

My main interest in the topic was whether trying to access a list record that no longer existed would through a memory type error but apparently it won't.

Posted: Fri Nov 30, 2007 10:13 pm

OK, I've made some changes to alarms in 2.14 that hopefully will help with this. First, as mentioned in another thread, alarms will now only fire again *after* they have finished executing. So you won't get multiple copies of the same alarm running at once.

The bigger issue was handling when the Windows WM_TIMER messages were being processed. As you might recall from other discussions, CMUD blocks Windows Messages while executing a script. This prevents you from entering another command (or macro, etc) in the middle of a currently executing thread. The Window Messages are just queued up until the thread is finished (or suspended, like with a #WAIT command). This prevents parallel thread execution, unless the user specifically uses a #WAITxxx command.

However, Alarms generate WM_TIMER events in Windows. And WM_TIMER events *were* getting processed during other threads. This is what made alarms highly unsafe in the past few versions. Even though I thought I had changed it to prevent alarms from running as background threads, this issue with WM_TIMER events being processed was still causing alarms to get executed in the middle of other threads.

I have fixed this in v2.14 so that WM_TIMER messages are also blocked during thread execution (again: unless you put a script into the background using #wait). This seems to be working much better. Here is the killer stress-test that I just tried in v2.14:

Apprentice Joined: 03 Nov 2007 Posts: 132

I'm moving this weekend but hopefully I'll have a chance to play with it tomorrow night or sunday. I'll be curious to see how it works!

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Wow! It sounds like you have pratically nailed down every problem possible with making alarms global. I guess it is time for me to throw together a package with all sorts of examples for how to make use of global alarms in easy window specific fashions. Nice work Zugg! Very Happy

Apprentice Joined: 03 Nov 2007 Posts: 132

Excellent news so far!!! I ran my current package with the standard testing I've been doing. Very, very smooth. No AV errors at all and before I would get them pretty regularly (as I'm sure you all remember me mentioning once or twice :p). But I decided the real test was my old package that I sent to Zugg that had so many more alarms than this one.

I just turned on the test and let it run while I've been packing and not one AV error yet in 30 minutes straight of running heavily and with this package I was getting incessant AV errors within about 15 seconds of starting the test before.

Oh and no duplicates so far!

I'm not going to jump the gun and say it's fixed but it's looking really really nice so far.

EDIT: At an hour now, no hitches.

Posted: Sat Dec 01, 2007 2:13 am

Woohoo! Thanks for letting me know. Keep testing what you can over the weekend (I know you are moving though...I hate moving ;)

But I'll sleep better tonight because of your post!

Apprentice Joined: 03 Nov 2007 Posts: 132

Just had two intense fighting sessions while connected that lasted about 15 minutes a piece. No errors thrown! Yaaay!