send "ingame" status change only to players which are inside the same battle

[abma]

no need to send it to all clients

[sprunk]

it's useful to know whether someone is ingame or not, even if you're not in the same battle, eg. if you need to talk to a mod or a clan-mate you can pick one that is not ingame

[abma]

performance vs comfort

sending status to every connected client is VERY inefficient

i guess friend list should be used for that as well.

[gajop]

Should also be sent to friends automatically, and should be able to query a user's status (like it works in most systems).

[PicassoCT]

Sorry, but i still think, the concerns would be seperated in a most clean fashion, if the client registers for the data it wants to hear and has to take the burden of concern. Else you will have a giant state machine on the server, for every client to find out what data he needs. Finally with over 9000 players, there comes a point where you have to add multi-server support - and then what? Handing over a client-concern-simulation with all the friends-lists etc. sounds at lot more complicated, then just handing down a list of listeners and add what is still missing to one big server-server listener to transfer info the other server just doesent have. But i may be wrong. Its just instinct yelling, that the object that has the most agency with something, should have the burden of concern.

[silentwings]

Perhaps its enough just to send the ingame status for battle hosts

[sprunk]

Sounds like a fairly good approximation if 100% accuracy is not required.

[silentwings]

closing for now - can be reopened in future if traffic reduction is needed

[abma]

this request is not about traffic reduction: its just not needed and also it scales very badly.

[abma]

as compromise only the ingame status of hosts could be send.