Zugg Software :: View topic - Poll about how Published Modules should work

Posted: Wed Nov 22, 2006 8:10 pm

Right now, when a Module is Published, that means that other Modules and Windows in *different* packages can see the settings in the published module.

Also, when a Module is Published, other Modules and Windows in the *same* package can NOT see the settings in the published module.

Is this counter-intuitive? Should a Published Module be visible regardless of which package you are in?

Magician Joined: 13 Oct 2000 Posts: 463

Can you explain how visibility works right now? I've run into some confusion already with this, and I haven't even gotten to deciding to publish anything.

Posted: Wed Nov 22, 2006 9:29 pm

I just did. Read the first two lines of the post. It describes how module visibility currently works.

Magician Joined: 13 Oct 2000 Posts: 463

It explained how published module visibility works... what about unpublished modules? Does a module BECOME invisible to other settings in the local package when it is published, or does it REMAIN invisible to other settings in the local package? Is there a way to make it global within a package (or make it not global if it defaults that way, without publishing it)?

Posted: Wed Nov 22, 2006 9:57 pm

Currently, unpublished modules are only visible within the same package. And yes, right now it's only visible within the same package when it is *not* published. In other words:

1) Published: visible to other packages, but not by the current package
2) Not-Published: visible only by the current package (not by other packages).

So, case (2) makes it Global within the current package without making it visible outside. And this would not change. My proposed change is:

1) Published: visible to all packages (including current package)
2) Not-Published: visible only by the current package

Also, for completeness, I should mention that Windows work like the current unpublished modules. Settings within Windows are never seen by anyone outside of the window, no matter what package you are in. And this wouldn't change.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Yes.

I had been trying to write some lengthy explanation of what I want, but it just seems overly complicated and unnecessary. Everything within a package should be able to access everything else in that package. Otherwise it would have been put into another package.

Apprentice Joined: 12 Mar 2005 Posts: 195

Yeah, i agree with vijilante

Posted: Thu Nov 23, 2006 1:22 am

Ditto.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Yeah, it's pretty crazy the way it is now. Why would I want to hide something from myself? *mimes looking for his left arm*

Posted: Thu Nov 23, 2006 1:45 am

Yeah, that's pretty much what I thought. Not sure why I designed it this way to begin with, but I figured that if even I wasted time today trying to figure this out that other people were probably having the same problem Razz

It's "fixed" for 1.16 now!

Posted: Thu Nov 23, 2006 2:30 pm

I'd just like to verify that if you have two variables with the same name, one in one package and one in another, that scripts from one package will always refer to the variable in their own package first before those in another in this new system. For example (all modules being published for the sake of simplicity):

In Package1, an alias in the module P1M1 that refers to a variable test. There is no variable test in Module P1M1.
Also in Package1, a variable in module P1M2 called test.

In Package2, a variable in module P2M1 called test.

Would //P1M2/test be referred to before //P2M1/test, or would it have to specified explicitly each time?

Magician Joined: 29 Nov 2005 Posts: 482

Well thanks for that explination :) seems to help me understand why my non published settings under a published parent werent being seen

I definatly agree with

1) Published: visible to all packages (including current package)
2) Not-Published: visible only by the current package

Wizard Joined: 14 Aug 2004 Posts: 1269

Good, I definately agree with the change. The previous behaviour does seem counter-intuitive.

Posted: Fri Nov 24, 2006 6:31 pm

Fang: Yes, CMUD should always look in the current package before looking elsewhere, but if you find a case where this doesn't happen, let me know.

Novice Joined: 14 May 2001 Posts: 33 Location: USA

I found a slight issue with the new package visibility in 1.16.

The problem is that if you have capture triggers and windows inside a package that work off the main window it create a loop if publish is set to on as the triggers fires on the main window and the text captured to the chat window as well.

The only work around I found was to move the chat windows into the main package and enable it only for the main window. This works but it pretty much defeats the purpose of putting the chat windows and settings inside a separate package.

Posted: Sat Nov 25, 2006 7:30 am

Hmm, maybe that is why I did this in the first place. You raise a good point, but since the old way was still confusing, it seems like we need to think of a better way to accomplish this. You should certainly be able to create a "chat package" that works with any session. Maybe instead of overloading the "published" option I need some sort of other option.

What I need is a way to handle this that isn't confusing for normal users.

Posted: Sat Nov 25, 2006 7:37 am

If your chat window is in another package (as it seems to be in this example) can't you just uncheck the main package in the chat package's enabled list to prevent the triggers from being visible to it? Would capturing to it still work?

Posted: Sat Nov 25, 2006 7:53 am

No, he means that he created a standalone "chat package". This package has a chat window, along with a module that contains the capture triggers. His problem is that the capture triggers are fired by both the main window and the chat window. He needs to hide his published chat module (where the capture triggers for the main window are) from the chat window itself.

This is one of the package cases that we actually discussed a while back, and I had forgotten about it. But it was exactly this kind of example that led me to make published modules not visible within their own package.

Posted: Sat Nov 25, 2006 8:39 am

Why not just have another option to control visibility to modules within the same package that's on by default? As long as they're labelled clearly it shouldn't be confusing.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Just to make it totally clear for those that missed the original discussion:

In that stand alone chat package, the triggers that should only fire within the chat window should be created as child settings of the window setting. Those triggers that should fire in the main session window would be in the published module. We want variables and other settings in that published module to be accessible throughout the package. We also want to be able to have other triggers fire on the same text as the evil #CAPTURE trigger. For example we may want to capture the line from the main window, then add a time stamp in the child window, and have other triggers recolor things in the main window.

Personally I think we have an option that handles this already, trigger on trigger. This option is nicely abbreviated NoTrig for a reason, it says that other triggers should not fire on the output of this trigger. That is almost exactly what we need, #CAPTURE is functionally an output. There are 3 changes that would have to be made.

1. The option should default to on for new triggers(meaning the checkbox next to Trigger on Trigger should be unchecked). This prevents a large number of trigger loops in the first place.

2. The description of this option displayed on mouse over needs to be fixed. So that it really says what it does.

3. The option would only affect triggers that are children of the same module or window. This is the major change. In zMud a capture trigger only had 1 chance to fire because it never saw the text arrive in the other window. The package system is trying to open the door for people to write more general groups of scripts and for them to be readily importable. We want triggers unknown to that particular module to be able to react that output, while telling sibling triggers that they may have no interaction with that output.

Posted: Sat Nov 25, 2006 5:18 pm

So what you're suggesting is that the NoTrig option be used to prevent the output of the capture trigger setting off that trigger again (or, indeed, any other trigger) in the chat window? Doesn't that stop you doing things like adding timestamps to the captured text by having triggers in the chat window?

Posted: Sat Nov 25, 2006 6:47 pm

I don't think I want to mess with the Trigger on Trigger option. I certainly don't want to turn this off by default. This option is left over from zMUD and can have some bad side effect. Essentially what it does is to control the global "Triggers enabled" flag. When the Trigger on Trigger is off, the global trigger flag is turned off while the trigger is running. Depending upon what your trigger does (like if it uses the dreaded #wait command), any text from the MUD that is received while the trigger is running will not have any triggers processed.

So, when Trigger on Trigger is turned off, you run into possible situations where your other triggers might not fire. In CMUD, this situation is better than in zMUD because of how loops are handled, and because CMUD scripts run faster. But it's not a situation that I really want to make the default.

Also, using the Trigger on Trigger option only helps with triggers. It really doesn't address the fundamental issue of module visibility. I'd much rather handle this on a Module level, and not on a trigger level. It's a change of one line of code to add an option for "Publish to external packages but not the current package". It would be a lot more complicated to mess with the current trigger system.

I think I prefer Fang's suggestion of just having a second option for modules:

Posted: Sat Nov 25, 2006 7:40 pm

Can scripts in the current module still see settings in the same module under option 1? I thought the old published setting was "visible to external modules and the module it's in, but not to other modules in the same package". If this is the case, then option 1 does have some (albeit limited) uses.
Also, isn't option 3 the current default?

If you really do need all four options, why not just have two checkboxes? One labelled "Module is visible to other packages." (defaulting to off) and another labelled "Module is visible to other modules in the same package." (defaulting to on).

If you really do need only options 2-4, I suppose you could use a dropdown box with the options you have listed there (Module is visible to: Everyone/Current Package only/Other packages only) with current being the default (perhaps it should be "parent" rather than "current?"). You can use the hover-over text in the status line at the bottom of the settings editor for more explanation - perhaps including that the settings in the module are always visible to other settings in that module, if that's the case. You could even use this option with "Nobody" on this list and have it work that way instead.

Posted: Sat Nov 25, 2006 10:30 pm

Fang: Yes...a module will always see settings within itself. It's just the modules outside of the current module that we are talking about.

The old Published setting was option (4).

Since I can't see a need for option (1), I'm leaning towards radio buttons. Dropdown boxes cannot have different hints for the different items within the box. Hints could be done if I use a Radio button with three options.

Posted: Sat Nov 25, 2006 10:54 pm

Well, it could be useful to have option 1 if that chat package we were talking about earlier contained two different windows that both received capture input. It might be useful then to make triggers they contain visible only to that window rather than every window in that package.