This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: playable again with a few problems
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Tom Low-Shang <tlow at low-shang dot homelinux dot com>
- Cc: xconq7 <xconq7 at sources dot redhat dot com>
- Date: Sat, 15 May 2004 22:30:18 -0600
- Subject: Re: playable again with a few problems
- References: <20040516040055.GC6324@low-shang.homelinux.com>
Tom Low-Shang wrote:
Xconq is playable again and there was much rejoicing! :-)
:-)
Thanks
to all the developers for their efforts, but I must regretfully
report that there still some problems.
Have no regrets about reporting Xconq bugs.
1. The fuel supply low condition is higher than before. Fighters
run low on fuel at 10 instead of 9 and bombers run low at 21
instead of 18. Is this new behaviour expected? Fighters and
bombers run low on fuel more frequently the other types, so I
have not seen what happens with other units.
I changed the halfway point calculation to conform to a unit's resupply
percentage doctrine a few months ago. Perhaps this is causing the
problem. I will look into it later.
2. When a unit's task ends without player intervention, the unit
status still shows the task even though the unit itself shows it
is selected, which is a little confusing. Example: A fighter is
doing a move-direction-multiple task and runs low on fuel.
I think that the task is still there in such cases. Probably the display
needs to add "(Suspended)" somewhere in the task description.
3. The resupply command does not work if the unit has to move to
the resupply point first. Because of problem #2 you can see that
the move to and resupply tasks were setup, but the unit does
nothing and just reverts to the selected state. If you move the
unit to the resupply point first, the resupply command works
correctly.
That sounds odd. I will look into it at some point in the near future.
4. Move-direction-multiple is blocked by friendly units. This is
not new behaviour and I just accepted it before,
but it suddenly
occured to me that this is not what I would expect. Is this
behaviour intentional?
No, it is most definitely not, and I certainly thought it was fixed. In
my test cases, it did work correctly. You are using recent CVS sources,
right?
Also, could the blocking friendly unit have been filled to capacity with
other units?
5. This one is definitely strange and problably not even
reproducible. After canceling the build task in several towns,
they were unable to build anything again.
Oh jeez, another create/build bug.... Apparently I fixed 2 bugs and
created a million new ones.
They would accept the
produce command but sometimes they would revert to the selected
state, and other times the town would appear to start building,
but the next turn it would be passive again.
A unit will stop building if it runs out of a material. But, if this was
with the standard game, I would find it hard to believe that that would
occur.
In the cases where the unit immediately reverts to the selected state,
could it be that the unit is filled entirely to capacity with other units?
Eventually some of
the towns would build again, except for one which stubbornly
refused to build anything. I saved the game thinking it might
tell you something, but the problem disappeared in the reloaded
game.
Ugh. Did you get any init warnings about units not being able to be
placed in a cell when you restored the game?
Would -D have helped in this case?
Possibly. Every time a task is run, there is diagnostic output (when
this flag is set). You could attempt a task and then see what messages
show up on the console window. If nothing shows up, then the problem is
likely at the UI level and not in the game kernel's task system.
Thanks for the feedback,
Eric