--- Log opened Sun Nov 16 00:00:04 2014
--- Day changed Sun Nov 16 2014
20141116 00:00:04< gfgtdf> iceiceice: i think it's wrong that we stpore teh controller tweaks in the history
20141116 00:00:38< gfgtdf> iceiceice: the cleints usualy read the "history" after the  prestart event and then is most likeley too late.
20141116 00:00:51< iceiceice> gfgtdf: yes, its not for the clients
20141116 00:00:53< gfgtdf> iceiceice: since we need correct controller information during presteart events
20141116 00:01:08< iceiceice> the history is only important to be read by (1) observers (2) anyone who watches server replay
20141116 00:01:16< gfgtdf> iceiceice: but same is true for bservers
20141116 00:01:20< gfgtdf> observers*
20141116 00:01:27< iceiceice> not for observers that join the game late
20141116 00:01:41< iceiceice> for observers that joint he game while its in mp connect, the history is not important
20141116 00:01:48< iceiceice> but for observer who clicks on game in lobby after it started,
20141116 00:01:49< gfgtdf> iceiceice: for other neigher
20141116 00:01:55< iceiceice> the server will send him the level_
20141116 00:02:00< gfgtdf> iceiceice: the others also doesnt read hsitory before prestaert event
20141116 00:02:28< iceiceice> he will get the [multiplayer] tag from level_
20141116 00:02:43< gfgtdf> iceiceice: is they dont have correct controller data in prestart it doesnt help
20141116 00:03:02< iceiceice> if you don't adjust the level_ at some point,
20141116 00:03:10< iceiceice> then when an observer joins he will get the exact same level as was generated by host
20141116 00:03:17< iceiceice> which will list sides local to host as "human"
20141116 00:03:21< iceiceice> and to clients as "network"
20141116 00:03:24< iceiceice> so it will be broken
20141116 00:03:31< gfgtdf> iceiceice: but then the controller_tewaks in teh histry will do justnnithign
20141116 00:03:47< iceiceice> no,
20141116 00:03:57-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has quit [Ping timeout: 272 seconds]
20141116 00:04:23< iceiceice> the way it currently works, after the game start the level_ is supposed to reflect starting_pos appropriate for an observer
20141116 00:04:28< gfgtdf> iceiceice: yes
20141116 00:04:35< iceiceice> so its suppose dto reflect exactly which controller ids had which sides,
20141116 00:04:42< gfgtdf> iceiceice: but why do we store teh controller wteaks in the hstory then =
20141116 00:04:44< iceiceice> and shoudl have netowrk or network_ai as approrarte
20141116 00:04:48< gfgtdf> ?*
20141116 00:04:52< iceiceice> because, the controllers might have changed....
20141116 00:05:00< iceiceice> and the observer that joins needs to be up-todate
20141116 00:05:02< iceiceice> or its out of sync
20141116 00:05:16< gfgtdf> iceiceice: i mena the data of preform_controller_tweaks in teh history not controllerchanges durign teh game.
20141116 00:05:22< iceiceice> yes, i mean that too
20141116 00:05:29< iceiceice> oh
20141116 00:05:56< iceiceice> well perform_controller_tweaks surely results in some redundant messages
20141116 00:06:01< iceiceice> for instance why does it send anything to the host
20141116 00:06:14< iceiceice> but it doesn't hurt anything
20141116 00:06:25< iceiceice> where do you think there is OOS?
20141116 00:06:35< gfgtdf> iceiceice: in teh current implementasion you eman ?
20141116 00:06:58< gfgtdf> iceiceice: when we advance to a next scenario and have an observer joun with mp stuff in prestart events.
20141116 00:07:04< gfgtdf> my sync stuff
20141116 00:08:25< iceiceice> what does it have to do with putting controller tweaks in the history?
20141116 00:08:26< gfgtdf> iceiceice: becasue teh load_next_scenario might change level_
20141116 00:09:14< gfgtdf> iceiceice: it doenst directly, but i still say putting controller changes, made by perform_controller_tweaks(), in teh history doesnt help us in any situation
20141116 00:09:48< iceiceice> i just don't want to write more duplicate code than there already is
20141116 00:09:58< iceiceice> you are saying you want some versino of this line that doesn't affect the history?
20141116 00:09:59< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/server/game.cpp#L207
20141116 00:10:43< iceiceice> gfgtdf: maybe a different way is,
20141116 00:10:50< iceiceice> never make changes to level_ from what host sends
20141116 00:10:57< iceiceice> and rely on those messages to correct it
20141116 00:11:15< gfgtdf> iceiceice: you mean not aplying [scenario_diff] ?
20141116 00:11:39< iceiceice> i mean deleting this block: https://github.com/wesnoth/wesnoth/blob/master/src/server/game.cpp#L209
20141116 00:12:06< iceiceice> i mean since there is the change_controller, and that makes records in the history, it should actually be okay i guess
20141116 00:12:29< gfgtdf> iceiceice: what im saying is exactly taht is not ok
20141116 00:12:41< iceiceice> why not?
20141116 00:13:09< gfgtdf> iceiceice: things taht we recive during the actualy game are applied after prestart, but we want thsoe changes before prestart
20141116 00:13:36< gfgtdf> iceiceice: since teh y reflect the initial controller values
20141116 00:13:42< iceiceice> hmmm
20141116 00:13:58< iceiceice> can that be changed?
20141116 00:13:58< gfgtdf> iceiceice: anyn having correct controller information in prestart events is vital for ms sync
20141116 00:14:13< iceiceice> why doesnt the client process network info for prestart also?
20141116 00:14:14< gfgtdf> iceiceice: you mean readin those before prestart ?
20141116 00:15:15< iceiceice> i guess it won't help either if there is lua stuff in preload
20141116 00:15:20< gfgtdf> iceiceice: i think simething like "if(have_data_from_network) { applly_data_from_network() }   ..  fire prestart()" is too dangerous since it migth happpen that we dodnt receive teh data YET due to lags
20141116 00:15:32< iceiceice> i see
20141116 00:16:01< gfgtdf> iceiceice: i really thign we need to apply add those data in the mp_wait/mp_connect state
20141116 00:16:17< iceiceice> yeah that would be easiest thing
20141116 00:16:25< gfgtdf> iceiceice: thsi is esepcaiyl true for scewnario transitions
20141116 00:16:27< iceiceice> either that or server needs to collect all this stuff and keep track of it
20141116 00:16:28< gfgtdf> scenario*
20141116 00:17:27< iceiceice> yeah i agree, i think maybe mp connect should do this
20141116 00:22:08< gfgtdf> iceiceice: i think the host also sends [start_game] for scenario transitation for teh next scenario ?
20141116 00:22:31< gfgtdf> iceiceice: maybe we can put teh correct controller for that player into [start_game].
20141116 00:22:45< gfgtdf> iceiceice: the thing that is sended by teh server i mean
20141116 00:23:57< gfgtdf> iceiceice: and then teh host also waits for [start_game] after he sended teh stert signal to teh server
20141116 00:26:11< iceiceice> yeah its not a bad idea
20141116 00:29:13< gfgtdf> iceiceice: also
20141116 00:30:28< iceiceice> gfgtdf: i think the only reasons to do things server side are (1) the server has all the connections so some stuff is easier to see there (2) if somehow mp gets broken, we can still patch the server but not the clients
20141116 00:30:29< gfgtdf> iceiceice: we currently update the controller data in load_next_scenario with the CURRENT controller data from sides_, side_controllers_, better woudl be if we gave then teh data how it was when thw scenario begun i'd think.
20141116 00:31:06< iceiceice> hmmm
20141116 00:31:33< iceiceice> so if A and B are playing and C is watching,
20141116 00:31:38< iceiceice> but then half way through B watches and C plays,
20141116 00:31:50< iceiceice> then when they go ot the next scenario B will be player and C will be observer?
20141116 00:33:15< gfgtdf> iceiceice: i think they but i think that becasue the code that assigns users to sides at scenario transition might forget controller changes durign teh game in mp_connect.cpp but im not sure
20141116 00:34:18< iceiceice> gfgtdf: i think the server should not really attempt to figure it out...
20141116 00:34:29< iceiceice> i would be much happier if, when the server gets 'next sceanrio" from host
20141116 00:34:29< gfgtdf> iceiceice: yes it currently one by te client i thin
20141116 00:34:31< iceiceice> it makes a new game
20141116 00:34:41< iceiceice> and holds onto a pointer to it
20141116 00:35:32< gfgtdf> iceiceice: so then the player that is still in the previous scenario locally is then in the old game or teh new ?
20141116 00:35:49< iceiceice> the server will think they are in the old game
20141116 00:35:55< iceiceice> and when they want to proceed with campaign,
20141116 00:36:02< iceiceice> the server sends them the gameid of the next game
20141116 00:36:47< gfgtdf> iceiceice: hmm but who controlled teh side that was assigne ot player B (non host) in teh new game while B is in teh odl scenario ?
20141116 00:37:09-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20141116 00:37:11< iceiceice> i think it should be marked "Reserved" in the server or something
20141116 00:37:28< iceiceice> and if they join, then it sends them the level and all the history they missed
20141116 00:37:39< iceiceice> or if they DC and never join,
20141116 00:37:47< iceiceice> it will just stay that way until the host reassigns
20141116 00:38:55< gfgtdf> iceiceice: you yyou want to allow "reserved" during the game ?
20141116 00:39:14< iceiceice> maybe it shold be called "lingering"
20141116 00:39:39< gfgtdf> iceiceice: maybe this shoel one player on one scenario another player ina another is just too cpmpülicated
20141116 00:39:53< gfgtdf> iceiceice: and we shodul only let teh player proceed to next scenario all together
20141116 00:40:22< iceiceice> hmm so a way that we could do that is,
20141116 00:40:33< iceiceice> when the host is ready, he goes to mp connect mode or whatever
20141116 00:40:43< iceiceice> but on the server side, he is thought of as in a new game
20141116 00:40:48< iceiceice> and the new record for that game has been created
20141116 00:40:52< iceiceice> but it cannot start
20141116 00:40:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20141116 00:40:58< iceiceice> until everyone has stopped lingering
20141116 00:41:56< gfgtdf> note taht even currently the linger mode end of other player if it end for host
20141116 00:42:24< iceiceice> y but i think it should work like it does in SP
20141116 00:42:38< gfgtdf> iceiceice: but for example the other cleints can spend their time in the "do you really want to overwrite the 'LoW_The Uprooting replay.gz file?" question
20141116 00:43:01< gfgtdf> clients*
20141116 00:43:04< iceiceice> y, so thats why i propose that the server allow the game to start without them
20141116 00:43:17< iceiceice> another option if you want to make it all client side,
20141116 00:43:21< iceiceice> if the host knows that a player is lingering,
20141116 00:43:30< iceiceice> hmm..
20141116 00:44:21< iceiceice> gfgtdf: i think conceptually it should be simpler if different game is a different room
20141116 00:44:26-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Bye for now]
20141116 00:44:39< iceiceice> i don't like that the game object has so much functions, it should be simple from server point of view
20141116 00:45:00< iceiceice> its not even clear to me that the server needs to have a concept of "campaign"
20141116 00:45:33< iceiceice> but... that is far from what we have right now
20141116 00:45:55< iceiceice> i guess if you want to allow clients to linger, it might be easier for the server to have no idea
20141116 00:46:04< iceiceice> and all the details of that to be handled on client side
20141116 00:46:37< gfgtdf> iceiceice: i personaly just dont know wheter teh "procedd to next scneario immidietely without mp_connect screen between" is a very important featuire or not
20141116 00:46:49< gfgtdf> iceiceice: it sure makes mp sync quiet harder
20141116 00:47:48< iceiceice> i think its good, it will make some add-ons quite awkward if you force these screens all the time
20141116 00:48:07< iceiceice> but i dont think it should be a big deal, couldn't we just have everyone run that code without showing the screens
20141116 00:48:53< iceiceice> what i'm imaginging i guess for linger mode is, if the server says a new level is available,
20141116 00:49:00< gfgtdf> iceiceice: so just a "waitign of other players, please be patient" instead of teh option to change the controllers?
20141116 00:49:12< iceiceice> we make a buffer where all the information will go, and we keep it there until we stop lingering
20141116 00:49:22< iceiceice> i guess we want to sift through for the chat messages maybe
20141116 00:49:58< iceiceice> idk i think it would be much simpler if there's just two different game objects on server
20141116 00:51:39< iceiceice> gfgtdf: what happens right now if we are playing but i bring up a menu
20141116 00:51:42< iceiceice> and then you transition to the next server
20141116 00:51:44< iceiceice> *next game
20141116 00:51:59< iceiceice> i mean basically it works right?
20141116 00:52:10< iceiceice> for the host, he thinks i am in game and everything is fine,
20141116 00:52:13< iceiceice> i am just unresponsive
20141116 00:52:21< gfgtdf> iceiceice: yes
20141116 00:52:31< iceiceice> for the client, i don't process anything but when i get the menu down, then i figure it all out and i am caught up
20141116 00:52:37< iceiceice> and the replay looks as though i controlled it all from the start
20141116 00:53:00< iceiceice> so there should be some way to make a client linger mode that works like that
20141116 00:53:11< iceiceice> but isnt based on blocking stuff with menu
20141116 00:53:46< iceiceice> i guess the only thing thats different is, the people in linger mode probably should be able to chat
20141116 00:55:53< gfgtdf> iceiceice: currently the clients want to go the next scenario if teh hosts clicks teh button
20141116 00:56:27< iceiceice> y we don't allow them to have linger mode
20141116 00:57:59< iceiceice> i remember when we changed this like a year ago
20141116 00:58:18< iceiceice> because fixing other bugs was more important than making some linger mode stuff work
20141116 01:05:24< gfgtdf> iceiceice: maybe we could have somethign like "mo_connect/wait" run in the backgroudn while the linger mode is there
20141116 01:05:40< gfgtdf> iceiceice: thats not trivial to implement though i think
20141116 01:06:21< gfgtdf> iceiceice: but for teh user thats most likeley the prettiest.
20141116 01:06:40< iceiceice> hmm so
20141116 01:06:45< iceiceice> why can't the user just buffer all the input
20141116 01:06:57< iceiceice> and then when they stop lingering put it on the real buffer
20141116 01:07:10< iceiceice> so they will fly through mp connect (maybe we have some option to skip the graphics)
20141116 01:07:31< iceiceice> s/the user/the client
20141116 01:11:07< gfgtdf> iceiceice: but teh current versoiesnt doesnt working really well eigher
20141116 01:11:24< gfgtdf> iceiceice: especiayl teh load_next_scenario function
20141116 01:11:43< iceiceice> yeah, i think these are two separate fixes really
20141116 01:12:40< iceiceice> i think even if linger mode is not involved its probably better to make a new game object for the next part of campaign
20141116 01:13:28-!- EliDupree [~quassel@66-189-34-122.dhcp.oxfr.ma.charter.com] has quit [Ping timeout: 255 seconds]
20141116 01:13:39< gfgtdf> iceiceice: no i don't think they are seperate the lingermode could make fixing the other significatly harder
20141116 01:14:01-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141116 01:15:00-!- EliDupree [~quassel@66-189-34-122.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20141116 01:15:01< gfgtdf> iceiceice: and i'd appreciate to drop the "sides advance the the next scenario one after another" feature. 
20141116 01:15:25< gfgtdf> iceiceice: we coudl maybe do it like  "end linger mode when everyone is ok with that"
20141116 01:16:15< iceiceice> gfgtdf
20141116 01:16:33< iceiceice> well i dont know who else is using the "fast next scenario" behavior
20141116 01:16:42< iceiceice> i can tell you right now it will make RBY alot more cumbersome
20141116 01:17:01< iceiceice> the "random map pool"
20141116 01:17:21< gfgtdf> iceiceice: what is RBY ?
20141116 01:17:27< iceiceice> it has always been implemented as a trick with mp campaign, where there is a random scenario picker
20141116 01:17:53< iceiceice> RBY is the the mp ladder map pool add-on, which I maintain
20141116 01:18:25< gfgtdf> iceiceice: does is require download for clients ?
20141116 01:18:28< iceiceice> no
20141116 01:19:17< iceiceice> the way it works is, it makes a random number with math.random in prestart, and chooses a map from the list, shuffles the sides itself, then ends the scenario during prestart
20141116 01:19:36< iceiceice> and everyone transitions immediately to the next level
20141116 01:19:55< iceiceice> if anyone has some short sequence like this, its going to be more cumbersome if we have to wait for all the players
20141116 01:20:06< iceiceice> idk if you are playing an mp campaign, and there is just some talk sequence for a minute
20141116 01:20:20< iceiceice> if you have to have all the players go to mp connect gui before and after this,
20141116 01:20:27< iceiceice> idk i don't see why it should be necessary
20141116 01:21:27-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141116 01:21:43< gfgtdf> iceiceice: so use linger__mode = no, pre_screario_save = no .. ?
20141116 01:21:54< iceiceice> yes
20141116 01:22:25< iceiceice>         linger_mode=false
20141116 01:22:25< iceiceice>         save=no
20141116 01:22:25< iceiceice>         replay_save=no
20141116 01:23:54< gfgtdf> iceiceice: but i stil ldont see why you rely on teh "players advance to next scenario one after anothe" feature.
20141116 01:24:12< gfgtdf> where*
20141116 01:24:14< iceiceice> hmm maybe i dont understand what you mean
20141116 01:26:19-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 264 seconds]
20141116 01:27:51< gfgtdf> iceiceice: all i want is to not allow having one player in the the old scenario whe teh new scenario already started
20141116 01:28:12< gfgtdf> iceiceice: i think there are mutple option what we can display at cleintisde
20141116 01:28:22< gfgtdf> iceiceice: another quetion:
20141116 01:29:22< gfgtdf> iceiceice: if you have [endlevel] with linger_mode = no, replay_save = yes durng a prestart event, what do you see in the background during the "do you really want to overwrtite the file" messsagebox ?
20141116 01:29:37< iceiceice> just blackness
20141116 01:30:06< gfgtdf> iceiceice: hm ok
20141116 01:31:55< iceiceice> gfgtdf: yeah i guess no one needs the linger mode to work most likely
20141116 01:32:03< iceiceice> what does it break in sync code though?
20141116 01:32:32< iceiceice> it's important for sync that all the clients are responsive?
20141116 01:32:33< Ravana_> is there need for advance there?
20141116 01:33:47< gfgtdf> iceiceice: not really only if you want sonthign from the side e.g its that sides turn or you use get_global_variabel from that side
20141116 01:34:28< gfgtdf> iceiceice: for example if you use get_global_variable during a prestart event and teh side is not responsive you are stuck with a back screen, while teh clients waits for that side got tell you teh global variable
20141116 01:34:49< gfgtdf> iceiceice: any most likeley that game will crash as soon as you alick n that back screen
20141116 01:34:55< gfgtdf> clik*
20141116 01:37:12< iceiceice> gfgtdf: i din't realize that persistant variables could be gotten from a side
20141116 01:37:19< iceiceice> i thought it would always just be the host
20141116 01:38:13< iceiceice> i see it now in the wiki
20141116 01:43:54< gfgtdf> iceiceice: no it never teh host 
20141116 01:44:01< gfgtdf> iceiceice: meaning the defautl is not teh host
20141116 01:44:20< gfgtdf> iceiceice: the default the current active side
20141116 01:44:45< gfgtdf> iceiceice: actuayl get_global_variable is quiet cool
20141116 01:45:41< gfgtdf> iceiceice: you can use it to make hacks to show dialogs to players when its not their thrn and make teh gamestate depend on then without getting any problems.
20141116 01:46:57< gfgtdf> iceiceice: obvioudlsy youc annot make such dialogs durign prestart events
20141116 01:46:59< gfgtdf> you*
20141116 01:47:28< iceiceice> i didnt know this
20141116 01:47:38< shadowm> In single-player I can run Lua GUI2 dialogs in prestart and preload.
20141116 01:47:55< gfgtdf> shadowm: accorign to the wiki you shouldnt
20141116 01:48:07< shadowm> Link?
20141116 01:50:08< gfgtdf> shadowm: http://wiki.wesnoth.org/index.php?title=EventWML
20141116 01:50:57< shadowm> "UI things don't work during prestart events" Overly broad false statement.
20141116 01:51:29< gfgtdf> shadowm: "For things displayed on-screen such as character dialog, use start instead. "
20141116 01:51:44< shadowm> No explanation given.
20141116 01:52:05< iceiceice> idk maybe ask whoever wrote it
20141116 01:52:22< shadowm> I do know of a related bug that was fixed.
20141116 01:53:36< shadowm> https://gna.org/bugs/index.php?12962
20141116 01:56:00< shadowm> Looking forward, I'd consider it bad form (as in bad UX) to display a GUI dialog in the middle of processing preload and prestart, but it shouldn't crash the game or cause unexpected behavior.
20141116 01:59:17< iceiceice> shadowm: it sounds like it coudl unavoidably cause probelms in mp
20141116 01:59:37< iceiceice> because... the engine is single threaded
20141116 02:00:08< iceiceice> its hard to see why it could break things in sp
20141116 02:00:13-!- ToBeCloud [uid51591@gateway/web/irccloud.com/x-pbupezfqvqizdxmf] has joined #wesnoth-dev
20141116 02:00:24< iceiceice> but at the same time the engine does a lot of stupid things
20141116 02:00:32< shadowm> Isn't the network transmission thread running at that point already?
20141116 02:00:50< iceiceice> i really don't know,
20141116 02:01:05< iceiceice> i think that for such questions there is a world of difference beteween prestart and preload though
20141116 02:02:35< shadowm> Meh. I don't really care about MP as long as SP isn't meddled with.
20141116 02:06:58< gfgtdf> iceiceice: i just tested what i said earlier
20141116 02:07:13< gfgtdf> iceiceice: about mp sync in prestaert and client not reacting
20141116 02:07:21< gfgtdf> iceiceice: it better than i thought
20141116 02:07:59< gfgtdf> iceiceice: the whoile window gets greyed out becasue the window doesnt answer and ou'd think it had crashed
20141116 02:08:05< gfgtdf> iceiceice: but it didnt :)
20141116 02:08:28< gfgtdf> iceiceice: as soon as the other side commits it data teh game continued
20141116 02:08:42< gfgtdf> s/ou'd/you'd
20141116 02:09:01< iceiceice> i see, that is good
20141116 02:09:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20141116 02:23:24-!- gfgtdf [~chatzilla@d148144.adsl.hansenet.de] has quit [Read error: Connection reset by peer]
20141116 02:27:06-!- gfgtdf [~chatzilla@d148144.adsl.hansenet.de] has joined #wesnoth-dev
20141116 02:29:13< gfgtdf> iceiceice: you see a rason against merging dontlimit serversides if i tested that it works with a 10 player sccenario ?
20141116 02:29:25< iceiceice> no
20141116 02:37:35-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141116 02:46:09-!- ancestral [~ancestral@166.170.21.8] has joined #wesnoth-dev
20141116 02:50:54-!- ancestral [~ancestral@166.170.21.8] has quit [Read error: Connection reset by peer]
20141116 02:51:13-!- ancestral [~ancestral@166.170.21.8] has joined #wesnoth-dev
20141116 02:58:07< gfgtdf> iceiceice: besides that i mamanged to loose with 10 human sides against 2 ai sides ... it worked all well.
20141116 02:58:52< iceiceice> i decided to rewrite the RBY era code in lua
20141116 02:58:58< iceiceice> and it seems to be working now,
20141116 02:59:06< iceiceice> but i have wierd bugs where fog is disabled randomly sometimes
20141116 02:59:32< gfgtdf> iceiceice: you you also miantain teh scenario or just teh ere that loads them ?
20141116 02:59:49< iceiceice> there are copies of hte scenarios in the add-on
20141116 03:00:18< gfgtdf> iceiceice: does you era more then selecing a rnsom scenario in the perstaer event ?
20141116 03:00:29< iceiceice> y
20141116 03:00:34-!- ancestral [~ancestral@166.170.21.8] has quit [Quit: Smell ya later!]
20141116 03:00:40< iceiceice> rby has a "no mirror era"
20141116 03:01:04< iceiceice> its supposed to work so that two players choose random sides but they don't get a mirror
20141116 03:01:21< iceiceice> also, one or both of them may choose a faction, and the other random, and there still should not be a mirror
20141116 03:02:20< iceiceice> actually i am thinking to change it to a modification, but i have to get the basic part working again
20141116 03:02:35< gfgtdf> iceiceice: how does npo mirror work ?
20141116 03:02:49< iceiceice> in 1.10 it works by making a new era
20141116 03:02:54< iceiceice> where random side is replaced by "rby random side"
20141116 03:03:00< iceiceice> which has only yeti as leader
20141116 03:03:10< iceiceice> and the era event detects the yetis
20141116 03:03:15-!- Ivanovic_ [~ivanovic@frnk-5f74d667.pool.mediaWays.net] has joined #wesnoth-dev
20141116 03:03:36< iceiceice> in 1.12 i cant do taht if it is a modification,
20141116 03:04:24< iceiceice> i think there might be a trick i can use, not sure if it will work yet
20141116 03:04:40< iceiceice> it might still have to be an era for now
20141116 03:06:06-!- ancestral [~ancestral@166.170.21.8] has joined #wesnoth-dev
20141116 03:06:58-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 256 seconds]
20141116 03:07:09-!- Ivanovic_ is now known as Ivanovic
20141116 03:10:13-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141116 03:12:29-!- ancestral [~ancestral@166.170.21.8] has quit [Ping timeout: 264 seconds]
20141116 03:12:46< gfgtdf> iceiceice: which trick
20141116 03:13:43< gfgtdf> iceiceice: can you split the "random mpa selection part" from the "random side detation part" ?
20141116 03:15:02-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 255 seconds]
20141116 03:15:30< iceiceice> gfgtdf: those parts are separate,
20141116 03:15:38< iceiceice> the random map selection part is in a scenario
20141116 03:15:47< iceiceice> the yeti replace event is in the era
20141116 03:15:57< iceiceice> you dont have to use the map pool with the era
20141116 03:20:23-!- happygrue [~Laptop@wesnoth/developer/wintermute] has joined #wesnoth-dev
20141116 03:22:08< gfgtdf> iceiceice: so yich one do you ant to translate to lua ?
20141116 03:22:19< gfgtdf> iceiceice: to a miodification
20141116 03:22:28< iceiceice> the replacement
20141116 03:22:35< iceiceice> the rerandomizing
20141116 03:23:16< iceiceice> because, apparently i made a bug in it 1 or 2 versions ago and didn't notice
20141116 03:23:20< iceiceice> by deleting a $ by accident
20141116 03:23:35< iceiceice> also i assumed that {LOOKUP_INDEX} works a certain way, that it actully doesnt
20141116 03:23:48< gfgtdf> iceiceice: LOOKUP_INDEX is your won macro ?
20141116 03:23:51< gfgtdf> own*
20141116 03:23:51< iceiceice> no its core
20141116 03:24:52< gfgtdf> iceiceice: i tink translatin into lua it a good option
20141116 03:25:09< iceiceice> y, this is what i have right now: https://gist.github.com/cbeck88/f3fab57dc45ed88a2a0c
20141116 03:27:00< gfgtdf> iceiceice: where is the factions variable initilized ?
20141116 03:27:18-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141116 03:27:46< iceiceice> https://gist.github.com/cbeck88/c466eb64621ed01d42b7
20141116 03:28:52< gfgtdf> iceiceice: you are suing math.random
20141116 03:29:08< gfgtdf> iceiceice: doesnt taht give you OOS ?
20141116 03:29:08< iceiceice> y
20141116 03:29:13< iceiceice> technically yes,
20141116 03:29:19< iceiceice> but because it ends in prestart it doesnt matter
20141116 03:29:28< iceiceice> and no one wants to save the replay of that scenario anyways
20141116 03:29:56< gfgtdf> iceiceice: so what the non host get doesnt matter
20141116 03:30:02< iceiceice> y
20141116 03:31:25< iceiceice> i did not invent that technique, i think probably it was used in wesnoth 1.8 even
20141116 03:31:33< iceiceice> for these random map pools
20141116 03:35:19-!- shadowm_desktop2 [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 264 seconds]
20141116 03:35:24-!- happygrue [~Laptop@wesnoth/developer/wintermute] has quit [Remote host closed the connection]
20141116 03:36:39-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141116 03:46:07-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 244 seconds]
20141116 03:48:40-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141116 03:48:41-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141116 03:51:06< gfgtdf> shadowm: do you have an opinion on https://github.com/wesnoth/wesnoth/pull/333 ?
20141116 03:55:35-!- gfgtdf [~chatzilla@d148144.adsl.hansenet.de] has quit [Quit: ChatZilla 0.9.91 [Firefox 33.1/20141106120505]]
20141116 03:56:49-!- gfgtdf [~chatzilla@d148144.adsl.hansenet.de] has joined #wesnoth-dev
20141116 03:56:52< gfgtdf> iceiceice: 
20141116 03:57:16< gfgtdf> iceiceice: i also think the "wrong names in status tabel might be related to teh controller tweaks"
20141116 03:57:51< iceiceice> maybe
20141116 03:57:57< gfgtdf> iceiceice: becasue we update "current_player" to the hosts name when we receive a [change_controller] durign teh game
20141116 03:58:04< gfgtdf> iceiceice: i actual think it'
20141116 03:58:20< gfgtdf> s s uiet hard to figure out when we have to change it and when not
20141116 03:58:44< gfgtdf> iceiceice: esepciayl if it's possible that human sided gets drioded and the opposite
20141116 04:08:23< shadowm> gfgtdf: Not really, because I don't know the original rationale for the server-side limit and can only speculate.
20141116 04:10:23-!- gfgtdf_ [~chatzilla@d148144.adsl.hansenet.de] has joined #wesnoth-dev
20141116 04:11:52-!- gfgtdf [~chatzilla@d148144.adsl.hansenet.de] has quit [Ping timeout: 240 seconds]
20141116 04:12:03-!- gfgtdf_ is now known as gfgtdf
20141116 04:12:44-!- gfgtdf [~chatzilla@d148144.adsl.hansenet.de] has quit [Client Quit]
20141116 04:27:50-!- ToBeCloud [uid51591@gateway/web/irccloud.com/x-pbupezfqvqizdxmf] has quit [Quit: Connection closed for inactivity]
20141116 04:38:47< iceiceice> hmmm....
20141116 04:39:05< iceiceice> i think someone didn't understand about gettext: https://github.com/wesnoth/wesnoth/blob/113c8d8504cc0432b4ba063ae076e9a0107477d3/src/game_initialization/multiplayer_connect.cpp#L56
20141116 04:41:23< iceiceice> hmm so wait,
20141116 04:41:31< iceiceice> are we allowed to push gettext fixes to 1.12 now?
20141116 04:41:59< iceiceice> is there a point to do that, or will 1.12.x not be recieving new translations?
20141116 05:14:57-!- oldlaptop [~quassel@50-108-67-218.adr01.mskg.mi.frontiernet.net] has quit [Ping timeout: 240 seconds]
20141116 05:18:20-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Quit: tomreyn]
20141116 05:27:28-!- oldlaptop [~quassel@50-108-67-218.adr01.mskg.mi.frontiernet.net] has joined #wesnoth-dev
20141116 06:00:00-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141116 06:16:40-!- kex [~kex@78.157.29.160] has quit [Remote host closed the connection]
20141116 06:37:09-!- fkhodkov [~user@2a01:d0:ffff:10ea::2] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
20141116 06:55:26-!- Sulfur [~Miranda@p5B00888C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141116 07:42:53-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20141116 07:44:03< Rhonda> iceiceice: Yes, of course it's allowed to work on translations in the 1.12 branch.
20141116 07:46:12< Rhonda> iceiceice: And yes, it looks strange to allow translation of () and +, but some languages might use other signs than the ascii ones for that.  Then though it might make sense to also allow to postfix the income with the + character and not only prefix depending on the translation, if one goes to that troubles already.
20141116 07:47:53-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Ping timeout: 264 seconds]
20141116 07:50:17-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 264 seconds]
20141116 07:53:39-!- cib0 [~cib@p5DC75847.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141116 08:05:07-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141116 08:10:14-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 265 seconds]
20141116 08:21:24-!- ryao_ [~ryao@smtp.gentoo.org] has quit [Changing host]
20141116 08:21:24-!- ryao_ [~ryao@gentoo/developer/ryao] has joined #wesnoth-dev
20141116 08:22:12-!- Ivanovic [~ivanovic@frnk-5f74d667.pool.mediaWays.net] has quit [Changing host]
20141116 08:22:12-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20141116 08:24:10-!- Ivanovic changed the topic of #wesnoth-dev to: 1.12.0 tagged, announcing Sat 22nd Nov or Sun 23rd Nov | Logs: http://irclogs.wesnoth.org | Alternate logs (down): http://wesnoth.debian.net
20141116 08:26:13-!- Ivanovic changed the topic of #wesnoth-dev to: 1.12.0 tagged, announcing Sat 22nd Nov or Sun 23rd Nov | hard string+feature freeze active on 1.12 until announcement posted |  Logs: http://irclogs.wesnoth.org | Alternate logs (down): http://wesnoth.debian.net
20141116 08:52:36-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141116 08:53:16-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141116 08:58:42-!- cib0 [~cib@p5DC75847.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20141116 09:24:06-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20141116 09:28:03-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20141116 09:33:43-!- thunderstruck [~thunderst@cpc8-sgyl29-2-0-cust37.sgyl.cable.virginm.net] has joined #wesnoth-dev
20141116 09:37:57-!- mjs-de [~mjs-de@f048067162.adsl.alicedsl.de] has joined #wesnoth-dev
20141116 09:50:52-!- irker334 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20141116 09:54:11-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141116 09:58:56-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 256 seconds]
20141116 10:06:44-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141116 10:07:17-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Client Quit]
20141116 11:20:13-!- ryao_ is now known as ryao
20141116 11:20:55-!- Anakonda [Anakonda@87-92-152-95.bb.dnainternet.fi] has joined #wesnoth-dev
20141116 11:28:21-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has joined #wesnoth-dev
20141116 11:42:56-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141116 11:48:13-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 272 seconds]
20141116 12:02:31-!- LAZA74 [~LAZA@p5B16B642.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141116 12:02:34-!- cib0 [~cib@p5DC75847.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141116 12:04:49< LAZA74> new bug/problem in 1.11.19
20141116 12:05:52< LAZA74> settings - misc --> window is beyond the scope/frame
20141116 12:06:26< zookeeper> what is "settings - misc"?
20141116 12:07:05< LAZA74> sorry: Preferences - Advanced --> seems to hit only if the language is German
20141116 12:07:27< zookeeper> ok, advanced
20141116 12:07:48< LAZA74> "Frist für Chat-Nachrichten"  = time for chat messages
20141116 12:08:43< zookeeper> oh, indeed it's messed up in german
20141116 12:09:11< zookeeper> same with the second-to-last preference
20141116 12:09:17< LAZA74> so it ist know? or should i open up a bug report?
20141116 12:11:48-!- LAZA74 [~LAZA@p5B16B642.dip0.t-ipconnect.de] has quit [Quit: Verlassend]
20141116 12:12:40-!- LAZA74 [~LAZA@p5B16B642.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141116 12:13:08< Ivanovic> LAZA74: fixed for 1.12.0
20141116 12:13:23< LAZA74> thanks, Ivanovic - but i got 2 more
20141116 12:14:02< LAZA74> 1. starting the game in Windows 7 + 8 + 8.1 gives a difference between
20141116 12:14:24< LAZA74> - start from Desktop (icon created) or
20141116 12:14:54< LAZA74> - start from menu list/desktop menu in Windows 8
20141116 12:15:27< LAZA74> if i star one of the and change some settings and start then by another way the game the settings are not there
20141116 12:15:52< LAZA74> i think this is an older problem and still in 1.11.x
20141116 12:17:48-!- cib [~cib@p5DC75847.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141116 12:18:11-!- cib is now known as Guest21500
20141116 12:18:11< Ivanovic> no idea what that is, probably some "interesting" windows quirk in how/where it stores content which you try to write somewhere
20141116 12:18:20-!- Guest21500 [~cib@p5DC75847.dip0.t-ipconnect.de] has quit [Client Quit]
20141116 12:18:33< Ivanovic> please report this one under bugs.wesnoth.org
20141116 12:19:00< Ivanovic> so that loonycyborg (our packager for windows who does not make use of that OS) or someone developing under windows might see and fix it
20141116 12:19:33< LAZA74> okay and second one i just found on the website
20141116 12:19:38< LAZA74> http://wiki.wesnoth.org/UsefulLinks
20141116 12:19:54< LAZA74> Topic "Other Links"
20141116 12:19:56< LAZA74> Run Wesnoth online (Windows)      http://spoon.net/the-battle-for-wesnoth
20141116 12:20:13< LAZA74> this Link gives "Sorry, we can't seem to find the page you're looking for.
20141116 12:20:13< LAZA74> You might be looking for //turbo.net/the-battle-for-wesnoth"
20141116 12:20:29< LAZA74> and this site is working
20141116 12:20:33< Ivanovic> really no idea
20141116 12:20:40< Ivanovic> if that site is working, feel free to edit the website and fix the link
20141116 12:20:47< Ivanovic> this is a wiki and contributions are welcome!
20141116 12:20:49< Ivanovic> :)
20141116 12:20:58< LAZA74> can i do this with my log in from the forum?
20141116 12:21:06< Ivanovic> sadly not
20141116 12:21:21< Ivanovic> we don't have a syncronization between our mediawiki and the phpbb forums
20141116 12:21:37< Ivanovic> no idea if/how that is possible or if it would make sense to allow this from a secutiry perspective
20141116 12:21:52< LAZA74> so it would be nice somebody with an working login just can fix this for me
20141116 12:24:53-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141116 12:26:22< shadowm> vultraz: ^
20141116 12:27:38< shadowm> LAZA74: Make sure to use the same command line from the menu shortcut  for any shortcuts you manually create.
20141116 12:27:46< shadowm> And no, that's not a bug.
20141116 12:29:05< LAZA74> okay, so in Windows 8 and 8.1 the "App" icon is created by the installer
20141116 12:29:55< LAZA74> Target is: "C:\Program Files\Battle for Wesnoth 1.11.19\wesnoth.exe" --config-dir Wesnoth1.11
20141116 12:29:59< shadowm> Yes, and it uses a specific command line for the user data and preferences path depending on your choices when installing.
20141116 12:30:16< shadowm> Do also note the initial working path in the properties.
20141116 12:30:25< LAZA74> okay, i see
20141116 12:31:39< LAZA74> and cause there is no icon created on the Desktop this differs if somebody creates on by just searching for the path in C:\Programs\
20141116 12:32:26< shadowm> Software developers are discouraged from littering the desktop with shortcuts nowadays IIRC.
20141116 12:32:58< LAZA74> so my question is: is there an easy possibility to add an option in the installer to ask "if an deskto icon should created" = so the options would be the same?
20141116 12:33:03< LAZA74> ahh, i see
20141116 12:33:22< shadowm> loonycyborg would know for sure if that's an option since he's in charge of building the Windows package.
20141116 12:40:22< shadowm> In general, though, I doubt Wesnoth is the only application whose behavior when invoked with a clean command line (e.g. by double-clicking in explorer) is different from when invoked through a provided desktop/menu shortcut. In my experience there also tend to be a lot of internal-use-only executables for more complex software. Perhaps in our case the problem is more evident because a key configuration option (namely, where to find ...
20141116 12:40:28< shadowm> ... our configuration) is tied to shortcuts instead of, say, reading that value from the Windows registry -- but IIRC, not reading or writing anything to the registry ourselves (other than the Programs & Features control panel entry, which is the installer's responsibility and not Wesnoth's) is a conscious design decision.
20141116 12:44:29< LAZA74> imho it is a trap for all n00bs
20141116 12:45:36< LAZA74> in Win 8 cause of the new design it is not as dangerous as in Win 7 (which the most players still favour!)
20141116 12:48:25< LAZA74> but i'm *not* the one here to judge about this
20141116 12:54:07-!- Sulfur [~Miranda@p5B00888C.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20141116 13:15:59-!- Sulfur [~Miranda@p5B00888C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141116 13:26:39-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20141116 13:31:44-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141116 13:36:22-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 250 seconds]
20141116 13:36:41-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has joined #wesnoth-dev
20141116 13:43:46-!- LAZA74 [~LAZA@p5B16B642.dip0.t-ipconnect.de] has quit [Quit: Verlassend]
20141116 13:57:17-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has quit [Ping timeout: 240 seconds]
20141116 13:59:20-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Quit: downloading more RAM!]
20141116 14:00:25-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Read error: Connection reset by peer]
20141116 14:00:33-!- Grickit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20141116 14:01:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20141116 14:04:12-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has joined #wesnoth-dev
20141116 14:09:09-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20141116 14:12:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20141116 14:15:57-!- cib0 [~cib@p5DC75847.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20141116 14:15:58-!- Grickit is now known as Gambit
20141116 14:25:07-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20141116 14:44:43-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20141116 15:11:13-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 244 seconds]
20141116 15:12:58-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141116 15:15:30< vultraz> ah, hey mattsc 
20141116 15:16:52< mattsc> hi vultraz 
20141116 15:17:14< vultraz> I was wondering if these two pages could now be removed from the wiki: http://wiki.wesnoth.org/AI_Module http://wiki.wesnoth.org/Customizing_AI_in_Wesnoth_1.8
20141116 15:19:49< vultraz> And likely, this http://wiki.wesnoth.org/WritingYourOwnAI
20141116 15:20:03< mattsc> vultraz: I’m not 100% certain, but I believe there is information on these pages that is not shown anywhere else on the wiki
20141116 15:20:34-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141116 15:21:08< mattsc> So removing them would result in the loss of that information.
20141116 15:23:31< vultraz> Well, what should I do with them, then
20141116 15:24:13< mattsc> Somebody should rewrite the entire AI wiki section.
20141116 15:24:33-!- irker256 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20141116 15:24:33< irker256> wesnoth: gfgtdf wesnoth:master f6065d3da939 / src/server/ (game.cpp game.hpp server.cpp): don't limit server max sides http://git.io/a2bX0A
20141116 15:24:33< irker256> wesnoth: gfgtdf wesnoth:master 10b2c0d9beb5 / src/game_initialization/connect_engine.cpp: fix mp connect colors http://git.io/C9WICA
20141116 15:24:34< irker256> wesnoth: gfgtdf wesnoth:master a53594b2b197 / src/server/server.cpp: remove outcommented code http://git.io/Y4AkCg
20141116 15:24:35< mattsc> And no, the obvious suspect will not have time to do that any time soon.  :P
20141116 15:24:35< irker256> wesnoth: gfgtdf wesnoth:master 50d2b133ec3a / src/ (4 files in 2 dirs): Merge pull request #333 from gfgtdf/wesnothd_sides http://git.io/i9fMCg
20141116 15:25:08-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 250 seconds]
20141116 15:26:01< mattsc> I disagree with the header of that page, by the way.  The information is not obsolete.  It’s still correct, it’s just incomplete and badly organized.
20141116 15:26:15< vultraz> Even the 1.8 page?
20141116 15:26:25< mattsc> yes, especially the 1.8 page.
20141116 15:26:29< vultraz> Ah
20141116 15:26:48< mattsc> The AI itself has not changed since then, it has just seen quite a few additions.
20141116 15:27:02-!- You're now known as lobby
20141116 15:27:27< mattsc> And yes, it’s always been my itention to clean all of this up eventually, but it’s a huge job to do so and I just don’t have the time for it.  :(
20141116 15:28:13< vultraz> The whole wiki needs a cleanup
20141116 15:28:32< vultraz> I began back in April and got quite a bit done, but I haven't been working on it much recently :(
20141116 15:28:36< mattsc> Probably.  I just know the AI pages best.
20141116 15:28:47-!- happygrue [~Laptop@wesnoth/developer/wintermute] has joined #wesnoth-dev
20141116 15:29:02< mattsc> Well, anything counts.
20141116 15:29:02-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141116 15:33:46< mattsc> It’s good that somebody is working on it, even if intermittently!
20141116 15:41:25-!- gfgtdf [~chatzilla@d148144.adsl.hansenet.de] has joined #wesnoth-dev
20141116 15:41:45< vultraz> mattsc: so I should just leave those pages as-in?
20141116 15:41:47< vultraz> is*
20141116 15:42:07< mattsc> vultraz: I think for the time being that’s the best solution.
20141116 15:46:29< vultraz> ok. thanks
20141116 15:51:19-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20141116 15:54:13< zookeeper> so is there some kind of reason why the map format can only store starting locations for 9 sides? sounds like it'd be really easy to just make it allow for more, either by actually looking for more than 1 number, or maybe by using hexadecimal to bump the max to 15
20141116 15:59:10< happygrue> zookeeper: there are umc authors who would love to have more sides available, I know.  I always though there was some reason back years ago, but I can't for the life of me remember what it was
20141116 16:02:06-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has quit [Remote host closed the connection]
20141116 16:18:24< zookeeper> happygrue, well there are more sides available, you're only limited to 9 starting locations.
20141116 16:18:49< zookeeper> it's just an inconvenience that you need to specify the starting locations in WML rather than have them placed on the map, not really a limitation
20141116 16:19:07< happygrue> I see.
20141116 16:21:19< shadowm> The MP server also rejects games with more than 9 sides before gfgtdf's changes to master.
20141116 16:22:58< gfgtdf> zookeeper: i think at some point we assume < 10 characters per hex, 9 of them are used by the terrain description leaving one for the side number.
20141116 16:23:09< gfgtdf> per hey in teh map format i mena
20141116 16:23:37< gfgtdf> zookeeper: coudl be taht i only saw that in teh mapgenerator iplementation though
20141116 16:23:46< gfgtdf> random map generator*
20141116 16:25:10< gfgtdf> hrex*
20141116 16:25:15< gfgtdf> hex*
20141116 16:25:36< zookeeper> right
20141116 16:25:48< zookeeper> shadowm, really? oh, well, i guess it was a limitation then after all
20141116 16:31:17< gfgtdf> zookeeper: i tink the main limitation is still the number of colors. For exampel in in the flagicons in the editor.
20141116 16:31:40< gfgtdf> zookeeper: i wouldn't be surprised if the edtor asumes number of colors = max numer os startign positions somewhere
20141116 16:32:10< shadowm> I would, because that doesn't make sense at all.
20141116 16:32:30< shadowm> If you check the color ranges defined by mainline you'll see they are at least 18.
20141116 16:34:35< gfgtdf> shadowm: really? i think i got my main information form this comment: tho this comment: https://github.com/wesnoth/wesnoth/blob/master/src/map.hpp#L200 
20141116 16:35:52< Ravana_> in that case I suggest addition of yellow
20141116 16:36:17< gfgtdf> actualy i cannot fing teh file team_colors.cfg
20141116 16:36:18< shadowm> That information is irrelevant, the fact is that there are at least 18 color ranges and the engine doesn't check color range definitions for duplicity.
20141116 16:36:33< shadowm> data/core/team_colors.cfg
20141116 16:36:47< shadowm> s/_/-/
20141116 16:39:15< gfgtdf> shadowm: i just read in eth wiki taht te numeric form is deprecated
20141116 16:39:37< gfgtdf> shadowm: but in mp_connect we onyl accept te numeric form it looks
20141116 16:39:38< shadowm> That was the intention, but the fact is that it's still used everywhere, so don't touch it.
20141116 16:46:15< iceiceice> shadowm: you are misunderstanding,
20141116 16:46:29< iceiceice> the team colors cfg file indeed defines many colors,
20141116 16:46:37< iceiceice> but the only that are detected for multiplayer purposes
20141116 16:46:44< iceiceice> are those with an id which is a number
20141116 16:46:48< iceiceice> the nine defined here: https://github.com/wesnoth/wesnoth/blob/master/data/core/team-colors.cfg#L273
20141116 16:47:30< shadowm> Are you saying there is code actually trying to "detect" things?
20141116 16:47:49< iceiceice> the multiplayer code will basically cast the side number to a string,
20141116 16:47:53< iceiceice> and search for a color with that id
20141116 16:48:10< shadowm> Yes, but no, that's not what I was talking above.
20141116 16:48:13< iceiceice> if it doesn't find something, i think it throws an error
20141116 16:48:40< shadowm> I was specifically saying that the number of color ranges defined does not under any circumstances match 9.
20141116 16:49:02-!- un214 [~un214@2602:306:cccf:af99:56a0:50ff:fe57:101d] has joined #wesnoth-dev
20141116 16:49:15< shadowm> And nothing should expect that to happen (UMC can define color ranges).
20141116 16:49:39< iceiceice> okay but this information has nothing to do with what gfgtdf was talking about
20141116 16:49:48< gfgtdf> can anyone veryfy that non numeric color= values still work after RiftWalker spmp patch ?
20141116 16:50:01< shadowm> No, it does, you just missed the original context.
20141116 16:50:23< iceiceice> shadowm: no, it does. the main limitation is indeed the lack of additional color definitions.
20141116 16:50:47< iceiceice> i tested it once, it gave some kind of crash, i dont remember exactly
20141116 16:50:48< shadowm> That's a limitation.
20141116 16:51:34< shadowm> However, if I define additional color ranges the game shouldn't naïvely try to assign them to sides automatically.
20141116 16:52:05< iceiceice> indeed, it doesn't do that.
20141116 16:52:34< shadowm> And neither it should define the number of possible sides in function of the number of color ranges defined.
20141116 16:52:47< iceiceice> indeed, it doesn't do that either....
20141116 16:53:01< iceiceice> what it does is, tries to define side 10 to have the color range with id "10"
20141116 16:53:05< iceiceice> which doesn't exist.
20141116 16:54:30< iceiceice> and iirc this is indeed the main limitation why we have the server rejecting games with too many sides,
20141116 16:54:37< iceiceice> it isn't necessary for every side to have a map-defined starting position
20141116 16:57:46-!- lipkab [~lipkab@host-91-147-211-128.biatv.hu] has joined #wesnoth-dev
20141116 16:58:13-!- un214 [~un214@2602:306:cccf:af99:56a0:50ff:fe57:101d] has quit [Remote host closed the connection]
20141116 17:03:45< gfgtdf> iceiceice: i think teh commit the impleententd the "limit 9 sides on server" was this one: https://github.com/wesnoth/wesnoth/commit/aca79752ac92d7cf4ff909809a30325daa734161
20141116 17:04:48-!- un214 [~un214@2602:306:cccf:af99:56a0:50ff:fe57:101d] has joined #wesnoth-dev
20141116 17:07:35< gfgtdf> iceiceice: and i think its posible that it was implemented that was becasue beeing able to have more than 9 sides was just not highr priority at that time.
20141116 17:07:51< iceiceice> y i think its likely
20141116 17:08:20< iceiceice> i mean there must some limit, unless you introduce a "color range generator" or something
20141116 17:08:43< iceiceice> or recycle colors, but that seems bad
20141116 17:09:19-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141116 17:09:34-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20141116 17:10:14< gfgtdf> iceiceice: no i said it's possible taht teh one who imeplemnted it didnt thouight about colors, but rather that a fixes sized vector migth be easier to implement. And then teh 9 was chosen becasue at other places the limit is also 9
20141116 17:10:40< iceiceice> yeah that's a good theory why 9 is chosen
20141116 17:11:14< shadowm> We were also using a map format that only allowed a single char per tile, and 1-9 were always keeps.
20141116 17:11:42< shadowm> (That's not a theory, that's a fact.)
20141116 17:11:56< iceiceice> yeah but that doesn't explain why the mp server limit is imposed
20141116 17:12:10< iceiceice> because you don't need to define a starting location in the map, for every side.
20141116 17:13:14< shadowm> vultraz: I have enabled file uploads in the wiki for members of the sysops group only.
20141116 17:13:32< shadowm> I hope ancestral will appreciate the fact I spent two hours working on this.
20141116 17:13:42< vultraz> Noted
20141116 17:13:55< gfgtdf> iceiceice: an optimion on https://github.com/gfgtdf/wesnoth-old/commit/8ee1fdd5b128521fbb073ee95aec9192077b6364
20141116 17:13:57< gfgtdf> ?
20141116 17:14:09-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 258 seconds]
20141116 17:14:28< iceiceice> hmm
20141116 17:14:41< shadowm> vultraz: That said, I'd prefer if you prodded me if you start using thumbnailed uploads in an existing page.
20141116 17:14:47< iceiceice> you don't think that :control and the wml should use the same mechanism?
20141116 17:15:09< vultraz> Also noted
20141116 17:15:18< shadowm> vultraz: I'd like to make sure it looks right and that we can come up with a real policy for uploads, because the plan is to upload everything that needs to be uploaded and disable hotlinking images.
20141116 17:15:57< vultraz> What about images hosted in our repo?
20141116 17:16:01< shadowm> Later we can create an additional group for uploaders if we want, but it definitely shouldn't be a power that's automatically granted to users.
20141116 17:16:09-!- un214 [~un214@2602:306:cccf:af99:56a0:50ff:fe57:101d] has quit [Remote host closed the connection]
20141116 17:16:15< gfgtdf> iceiceice: hm  no for wml all client get the update from wml, the one one who is not informted is taht server, taht different for :controller, at origin at one cleint and tehn gets sended to the othe cleints
20141116 17:16:21< vultraz> Jesus, no. Of course not
20141116 17:16:27< gfgtdf> the only one*
20141116 17:16:40< shadowm> Hotlinking can only be enabled or disabled entirely.
20141116 17:17:07< vultraz> And the eventual goal is disabled?
20141116 17:17:14< iceiceice> gfgtdf ok i agree
20141116 17:17:16< shadowm> That's what I said above.
20141116 17:17:36< shadowm> "[...] the plan is to [...] disable hotlinking images."
20141116 17:18:09< shadowm> Obviously I'm not going to make an active effort to do this because I have better things to do than edit a stupid wiki.
20141116 17:18:15< gfgtdf> iceiceice: hm no for [modify_side] all clients get the update from wml, the only one who is not informted is the server. It's different case for :controller where the controller change at origins at one client and then gets sended to the other cleints
20141116 17:18:27< gfgtdf> iceiceice: ^ with corrected spelling
20141116 17:18:36< shadowm> So I don't particularly care if it takes you a year as long as it gets done.
20141116 17:18:51< shadowm> You could also recruit Crendgrim's and zookeeper's help I guess?
20141116 17:19:22< vultraz> I believe first I should finish my wiki restructure plan, then begin  putting that into action
20141116 17:19:29< shadowm> After we get the thumbnailing check done first.
20141116 17:19:34< vultraz> During the transition there'll probably be a lot to upload/delete
20141116 17:20:33< vultraz>  Once that's done we can do a hard switch to uploads only
20141116 17:22:45< vultraz> I think we should also make a policy regarding user-content related pages
20141116 17:23:41< iceiceice> gfgtdf: the way that i thought the #sides limitation would be worked would be just, ask some artistically involved person to define colors for up to 20 sides, and make that the new limit for mp games
20141116 17:24:20-!- lipkab [~lipkab@host-91-147-211-128.biatv.hu] has quit [Ping timeout: 256 seconds]
20141116 17:25:04< iceiceice> i mean you could do more and more fussy things with it, like make the color ranges be defined in the scenario and transmitted in mp, rather than take them from game-config.cfg
20141116 17:25:32< gfgtdf> iceiceice: well i think teh most common usecase for such many sides s if there are many ai sides and i think it it isnt really bad if 2 ai allied ai sides have the same color.
20141116 17:25:52< iceiceice> ok, so we should just cycle colors?
20141116 17:25:58< iceiceice> unless the scenario defines otherwise?
20141116 17:26:28< iceiceice> i mean i think this stuff is only done in mp connect or something
20141116 17:27:53< iceiceice> i dont remember for sure anymore
20141116 17:27:57< gfgtdf> iceiceice: currently in m_connect all sides that have side_numer > 9 have as defautl color 9 (cyan). I think expecting the wml devepoers to set the colors himself woudl be ok. But in order to give hin that changece to do so we choudl accpet non numerical colors in mp connect too
20141116 17:28:16< gfgtdf> iceiceice: to set the colors for scenarios with > 9 sides
20141116 17:30:26-!- lipkab [~lipkab@host-91-147-211-128.biatv.hu] has joined #wesnoth-dev
20141116 17:31:15< iceiceice> gfgtdf: i think it might be enough to change this line:
20141116 17:31:16< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/game_initialization/multiplayer_ui.cpp#L77
20141116 17:31:38< iceiceice> `strcast(id+1)` to `strcast((id%9) +1)`
20141116 17:32:11< gfgtdf> iceiceice: no
20141116 17:32:34< gfgtdf> iceiceice: we dont use the "side" value in mp connect ot call taht fucntion
20141116 17:32:45< gfgtdf> iceiceice: we rather use it in this vector: https://github.com/wesnoth/wesnoth/blob/113c8d8504cc0432b4ba063ae076e9a0107477d3/src/game_initialization/multiplayer_connect.cpp#L412
20141116 17:33:10< iceiceice> sure so you would have to change that also ofc
20141116 17:34:33< gfgtdf> iceiceice: ok this is my test scenario for the update controllers: http://pastebin.com/9k2PAeLw
20141116 17:34:39< iceiceice> hmm is player_colors_ actually used in the connect_engine?
20141116 17:34:44< iceiceice> i don't remember now
20141116 17:37:37< gfgtdf> iceiceice: yes it is
20141116 17:38:05< iceiceice> no, i dont think so
20141116 17:38:29< iceiceice> https://github.com/wesnoth/wesnoth/blob/113c8d8504cc0432b4ba063ae076e9a0107477d3/src/game_initialization/connect_engine.cpp#L902
20141116 17:39:41< gfgtdf> iceiceice: https://github.com/wesnoth/wesnoth/blob/113c8d8504cc0432b4ba063ae076e9a0107477d3/src/game_initialization/multiplayer_connect.cpp#L189
20141116 17:39:49< iceiceice> that's not the connect engine
20141116 17:39:52< iceiceice> thats the connect gui
20141116 17:39:58< gfgtdf> iceiceice: but it changes tah value in connect engine
20141116 17:40:37< gfgtdf> player_colors_ is used to initilize conbo_color_ whcih si than used to set engine_.color all this happens in the gui file
20141116 17:41:01< iceiceice> y so the change i suggested doesnt do anything, it would only cause the dropdown menu to contain a very long list of options
20141116 17:41:23< iceiceice> the %9 thing putatively would be better at the line i poitned to in connect_engine.cpp
20141116 17:41:35< iceiceice> because in connect engine that # is initialized to side #
20141116 17:41:49< iceiceice> i think that's where the error occurs
20141116 17:41:55< gfgtdf> iceiceice: which error ?
20141116 17:42:02< iceiceice> the error i observed long ago
20141116 17:42:11< gfgtdf> iceiceice: and which oe is that ?
20141116 17:42:23< iceiceice> from trying to host a game with > 9 sides
20141116 17:42:40< gfgtdf> iceiceice: i actuyl coudl do taht succefully
20141116 17:42:48< iceiceice> really?
20141116 17:42:50< gfgtdf> iceiceice: y
20141116 17:42:57< gfgtdf> iceiceice: also you are aware of https://github.com/wesnoth/wesnoth/commit/10b2c0d9beb5ab9710128fe2a47f5515584971ce ?
20141116 17:43:20< iceiceice> ok you fixed it then :)
20141116 17:43:20< iceiceice> https://github.com/wesnoth/wesnoth/commit/10b2c0d9beb5ab9710128fe2a47f5515584971ce
20141116 17:43:35< iceiceice> i tested this liek a year ago or something, and it made an error
20141116 17:44:07< loonycyborg> is 1.12 same branch as 1.11.19?
20141116 17:44:32< iceiceice> gfgtdf: without your 18hours ago commit though,
20141116 17:44:44< iceiceice> you will get an error i'm pretty sure at the line i poitned to
20141116 17:44:48-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20141116 17:44:52< iceiceice> unless you changed your game-config.cfg to define color "10"
20141116 17:44:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 255 seconds]
20141116 17:44:53< gfgtdf> iceiceice: ok my test scenario went succesfully, and was quiet absurd.
20141116 17:45:09-!- lipkab [~lipkab@host-91-147-211-128.biatv.hu] has quit [Read error: Connection reset by peer]
20141116 17:45:42< gfgtdf> iceiceice: why shodul changing it 10 10 help ?
20141116 17:45:54< iceiceice> well, as many sides as you had
20141116 17:46:05< gfgtdf> iceiceice: wouldnt we then get problems with color=11 ?
20141116 17:46:12< iceiceice> yes ofc
20141116 17:46:22< gfgtdf> iceiceice: maybe we just need a max or moduly in taht side you pointer out too
20141116 17:46:24< iceiceice> and it wouldn't work in networked either
20141116 17:46:32< iceiceice> y it would be safer
20141116 17:46:37< gfgtdf> iceiceice: why would it wokr in networked ?
20141116 17:46:48< iceiceice> because game-config.cfg is not transmitted
20141116 17:47:20< gfgtdf> iceiceice: ah you mean "changed locally game-config.cfg  but don't push to master"
20141116 17:47:31< iceiceice> y
20141116 17:47:57< gfgtdf> iceiceice: i really thignk we should allow non numerich color= values in connect_engine
20141116 17:48:22< iceiceice> so you could put all the colors from game_config in i guess
20141116 17:48:41< iceiceice> a different option would be to make a mechanism to transmit umc-defined colors
20141116 17:49:28< loonycyborg> hmm
20141116 17:49:39< gfgtdf> loonycyborg: i think it is
20141116 17:49:55< loonycyborg> I did something weird with my git repo
20141116 17:50:19< loonycyborg> I have one local repo that uses other local repo as upstream
20141116 17:50:41< loonycyborg> and I can't get 1.12.0 from first repo
20141116 17:50:48< loonycyborg> and 1.12 branch there is really old
20141116 17:51:54< iceiceice> loonycyborg: i used this "git-new-workdir" thing,
20141116 17:52:23< iceiceice> it's a little wierd in some ways but i think it is meant to make this simpler
20141116 17:52:40< loonycyborg> yes, I originally made it long time ago, before I knew about git-new-workdir
20141116 17:54:50< loonycyborg> It seems I needed to do git fetch --tags
20141116 17:57:13-!- Appleman1234 [~Appleman1@rrcs-97-79-164-178.sw.biz.rr.com] has quit [Quit: Leaving]
20141116 18:00:47-!- vifon is now known as czlowiek-zupa
20141116 18:05:11-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has joined #wesnoth-dev
20141116 18:11:03< iceiceice> bbl
20141116 18:11:04-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20141116 18:18:30-!- Sulfur [~Miranda@p5B00888C.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20141116 18:24:37-!- irker256 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20141116 18:24:38< gfgtdf> shadowm: do you knwo wehther there is a specialy markup in commit messages if i want to post a longer sample code ?
20141116 18:32:39< shadowm> gfgtdf: Commit messages are plain text, there is no markup whatsoever. I just indent anything that needs to be quoted.
20141116 18:45:09-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141116 18:47:13-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20141116 18:48:04-!- happygrue [~Laptop@wesnoth/developer/wintermute] has quit [Ping timeout: 258 seconds]
20141116 18:50:30-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141116 18:54:26-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 256 seconds]
20141116 18:55:55-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141116 18:58:06-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141116 19:02:40-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 250 seconds]
20141116 19:03:57-!- fkhodkov [~user@2a01:d0:ffff:10ea::2] has joined #wesnoth-dev
20141116 19:10:22-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 240 seconds]
20141116 19:19:45-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20141116 19:32:07-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20141116 19:40:09-!- travis-ci [~travis-ci@ec2-54-198-229-181.compute-1.amazonaws.com] has joined #wesnoth-dev
20141116 19:40:09< travis-ci> gfgtdf/wesnoth-old#379 (wesnothd_sides - a65752a : gfgtdf): The build has errored.
20141116 19:40:09< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/41177509
20141116 19:40:09-!- travis-ci [~travis-ci@ec2-54-198-229-181.compute-1.amazonaws.com] has left #wesnoth-dev []
20141116 19:52:01-!- irker839 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20141116 19:52:01< irker839> wesnoth: gfgtdf wesnoth:master 6dee1366a59f / src/ (7 files in 4 dirs): notify server of wml controller changes http://git.io/YqwlFA
20141116 19:52:01< irker839> wesnoth: gfgtdf wesnoth:master a65752a67696 / src/ (playmp_controller.cpp playsingle_controller.cpp playturn.hpp): remove class with throwing destructor http://git.io/80TdWw
20141116 20:04:48< gfgtdf> shadowm: : can you please rebuidl the server ?
20141116 20:16:05< irker839> wesnoth: gfgtdf wesnoth:master b487985255ed / changelog: Update changelog http://git.io/VM-_Gg
20141116 20:46:55-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141116 20:52:15-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 272 seconds]
20141116 20:53:24-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141116 20:57:29-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141116 21:09:06-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20141116 21:09:15< iceiceice> hmm, gfgtdf, in this commit: https://github.com/wesnoth/wesnoth/commit/a65752a67696290c6f8a0e96c1b38c37c71535f5
20141116 21:09:30< iceiceice> don't you also need to send the data if no exception is caught?
20141116 21:09:51< gfgtdf> iceiceice: ah yes abviously ...
20141116 21:09:56-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141116 21:09:59< iceiceice> idk what the best thing to do about that is
20141116 21:10:10< iceiceice> i guess java has a "finally" block that is always executed
20141116 21:10:24< iceiceice> you could maybe put like `throw "send turn data"` at the end of try?
20141116 21:10:27-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141116 21:10:35< iceiceice> hmm
20141116 21:10:40< iceiceice> that wont work either 
20141116 21:11:15< iceiceice> i guess just to put the send also just after the try catch
20141116 21:13:24-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has quit [Quit: Sűrű sötét az éj, dühöng a déli szél]
20141116 21:13:32< gfgtdf> iceiceice: yes i think thats how it was donw previously.
20141116 21:22:43-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141116 21:23:20-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141116 21:24:53-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141116 21:25:55-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141116 21:27:44< irker839> wesnoth: gfgtdf wesnoth:master 262fc819ea1a / src/ (playmp_controller.cpp playsingle_controller.cpp): fixup a65752a67 http://git.io/CgVEJw
20141116 21:38:17-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20141116 21:58:19< iceiceice> ancestral: i made a homebrew update for 1.12.0: https://raw.githubusercontent.com/cbeck88/homebrew-games/250ef1b0578e108965a95d1d9d3d5f95a735407a/wesnoth.rb
20141116 21:58:36< ancestral> I’ll check it out later tonight
20141116 21:58:40< iceiceice> ok thank you
20141116 22:00:07-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 265 seconds]
20141116 22:00:14-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141116 22:21:50-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20141116 22:22:23-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20141116 22:54:08-!- ancestral [~ancestral@216.161.16.4] has joined #wesnoth-dev
20141116 22:55:01-!- gfgtdf_ [~chatzilla@f054144148.adsl.alicedsl.de] has joined #wesnoth-dev
20141116 22:56:08-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141116 22:56:39-!- Anakonda [Anakonda@87-92-152-95.bb.dnainternet.fi] has quit [Read error: Connection reset by peer]
20141116 22:57:09-!- gfgtdf [~chatzilla@d148144.adsl.hansenet.de] has quit [Ping timeout: 265 seconds]
20141116 22:57:12-!- gfgtdf_ is now known as gfgtdf
20141116 22:58:11-!- gfgtdf [~chatzilla@f054144148.adsl.alicedsl.de] has quit [Read error: Connection reset by peer]
20141116 23:04:25-!- ancestral [~ancestral@216.161.16.4] has quit [Read error: Connection reset by peer]
20141116 23:20:03-!- gfgtdf [~chatzilla@f054144148.adsl.alicedsl.de] has joined #wesnoth-dev
20141116 23:27:46-!- mjs-de [~mjs-de@f048067162.adsl.alicedsl.de] has quit [Remote host closed the connection]
20141116 23:31:24-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Bye for now]
20141116 23:38:06-!- fabi [~quassel@p20030051AA25B935046E15148CFC3BC8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141116 23:38:06-!- fabi [~quassel@p20030051AA25B935046E15148CFC3BC8.dip0.t-ipconnect.de] has quit [Changing host]
20141116 23:38:06-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141116 23:38:19-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20141116 23:39:26< fabi> hello
20141116 23:43:51-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has quit [Quit: leaving]
--- Log closed Mon Nov 17 00:00:47 2014