Discussion:
[Freecol-developers] Skipping the turn should mean skipping the turn...
William Astle
2015-07-31 20:24:25 UTC
Permalink
Of all the little niggles that I never get motivated to write down, this
one finally got my attention today.

I don't think this is exactly a bug, but it does annoy me regularly. It
might be partly my play style ("mega stacks of doom") but I can't be the
only one who does that. After all, that's what the REF does. :)

When I press "space" for a unit to skip the turn, I expect that to mean
that it will not pop up and ask me for orders again during that turn.
That's what "skip" means. If I wanted it to ask me again, I'd use the
"wait" command.

Now ordinarily, it behaves as I expect. However, there is one case where
it doesn't. That is, when I move another unit to the same tile where
units have been told to "skip" the turn. The other unit arriving wakes
up the units that were told to skip the turn. It's not so bad when there
is one or two units there. However, when you are marshalling a stack of
artillery, dragoons, and soldiers, this can easily end up waking up 30
or 50 or more units depending on the stack, all of which were told to
"skip" the turn.

If I really wanted to wake those units for orders again, I can select
them, or wake all the units on the tile.

The same thing happens when loading a saved game. All the units that
were previously told to "skip" the turn are now waiting for orders
again. (Not everyone saves the game at the start of a turn.)

It seems to me that the units need to stay in the "skip" state unless
activated somehow, and they need to remember that "skip" state across
saves. The latter is probably more problematic.

At the very least, the "activate all units with movement left when
moving other units into the tile" behaviour needs to be configurable. I
can see a case for it if the units in the tile haven't already been
given orders, but if they've already been told to "skip", they shouldn't
be activated again.

------------------------------------------------------------------------------
Michael T. Pope
2015-08-03 09:41:44 UTC
Permalink
On Fri, 31 Jul 2015 14:24:25 -0600
William Astle <***@l-w.ca> wrote:
> Of all the little niggles that I never get motivated to write down, this
> one finally got my attention today.
>
> I don't think this is exactly a bug, but it does annoy me regularly. It
> might be partly my play style ("mega stacks of doom") but I can't be the
> only one who does that. After all, that's what the REF does. :)

The REF has a lot more patience than humans. Keep hoping we implement
unit grouping one day. I just went through the IR list and closed two
duplicate requests for it, and another one on the FC2 list IIRC.

> When I press "space" for a unit to skip the turn, I expect that to mean
> that it will not pop up and ask me for orders again during that turn.
> That's what "skip" means. If I wanted it to ask me again, I'd use the
> "wait" command.
>[lots more]

Thanks for the detailed description. In short, you are quite right, this
is broken and annoying, probably is a bug, and its worse that you mention
in that everything can get woken up again after the trade route and/or
goto orders are executed.

Clearly the semantics of "Skip" have drifted with time. It may take a bit
of trial and error, but we should be able to bring it back to "skip
really means skip". There is some internal weirdness with units that are
given a move that can not be completed immediately, units with long
distance goto orders, and units that have had their moves removed for
special reasons (e.g. trade haggle fail), hence my caution. Which if any
of these (including explicitly skipped units) should appear in the End Turn
panel is another question. I am assuming that if you skip a unit, you
would *not* want its potential for movement zeroed out, so that it would
still be able to be activated by hand and moved.

Cheers,
Mike Pope
William Astle
2015-08-03 17:16:49 UTC
Permalink
On 2015-08-03 03:41, Michael T. Pope wrote:
> On Fri, 31 Jul 2015 14:24:25 -0600
> The REF has a lot more patience than humans. Keep hoping we implement
> unit grouping one day. I just went through the IR list and closed two
> duplicate requests for it, and another one on the FC2 list IIRC.

Indeed, and the fact that it's a patience issue is a good reason to hold
trying to implement that until FC2. Individual unit moves are tedious
but functional. Also, my mega stacks of doom are usually smaller than
the REF's.

>> When I press "space" for a unit to skip the turn, I expect that to mean
>> that it will not pop up and ask me for orders again during that turn.
>> That's what "skip" means. If I wanted it to ask me again, I'd use the
>> "wait" command.
>> [lots more]
>
> Thanks for the detailed description. In short, you are quite right, this
> is broken and annoying, probably is a bug, and its worse that you mention
> in that everything can get woken up again after the trade route and/or
> goto orders are executed.
>
> Clearly the semantics of "Skip" have drifted with time. It may take a bit
> of trial and error, but we should be able to bring it back to "skip
> really means skip". There is some internal weirdness with units that are
> given a move that can not be completed immediately, units with long
> distance goto orders, and units that have had their moves removed for
> special reasons (e.g. trade haggle fail), hence my caution. Which if any
> of these (including explicitly skipped units) should appear in the End Turn
> panel is another question. I am assuming that if you skip a unit, you
> would *not* want its potential for movement zeroed out, so that it would
> still be able to be activated by hand and moved.

Yes, that assumption is correct. That makes it work the same as
"Fortify" which can be undone by reselecting the unit on the same turn,
which makes it possible to correct an accidental fortify order. However,
if "wait" worked correctly (see below), that would be an option if the
movement was zeroed out for "skip". (Fortify might have some oddness,
too. It seems that when you fortify, you cannot reactivate the unit on
the next turn. You have to wait for the next turn after. That may be
intentional and might even be what Col1 does. It just seemed surprising.
I haven't specifically tested for that behaviour, though, so I might be
misremembering what it was doing. It's usually not a problem since I
usually fortify units for a long term.)

Since sending my original description, I observed some weirdness with
the "wait" order, too, which might be related. I had a dragoon and a
couple of artillery in a tile. I wanted to give the artillery orders so
I pressed "w". The dragon remained active. I had to actually select the
artillery to give it orders first.


------------------------------------------------------------------------------
Michael T. Pope
2015-08-29 04:44:59 UTC
Permalink
On Mon, 03 Aug 2015 11:16:49 -0600
William Astle <***@l-w.ca> wrote:
> On 2015-08-03 03:41, Michael T. Pope wrote:
> > I am assuming that if you skip a unit, you would *not* want its potential
> > for movement zeroed out, so that it would still be able to be activated
> > by hand and moved.
>
> Yes, that assumption is correct. That makes it work the same as
> "Fortify" which can be undone by reselecting the unit on the same turn,
> which makes it possible to correct an accidental fortify order.

OK. Try git.38f8903. Skip should now really mean skip, and a skipped
unit will not be listed in the End Turn dialog.

I have also changed the "really skipped" units to display with an "X"
rather than the old "W" which is confusing with respect to the wait
command, we can not use "S" because that belongs to the sentry state, and
"X" was easy to pick as non-colliding. Better ideas than "X" are welcome.

> Since sending my original description, I observed some weirdness with
> the "wait" order, too, which might be related. I had a dragoon and a
> couple of artillery in a tile. I wanted to give the artillery orders so
> I pressed "w". The dragon remained active. I had to actually select the
> artillery to give it orders first.

"W" operates on the current active unit, so I think it is not unreasonable
for you to have to select a unit to make it wait. The source of the
confusion here might be our ongoing problems making the active unit show
up reliably in the InfoPanel (lower right corner).

Cheers,
Mike Pope
William Astle
2015-08-29 13:54:28 UTC
Permalink
On 2015-08-28 22:44, Michael T. Pope wrote:
> OK. Try git.38f8903. Skip should now really mean skip, and a skipped
> unit will not be listed in the End Turn dialog.
>
> I have also changed the "really skipped" units to display with an "X"
> rather than the old "W" which is confusing with respect to the wait
> command, we can not use "S" because that belongs to the sentry state, and
> "X" was easy to pick as non-colliding. Better ideas than "X" are welcome.

So far, so good. The specific situation that was causing me pain seems
to be solved by this update. I'll report back if I run into any trouble.

There is one thing that seems less than ideal, but I'm not sure that the
current behaviour is necessarily wrong. When a unit does not have
sufficient movement points to enter a tile, it switches to the skip
state but remains active. I'm not sure what the best solution for that
is. It may be that the current behaviour is the right thing. I wonder if
it shouldn't move on to the next available unit in that case.

------------------------------------------------------------------------------
w***@genial.ms
2015-08-29 14:11:55 UTC
Permalink
> Gesendet: Samstag, 29. August 2015 um 15:54 Uhr
> Von: "William Astle" <***@l-w.ca>
> An: freecol-***@lists.sourceforge.net
> Betreff: Re: [Freecol-developers] Skipping the turn should mean skipping the turn...
>
> There is one thing that seems less than ideal, but I'm not sure that the
> current behaviour is necessarily wrong. When a unit does not have
> sufficient movement points to enter a tile, it switches to the skip
> state but remains active. I'm not sure what the best solution for that
> is. It may be that the current behaviour is the right thing. I wonder if
> it shouldn't move on to the next available unit in that case.

That will fix itself as soon as PF#30 is implemented:
https://sourceforge.net/p/freecol/pending-features-for-freecol/30/

------------------------------------------------------------------------------
Michael T. Pope
2015-08-29 22:03:39 UTC
Permalink
On Sat, 29 Aug 2015 16:11:55 +0200
***@genial.ms wrote:
> > Von: "William Astle" <***@l-w.ca>
> > There is one thing that seems less than ideal, but I'm not sure that the
> > current behaviour is necessarily wrong. When a unit does not have
> > sufficient movement points to enter a tile, it switches to the skip
> > state but remains active. I'm not sure what the best solution for that
> > is. It may be that the current behaviour is the right thing. I wonder if
> > it shouldn't move on to the next available unit in that case.
>
> That will fix itself as soon as PF#30 is implemented:
> https://sourceforge.net/p/freecol/pending-features-for-freecol/30/

I am still hesitant over PF#30, and ideally would like more confirmation.
There are two proposed mechanisms, of which I *much* prefer your
suggestion, which is easy to understand and to implement, while the other
is potentially confusing and needs save format changes. I recommend we
finish other PFs first.

The "skipped but active" units are indeed a special case. There are a
couple of places where this trick is used within the *client* to signify
some reason the unit can not proceed. However it is in the old "skipped
does not really mean skipped" state, in that the state has *not* been
propagated to the server, and as soon as the unit is updated for whatever
reason it will drop back to the default state. This is indeed not ideal,
so I will have a look at the use cases and see if something better is
possible.

Cheers,
Mike Pope
w***@genial.ms
2015-08-30 05:52:21 UTC
Permalink
Hi,

> Gesendet: Sonntag, 30. August 2015 um 00:03 Uhr
> Von: "Michael T. Pope" <***@computer.org>
>
> On Sat, 29 Aug 2015 16:11:55 +0200
> ***@genial.ms wrote:
> > That will fix itself as soon as PF#30 is implemented:
> > https://sourceforge.net/p/freecol/pending-features-for-freecol/30/
>
> I am still hesitant over PF#30, and ideally would like more confirmation.
> There are two proposed mechanisms, of which I *much* prefer your
> suggestion, which is easy to understand and to implement, while the other
> is potentially confusing and needs save format changes. I recommend we
> finish other PFs first.
>

My impression is, that the OP of PF#30 correctly found that there is _some_
mechanism that allows making use of partial moves, but then imagined some
logic inside Col1 which never existed and immediately disproved his own
guess by saying sometimes he can do more moves than his complicated, guessed
mechanism would allow.
I'd take the answer to my guess as confirmation it was correct and would
think this is enough to implement it (its simple and more correct than now),
but would then let the PF open to gather more information, asking if all
corner cases are done right and in same way as in Col1.
Anyway, its in the hands of the person choosing to implement something
to decide which gets done first, and thats mostly you atm. ;)


Regards,

wintertime

------------------------------------------------------------------------------
Loading...