--- Log opened Tue Jul 11 00:00:31 2017
--- Day changed Tue Jul 11 2017
20170711 00:00:31-!- Polesaker is now known as Polsaker
20170711 00:00:55< celticminstrel> ...wait, since when could you deselect units with left click?
20170711 00:01:12< celticminstrel> Hasn't left click always been move?
20170711 00:03:40< Coffee_irc> celticminstrel: you can't as far as I see??
20170711 00:03:49< celticminstrel> Hm, so DeFender1031's suggestion would seem to suggest the use of a macro something like DEPRECATED_SINCE(version) would be good.
20170711 00:03:52< Coffee_irc> I remember that you could some time back (say 1.10)
20170711 00:04:01< celticminstrel> Coffee_irc: I dunno, ask Bonobo, he's the one who brought it up.
20170711 00:04:19< Coffee_irc> oh ok
20170711 00:04:27< Coffee_irc> just so you know Bonobo is my brother
20170711 00:05:27< Bonobo> Way back when, I used to use left click to deselect every time. It seems more inuitive to me
20170711 00:05:38< Coffee_irc> there was an issue with a "new movement interface" introduced by fendrin
20170711 00:05:48< Bonobo> but I've gotten used to it only being right click now
20170711 00:06:14< Coffee_irc> most of the code changes were kept
20170711 00:06:26< Coffee_irc> and the functionality reverted
20170711 00:06:35< Coffee_irc> this was a "side effect" of this
20170711 00:06:38< celticminstrel> If you left-click to deselect, how do you move units?
20170711 00:06:56< Coffee_irc> I think he means click once on a unit and then again to deselect
20170711 00:07:13< Coffee_irc> right click use to bring up the menu instead
20170711 00:07:20< celticminstrel> Ooh, clicking again on the unit to deselect... I suppose that does kinda make sense.
20170711 00:07:28< celticminstrel> Obviously that won't be a move.
20170711 00:07:47< celticminstrel> Seems like it'd be relatively simple to reimplement if someone wished to...
20170711 00:08:11< Coffee_irc> I did much of the work to make the input system work as users expected before 1.12.0 was released
20170711 00:08:24< Coffee_irc> and remember this being harder than it seemed to make work
20170711 00:09:32< celticminstrel> Maybe.
20170711 00:09:52< Coffee_irc> celticminstrel: you are very welcome to make this happen :)
20170711 00:10:14< celticminstrel> I'm in the middle of two other things ATM, but I may look into it. :)
20170711 00:10:45< Coffee_irc> all I want to do before 1.14.0 is make the animations work correctly
20170711 00:10:54< celticminstrel> I suspect that the cases vultraz_iOS is worried about (where backwards compatibility is impossible) would be very rare.
20170711 00:11:31< vultraz_iOS> What?
20170711 00:11:32< Coffee_irc> the difficulty with the new inputs is that you can remap the mouse keys
20170711 00:11:32-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 00:12:04< Coffee_irc> and to make things work on ipads and such might require extra effort
20170711 00:14:43< celticminstrel> Also, the deprecation function does not exist for all contexts.
20170711 00:14:56< celticminstrel> It exists for ActionWML and I think it exists for Lua.
20170711 00:15:23< celticminstrel> There is no C++ deprecation function AFAIK, and there's nothing for non-action WML either (a preprocessor feature is probably the best option there).
20170711 00:15:56< celticminstrel> The practice for C++ deprecation seems to be to just write to lg::wml_error, so wrapping that in a function should be simple to do.
20170711 00:16:11< celticminstrel> Modifying the preprocessor on the other hand... I have no idea how complicated that would be.
20170711 00:16:39-!- Polsaker is now known as Polsakerino
20170711 00:16:41< Coffee_irc> well, presumably next work be C+++
20170711 00:17:46< vultraz_iOS> celticminstrel: am I missing some context
20170711 00:17:53< celticminstrel> (IIRC the Lua deprecator is a function mutator - it takes a function as parameter and returns a new function that adds the deprecated message. I'm not sure if that will suffice for all cases.)
20170711 00:18:00< celticminstrel> vultraz_iOS: I'm reading up on today's log, FTR.
20170711 00:18:03< vultraz_iOS> You're talking about left clicks and now suddenly back to deprecation?
20170711 00:18:16< celticminstrel> So its responses to the stuff you were talking about with zookeeper and DeFender1031 
20170711 00:18:33< celticminstrel> The left clicks stuff was a response to Bonobo's offhand comment a little before that discussion.
20170711 00:18:59< Coffee_irc> I always assumed minstrel's usually travel around a bit
20170711 00:19:06< celticminstrel> ???
20170711 00:19:19< Coffee_irc> sorry, trying to be humorous
20170711 00:19:20< vultraz_iOS> What do you mean C++ deprecation function? You mean for deprecating ActionWML from the c++?
20170711 00:19:44< Coffee_irc> I'll get my hat before closing the door :P
20170711 00:19:47< celticminstrel> vultraz_iOS: I mean basically a C++ function to print a deprecation message or some such.
20170711 00:19:57< vultraz_iOS> I see
20170711 00:20:00< vultraz_iOS> Alright
20170711 00:20:07< celticminstrel> It wouldn't be for ActionWML, unless you were deprecating one of WML tags implemented in C++.
20170711 00:20:19< vultraz_iOS> What else would it be for?
20170711 00:20:25< vultraz_iOS> Besides Lua
20170711 00:20:34< celticminstrel> It could probably be used anywhere where you're working with a config.
20170711 00:20:53< vultraz_iOS> Well, only user-facing ones, of course
20170711 00:20:56< celticminstrel> It could also be used in the WFL parser if you were deprecating some feature of WFL.
20170711 00:21:07< celticminstrel> (Such as the fae / faiend keywords.)
20170711 00:21:10< celticminstrel> ^fai
20170711 00:21:20< vultraz_iOS> Ah yes
20170711 00:21:30< vultraz_iOS> We should deprecate those
20170711 00:21:35< vultraz_iOS> And .fai
20170711 00:21:41< celticminstrel> It could also be used in IPF parsing or any other parsing that occurs.
20170711 00:43:29< irker311> wesnoth: Celtic Minstrel wesnoth:master c2a53a7fb3fd / src/hotkey/command_executor.cpp: fixup 658bb10 https://github.com/wesnoth/wesnoth/commit/c2a53a7fb3fda9722b64c9234fb767fe6543e32d
20170711 01:03:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170711 01:12:32-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20170711 01:12:37-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20170711 01:13:20-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has joined #wesnoth-dev
20170711 01:32:08-!- travis-ci [~travis-ci@ec2-54-144-106-53.compute-1.amazonaws.com] has joined #wesnoth-dev
20170711 01:32:09< travis-ci> wesnoth/wesnoth#14422 (accelerated_rendering - 65c57fd : Charles Dang): The build has errored.
20170711 01:32:09< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/252213279
20170711 01:32:09-!- travis-ci [~travis-ci@ec2-54-144-106-53.compute-1.amazonaws.com] has left #wesnoth-dev []
20170711 01:53:28-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 01:53:47-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has joined #wesnoth-dev
20170711 02:12:16-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20170711 02:24:10-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 02:55:35-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has joined #wesnoth-dev
20170711 03:18:15-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20170711 03:21:01-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Read error: Connection reset by peer]
20170711 03:21:02-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 03:25:27< celticminstrel> Oh BTW, when I tried --render-image with 1.13.8, it did not work. Maybe someone else could try it to see if it's just me?
20170711 03:25:34< celticminstrel> IIRC it gave some SDL initialization error.
20170711 03:25:49< celticminstrel> (Despite working fine if I just launch the game normally.)
20170711 03:25:54-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20170711 03:34:28< celticminstrel> ...wait, can you define sounds for arbitrary status effects in [game_config][sounds][status]?
20170711 03:44:25-!- irker311 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170711 03:56:07-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has joined #wesnoth-dev
20170711 04:01:01< celticminstrel> Oh also, mattsc or ancestral need to update the Xcode project, I think?
20170711 04:01:13< celticminstrel> For PR 1806?
20170711 04:10:54< DeFender1031> celticminstrel, I assume you're on board with the majority of what vult, zookeeps, and I were discussing?
20170711 04:11:03< celticminstrel> Seems like it.
20170711 04:11:08-!- irker990 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170711 04:11:08< irker990> wesnoth: Celtic Minstrel wesnoth:master 00f01278c5c6 / changelog: Update changelog https://github.com/wesnoth/wesnoth/commit/00f01278c5c60cae560cfe9bf857c5c0b330d42f
20170711 04:13:03-!- Coffee_irc [~david@203.63.51.218] has quit [Quit: Konversation terminated!]
20170711 04:14:53-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.]
20170711 04:16:00-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170711 04:31:30-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 04:37:10-!- Kwandulin [~Miranda@p200300760F12B3A125FF4343E3D36C04.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170711 04:48:40-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has joined #wesnoth-dev
20170711 05:10:08-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170711 05:12:41-!- RatArmy_ [~ratarmy@om126200118098.15.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 05:42:39< irker990> wesnoth: Charles Dang wesnoth:accelerated_rendering 5fce25a954c4 / src/gui/core/canvas.cpp: GUI2/Canvas: don't skip drawing if canvas texture is null https://github.com/wesnoth/wesnoth/commit/5fce25a954c4063bc001e642d64c450b014355d0
20170711 06:17:53-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has joined #wesnoth-dev
20170711 06:20:46< DeFender1031> vultraz_iOS, zookeeper, anyone else interested in the compatibility policy, first draft done: https://wiki.wesnoth.org/CompatibilityStandards
20170711 06:21:35< DeFender1031> Let me know what you think.
20170711 06:50:08-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 06:50:25-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has joined #wesnoth-dev
20170711 06:59:57-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170711 07:00:04-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170711 07:01:24-!- Kwandulin [~Miranda@p200300760F12B3A125FF4343E3D36C04.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170711 07:02:37< vultraz_iOS> DeFender1031: we should date it
20170711 07:11:04-!- Duthlet [~Duthlet@ipservice-092-211-172-179.092.211.pools.vodafone-ip.de] has joined #wesnoth-dev
20170711 07:14:18-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 07:15:42-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has joined #wesnoth-dev
20170711 07:16:39< vultraz_iOS> wedge009: when you tested a_r, was it on Windows or Linux?
20170711 07:21:52-!- Duthlet [~Duthlet@ipservice-092-211-172-179.092.211.pools.vodafone-ip.de] has quit [Ping timeout: 260 seconds]
20170711 07:39:14-!- Duthlet [~Duthlet@ipservice-092-211-172-179.092.211.pools.vodafone-ip.de] has joined #wesnoth-dev
20170711 07:59:36< wedge009> vultraz_iOS: Windows 7
20170711 07:59:41< vultraz_iOS> wat
20170711 07:59:47< vultraz_iOS> are you sure?
20170711 07:59:57< wedge009> Very much so.
20170711 08:00:02< vultraz_iOS> well then
20170711 08:00:08< wedge009> Should I test again today?
20170711 08:00:12< vultraz_iOS> no
20170711 08:00:29< vultraz_iOS> I've figured out how to repro the problem
20170711 08:00:44< wedge009> That's a good start, right?
20170711 08:01:30< vultraz_iOS> But it's odd you got it on windows...
20170711 08:02:16< wedge009> You can reproduce it on Linux but not Windows?
20170711 08:02:18< vultraz_iOS> Basically, I think the problem has been that SDL has been creating the renderer with Direct3D for me - if I set the preferred renderer driver to opengl, I get the artifacts.
20170711 08:02:25< vultraz_iOS> D3D is windows
20170711 08:02:28< vultraz_iOS> :/
20170711 08:02:41< wedge009> Oh.
20170711 08:02:59< vultraz_iOS> So you tested on Windows, you should not get them
20170711 08:03:00< wedge009> Where do you set that, maybe I can experiment with it too.
20170711 08:03:01< vultraz_iOS> But you did
20170711 08:03:20< vultraz_iOS> And shadowm tested on Linux, where D3D is *not*, but did *not* get them :
20170711 08:03:22< vultraz_iOS> :|
20170711 08:03:56< wedge009> If I test D3D and OpenGL, then I can confirm if your theory applies to my case.
20170711 08:04:05< vultraz_iOS> alright
20170711 08:04:26< vultraz_iOS> add this line to src/sdl/window.cpp:37
20170711 08:04:30< vultraz_iOS> SDL_SetHint(SDL_HINT_RENDER_DRIVER, "opengl"); to OGL
20170711 08:04:38< vultraz_iOS> for*
20170711 08:04:46< vultraz_iOS> and SDL_SetHint(SDL_HINT_RENDER_DRIVER, "direct3d"); for D3D
20170711 08:04:52< vultraz_iOS> (don't have both at once, ofc)
20170711 08:04:55< wedge009> Okay, thanks.
20170711 08:05:00< wedge009> Yes, of course.
20170711 08:12:05-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170711 08:13:45< vultraz_iOS> wedge009: let me know what you find.
20170711 08:14:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170711 08:18:25-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 08:19:00< wedge009> Of course. Just trying to work out why MSVC doesn't like DEPRECATED()
20170711 08:21:51< wedge009> Looks like MSVC insists that there is a string provided as an argument. Seems to be compiling when I change it to DEPRECATED("fred").
20170711 08:22:53< zookeeper> celtic_minstrel, no, those are only for poison/slow/petrify.
20170711 08:25:10< DeFender1031> vultraz_iOS, that's all?
20170711 08:25:21< vultraz_iOS> i didn't read it
20170711 08:25:25< vultraz_iOS> I'm busy r/n sorry
20170711 08:25:26< DeFender1031> ...
20170711 08:25:30< DeFender1031> That's alright.
20170711 08:25:33< vultraz_iOS> I'll read it later
20170711 08:25:40< DeFender1031> Also, date it for what purpose?
20170711 08:27:01< vultraz_iOS> On the wiki, it's very common for old pages to be dismissed as out-of-date
20170711 08:27:04< vultraz_iOS> mostly since we never update them
20170711 08:27:29< vultraz_iOS> I think something like this should be reviewed yearly, or something, and dated appropriately, so we all know it's still relevant
20170711 08:27:39< DeFender1031> Ah. Fair.
20170711 08:27:49< vultraz_iOS> else you get stuff like //wiki.wesnoth.org/NotSoEasyCoding
20170711 08:27:54< vultraz_iOS> https://wiki.wesnoth.org/NotSoEasyCoding
20170711 08:27:57< vultraz_iOS> which is half out of date
20170711 08:28:36< DeFender1031> done.
20170711 08:52:13< wedge009> vultraz_iOS: This is going to confound you: I get the artefacts with D3D but *not* with OpenGL. :S There appears to be no difference due to GPU manufacturer. Help is still broken with both renderers, but I'm guessing you already know that.
20170711 08:52:38< vultraz_iOS> WHAT
20170711 08:52:48< vultraz_iOS> THE FUCK
20170711 08:53:06< wedge009> Need more testers, I think.
20170711 08:53:56< vultraz_iOS> what the actual hell is going on here
20170711 08:54:41< vultraz_iOS> I get the bug with OGL but not D3D. You get the bug with D3D and not OGL. Shadowm doesn't get the bug with OGL but he has no D3D. Everyone else seems to get the bug with OGL
20170711 08:54:45< vultraz_iOS> the fuck is happening here!
20170711 08:55:26< DeFender1031> I would imagine that it's not the bug you think it is.
20170711 08:55:27< wedge009> I wish I knew. ): I'm still using libsdl 2.05 of course.
20170711 08:55:40< vultraz_iOS> DeFender1031: then what could it be
20170711 08:55:52< wedge009> Vultraz, what's your GPU?
20170711 08:56:06< vultraz_iOS> GTX 950m
20170711 08:56:09< DeFender1031> vultraz_iOS, drivers? scaling? resolution? hardware? who knows?
20170711 08:58:34< vultraz_iOS> ;_;
20170711 08:59:19< DeFender1031> What's the actual bug that's occurring, anyway? I only picked up that it has something to do with graphics artifacts.
20170711 08:59:49< vultraz_iOS> yes
20170711 09:00:00< vultraz_iOS> texture bleed-through, render artifacts, etc
20170711 09:00:03-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has joined #wesnoth-dev
20170711 09:00:05< wedge009> Things don't appear to get 'unrendered'. eg in the story dialogue, character images and text just keep overlapping each other.
20170711 09:00:56< wedge009> I was running in windowed mode. Confirm full screen doesn't make a difference.
20170711 09:02:26< DeFender1031> so things aren't getting re-drawn when necessary?
20170711 09:04:07< wedge009> No.
20170711 09:04:08< vultraz_iOS> wedge009: 1772 is not fixed on master
20170711 09:04:14< wedge009> Ah, okay.
20170711 09:04:23< wedge009> I saw two commits, I thought one was on master.
20170711 09:04:44< vultraz_iOS> original commit and rebase commit + forcepush
20170711 09:06:46< DeFender1031> Sounds to me as though the code is perhaps not calling some function it's supposed to call or something, and then undefined behavior is leading to things sometimes clearing and sometimes not depending on tangential factors.
20170711 09:12:56< vultraz_iOS> but what!
20170711 09:17:51< vultraz_iOS> maybe it's something about texture size
20170711 09:18:38-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170711 09:23:22< DeFender1031> I don't know. I'm merely speculating based on my experience with software in general. I know pretty much nothing about rendering graphics.
20170711 09:25:39-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 09:32:52-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has joined #wesnoth-dev
20170711 09:44:32< zookeeper> from what i know, once you start working with hardware rendering, you're bound to bump into quite a lot of problems with specific hardware or drivers doing certain things wrong or at least differently from each other.
20170711 10:02:52-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 10:03:48-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has joined #wesnoth-dev
20170711 10:18:44-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 10:23:49-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has joined #wesnoth-dev
20170711 10:41:43-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 10:46:24-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has joined #wesnoth-dev
20170711 11:02:49-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 11:03:08-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has joined #wesnoth-dev
20170711 11:07:16-!- Kwandulin [~Miranda@p200300760F12B3A1741879FAFD6DDB9C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170711 11:21:48-!- irker990 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170711 11:42:26-!- gfgtdf [~chatzilla@x4e363a77.dyn.telefonica.de] has joined #wesnoth-dev
20170711 12:02:34-!- gfgtdf [~chatzilla@x4e363a77.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 54.0.1/20170628075643]]
20170711 12:05:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170711 12:22:25-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 248 seconds]
20170711 12:26:40-!- clavi [~clavi@v22017034422546657.goodsrv.de] has quit [Quit: ZNC - http://znc.in]
20170711 12:29:46-!- clavi [~clavi@v22017034422546657.goodsrv.de] has joined #wesnoth-dev
20170711 12:53:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170711 12:54:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170711 13:29:47-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20170711 13:34:47-!- RatArmy_ [~ratarmy@om126204172070.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 13:43:35-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20170711 13:45:50< DeFender1031> zookeeper, saw my write-up?
20170711 13:46:22-!- Kwandulin [~Miranda@p200300760F12B3A1741879FAFD6DDB9C.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170711 13:47:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170711 13:47:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170711 13:48:55< zookeeper> DeFender1031, yes
20170711 14:00:53< DeFender1031> Any thoughts?\
20170711 14:06:02< zookeeper> my main remaining concern is that it still seems to leave the door open for _needless_ wanton deprecation of things such as macros which have essentially zero maintenance cost attached to them, on the basis that "there's a different (and i'm calling it better) way of doing the same thing now". that's still something that will in practise create extra effort for content creators trying to 
20170711 14:06:02< zookeeper> stay up-to-date, even if said thing would actually be kept around in deprecated form indefinitely.
20170711 14:09:58< DeFender1031> That seems to be a matter of determining what "better" really means.
20170711 14:10:42< DeFender1031> In many of those cases, there's no objective reason why, say, a tag would be "better" than a macro for content creators who are maintaining their own content.
20170711 14:11:46< zookeeper> of course, it's hard to write in a clause saying "for deprecating something, you still need to have a reason beyond whimsical ideological or aesthetic preferences".
20170711 14:11:48< DeFender1031> I mean, core developers may want to stick to one or the other so as not to mix idioms, but devs shouldn't really dictate how content creators should operate stylistically.
20170711 14:12:37< DeFender1031> Well, we can formalize it a little more. We can add a deprecation level which is even lower than "deprecated indefinitely" which is, i dunno, "deprecated conventionally"?
20170711 14:12:39< zookeeper> yeah, i mean this all might sound pedantic otherwise, but i'm just bringing it up because for example vultraz specifically has said he wants to dictate how content creators should operate stylistically
20170711 14:13:56< DeFender1031> Essentially, "our stylistic approach says that you should be using this other thing instead of this, but both will continue to work perfectly". Then content creators can choose whether to conform or not.
20170711 14:15:04< zookeeper> "still exists, but not used in mainline content"?
20170711 14:15:07< DeFender1031> It may even be prudent to have different levels of debug mode such that a creator can limit the messages they see to whichever deprecation level most affects them.
20170711 14:16:25< DeFender1031> it's more than that though... sometimes it still exists, IS used in mainline content, but for convention reasons we'd want it to be transitioned to not be
20170711 14:17:42< DeFender1031> But whatever, we can worry about what to call it after agreeing on its existence. For that, we need vultraz to agree too. vultraz_iOS, does the above make sense?
20170711 14:17:44< zookeeper> right. i'm not sure if there's really a need to describe that kind of state anywhere, though.
20170711 14:17:54< vultraz_iOS> what?
20170711 14:17:56 * vultraz_iOS reads
20170711 14:18:20< DeFender1031> zookeeper, I think I still would, especially if it's going to have its own level of deprecation message.
20170711 14:19:11< vultraz_iOS> I disagree such a state should exist.
20170711 14:19:21< zookeeper> DeFender1031, if we'd actually have multiple levels of messages that the content author can conveniently toggle between, then sure we can add a "how much the developers like this thing" message to literally everything as far as i care :>
20170711 14:19:23< vultraz_iOS> Deprecated code should be expunged from mainline content.
20170711 14:19:35< vultraz_iOS> No matter what level.
20170711 14:20:21< DeFender1031> vultraz_iOS, you seem to have misunderstood then.
20170711 14:20:55< DeFender1031> Of course deprecated code should be expunged from mainline content, even that which has been deprecated for merely stylistic reasons.
20170711 14:21:14< vultraz_iOS> There's no way we can effectively draft a rule for dealing with macros
20170711 14:21:22< DeFender1031> Mainline content should reflect the current state of content-creation best-practice. No question.
20170711 14:22:00< vultraz_iOS> Say we have a macro (they have existed) they does a really complex thing. We introduce a cleaner, more efficient way to do it via Lua or a new tag. We obviously want to then deprecate that macro.
20170711 14:22:19< DeFender1031> However, what we're talking about is stuff which is merely stylistic, which we KNOW can continue to work forever if just left alone, and which therefore should still be free for use to content creators without having to worry that it might disappear at some point.
20170711 14:22:40< zookeeper> it's hardly obvious, if we can just update the macro to perform its task using that new cleaner and more efficient method
20170711 14:23:35< vultraz_iOS> for example, this:
20170711 14:23:36< vultraz_iOS> https://github.com/wesnoth/wesnoth/blob/master/data/core/macros/deprecated-utils.cfg#L109-L255
20170711 14:23:50< zookeeper> then we merely reach the point of "we wouldn't have included that macro in the first place if the new cleaner and more efficient method had always been available", but if it's there already then better to leave it in than go through the hassle of deprecation.
20170711 14:23:52< vultraz_iOS> we sure as *hell* don't want that around and in continued use indefinitely 
20170711 14:24:24< DeFender1031> vultraz_iOS, The point is, if the "deprecated style" can still, and will always be able to wrap perfectly to the "cleaner style", why should mainline developers care whether an add-on creator uses a deprecated style or not?
20170711 14:24:52< vultraz_iOS> thats a reasonable point
20170711 14:25:17< zookeeper> yeah, ON_SIGHTING is terrible, even for my tastes. i wonder if it could just be a sighted event wrapper.
20170711 14:26:18< vultraz_iOS> But I don't know what macros fit that category
20170711 14:26:22< zookeeper> it _is_ used a lot, because it actually works (i think), unlike sighted events traditionally have, and outwardly it's really simple. so if it can map cleanly to a sighted event, might as well keep it.
20170711 14:26:48< vultraz_iOS> zookeeper: see now you're doing that thing I hate :|
20170711 14:27:27< DeFender1031> Obviously macros which were ill-conceived and have wacky parameters to workaround things which are no longer relevant as such and have no remaining analog that they can wrap to simply should be deprecated. What we're talking about is things like {FOREACH} which is such a fundamental concept that code to allow it will always exist in some form and can be easily wrapped and kept around forever. Core should use the tag rather 
20170711 14:27:29< DeFender1031> than the macro, but there's no reason to force that on add-ons.
20170711 14:27:54< vultraz_iOS> FOREACH... I guess its reasonable to keep
20170711 14:28:21< vultraz_iOS> but most of the deprecated macros are for things that can be done in a simpler way now or are just unncessary
20170711 14:29:01< vultraz_iOS> for example, MAGENTA_IS_THE_TEAM_COLOR
20170711 14:29:10< vultraz_iOS> this was basically a hack we made everyone put in their code
20170711 14:29:14< vultraz_iOS> it's no longer necessary
20170711 14:29:29< vultraz_iOS> should we allow people to clutter up their unit type code with it?
20170711 14:29:34< vultraz_iOS> perhaps
20170711 14:29:53< DeFender1031> If it's not necessary, it can just print nothing.
20170711 14:29:54< vultraz_iOS> but should we say nothing about it not being necessary anymore and thereby allow people to continue to think it's necessary?
20170711 14:29:54< vultraz_iOS> no
20170711 14:30:45< vultraz_iOS> or something like ANIMATED_CAMPFIRE 
20170711 14:30:46< vultraz_iOS> this works
20170711 14:30:55< vultraz_iOS> but there are now terrains for that
20170711 14:31:24< DeFender1031> That's not a one-to-one evet.
20170711 14:31:26< DeFender1031> even*
20170711 14:31:39< DeFender1031> Can't use the terrain if there's already an overlay on the hex where you want the fire.
20170711 14:31:55< DeFender1031> Hence, there could be rare cases where you still need the macro form.
20170711 14:32:41< zookeeper> not even that rare
20170711 14:34:42< DeFender1031> But the point is, if there's no forseeable way that the existence of a particular macro can hinder development, no matter how ugly, then there's no reason not to leave it and allow content creators to continue to use it. (Again, if the code for it is complex and would require maintenence if the underlying tags are changed, then that IS a hindrance to development, but if it's just something that can be wrapped one-to-one to 
20170711 14:34:44< DeFender1031> something else, it becomes a matter of convention.)
20170711 14:35:06< zookeeper> now, as said, if the user can easily choose which severity of messages they want to see, then i don't have anything against using the lowest severity levels to liberally tag all sorts of things.
20170711 14:36:58< DeFender1031> zookeeper, then I guess I should begin to look into what functions and tags exist for printing a deprecation message and see how hard it would be to add such an option...
20170711 14:38:02< vultraz_iOS> God dammit
20170711 14:38:33< vultraz_iOS> I really can't support allowing crap like ON_SIGHTING around just because it could work
20170711 14:38:38-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has joined #wesnoth-dev
20170711 14:38:38< vultraz_iOS> It's *bad*
20170711 14:38:40< vultraz_iOS> I mean
20170711 14:38:41< DeFender1031> vultraz_iOS, chill.
20170711 14:38:55< vultraz_iOS> A lot of this stuff there's no reason to ever remove because they don't hinder development
20170711 14:38:58< DeFender1031> We're just trying to iron out the fine details here.
20170711 14:40:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170711 14:40:27< vultraz_iOS> like, yeah, it might be some work to change ON_SIGHTING to a sighted event but it will reduce WML footprint
20170711 14:40:30< vultraz_iOS> especially if used a lot
20170711 14:40:33< vultraz_iOS> reduce savefile size
20170711 14:40:37-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170711 14:40:37< vultraz_iOS> make their code clearer
20170711 14:40:52< vultraz_iOS> etc
20170711 14:41:10< DeFender1031> Let me try to make the point a different way.
20170711 14:41:48< DeFender1031> I think we all agree that if no content existed and wesnoth were just now being created from scratch, stuff like ON_SIGHTING wouldn't get created, correct?
20170711 14:42:04< zookeeper> certainly
20170711 14:42:08< DeFender1031> However, it DOES exist, and is potentially used in thousands of places.
20170711 14:43:17< zookeeper> just a bit under 100 matches in about 16 add-ons (1.12 only). so, a considerable amount.
20170711 14:43:43< DeFender1031> Therefore, there are two ways to deal with it: 1. Replace its internal code with simpler stuff that wraps to what now makes sense. 2. Force all content creators to replace that themselves in ALL PLACES where it appears in their code.
20170711 14:44:19< DeFender1031> Option 1 requires about 5 man-minutes to accomplish. Option 2 requires potentially hundreds.
20170711 14:44:58< DeFender1031> Keeping the macro around is more efficient from a workload perspective, despite how ugly it is, how much we hate it, and how it wouldn't be created if it were being done now.
20170711 14:46:12< DeFender1031> And zookeeper isn't even saying not to deprecate it.
20170711 14:46:37< DeFender1031> And we've already agreed that deprecated stuff should be kept around until it actively presents an obstacle to further development.
20170711 14:47:32< DeFender1031> The only thing zookeeper is saying is that creators need to have the ability to control what level of deprecation notice they see so as not to get bogged down with all the "we don't like how ugly this is" while trying to update the "this is really something that needs to be fixed".
20170711 14:48:05< DeFender1031> I mean, correct me if I'm wrong, zookeeper, but that was what I got out of your position.
20170711 14:49:24< zookeeper> yeah, more or less. i object to technically-needless deprecation only if it causes extra noise for authors updating their content if/when they can't tell what's a priority and what's just a stylistic suggestion.
20170711 14:50:47< vultraz_iOS> I do agree having levels of deprecation can be useful
20170711 14:51:11< vultraz_iOS> We have the [deprecated_message] tag and can probably add a level= key
20170711 14:51:30< zookeeper> if they can choose to only see "these things will/might actually break in the next stable release" and/or "pro tip: these things you might want to update for the sake of your own convenience", then i have no fundamental problem with deprecating a lot of stuff with the latter type of level.
20170711 14:52:05< zookeeper> now, i'm sure that it's relatively easy to internally add different levels and stuff, the main question is how do you create a convenient toggle for those in the UI?
20170711 14:52:34< DeFender1031> BTW, another point vultraz_iOS, removing things like ON_SIGHTED is a great way to ensure that ON_SIGHTED never dies. I know that sounds backwards, so let me explain. Most content creators will take the path of least resistance when their code breaks to get it working again. In the case of removed macros, that means recreating the macro in their own code. Unless you want add-ons filled with bad copies of deprecated and 
20170711 14:52:35< DeFender1031> removed macros, keeping them around indefinitely with a gentle nudge of "this is really not the best approach" will encourage most creators to, gradually, update their code to conform to the latest style.
20170711 14:54:30< vultraz_iOS> DeFender1031: good point
20170711 14:55:16-!- Kwandulin [~Miranda@p200300760F12B3A105A193358EAFB60F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170711 14:56:05-!- Duthlet [~Duthlet@ipservice-092-211-172-179.092.211.pools.vodafone-ip.de] has quit [Ping timeout: 255 seconds]
20170711 14:57:50< DeFender1031> Anyway, there seem to be only two question left, one logistical and the other technical:
20170711 14:58:50< DeFender1031> 1. Should the "deprecated indefinitely" be split into separate "possible to cause issues eventually" and "likely to remain viable forever" levels or remain just as "whatever, don't use this if you can help it because we may remove it"?
20170711 15:00:06< DeFender1031> 2. What's the best way to go about adding the ability to filter deprecation levels and then updating various deprecated stuff to ensure it uses that? (I'm considering looking into this one myself if I have time and if no one else gets there first.)
20170711 15:00:54< DeFender1031> I also anticipate that in the process of #2, we may end up deprecating certain deprecation warning functions as well, which is hilariously meta.
20170711 15:02:44-!- Duthlet [~Duthlet@ipservice-092-211-172-179.092.211.pools.vodafone-ip.de] has joined #wesnoth-dev
20170711 15:05:17< DeFender1031> vultraz_iOS, zookeeper, any input on question 1?
20170711 15:06:39< zookeeper> i think question 1 touches on whether this whole thing should be for deprecation messages only, or a more general in-game filtering system affecting other warnings too
20170711 15:09:21< zookeeper> well, i guess in either case i think it'd still be nice to separate between "we don't look favourably upon this anymore" and "we might actually need to remove this in the future, so beware"
20170711 15:09:41< zookeeper> because there might be a lot of the former cases
20170711 15:10:00< DeFender1031> zookeeper, I don't think this policy is going to work without the ability to filter warnings of different levels, so yeah, it has bearing on that.
20170711 15:10:16< DeFender1031> I mean, question 2 essentially makes it clear that I think it's a necessity.
20170711 15:14:13< DeFender1031> Btw, one other thing that hasn't been mentioned, which is that if something which is "deprecated indefinitely" can be shown to have been completely purged from all actively maintained add-ons (say all add-ons on current stable and one stable previous, with allowances for "the same add-on that used it in old stable no longer uses it in current stable" being disregarded), I think zookeeper, you'll also agree that there's no 
20170711 15:14:14< DeFender1031> reason not to remove it at that point?
20170711 15:14:41< zookeeper> oh sure.
20170711 15:15:15< DeFender1031> vultraz_iOS, I assume that satisfies you as well?
20170711 15:27:24-!- Greg-Boggs [~greg_bogg@c-76-115-139-154.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170711 15:28:30< vultraz_iOS> hm...
20170711 15:28:50< vultraz_iOS> I'm not entirely sure about point 1 but I think i'd be fine with either
20170711 15:29:36< vultraz_iOS> DeFender1031, zookeeper: I also assume purging support or significantly for a feature - say, ThemeWML - is acceptable immediately if only a few addons use it and we provide a drop-in replacement?
20170711 15:30:37< DeFender1031> I'm having trouble parsing "purging support or significantly for a feature"...
20170711 15:31:05< vultraz_iOS> oops
20170711 15:31:12< vultraz_iOS> significantly altering
20170711 15:31:45< zookeeper> yeah. i'm fine with something like removing ThemeWML entirely (assuming it actually gets us something nice in return, of course), because it's almost unused in UMC, hard to keep compatibility for, and removing it doesn't _break_ anything, just removes what's arguably an optional visual thing. it's really only used for minimalist cutscene themes or themes without a gold counter and so on, 
20170711 15:31:45< zookeeper> not by very many add-ons.
20170711 15:32:19< zookeeper> so for me that counts as one of those rare exceptions.
20170711 15:32:36< DeFender1031> I think I get the gist anyway, and even then, I'd say it depends on how heavily those add-ons use it, how difficult it'd be to create a temporary wrapper, etc. For something like ThemeWML which, IINM is set up in basically one place, I'd not have a problem with removing.
20170711 15:33:54< DeFender1031> I'd imagine that any update to how themes are controlled would be vastly different to the current ThemeWML and would be vastly difficult to wrap simply.
20170711 15:34:46< DeFender1031> As such, it probably qualifies as what will be a level 4 deprcation as soon as I update the doc to split level 1.
20170711 15:35:01< DeFender1031> Yeah, as zookeeper said, it's one of those extremely rare cases.
20170711 15:52:11-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20170711 15:57:32-!- Bonobo [~Bonobo@203.63.51.218] has quit [Ping timeout: 260 seconds]
20170711 16:15:03-!- RatArmy_ [~ratarmy@om126212240240.14.openmobile.ne.jp] has joined #wesnoth-dev
20170711 16:26:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170711 16:30:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds]
20170711 16:30:47-!- RatArmy_ [~ratarmy@om126212240240.14.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170711 16:31:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170711 16:44:17-!- Kwandulin [~Miranda@p200300760F12B3A105A193358EAFB60F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170711 17:05:11-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20170711 17:08:42< shadowm> vultraz_iOS: Just as a reminder, OpenGL implementations vary a lot between vendors on both platforms.
20170711 17:09:09< vultraz_iOS> So what can I do.
20170711 17:09:30< shadowm> Hire a QA lab to test everything for you and report back.
20170711 17:09:45< shadowm> Learn about platform differences and fix them as they crop up.
20170711 17:09:52< shadowm> That's what a professional studio would do.
20170711 17:10:21< shadowm> I've been warning you all about this for at least half a decade.
20170711 17:33:15-!- Kwandulin [~Miranda@p200300760F12B3A1D90A79C5EC13B4AF.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170711 18:33:38-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170711 18:51:27-!- Duthlet [~Duthlet@ipservice-092-211-172-179.092.211.pools.vodafone-ip.de] has quit [Quit: Lost terminal]
20170711 18:54:56-!- Kwandulin [~Miranda@p200300760F12B3A1D90A79C5EC13B4AF.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170711 18:59:16< DeFender1031> shadowm, is there some kind of crash-course on opengl platform differences that you know of and could point vultraz_iOS to?
20170711 19:01:11< JyrkiVesterinen> AFAIK, there isn't one. Developers just run into that kind of differences while developing games (or other software).
20170711 19:02:12< DeFender1031> That... sucks.
20170711 19:02:53< JyrkiVesterinen> One case that I recall was when I was experimenting a way to reduce the memory usage of Angry Birds. My experiment involved a shader where I used way more uniforms ( https://www.khronos.org/opengl/wiki/Uniform_(GLSL) ) than OpenGL ES guaranteed to be available. (I didn't know that the limit was so low.)
20170711 19:03:19< DeFender1031> A quick google search brought me to https://www.khronos.org/opengl/wiki/Common_Mistakes
20170711 19:03:27< JyrkiVesterinen> In one test device, it worked perfectly. Another refused to compile the shader, which was also perfectly reasonable behavior.
20170711 19:03:35< DeFender1031> JyrkiVesterinen, you worked on angry birds?!
20170711 19:04:01< JyrkiVesterinen> But the third test device was the worst of all. It compiled the shader, but then rendered in a completely wrong way.
20170711 19:04:27< JyrkiVesterinen> That kind of stuff one can only find by experimenting.
20170711 19:05:15< JyrkiVesterinen> DeFender1031: Yes. I have worked on that game (but only on its updates which came out in 2013 and 2014, not the original version).
20170711 19:05:35< DeFender1031> Nice! You're famous! :P
20170711 19:07:29< JyrkiVesterinen> Yep. I have retained a screenshot of game credits as a memento. :)
20170711 19:08:19< DeFender1031> anyway, vultraz_iOS, a quick google search brought me to https://www.opengl.org/archives/resources/features/KilgardTechniques/oglpitfall/ and https://www.khronos.org/opengl/wiki/Common_Mistakes both of which may be somewhat helpful in confronting open gl weirdness. (I did a quick skim and it seems to have some words that are similar to the issue you were talking about...)
20170711 19:21:54-!- RatArmy_ [~ratarmy@om126200117064.15.openmobile.ne.jp] has joined #wesnoth-dev
20170711 19:34:04< shadowm> DeFender1031: Nope. I don't know anything about this other than basic information from other devs' experiences, as well as watching industry trends.
20170711 19:35:26< shadowm> One common criticism about NVIDIA, for example, is that their drivers ship with a myriad of workarounds for broken applications (most of them clients that pay NVIDIA for technical consulting, priority support, and other resources).
20170711 19:36:05< shadowm> An obvious corollary is that software that is only tested and developed on NVIDIA's platforms will not work the same with AMD or Intel's.
20170711 19:37:59< shadowm> The other obvious corollary is that NVIDIA's OpenGL implementation is not conforming.
20170711 19:39:54< shadowm> *non-conformant
20170711 19:41:19< shadowm> This has been the source of many a headache for software (not just game) devs, especially if they can't afford NVIDIA's consulting services for financial reasons or otherwise.
20170711 19:42:24< shadowm> tl;dr monopolies are bad.
20170711 19:43:23< JyrkiVesterinen> I have to say that the mobile landscape with a bunch of GPU manufacturers with so many different kinds of breakage isn't very good either.
20170711 19:43:44< JyrkiVesterinen> Like that driver that miscompiles shaders which attempt to use too many uniforms.
20170711 20:02:43-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170711 20:02:50-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170711 20:05:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170711 20:05:34-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: Going to bed]
20170711 20:05:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170711 20:07:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170711 20:08:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170711 20:16:00-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170711 21:03:50-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20170711 21:30:10-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Quit: I'll be back!]
20170711 21:42:37-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 276 seconds]
20170711 21:42:56-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20170711 21:53:27-!- horrowind [~Thunderbi@p2003008E6C0B2654964452FFFE0220ED.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170711 21:58:12-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170711 21:58:50-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170711 21:58:57-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170711 22:02:00-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20170711 22:08:08-!- horrowind [~Thunderbi@p2003008E6C0B2654964452FFFE0220ED.dip0.t-ipconnect.de] has quit [Quit: horrowind]
20170711 22:13:17-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170711 22:15:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170711 22:26:00-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170711 22:26:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170711 22:27:00-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170711 22:27:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170711 22:33:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170711 22:33:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170711 22:35:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170711 22:36:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170711 22:42:09-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170711 23:01:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170711 23:12:15-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170711 23:21:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170711 23:21:58-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 255 seconds]
20170711 23:26:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
--- Log closed Wed Jul 12 00:00:35 2017