Zugg Software :: View topic - [2.18 Pro] Window disabled for no apparent reason

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I'm editing and testing my new combat system. It's obviously very complex and that makes it difficult to track down the source of some of the stranger things I'm seeing when working with CMUD. My latest conundrum involves my one and only window (containing just a single #GAG trigger) being disabled when a certain trigger fires in a certain way.

The trigger giving me the troubles (or so it seems, since I can't pin this down yet) is this:

Posted: Sun Dec 16, 2007 12:41 am

Is it possible that you have a room trigger that's preventing the other rune trigger from firing?

Also, you may have simplified it but I"m not sure what your inner ALARM is supposed to accomplish.

Posted: Sun Dec 16, 2007 11:10 am

Could be an anti-illusion countermeasure, I guess, because runes have a recovery time. Someone's name will only be in the variable for 1s after they've cast a rune, and perhaps the i_runes alias checks that.

Anyhow. While they're almost certainly irrelevant to the problem, there are two pretty naff syntaxes in there - the first is %%1, which is invalid, and "anti_"%1 to create the alarm's ID should probably be explicitly concated. Is this trigger actually compiling with the invalid syntax in there?

What does the i_runes alias do? Does this problem still occur with that alias disabled?

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I would try the named parameter approach, except then I'd have to make a special alias just to create the alarm, wouldn't I? I suppose all the logic could just be moved into the i_runes alias (which right now just looks up the names of the two rooms in a data record of afflictions by rune name) and the caster's name would then be a parameter, but the %%1 and "anti_"%1 are actually making the alarm correctly, believe it or not. There may be some unwanted side effect in memory that's causing the window to be disabled, though, so I'll play with it again based on these suggestions.

Posted: Sun Dec 16, 2007 2:49 pm

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Yeah, but I wrote these scripts back when the ($localvar:wildcard) stuff was broken. Smile

I tried the $var syntax, though, and it didn't make any difference. I also tried creating a brand new package and loading my settings from XML, with the assumption that the database somehow got corrupted in my testing or loading of command-line scripts and the XML format is cleaner, but that didn't change this behavior. I still see nothing in the script debugger window that points to any sort of problem. I have no triggers that execute a generic #T- Lusternia, of course, so I'm at a loss.

My workaround for this is simply to hardcode the class folders for my dynamically created settings and to just keep things out of the window class scope. Disabling the active session window seems to have no other adverse side effects, such as the window disappearing...

Posted: Sun Dec 16, 2007 4:31 pm

I thought some of the reason for local variables was to avoid/remove the need for %% delayed expansion. I guess the code still exists to deal with %% but I would agree with Fang here the correct method now is to use local variables.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I only used the %%1 because I was making an alarm and not an alias. The example given for not using %%1 shows how to make an alias within an alias. Alarms don't accept parameters that same way, so I stuck with the %%1. At any rate, it's not what's causing my troubles with the disabling window because it still happens even now that the %%1 is gone.