--- Log opened Tue May 29 00:00:13 2018 20180529 00:00:17<+discordbot1> gfgtdf: It doesn't happen if I disable the animation. 20180529 00:01:35<+discordbot1> I wonder if that might also be behind the crash in my campaign. 20180529 00:03:03< gfgtdf> hmm 20180529 00:04:02< gfgtdf> does it also happen without addons? (without 'disable_loadingscreen_animation=yes' ) ofc 20180529 00:04:33<+discordbot1> My add-ons do not inject any code when they aren't running, for the record. 20180529 00:05:16< gfgtdf> ok and you have no other addons installled? 20180529 00:05:23<+discordbot1> And yes, it still crashes when the animation is enabled if I run without any add-ons installed. 20180529 00:05:35<+discordbot1> (Renamed the add-ons dir.) 20180529 00:05:36< gfgtdf> also this coudl easily be a memeory corruption that is unrelated to your stacktrace 20180529 00:06:24<+discordbot1> That's the fun thing about heap corruption. 20180529 00:06:44<+discordbot1> You can't easily tell where it came from without using valgrind. 20180529 00:06:59<+discordbot1> (Which I have, but... ugh.) 20180529 00:07:46< gfgtdf> or maybe we have to make the code involved in ::image::get_image(::image::locator(...)) threassafe 20180529 00:10:55< mattsc> celticminstrel: gfgtdf fixed a bug (inefficiency) in the evaluation of [and] in SUFs earlier today. Since then, what we talked about yesterday for combining the check for moves and other filters works well and fast. 20180529 00:11:06< mattsc> So as you suggested, there’s no need for a basic and an advanced filter any more for the mainline implementations of the MAIs. 20180529 00:22:30< celticminstrel> Eh? 20180529 00:26:38< celticminstrel> Ah, I see. 20180529 00:26:55< celticminstrel> If you add a changelog entry gfgtdf, please mention [or] and [not] too. 20180529 00:28:57< celticminstrel> ...wait what? Why do leaders have upkeep defaulting to full? 20180529 00:29:08< celticminstrel> They don't actually cost upkeep, right? 20180529 00:29:47< celticminstrel> (I assume beetlenaut is using [filter_wml]?) 20180529 01:21:20-!- gfgtdf [~gfgtdf@134.76.63.8] has quit [Quit: Leaving] 20180529 01:24:04<+discordbot1> gfgtdf: Is an image involved in the animation? I kind of assumed it was procedural but I haven't looked at it. 20180529 01:24:58<+discordbot1> How does the loading screen actually work, anyway? 20180529 01:28:21<+discordbot1> The main thread handles drawing the window, and the worker thread handles whatever loading process you throw at it. In 1.14, a timer handles updating the animation and checks for worker thread completion every 100 ms. In master, drawing is handled by a DRAW hook (which is why it's so much faster), and the worker check is done every time events::run_event_loop is called by means of a pump observer 20180529 01:29:11<+discordbot1> What is the worker thread normally instructed to do then? 20180529 01:29:54<+discordbot1> i.e. why are thread-safety provisions required for the image cache code? 20180529 01:30:52<+discordbot1> Mostly, preprocess the cache and load the game, or connect to the MP server. As for image thread-safety... awhile back, I added a fix to a bug where images are shared between campaigns 20180529 01:30:58<+discordbot1> ifthey had the same name 20180529 01:30:59<+discordbot1> for exampel 20180529 01:31:06<+discordbot1> if you played iftu followed by utbs 20180529 01:31:22<+discordbot1> utbs's elyssa would have iftu elyssa's portrait 20180529 01:31:42<+discordbot1> I fixed that by clearing the image cache when refreshing the cache 20180529 01:31:54<+discordbot1> it was pointed out this might cause problems for the loading screen 20180529 01:32:14<+discordbot1> since in this case the cache would be cleared by the worker thread and accessed by the drawing in main 20180529 01:32:24<+discordbot1> but it hasn't seemed to manifest itself 20180529 01:32:32<+discordbot1> Wait. 20180529 01:32:41<+discordbot1> Are you saying you're WAITING for that to happen? 20180529 01:32:51<+discordbot1> also, image::locator is also thread-unsafe on its own since it modifies a global state 20180529 01:33:21<+discordbot1> A lot of things are. 20180529 01:33:32<+discordbot1> The question is why are they being called from the wrong thread in the first place. 20180529 01:33:52<+discordbot1> As an aside note, gambling isn't part of coding. 20180529 01:34:17<+discordbot1> If you know there might be a way to trigger a bug that's not been observed in the wild, you're supposed to fix it before anyone has a chance to come across it. 20180529 01:34:48<+discordbot1> For all I know the bug I posted above might be the bug you're expecting to happen. 20180529 01:38:27<+discordbot1> there's a simple way to confirm that. comment out src/game_config_manager.cpp:573 and see if it still happens 20180529 01:42:10<+discordbot1> (there is another image::flush_cache call in that file but I don't think it's the problem) 20180529 01:45:12<+discordbot1> Yep. 20180529 01:45:18<+discordbot1> It doesn't happen if I comment it out. 20180529 01:45:35<+discordbot1> The one at line 573, specifically. I didn't touch the other one. 20180529 01:46:02<+discordbot1> Sooo... yeah, good job, you are a visionary AND a gambler. 20180529 01:46:25<+discordbot1> alright, thanks 20180529 01:46:30<+discordbot1> I'll need to figure out how to fix this 20180529 01:46:39<+discordbot1> Do you need a bug report? 20180529 01:46:47<+discordbot1> hmmm 20180529 01:47:16<+discordbot1> No, I think I got it. Plus I think there might already be one 20180529 01:47:33<+discordbot1> https://github.com/wesnoth/wesnoth/issues/2903 20180529 01:50:13<+discordbot1> gfgtdf: ok, so I think we need to guard the image cache with a bunch of mutexes 20180529 01:53:18<+discordbot1> or perhaps the caches themselves need to be made atomic? 20180529 01:59:46< celticminstrel> What do you mean by that? 20180529 02:00:06< irker528> wesnoth/wesnoth:1.14 Jyrki Vesterinen 6d8957ca5c Changelog entries AppVeyor: All builds passed 20180529 02:00:09< celticminstrel> I'll just say that making a complicated operation atomic is probably not a good idea. 20180529 02:00:25< celticminstrel> But I can't tell if that's what you're talking about. 20180529 02:04:13<+discordbot1> the cache objects themselves 20180529 02:05:12-!- mattsc_ [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180529 02:07:05-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Ping timeout: 256 seconds] 20180529 02:07:05-!- mattsc_ is now known as mattsc 20180529 02:11:41< celticminstrel> What about them? 20180529 02:12:11<+discordbot1> if one thread clears them and another accesses them, that's a problem, yes? 20180529 02:12:35< celticminstrel> So what you want to do is synchronize their methods or some such? 20180529 02:12:38<+discordbot1> isn't that what std::atomic is for? 20180529 02:12:41< celticminstrel> Uh. 20180529 02:12:54<+discordbot1> "If one thread writes to an atomic object while another thread reads from it, the behavior is well-defined" 20180529 02:13:10< celticminstrel> I mean... 20180529 02:13:57< celticminstrel> When you're working with an object, most of what you're doing doesn't really count as a read or write on the object itself. I don't think it makes much sense to use std::atomic on an object. Now... I might be wrong? I may know some stuff about threading but I'm not an expert on it. 20180529 02:14:36< celticminstrel> But basically I think it makes more sense to either make the object's members atomic, or synchronize the object's methods. 20180529 02:15:13< celticminstrel> (I use the term "synchronize" because Java uses that as a keyword for this effect.) 20180529 02:15:33<+discordbot1> so you mean making the actual cache vector atomic? 20180529 02:16:39<+discordbot1> in cache_type 20180529 02:16:46< celticminstrel> (FTR, IIRC the technical term for what Java does is a "monitor", though I'm pretty sure it's called something else in the C++ threading library.) 20180529 02:16:51<+discordbot1> the main accessor is get_element 20180529 02:16:58<+discordbot1> and there's flush 20180529 02:17:25< celticminstrel> Well, making the vector itself atomic is a possibility, I guess... but that raises the same questionability as making the cache object atomic. 20180529 02:17:41<+discordbot1> I mean 20180529 02:17:54< celticminstrel> I don't really know how effective atomic is when used on an object. 20180529 02:17:55<+discordbot1> I could throw mutexes everywhere 20180529 02:18:08< celticminstrel> Mutexes would work, indeed. 20180529 02:18:45<+discordbot1> looks like you cannot have an atomic vector 20180529 02:18:51< celticminstrel> Or a conditional variable (I think that's what C++ calls a monitor). 20180529 02:19:11<+discordbot1> it's not trivially copyable 20180529 02:19:13< celticminstrel> Might be overkill in this use-case, not sure. 20180529 02:20:15<+discordbot1> so... 20180529 02:20:30<+discordbot1> could cache_type hold a mutex and then the two accessors lock it? 20180529 02:21:03< celticminstrel> This is a possibility. If you do that be sure to use lock_guard instead of manually locking it. 20180529 02:21:20< celticminstrel> Trying to remember how to use a conditional variable so I can determine whether it makes sense to use one here... 20180529 02:21:23<+discordbot1> obviously 20180529 02:21:59<+discordbot1> maybe we want unique_lock? 20180529 02:22:32< celticminstrel> Ah yes, I think it's probably not appropriate; a conditional variable basically lets you "wait' or "signal", so it's good for a producer and consumer setup, for example. 20180529 02:23:40<+discordbot1> celmin: https://pastebin.com/jAuzhtaA 20180529 02:28:42<+discordbot1> going to assume you silence is tacit approcal 20180529 02:28:44<+discordbot1> approval 20180529 02:28:49<+discordbot1> your 20180529 02:29:57<+discordbot1> @shadowm would you mind testing this patch and seeing if the bug persists? https://pastebin.com/ucGaey04 20180529 02:30:01<+discordbot1> celmin could've gone to the toilet. 20180529 02:30:18<+discordbot1> Or could've fallen down a cliff. 20180529 02:30:25<+discordbot1> oh dear 20180529 02:30:30< celticminstrel> I haven't even looked at it yer. 20180529 02:30:32< celticminstrel> yet 20180529 02:30:32<+discordbot1> or hit by a bus 20180529 02:31:40< celticminstrel> Well, your first paste does make sense to me. 20180529 02:31:47< celticminstrel> Not sure what unique_lock is or why you'd want it. 20180529 02:32:05<+discordbot1> which is why I didn't use it 20180529 02:32:15<+discordbot1> I forgot locks can't be held by two functions at once 20180529 02:32:54< celticminstrel> No idea what you're even talking about now. 20180529 02:33:09<+discordbot1> NEVERMIND 20180529 02:33:25< celticminstrel> You should probably learn about what a conditional variable is in any case. 20180529 02:33:39< celticminstrel> I don't think it's applicable here, though. 20180529 02:33:58<+discordbot1> Don't say "never mind" when I'm in the middle of linking a fresh build right off the oven. 20180529 02:34:12<+discordbot1> nevermind to celmin 20180529 02:34:13< celticminstrel> Unless you want to make the cache itself threaded, then it might come in handy. 20180529 02:34:20<+discordbot1> my thoughts on unique_lock aren't important 20180529 02:34:24<+discordbot1> what I gave you is fine 20180529 02:34:41<+discordbot1> @Vultraz Can't reproduce the bug with the patch applied. 20180529 02:34:46<+discordbot1> 😮 20180529 02:34:55< celticminstrel> So it was actually reliably reproduceable? 20180529 02:34:56<+discordbot1> mein gott it works 20180529 02:35:11<+discordbot1> On my system it was. 20180529 02:35:15< celticminstrel> Nice. 20180529 02:35:23 * celticminstrel replaces Vultraz's gott with a goth. 20180529 02:35:30<+discordbot1> I wouldn't bet on it though. 20180529 02:35:43<+discordbot1> It seems like it's timing related and my system just happens to be fast enough 20180529 02:35:59<+discordbot1> Will commit 20180529 02:36:08< celticminstrel> Mutexes do impact performance, right? 20180529 02:36:48<+discordbot1> No idea if the impact will be noticeable for our use cases. 20180529 02:36:53< celticminstrel> Yeah probably not/ 20180529 02:36:54<+discordbot1> Probably not to any extent we need worry about 20180529 02:36:57< celticminstrel> And deadlocks? 20180529 02:37:06<+discordbot1> Well, I was going to say "probably yes, sometimes". 20180529 02:37:06< celticminstrel> I feel like they're unlikely here but not sure. 20180529 02:37:08<+discordbot1> So, this change means the cache is thread-safe? 20180529 02:37:22-!- Netsplit *.net <-> *.split quits: ChipmunkV[m] 20180529 02:37:22<+discordbot1> I think you're supposed to tell me that. 20180529 02:37:24<+discordbot1> Since you're the one making it so. 20180529 02:37:32< celticminstrel> I dunno, is something thread-safe if it's possible to deadlock? (Is it possible to deadlock this?) 20180529 02:37:40-!- Netsplit over, joins: ChipmunkV[m] 20180529 02:37:40<+discordbot1> what is a deadlock 20180529 02:37:49<+discordbot1> 🤦 20180529 02:38:13< celticminstrel> It's when two threads are waiting for each other to finish before continuing. 20180529 02:38:13<+discordbot1> I'm no threading expert! 20180529 02:38:26< celticminstrel> So neither can make any progress. 20180529 02:38:34<+discordbot1> Which is why you should let threading experts write your threaded code vultraz. 20180529 02:38:47<+discordbot1> hmmmm 20180529 02:38:57<+discordbot1> I don't think it's possible in this case though. 20180529 02:39:00< celticminstrel> I can't see a way for this code to deadlock, but I'm not exactly an expert either (though clearly I know more than Vultraz). 20180529 02:39:02<+discordbot1> I don't think so either 20180529 02:39:36<+discordbot1> Basically you'd need to run into a situation where a thread ran into the lock, and was waiting for it, and the thread currently holding the lock decided to wait for the thread waiting for the lock to be released. 20180529 02:40:51< celticminstrel> Which I think amounts to flush and get_element being able to call each other (directly or indirectly), in this particular case. 20180529 02:41:14< celticminstrel> Pretty sure that, at least, is impossible. 20180529 02:41:40-!- ChipmunkV[m] [chipmunkvm@gateway/shell/matrix.org/x-tmspnclnpfsenzyf] has quit [Ping timeout: 240 seconds] 20180529 02:41:48-!- Kawa[m] [kawamatrix@gateway/shell/matrix.org/x-fhwuiiavwgcqeuwx] has quit [Ping timeout: 255 seconds] 20180529 02:41:52-!- Netsplit *.net <-> *.split quits: irker528 20180529 02:41:52-!- madmax28 [madmax28ma@gateway/shell/matrix.org/x-ejeuhydyjcbiinzz] has quit [Ping timeout: 256 seconds] 20180529 02:42:14-!- Netsplit over, joins: irker528 20180529 02:44:09-!- fabi_ [~fabi@200116b82b9e32000dc03a2cbb04bf70.dip.versatel-1u1.de] has joined #wesnoth-dev 20180529 02:44:29-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Ping timeout: 265 seconds] 20180529 02:45:01-!- Netsplit *.net <-> *.split quits: oldlaptop, Ravana_, behalebabo, DDR 20180529 02:45:19-!- Netsplit over, joins: behalebabo, DDR, Ravana_, oldlaptop 20180529 02:47:00-!- Netsplit *.net <-> *.split quits: APic, loonycyborg, aidanhs2, celticminstrel, janebot 20180529 02:47:22-!- Netsplit over, joins: celticminstrel 20180529 02:47:23-!- Netsplit over, joins: loonycyborg 20180529 02:48:03-!- Netsplit over, joins: janebot, APic, aidanhs2 20180529 02:48:13-!- APic [apic@apic.name] has quit [Max SendQ exceeded] 20180529 02:50:13-!- Netsplit *.net <-> *.split quits: Soliton, celticminstrel, wedge009, shadowm, behalebabo, irker528, TC01, Ravana_, +discordbot1, iwaim, (+11 more, use /NETSPLIT to show all of them) 20180529 02:50:15-!- Netsplit *.net <-> *.split quits: crimson_penguin 20180529 02:50:23-!- Netsplit *.net <-> *.split quits: galegosimpatico, vincent_c, Rhonda, nurupo, commavir, nore, timotei_, vihta, Polsaker, higgins, (+4 more, use /NETSPLIT to show all of them) 20180529 02:50:28-!- Netsplit *.net <-> *.split quits: AI0867, elias, DeFender1031, Jetrel_bot, minzbonbon 20180529 02:50:58-!- Netsplit over, joins: loonycyborg, celticminstrel, Ravana_, aidanhs2, janebot, oldlaptop, DDR, behalebabo, fabi_, irker528 (+22 more) 20180529 02:50:58-!- APic [apic@apic.name] has joined #wesnoth-dev 20180529 02:51:03-!- Netsplit over, joins: +discordbot1, shadowm, Ivanovic, heirecka, wedge009 20180529 02:51:11-!- Netsplit over, joins: Soliton, mattsc, TC01, Guest33538 20180529 02:51:23-!- discordbot3 [~discordbo@baldras.wesnoth.org] has joined #wesnoth-dev 20180529 02:51:23< discordbot3> Basically picture a tug of war between threads, except none of them can ever win without an intervening third party. 20180529 02:51:26-!- mode/#wesnoth-dev [+v discordbot3] by ChanServ 20180529 02:51:44< celticminstrel> XD 20180529 02:51:47-!- discordbot1 [~discordbo@baldras.wesnoth.org] has quit [Write error: Broken pipe] 20180529 03:00:07< irker528> wesnoth: Charles Dang wesnoth:1.14 0eb27e246bfc / src/image.cpp: Fixed an occasional crash resulting from multi-thread access of the image cache https://github.com/wesnoth/wesnoth/commit/0eb27e246bfc842655ee5ee4d3e1ddc326e87ebb 20180529 03:01:27< irker528> wesnoth: Charles Dang wesnoth:master 6d0b7c84243a / src/image.cpp: Fixed an occasional crash resulting from multi-thread access of the image cache https://github.com/wesnoth/wesnoth/commit/6d0b7c84243aba8444f5e722cd855feed3501f12 20180529 03:14:38-!- ChipmunkV[m] [chipmunkvm@gateway/shell/matrix.org/x-njbzktoszawhovmp] has joined #wesnoth-dev 20180529 03:44:40<+discordbot3> @Vultraz Have you measured the performance impact? cache_type::get_element() is performance-critical code, and mutexes are expensive. 20180529 03:44:49<+discordbot3> no 20180529 03:45:35<+discordbot3> I am actually curious now, why on earth would a thread other than the main thread ever need to call that? 20180529 03:45:49<+discordbot3> image::flush_cache is called by the worker 20180529 03:45:53<+discordbot3> I understand the worker thread needs to clear the cache, but not access it. 20180529 03:46:03<+discordbot3> It doesn't need to read from it. 20180529 03:46:16<+discordbot3> The image cache can be accessed whenever an image is drawn anywhere. 20180529 03:46:27<+discordbot3> The worker thread shouldn't be drawing images. 20180529 03:46:54<+discordbot3> are you saying only the flush() function needs a mutex? 20180529 03:47:00<+discordbot3> Or loading them either. 20180529 03:47:10<+discordbot3> I don't know, I'm not the one who came up with the threaded load process. 20180529 03:47:29<+discordbot3> What happens if you put an assert in there checking that the method is only called by the main thread? 20180529 03:50:22<+discordbot3> in get_element? 20180529 03:50:25-!- Kawa[m] [kawamatrix@gateway/shell/matrix.org/x-etitbkxjqjefdloa] has joined #wesnoth-dev 20180529 03:50:25-!- madmax28 [madmax28ma@gateway/shell/matrix.org/x-upalhxaxxdlwiatd] has joined #wesnoth-dev 20180529 03:51:31<+discordbot3> Obviously. 20180529 03:51:54<+discordbot3> We already know the flush method is called from the worker thread, and that's how we got here. 20180529 03:52:30<+discordbot3> I could do such a thing 20180529 03:52:50<+discordbot3> but I can't guarantee a worker thread would never need to fetchsomething from the cache 20180529 03:53:01<+discordbot3> this cache mechanism isn't just used for usrfaces/textures 20180529 03:53:08<+discordbot3> there'salso a file existence cache 20180529 03:53:19<+discordbot3> and also aworker might want to fetch a syrface to get image size 20180529 03:54:19<+discordbot3> Here's how you normally do these things: you tell people to not call the method from the wrong thread. 20180529 03:54:47<+discordbot3> Also I just realized that my question is stupid 20180529 03:55:39<+discordbot3> That's how you can tell someone shouldn't touch threaded code, if they ask stupid questions they should already know the answer to. 20180529 03:56:41<+discordbot3> So here's why my question is stupid: there's no point in making the flush method hold a lock and let get_element() get away with accessing the cache any time scot-free unless the issue is that more than one thread can call flush() at the same time. 20180529 03:57:02<+discordbot3> The issue is not that. The issue is that any thread can call flush() at the same time as another thread calls get_element(). 20180529 03:57:19<+discordbot3> essentially 20180529 03:57:22<+discordbot3> So yes, both methods need to acquire the mutex. 20180529 03:57:46<+discordbot3> I just think it may be too fine-grained way to deal with the issue. 20180529 03:58:05<+discordbot3> An alternative fix would be to simply not flush the cache from other threads. 20180529 03:58:08<+discordbot3> if jyrki knows a better method I'd be happy to hear it 20180529 03:58:14<+discordbot3> The only thing we need to ensure is that one thread doesn't flush the cache while another is accessing it. 20180529 03:58:18<+discordbot3> Tell the main thread to flush the cache as soon as it has the chance to do so. 20180529 03:58:36<+discordbot3> For example, we could completely block the loading screen from drawing for the duration of the flush. 20180529 03:58:50<+discordbot3> Or indeed, flush the cache in the main thread. 20180529 04:00:17<+discordbot3> i doubt the performance hit of mutexes can be that huge 20180529 04:00:57<+discordbot3> https://gist.github.com/jboner/2841832 20180529 04:01:52< celticminstrel> Pretty sure the performance hit of mutexes can be significant? 20180529 04:01:57<+discordbot3> 25 nanoseconds. 20180529 04:02:19<+discordbot3> That actually sounds at least an order of mangitude too small to me... 20180529 04:02:25<+discordbot3> *magnitude 20180529 04:02:38< celticminstrel> That's just for lock/unlock though. 20180529 04:02:55< celticminstrel> The fact that you have to wait for the lock to be released will also impact performance, right? 20180529 04:02:58<+discordbot3> Locking a true mutex involves a system call. 20180529 04:03:06< celticminstrel> Probably more than the time it actually takes to lock/unlock? 20180529 04:03:13<+discordbot3> That's the slow part assuming no lock contention. 20180529 04:03:56<+discordbot3> To start with, it's hard to imagine that a syscall would succeed without needing to access system RAM, which takes 100 ns according to that same gist. 20180529 04:05:06<+discordbot3> I think it won't be noticeable in the average case, which is the only thing that concerns vultraz. 20180529 04:05:17<+discordbot3> As a content creator though, I am concerned about the non-average case. 20180529 04:05:45< celticminstrel> Like DeFender1031's elaborate cutscenes, right? 20180529 04:05:57<+discordbot3> There's already the issue with certain images (cough cough terrain graphics) not being preloaded ahead-of-time, so the first time they're required to be rendered the game blocks on I/O. 20180529 04:06:01<+discordbot3> Or TLU 20180529 04:06:12< irker528> wesnoth/wesnoth:master Jyrki Vesterinen ae8baa6356 Changelog entries AppVeyor: All builds passed 20180529 04:06:22<+discordbot3> I don't know what DeFender1031 makes, haven't heard of it. 20180529 04:07:17<+discordbot3> TLU is all the rage these days though, and it has some cinematic sequences and (when I last heard of it long before 1.14) other visual effects fluff that makes IftU and AtS look like the output of Wesnoth Campaign Development 101 in comparison. 20180529 04:07:55<+discordbot3> Odds are that if you look hard enough you'll find more performance-sensitive code in there. 20180529 04:08:10<+discordbot3> HAH 20180529 04:08:15< celticminstrel> TLU? 20180529 04:08:26<+discordbot3> The Lands Unknown, inferno8's campaign. 20180529 04:08:31< celticminstrel> Ah. 20180529 04:08:39< celticminstrel> (Isn't it "to" not "the"?) 20180529 04:08:48<+discordbot3> To. 20180529 04:08:50<+discordbot3> http://i0.kym-cdn.com/entries/icons/original/000/017/204/CaptainAmerica1_zps8c295f96.JPG 20180529 04:09:10< celticminstrel> Someday I should actually play a user-made campaign. >_> 20180529 04:09:16<+discordbot3> You probably haven't seen the bug report wherein we quickly came to the conclusion that it needs to address more than the lower 2 GB of RAM allocated to 32-bit user mode processes on Windows. 20180529 04:09:55<+discordbot3> (And we can't provide a 64-bit Windows build yet because rebuilding the Gnome libraries for it is reportedly non-trivial.) 20180529 04:10:13<+discordbot3> loony said he could do it 20180529 04:10:23<+discordbot3> since he uses mingw 20180529 04:10:31<+discordbot3> it's the vs libs that are hard 20180529 04:11:02-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] 20180529 04:12:42<+discordbot3> I think in my brain it's just unacceptable for a campaign's name to begin with a preposition. 20180529 04:13:25<+discordbot3> This is probably the 100th time I call it The Lands Unknown and I don't expect it'll stop happening any time soon. 20180529 04:55:25-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has quit [Ping timeout: 260 seconds] 20180529 05:11:41<+discordbot3> jesus, reading that thread where the faction sorting is discussed... 20180529 05:17:35<+discordbot3> I'm gonna be honest, it kinda pisses me off that ravana went looking specifically for a hack to get around a perfectly logical change 20180529 05:17:44<+discordbot3> and then advertised it 20180529 05:19:42<+discordbot3> so much so that I'm extremely tempted to specifically strip out zero-width spaces. 20180529 05:22:53<+discordbot3> Uh, you're supposed to work together with UMC authors, not fight against them. 20180529 05:23:12<+discordbot3> ^ 20180529 05:29:30<+discordbot3> It's the way the complaints were presented. Not as a "well, I'd really like to have a specific sorting order because it's useful for my addon". It was instead presented as "god this change is so fucking stupid and absurd, so we're gonna call it a bug even though it's not, and here's let's go find some absurd hack to work around it irrespective of what the original author's intent was." Instead of asking me why I made the change, 20180529 05:29:30<+discordbot3> or even accepting that I had reasons for it, it comes across as whiny and demanding. 20180529 05:31:40<+discordbot3> Even then, it's understandable why they would resort to hacks. 20180529 05:32:06<+discordbot3> They wanted some way to disable the automatic sorting now. 20180529 05:32:22<+discordbot3> Without having to wait for a future release. 20180529 05:32:23<+discordbot3> Sure. But saying something is a bug because you don't like they behavior is just rude. 20180529 05:32:54<+discordbot3> And makes me really, really reluctant to add sorting options 20180529 05:33:05<+discordbot3> Yeah, I have to agree with that. Factions being sorted in alphapetical order doesn't look like something that would just accidentally happen. 20180529 05:33:17<+discordbot3> One should assume such a change to be intentional. 20180529 05:33:55<+discordbot3> well, you don't need to implement sorting options. They already have the zero-width space hack. 😉 20180529 06:09:54< irker528> wesnoth/wesnoth:1.14 doofus-01 d0128ff7f0 slight revision to ant base sprite AppVeyor: All builds passed 20180529 06:12:14-!- gallaecio [~quassel@143.red-81-32-24.dynamicip.rima-tde.net] has joined #wesnoth-dev 20180529 06:59:05-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180529 07:53:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180529 08:18:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds] 20180529 08:50:46<+discordbot3> should we release a non-versioned hotfix to steam, steam and desktop, or 1.14.3? 20180529 08:51:10<+discordbot3> specifically to address the unit HP fix 20180529 08:51:42<+discordbot3> I'm strongly in favor of 1.14.3. 20180529 08:51:43< Soliton> what's the advantage of an unversioned hotfix? 20180529 08:52:12< Soliton> and why would you want to leave non-steam users without the fix? 20180529 09:06:50< zookeeper> and is it a critical enough problem that it warrants a fix ASAP in the first place? 20180529 09:07:38< Soliton> i think so. 20180529 09:07:51<+discordbot3> It breaks some UMC campaigns, as well as TRoW. 20180529 09:07:53< irker528> wesnoth/wesnoth:1.14 Charles Dang 0eb27e246b Fixed an occasional crash resulting from AppVeyor: All builds passed 20180529 09:11:18< zookeeper> all right 20180529 09:11:40< zookeeper> (AFAICT it breaks TRoW only in one specific path, the rarest one) 20180529 09:11:57<+discordbot3> An unversioned stream release is the simplest option for us since then we don’t need to go through the whole release process all over. 20180529 09:14:47<+discordbot3> How much effort would it even save in the end? 20180529 09:14:49< Soliton> simplest in what sense? in the sense that it's simple to figure anything out if players cannot tell you what version they're using? 20180529 09:15:05<+discordbot3> I think writing the release announcement is the biggest step you might be able to skip. 20180529 09:15:48<+discordbot3> And it's also a bit ironic to hear that from the guy who has said "we can do it if we all work hard"... 20180529 09:23:38<+discordbot3> That was about getting 1.16 out in a year 20180529 09:23:57<+discordbot3> Don’t take my words out of context 20180529 09:29:14< zookeeper> @Vultraz, i don't think you can be very pissed off about people assuming the faction sorting had no particular rationale, if in reality the rationale _was_ merely "i think it looks better/logical" :p 20180529 09:29:50< zookeeper> there's no other conceivable reason for it, after all. or at least none i can think of. 20180529 09:29:59<+discordbot3> You can binary search an alphabetically sorted list. 20180529 09:30:07<+discordbot3> I notice no one has complained that I also sorted the leader list. 20180529 09:30:17<+discordbot3> And the recruit list. 20180529 09:31:08-!- gfgtdf [~gfgtdf@134.76.63.8] has joined #wesnoth-dev 20180529 09:31:14-!- gfgtdf_ [~gfgtdf@134.76.63.8] has joined #wesnoth-dev 20180529 09:31:15< zookeeper> @jyrkive, uh, i don't get how that's relevant for a user-visible list. you mean like if you want to find where "undead" is on the list, you can look at the middle entry in the list and... well, no one would do that 20180529 09:31:52<+discordbot3> People also binary search unconsciously. 20180529 09:32:14<+discordbot3> If you're looking for undead, you don't read through every entry. 20180529 09:32:39-!- gfgtdf [~gfgtdf@134.76.63.8] has quit [Client Quit] 20180529 09:32:48-!- gfgtdf_ [~gfgtdf@134.76.63.8] has quit [Client Quit] 20180529 09:32:49< zookeeper> yeah, you see where it is at a glance 20180529 09:32:59-!- gfgtdf [~gfgtdf@134.76.63.8] has joined #wesnoth-dev 20180529 09:34:38< gfgtdf> some eras simply have 'special' factions that need to be placed above below the others, just like mainline has an exception for random factions. is not that case for recruitlists (yet) 20180529 09:37:42< gfgtdf> and i also dont rememebr anyone calling it a 'bug' but its a fact that it breaks those addons, that is that it no longer displayed in the order that makes the most sense. 20180529 09:39:29< zookeeper> i'd argue it's largely due to the race prefixes in unit names that recruit lists look okay with alphabetical sorting. for knalgans all dwarf units go first (only gryph is in the middle of outlaw units), for rebels all elf units go first and special units last, for drakes saurians go last, for undead lvl0's go last... 20180529 09:40:49< zookeeper> it'd probably be more awkward if no units had race prefixes and thus there wouldn't appear no be any grouping at all 20180529 09:40:57< gfgtdf> i ws talking about the faction list in my last post 20180529 09:42:03< gfgtdf> for the recruilist it could also be that it doesn't matter thther they are sorted or not since they are short enough to find your units innidiateley. 20180529 09:44:49-!- discordbot4 [~discordbo@baldras.wesnoth.org] has joined #wesnoth-dev 20180529 09:44:52-!- mode/#wesnoth-dev [+v discordbot4] by ChanServ 20180529 09:48:19< Ravana_> for faction it is important since first entry is selected by default 20180529 09:48:40-!- discordbot3 [~discordbo@baldras.wesnoth.org] has quit [Ping timeout: 256 seconds] 20180529 09:55:49< irker528> wesnoth: Charles Dang wesnoth:1.14 90fc8cf9b6da / changelog.md: Updated changelog https://github.com/wesnoth/wesnoth/commit/90fc8cf9b6da5e07873ec4d44dc9ff8a05c4e977 20180529 09:55:52< irker528> wesnoth: Charles Dang wesnoth:1.14 803d206cd218 / data/gui/window/campaign_difficulty.cfg src/gui/dialogs/campaign_difficulty.cpp: Campaign Difficulty: consolidated both lines into a single label https://github.com/wesnoth/wesnoth/commit/803d206cd2188613f5b44409205f81a7346f5390 20180529 10:01:30< irker528> wesnoth: Charles Dang wesnoth:master 61694688a8e6 / changelog.md: Updated changelog https://github.com/wesnoth/wesnoth/commit/61694688a8e6afc66a34e7347f52b92f2b7a3102 20180529 10:01:33< irker528> wesnoth: Charles Dang wesnoth:master f72f89f4d562 / data/gui/window/campaign_difficulty.cfg src/gui/dialogs/campaign_difficulty.cpp: Campaign Difficulty: consolidated both lines into a single label https://github.com/wesnoth/wesnoth/commit/f72f89f4d562231f831793b3719a115a79cc102c 20180529 10:01:36< irker528> wesnoth: Charles Dang wesnoth:master eddbaa21593d / src/events.cpp: Events: minor cleanup https://github.com/wesnoth/wesnoth/commit/eddbaa21593de3007e945a39f104c2a7d48bb284 20180529 10:13:35< irker528> wesnoth: Charles Dang wesnoth:master 4b03168fec89 / src/gui/dialogs/campaign_difficulty.cpp: Fixup f72f89f https://github.com/wesnoth/wesnoth/commit/4b03168fec89b9d4c29af77111a50ce6b0467538 20180529 10:14:21-!- travis-ci [~travis-ci@ec2-184-73-117-198.compute-1.amazonaws.com] has joined #wesnoth-dev 20180529 10:14:22< travis-ci> wesnoth/wesnoth#18414 (master - eddbaa2 : Charles Dang): The build was canceled. 20180529 10:14:22< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/385119259 20180529 10:14:22-!- travis-ci [~travis-ci@ec2-184-73-117-198.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180529 10:31:40-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Read error: Connection reset by peer] 20180529 10:32:40-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev 20180529 10:45:48-!- gfgtdf [~gfgtdf@134.76.63.8] has quit [Quit: Leaving] 20180529 10:56:52-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180529 11:15:37< irker528> wesnoth/wesnoth:master Charles Dang 6d0b7c8424 Fixed an occasional crash resulting from AppVeyor: All builds passed 20180529 11:28:24<+discordbot4> So if 1.14.2 has shipped, I guess that means my PRs #3103 and #3154 weren't included? 20180529 11:29:21<+discordbot4> Whoops, I mean #3104, as #3103 had a string change. 20180529 11:52:53-!- gfgtdf [~gfgtdf@134.76.63.8] has joined #wesnoth-dev 20180529 11:57:08-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180529 12:18:07-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has joined #wesnoth-dev 20180529 13:04:45-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180529 13:04:51-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180529 13:06:03-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20180529 13:15:09< irker528> wesnoth/wesnoth:master nemaara 6b13055c5b Replaced all gate-vision modifying event AppVeyor: All builds passed 20180529 13:17:41-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180529 13:52:35-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180529 13:52:41-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180529 14:42:18-!- fabi_ [~fabi@200116b82b9e32000dc03a2cbb04bf70.dip.versatel-1u1.de] has quit [Quit: Konversation terminated!] 20180529 14:51:10-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20180529 14:52:34-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev 20180529 14:59:49-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Quit: Konversation terminated!] 20180529 15:05:59-!- fabi [~fabi@200116b82b9e3200cd4d716353e265ad.dip.versatel-1u1.de] has joined #wesnoth-dev 20180529 15:05:59-!- fabi [~fabi@200116b82b9e3200cd4d716353e265ad.dip.versatel-1u1.de] has quit [Changing host] 20180529 15:05:59-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev 20180529 15:10:36-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Client Quit] 20180529 15:14:13-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180529 15:32:44-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev 20180529 15:47:41-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Quit: Konversation terminated!] 20180529 15:50:45-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev 20180529 16:01:12-!- gallaecio [~quassel@143.red-81-32-24.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 20180529 16:16:14-!- irker528 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20180529 16:24:24-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Quit: Konversation terminated!] 20180529 16:27:33-!- gallaecio [~quassel@188.79.96.255] has joined #wesnoth-dev 20180529 16:33:27-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev 20180529 16:38:11-!- irker880 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20180529 16:38:11< irker880> wesnoth/wesnoth:1.14 Charles Dang 803d206cd2 Campaign Difficulty: consolidated both l AppVeyor: All builds passed 20180529 16:51:05-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20180529 17:03:16-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev 20180529 17:15:12<+discordbot4> Indeed 20180529 17:25:28<+discordbot4> No worries. They're not high priority changes anyways, but is there something that I should do better in order to get changes included more smoothly? 20180529 17:40:34-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20180529 18:07:48-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection] 20180529 18:13:05< irker880> wesnoth/wesnoth:master Charles Dang 4b03168fec Fixup f72f89f AppVeyor: All builds passed 20180529 18:21:51-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20180529 18:36:44<+discordbot4> no, not really 20180529 18:43:54-!- gfgtdf_ [~gfgtdf@134.76.63.8] has joined #wesnoth-dev 20180529 18:44:38-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev 20180529 18:45:25-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20180529 18:46:31-!- heirecka_ [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev 20180529 18:48:26-!- ShikadiQueen [~iris@wesnoth/developer/shadowm] has joined #wesnoth-dev 20180529 18:53:00-!- Netsplit *.net <-> *.split quits: gfgtdf, heirecka, wedge009, shadowm, Ivanovic 20180529 18:53:00-!- heirecka_ is now known as heirecka 20180529 18:53:00-!- wedge010 is now known as wedge009 20180529 18:54:34-!- Ivanovic_ is now known as Ivanovic 20180529 19:02:06-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20180529 19:15:01-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20180529 19:22:35-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has quit [Ping timeout: 240 seconds] 20180529 19:23:42-!- gallaecio [~quassel@188.79.96.255] has quit [Remote host closed the connection] 20180529 19:26:46-!- gallaecio [~quassel@188.79.96.255] has joined #wesnoth-dev 20180529 19:44:14-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20180529 19:53:51-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20180529 20:24:37< irker880> wesnoth/wesnoth:master UnwiseOwl 77b76568db Change to objectives tag to meet mainlin AppVeyor: All builds passed 20180529 20:26:07< irker880> wesnoth: gfgtdf wesnoth:1.14 d36c6a928b0e / src/generators/default_map_generator_job.cpp: add mapgen debug info. https://github.com/wesnoth/wesnoth/commit/d36c6a928b0e8f3b9075812ef683a85eba21660b 20180529 21:04:49< Soliton> Vultraz: what's the idea with https://github.com/wesnoth/wesnoth/issues/3177 ? what do you hope will happen when taking agency away from content creators? everyone will agree that sorting is awesome and be happy with it or people will find more or less awful workarounds to get stuff to display how they want it? 20180529 21:10:44< Soliton> looks like the logical order of leaders is gone as well. 20180529 21:25:18<+discordbot4> celticminstrel, you around? 20180529 21:26:06<+discordbot4> Was going to respond to your q on my DW scenario PR, but thought I could do it here if it would be a better medium for discussion. 20180529 21:32:47-!- gallaecio [~quassel@188.79.96.255] has quit [Remote host closed the connection] 20180529 21:42:04< irker880> wesnoth: Nils Kneuper wesnoth:master 29c9f1d2983b / po/wesnoth-httt/fr.po: updated French translation https://github.com/wesnoth/wesnoth/commit/29c9f1d2983b280a946b1eb1781f6b93f8e9643c 20180529 21:42:11< irker880> wesnoth: Nils Kneuper wesnoth:1.14 1977a9ad793e / changelog.md players_changelog.md po/wesnoth-httt/fr.po: updated French translation https://github.com/wesnoth/wesnoth/commit/1977a9ad793e37ad0fac240b5d45a9c1bbcc9d2f 20180529 22:00:29-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 256 seconds] 20180529 22:34:28-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20180529 22:34:51-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20180529 22:34:56-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20180529 22:35:14-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit] 20180529 22:35:40-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20180529 22:35:40-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit] 20180529 22:45:00-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180529 22:45:06-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180529 22:51:53-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has joined #wesnoth-dev 20180529 22:56:53-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180529 22:56:59-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180529 23:03:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180529 23:11:44-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180529 23:11:50-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180529 23:26:46-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20180529 23:40:57-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] --- Log closed Wed May 30 00:00:14 2018