Page 1 of 1

Turn change in v2.6

Posted: Wed Oct 10, 2018 10:22 pm
by bard
In previous versions, if playing in "concurrent mode", when a unit was ordered to fortify or to build a tile improvement (requiring 1 turn), and then "end turn" was pressed, the action was finished at the start of the next turn, before the AI units could attack it. It was possible for a worker to finish a road just before it was killed by enemy units after the turn change, or to finish a fortification whose defence would be taken into account for the attacks from the AI.
It was even possible to order a unit to move with "goto" when there were no remaining movement points, and the unit was able to move at the start of the next turn before the AI was able to move or attack.

In current v2.6, it seems this is no longer possible, and the actions ordered at the end of a turn are taken into account only after the AI has already moved the next turn.

I've been unable to find any info about this change in the release notes, or the forums, or the bug tracker. Could you confirm if this behavior have been changed? and if so, to point me to related issue in hostedredmine.

Re: Turn change in v2.6

Posted: Thu Oct 11, 2018 12:41 am
by cazfi
There's a recent commit (after 2.6.0) that sounds related:

commit 72f212b545d1d6d6bca18d172c14057ec5e10e3e
Author: mir3x <>
Date: Mon Aug 20 21:57:28 2018 +0200

Server - move AI phase before player activities/orders phase

See hrm Bug #769791

Re: Turn change in v2.6

Posted: Thu Oct 11, 2018 2:09 am
by bard
Thank you, that's it.

I'm liking the movement of AI before the goto moves. But I'm not liking the AI attacking before the fortify action is taken into account. It has a big impact in gameplay, and it makes fortifications very different from concurrent multiplayer games.

I think the same result of this patch can be achieved by playing against the AI in "alternate turn mode". I prefer to keep the old behavior of "concurrent turn mode" for now. I'll revert to 2.6.0 then.

Re: Turn change in v2.6

Posted: Fri Oct 19, 2018 5:01 am
by cazfi
The change has been reverted now.

Re: Turn change in v2.6

Posted: Mon Oct 22, 2018 6:03 pm
by nef
Being a newbie at this I am confused about the default "internal" option "All players move concurrently". As a single player (and this forum is SP), this text of this default option seems incongruent with the fact that I am alternating with the AI. [should the text be changed to "AI players ...."?] Would someone take the time to enlighten me?

Having played fc from 2.4.4 I noticed that there was a distinct difference between fc and Civ I when it comes to city processing. In Civ I if you waited until an AI (notably barbs) turned up on your doorstep you were too late, your goose was cooked. You could NOT build any defense unit or improvement before the AI attacked.

It was only over a period of time that I also noticed that you get a free turn (advance) if you used automated moves (Goto, goTo, eXplore, patrol (q)). It was/is therefore possible to have defensive units 6 tiles away and still protect a city (along with a huge variety of other exploits). Changing this to what it should be (3) is a major change to gameplay and should perhaps be introduced with some warning and consideration to unsuspecting users.

HACKING wrote:The server main loop basically looks like:

while (server_state == RUN_GAME_STATE) { /* looped once per turn */
do_ai_stuff(); /* do the ai controlled players */
sniff_packets(); /* get player requests and handle them */
end_turn(); /* main turn update */

If this code is still there then it is (or contributes to) the problem. This top level code should be in quadrature, that is there should be an interlude between the two alternating players: me as one and all the AI as a collective other. Each interlude should include an epilogue for the player who has just finished (by hitting "Turn Done") followed by a prologue for the next player to move. I presume in fc that (my) city processing is done in end_turn, and that automated moves are either done here, game_next_year, or somewhere in do_ai_stuff. If this was properly formulated one could then have a clear understanding of what happens when. Indeed, some aspects of this should be softcoded so that, for example, the ruleset author can specify if defense building is traditional fc or traditional Civ I.

Now as to an issue that bard often refers to: that of gardening, I have to say I now have no clear idea of what is going on. Making some observations on fc 2.5.11 and fc 2.6.0 I have noticed that the free turn is erratic especially when it comes to gardeners (settlers etc.) (even just Goto) so it may be that some AI moves come first, then my auto moves then the remaining AI moves. Am I reading too much into this by suspecting that the current code is working correctly for some activities but fixing the code for others is now breaking this existing code? This suggests that there was an ad hoc approach to solving individual problems. Now I may be well out of line here but as a maintenance code cutter my general policy of fixing a bug was to remove the bad code (often pages at time). Typically I had to actually add a few lines back - but not always. In this case, it seems to me that the simple solution is to create a prologue for EACH player where ALL that player's automated moves are done. I think this would solve bard's problem with stacked engineers building a fortress when they can reach a tile with MP left (i.e. the "action" is 'automated' as per fortify). This would remove the need for the Stack Death option for fortresses. [There is a touch of irony here because in Civ I there was a well known exploit where you could always do whatever gardening you wanted (with just one settler) if you had mp left.] For those players that are moving concurrently the sets {prologue,moving,epilogue} are the procedural units to run in parallel - the members within each set are of course sequential. May I assert that this conceptualisation will be essential (and convenient) if/when multitasking is employed since it will be the set {...} that will be identified with the task. [Having said that there are some clear pitfalls for those not so familiar with multitasking - in this case there are plenty of competitions so one will need an umpire.]

As noted above this prologue should also be where city processing is done if you want Civ I compliance. If you want to continue with the current fc paradigm then the city processing should be done in a clearly marked epilogue [hence my suggestion about softcoding].

I would like to add an anecdote about Civ I which illustrated that in Civ I the AI actually got a free turn. In one game an AI during its turn researched automobile, changed city production to armor, which completed, and then deployed, all before I had a chance to defend myself.

cazfi wrote:It's more than balance issue. It's wrong that AI makes unit moves of the new turn before end of previous turn, as with currently applied patch. I have not looked closely what kind of bugs it introduces, though. I don't know if AI will move newly built units at all (or will they be finished in the end of the turn only after AI already moved), or does it get a benefit of getting to attack with units that it loses because of lack of maintenance, or does it get bonuses of previous turn's government instead of new turn's etc etc.
The correct fix would be to make cleaner separation of turn-end and turn-begin actions (goto with fresh movement points would belong to latter) and to execute AI between them.

Neat summary.

The key point is that sequencing should be transparent and obvious. Moving it to the ruleset would make this so. I will add that IMHO the rules (as expressed by prologue/epilogue processing) should apply to ALL players individually, that is it is (or should be) not just a turn-end turn-begin ai-in-between issue. Example rule for Civ I {city-processing, auto-moves, player-moves}; for traditional fc {auto-moves, player-moves, city-processing}. I have taken a notational liberty here: anything before "player-moves" is prologue, after is epilogue, and either could be null so the ruleset defines what is in each of prologue and epilogue as sets in their own right. e.g. prologue = city-processing, auto-moves. One could subdivide city-processing but that is a whole new can of worms best left for another day.

If one really wanted to creep the elegance (i.e. have the option for asymmetry) then you could add Effects to alter what is done where within the set {...}.

One final note: the free turn is not entirely a free lunch. If/when an automated unit is stopped (by being blocked or by patrol noticing something), the offending foreign unit is long gone by the time you get focus. Removing this free turn would go a long way to solving this problem.