Lobby :: Dev meeting minutes 2012.03.25

Lobby :: Dev meeting minutes 2012.03.25

Archive of lobby developer discussions

Moderators: Moderators, Lobby Developers

Post Reply
User avatar
Posts: 505
Joined: 08 Feb 2010, 22:21

Lobby :: Dev meeting minutes 2012.03.25

Post by danil_kalina »

Date: 25 March 2012


[*]remaining uberserver commands
OPENBATTLEEX family of commands
EXIT https://github.com/spring/LobbyProtocol/issues/2
[*]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[/list]

_koshi_ I'm here now, I see you haven't started yet
anybody awake?
[CN]Zydox a1983 bibim_ danil_kalina Licho[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_kalina aegis 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?
danil_kalina me again

-------------------- uberserver commands --------------------

_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
_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

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
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
_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"
_koshi_ these question generally weaken passwords imo, I see nothing good in their use
_koshi_ alright, so we'll ge going forward with the proposal as is?
a1983 +1
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 :P
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
_koshi_ so you'd like to add another command for that or want to fit the into SETEMAIL?
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
danil_kalina Proposal 3: it is for autohost, isn't it ?
_koshi_ anything there is to be replaced by SAYDATA*, not necessarily authost related
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


_koshi_ alright
next up commands discovered in uberserver that aren't in protocol yet
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
aegis _koshi_: yes, autohosts use it
afaik they still do
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
_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
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
_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
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
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?

------------------- IRC bridge -------------------

_koshi_ exactly
Clogger Add a welcome message property to battles, instead
_koshi_ we're already at 90+ minutes again
next would be:
aegis Clogger: 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?
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
_koshi_ alright, let's vote then. add compat flag and nochanneltopic command?
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
_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
_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
_koshi_ anybody seriously against?
good, meeting ends -------------------------------------------------------------------------------

[*]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 )

Accepted Licho and Aegis want and use eagerly

[*]IRC bridge
Accepted compat flag + command ( NOCHANNELTOPIC )

[*]OPENBATTLEEX family of commands
Postponed until next meeting[/list]
User avatar
Lobby Developer
Posts: 1059
Joined: 14 Aug 2007, 16:15

Re: Lobby :: Dev meeting minutes 2012.03.25

Post by koshi »

LISTCOMPATFLAGS wasn't declined (it's in protocol already), only the etherpad link was removed as it had become obsolete.

Edit: oh and SAYPRIVATEBATTLE(EX) wasn't accepted as is, but licho/aegis will prepare a new draft for a future meeting

Edit2: Clogger is an alt of CarRepairer
User avatar
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: Lobby :: Dev meeting minutes 2012.03.25

Post by hoijui »

ehhh wow! :-)
nice meeeting, congrats. :-)
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Lobby :: Dev meeting minutes 2012.03.25

Post by Forboding Angel »

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!
User avatar
Posts: 1571
Joined: 07 Feb 2005, 21:30

Re: Lobby :: Dev meeting minutes 2012.03.25

Post by Cheesecan »

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.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Lobby :: Dev meeting minutes 2012.03.25

Post by Forboding Angel »

Very little of what I said had to do with you.
User avatar
Lobby Developer
Posts: 1059
Joined: 14 Aug 2007, 16:15

Re: Lobby :: Dev meeting minutes 2012.03.25

Post by koshi »

I've added the last requested change to CHANGEEMAIL and merged the branch into spring/LobbyProtocol master.
Post Reply

Return to “Lobby Meeting Minutes”