Zugg Software :: View topic - [303aB] [237] Ghost response from macro key

Posted: Wed Jan 21, 2009 3:56 am

I once had KEY5 assigned to the LOOK MUD command. A while back, the GLANCE command was added to the MUD. This command does what LOOK does but omits the room description. I reassigned the KEY5 macro key to use GLANCE instead of LOOK.
However, many times when I press this key, a LOOK command is output to the MUD rather than a GLANCE. This will continue to happen until I open the Settings Editor. Once I do this, the macro key begins to output the currently assigned command.
The reason I call it "ghost response" is that the incorrect output is sent to the MUD exactly how I originally typed it for the KEY5 setting. So it is "remembering" what the key used to have. I have tried deleting the macro assignment and reassigning the key, but the problem persists. This will occur at least once a session. I also have ALT-KEY assigned. It happens to be assigned to LOOK. However, I can tell that this value is not the one being output because the definition is in all caps, while the output to the MUD (the "ghost" one) is in lower-case which is how it was defined for KEY5.

Posted: Wed Jan 21, 2009 5:17 am

Did you try doing a #KEY to see if you have the macro define more than once. I'm guessing that this is the case, but that it's assigned to a particular scope, so that only when you enter this scope (through whatever means) you see the old version of the macro. You could also try doing an export all of your settings to check as well.

Posted: Wed Jan 21, 2009 8:30 am

#KEY shows only one definition for KEY5 which is glance. As it turns out, ALT-KEY5 is no longer defined so what I said about that key in my original post can be ignored. Also, remember I said that this has happened even when I deleted the definition for the key, which gives strength to my idea of the "ghost" macro key. I've searched my settings for the string "LOOK" and it doesn't appear anywhere. However this package once contained such string in the previous definition of KEY5. My guess is that there is more that one internal pointer to the macro key definitions and that they are out of synch. Once in a while, the bad pointer is accessed by some seldom-used routine and the problem surfaces. It is interesting to note that I imported my macro definitions from zMUD. KEY5 is the only one that I have changed since I first defined them long ago (I added and then deleted the macro definition for ALT-KEY5, additionally). KEY5 is the only key that exhibits this problem.

Magician Joined: 17 Apr 2005 Posts: 496

It could have gotten into one of the default packages, maybe. Make sure you have view>default packages and view>hidden classes enabled?

Posted: Mon Jul 20, 2009 10:40 pm

I am refreshing this post because I think I found something relevant to the problem. I noticed that when focus is on a secondary window and I press a Macro key, the value of the key is echoed to the secondary window. However, what is echoed is not the actual value of the key but its default value. This leads me to believe that the "ghost" behavior occurs because CMUD somehow "forgets" that there are explicit definitions for the keys and reverts to default values. This problem continues in 309B.

Posted: Tue Jul 21, 2009 4:37 pm

When you have a different window focused and press a macro key, CMUD looks for the macro that is defined and visible from that window. Settings within a Windows are *private* to that window. So if your "glance" macro is defined in your main window, then it won't be seen from the secondary window. You need to put the macro into a global module that both windows have access to for it to work.

This is not a bug. This is how CMUD is designed to work. There is no real concept of "secondary windows" in CMUD. Each window can be it's own session window. And you don't want scripts/macros/triggers/etc from one window to be active in another window normally. And if you do, that's what the global modules are for.

Posted: Tue Jul 21, 2009 11:03 pm

I used the information I got from the echo to the secondary window to infer what the problem with the main window is. I don't have a "LOOK" macro key defined, however, at times that is exactly what CMUD sends to the MUD when I press KEY5. It sends "look" instead of "glance", even though this is the definition. What I observed was that "look" was being echoed to the secondary window (which doesn't have any macro keys defined) when I pressed KEY5. I also remembered that "look" is the default setting for KEY5, which is why it was being echoed to the secondary window.
The point is that since there is a definition for KEY5 in the main window, "look" should never be sent. However, this happens. The only way to stop this when it starts happening is by cutting the class folder containing the MACRO definitions and re-pasting them. This has the effect of re-defining the MACRO keys, so they begin to function correctly again until the next time it "forgets".
Somewhere along the line CMUD misplaces the MACRO definitions and reverts to default values. I am not sure that this applies to all the definitions but it certainly applies to KEY5.
Moreover, in the Map property definitions, I replaced "look" with "glance" also. When KEY5 begins to malfunction so does the Map action that reloads the room info. It also sends "LOOK" instead of "glance".
Nowhere in my package file the word "look" appears in any way, for any reason.

Posted: Wed Jul 22, 2009 2:43 am

The "look" key for KEY5 is defined in the "English Keypad" package, which is enabled by default for all windows. The secondary window doesn't see the KEY5 definition for the main window (it's private), so it only sees the global English Keypad package. That is why "look" is being sent.

However, this should not have any relation to the mapper "look" command getting replaced with glance. The mapper look command is a separate setting within the Mapper Properties window and is not related at all to any macro settings, or the KEY5 setting or anything like that. I have no idea how it got changed to "glance" on your system.

Posted: Wed Jul 22, 2009 3:02 am

Yes, I understand about the default values, that is what gave me the idea that the bug lies in that direction. To summarize: I changed KEY5 to "glance", I also changed the map look command to emit a "glance" command. However, for some unknown reason, at some point during the session, when I press KEY5, or invoke the look command from the mapper action menu, "glance" (the defined command) doesn't get sent to the mud, "look" gets sent. That is, for some reason, CMUD fails to see the defined values and is sending the default values. The only way I've found to solve this problem is by cut/pasting the folder with the macro definitions. This effectively re-defines the macro keys. This incidentally restores the value that is sent from the mapper action menu (Yes, I know they are not related). The source of the "look" command is the issue here, it shouldn't be sent to the mud because I have explicit definitions for both KEY5 and the map look (room reload) command. Since, as you pointed out, "look" is defined in the English package, what seems to be happening is that CMUD loses track of the explicitly defined commands and is sending the default commands. My reference to what is happening to the secundary windows was just to point out to what I noticed and what gave me the idea to what the bug is. I would expect the default values to be sent to those windows since I don't have explicit definitions for them.
The fact that to unrelated commands (KEY5 macro key) and mapper room reload are sending "phantom" commands clearly point to a bug or bugs that must have a common source. The word "look" does not appear anywhere in my package file, so "look" must becoming from some default location, ignoring my explicit declarations.