Project

General

Profile

Actions

Bug #2452

open

AI builds diplomat for any military threat.

Added by Sweet Tea Dorminy about 18 hours ago. Updated about 14 hours ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
AI
Target version:
Start date:
11/08/2026
Due date:
% Done:

0%

Estimated time:

Description

city_data->diplomat_threat is documented as "Enemy diplomat or spy is
near the city" (daicity.h), and is the sole trigger for
dai_choose_diplomat_defensive()'s 16000 want, which outranks every
military build.

However, assess_danger() set it for any unit, by checking utype_acts_hostile(). ACTION_HOSTILE is true of attackers, pillagers, bombarders and city conquerors just as much as spies, so an approaching Warriors made the city buy a Diplomat before a defender -- a poor life choice.

It should test as others do: dai_choose_diplomat_defensive() answers with best_role_unit(pcity, UTYF_DIPLOMAT) and count_diplomats_on_tile() counts UTYF_DIPLOMAT, so the threat is raised by UTYF_DIPLOMAT units only.


Files

Actions #1

Updated by Sweet Tea Dorminy about 18 hours ago

There's an even better -- but more sweeping -- change which could be done: use the govt+ruleset+buildings to decide if the diplomat actually poses a threat. Attached is a patch which does that arguably more correct enhancement, but I can see a very good argument that first we fix the bug back to the original's intent, which is the first patch.

Actions #2

Updated by Marko Lindqvist about 17 hours ago

  • Target version set to 3.2.8

Sweet Tea Dorminy wrote in #note-1:

There's an even better -- but more sweeping -- change which could be done: use the govt+ruleset+buildings to decide if the diplomat actually poses a threat. Attached is a patch which does that arguably more correct enhancement, but I can see a very good argument that first we fix the bug back to the original's intent, which is the first patch.

I doubt the original intent was to rely on UTYF_DIPLOMAT, which we sort of should be getting rid of now that we have (action) enablers. In the contrary, the intention (causing the bug) likely was to generalize away from UTYF_DIPLOMAT towards depending on action enablers. So, I'd work with the second patch.

- Function header starts from the same line the previous function ends ( "}/***" )
- There's extra empty lines in the end

Actions #3

Updated by Sweet Tea Dorminy about 14 hours ago

Bleh. Sorry about the formatting. Anyway, makes sense, fixed up the second version (also See RM etc.) -- thanks!

Actions #4

Updated by Sweet Tea Dorminy about 14 hours ago

Ugh, apologies, attached exactly the same thing in #3. Actually fixed this time.

Actions

Also available in: Atom PDF