public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Hans Ronne <hronne@comhem.se>
To: Jim Kingdon <kingdon@panix.com>
Cc: xconq7@sources.redhat.com
Subject: Re: time.g weirdness
Date: Thu, 12 Aug 2004 08:56:00 -0000	[thread overview]
Message-ID: <l03130303bd40dbe74ba0@[212.181.162.155]> (raw)
In-Reply-To: <200408120403.i7C43mu24086@panix5.panix.com>

>What I had in mind was something much less deep.  If
>mp-to-enter-terrain says you need 99 movement points, and
>acp-per-turn, free-mp, etc, say that a unit can never get 99 movement
>points in a turn, then have the help report it as infinite.  The big
>problem with that is that it is very case-by-case, and it would be
>easy for this computation to be out of sync with the action code.  So
>maybe one of the infinity variants would make more sense anyway.

In fact, I did something very similar to supply_desc last year:

/* Don't print out storage space if it is set to arbitrarily large
(9999, 999 or 99) as in many games. */
if (um_storage_x(u, m) == 9999
    || um_storage_x(u, m) == 999
    || um_storage_x(u, m) == 99) {
          tprintf(buf, "%s %d  ",
	m_type_name(m), unit->supply[m]);
} else {
          tprintf(buf, "%s %d/%d  ",
	m_type_name(m), unit->supply[m], um_storage_x(u, m));
}

This is what the subsequent discussion with Peter Garrone was about. He
thought (based on a less than perfect documentation) that 9999 really meant
infinite storage space.

Hans


  reply	other threads:[~2004-08-12  8:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-10 17:51 Robert Goulding
2004-08-10 18:11 ` Hans Ronne
2004-08-11  1:23 ` Hans Ronne
2004-08-11 16:34   ` Jim Kingdon
2004-08-11 16:34     ` Hans Ronne
2004-08-11 16:47       ` Eric McDonald
2004-08-11 17:09         ` Hans Ronne
2004-08-12  4:03           ` Eric McDonald
2004-08-12 11:16             ` Hans Ronne
2004-08-11 16:41     ` Eric McDonald
2004-08-12  8:42       ` Jim Kingdon
2004-08-12  8:56         ` Hans Ronne [this message]
2004-08-12 15:42           ` Jim Kingdon
2004-08-12 16:58             ` Eric McDonald
2004-08-12 17:35               ` Hans Ronne
2004-08-12 16:55         ` Eric McDonald
2004-08-12 15:39 ` Hans Ronne
2004-08-12 16:53   ` Jim Kingdon
2004-08-12 16:59     ` Hans Ronne
2004-08-12 17:08     ` Eric McDonald
2004-08-12 17:19       ` Hans Ronne
2004-08-12 17:24         ` Eric McDonald
2004-08-12 18:15           ` Hans Ronne
2004-08-13 23:46             ` Eric McDonald
2004-08-14  3:50             ` Wrecked-Type Doesn't Apply to Detonating Units Elijah Meeks
2004-08-14  9:19               ` Eric McDonald
2004-08-14 15:36                 ` Hans Ronne
2004-08-14 16:00                   ` Eric McDonald
2004-08-14 17:42                     ` Eric McDonald
2004-08-16  0:27                 ` Elijah Meeks
2004-08-16 18:24                   ` Eric McDonald
2004-08-16 21:34                     ` Elijah Meeks
2004-08-17  0:50                       ` 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='l03130303bd40dbe74ba0@[212.181.162.155]' \
    --to=hronne@comhem.se \
    --cc=kingdon@panix.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).