Recent Xconq improvements

Recent Xconq improvements

[Hans Ronne]

I have checked in a number bug fixes and improvements to the isometric
drawing code in the last few days. The isometric maps now always stay
within the scrolling limits and there are no longer any black holes or
undrawn regions.

A bug in the non-isometric drawing code that caused half-cells to be drawn
near the dateline has been fixed.

A crashing bug in the classical (non-advanced) build code for exploring
units has been fixed. The classical build code is now also a little more
intelligent when picking units to build. I intend to improve it further so
that it works just like the advanced build code.

Hans

Recent Xconq improvements

[Hans Ronne]

It is no longer possible to crash the tcltk interface by just closing a map
window. This was a major bug that should have been fixed a long time ago,
but it was a little tricky to solve in the right way.

I have now also implemented a Windows menu similar to that in the Mac
interface, where all available maps (also those that have been closed) are
listed and can be readily accessed.

If you have only one map left and try to close it Xconq will now refuse to
do so. This is not because of the crashes, which have been fixed, but
because Unix and Windows users need at least one open map to access the
Windows menu and get back into the game (Mac users would keep their menubar
even if all windows were closed).

The new Help menu has already been discussed. Thanks to Peter Garrone for
the original idea. It makes the help system much more accessible.

Both Xconq and Imfapp have received new high resolution icons for Windows
XP and Mac OSX.

There has been a major overhaul of the window managing code in the Mac
interface. A number of bugs have been fixed, and Xconq now runs without
problems on all Mac OS versions from 8.1 to X.2.

As you already know, Eric has been busy with the Makefiles and the new
Windows installer, but he also had time to add compound terrain visibility
and snprintf support in the last few weeks.

For more details, see the ChangeLog (or subsribe to the CVS update list if
you want the latest news).

Hans

Re: Recent Xconq improvements

[Jakob Ilves]

Hello Hans!

Very intresting work with the AI player.  Could binaries for this be created at your home page? 
If I ask very nicely?  Pleease...? :-D

I'm very eager to try out this new and enhanced AI to see if it get's more difficult to beat it!

(...and yes, I don't have any possibility right now to use CVS, get the latest check in and build
the thing :-/ )

I'm still tweaking the postmodern.g scenario and maybe the changes above would make the AI behave
more sensible (I've seen that the AI has had an annoying tendency of developing engineer troops
which it then sends out for creating lots of cities, towns and villages.  Sure a good idea, if it
wasn't for that it's bad on doing a systematic COMPLETION of all unfinished cities/towns/villages
it leaves lying around :-)

--- Hans Ronne <hronne@telia.com> skrev:
>
[ Lines deleted describing lots of fascinating changes to the Xconq ]
>

Best regards and thanks for keeping up the good work!

/IllvilJa


=====
(Jakob Ilves) <illvilja@yahoo.com>
{http://www.geocities.com/illvilja}

Yahoo! Mail - Gratis: 6 MB lagringsutrymme, spamfilter och virusscan. Se mer på http://se.mail.yahoo.com

Re: Recent Xconq improvements

[Hans Ronne]

>Hello Hans!
>
>Very intresting work with the AI player.  Could binaries for this be
>created at your home page?

As soon as I am done with updating the game modules and readme files I will
make pre-releases for all platforms that include not only binaries but all
the other stuff as well. My work on this has taken a little longer than I
thought it would, but is well under way. Please understand that it takes
some time to go through more than 80 games and 300 associated files.
Moreover, a number of problems that I came across could not be fixed in the
game files, but required kernel hacks. Most of the recent xconq
improvements were in fact prompted by problems that I discovered while
testing the games.

>I'm still tweaking the postmodern.g scenario and maybe the changes above
>would make the AI behave
>more sensible (I've seen that the AI has had an annoying tendency of
>developing engineer troops
>which it then sends out for creating lots of cities, towns and villages.
>Sure a good idea, if it
>wasn't for that it's bad on doing a systematic COMPLETION of all
>unfinished cities/towns/villages
>it leaves lying around :-)

Part of the problem is that the engineers get distracted by nearby enemy
units and lured away from their build task. This is hard to avoid if it
takes 45 turns to build a city. Perhaps one should shorten the build times,
or even make it complete in one turn, with the engineer being consumed in
the process. The ai code is really written for that kind of civ-like
building. Any situation that requires a mobile unit to switch back and
forth between different tasks is problematic. This can be seen also when
transport tasks are interrupted by fighting.

Another problem with the postmodern game is that it takes 50+ turns before
anything happens due to tech development. Perhaps one should give all sides
the ability to build infantry right from start?

Hans

Re: Recent Xconq improvements

[Jakob Ilves]

Hello Hans!

Very intresting work with the AI player.  Could binaries for this be created at your home page? 
If I ask very nicely?  Pleease...? :-D

I'm very eager to try out this new and enhanced AI to see if it get's more difficult to beat it!

(...and yes, I don't have any possibility right now to use CVS, get the latest check in and build
the thing :-/ )

I'm still tweaking the postmodern.g scenario and maybe the changes above would make the AI behave
more sensible (I've seen that the AI has had an annoying tendency of developing engineer troops
which it then sends out for creating lots of cities, towns and villages.  Sure a good idea, if it
wasn't for that it's bad on doing a systematic COMPLETION of all unfinished cities/towns/villages
it leaves lying around :-)

--- Hans Ronne <hronne@telia.com> skrev:
>
[ Lines deleted describing lots of fascinating changes to the Xconq ]
>

Best regards and thanks for keeping up the good work!

/IllvilJa


=====
(Jakob Ilves) <illvilja@yahoo.com>
{http://www.geocities.com/illvilja}

Yahoo! Mail - Gratis: 6 MB lagringsutrymme, spamfilter och virusscan. Se mer på http://se.mail.yahoo.com

Recent Xconq improvements

[Hans Ronne]

I have checked in several important improvements to Xconq during the last
few weeks. Most of them are under the hood and affect how the ai (mplayer)
works:

1. The repair and resupply code has been overhauled and partly rewritten.
Most of the bugs that have plagued it over the years are hopefully gone.
The new code is also more efficient. It uses the landsea_regions area
layer, which is precomputed at the start of the game, to figure out if a
particular repair or resupply point is connected by non-hostile terrain to
the unit in need. Operating ranges and several other parameters are now
also calculated more accurately.

What this all means is that a number of problems that we all are familiar
with are gone. No more units running out of fuel and crashing. No more
units stuck in reserve mode trying to repair or resupply in the field even
though they cannot. No more ships trying forever to reach an inland city
for resupply or repair.

I have also made several doctrine changes that improve ai performance.
Units will now use up all their ammo before going back for more.
Furthermore, when they go back to rearm, resupply or repair, they will do
this to 100%.

Units that have ammo or fuel are now also more generous in sharing it
around. They will now give away up to 50% of their supply to a unit in
need. This has a big impact on how carriers work in the standard game.
Previously, planes would get stuck forever on carriers since the latter
would hold on to fuel and ammo instead of sharing it. Now they really work
as mobile airfields.

2. The other major improvement is an overhaul of the ai construction code.
In particular, I have added code that uses the landsea_regions layer to
figure out if it is meaningful to build naval units in a city. Naval units
being built in inland cities, or cities on small lakes, was a big problem
in many games. The new code checks if a city has water access and how big
the body of water is. If it is too small, no naval units are built.

The cutoff value for minimal sea size can be adjusted on a unit type basis.
Here is how it works:

(add city minimal-sea-for-docks 50)
(add town minimal-sea-for-docks 10)

The city will now build naval units if it borders on a sea or lake of at
least 50 cells. The town will build naval units in smaller lakes, of 10 or
more cells. The default value for all units is 30 cells.

3. There have also been a number of interface improvements. The scorekeeper
output now makes more sense. For alliances, the reported score is followed
by the side's own score in parenthesis. Several scorekeepers can now also
be shown in the tcltk interface (this was previously possible only in the
Mac interface). Several bugs in the weather dispaly code have also been
fixed in both interfaces. For more details on these and other changes, see
the ChangeLog.

Hans