Project

General

Profile

Actions

Feature #2052

open

improve reporting of obsolete wonder

Added by Dean Brown 3 months ago. Updated about 8 hours ago.

Status:
In Review
Priority:
Normal
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

2052_Main.patch (7.06 KB) 2052_Main.patch Dean Brown, 08/30/2026 02:31 AM
2052.patch (7.62 KB) 2052.patch Dean Brown, 08/30/2026 02:31 AM
Actions #1

Updated by Dean Brown 3 months ago

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

Updated by Marko Lindqvist 3 months 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 #3

Updated by Dean Brown 2 months ago

  • File deleted (2052.patch)
Actions #4

Updated by Dean Brown 2 months ago

  • File deleted (2052_Main.patch)
Actions #5

Updated by Dean Brown 2 months ago

  • File 2052_Main.patch added
  • File 2052.patch added

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 #6

Updated by Dean Brown about 1 month ago

  • File deleted (2052_Main.patch)
Actions #7

Updated by Dean Brown about 1 month ago

  • File deleted (2052.patch)
Actions #8

Updated by Dean Brown about 1 month ago

  • File 2052_Main.patch added
  • File 2052.patch added

Found a bug in my patch, replaced.

found_new_tech() does get called when a tech comes from "ancient scrolls of wisdom", not an issue.

Actions #9

Updated by Marko Lindqvist 25 days ago

REQ_RANGE_PLAYER check breaks when pooled research is enabled (it assumes research number to match player number)

Actions #10

Updated by Dean Brown 6 days ago

  • File deleted (2052_Main.patch)
Actions #11

Updated by Dean Brown 6 days ago

  • File deleted (2052.patch)
Actions #12

Updated by Dean Brown 6 days ago

  • File 2052_Main.patch added
  • File 2052.patch added

Fixed.

Actions #13

Updated by Marko Lindqvist 1 day ago

REQ_RANGE_PLAYER with pooled research still wrong. Now it checks if player is allied to someone with the research, when it should just check if player (themself) is part of the research.

Actions #14

Updated by Dean Brown about 9 hours ago

  • File deleted (2052_Main.patch)
Actions #15

Updated by Dean Brown about 9 hours ago

  • File deleted (2052.patch)
Actions #17

Updated by Marko Lindqvist about 8 hours ago

  • Status changed from New to In Review
  • Assignee set to Marko Lindqvist
  • Target version set to 3.3.0
Actions

Also available in: Atom PDF