[solved] BATTLEOPENEX was undocumented
Moderators: Moderators, Lobby Developers
[solved] BATTLEOPENEX was undocumented
Whats with BATTLEOPENEX? its undocumented...
https://github.com/spring/LobbyProtocol/issues/11
for me it makes no sense to implement it until its documented.
the guys who implemented it (i guess aegis & licho) can they please document it?
https://github.com/spring/LobbyProtocol/issues/11
for me it makes no sense to implement it until its documented.
the guys who implemented it (i guess aegis & licho) can they please document it?
Last edited by abma on 26 Mar 2013, 08:01, edited 1 time in total.
- danil_kalina
- Posts: 505
- Joined: 08 Feb 2010, 22:21
Re: BATTLEOPENEX is undocumented
The compat flag set on login is "eb"
You will recieve
BATTLEOPENEDEX
with two new arguments between map hash and map name there are 2 new parameters:
- engine name
- engine version
( "Spring" and "91.0" for example )
You can also use OPENBATTLEEX and set those parameters for battles you host.
You will recieve
BATTLEOPENEDEX
with two new arguments between map hash and map name there are 2 new parameters:
- engine name
- engine version
( "Spring" and "91.0" for example )
You can also use OPENBATTLEEX and set those parameters for battles you host.
Re: BATTLEOPENEX is undocumented
anyone willing to document it?
- danil_kalina
- Posts: 505
- Joined: 08 Feb 2010, 22:21
Re: BATTLEOPENEX is undocumented
access granted ?
Re: BATTLEOPENEX is undocumented
send a pull request? you don't need access...
Re: BATTLEOPENEX is undocumented
I think BATTLEOPEN/BATTLEOPENED must be removed for these to come into use.
Basically there should be two more columns in the lobby battle list: "Engine" and "Engine version". The lobby should preferably keep all engines in subfolders.
/lobby/maps
/lobby/games
/lobby/spring_91.0/
/lobby/spring_94.0/
etc.
Autodownloading of engines isn't gonna work though, so just need a common place for all engine downloads, e.g. springrts.com/wiki/engines
With this, no need to enforce any versions on the server...
Basically there should be two more columns in the lobby battle list: "Engine" and "Engine version". The lobby should preferably keep all engines in subfolders.
/lobby/maps
/lobby/games
/lobby/spring_91.0/
/lobby/spring_94.0/
etc.
Autodownloading of engines isn't gonna work though, so just need a common place for all engine downloads, e.g. springrts.com/wiki/engines
With this, no need to enforce any versions on the server...
Re: BATTLEOPENEX is undocumented
no, its kept for backwards compatibility. it could be removed when all lobbies support it.zerver wrote:I think BATTLEOPEN/BATTLEOPENED must be removed for these to come into use.
zero-k lobby & afaik nota lobby already do this. current version of weblobby should do this, too.zerver wrote:Basically there should be two more columns in the lobby battle list: "Engine" and "Engine version". The lobby should preferably keep all engines in subfolders.
you missed some years of development? at least 3 lobbies support engine download!zerver wrote:Autodownloading of engines isn't gonna work though, so just need a common place for all engine downloads, e.g. springrts.com/wiki/engines
also, you missed this: http://api.springfiles.com/?category=engine_windows
the common place already exists at http://sourceforge.net/projects/springr ... springrts/ and http://springrts.com/dl/buildbot/default/master/ no wiki page needed...
Re: BATTLEOPENEX is undocumented
many thanks!
(i wanted to do it you / aegis or licho as i have no clue what to talked before it was implemented to uberserver)
(i wanted to do it you / aegis or licho as i have no clue what to talked before it was implemented to uberserver)
Re: BATTLEOPENEX is undocumented
Thank you danil_kalina, however this patch doesn't specify at all how the lobby server behaves regarding versionned battles and legacy lobby clients which don't handle this protocol extension.
Also, for both new commands OPENBATTLEEX and BATTLEOPENEDEX you specify the two new parameters "engineName" and "engineVersion" as sentence parameters (surrounded by { }, which means they are separated by tab characters), whereas according to uberserver code they are normal parameters (separated by spaces).
Also, for both new commands OPENBATTLEEX and BATTLEOPENEDEX you specify the two new parameters "engineName" and "engineVersion" as sentence parameters (surrounded by { }, which means they are separated by tab characters), whereas according to uberserver code they are normal parameters (separated by spaces).
Re: BATTLEOPENEX is undocumented
i guess the lobby clients which don't support it just get the normal openbattle data and are likely to desync if lobby server version != autohost version of spring.bibim wrote:this patch doesn't specify at all how the lobby server behaves regarding versionned battles and legacy lobby clients which don't handle this protocol extension.
Re: BATTLEOPENEX is undocumented
Actually it's a bit more complex than this. Iirc, for legacy clients uberserver prefixes the incompatible battle names so that users know the battle isn't compatible with their current version. What would be interesting to know for example is how uberserver decides if 2 versions are incompatible (for some reason it considered 93.1 as incompatible with 93.2...).abma wrote:i guess the lobby clients which don't support it just get the normal openbattle data and are likely to desync if lobby server version != autohost version of spring.
Re: BATTLEOPENEX is undocumented
i didn't look into the code, but i would think uberserver doesn't decide here anything. clients have to decide if they are compatible by version string they get from lobby server.
Re: BATTLEOPENEX is undocumented
We are speaking of legacy clients here, which don't receive any version string for battles.abma wrote:i didn't look into the code, but i would think uberserver doesn't decide here anything. clients have to decide if they are compatible by version string they get from lobby server.
- danil_kalina
- Posts: 505
- Joined: 08 Feb 2010, 22:21
Re: BATTLEOPENEX is undocumented
Bibim, you are takeing it too seriously. This is patch, not the coolest protocol ever. Take it easy
Re: BATTLEOPENEX is undocumented
I'm taking it easy, why do you think otherwise?danil_kalina wrote:Bibim, you are takeing it too seriously. This is patch, not the coolest protocol ever. Take it easy
I don't get what you mean actually... Because it's not a perfect protocol, we shouldn't fix wrong specifications in it?
Re: [solved] BATTLEOPENEX was undocumented
Yeah, wrong documentation is worse than none imo.
Re: [solved] BATTLEOPENEX was undocumented
I think it is a security risk, and useless unless it works on all supported OS:s.abma wrote:you missed some years of development? at least 3 lobbies support engine download!
Re: [solved] BATTLEOPENEX was undocumented
Out of which:at least 3 lobbies support engine download!
- one is a gpl-violating thing that has rigidly unfixable rules about what counts as spring executable (linux Optimus users? never heard of those)
- one is a windows-only dotnet thing that is mostly a lobby for running a single game (even though it can be told to support others)
- one runs in your browser. oh, wait, did i say "runs"? more like walks. leisurely.
:X
Re: [solved] BATTLEOPENEX was undocumented
weblobby, notalobby & pr-downloader works on all os'. also pr-downloader is mostly a lib, so it can be adapted by others.zerver wrote:I think it is a security risk, and useless unless it works on all supported OS:s.abma wrote:you missed some years of development? at least 3 lobbies support engine download!
security risk? i don't see a big difference between typing in an url, download a program, run it and run a lobby which (maybe asks before) downloads a program and runs it.
the problem arises when it happens automaticly and the user can't verify if weird things happen.
yeah, there could be some things improved, like: create file checksums of the generated files already at the buildslaves, so it can be verified if they were modified. the checksum currently is created at springrts.com, so we could only reduce the point were files could be modified from two to one.
users who don't trust have to compile the code their self, but they also have to trust, that the source-code wasn't modified / contains backdoors.
what we should care about is, that spring / lobbies are not remotely exploitable, which practically means: no autohost owner or a lobby client should have the possibility to "infect" others with viruses/worms/trojans (lua scripts count here, too) automaticly.
it always comes to the point, where a user has to trust the program he downloads and runs. We only can help, that users can verify that the code wasn't modified by a 3rd party and our programs should run without system privileges.
Also we can't prohibit, that a users installs and runs malicious code.