public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: "Erik Jessen" <ejessen@adelphia.net>
To: "'Hans Ronne'" <hronne@comhem.se>
Cc: <xconq7@sources.redhat.com>
Subject: RE: Xconq testing: Win2K
Date: Mon, 24 Nov 2003 02:27:00 -0000	[thread overview]
Message-ID: <000801c3b231$fdcbf650$6401a8c0@Win2k> (raw)
In-Reply-To: <l03130300bbe70647e2cc@[212.181.162.155]>



-----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




  reply	other threads:[~2003-11-24  2:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2003-11-25  1:47           ` Hans Ronne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000801c3b231$fdcbf650$6401a8c0@Win2k' \
    --to=ejessen@adelphia.net \
    --cc=hronne@comhem.se \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).