Feature #2052
openimprove reporting of obsolete wonder
0%
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
Updated by Dean Brown 3 months ago
- File 2052_Main.patch added
- File 2052.patch added
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.
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.
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.
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)
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.
Updated by Dean Brown about 8 hours ago
- File 2052_Main.patch 2052_Main.patch added
- File 2052.patch 2052.patch added
Fixed.
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