Zugg Software :: View topic - Access Violation Error (Posting before BUGging)

Beginner Joined: 09 Dec 2000 Posts: 22 Location: USA

Ok... I am using ZMUD 6.62 with Win98SE.

I have narrowed the cause of the following error message:

Access Violation at address 006DA247 in module ZMUD.exe. Read of address FFFFFFFF

to the useage of a bot i have set up to autokill mobs in a zone (i actually have 3 bots for 3 different zones.)

Below is examples of aliases and triggers using the actual command sequences i use (modified to suit the example).

Alias: BotZone1
Alias Command: @Zone1Fighting = 0;@Zone1Bot = 1;@ZoneBotted = "Zone1";@BigMobCount = 0;@MediumMobCount = 0;@SmallMobCount = 0;@BotOption = 1

Zone1Fighting represents whether i'm fighting or not.
Zone1Bot represents that Zone 1 is being botted.
ZoneBotted represents the zone being botted. (same as zone1bot)
Big/Medium/SmallMobCount represents the counters for each mob.
BotOption represents which bot is running (same as zone1bot and zonebotted)

Alias: nobot
Alias Command: #IF (@ZoneBotted != "NOBOT") {#IF (@ZoneBotted = "Zone1") {@Zone1Bot = 0;@ZoneBotted = "NOBOT";@Zone1Fighting = 0;@BigMobCount = 0;@MediumMObCount = 0;@SmallMobCount = 0} {#IF (@ZoneBotted = "Zone2") {@Zone2Bot = 0;@ZoneBotted = "NOBOT";@Zone2Fighting = 0;@FireMobCount = 0;@IceMobCount = 0;@LightningMobCount = 0} {#IF (@ZoneBotted = "Zone3") {@Zone3Bot = 0;@ZoneBotted = "NOBOT";@Zone3Fighting = 0;@GremlinMobCount = 0;@HalflingMobCount = 0;@GhoulMobCount = 0;@GhostMobCount = 0;@OgreMobCount = 0}}}};@BotOption = 0

This alias checks to see which zone is being botted, which ever zone it is, it sets all that zones counts to 0, and effectively states the zone is no longer being botted, and no bot is running.

Trigger Pattern: A big mob stands here
Trigger Command: #IF (@ZoneBotted = "Zone1") {#ADD BigMobCount 1;#IF (@Zone1Fighting = 0) {@Dead = 1;@BigMobBot = 1;#WHILE (@BigMobBot = 1 & @Zone1Fighting = 0) {@Zone1Fighting = 1;@BigMobBot = 0;kill big}}} {}

The above trigger is repeated with patterns matching medium and small mobs. They all act the same way. I walk into a room, the first mob encountered is attacked, setting Dead to 0 (signaling the mob is alive), Zone1Fighting to 1 (signaling i'm in this zone fighting), and MobBot to 1 (signaling this mob is under attack). The other mobs present in the room are not attacked, but their presence is accounted for. The following trigger regards the death. Note the reason of the extra variables signaling fighting and such.. i put these in there to prevent spamming the mud with kill (mobname) for each instance of the mob in the room, yet allow each instance of mobs to be accounted for in the counters.

Trigger Pattern: A big mob falls to the ground with numerous slashes.
Trigger Command: @Dead = 1;@Zone1Fighting = 0;#ADD BigMobCount -1;#IF (@hp >= 125) {#WHILE (@BigMobCount >= 0) {#IF (@BigMobCount >= 0) {#IF (@Dead = 1 & @Zone1Fighting = 0) {#IF (@MediumMobCount > 0) {@Dead = 0;kill medium} {#IF (@SmallMobCount > 0) {@Dead = 0;kill small} {#IF (@BigMobCount > 0) {@Dead = 0;kill big} {}}}}}}} {sleep}

In actuality there are numerous death messages which all have the same trigger command. Triggers like this have been set up for each mob. This trigger first sets Dead to 1 (signaling the mob is dead), then Zone1Fighting to 0 (signaling no fight in this zone in process), then effectively reduces the count of that mob by 1. Now it checks to see if my hps are 125 or above. If so, while the mob count is 0 or greater it will check the count for big mobs, which if detected will verify if dead is 1, and zone1fighting is 0, upon this it will check for medium mobs to kill. If no medium mobs, check for small mobs. If no small mobs, then double check for big mobs and kill them (we already know big mob is there otherwise the while loop would not have initiated). If the hps is less than 125 it will put me to sleep.

I initially type out my alias to turn on Zone1, Zone2, or Zone3 (they each do the same thing, with the commands modified to suit the zone, and the mobs to be counted for). Then i wander around that zone letting the mob detection triggers fire off. They generally kill first mob, then once that one is dead, kills the next one. I have additional triggers to add mob counts if mobs arrive, or decrement if mobs leave. They are simple..

Trigger Pattern: Mob arrives
Trigger Command: #ADD MobCount 1

Trigger Pattern: Mob leaves
Trigger Command: #Add MobCount -1

** Note each pattern is matched to the corresponding mob to add to the corresponding mob counter variable. **

When i decide i'm done botting the zone and want to do something else, i just type NOBOT which will see which bot is running, and shut it down initializing all mob counters for that zone to 0, and fighting for that zone to 0.

I have gone thru all the aliases and triggers and verified the parsing to be correct (zmud does not tell me anything is wrong), and i have created new mud files for the characters i have (one character does not use the hp checker in the death patterns, and it has the same issue as the char spoken of thus far) and imported the settings from the old char files (which were simply renamed in accordinance with other forum posts relating to corrupt settings). The access violation errors still persist when i quit zmud. I logged on, turned the bot on, killed a mob or two, turned the bot off, then quit zmud. access violation errors ensued (which all said exactly as stated above). In another test i logged into the mud, ran around for a bit, then quit zmud. No access violation errors occured. This is how i arrived at the conclusion the bots are causing it somehow.

Something else also.. now and then when i get the error messages, it may come up with a dialog box (i think parse error is the box title) with the command from one of the triggers. It appears to allow me to edit the command. If i remember correctly it only has an OK button to click (it may have another button or two but i'm not sure atm).

Does anyone by chance happen to see anything within the previous alias/trigger examples that may be contributing to the access violations (and/or possible parse error) i recieve every time i quit zmud after running the bot(s)?

I will continue to experiment with the bots, and clean up some of the unceccessary counters used and see what results i get. If i happen to finally find the fix, i'll post an update.

Thanks ahead of time. :)

Beginner Joined: 09 Dec 2000 Posts: 22 Location: USA

Having done some more troubleshooting, and a bit of modification to the nobot alias (which sets all variables used in all bots to 0 and disables the 3 folders which contain bots for their respective zone).. I have come to the conclusion that the error lies somewhere within the death triggers.

I will continue to work on the death triggers, if not completely remake one to see what causes it then report it if i happen to find it.

Thanks

Beginner Joined: 09 Dec 2000 Posts: 22 Location: USA

Welp.. it appears i finally found the cause.. it seems to me the WHILE loop in the death triggers somehow had a hand in the Access Violation errors i had recieved. Below is the revised death trigger commands...

Trigger Pattern: Big mob dies from many slashes
Trigger Command: @Dead = 1;@ElemTowerFighting = 0;#ADD BigMobCount -1;#IF (@hp >= 125) {#IF (@MediumMobCount > 0) {@Dead = 0;@Zone1Fighting = 1;kill medium} {#IF (@SmallMobCount > 0) {@Dead = 0;@Zone1Fighting = 1;kill small} {#IF (@BigMobCount > 0) {@Dead = 0;@Zone1Fighting = 1;kill big}}}} {sb}

Now.. the arduous task of going thru each trigger and modifying it back to simplicity again. :p

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

Yes, that's probably the cause.

#WHILE is a looping command. Once it starts, it continues looping through its commands for as long as the condition remains true. It doesn't wait for another trigger.

#WHILE (@BigMobCount >= 0)
If there were any big mobs, your bigmob death trigger starts a #WHILE loop when the first big mob dies. This loop continues running until you've killed all the big mobs AND ONE MORE (so that @BigMobCount is less than zero) or in other words, forever. When you kill the next big mob, the trigger will be set off again. This will start another #WHILE loop with the same condition and commands as the first one (which will also run forever). This will continue until you have more #WHILE loops running than your computer can handle, at which time you'll receive the access error.

If you had used (@BigMobCount > 0), the loops would at least have had a possibility of ending. However, they still would have accumulated one new loop per mob death until @BigMobCount did reach 0, and probably at least occasional access errors. The always-true condition just made it a certainty that you'd get the error.

Your new trigger has eliminated the problem, but I thought you might want an explanation.