PP: Score packet

[NotAFile]

Currently, scores must be kept by picking up and dropping the intel.

Adding a packet that sets the score of the team would be a good backwards-compatible packet to add. (on the original client it would just send intel pickup and capture packets instead)

[noway]

Having perfect graceful degradation means that it is redundant IMHO.

In general having packets which extend OS experience while still leaving beta playable are the best. This doesn't extend OS experience.

[NotAFile]

well, it's cleaner and clearer than an

"random person picked up the intel"
"random person captured the intel"

And it could include additional information.

Maybe, an option to send messages to the status message panel "you were killed by x" in OpenSpades would cover this use case.

[iamgreaser]

Here's the idea I have for how this could be done which would also kill a few stones with one bird:

• Set team scores and score limits, ideally on a per-team basis, and allow hiding them
• Set player scores, and maybe allow hiding them
• Set how many points per kill and capture per player, and capture per team, and this will override the defaults of 1, 10, 1 respectively.

Here's some packets that could work:

SetScoreMode

struct SetScoreMode {
   uint8_t extension_id[2] = {0x8?, 0x??};
   uint8_t packet_id = 0x00;
   uint8_t player_id;
   int32_t player_points_per_kill;
   int32_t player_points_per_intel_capture;
   int32_t team_points_per_intel_capture;
} __attribute__((__packed__));

This changes the default scoring rules. A game which doesn't need any of the builtin scoring can opt to set all the *_points_per_* fields to 0.

This could be extended in later versions by adding more fields to the end for e.g. points per death, points per suicide, points per teamkill... but you'd probably get more value out of overriding scoring full stop.

SetPlayerScore

struct SetPlayerScore {
   uint8_t extension_id[2] = {0x8?, 0x??};
   uint8_t packet_id = 0x01;
   uint8_t player_id;
   int32_t score; // -0x80000000 == don't show this player's score
} __attribute__((__packed__));

SetTeamScore

struct SetTeamScore {
   uint8_t extension_id[2] = {0x8?, 0x??};
   uint8_t packet_id = 0x02;
   uint8_t team_id;
   int32_t score; // -0x80000000 == don't show this team's score
   int32_t score_limit; // -0x80000000 == no limit, so don't show it
} __attribute__((__packed__));

---

And a question: When the score limit has been reached, does it automatically go "YAY YOU WON" on the intel capture, or is it a separate packet? I keep thinking it's the latter, but if it's the former then any use of ANY of these packets should disable that behaviour.

[xtreme8000]

@iamgreaser

And a question: When the score limit has been reached, does it automatically go "YAY YOU WON" on the intel capture, or is it a separate packet?

Client will display a "YAY YOU WON" message and play the horn sound when the winning flag is set in this packet: https://www.piqueserver.org/aosprotocol/protocol075.html#intel-capture

[iamgreaser]

@xtreme8000

Alright, thanks for digging that up.

Would adding a new "This Team Won" packet help here?

VictoryEvent

struct VictoryEvent {
   uint8_t extension_id[2] = {0x8?, 0x??};
   uint8_t packet_id = 0x03;
   uint8_t flags;
      // bit 0 = reset team scores
      // bit 1 = reset player scores
      // bit 2 = play victory sound
   int8_t team_id; // -1 == no particular team won
   int8_t player_id; // -1 == no particular player won, -2 == the player ultimately responsible for the victory has since left
} __attribute__((__packed__));

• player_id would be most useful for stuff like non-team deathmatch games.
• When player_id and team_id are both set, it's classified as a team victory where the given player is recognised for finishing up or having some notable importance.
• You can use this packet to reset all scores (all teams and/or all players) to 0 without even having to play the victory sound.
• You can also just play the victory sound alone. There's no such thing as having too many badmin buttons :^)

[xtreme8000]

Using magic values like -1 and -2 won't work for a player_id type, as this would break 256 players compatibility. You might rather use the flags field for those special cases instead?

[iamgreaser]

Going all the way up to 256 players I suspect would break a lot of things without expanding the player fields to 16 bits. Capping it at 250 players may be more reasonable, and on top of that we have yet to run a 64-player server that's actually had more than 32 players on it.

But I could definitely provide flags for those cases. Prod me when I get back from work.

[NotAFile]

Client support is also only up to 128 in the case of OS

[iamgreaser]

OK, coming back to this, I'm inclined to say we should assume that there won't be more than 128 players for the time being, and by the time we get close enough to that number, if demand requires us to support more than 128 players, I think we'd already be on a new vanilla-incompatible protocol version already (that is something other than v=3 or v=4).

First things first though, we need to get a 64-player game going.

[NotAFile]

SetScoreMode seems kind of unnecessary to me. It seems simple enough to just send a score packet with every kill? They're rare enough, not time critical, and enet will put them into one UDP packet anyway. Automatic scoring would be deactivated automatically if the server signals support for the extension.

[iamgreaser]

I was tempted to wait until the server at least sent a packet for it, but if the server supports the packet and the client supports the packet then the server's probably just going to use it anyway.

So in that case, consider SetScoreMode dropped.

As for player IDs and magic numbers... I suspect we'd have some form of score packet as part of a new base protocol before we even hit 128 actual players (read: not bots) on a single server.

If we reach the point where -1 or -2 is an issue, we will probably have transitioned to 16-bit player IDs throughout the whole protocol. And trust me, you won't be seeing a 32,768 player server unless servers with terabit connections can be rented cheaply, and you'll probably still have to wait until the average person has a gigabit connection. So 16 bits for the player ID is almost certainly enough.