Xconq output files

Xconq output files

[Hans Ronne]

I've been looking at the various files that Xconq creates recently, since I
have been fixing a number of MacOSX-related problems involving these files.
Anyhow, this got me thinking. A plethora of files are created by Xconq.
Furthermore, their names and locations vary according to the platform, the
interface, and the game being played:

* Saved game files ("save.xcq" on Unix and Windows, "Saved Game" on the Mac).
* Checkpoint files ("checkNN.xconq" on Unix and Windows, "Checkpoint" on
the Mac).
* Warning files ("Xconq.Warnings" on all platforms).
* Debug files ("Xconq.DebugOut" on all platforms).
* Preference files ("prefs.xcq" in the tcltk interface, "Xconq Preferences"
in the PPC interface).
* Scores files ("scores.xcq" for most games, but some games have their own
scores files).
* Statistics files ("stats.txt" on Unix and Windows, "Statistics" on the Mac).
* Error files ("ERRsave.xcq" on Unix and Windows, "Error Save" on the Mac).

Then there is the question where all these files live:

On Unix, preferences, checkpoints and saved games go into XCONQHOME. If
XCONQHOME is not defined, they go into an invisible ".xconq" directory in
the user's home directory. If none of these are defined, the files are
dumped into the current directory. Other files (debug and warnings) just go
into the current directory. The scores files go into XCONQ_SCORES
(/var/lib/xconq/scores by default) or else into a visible subdirectory of
the current directory named "scores".

On Windows, an attempt is similarly made to put things in XCONQ_HOME (note
the underscore), or else into a hidden "_xconq" directory in the user's
home directory (?). When this fails, the files go into the xconq top
directory. The scores files also end up in the xconq top directory.

On the Mac, finally, most files go into the xconq top directory, but some
go into the current directory (usually the same thing, but not always). An
exception is the preference file under the PPC interface, which lives in
the System folder. The Mac tcltk preference file does however live in the
xconq top directory.

I think we could simplify things a bit. One easy step is to give the files
the same names everywhere. I am already looking into that. I think it would
make sense to use the xcq extension only for files (game files) that can be
opened by Xconq and the txt extension for all other text files.

Another possible simplification would be to be more consistent about file
locations across platforms and interfaces. For example, does it really make
sense to hide saved games and checkpoints in an invisible Unix directory?
The preference file certainly belongs there, but saved games I would expect
to find in a visible directory. And do we really need to put the scores
files in a common place (/var/lib)? This made sense with the old xtconq
where one program handled several users. I see no reason why a user should
not get the scores from his own games saved in his home directory, except
perhaps to prevent cheating.

A possible simplification could look like this:

* saved games, checkpoints and debug files all go into a "save" directory,
either within the xconq top directory itself (Mac and Windows) or a visible
$HOME/xconq directory on Unix.

* scores files similarly go into an xconq/scores directory (or perhaps into
xconq/save to make it really simple).

* preferences stay in their platform-specific locations (System folder in
MacOS9, invisible $HOME/.xconq directory on Unix).

This would also help to keep the xconq top directory less cluttered, which
is a problem at least under Windows and MacOS.

Comments?

Hans

Re: Xconq output files

[Peter Garrone]

Hi Hans
  The only comment I have is that suppose a game is saved, as save.xcq
  or with a specific name, when reloading the game, the "secret"
  directory has to be prepended, so .xconq has to be sought out in 
  a possibly cluttered home directory to find these files again.
    Peter

Re: Xconq output files

[Jim Kingdon]

> And do we really need to put the scores files in a common place
> (/var/lib)?

Well, getting rid of this would remove the need for xconq to be
setgid, which would help with some of the known security holes.

I suppose there probably are people who like a common score file
(e.g. perhaps that ISP which has cconq installed).  But I don't know
whether there this is strong enough to warrant keeping the feature.

> I think it would make sense to use the xcq extension only for files
> (game files) that can be opened by Xconq and the txt extension for all
> other text files.

I'm not sure which files this would change.  Instead of txt, I might
just omit an extension (e.g. Xconq.Warnings rather than
Xconq.Warnings.txt).  But the general idea sounds OK.

> * saved games, checkpoints and debug files all go into a "save" directory,
> either within the xconq top directory itself (Mac and Windows) or a visible
> $HOME/xconq directory on Unix.

I guess I'd put these in .xconq.  It isn't really normal for an
application to hardcode the name of any directory not starting in ".".

Re: Xconq output files

[Eric McDonald]

Hi Hans,

On Sun, 5 Oct 2003, Hans Ronne wrote:

> I think we could simplify things a bit. One easy step is to give the files
> the same names everywhere.

This is a good idea.

> I am already looking into that. I think it would
> make sense to use the xcq extension only for files (game files) that can be
> opened by Xconq and the txt extension for all other text files.

From a Windows point of view, the "txt" extension makes sense, 
because a text editor (Notepad, etc...) is likely to be associated 
with it. But you also lose some descriptivity by using "txt" only; 
for things such as Xconq.Warnings, I think XconqWarnings.log might 
be more appropriate. 

> * saved games, checkpoints and debug files all go into a "save" directory,
> either within the xconq top directory itself (Mac and Windows) or a visible
> $HOME/xconq directory on Unix.

Sounds reasonable, except that I would suggest $HOME/Xconq for 
Unix systems: it will show up earlier in most conceivable file 
listings (with the ASCII charset, at least). Also, quite a few 
other programs used capitalized data directories, such as 
"Desktop" with some window managers.

> This would also help to keep the xconq top directory less cluttered, which
> is a problem at least under Windows and MacOS.

We can further unclutter the top level dir by moving Imakefile and 
Local.config into a subdir, and then documenting this for people 
who really dislike configure scripts. 

Also, the README and INSTALL files could be moved into doc, and a 
simple README could be left up top telling people to look in doc. 
This would effectively take 5 files out of the top level.

Eric

Re: Xconq output files

[Hans Ronne]

>> I think it would make sense to use the xcq extension only for files
>> (game files) that can be opened by Xconq and the txt extension for all
>> other text files.
>
>I'm not sure which files this would change.  Instead of txt, I might
>just omit an extension (e.g. Xconq.Warnings rather than
>Xconq.Warnings.txt).  But the general idea sounds OK.

I was thinking more about those files that have the xcq extension even
though they are not game files (prefs.xcq, scores.xcq). On systems that
care about extensions double-clicking on them will now launch Xconq instead
of the text editor they really need.

Hans

Re: Xconq output files

[Eric McDonald]

We never really got resolution on this thread. Since ".xcq" is now 
associated with Xconq on the Windows platform, I would like to 
clear things up.

On Sun, 5 Oct 2003, Hans Ronne wrote:

> I've been looking at the various files that Xconq creates recently, since I
> have been fixing a number of MacOSX-related problems involving these files.
> Anyhow, this got me thinking. A plethora of files are created by Xconq.
> Furthermore, their names and locations vary according to the platform, the
> interface, and the game being played:
> 
> * Saved game files ("save.xcq" on Unix and Windows, "Saved Game" on the Mac).
> * Checkpoint files ("checkNN.xconq" on Unix and Windows, "Checkpoint" on
> the Mac).

I vote to leave saved games with ".xcq". Furthermore, I would 
like to change the checkpoint savefiles to ".xcq" as well, since 
they really are saved Xconq games.

> * Warning files ("Xconq.Warnings" on all platforms).
> * Debug files ("Xconq.DebugOut" on all platforms).

"XconqWarnings.log" and "XconqDebugOut.log".

> * Preference files ("prefs.xcq" in the tcltk interface, "Xconq Preferences"
> in the PPC interface).

"XconqPrefs" or "XconqPrefs.txt".

> * Scores files ("scores.xcq" for most games, but some games have their own
> scores files).

"XconqScores" or "XconqScores.txt" for the main scores file.

> * Statistics files ("stats.txt" on Unix and Windows, "Statistics" on the Mac).

"XconqStats"

> * Error files ("ERRsave.xcq" on Unix and Windows, "Error Save" on the Mac).

"ErrorSave.xcq"

All files that do not have the ".xcq" extension are prefaced with 
"Xconq". This helps Xconq keep all of its files within a namespace 
and lessens the chance of colliding with other apps. The ".xcq" 
applies universally to anything that is a saved Xconq game.

Legacy support can be added to the code so that it will try 
reading a file called "prefs.xcq" if "XconqPrefs" does not exist 
yet.

Sound reasonable?

Eric

Re: Xconq output files

[Hans Ronne]

>We never really got resolution on this thread. Since ".xcq" is now
>associated with Xconq on the Windows platform, I would like to
>clear things up.
>
>On Sun, 5 Oct 2003, Hans Ronne wrote:
>
>> I've been looking at the various files that Xconq creates recently, since I
>> have been fixing a number of MacOSX-related problems involving these files.
>> Anyhow, this got me thinking. A plethora of files are created by Xconq.
>> Furthermore, their names and locations vary according to the platform, the
>> interface, and the game being played:
>>
>> * Saved game files ("save.xcq" on Unix and Windows, "Saved Game" on the
>>Mac).
>> * Checkpoint files ("checkNN.xconq" on Unix and Windows, "Checkpoint" on
>> the Mac).
>
>I vote to leave saved games with ".xcq". Furthermore, I would
>like to change the checkpoint savefiles to ".xcq" as well, since
>they really are saved Xconq games.

Yes. It makes sense for all game files to end in .xcq, so that they are
opened by Xconq. I even contemplated if all the .g files should be renamed
.xcq, but that would go to far (and also break the CVS record for all the
game files). I already started to implement some of these changes on the
Mac.

>> * Warning files ("Xconq.Warnings" on all platforms).
>> * Debug files ("Xconq.DebugOut" on all platforms).
>
>"XconqWarnings.log" and "XconqDebugOut.log".

Not sure about this one. A .log file to me is something that accumulates
output from several sessions. Which these files do not. How about just
XconqWarnings?

>> * Preference files ("prefs.xcq" in the tcltk interface, "Xconq Preferences"
>> in the PPC interface).
>
>"XconqPrefs" or "XconqPrefs.txt".

I like XconqPrefs. The .txt extension looks screwy except on Windows where
it is invisible. Of course, it is there that it is needed the most. Since
we want all these files to open in a text editor, is it possible to tell
Windows that anything that starts with Xconq should be openend in a text
editor?

Alternatively, we could have a second unique extension (.xcd ?) for all
Xconq-related doc files that should be opened in a text editor. Perhaps
this is a better idea.

>> * Scores files ("scores.xcq" for most games, but some games have their own
>> scores files).
>
>"XconqScores" or "XconqScores.txt" for the main scores file.

XconqScores is fine. However, since different games make different score
files, this is a tricky one.

>> * Statistics files ("stats.txt" on Unix and Windows, "Statistics" on the
>>Mac).
>
>"XconqStats"

Yep.

>> * Error files ("ERRsave.xcq" on Unix and Windows, "Error Save" on the Mac).
>
>"ErrorSave.xcq"

Yep.

Hans

Re: Xconq output files

[Eric McDonald]

On Sun, 23 Nov 2003, Hans Ronne wrote:

> >I vote to leave saved games with ".xcq". Furthermore, I would
> >like to change the checkpoint savefiles to ".xcq" as well, since
> >they really are saved Xconq games.
> 
> Yes. It makes sense for all game files to end in .xcq, so that they are
> opened by Xconq. I even contemplated if all the .g files should be renamed
> .xcq, but that would go to far (and also break the CVS record for all the

I thought about this as well, which is why I made sure to mention 
the word "save".

I could also associate ".g" with xconq.exe. But here I am a 
little bit more concerned with clobbering an existing extension. 
I think I can incorporate logic into the installer script to 
check for this though.

> >"XconqWarnings.log" and "XconqDebugOut.log".
> 
> Not sure about this one. A .log file to me is something that accumulates
> output from several sessions. Which these files do not. How about just
> XconqWarnings?

Sure, or how about "XconqWarnings.xcd" as you suggest below, but 
only for Windows? Since the default view settings in Windows 
Explorer hide file extensions, the ".xcd" files will appear to 
have the same names as they do on other platforms, but I will be 
able to associate shell extensions (e.g., Open) with them. (And 
for people like me, who prefer to see the extensions when dealing 
with Windows, they will appear less "clumsy".)

> >"XconqPrefs" or "XconqPrefs.txt".
> 
> I like XconqPrefs. The .txt extension looks screwy except on Windows where

I'll do XconqPrefs.xcd on Windows unless you object.

> Alternatively, we could have a second unique extension (.xcd ?) for all
> Xconq-related doc files that should be opened in a text editor. Perhaps
> this is a better idea.
> 
> >"XconqScores" or "XconqScores.txt" for the main scores file.
> 
> XconqScores is fine. However, since different games make different score
> files, this is a tricky one.

Well, we could alter existing modules where 'scorefile-name' is 
set to conform to some naming standard (perhaps the name of the 
the game module file minus the ".g" extension; in which case 
Bellum would be the only game currently in the library that needs 
to change). I would suggest that we remove any extensions from 
these, and then let the Xconq Windows code tack on a ".xcd".

So how does this sound?

Eric

Xconq testing: Win2K

[Erik Jessen]

I did some testing with a very simple map, where I actually had some
terrain listed on the map, that hadn't been declared.

Effects:
1) warning that the game might not be able to continue.
    I chose 'continue'
2) internal error, followed by hang, when I attempted to place a unit in
the topmost hex row.

Recommendations:
1) somehow ignore the invalid terrain cleanly; new users are bound to
mess things up, and internal errors will throw them for a loop.

Notes/thoughts:
1) since (I think) all games are supposed to be stored in 'lib', have
the 'open file' button default to starting there.

2) I am working on the model of:
   a) a 'standard config' file that declares all terrain types & unit
types
      and their interactions.  This is normally hand-typed.
   b) a map file.  This is normally entered via gui, and saved "binary".
   c) a unit placement file (scenario, if you will).  This is normally
       entered via gui, but might be hand-edited, and saved "binary".
   d) a 'game' is a small file that pulls all of the above together.
      This permits a map of W. Europe to be used for various eras, and
      Set of standard "modern" units to be used in various campaigns.

   This allows the following to be done:
   - create a single config file that describes Ancient Rome.
   - create maps for each battlefield
   - create various unit deployments for each battle

   I would really, really like an easy way to save off the map &
unit-placement as separate files in the GUI; it's been a while, but I
recall that it was really complicated to save off just what one wanted
to each file.

I would also like to be able to strip out a specific terrain-type, in
case I bungled the job & created an extra few early on, and would like
to clean things up.  Maybe the ability of the map-save function to not
list any terrain for which there were no placements would do this
perfectly?

I am hoping that the approach listed in (2) will encourage newcomers to
build new games: the normal game will be pretty small (because it'll
just include in 3 larger files), so the user will only have to edit one
or two
Of the file to create new games from existing ones.

For power users, it would be nice if there was an easy way to do
things like:
- shift a particular region of the map up/left/right/down/mirror.
- enlarge the map on any side(s)
- shrink the map (deleting terrain that fell off the face of the earth)

Erik

Re: Xconq testing: Win2K

[Hans Ronne]

>Recommendations:
>1) somehow ignore the invalid terrain cleanly; new users are bound to
>mess things up, and internal errors will throw them for a loop.

Sounds like a reasonable idea, but I'm not sure how to implement it.
Perhaps force undefined terrian to type 0 (ocean)?

>Notes/thoughts:
>1) since (I think) all games are supposed to be stored in 'lib', have
>the 'open file' button default to starting there.

How open file dialogs work is usually determined by the OS. On the Mac, it
will remember where you poked around the last time and go there. Which is
frequently (but not always) the lib folder.

>2) I am working on the model of:
>   a) a 'standard config' file that declares all terrain types & unit
>types
>      and their interactions.  This is normally hand-typed.
>   b) a map file.  This is normally entered via gui, and saved "binary".
>   c) a unit placement file (scenario, if you will).  This is normally
>       entered via gui, but might be hand-edited, and saved "binary".
>   d) a 'game' is a small file that pulls all of the above together.
>      This permits a map of W. Europe to be used for various eras, and
>      Set of standard "modern" units to be used in various campaigns.
>
>   This allows the following to be done:
>   - create a single config file that describes Ancient Rome.
>   - create maps for each battlefield
>   - create various unit deployments for each battle

This sounds like an interesting project. Reusable maps etc. is a good idea.
BTW, if anybody wants to make a Gulf War game my ancient near east map is
an excellent starting point.

>   I would really, really like an easy way to save off the map &
>unit-placement as separate files in the GUI; it's been a while, but I
>recall that it was really complicated to save off just what one wanted
>to each file.

That is possible. Just uncheck "Save all" in the designer save dialog and
then check whatever you want to save in a specific file ("world", "terrain"
or "units" for example).

>I would also like to be able to strip out a specific terrain-type, in
>case I bungled the job & created an extra few early on, and would like
>to clean things up.  Maybe the ability of the map-save function to not
>list any terrain for which there were no placements would do this
>perfectly?

Not sure what you mean here. Do you want to convert one terrain type to
another automatically? That cannot be done at present.

>I am hoping that the approach listed in (2) will encourage newcomers to
>build new games: the normal game will be pretty small (because it'll
>just include in 3 larger files), so the user will only have to edit one
>or two
>Of the file to create new games from existing ones.
>
>For power users, it would be nice if there was an easy way to do
>things like:
>- shift a particular region of the map up/left/right/down/mirror.
>- enlarge the map on any side(s)
>- shrink the map (deleting terrain that fell off the face of the earth)

Resizing and moving the map (or world) is possible in the Mac designer save
dialog, which has a special reshape world button. There you can also decide
how previously undefined terrain should be filled. I know this is not much
use to non-Mac users, but it shows it can be done. I may port this stuff to
tcltk, but only after 7.5 is done.

>It sure would be handy if there was a way to keep the 'design' popup
>always s on top of the map, or better - make it into a pane.

>It's always disappearing, and I have to go find it on the toolbar.

Again, this is how the Mac interface works. Maybe you should get yourself a
Mac :-).

Seriously, though, support for floating windows is not that great in tcltk.
The research dialog, which pops up and refuses to go to the back if all
that remains to be done is to pick a research subject, is my attempt to
make a flaoting window in tcltk. It does the job but is rather clunky, and
it took a lot of coding to get there.

And even if I made a floating tcltk designer window, it would probably keep
the focus as long as it stays in front. Meaning that you would not be able
to edit the map.

Hans

RE: Xconq testing: Win2K

[Erik Jessen]

-----Original Message-----
From: Hans Ronne [mailto:hronne@comhem.se] 
Sent: Sunday, November 23, 2003 5:25 PM
To: Erik Jessen
Cc: xconq7@sources.redhat.com
Subject: Re: Xconq testing: Win2K

>Recommendations:
>1) somehow ignore the invalid terrain cleanly; new users are bound to
>mess things up, and internal errors will throw them for a loop.

Sounds like a reasonable idea, but I'm not sure how to implement it.
Perhaps force undefined terrian to type 0 (ocean)?
-> is there any way to just not even stick it into the database when
read?

>Notes/thoughts:
>1) since (I think) all games are supposed to be stored in 'lib', have
>the 'open file' button default to starting there.

How open file dialogs work is usually determined by the OS. On the Mac,
it
will remember where you poked around the last time and go there. Which
is
frequently (but not always) the lib folder.
-> OK.  Not much we can do.

>2) I am working on the model of:
>   a) a 'standard config' file that declares all terrain types & unit
>types
>      and their interactions.  This is normally hand-typed.
>   b) a map file.  This is normally entered via gui, and saved
"binary".
>   c) a unit placement file (scenario, if you will).  This is normally
>       entered via gui, but might be hand-edited, and saved "binary".
>   d) a 'game' is a small file that pulls all of the above together.
>      This permits a map of W. Europe to be used for various eras, and
>      Set of standard "modern" units to be used in various campaigns.
>
>   This allows the following to be done:
>   - create a single config file that describes Ancient Rome.
>   - create maps for each battlefield
>   - create various unit deployments for each battle

This sounds like an interesting project. Reusable maps etc. is a good
idea.
BTW, if anybody wants to make a Gulf War game my ancient near east map
is
an excellent starting point.

>   I would really, really like an easy way to save off the map &
>unit-placement as separate files in the GUI; it's been a while, but I
>recall that it was really complicated to save off just what one wanted
>to each file.

That is possible. Just uncheck "Save all" in the designer save dialog
and
then check whatever you want to save in a specific file ("world",
"terrain"
or "units" for example).
-> it is doable, it's just that the 'save all' screen needs a help
button, or more text next to each check-box.  The text is probably the
best; there's no reason to have a small popup - it's a save-menu, after
all.

>I would also like to be able to strip out a specific terrain-type, in
>case I bungled the job & created an extra few early on, and would like
>to clean things up.  Maybe the ability of the map-save function to not
>list any terrain for which there were no placements would do this
>perfectly?

Not sure what you mean here. Do you want to convert one terrain type to
another automatically? That cannot be done at present.
-> no, for example let's say I created terrain-type 'village', then
didn't use any of them on the map.  Or, I would like to take a 1991-Gulf
map, and use it for an 'ancients' game.  I'd like all the 'airport'
hexes to convert to something else, or just disappear.  Right now, it's
a manual process of editing the GUI.  Maybe what's needed is a
side-program where one can load the GDL file, and just say "replace
terrain X with terrain type Y".  Right now, things are saved in a binary
format, and it's a mess to parse.   Of course, I could write one, but I
only know Perl, and then that means yet another language to support...

>I am hoping that the approach listed in (2) will encourage newcomers to
>build new games: the normal game will be pretty small (because it'll
>just include in 3 larger files), so the user will only have to edit one
>or two
>Of the file to create new games from existing ones.
>
>For power users, it would be nice if there was an easy way to do
>things like:
>- shift a particular region of the map up/left/right/down/mirror.
>- enlarge the map on any side(s)
>- shrink the map (deleting terrain that fell off the face of the earth)

Resizing and moving the map (or world) is possible in the Mac designer
save
dialog, which has a special reshape world button. There you can also
decide
how previously undefined terrain should be filled. I know this is not
much
use to non-Mac users, but it shows it can be done. I may port this stuff
to
tcltk, but only after 7.5 is done.

>It sure would be handy if there was a way to keep the 'design' popup
>always s on top of the map, or better - make it into a pane.

>It's always disappearing, and I have to go find it on the toolbar.

Again, this is how the Mac interface works. Maybe you should get
yourself a
Mac :-).

--> Yeah, yeah, yeah.  I actually heard of some companies that are
switching 100% off of Win*** to Mac, because the hardware costs more,
but the overall support cost is lower.

Seriously, though, support for floating windows is not that great in
tcltk.
The research dialog, which pops up and refuses to go to the back if all
that remains to be done is to pick a research subject, is my attempt to
make a flaoting window in tcltk. It does the job but is rather clunky,
and
it took a lot of coding to get there.

And even if I made a floating tcltk designer window, it would probably
keep
the focus as long as it stays in front. Meaning that you would not be
able
to edit the map.

--> OK.  How about putting the Design popup into a pane, instead?
Then it's not a popup?

Hans

RE: Xconq testing: Win2K

[Hans Ronne]

>>>Recommendations:
>>1) somehow ignore the invalid terrain cleanly; new users are bound to
>>mess things up, and internal errors will throw them for a loop.
>
>Sounds like a reasonable idea, but I'm not sure how to implement it.
>Perhaps force undefined terrian to type 0 (ocean)?
>-> is there any way to just not even stick it into the database when
>read?

Nope. Any terrain must have a defined type. That's why you get the crashes.

>>I would also like to be able to strip out a specific terrain-type, in
>>case I bungled the job & created an extra few early on, and would like
>>to clean things up.  Maybe the ability of the map-save function to not
>>list any terrain for which there were no placements would do this
>>perfectly?
>
>Not sure what you mean here. Do you want to convert one terrain type to
>another automatically? That cannot be done at present.
>-> no, for example let's say I created terrain-type 'village', then
>didn't use any of them on the map.  Or, I would like to take a 1991-Gulf
>map, and use it for an 'ancients' game.  I'd like all the 'airport'
>hexes to convert to something else, or just disappear.

Well, that's what I meant by automatic terrain conversion. A possible
feature in the future, but not available now.

>And even if I made a floating tcltk designer window, it would probably
>keep
>the focus as long as it stays in front. Meaning that you would not be
>able
>to edit the map.
>
>--> OK.  How about putting the Design popup into a pane, instead?
>Then it's not a popup?

That might work. Perhpas one could stick it in place of the unit list.

Hans

Re: Xconq output files

[Hans Ronne]

[ interrupted thread resumed once more ]

>I could also associate ".g" with xconq.exe. But here I am a
>little bit more concerned with clobbering an existing extension.
>I think I can incorporate logic into the installer script to
>check for this though.

That would be nice if it works, but I wouldn't spend too much time on it.

>> >"XconqWarnings.log" and "XconqDebugOut.log".
>>
>> Not sure about this one. A .log file to me is something that accumulates
>> output from several sessions. Which these files do not. How about just
>> XconqWarnings?
>
>Sure, or how about "XconqWarnings.xcd" as you suggest below, but
>only for Windows? Since the default view settings in Windows
>Explorer hide file extensions, the ".xcd" files will appear to
>have the same names as they do on other platforms, but I will be
>able to associate shell extensions (e.g., Open) with them. (And
>for people like me, who prefer to see the extensions when dealing
>with Windows, they will appear less "clumsy".)

Maybe. xcd was just a suggestion. Actually, if the text file extension is
going to be used only on Windows, .txt is fine with me. It is, after all,
what Windows users expect to see.

>> XconqScores is fine. However, since different games make different score
>> files, this is a tricky one.
>
>Well, we could alter existing modules where 'scorefile-name' is
>set to conform to some naming standard (perhaps the name of the
>the game module file minus the ".g" extension; in which case
>Bellum would be the only game currently in the library that needs
>to change). I would suggest that we remove any extensions from
>these, and then let the Xconq Windows code tack on a ".xcd".

Do we really need different scorefiles for different games? Right now, it's
kind of confusing with most of the games using scores.xcq and a few having
their own scorefiles. I never understood why.

Hans

Re: Xconq output files

[Eric McDonald]

On Wed, 26 Nov 2003, Hans Ronne wrote:

> That would be nice if it works, but I wouldn't spend too much time on it.

I don't think it would require too much time.
I just haven't had any quality time to spend with Xconq lately....

> going to be used only on Windows, .txt is fine with me. It is, after all,
> what Windows users expect to see.

Okay, fine. That makes my life easier.

Now as far as the directories part of this thread goes: Are we 
going to change things or are we going to leave them until after 
7.5?

Eric

Re: Xconq output files

[Hans Ronne]

>Now as far as the directories part of this thread goes: Are we
>going to change things or are we going to leave them until after
>7.5?

I'm not sure yet. I'm trying to get save/restore of network games to work,
which is one thing we do need before the release. Saved game locations are
important in this case (the client just gets a module name and must then
search for the file in the right place). Some kind of standard for this is
needed, and I'm considering various options.

Hans