search

beyond-all-reason / teiserver

Middleware server for online gaming
https://www.beyondallreason.info/
MIT License
55 stars 53 forks source link

Extend RING with initiator #341

Closed FIr3baL closed 1 month ago

FIr3baL commented 3 months ago

About 11 years ago a nice wrapper for the spring-protocol RING-command was introduced to spads. !ring features a nice way to control how often a user can be rung. And users can set their preferred minRingDelay. It also enables context specific multi-user-rings, e.g "!ring" results in ringing all players, that are not ready or didn't vote yet.

Our ring command travels this way for "client to client" (Similiar way for multi-rings by spads in other situations)

A user sends the spads command !ring by chat

[info] <-- UserInitiator: SAYBATTLE !ring UserToRing
[info] --> UserInitiator: SAIDBATTLE UserInitiator !ring UserToRing
[info] --> SpadsHostUser: SAIDBATTLE UserInitiator !ring UserToRing
[info] --> UserToRing: SAIDBATTLE UserInitiator !ring UserToRing

spads decides if the user will be rang and sends a public notification about the ongoing RING.

[info] <-- SpadsHostUser: SAYBATTLEEX * Ringing UserToRing (by UserInitiator)
[info] --> SpadsHostUser: SAIDBATTLEEX SpadsHostUser * Ringing UserToRing (by UserInitiator)
[info] --> UserInitiator: SAIDBATTLEEX SpadsHostUser * Ringing UserToRing (by UserInitiator)
[info] --> UserToRing: SAIDBATTLEEX SpadsHostUser * Ringing UserToRing (by UserInitiator)

spads sends RING to the rung user

[info] <-- SpadsHostUser: RING UserToRing
[info] --> UserToRing: RING SpadsHostUser

With the current implementation i see 2 downsides (at least for bar infrastructure):

  1. The rung user does not get to know who rang him initialy. RING is always sent from SpadsHostUser and does not include the initiator anymore. Of course the rung user can read the public message, but this info is not part of the RING command itself. (Because RING is limited by protocol specification)
  2. MinRingDelay and other autohost specific ring settings must be set for each spads host individually (this could be discussed in another issue: e.g add those settings to teiserver's global user prefs)

Suggestion for 1.: Replace teiserver's RING by an extended version, that can only be used by autohosts and allows a second argument: The initiator of the current ring. This way clients could show, who actually rang them. (or even decide to show notifications from ignored players or not - this could also be part of 2.)

In short:

RING <username>
-> RING <username> <initiator>

@Yaribz I guess a change to spads with the suggested 2nd argument would conflict with other games/servers, correct ? If that's the case, a new ring command would be needed, which could be triggered by barmanager. (if that's technical possible)

Yaribz commented 3 months ago

2. MinRingDelay and other autohost specific ring settings must be set for each spads host individually

Afaik BAR uses shared preferences data, so actually they must only be set once by cluster.

I guess a change to spads with the suggested 2nd argument would conflict with other games/servers, correct ?

Not if this is introduced with a compatibility flag, which is the mechanism in place in current lobby protocol to introduce non-backward compatible extensions like this one.