Zugg Software :: View topic - [2.36] package trouble - moved module settings invisible to child windows

Apprentice Joined: 18 Feb 2007 Posts: 190

long story short, ive been playing with packages, finally after realizing they have no use for me
i moved everything back to main session package, and that resulted with some strange corruption
and random crashes, eventually i ended up with several varfuns invisible to child windows Confused

to reproduce:
create empty session
create new package with some name
set this module (package main module) to local only
create new var within it, say abc=123
now... move that module to main session package
finally,
#win a
#SA test: @abc
:a:#SA test: @abc

- child window does not see the variable, order of creation of child window dosnt matter, neither does changing moved module visibility (after it has been moved while set local)
- crashes i was unable to reproduce

update: i managed to restore everything to order by disabling affected module, session restart, move contents to new module, delete old, session restart, rename new
session restart after disabling was necessary to prevent cmud from going into infinite loop while moving settings... glitchy stuff Wink

Posted: Sat Oct 25, 2008 11:04 pm

This code is working as expected. By default the new local module belongs to the main window, that's why it can see the local variable. The child window a, doesn't have the access to the module so that's why you can't see the variable. Either that or I'm missing something.

Apprentice Joined: 18 Feb 2007 Posts: 190

no mate, local should be visible to whole package given module is in, that includes all windows in that package

main point is however that hidden property is not being reset, module in question is permanently locked, and settings need to be moved to new module to restore proper access rights

Sorcerer Joined: 13 Jan 2006 Posts: 715

I wouldn't say you have no use for packages. I myself find it is better to separate all settings into sub-packages. Similar to coding in C, instead of having one huge file, I have several smaller ones with similar things grouped together.

Example:
Healing Package - Contains all healing trigs, aliases, etc
Group Package - Contains every setting I use in relation to running groups
Clan Package - Contains all my special aliases for my clan commands and communication.
Combat Package - Contains all my combat macros and triggers
Actions Package - Contains all my responses to things like being poisoned, blinded, plagued, etc etc
Protection Package - Contains all my triggers to keep my protection spells up, and warnings any time I lose something critical.

In this way I am also protected in the event something gets corrupted in one package, I don't have to remake EVERYTHING. Which would be a pain for someone like me who has 10k+ lines of code involved in their scripting (My last count in zMUD was 40k lines - sick I know, but considering my latest versions of Healer Bot and Autorescue for 2k1's ED are both over 500 lines each...)

Sorcerer Joined: 13 Jan 2006 Posts: 715

I should note, that my CMUD settings for the Healer Bot are in a separate package from the normal Healing Package, which only contains my manual healing macros and aliases.

Apprentice Joined: 18 Feb 2007 Posts: 190

grouping? naw, there already classes for that purpose, in zmud i had similar things grouped in one text file that would erase and recreate respective classes on load...
there are even modules now like classes werent enough Razz

indeed, thats one feasible use for packages there, data protection

but bottom line - settings shouldnt get corrupted in the first place - and this actually happens way too often

wow, you write _huge_ scripts Shocked

commendable effort

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

when you say "move that module into main session package" do you mean into a regular session rather then the empty one?

Just asking for me because I'm stuck on that part. :)

Apprentice Joined: 18 Feb 2007 Posts: 190

when you create new package (package editor -> file -> new package), whatever your configuration is, you will end up with at least 2 packages :P
so assuming we started empty session (esc on session select) go to package editor, create new package with name say, abc, we now have 2 packages, untitled and abc
package untitled being main session package and package abc being newly created package...

actually i havent played with it since, but i believe all modules moved between packages while being set local only with get affected
edit: confirmed above

Posted: Mon Oct 27, 2008 4:46 pm

I was not able to reproduce this. Here is what I did:

1) Run CMUD, close Sessions window, open Settings
2) Select File/New Package. Enter a name "mytest"
3) Click on the "mytest" tab to view it.
4) Click on the "Local" option and then click Save Changes
5) Select New/Variable. Enter "a" for name, and "123" for value
6) On command line, type "#SHOW @a" to verify that @a cannot be accessed yet (optional step)
7) Drag the "mytest" module and drop it over the "untitled" tab
8) On command line, type "#SHOW @a" and it properly displays 123

So it looks like it's working fine in a blank session. If you can find a different procedure that will reproduce the original problem, let me know. But it's important to post the *exact* steps (exactly what you click on, etc) since there are multiple ways to do things in CMUD. When you say "move that module into the main package", I can think of at least 3 ways to do that. So you need to be specific.

Apprentice Joined: 18 Feb 2007 Posts: 190

yes yes dear sir, it works for main window!
try show from child - :a:#SA @a

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

Hmm, I can't even get a variable to show with :a:#SH @abc when mytest is global.

Apprentice Joined: 18 Feb 2007 Posts: 190

dragging is correct answer

heres visual example which also uses another module, also note like package editor colours var a in red

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

okay, I think Tech was right, even if it maybe shouldn't be like that. The child window, despite being a part of the main session, does not see the module, in any mode. Maybe Zugg can speak to this more.

Apprentice Joined: 18 Feb 2007 Posts: 190

master z, field flag remains 128 for moved module tho it should be cleared, this is the reason

Posted: Tue Oct 28, 2008 4:15 pm

Apprentice Joined: 18 Feb 2007 Posts: 190

nope, extra aliases were only to present that package editor dosnt see variable either

another screenie where i followed _exactly_ your steps

Posted: Tue Oct 28, 2008 8:18 pm

OK, this is weird. We've got some sort of intermittent bug here. I just tried it again and now it fails. But it didn't fail yesterday. So it's probably some sort of uninitialized variable that depends upon whatever is in memory when I build CMUD. I've reproduced it today and while it's failing I will debug this right now to try and track down the problem...before it suddenly starts working again.

And Dumas: Yes, when it's in this bugged state, changing the "mytest" module to Global doesn't work either. So I can see both problems now. I hate bugs like this.

Posted: Tue Oct 28, 2008 9:27 pm

I think I found it. Very obscure and very intermittent. I'm pretty sure it's fixed now. It's working, but I'll test it again tomorrow to make sure it's *still* working.

What was happening was that the "Module Field" values in the database were getting stored incorrectly for moved modules and the settings within them. When a module is moved from one package to another, CMUD has to generate a new "ID" field for the module (since if it was record 1 in the new package database, record 1 in the previous package database was usually already taken, so CMUD would generate a new unique ID key value). But CMUD wasn't updating the Module field of the module and settings with it to this newly generated ID value.

So the bug didn't actually have anything to do with whether the module was Local or Global (as Dumas determined). Causing the bug required a very specific order of steps and a very specific timing, which is what made it intermittent, but easy to reproduce on other systems with different timings.

This bug actually messes up *any* module or window moved from one package to another potentially. So it's quite a serious bug.

In the database, what was happening is that the ModuleID field of the "a" variable was actually being set to the "untitled" window instead of the "mytest" module. Since variable "a" was now within the "untitled" window, which is private, so the "test" window could not see it. But having "a" within the "untitled" module is a valid location for it.

I might be able to come up with some automatted checks that looks at the Parent field (which is the parent shown in the tree view). In the case of the "a" variable, the Parent was properly set to "mytest" even though the Module field was set to "untitled". This shouldn't happen normally, so I might be able to check for this when loading a module and try to fix it automatically. But it's also possible that there are cases that won't be caught by this. So it's probably a good idea to do an Export XML and then Import XML to get all of your ModuleID fields regenerated correctly. That's the best method to remove the corruption caused by dragging modules to a different package.

This week I will try to see if I can still compile a version 2.37 of CMUD without the new mapper. It's going to be tough with all of the mapper changes I've been making, but it's probably important to get this bug fixed as soon as possible.

Thanks for your patience in tracking this one down.

Apprentice Joined: 18 Feb 2007 Posts: 190

excellence, this bugger caused me lot of frustration and probably was main cause of (nearly - sqlite admin to rescue) lost settings.
i wouldnt worry about 2.37, now that we know it is there and how to avoid it - time would be better spent on new mapper Wink

hmm, might be feasible option then to have module dragging over packages hooked to do lock, export to temp, destroy old and cleanup, import, unlock?

Posted: Tue Oct 28, 2008 10:47 pm