--- Log opened Thu Jan 24 00:00:18 2019 20190124 00:42:01< irker629> wesnoth/wesnoth:1.14 Wedge009 8b6e0ff8bd Secrets of the Ancient: Right click -> R AppVeyor: vs2017/Release Failed 20190124 00:42:02< irker629> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/21846871 20190124 01:10:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190124 01:26:45< irker629> wesnoth: Wedge009 wesnoth:master 0551246e3b4e / projectfiles/VC14/ (wesnoth.vcxproj wesnoth.vcxproj.filters): Use ogg/vorbis DLLs rather than static libraries. https://github.com/wesnoth/wesnoth/commit/0551246e3b4e43c830be255ab2cc80411b864b92 20190124 01:26:47< irker629> wesnoth: Wedge009 wesnoth:master 8c7b3a583bbf / projectfiles/VC14/ (wesnothlib.vcxproj wesnothlib.vcxproj.filters): Move compiled serialisation objects into the dedicated directory for consistency https://github.com/wesnoth/wesnoth/commit/8c7b3a583bbf667b35f17c5b7364c8e6f2935068 20190124 01:26:50< irker629> wesnoth: Wedge009 wesnoth:1.14 2266cac211e3 / projectfiles/VC12/ (wesnoth.vcxproj wesnoth.vcxproj.filters): Use ogg/vorbis DLLs rather than static libraries. https://github.com/wesnoth/wesnoth/commit/2266cac211e311f19a2dae22bbc63b0f2455a2d9 20190124 01:26:52< irker629> wesnoth: Wedge009 wesnoth:1.14 1f0fcf1be4a2 / projectfiles/VC12/ (wesnothlib.vcxproj wesnothlib.vcxproj.filters): Tidy the filters. https://github.com/wesnoth/wesnoth/commit/1f0fcf1be4a210783ec9294028750749a27658ac 20190124 01:34:22< irker629> wesnoth/wesnoth:master nemaara fab9f6f351 TRoW S15: do not fire victory text upon AppVeyor: 2/4 builds failed 20190124 01:34:23< irker629> Details vs2015/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/21841463 20190124 01:34:24< irker629> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/21841467 20190124 01:54:56< irker629> wesnoth/wesnoth:master nemaara 40bf6a2965 TRoW S17d: do not kill bats upon victory AppVeyor: 2/4 builds failed 20190124 01:54:57< irker629> Details vs2015/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/21842062 20190124 01:54:58< irker629> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/21842064 20190124 02:08:03<+wesdiscordbot> @Yumi I'm not confident that me playtesting the modified DW Sc12 will be of any use. I walked all over the enemy in that scenario and your changes are unlikely to change that. πŸ˜… 20190124 02:12:11<+wesdiscordbot> okay 20190124 02:13:38<+wesdiscordbot> it's still better for someone to playtest it tho 20190124 02:14:06<+wesdiscordbot> was hopoing you could since you were the one who made that issue, but I don't mind merging it as is 20190124 02:17:46<+wesdiscordbot> I'm already applying the changes to nightmare, I'm just warning you that it might be less useful than expected. 20190124 02:17:57<+wesdiscordbot> I don't mind 20190124 02:18:01< irker629> wesnoth/wesnoth:master nemaara 512221a8ca TRoW S22: give cuttlefish loyal marker AppVeyor: 2/4 builds failed 20190124 02:18:02< irker629> Details vs2015/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/21842542 20190124 02:18:03< irker629> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/21842544 20190124 02:18:23<+wesdiscordbot> the goal isn't for it to be hard for an experienced player, just for it to be reasonable for a newer one 20190124 02:18:34<+wesdiscordbot> it doesn't seem like DW is meant to be a hard campaign, at least to me 20190124 02:19:26<+wesdiscordbot> My problem is more like I have too much gold and units to struggle there. xD 20190124 02:41:19<+wesdiscordbot> So...they are certainly stronger reinforcements, but they arrive too late to do anything. 20190124 02:41:43<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/537824288825147402/DW-Revenge_replay.gz 20190124 02:43:36<+wesdiscordbot> And it's was absolutely possible to win (at least with the units and gold I had), even if I'd decided to defeat the reinforcements first. 20190124 02:44:36<+wesdiscordbot> @Yumi ^ 20190124 02:46:17<+wesdiscordbot> Maybe move them forward some turns? The reduced gold probably resulted in the ai running out of units faster. 20190124 02:47:14<+wesdiscordbot> okay 20190124 02:47:15<+wesdiscordbot> turn 8 20190124 02:47:18<+wesdiscordbot> well turn 9 20190124 02:48:12<+wesdiscordbot> the thing is the shadows will be invisible if reinforcements arrive at night :thonk: 20190124 02:49:00<+wesdiscordbot> I guess turn 8 is dawn 20190124 02:49:02<+wesdiscordbot> should be okay 20190124 02:49:57<+wesdiscordbot> I'll say you playtested it now 20190124 02:50:09<+wesdiscordbot> or you can just put a comment on github if you like 20190124 03:02:22<+wesdiscordbot> You can say it. And I only playtested on nightmare. ^^ 20190124 03:02:44<+wesdiscordbot> that's fine 20190124 03:03:58<+wesdiscordbot> I'm contradicting myself. 20190124 03:04:03<+wesdiscordbot> I need sleep. xD 20190124 03:04:06<+wesdiscordbot> Good night. 20190124 03:09:00<+wesdiscordbot> lol 20190124 03:09:01<+wesdiscordbot> gn 20190124 04:48:05-!- Punsaker is now known as Polsaker 20190124 04:55:13< irker629> wesnoth/wesnoth:master nemaara 09a1ad785b DW S12: rebalance ai gold values AppVeyor: 2/4 builds failed 20190124 04:55:14< irker629> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/21846028 20190124 04:55:15< irker629> Details vs2015/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/21846029 20190124 05:03:46< wedge009> Hmm, reading through the last few days' log, seems I could have stopped some problems if I paid attention. Sorry about that. ): 20190124 05:03:51< wedge009> jyrkive: Not sure why I missed your ping, but you should see I've already merged. 20190124 05:04:37< wedge009> And I only just saw your note about the DLL names. I'll have to double-check that as I built the DLLs ages ago when I was first playing around with that vorbisfile stuff. 20190124 05:05:04< wedge009> At any rate, I'm running okay with those builds at the moment (else I wouldn't have pushed them). 20190124 05:12:24<+wesdiscordbot> I wonder how it's even possible that 1.14 builds are passing at the moment. I coimmitted statically linked libogg and libvorbis to the external repo and there is _static in the .lib file names. 20190124 05:12:43<+wesdiscordbot> Whereas you changed the project file to link to files without _static. 20190124 05:14:09<+wesdiscordbot> odd... very odd 20190124 05:15:27<+wesdiscordbot> Okay, I see how. Wedge added dynamically linked libraries to the repo on his own. 20190124 05:15:49<+wesdiscordbot> He could remove the statically linked ones though. They aren't being used for anything. 20190124 05:16:30<+wesdiscordbot> We definitely need to find a better hosting for these lib builds 20190124 05:16:35<+wesdiscordbot> Git is bad 20190124 05:16:49<+wesdiscordbot> ANy ideas? 20190124 05:17:38<+wesdiscordbot> Microsoft Azure Blob Storage? 20190124 05:18:50<+wesdiscordbot> (At work I have sometimes worried about the possibility that our mobile game might exceed the 100MB size limit allowed for Android apps, in which case we'd have to implement downloading additional assets from a CDN. Azure Blobs has looked like a reasonable option for that purpose.) 20190124 05:19:10<+wesdiscordbot> We could also put them on our own server, or Sourceforge. 20190124 05:19:26<+wesdiscordbot> But honestly I'm very meh about the fact that we continue to use SF at all 20190124 05:20:31<+wesdiscordbot> Yes, the area of ad-injection is behind us, but the whole site just has this feel of one of those places where you're not entirely sure if what you're downloading is legit, YKWIM? 20190124 05:22:14<+wesdiscordbot> No, I don't really get that feeling when I download stuff from there. 20190124 05:22:27<+wesdiscordbot> hm 20190124 05:22:49<+wesdiscordbot> maybe just me, then 20190124 05:24:28<+wesdiscordbot> What's so special about blob storage? 20190124 05:24:38<+wesdiscordbot> As opposed to what? 20190124 05:24:43< celmin|away> Blobs! 20190124 05:25:01-!- celmin|away is now known as celmin|sleep 20190124 05:25:05<+wesdiscordbot> I mean, why would you suggest Azure Blob Storage specifically? 20190124 05:25:28<+wesdiscordbot> Like I said, because I had thought about using it as a CDN at work. 20190124 05:26:01<+wesdiscordbot> Our game servers are currently hosted in Microsoft Azure, and using Azure Blobs would keep the CDN in the same service. 20190124 05:26:07< celmin|sleep> There are probably hundreds of CDNs out there though. 20190124 05:26:08<+wesdiscordbot> ahh 20190124 05:28:02<+wesdiscordbot> I wonder if our current hosting is economical πŸ€” 20190124 05:28:14<+wesdiscordbot> never really considered it 20190124 05:29:12< celmin|sleep> I imagine the people who deal with it have considered it quite nicely. 20190124 05:29:28<+wesdiscordbot> no 20190124 05:29:59<+wesdiscordbot> No it is no economical or no it has not been considered? 20190124 05:30:04<+wesdiscordbot> latter 20190124 05:30:25<+wesdiscordbot> I should speak to Dave 20190124 05:31:20<+wesdiscordbot> It was at the time it was purchased (2012), nobody goes back and look and these things 20190124 05:32:16<+wesdiscordbot> We were paying a random for a far inferior server at the time which wasn't that expensive when we started in 2008 20190124 05:32:24<+wesdiscordbot> So bear that in mind 20190124 05:42:01< irker629> wesnoth/wesnoth:1.14 Wedge009 8b6e0ff8bd Secrets of the Ancient: Right click -> R AppVeyor: 2/4 builds failed 20190124 05:42:02< irker629> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/21846871 20190124 05:42:03< irker629> Details vs2015/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/21846872 20190124 05:44:41< wedge009> jyrkive: I thought about removing the static libraries but wasn't sure if they were being used elsewhere. 20190124 05:45:46< wedge009> I do feel a bit iffy about sourceforge.net as well, given past behaviour and the mirror system that doesn't seem to work quite right. But it does seem like things have improved a bit as well - I haven't paid too much attention to the news. 20190124 06:05:11<+wesdiscordbot> SourceForge has been working mostly fine for me lately. I even have a project of mine there. 20190124 06:05:38<+wesdiscordbot> ("Mostly" = they have had some issues with SVN repoisitories. I was unable to make commits for a few days.) 20190124 06:05:46<+wesdiscordbot> *repositories 20190124 07:13:01-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20190124 08:32:16< irker629> wesnoth/wesnoth:master Wedge009 8c7b3a583b Move compiled serialisation objects into AppVeyor: All builds passed 20190124 10:07:20< irker629> wesnoth/wesnoth:master nemaara 5f1a933110 DW S12: moved enemy reinforcements a bit AppVeyor: vs2017/Release Failed 20190124 10:07:21< irker629> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/21848873 20190124 11:13:18< irker629> wesnoth/wesnoth:1.14 Wedge009 1f0fcf1be4 Tidy the filters. AppVeyor: All builds passed 20190124 12:48:59< irker629> wesnoth/wesnoth:1.14 Wedge009 8ed7c0dacc Son of the Black-Eye: northlands -> Nort AppVeyor: All builds passed 20190124 13:38:50-!- celmin|sleep is now known as celmin|away 20190124 14:07:12< irker629> wesnoth/wesnoth:1.14 Wedge009 7aa3ed5c51 Son of the Black-Eye: northlands -> Nort AppVeyor: All builds passed 20190124 14:23:36-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 250 seconds] 20190124 15:07:20< irker629> wesnoth/wesnoth:master nemaara 5f1a933110 DW S12: moved enemy reinforcements a bit AppVeyor: 1/4 builds failed 20190124 15:07:21< irker629> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/21848873 20190124 16:42:51-!- smiley` [mlsmiley@gateway/shell/xshellz/x-xvapvbldgnbvaqpg] has quit [Ping timeout: 252 seconds] 20190124 17:50:47-!- smiley- [mlsmiley@gateway/shell/xshellz/x-omzugtzvtvdbalmb] has joined #wesnoth-dev 20190124 17:52:23-!- smiley- is now known as smiley` 20190124 17:55:16<+wesdiscordbot> I don't see anything wrong with using sourceforce for hosting our SDKs 20190124 18:07:25-!- irker629 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20190124 18:07:25-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190124 18:14:53-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20190124 18:15:00-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 250 seconds] 20190124 18:15:01-!- wedge010 is now known as wedge009 20190124 19:51:21-!- LovCAPONE [LovCAPONE@gateway/vpn/privateinternetaccess/lovcapone] has joined #wesnoth-dev 20190124 19:52:08< LovCAPONE> Q. I would like to work on issue #3862. Is there a way to indicate that this issue is assigned to me, so that others know that someone's working on it? 20190124 19:57:06< Soliton> can you not assign it to yourself? 20190124 20:00:44< LovCAPONE> Ok I wasn't sure we could freely do this. I thought maybe it has to be approved by someone. Ok thanks 20190124 20:05:34<+wesdiscordbot> I didnt mention it in text, but from the screenshot it is also visible that #textdomain comments are considered parts of description 20190124 20:09:52< LovCAPONE> Ravana: Ok thanks, noted. 20190124 20:23:52<+wesdiscordbot> whee 20190124 20:23:53<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/538091584856522762/unknown.png 20190124 20:24:34<+wesdiscordbot> I'm unsure how to go about the protocol addition to [error]/[warning]/[message] server responses 20190124 20:25:52-!- valdar [~atarocch@93.56.172.28] has quit [Ping timeout: 250 seconds] 20190124 20:26:11<+wesdiscordbot> I added an extra string attribute extra_data which contains the remaining ban duration (NOT the end time) as a time_t value, but perhaps we could decide to include even more information about some server events (not necessarily bans), so perhaps it should be an [extra_data] child tag instead? 20190124 20:26:48<+wesdiscordbot> Perhaps loonycyborg and/or Soliton have an opinion? 20190124 20:28:49-!- Ravana [~Ravana@wesnoth/mp-mod/ravana] has joined #wesnoth-dev 20190124 20:29:12< Soliton> i don't mind much either way. we could just as well add more attributes later? 20190124 20:30:11< Soliton> a more specific name than extra_data might be good though. 20190124 20:30:31< Soliton> so if you want to put that in a tag extra_data that makes sense. 20190124 20:30:59< Soliton> as in [extra_data] remaining_time= or so 20190124 20:31:04< loonycyborg> can you just have ban_duration attribute? 20190124 20:31:08<+wesdiscordbot> The function used to send this info is generic and used everywhere, that's why I didn't want want to name it ban_duration or so: async_send_error(socket_ptr socket, const std::string& msg, const char* error_code, const std::string& extra_data) 20190124 20:31:38< Soliton> yeah, a child tag with properly named attributes sounds good then. 20190124 20:34:13< loonycyborg> anyway it's fine either way 20190124 20:36:36< loonycyborg> Also I don't see this interface as ideal, mostly it got inherited from old wesnothd. I'd myself would prefer to have objects for each kind of error that would have virtual method to convert it to wml that gets sent to wire 20190124 20:37:28<+wesdiscordbot> That sounds horribly inefficient code-wise without LTO 20190124 20:38:11< Soliton> an async_* method got inherited from before asio was used? impressive! ;-) 20190124 20:38:13< loonycyborg> so it would be something like async_send_error(socket, client_banned_error{message, duration}) 20190124 20:38:20< loonycyborg> no 20190124 20:38:27<+wesdiscordbot> Because that means that you'd have a different block of code to produce the WML for each individual possible error the server can emit 20190124 20:38:33< loonycyborg> I followed pattern of different function that was there before 20190124 20:39:06< loonycyborg> not necessarily 20190124 20:39:20< loonycyborg> just a separate block of code for each kind of error 20190124 20:39:27< loonycyborg> and kinds could be pretty generic 20190124 20:39:27<+wesdiscordbot> (I think you know by now that I'm not a fan of abusing templates or OO design in C++ code) 20190124 20:39:46<+wesdiscordbot> loonycyborg what you just said is exactly what I said 20190124 20:41:21-!- LovCAPONE [LovCAPONE@gateway/vpn/privateinternetaccess/lovcapone] has quit [Quit: Life is like a void pointer: you never know what you're going to get...] 20190124 20:43:29<+wesdiscordbot> Also from a design perspective I feel like I shouldn't have to inform a centralized database of errors that I just decided that wesnothd should be able to respond with a "client is on fire and has a hand stuck in a bear trap while the facility is flooding" error. That's my biggest pet peeve with the current IRC-inspired numeric codes system we use (although its real purpose is to make it simpler to internationalize server 20190124 20:43:29<+wesdiscordbot> responses). 20190124 20:44:17<+wesdiscordbot> The general idea of genericizing each possible server response brings to mind Microsoft's silly system for signaling grave kernel errors 20190124 20:44:25< loonycyborg> there's another way then 20190124 20:44:38< loonycyborg> could extend that function to take wml itself 20190124 20:44:44< loonycyborg> rather than message and code 20190124 20:45:17< loonycyborg> and have some helpers that could make wml for errors you need 20190124 20:45:33< loonycyborg> but which would allow you to intercept and fixup wml 20190124 20:45:39<+wesdiscordbot> I'm currently writing the interface so that the contents of the [info] subtag (what was originally going to be extra_data) are generated from a string map 20190124 20:46:48<+wesdiscordbot> Since as far as I understand the server is supposed to avoid constructing and dealing with regular WML config objects in any hot code paths 20190124 20:48:14<+wesdiscordbot> (ignoring for a moment the issue of simple_wml being conceived long before we had C++11 and move semantics. although even with that in mind sometimes I look at config's and its children classes and I wonder if our current approach is really the best we could do) 20190124 20:53:44<+wesdiscordbot> Can someone remind me where I'm allowed to use auto in our code base? 20190124 20:54:00< loonycyborg> in master definitely 20190124 20:54:12< loonycyborg> because we require C++11 at least 20190124 20:54:27<+wesdiscordbot> That's not what I'm asking. 1.14 requires C++11 and master C++14 20190124 20:55:10<+wesdiscordbot> Everything in https://wiki.wesnoth.org/CodingStandards sounds like it was never updated after the C++11 transition 20190124 20:56:02<+wesdiscordbot> My question is in what contexts auto is considered acceptable practice 20190124 20:56:28< loonycyborg> well it mandates nullptr so it's c++11 aware at least 20190124 20:56:45<+wesdiscordbot> Not enough 20190124 20:56:50-!- irker253 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20190124 20:56:50< irker253> wesnoth/wesnoth:1.14 Steve Cotton 266749a212 LoW S22: Single-player objectives should AppVeyor: vs2015/Release Failed 20190124 20:56:50< irker253> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/21869402 20190124 20:57:22<+wesdiscordbot> You can even see that it says C++14 is not allowed even though that stopped being the case in master per our dictator's mandate 20190124 21:02:11< loonycyborg> so currently we allow c++14 and c++17 code in #ifdef HAVE* blocks atm? 20190124 21:02:27< loonycyborg> HAVE_CXX14 HAVE_CXX17 20190124 21:02:42< loonycyborg> seems global.hpp has some detection logic for compiler version 20190124 21:02:48< loonycyborg> features supported at least 20190124 21:03:53<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/538101656638849036/unknown.png 20190124 21:07:01< loonycyborg> ah yes 20190124 21:07:08< loonycyborg> master has c++14 as default 20190124 21:08:51< loonycyborg> while 1.14 requres c++11 20190124 21:09:41< loonycyborg> anyway, I have no idea atm what guidelines about auto should be 20190124 21:10:30<+wesdiscordbot> @Vultraz 20190124 21:11:10<+wesdiscordbot> πŸ€” 20190124 21:11:14<+wesdiscordbot> Hmmmmmmm 20190124 21:11:59<+wesdiscordbot> Perhaps I messed this up 20190124 21:12:12<+wesdiscordbot> Do we still support Vs2013? 20190124 21:12:18<+wesdiscordbot> In 1,14? 20190124 21:12:40<+wesdiscordbot> Because it’s very possible I fucked up and thought 1.14 was on c++14 while master was 17 20190124 21:12:51<+wesdiscordbot> While in reality 1.14 is 11 20190124 21:12:59<+wesdiscordbot> And master is c++14 20190124 21:18:22< loonycyborg> anyway I corrected that wiki page 20190124 21:18:31<+wesdiscordbot> @shadowm I typically use auto in cases where type names are super-long or redundant. For example: cpp std::shared_ptr foo = std::make_shared(a, b); It's much cleaner just to use auto since the type is readily apparently by the rvalue. 20190124 21:19:00<+wesdiscordbot> Can I auto a range-for loop's variable? 20190124 21:19:19<+wesdiscordbot> Which currently looks like this: cpp for(const std::pair& kv : info) { node.set_attr_dup(kv.first.c_str(), kv.second.c_str()); } 20190124 21:20:00<+wesdiscordbot> I do that extensively 20190124 21:20:05< loonycyborg> sure 20190124 21:20:10<+wesdiscordbot> for(const auto& has 285 hits in 1.14 20190124 21:20:15< loonycyborg> const auto&kv would be a lot better 20190124 21:20:16<+wesdiscordbot> Okay 20190124 21:22:03-!- valdar [~atarocch@93.56.172.28] has joined #wesnoth-dev 20190124 21:22:33<+wesdiscordbot> In fact I usually do that regardless of whether the type name in the loop is long or not 20190124 21:22:44<+wesdiscordbot> But most especially when iterating over maps 20190124 21:24:50<+wesdiscordbot> I wonder if I'm allowed to call translation::dsgettext() as soon as log functions are available? 20190124 21:25:26<+wesdiscordbot> Or more precisely, what happens if I call that before i18n has been set up? 20190124 21:27:58<+wesdiscordbot> I'm not sure 20190124 21:28:03<+wesdiscordbot> Might crash 20190124 22:12:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190124 22:13:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190124 22:13:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190124 22:15:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190124 22:18:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190124 22:20:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190124 22:27:33-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190124 22:29:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190124 22:30:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190124 23:07:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190124 23:41:26<+wesdiscordbot> soliton: what are our server specs? 20190124 23:57:52-!- irker253 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] --- Log closed Fri Jan 25 00:00:19 2019