Zugg Software :: View topic - #T+/- not working in secondary package

Posted: Tue Dec 09, 2008 2:47 am

I moved some scripts (with all their components) to a new package. I was expecting to be able to remove them from the main package if they worked properly. These scripts work with triggers that are enabled/disabled from those scripts. If tested this scripts to make sure they ran from a secondary package and found that I cannot enable, change the state or disable triggers. The commands are simply ignored. To test this, I enabled the triggers manually, and the script ran. The scripts have been running since 2.34. Other scripts in the new package that don't use triggers, seem to be running fine.
I tried using the class\triggerid method, but this didn't change the outcome. I renamed the triggers and that didn't change anything either.

Posted: Tue Dec 09, 2008 11:41 am

Check that the script that's issuing the #t+ command can see the setting you're trying to change. A common cause of this is either of them not being in a global module.

Posted: Wed Dec 10, 2008 1:21 am

All the pertinent settings are in the same package, there is no module involved. In fact, they are all in the same class. When I run it from the main package, it works fine. T+/- has no effect from script in the secondary package.

Posted: Wed Dec 10, 2008 2:10 am

Posted: Wed Dec 10, 2008 4:06 am

Posted: Wed Dec 10, 2008 11:15 am

Give us the XML for the module or whatever you have in this second package.

Posted: Thu Dec 11, 2008 2:01 am

Very well, here is the entire class settings:

Posted: Thu Dec 11, 2008 5:31 am

Out of the XML, the module tag was probably the most important. Just select the module and rclick-copy.

And the triggers you're trying to en/disable are the synctrigxx triggers, and they're in a separate package? Are they in a window, module, etc?

The reason I'm asking for this is because I'm trying to get my setup as similar as possible as yours to see if I can get it to fail. That takes as much info as you can give me.

Posted: Thu Dec 11, 2008 10:18 am

I'll do that, but first let me say I think I know what the problem is. I've found that if I am in a room with a map script (i.e. There is a Class folder RoomXXXXX), The variables in the above scripts, and the TEMP trigger get created in that class folder. As we know from long ago, this has been a problem with CMUD. The duplication of variables outside the class containing the executing a script. That is why the above scripts are "failing". The TEMP trigger, of course, ceases to be temporary, adding to the problem. See my posts here and here concerning these problems.

EDIT: Deleting the class folder (RoomXXXXX) where the items are being duplicated, allows the scripts to run successfully.

Posted: Fri Dec 12, 2008 7:25 pm

The issue with #TEMP triggers becoming "permanent" is fixed for the next version.

Posted: Sat Dec 13, 2008 12:31 am

I understand what you are saying, Zugg, and I think that under the circumstances you describe it works as it should (though, some of my room scripts won't execute, but that will be another post). My problem is different in this respect: When I walk into a room that has a RoomXXXX class folder defined, the class becomes enabled so that any scripts for that room may be executed. However, I am not executing a room script, I am executing an unrelated script and, because the class folder for the room is enabled, the variables get duplicated there. I am saying that there is a scoping problem when a room class folder is active. This problem is similar to those others discussed elsewhere, albeit for different reasons. This also would explain why #T+/- and #STATE do "nothing" (i.e. The triggers are not in the room class folder so they are not being found).

Posted: Sat Dec 13, 2008 3:11 am

Right, but that is what I cannot reproduce. When I am in a room that has the RoomXXX class enabled and one of my normal triggers runs, it runs as normal and creates the variables within the normal session window like it should. The RoomXXX classes are not set as the "current" classes...they are just enabled so that the scripts within them can be seen. But the context for triggers that execute is still set to the normal window itself. So that's why I mean when I say that I cannot reproduce your problem. You'll need to try and reduce it down to a simple package or module that can show the problem happen. It's got to be related to your specific window, package, and module setup, and might be related to the specific scripts in your RoomXXX class. Especially if some of your room scripts don't execute.

Posted: Tue Jan 06, 2009 7:00 pm

I have looked at this (persistent) problem further and have come to the conclusion that the behavior I described on the initial post is either collateral or additional to the problem of ignored triggers.
I think I have identified the source of the problem. I have a copy of a script class in both the main package and a secondary package. While the contents of the aliases and triggers vary, the names remain. Specifically, the trigger IDs are the same.
This is what happens:
In order to have the secondary script suite execute, I disable the class folder in the main package. However, when the secondary package scripts issue enables for their triggers, I find that the main package analogs are enabled and fire when the server data is presented. The triggers in the secondary (executing) package remain disabled. This happens even if the main package triggers are explicitly disabled within the disabled class. Proof of this is that if I change the main package trigger IDs, the secondary package suite executes properly.
The reverse is also true. That is, if I want to execute the script class in the main package, I must insure that the secondary package triggers have a different ID even when the container class and the triggers within, are disabled.

Perhaps, this works this way by design. However, I find it suspect that the execution module is "seeing" disabled components. They should be invisible whatever their IDs or labels might be.

Posted: Tue Jan 06, 2009 8:01 pm

This is because triggers execute within the context of the window that the text is received. If multiple classes or triggers have the same ID name, then when CMUD looks to decide which to enable or disable, it starts looking first within the current context. That is why the main window triggers are getting enabled first, because it looks first in the current context before looking in other packages.

So I don't think it is "seeing disabled components" or else maybe I'm not understanding what you are saying. Obviously the #T+ command needs to "look at disabled components" to decide which components to enable.

Posted: Tue Jan 06, 2009 8:22 pm

The nature of the scripts require that the triggers be disabled until they are needed. So when the scripts are ready for the data fetched by the triggers, they enable them. What is happening is that when the script runs from the secondary package, it will enable the main package triggers within the disabled main package class, not the disabled triggers within the enabled class in the secondary package, as long as the ID for the triggers are the same in both classes. What's more, the triggers within the disabled class are firing.

Posted: Tue Jan 06, 2009 9:38 pm

It's impossible for a trigger to fire if it is in a disabled class. So something else must be happening there.

As far as the triggers in the main package getting enabled, I think I already just said that it is correct. If you enable your trigger ID within another trigger, then the trigger ID in your main package class will be enabled because that is where CMUD looks first.

What is the reason for the triggers in the package and in the main window to have the same trigger ID? It really seems like that is the root of your problem and I cannot think of any good reason why you'd have multiple triggers with the same ID like this. It's just asking for confusion and problems.

Posted: Tue Jan 06, 2009 11:36 pm

The class suite in the secondary package was originally a copy of the class in the main package. I made some modifications to the scripts and was running them to insure their correctness. Also, the scripts in the main package work with the old map while the secondary scripts work with the new map. So they are a fallback in case of problems.
What I am trying to understand is why trigger IDs are being searched within disabled classes. That is not the case for aliases, as my current setup proves. Both the disabled and enabled classes have the same alias names within them. The scripts are enabling the triggers in the main package (disabled) class. However, when they fire they invoke the aliases in the secondary package (enabled) class. Which is what I would expect to happen. I don't see why the aliases (and variables) are invisible when within a disabled class but trigger IDs are not. Disabled classes should not be part of the execution context, with the exception of #T+/- using the class name as target.. Additionally, when the map is positioned over a room with a defined script class (which becomes enabled at this time) the original posted problem of variable duplication (within the room script class) takes place. It seems that when the triggers in the disabled class fire (and they do fire, which is the reason that I discovered the problem) and the map room script class is enabled, CMUD duplicates the variables in the room class folder rather than going through the process of fetching them from the secondary package. It is my experience that there has been a variable duplication problem as far back as ZMUD 7.21. I do think that the variable duplication is collateral, though. If the disabled class triggers didn't fire, the duplication might not occur.

Posted: Thu Jan 29, 2009 4:16 am

OK, I will bump this because I think this is a fundamental bug (or design philosophy) in CMUD. I have disabled triggers in a disabled class. If I have triggers in an enabled class with the same ID, the triggers in the disabled class will become enabled/disabled when #T+/- is used. I can understand the argument that triggers should have unique IDs. However, the whole point of disabling a class, IMO, is to make its contents invisible to the script executor. Aliases, Variables and Functions within disabled classes are ignored, why not Triggers? In fact, enabled triggers within a disabled class won't fire so the problem is not the triggers or whether they have unique ids or not. The problem is that #T+/- is ignoring the fact that the class is disabled.

EDIT: Tests show that even though #T+ is enabling the trigger, it won't fire. Which confirms, IMO, that the problem is with #T+/-.

Posted: Thu Jan 29, 2009 6:15 pm

Bringing this up again isn't going to change it. While you may disagree with the behavior, this is how both CMUD and zMUD have been for years, and it isn't going to get changed because it would break existing scripts too much. You have *always* been able to enable/disable specific trigger within a disabled class. That is just how the #T+/- command has always worked.

As an example, people often have scripts that use #T+/- to enable/disable specific triggers. When they want to prevent those triggers from running entirely, or for debugging purposes, they can disable the class containing them. The #T+/- scripts continue to work even with the class being disabled. When they want to enable everything again, they enable the class.

Yes, I know that this doesn't match what you'd expect. And I know it doesn't match aliases (because #T+/- was originally only used for triggers, thus the name of the command).

The whole point of IDs is that they should be unique. That is the solution to your problem. I have no intention of changing something this fundamental and breaking other user's scripts just because you don't want to use unique ID names.