There could exist default_read_from_field=field_name counter feature. It could be an alternative to parser.lua. User declare unit counter called action amount and connect it to action amount field of unit type, so while counter was created, game assign action amount counter to it with value read from priest unit type. When but creating priest, but workers this time, the same was done, but default value was set from workers unit type.
Maybe, instead reading default value of counter from special field, add counter_default effect plus countername requirement type. Counter name would be related only to counter_default effect. This could allow us to enhance gameplay by provide (for example) done wonder increasing default number of action points. In civilization 6, priest and workers have action points. Unit can do one action per turn. When user select action, unit turn will be done. Once unit do not have action point, unit disappear.
This will allow to declare some religious wonders to increase priest action points and pyramids increase action points of workers.
I also have four new ideas:
1. Shared index of two (or more) counters Some counters do the same think - it will be increased once some events or zeroed once some event. Thus, both counters will have the same value. There is no reason to keep two identical values except code simplicity. Firstly, we need to add function to return maximum number of index for some kind of counter (city, player, etc.). I must change behavior, because currently server simply iterates per counters of some range and modify value. I do not known how to solve change value of the same integer twice, because it's index in some array (given city, for example) are identical.
2. Virtual counter There is no need to store value for some thing in counter. Values such like Player's gold amount, Unit hp, Unit move point, Bulbs of player, etc. are currently stored after all, but in different place. Solution is to handle some counters in different way. Similar to above, we do not store it's value in given object's array (for example city), but read it from different place (player struct, city struct, unit struct, etc). This will allow us to define checkpoint for some cases like: If player have at least 5.000 Gold, then it achieves victory.
3. Effect counter It looks very nice, but I still do not known if there be any real use-case. Simple - made counter type called effect. Counter rule name will be use to gather each effect with name of counter and add each effect with counter's name, which have fulfilled requirements. Of course - we must do dependency tracking, so CounterA requires (Counter type of requirement) counter effect CounterB and this requires CounterA, or CounterA have checkpoint depends on itself. It is very bad case, but I can handle it.
4. Counter set/counter like multiplier We could integrate counters with multiplier code. Firstly, add multiplier_range to effect, so: 1. If entity of type required by multiplier_range are passed into effect calculation routines, we use entity.multiplier(counter)_name as multiplier 2. If entity of this type was not passed, we get the default value from counter definition and pass it as multiplier
As in 3, we calculate effects like counter_name_min_value, counter_name_max_value, counter_name_offset, counter_name_step, but not effect related to counter name. In this case, player can store this value, but listed in 4. item will be calculated as in 3.
Of course, this will allow to extend multipliers to thinks such like: city multipliers, unit multipliers, etc. I do not known AI will be capable of handling such things, because more things will be dynamic than in current multiplier implementation. But... If we do not allow of cyclic-dependency, it may work.
The reason we have multiple counters counting the same thing is just that they might have different checkpoint. There would be no need for that if we had checkpoint information in the requirement. This would be one reason to add "subvalue" to requirements, but far from the only one. It's something that I've had in my mind for some time.
But what about my suggestion to allow sharing index? I know this may require a lot of additional complexity, but...
Crated counter meta ticket for freeciv-3.2: #47293
Action costs:
As above, user could use checkpoint if counter is above value. In this case, there is no need to use min/max, but in case value is greater/lower than checkpoint of counter, ruleset author could set min and max. Min and max defines set of possible values counter will be set after applying value in vector showed above.
So:
Another example:
Action costs could be used in many ways; We could also provide more generic actions like do_nothing to allow moders use it only for counters manipulation.
Reply To lachu
4. Counter set/counter like multiplier
Yes, it's one of the first thing that came into my mind about counters. CivIII has war weariness: a counter that increases certain amounts from certain actions performed to or by the player during wars, if I remember correct even from just each unit staying in hostile territory, and this counter decreases overall happiness. I don't remember if it is tracked separately for each enemy (to nullify when a treaty is signed). Also, there are city unhappiness counters. A unit ranged counter would be e.g. attacks allowed per turn. Maybe culture could also be resolved as a regular counter, then it would scale e.g. city migration score (just that requires tracking national sum of city counters + a national counter, and the result goes into a "MinCulture"-replacing requirement as in your point 3.).
Reply To lachu
Action costs:
That was suggested in the beginnong of the counter history to resolve by events
[event_weariness_attack_1]
type = "action_started_unit_unit"
reqs = {"param", "type", "name", "range", "present"
1, "Action", "Attack", "Local"
2, "NationGroup", "Barbarians", "Player", FALSE
}
increments = {"counter", "source", "property", "value"
"WarWeariness", 3,3 ;+3 for the victim
"WarWeariness", 2, "unit.owner", 1 ;+1 for the attacker
}
or by effects
[effect_weariness_attacker]
type = "Counter_Increment_Actor"
value = 1
reqs = {"type", "name", "range", "present"
"Action", "Attack", "Local"
"NationGroup", "Barbarians", "Player", FALSE
}
[effect_weariness_defender]
type = "Counter_Increment_Target"
value = 3
reqs = {"type", "name", "range", "present"
"Action", "Attack", "Local"
"PlayerState", "Barbarian", "Local", FALSE ; calculated for The Other Player i.e. attacker
}
As you can see, one way requires a new kind of entities but the another needs a lot of new entities of old types.
I decided to start ticket for provide discussion about extension for counters idea. Ideal, if counter was integrated with action enablers, so doing action will increase/decrease counter values (additional action kind?). Additional user defined counters should been added. This should allow for implementing religion and others. Also, I think about add new field called counter_reset, which zeroes counter or reset it's value to default. It could bring some possibilities added in progress thanks to my work over effects (effects_vacation, effects_turn_remember and others), so we set def to 0, checkpoint to 5 and reset to 8, so effect will stay active for four turns.