Client counter's ruleset packet not handled in some cases
I look again at code and everything seems to work, but number city counters was not increased, so effects does not taking place. Values are set, but strange effect occurs without this patch.
It makes no sense to have such lists of ALL counters here and there. For the time being (as we have only city counters) you should be able to use just counter_behavior_is_valid()
Reply To cazfi
It makes no sense to have such lists of ALL counters here and there. For the time being (as we have only city counters) you should be able to use just counter_behavior_is_valid()
This should do the trick.
Patch doesn't apply. Tried both main and S3_2 branches.
2023-03-22 22:42 Updated by: lachu
Should apply. I work on other changes, when preparing previous patch (should switch to main and create new branch or squash changes).
Currently, only owned and city counter are properly handled. I missed this piece of code (if statement in client code related to networking), so default value, checkpoint and others was not initialized, which causes strange behavior, which may occur sometime, sometime another strange behavior was caused, etc.
To be descriptive, it was caused by not initializing counter memory (do not copy default/checkpoint/etc.) from packet, where packet is related to CELEBRATION or DISORDER type. In future it may be related to other types.