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.

--Kernel

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.

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

K24. Implement storms as very-high-density cloud.  Storms cause
accidents and attrition and loss of acp and reduction of speed.

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. (Can use pairs of 1-dir units to make
bridges.)

K35. Maintain an in-supply bit for units.

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 in some games should be unwilling to break a treaty.
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.
DoW may not be possible or meaningful in some games...
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?

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

K45. Implement (or stub) basic goal tests.

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.

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%

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

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.

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, use to build
panzer scenarios.

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.

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

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.

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.

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.

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.
Commitments default to zero.  If can be nonzero, create battle objects.
@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

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

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.

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

K112.
DEF_VAR_I("actions-are-buffered", g_actions_buffered, set_g_actions_buffered,
	"",
	gactionsbuffered, 0, 0, 1)
@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

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.

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.

K126. Add ut_people_supply that is amount of supply gotten by unit if people in
cell are on the same 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.

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.

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.
@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.

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.  Define money-to-create, etc for
units, alternate means of specifying build constraints.  Add way to define
money-per-turn-min, -max, taxation rates on units, connects to opinions.

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?

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

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

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".

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.

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.

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 plan, 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, or indep 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.
Make up a acting unit vector for all sides (incl. indepside) with acting
units.

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.

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.

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

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)

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, ...)
Read/write goals as separate forms, make xrefs to them.

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).

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

@subsection Morale effects

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

@deffn Table @code{surrender-chance-morale-modifier} u1 u2 -> n%
[use for sieges?]
@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 changes

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

@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

@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-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-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{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-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{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}
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}.

@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)

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.

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

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

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

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

K212. Add symbols for agreement states.

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]

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 specific properties individually,
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.

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.

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.

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 more layers and options to area add, such as add or subtract
from cur value, or a conditional such as (if mountains then ice).

K243. Keep part of history log on disk rather than in memory if log gets large.

K244. Implement morale-terrain-effect.

K245. Implement side control; add controlled side's units to controller's move
vector.

K246. Add controls for random cloud variation.

K247. Add effect of temperature on cloud formation.

K248. Provide a way for the gdl command to clear and recalculate all data
cached as the result of game parameter analysis.

K251. Add ability to have several hundred sides.

K252. Add the ability to use the unit defaults to set default plan properties.

K253. Change ammo usage specification to use two uu tables, one for material type
that will be used as ammo, and one to specify amount (consumption-per-attack),
eliminate hit-by table.

K255. Add ability to make some types' initial numbers settable by advantage,
have others unchanging.

K256. Add mechanism to define multiple types of accidents, each with own
probability, notification, etc.  Use basic table to trigger scan of possible
accident types, weight each for likelihood.

K257. Add a way to specify that a country should include specified numbers of
preexisting units already on map.

K258. Add a way to designate groups of units that can be saved, restored,
and manipulated as a group in a module. (extra property, like sym)

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

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

K263. Let transports on a trusted side do auto-resupply of occupants.

K264. Add consumption of material as part of change-type action.

K265. Add effect of being an occupant on weapon height.

K266. If unit accelerated by occupant has not yet moved in a turn, then
entry of accelerating occupant should increment acp to what it would have
had if occupant had started inside unit.

K269. 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.) (But what is the use for these regions?)

K270. 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.)

K271. 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.

K272. 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.

K273. Add a zero-morale retreat chance that is < 100%.

K274. Add a way to sell or trade tech levels explicitly.

K275. Disallow anonymous variants.

K276. Allow connection terrain to be used as passageways in mazes.

K277. When doing initial placement, test for presence of connection that allows
unit, even if underlying terrain does not.

K278. When counting adjacent terrain types, ignore edge terrain (in
what context?).

K279. When doing games based on real world maps&cities, allow option
to give all possible cities to a side, so that easy captures at
beginning don't cause AIs on weak sides to give up immediately.
Also add way for side selection to choose sides whose initial
units will match the desired advantages as closely as possible.

K280. Disallow construction of a unit on terrain that it would
vanish on.

K281. Add machinery sufficient to emulate Civilization-type games.
Add new object type "civilization advance" or just "advance".
Advances are bodies of knowledge, not physical unit types.
Advances enable new unit types, obsolete others, obsolete
units disappear (or may be upgraded to next generation?).
Advance has properties name, description, prereqs, cost, random
acquisition chance, get from other side chance, category, era
association.  Players may encourage a specific advance, but may
not have direct control over which will happen next.
Change current "research" to "development", use "research" for
advances?  But advancing should be backdrop activity, not driven
by specific actions.
Do city improvements as new unit types, or perhaps city type change -
walls, temples, marketplaces, libraries, banks, universities, factories.
Allow construction of road and railroad types, but allow road bridge
construction until specific advance achieved.
Scatter minor tribes randomly, add way to specify random individual
behavior - surrender, disappear.  Generate barbarians randomly during
game.
Make side name change from time to time, reflecting major upheavals,
barbarian takeovers, etc.
Define concept of eras, change era after n turns, or upon some condition,
affects reporting of time mainly.

K282. Add incremental random unit generation, chance of appearing near
existing units, don't generate any more than a certain density.
Distinguish initial density that can depopulate, vs ongoing density?
Hard to track, would need additional layer...
unit-create-chance u t
unit-create-density-max u t
unit-create-radius u1 u2
Code tests for need to generate at each turn for each unit on a side.

K283.
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.

M8. Prefer to hit or capture transports, especially if easier way to bag
or destroy the occupants.
Add estimation of units that might be hidden in transports.

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.

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.

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.
Routine could be chance_to_own_one_of_type(side, side2, u) that is the side's
current estimate of the likelihood of the given side2 owning at least one
unit of the given type.

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.

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.

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.)

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.

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

M55. Don't attempt to return for repair unless there is a known place to get
repaired at.  If can recover, go into reserve for the turn or move to a safe
place and then sit.

M56. If multiple move failures (such as because of stacking limits), delay
rather than cancel.  Count such delays, allow up to 4 before cancelling.

M57. Make AIs be willing to draw anytime during first turn, then go to normal
behavior thereafter.

M58.
Mlast.

--Interface

I7. Add way for player to declare if AI is assisting by default, or in
charge by default.  Allow AI to decide to resign, not just recommend.

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

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)

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 appear to be able 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.

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 (should warn player
attempting to move).

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

I29. Make command "ai" toggle 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.

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).

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. 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.

I49. Allow choice of small numbers for displayed side emblems, 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.

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.

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? or HTML).  Perhaps some way to name a picture and let interface
fill in actual picture.

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.
AI should detect preset theaters, use instead of calculating own.

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.
(including skelconq)

I72. Add ability to select direction of perspective view.

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.

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.

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

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

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

I93. Add option to set contour interval and/or number of contour lines to
display.

I94. If view range is less at night, when night falls, recalculate coverage
and update.

I97. Add a search button/command to help.  Search by either substring in
topic or substring in contents (expensive!).

I99. Add commands to set unit plan types and goals.

I101. Add multi-player alerts;
multi_alert(msg, sides, [minquorum, mintopass], timeout)
multi_query
update_multi_query_display
interface calls ack_multi_query.
Use these for run_error etc.

I102. Warnings and errors should have a preference to record full text
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.)

I105. Add support for 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.

I107. Add mechanism to specify images of incomplete and damaged units
and use them to draw if available.

I108. Add a flag that says whether to scroll over to units that have been
spotted or are passing by.

I109. Add a way to select a random subregion of a pre-existing map at startup;
could choose a 60x30 piece of earth-50km instead of synthesizing, for instance.

I110. Fix follow-action to work right in all interfaces, toggle with
single-key command.  Resolve issues of player control over scrolling
vs game control while player is in move mode.

I111. Make update_unit_display draw less; only unit within cell, or only
unit info.

I114. Let return command handle returning for repairs also.

I115. Reduce dual attack/capture messages to single message, double message
is confusing ("misses", then "captures", etc).

I116. Notify player when unit cannot respond immediately to a task that has
been given, then go into reserve.

I117. Add additional feedback/hints about the current play mode.

I118. Explain MP to enter/leave better in help info.

I119. Distinguish better between single- and multiple-action move tasks;
if in novice mode (add a preference), add notifications that a task has
been set up, plus estimate of # turns before completion or some such.

I120. Add more hints about turn change, possibly add a special notice
when in novice mode.

I121. Scroll to unit at each move within a turn, not just at the beginning
of the unit's move.  Must recognize when a unit is still the current unit,
not scroll to just any active unit, might be moving under totally automated
control.

I122. Add option to scroll to each unit when it moves, not just when it is
ready to be moved.

I123. If tooling or tech insufficient to build a type, and no way to increase
it, remove that type from all build prompts etc.

I124. Fix "throws back" messages (how?).

I125. Add a "fill transport" command (was ^F in 5.x).
Add a command to move to transport being filled (was E in 5.x).

I126. Add a command to clear task agenda but have no other effect.

I127. Add a patrol command (similar to standing order but more like task).

I128. Add a way for a remote player (such as an AI) to shift to being local.

I129. Make default image generation routines generic (use mac code), use
bar codes for default unit images and emblems above 10.

I130. Suppress "insufficient mp" message if reason is supply exhaustion.

I131. Add a map legend help screen driven by platform-specific drawing.

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

I134. Use action-narratives.

I135. Add startup option for
the number of (real) seconds to wait before declaring the
side to be finished with this turn.
Default to 60 secs for humans in multiplayer games.
If no player action, and all other
players finished turn, do a finish_turn.

I136. Merge all command lists into a single command list shared by all interfaces.

I137. Add concept of message channels, allow both private and public "chat lines"
to be created.  Retain current message as email-like interface.

I138. Move Mac-specific aux (feat) color and preference code into ui.c.

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

I140. 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.

I141. Define a kernel/cmd.c that includes generic implementations of some commands,
add mech to cmd.def to specify generic or platform-specific implementations.

I142. Implement side config stuff, in platform-independent way.

I143. 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.  Could calculate max alt for units, perhaps using log scale
to display.)

I144. When unit to be delayed is only one still capable of acting, beep or
otherwise indicate that this is the case.

I145. Tableize construction dialog info, assume left and right panes.

I146. Add a per-side play rate, use to govern how often AIs move when humans
are moving.

I147. Genericize by-name search function, define command, make case-sensitive
and able to match on substrings.

I148. Date/season string should also report night/day if same for all cells
in world.

I149. Do a score calculation before first turn of game, so as to get better display?

I150. Transport occupant display should include indication of percent
full, both "capacity" and per-type if appropriate.

I151. Add a way to describe the location of a unit in terrain or
transport as "at" or "orbiting" etc instead of always "in".

I152. If a unit can't move on its own, and can't be carried, then
complain about user attempts to move it.

I153. Add ability to have a larger image (gif?) showing what unit
would look like in real life, use in help info.

I154. For each feature type, be able to specify how rendered (color,
width, etc), in addition to any user configurability.

I155. Use common location_desc for both oneliner and unit info.

I156. Position names of large features to appear within visible
part of map.

I157. When reporting scores, identify score of just-completed
game differently (may not always show as most recent game in
list).

I158. When connecting to remote game, allow request for specific
advantage.

I159. In remote game setup, allow for additional chat window, retain
during regular game.

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

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

I162. Define tasks for all types of actions, don't let interfaces
specify actions directly.

I163. Eliminate character-based commands for designing, add long
commands to supplement mouse-based design.
layer <type> [<props>] @ x,y [to x,y] [r radius] [+-] <value>
new-unit <type> <side> @ x,y

I164. Add hp bargraph on map as part of icon.

I165.
Ilast.

--Documentation

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

D8. In manual, describe each table as UUTable, etc, so shows up in index.

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

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

D17. Fix generated html so that large manual title is at top of web page
instead of preamble material.

D18. Compare contents of refman with designer's guide, add refs to all
constructs in designer's guide.

D19. Eliminate mentions of GDL from player's manual.

D20.
Dlast.

--Testing

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

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

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).

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, dump out help info separately, save
game, restore, then compare with help info after restoration.

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.

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

T19. 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?)

T20. 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.

T21. Add test for side/unit priority machinery.

T23. Add analysis of the modules in the library - characterize each as base,
default base, directly included, indirectly included.

T24.
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.

L8. Make Gettysburg brigades vary in quality and hp.

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

L24. Develop modern-day military games, both operational and strategic.

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

L48. In Gettysburg, don't allow capture of artillery if stacked with infantry
or cavalry.

L49. For WW2 games, use pre-1949 flag for China, Soviet flag instead of star,
and old Japanese flag.

L50. In space, make suns not owned by any side?  Cruisers should be able to
attack planets/planet occs, damage shipyards.  All spacecraft should be able
to "enter" gas giants for refueling.  Eartlike planets should have more fuel.

L51. Add emblems for all sides in beirut.

L52. Don't let objects in cave see anything.  Define 32x32 and 16x16
images for gems.  Add more types of treasures, such as gold.

L53. Units in cherbourg should not be able to destroy port.

L54. Decide if armor should be train-transportable in nw-europe.

L55. Add material-to-build to greek period.

L56. In pelops, add hoplites and triremes to initial setup.

L58. In ww2-bn, let inf assaults capture CD arty, little/no chance
to be hit back in process.

L59. In earth-50km etc, fix Recife, San Francisco river positions, add
Yukon river.

L60. In ww2-eur-42, make France controlled-by Germany, but not trusting/
trusted.

L61. Add emulation of civ.  Materials are food, raw (subtypes?), goods
(subtypes?), population (subtypes).  Within city radius have units that
work specifically for city (use supply range?).
Use generic attack/defense factors instead of hit table.

L62.
Llast.

--X11 Interface

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

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).

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.

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

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.

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

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

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

X35. Change setup to use a single popup, filling with list of games
and preview first, then variants (min size initially, then grow for
actual variants), then player list and buttons, each in order as
contents.  Constrain to avail screen, borrow code from create_map.
Use cmdline to fill in as much as possible.  Confirm openability of
each display when typed in.  Copy Mac setup design where possible.

X39. Implement do_produce.

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

X50. If area has an image, display that instead of terrain/bords/conns.

X55. Interface should complain if no image found for terrain
type.

X56. Fix SelFile nonportabilities like decl of sys_errlist, etc.

X58. Implement up/down commands.

X60. Fix occupant test for inf entering incomplete base?

X61. Fix so that occupants of other sides' unit not visible unless see-occupants.

X62. 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.
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.

X63.
Xlast.

--Macintosh Interface

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

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

Mac17. Change of map magnification should automatically set window to
user state.  (Is this possible?  Finder changes window to user state
when it gets too many icons to fit in rightsized zoomed window, but no
mention of how to do this in IM.)

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

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.  Do by splitting offscreen
calcs into small areas (rows ideally), checking events between each
area.

Mac27. Make designer palette into a floating window.

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

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.

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?)

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. (generify list handling?)

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

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 when at high mag powers.
Do num parts/hp, mp/acp, in misc corners a la Empire Master.

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

Mac55. Implement doctrine changes with dialogs examining doctrine objects.

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.

Mac73. Reduce amount of redrawing of unit list window.

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

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

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

Mac93. Add TCP/IP as connection method for remote players.

Mac96. If area has an image, display that instead of terrain/bords/conns.

Mac99. Add display for standing orders.

Mac103. For incomplete units, collect a mask and gray out only the masked area,
or else when drawing incomplete, only draw 50% of its pixels.

Mac104. Implement removal of players/sides at startup.

Mac106. Draw a small unit icon in top unit info area.

Mac107. Add a help button to construction dialog that connects to
specific help screen.

Mac108. Reorganize listing of info in construction dialog, use
fixed-width columns set by maximum width.

Mac110. Fix overrun menu item.

Mac112. Implement up/down menu items.

Mac116. Reduce multiple behavior flags to move/survey mode.

Mac117. When saving on quit, bring up file selection dialog to specify save file name.

Mac119. In construction dialog, only list types that the player's side
can build.

Mac120. In construction dialog, recalculate contents when constructing
unit renamed.

Mac121. In construction dialog, arrange top buttons as construct, run
length, research, help.

Mac122. Use same drawing algorithm for unit images in each kind of window.

Mac123. Add a mode to IMFApp that displays each image separately.

Mac125. Add a menu item for "Wake All".

Mac126.
Maclast.

--Windows Interface

W1. Add one.

--Curses Interface

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

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 (?).

C31. Implement up/down commands. (only do after command sets unified)

C32.
Clast.