Lobbydev meeting minutes 2012-02-26

Lobbydev meeting minutes 2012-02-26

Archive of lobby developer discussions

Moderators: Moderators, Lobby Developers

User avatar
hoijui
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Lobbydev meeting minutes 2012-02-26

Post by hoijui » 27 Feb 2012, 09:19

Date: 26. February 2012
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
Note: Etherpad links are removed. Their content can be found here: http://pastebin.com/ixphiyNC


=== 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 :P
<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 :P
<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 :P
<[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 :P
<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 :P
<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?)
0 x

Axiomatic
Posts: 68
Joined: 20 Jan 2011, 04:17

Re: Lobbydev meeting minutes 2012-02-26

Post by Axiomatic » 27 Feb 2012, 12:28

Sorry but I can't make it to meetings at 5:30am. I'm don't expect to be included in votes if I'm absent. If I cared strongly enough I would've dragged myself out of bed.

Proposal 0 (LISTCOMPFLAGS): .
abstain
I don't see the need. Clients and servers should just ignore unsupported commands and trailing arguments.


Proposal 1 (FORCEJOINBATTLE):
abstain

Proposal 2 (USERCONNECT):
agree
(but only from host. Or after a player asked a matchmaker to find a game for him)


Proposal 3 (REQUESTDOWNLOAD):
agree
(same conditions as above)


a table that explains special CPU values:
disagree
CPU values are inflexible. Counter proposal: named parameters in LOGIN and ADDUSER.

Code: Select all

ADDUSER JohnnyFoo AU 2500 lobby=notalobby,lobby-version=2.0,os=Ubuntu 11.10,os-family=linux
ADDUSER HarryBar US 1800 lobby=springlobby,lobby-version=0.141,os=Windows 7,os-family=windows
CPU field should be removed anyway. It's not a useful measure of performance (not that that performance is relevant anyway)

Oh and +1000 for only using tabs to separate arguments.
0 x

Google_Frog
Moderator
Posts: 2440
Joined: 12 Oct 2007, 09:24

Re: Lobbydev meeting minutes 2012-02-26

Post by Google_Frog » 28 Feb 2012, 07:29

I know enough about juggler to see that meeting was frustrating. A lot of people there revealed that they have no clue about the current state of matchmaking in spring.
0 x

User avatar
hoijui
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Re: Lobbydev meeting minutes 2012-02-26

Post by hoijui » 28 Feb 2012, 07:56

if this system had been designed and introduced in a proper way, this would not be the case.
licho decided to do it otherwise, casue it was/is faster and easier to do, and now he is annoyed cause he has to suffer from the consequences. i am not sorry at all, and it there is noone else to blame for that. it also seems to me like it is not really a big deal, in the sense that stuff seems to happen mostly as he wants it, and in the end he will get what he always wanted (more cooperation in lobby dev). of course this does not mean, he creates, implements, and others follow. that would be bad.
he thinks it would not be, but all other lobby devs do seem to think so.

you like goebbels, being mad that mussolinis aparatus is not as effective as your own in blaming the jews for everything.
... ok the analogy is bad, but you know.. i am creative! ;-)

mr. goering ... energy!

i should get family psycho therapist. i would assing a famous nazi role to every member, then make them read about each other, and ...
it is perfect! they woudl have to tell me what the core.. the main thing that went wrogn in the live of their figure is, and ... people would love me (for healing them).
i would get Nobel price for turning the nazis into something usefull.
i accept praisals now already.
.. am i being ridicuous? ;-)
0 x

User avatar
Licho
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Lobbydev meeting minutes 2012-02-26

Post by Licho » 28 Feb 2012, 12:38

Thats simply not true, i explained the system in 3 threads in those forums and there is wiki linked which explains even the algorithm used by juggler internally.

First of the threads was calling for cooperation/comments.

People ignored this 6 months old thread.
People ignored even the recent threads and last meeting which explained juggler.

And now when the system is up and running want to discuss basics over and over again instead of doing their homework.

Massive annoyance and waste of time - 5h of meetings, hours in forum and what was done?
Zero.
When will server or SL be patched and by who? We dont know..
By contrast wolas has working SL !join patch that only needs to be released..
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Lobbydev meeting minutes 2012-02-26

Post by jK » 28 Feb 2012, 15:45

Licho wrote:Thats simply not true, i explained the system in 3 threads in those forums and there is wiki linked which explains even the algorithm used by juggler internally.
You did not made a springrts.com forum thread at all (searched for `match` & `juggler`). And you might have done it on the ZK forums. But you cannot blame anyone for not reading them there! (you cannot even search for text in those forums!)

Neither do you read engine devs minutes either.
No, you aren't the center of the universe ...
0 x

User avatar
Licho
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Lobbydev meeting minutes 2012-02-26

Post by Licho » 28 Feb 2012, 17:18

I did..
first thread .. from july:

http://springrts.com/phpbb/viewtopic.php?f=71&t=26394

second thread:

http://springrts.com/phpbb/viewtopic.php?f=64&t=27246

third thread:

http://springrts.com/phpbb/viewtopic.php?f=64&t=27685

There is also about 3 ZK tickets, several ZK forum threads and at least 2 ZK wiki entries.

Its not like I left spring community out of the loop ffs, its many months old!

So now ssh with similar remarks please.
0 x

User avatar
hoijui
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Re: Lobbydev meeting minutes 2012-02-26

Post by hoijui » 29 Feb 2012, 16:50

Licho, how long do you wnat to continue this?
none of the other devs thinks what you did was good, no matter how muhc you think it was, that will not change, and that is all that matters here.
you make system, and then ask others to comment is NOT the same like putting together the basics in cooperation already.
first is bad, we no want, second we want.
everyone understands why you want the first, and knows that you want it since long time. no need to tell us all the time. we do not want it.
0 x

Satirik
Lobby Developer
Posts: 1688
Joined: 16 Mar 2007, 18:27

Re: Lobbydev meeting minutes 2012-02-26

Post by Satirik » 29 Feb 2012, 19:51

hoijui wrote:Licho, how long do you wnat to continue this?
none of the other devs thinks what you did was good, no matter how muhc you think it was, that will not change, and that is all that matters here.
you make system, and then ask others to comment is NOT the same like putting together the basics in cooperation already.
first is bad, we no want, second we want.
everyone understands why you want the first, and knows that you want it since long time. no need to tell us all the time. we do not want it.
i liked it, im pretty sure your force crap doesn't allow simple users to force people to join their own battle, because it's a force and not a request, and stop thinking you and all the fake spring devs are EVERYONE
0 x

User avatar
smoth
Posts: 22300
Joined: 13 Jan 2005, 00:46

Re: Lobbydev meeting minutes 2012-02-26

Post by smoth » 29 Feb 2012, 20:08

FWIW, I think licho's thing is nice I just would opt out of it because I idle in my server a lot and gundam players like to talk fluff a lot. I think having 2 gundam hosts in the future(one with and one without juggle) would be AWESOME!
0 x

gajop
Moderator
Posts: 3023
Joined: 05 Aug 2009, 20:42

Re: Lobbydev meeting minutes 2012-02-26

Post by gajop » 29 Feb 2012, 21:17

smoth wrote:I think having 2 gundam hosts in the future(one with and one without juggle) would be AWESOME!
What exactly would be the point of juggling on a single host? Matchmaking on the other hand is something to look for and that's what having !join/!forcejoin will make room for in the future.
0 x

User avatar
smoth
Posts: 22300
Joined: 13 Jan 2005, 00:46

Re: Lobbydev meeting minutes 2012-02-26

Post by smoth » 29 Feb 2012, 21:42

taken to pm as gajops question is unrelated to the discussion IMO.
0 x

User avatar
Cheesecan
Posts: 1571
Joined: 07 Feb 2005, 21:30

Re: Lobbydev meeting minutes 2012-02-26

Post by Cheesecan » 29 Feb 2012, 22:37

Satirik wrote:
hoijui wrote:Licho, how long do you wnat to continue this?
none of the other devs thinks what you did was good, no matter how muhc you think it was, that will not change, and that is all that matters here.
you make system, and then ask others to comment is NOT the same like putting together the basics in cooperation already.
first is bad, we no want, second we want.
everyone understands why you want the first, and knows that you want it since long time. no need to tell us all the time. we do not want it.
i liked it, im pretty sure your force crap doesn't allow simple users to force people to join their own battle, because it's a force and not a request, and stop thinking you and all the fake spring devs are EVERYONE
As detailed in the protocol amendment, forcejoinbattle is only possible by host or lobby mod.
gajop wrote:
smoth wrote:I think having 2 gundam hosts in the future(one with and one without juggle) would be AWESOME!
What exactly would be the point of juggling on a single host? Matchmaking on the other hand is something to look for and that's what having !join/!forcejoin will make room for in the future.
!join is deprecated and should not be used in the future.
0 x

User avatar
Licho
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Lobbydev meeting minutes 2012-02-26

Post by Licho » 29 Feb 2012, 23:23

Cheesecan wrote:!join is deprecated and should not be used in the future.
Not so fast, wait until its in server.. until then !join all the way.
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Lobbydev meeting minutes 2012-02-26

Post by jK » 01 Mar 2012, 00:17

Code: Select all

    <Command Name="FORCEJOINBATTLE" Source="server">
      <Description>
      Sent to user specified by previous <clink name="FORCEJOINBATTLE"/> command from client. Client must subsequently comply by sending a <clink name="JOINBATTLE"/>  command to server.
      </Description>
    </Command>
In my opinion, it's bad to rely on a lobby client answer. If you really want to give the user an option to prevent a forcedjoin, it should be done via an Opt-out message and not the other way around. Else forcedjoin won't be backward compatible.
0 x

Satirik
Lobby Developer
Posts: 1688
Joined: 16 Mar 2007, 18:27

Re: Lobbydev meeting minutes 2012-02-26

Post by Satirik » 01 Mar 2012, 19:02

Cheesecan wrote:
Satirik wrote:
hoijui wrote:Licho, how long do you wnat to continue this?
none of the other devs thinks what you did was good, no matter how muhc you think it was, that will not change, and that is all that matters here.
you make system, and then ask others to comment is NOT the same like putting together the basics in cooperation already.
first is bad, we no want, second we want.
everyone understands why you want the first, and knows that you want it since long time. no need to tell us all the time. we do not want it.
i liked it, im pretty sure your force crap doesn't allow simple users to force people to join their own battle, because it's a force and not a request, and stop thinking you and all the fake spring devs are EVERYONE
As detailed in the protocol amendment, forcejoinbattle is only possible by host or lobby mod.
gajop wrote:
smoth wrote:I think having 2 gundam hosts in the future(one with and one without juggle) would be AWESOME!
What exactly would be the point of juggling on a single host? Matchmaking on the other hand is something to look for and that's what having !join/!forcejoin will make room for in the future.
!join is deprecated and should not be used in the future.
why is it only possible for host and moderators ? why is it a force ? someone can really force me to join a battle even if i don't want to ? will you add a FORCECLICK next ?
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Lobbydev meeting minutes 2012-02-26

Post by jK » 01 Mar 2012, 20:10

Satirik wrote:why is it only possible for host and moderators ? why is it a force ? someone can really force me to join a battle even if i don't want to ? will you add a FORCECLICK next ?
ONLY the host of the battleroom you are CURRENTLY joined is allowed to forcemove you (may be this should be even restricted to groups, so lobbybot host of battleroom A is only allowed to move you to battleroom B, but not to C?). So it is a feature of the battleroom/lobbybot. The user should not accept this with an agreement, same as you don't agree that the host is allowed to close the battleroom ...
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Lobbydev meeting minutes 2012-02-26

Post by AF » 02 Mar 2012, 13:50

The entire paridigm of !join or FORCEJOINBATTLE is wrong.

client in a battle sends: BATTLEINVITE AF message

server sends to me: BATTLEINVITE battleid personwhoinvitedme message

An Opt in system that's more flexible, less open to abuse, easier to implement, decouples requests from battles, allows you to invite people not already inside a battle, fits in better with existing protocol commands, matches closer with the behaviour of other lobbies in general outside of spring, and if it gets broken. It also sets a precedent for channel invitations.

The consequences are also far better security wise than FORCEJOINBATTLE, imagine, if BATTLEINVITE is compromised, you get an invite you can ignore (or switch off in options if the lobby has such a setting), but with FORCEJOINBATTLE, the worst case scenario is being forced into any old battle then immediatley dumped into a game via the host starting regardless of ready commands (or the lobby complaining and throwing warnings because it received unexpected commands).
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: Lobbydev meeting minutes 2012-02-26

Post by AF » 02 Mar 2012, 13:54

Not to mention that with FORCEJOINBATTLE I could setup a DSD autohost filled with 3 or 4 bots, but when you join it, the autohost sends FORCEJOINBATTLE to another battle, which then sends you back and forth, switching you between the two battles before you can leave.
0 x

User avatar
koshi
Lobby Developer
Posts: 1058
Joined: 14 Aug 2007, 16:15

Re: Lobbydev meeting minutes 2012-02-26

Post by koshi » 02 Mar 2012, 14:11

Reread the minutes. The system is already, albeit hackish as always, opt-in.
0 x

Post Reply

Return to “Lobby Meeting Minutes”

cron