--- Log opened Fri Dec 22 00:00:10 2017
20171222 00:00:26< vultraz> im just surprised..
20171222 00:00:43< fabi_> I see :-)
20171222 00:06:46< fabi_> vultraz: https://imagebin.ca/v/3lVSnWhxvzYO
20171222 00:08:15< vultraz> this looks a little....
20171222 00:08:25< vultraz> less "modern" than I'd like
20171222 00:09:24< fabi_> Do you want to elaborate?
20171222 00:09:45< vultraz> it looks like old-school wesnoth UI
20171222 00:11:22< fabi_> hmmm, I have not recognized a change in style
20171222 00:12:10< fabi_> What exactly is the different from old-school to new?
20171222 00:12:55< vultraz> you've brought the window borders back
20171222 00:13:13< vultraz> and have you noticed that scrollbars are much more minimal now
20171222 00:14:10-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has joined #wesnoth-dev
20171222 00:14:27< fabi_> vultraz: which window borders?
20171222 00:15:16< fabi_> I just used the higher resolution version of the border
20171222 00:17:27< vultraz> borders are now 1-px single-color
20171222 00:17:38< fabi_> What I really miss is a bigger title screen background. 
20171222 00:18:47-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has quit [Ping timeout: 256 seconds]
20171222 00:19:21< fabi_> My new titlescreen displays everthing unscaled, works fine with the map, but the background is still a problem.
20171222 00:20:35-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection]
20171222 00:21:51-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:9c2e:5247:634c:a348] has joined #wesnoth-dev
20171222 00:26:16-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:9c2e:5247:634c:a348] has quit [Ping timeout: 265 seconds]
20171222 00:27:55< fabi_> vultraz: I guess I can change the appearance of the sliders, but notice that they fit nicely to the new stepper widget on that screenshot.
20171222 00:28:46< fabi_> Only "Font Scaling" is a slider, resolution and frequency are both steppers.
20171222 00:41:19< gfgtdf> vultraz: did you saw https://github.com/wesnoth/wesnoth/issues/2310 ?
20171222 00:41:28< vultraz> yes
20171222 00:42:54-!- irker718 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20171222 00:43:20-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:9c2e:5247:634c:a348] has joined #wesnoth-dev
20171222 00:45:10-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:9c2e:5247:634c:a348] has quit [Remote host closed the connection]
20171222 00:46:46-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has joined #wesnoth-dev
20171222 01:10:32-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20171222 01:18:43-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has joined #wesnoth-dev
20171222 01:21:19-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20171222 01:23:21-!- Greg-Boggs [~greg_bogg@73.11.32.127] has joined #wesnoth-dev
20171222 01:27:10-!- Greg-Boggs [~greg_bogg@73.11.32.127] has quit [Remote host closed the connection]
20171222 01:30:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20171222 02:57:30-!- gfgtdf_ [~chatzilla@x4e32b5bc.dyn.telefonica.de] has joined #wesnoth-dev
20171222 02:59:29-!- gfgtdf [~chatzilla@x4e3693a1.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20171222 02:59:40-!- gfgtdf_ is now known as gfgtdf
20171222 03:08:56< vultraz> fabi_: so... why exactly are you working on this?
20171222 03:12:52< vultraz> fabi_: if implementing high-dpi assets, it should be global
20171222 03:12:59< vultraz> not limited to one dialog
20171222 03:20:27-!- celmin|away [~celmin@unaffiliated/celticminstrel] has quit [Read error: Connection reset by peer]
20171222 03:20:46-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20171222 03:21:20< celticminstrel> So I guess vultraz didn't notice my thought about shuffle sides.
20171222 03:22:57< vultraz> no
20171222 03:23:15< celticminstrel> Feel like browsing through the logs for it?
20171222 03:25:28< vultraz> guess so
20171222 03:25:39< vultraz> but this would really be easier if you were on discord :(
20171222 03:28:21< celticminstrel> Meh.
20171222 03:31:46< celticminstrel> Oh yeah, that "normalizing underscores" thing that you did also needs to be reverted.
20171222 03:31:54< celticminstrel> Or refined, I suppose.
20171222 03:33:21< vultraz> yeah
20171222 03:33:30< vultraz> and possibly that options save format
20171222 03:33:55< celticminstrel> Hm?
20171222 03:34:16< vultraz> where i simplified the format in which mp options are saved in prefs
20171222 03:34:24< vultraz> im told it might break names with variable...
20171222 03:34:24< vultraz> s
20171222 03:35:21< celticminstrel> MP options?
20171222 03:35:36< celticminstrel> What did you change there?
20171222 03:36:11< vultraz> i simplified the format
20171222 03:36:26< vultraz> instead of [option] id= value=
20171222 03:36:33< vultraz> it's now id=value
20171222 03:36:53< celticminstrel> And what's the problem with that again?
20171222 03:37:15< vultraz> gfgtdf tells me it's possible to have variables in names or something
20171222 03:37:22< vultraz> and $ is a invalid character in keys
20171222 03:37:25< celticminstrel> Isn't that referring to the event names?
20171222 03:37:45< vultraz> what?
20171222 03:37:59< celticminstrel> You can have variables in event names.
20171222 03:38:13< celticminstrel> Can you have variables in MP option names? I wouldn't think so?
20171222 03:38:25< vultraz> i dunno
20171222 03:38:30< vultraz> let us ask gfgtdf 
20171222 03:39:31< gfgtdf> you cannot, but what you might have is things like aaa.bbb[4].ccc
20171222 03:40:17< gfgtdf> id is basicialyl the name of the variable where that option is stored ingame an ofcourse this can also be a nested variable.
20171222 03:40:29< vultraz> ah....
20171222 03:41:49< celticminstrel> I see.
20171222 03:42:25< celticminstrel> Well, there's nothing to prevent you from supporting both formats though - use the simplified format when possible, otherwise use the old format. If you think that's worth it.
20171222 03:42:32-!- gfgtdf [~chatzilla@x4e32b5bc.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 52.5.2/20171206101620]]
20171222 03:48:12< celticminstrel> Basically the problem then is that .[] are not allowed in WML keys.
20171222 03:51:27< vultraz> yeah
20171222 03:51:28< vultraz> :(
20171222 03:52:11< celticminstrel> SImplest route is to revert both.
20171222 03:52:16< celticminstrel> It's not the only route.
20171222 03:52:39< celticminstrel> For the options, I can think of two other routes.
20171222 03:52:58< celticminstrel> For the events, one other route, but it's probably less than ideal.
20171222 03:53:34< celticminstrel> (It basically would means you can no longer rely on event names always having underscores, which was the entire point of the commit in the first place.)
20171222 03:53:48< celticminstrel> I guess there's also one other possibility for the events thing...
20171222 03:55:05< celticminstrel> Not entirely sure how the events work though.
20171222 03:55:11< celticminstrel> So maybe that's not a possibility.
20171222 03:57:17 * vultraz ponders how to fix https://github.com/wesnoth/wesnoth/issues/2310
20171222 03:58:08< vultraz> i guess i can't save an iterator
20171222 03:58:14< vultraz> since adding invalidates it
20171222 03:58:40< celticminstrel> Whether you can save an iterator depends on the container.
20171222 03:58:42 * vultraz tries to remember if there's a contiguous container that doesn't invalidate iterators...
20171222 03:58:52< celticminstrel> std::list - basically always
20171222 03:59:08< celticminstrel> std::deque - as long as you only ever use push|pop_front|back
20171222 03:59:22< celticminstrel> std::map - I think the same as std::list but can't quite remember
20171222 03:59:54< celticminstrel> std::vector - as long as you never add more elements after saving the iterator, I think it should be safe (but not 100% sure)
20171222 04:00:17< celticminstrel> The contiguous containers are std::vector and std::deque.
20171222 04:00:22< vultraz> so if i have a list, take its end iterator at a certain point, I can check that any iterator doesn't pass the original end, even if more are added?
20171222 04:00:32< vultraz> ah, then i'd need deque
20171222 04:00:33< celticminstrel> std::vector is fully contiguous; std::deque is mostly-contiguous. std::list is not contiguous at all.
20171222 04:00:54-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has joined #wesnoth-dev
20171222 04:01:02< vultraz> though...
20171222 04:01:08< vultraz> i could possibly use an index
20171222 04:01:10< vultraz> it is a vector
20171222 04:01:13< celticminstrel> I think std::list::end is always the end of the list, even if you add more elements or remove some.
20171222 04:01:43< celticminstrel> It may even be the end of other lists of the same type.
20171222 04:01:56< celticminstrel> Internally it's probably much like a null pointer.
20171222 04:02:28< celticminstrel> Using an index can still share some of the problems of iterator invalidation, but as long as you range-check your indices it's probably safe.
20171222 04:02:58< celticminstrel> std::deque is officially considered contiguous and can be random-accessed with [], but in fact it might be stored in several chunks in memory.
20171222 04:04:02< vultraz> hmmmm
20171222 04:04:11< vultraz> ok, this might be more complicated than I assumed...
20171222 04:04:44< vultraz> looks like the original check was only for the main list
20171222 04:05:45< vultraz> and it used indices before
20171222 04:05:49< vultraz> now i use iterators..
20171222 04:07:33< vultraz> i thought i could just keep an iterator and say don't go past that one...
20171222 04:08:17< celticminstrel> Basically, if you want to keep iterators, don't use vector.
20171222 04:08:39< celticminstrel> I'm not quite sure what you mean by "keep an iterator and say don't go past that one" though.
20171222 04:08:59< celticminstrel> Why do you need to store an iterator or index though?
20171222 04:09:29< vultraz> the bug is essentially that my refactoring caused events to be executed even if they were registered in the current event context
20171222 04:09:50< celticminstrel> I'm not sure if that answers the question.
20171222 04:10:09< vultraz> i need a way to say "stop iterating when you reach the original end point before this event was executed"
20171222 04:10:21< vultraz> or rather, before we started iterating over events to execute matching ones
20171222 04:10:48< celticminstrel> So something like...
20171222 04:11:11< celticminstrel> "Okay, we want to iterate over the events CURRENTLY IN THE ARRAY. While iterating, more might be added, and we don't want to include those."
20171222 04:11:17< vultraz> yes
20171222 04:11:28< celticminstrel> I think this would work then.
20171222 04:11:36< celticminstrel> 1. First, make sure the array is a deque, not a vector.
20171222 04:11:49< celticminstrel> 2. Next, just before iterating, save end() - 1 to a variable.
20171222 04:12:12< celticminstrel> 3. The iteration condition becomes iter <= saved_end.
20171222 04:12:41< celticminstrel> (Assuming standard iterator-based for-loop here.)
20171222 04:12:45< celticminstrel> (ie, not range-for)
20171222 04:13:23< vultraz> it's a weird not-really-but-kinda custom iterator class that iterates over two containers at once
20171222 04:13:54< celticminstrel> Oh my.
20171222 04:14:14< vultraz> i didn't write it
20171222 04:14:19< vultraz> complain to jamit
20171222 04:23:32< TadCarlucci> Assume: The event 'list' is a create-time-ordered collection of shared_ptr<>. The event::fire function scans this list for matches creating a new collection of weak_ptr<> in the same time-order as the underlying list. THEN the fire() function iterates that new list being aware that when executing one process future weak_ptr<> may become invalidated. The trick is to use an iterator which can withstand the removal of any (include the curremt) 
20171222 04:23:32< TadCarlucci> element in the collection.
20171222 04:24:11-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20171222 04:24:23< TadCarlucci> The problem is solvable. But it cries out for a complete analysis and design and not just slapping some code in and praying the corner conditions are magically handled.
20171222 04:24:27-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:9c2e:5247:634c:a348] has joined #wesnoth-dev
20171222 04:25:10-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:9c2e:5247:634c:a348] has quit [Remote host closed the connection]
20171222 04:25:55< vultraz> of course
20171222 04:28:27< TadCarlucci> The main problems with the current implementation: Primary: lack of documentation so the reasoning behind the design choices has been lost Secondary: the implementaion is tightly coupled with the use cases so it's impossible to know if some code, somewhere depends upon some internal implementation detail
20171222 04:31:32-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has joined #wesnoth-dev
20171222 04:34:09< vultraz> TadCarlucci: your idea isn't that bad actually
20171222 04:34:17< vultraz> construct a separate list
20171222 04:34:34< TadCarlucci> Actually, it works but there's a lot of design choices which need to be fleshed out.
20171222 04:36:11< celticminstrel> Yes, constructing a separate list to iterate over is one option.
20171222 04:36:41< TadCarlucci> celticminstrel, Actually, unless you want to discard the entire STL it's the only workable option.
20171222 04:38:10-!- Greg-Boggs [~greg_bogg@c-73-11-32-127.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20171222 04:39:52< TadCarlucci> So assume we have a list<shared_ptr<event>> encapsulate that mess in a EventHandler class which is basically a CRUD database: Create, Fire, Delete
20171222 04:41:47< TadCarlucci> First design question is should that be a singleton? I think not. It is an "event context" so we have an game->eventContext campaign->eventContext, scenario->eventContext, ui-> , addon-> ... whatever
20171222 04:44:14< TadCarlucci> Another design question is how Create is handled in the face of multiple running Fire instances. Specifically should there be an option to Create an event which appends to the(a) current running Fire
20171222 04:45:43< TadCarlucci> Should Fire() be queued or nesting, or should we offer a choice?
20171222 04:47:26< celticminstrel> IIRC [fire_event] will run the event immediately, before completing the current one, but I could be misremembering.
20171222 04:49:15< TadCarlucci> That is how it currently is. But if we're doing a redesign we can ask, again, if perhaps it would add to the game/language to allow a queue event "fire this when the current event finishes" or "fire this when all events finish down to this context" etc
20171222 04:49:30< celticminstrel> Yeah
20171222 04:53:13< TadCarlucci> I've been slowly working on this, more thinking and less writing, for some time now. I don't mind if someone else jump in before I'm ready to show my work. But I'll push for some sort of design documentation (not this-does-that but WHY) and I'll puhs hard for decoupling the mess so we can fix it without breaking everything because some jerk desided it was too just work to add FindEvent because he needed to know if it existed and reaching into 
20171222 04:53:13< TadCarlucci> the dataq structure locking us forever into using a list<> when we decide next year a deque<> would be better
20171222 05:02:27-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20171222 05:36:16-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.]
20171222 05:59:24-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:9c2e:5247:634c:a348] has joined #wesnoth-dev
20171222 06:43:36-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20171222 07:30:28-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20171222 07:31:27-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has joined #wesnoth-dev
20171222 07:44:21-!- atarocch [~atarocch@93.56.164.28] has quit [Remote host closed the connection]
20171222 08:18:04-!- Greg-Boggs [~greg_bogg@2601:1c2:1a80:1c20:9c2e:5247:634c:a348] has quit [Remote host closed the connection]
20171222 08:28:25-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20171222 08:28:35-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20171222 09:11:40-!- atarocch [atarocch@nat/redhat/x-ajosuaaidulwnbls] has joined #wesnoth-dev
20171222 09:14:38-!- irker926 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20171222 09:14:38< irker926> wesnoth: Charles Dang wesnoth:master 393ac9bd7026 / src/game_events/ (manager.cpp manager.hpp): Game Events/Manager: refactor event iteration interface https://github.com/wesnoth/wesnoth/commit/393ac9bd7026d138de803fee1b2e123f51c71b06
20171222 09:17:25-!- atarocch_ [atarocch@nat/redhat/x-olylezwaafnqvbgx] has joined #wesnoth-dev
20171222 09:17:41-!- atarocch [atarocch@nat/redhat/x-ajosuaaidulwnbls] has quit [Ping timeout: 256 seconds]
20171222 09:38:14-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev
20171222 09:39:26-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20171222 10:32:45-!- mjs-de [~mjs-de@x5ce370ee.dyn.telefonica.de] has joined #wesnoth-dev
20171222 10:36:28-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has quit [Quit: .]
20171222 11:10:47-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20171222 11:28:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20171222 11:59:25-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has joined #wesnoth-dev
20171222 12:15:11-!- irker926 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20171222 12:49:07-!- irker551 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20171222 12:49:07< irker551> wesnoth/wesnoth:master Charles Dang 393ac9bd70 Game Events/Manager: refactor event iter AppVeyor: All builds passed
20171222 12:49:19< irker551> wesnoth/wesnoth:master Charles Dang f5736eb76f Game Events/Manager: refactor event iter AppVeyor: All builds passed
20171222 12:57:40-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20171222 13:59:29-!- atarocch_ [atarocch@nat/redhat/x-olylezwaafnqvbgx] has quit [Ping timeout: 248 seconds]
20171222 14:32:51-!- DeFender1031 [~DeFender1@89-138-239-68.bb.netvision.net.il] has quit [Quit: I'm not back now.]
20171222 14:34:43-!- mjs-de [~mjs-de@x5ce370ee.dyn.telefonica.de] has quit [Remote host closed the connection]
20171222 14:49:31-!- atarocch [~atarocch@93.56.164.28] has joined #wesnoth-dev
20171222 15:12:46-!- atarocch [~atarocch@93.56.164.28] has quit [Remote host closed the connection]
20171222 15:14:02-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has quit [Quit: .]
20171222 15:18:25-!- atarocch [~atarocch@93.56.164.28] has joined #wesnoth-dev
20171222 15:49:34-!- irker551 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20171222 16:23:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20171222 16:47:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20171222 16:53:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20171222 17:12:26-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection]
20171222 17:28:42-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20171222 17:37:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171222 17:42:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20171222 17:43:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171222 17:48:11-!- mjs-de [~mjs-de@x4db5fdae.dyn.telefonica.de] has joined #wesnoth-dev
20171222 17:48:54-!- irker331 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20171222 17:48:54< irker331> wesnoth: Rikard Falkeborn wesnoth:master 557bbf36ea7d / src/ (display.cpp display.hpp): Make some functions static in display.{cpp,hpp} https://github.com/wesnoth/wesnoth/commit/557bbf36ea7dd990010d1126002fb9655b949b58
20171222 18:12:22-!- fabi_ [~fabi@2a02:810c:c840:2e65:b0e9:679d:1263:5c26] has quit [Ping timeout: 255 seconds]
20171222 18:19:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20171222 18:25:43-!- fabi_ [~fabi@2a02:810c:c840:2e65:30d2:683d:a19a:eb88] has joined #wesnoth-dev
20171222 18:29:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171222 18:59:35-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20171222 19:38:50-!- uprego [~uprego@216.red-83-46-196.dynamicip.rima-tde.net] has quit [Ping timeout: 252 seconds]
20171222 19:52:46-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20171222 20:49:00-!- irker331 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20171222 21:04:42-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20171222 21:29:53-!- irker391 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20171222 21:29:53< irker391> wesnoth/wesnoth:master Rikard Falkeborn 557bbf36ea Make some functions static in display.{c AppVeyor: All builds passed
20171222 21:33:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20171222 21:38:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171222 21:42:06-!- Greg-Bog_ [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has joined #wesnoth-dev
20171222 21:43:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20171222 22:09:46-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev
20171222 22:57:50-!- Greg-Boggs [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has joined #wesnoth-dev
20171222 22:57:50-!- Greg-Boggs [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has quit [Client Quit]
20171222 22:58:19-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20171222 22:59:08-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Client Quit]
20171222 23:00:48-!- Greg-Boggs [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has joined #wesnoth-dev
20171222 23:01:21-!- Greg-Bog_ [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has quit [Ping timeout: 248 seconds]
20171222 23:23:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20171222 23:23:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20171222 23:34:11-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection]
20171222 23:34:45-!- Greg-Boggs [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20171222 23:36:18-!- Greg-Boggs [~greg_bogg@2603:3004:1d:5b00:b192:d715:4253:f411] has joined #wesnoth-dev
20171222 23:40:41-!- Greg-Boggs [~greg_bogg@2603:3004:1d:5b00:b192:d715:4253:f411] has quit [Ping timeout: 265 seconds]
20171222 23:57:13-!- sigurdfd [sigurdfd@dynamic-acs-72-23-110-196.zoominternet.net] has joined #wesnoth-dev
--- Log closed Sat Dec 23 00:00:12 2017