--- Log opened Wed Apr 04 00:00:28 2018 20180404 00:16:36-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180404 00:17:29< mattsc> 20180403 03:15:50< celticminstrel> I guess I'd probably be more likely to look at the AI stuff than that? 20180404 00:17:37< mattsc> If I may ask, which AI stuff is that? 20180404 00:18:18<+discordbot> i think he's referring to the trouble he's been having with the schema and the Ai aspect syntax? 20180404 00:18:32< mattsc> Ah, I see. 20180404 00:18:44< mattsc> Oh well, I was hoping he was going to do my work for me. ;) 20180404 00:27:14< mattsc> @Vultraz: BTW, did you see the discussion on the AI recall/recruit problems and that I think one is a feature that cannot be fixed for 1.14 any more and the other a bug that should be fixed? 20180404 00:28:26< mattsc> Also, there’s a pathfinding issue that I think should be fixed. That one’s not an AI problem per se, but it manifested itself in one of the Micro AIs. 20180404 00:44:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180404 00:44:33-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180404 00:48:19<+discordbot> @mattsc hm? 20180404 00:48:27<+discordbot> i recall the pathfind tunnel issue... 20180404 00:48:32<+discordbot> not the other 20180404 00:48:59< mattsc> the other was discussed sometime before that 20180404 00:50:27< mattsc> starting 20180401 20:29:50 in the logs (longer ago already than I thought) 20180404 01:03:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180404 01:03:33-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180404 01:06:24<+discordbot> @mattsc ah, that 20180404 01:06:30<+discordbot> why cannot it be fixed? 20180404 01:07:09<+discordbot> Is it compatibility-breaking? 20180404 01:07:19<+discordbot> or you don't know the fix yet? 20180404 01:24:47< Ravana_> is it correct that https://i.imgur.com/Husfg5O.png + being there on only one published addon is from Error: ~BLIT(): offset and width '64' larger than destination image's width '60' no blitting performed. 20180404 01:27:32< irker719> wesnoth/wesnoth:1.14 gfgtdf 7e04aa52e3 f AppVeyor: All builds passed 20180404 01:36:12-!- Bonobo [~Bonobo@203.220.138.198] has joined #wesnoth-dev 20180404 01:37:59< mattsc> @Vultraz I haven’t really looked at how to fix it yet, but it’s not really a question of whether it can be done. It’s a logic error, not a coding error. 20180404 01:38:39< mattsc> And yes, it could be compatibility breaking, it’s not at all unlikely that there are add-ons that, knowingly or unknowingly, make use of this "feature". 20180404 01:39:05< mattsc> Ths is talking about the AI decided not to recall when it judges it not worth it. 20180404 01:39:22< mattsc> The AI not recruiting either after it decided not to recall is definitely a bug. 20180404 01:39:23<+discordbot> I see 20180404 01:39:48<+discordbot> Well, honestly, changes like that are just something UMC authors have to live with 20180404 01:40:04< mattsc> But not during a feature freeze. 20180404 01:40:16<+discordbot> Ehhhhhh 20180404 01:40:26< mattsc> So my suggestion is to change the former in master, and fix the later in 1.13. 20180404 01:40:32< mattsc> *latter 20180404 01:40:40<+discordbot> This is not really the type of thing to which the freeze applies 20180404 01:40:59< mattsc> Umm, if it breaks your add-on, how does that not apply? 20180404 01:41:51< mattsc> I just replayed one of my campaigns for the umptieth time in 1.13.12. I really really do not want to do so again to make sure something got changed yet again in 1.13.13. 20180404 01:41:56< mattsc> and .14 and … 20180404 01:42:17< celticminstrel> @Vultraz, mattsc - Actually I was not referring to that, I was referring to something ISTR mattsc looking at. 20180404 01:42:24< mattsc> make sure something did NOT get changed … 20180404 01:42:30< celticminstrel> Either recruitment or pathfinding? 20180404 01:42:41< celticminstrel> More likely pathfinding I guess? 20180404 01:43:15<+discordbot> Well, I suppose we can put off the logic change until 1.15 20180404 01:43:23< mattsc> celticminstrel: okay, that’s what I was wondering; I am going to look into the recruiting bit (although I might ask you for an opinion on how to code something); you said that maybe you’d look into the pathfinding, so I’ll do the recruiting first. 20180404 01:43:38< celticminstrel> 'kay 20180404 01:43:40< mattsc> @Vultraz Yeah, agreed. 20180404 01:44:13< celticminstrel> FTR @Vultraz, features that affect the API are absolutely forbidden in the stable branch, so. 20180404 01:44:31< celticminstrel> Now... whether this counts as affecting the API, that I'm not so sure about. 20180404 01:46:32< mattsc> I’m not sure about that either. I don’t think so, but I still would count the former problem as a feature; even if an undesriable one 20180404 01:46:51< celticminstrel> Hm? 20180404 01:47:00< celticminstrel> What would you count as a feature? 20180404 01:47:00< mattsc> Btw, there is a workaround for it, you just need to lower the recall cost to the recruit cost of the cheapest unit 20180404 01:47:08< celticminstrel> Ah, that, okay. 20180404 01:47:31< mattsc> Right, that. Did you talk about something else? 20180404 01:47:37< mattsc> I get easily confused these days. :P 20180404 01:48:10< mattsc> Anyway, since there is a workaround (or, one could even call that a configurability of the AI), I am not very worried about it 20180404 01:50:37< celticminstrel> Thinking about it, aren't AI actions synced? 20180404 01:50:58< celticminstrel> I mean, the AI is run only on one client and their actions are sent across the network. 20180404 01:51:16< mattsc> Right? 20180404 01:51:36< celticminstrel> So, considering that, making changes to AI behaviour is probably acceptable for the stable series (though definitely limit that to bugfixes). 20180404 01:51:53< celticminstrel> IOW I now think there's no problem fixing it on master. 20180404 01:52:03<+discordbot> I wonder if it would ever be worth it to have the AI run centrally 20180404 01:52:04< mattsc> Yes. We have done that before. Back in the day when _Crab was still around … 20180404 01:52:08< celticminstrel> The pathfinding bug I'm still not quite sure of. 20180404 01:52:27< mattsc> Whether that’s a feature? 20180404 01:52:43< celticminstrel> Whether we can fix it on 1.14. 20180404 01:53:15< celticminstrel> The chance that someone relied on the MicroAI ignoring tunnels is far higher IMO than the chance that someone relied on the AI not recruiting in rare circumstances. 20180404 01:53:33< celticminstrel> That said... it can probably be fixed in a way that causes the MicroAI to continue to ignore tunnels? 20180404 01:53:58< celticminstrel> And for master we can add a key to the MicroAI to make them consider tunnels. 20180404 01:54:35< celticminstrel> So I guess allowing paths with custom cost functions to account for tunnels in 1.14 is acceptable as long as it's not the default behaviour. 20180404 01:54:39<+discordbot> We don't have to make every tiny behavior change backwards-compatible.... 20180404 01:54:41< mattsc> True, but if we don’t change the behavior, what’s the point of putting the fix into 1.14? 20180404 01:54:48< celticminstrel> Hmm. 20180404 01:55:08< celticminstrel> True, I was just thinking that too. 20180404 01:55:28< celticminstrel> I dunno. 20180404 01:55:40< celticminstrel> Do people commonly rely on it ignoring tunnels? 20180404 01:55:59< mattsc> I wouldn’t think so, but I don’t know. 20180404 01:56:18< mattsc> The reason why I know about this is because Kwandulin reported it as “not working" 20180404 01:56:32< celticminstrel> Well, I'm not sure, basically. 20180404 01:57:33< mattsc> Right. 20180404 01:57:48< mattsc> It’s one of those things for which there are applications both ways. 20180404 01:58:21< mattsc> Same as with the question whether an AI should recall woodsmen or grunts at 20 gold if it cannot recruit anything else. 20180404 01:59:07< mattsc> I think the default behavior should be what one intuitively would expect the AI to do, but during a feature freeze is not the time to change that. 20180404 01:59:54< mattsc> So I guess you convinced me that the pathfinding thing should stay as it is in 1.14. 20180404 02:00:38< celticminstrel> Ugh, so {GUARDIAN} includes animate=no which means using it in [side] gives schema errors... >< 20180404 02:00:58< mattsc> … 20180404 02:01:48< mattsc> One more thing on the tunnels: this only affects one particular version of the Goto MAI, and since the MAIs are written in Lua, people can work around even that, if they need to. 20180404 02:02:03< mattsc> Not necessarily easily, but I can help with that. 20180404 02:02:15< mattsc> We should document both of these things on the wiki though. 20180404 02:02:21< celticminstrel> I guess I'll just have to add animate to the main [unit] definition. :/ 20180404 02:03:34<+discordbot> celmin IF you do what does it mean? That you can define a unit which does not animate? 20180404 02:04:05< celticminstrel> Nah, using animate=yes means it fades in as if it were recruited, while with animate=no it just appears. 20180404 02:04:38< celticminstrel> (Or in the case of a skeleton for example, animate=yes plays the raising animation.) 20180404 02:05:55<+discordbot> Did you mean add animate to [side]? 20180404 02:11:06< celticminstrel> What? No... 20180404 02:12:40< celticminstrel> ... 20180404 02:12:52< celticminstrel> Wait, but animate=no is the default in [unit]!? 20180404 02:13:02< celticminstrel> So I can just remove it from {GUARDIAN}, right? 20180404 02:19:05<+discordbot> I guess? 20180404 02:19:29< celticminstrel> ...why is there a flag on top of my unit's defense rating? 20180404 02:19:44< celticminstrel> In the sidebar on 1.14. 20180404 02:20:00<+discordbot> that's its side's flag, i think 20180404 02:21:22< celticminstrel> Sure but it shouldn't be on top of the defense rating. 20180404 02:21:56< celticminstrel> Oh FTR this is on the lowest available resolution, of course. 20180404 02:22:00<+discordbot> hey, the sidebar UI needs a revamp 😛 20180404 02:22:35< celticminstrel> Sure, but this does seem like something that could be relatively easily fixed. 20180404 02:28:29-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180404 02:28:35-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180404 02:35:18< celticminstrel> So in TSG The Long March, the undead do not have a leader and thus do not recruit? Is that correct? 20180404 03:03:09-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180404 03:03:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180404 03:05:36<+discordbot> I don’t know 20180404 03:05:43<+discordbot> You’d need to look at the wml 20180404 03:06:04< celticminstrel> I was looking at the WML but only the [side] definition. 20180404 03:19:17-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] 20180404 03:29:43-!- Bonobo [~Bonobo@203.220.138.198] has quit [Quit: Leaving] 20180404 03:36:43<+discordbot> celmin: often leaders can be added later 20180404 03:52:12<+discordbot> ugh 20180404 03:52:15<+discordbot> I feel... ill 20180404 03:55:38< mattsc> :( Hope you won’t get sick. 20180404 04:02:44-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20180404 04:07:48-!- vn971 [~vasya@94.158.103.15] has quit [Ping timeout: 260 seconds] 20180404 04:13:07< irker719> wesnoth/wesnoth:1.14 gfgtdf 650079412c fix filter not working in [disable] (#28 AppVeyor: All builds passed 20180404 04:21:28<+discordbot> thanks 20180404 05:19:28-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has quit [Ping timeout: 240 seconds] 20180404 05:42:51<+discordbot> @shadowm any chance you know what's going on here? https://github.com/wesnoth/wesnoth/issues/2825 20180404 05:43:27<+discordbot> not sure what this l10n-track file it's looking for it 20180404 05:45:51<+discordbot> It doesn't happen on Debian sid, that much I can tell you. 20180404 05:46:28<+discordbot> Also I don't remember how the image localization stuff worked. Let me see if I can dig it up from the old i18n ML archives. 20180404 05:47:43<+discordbot> https://wiki.wesnoth.org/ImageLocalization 20180404 05:48:10<+discordbot> "A tracker script is run periodically on the repository to indicate that localized images need updating when the original image has been changed or moved." ¯_(ツ)_/¯ 20180404 05:49:31<+discordbot> I don't understand though. The engine encounters an error state internally but the image is loaded anyway. 20180404 05:50:41<+discordbot> Perhaps Ivanovic still remembers anything about this stuff? The guy who was actually in charge of this stuff (and IIRC wrote the patches adding support for it) isn't around anymore I don't think. 20180404 05:50:54<+discordbot> well, it sounds as if onlY THE GD AMN O KEY DAMN YOU update check fails, but that doesn't affect the loading 20180404 05:51:12<+discordbot> (Vultraz is having issues with his keyboard.) 20180404 05:51:35<+discordbot> (keys keep popping up when i type >_> ) 20180404 05:52:02<+discordbot> I'm curious is that little passage I quoted refers to something that's formally part of the pot-update procedure, or something else entirely that has surely been forgotten over the years. 20180404 05:52:08<+discordbot> *if that 20180404 05:54:39<+discordbot> that is a very good question... 20180404 05:58:12<+discordbot> $ grep l10n-track -r * CMakeLists.txt: install(FILES l10n-track DESTINATION ${CMAKE_INSTALL_DATADIR}/${DATADIRNAME}) Binary file projectfiles/CodeBlocks/.objs-debug/src/image.o matches Binary file projectfiles/CodeBlocks/.objs-release/src/image.o matches Binary file projectfiles/VC15/Debug/image.obj matches Binary file projectfiles/VC15/Debug/wesnoth.exe matches Binary file projectfiles/VC15/Release/image.obj matches grep: 20180404 05:58:13<+discordbot> projectfiles/VC15/Release/vc141.pdb: Device or resource busy Binary file projectfiles/VC15/ReleaseDEBUG/image.obj matches SConstruct: env.InstallData("datadir", "wesnoth", "l10n-track") src/image.cpp: std::string trackpath = filesystem::get_binary_file_location("", "l10n-track"); 20180404 05:58:26<+discordbot> we don't have any such files in the repo, at least 20180404 05:59:13< irker719> wesnoth/wesnoth:master Charles Dang f4fb2a6dcc Changelog entry for c4cf0c9 AppVeyor: All builds passed 20180404 05:59:32<+discordbot> (grep is very thorough...) 20180404 06:06:47<+discordbot> 03:06:29 shadowm@hanacore ~/src/wesnoth git:master % find . -name 'l10n-track' ./l10n-track 20180404 06:07:11<+discordbot> grep searches the contents of files. find searches for filesystem objects matching certain criteria. 20180404 06:07:14< irker719> wesnoth: Charles Dang wesnoth:master 464f7ce62843 / src/ (8 files in 4 dirs): GUI2: minor refactoring of window construction to guard against memory leaks https://github.com/wesnoth/wesnoth/commit/464f7ce6284309ef3bba7999c220051007d6f071 20180404 06:07:37<+discordbot> oh 20180404 06:07:49<+discordbot> Also, the -I switch to grep prevents it from trying to look into files that don't look like plain text in the current locale. 20180404 06:07:58<+discordbot> (That's an uppercase i) 20180404 06:08:14<+discordbot> (-i makes it search contents case-insensitively instead.) 20180404 06:08:43< Ivanovic> shadowm, vultraz: no I don't remember how that thing worked 20180404 06:10:37<+discordbot> well, i can just add a check exit if the path is empty 20180404 06:13:50<+discordbot> though, perhaps we should remove the code altogether? 20180404 06:14:48<+discordbot> What code do you want to remove? 20180404 06:15:36<+discordbot> https://github.com/wesnoth/wesnoth/blob/master/src/image.cpp#L488-L523 20180404 06:18:56<+discordbot> I posted a comment. 20180404 07:16:18-!- grzywacz [~karol@89-70-226-147.dynamic.chello.pl] has joined #wesnoth-dev 20180404 07:22:15-!- vn971 [~vasya@94.158.103.15] has joined #wesnoth-dev 20180404 07:22:41<+discordbot> @jyrkive how do you think I can solve this bug? https://forums.wesnoth.org/viewtopic.php?p=625159#p625159 20180404 07:28:09<+discordbot> His suggestion is the easiest fix I can come up with, too - simply convert the image from RGB to RGBA on loading. 20180404 07:28:17<+discordbot> But how 20180404 07:29:19<+discordbot> make_neutral_surface()? 20180404 07:30:06<+discordbot> hmmmmmmmmmmmmmmmmmm 20180404 07:33:50<+discordbot> will test later 20180404 08:11:37-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180404 08:31:31<+discordbot> regarding to #2825 : Localized images are here: /wesnoth/images/misc/l10n/cs/logo.png or /wesnoth/images/misc/l10n/sk/logo.png or /wesnoth/images/misc/l10n/pl/logo.png ... 20180404 08:31:43<+discordbot> These images causes issues 20180404 08:34:12<+discordbot> I don't see any issues with selecting the Polish or Slovak translations. Or Spanish, for that matter, which also has a translated logo. 20180404 08:34:34<+discordbot> The most I get are setlocale() warnings (?????). 20180404 08:34:43<+discordbot> 20180404 05:33:17 warning general: setlocale() failed for 'pl_PL'. 20180404 05:33:17 warning general: setlocale() failed for 'pl_PL'. 20180404 05:33:33 warning general: setlocale() failed for 'sv_SE'. 20180404 05:33:33 warning general: setlocale() failed for 'sv_SE'. 20180404 05:33:39 warning general: setlocale() failed for 'sr_RS@latin'. 20180404 05:33:39 warning general: setlocale() failed for 'sr_RS@latin'. 20180404 05:33:43 20180404 08:34:44<+discordbot> warning general: setlocale() failed for 'sk_SK'. 20180404 05:33:43 warning general: setlocale() failed for 'sk_SK'. 20180404 08:35:24<+discordbot> Yes, I also get these warnings, but I would prefer step-by-step solving :S 20180404 08:35:42<+discordbot> I saw your comment about l10n-track 20180404 08:36:08<+discordbot> this file exists in root project dir 20180404 08:36:22<+discordbot> This file should be included inside package? 20180404 08:36:30<+discordbot> If so, in which path? 20180404 08:36:32<+discordbot> Nobody knows. 20180404 08:36:49<+discordbot> But if the answer is positive, then exactly where it already is, which is to say, the root of the data dir. 20180404 08:37:06<+discordbot> (Again, need to emphasise that the data dir is not data/, it's its parent.) 20180404 08:37:50<+discordbot> Maybe @loonycyborg might know about this since he's also a packager? 20180404 08:38:00-!- Rhonda [~rhonda@wesnoth/developer/rhonda] has quit [Remote host closed the connection] 20180404 08:38:10<+discordbot> oh, ok, so let me test it. I'll manually copy both l10n-* files inside Resources (our data root) 20180404 08:39:04<+discordbot> AFAIK l10n-* aren't included inside steam data bundle 20180404 08:40:10<+discordbot> know about what exaclty? 20180404 08:40:22<+discordbot> That may or may not be an oversight if someone can actually explain to me what the files are supposed to be used for, when they are supposed to be updated, and whether they should be distributed. 20180404 08:40:51<+discordbot> Then again, it's not me who needs an explanation. I'm just the messenger of yet another AWOL developer. 20180404 08:41:19<+discordbot> I don't know anything about localized images 20180404 08:41:34<+discordbot> ok, it looks that copying these two files inside data root does fix this error let me do one more test 20180404 08:42:10<+discordbot> I'm vaguely curious if this will somehow break certain translations. 20180404 08:43:06<+discordbot> it does not IMO. My question is, for what it is useful 20180404 08:43:14<+discordbot> I always perfectly mirror the directory structure in git 20180404 08:43:28<+discordbot> The last update to them was on November 5 2015 at commit c281b3af085ef6c30f1ea253e6432c6ecefeefd4 (1058 commits past 1.13.1). 20180404 08:44:20<+discordbot> As I understand (note: I've not read the wiki explanation in detail yet) they deserve as a dictionary of sorts telling Wesnoth which images have been localized and... when? 20180404 08:44:27<+discordbot> l10n-track contains hashes. 20180404 08:44:58<+discordbot> "A tracker script is run periodically on the repository to indicate that localized images need updating when the original image has been changed or moved." 20180404 08:45:49<+discordbot> That's what worries me. 20180404 08:46:04<+discordbot> Who runs this mystery script that isn't even identified on the wiki? 20180404 08:46:10<+discordbot> I certainly never did. 20180404 08:46:24<+discordbot> Apparently Ivanovic didn't either. 20180404 08:46:40<+discordbot> And a few localized images have had their source altered in some way since the Nov 5 2015 update. 20180404 08:46:55<+discordbot> Yeah, such things should definitely be documented in the wiki, instead of assuming that the developer responsible for that will stay in the project for all eternity. 20180404 08:47:26<+discordbot> I believe that wesnoth detect localised logo.png automatically while macOS localised logos worked without it 20180404 08:47:35<+discordbot> (Actually, that last part is speculation on my part. I would run a script to verify that theory but it's almost 6 am.) 20180404 08:47:55<+discordbot> Yes, Wesnoth does detect the logos regardless. 20180404 08:48:31<+discordbot> So my theory is simply as follows: the files might permit Wesnoth to implement a mechanism akin to the fuzzy flag in gettext. 20180404 08:48:51<+discordbot> I believe you're familiarized with that since you took over a translation team IIRC. 20180404 08:50:48<+discordbot> After second test I can confirm that when I copied both l10n-* files into Wesnoth's data dir, problem dissapeared. Only 'problem' is that there are two slashes before l10n-track: Printing description of trackpath: (std::__1::string) trackpath = "/Users/user/xcode/wesnoth/projectfiles/Xcode/build/Products/Debug/Wesnoth.app/Contents/Resources//l10n-track" 20180404 08:51:23<+discordbot> Yeah, that's innocuous, it happens all the time. 20180404 08:52:09<+discordbot> The only situation where it wouldn't be innocuous would be if Wesnoth tried to access an absolute path that starts with // -- apparently POSIX lets implementors behave in a special fashion with paths like that. 20180404 08:52:40<+discordbot> At least that's what Boost.Filesystem's documentation and several failing unit tests led me to believe at the time. 20180404 08:52:46<+discordbot> On Windows, such paths are UNC paths (can refer to network resources). 20180404 08:52:53<+discordbot> And a cursory glance at POSIX. 20180404 08:53:10<+discordbot> but on windows there are backslashes, aren't there? 20180404 08:53:13<+discordbot> I don't think Windows recognizes //foo/bar as an UNC. 20180404 08:53:21<+discordbot> \\foo\bar certainly. 20180404 08:53:34<+discordbot> Ah, right. I mixed them up. Sorry. 20180404 08:53:53<+discordbot> (And there's also \\.\ and \\?\.) 20180404 08:54:30<+discordbot> (Here's a very informative blog post on the matter for the curious. It is unfortunately exactly as dense as the subject matter: https://googleprojectzero.blogspot.cl/2016/02/the-definitive-guide-on-win32-to-nt.html) 20180404 08:54:36-!- Rhonda [~rhonda@anguilla.debian.or.at] has joined #wesnoth-dev 20180404 08:55:37<+discordbot> "If you ever encounter an application trying to validate a Win32 path, be very skeptical and try and use some of these techniques to bypass the checks." 20180404 08:56:11<+discordbot> ok, so what is solution? * update xcode project to include these two (really both?) files into package * find that this file is useless and remove it from src 20180404 08:56:49<+discordbot> That quote is exactly why the path blacklist I implemented in 1.13.12 doesn't try to take _server.ign into account. I was afraid it might be possible to trick Wesnoth into using a wrong _server.ign. Better safe than sorry. 20180404 08:57:18<+discordbot> I'll try to see if I can track down the commit that introduced the image localization code and the relevant mailing list posts or IRC logs. But that'll not happen until at least 15 more hours. 20180404 08:57:52<+discordbot> I might be able to make some sense out of this mess if I can actually see the full picture. 20180404 08:58:11<+discordbot> the theory about fuzzy translations for images seems correct 20180404 08:59:28<+discordbot> @jyrkive what would be the proper way to check if an image if alpha-channel-less? 20180404 08:59:49<+discordbot> I can, f course, run make_neutral_surface unconditionally 20180404 09:00:21<+discordbot> Stab it in the face and see if the pixels it bleeds are all opaque. 20180404 09:00:42<+discordbot> Just kidding. Besides, an image can have an alpha channel and be 100% opaque. 20180404 09:01:01<+discordbot> @Vultraz SDL_PixelFormat.Amask. It's zero if and only if the surface doesn't have an alpha channel. 20180404 09:01:07<+discordbot> https://wiki.libsdl.org/SDL_PixelFormat 20180404 09:05:50< irker719> wesnoth/wesnoth:1.14 Charles Dang 54d440edcc Changelog entry for 6500794 AppVeyor: All builds passed 20180404 09:12:33<+discordbot> I tried ti summary this discussion here: https://github.com/wesnoth/wesnoth/issues/2825#issuecomment-378534183 20180404 09:13:22<+discordbot> *she 20180404 09:14:00< irker719> wesnoth: Charles Dang wesnoth:1.14 f78e32c7f88b / changelog.md src/image.cpp src/sdl/utils.cpp: Fixed images with no alpha channel rendering incorrectly https://github.com/wesnoth/wesnoth/commit/f78e32c7f88b631f577e88315634ada43098885e 20180404 09:15:43<+discordbot> not really needed for master but i'll forward-port it for completeness in surface handling 20180404 09:16:47<+discordbot> Sounds good. The OpenGL texture implementation already requires the RGBA format (although sprites aren't supposed to be loaded directly to textures). 20180404 09:17:09<+discordbot> right now they're loaded directly to textures via SDL 20180404 09:17:19<+discordbot> @shadowm she? ok, sorry then 😶 20180404 09:17:32< irker719> wesnoth: Charles Dang wesnoth:master 6babb773d231 / changelog.md src/image.cpp src/sdl/utils.cpp: Fixed images with no alpha channel rendering incorrectly https://github.com/wesnoth/wesnoth/commit/6babb773d2319625a5b7def241fc0f9e4921db42 20180404 09:17:38<+discordbot> but because of that, none of these alpha/indexed issues applied 20180404 09:17:43<+discordbot> On master, yes. In the OpenGL branch they aren't loaded at all. 😛 20180404 09:17:51<+discordbot> 😂 20180404 09:18:37<+discordbot> @jyrkive side note: should https://github.com/wesnoth/wesnoth/commit/464f7ce6284309ef3bba7999c220051007d6f071 be backported? 20180404 09:18:55<+discordbot> Does the OGL branch do much yet or are you still busy trying to sort out low-level stuff? 20180404 09:18:58<+discordbot> (without the use of make_unique, of course) 20180404 09:19:36<+discordbot> @shadowm AFAIK latter 20180404 09:21:51<+discordbot> Well, if you need someone with NVIDIA hardware on Linux to test anything, you know who to call. 20180404 09:22:30<+discordbot> (As long as it doesn't involve Nouveau.) 20180404 09:23:05<+discordbot> (I have a GTX 1060. Nouveau can't do reclocking on Pascal processors yet.) 20180404 09:23:24<+discordbot> Damn you. You have a better GPU than I. 20180404 09:23:25<+discordbot> Still low-level stuff. I have barely done anything. 20180404 09:23:33<+discordbot> I only have a GTX 950M 20180404 09:23:40<+discordbot> I also have 32 GB of RAM. 20180404 09:24:06<+discordbot> And I only have 16 20180404 09:24:10<+discordbot> and when YOU had 16 I had 8 20180404 09:24:11<+discordbot> 😐 20180404 09:24:15<+discordbot> And your hardware wouldn't be very useful for my testing. I also have Geforce GTX 1060, and I dual boot Windows and GNU/Linux. 20180404 09:24:31<+discordbot> Is it also the 6 GB version? 20180404 09:24:36<+discordbot> Yep. 20180404 09:25:30<+discordbot> I also have a laptop with whatever graphics Ivy Bridge CPUs shipped with and a GT 735M. 20180404 09:25:39<+discordbot> But that runs Windows 10. 20180404 09:25:46<+discordbot> I currently have 16 GB of system memory - the capacity went down when I upgraded my CPU and motherboard in January. My new CPU isn't compatible with DDR3, and 32 gigabytes would have been way too expensive. 20180404 09:26:24<+discordbot> AT least your laptop is worse than mine 20180404 09:26:43<+discordbot> I know. 20180404 09:27:24<+discordbot> The worst part is this stupid hardware issue where the trackpad randomly stops working correctly until the next power cycle, so I am forced to use the keyboard and/or touchscreen to get myself out. 20180404 09:28:03<+discordbot> And I usually can't be bothered to plug in a mouse since my only decent mouse anymore is plugged in an awkward place on my main desktop screen. 20180404 09:28:47<+discordbot> I use a bluetooth mouse 20180404 09:28:59<+discordbot> On the plus side, mid-end systems are useful for testing too. 20180404 09:29:18<+discordbot> More useful than high-end setups. 20180404 09:29:41<+discordbot> It's an Intel Core i7-3537U. 20180404 09:30:42<+discordbot> So that's Intel HD 4000 Graphics. 20180404 09:33:28<+discordbot> is looking forward to redstone 4 20180404 09:33:51<+discordbot> Why? Is there some feature in particular you're waiting for? 20180404 09:35:08<+discordbot> What's 1803 again? I lost track when they decided to be as uncreative as possible with the codenames. 20180404 09:35:19<+discordbot> Oh, RS4 is 1803. 20180404 09:35:59<+discordbot> I just like Windows updates 20180404 09:36:10<+discordbot> You're weird. 😛 20180404 09:36:15<+discordbot> Lucky you. You don't run software that breaks with them. 20180404 09:36:29<+discordbot> I like the way they're making the interface looks more fluid and modern 20180404 09:36:33<+discordbot> Or have to pay for every gigabyte downloaded. 20180404 09:36:57<+discordbot> Hey, neither of us live in Finland with its literally obscene internet speeds. 20180404 09:37:09<+discordbot> I may not have a data cap, but it's still slow 20180404 09:37:42<+discordbot> I read this article before the other day. There's literally nothing in 1803 to make me even remotely excited. 20180404 09:38:30<+discordbot> "The Display page also introduces a new Graphics settings section that includes customization options to manage preferences for apps on computers with multiple GPUs." — Can't wait to see exactly how that plays along with the NVIDIA Control Panel. 20180404 09:42:06<+discordbot> Apparently Windows and Linux processes can now use domain sockets for IPC between each other. 20180404 09:42:31<+discordbot> Now that is something I can get behind. 20180404 09:42:52< grzywacz> Hardware porn. I have 4GB RAM and can barely compile wesnoth with latest gcc. :P 20180404 09:42:55< grzywacz> O tempora... 20180404 09:43:13<+discordbot> 4 GB of RAM stopped being enough to compile Wesnoth without much hassle around 2010. 20180404 09:43:42<+discordbot> I.e. shortly after I upgraded a laptop from 2 GB to 4 and then its GPU went up in flames. 20180404 09:45:08<+discordbot> (That's hyperbole. It didn't catch fire, it just probably desoldered itself. Got it fixed but I never made much use of the laptop after that because it was in a poor state anyway.) 20180404 09:45:09< grzywacz> That's about the time when I stopped compiling wesnoth regularly. ;-) 20180404 09:45:27<+discordbot> Yeah. Meanwhile several of us still stuck around. 20180404 09:45:51< grzywacz> `make` still works, but running a parallel build equals death. 20180404 09:46:01<+discordbot> Watching Wesnoth's compile time grow by a factor of 2 or 3 every development cycle. 20180404 09:46:14< grzywacz> Tools seem to be getting worse. 20180404 09:46:18<+discordbot> Sorting out past devs' mistakes. 20180404 09:46:24< grzywacz> Any luck with clang or sth? 20180404 09:46:26<+discordbot> That kinda thing. 20180404 09:46:37< grzywacz> "Mistakes" is kinda harsh. 20180404 09:46:41<+discordbot> We've had support for Clang since 1.9.x. 20180404 09:46:50<+discordbot> Or perhaps more accurately 1.11.x. 20180404 09:47:15<+discordbot> Also, it is harsh, but true. 1.13.x has been primarily about solving the project's ginormous technical debt. 20180404 09:47:42< grzywacz> The debt was, and still is, quite big. 20180404 09:47:48<+discordbot> indeed 20180404 09:48:00< grzywacz> But one shouldn't talk like that about work people did for free in their free time. 20180404 09:48:03< grzywacz> (shrug) 20180404 09:48:15<+discordbot> Overambitious long term plans, needlessly dense and unmaintainable code, people leaving without making sure that their babies wouldn't become orphans, all have contributed to that. 20180404 09:49:05<+discordbot> It is true that it's all volunteer work (I should know that of all people), but it's also true that the people who then replace the developers who leave have to deal with it. 20180404 09:49:05< grzywacz> The only problem I really see with the project, and I since I've been away I'm probably mistaken, is lack of strong leadership in terms of design, features and quality. 20180404 09:49:14<+discordbot> And it's not exactly trivial in many cases. 20180404 09:50:03<+discordbot> There are many ideas that were good on paper but by certain devs' own admission didn't quite work out in practice. 20180404 09:50:46<+discordbot> That's kind of inevitable in any project that isn't designed to "scratch an itch". 20180404 09:51:11<+discordbot> Wesnoth exists for the sole purpose of existing. It's not like GCC or Linux or GNU coreutils. 20180404 09:51:29< grzywacz> True. 20180404 09:51:38< grzywacz> There's no guiding vision. 20180404 09:51:38<+discordbot> I only just this past month almost completely finished ripping out the old UI rendering system that was supposed to go bye bye a decade ago. So, yes, the technical debt is still there. 20180404 09:51:42< grzywacz> Which means a leadership problem. 20180404 09:51:58<+discordbot> grzywacz: I'm trying my best, ya know 😐 20180404 09:52:16< grzywacz> Vultraz: don't need to tell me that. I wanted to add some unit tests, a decade ago, but untangling the code was beyond my time limits. 20180404 09:52:36< grzywacz> More recently, last week, I wanted to compile a simple test program using Wesnoth's WML parser. 20180404 09:52:54<+discordbot> There will still be technical debt until the GUI2 ingame UI is finished and bug-free. Missing or buggy core features are also technical debt, just of different kind. 20180404 09:53:17<+discordbot> Vultraz, this is a more general thing. You've certainly done a lot of work this cycle (far more than one would expect from the release manager) and we're thankful for that because otherwise we'd still be betting our money on keeping 1.12.x on life support. 20180404 09:53:24< grzywacz> This is the list of object files I ended up with *after commenting out some code so as not to pull in all of SDL*: config_runner.o config.o serialization/parser.o log.o config_attribute_value.o serialization/tokenizer.o tstring.o gettext_boost.o deprecation.o serialization/preprocessor.o version.o game_config.o filesystem_boost.o color.o serialization/string_utils.o font/constants.o color_range.o 20180404 09:53:30< grzywacz> filesystem_common.o serialization/unicode.o serialization/binary_or_text.o 20180404 09:53:32< grzywacz> color_range, for WML parser? nice. ;) 20180404 09:54:05<+discordbot> But you got handed a project that was already facing issues. The beta cycle for 1.12 showed that. 20180404 09:54:31< grzywacz> Vultraz: I see your work and I think it's what this project needs. 20180404 09:54:38<+discordbot> The parser is another area I want us to take a look at later, indeed. But we can't do everything at once. We need to pick our focus, and right now, that focus is the rendering engine. 20180404 09:55:06< grzywacz> Well, I agree with you wholeheartedly. 20180404 09:55:13<+discordbot> color_range is pulled in by the game_config stuff that everyone and their dog wants to include. 20180404 09:55:19< grzywacz> Aside from some bugs 1.14 RCs look like a good step forward. 20180404 09:55:38<+discordbot> The thing is, a lot of tasks aren't necessarily independent. 20180404 09:55:42<+discordbot> Basically, for some inexplicable reason the team colour globals are part of the same unit as the version number. 20180404 09:55:52<+discordbot> accelerated rendering needed the gui2 transition to commence 20180404 09:56:00<+discordbot> i did the gui2 transition to make the sdl2 transition easier 20180404 09:56:43<+discordbot> the sdl2 transition also enabled me to do a preliminary a_r implementation 20180404 09:56:51<+discordbot> which will then allow jyrki to implement ogl 20180404 09:57:16<+discordbot> (Not saying it's not easy to fix, it's just that nobody has ever tried to solve that purely-technical coupling issue because it's low-priority work compared to everything else.) 20180404 09:57:46<+discordbot> (The TC globals being part of the same unit exposing the version number and other essential globals, I mean.) 20180404 09:58:20< grzywacz> Typical problems of legacy code that's all tangled together. Solvable, but with massive effort. 20180404 09:58:31<+discordbot> The preliminary implementation is indeed a useful first step. The implementation is still ridiculous for a hardware rendering implementation (in particular, it uses way too many render passes), but at least the part of "only redrawing screen areas which have changed" is gone. 20180404 09:59:33<+discordbot> it also does a lot fewer render passes than my initial initial implementation 😛 20180404 09:59:54<+discordbot> remember, I tried keeping the render-everything-in-each-hex-top-to-bottom-one-hex-at-a-time method 20180404 10:00:03<+discordbot> until I realized I could optimize by rendering all terrains... all units... etc 20180404 10:00:48<+discordbot> It especially reduced texture swapping overhead, since the entirety of, say, the reachmap or grid overlay, were drawn all at once 20180404 10:04:08<+discordbot> Well if anything you can feel proud of the fact that you have worked on this whereas I decided to sit at the back and dedicate myself to keeping campaignd on life support until someone comes along to replace both of us. The program and me I mean. 20180404 10:05:11<+discordbot> For me the display engine always seemed impossibly unapproachable and save for a very minor fix I never dared touch it at all, so I didn't learn anything. 20180404 10:07:25<+discordbot> (The fix was for a bug in the scroll-to-unit algorithm resulting from an oversight when replacing the [message] UI in 1.5.x, fixed in 1.11.2 or so.) 20180404 10:08:51<+discordbot> (Realising that it was a bug was probably harder than fixing it. I literally had to write a > 50 scenarios campaign over the course of 5 years to actually see the bug.) 20180404 10:10:19-!- oldlaptop_ [~quassel@45.63.78.126] has joined #wesnoth-dev 20180404 10:11:14-!- Soliton [~Soliton@wesnoth/developer/soliton] has quit [Disconnected by services] 20180404 10:11:17-!- grzywacz_ [~karol@89-70-226-147.dynamic.chello.pl] has joined #wesnoth-dev 20180404 10:11:18-!- Soliton_ [~Soliton@wesnoth/developer/soliton] has joined #wesnoth-dev 20180404 10:11:33-!- Soliton_ is now known as Soliton 20180404 10:14:45-!- crimson_pingvin [~crimson_p@ec2.happyspork.com] has joined #wesnoth-dev 20180404 10:15:15-!- heirecka_ [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev 20180404 10:16:03-!- Netsplit *.net <-> *.split quits: heirecka, grzywacz, crimson_penguin, oldlaptop, iwaim 20180404 10:16:03-!- crimson_pingvin is now known as crimson_penguin 20180404 10:16:04-!- crimson_penguin [~crimson_p@ec2.happyspork.com] has quit [Changing host] 20180404 10:16:04-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev 20180404 10:16:53-!- heirecka_ is now known as heirecka 20180404 10:17:24-!- grzywacz_ is now known as grzywacz 20180404 10:17:28-!- grzywacz [~karol@89-70-226-147.dynamic.chello.pl] has quit [Changing host] 20180404 10:17:28-!- grzywacz [~karol@wesnoth/developer/grzywacz] has joined #wesnoth-dev 20180404 10:23:18-!- Netsplit over, joins: iwaim 20180404 10:24:49<+discordbot> By the way, don't forget to add stuff you worked on for 1.14 here @ all: https://wiki.wesnoth.org/User:Shadowm/Stable_1.14_Announcement_Outline 20180404 10:25:33<+discordbot> I'm sure there's a lot of user-visible stuff that's still not mentioned there. 20180404 10:53:32<+discordbot> @shadowm , this is not true: 20180404 10:53:33<+discordbot> https://cdn.discordapp.com/attachments/259976436490829825/431043640186503179/unknown.png 20180404 10:55:04<+discordbot> on macOS and every platform there is no Retina/HiDPI support. Only change is, that thank to SDL2 there is no more problems with at least LowDPI res. 20180404 10:55:48<+discordbot> There was some control problems and etc (you remember these problems better than me) caused by Retina/HiDPI 20180404 10:56:24<+discordbot> I think that's perhaps what she means 20180404 10:56:41<+discordbot> "thank to SDL2 there is no more problems with at least LowDPI res" Could you rephrase that in a way we could add it to the release announcement? 20180404 10:58:30<+discordbot> thanks to SDL2 there are no more problems on Retina/HiDPI screens such as non-working controls, (please fill the rest problems) 20180404 10:59:35<+discordbot> I would prefer not say something like "Retina/HiDPI" support because wesnoth is still downscaled 20180404 11:01:46<+discordbot> I ended up writing it as "Resolves issues like non-working controls on Retina displays" 20180404 11:02:31<+discordbot> yes, that is usable 20180404 11:09:55< irker719> wesnoth: Charles Dang wesnoth:master b8d051cb72e5 / src/ (25 files in 10 dirs): Moved game version stuff from game_config.hpp to version.hpp https://github.com/wesnoth/wesnoth/commit/b8d051cb72e51682d0fc41a3a37442ed7ecb553d 20180404 11:20:47< grzywacz> <3 20180404 11:21:40< irker719> wesnoth: Charles Dang wesnoth:master cc78bb3b1c1c / src/serialization/ (preprocessor.cpp preprocessor.hpp): Preprocessor: cleaned up an unnecessary header include https://github.com/wesnoth/wesnoth/commit/cc78bb3b1c1c52bbde0971e71a22b38a1f022cad 20180404 11:23:31<+discordbot> By the way, weakly typed enums can also be forward-declared if the underlying type is specified explicitly. 20180404 11:23:32<+discordbot> https://en.wikipedia.org/wiki/C%2B%2B11#Strongly_typed_enumerations 20180404 11:24:00<+discordbot> huh 🤔 20180404 12:18:55< irker719> wesnoth/wesnoth:master Charles Dang 464f7ce628 GUI2: minor refactoring of window constr AppVeyor: All builds passed 20180404 12:22:21<+discordbot> I wonder if these can be replaced with their proper c++11 equivalents? https://github.com/wesnoth/wesnoth/blob/master/src/serialization/unicode_types.hpp That is... utf8::char_t -> char utf8::string -> std::string utf16::char_t -> char32_t utf16::string -> std::u16string ucs4::char_t -> char16_t ucs4::string -> std::u32string 20180404 12:24:53<+discordbot> I think so. 20180404 12:26:36< Soliton> std::string doesn't make it clear what encoding might be used with it. 20180404 12:27:26<+discordbot> In general, you can assume std::string to be UTF-8 by default in a modern C++ codebase. 20180404 12:27:56<+discordbot> 🤦🏼 20180404 12:28:20<+discordbot> "The character types are large enough to represent any UTF-8 code unit (since C++14)" 20180404 12:29:37<+discordbot> A UTF-8 code unit takes exactly 8 bits of space. 20180404 12:29:57< Soliton> yeah, i wonder how that could have not been the case before. 20180404 12:30:10<+discordbot> Even before C++14, the possibility of char not being large enough only existed on ancient systems which don't use 8-bit bytes. 20180404 12:30:12<+discordbot> 7-bit bytes 20180404 12:31:05< Soliton> when did c++ allow 7bit char? 20180404 12:31:14<+discordbot> since day-0 20180404 12:31:36<+discordbot> until c++14 20180404 12:33:09< Soliton> are you refering to signed char or what? 20180404 12:34:21<+discordbot> char 20180404 12:35:57< Soliton> you got anything to back that up? 20180404 12:36:03<+discordbot> Want some fun? Port some 9-bit standard code to 7-bit 20180404 12:36:25< Soliton> afaik you can have char with more than 8 bits but not with less. 20180404 12:36:54< Soliton> i think some pdp whatever used 9 bits. 20180404 12:37:04<+discordbot> PDP-8 20180404 12:37:33<+discordbot> And CDC used 36-bit IIRC. 20180404 12:38:04< Soliton> that's all fine since afaik the standard mandates at least 8 bit. 20180404 12:38:39<+discordbot> Didn't used to. It used to say "the nartual size for stroring character data" 20180404 13:23:33< Soliton> http://port70.net/~nsz/c/c89/c89-draft.html (see 2.2.4.2) even c89 mandated CHAR_BIT to be equal or greater than 8. 20180404 13:24:31<+discordbot> Huh, interesting. I didn't know that. 20180404 13:25:40<+discordbot> It really raises the question why C++14 started to explicitly specify that char must be large enough to represent any UTF-8 code point. Judging from this, it has been the case ever since C++98 at least, if not earlier. 20180404 13:26:37< grzywacz> Maybe just for clarity... 20180404 13:26:41<+discordbot> Because C++ is NOT C. 20180404 13:27:06< Soliton> but c++ refers to the c standard for certain things. 20180404 13:27:08<+discordbot> It's almost fully backwards compatible, though. 20180404 13:28:20<+discordbot> Two different committees. And if the C++ committee could drop C backwards compatibility completely, they would. 20180404 13:28:21< Soliton> i think maybe that quote is refering to the execution or input character set or whatever. like the encoding of the source code itself. 20180404 13:28:53< Soliton> maybe that only required 7 bit ascii before. 20180404 13:29:34<+discordbot> No, it was "natural character representation" because you can't for EBCDIC in a 7-bit byte. 20180404 13:30:02<+discordbot> can't do 20180404 13:30:12< Soliton> for the source code encoding, sure. 20180404 13:31:06<+discordbot> Which includes quoted strings. 20180404 13:32:09< Soliton> well, perhaps there was a misunderstanding then since i was talking about the size of char. 20180404 13:32:22<+discordbot> So was I. 20180404 13:33:19<+discordbot> And I. The problem was (and I remember a lot of talk about it) that a char literal or quoted string had to be representable in BOTH the source and execution character set. 20180404 13:35:02<+discordbot> There are entire families of machines which can not compile "stanrdard" C / C++ anymore because we don't alow Trigraphs any more. So we have source CS code points which are not representable in the execution CS .. like // for a comment. 20180404 13:35:29<+discordbot> why would you need trigraphs 20180404 13:36:40< Soliton> to represent characters that are not in your input charset presumably. 20180404 13:37:34< Soliton> like if you can only write your source code in 7 bit ascii or ebcdic or whatever. 20180404 13:39:17< Soliton> well, probably more of an input method issue since the trigraphs seem to be all in ascii. 20180404 13:40:05<+discordbot> Yes, EBCDIC was a problem. And reading old C code with all those ??- and ??! or whatever was a royal paing in the arse. 20180404 13:46:37<+discordbot> The problem was C was writting for the PDP-11 and that meant ASCII. So bits of the language could not be written in EBCDIC. There were other encodings, too, but I don't recall ever meeting them. Trigraphs were a slimy hack and we're better off without them. But they couldn't go away until the legacy systems which needed them were sufficiently in the past. 20180404 13:53:29<+discordbot> Let's see what travis says 20180404 13:53:36<+discordbot> might not work 20180404 13:54:40-!- Oebele_ [~quassel@143.177.58.202] has joined #wesnoth-dev 20180404 14:26:02-!- grzywacz [~karol@wesnoth/developer/grzywacz] has quit [Quit: Lost terminal] 20180404 14:39:05-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180404 14:39:11-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180404 15:05:19<+discordbot> Travis passed 20180404 15:12:33-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180404 15:19:10-!- irker719 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20180404 15:26:26-!- irker428 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20180404 15:26:26< irker428> wesnoth/wesnoth:1.14 Charles Dang f78e32c7f8 Fixed images with no alpha channel rende AppVeyor: All builds passed 20180404 15:28:49<+discordbot> That's sort of like the Stock Broker who jumped, as he passes the 3rd Floor, "OK, so far!" 20180404 15:48:06<+discordbot> Anyone opposed if I just merge that PR? 20180404 15:51:56< Soliton> if noone sees value in the typedefs sure why not. the commit message is a bit odd like there is some functional change but whatever. 20180404 15:54:10<+discordbot> You mean 2831? Sure, go ahead. It should be safe. I'd not be surprised if some obscure problem results from it in the future; but it would be better to fix that than keep a bunch of meaningless custom types. 20180404 15:54:34< irker428> wesnoth: Charles Dang wesnoth:master 1deacd89f640 / src/ (31 files in 12 dirs): Convert custom unicode type aliases to proper types (available as of C++11) https://github.com/wesnoth/wesnoth/commit/1deacd89f640e1ddada75e1286c14a09ab8cce62 20180404 16:05:16-!- TC01 [~quassel@venus.arosser.com] has quit [Read error: Connection reset by peer] 20180404 16:06:53-!- TC01 [~quassel@venus.arosser.com] has joined #wesnoth-dev 20180404 16:21:58< irker428> wesnoth: gfgtdf wesnoth:1.14 56cf77e3a001 / data/lua/wml/message.lua: fix [message] side_for= not working for the last side. https://github.com/wesnoth/wesnoth/commit/56cf77e3a0014b656870ce2b340d76e1a23721ab 20180404 16:31:08-!- Bhoren [~Bhoren_wh@2a01:e0a:c:2150:291a:12b9:7ebe:3ed2] has joined #wesnoth-dev 20180404 16:47:10-!- Oebele_ [~quassel@143.177.58.202] has quit [Remote host closed the connection] 20180404 17:01:44-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20180404 17:11:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180404 17:32:25-!- oldlaptop_ is now known as oldlaptop 20180404 17:56:48-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20180404 18:13:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer] 20180404 18:14:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180404 18:27:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180404 18:44:12<+discordbot> @hrubymar10 Yes, that's what I meant by Retina support. 20180404 18:44:26<+discordbot> kk 🙂 20180404 18:45:02<+discordbot> Since the previous situation with Retina was, in the words of ancestral, "". 20180404 18:45:28<+discordbot> I think SDL 2.0 also fixes being unable to go fullscreen on macOS? 20180404 18:45:48<+discordbot> I should probably check the 1.13.2 announcement. 20180404 18:45:53<+discordbot> Yes, it does 20180404 18:46:00< irker428> wesnoth/wesnoth:master Charles Dang cc78bb3b1c Preprocessor: cleaned up an unnecessary AppVeyor: All builds passed 20180404 18:46:33<+discordbot> *1.13.[34] 20180404 18:46:47<+discordbot> Eh. It doesn't say anything. Just "the game now uses SDL 2". 20180404 18:47:20<+discordbot> OTOH the changelog has this: * Greatly improved SDL 2 support. SDL 2 is now used by default build when building. This fixes the following bugs, among others: * Bug #18112: Color cursors cause slow mouse movement at menus * Bug #19666: When I resize windows during dialog I lose the menu buttons * Bug #20332: Cursor not mapping correctly on Retina display when in Windowed mode * Bug #23820: SDL 2 alpha blending issues 20180404 18:47:20<+discordbot> * Bug #23821: Text input is broken in GUI1 under SDL 2 * Bug #23908: SDL 2 SDL_BlitSurface causes crashes * Bug #23918: UI graphics garbled on OS X 10.11 El Capitan * Bug #23934: Resize actions are laggy * Bug #24138: SDL 2 crash on resize after starting a game and returning to the title screen * Bug #24209: Screen becomes black upon minimise and restore * bug #24212: SDL 2 build handled input incorrectly once window 20180404 18:47:21<+discordbot> focus is lost when menus are open * Bug #24213: SDL 2 build leaves menu items stuck if window dimensions change while open * Bug #24214: SDL 2 build handles fullscreen toggle badly * Bug #24260: Menu and Action buttons disappear on resize * Bug #24261: Area under Objectives not redrawn on resize * Bug #24294: Doubled-up GUI1 dialogs don't redraw the secondary in SDL2 * Bug #24477: Segfault when launching Credits 20180404 18:48:46<+discordbot> Eh, other than #23918 none of them sound noteworthy to me. 20180404 18:49:06<+discordbot> And I don't even know if it was ever relevant outside of the dev series. 20180404 18:54:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180404 18:54:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180404 19:10:20-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180404 19:10:26-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180404 19:28:58-!- grzywacz [~karol@89-70-226-147.dynamic.chello.pl] has joined #wesnoth-dev 20180404 19:29:07-!- grzywacz [~karol@89-70-226-147.dynamic.chello.pl] has quit [Changing host] 20180404 19:29:07-!- grzywacz [~karol@wesnoth/developer/grzywacz] has joined #wesnoth-dev 20180404 19:36:35< irker428> wesnoth: Nils Kneuper wesnoth:master b45b0a3cbd99 / po/wesnoth-lib/pl.po: updated Polish translation https://github.com/wesnoth/wesnoth/commit/b45b0a3cbd99eb6558e0462f14f7cc8be111e264 20180404 19:36:40< irker428> wesnoth: Nils Kneuper wesnoth:1.14 6e5ec982bc89 / po/wesnoth-lib/pl.po: updated Polish translation https://github.com/wesnoth/wesnoth/commit/6e5ec982bc899809e2e0483d7ecbd2a6f9d88ed6 20180404 20:05:13-!- Bhoren [~Bhoren_wh@2a01:e0a:c:2150:291a:12b9:7ebe:3ed2] has quit [Quit: Leaving] 20180404 20:36:24< irker428> wesnoth/wesnoth:master Charles Dang c1040b803c Convert custom unicode type aliases to p AppVeyor: All builds passed 20180404 20:57:29-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180404 20:57:35-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180404 21:12:58-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds] 20180404 21:54:27-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20180404 22:05:32< irker428> wesnoth/wesnoth:master Charles Dang 1deacd89f6 Convert custom unicode type aliases to p AppVeyor: All builds passed 20180404 22:40:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180404 23:08:10-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180404 23:38:38<+discordbot> Did someone un-line wrap that SDL 2 support heading in the changelog? 20180404 23:40:17< irker428> wesnoth: gfgtdf wesnoth:master 0f756b81899e / data/lua/wml/message.lua: fix [message] side_for= not working for the last side. https://github.com/wesnoth/wesnoth/commit/0f756b81899ed9e965eb4f40b67bfeaaa3a1e518 20180404 23:41:05<+discordbot> gfgtdf please forward-port your commits 20180404 23:51:01-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20180404 23:52:45<+discordbot> You could find out yourself. Ctrl+F on the changelog. 20180404 23:54:23<+discordbot> good, good, it's still long 20180404 23:54:57< mattsc> celticminstrel: I am trying to catch up with the Wesnoth Lua status. Is the ‘wml’ library(?) documented somewhere? 20180404 23:55:06<+discordbot> Oh. 20180404 23:55:20<+discordbot> @Vultraz I pasted it like that because it was like that in the 1.13.4 tag's changelog. 20180404 23:55:26<+discordbot> (Obviously.) 20180404 23:55:41<+discordbot> I made it one line during the markdown conversion 20180404 23:55:46<+discordbot> it was necessary 20180404 23:55:46<+discordbot> 1.13.4 TAG 20180404 23:55:51<+discordbot> yes 20180404 23:55:51<+discordbot> It's past history. 20180404 23:55:56< celticminstrel> I have not yet documented the "wml" library. 20180404 23:56:02< celticminstrel> I need to do so soon though. 20180404 23:56:10< celticminstrel> It's mainly things moved from helper, though. 20180404 23:56:11<+discordbot> The whole point of tags is that stuff like this can't be altered. 20180404 23:56:12< celticminstrel> ^ mattsc 20180404 23:56:38< mattsc> celticminstrel: Okay. I found where it’s defined, so I can get the information I need on that from there. 20180404 23:56:46< celticminstrel> Yeah it's defined in core.lua. 20180404 23:57:25< mattsc> Right. Now, what I was actually trying to do is understand the recent switch away from ai.synced_command. 20180404 23:57:42< celticminstrel> gfgtdf was the one who removed that all of a sudden. 20180404 23:57:54< mattsc> Because I have an instances of that in on of my campaigns. 20180404 23:58:21< mattsc> Well, gfgtdf had been talking about this for a long time, but then it happened pretty quickly, yes. 20180404 23:58:29< celticminstrel> I agree with the move in principle, but removing it entirely is maybe a bit too sudden... 20180404 23:58:59< celticminstrel> I guess at minimum we'd need to write information on how to port old code over, like we did with the Lua CA API changes. 20180404 23:59:25< mattsc> I presume that wesnoth.invoke_synced_command() etc. are not documented at this time either? 20180404 23:59:31< celticminstrel> Not yet, no. 20180404 23:59:49< celticminstrel> Maybe this commit can help? (searching for it now) --- Log closed Thu Apr 05 00:00:02 2018