make current docs available

[abma]

https://github.com/spring/LobbyProtocol/issues/21

[Yaribz]

This document already exists, this should just be an old version of current doc.

[abma]

no, it never matched lobby server implementation

[Yaribz]

Maybe not exactly, but it was very close (only the multi engine extension was missing afaik). Now, even the basic commands such as OPENBATTLE aren't consistent with server implementation and can't be used as specified in the document.

[abma]

it was totally bogous and is still totally bogous, aggreed. i don't really get, what your intention of this feature / bug request is.

i hope current proposal of lobby protocol specs are ok. they have / had many issues/bugs which makes some commands unusable in some cases.

for example OPENBATTLEEX protocol spec for parameter enginename & version was, that its a sentence but it was implementated as words. i don't really see a downside in the "proposals" to fix this flaws with a newly introduced compatibility flag + fixing this.

for OPENBATTLEEX the "proposals" should match, for OPENBATTLE atm they don't match the implementation.

edit: as OPENBATTLEEX was already used in many places it was somehow impossible to fix the implementations as its very difficult to fix all at once, so spec was adjusted to match the implementation.

[abma]

only solution i see atm is to keep generated docs, so it can be easily browsed for changes. atm only git (+history) can be used to do that.

[Yaribz]

it was totally bogous and is still totally bogous, aggreed. i don't really get, what your intention of this feature / bug request is.

It wasn't totally bogous, why are you saying that? As I said, the only delta I can think of was the multi-engine protocol extension which was missing. My intention with this issue is just to say we should have a specification available as we used to.

i hope current proposal of lobby protocol specs are ok. they have / had many issues/bugs which makes some commands unusable in some cases.

I'm sure the proposal is good, but it's a proposal, not a spec. Concerning the spec, I will say it again: it WAS good and very close to implementation, which allowed lobby devs to make working lobbies. We just need to put this exact same spec back online (even if it lacks the multi engine description at first, it's still better than nothing).

for example OPENBATTLEEX protocol spec for parameter enginename & version was, that its a sentence but it was implementated as words. i don't really see a downside in the "proposals" to fix this flaws with a newly introduced compatibility flag + fixing this.

I don't see the downside neither? I never said it was bad to make proposals/fixes, I just said we should have a specification document as we used to.

for OPENBATTLEEX the "proposals" should match, for OPENBATTLE atm they don't match the implementation. edit: as OPENBATTLEEX was already used in many places it was somehow impossible to fix the implementations as its very difficult to fix all at once, so spec was adjusted to match the implementation.

Uh? I can't even find any OPENBATTLEEX description in the proposal, it was removed with "cl" comp flags proposal

only solution i see atm is to keep generated docs, so it can be easily browsed for changes. atm only git (+history) can be used to do that.

We just need 2 versions of the doc: the spec and the proposals. We used to only have the spec, now we only have the proposal.

[abma]

It wasn't totally bogous, why are you saying that? As I said, the only delta I can think of was the multi-engine protocol extension which was missing. My intention with this issue is just to say we should have a specification available as we used to.

data types for example didn't match / still don't match. currently there are many differences in whats in the lobby protocol and what is used in real. for example userid is a int64, but lobby spec says it should be hex. on lobby server side it is handled as string, clients use the int64.

Uh? I can't even find any OPENBATTLEEX description in the proposal, it was removed with "cl" comp flags proposal

yep, because OPENBATTLEEX was completely redundant to OPENBATTLE

I will say it again: it WAS good and very close to implementation, which allowed lobby devs to make working lobbies. We just need to put this exact same spec back online (even if it lacks the multi engine description at first, it's still better than nothing).

when was it good? thats completely subjective. it never reflected the current implementation in complete. there always differences, atm they are a bit bigger than seen in history because currently there stuff is changed. before for months stuff wasn't changed, this is why it was "better" before.

this discussion leads to nothing :-|

[abma]

maybe to clarify:

there are no "current docs" related to https://github.com/spring/LobbyProtocol, current doc is the source code / source code docs. since the "lobby dev meetings" it changed to proposals, before it just documented the current state of development this is why they were more accurate maybe.

feel free to document the current state, but atm i don't have the time to document it, i can just try to minimize the differences, for OPENBATTLE that would mean, implement the cl flag ASAP.

[Yaribz]

data types for example didn't match / still don't match. currently there are many differences in whats in the lobby protocol and what is used in real. for example userid is a int64, but lobby spec says it should be hex. on lobby server side it is handled as string, clients use the int64

Once again, this is a very minor thing. This has nothing to do with the major change proposals currently in the document. Also, if the server handles it as a string, then it respects the spec, it's just that it's more permissive.

yep, because OPENBATTLEEX was completely redundant to OPENBATTLE

I know, but then why do you tell me that the proposal should match for OPENBATTLEEX whereas it's not even described in it?

when was it good? thats completely subjective. it never reflected the current implementation in complete. there always differences, atm they are a bit bigger than seen in history because currently there stuff is changed. before for months stuff wasn't changed, this is why it was "better" before.

I repeat: it was very close to implementation. It was a usefull spec for anyone wanting to dev a lobby. I will try to make it simpler: it used to be possible to dev a working lobby using this document, it's no longer possible. I wouldn't be able to dev SPADS for example if I discovered Spring only now.

there are no "current docs" related to https://github.com/spring/LobbyProtocol, current doc is the source code / source code docs. since the "lobby dev meetings" it changed to proposals, before it just documented the current state of development this is why they were more accurate maybe.

No, the document available online was always corresponding to current protocol in use. Of course there could be a version with some changes in some repository, but the true specification was always available online in HTML format (I wouldn't have been able to dev SPADS otherwise).

feel free to document the current state, but atm i don't have the time to document it, i can just try to minimize the differences, for OPENBATTLE that would mean, implement the cl flag ASAP.

Current lobby protocol production state is more or less the same as one year ago. As I already said just above, we should just make the original document back available online, it would be much closer to reality than the proposal one (and once again I repeat: I don't say we should remove the proposal, it's just a different document with different goal).

this discussion leads to nothing :-|

Indeed, it seems once again I can't make you understand what I mean so I give up, feel free to close this issue, it's a waste of time.

[abma]

Current lobby protocol production state is more or less the same as one year ago. As I already said just above, we should just make the original document back available online, it would be much closer to reality than the proposal one (and once again I repeat: I don't say we should remove the proposal, it's just a different document with different goal).

which version? git hash please...

[Yaribz]

I guess spring/LobbyProtocol@884068c9fca57c6f3ac0d0e90d76a324b9514aed would be a good candidate.

[Yaribz]

And after taking a brief look at commit history, following commits should be applied to spring/LobbyProtocol@884068c9fca57c6f3ac0d0e90d76a324b9514aed to get a specification quite consistent with current protocol in production:

spring/LobbyProtocol@b6393ad5d34d1f11f7da4cc770960d60d0d4f379 add command FORCEJOINBATTLEFAILED:server spring/LobbyProtocol@6be1d7e0e02b09645a018e5f477efe763cbbd1e4 clarify server-wide engine version setting and updates spring/LobbyProtocol@dae3b75110d8a382ab92d78999e6d17680ca18b9 Merge branch 'exit' spring/LobbyProtocol@12361b740afc0cf0df579d9edac8b9f0e32f6ed3 Merge branch 'getingametime' spring/LobbyProtocol@b01e3b08bd46d8aa2a0738392aa17d8b01ebf92b Merge pull request spring/LobbyProtocol#10 from renemilk/master spring/LobbyProtocol@9fd8cc63b33a2f69671be71971aea5ac1f199e8e Merge pull request spring/LobbyProtocol#12 from danil-kalina/patch-1 spring/LobbyProtocol@efc58fbeefa4fbdbc97a34e2247d60330c1e63f5 apply bibim's docu-patch about client startscript usage (issue spring/LobbyProtocol#13) spring/LobbyProtocol@4f095b479c6abfac39639bea78bb7be910697790 add weblobby known cpu identifiers spring/LobbyProtocol@7a4312377d4b2e1fa855d0d21518ae6a940fbf18 adjust docs to implemention spring/LobbyProtocol@cc2889d2f66805488cb03fee33fd14acba0c0f60 update PING description, thanks bibim!

[abma]

cherry-picking these commits leads to many merge conflicts...

thats all i can do atm: http://springrts.com/dl/LobbyProtocol/releases/

[abma]

note: because lobby server supports now the cl flag, docs and specs should match in most important cases.

lobby server has 0.36 implemented and some stuff of 0.37 http://springrts.com/dl/LobbyProtocol/ProtocolDescription.html#0.37