--- Log opened Thu Mar 29 00:00:20 2018 20180329 00:04:07<+discordbot> @Vultraz You already knew Dave tried porting Wesnoth to use OGL once. Literally, I explained that attempt to you. 20180329 00:04:10<+discordbot> At least once. 20180329 00:04:23<+discordbot> i knew he had, yes. 20180329 00:04:37<+discordbot> I just didn't realize it was still in the repo. 20180329 00:05:21<+discordbot> Since last night i was thinking it amusing we now have an opengl branch on top of the 2010 ogl branch, and this morning I run a git pull and notice that we also have the old wesnoth-gl branch 20180329 00:09:05-!- grzywacz [~karol@89-70-226-147.dynamic.chello.pl] has quit [Ping timeout: 248 seconds] 20180329 00:18:06< celticminstrel> So what's up with the OpenGL stuff anyway. 20180329 00:18:23< celticminstrel> I did see a branch, and GLEW has been added to dependencies... 20180329 00:22:23<+discordbot> IIRC jyrkive said he's going to start working on getting the helper/wrapper stuff done, so everything else going forward will be simpler, which will take about a month. 20180329 00:23:00< celticminstrel> FTR I also have some helper stuff written on wesnoth-ipf. 20180329 00:23:12< celticminstrel> I dunno if it's worth taking it or not. 20180329 00:24:04< celticminstrel> https://github.com/CelticMinstrel/wesnoth-ipf/blob/master/shader.hpp 20180329 00:26:12< celticminstrel> Doesn't support other types of shaders, mind you, like geometry shaders (not sure if we have any use for those though). 20180329 00:28:03< celticminstrel> C++ typedefs for OGL types: https://github.com/CelticMinstrel/wesnoth-ipf/blob/master/utils.hpp 20180329 00:28:50< celticminstrel> (The other stuff in that file probably isn't relevant.) 20180329 00:30:53-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 276 seconds] 20180329 01:03:51< irker752> wesnoth: Wedge009 wesnoth:master fb866c6d1310 / data/core/units.cfg utils/pofix.py: 'moreso' isn't a word in any dialect of English. https://github.com/wesnoth/wesnoth/commit/fb866c6d1310d8398f0f481a8ab16b1606286cdd 20180329 01:05:58<+discordbot> wedge009: more like it's an informal one. 20180329 01:06:15< celticminstrel> It's not a word, it's two. 20180329 01:06:31< wedge009> True, but it goes against the formal nature of the context so I felt it best to correct it. 20180329 01:06:49< wedge009> As opposed to only correcting in the localisation. 20180329 01:06:55<+discordbot> fair enough 20180329 01:11:47-!- gfgtdf_ [~chatzilla@x4e363747.dyn.telefonica.de] has joined #wesnoth-dev 20180329 01:14:26-!- gfgtdf [~chatzilla@x4e36815a.dyn.telefonica.de] has quit [Ping timeout: 276 seconds] 20180329 01:14:27-!- gfgtdf_ is now known as gfgtdf 20180329 01:35:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180329 01:35:13-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180329 01:59:29-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180329 02:03:22< celticminstrel> I think the aspect issue might be a bug in the [switch] / [filter_wml] implementation. 20180329 02:10:43< celticminstrel> So, I think what's going on is the way [or] is being used. 20180329 02:11:00< celticminstrel> I add a new [or] tag for each possible key=value in the [switch]. 20180329 02:11:21< celticminstrel> And [or] tags are handled by the filter by "if matches, pass". 20180329 02:12:30< celticminstrel> [filter_wml] returns true at the end, though. 20180329 02:12:55< celticminstrel> And actually it would never even reach the [or] if the main filter failed on any attributes... 20180329 02:13:05< celticminstrel> So basically [or] in [filter_wml] is broken, I guess... 20180329 02:13:25< celticminstrel> IIRC [not] was already supported and [and] shouldn't have any issues. 20180329 02:13:36< celticminstrel> But [or] just does not work as intended. 20180329 02:13:48<+discordbot> are you referring to actual behavior? 20180329 02:13:50< celticminstrel> I think this is in the 1.14 branch, even. 20180329 02:13:57 * celticminstrel checks, 20180329 02:14:11<+discordbot> yes 20180329 02:14:17<+discordbot> but you just added [and]and[or] support 20180329 02:14:21<+discordbot> to [filter_wml] 20180329 02:14:30<+discordbot> for 1.13.12 20180329 02:14:39< celticminstrel> Right. The [and] should work but I think [or] is broken. 20180329 02:14:55< celticminstrel> Basically a WMl filter works like this: 20180329 02:15:15< celticminstrel> 1. Check all the keys in the filter against the config. If any of the keys is missing or doesn't have the proscribed value, fail immediately. 20180329 02:15:23< celticminstrel> (That's already antithetical to [or].) 20180329 02:15:50< celticminstrel> 2. Run through all the tags in the filter. 20180329 02:16:20< celticminstrel> 2a. For [not], return false if the sub-filter matches the main config. 20180329 02:16:39< celticminstrel> 2b. For [and], return false if the sub-filter doesn't match the main config. 20180329 02:16:53< celticminstrel> 2c. For [or], return true if the sub-filter matches the main config. 20180329 02:18:07< celticminstrel> 2d. For any other tag, search for the same tag in the main config and match that tag against the sub-filter. If it fails for every tag of the particular name, or there are no tags of that name, return false. 20180329 02:18:13< celticminstrel> 3. Return true. 20180329 02:19:01< celticminstrel> That's interesting actually, I somehow assumed the subtag matching would work like merge syntax, but it doesn't. 20180329 02:20:20< celticminstrel> I guess the best fix would be to never try to short-circuit? 20180329 02:20:48< celticminstrel> Probably can't fix this on 1.14; we'll just note it's broken or something? 20180329 02:21:02< celticminstrel> I don't think there's actually any way to get an [or] to work. 20180329 02:21:31< celticminstrel> It'll just always match, unless the main filter fails. I think. 20180329 02:24:49<+discordbot> You can fix it for 1.14 20180329 02:24:51< celticminstrel> It's possible [and] is actually useless on 1.14, too, not sure. 20180329 02:25:03< celticminstrel> So it might be easiest to just revert the commit for 1.14. 20180329 02:25:35< celticminstrel> [and] should be useful once I add pattern matching though. Maybe not super-useful, but not totally useless either. 20180329 02:26:24< celticminstrel> I can't think of any way that [and] would be useful with the way it is now, though. It's essentialy the default if you don't use [not], so using it doesn't do anything except maybe clarify your intent, at most. I think. 20180329 02:27:03< celticminstrel> Unless someone can come up for a use for [and] that doesn't work without it. 20180329 02:27:36< celticminstrel> I mean, the fix for [or] would be useful, of course. 20180329 02:27:50< celticminstrel> So I could either revert the commit or fix [or]. 20180329 02:27:59< celticminstrel> I think I know what Vultraz thinks, but what about other people? 20180329 02:28:11< celticminstrel> (In case you missed context, this is in [filter_wml] and similar places.) 20180329 02:28:59< Ravana_> I thought you were expected to use [or] around all cases, so step 1 would not have any keys to check 20180329 02:29:41< celticminstrel> Even if you do that, it still returns true at the very end, which is when none of the [or] tags matched. 20180329 02:30:29-!- Bonobo [~Bonobo@203.220.138.198] has quit [Ping timeout: 276 seconds] 20180329 02:37:11< celticminstrel> On a totally related not, it'd be great if someone would write config visualizers for Visual Studio and Xcode. 20180329 02:37:30< celticminstrel> (Though having a boost::optional visualizer would be sufficient... I thought I had one but it doesn't seem to be working.) 20180329 02:37:34< celticminstrel> ^note 20180329 02:39:15< irker752> wesnoth/wesnoth:1.14 Martin Hrubý dc174fb10a Updated Xcode's README.md AppVeyor: All builds passed 20180329 02:40:56<+discordbot> visualizers? 20180329 02:41:13< celticminstrel> For displaying values in the debugger. 20180329 02:41:26<+discordbot> they're displayed in 2017? 20180329 02:41:44< celticminstrel> Sure they're displayed, but not in a nice way. 20180329 02:42:07< celticminstrel> With a visualizer you could see a simple list of keys followed by the ordered list of tags, for example. 20180329 02:42:23< celticminstrel> Right now you just see the keys map and the values map and have to expand those to get a closer look. 20180329 02:45:16< celticminstrel> Don't all the filters actually have that problem with [or] tags? 20180329 02:45:29< celticminstrel> I mean if you wrap everything in an [or] tag with nothing in the root filter. 20180329 02:45:35< celticminstrel> The root filter will match, right? 20180329 02:45:42< celticminstrel> And as a result, the [or] filters won't matter. 20180329 02:46:29< celticminstrel> I think you need something in the root filter for [or] to work at all. 20180329 02:46:48<+discordbot> i'd still like us to consider switching to a JSON parser at some point. 20180329 02:46:50<+discordbot> meh 20180329 02:47:39< celticminstrel> "don't fix what's not broken" 20180329 02:49:31<+discordbot> Of course you'd say that 20180329 02:50:09< celticminstrel> IMO there is really nothing wrong with WML as a data format. 20180329 02:50:22< celticminstrel> Though the preprocessor is not the best idea, it's not that bad either. 20180329 02:51:13< celticminstrel> Ignoring the preprocessor, I would say WML is about equal with XML, YAML, JSON in most ways. 20180329 02:51:22<+discordbot> It's annoying to type closing tags. 20180329 02:51:26< celticminstrel> And probably superior to JSON/XML. 20180329 02:51:43<+discordbot> But it's not the frontend that's the problem. 20180329 02:51:50< celticminstrel> Definitely superior to XML, JSON might be debatable. 20180329 02:51:55<+discordbot> I'm talking about the config class. 20180329 02:51:58< celticminstrel> What? 20180329 02:53:18<+discordbot> I have the strangest sense of deju-vu that we've had this exact conversation before 20180329 02:53:23<+discordbot> at the same time of day, even 20180329 02:54:08< celticminstrel> Totally possible. 20180329 02:58:50<+discordbot> I lament that our config class is rather feature-sparse, especially compared to something like nlohmann's JSON library. And I wonder it would not simplify our codebase to rely on a 3rd party tool for parsing, serialization, data storage, and network packing (simple wml). 20180329 03:01:02< celticminstrel> Feature-sparse how, exactly? 20180329 03:01:23< celticminstrel> To me it feels like it has a lot of features (though some are a bit questionable). 20180329 03:03:24-!- gfgtdf [~chatzilla@x4e363747.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 52.7.3/20180322140748]] 20180329 03:06:26<+discordbot> Well again, look at the feature-set of the above library: https://github.com/nlohmann/json (yes, I've linked it to you before). With that, you get stuff like STL container-like access, built-in list storage (so we wouldn't have to be using utils::split all the time, you can convert to/from STL containers without manual parsing, you can specify arbitrary type conversions to/from JSON instead of doing manual parsing, it supports 20180329 03:06:26<+discordbot> conversion to CBOR, MessagePack, and UBJSON (of which I know nothing, but they said they're efficient binary formats good for data exchange, which would be good since ya know, MP). 20180329 03:07:24< celticminstrel> Well, we could pretty easily add built-in list support to the config class IMO. 20180329 03:07:36<+discordbot> Yeah. 20180329 03:07:42< celticminstrel> Basically just add a converter that calls split() for you. 20180329 03:07:46<+discordbot> And it's the exact opposite of feature-sparse right now. 20180329 03:07:57< celticminstrel> Maybe multiple converters. 20180329 03:08:27<+discordbot> In fact if it weren't a chronic victim of featuritis we wouldn't have ended up with the obnoxious "missing WML child yet unchecked for" error. 20180329 03:08:34<+discordbot> Or whatever the message actually says. 20180329 03:08:45< celticminstrel> IMO we should nuke that from orbit. 20180329 03:08:57< celticminstrel> By which I mean "remove it and follow through all the consequences". 20180329 03:09:11<+discordbot> There's also a load of stuff vultraz takes for granted which used to not exist at all. 20180329 03:09:35< celticminstrel> Like the iterators weren't bidirectional before I came along IIRC? 20180329 03:09:39<+discordbot> Before 1.9.x all WML values were stored as plain strings. 20180329 03:09:42< celticminstrel> Not that we make much use of that I guess. 20180329 03:10:11<+discordbot> Converting them to specific data types had to be done by hand and they were still internally stored as strings anyway. 20180329 03:11:17<+discordbot> *1.7.x 20180329 03:11:18<+discordbot> 🤔 20180329 03:11:52<+discordbot> It was partially an optimization, partially necessitated by the Lua interpreter code. 20180329 03:13:15<+discordbot> Unfortunately the up-to-eleven std::map::operator[]() semantics have remained a constant throughout its entire lifetime. 20180329 03:13:52<+discordbot> Including the aberrant const call behaviour. 20180329 03:14:08< celticminstrel> Hm? 20180329 03:14:50<+discordbot> operator[]() being able to do things it shouldn't when called on a const object. 20180329 03:15:04-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev 20180329 03:15:11<+discordbot> Namely, retrieving a reference to a dummy value. 20180329 03:15:30<+discordbot> Instead of the const object version of the method not existing in the first place. 20180329 03:15:45<+discordbot> And forcing people to think before they demand things from a config object. 20180329 03:16:08<+discordbot> It's kind of firmly ingrained in WML's design I guess. 20180329 03:18:51<+discordbot> alright, I guess it's inaccurate to say config is feature-sparse 20180329 03:19:16-!- Bonobo [~Bonobo@129.127.113.29] has joined #wesnoth-dev 20180329 03:22:39<+discordbot> But I definitely think it's worth it (for a 1.18 target, or something, definitely not 1.16. Plate too full.) to consider whether A: what we want couldn't be done better by a library such as the above, B: whether we want any of the additional features (binary representation seems especially useful) offered by such a library, and C: whether it would be more work, too difficult, or increase maintainability cost to implement such 20180329 03:22:40<+discordbot> things ourselves. 20180329 03:23:01<+discordbot> WML used to have a binary serialization. 20180329 03:23:09<+discordbot> Oh? 20180329 03:23:17<+discordbot> Yeah, you missed that boat too, naturally. 20180329 03:23:33<+discordbot> What happened that we ended up with SimpleWML? 20180329 03:23:46-!- Bonobo [~Bonobo@129.127.113.29] has quit [Ping timeout: 264 seconds] 20180329 03:24:17<+discordbot> Save compression, and compressed WML transfers over the network used to involve the binary WML serialization before version 1.5.x (this doesn't have anything to do with simplewml, the latter was created by Dave in order to address inefficiencies in wesnothd for version 1.3.x). 20180329 03:25:12<+discordbot> 1.5.x introduced zlib support, which yielded far better savings than the binary serialization and rendered the latter pointless and redundant to have. 20180329 03:25:19<+discordbot> It was gradually phased out. 20180329 03:25:58<+discordbot> Interesting..... 20180329 03:26:31< celticminstrel> So which do you think is better to match the absence of a key in [filter_wml]? 20180329 03:26:34<+discordbot> Well, that's another thing to consider. 20180329 03:26:49< celticminstrel> Something like [__missing]key=yes? 20180329 03:27:02<+discordbot> Ew, double underscore prefixes. 20180329 03:27:04< celticminstrel> Or something more like key__missing=yes or __missing_key=yes? 20180329 03:27:18<+discordbot> You're triggering formatting again 20180329 03:27:19< celticminstrel> Or something more like key=__missing? 20180329 03:27:45< celticminstrel> Just assume that formatting boundaries are a double underscore or something, Vultraz. 20180329 03:28:10< celticminstrel> OR 20180329 03:28:10<+discordbot> I feel like [filter_wml] merits a whole grammar of its own tbh. 20180329 03:28:10-!- Bonobo [~Bonobo@129.127.113.29] has joined #wesnoth-dev 20180329 03:28:40< celticminstrel> Would it be better to not add explicit support for it and then you can do [not][__pattern]key=* ? 20180329 03:29:15< celticminstrel> Or maybe __pattern_key=* or some other magic key name rather than a subtag. 20180329 03:34:20< celticminstrel> Basically I want to add a way to match a glob against the key values. 20180329 03:34:53< celticminstrel> Another possible syntax is [__glob]key=thing value=stuff 20180329 03:35:26< celticminstrel> Which would allow globbing against keys too, though that's a bit more work (requires iterating the entire source config's attribute map, where currently it only iterates the filter's attribute map). 20180329 03:35:42< celticminstrel> So what's the preferred syntax here? 20180329 03:36:09< celticminstrel> Note that magic keys of both types mentioned here are already precedented in the merge syntax (which supports __delete as well as add_to_*). 20180329 03:36:54< celticminstrel> Maybe glob_on_*=*? 20180329 03:37:33< celticminstrel> If we have glob then we can match the absence of a key by wrapping a glob in a [not], so maybe we don't need the specific support for lack of a key. 20180329 04:03:04< irker752> wesnoth/wesnoth:master Victor Sergienko 004d7b541b Credits for Chinese translation of iOS a AppVeyor: All builds passed 20180329 04:08:04< wedge009> Does anyone else find that the test scenario for 1.14 branch crashes? 20180329 04:23:57-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180329 04:24:03-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180329 04:24:57-!- Bonobo [~Bonobo@129.127.113.29] has quit [Ping timeout: 264 seconds] 20180329 04:25:14< irker752> wesnoth: Celtic Minstrel wesnoth:schema 42016b8bf811 / src/config.cpp: Fix [filter_wml] implementation so that [or] tags actually work https://github.com/wesnoth/wesnoth/commit/42016b8bf81107d1c3ece86d7dd48d6f5fabd7e4 20180329 04:25:15< irker752> wesnoth: Celtic Minstrel wesnoth:schema 50e78a4d9e87 / src/serialization/tag.cpp: Schema: Fix [switch] implementation https://github.com/wesnoth/wesnoth/commit/50e78a4d9e87f5715356a45b4052477a9762c356 20180329 04:25:17< irker752> wesnoth: Celtic Minstrel wesnoth:schema a9f8cac83471 / data/schema/units/modifications.cfg: Schema: Fix definition of [effect] tags for removing/modifying attacks https://github.com/wesnoth/wesnoth/commit/a9f8cac83471e9cb3ce9fb38e26c7bf982eece36 20180329 04:25:19< irker752> wesnoth: Celtic Minstrel wesnoth:schema b87970e673b2 / data/schema/ai/ (_main.cfg aspect_complex.cfg goal.cfg stage.cfg): A few more missing pieces to the AI schema https://github.com/wesnoth/wesnoth/commit/b87970e673b224c0bce86f5f5a9a3b6cc5202365 20180329 04:25:22< irker752> wesnoth: Celtic Minstrel wesnoth:schema 38a42231cde9 / src/config.cpp: Add a way in [filter_wml] to match key values against a glob https://github.com/wesnoth/wesnoth/commit/38a42231cde93c2fd3c71eff6dfd827adcdfdfbc 20180329 04:25:23< irker752> wesnoth: Celtic Minstrel wesnoth:schema c76f56fc92ee / data/schema/ai/ (aspect_complex.cfg engine.cfg): Schema: Use the new globbing feature to improve [aspect] definition https://github.com/wesnoth/wesnoth/commit/c76f56fc92ee85e9a3c9113022ada19a10fbd6be 20180329 04:25:25< irker752> wesnoth: Celtic Minstrel wesnoth:schema 149bb51062ae / data/schema/ai/goal.cfg src/serialization/tag.cpp: Schema: Add feature to [switch] to allow a [case] to match the absence of the ke https://github.com/wesnoth/wesnoth/commit/149bb51062aefad5159baf64c9738acae26c43f6 20180329 04:25:37< celticminstrel> I think this is good for today. Didn't get to [modify_ai], but did get pretty much all the other AI config stuff passing. 20180329 04:25:44< celticminstrel> \o/ 20180329 04:26:04< celticminstrel> [modify_ai] is where I really need to stretch the globbing. 20180329 04:26:55< celticminstrel> FTR, if you wish you can cherry-pick 38a42231cde9. It'll be merged in eventually anyway though, so there's not much point in cherry-picking it unless there's an actual release to make. 20180329 04:27:14< celticminstrel> (But I doubt there will be any dev releases on the 1.15 before 1.14 is out, right?) 20180329 04:28:11<+discordbot> correct 20180329 04:28:42<+discordbot> 1.15.0 won't be out for months 20180329 04:29:07< celticminstrel> Oh, right. 42016b8bf811 can be cherry-picked into 1.14 if you want to fix my broken [or]. The alternative is reverting 82fd82d in 1.14. 20180329 04:29:19< celticminstrel> shadowm: Which do you think is better? 20180329 04:30:08< celticminstrel> Basically the commit in question is broken to the point that (as far as I can tell) the added feature doesn't actually do anything useful; with the additional commit, [or] becomes useful (though [and] is still useless). 20180329 04:30:38< celticminstrel> (At least, I'm pretty sure [and] is useless. It does at least work though, so maybe it could have some unusual use cases.) 20180329 04:31:20< celticminstrel> Also, link for the lazy to the commit in question: https://github.com/wesnoth/wesnoth/commit/82fd82d53403b8173d234b8a3abef6a1e3ef39c9 20180329 04:31:38< wedge009> Bleh, must be a timing issue. I don't get any crash in debug mode. 20180329 04:32:23< celticminstrel> ...I just noticed that Appveyor is described as still running on a bunch of really old commits. Someone might want to look into ghat. 20180329 04:32:36< celticminstrel> For example the dunefolk balance commits on 1.14. 20180329 04:32:39< celticminstrel> ^that 20180329 04:33:21 * celticminstrel expects they're not actually still running and merely neglected updating the status on github, but who knows. 20180329 04:34:10-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] 20180329 04:50:07-!- travis-ci [~travis-ci@ec2-54-146-31-248.compute-1.amazonaws.com] has joined #wesnoth-dev 20180329 04:50:09< travis-ci> wesnoth/wesnoth#17306 (schema - 149bb51 : Celtic Minstrel): The build is still failing. 20180329 04:50:09< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/359681501 20180329 04:50:09-!- travis-ci [~travis-ci@ec2-54-146-31-248.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180329 04:55:50<+discordbot> looks like you forgot to mark a base class dtor virtual 20180329 05:03:14< irker752> wesnoth: pentarctagon wesnoth:opengl 3beff6012229 / / (11 files in 5 dirs): Updates cmake and scons to be able to compile with OGL. https://github.com/wesnoth/wesnoth/commit/3beff60122298b9ea3800d1bc0f7453fbc52ed27 20180329 05:03:29<+discordbot> Thanks. 😃 20180329 05:04:00<+discordbot> err... wait, whoops. 20180329 05:04:04<+discordbot> well, that half worked 20180329 05:04:34<+discordbot> that was supposed to go in my fork 20180329 05:05:17<+discordbot> oh well 20180329 05:08:40<+discordbot> It should work for travis at least, though I assume my handling of scons SConstruct is incomplete here: https://github.com/wesnoth/wesnoth/blob/opengl/SConstruct#L420 20180329 05:09:09<+discordbot> would need @loonycyborg probably to comment on what to do for Windows. 20180329 05:11:29<+discordbot> Heh. He had to do that 8 years ago: https://github.com/wesnoth/wesnoth/commit/3e2eba22a96cb2c6c69ee5109059b806f22a372f 20180329 05:11:36<+discordbot> 😛 20180329 05:13:58<+discordbot> well, I can probably just take that then. 20180329 05:14:24<+discordbot> We aren't using GLU, at least not yet. 20180329 05:20:22<+discordbot> pkg-config for gl glew includes -lGLU on its own, interestingly then 20180329 05:24:13-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity] 20180329 05:24:29< irker752> wesnoth: pentarctagon wesnoth:opengl c4ac690f0ff7 / docker/Dockerfile-travis: Remove extraneous apt install. https://github.com/wesnoth/wesnoth/commit/c4ac690f0ff7d214e3d00ef48c7cd20f312f16ed 20180329 05:24:53<+discordbot> will fix the sconstruct in a bit 20180329 05:25:10<+discordbot> the docker image has been updated though 20180329 05:26:10<+discordbot> somewhat surprisingly, removing SDL2_TTF and adding in OpenGL was a net neutral in terms of image size 20180329 05:34:08< irker752> wesnoth: pentarctagon wesnoth:opengl cb2b7e654623 / SConstruct: Remove forgotten environment dump. https://github.com/wesnoth/wesnoth/commit/cb2b7e6546231f861a12cd174ce7209f41a4048b 20180329 05:41:45< irker752> wesnoth: Charles Dang wesnoth:1.14 ccb22a967e85 / projectfiles/VC12/README.md: Updated Visual Studio projectfile readme https://github.com/wesnoth/wesnoth/commit/ccb22a967e85c37e47999d5ecf7c996615182a76 20180329 05:45:25-!- atarocch [~atarocch@93.56.164.28] has quit [Remote host closed the connection] 20180329 05:47:13-!- TheJJ_ [~rofl@ipbcc08bab.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer] 20180329 06:20:17-!- esr [~esr@wesnoth/developer/esr] has quit [Ping timeout: 248 seconds] 20180329 06:21:47<+discordbot> @Vultraz In the 1.14 branch the readme needs to mention that Wesnoth can be compiled with VS2013. 20180329 06:21:56<+discordbot> ah. 20180329 06:24:06< irker752> wesnoth: Charles Dang wesnoth:1.14 9f721189644e / projectfiles/VC12/README.md: We support building with VS 2013 on 1.14 https://github.com/wesnoth/wesnoth/commit/9f721189644e0ca769c27b8fc3a31c8ad360294a 20180329 06:24:28<+discordbot> I didn't occur to me earlier that it's pretty impressive git was able to resolve the cherry-pick from master even though the paths differ 20180329 06:25:37<+discordbot> @hrubymar10 the travis xcode job is still failing - I believe it needs to link with -lGLEW as well as -framework OpenGL. That's what I did for the osx+scons job, at least. 20180329 06:25:51<+discordbot> Because Git tracks contents rather than files. 20180329 06:28:19< irker752> wesnoth: pentarctagon wesnoth:master de48b9fbb133 / .dockerignore: Don't copy the .git directory into docker. https://github.com/wesnoth/wesnoth/commit/de48b9fbb13331a8a38911ee0ece47fd8f95d178 20180329 06:34:02< irker752> wesnoth/wesnoth:1.14 Victor Sergienko 6da3387969 Credits for Chinese translation of iOS a AppVeyor: All builds passed 20180329 06:46:55-!- Bonobo [~Bonobo@203.220.138.198] has joined #wesnoth-dev 20180329 07:11:19< irker752> wesnoth: pentarctagon wesnoth:opengl 92b37d6191a7 / .travis.yml: Re-add travis' notifications. https://github.com/wesnoth/wesnoth/commit/92b37d6191a7f26f49e3fe5bac40bcc157426ea4 20180329 07:21:32<+discordbot> finally got my 1.14 build back up 20180329 07:39:20-!- travis-ci [~travis-ci@ec2-54-146-31-248.compute-1.amazonaws.com] has joined #wesnoth-dev 20180329 07:39:21< travis-ci> wesnoth/wesnoth#17312 (opengl - 92b37d6 : pentarctagon): The build is still failing. 20180329 07:39:21< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/359714847 20180329 07:39:21-!- travis-ci [~travis-ci@ec2-54-146-31-248.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180329 07:39:56<+discordbot> Figuring out how to build Boost is always a joy. 20180329 07:41:36<+discordbot> it's quite dramatic how fast wesnoth loads without addons 🤔 20180329 07:47:43-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev 20180329 07:57:41<+discordbot> @shadowm I can help with building boost, did that many times 20180329 07:58:06<+discordbot> I want to pie the Boost devs in the face. 20180329 07:58:19-!- atarocch [atarocch@nat/redhat/x-hgylrcocgajnryay] has joined #wesnoth-dev 20180329 07:58:41<+discordbot> I can't seem to build Boost.thread with the POSIX thread API, and when I try the Win32 API I get compile-time errors when configuring Wesnoth. 20180329 07:59:14<+discordbot> well for some reason I don't remember having a problem with that 20180329 07:59:29<+discordbot> Yay. 20180329 07:59:47<+discordbot> with which command did you build boost? 20180329 07:59:50<+discordbot> Actually, hang on, Boost needs to use the Win32 API regardless... 20180329 08:00:18<+discordbot> It's GCC that needs to select the POSIX API behind the scenes. 20180329 08:01:16<+discordbot> update-alternatives --config i686-w64-mingw32-gcc 20180329 08:01:16<+discordbot> Okay, that seems to be working. 20180329 08:01:31<+discordbot> Um, I'm using the command directly. 20180329 08:01:48<+discordbot> 05:01:39 shadowm@hanacore ~/src/wesnoth-1.14 git:1.14 % cat ~/user-config.jam using gcc : w64mingw32 : i686-w64-mingw32-g++-posix ; 20180329 08:02:08<+discordbot> 05:01:54 shadowm@hanacore ~/src/wesnoth/win32-x-run git:master % grep cxxtool ../scons-win32-crosscompile/.scons-option-cache cxxtool = '/usr/bin/i686-w64-mingw32-g++-posix' 20180329 08:03:56<+discordbot> The hardest problem I had was making it use gzip and bzip2 20180329 08:04:02<+discordbot> but now it's a lot easier 20180329 08:04:23<+discordbot> literally has no idea if Boost selected that 20180329 08:04:31<+discordbot> just add appropriate flags with cxxflags= and linkflags= 20180329 08:04:56<+discordbot> 04:59:16 shadowm@hanacore ~/src/boost_1_66_0 % ./b2 -d+2 variant=release link=static address-model=32 target-os=windows threadapi=win32 cxxflags=-I$HOME/win32/wesnoth-1.14-xcompile-sdk/include linkflags=-L$HOME/win32/wesnoth-1.14-xcompile-sdk/lib --layout=system --prefix=$HOME/win32/wesnoth-1.14-xcompile-sdk/boost --with-test --with-locale --with-thread --with-iostreams --with-regex --with-filesystem --with-system 20180329 08:04:57<+discordbot> --with-program_options --with-random -j8 install 20180329 08:04:59<+discordbot> This is what I used. 20180329 08:05:02<+discordbot> if it didn't then checks for gzip and bzip2 support in iostreams will fail 20180329 08:05:26<+discordbot> Oh god why is this still a thing? 20180329 08:05:30<+discordbot> /home/shadowm/src/wesnoth/src/desktop/version.cpp:198:46: error: missing initializer for member ‘_OSVERSIONINFOEXW::dwMajorVersion’ [-Werror=missing-field-initializers] 20180329 08:05:39<+discordbot> It's supposed to set everything to 0. 20180329 08:05:59<+discordbot> Meh. Disabling strict. 20180329 08:06:45<+discordbot> *supposed to set everything to sizeof(OSVERSIONINFOEX) 20180329 08:06:59<+discordbot> Or isn't it 20180329 08:07:19<+discordbot> Wait, why have I been operating under this assumption? 20180329 08:08:16<+discordbot> Not that the rest of the contents of the OSVERSIONINFOEX actually matter before the GetVersionEx() call is done with it, mind you. 20180329 08:08:57<+discordbot> Would GCC hit me with a warning if I left it all defalt-initialized and explicitly set the first member to the required value? 20180329 08:12:25-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180329 08:15:44<+discordbot> Hm. -rwxr-xr-x 1 shadowm shadowm 511987 Mar 27 06:24 /home/shadowm/win32/wesnoth-1.14-xcompile-sdk/bin/libgcc_s_sjlj-1.dll 20180329 08:16:02<+discordbot> This is in your SDK package but I'm pretty sure it must be provided by the compiler instead. 20180329 08:17:09<+discordbot> placed it there for people who just want that sdk for dlls 20180329 08:17:26<+discordbot> changes are if they don't have gcc installed they don't have dll either 20180329 08:17:36<+discordbot> you may consider it dependency of sdl 20180329 08:17:42<+discordbot> 05:17:08 shadowm@hanacore ~/src/wesnoth/win32-x-run git:master % ln -s /usr/lib/gcc/i686-w64-mingw32/7.3-posix/libgcc_s_sjlj-1.dll 20180329 08:17:51<+discordbot> I should compile it with -static-libgcc 20180329 08:17:54<+discordbot> next time 20180329 08:17:55<+discordbot> I have a feeling if I don't do this Bad Things™ will happen. 20180329 08:19:58<+discordbot> https://cdn.discordapp.com/attachments/259976436490829825/428830666365599775/unknown.png 20180329 08:20:05<+discordbot> I got my first build in over a year! 20180329 08:20:30<+discordbot> gz 20180329 08:20:42<+discordbot> oh btw 20180329 08:20:58<+discordbot> (I also did the same with libgomp-1.dll.) 20180329 08:21:04<+discordbot> I think features tab was broken with russian localization 20180329 08:21:12<+discordbot> I mean. 20180329 08:21:42<+discordbot> Vultraz knows this screenshot by heart. 20180329 08:21:43<+discordbot> https://cdn.discordapp.com/attachments/259976436490829825/428831101562257429/unknown.png 20180329 08:23:25<+discordbot> Is this what you mean? 20180329 08:23:32< irker752> wesnoth: Iris Morelle wesnoth:master 8a905134a4fd / src/server/send_receive_wml_helpers.ipp: wesnothd, campaignd: Fix warning about uninitialized field on _WIN32 https://github.com/wesnoth/wesnoth/commit/8a905134a4fd6e230d978e59a91615b37072461c 20180329 08:24:41<+discordbot> yes 20180329 08:25:16<+discordbot> I'm not really sure if he has a plan for this at all. 20180329 08:28:54<+discordbot> https://cdn.discordapp.com/attachments/259976436490829825/428832911928852490/Screenshot_20180329_112311.png 20180329 08:29:02<+discordbot> I mean this 20180329 08:29:58<+discordbot> Oh. Blame your translators. 20180329 08:30:15<+discordbot> I've had to point this out to the Spanish translators several times. Do not include disambiguation prefixes in your msgstrs. 20180329 08:32:58<+discordbot> hmm in what textdomain those strings are? 20180329 08:33:20<+discordbot> You should be telling the translation team to sort it out instead of touching the po files directly without their permission. 20180329 08:33:22<+discordbot> I wonder if it would be proper for me just fix it without involving translation maintainer 20180329 08:33:26<+discordbot> No. 20180329 08:34:12<+discordbot> not sure who's translation maintainer now. I think it was @sinda before 20180329 08:34:15<+discordbot> I mean, look, I've not been an active translator for over 8 years and I went out of my way to help with this and other stuff. It doesn't take too much effort. 20180329 08:34:28<+discordbot> https://wiki.wesnoth.org/WesnothTranslations 20180329 08:42:16<+discordbot> @Aldarisvet seems he's here too 20180329 08:42:28<+discordbot> not online though 😛 20180329 08:42:38<+discordbot> I don't think he's often here. Just send him an email. 20180329 08:56:08<+discordbot> Also those translations are incorrect 20180329 08:56:32<+discordbot> I think I need to send him an update myself 20180329 08:59:30<+discordbot> Only I'm not sure how to translate them correctly either 20180329 09:05:21-!- Bonobo [~Bonobo@203.220.138.198] has quit [Ping timeout: 240 seconds] 20180329 09:06:19-!- Bonobo [~Bonobo@203.220.138.198] has joined #wesnoth-dev 20180329 09:13:14<+discordbot> @shadowm for the last time, the fix for that is complicated and I have yet to figure out how to properly implement it! 20180329 09:13:34<+discordbot> there's nothing I can do right now 20180329 09:13:53<+discordbot> unless you propose making the max width a whole lot wider 20180329 09:24:59< irker752> wesnoth/wesnoth:master Wedge009 fb866c6d13 'moreso' isn't a word in any dialect of AppVeyor: All builds passed 20180329 09:34:17< irker752> wesnoth: Charles Dang wesnoth:master 20a58fd8f827 / src/ (7 files in 4 dirs): Removed help_manager struct (it will be replaced) https://github.com/wesnoth/wesnoth/commit/20a58fd8f827a44497ff60f5c7bb411c5bc9a478 20180329 09:34:20< irker752> wesnoth: Charles Dang wesnoth:master 01bcee6be742 / src/server/send_receive_wml_helpers.ipp: Merge branch 'master' of github.com:wesnoth/wesnoth https://github.com/wesnoth/wesnoth/commit/01bcee6be7422f91ade2afe0f2e02660990aa0a8 20180329 09:34:41<+discordbot> (yes, I'm being lazy and didn't rebase) 20180329 09:50:18< zookeeper> @Vultraz, "one of the major changes that will be in 1.15/1.16 is that large multi-hex images like yours will now be drawn all at once instead of broken up into hundreds of hex-sized images." <- how do you plan on keeping different pieces of the image layered differently (WRT units for example)? 20180329 09:50:44<+discordbot> Draw all terrains, then draw all units 20180329 09:51:06< zookeeper> okay. how do you get terrains to draw over units then? 20180329 09:51:28<+discordbot> well, technically I split terrain drawing into two 20180329 09:51:30<+discordbot> bg terrains 20180329 09:51:31<+discordbot> then units 20180329 09:51:33<+discordbot> then fg terrains 20180329 09:51:52<+discordbot> the one caveat with that is that he fg terrains can sometimes encroach on the units :/ 20180329 09:51:55<+discordbot> will need to solve that 20180329 09:52:58< zookeeper> well that's what i asked 20180329 09:55:29<+discordbot> if I knew the answer there wouldn't be a problem 😛 20180329 09:58:27< zookeeper> sure, but you probably shouldn't assume that there is a (feasible) answer at all. maybe there is, maybe there isn't. 20180329 09:58:54<+discordbot> the old code had a weird constant that determined whether a certain terrain was considered foreground or background 20180329 10:00:16<+discordbot> There has to be some sort of solution 20180329 10:00:58<+discordbot> I'm just not really worried about it right now 20180329 10:01:02<+discordbot> It's relatively minor 20180329 10:01:49<+discordbot> And with jyrki's upcoming refactor of the terrain hex geometry rendering refactor, a solution might present itself. 20180329 10:16:04< zookeeper> i'm worried that you might not understand the current system that just barely manages to avoid everything looking like shit, then commit to a new system that fundamentally can't do the same thing and discover that problem too late in the process. 20180329 10:21:15<+discordbot> Well if the current system just barely manages to avoid everything looking like shit then it isn't a very good system, is it. 20180329 10:22:22< zookeeper> that's again about the most irrelevant thing you could say 20180329 10:22:44<+discordbot> 🙄 20180329 10:23:01< Soliton> if there is no theoretical solution to a problem some implementation detail changes will not present one either. 20180329 10:23:45<+discordbot> I simply haven't put much thought into it. 20180329 10:24:03<+discordbot> Because it's not something high-priority. 20180329 10:24:37< Soliton> i think the hint was just to not make claims about the solution then. 20180329 10:24:54<+discordbot> I said might 20180329 10:25:35<+discordbot> Seriously. It's an issue, we'll fix it. 20180329 10:27:21<+discordbot> I'm not making any claim to what the solution might be 20180329 10:28:48<+discordbot> and ftr, I've already switched gamemap rendering to the new system. 20180329 10:28:55<+discordbot> and threw out the old one 20180329 10:29:02< zookeeper> and that's fine. all i'm saying is don't bet everything on the assumption that rendering fg terrains without cutting them up into hex-sized pieces can produce an acceptable result. maybe it can, maybe it can't. 20180329 10:29:56<+discordbot> what does cutting them up have to do with anything? 20180329 10:30:36<+discordbot> And why would such a necessity be bad? I mean, jyrki's already going to be cutting up all the hexes into triangles, so... Really, cutting things up with OGL will be simple. 20180329 10:32:23< Soliton> it wouldn't be bad. it's likely necessary to make it work. 20180329 10:34:27< zookeeper> because the different pieces then get layered differently. you couldn't draw our mountains by effectively treating them as billboards, for example, you have to make different parts of them layer differently so they cover or don't cover up this or that adjacent hex. 20180329 10:34:53< zookeeper> and i've never said it's bad. see where the conversation started. 20180329 10:36:35< zookeeper> if it pleases you then i'll happily proclaim that the terrain/unit drawing system is terrible and fundamentally broken and there's basically no way to ever make our oversized units look good in the midst of fg terrains. 20180329 10:40:13< zookeeper> it's really difficult to get even fg terrains to play nice with each other (walls, mountains, castles, gates, it's a nightmare) but at least it's possible, whereas oversized units are practically impossible to account for. not relevant to a new rendering system, but i'm just clarifying that i'm not emotionally attached to the current paradigm. :p 20180329 10:48:16-!- gfgtdf [~chatzilla@x4e363747.dyn.telefonica.de] has joined #wesnoth-dev 20180329 10:50:31< gfgtdf> with opengl we could maybe also also use a little but of 3d, that is, give bummaps to all terrain images, and then use that to calculate which image defines which pixel, 20180329 10:50:54< gfgtdf> just a random thought though, i don' trealyl knowwnything about those tehcniques 20180329 10:51:51<+discordbot> yes, we can totally pop into 3rd dimension a bit 20180329 10:53:57< zookeeper> i can't say i see any way that 3d would help 20180329 11:40:04< irker752> wesnoth/wesnoth:opengl pentarctagon cb2b7e6546 Remove forgotten environment dump. AppVeyor: All builds passed 20180329 12:12:25-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180329 13:08:41-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180329 13:08:47-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180329 13:28:53< irker752> wesnoth/wesnoth:1.14 Charles Dang 9f72118964 We support building with VS 2013 on 1.14 AppVeyor: All builds passed 20180329 13:53:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 264 seconds] 20180329 14:06:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180329 14:06:43-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180329 14:16:09< irker752> wesnoth: pentarctagon wesnoth:opengl ff18ce28ebf3 / SConstruct scons/gl.py: Adds OpenGL/GLEW checks to scons. https://github.com/wesnoth/wesnoth/commit/ff18ce28ebf34944f45f6ef9f18a5e80afc3cf25 20180329 14:35:52< vn971> I got lost in branches.( So current master is 1.15-dev. But what is the branch for 1.13 ? Also, why does the MP lobby say to download version 1.14, while in fact people seem to download version 1.13.12 which has a _different_ MP lobby? 20180329 14:36:33< vn971> I was waiting for people on 1.14 server for days, but only now understood that I was waiting at the wrong place.( 20180329 14:37:01-!- travis-ci [~travis-ci@ec2-54-196-100-160.compute-1.amazonaws.com] has joined #wesnoth-dev 20180329 14:37:02< travis-ci> wesnoth/wesnoth#17316 (opengl - ff18ce2 : pentarctagon): The build is still failing. 20180329 14:37:02< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/359859732 20180329 14:37:02-!- travis-ci [~travis-ci@ec2-54-196-100-160.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180329 14:37:58-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180329 14:38:58< Soliton> there is master which is version 1.15.0-dev currently and there is the 1.14 branch which is version 1.13.12+dev currently. 20180329 14:40:26< Soliton> 1.13.12 should not have a different mp lobby. 20180329 14:40:51< vn971> Soliton: is it true that 1.14 branch and 1.13.12 Windows version shared from the site point to _different_ MP lobbys ? 20180329 14:41:39< vn971> Soliton: I've talked to a person who downloaded 1.13.12 (Windows) just yet, and he said he joined lobby and didn't see anyone (I didn't see him either). OK, I need to test that then. 20180329 14:43:53< Soliton> if it's KingHaldric then he is on the 1.13/1.14 server right now. 20180329 14:46:46< vn971> 1 sec I'll join myself from my client compiled from 1.14 branch. 20180329 14:47:52< vn971> v1.13.12+dev (6265181b57-Clean) I'm on lobby right now. 20180329 14:47:55< vn971> Soliton: ^ 20180329 14:48:07-!- Choicerer [6dca6b05@gateway/web/freenode/ip.109.202.107.5] has joined #wesnoth-dev 20180329 14:49:12< vn971> notice that may be important. I compiled with scons prefsdir=.local/share/wesnoth/1.14 20180329 14:49:53< Choicerer> Hi, I'm curious about how the game is going to be integrated with steam? Will you still be using your wesnoth server? What about user registration? 20180329 14:50:03< Soliton> right, 1.13*dev is accepted on the master server. that's a bit annoying. 20180329 14:50:28< Soliton> vn971: you can join port 14997 to get on the dev server. 20180329 14:50:43< Soliton> dev as in 1.13/1.14 20180329 14:52:15< Soliton> Choicerer: https://github.com/wesnoth/wesnoth/issues/1712 20180329 14:52:50< vn971> Soliton: should it be fixed somehow else? How did I end up connecting to master server (if I understood your question correctly, I did in fact connect to master server). 20180329 14:52:52< Choicerer> Thanks! 20180329 14:53:22< Soliton> vn971: it's going to fix itself once the version is 1.14*. 20180329 14:53:26-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180329 14:53:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer] 20180329 14:55:08< vn971> Soliton: that's tight. I do not really understand the reasons, but looking at your answer, that's a well thought-about issue, so no reason to re-iterate. 20180329 14:55:34< vn971> I'll live with the current work-around believing there are good reasons for that (even though initially it feels unexpected). 20180329 14:56:04< Soliton> it's normal for the unreleased dev version to go to the master server. only once the version is stable even the unreleased versions go to that stable versions server. 20180329 14:57:21-!- gfgtdf [~chatzilla@x4e363747.dyn.telefonica.de] has quit [Ping timeout: 246 seconds] 20180329 14:57:39< Soliton> since dev versions are not expected to be compatible. of course at this point in time they better should be. 20180329 14:57:52< Soliton> well, happy easter everyone. 20180329 14:57:55 * Soliton & 20180329 14:57:57< vn971> Soliton: well... This is **1.14** branch 20180329 14:58:49< vn971> ah, but your point is to disallow earlier versions than official 1.14.0 tag release on same server. 20180329 15:06:26-!- Bonobo [~Bonobo@203.220.138.198] has quit [Ping timeout: 256 seconds] 20180329 15:07:32-!- gfgtdf [~chatzilla@x4e363747.dyn.telefonica.de] has joined #wesnoth-dev 20180329 15:07:41< Choicerer> Happy Easter 20180329 15:09:46-!- Choicerer [6dca6b05@gateway/web/freenode/ip.109.202.107.5] has quit [Quit: Page closed] 20180329 15:16:19-!- sevu [~Shiki@p548557EE.dip0.t-ipconnect.de] has joined #wesnoth-dev 20180329 15:20:15-!- gfgtdf [~chatzilla@x4e363747.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 52.7.3/20180322140748]] 20180329 15:52:25-!- sevu [~Shiki@p548557EE.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 20180329 15:57:32-!- Bhoren [~Bhoren_wh@2a01:e0a:c:2150:cd3f:8da4:1a62:ab6] has joined #wesnoth-dev 20180329 16:00:27-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev 20180329 16:00:56-!- atarocch [atarocch@nat/redhat/x-hgylrcocgajnryay] has quit [Remote host closed the connection] 20180329 16:08:27-!- molgrum [~molgrum@unaffiliated/molgrum] has quit [Ping timeout: 256 seconds] 20180329 16:09:00-!- molgrum [~molgrum@databur.st] has joined #wesnoth-dev 20180329 16:09:00-!- molgrum [~molgrum@databur.st] has quit [Changing host] 20180329 16:09:00-!- molgrum [~molgrum@unaffiliated/molgrum] has joined #wesnoth-dev 20180329 16:36:47-!- sevu [~Shiki@p548557EE.dip0.t-ipconnect.de] has joined #wesnoth-dev 20180329 16:51:13< irker752> wesnoth/wesnoth:opengl pentarctagon 92b37d6191 Re-add travis' notifications. AppVeyor: All builds passed 20180329 16:54:25< vn971> found out something that feels like a small bug (1.13.12): https://github.com/wesnoth/wesnoth/issues/2776 20180329 17:19:01-!- atarocch [~atarocch@93.56.164.28] has joined #wesnoth-dev 20180329 17:59:12-!- sevu [~Shiki@p548557EE.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 20180329 18:06:11<+discordbot> @Vultraz Something needs to be done about it though. It's a rather important dialog. 20180329 18:06:49<+discordbot> I was hoping this would be figured out at some point between 1.13.2 and now but yeah, I guess that was a bit naïve of me in hindsight. 20180329 18:08:17<+discordbot> how do you even manage to write i with two dots 😛 20180329 18:10:49<+discordbot> ï 20180329 18:10:57<+discordbot> the answer is compose key 20180329 18:12:26<+discordbot> Some keyboard layouts (including Finnish) have a dedicated umlaut key. I can just press that, then i. 😉 20180329 18:33:28< vn971> Question: when is "message skipping" status being reset normally? After another event occurs? Or when? 20180329 18:41:41<+discordbot> The answer is what jyrkive said. Umlauts are part of Spanish and Portuguese so the Spanish and Latin American keyboard layouts have a dead key for it. 20180329 18:42:37< zookeeper> vn971, in the typical case, probably when all events of the current type have finished executing. 20180329 19:16:06< irker752> wesnoth/wesnoth:master Charles Dang 01bcee6be7 Merge branch 'master' of github.com:wesn AppVeyor: All builds passed 20180329 19:35:57-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180329 19:36:03-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180329 19:37:37< vn971> zookeeper: I'll raise this issue then: https://github.com/wesnoth/wesnoth/issues/2777 In short, if you generate messages from Lua console, they all fall into one big scope. 20180329 19:39:01< zookeeper> well, sounds like you would have wanted to raise that issue regardless of the specifics :P 20180329 19:40:26< vn971> zookeeper: as a matter of fact, if the "skipping messages" flag would be normally reset at e.g. end turn, I wouldn't. 20180329 19:40:59< vn971> but I wanted to raise it very much yes.) 20180329 19:53:32-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180329 19:53:38-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180329 20:04:52-!- Bhoren [~Bhoren_wh@2a01:e0a:c:2150:cd3f:8da4:1a62:ab6] has quit [Quit: Leaving] 20180329 20:34:11-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180329 20:34:21-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180329 20:57:26< irker752> wesnoth: Nils Kneuper wesnoth:1.14 e2ef02474a94 / / (14 files in 13 dirs): updated Scottish Gaelic translation https://github.com/wesnoth/wesnoth/commit/e2ef02474a94f851b286f59d190e71348fe94d37 20180329 20:57:28< irker752> wesnoth: Nils Kneuper wesnoth:1.14 3c656c86e761 / / (7 files in 6 dirs): updated Ukrainian translation https://github.com/wesnoth/wesnoth/commit/3c656c86e7617ff18165b5ffe525d70e2ddc8cdc 20180329 20:57:30< irker752> wesnoth: Nils Kneuper wesnoth:1.14 8f37d4114ea3 / / (10 files in 9 dirs): updated British English translation https://github.com/wesnoth/wesnoth/commit/8f37d4114ea3626fe2ab726490ec43ab74237172 20180329 20:57:33< irker752> wesnoth: Nils Kneuper wesnoth:master f19db187fab5 / / (14 files in 13 dirs): updated Scottish Gaelic translation https://github.com/wesnoth/wesnoth/commit/f19db187fab50e6a709c6bc3a737b996ac8e3756 20180329 20:57:35< irker752> wesnoth: Nils Kneuper wesnoth:master 4bcfada88a00 / / (7 files in 6 dirs): updated Ukrainian translation https://github.com/wesnoth/wesnoth/commit/4bcfada88a009301c8dbf6a1513cb1395a090432 20180329 20:57:37< irker752> wesnoth: Nils Kneuper wesnoth:master 57c1a671344d / / (9 files in 8 dirs): updated British English translation https://github.com/wesnoth/wesnoth/commit/57c1a671344d38705d918cce7a2208273a7c9f9b 20180329 21:17:33-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection] 20180329 21:17:46-!- travis-ci [~travis-ci@ec2-54-166-255-251.compute-1.amazonaws.com] has joined #wesnoth-dev 20180329 21:17:47< travis-ci> wesnoth/wesnoth#17317 (1.14 - 8f37d41 : Nils Kneuper): The build was broken. 20180329 21:17:47< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/360033861 20180329 21:17:47-!- travis-ci [~travis-ci@ec2-54-166-255-251.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180329 21:27:21-!- travis-ci [~travis-ci@ec2-54-166-255-251.compute-1.amazonaws.com] has joined #wesnoth-dev 20180329 21:27:22< travis-ci> wesnoth/wesnoth#17318 (master - 57c1a67 : Nils Kneuper): The build has errored. 20180329 21:27:22< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/360033922 20180329 21:27:22-!- travis-ci [~travis-ci@ec2-54-166-255-251.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180329 21:40:12-!- hrubymar10 [~textual@ip-86-49-9-122.net.upcbroadband.cz] has joined #wesnoth-dev 20180329 21:44:46-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20180329 21:46:58< irker752> wesnoth/wesnoth:opengl pentarctagon ff18ce28eb Adds OpenGL/GLEW checks to scons. AppVeyor: All builds passed 20180329 22:09:19-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180329 22:09:25-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180329 22:22:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180329 22:22:33-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180329 22:32:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180329 22:32:33-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180329 22:38:25-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 248 seconds] 20180329 22:44:20-!- louis94 [~~louis94@149.36-245-81.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev 20180329 23:04:30-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20180329 23:11:57-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180329 23:12:03-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180329 23:17:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180329 23:17:12-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180329 23:20:13-!- Bonobo [~Bonobo@203.220.138.198] has joined #wesnoth-dev 20180329 23:24:56<+discordbot> @Pentarctagon Docker image does not have SDL2_ttf which is required for 1.14 to build. 20180329 23:34:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180329 23:36:44<+discordbot> ah 20180329 23:36:45<+discordbot> shoot 20180329 23:37:51-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds] 20180329 23:43:55<+discordbot> 😦 20180329 23:46:58<+discordbot> I should probably separate things out at some point, instead of having a single base dockerfile. 20180329 23:53:32-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20180329 23:53:41-!- louis94 [~~louis94@149.36-245-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 256 seconds] 20180329 23:53:55< irker752> wesnoth/wesnoth:master Nils Kneuper 57c1a67134 updated British English translation AppVeyor: vs2015/Release Failed 20180329 23:53:56< irker752> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-2345 20180329 23:59:02<+discordbot> alright, should be good now --- Log closed Fri Mar 30 00:00:21 2018