Zugg Software :: View topic

Novice Joined: 18 Dec 2006 Posts: 47

The following alias (which worked in v1.34) is giving me an Access Violation:

#VAR Squinting 1
#VAR SquintDir %array("n","ne","e","se","s","sw","w","nw","u","d","in","out")
squint n
squint ne
squint e
squint se
squint s
squint sw
squint w
squint nw
#alarm "squint_alarm" +2 {#VAR Squinting 0;#VAR SquintIndex 1}

I had made an earlier post about this during the beta period, but couldn't ever seem to nail down what was happening, now it seems to be happening more frequently. I've submitted another in-client bug report as well.

This is happening in a number of different situations, but this alias seems to be the easiest way for me to recreate it.

Novice Joined: 18 Dec 2006 Posts: 47

I did realize there is an additional trigger that watches for the output from the Squint command, to increment the direction that's being squinted at to determine which direction potential targets are in.... this also might be part of what is causing this.

I'm surprised though that no one else is reporting similar issues. 2.18 is virtually non-playable as my primary client due to the large number of access violations I run into. This is using the exact same system I used on the previous public release which caused me no problems whatsoever.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

The alias above gives me no problems at all. Have you tried recreating the package by copying the XML from the existing one, making a new package then pasting the XML back in? Often if there's some corruption then that'll fix it.

Novice Joined: 18 Dec 2006 Posts: 47

I tried your suggestion, it hadn't occurred to me that all of these aliases/triggers are in the same package, perhaps it would just be easier to post the XML for the whole package, as it's quite likely an interaction issue between all of these.

Novice Joined: 18 Dec 2006 Posts: 47

This issue has been driving me insane, as it pops up all the time, essentially making 2.18 worthless for me. I've finally narrowed it down to when this is happening, but I still have no idea why, as it doesn't sound like anyone else is having this issue.

The Access Violation occurs every time I try and create an alarm, thus why it occurred in the above alias.

Just entering:

#alarm "concentrating" +2 {#var Concentrating 0}

at the command line will cause it to occur. It always occurs at the same address, no matter which alarm I'm trying to create, 9065646F.

Any ideas? I'm going crazy with this.

Posted: Mon Jan 07, 2008 11:57 pm

Not sure what to suggest. I just entered:

#alarm "concentrating" +2 {#var Concentrating 0}

and didn't get any crash or other problem.

Posted: Tue Jan 08, 2008 1:23 am

MNGrizzly I've seen some unpredictable results when I have variables/triggers with identical names and I try to disable the trigger that has a variable with the same name. Try making the names of the trigger/variable unique and see if you still have an issue.

Novice Joined: 18 Dec 2006 Posts: 47

This is something I've tried to be careful with, and a quick search of the package I'm working with shows this alarm name and variable name are unique.

I am using Vista ultimate, and I have now been able to reproduce this on two different machines, both with fresh OS installs.

Is there any additional info I can send you Zugg to help you debug this? Obviously if I can't use alarms, I'm more or less dead in the water with CMUD.

Posted: Tue Jan 08, 2008 5:50 pm

If you can reproduce it, give me the exact step-by-step procedure here, starting with a blank session.

Novice Joined: 18 Dec 2006 Posts: 47

Argh. I'm pulling my hair out.

I created a new blank session, and no alarm issues. I tried to copy the XML from my old session, into this new session. That didn't work, something was corrupted. Then, I started adding each major class one by one (I have around 8). I would do a New Class in the new session, then copy the XML from the old session into this newly created class. This worked, sort of, some of the time, but now corruption issues abound.

Some aliases/triggers/variables are just missing in action, other times variables or trigger names now became classes, and vice-versa. Things that should have been in one class wound up in another. Very screwy. I'm not sure what else to do to try and recreate the original issue, it looks like a corrupted package. I'll create a new thread for this new problem.

Novice Joined: 18 Dec 2006 Posts: 47

Something else interesting...

When creating a new package, this didn't happen. When I copy/paste XML from the bad package into a new one, this Alarm error doesn't seem to occur. (Although that could be misleading as I'm having issues duplicating the original package that way) However, when I export/import XML to the new package, the Alarm still occurs.

Sorcerer Joined: 13 Jan 2006 Posts: 715

Have you sent the crash dump in?

Novice Joined: 18 Dec 2006 Posts: 47

Yes, a few times now.