-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PP: Score packet #3
Comments
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. |
well, it's cleaner and clearer than an "random person picked up 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. |
Here's the idea I have for how this could be done which would also kill a few stones with one bird:
Here's some packets that could work: SetScoreMode
This changes the default scoring rules. A game which doesn't need any of the builtin scoring can opt to set all the 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
SetTeamScore
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. |
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 |
Alright, thanks for digging that up. Would adding a new "This Team Won" packet help here? VictoryEvent
|
Using magic values like |
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. |
Client support is also only up to 128 in the case of OS |
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. |
|
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 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 |
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)
The text was updated successfully, but these errors were encountered: