Lobbydev meeting minutes 2012-03-04

Lobbydev meeting minutes 2012-03-04

Archive of lobby developer discussions

Moderators: Moderators, Lobby Developers

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

Lobbydev meeting minutes 2012-03-04

Post by Cheesecan »

Date: 4 March 2012
Present: BrainDamage, [V]sheep, [CN]Zydox, _koshi_, a1983, [PinK]halcyon, [ARP]hoijui_irc, [1uP]CarRepairer, danil_kalina, Licho[0K]

Agenda:
  • Someone volunteers for minutes
  • Server development/documentation
  • Continuation of discussion of proposals postponed last time
  • SAY command change

=== Someone volunteers for minutes ===

<_koshi_> welcome everyone
<_koshi_> who's doing minutes ?
<[ARP]hoijui_irc> hey :-)
<_koshi_> hint: it's not [ARP]hoijui_irc or me :P
<[ARP]hoijui_irc> doing minutes works like this:
<[ARP]hoijui_irc> you copy whole chat log into a text file
<[ARP]hoijui_irc> then run it through the python script referenced in the agenda etherpad
<[ARP]hoijui_irc> then cleanup maunually a bit, and add summary
<[PinK]halcyon> I'll do it
<_koshi_> alright, thanks
<Licho[0K]> who are you halcyon? Oh wait its cheese?
<[PinK]halcyon> cheese
<Licho[0K]> ok
<Licho[0K]> and a1983?
<Licho[0K]> kalina?
<[PinK]halcyon> danil_kalina on forums
<Licho[0K]> ok
<[1uP]CarRepairer> isn't there also a1983 on forums
<[ARP]hoijui_irc> Malina is danil, no?
<[ARP]hoijui_irc> next


=== Server development/documentation ===

<[ARP]hoijui_irc> as you have probably seen... FORCEJOINBATTLE has been added to the xml doc
<a1983> I'm here
<[ARP]hoijui_irc> i fixed up some things, extended the docu a bit, and added a docu text explaining the system
<[ARP]hoijui_irc> cheesecan made a SpringLS patch, which i extended a bit
<[ARP]hoijui_irc> it is currently running on a test server
<[ARP]hoijui_irc> so far it was only tested with SL that does nto support the new command (and ti fails)
<[ARP]hoijui_irc> so the handling of a non-supporting client is buggy on the server still, i would say
<[ARP]hoijui_irc> what it currently does is:
<[ARP]hoijui_irc> send LEAVEBATTLE
<[ARP]hoijui_irc> and then fake receiving a JOINBATTLE right after that
<Licho[0K]> you mean battlejoined or how its called
<[ARP]hoijui_irc> i am open for better ideas
<[ARP]hoijui_irc> no JOINBATTLE
<[ARP]hoijui_irc> should i try battlejoined you mean?
<Licho[0K]> you should send to client the message that it normalyl gets when it joins a battle
<Licho[0K]> same for leavebattle
<Licho[0K]> battleleft
<[ARP]hoijui_irc> i think that is what i do
<[ARP]hoijui_irc> what i think is the problem..
<[ARP]hoijui_irc> that i send LEAVEBATTLE and immediatly after that do the joining
<[ARP]hoijui_irc> maybe i will try to send the joining a bit later
<[ARP]hoijui_irc> 500ms delay or so
<[ARP]hoijui_irc> to give the lobby time to handle the leaving part propperly
<Licho[0K]> i cant speak for sl but it should work fine for zk even without delay
<[ARP]hoijui_irc> ok
<[ARP]hoijui_irc> we can test on the server afterwards
<Licho[0K]> it will need to be done for uberserver eventually..
<Licho[0K]> unless you plan to switch lobbyserver yet again
<Licho[0K]> its tasserver based right?
<[ARP]hoijui_irc> SpringLS is tasserver based, yes
<[ARP]hoijui_irc> ok so one last time
<[ARP]hoijui_irc> we decide things here, and if someone does not comply with it
<[ARP]hoijui_irc> he will sooner or later be obsolete
<[ARP]hoijui_irc> if we add lots of new stuff, and SpringLS supports it, and ueberserver not, we will switch
<[ARP]hoijui_irc> if both support it, we wil probably not switch, or only later.. if there is a reason
<[ARP]hoijui_irc> no need to discuss this eveyr meeting again though
<_koshi_> fully agree
<Licho[0K]> idc as long as the server is stable and has same features
<[CN]Zydox> So the FORCEJOINBATTLE basically switches the user to another battle on the server side, the clients just needs to be aware that it happened?
<[ARP]hoijui_irc> ok so.. we will do ZK testing later with current thing, and .. try other ways to handle it..
<[ARP]hoijui_irc> and at some point we will need lobbies to test, that support FORCEJOINBATTLE
<_koshi_> to that end i've gotten in contact with wolas
<[ARP]hoijui_irc> dox, not really... it instructs the client to move
<Licho[0K]> zydox is correct, if lobby does not support the command it force moves
<[CN]Zydox> So the LEAVEBATTLE & JOINBATTLE is handed on the client?
<Licho[0K]> (compat flag based)
<_koshi_> that patch isn't usable tho and he declined on working further on it
<[CN]Zydox> When I read what hoijui wrote, I got the impression that it all happened inside the server
<[ARP]hoijui_irc> depends whether the client supports the commadn or not
<_koshi_> the idea is the server immitaes the responses to the client it would normally get if it left and joined another battle
<[ARP]hoijui_irc> if it supports it, then it instructs the client to move
<[ARP]hoijui_irc> if not, then we have to do hack stuff on the server.. trying to get hte client to move.. and we still have ot figure out what works best for that
<[ARP]hoijui_irc> ..yeah that
<[CN]Zydox> How does the server know if the client supports it or not?
<Licho[0K]> compat flag
<[CN]Zydox> Wouldn't it be easier just for the client to respond with something like AGREED and then the server switches the user to the new battle with the internal LEAVEBATTLE & JOINBATTLE ?
<Licho[0K]> no
<[ARP]hoijui_irc> zydox, read last meeting minutes, and the protocol doc
<_koshi_> and we've discussed taht to near death already
<[ARP]hoijui_irc> it seems you have not yet
<[ARP]hoijui_irc> yeah
<[CN]Zydox> I checked the protocol
<[CN]Zydox> but let's continue then


=== Continuation of discussion of proposals postponed last time ===

<[ARP]hoijui_irc> ..alternatively though, we could postphone them and start with properties instead
<_koshi_> has anybody added anything to the proposals?
<Licho[0K]> look same
<Licho[0K]> we voted on connect command
<Licho[0K]> but some people didnt understand why its proposed
<Licho[0K]> is it clear now and ready to next vote?
<[ARP]hoijui_irc> it is also badly docuemtned
<[ARP]hoijui_irc> we said it needs more docu
<[ARP]hoijui_irc> as was done for forcejoin
<Licho[0K]> i really dont see whats missing
<[V]sheep> which part are you talking about? this one: 1. Protocol - Add new commands for joining User ?
<_koshi_> Proposal 2.
<Licho[0K]> http://etherpad.springrts.com/xxxxxxx [[snipped, see http://pastebin.com/QmfUYvFh]]
<_koshi_> and fwiw it's perfectly clear to
<[V]sheep> should the client change its ingame status after it connects ?
<Licho[0K]> does not matter, this is not standardized anywhere
<Licho[0K]> i assume its set to ingame if it has spring running
[20:14:04] ** danil_kalina joined the channel.
<[ARP]hoijui_irc> ok.. guess its fine then.. just.. pease use full sentences, not Betalord ones
<[ARP]hoijui_irc> for some reason, he alwyas left out some words
<[ARP]hoijui_irc> mostly "the"
<[PinK]halcyon> those proposals look ok to me
<[ARP]hoijui_irc> so in what scenario are these comamnds used?
<[PinK]halcyon> proposals 2 and 3 I mean
<Licho[0K]> which commands?
<[ARP]hoijui_irc> proposal 2 for now
<Licho[0K]> proposal 2 is used for better matchmaking - to initiate game without creating game room first
<Licho[0K]> its also use dto initiate multiple games from same lobby room
<[ARP]hoijui_irc> ahh ok
<[ARP]hoijui_irc> that should be explaiend in one of the two comands or i n separate text then
<[ARP]hoijui_irc> will add that
<[PinK]halcyon> reportdownloadprogress is useful for players to see how long they have to wait for others
<[PinK]halcyon> atm some lobbies say it in chat
<_koshi_> imo this could better be represented and communicated via extended propoerties on users
<Licho[0K]> not always koshi
<Licho[0K]> you can have multiple running requests
<Licho[0K]> like matchmaking first requests dsd but then it has to change to smalldivide and both requests are running
<[CN]Zydox> Shouldn't it just display the info for the last request?
<Licho[0K]> no
<danil_kalina> I like download progress
<[CN]Zydox> why is the DSD progress intessting if the battle will use smalldivide?
<[ARP]hoijui_irc> multiple downloads can nto be handled through properties?
<Licho[0K]> not easilyl hoi
<Licho[0K]> because you could be requested for DSD by completely different agent
<[ARP]hoijui_irc> one game can depend on multiple files
<_koshi_> hmm licho, mapping onto properties would also allow to advertise download progress of non-requested resources
<Licho[0K]> or DSD can be valid at same time as small divide
<[PinK]halcyon> if you sent download speed instead you wouldn't need to send as many updates
<Licho[0K]> speed is sent
<Licho[0K]> you have progress + eta + time
<[V]sheep> with this prop2/CONNECTUSER, it means users/lobbies have no way to see/set game options before game starts except by interacting with autohost. is that correct ?
<Licho[0K]> you can calculate speed including acceleration vector
<Licho[0K]> :)
<[PinK]halcyon> you only need to know speed once
<Licho[0K]> thats entirely dependent on how is this command used [V]sheep
<[PinK]halcyon> after socket buffer is full and dl is stabilized
<[PinK]halcyon> then you can predict when it is done
<Licho[0K]> [PinK]halcyon downloaders use more advanced ways, like torrents with multiple sources
<_koshi_> also sheep, currently you can see what is set, but not what's actually to be used
<Licho[0K]> or rapid with multiple phases
<Licho[0K]> yes options and even team depend entirely on autohost
<Licho[0K]> and they are completely decoupled from lobby room in reality
<[PinK]halcyon> well..consider traffic impact of this type of regular messages
<Licho[0K]> there will be same traffic anyway halcyon
<Licho[0K]> with user attributes traffic is exactly same
<Licho[0K]> its just syntax change
<[PinK]halcyon> you mean cpu speed?
<[V]sheep> ?
<Licho[0K]> what are you talking about halcyon
<[PinK]halcyon> which user attribute
<_koshi_> uhm
[20:25:47] ** BrainDamage joined the channel.
<Licho[0K]> someone said it could bne done with user attributes
<_koshi_> proly no one but licho hoi and I know what extended propoerties are
<_koshi_> forgot about that
<[PinK]halcyon> that is just an idea
<[ARP]hoijui_irc> the question is, whether we shoudl use such comadns, or make general properties support first, and then use them to implement the smae functionality (and mcuh mroe of course)
<Licho[0K]> try /j #extensions
<[ARP]hoijui_irc> hey BD
<Licho[0K]> or /j #nightwatch
<Licho[0K]> not sure
<BrainDamage> hi
<[PinK]halcyon> imho you cannot say it will be better than attributes and assume that is fine..says nothing if it is actually good
<Licho[0K]> for battle room its useful as a general message
<Licho[0K]> with attributes to be used like that you need complicated systemwith subscriptions
<[V]sheep> its #extensions
<Licho[0K]> and permissions
<[V]sheep> err... #extension
<[PinK]halcyon> have you made an estimate how many messages will be generated from this
<[PinK]halcyon> what if resource is really long
<Licho[0K]> so what?
<Licho[0K]> at best it adds 60 bytes per minute :)
<Licho[0K]> thats 1 byte per second :)
<Licho[0K]> thats hardly anything
<[V]sheep> we are discussing this on etherpad... which embeds keystrokes in http messages :)
<[PinK]halcyon> so I put a novel inside resource
<[PinK]halcyon> and send it to everyone?
<[PinK]halcyon> :D
<[V]sheep> maybe its not a problem for clients... could it be for server?
<_koshi_> actually what I'm referring to is not lichos hack with the extra channel, but:
<_koshi_> custom properties:
<_koshi_> https://github.com/hoijui/LobbyProtocol ... 14e7da0032
<_koshi_> https://github.com/lunixbochs/uberserve ... rtymap.txt
<Licho[0K]> no it could not be a problem for srever
<Licho[0K]> yes i know koshi as i said its complicated problem and even that proposal is not complete and covering all needed aspects
<[V]sheep> at first sight, its missing errors... like trying to define an already defined property
<Licho[0K]> i also think that mapping on properties is a a bit hard
<Licho[0K]> will it demand every client to set download property on every resource even the one it has alreadY?
<Licho[0K]> just so that autohost can read the property?
<Licho[0K]> you also have to avoid name conflicts
<Licho[0K]> and transmit more information so more properties or property value encoding (to cram progress, eta in one)
<[CN]Zydox> like the SETSCRIPTTAGS command?
<_koshi_> well, imo it's a general decision we're facing here. Either try to use the generic approach of attaching new metadata with the property map design or introduce new protocol commands for new metadata
<Licho[0K]> with is a special case and not a genral property map case imo
<Licho[0K]> because requestor and battle room people need to read it, others not
<[ARP]hoijui_irc> i would say, if there is a somewhat realistic chance that it can be done well enough wiht properties, we should do properties first
<Licho[0K]> with proeprties you are also digging a hole
<Licho[0K]> because you will need to define the proeprty rules
<_koshi_> the design spec includes a pub/sub commands btw
<Licho[0K]> and basicalyl define the same thing but with properties
<_koshi_> not following
<[ARP]hoijui_irc> yeah true
<Licho[0K]> you will need to say that client must set map.internalname.percent
<Licho[0K]> map.internalname.eta
<Licho[0K]> etc for game and engine
<[ARP]hoijui_irc> it is not the smae thing though, as properties are still more leightweight.. definition wise
<Licho[0K]> you will need to specify the rules just with propmap
<[PinK]halcyon> lobbies request that info by polling?
<_koshi_> you can subscribe to changes
<Licho[0K]> you also need the request command
<Licho[0K]> in any case
<Licho[0K]> this cannot be done with properties
<_koshi_> yes
<[ARP]hoijui_irc> needs no changesi n main protocol doc, no compflags, no protocol version change, no precautions in lobbies that do not know abotu the protoperties
<Licho[0K]> yes but then you might hit a lobby which is silent
<Licho[0K]> and you dont know that
<Licho[0K]> or which does something else with those properties
<_koshi_> i think the request command is fine if you speficy more narrowly what resource is
<[ARP]hoijui_irc> if it uses the same properties for soemthing else, it is buggy
<Licho[0K]> resource is anything you need to run spring, atm three types are defined, map, mod and engine
<_koshi_> as in filename, internal name, either?
<Licho[0K]> its defined below as internal name
<Licho[0K]> and in case of engine version name
<[ARP]hoijui_irc> as we will have, as you alreayd said, the properties defined
<Licho[0K]> " Resource is resource name - internal name in case of map or game, and engine version including last number in case of engine. User is user name"
<_koshi_> sorry, I don't see that
<_koshi_> got it
<_koshi_> for me it was above >_>
<[PinK]halcyon> doesn't it make sense to always listen to changes affecting you
<Licho[0K]> ?
<[PinK]halcyon> I mean LISTEN/UNLISTEn
<Licho[0K]> well imagine if its implemented using properties
<Licho[0K]> client joins battle and suddently all existing people in battle must request listen on 6 properties
<Licho[0K]> and the joiner must set them accordingly
<Licho[0K]> map.name.progress
<Licho[0K]> map.name.eta
<Licho[0K]> etc
<Licho[0K]> its unwiedly and spammy
<[PinK]halcyon> so listen only tells on changes..what if user misses change
<Licho[0K]> thats why i think that special command is simpler in that case
<[PinK]halcyon> like they join right after
<Licho[0K]> yes but point is you have to register to lstart listening
<Licho[0K]> so on every join all OTHER existing clients in battle will have to start listening
<[PinK]halcyon> yes
<Licho[0K]> they will all have to send number of players * 6 request to server to start getting info about current map
<Licho[0K]> and when map changes again they have to request that
<Licho[0K]> thats why im against implementing this as properties
<[PinK]halcyon> it's like server maintains model instead of client
<[PinK]halcyon> model of state relating to client
<[ARP]hoijui_irc> sounds liek the server could handle it internally using properties. maybe?
<Licho[0K]> that does not matter really how its done in srever
<Licho[0K]> it could be done so
<Licho[0K]> also issue with properties is escaping
<Licho[0K]> you need to be able to represent names with spaces
<[ARP]hoijui_irc> it would matter for the order of implementation
<[ARP]hoijui_irc> hmm i guess it is not a too big thing, on hte server side anyway, right?
<[ARP]hoijui_irc> so koshi, what do you think?
<Licho[0K]> on the server side its nothing
<[ARP]hoijui_irc> properties for that or not?
<Licho[0K]> its just relay
<[ARP]hoijui_irc> mm
<Licho[0K]> it could all be done in direct client to client pm
<Licho[0K]> all this is just to satisfy the craving for buroacracy :)
<Licho[0K]> just like with !join
<[PinK]halcyon> players will be happy to see less commands passed in chats
<a1983> May be Licho is rigth, why server should implement matchmaking?
<[ARP]hoijui_irc> UHM
<Licho[0K]> why would they see anything in chat halcyon?
<[ARP]hoijui_irc> koshi?
<Licho[0K]> its up to lobby to hide that
<a1983> agree
<[PinK]halcyon> bcs some lobby will always not hide it
<_koshi_> not sure what you're asking me now [ARP]hoijui_irc
<[PinK]halcyon> but anyway..maybe not a big boon
<[V]sheep> if they dont hide it, its because they dont process it... so its better for users to see it :)
<[ARP]hoijui_irc> properties for that or not?
<[PinK]halcyon> bureacracy it is then
<[ARP]hoijui_irc> koshi: properties for that or not?
<_koshi_> i'm pro properties in general
<[ARP]hoijui_irc> UHM!
<[ARP]hoijui_irc> ok but you are not a politicion before elections in a polit talk here
<Licho[0K]> question is do you want to implement this machnism as :
<[PinK]halcyon> I still don't see why listening in is optional
<Licho[0K]> 1) using new server ocmamdns thats only relayed (current proposal)
<Licho[0K]> 2) using direct client to client pm (+no need for server change)
<Licho[0K]> 3) using properties (needs complicated rules and more work on client and server)
<[ARP]hoijui_irc> i ma pro 1 then
<a1983> We should start from that desicion )
<[ARP]hoijui_irc> seems nobody brings up arguments for 3
<Licho[0K]> im for 2
<[PinK]halcyon> properties don't make sense, server knows which client joined battle, just send them updates, no need for client to register
<Licho[0K]> basically with 2 we could add simple chat command !progress mapname 30% 345
<Licho[0K]> and client could send it in battle room
<Licho[0K]> and lobbies would parse it
<Licho[0K]> no need to touch server
<Licho[0K]> same can be sent in pm if its requested by pm
<Licho[0K]> and client itself can validate if request comes from valid user (room host or admin)
<[PinK]halcyon> why have multiple messaging systems, it's not consistent design
<Licho[0K]> why adding command for every new messages you want to send in a channel?
<Licho[0K]> we dont have "SENDHI" sends hi to battle room command
<[PinK]halcyon> wasn't the original idea to do that, only it took too long?
<[PinK]halcyon> ;D
<[V]sheep> lets bring a *little* bit of bureaucracy to prop 2 by requesting that commands be documented so people dont have to look at autohosts source code to know what to implement
<a1983> Because thay have diffferent purposes


=== SAY command change ===

<[ARP]hoijui_irc> instead of using chat for that, could we not add a new set of commands that work exactly like the say commands, but are meant for inter-lobby client com?
<[PinK]halcyon> why use say !join, at least add some other cmd for it
<Licho[0K]> there could be universal !data command or something
<[ARP]hoijui_irc> (and as such are not shown ot the user)
<[PinK]halcyon> exactly
<Licho[0K]> yes it could be some common prefix or something
<Licho[0K]> but no need to use something else than messages
<[ARP]hoijui_irc> and of course what sheep said, these comamdns still had to be docuemtned somewhere
<Licho[0K]> messages already solve the issue of grouping users
<Licho[0K]> and broadcasting
<Licho[0K]> it could even be special "DATA" command instead of SAY/SAID
<Licho[0K]> but all the uses can be done without changing server further
<[PinK]halcyon> imho that is a client processed command
<[PinK]halcyon> that requires no server handling
<[PinK]halcyon> name it something befitting that
<Licho[0K]> yes except for routing/broadcasting
<Licho[0K]> SAYDATA
<Licho[0K]> DATASAID
<_koshi_> either prefix messages or DATA would be fine with me
<Licho[0K]> for me too either prefix or SAYDATA
<a1983> DATASEND/DATARECEIVE
<[ARP]hoijui_irc> DATA woudl mean no spamming of old lobby users
<Licho[0K]> yes
<Licho[0K]> so just add something exactly like say/said except its called saydata ?
<_koshi_> my quarrel with messages from/to is I won't be bulied into rummaging thru 16 places to find what messages is what
<[ARP]hoijui_irc> and i would also like it more cause it fits better
<Licho[0K]> content can still be agreed upon
<Licho[0K]> in a same way
<[PinK]halcyon> needs a new protocol for those messages
<[V]sheep> +1 to SAYDATA/DATASAID ... may need a private version too
<[PinK]halcyon> :D
<Licho[0K]> yes it should mirror say functions
<Licho[0K]> it could even be extra parameter to say
<Licho[0K]> "send as data"
<Licho[0K]> and said "data message"
<Licho[0K]> and compat flag "data compatible"
<Licho[0K]> if not you are not getting data messages
<[ARP]hoijui_irc> SAY just does not make sense
<[ARP]hoijui_irc> people/users say
<[ARP]hoijui_irc> lobbies dont say
<Licho[0K]> it does its exactly same
<[PinK]halcyon> needs a new documentation, and some ppl will want to parse them automatically (means it should be xml)
<[ARP]hoijui_irc> they exchange commands
<Licho[0K]> its exactly same hoi, you sometimes need to say to battle room
<[ARP]hoijui_irc> dont know what name is best yet though
<Licho[0K]> sometimes to channel
<Licho[0K]> sometimes to private
<Licho[0K]> so its exactl like say
<Licho[0K]> only content is not user chat but machine data
<Licho[0K]> i would solve it as an extra parameter to say messages
<[ARP]hoijui_irc> yeah, thats what i said, smae command structure, but SAY does not match
<[ARP]hoijui_irc> the word
<Licho[0K]> probably also simpler in server
<Licho[0K]> oh its for simplicity
<Licho[0K]> so that you dont have to specify/implement new command
<Licho[0K]> you just add extra parameter
<Licho[0K]> like emote
<[PinK]halcyon> CLIENTMSG?
<[ARP]hoijui_irc> that woudl still spam old clients
<Licho[0K]> no it would not
<Licho[0K]> are you listening? :)
<Licho[0K]> compat flag
<Licho[0K]> if you dont set it you dont get messages marked as "data"
<[ARP]hoijui_irc> mm ok
<[1uP]CarRepairer> why is it bad if old clients are spammed with a server message
<Licho[0K]> and its uber simple in server and in client
<[PinK]halcyon> yep..true
<[PinK]halcyon> but pls do proper documentation(!) or it will fail
<[1uP]CarRepairer> it's just ignored
<Licho[0K]> if its piggybacked on say they would see the machine messages
<[ARP]hoijui_irc> yeah it is, i just dont like to have a command named SAY, and have it used for programms to exchange data
<[ARP]hoijui_irc> it smells C++
<a1983> ))
<Licho[0K]> but you will have to mirror all say commands if you want extra one
<Licho[0K]> on clients too
<[PinK]halcyon> c'mon, just rename it, issue done
<[ARP]hoijui_irc> yeah i know
<Licho[0K]> it becomes much more complicated to implement
<Licho[0K]> and maintain
<Licho[0K]> you will be forced to do every change in 2 places -> bad
<[ARP]hoijui_irc> rename is of course also not an option
<[ARP]hoijui_irc> not really, can handle it rhoguh alias
<[PinK]halcyon> now this is bureacracy
<_koshi_> i really see no reason for the duplication
<[ARP]hoijui_irc> ok ok
<[ARP]hoijui_irc> compatFlag + additional param to SAY* commands then
<_koshi_> +1
<Licho[0K]> yes
<Licho[0K]> or prefix, i dont care
<Licho[0K]> whatever suits you better guys
<[ARP]hoijui_irc> :D
<_koshi_> toggle
<Licho[0K]> prefix => no server change needed
<Licho[0K]> comaptflag + toggle -> can fitler out from old clients
<[ARP]hoijui_irc> so the biggest work then is.. the new docuemntation
<[ARP]hoijui_irc> integrate into the smae document?
<[ARP]hoijui_irc> make new one?
<[ARP]hoijui_irc> who creates it?
<[PinK]halcyon> it is different, why should it be in protocol document
<[1uP]CarRepairer> i still don't see why old clients are bothered by a new command
<[V]sheep> thats progress, carrep :P
<[ARP]hoijui_irc> because the exact smae people ahve to care about it
<[ARP]hoijui_irc> you can just add an aother section in the XML, and render it the smae way, with the XSLT
<[1uP]CarRepairer> i only say this because the compatflag thing seems unnecessary for a new command
<[PinK]halcyon> mm okey
<[ARP]hoijui_irc> it is not a new command
<_koshi_> [21:07:21] <[ARP]hoijui_irc> compatFlag + additional param to SAY* commands then
<[PinK]halcyon> this meeting is very strange, basically now everyone wants to do the opposite of last time
<[1uP]CarRepairer> i thought you were discussing SAYDATA
<a1983> )))
<[ARP]hoijui_irc> :D :D :D
<[1uP]CarRepairer> sorry
<Licho[0K]> thats because i done woodoo [PinK]halcyon
<[V]sheep> i'm not sure i get it... additional param == additional argument ... or suffix to SAY* ?
<Licho[0K]> additional param/toggle to say sheep
<Licho[0K]> +compat flag
<[ARP]hoijui_irc> yeah argument
<[1uP]CarRepairer> only thing about the extra arguments is it's hard to eyeball them when they use tab separation
<[1uP]CarRepairer> but that's a personal problem
<[ARP]hoijui_irc> argument name="isCommand"
<Licho[0K]> in this case you set compat flag and just send extra normal isCommand 1/0
<a1983> Because on 3-d meeting we begin to know what we need. but this is still hack way.
<[PinK]halcyon> well, at least now, you distinguished between commands that the server processes and commands that it only routes
<[V]sheep> no, server wouldnt process them anyway... even with iscommand=1... right?
<[ARP]hoijui_irc> i guess .... nobody else will do the documentaiton stuff anyway
<[ARP]hoijui_irc> so i will try to find time for it
<[ARP]hoijui_irc> as in.. define it in DTD and write XSLT
<[ARP]hoijui_irc> but i expect licho to do the actual commadn docu then
<Licho[0K]> buroacracy, im just level 100 buroacrat
<[PinK]halcyon> funfun
<[ARP]hoijui_irc> fuehrer
<Licho[0K]> yeah i will document acutal payload
<Licho[0K]> or more propose them
<[ARP]hoijui_irc> ..?
<Licho[0K]> it will be similar to whats already proposed with connectuser and requestdownload
<[V]sheep> wouldnt it be better to have the isCommand arg last ... ?
<Licho[0K]> no sheep because text can contain spaces
<Licho[0K]> its best to have sentence last
<Licho[0K]> always
<[PinK]halcyon> what does server care about your dl eta
<[V]sheep> its the same... if sentence, arg can't contain tab ...
<[PinK]halcyon> strange to store such a thing in property
<[V]sheep> and this would make it more like adduser with accountID based on compatflag
<Licho[0K]> no other command use sentence in middle
<Licho[0K]> dont put it last
<[V]sheep> well, of course, because once in sentence mode you cant revert back to non-sentence... :)
<[PinK]halcyon> yes such awesome design
<[V]sheep> yeah i've named my parser PerverseProtocolParser ...
<[ARP]hoijui_irc> lets vot on propoasl 2 and 3 then
<[ARP]hoijui_irc> or say.. the new proposal 3
<[ARP]hoijui_irc> compatFlag and additional arg to *SAY* commands
<[PinK]halcyon> some point in time..someone..maybe betalord..wanted to save a few characters..today we propose to send huge "resource" in arguments
<[ARP]hoijui_irc> plus documentaiton of commands
<[PinK]halcyon> obviously efficiency went out of the picture somewhere
<a1983> Do we need pro 2,3 if we iplement additional SAY flag?
<[ARP]hoijui_irc> proposal 2 (CONNECTUSER)
<[ARP]hoijui_irc> +1
<[ARP]hoijui_irc> 3 not as on etherpad, no
<[ARP]hoijui_irc> 2 yes
<_koshi_> proposal 2: +1
<Licho[0K]> +1
<[PinK]halcyon> +1
<[V]sheep> abstain
<a1983> abstain
<Licho[0K]> 3: -1, new say: +1
<[1uP]CarRepairer> abstain
<Licho[0K]> abstinency is bad for you
<[PinK]halcyon> still no documentation on character limit in resource
<Licho[0K]> this is now moot but there is no limit
<Licho[0K]> internal name jhas no limits
<Licho[0K]> ascii
<[PinK]halcyon> I will send you the bible then
<[PinK]halcyon> as one sentence of course
<Licho[0K]> sure
<Licho[0K]> server will stop that
<Licho[0K]> it has some line length limits
<_koshi_> 3: -1, new say: +1
<Licho[0K]> with new say we can then define universal services handled by third party bots already, like offline messages, or offline channels
<a1983> new say arg +1
<Licho[0K]> though this feature actually belongs to server :) its not implemented there
<[ARP]hoijui_irc> 3: -1, new say: +1
<[ARP]hoijui_irc> i will also do proposal 5
<[PinK]halcyon> prop 3 is just not documented enough
<Licho[0K]> 5 should actually be extnesions
<_koshi_> both Proposal 2 and new say are agreed then with no vote against
<[ARP]hoijui_irc> i mean .. write it to the protocol doc
<[1uP]CarRepairer> -1525630178 MUSLCE (Android Lobby)
<[1uP]CarRepairer> yeah ok
<[V]sheep> it looks better in hex...
<[ARP]hoijui_irc> i woudl change that sheep
<[PinK]halcyon> no I am -1 prop 3
<[PinK]halcyon> not that anyone listened to my complaints
<[V]sheep> and its negative because there is no point in choosing something which may conflict with a valid cpu frequency
<[ARP]hoijui_irc> it is too logn to easyli recognize by eye wiht a swift look
<Licho[0K]> [PinK]halcyon do you releaze we voted 3 down?
<[PinK]halcyon> no
<Licho[0K]> we didnt listen to you but you didnt listen to us apparently
<[1uP]CarRepairer> what's this hex 5AEF44E2
<[PinK]halcyon> it's good that it is mutual
<[PinK]halcyon> imho, u basically failed to get ur cmd thru bcs u dont even bring it up
<Licho[0K]> with lord's blessing, there will be a new say before next harvest
<[V]sheep> prop 3 : abstain, new say abstain (i'd +1 if isCommand arg is last)
<[PinK]halcyon> 360 degrees
<Licho[0K]> sure halcyon :) I proposed the new say that makes 3) irrelevent .. but ok.. i failed at getting "my" comand through
<[1uP]CarRepairer> i somehow prefer a new command than add params to existing SAY but i abstain from all votes
<[PinK]halcyon> yes well.. will say cmds even be voted on
<[ARP]hoijui_irc> yes
<[PinK]halcyon> good that you say this now
<[ARP]hoijui_irc> same procedure
<[ARP]hoijui_irc> we siad that already
<[ARP]hoijui_irc> logn ago
<a1983> I agree with [1uP]CarRepairer
<[ARP]hoijui_irc> licho siad it
<[PinK]halcyon> I didn't see it
<[ARP]hoijui_irc> ok
<Licho[0K]> unmute me
<[ARP]hoijui_irc> :D
<[PinK]halcyon> wish I had muted u
<[1uP]CarRepairer> ?
<[PinK]halcyon> a joke
<_koshi_> GUYS
<[ARP]hoijui_irc> we are done, right?
<Licho[0K]> yeah
<Licho[0K]> gg
<[ARP]hoijui_irc> btw... will need help in tesitng and debugging SpringLS FORCEJOIN, most likely
<_koshi_> imo we can strike the stuff below Prop 5
<Licho[0K]> just force join me using old !join to test it ;-)
<[ARP]hoijui_irc> yeah
<[V]sheep> i can add command to my client if you want
<[PinK]halcyon> lol
<[PinK]halcyon> so meeting end here?
<[ARP]hoijui_irc> yeah
<[PinK]halcyon> ok
<[PinK]halcyon> ***


Summary:
  • Proposal X (SAY with extra flag for filtering in old lobbies) was accepted.
  • Proposal 2 (CONNECTUSER) was accepted as on etherpad.
  • Proposal 3 (REQUESTDOWNLOAD) was rejected, will be re-proposed in the future for use with the amended SAY command.
  • Proposal 4 (renaming FORCEJOINBATTLE to JOINBATTLEFORCE) was rejected.
  • Proposal 5 was accepted, hoijui will do his thing(document).
Post Reply

Return to “Lobby Meeting Minutes”