Project

General

Profile

Actions
Copy link

Feature #2052

open

improve reporting of obsolete wonder

Added by Dean Brown about 1 month ago. Updated 26 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Server
Target version:
-
Start date:
06/14/2026
Due date:
% Done:

0%

Estimated time:

Description

Currently, when a wonder is obsoleted by a discovery, it only gets reported if
the obsolete_by has "range" = "World" and "survives" = TRUE. I would like to
get notified when the "range" = "Player". Yes I should know that I'm
researching something that will obsolete my wonder, but I also appreciate
getting notified when my Barracks gets sold when I get Gunpowder. Also should
handle "range" = "Team" and "range" = "Alliance".

Also, as is, if "survives" = FALSE then the wonder still becomes obsolete
but there's no notification. Note - for "Tech", "survives" only supported
for range "World".

Another can of worms - if "survives" = FALSE then does the wonder suddenly
come back to life if the tech is lost? Pretty unlikely, not sure it's
worthwhile to deal with that.

Files

Download all files
2052_Main.patch (5.05 KB) 2052_Main.patch Dean Brown, 06/20/2026 01:42 AM
2052.patch (5.6 KB) 2052.patch Dean Brown, 06/20/2026 01:42 AM
Actions
Copy link
 #1

Updated by Dean Brown about 1 month ago

  • File 2052_Main.patch added
  • File 2052.patch added
Actions
Copy link
 #2

Updated by Marko Lindqvist about 1 month ago

struct player *city_owner

Please rename so that it's not using the same name as an existing (and relevant) function

player_by_number(research_number(presearch));

I don't think this works the way you expect it to do, especially when team shared research is enabled.

- Missing empty line between variable declarations and code
- Do not use 'default' case but list all the ranges explicitly, so that when support for a new range is added, the compiler will error if its effect on this switch is not considered
- All this should be within the "if (pobs->source.kind VUT_ADVANCE && pobs->source.value.advance vap ... ) {" , and most of it should be within "if (pcity != nullptr) {"

&& pplayers_allied(new_tech_player, city_owner)) {

Here relying on a single player as new_tech_player breaks. The wonder will get obsolete if any of the players sharing the research is allied with the city owner.

Actions
Copy link
 #3

Updated by Dean Brown 26 days ago

  • File deleted (2052.patch)
Actions
Copy link
 #4

Updated by Dean Brown 26 days ago

  • File deleted (2052_Main.patch)
Actions
Copy link Download all files
 #5

Updated by Dean Brown 26 days ago

Yes, I missed the shared research complication. Also needed to fix dealing with was_first. Exhausting and exhaustive testing revealed I needed to add bool is_obsolete.

Thanks for the style advice.

Thought of another way the wonder could suddenly come back to life - with "range" = "Alliance", your ally gets the tech, you then break the alliance. Tested this and that indeed happens. Very unlikely, don't think it needs to be dealt with.

Another wrinkle - the auto-generated help does not deal with ranges, or even present = FALSE. This never occurs in the distributed rulesets so not a big deal.

Another thing I noticed while testing, it's possible found_new_tech() doesn't get called when a tech comes from "ancient scrolls of wisdom", will have to investigate this. Would be a separate issue if so.

Actions
Copy link

Also available in: Atom PDF