Client sends packages when the player has lost
Let's look into the code: if AI kills a king, it normally happens in phase beginning within first_activities AI callback that is followed by k_d_p(). If a user action (incl. player's own movement that causes auto-attack) kills a king, that happens within server_packet_input() that is also finalized with k_d_p(). If some tc happening misfortune kills the king, there is k_d_p() at phase end and a very special thing must happen to bypass it, we hardly have such one in standard rulesets (a sea bridge the king stays on is spontaneously removed?). But when we call a Lua callback, it may happen any moment without phase start, user input or turn end
In fact, how much do we need the gap between killing a gameloss unit and k_d_p? Likely, only few code requires players involved to stay alive, and we just must test any city or unit existence after we have called any Lua. Maybe in newer versions we should switch to an immediate kill_player() call.
Reply To ihnatus
Let's look into the code: if AI kills a king, it normally happens in phase beginning within first_activities
What if a human player kills a king mid-turn?
EDIT: Of course you already told that in "user action" part. For some reason I though that to mean losing player's own action only.
For the issue mentioned in the subject, we should take two approaches. First of all client itself should know not to send those packets when player is dying. The second part is actual removal of the player from the server, which above comments have already been discussing.
To already have k_d_p() in the end of server_packet_input() indicates that there is no problems to expect in removing player mid-turn. I don't think we can make killing player within the script to work - far too often the script is called within some iteration (or even multiple nested iterations that would break in sudden removal of the player).
So maybe we just need to identify the cases where the script might get called outside user input ('pulse' comes to mind), and call k_d_p() after such cases, outside any vulnerable iterations?
Reply To cazfi
So maybe we just need to identify the cases where the script might get called outside user input ('pulse' comes to mind), and call k_d_p() after such cases, outside any vulnerable iterations?
If I understand you right (since we can't be sure that any method will be called only in "pulse" callback), that means "what if we call k_d_p() at some regular moment outside of game code sections that presume players staying alive, so that a player has low probability to press a wrong button before it is inactivated"? Well, it's possible while does not seem perfect. The perfect way seems to be queuing a packet that inactivates interface as soon as we see we need to; but that requires tedious code changes and/or protocol changes that we are not going to do, at least in 3.0/3.1.
Spotted when a script kills in any way a gameloss unit. Before #44274, also happened when you remove a king in editor, after #44273, may be triggered by edit.player_lose() method. It might happen in some other situation and client ignorance/server package warning may be not the only bug effect, since marking players with PSTATUS_DYING and calling kill_dying_players() are distant and things happen between them.