@cazfi. How do that (in which way)? Should be new value generated by server send to each client for city counters, or (perhaps?) only to city owner? Maybe introduce special field, called "publicity" or "visible_other". It could be similar to range, so world, continent, ally, others.
Reply To lachu
Should be new value generated by server send to each client for city counters, or (perhaps?) only to city owner? Maybe introduce special field, called "publicity" or "visible_other". It could be similar to range, so world, continent, ally, others.
I think we should start by sending them to city owner only - probably some counters are such that other players are not supposed to know them,
Visibility ranges are a good idea, but let's leave it to a bit later -> can you open a new ticket?
Can maybe align with other things needing such visibility ranges (at least for achievements those have already been wanted for some time)
Reply To cazfi
Reply To lachu
Should be new value generated by server send to each client for city counters, or (perhaps?) only to city owner? Maybe introduce special field, called "publicity" or "visible_other". It could be similar to range, so world, continent, ally, others.
I think we should start by sending them to city owner only - probably some counters are such that other players are not supposed to know them, Visibility ranges are a good idea, but let's leave it to a bit later -> can you open a new ticket?
Can maybe align with other things needing such visibility ranges (at least for achievements those have already been wanted for some time)
I think it was done.
Reply To cazfi
Reply To lachu
Should be new value generated by server send to each client for city counters, or (perhaps?) only to city owner? Maybe introduce special field, called "publicity" or "visible_other". It could be similar to range, so world, continent, ally, others.
I think we should start by sending them to city owner only - probably some counters are such that other players are not supposed to know them, Visibility ranges are a good idea, but let's leave it to a bit later -> can you open a new ticket?
Can maybe align with other things needing such visibility ranges (at least for achievements those have already been wanted for some time)
It may require https://osdn.net/projects/freeciv/ticket/45489 . If you prefer, I will rebase it on master.
Reply To lachu
It may require https://osdn.net/projects/freeciv/ticket/45489 . If you prefer, I will rebase it on master.
It applies as is.
- handle_city_update_counter() needs function header
- handle_city_update_counter() should check also against negative 'counter'
- It doesn't make much sense to implement sending inside part of the code specific to the one counter we have (updated at turn change). You should probably make a separate (server side) function to update a city counter, which would then take care of sending info to client side too
- "if (is_human(pplayer) && NULL != pplayer->current_conn) {" breaks a lot of things, e.g., clients observing AI players, and latter part also global observers
- "send_packet_city_update_counter(pplayer->current_conn, &packet);" - send to player's all connections (including observers), not just to controlling connection; use "lsend_...(pplayer->connections...)"
- Send the info to global observers too. The "game.glob_observers" should cover them, though most parts of server still(?) do more cumbersome iteration over all connections and sending individually to each of them being a global observer
Also, it doesn't compile. Is the packet definition still older than #45567, which has been in for over a month?
Reply To cazfi
Reply To lachu
It may require https://osdn.net/projects/freeciv/ticket/45489 . If you prefer, I will rebase it on master.
It applies as is. - handle_city_update_counter() needs function header
- handle_city_update_counter() should check also against negative 'counter'
- It doesn't make much sense to implement sending inside part of the code specific to the one counter we have (updated at turn change). You should probably make a separate (server side) function to update a city counter, which would then take care of sending info to client side too
- "if (is_human(pplayer) && NULL != pplayer->current_conn) {" breaks a lot of things, e.g., clients observing AI players, and latter part also global observers
- "send_packet_city_update_counter(pplayer->current_conn, &packet);" - send to player's all connections (including observers), not just to controlling connection; use "lsend_...(pplayer->connections...)"
- Send the info to global observers too. The "game.glob_observers" should cover them, though most parts of server still(?) do more cumbersome iteration over all connections and sending individually to each of them being a global observer
Rebased on master, so it should compile now. I also add per-client update_city_dialog_information/description for future usage (currently, we update only on end of turn, but maybe it should be added).
- Send the info to global observers too.
- This part seems still to be missing?
- 'git diff' shows trailing spaces on the empty line between "pcity->counter_valuescounter = packet->value;" and "update_city_description(pcity);"
Otherwise I guess this is something to improve iteratively on later tickets, and should itself to go in enable people to use (= test) the feature.
Reply To cazfi
- Send the info to global observers too.
- This part seems still to be missing?
- 'git diff' shows trailing spaces on the empty line between "pcity->counter_valuescounter = packet->value;" and "update_city_description(pcity);"
Otherwise I guess this is something to improve iteratively on later tickets, and should itself to go in enable people to use (= test) the feature.
2022-10-17 21:30 Updated by: lachu
Sorry for I missed something you told. Space was removed and I add sending counter value to global observers instruction into routine responsible for sending this info to city owner's.
Counter values need to be updated also on client side.