Zugg Software :: View topic - CMUD 225

Posted: Sat May 10, 2008 4:58 pm

Normally, when the editor recognizes an alias, or other item that has been previously defined, in the text of a script, it colors it blue. However, the new editor is not recognizing defined items that are located in the root (that is, hanging from the main session window). It has no problems recognizing items that reside in modules. There is a variation with defined variables in the root: They show up in red in the scripts (which normally means they are not defined), again, no problem recognizing variables defined in modules. This does not affect script execution, just makes debugging a bit harder. The problem with not recognizing variables was intermittent with the 2.18 editor, it is persistent in this edition.
EDIT: Root includes any classes and sub-classes attached to the main session window.

Magician Joined: 17 Apr 2005 Posts: 496

OK, so I guess the obvious question is: are the scripts you're trying to use these things from in the same package? (I'm guessing they are since you say the scripts work, if they're not then the bug is that your scripts work at all, rather than with the highlighting.)

Posted: Sat May 10, 2008 6:19 pm

I have only one package.

Posted: Tue May 13, 2008 5:00 pm

Can we get XML snapshot of your settings to try and reproduce this. With out, or more specific steps in recreating the problem there's not much we'll be able to do.

Does this happen in a blank session for you? Does it only happen with one chararacter, or a particular set of aliases?

Posted: Wed May 14, 2008 12:27 am

The problem is general. The fact that it colors the settings in a script red when they are not in the same module is just an aspect of the problem. All you have to do is delete the alias you are viewing and you will notice that all the color on the settings will disappear until you do something that will make the Editor reload its data.
Besides, the unrecognized declared settings problem does not occur 100% of the time, but about 90%. All I can tell you at this point is, that it only occurs with settings not in the same module. I thought that it only applied to settings hanging from the root, but the general problem is recognition across modules (and perhaps packages, but as I said, I only have one so I can't testify to that).

EDIT: Another thing, and this may be a design decision by Zugg, paired parentheses and brackets are no longer in yellow or marked in red when unpaired.

EDIT: An update on the coloring of matching parentheses and brackets. It appears that the coloring of these items only take place while one is writing the script. Once it is saved clickling on a parenthesis or bracket will not color it. It would under CMUD 2.18.

EDIT: I've also traced a problem in the way the #IF trees are generated. It seems that the closing bracket is not included in the tree and this is causing the coloring to come out wrong. The ELSE portion of a complex statement comes out in black (indicating that a bracket is missing). This does not prevent the #IF statement from being correct, it just appears to be so.

Posted: Wed May 21, 2008 11:35 pm

Another odd behavior by the Editor is that it will randomly show the English Directions and English Keypad as modules hanging from the root window. They will disappear from the tree while one browses them.

Posted: Thu May 22, 2008 1:21 am

An extreme example of this:
I try to enter a command and the path recording box pops up while the command parsing icon gets crossed out. No matter what I do, I can't get the box to stay off. I can close it, I can click "cancel recording", but after that anything I enter on the command line will cause the box to re-appear. Hitting [b]esc/[b] does nothing. (All this while trying to get the hell out of an aggro room that's eating me alive. Result: death)
During this episode the command line won't accept any characters.
Problem resolution: reload CMUD.

Posted: Wed May 28, 2008 7:22 pm

First, please create NEW POSTS for each different error/problem that you are reporting. Otherwise it is very difficult for me to track different problems on my bug list and it reduces the chance that I can fix the bug and makes it harder for other people on this forum to help you with your problems.

On the original problem, I did this simple test in a blank session:

Posted: Thu May 29, 2008 12:08 am

Yes, the alias name will be colored properly. The problem of the coloring happens during editing, opening a saved script will have the correct coloring, mostly. Variables that are outside the class will, for the most part, show up in red (not defined), but not always, just most of the time. This problem also occurred in previous CMUD versions, but cut/pasting the variable would solve the problem. That doesn't work for this CMUD version, if the variable shows up in red, it will remain so, no matter what one does. Also, if one deletes a setting, then all other settings one views will show up in black only unless one either selects a settings type other than the one currently active or selects another class and views a setting in that class. Since deleting a settings causes the editor to bring a new setting to the display, the all-black problem shows up immediately. As to the English Directions and English Keypad settings, it is not a matter of me clicking on the All-View, that is my default setting, and if this showed the folders all the time, it wouldn't worry me. What I am saying is that they randomly pop-up into the view tree and when I click on either one of them, they disappear. What should happen is that they folders should be opened just as any other folder would.

Posted: Thu May 29, 2008 3:32 am

I created a variable outside the class and it showed up in blue as expected. Make sure your class containing the variable is not getting disabled somehow. This version fixed a bug in previous versions that was caching the red/blue of variables incorrectly. If a variable is red in this version, then it means it isn't visible to the currently edited setting for whatever reason (class disabled, variable disabled, etc). My guess is that there is something weird in your settings, so you'll need to try and reproduce it in a blank session if it's really a bug.

I've never seen the English Directions/Keypad show up like that, so I'll need to know what you were doing when it happened. It might also be an indication of a problem in your settings, but I just can't see how it would just randomly show those.

Posted: Thu May 29, 2008 3:44 am

Adept Joined: 27 May 2008 Posts: 299

Its got to be either Package>Window>Class>settings
or Package>Module>Class>Settings

But unless your package is corrupt you should have no settings that aren't under a window or a module.

Posted: Thu May 29, 2008 4:29 am

Normally I would agree with the reasoning that the variable or class etc., was disabled. However, since the scripts run, then the variables must be accessible. Proof of this is that one of the most common red-flagged variables are the references to COM objects, but the scripts that use them run properly.

Posted: Thu May 29, 2008 4:34 pm

Posted: Thu May 29, 2008 4:58 pm

Adept Joined: 27 May 2008 Posts: 299

In this case, we cant really see what your package name is... Your module name is however Concoctions, and the things under it are of course your classes.

Posted: Thu May 29, 2008 5:46 pm

Mmm, the layout there is Package (the whole tab) -> Module ("Concoctions") -> Classes, abc and "bowing deeply" trigger. The module/window is the vital step.

Posted: Thu May 29, 2008 6:08 pm

Yep, so you are fine...your classes are within a module. And sorry I got confused between Caled's reply and Anaristos. I thought it was Anaristos who was having classes or settings in the root level.

So, back to the original post...can anyone else reproduce a variable outside the class being red instead of blue. Or, I'm still waiting for a more detailed procedure from Anaristos on how to reproduce this.

Posted: Thu May 29, 2008 11:08 pm

Here is something interesting that I have just found. Looking for instances of red-flagged variables yielded the following:

Declared variables across modules are colored blue as they should be, unless the module containing the referring script has a window attached to it. If this is the case then trans-module variables will be colored red even if already declared. So it seems that a window within the module disturbs the editor.
As I pointed out before, the fact that the editor does not recognize the variable(s) does not affect the script.

NOTE: In my posts above and elsewhere, when I refer to the root class, I am referring to the window/module that has the same name as the package.

EDIT: Just a reminder that to see the loss of color effect in the Editor all one has to do is delete a setting. This will cause the Editor to load another setting into the display window. The setting will be displayed in black only. This condition will persist until one either chooses a different filter and setting or chooses a setting in another window/module. Also, while this problem affects mostly variables, it can and does affect other settings from time to time.

Posted: Fri May 30, 2008 2:00 am

Posted: Fri May 30, 2008 2:05 am

I think that somehow we have ended with two distinct threads here...

Posted: Fri May 30, 2008 3:04 am

If you look closely you'll notice that while the thread did indeed diverge - it has already converged.

Posted: Fri May 30, 2008 3:15 am

OK folks, we need some serious work here to get everyone talking the same language. CMUD can be very complicated, but it gets much worse if you don't use the correct terminology.

Package: This is just the *.PKG file. It contains Modules and Windows.
Module: Contains classes and other settings. Can be global, external, or local. Does not have any associated visual component.
Windows: Like a Module, but has an associated visual "window" component.

When you create a new package, a Module with the same name as the package is created automatically. In the Tree View, a Tab normally represents an entire package file, showing the contents of that file. The file can have multiple modules/windows at the top level. However, do not associate a "tab" in the editor directly with a package file since you can also customize tabs yourself to only show a particular class or module within a package. So just remember that a Package is a single file on the disk.

The "All" tab shows all settings no matter what file they are in. So it will show all of the modules/windows, with all of the various class folders and settings within. In the "All" view, it can be difficult to determine which module/window is stored in which package file.

OK, so now let me address something Anaristos said to get back to the main problem report of this thread:

Posted: Fri May 30, 2008 4:19 am

I apologize for the terminology. No, the window is not attached to the module but scripts in a module which has a window following it (alphabetcially in my case) will experience the coloring problem (as long as the referred setting is outside the module), while a module that has no window following it directly, will not have scripts having this problem.

Posted: Fri May 30, 2008 5:32 am