Issues with the opening global map warning

[raverdave2k]

When opening a global map a warning box is presented and there is a box you can untick to say don't display the warning in the future, I have encountered two problems with this.

1) Quite often that warning ends up appearing behind the file open dialogue which if you don't realise can make it look the editors frozen rather than waiting for your input.-- Even if you do notice there can still be an issue as you can't drag the "file open" screen out of the way while the warning is open and I've not always been able to alt-tab it to the front.

2) The "un-ticking" of the box only appears to only be remembered until you close the editor, the next time run it and open a global map you need to do it again, it's possible this is intentional but the wording certainly sound like it's supposed to be a one time deal.

[apocalyptech]

raverdave2k wrote:

When opening a global map a warning box is presented and there is a box you can untick to say don't display the warning in the future, I have encountered two problems with this.

I'll take a look at these; I'd wanted to do so anyway, since editing Global map files with Book 3 is something that we're going to start reasonably wanting to do, anyway.

As for point 2, I'm curious if other "preferences" get saved for you. It is supposed to be a one-time thing. If you go into the preferences and change some values, are any of THOSE saved between runs?

-CJ

[raverdave2k]

I've just tried changing a few settings in there (Default zoom and one of the tick box's on the same page) and neither of those were saved either, however it is remembering the paths to the save games an game dirs.

In case it helps to know, I'm running exe's I compiled myself from the code as it was about 48hrs ago on Windows 8 (64 bit), I'm not sure if the save settings issue existed previously or not but point 1 did.

[apocalyptech]

raverdave2k wrote:

I've just tried changing a few settings in there (Default zoom and one of the tick box's on the same page) and neither of those were saved either, however it is remembering the paths to the save games an game dirs.

In case it helps to know, I'm running exe's I compiled myself from the code as it was about 48hrs ago on Windows 8 (64 bit), I'm not sure if the save settings issue existed previously or not but point 1 did.

Okay, thanks for the info - I'll see what I can reproduce, and what I can do about it if so. :)

[apocalyptech]

Oops, didn't mean to close this - errant mouse click.

[apocalyptech]

Okay, the immediate symptom of the dialog sometimes getting buried has been solved by the simple expedient of just removing it entirely. That was mostly a holdover from the Book 1 days when it might have been more likely to be problematic. I think it's less so now, given that the editor won't ever be overwriting the actual base game maps, so it's gone. People editing Book 1 maps will just have to be careful of their own volition. :)

I've still got to look into the second point, to see if preferences are getting saved properly on the Windows (and OSX?) side of things.

[apocalyptech]

For the preference-saving issue, it looks like I can't reproduce that on my system at the moment. Would you mind making a small change in your code, recompiling, and letting me know what some output is? Specifically, around line 73 of eschalon/preferences.py, could you add in a couple "print" statements as the first thing inside load() and save(), like so:

    def load(self):
        print 'Loading preferences from: %s' % (self.filename)
        if (self.filename is not None and os.path.isfile(self.filename)):
            self.cp.read(self.filename)
            return True
        else:
            return False

    def save(self):
        print 'Writing preferences to: %s' % (self.filename)
        if (self.filename is not None):
            df = open(self.filename, 'w')
            self.cp.write(df)
            df.close()

I could push that into a separate branch somewhere if you'd rather not edit the source directly. Anyway, once you run that and recompile/install, the next time you run you should have a message on there which specifies the path that it's been trying to write its config file to. On my machine it's: C:\Users(username)\Local Settings\Application Data\Eschalon Savefile Editor\config.ini

Once you've got that, could you see if that's a valid path, and if not, what the path should be?

Thanks!

(Note that my fix for getting rid of the global-map warning is only in my "cj_working" branch at the moment, so you'd have to switch there if you wanted to get rid of that.)

[raverdave2k]

I'll give this a test this evening and report back with the output, I'm actually running your working branch at the moment anyway as I wanted to take a peek a look at the new open dialogue boxes (which I like by the way), I've no issue with editing the code so no need to put anything extra up.

[raverdave2k]

Right, just given this a run and this was the output:

Loading preferences from: None
Writing preferences to: None

[apocalyptech]

Hm, interesting. So - this kind of debugging functionality really Should be built in already, but for now, let's add in various print statements to see what variables some of this stuff is getting.

First off, near line 38 in the main __init__ function, could you add:

print 'Platform: %s' % (sys.platform)

To make sure that we're getting that properly. Then, assuming that that's coming out as 'win32' like we'd expect, you'd hop down to line 209 or so, in win32_prefsfile(). For there, I'd be interested to see what the various "appdir" vars get set to. So for instance, after each one, something like:

print 'Appdata dir: %s ' % (appdir)

I assume that it's not finding anything in that whole function and then just defaulting to "None" at the end. If none of the directories it finds are valid on your system, it'd be good to try and figure out a directory which DOES make sense...

[raverdave2k]

Added in all these and the latest out put is:

Platform: win32
Appdata dir: C:\Users\dave_000\Local Settings\Application Data
Appdata dir: C:\Users\dave_000\Application Data
Appdata dir: C:\Users\dave_000\Local Settings\Application Data
Appdata dir: C:\Users\dave_000\Application Data
Loading preferences from: None
Writing preferences to: None

"C:\Users\dave_000\" is a valid path but then neither Application Data or Local Settings exist, there is the AppData folder however, which appears to have replaced "Application Data" in Windows Vista / 7 / 8.

Just for comparison, the Book III save path on my system is:

"C:\Users\dave_000\AppData\Roaming\Basilisk Games\Book 3 Saved Games"

[apocalyptech]

Okay, looks like I should really be using the APPDATA variable, or rather the LOCALAPPDATA directory in this case, since the file contains pathnames, etc.

Could you add the following somewhere in there, just to verify that I'm looking at the right thing?

print 'Local Appdata: %s' % (os.environ['LOCALAPPDATA'])

Thanks!

[raverdave2k]

That returns "Local Appdata: C:\Users\dave_000\AppData\Local"

[apocalyptech]

Cool cool, and to doubly-verify: that folder exists?

[raverdave2k]

It does indeed, probably should of mentioned that sorry.

[apocalyptech]

Okay, I believe this should be good to go now. I'll go ahead and close it out, but let me know if you have any more trouble with it!

[raverdave2k]

Just tested with latest code in your working branch and can confirm settings are now saving for me :)

(The Book II and III map editors won't actually run from that buil but I'll assume that's because you have some work in progress)

[apocalyptech]

Ah! No, I actually wasn't aware of that. Turns out I accidentally used a function which is (somewhat mysteriously) only available on Linux. I'll have to put an alternative in place tonight. For now, if you had wanted to be working on maps in the meantime, you can delete these two lines from mapgui.py, 'round line 302:

                if starting_path and os.path.samefile(slot.directory, starting_path):
                    active_slot = idx

It's the "os.path.samefile()" function which doesn't exist on Windows.

I'll open up a separate issue for that, since it's not actually related.

[apocalyptech]

Okay, well, FYI - I got to that more quickly than I'd thought I would. Pulling should get you a fix.