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()
0%
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.
History
#1
Updated by Jacob Nevins almost 4 years ago
- File 26-ai-threatened-choose-defender.patch 26-ai-threatened-choose-defender.patch added
- Status changed from New to Resolved
- Assignee set to Jacob Nevins
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