Server Capabilities

[Hoikas]

Implements server capabilities broadcast as discussed for #112. This requires H-uru/Plasma#546

[zrax]

Do you think 32 bits will be enough for everything we may want to add in the future? I know the client makes varying length fields a bit more difficult, but I feel like we should reserve at least one more dword in case we come up with something that needs more than just a boolean bit.

In addition (more a note to others who come here since I'm sure @Hoikas is already aware): This method of setting caps will BOOT any client that doesn't have support for the message. If you run a server with this change, you MUST also be using a client that has H-uru/Plasma#546.

[Hoikas]

I was operating under the assumption that anyone using this changeset would be operating in lockstep with H-uru/Plasma master and that we could add new bits as needed. What we have to be careful about is the client sending garbage to the wrong server (MOULa), not the other way around IMO. I could up this to a 64-bit field. I bet eap's netcode doesn't support that natively, but new field types are fairly trivial to add.

[zrax]

I was thinking more along the lines of adding a second DWORD. But your point about keeping this in sync with the client is valid, so I'm fine with leaving it as a single value.

[dpogue]

I guess we don't have the option of just sticking a hsBitVector in there?

[Hoikas]

We could encode an hsBitVector inside a payload instead of sending down a DWORD, it's just a bit more work. Thoughts, @zrax?

[zrax]

Using a bit vector makes it easier to adjust in the future, so if it's not too painful to add, I think I like the option better.

[Hoikas]

Over a year later this has been updated to use an hsBitVector as requested 😛

[Hoikas]

Is there anything else that needs to happen here, @zrax?

[Hoikas]

Fixed issue from review

[Hoikas]

:boom: