=== are meeting minutes done? manually/automatically? by whom? === <[ARP]hoijui_irc> guess we can start now <[ARP]hoijui_irc> first topic is: <[ARP]hoijui_irc> how* <cheesecan> in other words who wants to volunteer to be secretary <[ARP]hoijui_irc> koshi... do you have a plan for setting up an automatic thing? <[ARP]hoijui_irc> or anyone else? <_koshi_> no, you guy didn't want/need that back when <Licho[0K]> [pikts]wolas i think there should not be map/mapoptions setup <_koshi_> guys* <Licho[0K]> because it can only be decided after number of players is known <Licho[0K]> (ffa case especially) <Licho[0K]> otherwise its about the way i would like it to look <Licho[0K]> there could also be simpler interface for ingame juggler (handled from the mod itself instead of lobby) <[ARP]hoijui_irc> ok, then we need a plan for who does it manually <Licho[0K]> maybe without chat <_koshi_> i will <[ARP]hoijui_irc> juggler topic comes later <[ARP]hoijui_irc> thanks koshi <[ARP]hoijui_irc> and for the future.. <_koshi_> right after i check whether logging is on, sec <Licho[0K]> also you need some "waiting for download" screen in later phase wolas <[ARP]hoijui_irc> in engine dev meeting, we have someone volunteer every meeting <Licho[0K]> i can post you logs if you want them <Licho[0K]> no aegis? <Licho[0K]> does it even make sense to discuss lobby stuff without him? <[ARP]hoijui_irc> lets say volunteer plan for now <[ARP]hoijui_irc> we can not make themeeting dependent on a single person
Conclusion: I'm doing minutes this time
=== everyone presenting themselfs (forum name + lobby project) === [19:39] ** BrainDamage joined the channel. <[ARP]hoijui_irc> hoijui - SpringLS (former TASServer) [19:39] ** Emblis joined the channel. <_koshi_> koshi - SpringLobby, relayhosts, ladder and so forth <[pikts]wolas> wolas -> random noob <cheesecan> openlobby and formely cheeselobby <Malina> danil_kalina - NotaLobby <sheepdev1> cheapsheep - muslce (android lobby client - chat only obviously) <[ARP]hoijui_irc> wolas, this is meant for lobby devs only <a1983> a1983 - NotaLobby <[pikts]wolas> I m interested <[ARP]hoijui_irc> you can read the meeting minutes afterwards <[ARP]hoijui_irc> many are interested <[pikts]wolas> ok i can be quiet if you want <[pikts]wolas> that wont harm anyone <[ARP]hoijui_irc> please leave <BrainDamage> BrainDamage - same projects as koshi, altough not very active in recent times <[pikts]wolas> lol ok [19:42] ** [pikts]wolas left the channel( ). <cheesecan> :'( [19:42] ** a1983 left the channel( Quit ). <[ARP]hoijui_irc> who is Emblis? <[ARP]hoijui_irc> and jseah? <[ARP]hoijui_irc> has just been added to this channel's operator list by <_koshi_> [19:43] ** a1983 joined the channel. <Emblis> Random guy striking terror in the local contryside.... <[ARP]hoijui_irc> ok.. then leave too, please <cheesecan> btw for future, we need chanserv for this channel <cheesecan> so we can /kick <[ARP]hoijui_irc> it is here [19:43] ** Emblis left the channel( ). <cheesecan> where? [19:43] ** a1983 left the channel( Quit ). <cheesecan> oh <[ARP]hoijui_irc> i guess i can't kcikc casue i am on irc <[ARP]hoijui_irc> or i dont know how [19:45] ** a1983 joined the channel. [19:46] ** jseah left the channel( ). <[ARP]hoijui_irc> k.. guess we can go to next topoc then <[ARP]hoijui_irc> topic
=== Meeting specifics (where (lobby/IRC), how often, which day, what time, # devs for meeting to start) === <[ARP]hoijui_irc> so.. i think once a week is of for hte beginning <[ARP]hoijui_irc> can still be done less often later on <[ARP]hoijui_irc> anyone wants to change that? <[ARP]hoijui_irc> day of week and time seem fine too <Malina> here, every week, Sunday/Monday, 19:30 CET <[ARP]hoijui_irc> we are 8 devs today <a1983> +1 <[ARP]hoijui_irc> one server dev <sheepdev1> seems fine, but if aegis can never be here for those meetings and what we discuss here cant be "forced" upon him... it doesnt seem effective <_koshi_> weekdays at that time is no good for me <[ARP]hoijui_irc> k <[ARP]hoijui_irc> he is not unreasonable usually <[ARP]hoijui_irc> if the 8 of us woudl agree on something, it woudl be likely he'd do it <[ARP]hoijui_irc> if he would always be totally against everythign, we could use an other lobby server <[ARP]hoijui_irc> or fork ueberserver <cheesecan> once a week, at least 5? <[ARP]hoijui_irc> sounds good though... <sheepdev1> +1 <[ARP]hoijui_irc> maybe lets say, additionally we need people from at least two widely used projects <[ARP]hoijui_irc> like ueberserver, SL, ZeroK, TASClient <[ARP]hoijui_irc> or at least one of them? <Licho[0K]> dogwalk bbl <[ARP]hoijui_irc> :D <cheesecan> I think in order for decisions to be valid a majority must be present.. so more than half of big projects <[ARP]hoijui_irc> that is not feasable, if you consider the ones i just named as the important ones <cheesecan> <[ARP]hoijui_irc> with Licho gone, we now have SL only in here <[ARP]hoijui_irc> so even though we are 8, we have two mising <cheesecan> then anything you decide, they could rightly oppose <[ARP]hoijui_irc> ok then lets forget that extra <[ARP]hoijui_irc> lets only use the 5 devs min <cheesecan> +1 <[ARP]hoijui_irc> and decide at 19:30 whether it is a good 5 devs (as in, representative) <[ARP]hoijui_irc> next topic then
Conclusion: we'll try having meetings sundays 19:30 cet, if 5+ devs are present
=== 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.
thanks koshi! and... it was a good meeting in my eyes, especially considering the last one, and that this is (kind of) the first real one. we still need someone to do the xml documentation of the two commands that licho suggested for j1. should not be more then 10min work i guess. of course this is actually Lichos task, but he seemed unwilling to do that. even a half-assed version of it would be ok, as long as we have something as a base to work & vote on.
engine dev meetings are usually not more efficient btw. but i have good hopes that it will work better for other discussions, where the situation will be different (nobody having done work yet that he feals is beeing disrespected or the like).
Joined: 07 Feb 2005, 21:30 Location: Cheese factory
An indicator of how the meeting went is that AF will probably be annoyed it didn't go as he predicted. Pretty good meeting in other words.
But in the future, to be more organized, meetings should have a fixed timeframe, say one hour. That way more will be accomplished when there is some kind of deadline. If someone has some complicated system they want to describe to the others, it's better to supply it as documentation in the meeting agenda for the next meeting rather than try to explain it during a meeting.
we can try that, but i don't think it will work. even if someone would do that kind of documentation, others will not read it beofre the meeting. i'd be happy to be proven wrong of course. multiple proposals by different people, regarding protocol, as git branches is a similar thing, and that would surely be good/the best way to compare different proposals (with the addition of a short explanation of each branch).
in addition to that, github even supports online/through-website forking,editing,committing,creating-pull-request in a single, simple action, which i was told wroks great for single files (which the protocol XML is).
edit: ... if that is still not easy enough, as you need to create an account, you can also send me the changed XML, though .. it quite sucks in case you had to do mroe and more changes.
Joined: 22 Feb 2006, 01:02 Location: cheap kitchen
if you need topics to discuss: -something to remove the need of ever having to type !commands into chat (eg standardization of autohost commands so lobbies can add buttons for that) -standardization of some UI stuff, some stuff should always be named the same. eg I think allyID sometimes is "ally" or "team" -validmaps.lua, validais.lua viewtopic.php?f=64&t=27491
Users browsing this forum: No registered users and 0 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum