Zugg Software :: View topic - Is there a way to make a module the default setting location

Wanderer Joined: 09 Nov 2006 Posts: 55

I mean when adding new settings from the command line, or even from the editor, when clicking new alias, they default to the main package. I want them to default add to the module.

Is it just like a class where when I log in, I should type #class <myModule> or something?

and will that make it so the settings window (docked one) on the right side will show the settings in the module?

Posted: Mon Nov 20, 2006 3:17 pm

The #module command should do this.

The fly-out settings window will always show the settings of the currently selected window. It won't display any other modules. You have to use the main settings editor to edit other modules.

Wanderer Joined: 09 Nov 2006 Posts: 55

I'v actually tried that and nothing changed, syntax #module moduleX right? still sends settings to the main pkg. no worries. I'm getting used to it/ makes me organize when I move them. :)
one annoying thing however. In the package editor, if I click the tab with a particular module, click a class, and click new (alias/trigger/whatever), ONCE in a while it creates a new setting where I selected. MOST of the time it creates it in the main pkg instead of where I selected it to go!
(which is hard because I'm looking at the module tab and I cant even edit the new alias i just created until i click the main pkg tab to point to it.)

Posted: Mon Nov 20, 2006 10:32 pm

Well, the #module command is only supposed to be working from the command line...it doesn't help with the settings editor. I'll see if I can reproduce these problems. The settings editor problems sound serious.

Have your done a fresh install of 1.15 or have you been upgrading all along in the same directory? From the memory corruption bugs in 1.13 it's possible your package files are messed up.

Also, remember that the "tabs" in the setting editor are for different package files. So are you saying that you are dragging to a new package tab, or did you right-click on a module and manually add it to it's own tab?

Wanderer Joined: 09 Nov 2006 Posts: 55

it is a fresh 1.15. Each upgrade and crash/reinstall, I erase the directory and start again.

I'm saying that with a couple packages loaded in a session, 1 converted to a module so 2 windows dont open at connect and they share the settings/preferences, when I have the module tab clicked and sort out a class and where I want to make a new setting, I click the NEW button above and the new setting is created in the first package tab, not the module where I wanted it. (most the time. sometimes it is created where I wanted but click new again and its back to the front.

Posted: Tue Nov 21, 2006 11:36 pm

Well, either it's already fixed or it's something wierd with your packages. Here is what I did with a fresh install:

1) Press ESC to remove session screen, and then click Settings to open settings editor
2) Select File/New Package. Enter "test" for the package name
3) Click back on the "untitled" tab.
4) Select New/Alias. Alias is created in untitled package.
5) Click on "test" tab
6) Select New/Alias. Alias is created in test package.

So this basic test seems to work fine for me here. If this simple test doesn't work in your 1.15 version, then the bug is probably already fixed in 1.16. If this test works, but you still have trouble with your packages, then there is something wierd in your packages or in your setup and you'll need to try and come up with a way to tell me the steps that you used to create your packages so that I can try to reproduce it here.

Posted: Wed Nov 22, 2006 8:48 pm

Btw, a clarification of the #MODULE command:

Remember that when you are typing stuff into the command line, you are typing commands for that selected Window (remember a Window is a type of a module). So the command line is always going to use the window attached to the command line as the module for commands.

So if you just type:

#MODULE test

and then type

#ALIAS myalias {whatever}

then this alias will still be created within the Window that the command line is attached to and NOT the "test" module that was given in the previous statement. If you want to create an alias in a different module from the command line of a different window, then you need to put it all on one command line:

#MODULE test;#ALIAS my alias {this is created in the test module}

So keep in mind that while #MODULE works as expected within scripts (and doesn't need to be on the same line), that it's different when typing it into the command line of a particular window.

Magician Joined: 13 Oct 2000 Posts: 463

A multi-line command line would also work as described, right? For example:

#MODULE test <shift+enter>
#ALIAS my alias {this is created in the test module}

This does not seem very intuitive by the way. The #CLASS command is persistent (or at least, it was last I checked, which isn't recently). I would expect #MODULE to be persistent as well, and turned off with #MODULE 0 just like #CLASS 0.

Is there a reason for it being different? Could they be made to operate the same way?

Posted: Wed Nov 22, 2006 9:32 pm

Yes, using the shift+enter should be the same as using the ; seperator.

The reason for it being different than #CLASS is that a window *is* module, and when you click on a command line, you are selecting that window and making it the current module. There is no way to make it operate the same way. You should be using #MODULE in your scripts and not from the command line. Or, open the Editor (Shift-Ctrl-Enter) and enter your scripts from there. The command line is optimized for interacting with the MUD...the Package Editor is optimized for making scripts.

And this *is* intuitive because most users have no idea about Modules (nor do they care), but they would expect when they have multiple windows with command lines that each command line will create settings for *that* window. People who understand how modules work can easily either use the settings editor, or just put things on the same line.

Magician Joined: 13 Oct 2000 Posts: 463

I'd make a case that #CLASS should work that way too... I actually wasn't really arguing that #MODULE should be persistent... but that #CLASS should not be (sorry, I re-read it and realized it didn't sound like that at all). I've had more bugs in scripts due to forgetting #CLASS 0 than I can count. I would prefer it if #CLASS was transient, just like #MODULE.

Posted: Wed Nov 22, 2006 9:54 pm

Unfortunately, I can't change #CLASS because it would break tons of scripts. And actually, it does make sense. Each module/window has a "current class", which is selected by the #CLASS command. Since a window *is* a module, there is no concept of a current module within a window.

In any case, your comment about forgetting to do #CLASS 0 is exactly why the module doesn't reset. Putting something in the wrong class is bad enough, but it would be really bad to forget to do #MODULE 0 and have settings going to wrong modules, possibly in other packages, getting saved to other pkg files. That would be a nightmare.

But sorry, #CLASS is not changing because of compatibility issues.