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
next prev parent 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).