Present: Malina, [V]sheep, _koshi_, a1983, [ARP]hoijui_g5, [PinK]halcyon, [1uP]CarRepairer, bibim_, Licho[0K]
Agenda ___
- Welcome
- Presentation of compat flags query protocol addendum
- Presentation of FORCEJOINBATTLE protocol addendum
- Presentation of USERCONNECT protocol addendum
=== Welcome ===
<_koshi_> first up: hi everyone
<_koshi_> next up: someone volunteers for making minutes
<[ARP]hoijui_g5> me
<_koshi_> thanks
=== Presentation of compat flags query protocol addendum ===
<[ARP]hoijui_g5> sheep, you wrote that?
<[V]sheep> yes... i propose something rather obvious
<[ARP]hoijui_g5> is there anything that is unclear/could be done in an other way
<[ARP]hoijui_g5> ?
<[V]sheep> only other options i see is to add user-readable description of flags...
<[ARP]hoijui_g5> k.. so not in your view
<[ARP]hoijui_g5> hmm
<[V]sheep> but it would be mostly useless
<[ARP]hoijui_g5> the individual compflags are described in the LOGIN command?
<[ARP]hoijui_g5> should be described somewhere in the protocol
<[ARP]hoijui_g5> spec
<[V]sheep> yes they currently are, but maybe the protocol spec should be modified to have a section where they are described
<[V]sheep> if you agree on this, i'll extract them from the login command
<_koshi_> sounds good
<[ARP]hoijui_g5> yeah.. ok with me
<[ARP]hoijui_g5> so we vote on this one?
<_koshi_> we do
<[ARP]hoijui_g5> the spec and the extraction of the description
<[ARP]hoijui_g5> +1 +1
<_koshi_> +1 +1
<[V]sheep> +1 +1
<_koshi_> anybody against?
<a1983> +1 +1
<[ARP]hoijui_g5> i guess that is enough then
<_koshi_> yeah
<[ARP]hoijui_g5> next
<[V]sheep> Malina, Licho[0K], bibim_, [PinK]halcyon, are you there?
<Malina> yes
<[ARP]hoijui_g5> they can still give -1 ones later
<Malina> +1 +1
<_koshi_> [V]sheep: if you get a pull request / path to us, [ARP]hoijui_g5 or me will merge that then
<a1983> but about spec seems, that arguments is a simple one line
<a1983> with space separators
<[V]sheep> yes, i hate the space/tabs mixup, but to respect protocol as it is designed, this command is using spaces for consistency (as no flag is supposed to contain spaces)
<[V]sheep> note that LOGIN command expects concatenated flags, so we must make sure we choose flags that can be unambiguously parsed
<a1983> So may be need correct description
<[V]sheep> yes i'll add a warning in the compflags section to make sure we think about it when adding new flags
<[ARP]hoijui_g5> good
<_koshi_> if noone has anything to add to this point we can get to the next point then
<[1uP]CarRepairer> so there is a flag called sp but what if there is a flag called just s
<[V]sheep> yes thats the problem, there can not be a flag s now, especially not is another flag starts with p :)
<[V]sheep> *if
<bibim_> hey, yes I'm here now
<[V]sheep> we could change the LOGIN command to expect something like a list of compflags, or a single argument made of delimiter separated flags... up to you... but this would be a breaking change so i'm not sure
<[V]sheep> we can also choose wisely new flags... :)
<_koshi_> if we exceed our options for that in one protocl reveision we're certainly doing sth wrong
<Licho[0K]> yes im here sheep, why?
<bibim_> concerning compat flags, aegis changed syntax, they are space separated now
<bibim_> (but old flags can still be concatened for backward compatibility)
<[V]sheep> i didnt see that in the "published" doc (0.36)... i'll check github now
<bibim_> aegis didn't update doc at all...
<bibim_> unfortunately
<Licho[0K]> compfags looks good.. but 1) who needs it? certainly not me atm
<Licho[0K]> 2) who will implement it? not me
<[ARP]hoijui_g5> ah yeah true, SpringLS also supports these new flags
<bibim_> concerning the compat flags query thing, that's good in theory
<Licho[0K]> compat flags are also meant to be client invisible, they are meant to keep backwards compatibility
<Licho[0K]> handled by server
<bibim_> but problem is it's a lot of work at lobby client side to support all combinations of server capabilities
<Licho[0K]> so listing it at all goes against the spirit a bit
<Licho[0K]> server handles clients differently based on their capability isolating other clients from necessatiy to do that
<[V]sheep> if you write a client that connects to a single server that you know supports the flags you request, then you dont need listcompflags... just dont request it
<Licho[0K]> what?
<Licho[0K]> thats certainly not my concern, server should always know what client does
<Licho[0K]> we have 1 server and that wont change anytime soon
<bibim_> [V]sheep what I mean is that we don't have that many lobby server programs, ideally they should implement new functionnalities as they are decided, it's not like lobby clients...
<[V]sheep> suppose you request a new flag to be implemented on the server, with this you can check whether the change was implemented and deployed
<_koshi_> bibim, that's already not our reality
<Licho[0K]> why would any client implement something that isnt on server
<Licho[0K]> and maintain that
<Licho[0K]> and add flags to change behavior based on server
<Licho[0K]> seems pointless
<Licho[0K]> i will always wait until server support
<[1uP]CarRepairer> irony?
<[1uP]CarRepairer> sarcasm?
<[1uP]CarRepairer> not sure
<Licho[0K]> no i mean that
<Licho[0K]> why would you code non existing server command
<Licho[0K]> if you want to do it you would do hack like !join
<Licho[0K]> but not implement something that isnt in server yet and you have no guarantee it will be
<[ARP]hoijui_g5> hehe
<bibim_> _koshi_ indeed, however I'm just afraid it could be worse by allowing server to explicitly say they don't support a feature
<Licho[0K]> anyway does any major lobby dev plan to put this to use?
<Licho[0K]> listing server capabilities and changing lobby behavior accordingly
<Licho[0K]> not me
<bibim_> well for now I made SPADS handle both TASServer and uberserver, in both modes (LAN or normal)
<[ARP]hoijui_g5> look licho, you still afraid becuase you will depend more on others now
<_koshi_> can't say and see no harm in having the proposed functionality
<bibim_> but if it becomes too complicated I will only support live server :/
<[ARP]hoijui_g5> eg.. on aegis and me.. or someone writing a patch
<Licho[0K]> wut? no i dotn care
<Licho[0K]> i just think this is not very useful feature
<[ARP]hoijui_g5> but before, everyone was depending on you, not just for implementation, but also for design
<Licho[0K]> i plan to leave this lobby server asap
<_koshi_> alright, this is going off topic
<bibim_> to sum up Im' not agains functionnality neither :)
<[ARP]hoijui_g5> but yo uare here
<[V]sheep> i'm writing a client, i'm not sure if/why people would use it... i dont think i should hardcode compflags so i need a way to tell if server knows flags i'm able to handle...
<[V]sheep> as said, if you write a lobby client that only connects to 1 place... just ignore this command :)
<Licho[0K]> what if you connect to old tasserver which does not support the command but supports the flags :)
<[ARP]hoijui_g5> i guess that means we have to update the protocol version for this change?
<[ARP]hoijui_g5> i mean.. increase
<Licho[0K]> anyway if you want it just stick it into protocol.py
<_koshi_> lets put the increment on hold for a bit
=== Presentation of FORCEJOINBATTLE protocol addendum ===
<[ARP]hoijui_g5> so this was..
<[ARP]hoijui_g5> licho, i guess you did not do this.. and nobody else either
<[PinK]halcyon> did I miss anything
<Malina> hmmm, :D, What about fixing Autohosts/Server spectator count bug ?
<Licho[0K]> no i didnt do anything but i wrote proposal last meeting into the chat
<[ARP]hoijui_g5> sounds like offtopic, and .. is this an ueberserver bug? if so... just report to aegis
<[ARP]hoijui_g5> ok... did anyone say he would convert it into propper xml spec format?
[21:19] ** Malina left the channel( Quit ).
<Licho[0K]> no afaik
<[V]sheep> it seems common sense that dev who requests a change document it himself... we can keep it for next week to see if any progress is made...
<Licho[0K]> fine, koshi please document it then
<[ARP]hoijui_g5> hehe
<Licho[0K]> i certainly dont request any server change :)
<Licho[0K]> i only request !join implementation for SL
[21:22] ** Malina joined the channel.
<[PinK]halcyon> and forcejoinbattle?
<Licho[0K]> that is requested by koshi
<Licho[0K]> because he does not like !join
<[PinK]halcyon> how do you feel about it
<[PinK]halcyon> ok to rewrite for it?
<Licho[0K]> wut?
<[PinK]halcyon> are you willing to use forcejoinbattle instead of !join
<Licho[0K]> sure, i dont care
<Licho[0K]> if it works same way
<[PinK]halcyon> << cheesecan btw
<a1983> what way? should it drug user without confirmation?
<Licho[0K]> yes taht way
<Licho[0K]> there must not be any client side query
<Licho[0K]> if there is its useless for matchmaking
<[PinK]halcyon> did we get any forcejoinbattle proposal?
<Licho[0K]> yes last meeting
<[PinK]halcyon> yours?
<Licho[0K]> yes
<[PinK]halcyon> k
<[V]sheep> volunteering to document this would increase your karma
<[PinK]halcyon> seems a bit idle here
<[ARP]hoijui_g5> i am quite tired
<Licho[0K]> my karma is fine
<Licho[0K]> i will rather donate to poor people
<[ARP]hoijui_g5> :D
<[PinK]halcyon> how to control who sent forcebattlejoin?
<Malina> PROPOSAL
<Licho[0K]> it was said in m proposal
<Malina> 1. Protocol - Add new commands for joining User[br] // Suggest user to join me (Battleroom)[br] JOINROOM {password}[br] [br] // User must tell Server that he wants to play some Game with Cooperative / FFA / Bugs[br] JOINWANTED {game, mode, ...}[br] [br] // Then, the user status changed on Server[br] // Then Server can join that user by force to any battleroom[br] JOINROOMFORCE {password}[br] [br] // Suggest user to join me (Channel)[br] JOINCHANNEL {password}
<Licho[0K]> battle host can do it and lobby moderator can do it
<Licho[0K]> actually because server decides whether to relay or not it can even be changed later
<Licho[0K]> cient just listes to new command from server
<[ARP]hoijui_g5> Malina, that is an alternative proposal?
<a1983> Not completed
<Licho[0K]> sounds rather incomplate
<a1983> Licho made basic mathmaking
<[V]sheep> so to not drag this on for hours, i propose this topic to be postponed until we have at least one formal proposal to vote on (and maybe alternatives too)
<a1983> So does we need commands for that in TAS Server, or matchmaking is autohost feature?
<[PinK]halcyon> http://etherpad.springrts.com/XXXXXXXX
<Licho[0K]> a1983 we dont need any change in server or autohost
<[PinK]halcyon> something like that?
<Licho[0K]> except those already in place
<Licho[0K]> no change is needed at all
<Licho[0K]> only needed change is for SL to implement !join
<Licho[0K]> period
<[PinK]halcyon> does battle host /moderator need to know if it succeeded?
<Malina> nice, Is that meeting for that ? !join
<Licho[0K]> sounds good except add passwrod
<Malina> and fixing SpringLobby ?
<Licho[0K]> [PinK]halcyon they cannot not succeed!
<Licho[0K]> if they can fail, it breaks matchmaking again
<Licho[0K]> its like the prompt
<Licho[0K]> it must be 100% reliable
<[PinK]halcyon> what if room goes full or something?
<Licho[0K]> agent know it
<Licho[0K]> it wont do that
<[PinK]halcyon> host crashes?
<Licho[0K]> thats not relevant
<Licho[0K]> and they dont crash :)
<[PinK]halcyon> also, what about cyclical joinbattleforce
<Licho[0K]> client rejoins
<Licho[0K]> no issue
<[PinK]halcyon> if both are set to re-route to eachother when full
<Licho[0K]> why would you do that?
<[PinK]halcyon> idk how you will use it, asking you :)
<Licho[0K]> its already in place
<Licho[0K]> this is not something new
<Licho[0K]> it was used for several weeks
<[PinK]halcyon> I know, but I rarely play zk
<Licho[0K]> i assure you such things dont happen :)
<Licho[0K]> autohosts are not independent
<Licho[0K]> there is central agent organizing it
<Licho[0K]> there is also no way to permanently redirect people etc so such cycle simply wont hapen in real world
<[PinK]halcyon> I guess if it turns out to be an issue in the future, server can do it without extending command
<Licho[0K]> you could only do it with some modified autohosts/clients as a "trap"
<Licho[0K]> why would that be an issue?
<Licho[0K]> you can make 1000 fake battlerooms
<[PinK]halcyon> yes, was mostly thinking about new autohosts
<Licho[0K]> you can make rooms that kick you instantly
<Licho[0K]> you can make rooms that desync spring 100% times
<Licho[0K]> abusers -> ban
<Licho[0K]> simple as that
<[PinK]halcyon> >:)
<[PinK]halcyon> anything else to take into consideration?
<_koshi_> also password is not mandatory/can be empty?
<[V]sheep> in c2s message, password can be empty
<[V]sheep> in s2c message, password should be omitted because client has no use for it
<Malina> can be empty
<[PinK]halcyon> s2c?
<[V]sheep> server to client
<_koshi_> either way, should be same es OPENBATTLE/BATTLEOPENED probably
<[PinK]halcyon> so we have two proposals then
<[V]sheep> and yes maybe we dont need to differenciate s2c FORCEJOINBATTLE and BATTLEJOINED ... is there a reason ?
<[PinK]halcyon> protocol is full of commands with same name but different source
<[V]sheep> i agree we may need a new command to tell server to pull in a user in some battle, but from the "juggled" user, he could receive a well-known BATTLEJOINED message... is there a reason to add a new message for it ?
<Licho[0K]> what?
<[PinK]halcyon> I don't like these pm commands as u know
<Licho[0K]> of course client will recieve that mesage [V]sheep
<Licho[0K]> client manually joins the new battle!
<Licho[0K]> it only instructs client to join
<[PinK]halcyon> i'm assuming client gets regular joinbattle maphash etc too?
<Licho[0K]> of course after he actually joins
<[PinK]halcyon> don't see any flaws then
<_koshi_> alright
<Licho[0K]> there will be compat flag
<Malina> so, Jugler works with Zero-K only ?
<Licho[0K]> and incompatible players will be moved by hackier way
<a1983> How can I tell to juggler to join BA, for example?
<Licho[0K]> Malina no
<_koshi_> can we pretty please try to stay on topic?
<Licho[0K]> a1983 you set prefernece to "Ba" type game
<[V]sheep> oh ok so licho's proposal is to have the client honour the forcejoinbattle request by actually joining... i thought if it was all mandatory, server could simply join the user and notify him he has been joined
<Licho[0K]> [V]sheep thats what will server do for incompatible client
<Licho[0K]> however it can break some gui stuff so its better if client explicitly supports it
<_koshi_> I don't see how it will not break incompat. client's tbh
<_koshi_> anywho
<a1983> So ful algorithm - first I send pm with settings to Nightwatch juggler, then he will send me !join or FORCEJOINBATTLE?
<Licho[0K]> koshi
<Malina> where is it ? Where I should set BA for playing ?
<Licho[0K]> it will send "kicked"
<Licho[0K]> and "joined"
<Licho[0K]> Malina system is offline atm
<Licho[0K]> people voted to turn it off untilSL support
<_koshi_> any further changes to proposal one?
<Malina> yes
<Malina> or no if it has been already done by Licho
<[PinK]halcyon> if Host A has 10/10 users, 1 spec, spectator gets FORCEJOINBATTLE Host B, Host B has 9/10 users, another user joins Host B before spectator. What happens?
<Licho[0K]> it fails
<Licho[0K]> new user joins as spec only
<Licho[0K]> oh spectator gets it
<Licho[0K]> spectator generally joins as spec
<Licho[0K]> depending on lobby
<[PinK]halcyon> so outcome is uncertain really
<Licho[0K]> nobody usually tries to move specs
<[PinK]halcyon> k
<Malina> then Server should inform the user a message ?
<Licho[0K]> it does that atm
<Licho[0K]> nightwatch sends you message
<[PinK]halcyon> will server require client to do JOINBATTLE after FORCEJOINBATTLE?
<Licho[0K]> yes as i said
<Licho[0K]> client must request the join
<[PinK]halcyon> or enforcement responsibility is on lobby?
<Licho[0K]> in normal way
<Licho[0K]> yes its responsibility of the lobby
<[PinK]halcyon> that doesn't add up what u said
<[PinK]halcyon> first
<[PinK]halcyon> ok
<Licho[0K]> i never said anything else
<Licho[0K]> i said if client does not have compat flag
<Licho[0K]> he wont receive forcejoinbattle
<Licho[0K]> and instead be hackmoved
<[PinK]halcyon> k
<Malina> If we play Jugler rules than it not responsibility of Lobby
<[PinK]halcyon> why do we need scriptpassword
<[PinK]halcyon> it is sent in regular joinbattle cmd
<Licho[0K]> we dont
<Licho[0K]> i didnt add it
<[PinK]halcyon> pls stop adding unuseful stuff
<Licho[0K]> can i add one more protocol change?
<[V]sheep> i'm not sure i understand everything there... but if there is a command that request user to join a battle... user need all info that can be needed for JOINBATTLE
<Licho[0K]> [V]sheep joinbattle does not need script password
<[PinK]halcyon> user does a regular JOINBATTLE after it receives FORCEJOINBATTLE
<[PinK]halcyon> since user can opt-out by clicking some checkbox in lobby
<[PinK]halcyon> (prior to receiving forcejoinbattle) right?
<[V]sheep> :)
<Licho[0K]> added proposal for CONNECT
<[PinK]halcyon> uh
<Licho[0K]> [PinK]halcyon i really dont know how many times i will have to repeat this
<Licho[0K]> there is no opt out :)
<Licho[0K]> there must not be
<[PinK]halcyon> there is, you just don't see it
<[PinK]halcyon> you made a contract between lobby and autohost
<a1983> Indeed
<[PinK]halcyon> any rogue lobby can add opting out feature if they want
<Licho[0K]> yes but i care about non rogue lobbies
<[PinK]halcyon> if you rely on mandatory move..you must beat all lobbies into submission
<[V]sheep> if there is no opt-out, why send a FORCEJOINBATTLE to client and not just notify him that he has been BATTLEJOINED ?
<Licho[0K]> to make it nice and clean sheep
<Licho[0K]> and compatbile with existing joining
<Licho[0K]> and wolas patch
<[PinK]halcyon> you want this also for quick matchup e.g. 1v1?
<Licho[0K]> ffs
<[PinK]halcyon> where opting out would ruin system
<[V]sheep> if you send a request to client, he may not honour it... thats simple :)
<Licho[0K]> [PinK]halcyon IT WAS ALREADY USED FOR 1v1 OR WHATEVER
<Licho[0K]> you are so behind people
<Licho[0K]> its really frustrating
<[PinK]halcyon> spare us the nerd rage pls
<Licho[0K]> who are you [PinK]halcyon
<Licho[0K]> what do you develop?
<[1uP]CarRepairer> he's cheesecan
<Licho[0K]> what do you develop?
<[PinK]halcyon> said I'm cheesecan before
<[PinK]halcyon> openlobby and before that cheeselobby
<Licho[0K]> what do you make for lobby?
<[V]sheep> dont answer... its nerd pissing contest
<[PinK]halcyon> so now it is ad hominem attack?
<Licho[0K]> no im just asking who are you
<Licho[0K]> i dont know cheese lobby
<Licho[0K]> but ok
<[PinK]halcyon> you're not required to
<Licho[0K]> i hope its not some silly joke
<[PinK]halcyon> just show ppl some respect even if u think their project is obscure and doesn't matter to zk at all
<[PinK]halcyon> what is a joke?
<_koshi_> you guys can continue that later, alright?
<a1983> How non ZK users setup juggler preference? Without preference FORCEJOINBATTLE is not useful.
<Licho[0K]> ok people get that straight
<Licho[0K]> its not about juggler
<Licho[0K]> forget juggler
<Licho[0K]> focus on command
<Licho[0K]> thats all
<Licho[0K]> i already explaine djuggler like 4x
<_koshi_> aye
<Licho[0K]> here, on 2 forum threads
<[PinK]halcyon> there is still a glaring flaw
<[PinK]halcyon> some lobbies want to be able to opt out
<[PinK]halcyon> and will do so and you cannot stop them
<Licho[0K]> fine unless its something major like SL it doe snot matter much
<Licho[0K]> for me at least
<_koshi_> I will only opt-out by not joining hosts itfp
<_koshi_> i would like a nicer way to discover that at some point
<Licho[0K]> there will also be opt out to juggler directly by pming to nightwatch but as i said its not about juggler now
<_koshi_> but for now the cpu stuff is alright
<Licho[0K]> now CONNECTUSER is that ok?
<Malina> no
<[V]sheep> i still do not agree on the forcejoinbattle... but lets continue, i'll just vote -1 later
<[ARP]hoijui_g5> kosh, what is itfp
<_koshi_> certainly sounds nice if you don't want to throw people in another battlerrom but start game direclty
<[ARP]hoijui_g5> ?
<[PinK]halcyon> sheep: why?
<_koshi_> in the first place
<[PinK]halcyon> shouldn't move on before it is settled
<Licho[0K]> yes thats the plan
<Malina> someone will do that and then you will say to us bye-bye - jugler is working
<[ARP]hoijui_g5> ah
<[V]sheep> if client is forced to do something, I dont see the benefit in asking him to join and not having the server forcefully join him and notify him through standard BATTLEJOINED message
<[PinK]halcyon> as Licho said, your lobby can opt out, he doesn't care
<Licho[0K]> [V]sheep its needed
<Licho[0K]> host can send you anywhere
<Licho[0K]> even to other battle which wont approve
<[ARP]hoijui_g5> ok so.. the propper way to opt out of juggler is, to not join juggler enabled hosts, right licho?
<Licho[0K]> thats why client must do its own join rquest
<[PinK]halcyon> by parsing cpu :)
<[PinK]halcyon> in undocumented way
<Licho[0K]> well atm yes [ARP]hoijui_g5
<[V]sheep> licho, why would you want to move user to a battle which wouldnt approve him ?
<[ARP]hoijui_g5> ok.. and are juggler enabled hosts clearly visible to noobs in the lobby?
<[ARP]hoijui_g5> like..
<Licho[0K]> say you are admin
<Licho[0K]> and all people in your battle agreed to join KP game
<[ARP]hoijui_g5> haivng "Matchmaker" in theri name or so
<Licho[0K]> so you issue the command
<[ARP]hoijui_g5> mm ok
<[ARP]hoijui_g5> so can not be done that way
<Licho[0K]> juggler autohosts should be marked
<Licho[0K]> they are not evne real autohosts and could be passworded later
<[ARP]hoijui_g5> ok
<Licho[0K]> but command can be issued at anytime by admins -for good reason i presume
<Licho[0K]> if you remember admins were able to do it using FORGEMSG for some time
<[ARP]hoijui_g5> as long as they are marked ... it sounds ok to me, but i woudl preffer somethign like mathcmaker, not juggler as in.. something one can understand without prior knowledge
<Licho[0K]> thats name issue
<[ARP]hoijui_g5> yeah ok.. i dont care so muhc about that
<Licho[0K]> lobby can call it whatever it watns :)
<[ARP]hoijui_g5> ah ok
<[PinK]halcyon> so we should add magic constant "matchmaker" and parse room name to see if juggler or not?
<[ARP]hoijui_g5> i did not know that lobby knows that
<[ARP]hoijui_g5> thats fine then
<Licho[0K]> lobby knows it by cpu atm
<Licho[0K]> i would like to avoid spamming title with extra information
<[ARP]hoijui_g5> ahh k :D now i got it
<[PinK]halcyon> idk know where to find this cpu info, wiki?
<Licho[0K]> nowehere
<[ARP]hoijui_g5> the hosts cpu info
<[ARP]hoijui_g5> it is alreayd in protocol
<[PinK]halcyon> yes but what is the format
<Licho[0K]> he asked about meaning of cpu i guess
<[V]sheep> maybe we should add a table to documentation for "known" cpu values... even if its a hack, its better when it is documented
<Licho[0K]> format is if its 6667 its autohost which MIGHT be using juggler
<[1uP]CarRepairer> weblobby uses 7777 mhz
<Licho[0K]> ZK lobby uses 6666
<[PinK]halcyon> can we get rid of cpu in the future
<Licho[0K]> and springie
<_koshi_> that "MIGHT" you didn't mention before
<[V]sheep> and i'm using 0xa51obb1e
<Licho[0K]> might is atm
<[1uP]CarRepairer> weblobby has 1111 more mhz than zklobby
<Licho[0K]> because its off
<[ARP]hoijui_g5> indeed sounds new to me too
<Licho[0K]> but normally i assume it will be always on
<[ARP]hoijui_g5> ok
<_koshi_> you already had requests for autohosts of certain games to disable juggler
<[ARP]hoijui_g5> bibim/spads uses other values?
<[ARP]hoijui_g5> yeah true..
<[ARP]hoijui_g5> non-jugler autohosts support would be nice
<[ARP]hoijui_g5> coudl you use different value for jugler enabled ones?
<Licho[0K]> wut?
<[ARP]hoijui_g5> whats hte problem wiht that?
<Licho[0K]> there are two autohosts
<Licho[0K]> 6666
<Licho[0K]> and 6667
<Licho[0K]> 6667 normally use juggler
<Licho[0K]> 6666 not
<[ARP]hoijui_g5> ahh ok
<Licho[0K]> S44 etc are 6666
<[ARP]hoijui_g5> you said ZK lobby uses 6666, nothing about autohosts
<_koshi_> yeah
<Licho[0K]> ZK lobby + springies use 6666
<Licho[0K]> they have same library
<Licho[0K]> its same code
<[ARP]hoijui_g5> ok then
<[V]sheep> it will be funny when we'll have cpu with 6.6Ghz or some lobby decide to report 3.3GHz dual-core as 6.6 ... :)
<Licho[0K]> same as website which is nightwatch, again 6666
<[1uP]CarRepairer> weblobby uses 7777 mhz, in case anyone missed it
<Licho[0K]> i didnt miss it
<Licho[0K]> ima adding few more lobby commands
<[ARP]hoijui_g5> so S44 guys chan choose to host a 6666 autohost then?
<[PinK]halcyon> it would be good to have this documented at least in wiki
<[ARP]hoijui_g5> could also be in protocol spec, for what i care
<[V]sheep> +1 to add cpu table to protocol spec
<[ARP]hoijui_g5> thats where all people that have to worry about this will look at
<[PinK]halcyon> we done with forcejoinbattle now?
<[V]sheep> yeah... even though i guess it can be expected some lobby dev will provide an optout despite not being allowed to...
<[ARP]hoijui_g5> if one can choose to do a 6666 autohost or 6667, i have no more questions
<_koshi_> alright
<[PinK]halcyon> sheep raised a point about password being a sentence
<[V]sheep> its not, as per JOINBATTLE description
<[PinK]halcyon> k
<[V]sheep> ignore that bad guess
<[PinK]halcyon> continue to next cmd?
<[PinK]halcyon> licho gone wild now adding cmds
<Licho[0K]> [ARP]hoijui_g5 its compeltely unrelated to protocol changes
<Licho[0K]> basically i run springies
<Licho[0K]> springies can have autohost in "juggler" mode
<[ARP]hoijui_g5> yes true.. i know
<Licho[0K]> depends on config, i can change it
<Licho[0K]> they request - i change
<[ARP]hoijui_g5> ok, good
<Licho[0K]> now i added REQUESTDOWNLOAD and REPORTDOWNLOADPROGRESS commands
<Licho[0K]> this is for system to query if client has resources and prompt their download
<[1uP]CarRepairer> download of what
<Licho[0K]> map, game, engine
<Licho[0K]> for matchmaking without room
<[1uP]CarRepairer> is it related to rapid?
<Licho[0K]> so that system knows its safe to send you CONNECTBATTLE
<Licho[0K]> no its related to nextgen juggler
<Licho[0K]> proper matchmaking system
<Licho[0K]> the agent that wants to organize match sends REQUESTDOWNLOAD to clients with necessary engine,game and map
<[ARP]hoijui_g5> the command description is .. i have no idea what that command does after reading it
<Licho[0K]> client reports with download progress 100 if it has it, -1 if download fails
<Licho[0K]> and otherwise every 30s with download progress
<[V]sheep> please change s2c message from request to requested so its easier to disambiguate
<a1983> REQUESTDOWNLOAD mod map
<a1983> I think
<Malina> that is related to unscynced users and hte users who wait unsynced ones
<[ARP]hoijui_g5> btw, there is some place to describe such stuff in the xml
<[PinK]halcyon> how does user request this matchmaking
<Licho[0K]> its REQUESTDOWNLOAD hoi map azure_rampart
<[ARP]hoijui_g5> maybe that shoudl be aded as extra text.. i think its in the top soemthere
<[ARP]hoijui_g5> adn the related comamdns can link to it
<_koshi_> and we're going on 2 hours again guys
<[V]sheep> the CLINK doesnt specify where it links to server or client issued command
<a1983> extra to FORCEJOINBATTLE
<[PinK]halcyon> you lost me at nextgen juggler
<Licho[0K]> i dont know the obscure format i can explain what i mean though
<[ARP]hoijui_g5> yeah.. discuss these two comadns next time?
<[V]sheep> yes next time please
<Malina> that is simple
<Malina> we don't need to discuss it later
<[ARP]hoijui_g5> so we vote on forcebattlejoin thing?
<Malina> approved and Agreed
<a1983> REPORTDOWNLOADPROGRESS <ets
<a1983> REPORTDOWNLOADPROGRESS <eta>
<Malina> for reportdown.....
<[ARP]hoijui_g5> we want to end meeting now, not start a new topic... i though
<_koshi_> indeed
<[PinK]halcyon> agree with hoijui, dont rush too much
<Malina> who wants ?
<Licho[0K]> just end the meeting i dont care
<Licho[0K]> this is longer term stuff anyway
<[ARP]hoijui_g5> this just started, and it woudl surely need even more discussion and explaining then uggler stuff, as nobody except licho knows about it yet
<Licho[0K]> it will take 1-2 years to implement forcejoinbattle anyway
<a1983> )
<[PinK]halcyon> pout much
<a1983> optiimist
<[ARP]hoijui_g5> so lets finnish forcejoinbattle stuff
<Malina> joinbattleforce you mean
<[PinK]halcyon> somebody still thinks forcejoinbattle has problems?
<[ARP]hoijui_g5> as proposed and discussed here, lobbies do not add optout when join is requested, btu user may choose to not participate by not joiining juggler hosts
<Malina> the NAME
<Licho[0K]> how aobut calling it ARGLEBARGLE then ?
<[ARP]hoijui_g5> i guess juggler is an ok name for us here, in case there will eb new/other matchmaking systems in the future
<[ARP]hoijui_g5> but lobbies should show it differently to users
<Malina>
<[1uP]CarRepairer> battlematcher
<Malina> not juggler
<_koshi_> GUYS
<_koshi_> seriously
<[ARP]hoijui_g5> +1 from me
<_koshi_> vote is now open on proposal 1
<_koshi_> +1
<Licho[0K]> +1
<[PinK]halcyon> +1
<[1uP]CarRepairer> abstain
<[V]sheep> abstain
<[ARP]hoijui_g5> that means +-0, right?
<[1uP]CarRepairer> yes
<[V]sheep> yes -0
<bibim_> abstain too (had to go afk for most of the discussion unfortunately...)
<[PinK]halcyon> so 4 for 0 against?
<Licho[0K]> -0 exists only in computers, not in reality
<[ARP]hoijui_g5> thats so swiss!
<_koshi_> the +1 have it then
<[ARP]hoijui_g5> yeah
<[V]sheep> hoi :)
<_koshi_> objections to proposal 2, CONNECTUSER ?
<_koshi_> the rest will be put on agenda for future meeting
<Licho[0K]> +1 for connectuser
<a1983> +1
<_koshi_> +1
<[1uP]CarRepairer> abstain
<Malina> -1
<Licho[0K]> zomg what if someone uses -3 ?
<[PinK]halcyon> -1 (I don't think connectuser was discussed even)
<[V]sheep> -1
<Licho[0K]> ok why
<Licho[0K]> its just request to connect given up
<Licho[0K]> ip
<Licho[0K]> so it does not have to be set when you openbattle
<Licho[0K]> and known beforehead
<[ARP]hoijui_g5> i also cant remember connectuser beeing discussed
<Licho[0K]> because its too trivial
<[ARP]hoijui_g5> +3 -> invalid => +0
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> +1 then
<[PinK]halcyon> how does it fit in with !start and !forcestart
<[V]sheep> i need to have arguments to understand why its needed...
<Licho[0K]> [PinK]halcyon completely unrelated
<[PinK]halcyon> not to me
<Licho[0K]> sigh
<[ARP]hoijui_g5> <Command Name="CONNECTUSER" Source="client"> description is also not sufficient though
<Licho[0K]> its needed 1) for room-less matchmaking
<Licho[0K]> so you can tell client to connect without first creating room, having him join and then starting
<Licho[0K]> 2) for room that does not know auothost port before
<[V]sheep> so where are the scripttags and such stuff ?
<[PinK]halcyon> how does client initiate it? I asked this before, you didn't answer
<Licho[0K]> 3) for room that lets start multiple games at once -> redirect people to final battles
<Licho[0K]> client?
<Licho[0K]> its not for client
<Licho[0K]> its for battlehost
<Licho[0K]> its for autohost
<[PinK]halcyon> why do you need autohost for room-less matchmaking
<Licho[0K]> scripttags? You dont need them
<Licho[0K]> you dont
<Licho[0K]> admin can do it too remember
<Licho[0K]> its same rules as FORCEJOINBATTLE
<Licho[0K]> its very similar command with same rules
<Licho[0K]> only effect is different
<Licho[0K]> effect of FORCEJOINBATTLE -> client joins battleroom
<[PinK]halcyon> it would be nice if there was proper 1v1 matchmaking
<[PinK]halcyon> that client can initiate
<[ARP]hoijui_g5> definitely needs more docu, all of this
<[ARP]hoijui_g5> then what is in the proposals so far
<Licho[0K]> effect of USERCONNECT -> client starts spring with script to connect to given ip
<[PinK]halcyon> I mean I'm not opposed to the idea, just the specification
<[PinK]halcyon> why limit to just juggler hosts when any user might want 1v1
<Licho[0K]> FFS
<Licho[0K]> there is no such thing as juggler host
<Licho[0K]> seriously
<[PinK]halcyon> lulz
<Licho[0K]> forget about juggler
<Licho[0K]> forget about 1v1 matchmaker
<Licho[0K]> focus on command
<Licho[0K]> thats all there is
<[V]sheep> all i can see is that there is misunderstanding, so there is evident lack of arguments/documentation...
<Licho[0K]> koshi understands it well
<[PinK]halcyon> imho, it's a pretty big change because lots of ppl want quick matchup 1v1/2v2/3v3 ála battle.net and you should take that into consideration when doing this new cmd
<Licho[0K]> AAAAA
<Licho[0K]> there is no change in anything
<Licho[0K]> its just a command
<[V]sheep> lol
<[PinK]halcyon> trivialize it some more pls
<[ARP]hoijui_g5> aehh licho... it is old to you, but new to most others
<Licho[0K]> it wont be used anywtime soon anyway
<[ARP]hoijui_g5> koshi may know soem more then others due to.. obvious reasons
<Licho[0K]> because it needs requestdownload first
<[V]sheep> so dont rush vote...
<[PinK]halcyon> make it usable for other things as well u get my vote
<[PinK]halcyon> !
<[ARP]hoijui_g5> you doing it the hacky way is why others do not know about it.. cant blame them for not knowing
<Licho[0K]> seriously can i invite some more people here?
<Licho[0K]> lets same some ZK players
<Licho[0K]> so they can ask questions and post opinions too
<[PinK]halcyon> it was decided only devs sit in here
<[PinK]halcyon> in 1st meeting
<Licho[0K]> ZK has 40 devs! :)
<[PinK]halcyon> must be lobby dev or server dev
<Licho[0K]> they are
<Licho[0K]> they can commit to springie too
<Licho[0K]> or ZKL
<_koshi_> alright, there was no clear majority for or against, proposal 2 is postponed as well
<[PinK]halcyon> ehm..stop with the rhetorics pls
<[ARP]hoijui_g5> if propper meetings would have started years ago.. none of the other guys would be here
<_koshi_> if there's nothing else but bickering I call this meeting ended
<_koshi_> anyone?
<[ARP]hoijui_g5> so proposal one is also postphoned, right?
<_koshi_> correct
<Licho[0K]> i can explain it more
<[PinK]halcyon> why?
<_koshi_> eh
<_koshi_> no
<Licho[0K]> if you ask proper question
<[ARP]hoijui_g5> ok
<[PinK]halcyon> one was approved
<Licho[0K]> ok no then
<Licho[0K]> or yes?
<_koshi_> proposal 1 is accepted
<[ARP]hoijui_g5> proposal 1 is accepted
<[ARP]hoijui_g5> noone of the others yet
<_koshi_> rest postponed
<[PinK]halcyon> put the others in a new etherpad
<[ARP]hoijui_g5> we need good textual documentation for 1 and two till next time
<[PinK]halcyon> for next time
<[V]sheep> i have a small something to ask so i know if i prepare some proposal for next meeting... what about getting rid of RTF in the agreement?
<Licho[0K]> any reason? All lobbies can show it now
<[PinK]halcyon> just bcs you can't do RTF parsing on android?
<[ARP]hoijui_g5> umm
<Licho[0K]> i dont care much imo its strange place for server to show general agreement
<[PinK]halcyon> doesn't make sense
<[ARP]hoijui_g5> add a menu point into agenda for next meeting
<[1uP]CarRepairer> yeah rtf is weird
<[V]sheep> no i can do it... i'm a bit lazy though... :)
Summary ___
- Proposal 0 (LISTCOMPFLAGS): accepted as on etherpad
- Proposal 1 (FORCEJOINBATTLE): accepted as on etherpad, but needs a good explanation/description to be added to the protocol doc
- Proposal 2 (USERCONNECT): decission postphoned (casue no time left for discussion/explanation); also needs a good explanation/description to be added to the protocol doc
- Proposal 3 (REQUESTDOWNLOAD): postphonehponed
- a table that explains special CPU values has to be added to protocol spec (sheep doing it?)