server development/documentation / what was done this week
if meeting length < too long: custom properties decoupling account control from lobbyserver (for integration with external stuff like desura, fb, zk etc) cleaning old accounts
_koshi_ I'm here now, I see you haven't started yet anybody awake? [CN]Zydoxa1983bibim_danil_kalinaLicho[0K] hey aegis we haven't started yet aegis k _koshi_ i just came in 3 minutes ago and no one else seems awake aegis k a1983 I think we need at least Licho and hoijui to process meeting aegis we could work through some points? Licho[0K] well aegis there's licho. Licho[0K] i thought it started 2h ago was planning to go to bathtube now aegis is that a website? bibim_ hey Licho[0K] yeah something like a website _koshi_ i think you misunderstodd the dst bit then licho, sorry Licho[0K] brb in 30 mins or so feel free to do the meeting stuff meanwhile danil_kalinaaegis is a bot :D aegis exactly a1983 cool AI turing test is passing :) danil_kalina Is it hard, or no, Are you hot :D aegis yes _koshi_ alright, let's start then? meeting begins ---------------------------------------------------------------------------------- danil_kalina go go go _koshi_ welcome and who's volunteering for minutes this time? 23:04 danil_kalina me again
_koshi_ alright, thanks first up: document use of full release version string in protocol unless someone wants to discuss this again, this is only informative server minimum version shall be full xx.x from 89.0 on aegis k danil_kalina + aegis uberserver equates 87.0 = 87 for BATTLEOPENEDEX checks _koshi_ alright, next: final vote for account recovery stuff zydox had made the adjustments we've discussed last meeting and I had merged them in the email branch aegis for storing email - I'll either need to add a field to accounts.txt or we'll need to switch to a mysql backend 23:09 _koshi_ whatever suits you best I guess did you and hoi talk about schema compat? aegis I guess accounts.txt is still backwards-compat if we use awk extra field in schema shouldn't break tasserver? and it would ideally be implemented in both _koshi_ it currently converts from accounts.txt afaik to its scheme aegis I talked with hoijui, most of our sql should be identical _koshi_ but I dunno if the schemes are compat, so the ability to drop into accounts.txt would be a plus imo k
then there's licho concerns raised in the agenda i've moved them here: http://etherpad.springrts.com/NI0xrPffI3 aegis we coordinated a while back when he started working on tasserver 23:12 aegis web-based reset would add a web component uberserver does not currently have although I was toying with the idea of builtin server for weblobby+interface _koshi_ it's a nice addon I guess, but not necessary aegis email is easiest, and I'd probably email a temp password instead of a link (to remove postback complexity) i.e. no need to have a working url _koshi_ ok, we've left that intentionally open aegis implementation there doesn't matter as long as it works 23:16 _koshi_ anything else? aegis as argument against question/answer, someone in spring posted that he called up his cell company to reset his password and they said the secret question was "hahaha you forgot your password" 23:19 _koshi_ these question generally weaken passwords imo, I see nothing good in their use 23:20 _koshi_ alright, so we'll ge going forward with the proposal as is? +1 a1983 +1 23:22 bibim_ +0 we need a !ring command here :) aegis I can actually do that danil_kalina + aegis but some of us are probably in lobbies without RING +1 Licho[0K] my concerns are about email verification you wont verify email in anyway so you can register account with other than yours email bibim_aegis: well, Irc Bridge forwards ring as notices so it would work for irc users at least :) _koshi_ what good would that do licho? Licho[0K] dunno, annoy other person ? it would also be nice to have a way to associate email with given account but not necessary _koshi_ but verifying the address won;t help that then Licho[0K] yeah ok _koshi_ it isn't mandatory licho and you can set your email if you're logged in Licho[0K] i would like it for a bot if possible, so that existing zk players can add email to their accounts and reset through web but as i said its not needed bot could as well just store email separated in zk db and reset independently of lobby too so nm i dont care _koshi_ so basically you'd like admins to be able to set email? Licho[0K] well optionalyl if its nto too hard aegis not hard for me 23:31 _koshi_ so you'd like to add another command for that or want to fit the into SETEMAIL? i mean CHANGEEMAIL 23:35 aegis optional second param? _koshi_ account name and you can only set sth there that isn't your own of you're admin? aegis yeah _koshi_ of=if aegis same as checks like GETINGAMETIME work _koshi_ alright, I'll add that and merge then anybody object? danil_kalina no _koshi_ good. next up: act on items listed as "ongoing proposals"? anybody consider sth from the first link still viable/necessary to save? the second one is def. obsolete imo danil_kalina where is the first link, where is the second ? _koshi_ Links: ongoing protocol proposals http://etherpad.springrts.com/xBzU7W8wvg (delete?) http://etherpad.springrts.com/FYRUL6nUXO (deleteis already in protocol git) danil_kalina aha, it is below, let me see 23:41 danil_kalina Proposal 3: it is for autohost, isn't it ? 23:43 _koshi_ anything there is to be replaced by SAYDATA*, not necessarily authost related 23:44 danil_kalina List compatibility flags. Is it for backward compatibility ? move proposal 3 to autohost related stuff, to SAYDATA aegis listing compatibility flags is only necessary if *lobby* wants to be backwards compatible with old servers or forwards compatible with partial server implementations danil_kalina but why do we need that list _koshi_ i'm really just asking if someone wants to save anything from there, not discuss this yet again exactly for the reason aegis just stated bibim_ from the first link I guess the command description should be kept because they could be quite the same except using SAYDATA? danil_kalina why lobby need to be backward if it supports new server ? bibim_ apart from that I'm ok with deleting _koshi_ goog point 23:49
_koshi_ alright next up commands discovered in uberserver that aren't in protocol yet 1. SAYBATTLEPRIVATE & SAYBATTLEPRIVATEEX I don't see any use for that, is someone actually using it? Clogger Whats it for? _koshi_ indeed private messages are private messages imo 23:54 aegis_koshi_: yes, autohosts use it afaik they still do bibim_? a1983 or Licho? Licho[0K] what does it do? _koshi_ heh, seems no one but bibim_ would know aegis allows autohost to send message to single user in battleroom so join message etc aren't spammy 23:57 _koshi_ if that's the case no one would see these msg atm? cause no one is listenting for SAIDBATTLEPRIVATE [CN]Zydox server sends SAIDBATTLEEX, afaik But just to the specified user aegis yeah, server sends normal saidbattle / ex _koshi_ ah, now I get it Licho[0K] thats useful yeah i forgot to use it _koshi_ yeah, I agree only I couldn't even forget to use it :) +1 adding that to protocol then Licho[0K] wait a moment does server send SAIDBATTLEPRIVATEEX at all? i would like to make a difference between private and public message send this way is there a way to tell them apart( (for example i dont want private message to be copied ingame0 aegis only autohosts send saybattleprivate to server? so autohost knows when it's ingame... Licho[0K] yes, but it would need to store it aegis and knows what it's saying Licho[0K] its event driven, it would need to know what it sent and in what mode and store tha for processing in event furthermore event processing is very far in the code from the stuff that sends it - which is some submodule of spring log reader for example aegis if someone says something to the autohost while ingame, their fault:P er Licho[0K] no i mean lets say welcome message aegis what copies it ingame? the autohost? Licho[0K] yess .. but stuff connected to BATTLESAID or how its called aegis it won't receive that Licho[0K] oh ok aegis only the recipient Licho[0K] ok then it might be useful to make it differnet colored in lobby too but no biggie aegis use ex for color? or clients can color autohost messages Licho[0K] they cannot know hwich is private and which is public aegis you don't need different messages to color autohost messages [CN]Zydox It still would be nice for the client to know if all saw the message or just them Licho[0K] its not ALL autohost messages some will be public and some private aegis so? use ex/not Licho[0K] ex can be both even players can do ex aegis right, but you know which player is the autohost Licho[0K] thats hardly a reliable indicator whether others read the same message or not aegis from the client's perspective Licho[0K] but that would need some general autohost rule ex is used for all autohost messages atm and atm they are all public i want to use ex for private too it makes them stand out _koshi_ basically the PRIVATE in the command is misleading imo if it's not so much private, but 'only' Licho[0K] private will be useful for stuff like welcome or various lists, but not for stuff like posting link to replay after battle _koshi_ i could also see using saydata for this instead, no? Licho[0K] that would make it incompatible with other lobbies this stuff is to be visible in battle room lists = !listmaps well generally im not a big fun of various SAID and SAY commands i would prefer single one with flags but since we are i nthis mess already it would be nice to be able to tell difference between private and public message 00:12 _koshi_ I see no way of having that with either set atm. Could we postpone this, maybe you guys figure sth out till next meeting? a1983 I think nobody else interested in that cmd 00:15 Licho[0K] this command is useful its good one ther eis just no way for client to tell whether it was sent this way or as a public battle message _koshi_ i'd like reduced msg spam for everyone too aegis changing incoming message would require compat flag right now it's easy to add to things like welcome banner that are only useful to newly joined client Licho[0K] yeah i know it would need compat flag and for non compat it would appear as normal battle message you can add compat flag later http://etherpad.springrts.com/xBzU7W8wvg should not be deleted _koshi_ so you'll draft sth till next meeting then? it won't be Licho[0K] so we dont forget what is needed it wont be used in this form _koshi_ it's listed under ah protocol point now Licho[0K] ok _koshi_ so you'll draft sth till next meeting thenaegis,Licho[0K]? for the mtargeted msg i mean bibim_ back, sorry had to go afk aegis I think just compat flag = SAIDPRIVATEBATTLE? bibim_ [20:53:30] <_koshi_> 1. SAYBATTLEPRIVATE & SAYBATTLEPRIVATEEX [20:53:53] <_koshi_> I don't see any use for that, is someone actually using it? it's to avoid spam of welcome msgs in autohosts it's currently used by spads Licho[0K] draft what? aegis basically write down a proposed compat flag and the added commands?
_koshi_ exactly Clogger Add a welcome message property to battles, instead _koshi_ we're already at 90+ minutes again next would be: aegisClogger: can't personalize that _koshi_ "et" compat flag (send NOCHANNELTOPIC on join if channel has no topic, used only by IRC bridge) aegis "wecome Clogger, advanced player" _koshi_: bibim_ Clogger Oh _koshi_ is that really necessary bibim_? Licho[0K] customization is necessary all autohosts tell player his admin rights etc and when game started etc _koshi_bibim_'s afk again i guess bibim__koshi_ for correct irc bridge behaviour, yes no I was just reading what I missed :) _koshi_ seems kinda weird to me that you can't filter that out on the bridge end bibim_ it's the opposite, I need this additional command Licho[0K] well problem is he woould need to wait indefinitely maybei always found it odd that there was no "end of the list" in any of the commands aegis channel topic does that? er list? Licho[0K] it does send end of topic now? always? aegis channel list you don't need to send end of topic because it's one command Licho[0K] and its sent even if topic is empty? bibim_Licho[0K] with 'et' compat flag, you will always have a topic msg at the end of the list if there is a topic it's the normal topic message if there is no topic, it's the new NOCHANNELTOPIC (or something like that) message it's very very usefull for IRC/Spring bridge, due to irc specs Licho[0K] well if server does not send "empty topic" message i understand it can be useful bibim_ for tasserver I had coded a ugly hack which worked, but it didn't work on uberserver due to different command orders/timers so I decided to ask aegis about adding this functionnality to make it much cleaner Licho[0K] exactly _koshi_ channeltopic: Sent to a client who just joined the channel, if some topic is set for this channel. alright then, I see no harm in adding this into protocol instead of changing channeltopic semantics for everyone Licho[0K] well i would rather always sent channeltopic with empty string so this flag would not be needed aegis making topic part of channeltopic optional probably won't be backwards comp? because I know people complained about empty description on battle or w/e Licho[0K] do you need backward compI bet it wont break anything aegis no it will if they use positional crap Licho[0K] and if so satirik can fix it in a moment bibim_ I'm ok with both solutions aegis based on complaints from lobby devs when your battles didn't have all the params i.e. the last sentence arg was empty string we can't remove param from command and expect it to work still. Licho[0K] you could also send " " or something like that :) aegis that's ugl Licho[0K] nochanneltopic compat flag is ugly too .. but i have no strong feelings eitherway aegis nochanneltopic is far cleaner than adding extra strings in random commands 00:34 _koshi_ alright, let's vote then. add compat flag and nochanneltopic command? +0 Clogger Why is it needed, i missed it Just for irc bridge? a1983 yes _koshi_ actually, I should be more precise the vote should be for between two options bibim_ I don't care as long as there is a topic msg sent in every case nochanneltopic or classic topic msg with specific params/values 00:39 _koshi_ vote: pro compat flag vs pro channeltopic semantics change don't care bibim_ well I guess in this case I vote pro compat flag, but it's just because it's already coded a1983 it's not needed in ProtocolDescription anyway _koshi_ it's part of the protocol so it needs to be described aegis, Licho[0K], [1uP]CarRepairer, danil_kalina, [CN]Zydox, vote? aegis would be easiest to keep it as nochanneltopic most clients won't subscribe to it anyway _koshi_ anybody strong feelings pro channeltopic change then? otherwise we're going with the compat flag and I'd ask maybe bibim_ for a protocol patch bibim_ hum I don't remember, what happens when we open battle with an empty descriptionserver fills description with "(empty description)" or something like thator it's the lobby client which automatically fills it? Licho[0K] abstain bibim_ my idead is that maybe we could do the same for topic, something like "(empty topic)" _koshi_ battles have no topic bibim_ yeah I know _koshi_ ah description Licho[0K] motd [1uP]CarRepairer i use battle description as the "topic" Licho[0K] you mean battle title? bibim_ yes [1uP]CarRepairer yes bibim_ if the lobby server fills automatically empty battle title with "(empty description)", it could do the same for empty topic with "(empty topic)" it would be totally backward compatible and wouldn't require additional flags 00:46 _koshi_ don't like relying on a certain string to identify aegis then when you join a channel, it'll say "CHANNEL TOPIC: *" a little weird. but clients can update to support it bibim__koshi_ well actually there wouldn't be a need to identify Licho[0K] there would, for example in ZKL topic is overlay on top like this: http://img850.imageshack.us/img850/1787 ... 224805.png you dont want * there if its empty it should not be there bibim_ I had "(empty topic)" in mind, not "*", but I guess you don't want "(empty topic)" neither ok so forget it then _koshi_ ok Licho[0K] well i abstain on this aegis * is used in other places iirc to signify empty? Licho[0K] just mentioning how things stand * is used for passwords yeah _koshi_ compat flag + command it is then next would be: OPENBATTLEEX family of commands but since we're on 2hours again and this will likely take a while i'd like to postpone that bibim_aegis I don't think '*' is used for empty battle description, but I may be wrong aegis I know it's used for passwords bibim_ yes I'm ok with postponing _koshi_ it would also be good if someone could prepare a description of how those would be used for next meeting 00:51 _koshi_ anybody seriously against? good, meeting ends -------------------------------------------------------------------------------
Summary:
uberserver commands Accepted Can register account with other than yours email Accepted Add CHANGEEMAIL command
ongoing proposals Declined List compatibility flags Accepted SAYDATA Licho is keeping silence, It seems he is thinking about new server...( danil_kalina decision )
SAYBATTLEPRIVATE & SAYBATTLEPRIVATEEX AcceptedLicho and Aegis want and use eagerly
IRC bridge Accepted compat flag + command ( NOCHANNELTOPIC )
OPENBATTLEEX family of commands Postponed until next meeting
Joined: 07 Feb 2005, 21:30 Location: Cheese factory
Forboding Angel wrote:
A meeting without trolling, bickering, where people actually get stuff done. I am a fan!
Very nice!
Cheers to aegis for being there. It makes a world of difference!
I assume you're referring to me.
For the record I have not been trolling. If you go back to previous meetings, each one where Licho joined began with him attacking me and my grounds for being there.
Additionally, it is easy not to disagree if disagreement is outlawed. Welcome to new meetings where the rest abstain or +1 by default. Now you can have merry get togethers where the patricians rule by implied threat.
Users browsing this forum: No registered users and 1 guest
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
Home
Download
Login
Register
FAQ
Search
