=== suggestions for protocol changes ===
<sheepdev1> current protocol doesnt define any way to negotiate protocol features
<sheepdev1> there is a compFlags parameter... but server doesnt advertise what it supports
<sheepdev1> and doesnt confirm he accepted requested compflags
<sheepdev1> whatever change we make, i think this should be addressed so client can find out what server supports
<sheepdev1> reasonable?
<a1983> yes
<a1983> I think we must request feature from server, and he respond
<a1983> maintain it or not
<Malina> +1
<[ARP]hoijui_irc> sound ok
<sheepdev1> would you have to ask for supported features? or should it be advertised before/after TASServer statement?
<[ARP]hoijui_irc> ouh one thing.. maybe we shoudl agree on a protocol standard
<[ARP]hoijui_irc> as in.. currently it is kind of the XML document on the git repo
<[ARP]hoijui_irc> is everyone ok wiht that?
<a1983> And server can request from client some needed features I think
<[ARP]hoijui_irc> we already know that aegis is not
<[ARP]hoijui_irc> or he woudl at least refuse to change the XML himself
<cheesecan> why
<[ARP]hoijui_irc> is anyone agasint using the XML/rpo somethign else?
<sheepdev1> no the xml is fine (but i have some requests about its content/format)
<a1983> What is else?
<a1983> If it will be like google probuf - I agree
<sheepdev1> are we/you talking about a complete protocol redesign or just some changes to it?
<[ARP]hoijui_irc> lets first do small changes maybe
<[ARP]hoijui_irc> ok lets say the XML is ok
<_koshi_> +1
<a1983> If small - then of cause xml must be stayed
<sheepdev1> +1
<cheesecan> +1
<BrainDamage> +1
<[ARP]hoijui_irc> maybe we can discuss stuff here first, get to a rought agreement on what shoudl be done and how, and then someone makes a proposal for the change on git, on the XML)
<[ARP]hoijui_irc> i though small si good at first, to see how the whole thing works out
<[ARP]hoijui_irc> like.. the meeting and people doing stuff they shoudl be doing
<_koshi_> yeah
<[ARP]hoijui_irc> ok then... lets go on with that about.. how to treat different protocol versions
<sheepdev1> currently, you must request additional features on the LOGIN statement (compflags parameter)
<sheepdev1> so server either need to advertise what it supports in the TASServer statement (may break older clients) or answer to a LISTCOMPFLAGS like command before login
<sheepdev1> or use something else than login compflags
<a1983> different version is not comaptible, so lobby should be disconnect, if outdated
<sheepdev1> i dont know about details, but from what i read in the spec, TASServer advertise product version, not protocol version... maybe i'm wrong
<cheesecan> that's correct
<cheesecan> spring major version is advertised, maybe also minor version
<Malina> only major
<[ARP]hoijui_irc> TASServer command advertises protocol version
<[ARP]hoijui_irc> it was jsut documented wrong in hte protocol specs, i fixed that abotu a month ago
<[ARP]hoijui_irc> the protocol version was fixed to TASServer version
<[ARP]hoijui_irc> it is not anymore now
<[ARP]hoijui_irc> so protocol version is now 0.35 (whcih was latest released TASServer version)
<cheesecan> 0.36?
<Malina> I mean Spring Engine version
<sheepdev1> i see 0.36 in my working doc
<cheesecan> I think sheepdev1's suggestion of listcompflags command seems good..
<[ARP]hoijui_irc> ouh ok, sorry then
<[ARP]hoijui_irc> 0.36
<[ARP]hoijui_irc> ok that means.. no change to how it is done now?
<[ARP]hoijui_irc> or would we need a way to qualify protocol changes as optional or not
<[ARP]hoijui_irc> so if server advertises a non optional feature, client would disconect?
<a1983> hoijui is right - currently TASserver report protocol version 0.35, but in XML latest 0.36
<cheesecan> that doesn't make sense compflags are all optional
<[ARP]hoijui_irc> ah ok
<[ARP]hoijui_irc> so compflags are optional, and server version is mandatory stuff?
<sheepdev1> yes that would be for optional features only... bumping protocol version if it breaks older client as it was done until now seems good
<a1983> I think it's kinda hack
<a1983> We don't need old clients
<a1983> Cause they not work on new spring
<cheesecan> they might work if unitsync is not updated in a new spring version
<cheesecan> *unitsync api
<_koshi_> or if they lod a fitting usync
<_koshi_> load*
<Licho[0K]> back
<sheepdev1> there is a chicken/egg timing problem when releasing new versions of protocol... i dont know how you handle it now
<[ARP]hoijui_irc> we surely will not kick clients just cause they are not up to date with technically optional changes
<[ARP]hoijui_irc> that is bad
<cheesecan> if you want to have to update your client every time lobby server protocol changes: use mandatory disconnect if protocol version is newer than what lobby was compiled for. If you want to have backward-compatibility, implement proper optional/non-optional flags :)
<a1983> Of cause not, but it seems that you have much and much "optional" parametrs
<Licho[0K]> i would recommend spring server to advertise both major and minor
<Licho[0K]> its up to client to decide whether to update
<Licho[0K]> some clients - like zkl wish to always update to latest because it costs nothing and its usually a bugfix
<[ARP]hoijui_irc> thats casue we did not have non-optional changes for a long long time
<_koshi_> protocol rev, not engine licho
<cheesecan> let's be clear, there are two issues: spring engine versions - and lobby server version
<Licho[0K]> protocol changes uses compatibility flags now
<Licho[0K]> every new breaking feature has compat flag
<sheepdev1> the compflags are already here, it just miss a way to negotiate them... if it is a hack, it should be removed completely, if it stays, there should be a way to know what server supports
<Licho[0K]> you dont want client that changes behavior based on server .. assume server knows more or same as client :)
<a1983> It's because autohost and they irc system commands
<a1983> so main protocol is unchanged
<a1983> But all changes in autohost system
<cheesecan> then..we should add all new features in compat flag IF they break existing lobby?
<Licho[0K]> yes or if they introduce new message ignored by lobby
<Licho[0K]> its done this way and works fine
<[ARP]hoijui_irc> ok .. so you say compatflags were abused so far, licho?
<[ARP]hoijui_irc> ouh..
<Licho[0K]> abused? no i think system works fine
<cheesecan> how about our first small change is !join compflag?
<Licho[0K]> no problem with it, its great
<[ARP]hoijui_irc> so the protocol version is useless?
<Licho[0K]> yes protocol version is useless and should be useless for most of use
<cheesecan> I don't know about these joinbattleaccept commands, if you're using them
<[ARP]hoijui_irc> how to differentiate optional form non optional then?
<Licho[0K]> comapt flags include lobby id support, join accept support and multi engine support
<Licho[0K]> all compat flags are optional
<Licho[0K]> thats whole point of them, there is backwards compatibility
<cheesecan> 'b': client supports battle authorization system (JOINBATTLEREQUEST,
<cheesecan> JOINBATTLEACCEPT and JOINBATTLEDENY commands)
<[ARP]hoijui_irc> aehh.. ok...
<cheesecan> these are not sufficient to implement !join?
<[ARP]hoijui_irc> but then protocol version is not useless
<Licho[0K]> no they are completely not related to join
<Licho[0K]> join -> redirect user to new host
<cheesecan> so join is forced joining
<Licho[0K]> join accept is just denying user entry to battle
<cheesecan> aha
<cheesecan> then we can add a new flag for you
<cheesecan> as the first small change
<Licho[0K]> as for whats needed for matchmaking - it all depends how ambitious you are .. the simplest way to do it is by supporting only join
<Licho[0K]> more advanced need many more commands/transfers and for sure "!connect ip" or something like that
<Licho[0K]> juggler is just hacky way to make matchmaking with least changes in lobby
<Licho[0K]> (to support other than zkl lobbies easilly)
<cheesecan> why ip?
<Licho[0K]> because for real matchamking, lobby room is irrelevant
<Licho[0K]> you will send ip/port to connect spring
<sheepdev1> would it be better to have proper commands rather than "inband" !join ?
<Licho[0K]> (when battle is finalized and ready to start)
<cheesecan> you mean for instant matchup
<Licho[0K]> well thats how matchmaking works in other games
<Licho[0K]> juggler is bastard son of proper way and legacy lobby support
<cheesecan> I like that idea
<Licho[0K]> that "idea" needs far more than "connect ip" though - you need new interface in lobby
<Licho[0K]> you need to excahnge preferences
<Licho[0K]> you need to exchange map/mod/engine presence/download status
<Licho[0K]> etc
<cheesecan> that is a pretty big change, I suggest we do that after join
<Licho[0K]> its so much changes there is no guarantee it would be done this century in non zkl, thats why we started with !join
<sheepdev1> whats the status of the propertymap ?
http://cgit.springlobby.info/cgit/aegis ... rtymap.txt
<Licho[0K]> also you can make matchmaking ike that in engine itslef
<Licho[0K]> since next release with luasocket
<Licho[0K]> proeprty map was implemented by my hack
<Licho[0K]> /j #nightwatch
<Licho[0K]> aegis promised it but its not done yet
<Licho[0K]> i want to switch syntax of my hacks to json but thats all
[20:37] ** Sprung joined the channel.
[20:37] ** Sprung left the channel( ).
<_koshi_> that property stuff is over a year old now iirc
<cheesecan> well all I know is..join is obviously needed, specs sit in games hoping to be able to unspec, asking people to leave with you and join another game has erratic success at best..
<BrainDamage> but don't assume that all specs want to be moved
<BrainDamage> some just really want to spec
<[ARP]hoijui_irc> indeed!
<Licho[0K]> juggler is not moving specs
<cheesecan> that is why lobby should prompt user if they want to be moved
<Licho[0K]> meh how you can ask if they want to be moved?
<Licho[0K]> hey do you want to be moved to 8 ppl game (8 ppl if all agree) ..
<Licho[0K]> now 50% wont agree
<cheesecan> something like joinrequestaccept/joinrequestdeny
<Licho[0K]> and you just annoy those who agreed who end up in 4 ppl game
<Licho[0K]> and next time disable it
<BrainDamage> a checkbox
<BrainDamage> do you want to be randomly moved in a game?
<Licho[0K]> there can be permanent opt in/opt out
<Licho[0K]> actually thats exactly what juggler does
<Licho[0K]> it randomly moves you ..
<Licho[0K]> it has battle classes .. like small teams, big teams etc
<cheesecan> it could send joinrequestupdate and say how many accepted, if enough accept only it joins
<sheepdev1> +1 to cheesecan proposal... if you want your zkl users to have have the choice, let zkl always accept
<sheepdev1> to *not have the choice
<Licho[0K]> if there are multiple small teams it can merge/split them (in memory) to make 2 same sized battles of different skill levels
<Licho[0K]> separating nubs from pros
<a1983> What bad to implement
<Licho[0K]> that should not be request
<Licho[0K]> thats crazy
<Licho[0K]> you dont want to spam 300 people every 10s
<Licho[0K]> thats what juggler does
<Licho[0K]> it runs algo every couple of seconds
<Licho[0K]> it has to be preference "enable juggler" "disable juggler"
<Licho[0K]> sent to server
<cheesecan> so you want user to control themselves if they have it on/off, if on they are always moved
<Licho[0K]> yes
<cheesecan> that sounds ok
<Licho[0K]> but problem is it makes the algo very complex
<sheepdev1> what about some kind of publish/subscribe about current battles that may be started... if you subscribed to one of those battles, you get moved to that battle forcibly and game can start
<Licho[0K]> or it can screw battles for them
<Malina> +1
<Licho[0K]> like it could move all people except those unmovable out
<Licho[0K]> meh whats the point sheep?
<Licho[0K]> juggler can make new battle out of existing people
<Licho[0K]> does not matter whats there
<cheesecan> a lot of people go idle while waiting, maybe eating or w/e, can't rely on them being present
<Licho[0K]> like if it finds two good partners for 1v1 that prefer to play 1v1 it makes game for them
<Licho[0K]> or ffa or small teams or whatever
<a1983> I think juggler need onl for noobs
<Licho[0K]> all based on preferences
<a1983> So it must be simple
<a1983> ans good way to start battle
<Licho[0K]> seriously stop theoretizing about existing system
<Licho[0K]> it works , its simple, it lets user set preferences
<Licho[0K]> its already done, running for several months
<cheesecan> it is proven, so now add to lobby protocol so we don't need to spam pms :)
<cheesecan> you are even pming me my level increased in zk
<Licho[0K]> thats for SL people again
<cheesecan> lol well point of meeting is not to throw blame
<cheesecan> but see how we can solve it
<a1983> ok, so how does it implement in TAS prortocol?
<[ARP]hoijui_irc> yeah.. there seems to be a quasi agreement now abotu these new commands, if anyone already knows he is agasint this, he should speak now
<sheepdev1> so whats requested is something that would replace !join with a command... like FORCEJOINBATTLE
<[ARP]hoijui_irc> if not, it should be done more precise
<[ARP]hoijui_irc> dont know if in xml yet
<Licho[0K]> basically commands depend on how much capability you want to add to existing lobbies
<[ARP]hoijui_irc> then we can talk abotu it agian or vote or something
<Licho[0K]> for barebone stuff - just forcejoin is needed
<Licho[0K]> for more advanced you need a way to exchange preferneces
<cheesecan> well for next meeting, the people with most insight(licho) should suggest protocol commands necessary to interface with juggler
<BrainDamage> we could do in steps
<BrainDamage> do first the forcejoin
<Licho[0K]> for even mor e excahnge map/mod/engine presence and download progress and add connect too
<Licho[0K]> for final do that in mod itself even without lobby (usins some bridge) so you could search for another battle while speccing
<Licho[0K]> oh also more advanced needs friends - friend invite/accept
<Licho[0K]> (play with friends)
<a1983> I think we agreed that only simple changes in protocol
<a1983> Wo we add FORCEJOIN command
<a1983> So? or not?
<Licho[0K]> you should do that with compatibility flag
<Licho[0K]> and let others discover if you support it
<a1983> and another one compFlags?
<Licho[0K]> + something to discover compat flags of users
<a1983> j - juggler support
<Licho[0K]> who will do it?
<sheepdev1> seems fine... add a new compflag definition for forcejoinbattle command, add LISTCOMPFLAGS command for client to request server supported compflags, add CLIENTCOMPFLAGS command for a client to request another clients enabled compflags
<cheesecan> it's not a big deal to checkout ueberserver and add some cmds..
<Malina> JOINBATTLE - in protocol. -> JOINBATTLEFORCE
<Licho[0K]> that would mean list spam on every adduser but ok
<[ARP]hoijui_irc> licho, who will do what?
<Licho[0K]> uberserver changes
<Licho[0K]> lobby changes
<[ARP]hoijui_irc> server impl.? protocol spec?
<Licho[0K]> specs
<Licho[0K]> pffs
<cheesecan> then just do a pull request and let hoijui or aegis check it
<Licho[0K]> just invent suitable name :)
<[ARP]hoijui_irc> specs first, then vote, then change in server and lobbies
<cheesecan> most important is that it is correct in the first place, no happy hacking
<Licho[0K]> who will do it?
<Licho[0K]> and when?
<Licho[0K]> you realize i already requested just that
<Licho[0K]> from aegis
<Malina> how you will call the ship that is how it will sail
<Licho[0K]> 14 and 2 months ago
<cheesecan> licho *you* need to suggest protocol changes for next meeting, then we can do it
<sheepdev1> democracy is slow
<Licho[0K]> i requested it from aegis he invents protocol
<_koshi_> there also needs to be a client command that triggers that server command
<[ARP]hoijui_irc> licho, you do spec change i woudl say, then we vote on it?
<cheesecan> I need one document stating exact command syntax
<Licho[0K]> he also plans to do it with backwards compatibility
<Licho[0K]> so it force joins even outdated clients
<Licho[0K]> using forged messages
<Licho[0K]> _koshi_ there is no such thing as client caused trigger
<[ARP]hoijui_irc> we dont care what you discussed in private with aegis here
<Licho[0K]> some autohost participate in the scheme
<Licho[0K]> those send detailed data to server
<Licho[0K]> and server executes it every couple of seconds and when battle ends
<Licho[0K]> it then returns list of changes to autohosts - which to delete, which to add, who to move where
<Licho[0K]> it does not work from individual user perspective, its awlays global shuffle operation
<Licho[0K]> im just saying without people doing work its all moot and its better to implement !join :)
<_koshi_> then i'm missing sth licho
<Licho[0K]> unless someone declares he will do it instead of aegis
<cheesecan> i'm jsut saying don't worry about work, focus on making a documentation for changes, then we can implement them
<[ARP]hoijui_irc> we already discussed that in the beginnig licho
<_koshi_> uberserver would know how and when to send the new protocol command to someone how exactly?
<Licho[0K]> uberserver wont
<Licho[0K]> ok i will descrie how current system works
<cheesecan> ueberserver is a git project, nothing stops u from forking it and making changes then doing a pull request
<Licho[0K]> all springies report to nightwatch, nightwatch dfecides what to do and reports to springies
<Licho[0K]> (it can report to any autohost)
<Licho[0K]> autohost executes !join commands
<Licho[0K]> to move its people out
<sheepdev1> is aegis also operating/maintening on the server ?
<Licho[0K]> server runs on springrts.com machine, we have access to it but he is the boss
<Licho[0K]> we can change it but he will get angry if its not agreed by him
<Malina> we must have a Juggler separate
<Licho[0K]> juggler is separate
<Malina> autohost shouln't do that
<Licho[0K]> you can also find more uses to !join than juggler
<Licho[0K]> only host has necessary information
<Licho[0K]> ytou cannot tell who is spec adn who not and who is ingame player and who not
<Licho[0K]> only autohost knows that
<Licho[0K]> and autohost sends that to juggler
<Malina> server knows everything
<Licho[0K]> no it does not
<Licho[0K]> it does nto know who is ingame player
<Licho[0K]> only autohost knows that, server knows nothing about startscript
<Licho[0K]> or who died ingame
<Malina> we have Players status
<Licho[0K]> who left the game and who just left lobby
<Licho[0K]> malina this says nothing i assure you
<Licho[0K]> there is no guarantee its synced
<Licho[0K]> springie can generate script that makes specs players and vice versa ingame
<Licho[0K]> and it does such things to change team ids for examples
<Licho[0K]> and only springie knows who died ingame
<BrainDamage> oh, and i added possibility for spring to let dynamic joins to attach to an existing team >_>
<Licho[0K]> yeah..
<BrainDamage> ( up to the autohost )
<Licho[0K]> so springies send "ingame " and "lobby" context to juggler
<Licho[0K]> basically list of players with information aobut their statuses
<cheesecan> well zk don't even care about ready/unready
<cheesecan> game is always forced
<Licho[0K]> but anyway you dont need to implement that its already done by springies .. you can run as many springies as needed
<Licho[0K]> you dont have to care about that end of the system
<sheepdev1> licho i dont understand why you say you cannot tell who is spec and who is not, same with ingame
<Licho[0K]> matchmaking hosts must be special anyway
<cheesecan> because zk forces and then re-assigns
<BrainDamage> say a player dies in the game
<Licho[0K]> because you cannot unless you host the battle and run the dedicated
<BrainDamage> or resigns
<BrainDamage> that player is now a spec ingame
<a1983> for that - send by lobby user JOINBATTLEWANT, and server say to some players (matchamking autohost) that user status changed
<BrainDamage> but a player in the lobby
<Licho[0K]> yes what bd says
<Licho[0K]> or say you restart lobby while you play
<Licho[0K]> you are not ingame in lobby
<Licho[0K]> but player ingame
<Licho[0K]> again only autohost/dedi server know that
<sheepdev1> ok
<Licho[0K]> it works you really dont need to think about this part :)
<Licho[0K]> its internals of matchmaking
<Licho[0K]> no special support from lobbies needed
<Licho[0K]> you dont want to host matchmaking srever nodes on clients
<Malina> what about other autohosts ?
<Licho[0K]> springrts.com provides hosting for any mod that asks
<sheepdev1> and permissions to request a user to join
<Licho[0K]> again matchamking is special its fine that we dont have 3 softwares to run matchmaking nodes
<Licho[0K]> most autohost wont be matchmaking srevers of course
<Licho[0K]> its not to change all games
<Licho[0K]> its too add new option
<sheepdev1> we dont but it should be open enough so there could be competing matchmakers
<_koshi_> indeed
<Licho[0K]> jesus
<Licho[0K]> fine when you code your own
<_koshi_> also, we kinda drifted from my original question
<Licho[0K]> you code your own autohosts too
<Licho[0K]> so you dont need to know how mine works
<Licho[0K]> though i will gladly describe details
<_koshi_> I asked how server knows when to trigger this new command to which you said it won't, right Licho?
<cheesecan> meeting has been going for a while now, unless we want to spend whole evening here, I suggest we move on to the point of what should be done between next meeting to bring about this protocol update
<Licho[0K]> what you mean server
<Licho[0K]> which srever?
<Licho[0K]> uberserver?
<_koshi_> lobby server
<Licho[0K]> battle host tells it to uberserver .. battlehost sends FORCEJOIN player host
<Licho[0K]> (player must be joined on that battlehost)
<_koshi_> and that first bit needs to be documented as well
<sheepdev1> forcejoinBATTLE please (to not confuse with channels)
<Licho[0K]> ok call it whatever you want
<sheepdev1> and command must be restricted (to who?)
<Licho[0K]> atm its !join
<Licho[0K]> to battlehost and admin
<Licho[0K]> as is now
<Licho[0K]> (lobby moderator)
<a1983> but may be user must send commnad that he want use JUGGLER?
<_koshi_> because all your active parts may want to send that?
<_koshi_> as in any auothosts, bot in your system?
<Licho[0K]> there is compatibility flag for that a1983
<Licho[0K]> well for juggler only battlehost sends the !join
<a1983> But how can I tell that I don't want use juggler?
<Licho[0K]> but admins sometimes want to move people manually
<Licho[0K]> thats why its also for mdoerators
<Licho[0K]> a1983 thats user preference, thats advanced stuff, step 2
<sheepdev1> should there be a new clientstatus bit to give rights to move users? i think lots of users currently have moderator status
<Licho[0K]> yeah and right to fart in presence of others..
<a1983> so if I give FORCEJOIN i can reject taht request?
<Licho[0K]> we dont have special rights, why for this?
<Licho[0K]> moderators can ban, you dont trust them to move people?
<Licho[0K]> a1983 only if you didnt set compat flag
<Licho[0K]> then it assumes you dont know that
<Licho[0K]> but if aegis makes it with legacy support, it will move you always
<a1983> so if I not compatible - I'm not participant of JUGGLER match? Isn't it?
<Licho[0K]> no, if not compatible you will be moved using legacy method
<Licho[0K]> as i said its completely separate
<Licho[0K]> only host can move you
<Licho[0K]> you not particapte by not joining juggled autohosts!
<Licho[0K]> in the step 2 advanced features you can talk to system directly and set preferences on the fly
<Licho[0K]> like juggler: on/off even if you dont join any battle
<Licho[0K]> however atm you turn it on by joining juggler autohost
<Licho[0K]> and you turn it off by leaving it
<a1983> ok
<_koshi_> currently there is no way to discover which hosts juggle, correct?
<Licho[0K]> there is
<Licho[0K]> cpu status..
<Licho[0K]> cpu speed
<cheesecan> wrong way
<Licho[0K]> sure wrong way
<Licho[0K]> its just temporary before user attributes are possible
<Licho[0K]> it wont take longer than 1-2 years
<sheepdev1> there is no other way... and nobody cares about meaningless cpu speed
<cheesecan> that is a joke right
<cheesecan> :)
<Licho[0K]> no its not
<Licho[0K]> its the truth
<cheesecan> don't rely on other lobbies to do that
<Licho[0K]> user preferences were requested over year ago, there were some proposals, some accepted proposals
<Licho[0K]> and consensus it will be done
<Licho[0K]> its nothing to do with lobby
<Licho[0K]> its ubersrever
<cheesecan> I mean don't expect us to make ur cpu speed hack
<[ARP]hoijui_irc> cant you put JUGGLER in front of host name?
<cheesecan> it's really ugly
<Licho[0K]> i have a way to set user attributes through #nightwach channel hack but for other lobbies its by far easiest to read cpu
<Licho[0K]> i think its ugly and confusing hoi
<Licho[0K]> cheesecan i assure you i dont expect you to do anything at all
<cheesecan> things like that should be in the agenda for future meetings
<cheesecan> very witty..
<sheepdev1> well... having a clientstatus bit that gives permission to juggle would also give information about who juggles...
<a1983> ok, for now JOINBATTLEFORCE specs to next meeting by Licho?
<Licho[0K]> me? specs? why?
<Licho[0K]> i made specs !join
<Licho[0K]> if you want something else, design it, propose it, implement it
<Licho[0K]> and ask other lobby devs to implement that
<cheesecan> ok, don't complain if what is designed don't fit you
<Licho[0K]> of course i will
<cheesecan> you are the principal behind juggler
<cheesecan> so if anyone should design joinbattleforce cmd it should be you
<Licho[0K]> so, why dony you want to use my specs?
<Licho[0K]> you are the people who are unhappy with it
<Licho[0K]> its ball on your side
<cheesecan> see lobby thread for reasons
<sheepdev1> my proposal is that before next meeting, people document protocol spec change requests and publish it...
<Licho[0K]> that thread made me quit spring forums
<Licho[0K]> i wont read that anymore
<cheesecan> >_>
<sheepdev1> i will document a listcompflags command so you can request server supported compflags
<Licho[0K]> ok back to first question
<Licho[0K]> who will implement ubersrever changes?
<[ARP]hoijui_irc> you cant do hack casue propper way of doing it is too slow for your taste, and then expect others to fixup your hack
<Licho[0K]> whats the point of designing stuff?
<Licho[0K]> we spent meetings desining user attributes
<Licho[0K]> and whats the result??
<Licho[0K]> nothing, ugly #nightwatch hack
<Licho[0K]> and burned hours
<cheesecan> we're not the same people from those meetings
<cheesecan> why you blame us?
<[ARP]hoijui_irc> the other meeting was total fail
<sheepdev1> i will also document a command to request another client's compflags, if you agree its a good thing
<Licho[0K]> im stating how things are
<[ARP]hoijui_irc> this one was qutie good until now
<[ARP]hoijui_irc> there were no meetingS so far
<Licho[0K]> unless there are people coding uberserver all of this is just smalltalk
<Licho[0K]> sheepdev1 talk to aegis
<cheesecan> I repeat again, do fork, edit, pull request
<Licho[0K]> he probably has very speicifc plan
<Licho[0K]> including backwards compatibility
<cheesecan> if that is rejected we can flame aegis
<Licho[0K]> its also possible its half done now
<Licho[0K]> well people who are unhappy with !join should fork edit and pull :)
<Licho[0K]> not my business
<cheesecan> on zk project?
<cheesecan> you serious..
<Licho[0K]> uberserver
<cheesecan> how is !join in uberserver
<Licho[0K]> ...
<cheesecan> that is your own hack
<Licho[0K]> if you dislike !join make uberserver join
<Licho[0K]> thats all im saying
<a1983> ok
<cheesecan> yes this is what we are trying to do
<[ARP]hoijui_irc> licho, we agreed that first specs, then impl
<cheesecan> but first we need to document a proposal, then vote on it
<sheepdev1> document it first... documenting this is a small job... then we can discuss it next time and aegis can comment in the meantime...
<Licho[0K]> ok compat flag "j1"
<Licho[0K]> battle host or lobby moderator sends "FORCEBATTLEJOIN name target"
<Licho[0K]> and person gets "FORCEBATTLEJOIN target"
<Licho[0K]> if he has j1 set
<Licho[0K]> if not he is force moved using forged messages
<sheepdev1> ok so autohost doesnt need to find out about compflags enabled by client...
<Licho[0K]> no
<cheesecan> you really need a proper use-case documentation
<cheesecan> 
<sheepdev1> uml diagrams! :)
<[ARP]hoijui_irc> that sounded close enought to me for beeing converted to the xml spec, if that is all for the first change we need
<Licho[0K]> its "j1" first level
<Licho[0K]> for the next i can prepare "j2" but i think it should really not be tied to protocol specs
<cheesecan> i'm serious though, from what you said, I don't even know what is target, if it is battleid, if forged messages mean kicked from game then force-joined etc
<Licho[0K]> mainly because its nothing that concerns uberserver in those cases
<Licho[0K]> its exchange between master bot and clients of juggler system
<Licho[0K]> it can be standardized but certainly does not concern uberserver
<[ARP]hoijui_irc> in other wrods, we shoudl have properties first?
<[ARP]hoijui_irc> words*
<Licho[0K]> yes it could be done using some properties
<Licho[0K]> but perhaps more complex than currently proposed ones
<Licho[0K]> or at least nested or something
<Licho[0K]> or with namespaces
<Licho[0K]> some "j3" features are useful as lobby protocl changes
<Licho[0K]> like getting map/mod/engine download progress and eta
<a1983> without properties, how autohost find users for that FORCE command? (if they not joined autohost)
<sheepdev1> this is basically client2client communication, with a service bot... do we need to involve server/protocol spec in this?
<Licho[0K]> yes thats what im saying
<Licho[0K]> for preferences (what games i want to be juggled, do i want to be juggled) you dont need lobby - its client to bot communication and can be "matchmaker" specific if you want to make different matchmakers
<a1983> so we have 2 protocols : with TAS server, and with Autohost
<Licho[0K]> where do you get autohost
<Licho[0K]> autohost is not involved
<Licho[0K]> juggler is system that works on one server and does not necessary have lobby presence
<Licho[0K]> the way to set user preference atm is through webpage, but it coul dexpose some interface into lobby
<Licho[0K]> in that case it would be through nightwatch pm probably
<Licho[0K]> but certainl ynot autohost because its not autohost specific
<Licho[0K]> in fact in the final system there might not even be any autohosts
<Licho[0K]> you would just run the game without creating lobby room
<Licho[0K]> or you would create lobby room after it starts, just for specs to join and watch
<Licho[0K]> and to signal it exists
<sheepdev1> i dont think its wrong to make a proprietary protocol on top of normal messages... when server logic isnt involved... anybody thinks otherwise?
<cheesecan> +1
<_koshi_> the problem here was that until a couple minutes ago I didn't even know juggling hosts could be discovered, even it's super hacky
<_koshi_> and licho kept telling me making clients opt-in is impossible/not wanted
<Licho[0K]> for joined autohost of the most primitive juggler we have yes its not wanted
<Licho[0K]> i will describe plans
<Licho[0K]> including all hacks used and various steps of progression
<Licho[0K]> if you want
<Licho[0K]> though in reality it could divert/change
<Licho[0K]> or hit the lack of players or something
<cheesecan> this is pointless
<a1983> So TAS protocol stay unchaged
<cheesecan> agree on something for future or just end meeting and rant on about juggler
[21:42] ** [1uP]CarRepairer joined the channel.
<Licho[0K]> i just proposed FORCEBATTLEJOIN change
<Licho[0K]> for tas
<Licho[0K]> thats reasonable
<[1uP]CarRepairer> ok
<[1uP]CarRepairer> what else did i miss
<Licho[0K]> nothing really
<[1uP]CarRepairer> good
<Malina> :D
<[1uP]CarRepairer> BrainDamage, long time no see
<sheepdev1> ok one more small topic to finish this... may have to do with server deployment and not only protocol...
<sheepdev1> i'd like to have tls/ssl support to connect to server...
<Licho[0K]> setup tunnel on host
<[ARP]hoijui_irc> i think one change is enough for this first meting
<sheepdev1> yes stunnel would be fine with me...
<Licho[0K]> ask some linuxer to set it up then
<Licho[0K]> lurker, tobi, det etc
<sheepdev1> ok
<[1uP]CarRepairer> let's be honest
<Licho[0K]> fine so we agreed on j1 compat flag and FORCEBATTLEJOIN ?
<[1uP]CarRepairer> lurker hasn't said a word in over two and a half years
<cheesecan> no
<[1uP]CarRepairer> it's his corpse
<Licho[0K]> so this meeting was pointless?
<[1uP]CarRepairer> that you see logged in
<sheepdev1> we agreed on the documentation of this change and to confirm it next time i think
<BrainDamage> yeah, i'm kinda ghosty myself, busy with real life and exams :/
<Licho[0K]> i spit documentation here :)
<Licho[0K]> it was that
<cheesecan> what sheepdev1 said
<Licho[0K]> those 3 lines
<Licho[0K]> thats all there is
<_koshi_> +1 sheepdev
<Licho[0K]> you can confirm it right here
<Licho[0K]> and we can postopone next meeting until its implemented
<sheepdev1> one smallish topic... i think protocol spec <argument> tag should include proper typing of arguments... would this break something, or am i the only one foolish enough to want to generate his implementation based on xml ?
<BrainDamage> i think protocol should use 1 simple separator
<BrainDamage> just tab
<Licho[0K]> i also recommend all to watch life of brian for lesson on decision making :)
<BrainDamage> but it's probably a too radical change
<BrainDamage> yes, we all agree to decide a resolution!
<sheepdev1> braindamage +10 ... but its kinda breaking change :)
<[ARP]hoijui_irc> so licho.. you will not do xml doc/spec of that, right?
<Licho[0K]> anyway off to bathtube, brb
<sheepdev1> i'm keeping my security proposals for next meeting...
<[ARP]hoijui_irc> thanks
<a1983> With client2client message system don't need changes in protocol
<a1983> And what one change?
<[ARP]hoijui_irc> the j1 change with a compat flag and two new commands
<a1983> Sorry for thumb question
<sheepdev1> a1983 : the join request would be better with his own protocol message, but all the preferences stuff can stay as chat messages
<a1983> And who is spec it?
<a1983> :)
<sheepdev1> i think people who request a change should document it... i will do it for the listcompflags command + reply
<[ARP]hoijui_irc> yeah i agree
<sheepdev1> there is no forum section for discussing lobby protocol if i'm right... only for server + clients...
<a1983> ok - one command request we have :)
<[ARP]hoijui_irc> they shoudl document it in the agreed uppon way
<_koshi_> +1 sheepdev
<[ARP]hoijui_irc> not in their preffered way
<sheepdev1> not sure licho's bathtube is equipped with text to speech
<a1983> )
<[1uP]CarRepairer> might be his youtube channel
<sheepdev1> also if anyone is interested in trying my android client, let me know... its not (fully) vaporware... it just has a few rough edges...
<_koshi_> still need someone for the FORCEJOIN doc changes
<[1uP]CarRepairer> can you put it in a link that i can access by my own memory when i later use my android device
<Malina> I want your Android client. What should I do to install it ?
<[ARP]hoijui_irc> sheepdev1, maybe you want to join cheescan
<cheesecan> ?
<[ARP]hoijui_irc> have you talked to him yet?
<[ARP]hoijui_irc> i mena..
<cheesecan> what?
<[ARP]hoijui_irc> android .. menas its in java, right?
<sheepdev1> not talked to him before...
<_koshi_> alright, someone that is not me will do those doc cahgnes for next week
<sheepdev1> yes its in java
<_koshi_> and that's about all conclusions for today
<cheesecan> why are you making an android client lol
<[ARP]hoijui_irc> adn as i got it, your android thing is very basic?
<_koshi_> we're on 2.5 h ..
<sheepdev1> cheesecan : i named it "muslce" for most useless spring lobby client ever... wonder why ?
<[ARP]hoijui_irc> yeah. lets end official meeitng here
Conclusions: Someone that is not me will fixup documentation changes for FORCEBATTLEJOIN stuff till next meeting.
Sheepdev1 will do this for a way to query compat flags.
We need to get way more effective in holding meetings.
*proud*