public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Lincoln Peters <sampln@sbcglobal.net>
To: Xconq list <xconq7@sources.redhat.com>
Subject: More terrain coating issues
Date: Fri, 05 Nov 2004 21:37:00 -0000	[thread overview]
Message-ID: <1099261618.26829.6570.camel@localhost> (raw)

I've been working on a test module that demonstrates how omniterr.g
might be used in a game that someone might actually want to play. 
However, I've run into two problems:

1. I created "engineer" units that can theoretically add and remove
terrain coatings, thus allowing a side to alter its environment
(essential if the map has no environment to start with!).  However, when
I try to have an engineer add a coating, the "add terrain" command
appears to complete with no errors (thus burning an ACP, probably would
also burn materials if I had enabled consumption-per-add-terrain). 
However, the map is unchanged!

When I run Xconq with the -D option, I get the following output from the
"add terrain" command:

Moving s1 e 2 (6,24) (0/1, buzz 0) with plan type Passive <null goal> waiting supply_alarm no tasks
s1 e 2 (6,24) doing [add-terrain 6 24 1 31 (#2)] with 2 acp left
s1 e 2 (6,24) action [add-terrain 6 24 1 31 (#2)] result is action-done, 1 acp left


2. The code for advanced units seems to get confused if none of the cell
terrain within its reach can produce any materials.  If the cell has
several coatings that produce materials, those coatings are completely
ignored.


3. I can't figure out how to make terrain consume materials.  Usually
such a thing is unnecessary, but if a game is set up to track soil
nutrients, it would be a good way to prevent players from trying to
place vegetation in an inappropriate area (e.g. tropical rain forest in
a polar ice cap).


4. Xconq doesn't complain if an illegal edge terrain, such as a coating,
is specified.  It proceeds as if the terrain type was legal, apparently
by treating it as cell terrain.  Fortunately, the consequences of the
bug seem to be harmless.


Finally, I have a new version of omniterr.g, plus the current pre-alpha
version of my test module (loosely based on empire.g), should it be
helpful for reproducing the aforementioned bugs (it exhibits #1 and #2):

http://homepage.mac.com/lmpeters/omniterr.g
http://homepage.mac.com/lmpeters/imperium.g

---
Lincoln Peters
<sampln@sbcglobal.net>

I don't know anything about music.  In my line you don't have to.
		-- Elvis Presley

                 reply	other threads:[~2004-10-31 22:27 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1099261618.26829.6570.camel@localhost \
    --to=sampln@sbcglobal.net \
    --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).