--- Log opened Tue Dec 01 00:00:24 2015
20151201 00:17:38< shadowm> Hm.
20151201 00:19:22< shadowm> Interesting artifact of losing power mid-save:
20151201 00:19:27< shadowm> -rw-r--r-- 1 shadowm shadowm  6707 Nov 30 04:55 animation-utils.cfg
20151201 00:19:27< shadowm> -rw-r--r-- 1 shadowm shadowm  6707 Nov 30 04:56 animation-utils.cfg.El7987
20151201 00:20:06-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20151201 00:43:17-!- mjs-de [~mjs-de@f048005081.adsl.alicedsl.de] has joined #wesnoth-dev
20151201 01:22:43-!- mjs-de [~mjs-de@f048005081.adsl.alicedsl.de] has quit [Remote host closed the connection]
20151201 01:27:43-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20151201 01:27:50-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20151201 01:28:38-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 250 seconds]
20151201 01:34:27-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20151201 01:47:07-!- shadowm_desktop [~ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20151201 02:11:41-!- gfgtdf_ [~chatzilla@f054150059.adsl.alicedsl.de] has joined #wesnoth-dev
20151201 02:13:42-!- gfgtdf [~chatzilla@f054151099.adsl.alicedsl.de] has quit [Ping timeout: 250 seconds]
20151201 02:13:50-!- gfgtdf_ is now known as gfgtdf
20151201 03:03:58-!- shadowm_desktop [~ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 260 seconds]
20151201 03:05:46< gfgtdf> is there a place in the forum to give feedback about mainline campaigns ? I only find feedback threads about single scenarios not about issues that effect the whole campaign.
20151201 03:06:19< shadowm> The campaign's development thread.
20151201 03:06:25-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20151201 03:07:04-!- shadowm_desktop [~ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20151201 03:07:30-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20151201 03:07:37< gfgtdf> shadowm: found it ty
20151201 03:37:11-!- louis94 [~~louis94@109.129.245.154] has quit [Quit: Konversation terminated!]
20151201 03:41:22-!- gfgtdf [~chatzilla@f054150059.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 42.0/20151029151421]]
20151201 03:41:46-!- shadowm_desktop [~ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 260 seconds]
20151201 03:45:39-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20151201 04:05:34-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 245 seconds]
20151201 04:07:37-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20151201 04:32:18-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20151201 04:44:19-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Read error: Connection reset by peer]
20151201 04:48:04-!- knotwork [~markm@unaffiliated/knotwork] has quit [Ping timeout: 245 seconds]
20151201 04:48:54-!- knotwork [~markm@unaffiliated/knotwork] has joined #wesnoth-dev
20151201 04:50:13-!- shadowm_desktop [~ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20151201 05:01:34-!- shadowm is now known as evilshadowm
20151201 05:37:22-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Ping timeout: 250 seconds]
20151201 05:48:35-!- Kwandulin [~Miranda@p200300760F6D9F14AC652DEB0E949EA3.dip0.t-ipconnect.de] has joined #wesnoth-dev
20151201 06:20:26-!- ancestral [~ancestral@184-100-99-25.mpls.qwest.net] has joined #wesnoth-dev
20151201 06:52:55-!- evilshadowm is now known as shadowm
20151201 07:05:26-!- Kwandulin_2 [~Miranda@p200300760F6D9FC4AC652DEB0E949EA3.dip0.t-ipconnect.de] has joined #wesnoth-dev
20151201 07:05:46-!- Kwandulin [~Miranda@p200300760F6D9F14AC652DEB0E949EA3.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
20151201 07:15:19-!- ancestral [~ancestral@184-100-99-25.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20151201 07:36:28-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20151201 07:59:15-!- boucman_work [~jrosen@193.56.60.161] has joined #wesnoth-dev
20151201 07:59:15-!- boucman_work [~jrosen@193.56.60.161] has quit [Changing host]
20151201 07:59:15-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20151201 08:14:55< Aginor> fabi: I would be keen to go to FOSDEM, but I am sadly on the wrong side of the planet. There's no feasible way for me to attend
20151201 08:21:34< shadowm> Aginor: So, what's the situation with the sdl2 branch?
20151201 08:27:50-!- Kwandulin_2 [~Miranda@p200300760F6D9FC4AC652DEB0E949EA3.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]
20151201 08:45:09< Aginor> shadowm: I havn't been able to debug the wine crash in the slightest, gfgtdf has reported a crash nobody else has managed to reproduce, including me and he's not been able to help me pinpoint what may cause it
20151201 08:46:09< shadowm> I've had a change of mind.
20151201 08:46:58< Aginor> oh?
20151201 08:47:14< shadowm> I'd like to release 1.13.2 on the 18th if no-one (including you) has any objections to that (obviously will post to the ML later today), mostly so we can get a relatively clean slate bug-wise for the first SDL 2-based release, which would be 1.13.3 instead.
20151201 08:47:39< Aginor> fair enough by me
20151201 08:47:59< shadowm> The primary reason I'd like to do this is that 1.13.2 would have celticminstrel's [foreach] tag and new [message] implementation, as well as the plethora of WML/Lua engine fixes we've accrued in the meantime.
20151201 08:48:18< Aginor> and as I've said in the past, I feel like I need more active help from a windows developer as well
20151201 08:48:33< shadowm> Plus it's been too long since 1.13.1, much longer than I originally expected.
20151201 08:49:14< Aginor> but then we can make 13.3 pretty quick if we get the last bits resolved?
20151201 08:49:28< shadowm> But once sdl2 lands post-1.13.2, I really want to move us to a time-based development release model, and feature-based stable release.
20151201 08:50:36< shadowm> I don't have a problem with fast-tracking 1.13.3 after sdl2 lands, but the earliest release date would have to be January 8th.
20151201 08:51:16< shadowm> (I don't want to go down in history as the guy who ruined the holidays for Wesnoth's packagers, you know.)
20151201 08:51:27< Aginor> that's fair enough
20151201 08:52:08< shadowm> (In fact, I'd also like to propose December 11th for 1.13.2 in case our packagers have plans for mid-December.)
20151201 08:52:51< zookeeper> hrhm, i guess the UtBS stuff goes in 1.13.3 then
20151201 08:53:00< zookeeper> Jetrel_bot, ^ unless you think you can crank out sprites like really fast
20151201 08:54:01< shadowm> Aginor: About the Windows issues... all I know is that 1) Wine is perpetually buggy, so Wine-specific bugs wouldn't be unlikely to happen and we shouldn't care much about those (unless they can be confirmed to have implications for real Windows); 2) gfgtdf's bug will have to be treated as a regular bug rather than a merge blocker unless at least one other person can reproduce it.
20151201 08:54:12< shadowm> (regular bug = release blocker, not merge blocker)
20151201 08:54:46< shadowm> In other words, disregard my Wine bug, and don't consider gfgtdf's a merge blocker yet.
20151201 08:55:10< Aginor> shadowm: unless more people go and test on windows we won't know though. there's reasonably little testing having happened
20151201 08:55:23< Aginor> shadowm: care to weigh on on the PM with that?
20151201 08:55:34< shadowm> I did take a look at sdl2 on a Windows 8.1 VM running under VirtualBox with no 3D accel enabled and didn't really see any problems with resizing the window, other than the blackness glitch.
20151201 08:55:54< shadowm> I'm not sure if I mentioned that in here.
20151201 08:56:22< Aginor> I never noticed if you did :)
20151201 08:56:35< shadowm> I wouldn't try enabling 3D accel because VirtualBox's 3D accel support is seriously buggy.
20151201 08:58:37< shadowm> There's actually a third reason I want a last non-SDL 2 release out: easing people into the new Windows workflow.
20151201 08:59:15< Aginor> and what is the new windows workflow?
20151201 08:59:20< shadowm> (Meaning combined log in user data\logs, forcibly moving user data to Documents by default, generally not relying on UAC virtualization anymore and manifesting executables for Windows Vista - 10.)
20151201 08:59:37< Aginor> ah
20151201 08:59:47< shadowm> That stuff, nothing I didn't post to the ML before. :)
20151201 09:00:09< Aginor> fair enough
20151201 09:00:14< Aginor> I have read about those things
20151201 09:00:29< shadowm> It's important because I suspect the UMC authors crowd will want to lynch me anyway.
20151201 09:01:23< shadowm> "you want to introduce CHANGES??? how evil can you BE"
20151201 09:02:48< Aginor> hmmm
20151201 09:02:56< Aginor> there's a conflict between master and sdl2
20151201 09:02:59 * Aginor sighs
20151201 09:03:25< shadowm> It might be in my code.
20151201 09:03:48< Aginor> yes
20151201 09:03:54< shadowm> Want me to deal with it?
20151201 09:04:20< Aginor> you also broke OSX
20151201 09:04:23-!- zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] has joined #wesnoth-dev
20151201 09:05:19< Aginor> #if defined(__native_client__) || (defined(__APPLE__) && SDL_VERSION_ATLEAST(2, 0, 0))
20151201 09:05:22< Aginor> extern "C" int wesnoth_main(int argc, char** argv);
20151201 09:05:37< Aginor> those are also needed by the objective-c files digging into wesnoth
20151201 09:05:50< shadowm> Uh, I didn't touch anything involving OS X.
20151201 09:06:07< Aginor> no, OS X invokes that file too
20151201 09:06:13< Aginor> s/file/function/
20151201 09:06:21< Aginor> and I think it relies on it being extern "C"
20151201 09:06:29< Aginor> at the very least being defined
20151201 09:06:34< loonycyborg> I was planning to set up sdl2 for my windows builds, but it would be nice if I didn't have to check out a separate branch to test it properly
20151201 09:06:54< shadowm> You people are allergic to branches, you know? :p
20151201 09:07:07< Aginor> loonycyborg: "git checkout sdl2" it's not that hard :D
20151201 09:07:27< loonycyborg> it can lead to confusion later.
20151201 09:07:27-!- Kwandulin [~Miranda@p200300760F6D9FC4AC652DEB0E949EA3.dip0.t-ipconnect.de] has joined #wesnoth-dev
20151201 09:07:37< loonycyborg> like me forgetting on which branch I was
20151201 09:07:38< shadowm> Aginor: Do you have many local commits that you haven't pushed upstream yet?
20151201 09:07:40< loonycyborg> and gettig confused
20151201 09:08:16< shadowm> loonycyborg: git-new-workdir.cmd (though it's a PITA to set up the first time, and also only probably works on Vista and later).
20151201 09:08:33< shadowm> Best way to have one dir for each branch.
20151201 09:08:34< loonycyborg> I still have winxp there
20151201 09:08:46< loonycyborg> and I already have 2 dirs
20151201 09:08:53< loonycyborg> one for stable other for master
20151201 09:09:02< Aginor> shadowm: none, I'm in the process of resolving your conflict
20151201 09:09:07< Aginor> then I'll do a new push
20151201 09:09:31< shadowm> Aginor: Okay, so I don't need to deal with it then?
20151201 09:09:55< shadowm> I just tried a merge between the upstream versions and only got a single conflict near the start of wesnoth.cpp due to a comment removal I did.
20151201 09:10:19< Aginor> shadowm: no, I've got it
20151201 09:11:01< shadowm> And about the SDL_main/main function signature, I definitely didn't touch it.
20151201 09:11:24< Aginor> hmmm
20151201 09:11:51< Aginor> maybe I'm just too tired and fail at merging
20151201 09:12:09 * Aginor gives up on meld and trusts in emacs instead
20151201 09:13:48< Aginor> hmm
20151201 09:13:53< Aginor> cmake on master is broken
20151201 09:13:57 * Aginor grumbles further
20151201 09:14:01< Aginor> nothing is ever simple
20151201 09:14:19< Jetrel_bot> zookeeper:  it'll wait, then
20151201 09:14:51< shadowm> Aginor: That might be me.
20151201 09:15:14< shadowm> Especially if you are using CMake on Windows.
20151201 09:15:34< Aginor> yes, it's you :D
20151201 09:15:37< Aginor> aae8e70c7aff84117f48271dedbd1f2189fd7509
20151201 09:16:00< shadowm> Ohhh.
20151201 09:16:03< Aginor> introducing and if without closing it
20151201 09:16:12< shadowm> Yes, I'll commit a fix immediately.
20151201 09:16:18< Aginor> please do :)
20151201 09:16:24< Aginor> I will verify it's correctness
20151201 09:17:00-!- irker680 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20151201 09:17:00< irker680> wesnoth: Ignacio R. Morelle wesnoth:master d966b68d64d9 / src/CMakeLists.txt: cmake: Fix unclosed if block http://git.io/vBNMA
20151201 09:17:12< zookeeper> Jetrel_bot, okay. i think it definitely needs to be in 1.13.3 though, so in a few months time i suppose.
20151201 09:17:25< shadowm> Aginor: Sorry about that. It shows that people don't use CMake a lot. :p
20151201 09:21:01 * Aginor gives a pre-canned rant on the importance about testing before pushing to master :D
20151201 09:21:36< Aginor> and no worries, it works now :)
20151201 09:22:00< shadowm> It didn't occur to me that I could break CMake for all platforms with a line-wide typo, and I haven't figured out how to use CMake on Windows yet.
20151201 09:22:13< Aginor> what is it people use instead? scons?
20151201 09:22:32< Aginor> shadowm: download cmake and run it as normal from the cmd prompt
20151201 09:22:37< shadowm> Packagers use CMake, developers on Linux like me mostly prefer SCons.
20151201 09:23:24< Aginor> I've somehow gotten it into my head that compiling is a lot faster with cmake
20151201 09:23:33< shadowm> I mean downstream packagers like Debian, Fedora, etc. Our mainline packagers use SCons (Windows) and XCode (OS X).
20151201 09:24:09< Aginor> that explains my rocky experience with trying to cross compile for wine then :D
20151201 09:24:16< shadowm> CMake's Release build type uses -O3 whereas SCons' uses -O2, so by all means SCons ought to be faster out of the box.
20151201 09:24:30< Aginor> I meant compiling
20151201 09:24:38< shadowm> Except that CMake doesn't specify a build type by default, so it doesn't pass any -O switches and most compilers default to -O0 then.
20151201 09:25:50< shadowm> Anyway, later.
20151201 09:27:01< Aginor> would you ind squelching the bot before you leave
20151201 09:27:02< shadowm> Oh and if you will push the merge, you can ask zookeeper or vultraz or loonycyborg to use `/msg chanserv quiet #wesnoth-dev irker*!*@*` (and later unquiet).
20151201 09:27:07< shadowm> Oh okay.
20151201 09:27:14-!- mode/#wesnoth-dev [+q irker*!*@*] by ChanServ
20151201 09:27:22-!- mode/#wesnoth-dev [+o shadowm] by ChanServ
20151201 09:27:25-!- mode/#wesnoth-dev [+z] by shadowm
20151201 09:27:28< Aginor> and please weigh in on the PR when you have the time
20151201 09:27:28<@shadowm> Aginor: You can push now.
20151201 09:28:22< Aginor> yup, just giving it a quick test first
20151201 09:37:28-!- mode/#wesnoth-dev [-qzo irker*!*@* shadowm] by shadowm
20151201 09:37:38< Aginor> thanks shadowm 
20151201 09:37:48< shadowm> No problem.
20151201 09:37:58< Aginor> I was giving it time to quiet down, but maybe that's not needed
20151201 09:38:11< Aginor> I don't particularily know how the bot does its thing
20151201 09:38:35< shadowm> When I turn on channel mode +z, messages from quieted users can still be seen by ops.
20151201 09:38:45< shadowm> I was opped, so I saw this: 06:36:43 <irker680> wesnoth: Andreas Löf wesnoth:sdl2 81480d1d774d / / (70 files in 23 dirs): Merge branch 'master' into sdl2 http://git.io/vBNdW
20151201 09:38:52< Aginor> right
20151201 09:39:21< shadowm> That's the branch tip, so I knew the flood was over then.
20151201 09:39:32< Aginor> indeed
20151201 09:51:02-!- Appleman1234 [~Appleman1@KD119104016127.au-net.ne.jp] has joined #wesnoth-dev
20151201 10:06:46-!- shadowm_desktop [~ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 260 seconds]
20151201 10:35:34-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20151201 10:45:10-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Quit: Disconnecting from stoned server.]
20151201 10:46:53-!- Ivanovic [~ivanovic@p579FB451.dip0.t-ipconnect.de] has joined #wesnoth-dev
20151201 10:55:46-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 260 seconds]
20151201 11:01:50-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20151201 11:01:50-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20151201 11:01:50-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20151201 11:13:03-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20151201 11:38:20-!- oldlaptop [~quassel@192.183.50.87] has quit [Remote host closed the connection]
20151201 11:43:11-!- oldlaptop [~quassel@192.183.50.87] has joined #wesnoth-dev
20151201 12:18:46< zookeeper> what was it that SUF find_in looks for again? just id=?
20151201 12:27:14-!- molgrum [~molgrum@unaffiliated/molgrum] has quit [Ping timeout: 260 seconds]
20151201 12:29:06-!- molgrum [~molgrum@h-94-103.a230.priv.bahnhof.se] has joined #wesnoth-dev
20151201 12:29:06-!- molgrum [~molgrum@h-94-103.a230.priv.bahnhof.se] has quit [Changing host]
20151201 12:29:06-!- molgrum [~molgrum@unaffiliated/molgrum] has joined #wesnoth-dev
20151201 12:36:45-!- irker680 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20151201 12:43:42-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20151201 12:45:02< fendrin> zookeeper: underlying_internal_id_mess_thing?
20151201 12:55:08< fendrin> zookeeper: unit_filter.cpp Line 513: if(c["id"] == u.id()) found_id = true;
20151201 12:55:47< zookeeper> right, cool
20151201 13:03:44-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20151201 13:05:27-!- ancestral [~ancestral@184-100-99-25.mpls.qwest.net] has joined #wesnoth-dev
20151201 13:14:21-!- Kwandulin [~Miranda@p200300760F6D9FC4AC652DEB0E949EA3.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20151201 13:17:39-!- Grickit is now known as Gambit
20151201 13:24:27-!- aquileia [~chatzilla@eduroam172-062.wlan.uni-ulm.de] has joined #wesnoth-dev
20151201 13:27:47< aquileia> Aginor: Don't have much time this or next week, but I could check the bug gfgtdf reported if you tell me how to reproduce it
20151201 13:31:05< aquileia> shadowm: It wouldn't have hurt to add a #po comment to the string you introduced in 4265527a90 - as it's only a single font, translators may not understand that it's translatable for sake of permutations
20151201 13:37:22< aquileia> AI0867: In 038ff82a0 you introduced a translatable string to data\scenario-test.cfg, which aside from that isn't translatable... I doubt we need to translate a test scenario?
20151201 13:41:26< aquileia> mattsc: GTW, your wesnoth-ai textdomain for the Micro AI sample scenarios is in mainline as well, I thought they were only accessible via the command line (unless you install them from the addon server, of course)?
20151201 13:41:34< aquileia> s/GTW/BTW
20151201 13:48:27-!- zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] has quit [Quit: Leaving]
20151201 13:50:40-!- Kwandulin [~Miranda@p200300760F6D9FC455ACE836A5C59C00.dip0.t-ipconnect.de] has joined #wesnoth-dev
20151201 13:50:56-!- Appleman1234 [~Appleman1@KD119104016127.au-net.ne.jp] has quit [Ping timeout: 250 seconds]
20151201 14:05:42-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 260 seconds]
20151201 14:06:42-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20151201 14:10:52< mattsc> aquileia: yes - does that mean there shouldn’t be a textdomain?  They are still in mainline, just not accessible as easily as other things.  Maybe I am missing something?
20151201 14:13:43-!- mjs-de [~mjs-de@x4db5c9d5.dyn.telefonica.de] has joined #wesnoth-dev
20151201 14:15:23< aquileia> mattsc: It's just that wesnoth-ai is barely translated at all (see http://www.wesnoth.org/gettext/?package=wesnoth-ai&order=trans&version=branch ), and most test scenarios don't use translatable strings.
20151201 14:16:00< aquileia> It may be preferable not to burden translators with content the end user never sees.
20151201 14:16:16< aquileia> However, I've got to go, so see you later (or via the logs)
20151201 14:16:26-!- aquileia [~chatzilla@eduroam172-062.wlan.uni-ulm.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 42.0/20151029151421]]
20151201 14:25:21-!- mattsc [~mattsc@wesnoth/developer/mattsc] has left #wesnoth-dev []
20151201 14:32:55-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20151201 14:40:41-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20151201 14:47:14-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20151201 14:54:44-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20151201 15:03:36-!- ancestral [~ancestral@184-100-99-25.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20151201 15:05:39-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20151201 15:36:23-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20151201 15:48:32-!- gfgtdf [~chatzilla@f054150059.adsl.alicedsl.de] has joined #wesnoth-dev
20151201 15:54:29< gfgtdf> is there  reason why leadership doest work on allied units ?
20151201 15:55:12< zookeeper> could be for 2vs2 balance originally
20151201 15:57:51-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20151201 15:58:43< gfgtdf> zookeeper: is it true the affect_allies="" meany onyl effect same side affect_allies=yes means effect allies and same team, and affect_allies=no means effect neigher allies nor same side ?
20151201 16:10:10< zookeeper> i don't know
20151201 16:10:40< gfgtdf> zookeeper: hmm i think this is not very good documented
20151201 16:11:46< zookeeper> looks pretty clear to me
20151201 16:11:54< zookeeper> i bet it says exactly what it says on the tin
20151201 16:11:59< zookeeper> err, s/says/does
20151201 16:12:42< gfgtdf> "tin" ?
20151201 16:12:43< zookeeper> affect_allies and affect_enemies only work in abilities which actually affect adjacent units
20151201 16:12:57< Jetrel_bot> zookeeper:  so regarding me getting started on those desert elf sprites - is there a unit tree up anywhere?  ISTR you having made some test objects for them - if it's on github anywhere, I can work from that
20151201 16:13:03< zookeeper> https://en.wikipedia.org/wiki/Does_exactly_what_it_says_on_the_tin
20151201 16:14:46< Jetrel_bot> gfgtdf:  "tin" => "tin can"; i.e. industrially-canned goods.  Probably leans towards being a british-ism
20151201 16:14:52< zookeeper> Jetrel_bot, it's all up and functional in https://github.com/ln-zookeeper/wesnoth/tree/quenoth/data/campaigns/Under_the_Burning_Suns although maybe you find https://dl.dropboxusercontent.com/u/63964618/wesnoth/quenoth/unit_tree.png useful for quick reference
20151201 16:16:25< Jetrel_bot> okay, great.  I'll try to break the ice on this, this week
20151201 16:17:10< gfgtdf> zookeeper: still dont know what it means
20151201 16:17:49< zookeeper> gfgtdf, i bet it works exactly how the documentation says it works
20151201 16:18:12< Jetrel_bot> gfgtdf:  so, a great many "industrially-canned products", when not necessarily food (paint, various chemicals designed to do things, etc" often had instructions printed on the side of them.
20151201 16:18:30< zookeeper> as in, affect_allies=yes makes it affect allies too, affect_allies=no is very likely the same as omitting it (for abilities which by default would affect your own side's units), etc
20151201 16:18:57< gfgtdf> zookeeper: im quite sure that affect_allies=no is not that same as sommiting it
20151201 16:19:05< zookeeper> for leadership?
20151201 16:19:42< gfgtdf> zookeeper: i think it works the same for every ability.
20151201 16:20:20< zookeeper> most abilities _can't_ affect other units
20151201 16:20:29< zookeeper> skirmisher, teleport, regenerate...
20151201 16:20:30< gfgtdf> Jetrel_bot: that " was meant as a ) ?
20151201 16:21:12< Jetrel_bot> yeah
20151201 16:21:32< gfgtdf> zookeeper: did you test what happens if you add [affect_adjacent] to them ?
20151201 16:22:03< zookeeper> i haven't tested anything
20151201 16:22:49< zookeeper> some of that ability stuff had all sorts of weird inconsistencies at some point, so it's entirely possible there's still bugs left
20151201 16:23:27< celticminstrel> How could omitting affect_allies be different from affect_allies=no?
20151201 16:23:31< Jetrel_bot> gfgtdf:  anyways, the loose idea behind the phrase is that a great many products had "unspoken caveats" - i.e. they didn't quite work the way they were supposed to work.  Often there were informal tricks-of-the-trade people had to employ to make a product actually work properly.  For example, some glue might need heat to dry and cure properly, whereas the packaging might have implied that air drying would suffice.
20151201 16:23:53< zookeeper> [affect_adjacent] should just act as an optional extra filter on which adjacent units can receive the effects
20151201 16:25:11< Jetrel_bot> gfgtdf:  anyways, the original ad-campaign that spawned the phrase was capitalizing on the idea that it would be nice if something was simple, and worked exactly the way it was described to work without needing any esoteric tricks to make it do so.  It's interesting how many things well outside of the original domain this idea applies to.
20151201 16:26:35< zookeeper> Jetrel_bot, not that it's a major problem or anything, but i feel like the unit tree is a bit... formulaic in how the branching works :p
20151201 16:26:47< gfgtdf> zookeeper: so you think we can remove the [affect_adjacent] from mailine heals abilty ?
20151201 16:27:14< Jetrel_bot> zookeeper:  I'm fine with any changes to liven that up, of course.
20151201 16:27:27< zookeeper> gfgtdf, huh... i didn't realize there were empty tags like that there. i... think so? they shouldn't actually do anything.
20151201 16:30:34< zookeeper> " If there are no [affect_adjacent] tags, then no adjacent units will receive the effects."
20151201 16:31:28< zookeeper> i don't really know what the exact history behind that is
20151201 16:31:43< fendrin> hmmm
20151201 16:32:03< fendrin> affect_adjacent is just another unit_filter
20151201 16:32:14< fendrin> and empty unit filters match to every unit
20151201 16:32:22< zookeeper> of course, that part of the documentation could simply be outdated
20151201 16:33:10< celticminstrel> The affect_allies and affect_enemies keys logically belong in the [affect_adjacent].
20151201 16:33:22< celticminstrel> However, that's not possible since the unit filter only knows about one unit.
20151201 16:33:49< celticminstrel> ...although it could be made possible, since I implemented a way for a unit filter to know about two units.
20151201 16:34:12< celticminstrel> I can't quite remember, but I don't think I applied that to [affect_adjacent].
20151201 16:34:35< zookeeper> the keys are fine where they are, please don't give certain unnamed people ideas
20151201 16:34:45< celticminstrel> ...heh, okay, fine.
20151201 16:35:01< celticminstrel> They are certainly fine where they are.
20151201 16:35:53< gfgtdf> back to my original issue which is that affect_allies beeing wrongly  documented, we could eigher split affect_allies to affect_allies  and affect_side or chang the documentation. Any opionion on this?
20151201 16:35:59< zookeeper> they wouldn't need to be moved anyway, since [affect_adjacent][filter] could now apparently perform the ally/enemy checks on its own
20151201 16:36:10< fendrin> "please don't give certain unnamed people ideas"  I really love the attitude of this project.
20151201 16:37:09< celticminstrel> Pretty sure he didn't mean you.
20151201 16:37:11< zookeeper> gfgtdf, i still don't understand what you say is wrong about it
20151201 16:37:35< fendrin> I shoule make that my forum account signature.
20151201 16:38:09< celticminstrel> Hmm. I see. [affect_adjacent] is not a SUF after all.
20151201 16:38:15< fendrin> no?
20151201 16:38:18< celticminstrel> Rather, it contains a SUF.
20151201 16:38:45< fendrin> well
20151201 16:38:56< celticminstrel> In a nested [filter] tag.
20151201 16:39:03< fendrin> oh yeah
20151201 16:39:10< fendrin> that is a difference
20151201 16:39:20< celticminstrel> And I did enable two-unit filtering there.
20151201 16:39:33< fendrin> I wonder if I remove every not nested filters in WSL.
20151201 16:40:00< celticminstrel> So, if I'm not mistaken, the effect of affect_allies and affect_enemies could be implemented with just the [affect_adjacent].
20151201 16:40:36< zookeeper> yes
20151201 16:41:05< celticminstrel> Because of the new $other_unit variable.
20151201 16:41:08< zookeeper> but let's not give certain unnamed people ideas about that either :>
20151201 16:41:16< fendrin> yeah
20151201 16:41:17< celticminstrel> It'd be quite a bit more verbose though.
20151201 16:41:27< fendrin> unnamed people are bad
20151201 16:41:29< celticminstrel> So it's probably worth retaining the simpler version.
20151201 16:41:54< shadowm> Give who ideas?
20151201 16:42:49< shadowm> !commit 4265527a90
20151201 16:42:50< shikadibot> shadowm: Revision 4265527a90f6 (Ignacio R. Morelle) on Sat May 30 23:13:05 2015:
20151201 16:42:53< shikadibot> shadowm: ttext: Add support for selecting monospace font family
20151201 16:42:55< shikadibot> shadowm:  
20151201 16:42:58< shikadibot> shadowm: This selects DejaVu Sans Mono instead of whatever sans serif font is the
20151201 16:43:01< shikadibot> shadowm: (+9 discarded lines)
20151201 16:43:03< shikadibot> shadowm: Web interface URL: https://github.com/wesnoth/wesnoth/commit/4265527a90f6
20151201 16:43:27< shadowm> aquileia: Ah, yeah, probably should add that.
20151201 16:43:47< gfgtdf> zookeeper: : look at documentation: http://wiki.wesnoth.org/AbilitiesWML and look at the code https://github.com/wesnoth/wesnoth/blob/master/src/unit_abilities.cpp#L118
20151201 16:44:30< shadowm> aquileia: AI0867 is dead (metaphorically speaking) so he'll never respond to you. Just make it not translatable.
20151201 16:44:43< vultraz> zookeeper: you mean me? :P
20151201 16:44:49< zookeeper> oops
20151201 16:45:06< shadowm> (Don't worry, I know for a fact that he's alive, he's just not responding to any messages at all.)
20151201 16:45:22< zookeeper> curse my metal body, i wasn't vague enough
20151201 16:45:42< fendrin> rofl
20151201 16:45:47< fendrin> poor vultraz
20151201 16:46:17< celticminstrel> gfgtdf: Your point?
20151201 16:46:28< gfgtdf> celticminstrel: ?
20151201 16:46:29< zookeeper> gfgtdf, ok, so... i take it that affect_allies defaults to false? so, if affect_allies is missing, it won't affect any side? but is that function used to check whether to affect the same side's units, or only other sides' units?
20151201 16:46:33-!- shadowm_desktop [~ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20151201 16:46:51< shadowm> Hi fendrin.
20151201 16:46:52< celticminstrel> It looks to me like the code and docs match.
20151201 16:47:17< celticminstrel> Based just on that function, mind you. What zookeeper is also relevant.
20151201 16:50:59< fendrin> gfgtdf: regarding your post in the forum about LoW, your first point.
20151201 16:51:18< fendrin> Please have a look at the chapter system LoW comes with.
20151201 16:51:39< fendrin> In fact mp LoW is 4 (later maybe 5) short campaigns
20151201 16:52:04< fendrin> persistent variables 
20151201 16:52:33< fendrin> are used to load your side state when you start one of the later chapters from scratch.
20151201 16:52:41< gfgtdf> celticminstrel: the function checks affect_allies 2 times oce for the same_side case and once for the allied but differnt side case, in the first case it defaults to true in teh seconds it defaults to false.
20151201 16:53:23< celticminstrel> I wouldn't be surprised if the first case is never reached.
20151201 16:53:51< celticminstrel> If it's only called for adjacent units...
20151201 16:53:54< gfgtdf> fendrin: i know but it still make it more complicated sonce you cannot easily conibue after you finished scneario 3.
20151201 16:54:00< celticminstrel> Oh wait, never mind.
20151201 16:54:04< celticminstrel> It's checking the side.
20151201 16:54:18< celticminstrel> Now I get what you're saying.
20151201 16:54:39< fendrin> gfgtdf: Well yes. But how often do all players have enough time to play a huge campaign like LoW in one row?
20151201 16:54:39< celticminstrel> affect_allies omitted = it affects units of the same side, but not units of allied sides.
20151201 16:55:05< gfgtdf> fendrin: hmm if they for exmaple from a loaded game from scenario 2 or 3 then it coudl be
20151201 16:55:48< fendrin> gfgtdf: 2) is a good point and should be fixed by adjusting how leadership works in LoW and LoW only.
20151201 16:56:14< celticminstrel> Wait, why?
20151201 16:56:26< zookeeper> gfgtdf, celticminstrel, so is there a discrepancy or not? if there is then i'm still not seeing it :p
20151201 16:56:41< gfgtdf> celticminstrel: why what?
20151201 16:56:49< celticminstrel> What fendrin said.
20151201 16:58:06< celticminstrel> zookeeper: Nothing the wiki says is wrong, but the effect of omitting affect_allies altogether is undocumented and would probably be surprising if someone leaves it out accidentally.
20151201 16:58:35< zookeeper> celticminstrel, and just to be clear, what is the effect of omitting affect_allies?
20151201 16:59:21< celticminstrel> The ability will affect units of the same side but not units of allied sides.
20151201 16:59:35< celticminstrel> (Nor units of enemy sides.)
20151201 17:00:09< zookeeper> well, yes, i agree that it's undocumented that by default healing and leadership affect units of the same side
20151201 17:00:16< zookeeper> i dunno if anyone's been confused by that though :P
20151201 17:01:11< celticminstrel> Hm?
20151201 17:01:38-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 260 seconds]
20151201 17:01:42< celticminstrel> Those also affect units of allied sides though, right?
20151201 17:02:46< Ravana_> the question here should be if it is reasonably simple to have ability that affects allies but not own units
20151201 17:03:06< zookeeper> celticminstrel, i bet that without affect_allies=yes they don't
20151201 17:03:24< celticminstrel> Ravana_: It could be done with the $other_unit variable.
20151201 17:03:38< zookeeper> ^ yes, in 1.13 there is that way
20151201 17:03:46< Ravana_> then changing wiki should be good enough
20151201 17:03:52< celticminstrel> Doesn't healing affect allies?
20151201 17:03:57< celticminstrel> I thought it did.
20151201 17:04:34< gfgtdf> celticminstrel: haling effect allies
20151201 17:04:35< zookeeper> healing or [heals]? naturally we're talking about the latter
20151201 17:04:50< celticminstrel> Oh.
20151201 17:05:04< fendrin> I think if the behavior of those WML tags is to be changed it should be done by basing the whole thing on a common infrastructure.
20151201 17:05:55< fendrin> Meaning that the abilities should just use the wml_action [heal_unit] 
20151201 17:06:11< zookeeper> Ravana_, what's there to change? add a note that "[heals] and [leadership] by default affect adjacent units of the same side"? sure... i guess that doesn't hurt, but seems pretty redundant.
20151201 17:06:31< celticminstrel> It's not just [heals] and [leadership], is it? Isn't it all abilities?
20151201 17:06:38< fendrin> and not have its own [heals] tag with a different code behind it
20151201 17:06:40< zookeeper> no, it's just those
20151201 17:06:50< celticminstrel> Are you sure?
20151201 17:06:57< zookeeper> you can't make a [resistance] or [skirmisher] ability affect adjacents
20151201 17:07:12< gfgtdf> zookeeper: you can i have seen addons that do this
20151201 17:07:25< celticminstrel> I seem to recall making a [resistance] ability that affects adjacents.
20151201 17:07:38< gfgtdf> zookeeper: LotI does it with [resistance] in im quite sure i have also already seen iwth with skirmisher
20151201 17:07:55< zookeeper> i'm not saying it's not possible that i just haven't noticed someone implementing that, but i demand proof :>
20151201 17:08:12< Ravana_> not sure what exactly to change..
20151201 17:08:29< zookeeper> the usual way to do those is to give everyone the ability, and filter it so that it activates when the "unit giving the ability" is adjacent
20151201 17:08:53< zookeeper> for example the distract ability in TRoW
20151201 17:09:09< zookeeper> wait, what
20151201 17:09:12< zookeeper> that's not how it works
20151201 17:09:24< zookeeper> it actually works the way you said O.o
20151201 17:10:18< zookeeper> ok, so, yes, i need a minute to re-evaluate this whole discussion then
20151201 17:10:26< Ravana_> zookeeper: resistance is quite common to have for allies, https://github.com/ProditorMagnus/Ageless-for-1-11/blob/master/data/EoMa_data/abilities/cold_aura.cfg https://github.com/ProditorMagnus/Ageless-for-1-11/blob/master/data/EoMa_data/abilities/circle_of_sus.cfg https://github.com/ProditorMagnus/Ageless-for-1-11/blob/master/data/FE_data/abilities/phalanx.c
20151201 17:12:09< Ravana_> I can recall ME, EoMa, FE, EoC, EFM having that
20151201 17:12:37< zookeeper> yeah i have no idea why i have forgotten that. i wrote the distract ability after all :P
20151201 17:12:37-!- fendrin [~quassel@wesnoth/developer/fendrin] has quit [Quit: No Ping reply in 180 seconds.]
20151201 17:13:04-!- molgrum [~molgrum@unaffiliated/molgrum] has quit [Ping timeout: 245 seconds]
20151201 17:14:07-!- molgrum [~molgrum@h-94-103.a230.priv.bahnhof.se] has joined #wesnoth-dev
20151201 17:14:07-!- molgrum [~molgrum@h-94-103.a230.priv.bahnhof.se] has quit [Changing host]
20151201 17:14:07-!- molgrum [~molgrum@unaffiliated/molgrum] has joined #wesnoth-dev
20151201 17:14:08-!- fendrin [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20151201 17:15:42< zookeeper> ok, so... by default, an ability only affects self. if you have [affect_adjacent] (let's say an empty one), then it affects self and adjacent units of the same side. without [affect_adjacent], no adjacent units of the same side can be affected. adding affect_allies/enemies=yes makes it affect allies/enemies too.
20151201 17:16:22< zookeeper> what happens if you omit affect_allies but still have an empty [affect_adjacent]?
20151201 17:18:00< celticminstrel> I've already said it twice...
20151201 17:20:24< zookeeper> yeah but i'd need to slowly read through the whole discussion again to make sure i understand what was meant :p
20151201 17:21:06< zookeeper> <celticminstrel> affect_allies omitted = it affects units of the same side, but not units of allied sides.
20151201 17:21:09< zookeeper> i guess that's it
20151201 17:21:34< celticminstrel> If I understand correctly, with no [affect_adjacent], the affect_allies and affect_enemies keys have no effect.
20151201 17:22:43< zookeeper> yeah, probably
20151201 17:24:08< zookeeper> so, that should be mentioned next to those keys
20151201 17:24:26< zookeeper> as opposed to only having that "If there are no [affect_adjacent] tags, then no adjacent units will receive the effects" note in [affect_adjacent]
20151201 17:27:37< zookeeper> so the confusing part is that if you have say a [skirmisher] ability which has [affect_adjacent] but no affect_allies/enemies at all, it's going to affect units of your own side only?
20151201 17:28:25< celticminstrel> Yeah.
20151201 17:28:29< fendrin> affect_adjacent works in skirmisher?
20151201 17:28:34< zookeeper> even though it might seem like logically it'd affect _any_ adjacent unit?
20151201 17:28:38< fendrin> How does that work?
20151201 17:28:42< zookeeper> yeah i agree that should be clarified, then
20151201 17:28:59< celticminstrel> Actually, if it had affect_enemies but not affect_allies, it would still affect units of the same side in addition to enemies, I think.
20151201 17:29:24< zookeeper> right! that's bad
20151201 17:29:28< zookeeper> fendrin, easily: https://github.com/wesnoth/wesnoth/blob/master/data/campaigns/The_Rise_Of_Wesnoth/utils/trow-abilities.cfg
20151201 17:30:44< fendrin> Thank you.
20151201 17:31:10< fendrin> Interresting use case. 
20151201 17:33:42< shadowm> !tag 1.12.5
20151201 17:33:43< shikadibot> shadowm: Tag 1.12.5, revision 1ce2ee82e8d8 (Ignacio R. Morelle) on Fri Nov  6 00:37:04 2015:
20151201 17:33:46< shikadibot> shadowm: Version 1.12.5
20151201 17:33:49< shikadibot> shadowm: Web interface URL: https://github.com/wesnoth/wesnoth/commit/1ce2ee82e8d8
20151201 17:36:08< gfgtdf> if all abiltties can effect adjacent units i wonder why we have differnet [heals] and [regenerates] then ?
20151201 17:36:24< celticminstrel> I think that's a relic.
20151201 17:38:00-!- Kwandulin [~Miranda@p200300760F6D9FC455ACE836A5C59C00.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20151201 17:39:49< zookeeper> yes, that case is... probably a relic
20151201 17:40:00< zookeeper> dunno if there's some corner case reason why it should be kept
20151201 17:48:20-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20151201 17:48:20-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20151201 17:52:45-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20151201 18:10:11< zookeeper> what the...
20151201 18:11:41< zookeeper> so i went digging for the origins of the distract ability. if someone had proposed a bet with a nontrivial sum of money on when it was written and by whom, i'm pretty sure i would have been fine with it, because i was absolutely certain that i wrote it in, like, 2008-2012 or so.
20151201 18:12:26< zookeeper> but then i found my way to https://gna.org/patch/?813
20151201 18:17:52-!- louis94 [~~louis94@109.129.245.154] has joined #wesnoth-dev
20151201 18:17:52< shadowm> Ugh why do tables in MediaWiki have to be so hard to make.
20151201 18:18:58< zookeeper> well, looks like i still wrote the original code, but it was in 2007 O___o
20151201 18:23:23-!- Kwandulin [~Miranda@p200300760F6D9FC4FDA40FE1FA6EDA07.dip0.t-ipconnect.de] has joined #wesnoth-dev
20151201 18:25:26-!- ideuler [~textual@a89-153-16-141.cpe.netcabo.pt] has joined #wesnoth-dev
20151201 18:33:30-!- neverEnough_ [~nE@host97-236-dynamic.9-87-r.retail.telecomitalia.it] has joined #wesnoth-dev
20151201 18:33:37-!- neverEnough [~nE@host251-57-dynamic.8-87-r.retail.telecomitalia.it] has quit [Ping timeout: 276 seconds]
20151201 18:36:25-!- fendrin [~quassel@wesnoth/developer/fendrin] has quit [Read error: Connection reset by peer]
20151201 18:40:15-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20151201 18:43:29-!- TC01 [~quassel@london.acm.jhu.edu] has quit [Ping timeout: 245 seconds]
20151201 19:01:34-!- louis94 [~~louis94@109.129.245.154] has quit [Ping timeout: 260 seconds]
20151201 19:10:56< shadowm> Aginor, ancestral, aquileia, celticminstrel, Elvish_Hunter, gfgtdf, Ivanovic, Jetrel_bot, lipkab, loonycyborg, mattsc, Rhonda, Soliton, vultraz, zookeeper: I've sent an email to the devs ML regarding 1.13.2, 1.14, and GSoC 2016. All input is appreciated.
20151201 19:11:21< loonycyborg> are you going to be at fosdem yourself?
20151201 19:12:32< Rhonda> vincent_c: ^^
20151201 19:17:50-!- ideuler [~textual@a89-153-16-141.cpe.netcabo.pt] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
20151201 19:18:27< gfgtdf> shadowm: you know whether 1.12 currently still has the chat message appearing twice bug?
20151201 19:19:18< loonycyborg> shadowm: btw wasn't there some efforts to rewrite campaignd too?
20151201 19:19:34< loonycyborg> I think I should get to it myself once wesnothd is done
20151201 19:20:08< shadowm> gfgtdf: Uh I thought we decided 1.12 wasn't affected. I imagine the MP crowd would be furious otherwise.
20151201 19:21:11< shadowm> loonycyborg: Yeah, by mordante and some GSoC students, the asio_campaignd branch.
20151201 19:21:33< loonycyborg> iirc there was some thing called umcd
20151201 19:21:35< shadowm> That was never properly discussed so for all intents and purposes it's dead code.
20151201 19:21:55< shadowm> asio_umcd, yes.
20151201 19:22:23< gfgtdf> shadowm: a h right i mean 1.13 (current master)
20151201 19:28:10-!- Yaiyan [~Yaiyan@46.101.48.31] has quit [Ping timeout: 260 seconds]
20151201 19:29:10-!- Yaiyan [~Yaiyan@46.101.48.31] has joined #wesnoth-dev
20151201 19:29:20< shadowm> gfgtdf: Yes.
20151201 19:29:38< vultraz> Hm, no mention of fosdem?
20151201 19:33:41< zookeeper> shadowm, all good by me.
20151201 19:34:39< vultraz> anyway, I'm find with the rest
20151201 19:34:58< shadowm> Discussing FOSDEM is the responsibility of people who can go to FOSDEM. Ivanovic posted a thread back in September and nobody said a thing..
20151201 19:35:35< shadowm> Granted, that was punctually about hosting a presentation.
20151201 19:35:40-!- Ivanovic [~ivanovic@p579FB451.dip0.t-ipconnect.de] has quit [Changing host]
20151201 19:35:40-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20151201 19:36:14< shadowm> I'd even be tempted to say it's _your_ responsibility as the newly appointed Community Manager, vultraz. :p
20151201 19:36:45-!- Kwandulin_2 [~Miranda@p200300760F6D9FC4AC42EF8545A7E6C1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20151201 19:37:40< vultraz> I have no idea of the details or where to get started
20151201 19:37:42< vultraz> Who do I talk to?
20151201 19:38:11< shadowm> Ivanovic, AI0867, fabi are FOSDEM veterans who are still around.
20151201 19:38:25< shadowm> Well, maybe strike AI0867 out of that list.
20151201 19:38:54-!- Kwandulin [~Miranda@p200300760F6D9FC4FDA40FE1FA6EDA07.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
20151201 19:40:34< vultraz> What do we even DO there
20151201 19:43:05-!- aquileia [~chatzilla@HSI-KBW-078-042-007-104.hsi3.kabel-badenwuerttemberg.de] has joined #wesnoth-dev
20151201 19:46:17< Ivanovic> shadowm: i will not be around for that dev release, will be on vacation at that time without wesnoth access
20151201 19:46:51< shadowm> vultraz: Officially, on the years we've not hosted any presentations there people just go to socialize with fellow Wesnothians and OSS users and devs in general I believe.
20151201 19:47:02< Ivanovic> vultraz: for fosdem, have a look at the wesnoth-dev archive
20151201 19:47:09< Ivanovic> i wrote mails in the past years
20151201 19:47:15< Ivanovic> (okay, not this year, but the years before)
20151201 19:47:45< Ivanovic> shadowm: but we somehow organized this, at least a little
20151201 19:48:02< shadowm> The socializing part tends to result in ideas or code being produced, but it's just a happy side-effect.
20151201 19:48:23< Ivanovic> like organizing when/where to meet, organizing the hotel (like "do we want to do a group booking?", ...
20151201 19:48:26-!- aquileia [~chatzilla@HSI-KBW-078-042-007-104.hsi3.kabel-badenwuerttemberg.de] has quit [Ping timeout: 250 seconds]
20151201 19:49:35-!- ideuler [~textual@a89-153-16-141.cpe.netcabo.pt] has joined #wesnoth-dev
20151201 19:50:50< shadowm> Ivanovic: Re 1.13.2 that surely won't be a problem, I don't think anyone would even notice if translations disappeared for a single non-stable release. :p
20151201 19:51:00-!- aquileia [~chatzilla@HSI-KBW-078-042-007-104.hsi3.kabel-badenwuerttemberg.de] has joined #wesnoth-dev
20151201 19:51:04< Ivanovic> :)
20151201 19:51:32< shadowm> Do you plan on figuring out what to do about Pandora once we get SDL 2.0 support in master?
20151201 19:52:07< Ivanovic> i think there is just no more pandora port since the start of the 1.13.x series
20151201 19:52:16< celticminstrel> I don't have anything to say on GSoC, and no objections to 1.13.2 or 1.14
20151201 19:52:24< Ivanovic> because the bundling of a more recent boost and other are already, uhm, no fun IMO
20151201 19:53:11< shadowm> Are the OS' library versions frozen in ice forever or something?
20151201 19:53:21< Ivanovic> basically yes
20151201 19:53:36< Ivanovic> since all existing packages depend on the packages
20151201 19:53:57< shadowm> Even Debian tends to have a new stable series every two years with new libraries...
20151201 19:54:22< aquileia> iceiceice: data\test\scenarios\test_check_victory.cfg defines "KILL_", e.g. {KILL_ "2,3" "no"} - Take a guess what wmlgettext does...
20151201 19:55:05< aquileia> I guess nobody will mind if I rename that macro to KILL_SIDE
20151201 19:56:39< aquileia> Ivanovic: A shame you couldn't use the libraries bundled with that Pandora Code Blocks package
20151201 19:57:04< Ivanovic> aquileia: i might be able to somehow do it but feel to lazy to figure it out
20151201 19:59:20< shadowm> Anyway, if that's the case then that's a pity, and I don't feel it's worth our time and energy to figure out a solution that's compatible with our need to move forward.
20151201 20:00:23< Ivanovic> that is what i said, that i would like to be able to continue the 1.12.x stable series but that we should cut off with the dev series
20151201 20:23:02-!- louis94 [~~louis94@109.129.245.154] has joined #wesnoth-dev
20151201 20:37:24-!- louis94 [~~louis94@109.129.245.154] has quit [Ping timeout: 250 seconds]
20151201 20:41:31-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Read error: Connection reset by peer]
20151201 20:44:26< neverEnough_> fabi: i'm very glad i got invited, it would be my first time at this event. But i'm forced to refuse after a long home discussion, i'm about to lose my good old stable work in a month or so and economy isn't going to be a secondary issue :(
20151201 20:44:55-!- neverEnough_ is now known as neverEnough
20151201 20:45:07< shadowm> Ouch, that's bad.
20151201 20:45:25< neverEnough> yea, i'm employed there since 1999
20151201 20:45:40< neverEnough> but company is about closing the production line in my city
20151201 20:47:54< neverEnough> shadowm, got time for a priv chat?
20151201 20:48:06-!- Guest81714 is now known as Espreon
20151201 20:48:10< shadowm> neverEnough: Sure.
20151201 20:48:10-!- Espreon [~espreon@uruz.ai0867.net] has quit [Changing host]
20151201 20:48:10-!- Espreon [~espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20151201 21:04:42-!- ideuler [~textual@a89-153-16-141.cpe.netcabo.pt] has quit [Quit: Chakalaka.]
20151201 21:09:17-!- louis94 [~~louis94@109.129.245.154] has joined #wesnoth-dev
20151201 21:09:39-!- Kwandulin_2 [~Miranda@p200300760F6D9FC4AC42EF8545A7E6C1.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20151201 21:23:46-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 250 seconds]
20151201 21:26:14-!- molgrum [~molgrum@unaffiliated/molgrum] has quit [Ping timeout: 260 seconds]
20151201 21:26:34< mattsc> shadowm: no objections to any of that.  I likely won’t be able to help with the 1.13.2 release.  I’ll start traveling again on the weekend and will be mostly gone until right before Christmas, and then probably again right after.
20151201 21:26:57< shadowm> Will you ever stop traveling all the time? :p
20151201 21:27:12< mattsc> Also, if anything my schedule is going to be more crazy than it has been, so I won’t be able to take on any significant role in GSOC or the like
20151201 21:27:24< mattsc> and that ^ should answer your question  :)
20151201 21:27:44< shadowm> Hm, sad.
20151201 21:28:01< mattsc> Nah, it’s fun, just tiring.
20151201 21:28:08< shadowm> I mean, it's probably good for you (hopefully), it's just sad that we can't have you around.
20151201 21:28:35-!- molgrum [~molgrum@h-94-103.a230.priv.bahnhof.se] has joined #wesnoth-dev
20151201 21:28:35-!- molgrum [~molgrum@h-94-103.a230.priv.bahnhof.se] has quit [Changing host]
20151201 21:28:35-!- molgrum [~molgrum@unaffiliated/molgrum] has joined #wesnoth-dev
20151201 21:29:16< mattsc> I’ll still be happy to help out, but for example assigning me as a mentor to a student would not be fair to the student, etc.
20151201 21:43:02-!- shadowm_desktop [~ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 260 seconds]
20151201 21:50:07-!- iceiceice [~chris@static-151-204-19-2.pskn.east.verizon.net] has joined #wesnoth-dev
20151201 21:50:07-!- iceiceice [~chris@static-151-204-19-2.pskn.east.verizon.net] has quit [Changing host]
20151201 21:50:07-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20151201 21:50:23-!- ancestral [~ancestral@184-100-99-25.mpls.qwest.net] has joined #wesnoth-dev
20151201 22:07:49< shadowm> shadowm@reicore:~$ screen -DR
20151201 22:07:54< shadowm> [1]    12141 abort      screen -DR
20151201 22:08:02< shadowm> Okay then!
20151201 22:09:00< shadowm> Oh, it's because I'm actually in a screen session already. Oops. Probably should print something useful in that case instead of SIGABRTing users.
20151201 22:10:26< aquileia> shadowm: Hmm... since 2010 scenario-test.cfg has _"very long" and _"electrical" (range and weapon type, respectively) and they're well translated. Guess we'll keep them around?
20151201 22:11:43< shadowm> Well, I guess those are intentional.
20151201 22:12:18< iceiceice> aquileia: is there any reason to run wmlxgettext over the unit tests at all?
20151201 22:12:20< aquileia> Ok. Won't hurt for UMC purposes, in any case
20151201 22:12:43< aquileia> iceiceice: It runs over any and all .cfg files in data
20151201 22:12:53< iceiceice> i guess you could exclude data/test though
20151201 22:13:11< iceiceice> i mean i dont think theres anything in there that a translator should spend time translating
20151201 22:13:29< iceiceice> maybe if people want to make unit tests that test that gettext is working...
20151201 22:13:38< iceiceice> but otherwise it probably doesnt matter i guess
20151201 22:13:43< iceiceice> do whatever you want ofc
20151201 22:14:32< shadowm> aquileia: Also, did you see my email?
20151201 22:15:07< aquileia> shadowm: I'm aware you sent one, but as I chose digest mode, I'd have to check the archive
20151201 22:15:38< shadowm> I'm particularly curious about the future of the patch upgrader, since according to my email (not specifically mentioned there) 1.12.6 would be released on January 22.
20151201 22:16:09< shadowm> Eh, why would anyone need digest mode with wesnoth-dev? We get less than 1 email per _week_. :p
20151201 22:23:50-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20151201 22:24:25< aquileia> shadowm: Aside from a few minor problems I could fix before the 18th, the patch installer should be ready. However, aside from gfgtdf's comment I got no feedback on it. The auto updater for Wesnoth needs to be called from inside Wesnoth, so we'd still need a C++ interface for it
20151201 22:25:01< gfgtdf> we also need a server which we can ask whether our wesnoth version is up to date
20151201 22:26:16< aquileia> gfgtdf: As to your comment, I'm changing the start menu shortcuts as well - do you still see it as a problem if I update the install location with the new version number?
20151201 22:27:59< gfgtdf> it still say we shoudl not change the folder names we should, as soon as we have an automatic updater remove the version number from teh wesnoth folder name so that wesnoth exe is ineigher "wesnoth/wesnoth.exe"  or ""wesnoth 1.13/wesnoth.exe" but not have more minor versions.
20151201 22:28:13< aquileia> I understand it could break user-made shortcuts, but do we really want e.g. 1.12.6 to be installed in a dir containing 1.12.4 ?
20151201 22:29:29< gfgtdf> aquileia: i thought that automatic updater is 1.13 only?
20151201 22:30:01< aquileia> gfgtdf: That would indeed be preferable, but what about current installations? Should I remove the minor version number?
20151201 22:30:55< aquileia> gfgtdf: The manual patch installer will impact 1.12, so the version number dilemma still holds
20151201 22:34:13< gfgtdf> aquileia: hmm hard to say how to do it on 1.12.6
20151201 22:34:40< aquileia> shadowm: With "Windows upgrade packages" I assume you mean the manual version?
20151201 22:35:02< celticminstrel> You could store the version in the registry?
20151201 22:35:31< celticminstrel> If the problem is "how do we know which version they have".
20151201 22:35:43< celticminstrel> I'm not quite sure if I understand the trouble here.
20151201 22:36:55< aquileia> celticminstrel: We already do. The problem is that the default install path includes the minor version number, which changes when we apply a patch. The questionn is: Should the patch rename the install location or leave e.g. the patched 1.12.6 in the 1.12.4 dir?
20151201 22:37:45< celticminstrel> Ah. I don't think it's a good idea to have v1.12.6 stored in a directory with 1.12.4 in the name, but I'd actually suggest renaming it to just 1.12.
20151201 22:38:29< aquileia> That's what we intend to do, but the question remains whether the risk of breaking user-made shortcuts  is too high to rename it
20151201 22:38:43< celticminstrel> Ah.
20151201 22:39:21< celticminstrel> You could give users an option to not rename it, I suppose...
20151201 22:39:50< celticminstrel> Or put up a warning that you may need to update shortcuts.
20151201 22:40:36< aquileia> I'd like to keep user interaction minimal for the patcher - while NSIS has a llot of pre-translated strings for installers, it lacks them for patching
20151201 22:41:49< celticminstrel> I personally think that broken shortcuts are better than confusion arising from 1.12.6 being in a folder labelled 1.12.4.
20151201 22:42:10< celticminstrel> Though I don't really know how likely people are to have made their own shortcuts...
20151201 22:42:29< aquileia> gfgtdf, loonycyborg, shadowm: Your opinion would be appreciated as well
20151201 22:43:23< gfgtdf> i used to make a lot of wesnoth sortcuts, but i dont so soo maybe anymore
20151201 22:43:51< gfgtdf> also i dont really know how the windows start bar works (bew bar at the bottom of the screen)
20151201 22:43:58-!- ancestral [~ancestral@184-100-99-25.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20151201 22:43:59< gfgtdf> most people use that bar to start applications
20151201 22:44:18< gfgtdf> i dont know whther those items are actualyl shortcuts or something different
20151201 22:44:24< celticminstrel> They're shortcuts.
20151201 22:44:41< celticminstrel> But since the installer (presumably) knows about them, it would be able to update them automatically.
20151201 22:44:41< gfgtdf> they could also be 'sortcuts to stortcuts' or similar.
20151201 22:44:49< celticminstrel> They're shortcuts.
20151201 22:45:20< celticminstrel> Does Explorer even let you make a shortcut to a shortcut?
20151201 22:45:30< aquileia> celticminstrel: The installer doesn't create start bar shortcuts, so we can't redirect them
20151201 22:45:45< celticminstrel> It doesn't?
20151201 22:45:53< celticminstrel> That's kind of surprising?
20151201 22:46:05< aquileia> I rename all start menu shortcuts, but desktop & start bar aren't touched by us
20151201 22:46:26< celticminstrel> Ohh, I see what happened here.
20151201 22:46:33< gfgtdf> celticminstrel: well i can't change the taget of those bar items at least (this is the main reason why im not sure whether they are sortvuts)
20151201 22:46:36< celticminstrel> gfgtdf is referring to the quick launch buttons.
20151201 22:46:41< celticminstrel> I don't know how those work either.
20151201 22:46:53< celticminstrel> I don't remember the official name for them either.
20151201 22:47:20< aquileia> I mean, I could parse all these shortcuts as to whether they point to Wesnoth... but that's a little complicated, I fear
20151201 22:48:09< aquileia> celticminstrel: I guess they're just shortcuts in a special system-owned dir
20151201 22:48:30< celticminstrel> I think that's probably, though maybe not system-owned.
20151201 22:48:33< celticminstrel> ^probable
20151201 22:49:34< aquileia> AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar
20151201 22:49:52< aquileia> Yes, in a IE dir...
20151201 23:07:19-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20151201 23:08:05< shadowm> aquileia: Who would work on the C++ code for the auto-updater?
20151201 23:09:05< aquileia> gfgtdf considered it, but currently it's unassigned
20151201 23:09:09< shadowm> aquileia, gfgtdf: A simple http request to fetch a document with the new version number would suffice, we can figure that out eaily on the server side.
20151201 23:10:09< shadowm> Also, I'm primarily interested on the manual patch updates for 1.12.x until that code exists (can't evaluate the regression potential of code that doesn't exist yet...).
20151201 23:10:16< aquileia> shadowm: The updater needs: a) The current version number (trivial)  b) The new version number   c) The MD5 sum of the patch
20151201 23:11:01< shadowm> The document in question can even be WML, which is more or less appropriate for us since we use WML where others would use JSON or YAML.
20151201 23:11:37< shadowm> Well, the current version number isn't trivial when it comes to packages, since for example 1.12.4a identifies itself as 1.12.4.
20151201 23:11:42< aquileia> shadowm: PR #549, or more specifically https://github.com/aquileia/wesnoth/commit/a8dacb4db
20151201 23:12:01< shadowm> However, it shouldn't be a problem to require packages to carry the package version number in a file somewhere in the install dir.
20151201 23:12:18< aquileia> shadowm: We need only the numeric part (no a, no +dev)
20151201 23:12:39< shadowm> But then you can't upgrade 1.12.2 to 1.12.4a, for example.
20151201 23:12:49< shadowm> You'd get 1.12.4, which is broken and shouldn't be used.
20151201 23:14:14< shadowm> aquileia: So why hasn't the PR moved along since then?
20151201 23:15:04-!- Appleman1234 [~Appleman1@KD119104009174.au-net.ne.jp] has joined #wesnoth-dev
20151201 23:15:28< aquileia> shadowm: Well, currently 1.12.4a is handled by scons as 1.12.4 and loonycyborg renames it afterwards - if we want to change that, scons would have to know the suffix
20151201 23:15:55< shadowm> Re shortcuts, personally, the default install dir should be named after branches rather than punctual versions if it isn't already (e.g. "Battle for Wesnoth 1.12", not "Battle for Wesnoth 1.12.6").
20151201 23:17:09< shadowm> That only leaves cross-branch upgrades to worry about, and for those I think we just need to have the user accept responsibility for broken shortcuts or settings (which I assume the patcher would take care of carrying over to the new location?).
20151201 23:17:15< aquileia> shadowm: I have a few changes locally, but it mostly halted due to lack of feedback (I can't even compile with scons because our current recipe doesn't recognize MSVC, so testing is somewhat limited for me)
20151201 23:18:36< shadowm> I'm not familiarized with SCons to the level you need here, I'm afraid, and I've never used NSIS at all.
20151201 23:18:45< shadowm> Is there specific people you'd like to me to prod?
20151201 23:18:50< shadowm> Are.
20151201 23:18:59< aquileia> Yes, the patcher replaces the start menu shortcuts created by the installer
20151201 23:19:24< shadowm> I meant broken custom shortcuts in locations the installer can't know about.
20151201 23:20:19< shadowm> And settings = the game preferences, which are always hit-and-miss when it comes to cross-branch upgrades regardless of platform.
20151201 23:24:34< aquileia> shadowm: 1.12->1.13 currently isn't handled, but it should be relatively simple to add. I won't add it before the in-branch updates are tested thoroughly, though - too high a risk to break stuff.
20151201 23:25:11< shadowm> Okay, sure, I wouldn't worry too much about them anyway.
20151201 23:25:37< shadowm> It's somewhat questionable whether we actually _need_ to support them, in fact.
20151201 23:26:37< aquileia> The in-branch patcher can always replace itself with a newer version, if required, so there's no hurry to get it in either
20151201 23:26:49< celticminstrel> 1.12->1.14 seems more useful actually.
20151201 23:27:54< shadowm> celticminstrel: True, but the size of the download and the add-ons+preferences issue would probably make it more worthwhile to require people to download the whole thing.
20151201 23:28:15< celticminstrel> Yeah, probably.
20151201 23:28:49-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20151201 23:32:36-!- gfgtdf [~chatzilla@f054150059.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 42.0/20151029151421]]
20151201 23:38:04-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 245 seconds]
20151201 23:38:27-!- irker315 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20151201 23:38:27< irker315> wesnoth: aquileia wesnoth:master 4f7ad480f346 / / (5 files in 5 dirs): German translation update http://git.io/vRv57
20151201 23:38:27< irker315> wesnoth: aquileia wesnoth:master 53e61d7f6bf9 / po/ (wesnoth-help/de.po wesnoth/de.po): German translation: Fix quotes http://git.io/vRv55
20151201 23:38:27< irker315> wesnoth: aquileia wesnoth:master 5adfa80eed11 / / (64 files in 3 dirs): Unify khalifate unit plural forms http://git.io/vRv5d
20151201 23:38:28< irker315> wesnoth: aquileia wesnoth:master 798f0377386d / / (26 files in 26 dirs): Remove POTFILES.in http://git.io/vRv5F
20151201 23:38:29< irker315> wesnoth: aquileia wesnoth:master 88d4c15c87f3 / / (60 files in 3 dirs): Exclude test strings from gettext http://git.io/vRv5b
20151201 23:40:53-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Read error: Connection reset by peer]
20151201 23:45:21-!- fabi [~quassel@176.4.104.24] has joined #wesnoth-dev
20151201 23:45:21-!- fabi [~quassel@176.4.104.24] has quit [Changing host]
20151201 23:45:21-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20151201 23:58:40-!- aquileia [~chatzilla@HSI-KBW-078-042-007-104.hsi3.kabel-badenwuerttemberg.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 42.0/20151029151421]]
--- Log closed Wed Dec 02 00:00:26 2015