PROJECT IDEAS

This list is a collection of ideas about what to change in Xconq.
In general, these are new features, rather than bug fixes.
Everything is grouped into one of several categories, although
the grouping is not precise, and to find out if some idea has been
already thought of, you should search this using appropriate keywords.

--General

G5. Fix -DSYSV nonsense in SelFile so builds don't break.

G17. Write a search_straight_line(x0, y0, x1, y1, fn) that scans
exact line between places.  Could also do 3d version.
Use to determine obstacles to fire.

G23. Add multi-player alerts;
multi_alert(msg, sides, [minquorum, mintopass], timeout)
multi_query
update_multi_query_display
interface calls ack_multi_query.

G27. Define performance as a sort of ratio to specmarks, so benchmark game is
known to last 2 minutes on a 100-specmark machine, etc.  Use -R 1, only
"real" games, various mixes of AI, little/no interaction.
Games should include classic, standard, gettysburg, magnusvew, ww2-eur-42.
Add as "testperf" script, "check-perf" action to test makefile.

G30. Define foo_text(buf, n, xxx) where n is available space for description,
return actual length of text in buffer.
To get strings, define foo_string(xxx), which returns a 0-terminated string.

G32. Implement a convex region finder that works by picking random points as seeds
and grows out from those.  Sides have to be "locked" if entire side can't
all grow - combo of locked and unlocked sides allows region to become
parallelogram, triangle, etc.
How should borders and connections affect generic region finding?
Grow from random points until about 3/4 of cells in regions, then scan
down to finish off.  (Could leave single points as "their own regions",
not alloc any region structs.)

G33. General path objects consist of multiple segments, each with start/end
point and a validity test (that can be done at any time).  Also include
a bit with segment saying "shortest" or just "nonincreasing distance".
Should be possible for a path to say "impossible" for some segment??
(consider path that consists of land travel segments plus a sea hop
that needs a ferry of some sort - path is still valid and useful.)

G34. Regions should
point to super-regions, not necessarily contained.  Include bits for
caching connectedness, terrain percentages, etc.  Add region layer to
regular map (each hex can only point to one region, multi-stuff must be
between regions).  Need commands to define and display regions.
Regions never overlap, must subdivide and make subregions be included
in several super-regions.  True for all regions, don't do multiple
"region layers" (unless significantly more efficient?  check stats).
Add region layer for AIs that need to explore, add to layer
as AI sees stuff.

G35. Theory of networked Xconq is that all copies synchronize on actions
and random seeds, then do run_game and get identical results.  Each
program will broadcast its planned actions, then wait until each other
program indicates that it has sent all that it plans to.  When a program
has received "done" from all others, then it can safely execute.
Allow various combinations of multiple- and single-server games.
For any routine in the interface that tweaks in the kernel, have to
siphon it off to the network also.  Do via compiling interface with
augmented calls, so kernel code need not be modified to know about
networking.  On receiving side, input mux includes a decoder that
invokes kernel routines (note that decoder has to know about calls
that not all interfaces actually support, since less-powerful
interface may get kernel-changing messages from more powerful interface).
Build a "skelclient" from skelconq.c and client.c.  client.c includes
a "wait_for_server" that calls run_game or just accepts outcomes and
state changes from the server.
Add tests involving two communicating skelconqs with preset port
numbers, use to test networking behavior.  Use a skelconq and Xconq
on Macs to test PPC (or GUSI?)
Add a protocol version number etc so that mismatched versions can't
connect.

G37. Define a "text buffer" object that is variable-size, resizes as needed,
do all printfs into it.

G38. To guarantee integrity, program could display checksum or signature to players
upon startup, so they can agree as to identity of program.

G39. To do play-by-mail games, need to be able to save an optionally encrypted game
and pass along to next player -
player info includes some sort of bit indicating
where to send to. (player-address slot)
Encrypted game should retain game-module form as plaintext,
include a "password" slot, then all numbers appearing at "top level" will be
decrypted, random forms still read normally.
Also must be able to store all notices so other players can see.

G46. Finish writing game compiler, test, collect speed comparisons.

G47. Historical events should always be unique; check for duplications and
complain or avoid creating when restoring a game.

G48. Restrict Lisp syntax knowledge to small part of code, allow translation
to other syntaxes (tcl?).

G49. Keep part of history log on disk rather than in memory, read in to temp
(preallocated) space when saving game.

G50. Add machinery to control size and detail of log, translate old stuff or
some event types into summaries rather than full records.

G55. Decide where scorefiles should live, implement.
One choice would be to make a scores directory, have a generic scorefile
and several specialized game score files there also.

G56. Add a macro apply_to_all_stack(x, y, fn, go_down_if_true_fn).

G57. Add mechanism to record and replay a full transcript of all or part of
a game.

G58. Decide what "taking a unit" is supposed to mean and implement if
necessary.  Could be considered a combat-less capture, constrain when
a unit can be captured vs fought.

G59.
Glast.

--Kernel

K1. Allow game to define the fate of units when a side resigns.  Default
should be for nothing to happen to any unit.  Possibilities include
disappearance, surrender to first unit showing up, whole side being
controlled, etc.
Also include policy or commands to edit the leftover images from
a losing side.

K2. Set up consistent rules for action priority.
Unit action priority should be able to derive from individual extension
property, a per-side vector of type priorities, a per-type property,
and a per-side property.  Routine is just unit_priority(unit).
Goal is to be able to have, say, allied aircraft and German ground
units move together, then German aircraft and allied ground, then
trains and trucks of both sides.
Requirements:
1. Units of same priority should be able to be moved in a convenient
order (to minimize scrolling, according to player's prefs, etc).
2. All units of a given priority must have finished movement before
the next will move.  Includes delayed units.

K3. In evals, give meaning to "this" so expressions like (count <u> (this side))
work.

K4. Could restrict some tables to 15 bit integers, use top bit to repn varying
value, up to 16d15+127 by doing a 4/4/7 split of bits. (why?)

K5. Support full decimals for parms, flush the "10000" numbers and add scale
factor to all numeric parms.  Scaling fixed by code, use scaling when
computing effects.
Ambiguity if context of decimal doesn't include scale factor (as in "define"),
but could support decimals as a distinct type in GDL (as ratios instead of
floats?).  c_number should convert to integer, or check validity of uses.

K6. Error messages should include context as well as line numbers (save previous
several lines, and dump next several if still reading after error).
Show first 72 chars of 3 previous lines and 3 following lines.

K7. Fix see-always to not show city occupants unless explicitly set up.
(Only true of X11 interface?)

K8. If the people in a cell change to a trusted side, or if a trusted unit
enters enemy cell, allies should get view updates.

K9. Implement delayed views, where a unit that is out of contact with the side
keeps own view data and only merges when in contact with side again.

K10. [vision-terrain-effect to alter range depending on terrain?]

K11. [check validity of random event list after loading]

K13. For small-part-of-world areas, define daylight-zone and twilight-zone(?),
which default to 1/2 and 1/12 respectively.

K14. Add area illumination ability so that burning wrecks and such can illuminate
immediate area at night.  Do by adding bit vector for lighting or coverage-like array.

K15. Add a "last-alliance-wins" scorekeeper, use with some games.

K16. Decide when sides should be able to look at other units' hp.

K17. Climate-related global vars should become world or area properties.
(like what?)

K19. Add a controlled-by layer to world that can be distinct from people side.
Control can be imposed by presence of particular units within a given
range, maintained by others to a given range, with chance of reversion
to people side if different from controlling side.

K21. Define unit feelings toward each side as pair of bytes, for/against and
willingness to act on feeling.

K22. Clarify vision rules.  The true state of the world is a set of layers.
For each cell in each layer, there is an apparent value, a date for
that value, possibly prev values also.  Only need bit if value always
accurately known once discovered.  Elevations and features unlikely
to change.
directly_visible(side, unit)
implies that unit is accurately seen.
chance_to_see{,_on_movement,_on_action,_each_turn}(side, unit)
if always 100%, then is equiv to directly_visible.
Need parms see-xxx-always for each layer.

K23. Define a unit->tracking slot that is a sidemask of sides that are
seeing the unit move around.  (Unit property "trk".)
#define side_tracks_unit(side,unit) (unit->tracking&side_bit(side)).
Define u_track_chance, defaults to 0.
Define u_lose_track_chance, evaluate once/move, once/turn.
If unit being tracked, then updates about unit state go to all
tracking sides.
Track bit would always be set for own units.
(Is this the same as "unit->spotted"?)

K24. Implement storms as very-high-density cloud (>100%?).  Storms cause
accidents and attrition and loss of acp and reduction of speed.

K25. Impl constant elevations and temps that don't need a whole layer.
Detect by seeing min == max of terrain types present (and no chance
of terrain changes - test this in general).

K26. Allow some moves to use random mp, be able to specify +/- amounts.
This is mp (and acp?) consumption only, does not affect validity of action.
ut_mp_extra?

K27. Define a notion of hp for bord/conn types, allows for interdiction
and repair.

K28. Define a hallucination chance for some utypes:
(sp-)looks-like u1 u2 -> n% is chance that u1 appears to be a u2
and is recorded as such in a view.
Note that code should ensure that only info about image is displayed
rather than hallucination.

K29. Use a slot (which?) to indicate variation radius of actual reinforcement
position around  given xy.  Default of zero requires to be on actual xy.

K30. Implement ZOC as a layer if any ZOC ranges > 1.

K32. Add a "facing" bitmask that indicates the directions that a unit is
"facing", or can operate in, add effects of facing vs non-facing.
Come up with a display for this.

K33. Events can have causes that they should be tied to, can use to
enhance displays etc.

K34. Add a (sym <sym>) property to units that can be used to write a symbolic
ref to unit when saving.  Stash in unit extras.

K35. Maintain an in-supply bit for units.

K36. Add chance that incomplete units will lose cp (eliminating if cp < 1),
call it incomplete-accident-chance.

K37. To decide about control, see if any units cannot always be controlled
directly, then for those compute the max radius that controlling units
can be in.  If > 1, should define a layer, otherwise check directly
when need to know.

K38. Add a commander property to units, control of units can recurse through
commanders, so unit not under direct control can be under control if
commander is in control range.

K39. Some unit types should be unwilling to break a treaty.
(In some games,)
Should humans have to declare war explicitly?
DoW may not be possible or meaningful in some games...
DoW is agreement by single player doing the declaration, terms are to
treat side as enemy (doctrine), and to hit other side (how often?),
could demand a surrender of some sort.
DoW must be public.
Up to other sides how to respond.
Peace treaty includes terms to nullify DoW.
In general, terms should be able to include refs to other agreements.
DoW can always be rescinded by player alone, make it have morale
consequences?

K41. @deffn Table @code{people-sabotage-rate??} u m -> .01hp
This table is the attrition rate of a unit in the open in
a cell with people on a hostile [define] side.
@end deffn

K42.
DEF_UPROP_I("lockon-chance", u_lockon_chance,
	"chance that unit remains seen when no longer covered",
	lockonchance, 0, 0, 100)
@deffn UnitTypeProperty @code{lockon-chance} n%
This property is the chance that once seen, a unit will continue to be seen
while it is being covered.
Defaults to @code{0}.
@end deffn

K43.
DEF_UPROP_I("storage", u_storage,
	"space for materials shared by all types",
	storage, 0, 0, 9999)
DEF_UM_TABLE("material-size-in-unit", um_size,
	"how much space one unit of a material requires in a unit",
	umsize, constumsize, 0, 1, 9999)
@deffn UnitTypeProperty @code{storage} n
This property is a unit's generic space for materials of any type.
Defaults to @code{0}.
@end deffn
@deffn Table @code{material-size-in-unit} u m -> n
This table is the amount by which the given material counts against
the unit's storage space.
Defaults to @code{1}.
@end deffn

K44.
DEF_UT_TABLE("capacity-negation", ut_capacity_neg,
	"true if the unit negates capacity of connections of the terrain type",
	utcapacityneg, constutcapacityneg, 0, 0, 1)
[, but some unit types negate the capacity of connections.]
@deffn Table @code{capacity-negation} u t -> t/f
This table is @code{true} if when @var{u} is in the open in a cell
that includes connections of type @var{t},
those connections have no capacity for units.
Defaults to @code{false}.
@end deffn

K45. Implement (or stub) basic goal tests.

K46. Implement doctrine locking.

K47. Terrain types should have a precedence determining which conn/border types
override each other's effects (right now any conn overrides any border).
Should be a property of ttypes.

K48. Side relations could be expressed as a bit vector of what will happen
in various situations.  "wake up if approached", "allow entry", "exchange
view info", etc.  Particular relationships such as trust and control
become particular bit vectors then. (or could do as defcon levels?)

K49. Need a way to have an OB with lots of units, followed by refs to
particular units and modified properties, and read both without
creating any useless units.

K50.
@deffn SideProperty @code{respect-neutrality} t/f
@end deffn

K51.
DEF_KWD("real-timeout", K_REAL_TIMEOUT, 0)

K52.
@deffn SideProperty @code{real-timeout} seconds
This property is the number of (real) seconds to wait before declaring the
side to be finished with this turn.
Defaults to @code{-1}, which waits forever.
@end deffn

K53.
@deffn SideProperty @code{task-limit}
This property is the maximum number of tasks a unit is allowed to stack up.
@end deffn

K54.
@deffn DoctrineProperty @code{avoid-bad-terrain} n%
This property is the probability that the unit will not enter
unhealthy terrain, even if it delays meeting goals.
Unhealthy means higher attrition and accident probs, materials
consumed faster than replaced, slower movement.
Defaults to @code{0}.
@end deffn

K55.
@deffn DoctrineProperty @code{repair-at} n%
This property indicates that when the unit's hp is at @var{n%} of max,
make a plan to repair.
Defaults to @code{50}.
@end deffn

K56.
@deffn DoctrineProperty @code{resupply-at} n%
This property indicates that when the level of a
operationally-consumed material is at @var{n%}
of capacity, try to resupply.
Defaults to @code{50}.
@end deffn

K57.
@deffn DoctrineProperty @code{rearm-at} n%
This property indicates that when the level of a
combat-consumed material is at @var{n%}
of capacity, try to resupply.
Defaults to @code{50}.
@end deffn


K58. Be able to expand country borders by building or occupying outside original
country.
ut_add_people_chance n%
ut_add_people_adj_chance n%

K59. Decide if/how country growth and initial strength should interact.

K61. Add a command-line option to interpret forms supplied on the command line.
Do these after all else read and interpreted and variants done.
Allow both pre-load and post-load (default) forms.

K62. Each side should be able to get different instructions.
Per-side instructions should not be accessible to other sides.

K63. Should use elevation diffs to decide about sloping terrain (a new subtype-x).
Add to basic percentile algorithm.

K64. Look further ahead in road generation to pick overall most favorable
routing. (count cells adjacent to proposed next cell).

K65. Player mix test should be allowable_player_mix(assignmentindex),
allows "scapegoating" a particular player if failed - gives
a starting place for interface to fix.

K66. Define parms for variability of initial materials using variation
on fractal percentile synth method.

K67. Add flooding rules for when terrain changed around a liquid type.
Non-liquid border could be a dike.

K68. Add density of occupants of indep units already placed.  Specify for
both units that have to be occs and others that don't.

K69. Need a way to coordinate all name gen for a single side -
"foo" -> Fooland, Fooard, Fooards, Fooish"  Could also decide colors and
emblem randomly, but wouldn't need to coordinate.
Specify just *one* side name generator, extensions added in a standard
way by an nlang.c routine.
Predefine nonterminals side-name, side-noun, etc in side-namer grammar.

K70. Add "earthlike" generator that borrows code, but is completely wired
to do Earthlike stuff, including a semi-wired set of terrain types
(use extensions to recognize by attributes rather than position,
so that river deltas can be flat and swampy indep of how terrain type
fits with others in a game design).
Use tectonic code at some scales, erosion at others.
Could base calcs on sphere, translate to world grid when done.
Base on all real dimensions, so alt ranges wired.
Parameters are area size/world.circumference for the scale
(assume 100 km/cell if weird circumference),
latitude of area, range of elevations (0 - 10000 meters),
distance from coast (at center of area, allows specifying distance such that
area can be 3/4 land, etc), average temp, average rainfall.
For tectonics, use layers for plate num, move dir, and elevation.
For small-scale, make random ridge/high point, erode down to lowest
or to coast.

K71. Add recorded events that get played when their scheduled time
arrives, so that a city could revolt or disappear at a preset time.
Playing scheduled events should happen after acp/mp calc, but before
players actually get to move.

K72. Add synth method for secret scorekeeper goals.

K73. Use password to match up players when restoring into a different set
of displays.  If no password, then will just accept a different
assignment, perhaps warn for cmdline setup, flag in dialog boxes.

K74. Any terrain-based variation, such as temperature, should check
if need to represent varying values over area, don't need to
alloc layer if not, *but* may need to quickly synth layer if
terrain is added that *does* allow variations.

K75. Should be able to conceal the identity of side until first
encountered (still display progress in turn, helpful to play).
Also not be able to send messages to unknown sides, though
broadcast should still work.

K77. When making units appear, do only units in open directly, then
occupants recursively once transports have appeared.
Similarly for disappearance, but in reverse order.

K78. Fix up material transfer action so that transfer is free or cheap
in most games, but can be made expensive.

K79.
DEF_UPROP_I("elevation-at-max-range", u_elev_at_max_range,
	"elevation of fire when shooting at maximum range",
	elevatmaxrange, 0, 0, 9999)
Formula is something like
maxelev = (range / rangemax) * elev_at_max_range
y = maxelev - (maxelev * (x - range/2)^2) / (range/2)^2.
@deffn UnitTypeProperty @code{elevation-at-max-range} dist
[elaborate calc to interpolate while rising and falling, basically
approximating a parabola]
Defaults to @code{0}.
@end deffn

K79. Add tables material-to-add-terrain, material-to-remove-terrain
(examples are cement to make road, fill material to remove ditch or gully).

K80. Define action "influence" that is like proposed "charm" but more
general.

K81. Allow the construction of bases even when it would be necessary
to bring all units stacked in the cell inside the incomplete base,
in order to make sufficient room.
Entries should be automatic and free.

K82. Add a uu_acp_for_pursuit to give a bonus if the victim is retreating.

K83. Implement acp_for_retreat.  For each direction away from the attacker,
see if (acp_for_retreat + acp) * speed > mp needed to enter cell.
Do for each dir, pick workable.  But first try to retreat into transports
if possible.

K86. Some occ types could protect by intensifying counterattack.

K87. Add a material cost um_material_per_<type> and prerequisite
um_material_to_<xxx> for all actions.

K88. Generalized notion of fire interdiction would be useful, could subsume
effects of jammers and suchlike, also if firing is used to represent
aircraft raids, need a way to define interceptors that can reduce
the effectiveness of the raid and the amount of aircraft material
available.

K89. To do < 1 cell/turn speeds, available acp should translate to
occasional ability to move.

K90. Define material-theft-per-contact(u1, u2, r) -> n in combat,
material-loss-per-hit(u1, u2, r) -> n which is material completely lost.
Some could be "resorbed" by terrain?

K91. Chance to surrender should be higher if damaged.

K92. A mobile unit should be considered surrounded or cornered if adjacent
cells are either impassable or occupied by unfriendlies.  Also look for
impassable borders and passable connections.

K93. Occupants of captured units might get to stay and not change side
if friendliness-to-enter allows it (?).

K94. Detonation's effects should depend on altitude of detonating unit -
compute the "actual" 3d distance.

K95. Define effects of altitude differences on all unit interactions.

K96. Damage to multi-part units could be done by detaching wrecked-type
instead of damaging all parts equally.  Do only if wrecked-type
has appropriate sizes.  Only applies if wrecked-type has equal num
parts to original type.

K97. Could do multi-cell move actions as repeat of hex entry until
anything happens that requires a decision - blockage, etc.
example: acp = 1, mp/acp = 10, allows single move of up to 10 hexes.

K98. If a side wins a battle, then side's units involved should gain affinity
for side, lose fear of other side.
On losing side, units lose affinity for own side and increase fear of
winning side.  Nonparticipants also affected, but less so.
Affinity increases by positive acts, fear increases by negative acts.
Betrayals should be detectable, have large effect.
Need some implicit agreements about defense of units on a side,
that players should not violate.

K99. Side action limit should be a distinct value, decremented only for "manual"
activity by player (first action after waiting for input?).

K100. Add a "coordination" action that adds other units to a unit's attack,
with multiplied effect.  Attack action has to look at each coordinating
unit, add effect if able to do so, and take away acp for coordinating
units also.

K101. For variable-commitment combat, attacker effectively sets m% commitment
for self, desires n% from defender.  Defender then chooses between n1-n2%
commitment, where limits set by unit types and m%.
Possible reactions also limited by commitment - defender could disengage
at <10% commitment, say, is otherwise stuck in the battle.
Reactions are counterattack, surrender, withdraw, do nothing special,
these are (mostly) indep of damage.

K102. Commitments default to zero.  If can be nonzero, create battle objects.

K103. If defender counterattacks, then might exchange attacker/defender
in battle, so now defender can decide commit/withdraw.

K105. Add loss of material as consequence of combat.
@deffn Table @code{theft-chance-per-attack??} u1 u2 -> n%
@end deffn
@deffn Table @code{stealable-material??} u m -> n
@end deffn
@deffn Table @code{loss-per-attack??} u1 u2 -> n%
@end deffn

K106. Add variable commitment and then constrain it:
@deffn Table @code{attack-commit-min??} u1 u2 -> n%
@end deffn
@deffn Table @code{defend-commit-min??} u1 u2 -> n%
These tables are the minimum limits on the initial commitment to a battle.
Defaults to @code{0}.
@end deffn
@deffn Table @code{attack-commit-max??} u1 u2 -> n%
@end deffn
@deffn Table @code{defend-commit-max??} u1 u2 -> n%
These tables are the maximum limits on the initial commitment to a battle.
Defaults to @code{100}.
@end deffn
@deffn Table @code{attack-commit-up-max??} u1 u2 -> n%
@end deffn
@deffn Table @code{defend-commit-up-max??} u1 u2 -> n%
@end deffn
@deffn Table @code{attack-commit-down-max??} u1 u2 -> n%
@end deffn
@deffn Table @code{defend-commit-down-max??} u1 u2 -> n%
These tables are the maximum limits on the change to commitment to a battle.
Defaults to @code{100}.
@end deffn

K107. cxp affects both attack and defense abilities, should define
uu_cxp_{attack,defend}_effect.

K108. Be able to control whether occupants can be attacked directly.

K109. [need general defns for who moves and when during combat rounds]
[could potentiall acquire additional acp if move is discretionary,
also get a level of flexibility about future commitment]

K110. [need combat's effect on tooling? uu_tp_hit_effect, can be positive
or negative (being hit helps recruiit soldiers)
just hit tp randomly as percentage of hp]

K111.
@c @deffn Table @code{cxp-hit-plus-max} u1 u2 -> n%
@c This table is the maximum hit modifier for attacker unit.
@c Defaults to @code{0}.
@c @end deffn
@c 
@c @deffn Table @code{cxp-hit-minus-max} u1 u2 -> n%
@c This table is the maximum hit modifier for defender unit.
@c Defaults to @code{0}.
@c The actual hit probability equals the basic hit probability, plus
@c @code{experience-hit-plus-max} times fractional experience (i.e.
@c experience divided by maximum experience) of the attacking unit, minus 
@c @code{experience-hit-minus-max} times fractional experience of the
@c defending unit.
@c @end deffn

K112.
DEF_VAR_I("actions-are-buffered", g_actions_buffered, set_g_actions_buffered,
	"",
	gactionsbuffered, 0, 0, 1)

K113.
@deffn GlobalVariable @code{actions-are-buffered} t/f
This variable is @code{true} if all the units of the same priority
must specify their actions first and then execute
them all at once,
rather than deciding and executing before the next unit gets to act.
Defaults to @code{false}.
@end deffn

K114.
DEF_UU_TABLE("material-cxp-effect", uu_material_cxp_effect,
	"effect of combat experience on material usage in combat",
	uumaterialcxp, constuumaterialcxp, 0, 100, 9999)
@deffn Table @code{material-cxp-effect} u1 u2 -> n
@end deffn

K115.
DEF_UU_TABLE("attack-elevation-effect", uu_attack_elev_effect,
	"",
	uuattackeleveff, constuuattackeleveff, 0, 100, 9999)
@deffn Table @code{attack-elevation-effect} n
Defaults to @code{100}.
@end deffn

K116.
DEF_UU_TABLE("friendly-hit-chance", uu_friend_hit,
	"base chance for a type of unit to hit a unit on a friendly side",
	uufriendhit, constuufriendhit, 0, 0, 100)
@deffn Table @code{friendly-hit-chance} u1 u2 -> n%
This table is the chance that a unit @var{u2} on the attacker's side will
be hit accidentally during an @code{overrun} or @code{fire-into}
action.
Defaults to @code{0}.
@end deffn

K117.
DEF_UU_TABLE("ambush-chance", uu_ambush,
	"chance that a unit will be able to attack by surprise",
	uuambush, constuuambush, 0, 0, 100)
@deffn Table @code{ambush-chance} u1 u2 -> n%
If @var{u1} attempts to move into a cell containing @var{u2},
then a) if can't co-occupy, this table is the chance that @var{u1}
gets a chance to attack at improved odds(?), or if b) if can
co-occupy, then @var{u1} will enter the cell, then be attacked
as in a).  The ambusher's plan can flag whether the unit
will take ambush opportunities or not.
@end deffn

K118.
DEF_UT_TABLE("mp-to-ascend", ut_mp_to_ascend,
	"mp needed to increase elevation or altitude",
	utmptoascend, constutmptoascend, -1, 0, 9999)
DEF_UT_TABLE("mp-to-descend", ut_mp_to_descend,
	"mp needed to reduce elevation or altitude",
	utmptodescend, constutmptodescend, -1, 0, 9999)
@deffn Table @code{mp-to-ascend} u t -> mp
@end deffn
@deffn Table @code{mp-to-descend} u t -> mp
These tables are the mp cost to go from the min possible elevation
to the max possible elevation in the world.
This is interpolated and rounded down.
@var{t} is the type of terrain being left.
Defaults to @code{0}.
@end deffn


K119.
@deffn Table @code{ablation} u1 u2 -> n%
This table is the amount of the hit that gets passed through
to the transport's occupants.
Defaults to @code{100}.
@end deffn
@deffn Table @code{stack-ablation} u1 u2 -> n%
@end deffn

K120. Add a way for elevation to screen out detonation effects.

K121. Interleave visual effects with detonation.

K122. Add screen and area flashes as types of movies.

K123. Define a "process" object:
(process <name>
  (agents <unit-type(s)>)
  (automated-rate n1)
  (manual-rate n2) ; + acp to do?
  (inputs <material-types>)
  (outputs ...)
  (catalysts ...)
  (terrain-effects ...)
  )
Process agent units are optional.
May want to add "tooling" of units to do a process.

K124. Add a type of random event where a side or group of units can change
to an active side all at once, reflects changing politics, requires
maintenance of reserves, etc.

K125. Add a min-hp-to-recover that is like hp-to-repair, but applies to
automatic hp recovery.

K126. Add ut_people_supply that is amount of supply gotten by unit if people in
cell are on the same side.

K127. Express need for limited supply as "n turns of supply before starvation"?
Can lead to tough decisions about starving rear areas for sake of major
offensives, etc.

K128. in-length > 0 + ability to transfer from terrain should mean that unit
can get supply from cells other than own cell.  Use to get water from
adjacent land in "voyages".

K129. Should choose side to revolt to by counting
number of units (of same type on each side?).

K130. Siege surrender chance should be distinct from normal surrender chance.

K131. Games should be able to define what size groups can be surrounded,
by radius or number of units.  Default to 1 cell areas.

K132. [need to identify motives for material demand, if type not needed
for actual survival - dyes needed for "art" for example -
might vary between sides/unit types?]
[would need to define generic elasticity of demands,
also the profit-seekingness of a population (vs conservatism, etc)]
[need some notion of credit too?]
[units can effectively forage at some distance, distinguish foraging
from actual production]
[price should go up as material is transported further and further,
and across varying difficulty of terrain...]
[note that as sides, players can't force cell economy but can
encourage it]
[perhaps allow a side to fix a price artificially, let everything
else readjust around it?]
Sides can specify their trading relationship with other sides,
by specifying the ratio of tariff to supply [etc].
[trade relationship is indep of general trust/friendliness]
[some type of agreements might be intrinsically enforceable, such as
exchanges between units that cannot attack or capture each other]
[exchange of material needs to relax fullness rules or be done as
a sort of prim, else might not be able to trade when full]

K133. Do supply lines, display unit's supplier and maybe supply route.
Is there an efficient way to handle this?

K134. To do large elev ranges, use bit 14 to indicate which range,
define a global that gives ratio of ranges.  Also need a descriptor
for text generation.

K135. Add possibility to see some/all of a side's units if one of them is captured.

K136. Weather needs pressure, humidity, calculates new values of these
and also has effects on visibility at multiple levels of atmosphere.
Need to identify effect of each terrain type (and elevation) on each
of these, also specify the rate at which changes occur.
Effects on supply.
Effect on vision, sensing in general.
Each utype has preferred weather, gradual falloff in effectiveness.
Add a generic "violence" value that summarizes wind/storm strength,
relate to unit behavior.
Impl via weather phenomena - overcast/clouds, rain/snow, storms/wind,
temperature, humidity (compute value of phenomena, then compute phenomena's
effect on units).
Attrition increased by storms, also chance of accidents (for each accident
type).
Could make some types of terrain temporarily impassable.
Display should show fronts, major storms.
Impl sequence should be fixed weather (weather state), random weather,
seasonal weather, calculated weather.

K137. Compute a daily temperature cycle based on number of daylight hours etc.

K138. @deffn UnitTypeProperty @code{weather-vision-range} dist
[should be a table so can't see a long ways off from within forest?]
@end deffn

K139. The primary effect of clouds is to make things harder to see,
can affect both units on ground (such as for fog) and in the air.

K140. @deffn UnitTypeProperty @code{vision-cloud-effect} xxx
@end deffn

K141. Be able to play back a recorded sequence of weather during a game.

K142. Distinguish "ideal" material level from "max" level, let
some percentage of material move towards comfortable areas.

K143. Scorekeeper can forbid the saving and restoring of a game, use in
nonsecure situations.

K144. Add a scorekeeper that looks at side view to decide whether player has
discovered something that is to be searched for.  Should be able to
require finding a lost city, etc.

K145. Add option to scorekeeper to run on success/failure of an action
matching given parameters, plus option to run on occurrence of a specified
events, otherwise scorekeeper runs at either beginning or end of turn.
Matching includes side and unit.

K146. Add formal notion of money as a type of material that is global to a side,
has no physical repn.  Materials such as gold can have a monetary value.
Sides can force exchange rates or let float.

K147. Add a "plague" random event/process that randomly spreads and moves around,
use for fires, plagues, floods, etc.
Could track state/progress by material layer or a "severity" layer.
Perhaps use coating terrain for this?

K148. Add random cloud modification process, include random storm generation.

K149.
DEF_TM_TABLE("supply-move-rate", tm_supply_move_rate,
	"",
	tmsupplymove, consttmsupplymove, 0, 0, 0)
@deffn Table @code{supply-move-rate} t m -> n
This table says how much of material @var{m}
can be moved through terrain @var{t}
(cell, border, or connection) in each material transfer action.
The actual limit is the minimum of all cells and borders
along the supply route.
A value of @var{-1} allows any quantity to go through.
@end deffn

K150.
DEF_UM_TABLE("supply-interdiction", um_interdiction,
	"",
	uminterdiction, constuminterdiction, 0, 0, 9999)
@deffn Table @code{supply-interdiction} u m -> n%
This table is the reduction of supply due
to the presence of an enemy unit of the
given type on the supply line.
A value of @code{100} means that the unit has no effect on supply movement,
a value of @code{0} means that the supply line is completely cut.
Defaults to @code{0}.
@end deffn

K151.
DEF_UU_TABLE("spy-see-always-chance", uu_spy_see_always,
	"",
	uuspyseealways, constuuspyseealways, 0, 0, 100)
@deffn Table @code{spy-see-always-chance} u1 u2 -> n%
This table is the chance that if @var{u1}'s spies return information
about a unit of type @var{u2}, then that unit will always be
visible thereafter, as if it were @code{see-always}.
The compromised unit and its side will not be aware that
this has happened.
Defaults to @code{0}.
@end deffn

K152.
@deffn UnitTypeProperty @code{spot-movement} t/f
If this property is @code{true},
then the unit's chance to be seen by other sides will be
tested each time the unit moves.
@code{spot-action} implies @code{spot-movement}.
Defaults to @code{true}.
@end deffn

K153.
@deffn UnitTypeProperty @code{spot-combat} t/f
If this property is @code{true},
then the unit's chance to be seen by other sides will be
tested each time the unit engages in combat.
@code{spot-action} implies @code{spot-combat}.
Defaults to @code{true}.
@end deffn

K154.
@deffn Table @code{see-combat-chance} u1 u2 -> n%
This table is the basic chance to see a unit of type @var{u1} when
in combat with a unit of type @var{u2}.
The location of @var{u1} must be covered by some unit on the viewing side.
This is evaluated for each combat action within a turn.
Defaults to @code{100}.
@end deffn

K155. Add to move task to distinguish between "move and enter" and "move in open".

K156. In some circumstances (which?), allow plan-tweaking commands to
create and fill in the plan for an incomplete unit.

K157. Add an ability to store and act on dated future plans and goals.
Need to be able to evaluate preconditions for plan, so can do only
if makes sense.

K158. Doctrine and unit plans should include rules about when units should
attack automatically.  Should be careful or will lose units to foolish
actions.

K159. Attack tasks should go after damageable units,
if less than perfect protection, damageable visible occupants.

K161. Defense plan should identify what is defended, and what are the threats.
If no threats, unit just tries to stay healthy.
Defender's search for threats should cover a radius computed from
defender's and ward's positions, areas covered by view, speed of threats
(need to see bombers *before* they reach cities, can attack and retire
before anybody can react).
Threats can be recognized directly, or gotten from AI's list of threats.
A unit is a threat if
1) it can capture or damage the ward
2) it can cut the ward off from supply or other defenders
3) it can hurt the defender
To respond to a chosen threat, can 1) attack the threat, 2) interpose,
3) move the ward, either on own or by carrying.

K163. "Intercept/defensive" plan directs units to patrol in an area, attacks any
enemy unit (doctrine defines "enemy") that is of a type that can be
attacked/harassed/blocked (ignore types that we can't do anything about!)
Only some kinds of defensive units are interceptors, others are blockers
or kept in reserve.  Blockers interpose rather than attack enemies,
while reserves avoid contact until plan is changed.  Defn of "reserve"
partly depends on attacker, so fighters intercept bombers but ignore
battleships.
Do as explicit decision in general defense plan.

K164. Re-evaluate return if transport moving away too fast.
Calc distance, record as task parameter, check on next
execution of task.  Add AI hook to allow for making transport move
slower or rendezvous with unit needing supplies.
Could have a "home" unit that is preferred if in range, such as
fighters assigned to carriers.  Don't return to transports that
don't have any fuel, unless there is no other choice; check on
each task execution. Special-case
grounding of aircraft if no supply in a base vs starvation of troops
if no food in a base.

K165. Exploration plan should set recon vs invasion type, use to decide
about visibility while exploring.  Recon should attempt to gather
knowledge without being seen.

K166. If can refuel along a route if chosen correctly, subdivide move task
so as to stop at refuel points.

K167. Define a plan type that tracks/shadows units while staying out of sight
as much as possible.  Would have to keep unit within view range but outside
of its view range (and any other coverage, should write something to see
whether a given cell might be visible to enemy), but may have to get
closer to avoid losing trackee.  If unit being tracked seems about to
do some damage, engage instead of shadowing.  May sometimes want to
move to block or slow down trackee's escape.

K169. Plans that fail to decide what to do are a potential problem, should
eventually be replaced, but not too often or else warn about replacement.
Track total usages as well as per-turn usage.
Each successive plan for a unit should have a distinct serial number,
display when displaying plan.  (units never share plans)

K170. All units should get a chance to replan after acp/mp calculated
but before anybody moves.  Should be fast, since nobody can move
while this is happening.
(Interface should be more obvious about this, so less confusion
about turn change.)
Give human players a chance to review plans made by high-initiative units
before irreversibly made (flag review-plans, shows plans of units that
are selected).

K171. What about a task to not just resupply but to prepare for a long trip?
Stock enough to make a crossing, etc.
Check when doing an approach task, may want to push a "fillup" task.

K172. Add notion of "supporting" another unit to doctrine, then unit could wake
up and get involved automatically if combat nearby.
Should specify by type & distance, as well as particular unit.

K173. Do general org chart mechanism, as combined plan/task/AI machinery (formal
limits on action expressed as unit control properties/tables).
Allow promoting any (or restricted type?) unit to be a commander, and
assignment of units to commanders.
Units can have orders to follow cmdr, cmdrs could have utype requisitions
so production automatically goes to them.
(Machine player could use this too.)
Add a display to show how everything relates.
Define a commander_decide_plan(cmdr, unit) or have cmdr make tasks directly?
Each commander should have (or appoint) a deputy unit that will get its
plan data if it dies.  If deputy dies, should work down through orgchart
to find anyone, only giving up if entire group is gone.
"Commander" plan is mod of other plan types, cmdr bit is for coordination.
Cmdr plan includes an "ideal" mix of types to command.
AI uses to set production, human gets told of cmdr unit's needs somehow.

K174. If no AI or display on a side, what should units do?
Will still have doctrine, attitudes, loyalties, so plenty to work from
Can have and execute plans, combination of game, game design, doctrine
chooses plans.

K175. Should be able to set a "build rate" that is slower than "fast as possible",
to avoid material depletion.  (i.e. use doctrine to set default rate of
build actions, set actual rate in build task?)
Define as amt of time to wait before starting build of next type (if the same).

K176. Define a "meet" task where transport and occ (or whatever pair
or group) converge on a mutually acceptable place.  Track progress,
give up if not getting closer.

K177. If hit/capture task fails because target has disappeared, offensive plan
should search vicinity of target location for units of matching type.
(But might be better to let generic task planning take over instead.)

K178. Goal to move to an area should be satisfied by moving to nearest spot,
instead of a random point inside.

K179. Add an "engineering" plan type, with subtypes "make-access" and "block-access".
Engineering units build access routes
by adding/removing/modifying terrain, or by building units that serve
only as bridges.  Should be able to build multi-cell/unit chains in
difficult cases.  Examples: could bridge one blocking cell by a) building
a transport unit that ferries, or b) building two connections.  Could
bridge a single blocking border by building a connection or by removing
border.  Want to do this for any cell that is very expensive to cross.
To implement, plan should look for cheapest route assuming that blockage
has been negated, then build bridges for that route.
Engineers should also know how to build roads, do that if road movement
is much faster (such as doubled) than normal movement.

K180.
Possibly useful doctrine slots:    
    short tasklimit;		/* max length of task queues */
    int respectneutrality;	/* attack neutrals automatically? */
    int trustallies;		/* rely on allies for transport etc? */
    short moverandomness;
    int movestraight;		/* try to move in a straight line? */
    short backtrackinglimit;	/* how far backwards to look for route */
    int unitseveraskside;
    int usemachinestrategy;	/* like setting humanp */
    int wakeintransport;	/* be awake while in transport? */
    int avoidbadterrain;	/* avoid dangerous/unproductive terrain? */
    /* need something generic for event wakeup */
    int lowsupplyreturn;	/* return to base if supplies low? */
    short supplyspare;		/* how close to cut low supplies */
    int repairreturn;		/* return to base for repairs if damaged? */
    int lowammoretreat;		/* run away if ammo is low? */
    int lowammoreturn;		/* return to base if ammo is low? */
    short generosity;		/* how much supply to share with others */
    int expendable;		/* OK to risk destruction in combat? */
    short rearm;
    short repair;
    short resupply;
    short ifnearbycombat;
    short ifnearby[MAXUTYPES];	/* how to react to utype nearby */
    short aggressiveness;	/* general aggressiveness */
    short wakeupinterval;
    short replaninterval;	/* how often to recompute plans */
    short exploreimportance;	/* priority of exploration */
    int exploreedges;		/* explore by going around edges? */
    int buildalways;
    /* something for move order? */
    short maxsubordinates;	/* general limit on number of subords */
    short maxsubordtypes[MAXUTYPES];  /* per-type limit on subords */
	  case K_TASK_LIMIT:
	    side->tasklimit = numval;
	    break;
	  case K_RESPECT_NEUTRALITY:
	    side->respectneutrality = numval;
	    break;
	  case K_AVOID_BAD_TERRAIN:
	    doctrine->avoidbadterrain = numval;
	    break;
	  case K_REARM_PERCENT:
	    doctrine->rearm= numval;
	    break;
	  case K_REPAIR_PERCENT:
	    doctrine->repair = numval;
	    break;
	  case K_RESUPPLY_PERCENT:
	    doctrine->resupply = numval;
	    break;
DEF_KWD("task-limit", K_TASK_LIMIT, 1)
DEF_KWD("respect-neutrality", K_RESPECT_NEUTRALITY, 1)
DEF_KWD("avoid-bad-terrain", K_AVOID_BAD_TERRAIN, 0)
DEF_KWD("repair-at", K_REPAIR_PERCENT, 0)
DEF_KWD("resupply-at", K_RESUPPLY_PERCENT, 0)
DEF_KWD("rearm-at", K_REARM_PERCENT, 0)

K181. Fix AI so that it obeys real-time limits, and so that if acting as
assistant, timeout isn't ended prematurely.

K183. Add ability to have future goals, ultimately be able to script much
behavior.

K184. Hit worth should be the general payoff of one-on-one combat.
First test if combat possible.
bhw = 0 means breakeven.
bhw > 0 means always advantageous, < 0 disadvantageous.
Should account for construction and fuel costs? (is "Strategic worth")
In practice, tactical needs will outweigh the risks involved in fighting
when bhw < 0.
Also account for ability to escape, so less risk?

K185. Need better weighting of hit prob vs death prob, also relate to goals,
so unit with low hit prob will still attack another unit if it can win
the game by doing so.  (implies we need to evaluate importance of goals,
nearness to achieving them)

K186. Add a player slot that can be used to set explicit AI goals, would
take precedence over computed goals.

K187. Get goals from a hash table instead of creating anew each time.
Parameters of goal will be read-only.
get_goal(type, p1, ...)
change_goal(goal, newtype, newp1, ...)

K189. Write a stdplay.c that is only applicable if game is similar to standard
game (examine set of types, but still need to doublecheck numbers).

K190. Define some sort of generic ai-to-interface display.

K191. Period converter should add a default favored-terrain = 0.

K192. Implement Massimo's proposal for morale and feelings:

@section Morale and feelings

@subsection Notes

[@code{feelings} and @code{morale} should be kept orthogonal to
@code{cxp} and acp-debt.]

@code{feelings} (towards each side) are ``affinities''; they can be used
to implement ``loyalty'', ``fear'', etc.

@code{morale} is a sort of ``self-feeling''; it can implement
``heroism'', ``honor'', etc.

@code{feelings} and @code{morale} can also be used to model ``magic
spells'', ``bribes'', ``leadership'', etc.

[remove @code{attitudes-max}, have a feeling towards each side.]

[I think that the following ``status'', ``effects'', and ``charm'' parts
are reasonable; the ``change'' parts are very cumbersome, but I couldn't
come out with something better.]

@subsection Status

@deffn UnitProperty @code{feelings} side-value-list@dots{}
The unit's true feelings towards each side,
including its own side.
Defaults to @code{0} for each side.
@end deffn

@deffn UnitProperty @code{morale} fp
The unit's true morale.
Defaults to @code{0}.
@end deffn

@deffn UnitTypeProperty @code{feeling-max} fp
Sets the range for @code{feelings} and @code{morale} from
@code{-feeling-max} to @code{+feeling-max}. 
Defaults to @code{0}, which disables @code{feelings} and @code{morale}.
@end deffn

@subsection Morale effects

All the following modifier add to the given quantity; they are
proportional to @code{morale} and are given at @code{feeling-max}
(i.e., they are multiplied by @code{morale}/@code{feeling-max} first).
They all default to @code{0}.

@deffn Table @code{surrender-chance-morale-modifier} u1 u2 -> n%
[use for sieges?]
@end deffn

@deffn Table @code{base-production-modifier} u m -> n
@end deffn

@deffn UnitTypeProperty @code{acp-per-turn-modifier} acp
@end deffn

@deffn UnitTypeProperty @code{disband-chance-modifier} n%
@end deffn

@code{disband-chance-modifier} requires of course the introduction of
@deffn UnitTypeProperty @code{disband-chance} n%
This is the chance for the unit to disband spontaneously.
Defaults to @code{0}.
@end deffn
Example: setting @code{disband-chance} to @code{0} and
@code{disband-chance-modifier} negative can model samurais: when morale
becomes negative (their honor is spoiled), they have a chance of
disbanding (with @code{disband-message} @code{"commits seppuku"}).

@subsection Feelings effects

All the following modifier add to the given quantity; they are
proportional to @code{feelings} towards the ``other unit's side'' (which
may often be the ``unit's own side'') and are given at @code{feeling-max}.
They all default to @code{0}.

@deffn Table @code{surrender-chance-feeling-modifier} u1 u2 -> n
[use for sieges?]
@end deffn

@deffn Table @code{capture-chance-modifier} u1 u2 -> n
@end deffn

@deffn Table @code{withdraw-chance-modifier} u1 u2 -> n
@end deffn

@deffn Table @code{control-chance-modifier} u1 u2 -> n
@end deffn

@deffn UnitTypeProperty @code{revolt-chance-modifier} n%
(proportional to @code{feelings} towards the ``unit's own side'').
@end deffn

@subsection Morale at creation

Builders may ``transfer'' their morale/feelings to created units.


@deffn Table @code{creation-feelings} u1 u2 -> n
Newly created units start with @code{feelings} equal to n/100 of
creator's @code{feelings}. Defaults to @code{0}.
@end deffn

@deffn Table @code{creation-morale} u1 u2 -> n
Newly created units start with @code{morale} equal to n/100 of creator's
@code{morale}. Defaults to @code{0}.
@end deffn

@subsection Morale changes

They all add to the unit's @code{morale}.
They all default to @code{0}.

@deffn Table @code{terrain-morale} u t -> fp
fp is added after each turn to the @code{morale} of u sitting in t.
Models (dis)-comfort of unit in given terrain.
@end deffn

@deffn UnitTypeProperty @code{acp-low-point} acp
@end deffn
@deffn UnitTypeProperty @code{acp-low-morale} fp
@end deffn
@deffn UnitTypeProperty @code{acp-high-point} acp
@end deffn
@deffn UnitTypeProperty @code{acp-high-morale} fp 
If u is left with less then @code{acp-low-point} acp at the end of a
turn, @code{acp-low-morale} is added to its @code{morale}.
If u is left with more then @code{acp-high-point} acp at the end of a
turn, @code{acp-high-morale} is added to its @code{morale}.

They model fatigue/rest effects.
@end deffn

@deffn Table @code{mp-low-point} u m -> mp
@end deffn
@deffn Table @code{mp-low-morale} u m -> fp
@end deffn
@deffn Table @code{mp-high-point} u m -> mp
@end deffn
@deffn Table @code{mp-high-morale} u m -> fp 
If u is left with less then @code{mp-low-point} of m at the end of a
turn, @code{mp-low-morale} is added to its @code{morale}.
If u is left with more then @code{mp-high-point} of m at the end of a
turn, @code{mp-high-morale} is added to its @code{morale}.

They model starvation/abundance effects. [use for sieges? m is
@code{"food"}]
@end deffn

@subsection Feelings changes
They all add to the unit's @code{feelings} towards the ``other unit's
side''.  They all default to @code{0}.

@deffn Table @code{transport-feelings} u1 u2 -> fp
fp is added after each turn to the @code{feelings} of u1, enjoing the
ride or the vacation in u2 (which can be a ``resort hotel'').
@end deffn

@deffn Table @code{material-transfer-feelings} u m -> fp
fp is added (for each mp transferred) to the @code{feelings} towards the
side transferring the material m to u.
Models pay, bribes ... (m is often @code{"gold"}).
@end deffn

@subsection Morale and feelings changes

They add to the unit's @code{morale}, to @code{feelings} towards the
``unit's own side'', or to  @code{feelings} towards the ``other unit's
side'', according to their keyword.  They all default to @code{0}.


@deffn Table @code{win-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{win-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{win-other-feeling} u1 u2 -> fp
They are applied when u1 destroys u2.
@end deffn

@deffn Table @code{hit-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{hit-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{hit-other-feeling} u1 u2 -> fp
They are applied when u1 hits u2.
@end deffn

@deffn Table @code{wound-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{wound-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{wound-other-feeling} u1 u2 -> fp
They are applied when u1 is hit by u2.
@end deffn

@deffn Table @code{see-enemy-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{see-enemy-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{see-enemy-other-feeling} u1 u2 -> fp
They are applied when u1 sees a hostile unit of type u2.
@end deffn

@deffn Table @code{see-friend-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{see-friend-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{see-friend-other-feeling} u1 u2 -> fp
They are applied when u1 sees a friendly unit of type u2.

@code{see-enemy} and @code{see-friend} can be used to implement
specialized morale/feeling (anti-)boosters: secret police, preachers,
leaders, dragons, nazguls...
@end deffn

@deffn Table @code{capture-morale} u1 u2 -> fp
@end deffn
@deffn Table @code{capture-own-feeling} u1 u2 -> fp
@end deffn
@deffn Table @code{capture-other-feeling} u1 u2 -> fp
They are applied when u1 is captured by u2.
@end deffn

@deffn UnitTypeProperty @code{change-side-morale} fp
@end deffn
@deffn UnitTypeProperty @code{change-side-own-feeling} fp 
@end deffn
@deffn UnitTypeProperty @code{change-side-other-feeling} fp
They are applied when u changes side (own is the ``old'' side, ``other''
the new side).
@end deffn

@deffn UnitTypeProperty @code{revolt-morale} fp
@end deffn
@deffn UnitTypeProperty @code{revolt-own-feeling} fp 
They are applied when u revolts.
@end deffn

@subsection Charm

This action can model magic spells, terrorism, psychological weapons,
propaganda, bribes, etc.

@deffn ActionType @code{charm} unit
This is the action that a unit performs to modify the @code{morale} and
@code{feelings} of another unit.  The unit must be visible and within
@code{charm-range} to be charmed. 
@end deffn

@deffn UnitTypeProperty @code{charm-range} dist 
Defaults to @code{1}.
@end deffn

@deffn Table @code{charm-friend-chance} u1 u2 -> n% 
The chance of charming a friendly unit.
Defaults to @code{0}.
@end deffn
@deffn Table @code{charm-enemy-chance} u1 u2 -> n%
The chance of charming a hostile unit.
Defaults to @code{0}.
@end deffn

@deffn Table @code{acp-to-charm} u1 u2 -> acp
This is the number of acp a unit uses to do one charm action.
Defaults to @code{1}.
@end deffn
@deffn Table @code{charm-consumption} u1 m -> mp
This is the amount
of u1's supply used up in one charm action.
m is usually something like @code{"mana"} or @code{"gold"}.
Defaults to @code{0}.
@end deffn

@deffn Table @code{charm-morale} u1 u2 -> fp
Added to u2's @code{morale} if charm is successful.
Defaults to @code{0}.
@end deffn
@deffn Table @code{charm-own-feeling} u1 u2 -> fp
Added to u2's @code{feelings} towards its side if charm is successful.
Defaults to @code{0}.
@end deffn
@deffn Table @code{charm-other-feeling} u1 u2 -> fp
Added to u2's @code{feelings} towards u1's side if charm is successful.
Defaults to @code{0}.
@end deffn

@subsection Relaxation

@deffn UnitTypeProperty @code{morale-relaxation} n
@end deffn
@deffn UnitTypeProperty @code{own-feelings-relaxation} n
(for the unit's own side)
@end deffn
@deffn UnitTypeProperty @code{other-feelings-relaxation} n 
(for all the other sides)

They default to @code{100}.
@end deffn

At the and of each turn, the old values of @code{feelings} and
@code{morale} are multiplied by (the appropriate) n/100; then all the
previous modifiers are added; the result is rounded to an integer in the
usual (stochastic) way to obtain the new @code{feelings} and
@code{morale}.

@subsection Missing

@code{revolt-chance} modifier for occupants (and nearby units).  Then,
using with @code{revolt-chance-modifier} and assuming that a
newly-captured unit retains a ``bad'' feeling towards the old enemy, you
will have to guard a newly-captured unit (with your ``secret police''?)
until its feeling towards you improves.

Effects of side behavior: d.o.w. or breaking a treatise should modify
feelings of (certain) units.

Effects of weather.
(end of proposal)

K193. Add a help node with properties of world (day/night for instance), install just
before unit type nodes.

K194. Kernel should be able to do a system reset - all data structures
and all allocation, so that a different game can be started up.

K195. Write goals as separate forms, make xrefs to them.

K197. Use obstacks for building up help text.

K198. Only cache a limited number of help node texts, flush oldest when limit reached.

K199. If unit being read-in is at a location where it would vanish, but there is a
transport in that cell that will not vanish there, put the unit on the transport.

K205. Add a way to make captured units disappear from game automatically.

K207. Fix details of roundup/down calculation for movement points.

K209. Add a way for occupants to escape destruction of a transport as well
as its capture.

K211. Include values such as @code{enforced} and @code{publicity} for agreements?

K212. Add symbols for agreement states.

K213. Implement scorekeeper messages (or eliminate property).

K214. self-required should also have a related side property?
[rounding-down advantage should not eliminate one needed as self-unit?]

K215. Allow a null unit to transfer-action to be act of discarding material?

K216. [effects of coating should be increased attrition, decreased
productivity, decreased activity and mobility]

K217. Make temperature-year-cycle an area property.

K218. Add some way to specify which side a unit in revolt goes over to.
What if the side didn't want the unit?

K219. In statistics, record and report fates of incomplete units separately.

K220. Add fire consumption and material requirement different from generic
attack requirements.

K221. For each scorekeeper, add an internal flag that saves applicability
of scorekeeper, also calc for current turn - if changed, then AI
analysis code should re-run.

K222. Be able to save individual properties along with ids to match with units.

K223. Add option to save a map rotated, at least by 60-deg increments.
60 left, 1st hextant formula is y' = x + y, x' = -y, etc.

K224. Write dice specs as dice specs, not large numbers.
Must record for each table/property that number *is* a dice spec or what.

K226. Implement unit layer for large worlds using some sort of tree search
to find unit at x,y and not allocating unit layer at all.

K227. unit_desig should format typename into minimum space, determined dynamically.
Assign chars, if defined, as shortest names, then add longer names to
uniquify names after the first using a particular char.

K228. Collect/write stats on each call to run_game - # unit scanned, # acted,
# actions, # plan executions.  Also classify by type and side.

K230. Add a way to send/broadcast messages anonymously.

K231. Extend "bridge" table to distinguish from/to terrain, and to apply to
assaults as well as captures.  Come up with a new name for it.

K232. Further compress layers by including info about # bits (1,8,16)
and recording several values as bitfields in a single char.

K233. Define zz-s-u-n as cache for shortest name (down to 1 char if possible,
but confusing if only some have one-char names, others are all-but-one
char of name, etc)

K234. Define a can_occupy_without(...,exclunit) that indicates room if given other
unit is *not* counted (since it will be removed shortly, for instance)

K235. For all units on a side, keep sorted by type, keep ptrs to start of each
type, use to index faster.  Could even maintain separate chains for each type.
Define a for_all_side_units_of_type(side,type,unitvar) iterator.

K236. Optimize mapping side and unit ids back to objects themselves.  Use hash
table for units (hash on low bits of id), direct table for sides.

K237. Add option to "add" form to modify layers in area, a la
(add area <layer> x,y[,w,h] <xform>), where <xform> could be to add or subtract,
or a conditional such as (if mountains then ice).

K238.
Klast.

--Mplayer AI

M1. If game win is to own a particular type of unit, then set goal to own
one.  If can build, then start building and defend builder.  If unit
known to exist (how?), set goals to find and to capture.  If unit is
mobile, or if might be carried by mobile unit, set up a search pattern, and ?

M3. To do patrolling/picketing, space units so that few or no holes in coverage.
In theater being covered, check view dates and send units to update oldest
information - should be closest unit or one assigned to cover.  Could therefore
have a patrolling unit that only moves very little since its view range covers
nearly entire assigned area.  Allowable age of views depends on what sort of
surveillance is avail, how many units are assigned.

M4. Derive acceptable risks from goals - unit that is crucial to game should not
risk self, disposable types can be sacrificed.

M5. Construction calculations should prefer multi-purpose units, but randomize if
values close together.  (Test by making game variants with ultra-powerful
units, should see mplayer shift to building all the time.)
Each goal should be characterized timewise, so mplayer can start builds and
have units ready when goal becomes relevant.

M6. For each type of goal in game, decide which units help accomplish and how
well, which units support indirectly, etc.  Also classify by short/long term
value - short-term is 5-10 turns or 1/10 of game, long-term is length of game.

M7. When exploring world,
use knowledge of country size to optimize search, by spacing out explorers,
not filling in details of terrain until later (is diff, low-priority goal,
maybe subsumed by patrolling).

M8. Prefer to hit or capture transports, especially if easier way to bag
or destroy the occupants.

M9. Keep a persistent layer of "sightings" (or linked list if can be short),
record into when nonempty cell in view array is about to be cleared
during a turn (need hook from vision code).  Date sightings, clear
periodically.

M10. Need a way to estimate units hidden in transports, so can freak out
over approaching transports.

M11. Compute desired number of depot types by calculating the spacing
between necessary to ensure that each can supply another.

M12. If only one builder available, should "timeshare" it properly.
Plan should track what has been produced, reduce preferences as more and
more of a type gets built.
Test with old-empire.

M13. Add heuristics to try to build bases at key or useful locations.

M14. If scorekeeper body says something about testing possession on a given
turn, then make occupation a goal from the start.
If occupation goal unsatisfied, assign units to occupy, give each
the same goal, should also attempt to clear the area.
If satisfied, assign unit to defend the area (need to write "how
to defend" code?), possibly patrol around if everything not always
visible.

M16. If contacted more than one side, choose a side to concentrate on
(closest most likely), act defensively against other sides (but
still take opportunities).  May need to change emphasis if another
side turns out to be most threatening (tell this by tracking apparent
success w.r.t. each side).

M17. Shift from offensive to exploration if everybody disappears.
Track max # of enemy ever seen and on which turn(s).
Should be persistent in covering area near last spotting of units.

M16. When a unit executes its plan, routines like find_target()
either get a value from AI or search around (implicit "nobrains" AI?).
(AI should have prioritized list of targets composed already and
sorted by theater and goal etc.)

M19. If parts of world view not necessarily up-to-date, need to do pickets
or patrols to guarantee as much coverage as possible. (use view dates)

M20. If moderate-to-high chance of capture by unit surround, put units in
lines and other formations that can't be surrounded easily.

M21. A side should act primarily defensively if it satisfies a goal,
but the game is not over and another side could take away.

M22. Guess at likely theater for contacts, carve out of existing theaters,
reassign/replan *all* units.

M23. Track contacts with other sides on a per-theater basis.

M24. Mplayer should compute which types are mostly likely to be in play
at present, and at future times.  Can look at initial setup, construction
times, etc, and ignore types that can't possibly appear.

M25. Mplayer should attempt to compute numbers of units and material needed
to achieve a goal, to some level of confidence, then set "buildup" plans -
some units explore/patrol etc, then when buildup finished, should plan
large-scale attack, from several directions if possible.  Reserve units
should hang around transports, but not sit on them unless transport protected.

M26. Use people sides to adjust theather boundaries sometimes. (how?)

M27. If chance to surrender by siege > 5%, compute an ideal frontage, minimizes
chance of units getting isolated.

M28. Could do formations by reshaping theaters.  Units mass on edge, don't go past
until mplayer directs an offensive.  If offensive successful, mplayer adds gains to
theater.

M29. If returning to a moving transport, and transport destination is further away,
push a "wait" or "rendezvous" task onto transport's queue.
Rendezvous task should estimate time of expected rendezvous, fail only
if actual time is 1 1/2 longer than expected time.

M31. For each theater, distinguish
recent vs older sightings, with exponential backoff (1-2 turns ago,
3-5, 6-10, 11-20, etc).

M32. AI should have a chance_to_own_one_of_type(side, side2, u) that the side's
current estimate of the likelihood of the given side2 owning at least one
unit of the given type.

M33. Need special code to know how to defend bridgeheads, recent captures,
etc.  Reduce theater size or focus on immediate vicinity.  Own units
in "enemy" theater (define) should be defended against the most
immediate threats.  Look around for threats or potential threats.
Assign best units to deal with threats.

M34. Have machine player compute general dependency chains for its strategy.
For instance, "need miners to produce uranium from mountains
to build nukes to attack cities".
Should be "lazily" computed, as needed to achieve basic goals.
Strategy code works by calculating a plan that consists of steps
to reach the goals.  Plan is sufficiently detailed when side can
tell each unit what to do, or doctrine has the same effect.
Not always totally deterministic, how does this work?

M35. Unit type analysis should be based on average outcome, plus worst/best-case
outcomes if not maybe not expecting enough action to let things average out.

M36. To estimate materials, scan world, for each unit image, add survival
needs to min est, stockpile - avg operating costs to likely est,
total storage capacity to max est.  Can use actuals for own and allies.
Similar for terrain and population.

M37. Unit first spotting human enemy should disappear as quickly
as possible, might escape before human notices. (exploratory plan only)
Purely exploratory/recon units should generally avoid combat, try to escape
and stay hidden if possible.

M39. To decide when to make bases, do if can create supply, can xfer from
further than units can, can protect units in or near base.

M40. Do base construction as 1) moving to construction site, 2) building, and
3) carrying to final site.  (Must verify that base or parts of base can
be carried.)

M41. When exploring and switching theaters, shift both to inner and outer
theater (actually an abutting theater of any sort).

M42. When enemy unit spotted in a zone, decide if unit is part of larger
group (like a country), what kinds of units might be present (similar,
sessile, etc).
If unit is isolated, decide if it is a threat in any way, if so, make
a goal "enemy gone from x,y" and assign units to work on this goal,
with types and numbers sufficient to the job.  Can borrow from nearby
theater if not too time-consuming.
If group, decide importance (home country being most important),
also assign # units, maybe make theater, track strengths, # units
enroute, and # still needed.
Distinguish units that are dangerous alone and ones that are carriers.
An army that is 2 cells away from capturing a self-unit should have
a maximal threat, since loss of game is certain if threat not counteracted.

M43. Machine player should attempt to infer other sides' strategies.
side->strategy->other_side_analysis[nsides]
If no player on other side, record that other side will not do
anything (and go after to build territory).
If has a display, record as "more dangerous", use as a reason to
ally with other AIs in game.
Sides with displays should also be considered "more unpredictable".
If AIs ally, should be temporary, since game won't end even if all
are allied.

M44. Define an "importance" of activities that gets divvied up among
subcommanders, so overall plans can be set aside temporarily while
individuals deal with immediate threats.

M45. Mplayer code should look for "choke points" that are standard
routes between important places and around obstacles.  Calculate from
world and utypes, share among all machines (don't use if haven't seen
yet!).

M46. Add code to negotiate for neutrality/ally status.

M47. Mplayer should prefer goals with fewest dependencies (prereqs) and
quickest time to completion.  Prereqs mean conditions that must be
true before main goal is worthwhile attempting, but are not formal
requirements - goals are intrinsically self-contained.

M48. Scorekeeper analysis:
if keeping score
  make overall goal to win
  call make_subgoals
else amuse self by being random
if goal is to win
  for each scorekeeper
    if last-side-wins, ... (already done)
	else scan body looking for if's and do's
	(might be too complicated, should announce the fact as a warning
	"too complicated for me, don't know how to play" and drop
	back to simpler if mistaken goals) (or resign?)
	if body is "(if <test> win/lose)"
	  make the satisfaction of the test a goal
if goal is to make a side lose
  if can be accomplished by eliminating a side's nonzero-value units,
  set goals to destroy/capture each type
  if not all visible, set goal to find units
    if type can move, goal is to keep info about world up-to-date;
	  no random walking, always move to update oldest spots (but
	  only in terrain where units could be)
	if type can't move, goal is to have examined all possible
	  terrain.

M50. Designer should be able to toggle flags for mplayer,
force reevaluation etc.

M51. Come up with a way to prove that mplayer doesn't cheat by looking
at structs?  Could add a "sneaker" unit to some game that is always invisible,
would never be noticed or attacked unless mplayer cheats.

M52. If in a multiplayer game, one side is becoming much stronger, ally with
other weaker sides.

M53.
Mlast.

--Interface

I1. Add mechanism to display pictures in the background of a map, instead of
terrain cells/bords/conns.

I3. When game ends, see-all should become true for all displays, redraw
all maps automatically.
Interfaces should better declare when the game has been ended
arbitrarily (such as by running out of turns).

I4. Come up with a way for update_unit_display to not redraw cell until
all units in cell updated.

I5. Add help node for instructions. (but don't include instructions not
known to all sides).

I6. Allow typing prefix arg as prefix (or suffix ?) to long commands.

I7. Add way for player to declare if AI is assisting by default, or in
charge by default.  AI decision about whether to end a turn should
also be controllable.  Similarly for resignation.

I9. Add idle-timeout, default to 60 secs.  If no player action, and all other
players finished turn, do a finish_turn.

I10. Add a tabular form displaying side relationships (trust, willing to draw, etc).

I11. Add a way to get explanations of action and task failures, needed to
explain non-functioning in game designs.

I12. If gdl command is done, all help nodes should be invalidated.
Similarly for many internal arrays (bleah).

I13. Distinguish two kinds of "go to next" consistently - unit that would normally
be queried about next (if current unit not moved so as to require scrolling),
ignore current unit until all others on side have moved.

I14. Autoscrolling should always position so that each adjacent cell to a unit
also shows *entire* adjacent cells, all around.

I15. Lists of units should also be able to display glimpses, just omit data
that is not available (what about names? might be tough to save names
with glimpses)

I16. Need some sort of default grammar used when game designs don't want
to add anything special.
Copy ^0, ... concept for format strings generated by grammars.
Use grammar idea for narrative generation.
Do for actions, notable backdrop events, summaries.
(text disband-narrative
  (self infantry (actor "goes home"))
  (u* bomb (actor "dismantles" actee))
  )
Match on action args to choose sentence, allow multiple weighted choices
for variety, be able to tailor for each side.
Should be able to do both present and past tense generation.
Routine is describe_thing(side(s), generator, parms[10]).
(Would be generally useful to have a side-to-bit-vector conversion routine...)
"Narrative" different from "message", is past sense, while "message"
describes ongoing things.
Need to do narrative descriptions / events for notable backdrop events
such as migrations, storms, etc.

I18. Add an imf procedure to compute actual bbox of nonzero bits/mask in an image,
use to position emblem adjacent to unit image, etc.

I19. When drawing elevation changes, draw a gray line at cell edges to indicate
the "crease".

I20. To indicate slope, draw center of cell with shape for next smaller mag,
then sloping rects joining adjacent edges of cells, then triangles around
each 3-way meet (for hexes anyway) to fill in holes.

I21. Should not be able to appear to attack if attack not allowed
(arty in ww2-bn for example).

I22. Add designer save option to write only some props of a unit, such as
position, and write as (unit <id> <props>), using name, number or id
as identifier.

I23. Use generic names when summarizing types at a location or in a transport.

I24. Add a side->ready_to_start that each player must enable before actual
game play starts.  Initially false for all sides, mplayer sets when
init done, interfaces enable at player's direction.  Could be button
or implicit when player tries to move.  Note that if multiple humans, and
one tries to move, move will not actually happen until everybody either
tries to move or else clicks on the start button.

I26. Interface should indicate a "move near" plan with a multiple lines
indicating radius, and circle around destination.

I27. Direction cmds in dir of blocking terrain but adj to a slideable
border should cause a border slide. (also for move tasks?)

I28. Linear terrain should be affected by night - draw half-black mask.

I29. Command "ai" toggles between default aitype (first valid type in list
of types - generic mplayer should be first always?) and none, while "ai <name>"
switches to particular ai type.

I30. Add ability to switch to alternate color/icon schemes, such as
winter camouflage for panzer, or military vs pictorial icons.

I31. Add mechanism so that messages get echoed back, for confirmation
of contents mainly.

I33. When displaying perspective, show both top and bottom of "thick" terrain.

I34. For textual commands, interpret <tab>, extend words, etc.

I35. Handle some glimpses as special event types, such as spotting occupants
in a unit, instead of trying to draw on display somehow.
Call glimpse_unit(side, unit).

I36. Don't say, for instance, "independent 2nd wreck" in textual displays,
but just "wreck" - both in topline displays and narratives.

I37. A game design should be able to specify a per-side optimal centering
for the initial view.  Side property "center-at".

I38. Add some kind of sort key control to help info for commands.

I39. Add more help nodes to explain general concepts like acp.
Describe each general concept that is enabled for the given
game, otherwise say "no xxx in this game".

I40. Add table info to help nodes displayed by both first and second indices
(so for ut table, info is listed in a unit node and also in a terrain
node), plus add an additional node for the table alone.  Should table
help nodes be on a separate chain?

I41. Add generic commands to go up and down; '-', '+'.
Arg specifies size of change, default is 1/2 of distance to lower/upper limit
on altitude.  Use long name command "alt <n>" to set altitude explicitly.

I42. Allow definitions of images that constitute the border between two given
ttypes, or t1/t2/border combos, etc.  Store in global additional-images
or special-terrain-images
as list where each element is like (<ttype> (<ttype> <dirs...>) ... "image-name")
where first ttype is main cell type, succeeding indicate either linear
in given directions, or adjacent cells of given types in given directions.
image-name is the image or family name to use.
Example? (beach (terrain (ne sea) (half (n sea) (s beach)))
       (border (w nw) river)
       "beach&sea&river-1")

I43. Add "angle" and "facing"  image properties that indicate approximate orientation and
direction being viewed from (side, top, 30 degrees, etc).

I44. Add "dirmask" (or list of dirs) to images that may be used for linear
terrain.

I45. Some images in imf may be precalced for a hex or other shape,
need to indicate specially.

I46. Need keywords for images to tie less specific images at smaller
scales to more detailed ones - "su-85" -> "tank", etc.

I48. Need a way to indicate relative precedence of sort keys in list windows.

I49. When in mono, allow choice of small numbers or letters for side, instead of
emblem.

I50. At high mag powers (emblem width < 1/4 cell width), draw people emblems on each
border of hex next to hex with different people.

I51. Define a -h <n> that sets up and waits to get pings from human players.
Like -e <n>.  Kernel only has "wait for <n> remote players", cmdline
does the -h part. -wait <mins> to say how long to wait before going
ahead, also allows players to get impatient and start anyway.
Ideally, the startup host gets a window or command interface
to control the startup process, see who is in, perhaps edit
display specs.

I52. Players should be able to join above by doing "xconq -join host nnnn [-help]".
Help shows description of game and list of players/sides; say "(available)"
if side is waiting for a player, ask terminal for a side number to join in on.
Serving game must open a socket to listen.  If under X11, program can quit
once display is open; for others, program will continue to run.

I53. Game should be able to spec relative or absolute widths of borders
and connections (used when solid or a pattern).

I54. Should be able to, from cmdline, list available player slots in a remote
game without actually trying to get in.

I55. Should be able to parse dates in commands,
omit parts that are same as current value (such as year).
Date string function should cache stuff, so not always allocing new
strings.

I56. Robustify the initial and random date parsing.

I57. Add a text parser etc for specifying units and types.  parse_[urt]type,
parse_unit should be able to recognize ambiguous matches, either return
# results or report of multiple, be able to process each independently,
put in dialog, etc.  parse_feature to locate geo geatures by name.

I58. Kernel should deliver basic formatting info in help text, let interface
digest - need line breaks, text fill, tabs/tabstops, emphasis/bold (use
^B,^P,^I chars?).  Perhaps some way to name a picture and let interface
fill in actual picture.

I59. Do something in general for reporting destinations, choices are
raw coords, dir/dist, or a dest name of some sort (unit or region).
Useful to have optional map scale to report distances in miles etc?
Examples: "in xxx country" (needs defn of country)
(define gvar "start-area-name" that gives name?)
"NE of country" "E of Foo Bar" "in <region>"
Function is position_desc(buf, side, x, y), where side==NULL means
do for omniscient side,.
also define position_desc_relative(buf, side, x, y, x2, y2).

I60. If info is always accurate and up-to-date, calculate display directly
from state.  If might be unknown at first, but always accurately
known once discovered, keep a bit/piece of info, display from state
if bit is on, else show nothing.  Similarly for info that might
get out of date if observer not present?
If info might be known/unknown and right or wrong, then must maintain
full copy, though can forward to real state if internally known to be
accurate.

I63. Add designer tool to paint theaters for AIs.  Should just be a hook to AI
that is interpreted as AI prefers.
AI should report range of integer values (with optional names) to paint.

I64. In perspective view, displace units by both elevation of cell and their
altitude above it, maybe draw shadow on ground if airborne.
Center unit in cell better (?).
Shade slopes in perspective view according to time of day.

I65. To support multiple natural languages, associate one of several languages
with each side, use to invoke nl-specific nlang.c/help.c routines.
Also have separate command definitions (de-cmd.def, fr-cmd.def, etc)
that interface should be able to use instead.  Each interface, if configured
for it, will have to set up all the command tables, so can be chosen
by each side at game startup.
Would need some sort of function vector setup so as to select the right
set of routines dynamically.

I66. Add interface-independent printable output of all help info.
Add as "save topic", "save all" commands to help dialogs.

I67. In printed map, make grid be gray, draw only around known-about terrain.
Draw area edge in light gray if adj cells not known terrain.
Use halftones or patterns instead of bitmaps possibly, add a
color -> grayscal translation process.
General cmd should be "print [window] [width]", where saying "window"
limits to contents of a window (else whole area is printed), and width
gives physical width of map, default is to fit on one page.
Each page should include a legend showing terrain, units, sides, use
up to four columns at bottom of page, run types together in columns to
save space. (Ditto for text/ascii view.)

I68. Common printing code handles layout setup, layout checking, and actual
computation of printed view.  Interface handles any print setup dialog,
plus final disposal of printed view (to file, to print queue, etc).

I69. All interfaces should have all printing methods available.

I70. At end of a turn, display summary/histogram of action/task/plan types
and outcomes. (debugging display?)

I71. Define a general (all-interface) strategy for guaranteeing image
consistency on screen.

I72. Add ability to select direction of perspective view.
Easier if only one of NUMDIRS dirs allowed.

I73. Clarify rules of how immobile units get on transports.

I74. When autoscrolling, interfaces should support a brief delay option
so that players can see the outcome of a unit's last move for the turn.
Can omit if next unit is close by and no scrolling was needed.

I75. Add ability to supply phrases for table row display in help:
"[can create] by default, [except for] base,town,city".
These would be optional non-null args to table display routines.

I76. Skelconq should examine lib.imf directly during setup, report
on which images were found for the game being loaded if debugging
on, warn if images not found.

I77. Image tools should be able to study colors and colorized images
usefully somehow.

I78. Let images refer to colors by name.

I79. Allow images to refer to palettes by name and colors by index.

I80. Add run-length encoding to image data, important for 32x32 and up.

I82. To describe movement abilities, display both mp and "move range over
a given terrain type", which may be much less.

I83. Interface should complain if no color and no image found for terrain
type.

I84. Reduce amount of redrawing of unit due to display updates for state changes.

I85. Fix m_nearest_cell to account for perspective views.

I86. Notify of supply-related deaths.

I88. Support distinct images for individual units, via an extras property.
Maintain id->image table (hash table? do sizes as well).

I89. Split command help into separate single-char and long-name nodes.

I91. Implement agreement-building interface:
draft <typename> <id> [<title>] [<short-title], to create
drafters [<id>] sides, to add sides to drafting committee
proposers [<id>] sides, to add sides to list of proposers
signers [<id>] sides, to add sides to list of signers
known-to [<id>] sides, to add sides to list of who gets told about agreement
terms [<id>] [=/-] terms, to add/remove terms to an agreement (only drafters may do)
propose [<id>], to reveal proposed agreement
sign <id>, to sign it
show-agreement <title/id> to display a given agreement
list-agreements to list all of them known to a side

I92. Add ability to specify what sorts of events get presented
to players.

I93.
Ilast.

--Documentation

D4. List or index commands both alphabetically and by general function.

D8. In manual, describe each table as UUTable, etc.

D9. Index concepts in manual, index in each chapter as appropriate, so can
trace player/designer/hacker views of concepts.

D11. Describe format of description-format property.

D12. Describe action-messages etc, move descriptions to better places in manual.

D13.
Dlast.

--Testing

T1. Add a compiletime option to measure compute time in microseconds for each
run_game().  Report each turn as histogram of times.

T2. In symbol diff script, check symbols by class (type prop, table, etc)
against appropriate xxx.def file.  Implies no symbols used in both
xxx.def and keywords.def.

T3. Add testing machinery for the graphical interfaces.
Could have AIs play each other on multiple screens.

T4. Add a (quit [if-end]) command to skelconq that exits.  With if-end,
only exits if at end-of-game.

T5. Instead of scanning lib dirs wholesale, make up a list of combinations
of game and variant options to run (for longer tests only; check-lib should
still scan entire dir).

T6. test-lib should run all the useful -g options (use game.dir to collect).

T7. Add a script to discover which modules are never
loaded by any library game.

T8. Set up basic "make check" to run only limited tests on library and standard
test cases.  Should finish in < 1 hour.

T9. Add more directed tests as DejaGnu tests.

T10. Add complete set of test images to test.imf.

T11. Add tests for end-of-game handling; win, loss, draw, etc.
Set up some lib games with non- or feeble sides, so one side wins
more quickly, plus heavily lopsided advantages.

T12. To test save/restore of tables, dump out help info separately, save
game, restore, then compare after restoration.
Also use compiler and compare its output.

T13. Add a test of external synth program.

T14. Run gdl/doc/all.g consistency tests as part of "make check-gdl".

T15. Need special scenarios to be able to test all plan types accurately,
should set up similar tests for all major parts of planning and AI code,
each should ensure that all the code bits actually get executed.

T16. Fix command analysis script to work reliably.

T17. Write a library module name analyzer/checker - similar to doschk.

T18. Fix where test games have sides with negative priorities.

T19.
Tlast.

--Library

L4. WWII scenario should be able to have a "neutrals" side that resists
involvement.  Attempts to attack neutrals should have some consequences.
Spain and Turkey should be neutral, but if attacked, will go over to
other side.  (This should be recorded in the scenario as a preset
property of those AIs!)  AIs on opposed sides should assess value
of capturing side's units vs expense & risk of combat.

L6. Add more 16x16 panzer images.

L7. Eliminate panzer slope terrain, replace with hilly or rough.

L8. Gettysburg brigades should vary in quality and hp.

L9. For Gettysburg, add movie showing rain descending on field at end of game.
Make unit display say "Kane's brigade (Fed)" instead of "your infantry Kane".

L10. Add emblems for pelops sides (owl for Athens at least).

L11. If fighters had a low land/takeoff time, then could attack adj bombers
a lot more than now (realistic), but bombers can't escape then, unless
some sort of generic auto-retreat implemented (a good idea).  Auto-retreat
might happen in addition to the hit, rather than instead of the hit.
Refuel should consume part of flying time, but not all, then can
fly many sorties against nearby targets.

L12. Make new world maps that use connections for straits and rivers.
Distinguish navigable/unnavigable rivers?
(extra layers should be optional - could do "ifdef river type")

L13. Add modified standard game that is more resource-bound, supply used up
faster, all units must be kept supplied, need to build strings of
bases to get supplies out to where needed.

L14. Write a ww2-std-pac-42 scenario with Allies (including Soviets?)
vs Japan.  Immediate post-Pearl.

L15. Change ww2-div-pac to include diff sizes of ground units (reg, bde,
marine bn, inf-bn, marine-div).

L16. In ww2-eur-42,
Swiss, Spain&Turkey should have option to be inaccessible, also remove any indep cities.
Also make Sweden inaccessible?
Add more depth to USSR (move existing cities west to make room).

L17. WWII strategic games should have large number of predefined agreements
constraining players.  Add more pre-existing units to all sides.
Add "Axis/Allied minor" sides that include Balkans, etc.

L18. Define emblems for axis and allied sides in ww2-stdunit.

L19. For Normandy, set up staging areas for German reinforcements to arrive from.
Set German AI to be primarily defensive.

L20. In ring-quest, most types should be able to enter independents
without capturing.  Hobbits and elves should not be able to capture
anything, but dwarves could capture mines perhaps.  Should riders be
tied to Rohan specifically?

L21. To get the AI to try to capture the ring specifically, define a
scorekeeper that tests possession, Mordor wins if possesses.
Alliance wins if ring no longer exists, can be destroyed by
dropping when on "lava" terrain (only at Mt Doom).

L22. Add to game of wilderness fantasy adventure searching for treasure etc.
For one player, starts out as a vagabond with limited materials.
Either convert self to higher "rank", or else have improved capability
via experience points and more equipment (but what would "equipment" be
good for exactly?).
Can capture other humans, animals, etc, use as assistants of variable
loyalty.
Could have a machine-run side that seeks to capture/kill player, like a
police force or army (or assassins?).
Have ships for crossing oceans (but need to "buy" somehow, and if in town,
town should be on coast).
Include weather/seasons with significant effects.
Need unit/material as object of quest, perhaps different kinds for
different games.
Should predefine all sides(?), but allow multiple adventurers and only one
monster side - lock this side so players can't take it (but not always?)
To make a race game out of this, make a star shape with players at end points
and goal in middle.
Terrain then fixed in size and part of content, another part is variable
and may be modified by synthesis.

L23. Add a game "Medieval Diplomacy" a la Kingmaker.
Each player is a lord/lady with coat of arms.
Few battles, much maneuvering.
More alliance machinery?
Need rules/state for varying degrees/types of alliance, could affect
mutual transport, control, temporary vs permanent gift, etc.
Can move armies around, raise/lower taxes, manage rebellions, wheel/deal.
Players have a chance of dying accidentally or of old age.
Can players be taken prisoner themselves and try to buy their freedom?
(Because if player is killed, possessions revert to neutral or to ally
rather than being acquired by capturer.)
(Need primitive for "exchange", theory is that actual individuals arranging
trade can prevent cheating on the spot, perhaps include a "chance of cheating
success" plus "attempt-to-cheat-p" that each player can set.)
(Be able to have "materials" like age or heat or poison that are deadly if you
accumulate too much? would need a excess-death-chance that is like starvation)

L24. Add a game "Modern War".
Develop modern-day military games, both operational and strategic.

L25. Add a game "Today".
An all-out simulation of the modern world at a 1/2 degree scale,
with each indep country as a side!  Use earth-50km map,
add cities and population to account for everybody.
Would need high-density cities, factories, etc.  Don't worry about size of
game, use it as a test of massive scale.
Make small subareas as warmups and test scenarios.

L26. Add a game "Space Empires".
Like Spaceword HO or GB, based on thinly scattered solar systems with
planets as occupants, ships/cities occs of planets.  Deep space move
very slow (but not less than 1 hex/turn?), but could enter/leave gate
units more quickly if entry of non-adj unit allowed.
Solar systems are always-seen, but would need to explore planets more
carefully (planetary surfaces not plausible tho).
1-month turns??

L27. Add a game "Corporations".
[could make a game based on corporations that have units that are
factories etc, should be able to buy and sell them]
[most elaborate might be to allow corporations to coexist with
countries (what does that mean?)]

L29. Add a more elaborate version of "Tolkien".
Alliance A is dwarves, elves, hobbits&Gandalf, Gondor&dunedain, Rohan,
each with own realms (Lorien, Iron Hills, etc),
Alliance B is Mordor, Isengard, Easterners, Southerners,
and indep sides are dragons, trolls, maybe balrogs.
Indeps should have predefined chaotic behavior.
Predefine most units, allow slow production of more.
Places include:
village (Hobbiton, Rivendell) - minimal production, no fortification
town (Edoras, Bree) - minimal fortification
city (Minas Tirith, Barad-Dur?) - has towers and walls, large population
tower (Isengard, Minas Morgul) - fortified place
mine
ruins - defensive advantage only
Types for Mordor should include orcs (group of 100?), wolves (group of 10?),
individual nazgul and trolls.
Hobbits are individuals, elves and dwarves are groups of 20, men & riders
are groups of 100.
Balrogs and dragons are individuals.

L30. Add more instructions to library games in general.

L31. Rename "port" image to "anchor", "farm" to "barn".

L32. Fix match of village image and mask.

L33. Place galaxy's black holes by using random terrain generator
on top of fractally generated space and nebula.

L35. Add mask to glider-bn?

L36. In ww2-adv, penalize attempts to capture a city directly from transport.
Only do this for defended cities?

L37. Find out if classic Xconq always garrisoned captures, make classic module
do it also if necessary.

L38.
Llast.

--X11 Interface

X2. Show each player the options that were supplied at startup, as a notice.

X3. To do movies, draw a frame and schedule a timeout to draw next frame.

X4. In info window, use fixed fields of 4 chars for each supply type name.

X5. Extend X11 selection of unit types to include multi-char names.

X6. Fix X11 unit type list bitmaps to display with consistent colors.

X7. SelFile should be configured out with disable-selfile, only built
and linked in if configured and present.
Fix SelFile nonportabilities like decl of sys_errlist, etc.

X8. Make imf2x/x2imf translate bitmap filenames and struct names
properly.

X9. Colorize unit icons via u_color().
Allow either use of side colors (symbolically, %1, %2, etc
matching against side color array elts, or by name).

X10. List of unit types should gray out types that can't be owned by
the player.  Add option to eliminate any that can't be in game
at all (designer will need to see all types though, be able to
recalculate the list on demand).

X11. Side list should display other sides' willingness to draw.

X12. Use special bg pattern or stipple for unseen and grid colors if mono.
(or - support {lt,md,dk}gray on mono displays, in addition to other patterns.

X13. Let imf2x only extract bitmaps whose names match given arg.

X14. Add resource name to request_color, use to override standard
color choices in library.

X15. Add resources:
	-xrm
	-display (for player starting the game)
	-fn, -font (text font only)

X16. Use Xconq.game.<game>.<unit>.{char,image,color} to set per-game colors etc.

X17. Add side->ui->default_draw_units etc to set initial values for each
created map, let these be settable from resources.

X18. Fix drawing to not damage borders or else redraw as needed.
What rules for which should lay on top of which?
Try to optimize so border redrawing not always being done.

X19. Default unit images should include first few chars of name in box,
a la Mac interface.

X20. Allow setting of window subdivisions via resources.
xconq.mapListWidth: <pixels>
xconq.mapNotesHeight: <lines>

X21. Develop a higher-contrast more-visible display of current unit/location.

X22. Typing text into ask_position switches to prompt, reads a textual spec
of location.

X23. Allow terrain color to be two colors, use to colorize mono bitmap
for terrain.
Search for ',' in t_color, fg first, then bg, assume bg is black if
not given.  Need a way to reverse so fg is black and bg colored.

X24. imf2x should be able to indicate progress, never overwrite existing images
(or compare - effectively "move-if-change" behavior)

X25. Use a builtin color matching a color name if possible, otherwise
use the imc definition.

X26. Write image scalers for *2 and /2 size images, compute and cache during
startup.  Shrink rule is 0,1 -> 0, 2,3,4 -> 1.

X27. To describe movement abilities, display both acp and "move range over
a given terrain type", which may be much less.

X28. Non-tiling terrain patterns should be centered in cell on top of another
pattern/color possibly.  How to scale to larger cells?

X29. Never try to auto-calculate hex chars from fill patterns,
but maybe provide a simple tool, goes with tool to build
font from bitmaps?

X30. Font should support terrain pattern inside colored hex - needs to be
precomputed when building the font.  If not avail, still have to draw
twice.

X31. If names displayed on map, use different size (and type?) fonts
for different kinds of units.
Legend fonts should vary with magnification also.

X32. What to do about area painting and dragging?  Turn on pointer motion
events temporarily?  Look at "bitmap" source.

X33. Make the font stuff work again.
Define a family of "xconq" fonts, one (or two?) for each size, pack in
icons, masks, terrain.  Eventually allow more than one font at each size,
in case too many images.  Concentrate on terrain at first...  Keep separate
file with char->image mapping, read in from a standard place at startup.
(Install in program? No, can't update when font is updated)

X34. For event list display, maintain buffer of n lines, each pointing to
event being listed, recalc when window enlarged, etc.
When list[i] selected, display event description plus ptrs
to related events.
Some "events" will be summaries (like total losses),
be able to change amt of summarization.
Observer mask is parenthetical remark.
Include toggles to display events as they come in, and
to scroll map to show where event is happening.

X35. Change setup to use a single popup; list of games and preview at top,
then variants (min size initially, then grow for actual variants),
then player list and buttons.
Constrain to avail screen, borrow code from create_map.
Use cmdline to fill in as much as possible.
Highlight stage as committed to.
Confirm openability of each display when typed in.
Xconq.setup:
Xconq.setup.game:
Xconq.setup.game.list:
Xconq.setup.game.description:
Xconq.setup.game.picture:
Xconq.setup.game.loadbutton:
Xconq.setup.variants:
Xconq.setup.variants.{things}:
Xconq.setup.variants.ok:
Xconq.setup.variants.cancel:
Xconq.setup.players:
Xconq.setup.players.list:
Xconq.setup.players.{aibutton,etc}:
Xconq.setup.ok:
Xconq.setup.cancel:

X37. Implement do_attack.

X39. Implement do_produce.

X40. Implement do_remove_terrain.

X42. Implement do_surrender_to.

X43. Implement do_take_unit.

X44. Add dump of scores to stdout when quitting game.

X45. Make the following resources work and document them:
For instance, in your X resources, you would say:
@example
Xconq.{*,<game>}.SideName: <string>
Xconq.{*,<game>}.SideNoun: <string>
Xconq.{*,<game>}.SidePluralNoun: <string>
Xconq.{*,<game>}.SideAdjective: <string>
Xconq.{*,<game>}.SideColorScheme: <color names>
Xconq.{*,<game>}.SideEmblem: <image name>
@end example
where <game> identifies the specific game or game design,
and the resource names correspond to side slots in the obvious way.

X46. If a savefile is in current dir and no contradictory args found (no -f, -g, -join),
ask the player if they wish to resume the saved game.

X47. Add support for construction run doctrine to build command.

X48.
Xlast.

--Macintosh Interface

Mac4. Split play menu into an "action" menu and a "control" menu or some such.

Mac5. Test that maps are properly cleaned up when closed.

Mac6. Detect when world size variant can no longer be used (after game
loading and revisit to variants dialog) and gray out.

Mac7. Fix to beep if a unit ordered to attack but has no ammo available.
Should also pop up or otherwise make a warning visible.

Mac8. Fix scrolling confusions in history window.

Mac9. Fix scrolling confusions in list window.

Mac10. Add option to display terrain as solid colors if colors are available.

Mac11. Define and use an "erase-in-the-grid" procedure.

Mac12. Add a "completed units only" option to list view.

Mac14. Ensure that "computer" and "face" icons updated when side info changes.

Mac15. In list, add column that indicates current task.

Mac16. Disable "give" menu entirely if giving not allowed.  Disable giving unit
to self, and to any disallowed side; but don't complain too much, since user
might ask to give every unit to another side.

Mac17. Change of map magnification should automatically set window to user state.

Mac18. Display range of possible advantages in player dialog, allow setting via
popup or text box as well as up/down arrow.

Mac19. Add numerical display option for sides, set up 8x8 or 6x8 number emblems.
Also allow larger sizes of numerals (12x12 or 9x12).

Mac20. Save/restore window setup with Mac interface data, adjusting for
possibility that game is restarting on a different size screen.

Mac21. Eliminate occasional need to click a second time to get a build to happen.
Do by setting up task that will only fail if a certain number of turns
have passed, and feed back to user also, by indicating task exists, but
also that acp is currently insufficient to get started.

Mac22. Update a numeric world size in corner of world shape dialog as cursor moves.

Mac23. Don't redraw all controls when updating designer dialog.

Mac26. Check for events between every few rows of drawing, be able to abort or restart
drawing if requested.

Mac27. Make designer palette into a floating window.

Mac28. Do mouse-based actions when mouse *released*.

Mac30. Command-F (or '.'?) in construction should cause next window back to scroll/hilite
selected unit (but not bring the window forward).

Mac31. Use drag of unit to indicate waypoints of a path, feedback with envelopes
of route and only do waypoints when indicating points outside shortest route.

Mac32. Be able to double-click in build dialog to set construction .

Mac33. When laying out list window, precompute widths of columns using max/expected
string widths for type names etc.  Account for width of headers and desired
spacing between columns.

Mac34. Make pdoc load game and print the full description of it.

Mac35. Allow multiple units to be selected in list windows.

Mac36. Express merge by dragging onto unit, express detach by supplying an amount
in modal dialog (awkward, but rare?)

Mac37. Should be able to zoom or resize side list to show relative standings and
other detail about each side.

Mac38. Allow for more flexibility in size of emblem relative to unit (a preference?)

Mac39. Display instructions and notes from multiple modules possibly, need to say
how to do this (explicit "append" directive at end of instructions?).

Mac40. Implement a progress bar for internals of AI calcs or at least a watch cursor.

Mac41. Add new construction-like dialog for material production.

Mac42. Build routines to insert a string into a "field" of a list entry,
instead of rebuilding entire entry.

Mac43. Mark menus to indicate whether any of a group of selected units matches
each item.

Mac44. Unhighlight forward/backward arrows when no units to look at.

Mac45. Command-. should be able to interrupt nearly any calculation.

Mac46. Preferences dialog should have a list of specific setups to choose from
("big screen", "careful play", etc) impl as config-names.  Player config
objects should include Mac-specific flags then...  Dialog can also have
several screens of options.

Mac47. To display names, make a layer of shorts where each value is location of
cell with the legended object.  Cell itself has access to legend, plus
flag indicating direction and position of beginning of legend.  Then to
erase legend, have to clear each cell that refers to given cell.
Also need to repair legend correctly when another unit passes through it.

Mac48. When drawing rubberband line for movement, make line heavier for part of
movement that will happen immediately.

Mac49. When listing units by location, add twist-down for occupants, group stack
members with bar or some such.

Mac50. Be able to draw more unit info on map window, at least at high mag powers.
Do num parts/hp, mp/acp, in misc corners a la Empire Master.  Unit id would
be useful also sometimes.

Mac51. Implement both randomly-chosen and cycling image sets for the map window.

Mac52. Should be able to define special win/lose sounds (cheers and raspberries),
attach to interface's handling of events from kernel.

Mac54. To indicate available movement, change cursor to reflect accessibility
and amount of time needed to get there (ETA) or display in control panel
or elsewhere on map.

Mac55. Implement doctrine changes with dialogs examining doctrine objects.
Add button in unit closeups.

Mac56. Do offscreen drawing for visible map plus part of area around, but need
to calc memory limits so as not to exhaust space prematurely.  Do one
offscreen area/map, precalc size and retain, use individual cell drawing
otherwise.

Mac57. To draw maps while still allowing events, make an array of rows for each map.
Update event computes which rows to redraw, plus start/end of each (use 0/0
to indicate no drawing needed).   Then in main event-handling loop, if rows
remain to be drawn, do one or a few ("draw rows for 15 ticks") then go back
to wait for event.  Only call run_game when a) all map rows are drawn, or
b) an event comes in from another machine.

Mac58. Be able to hit key to bring up useful data while rubberbanding, or else have
additional popup or use topline with this info.  Useful data includes distance in
cells, how much supply unit might need, etc.

Mac59. Add localizations for common languages.

Mac61. Add a graph window that displays up to 4-5 chosen statistics against time.
Needs choice of what to display and a subset selector for each graph.
Some stats will have records that have been kept, others will start only
when graph is requested, but then keep accumulating even if no longer
being displayed.

Mac63. Add machinery (to MPW version) to build an integrated executable that
doesn't need lib or lib-mac.  Use sed/streamedit and Rez to make
resources from text files, plus renumber so no conflicts with base
resources.

Mac64. Connect button on splash screen should bring up a transport selection
a la Bolo, with choices of serial, ip, atalk/ppc, and subdialogs
appropriate for each.  Player setup dialog then needs a flag for each
player to indicate when connected.
(Flagging a player as "remote" should also bring up dialog, if method
not chosen already.)

Mac69. Implement do_surrender_to.

Mac70. Implement do_take_unit.

Mac72. If name of resource being read into IMFApp is mistaken, warn and
ignore if continued, don't exit.

Mac73. Reduce amount of redrawing of unit list window.

Mac75. Define fonts "small" and "large", make both user-settable.
"Small" font is for most text, "large" is for highlights and titles.

Mac77. Offset map being viewed at angle so that most-offset elevation
is still visible.  (What about aerial units?  May be very high up relative
to perspective.)

Mac78. Add view menu item to adjust sorting/summary of score window etc.

Mac79. Add tests for System 7 explicitly, warn and exit if not 7.

Mac80. Change IMFApp to output either color-only (cicn/ppat) or bw-only
(icon/sicn/pat) data.

Mac81. Fix IMFApp so that multiple sizes of cicn resource get written out
with different names.

Mac82. Read/write scores in same place, irrespective of where
game loads from.

Mac83. If no CQD, have picts for non-16x16, 32x32 images.

Mac84. If no CQD, still use black for default unknown terrain.

Mac86. Draw feature boundaries as X11 interface does.

Mac87. Fix redrawing of grow box when map is made larger.

Mac88. Do variable-width formatting of lists in construction window, don't cut
anything off short unless absolutely necessary.

Mac89. Port to PowerPC, supply PPC or fat version in distributions.

Mac90. Add dialog to record statistics in user-specified file.

Mac91.
Maclast.

--Windows Interface

W1. Add one.

--NextStep Interface

N1. Add one.

--Curses Interface

C3. Fix curses interface so cursor not always in bottom corner of screen
on some machines (like sun4).

C7. Extend selection of unit types to include multi-char names.

C10. When moving cursor modally, maintain some info about what exactly is under
the cursor (use whole info space, put info about what is being
moved in mode line).
Include info about distance from starting position, and support "direction"
cmds to cycle through stack.
Distinguish perm from temp top line data, keep track of each separately.

C11. 'D' doctrine, have it bring up textual summary, use textual commands to
modify.

C14. Allow putting up a legend to display chars (such as terrain type chars)
in list area.  Bring up via '/' or perhaps option to general help.
(or via 'v' command?)

C15. If can support, add getch() timeout so human can move immediately instead
of waiting for mplayer to finish.  Indicate that mplayer is "thinking"
periodically, need kernel callback (?).

C16. Help topics should be formatted as multi-column list, let arrow keys
move around.

C19. Warnings should have a preference to record full text of warning in a file.
Full warning should more data at end of message, then truncate if too big
for alerts.  (If warning recording is on, mention in alerts or somewhere
that additional data is available in a given file.)

C24. Implement do_surrender_to.

C25. Implement do_take_unit.

C26. Always write curunit's chars on top of chars already in cell.

C27. Fix map display to show bottom line after '_' command sets info size.

C30.
Clast.

--DOS/VGA Interface

Dos1. Add one.  (Xconq is fundamentally 32-bit code, so not much point in
trying to do anything less than i386 with VGA; use DJGPP with libgrx.)

Dos2. DOS code should do name reduction algo when trying to open
a long name file.
*.dir -> *_dir.txt for DOS.