More bugs.

More bugs.

[Mark A. Flacy]

This is the current CVS version, with this latest Changelog entry:

2004-01-01  Hans Ronne <hronne@comhem.se>
 
        Fix so that the curses interface does not choke on games
        like Bellum that generate messages during run_turn_start.
        * cdraw.c (show_cursor): Return if we lack curunit.


I've been playing Bellum, so the bugs are reported from there.

1) If a build of a base/town/grand citadel is interrupted for any reason,
   you are not able to finish building the installation.  You get a "no
   room" error.

2) Once you get a "no room" error, any other unrelated build requests are
   treated as an attempted repeat of the last build command for the
   remainder of the turn.  

3) You are no longer able to assign multiple engineer units to build the
   same base.  You are no longer able to assign multiple germinators to
   build the same grand citidel.  (No doubt a different manifestation of
   bug #1.) 

4) Patrol boats will not leave a sea base unless the destination is
   adjacent.  Frigates will leave a sea base even if the destination is
   distant. 


-- 
 Mark A. Flacy
 Any opinions expressed above are my own.  Any facts expressed above
 are, ummm, facts.

Re: More bugs.

[Hans Ronne]

>I've been playing Bellum, so the bugs are reported from there.
>
>1) If a build of a base/town/grand citadel is interrupted for any reason,
>   you are not able to finish building the installation.  You get a "no
>   room" error.

The reason is that the new build code checks if there is room to create a
new unit, and returns an error if there is not. Which will happen if you
are just resuming an old build task. I'll see what I can do about this.

>2) Once you get a "no room" error, any other unrelated build requests are
>   treated as an attempted repeat of the last build command for the
>   remainder of the turn.

This is a feature, not a bug :-). You are now supposed to finish the build
command by picking another location where you can really build before
proceeding to the next unit. The idea is that instead of repeating the
build command you just have to click once more on the map if you make a
mistake the first time.

However, resume build tasks will have problems here, too.

>3) You are no longer able to assign multiple engineer units to build the
>   same base.  You are no longer able to assign multiple germinators to
>   build the same grand citidel.  (No doubt a different manifestation of
>   bug #1.)

Yes.

>4) Patrol boats will not leave a sea base unless the destination is
>   adjacent.  Frigates will leave a sea base even if the destination is
>   distant.

This is a bug that you also see with land units. See the recent posts by
Brian Dunn, Jim Kingdon and myself. Probably related to recent changes to
the path-finding code. I'm looking into it.

Hans

Re: More bugs.

[Jim Kingdon]

> This is a feature, not a bug :-). You are now supposed to finish the build
> command by picking another location where you can really build before
> proceeding to the next unit. The idea is that instead of repeating the
> build command you just have to click once more on the map if you make a
> mistake the first time.

I hope you are joking :-).

There is nothing on the screen to indicate that you are supposed to
finish the build command.  Normal commands (like "z") all of sudden
have their strange modal behaviors.

And I wasn't even successful at getting out of it by typing escape.

I vote for having an error get you out of any mode.

Re: More bugs.

[Mark A. Flacy]

>>>>> "Hans" == Hans Ronne <hronne@comhem.se> writes:
Hans> 
Hans> This is a feature, not a bug :-). You are now supposed to finish the
Hans> build command by picking another location where you can really build
Hans> before proceeding to the next unit. The idea is that instead of
Hans> repeating the build command you just have to click once more on the
Hans> map if you make a mistake the first time.

My description was probably misleading.

I get that message even when I've canceled the original build request and
moved on to another unit and attempt to build something entirely different.
I'd say that some state didn't get cleaned up from the cancellation, but it
wasn't immediately obvious where to set the breakpoint to find out (ie, I
spent almost no effort to find it).


-- 
 Mark A. Flacy
 Any opinions expressed above are my own.  Any facts expressed above
 are, ummm, facts.

Re: More bugs.

[Hans Ronne]

>Hans> This is a feature, not a bug :-). You are now supposed to finish the
>Hans> build command by picking another location where you can really build
>Hans> before proceeding to the next unit. The idea is that instead of
>Hans> repeating the build command you just have to click once more on the
>Hans> map if you make a mistake the first time.
>
>My description was probably misleading.
>
>I get that message even when I've canceled the original build request and
>moved on to another unit and attempt to build something entirely different.
>I'd say that some state didn't get cleaned up from the cancellation, but it
>wasn't immediately obvious where to set the breakpoint to find out (ie, I
>spent almost no effort to find it).

OK. I'll look into what happens on cancellation.

Hans

Re: More bugs.

[Hans Ronne]

>> This is a feature, not a bug :-). You are now supposed to finish the build
>> command by picking another location where you can really build before
>> proceeding to the next unit. The idea is that instead of repeating the
>> build command you just have to click once more on the map if you make a
>> mistake the first time.
>
>I hope you are joking :-).

No. If this works the way it is supposed to (and it does in the Mac
interface) it helps a lot. Not only do you get a second chance to pick a
valid build location, but you are also told why the first location did not
work. I am testing the same kind of rapid feedback with the move-to command
right now, and it is even more useful there.

The reason why we need something like this is the new path-finding code. If
you pick a build or move-to target far away and the path-finding discovers
that it is unreachable, the task just fails and the unit does nothing.
There have already been bug reports on the list that are related to this.
We need to tell the human player early on that this will not work and give
him a second chance.

Obviously, there is some problem with cancelling the command in the tcltk
interface, but I think that is fixable.

>There is nothing on the screen to indicate that you are supposed to
>finish the build command.  Normal commands (like "z") all of sudden
>have their strange modal behaviors.

I'll add a notification message: "Please pick a new location."

>And I wasn't even successful at getting out of it by typing escape.

I'll look at the cancellation code again. It works in the mac interface,
but there may be a tcltk-specific problem here.

>I vote for having an error get you out of any mode.

You never get far as a task error with the new code. The idea was to avoid
task errors and the associated waste of acps and/or time.

Hans

Re: More bugs.

[Eric McDonald]

On 4 Jan 2004, Mark A. Flacy wrote:

> 2) Once you get a "no room" error, any other unrelated build requests are
>    treated as an attempted repeat of the last build command for the
>    remainder of the turn.  

I think this is a manifestation of a bug that has been around for 
quite some time. I have noticed this in slightly different 
contexts.

Also the "prefixarg" does not get cleared out as it should. If one 
cancels a command, then the previous numeric repeat argument is 
recycled rather than reset. I had intended to fix it soon, but 
from skimming later posts, it looks like Hans has volunteered to 
do it.

> 4) Patrol boats will not leave a sea base unless the destination is
>    adjacent.  Frigates will leave a sea base even if the destination is
>    distant. 

Interesting. I will look into it as soon as I get settled into my 
new dwelling.

Eric

Command pre-flight checks

[Hans Ronne]

I have now checked in fixes to the new build command pre-flight code.
Setting a resume build task should now work, as should making more than one
unit build on the same target. The modal mode can now again be exited by
hitting the escape key. Finally, more feedback messages have been added so
that the user knows what he is supposed to do (i.e. click on the map again
if the first click fails).

You can get several kinds of build error messages. One is if there is no
room for a new unit in the selected cell. Another is if a mobile builder
cannot get within create-range of the target cell. This pre-flight check
uses the new path-finding code. A third kind of error is if an immobile
builder is out of build range.

More importantly, I have implemented the same pre-flight checks for the
move and move-to commands. This means that commands to move somewhere (by
using either 'm' or clicking on the map) may fail even before execution,
and the computer will in that case tell you why. You then get a second
chance to issue a correct command while staying in modal mode.  The most
common errors are that the terrain has no room for your unit, or that no
path exists that will take you there.

This is how unit type selection already works in the tcltk interface (the
computer will beep if you hit an invalid key and give you a second chance)
so it should not be too difficult to adapt to. It does save a lot of time
since you don't have to reissue the 'P' or 'm' command if you make a
mistake.

The ability to issue certain commands is affected right now by two bugs in
the path-finding code :

1. Failure of units to exit transports when you click several cells away.
This bug appeared quite recently. We should be able to track down exactly
when.

2. Path-finding does not work for transported units, i.e. if you click on
the other side of the sea, you will always get a no-path error, even if the
unit is sitting on a ship that is on its way to the destination. Hopefully,
the improved path-finding code that Peter is working on will fix that.

These two bugs have nothing to do with the new command pre-flight checks,
but there may well be more bugs in the latter code, too, that remain to be
found. Bug reports are welcome.

Hans

Re: Command pre-flight checks

[Jim Kingdon]

> The modal mode can now again be exited by hitting the escape
> key. Finally, more feedback messages have been added so that the user
> knows what he is supposed to do (i.e. click on the map again if the
> first click fails).

This should solve the problem.

What made the previous situation so bad was that the mode was not
visually apparent, and there was no way to get out of it.

Now, the use of messages isn't quite ideal for this (for example, they
go into the message history, and the error message might scroll off if
the window is small), but it is good enough.