[hronne@2.sbbs.se: Lots of new code]

[Stan Shebs <shebs@cygnus.com>]

For the record, here is HR's description of his code additions of last
month. -s

------- Start of forwarded message -------
From: hronne@2.sbbs.se
Date: Sun, 9 May 1999 19:54:51 +0200

Here is finally all the code I have accumulated during the spring. It is
quite a lot of new stuff, which is described in detail below. I would say
the most important things are:

1. A new game "ane.g" which uses both advances and advanced units and
actually works. If you put all 4 sides under mplayer control you can just
sit back and watch how they colonize the land, research advances and
finally go to war against each other. Quite fascinating! It usually takes
around 75 turns before one of them wins the game. Note: It is a good idea
to give Xconq 12M on the Mac when playing this game, 8M is not enough.
Perhaps we should make 12M the default memory allocation for the PPC
version? Anybody that has a PPC should be able to run a program of that
size.

2. Substantial improvements to the kernel AI code. Most important is
perhaps the new function mplayer_update_plan which makes sure the AI is not
pursuing obsolete goals, a common problem with the old code. The AI now
also understands how to protect its cities in an adequate way, using the
new GOAL_UNIT_OCCUPIED, and build tasks are chosen more intelligently for
advanced units.

3.  The ability (on the Mac) to select enemy units and open their closeup
windows. Very useful when trying to figure out how the AI handles different
situations! I strongly recommend that you make this possible also in the
tcltk version.

Everything has been moved to cleaned-up 7.2.91 sources and is marked by
double-slashes as usual. I hope this is the last time I have to do this and
look forward to using CVS instead. In addition to the ChangeLog I have also
summarized all the changes in New Hacks file. Its content is enclosed below.

Finally, I really liked your new terrain images. They make the game look
much more professional! How did you make them? I would like to try my hands
at this.

Hans

- --------------------------------------------------------------------------------
- ---------------------------------------------

COMPILE PROBLEMS

A few minor bugs that prevented 7.2.91 from compiling under Codewarrior 4
pro have been fixed. Most of them involved missing or incorrect prototypes,
or obsolete header files such as Windows.h. See the ChangeLog for details.


SUPPORT FOR MULTIPLE AIS

As a first step towards enabling multiple AIs in the same game, I have
changed the Mac interface code so that the AI Type menu now is built
dynamically, using all_ai_ops.  This makes it possible to compile and run
games with more than one AI.


IMPROVEMENTS IN MACADV.C

The whole city dialog has been rewritten and a number of features added.
The unit info of the city is now displayed in the unit info box (if
visible) when the dialog is opened. The offscreen graphics for the
clickable city map has been improved. Thus, wrapped gworlds are now handled
correctly and regions outside the gworld are painted in backcolor instead
of being scrambled. A new popup menu for setting the plan type has been
added. As you suggested, I have also split the occ display panel into two,
one for facilities and one for the garrison. Finally, several checkboxes
and radio buttons now make it possible to fine-tune the level of AI control
for each city. A number of bugs have been fixed. See the ChangeLog file. A
new dialog, unit_plan_dialog, has also been added.


IMPROVED RUN_CONSTRUCTION

The advanced unit code in run.c (in particular run_construction) has been
rewritten again and extensively debugged. There were a number of problems
with the old code, not just the stuff you found but other issues as well.
This time I think I got it right. The game will run for at least 100 turns
on automatic without crashing (if you give it enough memory) and the
DebugOut file reveals no problems whatsoever at either the task or action
level.


NEW AI FOR AUTO BUILD CODE

The AI code in auto_pick_new_build_task has been rewritten. This time, it
was modelled on your code in ai.c. Thus, instead of just indexing all
available utypes as offensive, coloninzing etc. I have added functions to
ai.c (offensive_worth, set_u_offensive_worth etc.) for calculating specific
utype values in different tactical situations. The new function
auto_pick_new_plan then decides what plan type to use, and select_by_weight
picks an utype to build based on these values. I have removed all the old
indexed utype vector stuff.

I skipped the build runlenghts in the AI code, which instead always
reevaluates the build plan each time a unit is completed. I did this for
two reasons. First, getting the runlength code to work for the AI was a
major hassle. Second, testing revealed that an AI which uses runlenghts
always is beaten by one that does not, since it fails to adapt quickly to
new tactical situations. Toggling on full AI control will therefore
inactivate the runlength code, but the selected runlength is still
remembered in case the player goes back to manual. The name of the gvar has
also been changed from g_ai_build_runlength to g_default_runlength, since
it is no longer used by the AI.


TWO NEW PLAN TYPES

Support for 2 new plan types, PLAN_IMPROVING and PLAN_COLONIZING has been
added throughout the code.


DIRECT CALLS TO HAS_ADVANCE_TO_BUILD

In the old code, has_advance_to_build was called indirectly, from
type_allowed_on_side. This was a problem since inability to build a unit
automatically would prevent its acquisition through capture etc. I have
therefore separated these two functions and added separate calls to
has_advance_to_build in a number of places. When I was going through the
code, I also found a number of cases (mostly in mplayer.c and plan.c) where
build code did not check for anything but could_create. I have added calls
to both has_advance_to_build and type_allowed_on_side in those cases.


HELP NODE IMPROVEMENTS

The advances help code now prints "None" when no advances are needed. I
have also changed all the table_row_desc functions so that a space is added
after each comma in the lists, to prevent the formation of very long
concatenated words which mess up line wrapping on the Mac.


HANDLING OF ABANDONED BUILD PROJECTS

Abandoned incomplete build projects tend to accumulate in advanced games,
where there is a lot of building going on. This causes various problems
later on. I have therefore changed run_construction so that it always looks
for any incomplete unit to finish before starting a new one. This goes a
little further than find_unit_to_complete, which only looks for incomplete
units of the desired type. Moreover, I have made it an option (through a
new gvar) to disband old build projects whenever a new one is started.
Options to salvage the incomplete project for use elsewhere have also been
added. This may occur either at the level of materials used, which are
added back to the builder's supply, or at the level of accumulated cps,
which are added to the new variable unit->cp_stash. Both options are
controlled by new gvars. The second option was of course inspired by Civ. I
always liked to ability to change build task to Chariots on the fly when
the Barbarians land next door :-)


NEW MACROS FOR FINDING ALL UNITS OR OCCS IN A CELL

I have written two new macros, for_all_stack_with_occs (unit.h) and
for_all_occs_with_occs (world.h) which will go through all units including
all their occs and suboccs at least four levels down. I did this since I
was tired of having to do recursions whenever occupants are involved.
Moreover, the recursion approach cannot be used in certain situations. I
think these macros could be used to simplify the code in many places, but I
have sofar only done so in a few cases where the existing code did not
work. One example of this is in detonate_on_cell where occupants would
escape being nuked due to the limitations of for_all_stack. Another is in
preferred_build_type, where the old code relied on for_all_stack without
recursion and therefore failed to count enemy occs when assessing a
tactical situation.


NEW PROTECTION CODE

I have added support for two new tables, uu_cellwide_protection_against and
uu_cellwide_protection_for, in combat.c. I did this for two reasons. First,
I was unable to get the existing protection code to make one occupant (e.g.
triple-A or city wall) protect all other units in the cell. The new code
uses the for_all_stack_with_occs macro to achieve this. Second,
uu_protection and uu_stack_protection are both focused on the donor and
recipient of protection, but ignore the type of the attacker. I wanted to
have protection against some attackers but not others. Examples: city wall
protects against ground units but not artillery; triple-A protects against
bombers but not ground units. The new uu_cellwide_protection_against table
works in this way, while the uu_cellwide_protection_for table works just
like the old uu_protection and uu_stack_protection.


BUG FIX IN THE OLD PROTECTION CODE

I have also fixed a nasty bug in the old protection code. Thus, in
maybe_hit_unit, recursions for occs used probability(100 - uu_protection)
instead of just probability(uu_protection). Since protection numbers
already are reversed (0 is full protection) this gave the wrong result. The
situation was further messed up by the fact that protection of occ by
transport already was factored in elsewhere. I have now changed the code so
that protection by transport is computed correctly and only once, at the
point of recursion.

I think this bug could in part explain some complaints on the mailing list
last year that protection did not work as expected with units being more
vulnerable inside cities tham outside. However, another reason is that if
you hit a transport you also get a free shot at every occ without using up
any extra acps. This makes sense in small scale situations such as if you
fire a shell at an apc, but I question the logic of this when applied to
cities. In effect, it makes units inside the city wall more vulnerable than
outside since it costs less to hit them.

One possible fix would be to move the call to use_up_acp from fire_on_unit
and attack_unit to within maybe_hit_unit, so that it is triggered on
recursion. However, this could have major consequences for some existing
games, so one should test the effects carefully before applying such a fix.
I have not done that in the enclosed code. In the long run, I think we need
a concept for cities/fortresses that differs from that of
transports/carriers, but that would of course require a major revision of
the move and combat code.


ENABLING OVERRUN BY FIRING UNITS AND NONCOMBAT UNITS

Overrun actions are possible only for units that can attack, but not for
units that can fire or noncombat units. However, you have commented in the
code that it should perhaps be possible for a noncombat unit to overrun an
empty cell. I agree. In fact, the same argument also applies to firing
units which may kill all targets by fire and then move into the empty cell.
I have therefore made the necessary changes in the code.


IMPROVED CAPTURE CODE

I have also made it possible to attempt a capture after firing at another
unit, but with the restriction that it has to be in the same or an adjacent
cell. I think this is logical. Artillery should of course not be able to
capture anything from a distance but it does make sense to permit a tank
that fires at a unit in the same cell to then also attempt its capture.

In a further attempt to improve the capture code, I have added a new
function go_after_captive. It works just like go_after_victim or
fire_at_opportunity but considers capture options only. It is called from
mplayer_update_plan.

In ane.g, the presence of any armed unit within a city protects it from
capture. This would cause fruitless attempts to capture a city since the
old capture_chance code did not take protection into account. I have
therefore written a function, real_capture_chance, which calculates the
chance that one real unit may capture another.


MAKING COMBAT AND FIRE VISIBLE TO MORE SIDES

I have changed the code in maybe_hit_unit, do_fire_at_action and
do_fire_into_action so that every side who has a unit in either the
attacker's or the defender's cell always can see what is going on.
Basically, all three now use the SideMask code from do_fire_into_action.
Moreover, the new code handles side_see_all and all_see_all correctly. I
did the change primarily for the latter reason, since Im found that I could
not see all fire even though all_see_all was set. However, I do think it
makes sense for side who can see a unit being hit (by having a unit in the
same cell) to also see the incoming fire itself.


FIRING RANGE BUG FIX

I found a serious bug in the task code for units that can fire from a
distance. These units would move to within range of their target, but then
just sit there trying to fire each turn but never succeeding. The cause was
a bug in do_hit_unit_task which limited the effective firing range to
u_range - 1. While debugging this code, I also added some code that will
make a firing unit move closer if the target is undefended, in order to
attempt its capture.


IMPROVED PRE-ATTACK DAMAGE CALCULATIONS

When I wrote the ane.g game, I made cities easy to hit but invulnerable as
such. The main effect of hitting a city is instead to damage its occupants
until none are left. The city can then be captured. However, I ran into an
unexpected problem: units under AI control refused to attack cities since
they could not damage them. I have therefore rewritten fire_can_damage and
attack_can_damage_or_capture so that the ability to damage visible
occupants also is taken into account. A new function,
fire_can_damage_or_capture, which was needed for the new capture code (see
above) also works in the same way.


GOAL_UNIT_OCCUPIED AND GOAL_COLONIZE

A very important task in any advanced game is of course to protect the
advanced units adequately. In fact, this applies also to classical games,
where protection of cities and other units that can build is very
important. I have therefore created a new unit plan goal,
GOAL_UNIT_OCCUPIED, which assigns a unit to protect another unit, usually
its own transport. The new constant u_ai_min_defenders specifies the number
of defenders that should be assigned to each unit type. It defaults to 1
but can be set explicitly to other values. A specific unit plan goal for
colonizers has also been added.


NEW FUNCTION: AI_UPDATE_PLAN

I was never very happy with the performance of the AI, which does not
handle emergencies well and fails to focus on the mosty important task at
hand. Debugging of the AI using closeups of multiple enemy units (see
below) revealed that lots of units are pursuing goals that are obsolete,
such as chasing units that no longer exist or have moved out of sight. The
main problem here is a failure to update plans before execution. Some plan
updating is done at the end of the preceeding turn by rethink_plan, but
lots of things may happen between then and plan execution.

I have therefore added a call to the new function ai_update_plan in
execute_plan. The corresponding function in the mplayer,
mplayer_update_plan, first checks that all cities in the neighborhood have
adeqaute protection, and then attacks any nearby enemy unit. I have found
that this knee-jerk attack on nearby enemies is very important in order to
keep the tactical initiative, and produces a much meaner AI.

The new code does of course further blur the distinction between different
plan types. An offensive unit may be assigned to protect a transport if no
other defender is available, and a defensive unit will attack enemies
within its range. However, this kind of flexibility is crucial for good AI
play. It should be noted that the original plan always is retained, so the
unit can therefore go back to it once the emergency has been dealt with.


SLEEP AND RESERVE MODE

Another problem revealed by using multiple closeups during debugging is
that AI units much to easily will go into sleep or reserve mode, and then
just sit around and do nothing. I am not sure what to do about this, but in
an attempt to figure out what the problem is I have added two new gvars
which makes it possible to selectively disable both sleep and reserve mode.


TASK RETRY CODE

My debugging further revealed that lots of units get stuck trying to march
out into the sea again and again and again. The problem here is that
execute_task is to stubborn before it removes a failed task. To be able to
customize this behaviour and experiment with different values I have made
three new gvars, g_ai_badtask_remove_chance, g_ai_badtask_max_retries and
g_ai_badtask_reserve_chance. In the long run, I think we need more
intelligent code here. Obviously, it makes sense to persist if you are
attacking another unit, but not if you are trying to march out into the
sea. Unless your name is Moses, of course :-)


MODIFIED SIDE_SEES_UNIT AND SIDE_CONTROLS_UNIT

Throughout the interface code, a multitude of checks were used to decide if
a side may examine and/or control a unit, and these checks were not always
consistent with each other. To simplify things, I have replaced all such
checks with calls to side_sees_unit and side_controls_unit. However, to
accomodate all possible situations, these functions have been modified as
follows: side_controls_unit returns TRUE also if we are debugging, and
side_see_unit returns TRUE if we are debugging, if the game is over, if
g_peek_at_enemy is on, or if the unit belongs to a side that trusts you.


CTRL-CLICKING NOW OPENS UNIT CLOSEUP

I have rewritten the ctrl-clicking code in do_mouse_down_map_content. Now,
ctrl-clicking on a non-advanced unit brings up the closeup instead of the
side's global_advance_dialog. The main reason for this is that I needed a
quick way to access plan and task info for enemy units during debugging.
Access to the closeup is now controlled in the same way as for the city
dialog which means that you can peek at enemy units during design,
debugging and whenever g_peek_at_enemy is on. I think these changes make
sense since advanced and non-advanced units now are treated similarly. In
the long run, I think the unit closeup and city dialog should be integrated
into one dialog.

I have also made some cosmetic changes to the closeup code in macwins.c.
Most importantly, the unit plan goal is now printed only once instead of
twice within the closeup. Icon drawing using sidecolors is now also
supported in closeups.


SELECTION OF ENEMY UNITS PERMITTED

In order to get the ctrl-click closeups to work, I had to unselect all and
then select the unit even if it belongs to an enemy. The same goes for the
city_dialog, where prior selection is necessary in order to enable
draw_unit_info. In both cases, the unit is unselected when the window is
closed. These changes are of course not consistent with the notion that
only your own units ever are selected on the map. However, I can see no
reason in principle why it should not be possible to select enemy units in
order to access whatever unit information you are permitted to access,
provided that the code is modified so that you cannot give any commands to
such units.

I have therefore modified the interface code in order to enable selection
of enemy units. The following changes have been made: First, selection
boxes and animations are drawn in RED for these units. Second,
query_position_modally unselects any enemy units that are selected, so that
menu commands are not executed for them. This might otherwise happen if
both your own and enemy units are selected at the same time, in which case
the menu items are enabled and also executed for all selected units. Third,
I have modified apply_to_all_selected_units so that enemy units are
excluded even if they are still selected at the time of execution. The
latter may happen if enemy units are selected in the map, followed by a
keyboard or commandwin command. Fourth, I have modified
do_mouse_down_map_content so that all actions first are checked against
side_sees_unit or side_controls_unit before execution. Fifth, the selection
code itself has been modified in a few places in order to permit selection
of enemy units.

This is a pretty radical change to the mac interface, but one that as far
as I can tell only has positive consequences. The ability to select enemy
units does not in any way interfere with normal game play. The ability to
open closeups for enemy units is particularly helpful during AI and task
code debugging, since you then can follow how the AI responds to different
situations. However, I think that ctrl-clicked closeups of enemy units
could be useful also in normal play, even if no task or plan information
would be provided in that case. Specifically, I plan to add the ability to
instead bring up the help node info for the ctrl-clicked unit, which I
think would be a very helpful option in normal play.

In short, I propose that you make selection and closeups of enemy units an
option not only on the Mac, but also in tcltk. The necessary changes are
easy to make (it took me just a few hours) and the benefits are
considerable.


CHANGING THE FIRST UNIT ID BACK FROM 0 TO 1

If you remember, I changed the initialization of nextid from 1 to 0 to
prevent sporadic crashes in the mplayer (and also in the Mac interface)
when it tried to get the side number of the nonexisting unit 0. The fix
solved these crashes, but just like you, I found that it caused problems
elsewhere. Specifically, create_task initializes all task args to 0, and
these default values will in some cases incorrectly be interpreted as
references to unit 0. It is hard to do anything about this without
rewriting the task code, so I changed the code in read.c, write.c and
unit.c back to the old version which assumes that the first unit id is 1
instead of 0. This does of course mean that the sporadic crashes may
reappear, but I think the correct way of handling this problem is to find
out why the mplayer tries to look up a unit which does not exist, and fix
its code instead.

Please note that when you restored the old code in unit.c, you did not make
the corresponding changes in read.c and write.c. These changes are also
necessary in order to make saving and restoring of games work properly!


MENU BUG FIXES

The AI Control item in the Mac More menu did not work. The rather obscure
and difficult to find cause of this turned out to be in create_side, where
the new side->prefixarg variable was not properly initialized. This has now
been fixed.

The Plan Type submenu in the Mac More menu did not work either. The culprit
in this case was a menu number bug in enable_commands_for_unit. This bug
was also the cause of a strange problem that has been around for a while
and which resulted in disabling of several other items in the More Menu. If
you remember, I once had to move the Give Unit submenu to the last position
in the More menu because it mysteriously failed to work in its old position
as item 6.

The Plan Type menu resource (MENU 249) was damaged (all items deleted).
This has also been fixed.


NULL SIDE TREASURY CRASHES

Your new treasury code in actions.c crashes when trying to access the NULL
side treasury. I have added the necessary fixes
everywhere. In one case (transfer_supply) your code already handled this,
by explicitly setting the NULL side to indepside. This prevents crashes,
but I am not sure it is a good idea to let the independent units have any
treasury at all. Presumably, independent cities and villages are not
supposed to pay taxes to a central treasury, or collaborate in any other
way. I have therefore applied the same fix (just disabling the treasury
code for the NULL side) as elsewhere.


MERIDIAN DRAWING

Your "Handle negative longitudes correctly" fix in latlong_to_xy (forced
wrapping of negative minute values) prevents drawing of the Western
hemisphere on the Mac if the area is not wrapped. I have therefore
restricted the fix to those cases where the area is wrapped. I hope the
problem you were trying to fix on Unix is still handled under those
conditions. If not, we may have to split the code somehow. There is no vp
passed here, so we cannot use vp->wide_viewport, but ifdef UNIX could be
used instead.

I have also written a new function, adjust_latlong_interval, which makes a
more intelligent choice of meridian interval when a map is first created
and also when its magnification is changed.

XFORM_CELL_FLAT

Meridians were not drawn correctly when viewing at an angle. The reason for
this was the vertical offset imposed by xform_cell. This is something I
have had problems with before in the interface code - sometimes you need
the xformed value without this offset. To solve this problem once and for
all, I have split xform_cell into two functions, a core (xform_cell_flat)
which does the xform calculations and a shell (xform_cell) which adds the
vertical offset. It is then possible to bypass the offset by calling
xform_cell_flat directly from the interface code. Another new function,
xform_cell_fractional_flat, handles fractional xforms in the same way.


WEIRD CLIFF PROBLEM

In 7.2.91 cliff drawing on the Mac (at least) suddenly broke. The reason
turned out to be that you had changed the type of vp->cellwidth from short
to int. Why should this matter? It took me a while to figure out, but here
is the explanation. First, stdterr.g has the area cellwidth set to 100000.
In new_vp, this gigantic value is fed into vp->cellwidth, which in turn
affects the drawing scale. Since vp->vertscale by default is 1 (no vertical
exaggeration) the cliffs are so small that they are invisible. So how come
we used to be able to see the cliffs, then? Well, in the old code, the
forced typecasting to short just nuked the 100000 value, so vp->cellwidth
was always set to 1 instead.

The obvious way to fix this problem is to set vp->vertscale to a reasonable
value that ensures the cliffs always are visible. This could be done either
in the kernel or in the interface code. I have chosen the latter approach
since I didn't know if cliff drawing still works as expected on Unix. You
will find a setting for vp->vertscale that works reasonably well with all
games that have elevations defined in set_map_angle (macmap.c). If
necessary, you could move it to new_vp to fix the problem on Unix as well.


UNIT ICON DRAWING

I have rewritten and simplified draw_unit_image. It now uses the same code
for all windows (maps. lists, closeups etc.) and therefore also supports
color drawing with masks for closeups. A problem with corrupted colors in
the lists was tracked down to the fact that create_list used GetNewWindow
instead of GetNewCWindow, and has now been fixed.


MISCELLANEOUS

A gvar option to disable the supply and economy code has been added to
run_turn_start. The reason for this is that I had problems tuning the
advanced unit code with all this other supply stuff going on. In the end, I
would like the advanced games to use the same supply and economy code as
other games, but some problems must first be solved. For example, it should
not be possible to harvest the supply produced by one cell twice each turn,
once in run_advanced_units and once in run_economy.

I have also gone through the advanced unit code and made sure it uses
network game compatible function calls whenever possible. A new function,
net_resume_build_task, was written to handle cases where you resume
building a specific incomplete unit. There is still a lot to do, though,
before all the advanced unit and advances code is network compatible. This
is one reason why I have not yet bothered to get rid of the Mac modal
dialogs. Another reason is the lack of TCP/IP support on the Mac. Do you
think you will be able to get this to work any time soon? I realize your
are busy with tcltk, but it would be nice to play against a human opponent
now and then. The mplayer is rather boring once you have figured it out.

There is now support for several types of advanced units (village, town,
city etc). The code in good_cell_to_colonize will go through all possible
advanced unit types and check the available supply within their specific
ranges before making a decision to settle in a cell.

Two new utype props, u_facility_total_max and u_mobile_total_max, make it
possible to specify separate number restrictions for facilities and mobiles
within another unit. This was necessitated by the split occupant panels in
city_dialog, but can of course be used with non-advanced transports in
other types of games as well.

I have rewritten auto_pick_new_research so that it picks an advance to
research at random, and not just the next one on the list. This makes for a
more interesting game where sides under AI control will differ from each
other after a while, and also have their cities work on several different
projects at the same time, just like a human player would do. Of course, a
real AI code that makes an intelligent decision is on my to-do list.

A typo has been fixed in do_move_action and do_enter_action, where it said
"nu2" instead of "u2" everywhere. This was initially spotted by CodeWarrior
as an undeclared variable, and you added declarations of "nu2" in an
earlier snapshot. However, after taking a closer look at this piece code,
it seems to me that "nu2" is just a typo. I have therefore changed it to
"u2" everywhere and removed the nu2 declarations.

Dummy support for the new unit_plan_dialog has been added in xconq.c, and
an error in the x11 unit_build_dialog was corrected at the same time.

A new default has been added default_draw_ai, which determines if AI
regions are drawn by default in new maps. Another new default,
alert_256_colors, determines if the "Change to 256 colors to save memeory"
alert is shown at start.

The "Changing palette" run warning in interp_image has been disabled on the
Mac, since the palettes are changed whenever the colors menu is rebuilt. I
am not sure why it is necessary to warn about this?

An argument mismatch for task_desc has been fixed which caused crashes in
draw_unit_list_entry.

Finally, the new function side_adjective is now used in macadv.c.


THOUGHTS AND IDEAS FOR THE FUTURE


MULTIPLE AND CUSTOMIZED AIS

After I introduced support for multiple AIs (see above) I tested different
hacked versions of the mplayer against each other in the same game. Cloning
the mplayer under another name is certainly a possible way of providing
multiple AIs. However, there are several problems with this. First, the
availble AIs are limited to those compiled into Xconq. Second, many AIs
will greatly increase the code size. Third, and most important, a lot of
the critical AI code is really located elsewhere, such as in plan.c,
task.c, combat.c and run.c.

I therefore think a much better solution is to make it possible to
customize all critical parameters affecting AI behaviour.  In this spirit,
I have already replaced several hard-coded numbers in the kerneI code with
gvars or utype constants that contain "ai" in their names, such as
g_ai_badtask_max_retries or u_ai_tactical_range. This will make it possible
to test out different AI variants at the game level through GDL. Once the
most important parameters for AI behaviour have been identified, I would
like to configure things so that you can chose between several AIs at
startup time, or even customize your own. Obviously, this would require a
lot more coding, but I think identifying and customizing the critical
parameters is an important first step.


INTEGRATION OF ADVANCED UNIT CODE

It is my intention to further integrate the advanced unit code with that
for other units. Some of the AI build code in run.c could be moved to the
mplayer and perhaps integrated with exisiting build code. However, some of
the changes needed are not trivial and have to be tested carefully. One
would also have to make some strategic decisions in that case. Should
non-advanced units also be allowed to to research? Should research and
building be handled separately at the start of each turn, as for the
current advanced units, or should these activities also consume acps, like
building does for normal units?
The main reason why I broke out advanced unit building and research from
the action loop is that it became to complicated to develop and debug the
code otherwise with all this other stuff going on at the same time.

 Another integration that I plan at the interface level is to combine the
unit closeup and the city dialog into one item. This is why I made both of
them open by ctrl-clicking (see above).


SIDE AND UNIT GOALS

Right now a "goal" can be both a side level strategic goal and a unit plan
level tactic goal. It is not a good idea to use the same name for two
different objects. In particular, handling the goal definitions are
confusing, as some of them apply only to the side and some only to the
units. For example, when I added the unit-specific GOAL_COLONIZE and
GOAL_UNIT_OCCUPIED I unexpectedly got crashes in goal_truth, since the
strategic side code didn't know about these new goals. I therefore suggest
that we find another name for one of the two objects. Perhaps the unit
"goal" could be called "mission" instead.


THE CAPTURE CODE

It would make things a lot easier if the capture code could be simplified
and unified. One step towards this is to allow capture also after fire
(makes it possible to treat attack and fire similarly at a higher level)
and also the new function go_after_capture (see above). However, it would
also be nice to get rid of all the capture_independent / capture_useful
duplications. Is there some reason why one function cannot handle all kinds
of captures?

Another question is  whether one should keep the option of direct capture
without preceeding fire or attack. It makes the code a lot more complicated
in some places but is hardly used at all. I did some profiling which
revealed that at least 99% of all captures occur as a consequence of
attack. It seems that right now the AI makes the (perhaps correct) decision
that it makes little sense to try to capture a unit directly. I can see
that picking things off a dungeon floor may rely on direct capture, but
even such cases could be handled by the attack code instead, by setting
uu_damage to zero.


NETWORK CODE

I have tried to figure out why some kernel functions come as "net" variants
and some not, but with little success. You would expect all functions that
can change the game state to be broadcasted, but this does not always seem
to be the true. Is there something I am missing here, or is it just that
the network code is not complete yet?


COLOR & B/W IMAGES

Finally, I just now saw that you have removed the style argument from
get_unit_type_images (this was done already in June last year, but I failed
to note it until now since I always use the side colors). It effectively
disables many of the color icons in the lib-mac Images file, which have the
suffix -c and thus cannot load using the new code. My question now is if we
should clean out the Images file, remove all the unsuffixed cicns (like
city20) and rename the color cicns like city20-c to city20, so that they
are loaded instead? Or is it perhaps time to scrap the lib-mac Images file?
It is really not needed any longer after I added support for the imf format
in the Mac interface colors and terrain menus.

- --------------------------------------------------------------------------------
- ---------------------------------------------