Small proposal for lobby protocol extension

[BrainDamage]

Atm the ranklimit field in battles indicates the minium rank required for an user to join a battle; many users requested the capability to set for a maximum rank allowed instead ( newbies only eg. ), the problem is communicating such before an user joins the battle:

I propose that to extend current ranklimit range: positive values means a min rank restriction is in place ( already current situation ), and negative values that a max rank restriction is used, I already tested with tasserver and it accepts negative values just fine

I realize it will imply that only one of the 2 of the systems is being used, but I think it will be already an improvement to current system without breaking backwards compatiblity

any objections?

[Neddie]

What about implementing a min-max system so you can also create bands of users to play with?

[koshi]

any objections?

nope

[BrainDamage]

What about implementing a min-max system so you can also create bands of users to play with?

I realize it will imply that only one of the 2 of the systems is being used, but I think it will be already an improvement to current system without breaking backwards compatiblity

this means 0 changes in protocol & server side, old clients not getting obsolete, so high change of deployment, any other solution needs someone to actually make it, others to approve it, etc

[Neddie]

I gathered that, but I felt it might have the support of a server developer somewhere, and a better solution if similarly painless should be the one used.

[bibim]

this means 0 changes in protocol & server side, old clients not getting obsolete, so high change of deployment, any other solution needs someone to actually make it, others to approve it, etc

How do old SpringLobby and TASClient react when they receive negative rank limits?

[BrainDamage]

old SL just displays a "?" in the rank requirement field and makes no glitches, tasclient shows no restrictions and seems to have no problems either

[jK]

If it is an integer why not using it as a bitmask for much further definitions (and using the negative bit as a flag for the new bitmask system)?

[Satirik]

no bit crap please !!

[Pxtl]

At some point you just need a set of arbitrary key/value pairs that are up to the lobby systems to support.

[echoone]

Someone said its an int. There are only a handful of ranks. Just break the int into two words. The low word represents the minimum rank. The high word represents the maximum rank. This keeps the bit fiddling to an absolute minimum. This also provides for rank ranging/banding; whereby a minimum and maximum rank can be set.

When maximum rank is not used, old clients work. When maximum rank is set, old clients see it as a really high minimum rank requirement.

Again, protocol changes won't be required. Only clients require change. And in cases were only minimum rank is required, old clients still work, as always.

[BrainDamage]

Someone said its an int. There are only a handful of ranks. Just break the int into two words. The low word represents the minimum rank. The high word represents the maximum rank. This keeps the bit fiddling to an absolute minimum. This also provides for rank ranging/banding; whereby a minimum and maximum rank can be set.

that's exactly what jk said already, just position of the bitfields shifted, but like all lobby devs will say:

no bit crap please !!

bitfields are largely used in the protocol and give several restrictions/headaches, to the point that devs developed an atavic hate for them, so no, won't happen that way for sure

[echoone]

There is a huge difference between a bitfield (bitmap) and a simple mask. The lobby developers would only need to use two masks. Or, they can parse it as two shorts rather than a single int and not have to use a single mask.

We're talking about two or three lines of new code.

pseudo code follows

Code: Select all

int rank = toInt(rank) ; // existing code
int minRank = rank & 0xffff ;
int maxRank = rank & 0xffff0000 ;

[BrainDamage]

the answer remains no, call them like you want ( the concept you described is how they are parsed already in SL for instance), answer won't change

we want to get rid of them, not add more

[echoone]

I edited by reply while you were typing yours.

Is two lines versus three really that big of a deal?

Obviously I'm not coding/maintaining it so my opinion really doesn't matter. And to be clear, I'm not trying to get under your skin on this.

[AF]

Bitfields were one of the single biggest headaches building AFLobby and the other bots I had, they're evil evil, and theres no point besides saving a tiny insignificant amount of bandwidth in favor of code that is not intuitive, and unwanted complexity.

Its not a big change, I say we make a nonbackwards compatible change, any lobbies or bots which dont adapt would have to face a problem like this sooner or later, and everybody pretty much ignores ranks in 99% of games already anyway

[BrainDamage]

i had to edit my reply too since otherwise it would be stating wrong stuff ( the concept you described is similar to SL's code, but not the code implementation )

it's not the amount of lines, we simply want them gone, not increased, it would be a step backwards in the protocol's flexibility for range increases. ( 16 teams limit in lobby for instance is derived from bitfields, or max amount of factions, etc )

also, this conversation is starting to circle, if you really just can't accept the arguments, then take it as "completely personal opinion based on past experiences", answer won't change, we just can't stand bitfields anymore

[AF]

I know, if anything in some codebases it might be longer code, but bitfields are not nice to look at in code when being parsed.

[echoone]

lso, this conversation is starting to circle, if you really just can't accept the arguments, then take it as "completely personal opinion based on past experiences", answer won't change, we just can't stand bitfields anymore

???

I replied only because you were so quick with your reply. We were two ships passing and I didn't think you had seen my whole reply. Its circling only because of the timing of our replies/edits. Nothing more. That's why I added the last bit.

No need to get adversarial. After all, I was just trying to help.

[BrainDamage]

No need to get adversarial. After all, I was just trying to help.

there is no anger/rage in my tone, I apologize if it seemed so, I wanted to close this conversation since it seems that nothing more can be gained from it ...
and circling conversation bit is about the fact that I had to repeat my statement multiple times that lobby devs don't want bitfields/bitfields/bitmasks or any bit crap in general, and it's a non negotiable condition