Zugg Software :: View topic - [2.21] Setting duplicated while redefining disabled setting (found in 2.18)

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

This problem, or a similar one, has been reported before (here, for instance), but I haven't yet found a thread showing this on the bug list, and it's still occurring in 2.18. So, here's a simple test case. Apologies if this is a repeat.

Defining a setting (e.g. a trigger) with the same ID and type as an existing setting should change the definition of the existing setting. If the existing setting is disabled, however, cMUD appears to create a duplicate instead.

Procedure

Start cMUD
Hit ESC to dismiss the Settings window
At the command-line, type:

Code:

#trig ft {foo} {#say trig 1}
#trig ft {foo} {#say trig 2}
#t- ft
#trig ft {foo} {#say trig 3}
#trig
#show foo
The output window will show:

Code:

Triggers:
- foo -> #say trig 2
foo -> #say trig 3
foo
trig 3

The existence of two triggers named 'ft' (one disabled, one enabled) can be confirmed with the Package Editor.

Note that 'trig 2' overwrote 'trig 1' (because the trigger was enabled when the #trig command was issued). This is the expected behavior. However, 'trig 3' created a duplicate - I would have expected it to overwrite 'trig 2', and probably to set the trigger to enabled.

I have produced similar errors with alarms and other setting types, as well. The same problem will also occur if the setting is within a disabled class (e.g. '#var foo/bar baz;#t- foo;#var foo/bar bag' will create a duplicate variable).

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Still present in 2.21 (not surprising, since I haven't seen it on the fix list).

Posted: Tue Apr 01, 2008 6:43 pm

Well, I think this is partly by design. When a setting is disabled, it is effectively invisible to your scripts. So it's like the trigger/variable/etc doesn't exist.

For example, imagine that you had a trigger named "ft" in your window, but also had a trigger named "ft" in a Global module in another package. Normally the "ft" trigger in your window will fire. But if you disable it, then the trigger in the global module will fire instead. And changing the "ft" trigger when the one in your window is disable causes the trigger in the global module to be changed instead.

This is inheritance and is the crude way that you can do some object-oriented programming in CMUD. By disabling a class folder, you can cause the inherited settings in another module to take over.

Now, with that said, getting duplicate settings with the same name in the same folder *is* bad and causes all sorts of problems. So I guess I need to think about exactly how to change this.

I'd actually be interested in exactly what zMUD does in this case if someone is willing to test it for me.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

I did the same set of commands in a blank session in zMUD 7.21:

Posted: Tue Apr 01, 2008 8:14 pm

Well, my routine for searching for a setting that is "inscope" can be called with an argument to ignore the "disabled" property. I think zMUD is doing something similar to just ignoring the Disabled property when overwriting an existing setting. So my modified version of your algorithm is this:

1. Attempt to locate an existing ENABLED trigger named 'foo', using all the existing scoping, etc.
2. If none is located, look for an existing DISABLED trigger named 'foo' using the existing scoping
3. If a trigger is found, replace it.
4. If no trigger is found, create it in the default location

That actually results in the fewest changes to the code, so should result in the fewest side-effects. And I think it will produce the same behavior as zMUD even when triggers are hiding in other classes.

Posted: Tue Apr 01, 2008 8:18 pm

Hmm, maybe not. In zMUD, if you do this:

#CLASS Test
#VAR InTest 123
#CLASS 0
#T- Test
#VAR InTest 456

then I think it creates a new variable called "InTest" within the main window. I don't think this overwrites the InTest in the disabled class. So I think that your algorithm might be more correct...it should only look for a disabled setting in the default location.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

In that second case you describe the variable itself is not disabled, its containing class is. I believe it is applicable to change a disabled setting when the setting itself is disabled and no enabled setting has been found. When a containing class is disabled we would not want anything to be created or updated in it.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

And an example to illustrate what I mean about disabling the classes:

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I would actually expect the code example Zugg gave to create a new variable. There is no default class defined, and the final #VAR command in his example does not specify a class.

I would expect your original trigger example

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Another slightly more convoluted example enter at the command line

Posted: Wed Apr 02, 2008 1:29 am

One of the key "rules" I can think of is that it should never be possible for CMUD to create a setting with the same name as another setting of the same type in the same class folder...ever. We know that if that happens, the internal hash table gets screwed up (because the hash table can only point to a single setting). I have recently improved the Settings Editor so that it is much harder to get duplicate settings with the same name. So scripting should also prevent this.

This was at the very core in zMUD. Since zMUD didn't have any database, it *only* had the hash table, so it couldn't create duplicate settings.

But we need to be *very* careful with these kind of changes. It would be really easy to completely screw up CMUD and compatibility with existing zMUD *and* CMUD scripts. So I really need to minimize the changes that I make to this low-level code.

It might just come down to doing a final check before CMUD creates any new setting. At the point of creating a new setting, CMUD already knows the correct name and class folder/module/package that the setting is going to be created in. At that time it could check to see if an existing setting with the same name already exists, and if so, just overwrite the existing setting regardless of whether it is enabled or disabled and regardless of whether the class containing it is enabled or disabled.

This kind of "last minute" check would ensure that duplicate settings don't get created. So this fixes any current situation that creates a duplicate setting (which we know is bad, so *must* be fixed), without changing any other existing behavior.

I really *don't* want to get into any side effects where using #CLASS might also enable the class. I think it is desirable to be able to use

#CLASS test
#T- test
#VAR a 123 // creates variable "a" in the disabled "test" class

In other words, people *should* be able to create variables in a disabled class without the side effect of enabling the class. Enabling the class might start causing triggers or alarms to run when all you want to do is reset a variable in the class. So I don't think I want to change that.

The problem that I need to fix is that doing

#CLASS test
#T- test
#VAR a 132
#VAR a 456

creates *two* variables named "a". That's the problem and bug that I need to focus on fixing.

So maybe I should just do that kind of fix and then see how things work after that and then we can decide if there are remaining cases that don't work the way we want them to.

Posted: Thu Apr 03, 2008 10:43 pm

OK, I have gone ahead and "fixed" this the way I described about. When creating a new setting, CMUD first searches (as before) for an existing setting that is visible in the current scope and enabled. Now, in v2.22, if nothing is found, CMUD also searches for a setting in the current context that is disabled. If a disabled setting is found, then the disabled setting is modified instead of creating a new setting with the same name. Here are some examples from v2.22:

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Well, I've been doing some thinking on this issue for the last couple of days. Started about four posts, and then deleted them to think some more. I wish I could say I've come back with great insights, but mostly I'm coming up with more questions.

The one that's really bending my brain involves this:

Posted: Fri Apr 04, 2008 7:28 pm

The order in which #T+ and #T- search for settings is undefined. If you have multiple different setting types with the same name, you can specify the "type" in the optional second argument, like this:

#T- a "alias"

However, with that said, it usually will search for a Class folder first, and then look for other settings. Internally, it will probably find settings in the order shown by the Filter buttons in the settings editor, since that represents the numerical "type" field for the setting, and that is how the database is sorted internally. But you should *never* count on this order, except for the fact that Classes will usually be tested before any other setting.

I came up with another test today: