Bug #1639
closed
City celebration not removing tile penalties under Anarchy, Despotism, Tribalism, etc.
Added by Affy Dal about 2 months ago.
Updated 1 day ago.
Description
The civ2civ3 ruleset (can probably be assumed this applies to all rulesets) supplied in v3.2 does not use expected celebration behavior under anarchism, despotism, and tribalism governments. City celebration under those governments is supposed to remove the -1 tile penalty imposed by those governments but instead it does nothing.
I've tried playing with the new
"CityStatus", "Celebration", "City", FALSE, FALSE
lines in the [effect_gov_tile_penalty_anarchy], [effect_gov_tile_penalty_despotism], and [effect_gov_tile_penalty_tribalism] fields within effects.ruleset, but when set to TRUE they seem to disable tile penalties for all cities nation-wide instead of just the cities currently celebrating.
Files
Well, certainly it should not be present=TRUE, as that would mean that Celebration is a requirement for the penalty.
One thing to note is that now the "CityStatus", "Celebration" checks for the real celebration status (at the previous turn change), not any of the temporary predictions during the turn. That said, it's also possible that celebration effects kick in one turn too late (even at the turn change where the celebration really starts, it might still check for the previous turn status)
Savegame to reproduce this would be nice, i.e. a savegame where there's a city celebrating but still suffering from the tile penalties.
I also ran into this bug. Here's a savegame, created with the help of edit mode.
Dug into this some - what I see is that, in requirements.c routine is_citystatus_req_active(), the value of context->city->rapture is always 0, even after multiple turns of rapture. Somehow the increment of pcity->rapture++; in cityturn.c routine update_city_activity() isn't getting propagated.
Could be that the 'rapture' is not sent to the client side. If this is such a client-side-only issue, it would mean that server does not actually apply penalties at turn change, it's just client showing that it would.
It is server->client problem, this patch fixes it. Also added anarchy field as well as rapture field to struct
packet_city_info because it looks like it's also needed, likely a similar bug related to that.
Wondering if there's also a similar bug with counters for "Disorder" and "Celebration", there's a field counter_values in struct city that is not in struct packet_city_info.
I think that this S3_3/main patch also needs to zero the fields on the client side when packet_short_city is received. Otherwise lost city keeps the values from the time it was still owned (or investigated) by the client's player-
For S3_2 we need a patch that does not break network compatibility, i.e., it needs to handle this with optional network capability.
Counters are not an issue - there's a separate struct packet_city_update_counters for them.
Yes network compatibility is an issue, tried using my patched client with test.cazfi.net server and got error "incompatible packet contents." Better to have someone else handle that - I'm more of a UI guy and not a network guy.
With the savegame you provided, I see no difference whether your patch has been applied or not. The central tile always has 2/3/1. It should be 2/4/1, I think.
Marko Lindqvist wrote in #note-9:
With the savegame you provided, I see no difference whether your patch has been applied or not. The central tile always has 2/3/1. It should be 2/4/1, I think.
Oh, the city was not celebrating yet, but starts celebrating only in two turns. I myself commented earlier that "it's also possible that celebration effects kick in one turn too late"
- Category changed from Rulesets to General
- Status changed from In Review to Closed
Also available in: Atom
PDF