--- Log opened Sun Aug 21 00:00:22 2016
20160821 00:12:13-!- Bonobo [~Bonobo@2001:44b8:254:3200:6c48:fa34:d249:7bee] has joined #wesnoth-dev
20160821 00:13:05< celmin> So, the password box seems to work properly again, now.
20160821 00:13:16< celmin> Unless I missed something.
20160821 00:17:10< celmin> Suddenly loading screen crash.
20160821 00:27:18-!- travis-ci [~travis-ci@ec2-107-22-65-229.compute-1.amazonaws.com] has joined #wesnoth-dev
20160821 00:27:19< travis-ci> wesnoth/wesnoth#10487 (master - 149b477 : Wedge009): The build is still failing.
20160821 00:27:19< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/153860875
20160821 00:27:19-!- travis-ci [~travis-ci@ec2-107-22-65-229.compute-1.amazonaws.com] has left #wesnoth-dev []
20160821 00:31:45-!- irker367 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160821 00:31:45< irker367> wesnoth: Celtic Minstrel wesnoth:master 274dfca77062 / src/gui/widgets/ (password_box.cpp password_box.hpp): Reimplement password box widget to avoid laying out text that will never be rend https://github.com/wesnoth/wesnoth/commit/274dfca77062be3839aa29d2bef72fd293754a74
20160821 00:31:53< celmin> Oh, irker is back, huh.
20160821 00:37:09< irker367> wesnoth: Celtic Minstrel wesnoth:team_index_refactor 2b0f92d8dffc / src/ (76 files in 18 dirs): Refactor team indexing to avoid using 0-based indices as much as possible https://github.com/wesnoth/wesnoth/commit/2b0f92d8dffc25316faf6e0e13414b99ac476ef5
20160821 00:37:12< celmin> ^ Still needs a sanity-checking code review
20160821 00:40:22-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160821 01:08:07-!- travis-ci [~travis-ci@ec2-54-227-153-63.compute-1.amazonaws.com] has joined #wesnoth-dev
20160821 01:08:08< travis-ci> wesnoth/wesnoth#10488 (master - 274dfca : Celtic Minstrel): The build is still failing.
20160821 01:08:08< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/153866292
20160821 01:08:08-!- travis-ci [~travis-ci@ec2-54-227-153-63.compute-1.amazonaws.com] has left #wesnoth-dev []
20160821 01:11:51-!- Bonobo [~Bonobo@2001:44b8:254:3200:6c48:fa34:d249:7bee] has quit [Ping timeout: 264 seconds]
20160821 01:12:11-!- Bonobo [~Bonobo@2001:44b8:254:3200:9c17:c27d:aa70:1c2b] has joined #wesnoth-dev
20160821 01:12:53-!- travis-ci [~travis-ci@ec2-107-22-65-229.compute-1.amazonaws.com] has joined #wesnoth-dev
20160821 01:12:54< travis-ci> wesnoth/wesnoth#10489 (team_index_refactor - 2b0f92d : Celtic Minstrel): The build is still failing.
20160821 01:12:54< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/153866704
20160821 01:12:54-!- travis-ci [~travis-ci@ec2-107-22-65-229.compute-1.amazonaws.com] has left #wesnoth-dev []
20160821 01:14:46-!- Shiki [~Shiki@141.39.226.227] has quit [Quit: Verlassend]
20160821 01:49:43-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160821 01:58:23< vultraz> wedge009: I wanted you to look at MP Create Game, no the lobby :)
20160821 02:01:01< irker367> wesnoth: doofus-01 wesnoth:master d24990dc8503 / data/core/ (38 files in 2 dirs): wooden floor variation and new transitions to chasm, water, and lava https://github.com/wesnoth/wesnoth/commit/d24990dc8503621152fb654b50a40a644a728092
20160821 02:01:03< irker367> wesnoth: doofus-01 wesnoth:master 6a27d1ca30aa / changelog: update changelog https://github.com/wesnoth/wesnoth/commit/6a27d1ca30aa4a19f33bf2bb157dc1d4dfe549a4
20160821 02:01:05< irker367> wesnoth: Charles Dang wesnoth:master bf4db3933873 / / (39 files in 3 dirs): Merge pull request #754 from doofus-01/new_wood_transitions https://github.com/wesnoth/wesnoth/commit/bf4db39338738bc07a5ce260391035aea389d621
20160821 02:21:00< irker367> wesnoth: Charles Dang wesnoth:master 05e095e5813b / data/core/images/icons/book.png: New book icon by myself https://github.com/wesnoth/wesnoth/commit/05e095e5813bfd44170148898ef6d654bfe304b1
20160821 02:21:03< irker367> wesnoth: Charles Dang wesnoth:master fe8a6d71fa01 / data/core/ (25 files in 2 dirs): Added new Rogue baseframes and defense animations https://github.com/wesnoth/wesnoth/commit/fe8a6d71fa018ce4ba4e97d08305f6ef7de494c2
20160821 02:27:38< vultraz> Only took 4 years to get those in :P
20160821 02:32:34< celmin> Seriously?
20160821 02:32:40< vultraz> yes
20160821 02:35:16< vultraz> still missing attack/die anims, but meh
20160821 02:38:03-!- travis-ci [~travis-ci@ec2-107-22-65-229.compute-1.amazonaws.com] has joined #wesnoth-dev
20160821 02:38:04< travis-ci> wesnoth/wesnoth#10490 (master - bf4db39 : Charles Dang): The build is still failing.
20160821 02:38:04< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/153871426
20160821 02:38:04-!- travis-ci [~travis-ci@ec2-107-22-65-229.compute-1.amazonaws.com] has left #wesnoth-dev []
20160821 02:38:07< vultraz> ok, still working  on a few QoL improvements for Create...
20160821 02:38:16< celmin> QoL?
20160821 02:38:34< vultraz> quality of life
20160821 02:39:25< celmin> I fail to see how that applies here.
20160821 02:55:52< shadowm> I think he means usability.
20160821 02:56:34< shadowm> Or potentially UX. It's really hard to tell since the actual meaning of QoL is completely orthogonal to software development.
20160821 02:59:34-!- fabi [~fabi@176.0.124.156] has quit [Remote host closed the connection]
20160821 02:59:49-!- fabi [~fabi@176.0.124.156] has joined #wesnoth-dev
20160821 03:04:39-!- louis94 [~~louis94@91.178.242.249] has quit [Ping timeout: 264 seconds]
20160821 03:04:47-!- travis-ci [~travis-ci@ec2-54-227-153-63.compute-1.amazonaws.com] has joined #wesnoth-dev
20160821 03:04:49< travis-ci> wesnoth/wesnoth#10491 (master - fe8a6d7 : Charles Dang): The build is still failing.
20160821 03:04:49< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/153872930
20160821 03:04:49-!- travis-ci [~travis-ci@ec2-54-227-153-63.compute-1.amazonaws.com] has left #wesnoth-dev []
20160821 03:15:38-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160821 03:15:51-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160821 03:19:30-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 276 seconds]
20160821 03:19:30-!- wedge010 is now known as wedge009
20160821 03:33:31< vultraz> wedge009: did you see my message from earlier?
20160821 03:49:31-!- JyrkiVesterinen [~JyrkiVest@87-100-131-34.bb.dnainternet.fi] has joined #wesnoth-dev
20160821 03:54:12< vultraz> JyrkiVesterinen: I have a small bug you might be able to fix.. not sure. when you first start a game, after an objectives dialog closes, a bunch of the buttons under the minimap are missing their icons until you select a unit or open a menu
20160821 03:54:58< vultraz> Aginor might be able to point you in the right direction
20160821 03:55:40< JyrkiVesterinen> I'll investigate it later today. It may well be related to the "staging event handlers" I added.
20160821 03:56:31< vultraz> no, it existed since before 1.13.5
20160821 03:58:06< irker367> wesnoth: Charles Dang wesnoth:master cd4c87ed6bbe / data/gui/window/mp_create_game.cfg src/gui/dialogs/multiplayer/mp_create_game.cpp: MP Create: few more tweaks https://github.com/wesnoth/wesnoth/commit/cd4c87ed6bbea86331db531d020a5ac40c91d0f2
20160821 04:32:58-!- travis-ci [~travis-ci@ec2-107-22-65-229.compute-1.amazonaws.com] has joined #wesnoth-dev
20160821 04:32:59< travis-ci> wesnoth/wesnoth#10492 (master - cd4c87e : Charles Dang): The build is still failing.
20160821 04:32:59< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/153879259
20160821 04:32:59-!- travis-ci [~travis-ci@ec2-107-22-65-229.compute-1.amazonaws.com] has left #wesnoth-dev []
20160821 04:38:21< celmin> We really need to fix that.
20160821 04:38:41< celmin> I bet it's something in MP Create.
20160821 04:41:05< vultraz> i just realized mp options get reset every time you switch away from their view :|
20160821 04:41:05< vultraz> blah
20160821 04:41:05< vultraz> i hope i don't have to use the godaweful options manager
20160821 04:41:05< vultraz> awful*
20160821 04:41:05 * vultraz cannot type
20160821 04:41:05< celmin> The what?
20160821 04:41:29< vultraz> mp::options::manager
20160821 04:44:16-!- fabi_ [~fabi@176.7.56.60] has joined #wesnoth-dev
20160821 04:45:25< vultraz> that class is full of gui1 crap :|
20160821 04:46:40-!- TheJJ_ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has quit [Ping timeout: 265 seconds]
20160821 04:47:07-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20160821 04:47:27-!- fabi [~fabi@176.0.124.156] has quit [Ping timeout: 244 seconds]
20160821 04:48:09< vultraz> I might have to rewrite it
20160821 04:48:51< vultraz> celmin: can you convert faction selection to gui2?
20160821 04:49:04< celmin> Maybe.
20160821 04:49:12< vultraz> not the mp connect screen, the one where you join a game and then select your faction/leader
20160821 04:49:19< celmin> I have to deal with the const_cast branch first.
20160821 04:49:24< celmin> Yeah, I got that.
20160821 04:50:12< vultraz> ok
20160821 04:50:24< vultraz> deal with cons_cast and team_index_refactor
20160821 04:50:44< celmin> team_index_refactor is probably harder
20160821 04:50:57< celmin> Might be better to try and break it up into chunks somehow...
20160821 04:51:17< celmin> Did you sanity-check the diff?
20160821 04:51:22< vultraz> some of it
20160821 04:51:36< celmin> I guess you had nothing to say?
20160821 04:51:54< celmin> They probably conflict with each other too.
20160821 04:52:30< celmin> They do at least both touch game_lua_kernel, but maybe with luck they only touch different areas.
20160821 04:52:34< vultraz> do const cast first
20160821 04:52:42< celmin> I plan to.
20160821 04:52:57< celmin> The errors wedge009 reported need to be dealt with.
20160821 04:53:26-!- Kwandulin [~Miranda@p200300760F35BF191C25916334F85E7E.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160821 04:53:31< celmin> I already tested most of the Lua functions that could've been affected, but the two seemingly responsible for those errors were those that I skipped because I was getting bored of testing things. >_>
20160821 04:53:42-!- vultraz changed the topic of #wesnoth-dev to: 1.13.6 planned for mid-to-late September | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160821 04:53:57< celmin> I see.
20160821 04:54:36< celmin> BTW, are you getting any crashes from MP Create?
20160821 04:54:56< vultraz> no
20160821 04:55:06< vultraz> I did get one or two in the inspector, though
20160821 04:55:40< vultraz> cannot reproduce though
20160821 04:55:45< vultraz> seems to happen at random
20160821 04:55:52< vultraz> usually when clicking a sub-side node
20160821 05:01:10-!- JyrkiVesterinen [~JyrkiVest@87-100-131-34.bb.dnainternet.fi] has quit [Quit: Updating AdiIRC]
20160821 05:02:02-!- JyrkiVesterinen [~JyrkiVest@87-100-131-34.bb.dnainternet.fi] has joined #wesnoth-dev
20160821 05:03:06< celmin> Has it happened since wedge009's fix?
20160821 05:03:16< vultraz> what fix?
20160821 05:03:24< celmin> Making a copy of defn_
20160821 05:03:58< celmin> About six hours ago.
20160821 05:04:04< vultraz> no
20160821 05:04:20< celmin> Unrelatedly, have you seen the new password widget?
20160821 05:04:47< vultraz> only difference I see is the dots
20160821 05:04:56< celmin> So no difference in performance?
20160821 05:05:23< vultraz> dunno
20160821 05:05:28< vultraz> i have no comparison
20160821 05:05:36< celmin> Fair enough.
20160821 05:06:23< vultraz> looks like you did a lot of cleanup, though
20160821 05:06:32< celmin> In the password widget?
20160821 05:07:17< vultraz> yes
20160821 05:09:49< vultraz> ok, so for 1.13.6 let's try to get the const_cast and team_index branches merged, mp create and mp lobby functional and enabled by default, and possibly spirit-po
20160821 05:09:53< celmin> Why do you call it cleanup?
20160821 05:10:06< celmin> Oh yeah, almost forgot about spirit-po.
20160821 05:10:14< vultraz> less code = cleanup
20160821 05:10:18< celmin> Not really.
20160821 05:10:38< celmin> From what I recall, spirit-po was missing two things: build system updates, and exception handling.
20160821 05:36:20-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160821 05:51:25-!- celticminstrel is now known as celmin|sleep
20160821 06:25:38-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20160821 06:31:48-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160821 06:49:12-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Changing host]
20160821 06:49:12-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160821 06:54:34-!- fabi_ [~fabi@176.7.56.60] has quit [Ping timeout: 244 seconds]
20160821 07:11:31-!- irker367 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160821 07:15:33-!- mjs-de [~mjs-de@x4e3051be.dyn.telefonica.de] has joined #wesnoth-dev
20160821 07:26:59-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160821 07:27:57-!- Kwandulin_2 [~Miranda@p200300760F35BFC31C25916334F85E7E.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160821 07:29:43-!- Kwandulin [~Miranda@p200300760F35BF191C25916334F85E7E.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160821 07:50:45< Aginor> celmin: did you manage to find the problem in your widget?
20160821 07:57:21-!- Kwandulin_2 [~Miranda@p200300760F35BFC31C25916334F85E7E.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160821 08:26:50-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160821 08:28:53-!- Kwandulin [~Miranda@p200300760F35BFC3059AF478B77054BA.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160821 08:41:29-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160821 08:47:30< wedge009> vultraz: Not sure what I'm supposed to be looking at. Everything looks like GUI1 to me.
20160821 08:48:02< vultraz> do you have the experimental lobby enabled? it's controlled by the same check
20160821 08:48:52< wedge009> I was told that it wasn't the lobby.
20160821 08:49:35< vultraz> both the new mp create and mp lobby only appear if the 'Experimental mp lobby' preference is on.
20160821 08:50:06< wedge009> Oh I see.
20160821 08:50:11< wedge009> It crashes. :S
20160821 08:50:17< vultraz> D:
20160821 08:50:21< vultraz> nuuuu
20160821 08:50:25< vultraz> what's the message
20160821 08:50:35< wedge009> Crash.
20160821 08:50:48< wedge009> Compiling debug mode.
20160821 08:51:04< wedge009> I really should leave this till after dinner.
20160821 08:51:38< vultraz> no rush
20160821 08:52:25< wedge009> Sundays I'm usually at church and seeing family. I just happened to have time before leaving this morning, that's when I looked at celmin's Inspector work.
20160821 08:52:53< wedge009> It's coming up now.
20160821 08:55:24< wedge009> Looks like another case of MSVC catching something in the use of vectors that doesn't get caught in Linux. Had similar stuff with the editor relating to uninitialised teams.
20160821 08:55:49< vultraz> blah
20160821 08:55:56< vultraz> is it something you can fix?
20160821 08:56:29< wedge009> create_engine.cpp:772, looks like index is -1/
20160821 08:56:30< wedge009> .
20160821 08:57:04< wedge009> Called from mp_create_game.cpp:355 (on_mod_select()).
20160821 08:58:16< vultraz> hmmmm
20160821 08:58:24< vultraz> maybe i wants set_current_level to be called before that?
20160821 08:59:06< vultraz> try moving the line "display_games_of_type(window, ng::level::TYPE::SCENARIO);" near the top of pre_show
20160821 09:55:20 * zookeeper will be away for the next >50 <60 hours
20160821 09:55:48< vultraz> noted
20160821 10:04:18-!- JyrkiVesterinen [~JyrkiVest@87-100-131-34.bb.dnainternet.fi] has quit [Quit: .]
20160821 10:09:42-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20160821 10:23:35< wedge009> vultraz: Sorry, where should I move that call to?
20160821 10:24:54< vultraz> move it from the end of pre_show to the beginning
20160821 10:25:15-!- irker606 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160821 10:25:15< irker606> wesnoth: Charles Dang wesnoth:master 941f76b607dd / src/minimap.cpp: Exclude border hexes from minimap drawing https://github.com/wesnoth/wesnoth/commit/941f76b607dd3c16ea83ca8741514213b2190805
20160821 10:28:41< wedge009> Doesn't appear to help. I'll try to see what's going on.
20160821 10:28:45< vultraz> hmm
20160821 10:28:49< vultraz> ok
20160821 10:28:56< vultraz> appreciated 
20160821 10:31:10< wedge009> 'Set up random faction mode copobox'?
20160821 10:31:20< wedge009> It's the start of that section which breaks.
20160821 10:31:23-!- Shiki [~Shiki@141.39.226.227] has joined #wesnoth-dev
20160821 10:32:40< vultraz> hmm
20160821 10:32:46< vultraz> comment out that whole section and see
20160821 10:33:01< vultraz> (the random faction mode 'copobox' section :P )
20160821 10:33:40< wedge009> Is it a typo?
20160821 10:34:33< vultraz> yes
20160821 10:43:37< wedge009> vultraz: What is tmp_create_game::on_mod_select() (mp_create_game.cpp:351) supposed to do? I'm guessing that since I have no mods, it's trying to set_current_mod_index (-1) (4294967295, actually), and then when it calls show_description() it crashes.
20160821 10:45:07< vultraz> ahhhhh
20160821 10:45:13< vultraz> that makes sense
20160821 10:45:29< vultraz> it's supposed to set the currently selected mod in the create_engine and display its description
20160821 10:45:53< vultraz> add a check to make sure mods are present
20160821 10:50:12< wedge009> There's a similar situation for eras. But there's always at least one era built in, right?
20160821 10:50:42< wedge009> If I had mods, where should I be able to find the list box?
20160821 10:51:12< wedge009> It seems to work once I added a check for non-positive mod item count (and subsequently return from the function).
20160821 10:51:43< wedge009> Never mind, found it.
20160821 10:52:17< wedge009> Without a mod list box, the Eras section takes up most of the width right of the map list.
20160821 10:53:37< wedge009> Is it okay to push the mod check?
20160821 10:55:22-!- JyrkiVesterinen [~JyrkiVest@87-92-37-20.bb.dnainternet.fi] has joined #wesnoth-dev
20160821 10:56:18< vultraz> sure
20160821 10:58:03< irker606> wesnoth: Wedge009 wesnoth:master d6e4c5dc0ad8 / src/gui/dialogs/multiplayer/mp_create_game.cpp: Don't try to show modifications if there are not any installed. https://github.com/wesnoth/wesnoth/commit/d6e4c5dc0ad80d884df1606fb7a4d25dfd09b53d
20160821 10:59:32< vultraz> thanks for catching that :)
20160821 11:00:52-!- travis-ci [~travis-ci@ec2-107-22-65-229.compute-1.amazonaws.com] has joined #wesnoth-dev
20160821 11:00:53< travis-ci> wesnoth/wesnoth#10493 (master - 941f76b : Charles Dang): The build is still failing.
20160821 11:00:53< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/153911476
20160821 11:00:53-!- travis-ci [~travis-ci@ec2-107-22-65-229.compute-1.amazonaws.com] has left #wesnoth-dev []
20160821 11:23:53 * vultraz ponders the options problem
20160821 11:25:07< vultraz> looks like there just needs to be a way to save a value..
20160821 11:26:46< vultraz> I shall wait for celmin to return, since this code confuses me
20160821 11:29:14-!- Shiki [~Shiki@141.39.226.227] has quit [Quit: Verlassend]
20160821 11:33:17-!- travis-ci [~travis-ci@ec2-54-227-153-63.compute-1.amazonaws.com] has joined #wesnoth-dev
20160821 11:33:18< travis-ci> wesnoth/wesnoth#10494 (master - d6e4c5d : Wedge009): The build is still failing.
20160821 11:33:18< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/153914818
20160821 11:33:18-!- travis-ci [~travis-ci@ec2-54-227-153-63.compute-1.amazonaws.com] has left #wesnoth-dev []
20160821 12:08:15-!- mjs-de [~mjs-de@x4e3051be.dyn.telefonica.de] has quit [Remote host closed the connection]
20160821 12:21:01-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160821 12:36:42-!- Shiki [~Shiki@141.39.226.227] has joined #wesnoth-dev
20160821 12:37:56< vultraz> celmin: give me a ping when you get back
20160821 13:15:43-!- Bonobo [~Bonobo@2001:44b8:254:3200:9c17:c27d:aa70:1c2b] has quit [Quit: Leaving]
20160821 13:26:29-!- Kwandulin [~Miranda@p200300760F35BFC3059AF478B77054BA.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160821 13:58:35-!- irker606 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160821 14:16:39-!- Kwandulin [~Miranda@p200300760F35BFC329B8EEDC6D370A14.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160821 15:07:43< celmin> Aginor: I got the widget working, but didn't address the excess of draw events I was experiencing.
20160821 15:07:46< celmin> vultraz: Pong
20160821 15:08:01< vultraz> ah, there you are
20160821 15:08:18< vultraz> I need design advice on this options value problem
20160821 15:09:08< celmin> If you're going to enable the new lobby, you really need to do some load testing.
20160821 15:09:13< vultraz> (and some technical background)
20160821 15:09:58< vultraz> If I understand correctly, the visible_options_ list in create is a map of a struct and a map of a string and a function
20160821 15:10:27< vultraz> Also, if I understand correctly, once cannot modify the contents of that struct once its been created as part of the map, is that correct?
20160821 15:12:38-!- celmin|sleep is now known as celticminstrel
20160821 15:14:02< celmin> I have no idea what you're talking about.
20160821 15:14:10< vultraz> :|
20160821 15:14:33< vultraz> could you look at the code, maybe
20160821 15:14:37< celmin> I could.
20160821 15:14:41< celmin> If I knew where.
20160821 15:15:01< vultraz> mp_create_game.hpp:52
20160821 15:15:34< vultraz> also relevant is*.cpp:432-573
20160821 15:15:50-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160821 15:16:56< vultraz> my dilemma is this: while the system as implemented would indeed fetch the widget value (at least, I think it does), it doesn't save any user-inputted values, rendering the options rather useless
20160821 15:17:47< vultraz> it doesn't save any because every time the list of options is updated (that is, when you change your selection of game, mod, era, or relevant tab), the tree and visible_options_ map are both cleared and regenerated
20160821 15:18:13< vultraz> clearing the tree is necessary, but I dunno about the map
20160821 15:19:11-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20160821 15:19:11-!- wedge010 is now known as wedge009
20160821 15:19:14< vultraz> I was considering dynamically adding and removing members from the map depending if they were already in the map or not when the options list is updated
20160821 15:19:19< vultraz> which I suppose is possible
20160821 15:19:32< vultraz> but that still leaves the matter of value
20160821 15:20:21< vultraz> I'm slightly confused by the fact that the map key member is a struct  
20160821 15:21:28< vultraz> in the code I see lines such as map[checkbox_option["id"]] (where map is visible_options_[{type, id}], where type and id are function arguments of display_custom_options())
20160821 15:21:35< vultraz> IIRC, maps are accessed by map[key]
20160821 15:21:51< vultraz> but the key here is a struct. Does that mean key can be any of the struct members?
20160821 15:22:16< vultraz> More importantly, can those members ever be changed once the k/v map pair is inserted 
20160821 15:23:20< vultraz> So, if, say, I were to insert a config::attribute value (or maybe std::string) 'value' member into the struct, could that be somehow changed as needed?
20160821 15:24:05< vultraz> A downside to this method of adding/removing things from the map would be that users options are only kept as long the game/era/mod with options is kept selected
20160821 15:24:37< vultraz> deselecting it would then remove it from the visible_options_map and lose all inputted values
20160821 15:24:50< vultraz> which is an option, but it doesn't feel optimal
20160821 15:25:36< celmin> Not sure if I've understood what you're getting at but… is the gist of your concern that you want it not to forget all your selected options?
20160821 15:25:39< vultraz> so I also considered keeping a 'master map' of all options, and a vector of the ids of the ones which are acive
20160821 15:25:59< vultraz> right
20160821 15:26:24< vultraz> right now, if you select a game, go to Options, choose some, and immediately start a game, stuff will be fine
20160821 15:26:30< vultraz> but say, then you go to Settings
20160821 15:26:45< vultraz> er, bad example
20160821 15:26:49< celmin> Note that the value_type of a map is std::pair<const key_type, mapped_type>
20160821 15:27:04< celmin> So you can't change the elements of the key when it's already in the map.
20160821 15:27:11< vultraz> what if you select a different game, and then select the first game, options will be gone
20160821 15:27:17< vultraz> option choices
20160821 15:27:41< vultraz> options allow default values
20160821 15:27:59< vultraz> the options need to respect that..
20160821 15:28:18< vultraz> but they should also preserve user values unless Defaults is selected
20160821 15:28:32< celmin> Suppose you enable a modification that has options. Will those be reset whenever you change scenarios too?
20160821 15:29:36< vultraz> everything resets, yes
20160821 15:29:54< vultraz> as I said, both the map and tree are cleared 
20160821 15:30:13< vultraz> (lines 555,556)
20160821 15:30:42< celmin> How is the map used exactly?
20160821 15:31:07< vultraz> see L 788
20160821 15:32:17< celmin> 776?
20160821 15:32:38< vultraz> what?
20160821 15:32:53< vultraz> no
20160821 15:33:00< vultraz> 788
20160821 15:33:13< celmin> That's the "Set game name" comment.
20160821 15:33:28< vultraz> that's line 800 for me :|
20160821 15:33:31< vultraz> have you pulled?
20160821 15:33:34< celmin> No.
20160821 15:33:46< celmin> Not since I went to sleep.
20160821 15:33:53< vultraz> ah
20160821 15:33:59< celmin> I suppose "since I woke up" would work better
20160821 15:34:07< vultraz> ok, well I mean the lines
20160821 15:34:10< vultraz> 		config options;
20160821 15:34:11< vultraz> 		for(const auto& mod_pair : visible_options_) {
20160821 15:34:12< vultraz> etc
20160821 15:34:18< vultraz> 12 lines up
20160821 15:34:19< celmin> Right, that's what I thought.
20160821 15:35:47< celmin> So I think what you need to do is only update the portion of the map and tree that has changed?
20160821 15:36:11< vultraz> that's... rather inconvenient 
20160821 15:36:35< vultraz> I have no way to check if a game/era/mod already has an options node 
20160821 15:36:50< celmin> Sure you do?
20160821 15:37:46< Ravana_> the options are eventually saved to preferences anyways, so why not update them there
20160821 15:37:49< celmin> If a mod has a node, the key in the map is {"modification", mod.id}
20160821 15:38:23< celmin> If an era has a node, the key is {"era", era.id}
20160821 15:38:54< celmin> So you just need to use visible_options_.find().
20160821 15:40:38< vultraz> I.. see
20160821 15:40:49< vultraz> ok
20160821 15:40:57< vultraz> but what if you deselect a game
20160821 15:40:59< vultraz> then select it again
20160821 15:41:07< vultraz> is it acceptable to lose your selections
20160821 15:41:07< celmin> That's another issue, yes.
20160821 15:41:36< celmin> It's not as bad as losing your modification/era selections every time you select a different game.
20160821 15:42:36< celmin> Maybe you could hide inactive tree nodes instead of removing them from the tree? Of course that means you need to check if they exist before adding them as well.
20160821 15:42:50-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160821 15:43:04< celmin> Also not sure if it could create a performance problem if the user starts looking at every possible thing.
20160821 15:44:00< vultraz> removing is better, likely
20160821 15:45:07< vultraz> what about my idea of keeping the map filled with every possible option?
20160821 15:45:27< vultraz> one map key per game/era/mod with options, and a config or something for the data?
20160821 15:46:42< celmin> What are the getters?
20160821 15:46:55< vultraz> what?
20160821 15:47:50< celmin> Yeah, you can't just put everything in the map.
20160821 15:48:00< celmin> Unless you also put everything in the tree view.
20160821 15:48:12< celmin> The getters in the map are linked to the tree view.
20160821 15:48:15< vultraz> i was going to have a 'visible' flag
20160821 15:48:43< celmin> So if you remove a node from the tree view but don't remove the corresponding options_map from visible_options_, you'll have problems.
20160821 15:48:58< celmin> ^option_map
20160821 15:49:08< vultraz> i'd keep another vector with the keys of the active options
20160821 15:49:36< celmin> That's not the point.
20160821 15:49:48< vultraz> ok, give me options
20160821 15:49:53< vultraz> I've been pondering this for hours
20160821 15:50:00< celmin> The point is that removing a node from the tree view invalidates the corresponding option_map in visible_options_
20160821 15:50:00< vultraz> and I haven't come up with a good solution
20160821 15:50:46< celmin> In other words, it's the tree view that's authoritative, and visible_options_ is more like just a convenient view of it.
20160821 15:51:28< vultraz> right
20160821 15:51:29< vultraz> ok
20160821 15:51:31< vultraz> so what do we do
20160821 15:51:59< celmin> There's the option of just hiding the tree node (with set_visible(invisible)).
20160821 15:52:11< celmin> I'm not sure if that could cause performance problems if there are a lot of invisible nodes.
20160821 15:52:24< celmin> I'm not even sure is tree views are well-equipped to deal with invisible nodes.
20160821 15:52:34< celmin> Hmm...
20160821 15:52:45< vultraz> I don't like that option
20160821 15:55:37< celmin> It seems like ttree_view_node doesn't have an option to remove a node?
20160821 15:56:05< vultraz> ttree_view does
20160821 15:56:43< celmin> That's not how it should be...
20160821 15:56:58< celmin> Oh, I see.
20160821 15:57:04< celmin> You pass the actual node to remove...
20160821 15:57:48< celmin> That function should probably be in ttree_view_node though.
20160821 15:59:00< celmin> I think a ptr_vector owns its elements, so extracting a node without destroying it is probably hard.
20160821 16:00:45< celmin> I suppose you could have a map<option_source, map<string, attribute_value>> inactive_options_;
20160821 16:01:55< celmin> So before removing an option_map from visible_options_ (and before removing the corresponding tree node), copy the option_map into a new map by calling each of its values.
20160821 16:02:53< celmin> Then check for that when displaying the custom options; honour it if present, and remove it when done.
20160821 16:02:56-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 250 seconds]
20160821 16:05:36-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160821 16:05:58-!- Shiki [~Shiki@141.39.226.227] has quit [Remote host closed the connection]
20160821 16:07:03< vultraz> celmin: can we ignore the implementation of tree views right now?
20160821 16:07:09< celmin> Huh?
20160821 16:07:42< vultraz> can we just come up with some kind of idea on how to keep values
20160821 16:07:54< celmin> I did say something.
20160821 16:08:29< vultraz> I don't like the idea of invisible nodes 
20160821 16:08:31< vultraz> at all
20160821 16:08:41< celmin> Not that.
20160821 16:09:08< vultraz> the last I saw was [02:59:00]	celmin	I think a ptr_vector owns its elements, so extracting a node without destroying it is probably hard.
20160821 16:09:25< celmin> [Aug 21@12:00:45pm] celmin: I suppose you could have a map<option_source, map<string, attribute_value>> inactive_options_;
20160821 16:09:26< celmin> [Aug 21@12:01:55pm] celmin: So before removing an option_map from visible_options_ (and before removing the corresponding tree node), copy the option_map into a new map by calling each of its values.
20160821 16:09:26< celmin> [Aug 21@12:02:53pm] celmin: Then check for that when displaying the custom options; honour it if present, and remove it when done.
20160821 16:10:17< vultraz> uhhh
20160821 16:10:38< vultraz> ok, well, firstly, I don't know how to remove a node individually... and secondly... I'm not sure I understand what you say at all :/
20160821 16:11:08< celmin> It's basically saving the settings to a separate map.
20160821 16:11:11< vultraz> and i still don't really know why we can't keep a map of all options
20160821 16:11:16< celmin> Then removing them.
20160821 16:11:33< celmin> You can't keep a map of all options mainly because the way the map was designed.
20160821 16:11:43< celmin> The fact that it directly references widgets in the tree view.
20160821 16:12:21< celmin> If you reversed the dependency somehow, you could make that work.
20160821 16:12:35< vultraz> but it...doesn't?
20160821 16:12:39< celmin> Hm?
20160821 16:12:47< celmin> It does.
20160821 16:12:52< celmin> Reference widgets, I mean.
20160821 16:12:58< celmin> Look in, uh… what was it...
20160821 16:13:08< vultraz> I'm not saying the master map should reference widgets
20160821 16:13:17< celmin> display_custom_options
20160821 16:13:22< vultraz> im saying the master map should be a container or something
20160821 16:13:26< vultraz> with just the data
20160821 16:13:40< celmin> I'm saying the visible_options map currently references widgets.
20160821 16:13:54< vultraz> yes, a map with all options wouldn't
20160821 16:14:10< celmin> So you'd have that and visible_options_?
20160821 16:14:21< vultraz> then again, I don't know how one would simply write the values...
20160821 16:14:25< vultraz> I'd have to hook in callbacks..
20160821 16:14:28< vultraz> it's messy :|
20160821 16:14:40< celmin> Frankly, it's messy already though.
20160821 16:14:55< vultraz> well, I was thinking visible_options_ could just be a vector of strings 
20160821 16:14:56< celmin> The fact that visible_options_ references widgets is a bit messy, for example.
20160821 16:15:00< vultraz> where strings are the ids
20160821 16:32:57< celmin> So what's your idea involving a map with all options?
20160821 16:34:33-!- horrowind [~Icedove@2a02:810a:83c0:404:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160821 16:34:37-!- Shiki [~Shiki@141.39.226.227] has joined #wesnoth-dev
20160821 16:56:15< vultraz> i still need to work out the details
20160821 16:56:19< vultraz> ill get back to you tomorrow
20160821 16:59:18-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20160821 16:59:21-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160821 16:59:44-!- VultCave is now known as vultraz
20160821 17:09:52-!- horrowind [~Icedove@2a02:810a:83c0:404:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160821 17:28:10-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has joined #wesnoth-dev
20160821 17:31:11-!- vultraz [~chatzilla@124.109.10.167] has quit [Read error: Connection reset by peer]
20160821 17:31:14-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160821 17:31:36-!- VultCave is now known as vultraz
20160821 17:34:22-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Ping timeout: 250 seconds]
20160821 17:34:45-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160821 17:34:46-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160821 17:35:45< tad_> So, who's up to talking about a bug with [side]user_team_name and how buggy it is?
20160821 17:37:59< tad_> Consider two sides: [side]side=2 team_name=enemies user_team_name=_"Undead" vs [side]side=3 team_name=enemies user_team_name=_"Bandits"
20160821 17:38:12-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has quit [Remote host closed the connection]
20160821 17:39:00< tad_> If you play from the previous scenario both show user_team_name "Undead". But if you load a saved scenario side=3 shows as "Bandits"
20160821 17:39:46< tad_> Reorder so [side]side=3 appears before side=2 and repeat .. playing from a previous scenario they both show as "Bandits" but load a save and side=2 shows as "Undead"
20160821 17:41:19< celmin> What...
20160821 17:41:44< tad_> So the bug appears to be that the user_team_name for a team_name is loaded only once if you're playing from a previous scenario and came here via End Scenario, but if you Load from the title screen it's loaded for each side from the [side] tag
20160821 17:42:13< celmin> Well, technically, there should be no association between user_team_name and team_name.
20160821 17:43:24< tad_> Well, from End Scenario it's loaded once for a team_name, first-come-first-served, and copied to all other sides on that team. But if you Load, or Back, or anything else (it seems) it's loaded separately for each [side] 
20160821 17:43:52< celmin> So the bug is that there is an association, I guess...
20160821 17:45:07< tad_> Well, it may be an implied association. Like, only when doing End Scenario loading next scenario, it assumes the previous team_name has it set and never looks for a re-set.
20160821 17:45:45< tad_> I have no idea how it works, but I'm surprised I can only tickle the bug when I End Scenario from the previous.
20160821 17:47:13< tad_> For a test, I swapped [side]side=3 to appear before [side]side=2 in the scenario and the problem stayed first-come-first served rather than related to side number.
20160821 17:50:15-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160821 17:54:43< tad_> https://github.com/GregoryLundberg/wesnoth/issues/29
20160821 17:57:24< tad_> We spoke about this a month or so ago when I was first looking at DM. I just noticed it again working on TSG did a bit more testing and thought I'd raise it again.
20160821 17:58:03-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has joined #wesnoth-dev
20160821 18:00:32< tad_> Oh cool .. the parser is pedantic about side numbers. Probably A Good Thing. 
20160821 18:00:49< celmin> You mean complaining if the side numbers are not in order?
20160821 18:00:54< tad_> yep
20160821 18:01:24< tad_> Works find. Filed on-screen as an error. Probably should be a warning because doesn't seem to really matter 
20160821 18:02:30< celmin> Well, the side key in [side] actually doesn't do anything, so if you have a mismatch, I think it'd mean the game thinks it's a different side number than you were expecting.
20160821 18:02:38< celmin> If I recall correctly.
20160821 18:02:59< celmin> eg, if you have two sides, one with side=1 and the other side=3, I think the second one will actually be side 2 for all purposes.
20160821 18:03:24< tad_> Might be the source of surprising bugs. Probably a good thing it's noted on stderr then.
20160821 18:03:46< celmin> It's on stderr? So not in the WML error stream?
20160821 18:04:27< tad_> Correct. No on-screen messages about side=3 in second [side] tag or side=2 in third
20160821 18:04:48< celmin> Maybe it should be moved onscreen then.
20160821 18:04:56< celmin> Most people don't see the log messages.
20160821 18:05:13< tad_> I was just thinking it might be best to declare it fatal and die.
20160821 18:05:28< celmin> That's an option too, I guess.
20160821 18:05:36< celmin> Using the VALIDATE macro.
20160821 18:06:19< tad_> [modify_side] is going to modify the wrong side since they're out of order and it ignored my side=3 declaration. Fatal may be the best choice
20160821 18:08:27< tad_> I would argue that the order in the file does not matter, nor does a gap, but I have a feeling there's something deep in the C++ which is gonna not like that.
20160821 18:09:00< celmin> Yeah, I was saying it shouldn't matter too, but gfgtdf chose instead to do the error message.
20160821 18:09:47< tad_> It certainly is a code smell. But if it's worth the error it's almost certainly worth dying over, too.
20160821 18:10:39< tad_> Trying to keep running means every use of side=N is a bug source
20160821 18:11:22< celmin> I personally think it would make sense to understand gaps as an implicit [side]controller=null.
20160821 18:11:32< celmin> (I think that would work, anyway?)
20160821 18:11:56-!- Kwandulin [~Miranda@p200300760F35BFC329B8EEDC6D370A14.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160821 18:12:14< celmin> Then there might also be an issue that the teams need to be constructed in order, but that could be handled by sorting the side configs before constructing the teams.
20160821 18:12:36< tad_> I would agree and only ask why you even need the implicit side. It should be a sparse array or a hash table and not a simple C array so side=N is a key, not an index
20160821 18:13:23< celmin> It's neither actually, it's a vector.
20160821 18:13:35< celmin> But yeah, making it a sparse array could also work.
20160821 18:16:24< tad_> You mean, about teams, that not only must side= be in order without gaps, but once you introduce a team you cannot go back to an earlier team?  All "a" then all "b" then all "c" but never some "c" then some more "b" then on to more "c" and then "d" ???
20160821 18:17:07< celmin> Huh?
20160821 18:17:21< celmin> Are you proposing merging all [side] tags with a given number, then?
20160821 18:17:30< celmin> I'm not sure why you'd want to split a side up like that though.
20160821 18:18:01< tad_> You said "teams need to be contructed in order" .. "team
20160821 18:18:07< tad_> "team_name" ??
20160821 18:18:48< tad_> If I wanted to split up a [side] I would expect [+side] to be the preferred solution.
20160821 18:18:58< celmin> Sorry, by "team" I meant [side] tags.
20160821 18:19:09< tad_> Ah. OK.
20160821 18:19:20< celmin> And [+side] wouldn't work if you were intermingling bits from various sides.
20160821 18:19:39< celmin> (The C++ uses "team" and "side" semi-interchangeably.)
20160821 18:20:09< tad_> At issue is the side number is the order of play. The team_name determines who attacks whom. The user_team_name is the translatable string to display. There should be NO relationship between the three.
20160821 18:20:55< tad_> The requirement that side numbers count up from 1, in order, with no gaps, is not a problem other than it's a code smell.
20160821 18:21:19< tad_> The wrong user_team_name appearing when you play through instead of load, though, is an issue.
20160821 18:21:23< celmin> There is no relation between the three, no.
20160821 18:21:34< celmin> Except that bug.
20160821 18:22:30< tad_> We're in agreement. My only sugguestion about the side number requirement is it's such a stinky smell I'd recommend killing the scenario rather than attempting to continue
20160821 18:31:28-!- irker580 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160821 18:31:28< irker580> wesnoth: Jyrki Vesterinen wesnoth:master 8816dc9cd9e8 / changelog players_changelog src/controller_base.hpp src/display.cpp: Fix icons of buttons under the minimap disappearing on closing a menu https://github.com/wesnoth/wesnoth/commit/8816dc9cd9e84d15d5cecdae752dbbd880aa24b8
20160821 18:31:55< JyrkiVesterinen> vultraz: The above commit fixes the bug you asked me to fix in the morning. :)
20160821 18:32:13-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has quit [Remote host closed the connection]
20160821 18:32:16< celmin> Yay bugfixes!
20160821 18:33:37-!- Shiki [~Shiki@141.39.226.227] has quit [Remote host closed the connection]
20160821 18:36:33-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has joined #wesnoth-dev
20160821 18:38:58< tad_> Oh, I have gotta see if that fixes it ... /me rushes off to compile
20160821 18:41:37< celmin> That's just a UI change, so...
20160821 18:44:37< tad_> Yep but it's been bugging me when I want to zoom in/out and the buttons are gone
20160821 18:46:24< celmin> Ah.
20160821 18:47:30< tad_> Anyway about user_team_name .. when I hit it today I made a personal issue for it (finally) and thought I'd mention it here. It's something wants to get fixed but it's not a big issue so whenever.
20160821 18:53:58-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has quit [Remote host closed the connection]
20160821 18:57:05-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has joined #wesnoth-dev
20160821 19:00:55-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has quit [Remote host closed the connection]
20160821 19:01:10-!- Shiki [~Shiki@141.39.226.227] has joined #wesnoth-dev
20160821 19:06:30-!- travis-ci [~travis-ci@ec2-54-227-153-63.compute-1.amazonaws.com] has joined #wesnoth-dev
20160821 19:06:31< travis-ci> wesnoth/wesnoth#10495 (master - 8816dc9 : Jyrki Vesterinen): The build is still failing.
20160821 19:06:31< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/153973341
20160821 19:06:31-!- travis-ci [~travis-ci@ec2-54-227-153-63.compute-1.amazonaws.com] has left #wesnoth-dev []
20160821 19:13:57-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160821 19:15:22-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has joined #wesnoth-dev
20160821 19:20:57-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160821 19:21:35-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160821 19:22:15-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has quit [Remote host closed the connection]
20160821 19:33:23-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has joined #wesnoth-dev
20160821 19:44:59-!- mjs-de [~mjs-de@x4e308290.dyn.telefonica.de] has joined #wesnoth-dev
20160821 19:51:47-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has quit [Remote host closed the connection]
20160821 20:00:59-!- Shiki [~Shiki@141.39.226.227] has quit [Remote host closed the connection]
20160821 20:03:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160821 20:06:45-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has joined #wesnoth-dev
20160821 20:26:40-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160821 20:26:43-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160821 20:31:25-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160821 20:35:58-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160821 20:37:47-!- mjs-de [~mjs-de@x4e308290.dyn.telefonica.de] has quit [Remote host closed the connection]
20160821 20:37:58-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160821 20:49:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160821 20:50:16-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has quit [Remote host closed the connection]
20160821 21:32:19-!- irker580 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160821 21:34:39-!- JyrkiVesterinen [~JyrkiVest@87-92-37-20.bb.dnainternet.fi] has quit [Quit: .]
20160821 21:39:31-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160821 21:39:45-!- EliDupree [~quassel@idupree.com] has quit [Remote host closed the connection]
20160821 21:42:52-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has joined #wesnoth-dev
20160821 21:44:15-!- Appleman1234 [~Appleman1@KD036012029168.au-net.ne.jp] has quit [Ping timeout: 244 seconds]
20160821 21:45:00-!- EliDupree [~quassel@2604:a880:400:d0::888:1] has joined #wesnoth-dev
20160821 21:45:57-!- EliDupree [~quassel@2604:a880:400:d0::888:1] has quit [Remote host closed the connection]
20160821 21:46:18-!- EliDupree [~quassel@2604:a880:400:d0::888:1] has joined #wesnoth-dev
20160821 21:47:17-!- EliDupree [~quassel@2604:a880:400:d0::888:1] has quit [Remote host closed the connection]
20160821 21:47:31-!- EliDupree [~quassel@2604:a880:400:d0::888:1] has joined #wesnoth-dev
20160821 21:48:12-!- EliDupree [~quassel@2604:a880:400:d0::888:1] has quit [Remote host closed the connection]
20160821 21:48:36-!- EliDupree [~quassel@2604:a880:400:d0::888:1] has joined #wesnoth-dev
20160821 21:51:39-!- EliDupree [~quassel@2604:a880:400:d0::888:1] has quit [Remote host closed the connection]
20160821 21:51:50-!- EliDupree [~quassel@2604:a880:400:d0::888:1] has joined #wesnoth-dev
20160821 21:55:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160821 22:12:46-!- Greg-Boggs [~greg_bogg@2601:1c2:901:e170:c413:b1fc:374b:83d8] has quit [Remote host closed the connection]
20160821 22:21:00-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160821 22:35:03-!- Appleman1234 [~Appleman1@KD036012021144.au-net.ne.jp] has joined #wesnoth-dev
20160821 22:36:56-!- EliDupree [~quassel@2604:a880:400:d0::888:1] has quit [Remote host closed the connection]
20160821 22:37:04-!- EliDupree [~quassel@2604:a880:400:d0::888:1] has joined #wesnoth-dev
20160821 22:38:27-!- EliDupree [~quassel@2604:a880:400:d0::888:1] has quit [Remote host closed the connection]
20160821 23:18:22-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160821 23:25:40-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
--- Log closed Mon Aug 22 00:00:08 2016