--- Log opened Sat Jun 11 00:00:14 2016
20160611 00:03:59< celticminstrel> So basically I guess I need to add a level of complexity to translation::dgettext...?
20160611 00:05:50-!- atarocch [~atarocch@151.64.65.55] has quit [Remote host closed the connection]
20160611 00:07:05-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160611 00:07:13< Aginor> hmm
20160611 00:07:18< Aginor> I think I've found my bug
20160611 00:07:20 * Aginor rejoices
20160611 00:11:21-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160611 00:26:09< celticminstrel> Or maybe I need to do something in translator::add_messages_domain...
20160611 00:28:02< celticminstrel> It looks like that's the function that actually loads in a mo file.
20160611 00:28:37< celticminstrel> Though the Boost.Locale documentation appears to be almost useless.
20160611 00:28:42< celticminstrel> So it's hard to say...
20160611 00:29:45< iceiceice> the idea in libintl and boost locale is that
20160611 00:29:56< iceiceice> the translations stuff is supposed to appear in the filesystem in a specific way
20160611 00:30:00< iceiceice> and you tell the lib the root
20160611 00:30:02< iceiceice> and add message domains
20160611 00:30:09< iceiceice> and it deduces the filepath from that, and loads the files itself
20160611 00:30:44< iceiceice> in spirit_po, the idea is that you make some `std::map<std::stirng, po_catalog>` data structure
20160611 00:30:58< iceiceice> and you do the filesystem stuff however you want
20160611 00:31:10< iceiceice> if you want to be able to emulate `dcgettext`
20160611 00:31:30< iceiceice> where `po_catalog` is the object from the lib
20160611 00:31:55< celticminstrel> I feel like it would be far easier to drop the mo-files than to use spirit-po alongside Boost.Locale...
20160611 00:32:26< celticminstrel> But Ivanovic said that the po->mo compilation process is helpful for locating errors... I suppose it's still possible to compile them but then discard the mo-files, though...
20160611 00:32:29< iceiceice> you might be right, you are the developer :)
20160611 00:32:39< iceiceice> yeah thats what i would suggest
20160611 00:32:50< iceiceice> leave the msgfmt in the build system to validate stuff
20160611 00:32:56< iceiceice> but you dont need to actually read the mo files
20160611 00:35:05< celticminstrel> If that's the case, then switching to spirit-po would also mean dropping Boost.Locale as a dependency, I suspect...
20160611 00:35:34< celticminstrel> s/would/could/
20160611 00:41:27< celticminstrel> Hmm. So ultimately all that's really needed is to implement the interface defined in gettext.hpp.
20160611 00:41:57< celticminstrel> How that's implemented isn't all that important, I guess.
20160611 00:43:41< celticminstrel> Why is egettext called in only one place?
20160611 00:43:46< celticminstrel> Line 62 of attack_type.cpp
20160611 00:44:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160611 00:45:40< iceiceice> i dont know what egettext is
20160611 00:48:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160611 00:55:32< Aginor> vultraz, gfgtdf: wesnoth segfaults if I ctrl+c during loading screen.
20160611 00:57:49< vultraz> cannot reproduce
20160611 01:02:15< gfgtdf> Aginor: what is crtl-c supposed to do ?
20160611 01:02:29< gfgtdf> Aginor: its not one of the hotkey i use often
20160611 01:03:15-!- gfgtdf [~chatzilla@x4e36330f.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160611 01:04:11< Aginor> gfgtdf: it sends a SIGTERM to a process. Issued in the console it was started from.
20160611 01:08:40-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20160611 01:09:06 * Aginor wonders if both gfgtdf and vultraz tried it
20160611 01:09:15-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160611 01:11:33< shadowm> Aginor: SIGINT.
20160611 01:11:48< Aginor> shadowm: I always confuse the two
20160611 01:11:54< shadowm> On POSIX systems, at least. I don't know what it does on Windows (which those two use), but it's certainly a thing.
20160611 01:12:05< Aginor> it is
20160611 01:12:17< Aginor> the game shouldn't segfault at the very least
20160611 01:12:38-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160611 01:15:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160611 01:33:28< shadowm> Certainly not, especially when the threaded loading screen was introduced precisely so cases like this would be handled instead of the game ignoring signals entirely for the duration of the load process.
20160611 01:37:46< Aginor> I thought it was heralded as the greatest speed improvement ever
20160611 01:37:49 * Aginor shrugs
20160611 01:38:20< Aginor> it has the net effect I wanted, the game stops
20160611 01:54:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160611 02:00:50< Aginor> vultraz, gfgtdf: the game crashes if resized during the loading screen.
20160611 02:02:47< celticminstrel> Ctrl+C didn't even work on OSX last time I tried.
20160611 02:03:01< Aginor> celticminstrel: at any time?
20160611 02:03:10< celticminstrel> I think so.
20160611 02:03:24< celticminstrel> I've only tried it while running the WML unit tests, I think.
20160611 02:11:43< vultraz> Aginor: I cannot reproduce that either
20160611 02:12:49< Aginor> vultraz: it's probably racy, try harder
20160611 02:13:33< celticminstrel> "racy"
20160611 02:13:48< celticminstrel> I know what you mean, but that's somehow a weird way of saying it.
20160611 02:13:54< Aginor> recey then :)
20160611 02:14:03< celticminstrel> That's... even weirder.
20160611 02:14:16< celticminstrel> Unless you meant "racey", in which case it's just as weird.
20160611 02:14:21< shadowm> More importantly they are homophones if you fix the typo.
20160611 02:14:42< celticminstrel> Yeah, the weirdness is in the sound, not the spelling.
20160611 02:14:52 * Aginor shrugs
20160611 02:15:02< shadowm> Unless you try pronouncing it in a broken French-like fashion like "raicé".
20160611 02:15:14< celticminstrel> Because it already has a meaning unrelated to threads.
20160611 02:15:17< celticminstrel> I think.
20160611 02:15:22< shadowm> https://en.wiktionary.org/wiki/racy
20160611 02:15:25< celticminstrel> Though I'm not quite sure what that meaning is.
20160611 02:15:39< Aginor> I've heard it used by several native english speakers in this context, so I think it's a thing
20160611 02:15:58< Aginor> unless it's been a part of some corporate engineering culture
20160611 02:15:59< vultraz> I don't know what you're trying to day
20160611 02:16:00< vultraz> say
20160611 02:16:13< celticminstrel> vultraz: He's saying it's a race condition.
20160611 02:16:16< Aginor> vultraz: the code is probably prone to race conditions, hence it is sometimes crashing
20160611 02:16:19< celticminstrel> Between threads.
20160611 02:18:14< Aginor> yes, although race conditions can occur in any parallell execution environment, it doesn't have to just be threads
20160611 02:18:22< Aginor> in this instance, it most likely is
20160611 02:21:15< vultraz> I believe there is still an issue with cache corruption and WML errors in the new loading screen, combined with a long-standing crash related to similar circumstances
20160611 02:22:16< Aginor> it sounds like the code has race conditions and need to be fixed
20160611 02:22:34< vultraz> (long-standing = predating the new LS)
20160611 02:22:43< Aginor> no.
20160611 02:23:00< vultraz> hm?
20160611 02:23:01< Aginor> it did not crash during these steps earlier
20160611 02:23:13< Aginor> I know because I spent a significant amount of time fixing it under SDL2
20160611 02:23:19< vultraz> oh, I'm referring to a different bug
20160611 02:23:21< vultraz> sorry
20160611 02:23:25< Aginor> so it was not segfaulting
20160611 02:23:32< Aginor> it should not segfault
20160611 02:23:38< Aginor> the segfaults needs to be fixed.
20160611 02:24:01< vultraz> I am still unable to reproduce your crash
20160611 02:24:42< vultraz> Maybe it's a linux vs windows things?
20160611 02:25:12< vultraz> thing*
20160611 02:25:35< Aginor> it's a race condition
20160611 02:25:53< Aginor> unless you happen to do it at the "right" time, you'll get the result you want
20160611 02:26:02< Aginor> which is not crashing
20160611 02:26:23< Aginor> but some small percentage of the time, you'll end up doing things at the wrong time and it crashes
20160611 02:26:44< Aginor> it will be hard to reproduce because it seems random
20160611 02:27:08< Aginor> while it is in fact determenistic, but there will be a multitude of factors at play
20160611 02:27:26< Aginor> the end result for the user is "it crashes randomly during startup, it's shit"
20160611 02:27:42< vultraz> I am afraid I cannot help you with race conditions
20160611 02:28:20-!- victorclf [~victorclf@187.181.129.74] has joined #wesnoth-dev
20160611 02:29:30< Aginor> ok, I have a stack trace for you when I ctrl+c during the loading screen
20160611 02:29:46< Aginor> and a core file, but you won't like it
20160611 02:31:18< vultraz> Oh?
20160611 02:31:43< Aginor> http://pastebin.com/ZNyGkDvp
20160611 02:31:52< Aginor> (the core file, that is)
20160611 02:33:06< vultraz> I'm not sure what you mean by 'core file'
20160611 02:33:13< vultraz> And I don't want to make an assumption here
20160611 02:33:32< Aginor> https://en.wikipedia.org/wiki/Core_dump
20160611 02:34:20< Aginor> q
20160611 02:35:16< iceiceice> wow
20160611 02:35:18< iceiceice> that's actually kind of awesome
20160611 02:35:20< iceiceice> "The Voyager craft uses routine core dumps to spot memory damage from cosmic ray events."
20160611 02:35:24-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160611 02:40:25 * Aginor sighs
20160611 02:40:33< Aginor> so much junk to clean up
20160611 02:40:44< Aginor> as in, I've made so much junk :)
20160611 02:40:54< Aginor> that needs to be tidied up before I can commit
20160611 02:41:16< Aginor> this really needs some optimisation too
20160611 02:41:26< Aginor> cpu usage is rather high :)
20160611 02:42:17< vultraz> That is a long stacktrace
20160611 02:43:02< celticminstrel> Another t_string crash...
20160611 02:44:08-!- ugudu [70865119@gateway/web/freenode/ip.112.134.81.25] has joined #wesnoth-dev
20160611 02:45:00-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160611 02:46:06< Aginor> (gdb) print id_to_textdomain
20160611 02:46:06< Aginor> $4 = std::vector of length 23, capacity 32 = { <error reading variable: Cannot access memory at address 0xffffffffffffffee>, <error reading variable: Cannot access memory at address 0xfffffffffffffff0>,  <error reading variable: Cannot access memory at address 0x7f19ffffffe8>,  <error reading variable: Cannot access memory at address 0xa9c37473755a>, 
20160611 02:46:11< Aginor>  "", <error rading variable: Cannot access memorys at address 0xd>, "ritos",  "", "", <error reading variable: Cannot access memory at address 0x1d>,  <error reading variable: Cannot access memory at address 0xffffffffffffffed>, <error reading variable: Cannot access memory at address 0xfffffffffffffff0>,  <error reading variable: Cannot access memory at address 0x7f19ffffffe8>, 
20160611 02:46:17< Aginor>  <error reading vaiable: Cannot access memory at address 0x747469685b>,  "",  <error reading variable: Cannot access memory at address 0xd>, "rusté", "",  "", <error reading variable: Cannot access memory at address 0x1d>,  <error reading variable: Cannot access memory at address 0xffffffffffffffe8>, <error reading variable: Cannot access memory at address 0xffffffffffffffe8>,  <error reading variable
20160611 02:46:23< Aginor> : Cannot access memory at address 0x7f1affffffe7>}
20160611 02:46:28< Aginor> I think it_to_textdomain doesn't contain filly initialised values
20160611 02:46:47< Aginor> tell me if you want me to dump any variables
20160611 03:08:20-!- ugudu [70865119@gateway/web/freenode/ip.112.134.81.25] has quit [Ping timeout: 250 seconds]
20160611 03:15:52-!- victorclf [~victorclf@187.181.129.74] has quit [Quit: Leaving]
20160611 03:19:53-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20160611 03:38:16< celticminstrel> What's "dsgettext" vs "dgettext" supposed to be...? :S
20160611 03:38:32< celticminstrel> t_string seems to use the former, but the latter is also used in at least one place.
20160611 03:39:08< celticminstrel> It looks like the "s" one implements the Wesnoth convention of starting translatable strings with a descriptive "prefix^" that gets ignored.
20160611 03:39:29 * celticminstrel actually didn't know that was a Wesnoth convention.
20160611 03:41:31< celticminstrel> I'm also not really sure whether I need to use a locale object here...
20160611 03:45:10< celticminstrel> Hmm. Apparently, the scons and CMake builds both have an option to use libintl instead of Boost.Locale.
20160611 03:45:18< celticminstrel> I wonder if anyone uses this option...
20160611 03:46:39< celticminstrel> Is there any point in keeping it?
20160611 03:47:43< Aginor> my inclination is "get rid of it"
20160611 03:48:07< Aginor> if it's not used and nobody knows about it, let's reduce complexity and support burden
20160611 03:48:18< Aginor> so let's find out if it's used :(
20160611 03:48:21< Aginor> :) even
20160611 03:49:11< celticminstrel> Excellent idea.
20160611 03:49:18< vultraz> I think it's a legacy remnant.
20160611 03:49:21< vultraz> Banish it
20160611 03:49:27 * celticminstrel banishes vultraz.
20160611 03:51:41< celticminstrel> If Boost.Locale isn't used for retrieving translations, then the only remaining use of the locale object is gfgtdf's new compare function.
20160611 03:55:21< celticminstrel> Maybe.
20160611 03:55:37< celticminstrel> I don't quite understand all the locale stuff going on here though, so I could be wrong... :S
20160611 03:55:54 * celticminstrel is looking at translation_manager in gettext_boost.cpp
20160611 03:57:44-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160611 04:01:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160611 04:05:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160611 04:11:13-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160611 04:17:35-!- ancestral [~ancestral@67-4-254-184.mpls.qwest.net] has joined #wesnoth-dev
20160611 04:25:47-!- iceiceice_osx [~chris@ext-74.ias.edu] has joined #wesnoth-dev
20160611 04:25:59< iceiceice_osx> gfgtdf: compiler error here: 
20160611 04:26:00< iceiceice_osx> http://pastebin.com/NeeCGUe5
20160611 04:34:05-!- ancestral [~ancestral@67-4-254-184.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160611 04:35:59< celticminstrel> Hmm, why is something using Boost.Bind? :S
20160611 04:36:14< iceiceice_osx> idk
20160611 04:36:16< iceiceice_osx> buggy ADL?
20160611 04:36:26< celticminstrel> ADL?
20160611 04:36:33< iceiceice_osx> ADL = argument dependent lookup
20160611 04:36:46< celticminstrel> Well, we always use std::bind.
20160611 04:36:59< iceiceice_osx> hmmm
20160611 04:37:13-!- ancestral [~ancestral@67-4-254-184.mpls.qwest.net] has joined #wesnoth-dev
20160611 04:37:47< iceiceice_osx> my repo is at this commit: 50e8fcda0895465f987a10a5b7e96fa95c6f4b47
20160611 04:38:04< celticminstrel> It's possible that some other Boost library is using Boost.Bind though.
20160611 04:38:18< celticminstrel> In fact I think that might've been why we had to support Boost placeholders...
20160611 04:39:01< celticminstrel> ...oh, right, functional.hpp includes bind.hpp to bring the placeholders into scope. Duh. >_>
20160611 04:43:01< iceiceice_osx> maybe should put like, "using namespace std::placeholders;" at the top of the function or something?
20160611 04:43:01< iceiceice_osx> or "using std::placeholders::_1;" etc.
20160611 04:44:13-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160611 04:44:42< celticminstrel> That wouldn't help with the placeholders issue, since the issue was that some files beyond our control include boost/bind.hpp
20160611 04:44:53< iceiceice_osx> well, it fixes compilation for me
20160611 04:44:57< ancestral> Ah, the bind inssue since yesterday
20160611 04:44:59< ancestral> *issue
20160611 04:45:03< celticminstrel> Which means "using namespace std::placeholders" would make _1 ambiguous in some cases.
20160611 04:45:19< celticminstrel> Where did you put that?
20160611 04:45:25< iceiceice_osx> when you make a using declaration within a scope, the inner one takes precedence
20160611 04:45:29< iceiceice_osx> there is no ambiguity in that case
20160611 04:53:44-!- RatArmy [~RatArmy@om126237116059.9.openmobile.ne.jp] has joined #wesnoth-dev
20160611 05:04:31< iceiceice_osx> celticminstrel, i can fix many files by adding local placeholders using declarations, but some of the gui2 code will be quite laborious to do this way
20160611 05:04:36< iceiceice_osx> so i'm giving up for now
20160611 05:04:52< celticminstrel> I think originally a global using namespace statement was attempted.
20160611 05:05:05< celticminstrel> Because like you say it can get quite laborious to put them in every function.
20160611 05:05:24< iceiceice_osx> its not that common to have functions with 7 parameters :p
20160611 05:05:27< iceiceice_osx> thats sort of unique to gui2
20160611 05:05:38< iceiceice_osx> probably should just bite the bullet and do it that way i guess
20160611 05:05:42< iceiceice_osx> idk
20160611 05:05:43< celticminstrel> I can't remember if someone attempted fully qualifying the placeholders, with or without a namespace alias...
20160611 05:05:53< iceiceice_osx> if you guys dont use boost::bind then the boost bind headers should'nt be included
20160611 05:06:09< iceiceice_osx> if you fully qualify the placeholders it works, but thats like 7 lines of code if there are _7
20160611 05:06:25< celticminstrel> Apparently some other Boost headers include the Boost bind headers.
20160611 05:06:33< iceiceice_osx> T_T
20160611 05:06:42< celticminstrel> So not including the boost bind headers turned out to be harder than it sounds.
20160611 05:07:47< iceiceice_osx> actually
20160611 05:07:49< iceiceice_osx> if you guys are c++11 now
20160611 05:07:57< iceiceice_osx> it should be feasible to eliinate boost headers from all of your headers
20160611 05:08:09< iceiceice_osx> so you only include it in certain compilation units
20160611 05:08:29< iceiceice_osx> that will make your compilation times much much better
20160611 05:08:34< celticminstrel> I was about to say that I don't think that's possible, but then I re-read it and noticed that you said "headers".
20160611 05:08:52< celticminstrel> Maybe I'll look into that a bit later...
20160611 05:08:57< iceiceice_osx> gl
20160611 05:20:11-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has joined #wesnoth-dev
20160611 05:24:52-!- Kwandulin [~Miranda@p200300760F3B06DD105E8E6234BD0DD8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160611 05:24:53< celticminstrel> It's a little inconvenient that catalog is not default-constructible.
20160611 05:25:01< celticminstrel> Easy to work around though, I guess.
20160611 05:25:12< celticminstrel> Just use insert and at instead of operator[]
20160611 05:29:10< celticminstrel> Well, spirit-po-based localization compiles now. I'm pretty sure it won't actually work like this though.
20160611 05:29:30< celticminstrel> For starters, I have to figure out where to put the po-files.
20160611 05:45:54-!- oldlaptop [~quassel@50-107-125-80.adr02.mskg.mi.frontiernet.net] has quit [Quit: No Ping reply in 180 seconds.]
20160611 05:49:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160611 05:54:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160611 06:04:46-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160611 06:13:34-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 250 seconds]
20160611 06:19:47-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160611 06:20:33-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 240 seconds]
20160611 06:26:20-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160611 06:26:38-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20160611 06:32:15-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 264 seconds]
20160611 06:43:35-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160611 06:45:16-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160611 06:45:32-!- Ivanovic_ [~ivanovic@p579FBE4D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160611 06:45:32-!- Ivanovic_ [~ivanovic@p579FBE4D.dip0.t-ipconnect.de] has quit [Changing host]
20160611 06:45:32-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20160611 06:46:02-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160611 06:46:17-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160611 06:47:42-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 276 seconds]
20160611 06:49:26-!- Ivanovic_ is now known as Ivanovic
20160611 07:06:58-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 252 seconds]
20160611 07:08:04-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has quit [Ping timeout: 272 seconds]
20160611 07:09:42-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160611 07:10:48-!- ancestral [~ancestral@67-4-254-184.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160611 07:22:48-!- RatArmy [~RatArmy@om126237116059.9.openmobile.ne.jp] has quit [Ping timeout: 276 seconds]
20160611 07:23:27-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 276 seconds]
20160611 07:26:19-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160611 07:38:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160611 07:40:28-!- iceiceice_osx [~chris@ext-74.ias.edu] has quit [Quit: Leaving]
20160611 07:42:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160611 07:49:36-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has joined #wesnoth-dev
20160611 07:57:15-!- Appleman1234 [~Appleman1@KD036012038024.au-net.ne.jp] has quit [Ping timeout: 276 seconds]
20160611 08:05:39-!- RatArmy [~RatArmy@om126204192158.6.openmobile.ne.jp] has joined #wesnoth-dev
20160611 08:14:33-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160611 08:22:59-!- Appleman1234 [~Appleman1@KD036012041021.au-net.ne.jp] has joined #wesnoth-dev
20160611 08:39:40-!- mjs-de [~mjs-de@x5ce33015.dyn.telefonica.de] has joined #wesnoth-dev
20160611 08:47:01-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160611 08:53:10-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160611 08:53:16-!- janebot_ [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160611 08:53:16-!- janebot_ is now known as janebot
20160611 08:55:27-!- Kwandulin [~Miranda@p200300760F3B06DD105E8E6234BD0DD8.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160611 09:10:45-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160611 09:11:15-!- RatArmy [~RatArmy@om126204192158.6.openmobile.ne.jp] has quit [Ping timeout: 244 seconds]
20160611 09:26:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160611 09:30:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160611 09:32:50-!- Kwandulin [~Miranda@p200300760F3B06DD2D64FE5CD2A92F81.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160611 09:42:37-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 252 seconds]
20160611 09:43:05-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160611 10:02:03-!- prkc [~prkc@192.40.89.14] has quit [Ping timeout: 276 seconds]
20160611 10:04:02-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160611 10:11:14-!- edgrey [~edgrey@178.205.46.126] has joined #wesnoth-dev
20160611 10:51:02-!- gfgtdf [~chatzilla@x4e368a98.dyn.telefonica.de] has joined #wesnoth-dev
20160611 11:06:50< gfgtdf> iceiceice: the given fil in your report is "boost/bind/arg.hpp" (boost::arg) which is used by boost placeholders so its likeley that it doesn use boost bind .
20160611 11:07:24< gfgtdf> iceiceice: whats suprisong me is, that is givin that error in line 82 even tough teh 10 lines before use bind aswell
20160611 11:08:19< gfgtdf> iceiceice: in case that we don't know the fix, i sugest to just use labdas in the particular line (82).
20160611 11:10:15< gfgtdf> Aginor: when i press 'crtl-c ' from titltescreen nothing, happens, which is what i'd exepct (on windows)
20160611 11:14:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160611 11:19:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160611 11:23:07-!- RatArmy [~RatArmy@om126204192158.6.openmobile.ne.jp] has joined #wesnoth-dev
20160611 11:25:51-!- oldlaptop [~quassel@172.79.57.34] has joined #wesnoth-dev
20160611 11:29:01-!- Bonobo [~Bonobo@2001:44b8:254:3200:99f1:140d:bd8:1486] has joined #wesnoth-dev
20160611 11:34:13-!- gfgtdf [~chatzilla@x4e368a98.dyn.telefonica.de] has quit [Ping timeout: 250 seconds]
20160611 11:50:23-!- gfgtdf [~chatzilla@x4e368a98.dyn.telefonica.de] has joined #wesnoth-dev
20160611 11:57:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160611 12:30:59-!- gfgtdf [~chatzilla@x4e368a98.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160611 12:46:08-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160611 12:51:37-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160611 12:58:44-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has quit [Quit: Konversation terminated!]
20160611 12:59:20-!- Coffee_irc [~david@ppp121-45-55-182.lns20.adl2.internode.on.net] has joined #wesnoth-dev
20160611 13:14:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160611 13:17:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160611 13:18:45-!- ancestral [~ancestral@67-4-254-184.mpls.qwest.net] has joined #wesnoth-dev
20160611 13:18:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160611 13:24:49-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160611 13:31:29-!- prkc [~prkc@192.40.89.17] has joined #wesnoth-dev
20160611 13:32:07-!- atarocch [~atarocch@151.64.65.55] has joined #wesnoth-dev
20160611 13:34:03-!- RatArmy [~RatArmy@om126204192158.6.openmobile.ne.jp] has quit [Ping timeout: 264 seconds]
20160611 13:52:33< shadowm> gfgtdf: Press Ctrl+C *on the console window* when on the loadscreen (not titlescreen) while launching a Wesnoth either built as a console application, or using --wconsole / the cwesnoth.cmd wrapper.
20160611 13:54:33-!- oldlaptop [~quassel@172.79.57.34] has quit [Ping timeout: 244 seconds]
20160611 13:59:10-!- Coffee_irc [~david@ppp121-45-55-182.lns20.adl2.internode.on.net] has quit [Quit: Konversation terminated!]
20160611 14:00:23-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has joined #wesnoth-dev
20160611 14:02:16< vultraz> Ok, Now I can reproduce 
20160611 14:09:19< shadowm> Went to make coffee and then wasn't sure if it'd work with cmd.exe and --wconsole since it's been too long.
20160611 14:09:37< shadowm> Although failing everything it should at least work with Mingw + bash.
20160611 14:10:21-!- gfgtdf [~chatzilla@x4e368a98.dyn.telefonica.de] has joined #wesnoth-dev
20160611 14:10:32< shadowm> Say goodbye to wiki.wesnoth.org, forums.wesnoth.org, and the MP authentication platform.
20160611 14:13:05< gfgtdf> vultraz: we can rmeove thread.hpp frm the main executable too since its only used by the network code afaik
20160611 14:13:29< gfgtdf> vultraz: although, some files might still include it though which neds to bre fixed first
20160611 14:13:38< vultraz> I'll see
20160611 14:17:34< vultraz> gfgtdf: seems it's still used in game_launcher.hpp
20160611 14:17:57< vultraz> const threading::manager thread_manager;
20160611 14:18:46< vultraz> I think I can remove that
20160611 14:18:53< vultraz> since it doesn't seem to be used anywhere
20160611 14:19:39< shadowm> ... That might be too adventurous an assumption to make for you.
20160611 14:20:05< shadowm> Manager objects are often used to take advantage of RAII with their mere existence.
20160611 14:20:30< vultraz> Builds without it, waiting to see what gfgtdf says.
20160611 14:20:38< shadowm> Instead of verifying whether they are directly referenced you should be paying attention to their side-effects (esp. their ctor and dtor's).
20160611 14:21:13< shadowm> They might be setting state that's needed by other objects. This means that the compiler won't necessarily catch any issues that may arise from their removal.
20160611 14:21:22-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160611 14:22:04< vultraz> doesn't look like it
20160611 14:22:41< shadowm> Probably depends on whether there's any client-side code remaining using SDL_net, now that I think about it.
20160611 14:22:55< shadowm> I think that was our only previous use of the SDL threads API.
20160611 14:23:01< vultraz> I'm building without SDL_net, so I'd say no.
20160611 14:23:22< celticminstrel> I think only the addons server still uses it?
20160611 14:23:23< shadowm> I don't know if the Asio code uses threads and which flavor of threads it uses.
20160611 14:23:36< celticminstrel> Oh, wait, we're talking about SDL threads here, I suppose.
20160611 14:23:36< shadowm> Yes, campaignd still needs SDL_net but that's only server-side.
20160611 14:23:46-!- Kwandulin [~Miranda@p200300760F3B06DD2D64FE5CD2A92F81.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160611 14:28:50< vultraz> celticminstrel: can you go through and clean up code related to _MSC_VER < 1800?
20160611 14:29:53-!- ancestral [~ancestral@67-4-254-184.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160611 14:30:35< celticminstrel> I suppose I could manage that...
20160611 14:30:44< vultraz> or do you want me to do it
20160611 14:30:56< celticminstrel> Um.
20160611 14:31:19< celticminstrel> I'll give it a try once I've got spirit-po working?
20160611 14:32:13< vultraz> probably best, since there are a lot
20160611 14:32:43< celticminstrel> Does anyone know what the various LINGUAS files are for?
20160611 14:33:32< vultraz> the what?
20160611 14:33:45< celticminstrel> eg po/LINGUAS, po/wesnoth/LINGUAS
20160611 14:33:45< vultraz> oh
20160611 14:33:47< vultraz> no idea
20160611 14:33:55< vultraz> maybe a list of available languages
20160611 14:34:22< celticminstrel> Well yes, that's what they contain.
20160611 14:36:46-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160611 14:50:25-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160611 14:50:26-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160611 14:54:13< gfgtdf> vultraz: asio ntowrk currently doesnt use threads, but it it woudl i'd mostlikeley use boost::thread or std::thread
20160611 14:54:27< gfgtdf> vultraz:  i think rmeoving the thread_manager form game launcher is fine
20160611 14:55:39< gfgtdf> vultraz: from llooking at the manager code it seems liek its onyöl purpose was to wait for running threads when the application is closed
20160611 14:55:56< gfgtdf> vultraz: for runng sdl threads that is
20160611 14:56:10< gfgtdf> vultraz: since the client doesnt use sdl clients anymore we can rmeove it
20160611 14:58:09-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160611 15:00:09-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has quit [Quit: Konversation terminated!]
20160611 15:00:49-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has joined #wesnoth-dev
20160611 15:11:59-!- mjs-de [~mjs-de@x5ce33015.dyn.telefonica.de] has quit [Remote host closed the connection]
20160611 15:12:36-!- daMark [5439bff6@gateway/web/freenode/ip.84.57.191.246] has joined #wesnoth-dev
20160611 15:13:14-!- Appleman1234 [~Appleman1@KD036012041021.au-net.ne.jp] has quit [Ping timeout: 258 seconds]
20160611 15:15:27-!- daMark [5439bff6@gateway/web/freenode/ip.84.57.191.246] has left #wesnoth-dev []
20160611 15:24:44-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has quit [Quit: Konversation terminated!]
20160611 15:24:57-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has joined #wesnoth-dev
20160611 15:39:48-!- Kwandulin [~Miranda@p200300760F3B06DDE4D21D0AFAA7FE8E.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160611 15:48:23-!- horrowind [~Icedove@2a02:810a:83c0:1c18:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160611 15:49:20< celticminstrel> Why are the constructor initialization lists filled with default constructors.
20160611 15:49:38< celticminstrel> That should only be needed for basic numeric types, otherwise it's totally redundant.
20160611 15:49:55< celticminstrel> (Well, pointer types too I guess.)
20160611 16:00:52-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has quit [Quit: Konversation terminated!]
20160611 16:01:15-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160611 16:01:43-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has joined #wesnoth-dev
20160611 16:05:03< celticminstrel> So, initial translation setup is run with the default C locale active... meaning I can't load the catalogs at that time...
20160611 16:23:32-!- ancestral [~ancestral@67-4-254-184.mpls.qwest.net] has joined #wesnoth-dev
20160611 16:25:53-!- horrowind [~Icedove@2a02:810a:83c0:1c18:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160611 16:25:56-!- ancestral [~ancestral@67-4-254-184.mpls.qwest.net] has quit [Client Quit]
20160611 16:28:11< celticminstrel> I guess English is represented by the empty string...
20160611 16:33:42-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160611 16:35:15-!- Kwandulin [~Miranda@p200300760F3B06DDE4D21D0AFAA7FE8E.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]
20160611 16:39:41< celticminstrel> There seems to be a disconnect between the filenames and the language codes.
20160611 16:39:52< celticminstrel> eg, language code is fr_FR but filename is fr.po.
20160611 16:40:34< celticminstrel> (Also slightly surprising that there's no fr_CA.)
20160611 16:40:51< shadowm> Does there need to be?
20160611 16:40:58< celticminstrel> (But that's entirely beside the point.)
20160611 16:41:17< shadowm> i.e. are there any tangible differences between that and vanilla French?
20160611 16:41:30< celticminstrel> There's a lot of differences.
20160611 16:41:38< shadowm> But more importantly, translations only exist as they are requested by translators.
20160611 16:41:57< AI0867> loonycyborg: commits?
20160611 16:42:11< celticminstrel> Though, I'm not sure how many of them would show up in a medieval-based setting - many of the differences are with respect to modern words (Parisian French tends to borrow, while Quebecois French tends to coin new words).
20160611 16:43:34< loonycyborg> AI0867: dce503ebec2c9d9c1ce574729b9321538ea8bb78 and  d3ed75d58a4bdea747041a32223e4d8f91c95e6e
20160611 16:43:45< celticminstrel> Anyway, it seems like the only option is to try the fr_FR name first and, if not found, try fr.
20160611 16:44:29< celticminstrel> The ".UTF-8" portion of the locale name is irritating, too... I suppose Boost's generator thing needs it though...
20160611 16:46:59-!- Kwandulin [~Miranda@p200300760F3B06DD18EFB01FC4F4EBBB.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160611 16:49:40-!- Bonobo [~Bonobo@2001:44b8:254:3200:99f1:140d:bd8:1486] has quit [Ping timeout: 250 seconds]
20160611 16:52:11< AI0867> loonycyborg: possibly, but I don't know
20160611 16:53:18< AI0867> loonycyborg: actually, for the second I'd say probably
20160611 16:54:15-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20160611 17:33:01-!- prkc [~prkc@192.40.89.17] has quit [Ping timeout: 240 seconds]
20160611 17:33:58-!- prkc [~prkc@192.40.89.17] has joined #wesnoth-dev
20160611 17:38:35-!- trewe [~trewe@bl20-30-79.dsl.telepac.pt] has joined #wesnoth-dev
20160611 17:38:51-!- prkc [~prkc@192.40.89.17] has quit [Ping timeout: 264 seconds]
20160611 17:45:24-!- prkc [~prkc@192.40.89.11] has joined #wesnoth-dev
20160611 17:57:24< shadowm> Who wrote gettext.wesnoth.org?
20160611 17:57:45< shadowm> Tell me ASAP so I can hit them in the face with the non-squeaky mallet.
20160611 17:58:48< shadowm> And if you know of any other PHP scripts relying on the PHP short_open_tag option do make sure to tell me ASAP as well.
20160611 18:00:00< shadowm> Blargh can't be bothered to deal with this horrid piece of crap right now, I'll just reenable that option.
20160611 18:00:59< celticminstrel> ...heh.
20160611 18:01:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160611 18:03:07-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160611 18:03:16-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160611 18:11:16-!- irker846 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160611 18:11:16< irker846> wesnoth: Charles Dang wesnoth:master fbc5d46b3834 / src/ (dialogs.cpp game_launcher.cpp game_launcher.hpp): Cleaned up some unused thread.hpp stuff in the main binary files https://github.com/wesnoth/wesnoth/commit/fbc5d46b3834935fed13a2d2bfcefdbf90e1558d
20160611 18:11:17< irker846> wesnoth: Charles Dang wesnoth:master 709b078a7aa8 / projectfiles/CodeBlocks/wesnoth.cbp: CB: removed thread.*pp from main binary https://github.com/wesnoth/wesnoth/commit/709b078a7aa823d7f96c81c7a8e600e1b68a4df5
20160611 18:11:59-!- Kwandulin [~Miranda@p200300760F3B06DD18EFB01FC4F4EBBB.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160611 18:13:35< celticminstrel> "main binary files"
20160611 18:13:46< vultraz> Excuse me it's 5 am
20160611 18:13:59< celticminstrel> ...wait, really?
20160611 18:13:59< vultraz> I just woke up
20160611 18:14:13< celticminstrel> Oh. You're up early, eh?
20160611 18:14:54< vultraz> Yeah, been sleeping intermittently the last day.
20160611 18:15:02< vultraz> Trying to get back on a good sleeping schedule
20160611 18:18:07< vultraz> Plus I've been feeling horrible since I heard the news that Christina Grimmie was shot and killed at her own concert :/ T'is sad.
20160611 18:21:31< celticminstrel> I have no idea who that is, but I suppose people being shot is never a good thing. Unless they're Donald Trump or Hitler or something, maybe.
20160611 18:22:10< vultraz> 22 year old former Voice finalist and youtube star.
20160611 18:23:06< celticminstrel> That doesn't really tell me anything at all.
20160611 18:23:49< vultraz> Google is your friend here
20160611 18:23:56< celticminstrel> That would imply I care.
20160611 18:25:19< vultraz> *raises eyebrow* I know what you're saying, but you could word that better.
20160611 18:25:54< shadowm> Agreed.
20160611 18:26:46< zookeeper> shadowm, you have a non-squeaky mallet too? :o that would certainly come in handy sometimes.
20160611 18:27:18< shadowm> It's reserved for very extreme situations.
20160611 18:27:52< shadowm> Like this one where a script dumped itself to the client side because it made assumptions about its operating environment.
20160611 18:28:17< zookeeper> good to know
20160611 18:41:20< gfgtdf> shadowm: how long will it be still down ?
20160611 18:41:34< shadowm> As long as necessary.
20160611 18:41:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160611 18:48:55-!- travis-ci [~travis-ci@ec2-54-196-222-175.compute-1.amazonaws.com] has joined #wesnoth-dev
20160611 18:48:56< travis-ci> wesnoth/wesnoth#9610 (master - 709b078 : Charles Dang): The build has errored.
20160611 18:48:56< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/136953482
20160611 18:48:56-!- travis-ci [~travis-ci@ec2-54-196-222-175.compute-1.amazonaws.com] has left #wesnoth-dev []
20160611 18:49:04< celticminstrel> Po-files appear to be saved under po/textdomain/langcode.po.
20160611 18:49:19< celticminstrel> Mo-files appear to be saved under translations/LC_MESSAGES/langcode/textdomain.mo.
20160611 18:49:50< celticminstrel> Is there any advantage in switching the language code and textdomain order in the path?
20160611 18:50:16< celticminstrel> Or is that just some arbitrary decision that someone made?
20160611 18:51:22< zookeeper> ...potato?
20160611 18:58:33-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has joined #wesnoth-dev
20160611 18:58:40< celticminstrel> Unrelatedly, I've noticed that there's a convention for UMC textdomains to begin with "wesnoth-", but if you think about it, is there any reason why they need to do so?
20160611 18:58:58< shadowm> Because Wesnoth does that too.
20160611 18:59:06< celticminstrel> It might even be better if they don't (unless there's some reason I don't know about).
20160611 18:59:18< celticminstrel> Because then there's no chance of conflicting with the ones Wesnoth uses.
20160611 18:59:29< shadowm> With gettext I think applications are expected to identify themselves in catalogue names.
20160611 18:59:49< celticminstrel> Hmm.
20160611 18:59:53< loonycyborg> celticminstrel: .mo files have totally different path structure than .mo files
20160611 19:00:00< loonycyborg> (.po files
20160611 19:00:16< celticminstrel> loonycyborg: I know, and my question is, why?
20160611 19:00:16< shadowm> I really don't see why we should change this and UMC generally doesn't conflict "because".
20160611 19:00:45< shadowm> The only issue is that UMC people will imitate whatever mainline does and do it incorrectly, such as the acronym textdomains thing.
20160611 19:00:50< loonycyborg> it's more convenient from perspective of appropriate tools
20160611 19:01:06< loonycyborg> .po files and .mo files have same relation as binaries and sources
20160611 19:01:06< shadowm> Blargh can't be bothered to write a more coherent explanation right now. Maybe ask AI0867 if he's still around.
20160611 19:01:43< celticminstrel> loonycyborg: So if mo-files are being dropped, would it be better to keep the po-file structure when copying them over, or mimick the mo-file structure?
20160611 19:02:19< loonycyborg> from perspective of translator tools textdomains are more prominent, so directory structure is based on them
20160611 19:02:42< loonycyborg> from perspective of the app and libintl api langs are more important
20160611 19:02:45< shadowm> Has anyone made sure the new code will not die horribly if you feed it an invalid or unreadable (i.e. nonexistent) po file, by the way?
20160611 19:02:57< loonycyborg> so message catalogs are oranized by langcode
20160611 19:03:15< celticminstrel> If you mean what I'm working on, shadowm, then I have accounted for that.
20160611 19:03:31< celticminstrel> It's necessary to have done so, because there are no po-files for en_US after all.
20160611 19:03:31< shadowm> I assume you are working on integrating that thing iceiceice wrote.
20160611 19:03:38< celticminstrel> Yes.
20160611 19:03:43< shadowm> Otherwise I don't know what you are working on.
20160611 19:03:55< loonycyborg> celticminstrel: what do you mean "mo files being dropped"?
20160611 19:04:07 * shadowm blinks.
20160611 19:04:11< celticminstrel> It throws an exception if the po file is invalid.
20160611 19:04:28< celticminstrel> loonycyborg: I thought that was self-explanatory...
20160611 19:04:59< loonycyborg> I lack the context to understand it
20160611 19:05:16< celticminstrel> iceiceice wrote a tool that loads strings from po files rather than from mo files.
20160611 19:05:28< celticminstrel> This is advantageous for UMC, since mo files are apparently not portable.
20160611 19:06:00< celticminstrel> Dropping mo files altogether seems to be easier than attempting to write a hybrid system that uses mo for built-in stuff and po for UMC.
20160611 19:06:23< celticminstrel> Once I have a commit, I'll push so you can see what I'm doing.
20160611 19:06:47< shadowm> I really don't know what the advantage for UMC is supposed to be beyond making life easier for content creators.
20160611 19:07:03< loonycyborg> ok then, I think you should keep po/ dir structure as it is for now
20160611 19:07:05< shadowm> Who don't have to figure out how to compile .po files they receive from translators.
20160611 19:07:22< shadowm> The elephant in the room here is where those files are supposed to come from in the first place.
20160611 19:07:27< loonycyborg> unless it makes things inconvient for the extraction tool
20160611 19:08:00< celticminstrel> Well, I was under the impression that mo files are platform-dependent, which implies that, even if they did manage to compile the po files, the result wouldn't work everywhere.
20160611 19:08:27< shadowm> Are they now?
20160611 19:09:18< shadowm> The wiki page doesn't really go into enough detail on the matter and only mentions endianness.
20160611 19:09:40< shadowm> Which kind of stopped being a concern for us since all T1 platforms are x86/x86_64 and therefore have the same endianness.
20160611 19:09:51< celticminstrel> Hmm, well, endianness isn't a problem for Windows vs Mac, at least.
20160611 19:09:59< shadowm> Yes that's what I just said.
20160611 19:10:01< celticminstrel> It could be a problem for some Linux platforms.
20160611 19:10:15< shadowm> No.
20160611 19:10:27< shadowm> Tier 1: OS X x86/x86_64, Windows x86/x86_64, Linux x86/x86_64.
20160611 19:10:27< celticminstrel> I imagine that would be uncommon though.
20160611 19:10:53< shadowm> I don't/didn't/don't (depending on which branch you ask me to Release Manage) consider other architectures tier 1.
20160611 19:11:10 * celticminstrel shrugs.
20160611 19:11:44< celticminstrel> Content creators could even create those po files themselves if they happen to be bilingual, you know.
20160611 19:12:04< shadowm> That's not what I was talking about
20160611 19:12:18 * celticminstrel referring back to your elephant.
20160611 19:12:21< shadowm> Creating the .po files in the first place requires using one of those things that Windows and OS X users are allergic to.
20160611 19:12:29< shadowm> A scary "command line" tool.
20160611 19:12:38< celticminstrel> That's the pot files, isn't it?
20160611 19:12:47< shadowm> Well yes, the .pot file.
20160611 19:12:59< shadowm> From which .po files originate. I thought that was obvious enough it needn't be stated explicitly.
20160611 19:13:00-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160611 19:13:14< shadowm> Anyway anyone feeling like breaking the website? I ran out of ideas myself.
20160611 19:13:16< celticminstrel> Elvish_Hunter could probably add wmlxgettext to the tools GUI now that it's Python.
20160611 19:13:18< iceiceice> shadowm, what about phones?
20160611 19:13:24< iceiceice> ios and android are not tier1 ?
20160611 19:13:29< shadowm> iceiceice: Yeah they aren't.
20160611 19:13:36< iceiceice> thats pretty dumb
20160611 19:13:41< shadowm> iOS has always been a shoddy 3rd-party port.
20160611 19:13:51< shadowm> Android is a non-shoddy but still 3rd-party port.
20160611 19:13:56< iceiceice> its also apparently where all of the revenue for mainline comes from
20160611 19:14:33< shadowm> <shadowm> Anyway anyone feeling like breaking the website? I ran out of ideas myself.
20160611 19:14:46 * iceiceice disappears in puff of smoke
20160611 19:14:47< shadowm> I had to rewrite some crucial configuration parts so I'd appreciate input.
20160611 19:14:49-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Client Quit]
20160611 19:14:50< celticminstrel> Breaking the website sounds fun.
20160611 19:15:06< celticminstrel> But I don't really know what you want. Randomly going to pages?
20160611 19:15:25< shadowm> Well, that and potentially dangerous misconfigured locations.
20160611 19:16:59< celticminstrel> Was addons.wesnoth.org supposed to be a standard directory listing?
20160611 19:17:01< shadowm> iceiceice: I mean seriously, you were (are) a developer so you are perfectly aware of the fact that the mainline codebase doesn't really acknowledge the existence of those ports in any fashion right now. Feel free to change that if you want, but it's not my business -- especially now that I'm only taking care of 1.12.
20160611 19:17:07< shadowm> celticminstrel: Yes.
20160611 19:17:39< celticminstrel> I assume replays.wesnoth.org is as well.
20160611 19:17:44< shadowm> Yes.
20160611 19:18:53< celticminstrel> I tried all the subdomains I can think of.
20160611 19:19:12< celticminstrel> status.wesnoth.org is useful since it links to several of them.
20160611 19:19:39< shadowm> Yeah but not all.
20160611 19:19:46< celticminstrel> Yeah.
20160611 19:20:04< celticminstrel> Huh, the links in the website header go to wesnoth.org/wiki instead of wiki.wesnoth.org.
20160611 19:20:17 * shadowm *eye twitch*
20160611 19:20:20< shadowm> Where?
20160611 19:20:49< celticminstrel> It was on units.wesnoth.org that I noticed it.
20160611 19:20:58< shadowm> Effing units.wesnoth.org.
20160611 19:21:10< shadowm> Wait, units.wesnoth.org doesn't have "links", plural.
20160611 19:21:27< shadowm> Oh, the units.wesnoth.org front page of sorts.
20160611 19:21:30< celticminstrel> It's the site header with the logo and navigation links.
20160611 19:21:38< shadowm> It's also obviously not been touched since 2012.
20160611 19:21:44< shadowm> What a piece of crap.
20160611 19:22:11< celticminstrel> Lookst the same as the front page, but the URLs are a bit different.
20160611 19:22:15< celticminstrel> ^Looks
20160611 19:22:23-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160611 19:22:30< shadowm> Is it unversioned? I'm unsure.
20160611 19:22:41< Elvish_Hunter> shadowm: trying to load today's IRC log in Firefox opens the open file/download dialog.
20160611 19:22:49< celticminstrel> No idea.
20160611 19:23:08< celticminstrel> The IRC log is likely somehow my fault. :/
20160611 19:23:10< shadowm> Elvish_Hunter: Blame Firefox and whoever it is that vomited control characters.
20160611 19:23:15< celticminstrel> Though, could be someone else.
20160611 19:23:16< shadowm> It may have been me as well.
20160611 19:24:09< shadowm> The moment Firefox sees a control character other than CR or LF or HT (and possibly others and probably only for the first n bytes) it decides to not honor the server's specified content type.
20160611 19:24:49< shadowm> That probably actually makes sense for one specific case, actually.
20160611 19:25:16-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 250 seconds]
20160611 19:25:17-!- wedge010 is now known as wedge009
20160611 19:25:23< shadowm> Those stupid software bundles that start with a plain-text script followed by a massive binary blob at the end.
20160611 19:25:54< shadowm> And also to alleviate user woes resulting from incompetent website admins.
20160611 19:25:57< Elvish_Hunter> Interesting. I checked in Firefox's web console, and it looks like no content type was sent in the header :/
20160611 19:26:08< shadowm> You are probably looking at the cached response.
20160611 19:26:40< shadowm> Oh okay, never mind, yes.
20160611 19:26:53< shadowm> It's a server-side misconfiguration, so call me incompetent.
20160611 19:27:15< celticminstrel> Don't feel like it.
20160611 19:31:36< Elvish_Hunter> celticminstrel: about the GUI for wmlxgettext, that was the idea.
20160611 19:32:42< shadowm> asdf.
20160611 19:33:07< Elvish_Hunter> shadowm: no, I won't call you incompetent :)
20160611 19:36:35< shadowm> There you should have it back if you force reload.
20160611 19:37:16< shadowm> As long as the file you choose isn't infected with extraneous control characters.
20160611 19:38:17< Elvish_Hunter> OK, now it works. Thanks!
20160611 19:39:34< shadowm> OK I'm reenabling the forums.
20160611 19:48:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160611 19:49:13< shadowm> My head hurts.
20160611 19:49:17< shadowm> I don't want to do this ever again.
20160611 19:51:34-!- edgrey [~edgrey@178.205.46.126] has quit [Ping timeout: 244 seconds]
20160611 20:26:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160611 20:27:17-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160611 20:27:32-!- edgrey [~edgrey@178.205.46.126] has joined #wesnoth-dev
20160611 20:43:53-!- lipkab [~the_new_l@host-91-147-210-58.biatv.hu] has quit [Quit: Leaving]
20160611 20:51:27-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160611 20:52:41-!- edgrey [~edgrey@178.205.46.126] has quit [Ping timeout: 240 seconds]
20160611 20:54:23-!- RatArmy [~RatArmy@om126204192158.6.openmobile.ne.jp] has joined #wesnoth-dev
20160611 21:00:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20160611 21:03:12-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160611 21:11:46-!- irker846 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160611 21:14:02-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160611 21:21:32-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has left #wesnoth-dev []
20160611 21:42:40< gfgtdf> shadowm: i just tried to play your campaign 'Invasion from the Unknown' (for the first time, im at senario 4, medium difficulcy) and there seem to be bugs with the loyal suppoter code
20160611 21:43:03< gfgtdf> shadowm: so that the supporter stays loyal for the reest of the campaign.
20160611 21:43:58< shadowm> gfgtdf: https://github.com/shikadilord/Invasion_from_the_Unknown/blob/master/macros/unit-utils.cfg#L256
20160611 21:46:08< gfgtdf> shadowm: 'duration=scenario' works afaik by removing that [object], then resetting all units stats (liek in advance to the same type) and then reapplying all remaining [modifications], its quite possible that upkeep= it not among the propertied that are reset when advaning units 
20160611 21:46:36< gfgtdf> shadowm: so 'all stats' might obviousl be wrong, it shoul be 'some stats'
20160611 21:46:46< celmin> That's not how I understood this works...
20160611 21:47:03< celmin> From what I understood, the "unit type" acts like a "prototype".
20160611 21:47:47< celmin> Whenever a unit is recalled or levels up, the unit is rebuilt from its prototype, keeping specific attributes constant (name, gender, variation, etc) and then reapplying any modifications on top.
20160611 21:48:09-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160611 21:48:17< celmin> I would expect object removal to do the same thing (for example with duration=turn).
20160611 21:48:42< celmin> Maybe it doesn't actually work this way, but I would argue that it should.
20160611 21:48:45< gfgtdf> celmin: yes its the same thing that happens when unit advances
20160611 21:48:59< gfgtdf> celmin: but nothign happens when a unit is recalled
20160611 21:49:13-!- shadowm is now known as shadowm2006
20160611 21:49:32< gfgtdf> celmin: and upkeep ismostlikeley among the properties that are keep intact
20160611 21:49:33< shadowm2006> I don't know C++ and programming stuffs so I don't know what you're talking about. :3
20160611 21:49:47< shadowm2006> (sic)
20160611 21:49:47< celmin> Doesn't recalling a unit rebuild it from the WML?
20160611 21:49:57-!- shadowm2006 is now known as shadowm
20160611 21:50:21< gfgtdf> celmin: hmm no it doenst it just moves the unti form the recall list ot the map.
20160611 21:50:46< celmin> Then, maybe it was rebuilt from the WML when the recall list was populated at scenario start?
20160611 21:51:27< gfgtdf> celmin: wel it was obvoudl read from the savefile whcih is wml
20160611 21:51:50< celmin> And that applies even if you advance straight to the next scenario, right?
20160611 21:53:11< gfgtdf> celmin: when a unit is read from wml things happen in this order: 1) the units stats are set to the stats of its unit_type, 2) [modification]s are applies, 3) propeties a overwritten using the content of single [unit] wml, (liek it also in savefiles)
20160611 21:53:53< gfgtdf> celmin: in savefiles, the singleunit wml contains more or less all data, so everythign calculates in 1) and 2) is overwritten anyways (except animation)
20160611 21:54:08< celmin> #1 is inaccurate.
20160611 21:54:27< celmin> "The unit's stats are set to the stats of the proper variant of its unit_type
20160611 21:54:28< gfgtdf> celmin: you'd decribe if differently ?
20160611 21:54:39< celmin> Where variant encompasses both gender and variation.
20160611 21:54:56< gfgtdf> celmin: hmm yes doenst realyl change my point,
20160611 21:55:10< celmin> No, I guess not.
20160611 21:55:27< celmin> I thought we weren't saving everything in savefiles anymore.
20160611 21:55:46< gfgtdf> celmin: everythign execpt animations
20160611 21:56:10< celmin> We should only save the attributes that differ from the result of step 2.
20160611 21:56:48< celmin> Plus the ones essential for running steps 1 and 2, of course (gender, variation, type, modifications).
20160611 21:57:00< gfgtdf> celmin: well i argee that the current way to do it is not really effcient
20160611 21:58:57< celmin> Maybe it would help to integrate the concept of a prototype into the config class… or a related class...
20160611 21:59:36< celmin> It's easy to implement what I want in JavaScript, because it has Object.hasOwnProperty().
20160611 22:00:37< celmin> So if there was a class that combines two configs such that one is the "prototype" and the other was the "overrides", it would be equally easy to implement what I'd like in C++, I think...
20160611 22:01:35< gfgtdf> celmin: ther are config members like apply_diff, merge etc, 
20160611 22:02:02< celmin> Yes, I can certainly do what I want with those, it's just not quite as convenient.
20160611 22:02:11< celmin> Maybe I'll give it a try again once I'm finished with spirit-po.
20160611 22:02:25< celmin> Though there's something else I kinda want to do first.
20160611 22:07:17< shadowm> So what should I take from this conversation?
20160611 22:08:57< gfgtdf> shadowm: that duration=scenario will remvoe the ojbect but the unit will stay loyal (it still has upkeep=loyal in its wml)
20160611 22:09:09< shadowm> Here's my version: "I'm using a feature that doesn't work as advertised."
20160611 22:09:58< celmin> ^
20160611 22:11:01< shadowm> I cannot express into words that I'm willing to use in this channel how much this sucks.
20160611 22:12:14< shadowm> But okay, it's only the millionth-twenty-second time that Wesnoth decides to rub in my face the fact that it absolutely hates creativity.
20160611 22:12:59< shadowm> It's not... going to leave much of a mark at this point.
20160611 22:13:43< shadowm> (Picture my voice breaking down as I can barely hold the tears in my eye sockets.)
20160611 22:14:55< shadowm> I guess I'll just... go and... sort of... make my code smarter than Wesnoth...
20160611 22:15:12< shadowm> ... Yeah...
20160611 22:16:00< shadowm> Anyone feeling like adding this crucial bit of information to the wiki entry on [object]?
20160611 22:16:11< shadowm> It'll probably save lives in the future.
20160611 22:16:28< shadowm> Or tears, at the very least.
20160611 22:16:42< vultraz> or maybe fix the issue
20160611 22:16:44< vultraz> ?
20160611 22:16:46< celmin> I would consider this a bug to be fixed, but mentioning it on the wiki sounds good nonetheless.
20160611 22:17:02< shadowm> vultraz: On master? Sure. On 1.12? No.
20160611 22:17:09< vultraz> it's at least an example of how our code sucks
20160611 22:17:28< shadowm> I'm not sure anymore if it's the code or the people who write it.
20160611 22:17:55< celmin> Well, I don't think the people who wrote it are the ones discussing it right now...
20160611 22:18:02< shadowm> Of course not.
20160611 22:18:14< shadowm> That's always the problem with everything that's broken in Wesnoth.
20160611 22:18:23< vultraz> it's the whole [object] system
20160611 22:18:28< shadowm> "how is this supposed to work?" "who knows, XYZ isn't around anymore"
20160611 22:18:31< vultraz> it's horrible by design
20160611 22:18:42< celmin> I disagree.
20160611 22:18:47< shadowm> "how do we refactor this code it's impossibly dense" "who knows, XYZ isn't around anymore"
20160611 22:19:14< celmin> Using an [object] is far better than arbitrarily altering the unit's attributes directly.
20160611 22:19:44< shadowm> [object] is good, it's the implementation that's prone to subtle bugs like this.
20160611 22:19:49< vultraz> celmin: perhaps, but I'm definitely going to come up with something better for 2.0
20160611 22:20:04< celmin> Somehow I think that's unlikely.
20160611 22:20:07< shadowm> Ugh, and then ABC plays the Wesnoth 2.0 card.
20160611 22:20:12< celmin> But feel free to make the attempt anyway.
20160611 22:20:17< shadowm> These exchanges have gotten incredibly predictable.
20160611 22:20:35< celmin> I'm doubting that there is a better way to do it.
20160611 22:20:42< celmin> I think the current way is actually quite good.
20160611 22:20:43< gfgtdf> resetting 'upkeep' in unit::advance_:to should be a one simple line.
20160611 22:21:41< shadowm> I'm making it a house rule that if you want me to take you seriously you are not allowed to play the Wesnoth 2.0 card. You may play the 1.14 card, or the 1.16 card, or any of the other 1.2n cards where n is an integer greater than 0. But you can't play the 2.0 card.
20160611 22:21:50< celmin> Feel free to do that, though if I get around to the prototypal thing it may be rendered redundant.
20160611 22:22:08< vultraz> alright, no more 2.0 card
20160611 22:22:21< shadowm> And no 2n.0 cards either.
20160611 22:22:30< vultraz> (I did have celmin's ptotype thing in mind)
20160611 22:22:32< shadowm> Or really any n.0 cards with n greater than 1.
20160611 22:22:34-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has quit [Remote host closed the connection]
20160611 22:22:36< vultraz> PROTOPEY
20160611 22:22:38< vultraz> f
20160611 22:22:41< vultraz> protoyype
20160611 22:22:42< vultraz> PROTOTYPE
20160611 22:22:44< vultraz> JFC
20160611 22:22:47< celmin> You do realize that my prototype thing does not abolish [object].
20160611 22:22:52-!- Coffee_irc [~david@2001:44b8:254:3200:eade:27ff:fe14:bca5] has joined #wesnoth-dev
20160611 22:22:59< vultraz> No need to abolish [object]
20160611 22:23:02< vultraz> just design it better
20160611 22:23:09< shadowm> I think he likes the word prototype because he's seen it elsewhere.
20160611 22:24:00< vultraz> I do like the word prototype
20160611 22:24:51< vultraz> anyway, I will henceforth refrain from mentioning 2.0
20160611 22:24:54< vultraz> however
20160611 22:25:09< vultraz> I would like to take this opportunity to remind celmin to reply to the email in a timely fashion
20160611 22:25:47< celmin> For the record, my use of the word "prototype" here refers to its meaning in JavaScript.
20160611 22:25:55< celmin> There was an email?
20160611 22:26:01< celmin> I haven't actually checked my mail for a bit.
20160611 22:26:14< vultraz> the mailing list
20160611 22:26:15< vultraz> email
20160611 22:26:52< vultraz> Please construct a list of things you want to absolutely do and things you'd only like to do for 1.14 and post it there.
20160611 22:27:02< shadowm> Any obvious problems with this code? http://pastebin.com/TR0ZUbZR
20160611 22:27:13< shadowm> Haven't tested it, just want to make sure I don't need to do it more than once.
20160611 22:29:02< celmin> Looks okay to me.
20160611 22:29:31< shadowm> Eh I can simplify the [if] condition but that's it.
20160611 22:31:42< shadowm> Yep, works.
20160611 22:31:48< gfgtdf> shadowm: hmm if there are unti shoudl becomeloyal suring a scenario scenario this code might fail, in this case i'D rather write [store_unit]variable=u[/store_unit] [clear_variavbe] u.upkeep [/clear_variavbe] [unstore_unit]variable=u[/unstore_unit]
20160611 22:32:07< gfgtdf> if there are units taht shoudl become loyal during the scenario.
20160611 22:32:08< shadowm> Although it'll probably make noise if the unit dies first, got to check that.
20160611 22:32:36< shadowm> gfgtdf: Eh.
20160611 22:32:56< shadowm> Okay firstly how is clearing the upkeep field going to make the unit anything other than full upkeep?
20160611 22:33:09< shadowm> That's the default for all units, isn't it?
20160611 22:34:04< celmin> Probably?
20160611 22:35:08< gfgtdf> shadowm: if there is an[object] apply_to=loyal, my issue was that is you for some reason add a apply_to=loyal to a veteran (that shodul no be removed at scenario ends) in some other code in your campaign your new code could clash with it, whether there is some code in your campaign i don't know
20160611 22:35:50< gfgtdf> s/that is you/that if you 
20160611 22:36:01< shadowm> I don't think so, because the only other option for units becoming loyal for any amount of time is one of the limited recall scenarios, and in those there aren't auto-recalled supporters.
20160611 22:37:01< shadowm> What can happen instead is that a supporter gets auto-recalled in a victory event, which reminds me of a subject that I never quite understood.
20160611 22:37:30-!- RatArmy [~RatArmy@om126204192158.6.openmobile.ne.jp] has quit [Ping timeout: 246 seconds]
20160611 22:37:33< shadowm> If I'm handling an XYZ event and define a new nested handler for it there, does the new handler get run at the end? Immediately? Maybe not at all?
20160611 22:37:40< shadowm> I guess I'm about to find out anyway.
20160611 22:38:47-!- mjs-de [~mjs-de@x5ce33015.dyn.telefonica.de] has joined #wesnoth-dev
20160611 22:39:04< shadowm> Looks like the answer is "never at all".
20160611 22:39:36< shadowm> :Z
20160611 22:39:38< celmin> I would expect it to run the next time that event is triggered.
20160611 22:39:52< shadowm> Yes, but the victory event is only fired once.
20160611 22:39:59< celmin> Ah.
20160611 22:40:01< shadowm> Because uh you can only win the scenario once.
20160611 22:40:02< gfgtdf> shadowm: i'd expect a segfault
20160611 22:40:11< celmin> But then, why do you even need a nested handler?
20160611 22:40:21< shadowm> gfgtdf: How can you say so calmly that you expect such a thing!
20160611 22:40:33< shadowm> And why would it crash, anyway?
20160611 22:40:41< shadowm> celmin: To unloyal the unit at the end of the scenario.
20160611 22:41:10< celmin> You could define the victory handler when the unit is first made loyal?
20160611 22:41:28< shadowm> ... Yes. That's what's in the paste.
20160611 22:41:40< shadowm> The problem is when the unit is first made loyal during the victory event.
20160611 22:41:55< gfgtdf> shadowm: hmm just joke, 
20160611 22:42:01< celmin> Why would it first be made loyal during the victory event?
20160611 22:42:04< shadowm> Which is a thing that I just confirmed happens in scenario 3 if the original supporter kicks the bucket.
20160611 22:42:06< celmin> gfgtdf: It wasn't very funny.
20160611 22:42:19< shadowm> The victory event recalls a new supporter in that case.
20160611 22:42:47< shadowm> Ugh I guess I could check what event is currently being handled, using Lua.
20160611 22:43:15< shadowm> But it's amazing how convoluted this simple mechanic is becoming thanks to a broken engine feature.
20160611 22:43:34< celmin> Indeed...
20160611 22:43:58 * vultraz nods
20160611 22:44:03< shadowm> Makes me regret giving in to the crowd and making auto-recalls loyal.
20160611 22:45:04-!- trewe [~trewe@bl20-30-79.dsl.telepac.pt] has quit [Quit: quit]
20160611 22:45:13-!- ancestral [~ancestral@35.sub-70-197-210.myvzw.com] has joined #wesnoth-dev
20160611 22:47:51< vultraz> ancestral: any trailer news?
20160611 22:48:36< ancestral> My schedule got changed today; I may have some time late tonight, but likely I’ll have something to show tomorrow
20160611 22:51:50< vultraz> ah, good, good
20160611 22:51:51< vultraz> :)
20160611 22:57:55-!- ancestral [~ancestral@35.sub-70-197-210.myvzw.com] has quit [Quit: i go nstuf kthxbai]
20160611 23:02:48-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20160611 23:03:02-!- Appleman1234 [~Appleman1@KD036012051027.au-net.ne.jp] has joined #wesnoth-dev
20160611 23:04:13-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160611 23:13:45-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160611 23:16:13-!- mjs-de [~mjs-de@x5ce33015.dyn.telefonica.de] has quit [Remote host closed the connection]
20160611 23:21:07-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160611 23:22:51-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20160611 23:34:12-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160611 23:39:38-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 250 seconds]
20160611 23:41:15-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160611 23:50:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160611 23:57:17-!- atarocch [~atarocch@151.64.65.55] has quit [Remote host closed the connection]
--- Log closed Sun Jun 12 00:00:51 2016