Openspades: 64 players

[Suiten]

Is it possible to realize 64 players in OpenSpades and piqueserver? Is it too difficult?

[NotAFile]

Hi! Thanks for submitting.

OpenSpades is just a client, and it needs to work with existing servers. The existing .75 protocol only supports 32 players and we would have to create a new, backwards-incompatible version. Feel free to file an issue at https://github.com/piqueserver/piqueserver where we are working on a new version of the protocol.

[VelocityRa]

@NotAFile Your link's dead :)
@Suiten here you go: https://github.com/piqueserver/piqueserver

[NotAFile]

There has indeed been changes proposed to increase capacity to 64. However I'm not sure any clients support it.

https://github.com/infogulch/pyspades/pull/290/files

[Suiten]

Thanks!

[yvt]

Raised the internal limit to 128, but it won't be enabled by default because some pyspades scripts (e.g., arena) rely on the currently invalid player ID 32 for certain operations.

[NotAFile]

also, System messages are currently broadcast with a player ID of 36.

What more needs to happen to support this? We need some way of telling the client that the player is 32+ player compatible, while also not allowing Voxlap clients to connect. The obvious way to do this would be to increase the protocol version, but that means pretty invasive changes in the codebase.

Also the .75 WorldUpdate packet always send 32 players, so we would have to use the .76 player update packet, right?

[Jipok]

@yvt
I manually changed manyPlayers flag. It seems besides the incorrect display in the table of players, everything works.

Or am I wrong? What is the current support status of 128 players?
What about next release? Will manyPlayers be activated when receive of ExtensionType128Player?

[yvt]

Currently, manyPlayers isn't automatically activated, although it's supposed to be.

@NotAFile HandleExtensionPacket (the handler for S→C ExtensionInfo) is the good place for this to happen, I suppose?

Also, I'd like to keep GameProperties as immutable as possible. Is there any guarantee about when the extension flags can be considered "frozen"?

[Jipok]

@yvt
Why not set manyPlayers = true by default? Old servers still work, new ones according to the client’s version will be able to find out if it supports more than 32 players.

[NotAFile]

HandleExtensionPacket (the handler for S→C ExtensionInfo) is the good place for this to happen, I suppose?

Yes, that seems good.

Also, I'd like to keep GameProperties as immutable as possible. Is there any guarantee about when the extension flags can be considered "frozen"?

I don't think so. Ideally, you'd expect this to be set before the State Data packet. Unfortunately though there are a number of issues.

• we can't demand an ACK for ExtInfo before completing the map transfer, as old clients ignore the packets
• we can't send ExtInfo before we have received a VersionGet reply, as <=0.1.3 breaks when sent unknown packets during map download.
• we can't expect an VersionSet reply before map load, as <= 0.1.2 can only reply to VersionGet when the world has already loaded.

So we'd end up with a race condition of the map transfer with the full extension handshake. The extension handshake will mostly win, but you can't know for sure.