This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: time.g weirdness


>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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]