Feature #2052
open
improve reporting of obsolete wonder
Added by Dean Brown 3 months ago.
Updated about 8 hours ago.
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
- File 2052_Main.patch added
- File 2052.patch added
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.
- File deleted (
2052.patch)
- File deleted (
2052_Main.patch)
- 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.
- File deleted (
2052_Main.patch)
- File deleted (
2052.patch)
- 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.
REQ_RANGE_PLAYER check breaks when pooled research is enabled (it assumes research number to match player number)
- File deleted (
2052_Main.patch)
- File deleted (
2052.patch)
- File 2052_Main.patch added
- File 2052.patch added
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.
- File deleted (
2052_Main.patch)
- File deleted (
2052.patch)
- Status changed from New to In Review
- Assignee set to Marko Lindqvist
- Target version set to 3.3.0
Also available in: Atom
PDF