xconq 7.5a (win32)

xconq 7.5a (win32)

[Tyson & Dina Ackland]

I have followed this game for years when it originally came out on X11.  
Was delighted to find this Windows version now that I have a home LAN 
and have been playing it with my son.

Couple of problems though:
1. Sometimes the selected item won't move.  When this happens, I 
minimise and then restore the window and find a different item is 
selected and this one I can move.
2. I have yet to complete a net game - at some point, a message appears 
saying the checksum doesn't match and the game appears to become 
unresponsive soon after.
3. Just now, I attempted to restore a saved game from it's save file and 
a number of warnings were reported as it restored including "colour of 
units changing" etc.  I decided to ignore future warnings and the game 
restored but the map image was corrupted and refused to come good so the 
game was impossible to continue with.

 From memory, these sorts of quirks have been around since the beginning 
as I remember having problems restoring save files back on X11 too as 
well as the game occassionally locking up etc.  It's a pity as it 
renders an otherwise unparalleled open-source strategy game into a "I'll 
play it if I'm really bored" sort of game.  What keeps bringing me back 
is it's addictive and I always hope I'll have no problems in the game 
but if the game play takes too long, one of these show-stoppers usually 
occurs.  If the developers could concentrate on rectifying these 
algorithm fundamentals and leave the interface/porting upgrades for a 
while, I think your game would be a real winner!

Cheers and all the best.

Re: xconq 7.5a (win32)

[Eric McDonald]

Hi,

On Mon, 26 Apr 2004, Tyson & Dina Ackland wrote:

> Was delighted to find this Windows version now that I have a home LAN 
> and have been playing it with my son.

I will hopefully be releasing a newer Windows installer later on 
this afternoon. Perhaps, the new executables will address some of 
the things you have been seeing. In particular, I think some of 
the networking code has been improved since the last time I 
released Windows executables.

> Couple of problems though:
> 1. Sometimes the selected item won't move.  When this happens, I 
> minimise and then restore the window and find a different item is 
> selected and this one I can move.

Can you specify under what circumstances the unit won't move?

> 2. I have yet to complete a net game - at some point, a message appears 
> saying the checksum doesn't match and the game appears to become 
> unresponsive soon after.

This problem might be addressed with the new release. If it isn't 
please let us know.

> 3. Just now, I attempted to restore a saved game from it's save file and 
> a number of warnings were reported as it restored including "colour of 
> units changing" etc.  I decided to ignore future warnings and the game 
> restored but the map image was corrupted and refused to come good so the 
> game was impossible to continue with.

I think this one was fixed too. Again, let us know if it's not 
with the new executables.

>  From memory, these sorts of quirks have been around since the beginning 
> as I remember having problems restoring save files back on X11 too as 
> well as the game occassionally locking up etc. 

There have been some stability improvements too. :-)

> It's a pity as it 
> renders an otherwise unparalleled open-source strategy game into a "I'll 
> play it if I'm really bored" sort of game.  

We're working to change this.... It's one of the reasons why we 
are more than a year behind the originally intended 7.5 release 
date.

>What keeps bringing me back 
> is it's addictive

That's what brought me back after 3+ years. (And the lack of a 
Linux/X11 port of Empire Master....)

> but if the game play takes too long, one of these show-stoppers usually 
> occurs.  

Please let us know if you run into any more showstoppers than the 
ones mentioned above.

>If the developers could concentrate on rectifying these 
> algorithm fundamentals and leave the interface/porting upgrades for a 
> while, I think your game would be a real winner!
> 
> Cheers and all the best.

Thanks.

  Regards,
    Eric

Re: xconq 7.5a (win32)

[Hans Ronne]

>2. I have yet to complete a net game - at some point, a message appears
>saying the checksum doesn't match and the game appears to become
>unresponsive soon after.

Is this a real network game or one between two instances of Xconq on the
same machine? I'm asking because almost all debugging of the network game
was done on one machine, for obvious reasons. Then only serious real
network debugging that I know of took place 2 years ago when Jim Kingdon
and I got rid of the last sync error.

The status of the network game is as follows. Prior to the addition of
Peter Garrone's path-finding code the network game was completely stable
(no desyncs at all). Unfortunately, the path-finding code reintroduced
desync at a low frequency, which is most likely what you are seeing. Eric
and I have discussed what to do about this, whether to take out the
path-finding code (a great addition) or try to fix it.

In any case, bug reports from network games are most welcome. I have asked
for such reports before on this list, but didn't get much feedback. What
would be very useful if you experience a desync is an auto-saved game from
the preceding turn. Also useful would be debugging output files, if you run
your game with debugging on. Xconq will generate two debug files if you run
a network game: Xconq-Master.DebugOut and Xconq-Client.DebugOut. There are
also the two files Xconq-Master.Csums and Xconq-Client.Csums which are
created automatically if a network game desyncs.  A bug report with these
files attached would be welcome. However, don't post big attachments to
this list. Mail it directly to me (or Eric) instead.

>3. Just now, I attempted to restore a saved game from it's save file and
>a number of warnings were reported as it restored including "colour of
>units changing" etc.  I decided to ignore future warnings and the game
>restored but the map image was corrupted and refused to come good so the
>game was impossible to continue with.

This complaint about a changed colour palette when restoring saved games is
an old problem. As far as I recall it is harmless on the other platforms
but does mess up the Windows interface. I'll see if I can finally figure
out what to do about it.

> From memory, these sorts of quirks have been around since the beginning
>as I remember having problems restoring save files back on X11 too as
>well as the game occassionally locking up etc.

The new (tcltk, MacOS, SDL) network game is completely different from the
old X11 network game. It is played between multiple apps on different
machines, while the X11 network game was played using one app on one
machine with a remote display for each player. The possibility of restoring
a network game from saved files did not even exist with the new code until
I added it just before Christmas. So we are still working hard on those
fundamentals that you mention. However, fixing interface bugs is important,
too. If your app crashes all the time in the interface code it doesn't
really matter if it would desync eventually. The MacOS X app is now much
more stable than it was just one week ago.

Hans

Path finding

[Brian Dunn]

> Prior to the addition of Peter Garrone's path-finding code


A bit of a problem since the path-finding stuff went in a month or two ago:

When trying the Middle Earth third age module, the base module for Lord of the Rings, large number of armies in the game are not allowed to cross rivers.  There are some fords, but they cannot cross just anywhere.  This is by game design.  Meanwhile, a lot of rivers are made.  This results in only a few choke points where armies may cross.  This makes the new pathfinding code seem to take much much longer per turn to think things through.  Before that path finding change, the turns went quite a bit faster.

I cannot guarantee that the path-finding code itself was the change which made the difference, because I think I remember that a lot of changes were being made at the same time back then.

---

Another thing is that the standard game doesn't make or use transports.  Try setting up a standard game between a few computer players and watch what they do for a few turns.

---

STILL no crashes on my Linux box since your fixes to the TCL map redrawing code!



Brian

Re: Path finding

[Eric McDonald]

Hi Brian,

On Tue, 27 Apr 2004, Brian Dunn wrote:

> A bit of a problem since the path-finding stuff went in a month 
>or two ago:

His Astar implementation has been in the source tree since the 
closing months of last year. We started earnestly debating about 
withdrawing it about a month or two ago.

>where armies may cross.  This makes the new pathfinding code seem 
>to take much much longer per turn to think things through.  
>Before that path finding change, the turns went quite a bit 
>faster.

This is symptomatic of all the games when using the new 
pathfinding code, though some feel the pain worse than others. 
However, in theory, it should do a better job at actually finding 
a path.

> Another thing is that the standard game doesn't make or use 
>transports.  Try setting up a standard game between a few 
>computer players and watch what they do for a few turns.

I believe this has something to do with Hans fiddling with 
roll_dice or some such call. It was part of a hack to get rid of 
some of the sync errors that the pathfinding created.

When I get around to working on the pathfinding and movement code, 
I will probably roll back the new pathfinding, if Hans doesn't do 
it first. At that time, I will undo any other little hacks that 
hobbled Xconq in an attempt to get rid of sync errors.

> STILL no crashes on my Linux box since your fixes to the TCL 
>map redrawing code!

Good.

  Regards,
    Eric

Re: Path finding

[Hans Ronne]

>> Another thing is that the standard game doesn't make or use
>>transports.  Try setting up a standard game between a few
>>computer players and watch what they do for a few turns.
>
>I believe this has something to do with Hans fiddling with
>roll_dice or some such call. It was part of a hack to get rid of
>some of the sync errors that the pathfinding created.

No, my hack had nothing to do with transportation. It just eliminated a
flip_coin call where xconq would chose randomly between two equally good
move directions. By making the code more deterministic, I was able to fix
some (but not all) of the sync errors.

The real reason why transportation does not work any more is simply that it
is not supported i the current version of the path-finding code. Peter was
working on a version that did, but he never finished the job.

Hans

Re: Path finding

[Eric McDonald]

On Tue, 27 Apr 2004, Hans Ronne wrote:

> No, my hack had nothing to do with transportation. It just eliminated a
> flip_coin call where xconq would chose randomly between two equally good

Oh, that's right. It was flip_coin. I thought that the greater 
determinism had affected production in some way, but I must be 
confusing it with something else. Sorry.

Eric

Re: Path finding

[Jim Kingdon]

> Another thing is that the standard game doesn't make or use
> transports.  Try setting up a standard game between a few computer
> players and watch what they do for a few turns.

I suspect this is the #1 reason why the AI has been doing so poorly
against me lately (this is the standard game).

I'm not sure whether it came on suddenly or gradually, though.  I kind
of suspect the code which decides what to build isn't building enough
armor/infantry, and it doesn't matter whether it has transports,
because they have nothing to transport.  But there could be more than
one problem.  I can clarify the symptom: xconq from about the year
2000 would send a flood of full transports in my direction starting at
turn 30 to 50 or so, which would completely overwhelm me if I wasn't
very careful.  xconq today will send few if any transports.

Re: Path finding

[Hans Ronne]

>> Another thing is that the standard game doesn't make or use
>> transports.  Try setting up a standard game between a few computer
>> players and watch what they do for a few turns.
>
>I suspect this is the #1 reason why the AI has been doing so poorly
>against me lately (this is the standard game).
>
>I'm not sure whether it came on suddenly or gradually, though.  I kind
>of suspect the code which decides what to build isn't building enough
>armor/infantry, and it doesn't matter whether it has transports,
>because they have nothing to transport.  But there could be more than
>one problem.  I can clarify the symptom: xconq from about the year
>2000 would send a flood of full transports in my direction starting at
>turn 30 to 50 or so, which would completely overwhelm me if I wasn't
>very careful.  xconq today will send few if any transports.

That's an interesting observation. I have also that the standard game now
seems to favour building aircraft and naval units, but not enough ground
units. I believe this happened maybe one year ago when there were some
changes to the unit worth functions, in particular exploring_worth. I
remember there was a discussion on the list about that.

Today, if you run the Intro game, at least one of the sides usually builds
just bombers, and therefore eventually looses the game.

There is however, a real problem with transportation, since the transport
code is broken right now because of the path-finding.

Hans

RE: xconq 7.5a (win32)

[Frank Gulia]

Please remove me from this distribution list.

Thank You

-----Original Message-----
From: xconq7-owner@sources.redhat.com
[mailto:xconq7-owner@sources.redhat.com] On Behalf Of Tyson & Dina
Ackland
Sent: Sunday, April 25, 2004 5:20 PM
To: xconq7@sources.redhat.com
Subject: xconq 7.5a (win32)


I have followed this game for years when it originally came out on X11.

Was delighted to find this Windows version now that I have a home LAN 
and have been playing it with my son.

Couple of problems though:
1. Sometimes the selected item won't move.  When this happens, I 
minimise and then restore the window and find a different item is 
selected and this one I can move.
2. I have yet to complete a net game - at some point, a message appears 
saying the checksum doesn't match and the game appears to become 
unresponsive soon after.
3. Just now, I attempted to restore a saved game from it's save file and

a number of warnings were reported as it restored including "colour of 
units changing" etc.  I decided to ignore future warnings and the game 
restored but the map image was corrupted and refused to come good so the

game was impossible to continue with.

 From memory, these sorts of quirks have been around since the beginning

as I remember having problems restoring save files back on X11 too as 
well as the game occassionally locking up etc.  It's a pity as it 
renders an otherwise unparalleled open-source strategy game into a "I'll

play it if I'm really bored" sort of game.  What keeps bringing me back 
is it's addictive and I always hope I'll have no problems in the game 
but if the game play takes too long, one of these show-stoppers usually 
occurs.  If the developers could concentrate on rectifying these 
algorithm fundamentals and leave the interface/porting upgrades for a 
while, I think your game would be a real winner!

Cheers and all the best.

RE: xconq 7.5a (win32)

[Eric McDonald]

There is mailing list management info that is part of each 
message. This tells you how to unsubscribe. Also, see:
 http://sources.redhat.com/lists.html

On Tue, 27 Apr 2004, Frank Gulia wrote:

> Please remove me from this distribution list.
> 
> Thank You