Help has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...

Bug #764974

Trouble choosing defenders in military_advisor_choose_build()

Added by Jacob Nevins almost 4 years ago. Updated almost 4 years ago.

Start date:
Due date:
% Done:


Estimated time:


Looking at code added in gna patch #5471 (debuting in 2.6):

/* Potential defender found */
if (urgency == 0
    && uchoice.value.utype->defense_strength == 1) {
  /* FIXME: check other reqs (unit class?) */
  if (get_city_bonus(pcity, EFT_HP_REGEN) > 0) {
    /* unlikely */
    uchoice.want = MIN(49, danger);
  } else {
    uchoice.want = MIN(25, danger);
} else {
  choice->want = danger;   // ONE

uchoice.want += martial_value;

CITY_LOG(LOG_DEBUG, pcity, "m_a_c_d wants %s with desire " ADV_WANT_PRINTF,
         choice->want);    // TWO

if (!build_walls || uchoice.want > choice->want) {
  *choice = uchoice;

I was led to this code by a crash in the debug message TWO, where 'choice' is all zeroes. I'm pretty sure this debug message is intended to refer to 'uchoice'.

Looking nearby at ONE, I think referring to choice->want is a bug too and this should be uchoice.want?
I'm guessing that this makes AI cities a bit less likely to build defenders when under threat; partly because uchoice doesn't have its want bumped, and partly because it's competing with whatever's in 'choice', which has had its want (erroneously) bumped further.

26-ai-threatened-choose-defender.patch (1.55 KB) 26-ai-threatened-choose-defender.patch S2_6 only Jacob Nevins, 2018-07-15 01:00 PM


#1 Updated by Jacob Nevins almost 4 years ago

In later branches, the code is the way I thought it should be, except that TWO still refers to 'choice' but is after uchoice has potentially been copied to it. This bug affects S2_6 only.

So I'm more confident in changing the code, since presumably it's already been tested on later branches. (A review would still be nice though.)

Basically-untested patch attached (it does fix my debug crash).

#2 Updated by Marko Lindqvist almost 4 years ago

Jacob Nevins wrote:

In later branches, the code is the way I thought it should be

The S2_6 code is likely result of an rebasing error (when patch was ported from later branches to S2_6 and it didn't apply cleanly)

#3 Updated by Jacob Nevins almost 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF