Zugg Software :: View topic - [316bB] CMUD ignores map database setting

Posted: Sun Apr 11, 2010 3:50 am

I was having problems with my main map so I decided to test whether the problem was due to corruption or had another source. I closed the map and removed the setting. This worked fine. When CMUD came back up there was no map, as expected. I then created a new map, this caused the appropriate setting, containing the path to the new map database, to be added. After I completed my experiment, I went back to the setting and restored the path to my production map database, then closed CMUD. I deleted the experimental database and the associated .ini and .zfg files. I then brought CMUD back up. It insisted on loading the experimental map. I went to the editor and checked the map setting and it contained the correct path, that is, the path of the production database. This made no difference to CMUD, when it didn't find the experimental database, it created one along with the .ini and .zfg files. I them manually loaded the production database and while this succeeded, CMUD insisted on calling it by the name of the experimental database and it went as far as updating the .ini and .zfg files that it had just created. So, in essence, it is ignoring the map database path setting which I provided and it routinely loaded in the past. Further, when I attempted to close CMUD with the path on the production database in the setting, it tried (and failed with a permissions violation) to store a .zfg file in Program Files (x86). This bug was reported on a separate post. I did send the dump in so it should be in your inbox at the moment.
I can only guess what is going on here, but, evidently, CMUD stores information about the environment that overrides whatever the user is intending to do. Since I found out that the package file contained control information that was not accessible to the user, I've worried about this, precisely for this reason. I am having this problem possibly because there is information in the package that it's not being updated.
It would be preferable if the package file only contained user-created settings and all the control information kept elsewhere, this would allow for some sort of utility to be developed that would deal with any control settings. As it stands now, the package must be loaded in order to effect any changes to the environment and if there is a problem with the package, the world comes to an end. By moving the control information out of the package, it would then just be the SQLite database that we can currently explore and nothing else. I one indication that this supposition is true is the fact that un-installing and re-installing CMUD (even into a brand new Program Files folder) makes no difference. So how can a brand new CMUD remember the past? From the .pkg file. If this is indeed the case, then the splitting of control information becomes even more important. This problem would simply go away by re-installing CMUD while deleting the control information file before re-installation, or even just deleting the control file and re-starting CMUD.
At any rate, I am now without a map, though I suppose that if I create a new package this problem will go away.

EDIT: I was wrong. I am able to use my map. I have to load it manually each time I start CMUD. CMUD still insists on acquiring the non-existent map. Also, when I close the session CMUD bombs trying to store the .zfg file in Program Files (x86), ignoreing the fact that my CMUD data folder is elsewhere, moreover, my map database is neither in Program Files (x86) or where the package file is stored, and CMUD does create a .zfg file at them map file location when it opens the non-existent map, so it knows where it is since it created a dummy map file there. (Seen relevent post).
Dumps have been sent.

Posted: Sun May 16, 2010 7:34 am

At Charneus' suggestion I turned ATCP off in my preferences and the mapper began to work normally again. Perhaps, the emulation should be unchecked by default.

Posted: Mon May 17, 2010 5:12 pm

Anaristos, I have no idea what you are talking about. A *.PKG file *IS* a plain SQLite database file. I don't know what "control information" you are talking about. There isn't anything like that in a package and I'm not sure where you think you are learning about that.

The only information used outside of the package database is the Windows Registry path that tells CMUD where your User Session Data Files are located. That path is used for session data paths. Then each session has it's path to the primary *.PKG file for the session stored in the session.db database. Everything else is in the package file.

There is no way for ATCP to control or change which map file is opened. The only place that determines the location of the map database is the Map Object in your package settings. It sounds more like you have additional map database objects somewhere else in your settings that is causing this problem. The fact that CMUD is trying to store the zfg file in Program Files is another indication that something is messed up in your Map Object since CMUD uses the same path of the *.DBM file for the *.ZFG files.

Posted: Mon May 17, 2010 5:12 pm

Also, if you are really still using v3.16b then you MUST UPGRADE to the 3.17 version. In the future I will ignore posts about older beta versions.

Posted: Mon May 17, 2010 7:39 pm

The suggestion for the ATCP was in order to get the mapper actually mapping again. Aardwolf recently added ATCP options, and for whatever reason, it's not mapping the rooms correctly any longer. :\

Charneus

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

charneus, are they adding the older ATCP, or the new GMCP/ATCP2 protocol that Zugg hasn't implemented quite yet?

Posted: Tue May 18, 2010 4:06 am

Good point. Hadn't thought of it, and now that you mention it, it MIGHT be ATCP2... not 100% sure yet. :\

Charneus

Posted: Tue May 18, 2010 5:18 pm

GMCP runs on a different option number (201 vs 200 of ATCP) so CMUD would just ignore any GMCP right now. I'm pretty sure they implemented regular ATCP. As mentioned in the other thread, I'll look at it when I'm done with TeSSH. It's possible their ATCP implementation is different than IRE somehow in a way that messes up the CMUD mapper.