Project

Profile

Help

HostedRedmine.com 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 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
AI
Sprint/Milestone:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

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,
         utype_rule_name(choice->value.utype),
         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

History

#1 Updated by Jacob Nevins almost 3 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 3 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 over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF