* Xconq output files @ 2003-10-05 21:47 Hans Ronne 2003-10-06 2:24 ` Peter Garrone ` (3 more replies) 0 siblings, 4 replies; 15+ messages in thread From: Hans Ronne @ 2003-10-05 21:47 UTC (permalink / raw) To: xconq7 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Xconq output files 2003-10-05 21:47 Xconq output files Hans Ronne @ 2003-10-06 2:24 ` Peter Garrone 2003-10-06 3:42 ` Jim Kingdon ` (2 subsequent siblings) 3 siblings, 0 replies; 15+ messages in thread From: Peter Garrone @ 2003-10-06 2:24 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Xconq output files 2003-10-05 21:47 Xconq output files Hans Ronne 2003-10-06 2:24 ` Peter Garrone @ 2003-10-06 3:42 ` Jim Kingdon 2003-10-07 3:28 ` Hans Ronne 2003-10-06 22:04 ` Eric McDonald 2003-11-23 20:12 ` Eric McDonald 3 siblings, 1 reply; 15+ messages in thread From: Jim Kingdon @ 2003-10-06 3:42 UTC (permalink / raw) To: xconq7 > 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 ".". ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Xconq output files 2003-10-06 3:42 ` Jim Kingdon @ 2003-10-07 3:28 ` Hans Ronne 0 siblings, 0 replies; 15+ messages in thread From: Hans Ronne @ 2003-10-07 3:28 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 >> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Xconq output files 2003-10-05 21:47 Xconq output files Hans Ronne 2003-10-06 2:24 ` Peter Garrone 2003-10-06 3:42 ` Jim Kingdon @ 2003-10-06 22:04 ` Eric McDonald 2003-11-23 20:12 ` Eric McDonald 3 siblings, 0 replies; 15+ messages in thread From: Eric McDonald @ 2003-10-06 22:04 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Xconq output files 2003-10-05 21:47 Xconq output files Hans Ronne ` (2 preceding siblings ...) 2003-10-06 22:04 ` Eric McDonald @ 2003-11-23 20:12 ` Eric McDonald 2003-11-23 21:54 ` Hans Ronne 3 siblings, 1 reply; 15+ messages in thread From: Eric McDonald @ 2003-11-23 20:12 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Xconq output files 2003-11-23 20:12 ` Eric McDonald @ 2003-11-23 21:54 ` Hans Ronne 2003-11-24 0:26 ` Eric McDonald 2003-11-24 1:25 ` Xconq testing: Win2K Erik Jessen 0 siblings, 2 replies; 15+ messages in thread From: Hans Ronne @ 2003-11-23 21:54 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Xconq output files 2003-11-23 21:54 ` Hans Ronne @ 2003-11-24 0:26 ` Eric McDonald 2003-11-26 21:53 ` Hans Ronne 2003-11-24 1:25 ` Xconq testing: Win2K Erik Jessen 1 sibling, 1 reply; 15+ messages in thread From: Eric McDonald @ 2003-11-24 0:26 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Xconq output files 2003-11-24 0:26 ` Eric McDonald @ 2003-11-26 21:53 ` Hans Ronne 2003-11-26 22:56 ` Eric McDonald 0 siblings, 1 reply; 15+ messages in thread From: Hans Ronne @ 2003-11-26 21:53 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 [ 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Xconq output files 2003-11-26 21:53 ` Hans Ronne @ 2003-11-26 22:56 ` Eric McDonald 2003-12-01 1:38 ` Hans Ronne 0 siblings, 1 reply; 15+ messages in thread From: Eric McDonald @ 2003-11-26 22:56 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Xconq output files 2003-11-26 22:56 ` Eric McDonald @ 2003-12-01 1:38 ` Hans Ronne 0 siblings, 0 replies; 15+ messages in thread From: Hans Ronne @ 2003-12-01 1:38 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Xconq testing: Win2K 2003-11-23 21:54 ` Hans Ronne 2003-11-24 0:26 ` Eric McDonald @ 2003-11-24 1:25 ` Erik Jessen 2003-11-24 2:16 ` Hans Ronne 1 sibling, 1 reply; 15+ messages in thread From: Erik Jessen @ 2003-11-24 1:25 UTC (permalink / raw) Cc: xconq7 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Xconq testing: Win2K 2003-11-24 1:25 ` Xconq testing: Win2K Erik Jessen @ 2003-11-24 2:16 ` Hans Ronne 2003-11-24 2:27 ` Erik Jessen 0 siblings, 1 reply; 15+ messages in thread From: Hans Ronne @ 2003-11-24 2:16 UTC (permalink / raw) To: Erik Jessen; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: Xconq testing: Win2K 2003-11-24 2:16 ` Hans Ronne @ 2003-11-24 2:27 ` Erik Jessen 2003-11-25 1:47 ` Hans Ronne 0 siblings, 1 reply; 15+ messages in thread From: Erik Jessen @ 2003-11-24 2:27 UTC (permalink / raw) To: 'Hans Ronne'; +Cc: xconq7 -----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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: Xconq testing: Win2K 2003-11-24 2:27 ` Erik Jessen @ 2003-11-25 1:47 ` Hans Ronne 0 siblings, 0 replies; 15+ messages in thread From: Hans Ronne @ 2003-11-25 1:47 UTC (permalink / raw) To: Erik Jessen; +Cc: xconq7 >>>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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2003-11-29 18:33 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-05 21:47 Xconq output files Hans Ronne 2003-10-06 2:24 ` Peter Garrone 2003-10-06 3:42 ` Jim Kingdon 2003-10-07 3:28 ` Hans Ronne 2003-10-06 22:04 ` Eric McDonald 2003-11-23 20:12 ` Eric McDonald 2003-11-23 21:54 ` Hans Ronne 2003-11-24 0:26 ` Eric McDonald 2003-11-26 21:53 ` Hans Ronne 2003-11-26 22:56 ` Eric McDonald 2003-12-01 1:38 ` Hans Ronne 2003-11-24 1:25 ` Xconq testing: Win2K Erik Jessen 2003-11-24 2:16 ` Hans Ronne 2003-11-24 2:27 ` Erik Jessen 2003-11-25 1:47 ` Hans Ronne
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).