public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Lincoln Peters <sampln@sbcglobal.net>
To: Elijah Meeks <elijahmeeks@yahoo.com>
Cc: Xconq list <xconq7@sources.redhat.com>
Subject: Re: Rebuilding Units That Turn
Date: Thu, 20 Nov 2003 00:13:00 -0000	[thread overview]
Message-ID: <1069286473.29637.136126.camel@odysseus.peterslan> (raw)
In-Reply-To: <20031119231348.89073.qmail@web13108.mail.yahoo.com>

On Wed, 2003-11-19 at 15:13, Elijah Meeks wrote:
> Well, change-type definitely won't work, because then
> the player would have to manually input it into the
> interface (At least, that's how it was when I tried to
> implement it in Specula for Dragons), so I was
> thinking of simply using Build and then hp-to-build (I
> think that's the table name) to kill off the unit that
> builds it, leaving you with just one unit.  How's
> upgrade work and is it easy to implement/use?

The table is hp-to-garrison.  When used in this manner, it destroys the
old unit (by reducing it to 0 hitpoints) as soon as the new unit is
completed.  The code in your game would probably look like:

(table hp-to-garrision
  (heavily-damaged-corps damaged-corps 999)
  (damaged-corps corps 999)
)

This has a few serious problems problems, almost all of which I found
while working on bolodd.g (although some came up in space-civ.g):

1. No material transfer from the old unit to the new one.  If you have a
huge stockpile of fuel or ammo in a unit that was upgraded in this
manner, it disappears once the upgrade is completed.

2. Any tooling the old unit had is lost.  The consequences of this vary
depending on how your game is set up, but it can be quite frustrating.

3. If used with advanced units, the newly-completed advanced unit MUST
be given enough material automatically to sustain it for one turn, or
else it will starve before it has a chance to collect anything from the
environment.


I use the time.g-like upgrade mechanism in bolodd.g to allow the various
types of bases to upgrade (level 1 base to level 2, level 2 base to
level 3, etc.).  However, because of the issues I mention above, it
works, but it doesn't work well.  I plan to change it to use "Change
type" as soon as "Change type" is implemented in the interface(s).

  parent reply	other threads:[~2003-11-20  0:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-19 22:41 Elijah Meeks
2003-11-19 22:44 ` Eric McDonald
2003-11-19 23:37   ` Elijah Meeks
2003-11-20  0:01     ` Eric McDonald
2003-11-20  0:13     ` Lincoln Peters [this message]
2003-11-20 18:00       ` Jim Kingdon
2003-11-20 18:52         ` Eric McDonald

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=1069286473.29637.136126.camel@odysseus.peterslan \
    --to=sampln@sbcglobal.net \
    --cc=elijahmeeks@yahoo.com \
    --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).