--- Log opened Thu Oct 06 00:00:06 2016
--- Day changed Thu Oct 06 2016
20161006 00:00:06< vultraz> :/
20161006 00:02:29< tad_> Revert that patch for all those warnings?
20161006 00:03:42< matthiaskrgr> well, the commits can be pushed into a branch and worked on until the game no longer crashes and tests pass 
20161006 00:03:54< matthiaskrgr> *shrug*
20161006 00:05:50< vultraz> heh
20161006 00:05:56< vultraz> of course this doesn't work
20161006 00:08:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161006 00:08:06< vultraz> let's see why it crashes
20161006 00:08:36< vultraz> ...in get_best_size
20161006 00:08:54< vultraz> makes sense, actually
20161006 00:08:56< vultraz> i guess
20161006 00:12:33-!- irker413 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161006 00:15:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161006 00:16:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161006 00:30:56-!- gfgtdf_ [~chatzilla@x4e32b082.dyn.telefonica.de] has joined #wesnoth-dev
20161006 00:32:47 * tad_ is testing rolling back those fixes for all those warnings.
20161006 00:33:12< tad_> And, yes,that means I finally got a good build.
20161006 00:34:35-!- gfgtdf [~chatzilla@x4e32b082.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20161006 00:34:36-!- gfgtdf_ is now known as gfgtdf
20161006 00:39:39-!- atarocch [~atarocch@ip-145-193.sn3.clouditalia.com] has quit [Remote host closed the connection]
20161006 00:50:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161006 00:51:45-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161006 00:52:03-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161006 00:55:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20161006 01:10:19< vultraz> ill have to ask mordante about this
20161006 01:10:23< vultraz> perhaps im using instance wrong
20161006 01:14:59< Aginor> hey tad_ 
20161006 01:15:17< Aginor> how is your network/cross platform compilation effort going?
20161006 01:16:04< Aginor> tad_: I'd be interested to know what network protocol/file systems you use and what the slowdown is
20161006 01:16:38-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161006 01:17:10< tad_> Aginor, Well, I finally convinced VS 2015 that it could compile. And I've already verified that the Windows For Linux subsystem can share the library.
20161006 01:17:53< tad_> Aginor, The slowdown is probably memory starvation coupled with a slightly older laptop.
20161006 01:19:38< Aginor> tad_: so you're not relying on a network share of some form?
20161006 01:20:26< tad_> Aginor, And I'll probably just export the repo through the shared partition over to my VM Linux. To ship it over to the other systems, I'll probably just use WINS, yes.
20161006 01:20:26-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161006 01:21:10-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161006 01:23:35-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161006 01:26:40-!- gfgtdf_ [~chatzilla@x4e3691d5.dyn.telefonica.de] has joined #wesnoth-dev
20161006 01:28:19-!- gfgtdf [~chatzilla@x4e32b082.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20161006 01:28:19-!- gfgtdf_ is now known as gfgtdf
20161006 01:40:06< Aginor> tad_: ok, thanks
20161006 01:40:10< Aginor> :)
20161006 01:48:41-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 01:50:58-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161006 01:51:35-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 252 seconds]
20161006 01:54:15-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20161006 01:54:31-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 01:59:34< tad_> vultraz, matthiaskrgr I reverted that large commit to fix warnings and still have the crash loading a core.
20161006 02:01:09-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161006 02:04:05-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 272 seconds]
20161006 02:05:12-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161006 02:16:55-!- tad_ [~Gregory@173.217.65.103] has quit [Quit: Leaving]
20161006 02:17:36-!- tad_ [~tadcarluc@173.217.65.103] has joined #wesnoth-dev
20161006 02:19:42-!- irker831 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161006 02:19:42< irker831> wesnoth: mattsc wesnoth:master 75817d3ba430 / data/ai/lua/ai_helper.lua: ai_helper: new function robust_move_and_attack() https://github.com/wesnoth/wesnoth/commit/75817d3ba4303a6fa4cd476b87d126fd3fd293e2
20161006 02:21:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 02:22:02< irker831> wesnoth: Wedge009 wesnoth:master f10f4e8a282d / projectfiles/VC12/ (WindowsTimeout.vcxproj liblua.vcxproj wesnoth.vcxproj wesnothd.vcxproj): Basic tidying of VC project files. https://github.com/wesnoth/wesnoth/commit/f10f4e8a282d4718d1f0c07f9ff5c487e2fc8756
20161006 02:22:58< wedge009> I was trying to find why tad_ is having problems, but didn't find anything substantially different between my set-up for VC14 and what's in master for VC12.
20161006 02:23:19< wedge009> But tidied some minor things while I was looking.
20161006 02:24:16< tad_> wedge009, Most likely because I'm rushing it
20161006 02:25:06< tad_> wedge009, If you're able to update the VC project, add a preprocessing define for _WIN32_WINNT=0x0501 so Boost know we're not targeting Windows 3.1
20161006 02:26:04< tad_> I see a few messages about that. Boost presumes it, defining it makes the messages go away.
20161006 02:26:20-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20161006 02:26:59< wedge009> Oh yeah, I've seen that too. Thought it might have come from processing the standard Windows headers, actually.
20161006 02:27:28< wedge009> I think Wesnoth is still WinXP as minimum, right?
20161006 02:27:39< Aginor> yes
20161006 02:27:49< Aginor> although I don't know if anyone has a test machine for it
20161006 02:28:05< tad_> Well, that define tells Boost XP-or-later
20161006 02:28:05< wedge009> Heh, I could dig up an old machine, but I'd rather not.
20161006 02:28:56< tad_> I could fire up an XP VM but would rather not. I do have VMs from XP to 8.1 .. need to put together a Windows 10 clean install VM.
20161006 02:29:01< irker831> wesnoth: mattsc wesnoth:master e65a460342f1 / data/ai/lua/ai_helper.lua: ai_helper: add E_FAILED_TELEPORT to list of non-fatal move errors https://github.com/wesnoth/wesnoth/commit/e65a460342f15d99e58295e4a06d5c35bf1cd97d
20161006 02:29:36< wedge009> Looks like Boost is assuming WinXP anyway. But I'll add it shortly.
20161006 02:30:22< tad_> Yes, it assumes XP or later. The define simply supresses the messages while building
20161006 02:31:16< irker831> wesnoth: mattsc wesnoth:master 8ad055e77f6f / data/ai/lua/ai_helper.lua: ai_helper: remove double spaces after punctuation https://github.com/wesnoth/wesnoth/commit/8ad055e77f6ff1fbe32c46ceea385c810d56d6ae
20161006 02:50:59-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20161006 02:56:18-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161006 02:57:00< mattsc> celticminstrel: I am not going to reply to that in the github repository
20161006 02:58:50-!- gfgtdf_ [~chatzilla@x4e3691d5.dyn.telefonica.de] has joined #wesnoth-dev
20161006 03:01:11< mattsc> celticminstrel: oh, you mean specifically the ai table?  Sorry, misunderstanding here ...
20161006 03:01:33-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has joined #wesnoth-dev
20161006 03:01:34< travis-ci> wesnoth/wesnoth#11331 (master - 75817d3 : mattsc): The build has errored.
20161006 03:01:34< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165412202
20161006 03:01:34-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has left #wesnoth-dev []
20161006 03:01:50-!- gfgtdf [~chatzilla@x4e3691d5.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
20161006 03:01:59-!- gfgtdf_ is now known as gfgtdf
20161006 03:02:43< mattsc> celticminstrel: because it’s in a helper library and it is not always guaranteed that the ai table is available as a global variable?  I don’t know.
20161006 03:02:50< mattsc> I’ll be back in ~15 min.
20161006 03:04:50-!- gfgtdf [~chatzilla@x4e3691d5.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]
20161006 03:11:22< irker831> wesnoth: Wedge009 wesnoth:master 0fe3e0ab13e2 / / (3 files in 2 dirs): Define _WIN32_WINNT for MSVC compilation (resolve warnings from boost). https://github.com/wesnoth/wesnoth/commit/0fe3e0ab13e27558582ee09dc08fa3b3820f0a91
20161006 03:18:52< vultraz> idea, I have
20161006 03:18:58< vultraz> instead of instance
20161006 03:18:58< mattsc> celticminstrel: yeah, I just tested it in my test scenario and at least there is does not work unless I pass the ai table
20161006 03:19:02< vultraz> why not a grid
20161006 03:19:06< vultraz> with a spacer
20161006 03:19:10< vultraz> then we swap grid
20161006 03:19:28< vultraz> eh, no
20161006 03:19:30< vultraz> that wouldn't work
20161006 03:19:34< vultraz> this is the definition
20161006 03:19:37< vultraz> ...or would it?
20161006 03:19:42< vultraz> the listbox does something similar
20161006 03:19:48< vultraz> dammit, where is mordante when you need him
20161006 03:24:59-!- shikadibot [~shikadi@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: manual override]
20161006 03:25:00-!- shadowm [~ignacio@wesnoth/developer/shadowm] has quit []
20161006 03:25:50-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161006 03:36:50< celticminstrel> mattsc: You're calling it from non-AI code?
20161006 03:37:20< mattsc> celticminstrel: for testing, yes
20161006 03:37:21-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has joined #wesnoth-dev
20161006 03:37:22< travis-ci> wesnoth/wesnoth#11332 (master - f10f4e8 : Wedge009): The build has errored.
20161006 03:37:22< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165412401
20161006 03:37:22-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has left #wesnoth-dev []
20161006 03:37:50< celticminstrel> I suppose this way would also make it possible to pass a "fake" AI table.
20161006 03:38:02< mattsc> true
20161006 03:41:23< celticminstrel> Why bother removing double spaces...
20161006 04:01:37-!- tad_ [~tadcarluc@173.217.65.103] has quit [Ping timeout: 256 seconds]
20161006 04:02:45-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 256 seconds]
20161006 04:06:11-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has joined #wesnoth-dev
20161006 04:06:12< travis-ci> wesnoth/wesnoth#11333 (master - e65a460 : mattsc): The build has errored.
20161006 04:06:12< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165413235
20161006 04:06:12-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has left #wesnoth-dev []
20161006 04:06:14-!- tad_ [~tadcarluc@173.217.65.103] has joined #wesnoth-dev
20161006 04:20:34< vultraz> celticminstrel: anything on the flg dialog?
20161006 04:21:01-!- vultraz changed the topic of #wesnoth-dev to: 1.13.6 planned for Friday, October 14th | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20161006 04:21:07< tad_> It seems to me that my system would run much faster if I'd get around to telling my anti-virus scanner to skip the ISO images and Virtual Machines ...
20161006 04:21:29< celticminstrel> Sorry.
20161006 04:21:52< celticminstrel> I've been sick lately so I haven't gotten any programming done.
20161006 04:22:28< vultraz> ah, why didn't you say so :(
20161006 04:23:11< vultraz> go get better, don't worry about programming 
20161006 04:24:58< celticminstrel> I just don't generally share such things.
20161006 04:34:30< irker831> wesnoth: Jyrki Vesterinen wesnoth:master 0fba36a9d099 / src/config_cache.cpp: Fix config_cache::read_cache() https://github.com/wesnoth/wesnoth/commit/0fba36a9d099344ab03d92b4f3142b9cb3464b49
20161006 04:37:44-!- JyrkiVesterinen [~JyrkiVest@87-100-240-212.bb.dnainternet.fi] has joined #wesnoth-dev
20161006 04:37:58< JyrkiVesterinen> 20161005 21:57:52< gfgtdf> JyrkiVesterinen: did you test that is all still works? whne you change codes like 'config *active = get_node(cfg_, namespace_);' to 'active = get_node(cfg_, namespace_);' you do change behaviour if 'active' is used outside that scope.
20161006 04:38:08< JyrkiVesterinen> Well, I did some cursory testing.
20161006 04:38:58< JyrkiVesterinen> Regarding the example you gave, I indeed changed the semantics of persist_file_context::clear_var() by accident. I'll fix it.
20161006 04:40:32< vultraz> any chance someone else could maybe look at why this dialog doesn't show: https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/multiplayer/mp_join_game.cpp#L220
20161006 04:42:09-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has joined #wesnoth-dev
20161006 04:42:09< travis-ci> wesnoth/wesnoth#11334 (master - 8ad055e : mattsc): The build has errored.
20161006 04:42:09< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165413404
20161006 04:42:09-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has left #wesnoth-dev []
20161006 04:43:40< irker831> wesnoth: Jyrki Vesterinen wesnoth:master 39b0b28d8bee / src/persist_context.cpp: Revert accidental semantical change in persist_file_context::clear_var https://github.com/wesnoth/wesnoth/commit/39b0b28d8bee88842bfc74a9156d4564f8a3efa9
20161006 04:47:44-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161006 04:49:54< irker831> wesnoth: Charles Dang wesnoth:master 1aa180b9e43f / src/gui/dialogs/multiplayer/mp_join_game.cpp: MP Join Game: include cleanup https://github.com/wesnoth/wesnoth/commit/1aa180b9e43f4960af29548c157f4aac34605c1c
20161006 04:54:43< irker831> wesnoth: Charles Dang wesnoth:master bdebafda4aed / src/gui/dialogs/multiplayer/mp_staging.cpp: Mp Staging: include cleanup https://github.com/wesnoth/wesnoth/commit/bdebafda4aed3ab6ffbf99363fc6cea8846dc867
20161006 04:55:38-!- JyrkiVesterinen [~JyrkiVest@87-100-240-212.bb.dnainternet.fi] has quit [Quit: .]
20161006 04:57:17< vultraz> tad_: would you approve a change making the Load Game dialog fixed size
20161006 04:58:46-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161006 05:02:22-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161006 05:02:41-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161006 05:04:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161006 05:06:22< tad_> Of course. The requirement would simply be that it fit on the smallest size window (800x600) and re-center as you change the window size.
20161006 05:07:55-!- travis-ci [~travis-ci@ec2-54-205-166-21.compute-1.amazonaws.com] has joined #wesnoth-dev
20161006 05:07:56< travis-ci> wesnoth/wesnoth#11335 (master - 0fe3e0a : Wedge009): The build has errored.
20161006 05:07:56< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165417217
20161006 05:07:56-!- travis-ci [~travis-ci@ec2-54-205-166-21.compute-1.amazonaws.com] has left #wesnoth-dev []
20161006 05:08:58-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161006 05:09:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20161006 05:11:13< irker831> wesnoth: Charles Dang wesnoth:master 0ead900f8f5f / src/gui/dialogs/ (helper.hpp preferences_dialog.cpp): Removed make_dialog_callback in favor of a lambda https://github.com/wesnoth/wesnoth/commit/0ead900f8f5fa443949577c4d6c08aa9583d04f6
20161006 05:11:59-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161006 05:25:39< irker831> wesnoth: Charles Dang wesnoth:master 6deb70f961e5 / src/gui/dialogs/lobby/lobby.cpp: MP Lobby: log + single include cleanup https://github.com/wesnoth/wesnoth/commit/6deb70f961e5a6e115bcd762765c0cd3cad538ad
20161006 05:27:45-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has joined #wesnoth-dev
20161006 05:27:46< travis-ci> wesnoth/wesnoth#11336 (master - 0fba36a : Jyrki Vesterinen): The build passed.
20161006 05:27:46< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165425762
20161006 05:27:46-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has left #wesnoth-dev []
20161006 05:53:19-!- travis-ci [~travis-ci@ec2-54-205-166-21.compute-1.amazonaws.com] has joined #wesnoth-dev
20161006 05:53:20< travis-ci> wesnoth/wesnoth#11337 (master - 39b0b28 : Jyrki Vesterinen): The build passed.
20161006 05:53:20< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165426574
20161006 05:53:20-!- travis-ci [~travis-ci@ec2-54-205-166-21.compute-1.amazonaws.com] has left #wesnoth-dev []
20161006 06:01:03< tad_> so I'm trying to find the crash and I'm up to zookeeper's change to show bitmaps .. I fire up expecting a crash but no, a game comes up and every hex has a number and I can't see how to turn it off
20161006 06:04:33< vultraz> tad_: top right, foruth button from right
20161006 06:04:41< vultraz> fourth
20161006 06:05:18< matthiaskrgr> draw number of bitmaps?
20161006 06:06:18< vultraz> something in the editor to deal with the terrain graphics system
20161006 06:06:20< tad_> Top right is a minimap. 4th button is "Toggle Minimap Unit Drawing"
20161006 06:06:39< tad_> No effect
20161006 06:07:03< vultraz> tad_: no, top right in the top bar\
20161006 06:07:08< vultraz> the one with the hex and the #
20161006 06:07:28-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161006 06:07:42-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161006 06:08:05< tad_> Only two: "Menu" and "Actions" and the normal display of stats. 4th from right is number of units on my side.
20161006 06:09:56-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20161006 06:13:24< tad_> Seems Zookeeper set the option to be always-on and no way to disable it.
20161006 06:19:52< tad_> Switched to Map Editor to try the button. No effect.
20161006 06:21:26-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has joined #wesnoth-dev
20161006 06:21:27< travis-ci> wesnoth/wesnoth#11338 (master - 1aa180b : Charles Dang): The build passed.
20161006 06:21:27< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165427180
20161006 06:21:27-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has left #wesnoth-dev []
20161006 06:24:16< vultraz> I....oh
20161006 06:24:21< vultraz> tad_: are you in game
20161006 06:24:34< tad_> Yes.
20161006 06:24:44< vultraz> ahhhhh
20161006 06:24:50< vultraz> i thought you were in editor
20161006 06:25:03< tad_> Not ATM but I can be again
20161006 06:25:12< vultraz> and you're right, now the button doesn't do anything
20161006 06:25:15< vultraz> tsk tsk, zookeeper
20161006 06:25:53< tad_> Tried the editor and the button is there but no-workie
20161006 06:27:52< vultraz> yeah
20161006 06:29:06-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161006 06:35:54< irker831> wesnoth: Charles Dang wesnoth:master 879b6a9efaac / src/display.cpp: Fixed terrain bitmap counts always showing in-game https://github.com/wesnoth/wesnoth/commit/879b6a9efaac9323afd3ccbe87dd82f40651e06a
20161006 06:36:15< vultraz> tad_: ^ another victim of the missing member initilizier
20161006 06:36:22< vultraz> initializer
20161006 06:36:49< tad_> "the"???
20161006 06:37:23< tad_> Oh .. yep .. default init wasn't what it needed, I see.
20161006 06:37:31< vultraz> s/the/a
20161006 06:38:28< vultraz> the show/hide state isn't preserved when entering the editor still, but that's a different issue
20161006 06:38:51< tad_> I will get to it later. git wanted to gc and refused so it's by-hand and it's taking a long time.
20161006 06:39:34< tad_> And the wife wants me to get some sleep. (A highly over-rated activity, but she insists)
20161006 06:41:21< irker831> wesnoth: Charles Dang wesnoth:master 4821b97949c5 / src/editor/controller/editor_controller.cpp: Fixed terrain bitmap count setting not being preserved through editor sessions https://github.com/wesnoth/wesnoth/commit/4821b97949c5cef5528349d0476f029f234b9d9d
20161006 06:41:22< vultraz> aannnnddd fixed
20161006 06:41:46< tad_> We're closing in on 1 million changes .. if case you're interested: 942477
20161006 06:42:05< tad_> Funny how initializing your variables does that.
20161006 06:43:23< vultraz> there should be a compiler warning about missing member initializers
20161006 06:43:45< tad_> We talkd about that. I s'pose I should write it up and send it off.
20161006 06:47:19-!- celticminstrel is now known as celmin|sleep
20161006 06:48:17< wedge009> JyrkiVesterinen: I had a go at extending what you did previously - https://github.com/wesnoth/wesnoth/pull/812
20161006 06:49:09-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has joined #wesnoth-dev
20161006 06:49:10< travis-ci> wesnoth/wesnoth#11339 (master - bdebafd : Charles Dang): The build passed.
20161006 06:49:10< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165427601
20161006 06:49:10-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has left #wesnoth-dev []
20161006 06:52:59-!- atarocch [~atarocch@ip-145-193.sn3.clouditalia.com] has joined #wesnoth-dev
20161006 06:53:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161006 06:57:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20161006 07:01:03< JyrkiVesterinen> wedge009: thanks, looks good. :)
20161006 07:01:29< JyrkiVesterinen> I slightly dislike that you prefix the names of the child config variables with the name of the parent config, though.
20161006 07:01:58< wedge009> Like I said, I have no idea of what should be the convention. Feel free to suggest better names.
20161006 07:02:09< wedge009> Surely anything is better than 'c' though.
20161006 07:02:23< JyrkiVesterinen> Such as having data_message, data_whisper, data_room_join, data_room_part and data_room_query_response instead of message, whisper, room_join, room_part and room_query_response.
20161006 07:03:10< JyrkiVesterinen> I think we don't even *have* a variable naming convention. Developers can do what they want as long as it's not outright insane.
20161006 07:03:34< tad_> Bah. Just name them all 'i' with a numeric uniquifier when needed. Gotta keep future maintainers on their toes!
20161006 07:04:30-!- atarocch [~atarocch@ip-145-193.sn3.clouditalia.com] has quit [Remote host closed the connection]
20161006 07:05:02< JyrkiVesterinen> I don't even dislike one-character names as long as they are used sparingly enough. I like to name loop variables that way.
20161006 07:05:34< wedge009> tad_: Reminds me of http://ioccc.org/!
20161006 07:05:58< tad_> And who says FORTRAN is dead? Using i, j and k for loop control vairables comes to us from common practice in FORTRAN.
20161006 07:06:14< JyrkiVesterinen> Like what I did here: https://github.com/wesnoth/wesnoth/commit/af733360a81405505673687b935a637ddedae861#diff-3fb455a3a4de1643cd04e57473b1b564L1666
20161006 07:06:15< wedge009> Loop variables on occasion I don't mind, but I think one-character names aren't helpful unless it really is a trivial variable. But if it's that trivial, why is it necessary?
20161006 07:07:11< tad_> https://www.se.rit.edu/~tabeec/RIT_441/Resources_files/How%20To%20Write%20Unmaintainable%20Code.pdf
20161006 07:07:53< vultraz> blah, I need ancestral now and he's not around
20161006 07:09:06 * tad_ wonders how many warnings Boost would generate if missing member initializers were flagged as a warning.
20161006 07:09:26 * tad_ shudders.
20161006 07:12:04< vultraz> I bet this will turn out to be in fact difficult 
20161006 07:13:36-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has joined #wesnoth-dev
20161006 07:13:37< travis-ci> wesnoth/wesnoth#11340 (master - 0ead900 : Charles Dang): The build passed.
20161006 07:13:37< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165429330
20161006 07:13:37-!- travis-ci [~travis-ci@ec2-174-129-95-170.compute-1.amazonaws.com] has left #wesnoth-dev []
20161006 07:13:40< tad_> What's that?
20161006 07:14:13< vultraz> I want to use the lighter variations of the Lato font for higher text sizes
20161006 07:14:19< vultraz> or at least, specify a way to do so
20161006 07:15:47< vultraz> sadly, this is not web design where such things are simple!
20161006 07:17:10< tad_> You have in mind switching to something like Hairline when it gets over a certain size?
20161006 07:17:51< vultraz> well, I was thinking Light
20161006 07:17:56< vultraz> hairline is wayyyy too hairline :P
20161006 07:19:00< vultraz> perhaps I want pango_font_description_set_weight
20161006 07:19:22< tad_> Sounds like it's in the ballpark.
20161006 07:21:04< vultraz> ah, I think I see how to do this
20161006 07:22:44< tad_> I would expect the layout to shift slightly when you make the shift. Should not be an issue for Wesnoth. In the web it would cause a noticable jump when it re-flows.
20161006 07:23:38< vultraz> mfw ttext uses SDL_TTF macro constants :|
20161006 07:25:00< vultraz> and WHY does the GUI2 canvas use these constants too
20161006 07:25:03< vultraz> mutter mutter mutter
20161006 07:26:15< vultraz> so gui2::decode_font_style returns SDL_TTF macro constants..
20161006 07:26:37< vultraz> but AFAIK there's no ttf thin constant..
20161006 07:27:01< vultraz> there is not
20161006 07:27:23< vultraz> this should be returning PangoWeight
20161006 07:29:41< vultraz> and this should be an alias enum
20161006 07:29:43< vultraz> ughh
20161006 07:30:20< vultraz> why is there even TTF compatibility when ttext isn't in gui1!
20161006 07:33:50< vultraz> definitely gonna do some refactoring here
20161006 07:37:37-!- atarocch [~atarocch@host-93-101-8-142.lottomatica.net] has joined #wesnoth-dev
20161006 07:38:55< wedge009> JyrkiVesterinen: Got rid of the prefixes. Not sure what to do about celmin's comments, though.
20161006 07:40:02< tad_> wedge009, Carefully think about what the intentions and expectations are.
20161006 07:40:13< tad_> Which is WHY there's a warning issued.
20161006 07:40:18-!- tad_ [~tadcarluc@173.217.65.103] has quit [Quit: Leaving]
20161006 07:40:38< wedge009> Of course, but it's hard to understand some of the cases where this is happening
20161006 07:41:58< wedge009> I sort of understand the example you gave, but I tend not to write stuff that way in the first place, making assignments in conditional statements.
20161006 07:42:56-!- travis-ci [~travis-ci@ec2-54-146-40-21.compute-1.amazonaws.com] has joined #wesnoth-dev
20161006 07:42:57< travis-ci> wesnoth/wesnoth#11341 (master - 6deb70f : Charles Dang): The build passed.
20161006 07:42:57< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/165430735
20161006 07:42:57-!- travis-ci [~travis-ci@ec2-54-146-40-21.compute-1.amazonaws.com] has left #wesnoth-dev []
20161006 07:43:53< vultraz> hmmm
20161006 07:43:58< vultraz> ok, the flag is set proper
20161006 07:44:03< vultraz> but the text isn't being light!
20161006 07:47:41-!- boucman_work [~boucman@159.195.204.77.rev.sfr.net] has joined #wesnoth-dev
20161006 07:47:55< Aginor> hmm
20161006 07:47:55< vultraz> :/
20161006 07:48:18< vultraz> I really have no way to confirm whether it's loading the font variant or not
20161006 07:48:35< Aginor> I'm having a very close look at utils.cpp:blit_surface, there's some rather odd alpha blending going on there that I'm not recognising
20161006 07:48:57< vultraz> oh?
20161006 07:49:00< vultraz> well that's not good
20161006 07:49:11< Aginor> I'm not an expert though :D
20161006 07:52:02< Aginor> hmm
20161006 07:52:03< Aginor> ok
20161006 07:52:45< Aginor> it's looking like premultiplied alpha
20161006 07:52:50< Aginor> so nevermind me :D
20161006 07:54:14< Aginor> or not quite
20161006 07:58:00< vultraz> so the weight here is properly set
20161006 07:58:08< vultraz> but the font doesn't reflect that :/
20161006 08:01:17< vultraz> don't really understand why
20161006 08:07:27< vultraz> where is the font actually loaded
20161006 08:08:31< vultraz> grrrrrrrrrrrr
20161006 08:17:22< vultraz> don't understand this code
20161006 08:18:34< vultraz> google has absolutely nothing
20161006 08:23:36< vultraz> guess I will again ask mordante..
20161006 08:26:48< vultraz> or
20161006 08:26:50< vultraz> hmmm
20161006 08:26:51< vultraz> maybe..
20161006 08:27:13< vultraz> let's do some refactoring.
20161006 08:31:08-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161006 08:32:19-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20161006 08:32:49< vultraz> hm
20161006 08:32:54< vultraz> style is different from weight
20161006 08:36:05< Aginor> hmm
20161006 08:36:14< Aginor> chatting doesn't work on the mutliplayer dialog
20161006 08:36:21< vultraz> Aginor: hm?
20161006 08:36:41< Aginor> join the lobby and try to talk to me
20161006 08:38:47< Aginor> can you see my typing
20161006 08:38:51< Aginor> or your own typing?
20161006 08:39:00< vultraz> Aginor: yes
20161006 08:39:04< Aginor> hmm
20161006 08:39:14< Aginor> maybe this is a false alarm
20161006 08:39:18 * Aginor facepalms
20161006 08:39:20< matthiaskrgr> works here
20161006 08:39:50< Aginor> I may have experimented quite a bit with some of the rendering code in GUI2 around alpha, trying to remove blit_surface
20161006 08:40:03< Aginor> I may have gotten something wrong and turned it transparent
20161006 08:40:09< Aginor> sorry
20161006 08:40:34< vultraz> ah, you're working on that!
20161006 08:41:04< Aginor> more like idly poking
20161006 08:41:24< vultraz> i did a lot of that
20161006 08:41:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161006 08:42:07< vultraz> i failed, though
20161006 08:42:15< vultraz> maybe you can succeed where I failed
20161006 08:42:32< zookeeper> ...whoops. my hex bitmap counting thingy is active outside the editor.
20161006 08:42:34 * zookeeper panics
20161006 08:42:46< vultraz> zookeeper: fixed
20161006 08:42:49< vultraz> already
20161006 08:42:53< zookeeper> oh?
20161006 08:43:09< Aginor> vultraz: I'm just working through the math, trying to figure out the exact goings on
20161006 08:43:51< zookeeper> vultraz, ah yes, i guess i missed that bit
20161006 08:44:11< zookeeper> great, thanks
20161006 08:44:29< vultraz> np
20161006 08:46:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20161006 08:58:08< vultraz> ok, giving up on this font thing temporatily
20161006 08:59:45< vultraz> was gonna make a different change anyway..
20161006 09:08:44< zookeeper> (6) How fun do you think the scenario is? (1-10)
20161006 09:08:44< zookeeper> 0. This game is a disaster in 'fun'. It is as fun as stabbing oneself in the eye. 
20161006 09:08:57< zookeeper> sounds like honest feedback :P
20161006 09:09:20< irker831> wesnoth: Charles Dang wesnoth:master f42b9f2099b7 / src/text.cpp: Slightly bumped text line spacing https://github.com/wesnoth/wesnoth/commit/f42b9f2099b7727f349fec9c96d10f2ba9601c2e
20161006 09:10:11< vultraz> ^ subtle, yet effective.
20161006 09:12:58< vultraz> the Aethermaw description in MP Create now takes up approximately 1 extra line of space in spacing
20161006 09:19:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 09:23:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20161006 09:23:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 09:24:04< Aginor> hmmm
20161006 09:24:20< Aginor> so I've reverted all my changes and I still cannot see my own chat messages in multiplayer
20161006 09:26:06< Aginor> oh well
20161006 09:26:39-!- benladin [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has joined #wesnoth-dev
20161006 09:38:31-!- benladin [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has quit [Quit: Page closed]
20161006 09:38:48< celmin|sleep> I wouldn't be surprsed if that makes the 800x600 resolution MP Create quite a bit worse.
20161006 09:38:57< celmin|sleep> ^surprised
20161006 09:58:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20161006 09:58:49-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 10:01:17-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161006 10:03:28-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20161006 10:03:59-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 10:05:41-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20161006 10:05:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 10:14:22< vultraz> Aginor: odd...
20161006 10:14:33< vultraz> Aginor: did you make any headway on the issue, though?
20161006 10:22:34< irker831> wesnoth: Charles Dang wesnoth:master 87f1f0567759 / data/gui/ (4 files in 3 dirs): MP Staging, MP Join Game: made side numbers really big https://github.com/wesnoth/wesnoth/commit/87f1f0567759a2fdd14dc491967ea277cb5f3165
20161006 10:23:44< vultraz> largest text in wesnoth
20161006 10:24:48< celmin|sleep> There are soooo many label definitions, it's kinda a bit ridiculous.
20161006 10:25:32< vultraz> indeed
20161006 10:25:37< vultraz> I should just make size a key
20161006 10:25:53< celmin|sleep> Well, that would be a bit ridiculous in a totally different way.
20161006 10:26:15< vultraz> how so?
20161006 10:26:38< celmin|sleep> This way there's some clear idea of "standard font sizes".
20161006 10:26:56< vultraz> true..
20161006 10:29:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161006 10:31:38-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20161006 10:34:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 272 seconds]
20161006 10:59:51-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161006 12:17:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161006 12:22:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20161006 12:54:05-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20161006 13:03:43-!- Bonobo [~Bonobo@2001:44b8:254:3200:e484:ecdc:5f1e:4455] has quit [Quit: Leaving]
20161006 13:05:10-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161006 13:05:50-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161006 13:07:50-!- Appleman1234_ [~Appleman1@KD106154006238.au-net.ne.jp] has joined #wesnoth-dev
20161006 13:10:17-!- Appleman1234 [~Appleman1@KD106154002212.au-net.ne.jp] has quit [Ping timeout: 252 seconds]
20161006 13:22:42-!- irker831 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161006 13:26:48-!- Appleman1234_ is now known as Appleman1234
20161006 13:36:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161006 14:07:05-!- atarocch_ [~atarocch@host-93-101-8-142.lottomatica.net] has joined #wesnoth-dev
20161006 14:09:25-!- atarocch [~atarocch@host-93-101-8-142.lottomatica.net] has quit [Ping timeout: 265 seconds]
20161006 14:11:34-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161006 14:11:42-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161006 14:15:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 14:41:48-!- Nobun [~nobun@host109-36-dynamic.48-82-r.retail.telecomitalia.it] has joined #wesnoth-dev
20161006 14:45:05< zookeeper> mattsc, you have any standard simple trick you use to verify that a given AI is actually being used and doing something? because now the assassins are acting up and first i want to make sure that i haven't actually messed up the AI code in the scenario somehow.
20161006 14:46:14< mattsc> zookeeper: if you want to see that the CA is included, just use ;inspect
20161006 14:46:51< mattsc> for seeing whether the code is being called, I include std_print(lines) in strategic places, or wesnoth.message()
20161006 14:47:33< mattsc> Since it’s Lua, you don’t need to restart from the beginning of the scenario, only reload the current save.
20161006 14:50:22< zookeeper> hmhm
20161006 14:51:57< zookeeper> right, i put some messages in ca_assassin_move:execution and ca_assassin_move:evaluation and they don't show up so i guess i got a problem with the scenario
20161006 14:54:07< zookeeper> you didn't happen to have a drop-in example of how exactly it should be wired in now?
20161006 14:54:44< mattsc> zookeeper: it’s a Micro AI: https://wiki.wesnoth.org/Micro_AIs#Assassin_Squad_Micro_AI_.28ai_type.3Dassassin.29
20161006 14:55:05< mattsc> Example at the end of that section.
20161006 14:55:20< zookeeper> perfect, thanks
20161006 15:00:11-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20161006 15:00:49-!- tad_ [~Gregory@173.217.65.103] has joined #wesnoth-dev
20161006 15:03:48< tad_> When compiling Wesnoth using Visual Studio 2105 Community I see the message "No FIFODIR set" coming from a #pragma in src/server/server.cpp. What is it and why does it choose a probably-wrong substitute which, if used, will cause problems on my wife's computer due to what drive D: is for her?
20161006 15:06:57< Soliton> it's not used on windows.
20161006 15:07:55< tad_> OK. I'll get with Wedge when he appears, then, and discuss having the message eliminated.
20161006 15:09:09< tad_> Oh, and, yes, it is used on all build targets, including Windows.
20161006 15:11:48< Soliton> if you define usage by seeing that pragma messgae, sure. but you already knew that before asking.
20161006 15:12:07< tad_> I define usage as building a string and using that string elsewhere.
20161006 15:14:00< zookeeper> Soliton, btw, feel free to merge https://github.com/wesnoth/wesnoth/pull/809 if it looks good
20161006 15:16:24-!- Kwandulin [~Miranda@p200300760F2C71FE58425FD047FEAAAC.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161006 15:25:42-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161006 15:33:39-!- Kwandulin [~Miranda@p200300760F2C71FE58425FD047FEAAAC.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161006 15:38:31-!- irker022 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161006 15:38:31< irker022> wesnoth: Lari Nieminen wesnoth:master 5ede2f851921 / src/ (log.cpp server/ban.cpp): Clarify the display of the remaining ban duration to banned users https://github.com/wesnoth/wesnoth/commit/5ede2f851921cc8d63b69f11f3ec9ce17d26c319
20161006 15:38:31< irker022> wesnoth: soliton- wesnoth:master 8d1e14980fa7 / src/ (log.cpp server/ban.cpp): Merge pull request #809 from ln-zookeeper/clarify_ban_duration https://github.com/wesnoth/wesnoth/commit/8d1e14980fa7d23bd37535c28ae41296f64ce608
20161006 15:39:39< Soliton> tad_: ok, my definition was that the fifo is actually being used.
20161006 15:40:45 * tad_ nods.
20161006 15:43:42< tad_> Defaulting it to "D:/socket" would be unfortunate if ever actually used on my wife's computer since D: is her 4T image library, mounted as D: .. I know .. the things we do for marital harmony.
20161006 15:50:43-!- Nobun [~nobun@host109-36-dynamic.48-82-r.retail.telecomitalia.it] has quit [Remote host closed the connection]
20161006 15:53:09< bumbadadabum> tad_: D: would be my face when I saw a 4T image library
20161006 15:54:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161006 15:54:35< tad_> I know. The question is which is more distressing, they she needs 4T for her images, or that she insists it be mounted as drive D:
20161006 15:54:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 15:55:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20161006 15:59:10< tad_> It's an Linux box running on an ARM. I could ssh in and port over a file compare script to eliminate duplicates but for two problems, she won't trust it and claim she can't find anything, and I estimate it would take about 4 months to run.
20161006 15:59:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 15:59:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20161006 16:00:32-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 16:00:37-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20161006 16:03:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 16:04:12-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20161006 16:04:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 16:06:41-!- boucman_work [~boucman@159.195.204.77.rev.sfr.net] has quit [Remote host closed the connection]
20161006 16:09:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161006 16:09:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161006 16:10:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161006 16:13:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161006 16:14:25-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 16:15:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20161006 16:16:13< mattsc> Umm…  If I use a [filter_vision]side=1 visible=‘yes’ one a hidden unit (e.g. an Elvish Ranger on forest) of side one, is that supposed to match or not ?
20161006 16:16:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 16:16:31< mattsc> zookeeper et al.: ^
20161006 16:16:50< DeFender1031> i would think not...
20161006 16:17:04< DeFender1031> according to wiki docs, not.
20161006 16:17:07< mattsc> Why not?  I cannot see units of my own side?
20161006 16:17:17< DeFender1031> [filter_vision]: this tests whether or not the unit is currently visible
20161006 16:17:19< DeFender1031> visible: yes or no, default yes. When "yes", this matches units that are not obscured by fog or shroud, and that are not hiding (via the [hides] ability). When "no", this matches units that are obscured by fog or shroud, or that are hiding.
20161006 16:17:34< DeFender1031> oh wait
20161006 16:17:45< DeFender1031> you mean units on the same side as vision is filtering for
20161006 16:17:51< mattsc> yes
20161006 16:17:58< DeFender1031> (allies too, i'd think)
20161006 16:18:32< zookeeper> mattsc, uh, good question
20161006 16:18:34< DeFender1031> then in that case, i'd say yes.
20161006 16:18:48< mattsc> DeFender1031: only the allies share vision
20161006 16:18:55< zookeeper> i'm inclined to say that yes it should match, because the unit is visible to side 1
20161006 16:18:57-!- atarocch_ [~atarocch@host-93-101-8-142.lottomatica.net] has quit [Ping timeout: 265 seconds]
20161006 16:19:06< DeFender1031> on the other hand, that's not actually a meaningful case, because a side should always be able to see all of its own units.
20161006 16:19:08< mattsc> I would have expected that this should match, but it does not
20161006 16:19:20< mattsc> at least not in Lua, but that should be the same in WML, I’d assume
20161006 16:20:04< mattsc> DeFender1031: so that should be reflected by the result of the vision filter
20161006 16:20:41< mattsc> From the wiki: “If there is *at least one* matching side which can see the unit / location (accounting for fog / hiding / shroud) then the filter matches”
20161006 16:20:41< zookeeper> sounds worth fixing, rare as it might be to encounter that
20161006 16:21:02< DeFender1031> yeah
20161006 16:21:18< DeFender1031> so it should match if the side can see through the hiding.
20161006 16:22:07< mattsc> DeFender1031: it is important for some AI code.  For example, if I want to know whether a hex is unoccupied by a visible unit, I’d rather just test whether there is a visible unit there, than having to distinguish between own and enemy units.
20161006 16:22:22< mattsc> Esp. if the behavior for own units is counter-intuitive
20161006 16:23:09< mattsc> Okay, so it sounds like this is a bug.  I’ll look into it.  Sigh.
20161006 16:23:40< DeFender1031> mattsc, ah, good point
20161006 16:30:20-!- tad_ [~Gregory@173.217.65.103] has quit [Quit: Leaving]
20161006 16:31:22-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161006 16:33:14-!- JyrkiVesterinen [~JyrkiVest@87-92-37-21.bb.dnainternet.fi] has joined #wesnoth-dev
20161006 16:43:28-!- tad_ [~tadcarluc@173.217.65.103] has joined #wesnoth-dev
20161006 16:57:59-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20161006 17:00:19-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161006 17:03:46< irker022> wesnoth: Wedge009 wesnoth:master 2e9a9fc2c9a6 / src/ (11 files in 7 dirs): Avoid hidden variable warnings produced in MSVC compilation. https://github.com/wesnoth/wesnoth/commit/2e9a9fc2c9a6f70f0d2e3dad576a1ed32f118c6b
20161006 17:03:48< irker022> wesnoth: Jyrki Vesterinen wesnoth:master ea5728c19a05 / src/ (11 files in 7 dirs): Merge pull request #812 from Wedge009/refactor_msvc_warnings https://github.com/wesnoth/wesnoth/commit/ea5728c19a059160d1b18e0b30eb85ecea5f0ae4
20161006 17:09:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20161006 17:11:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 17:12:57-!- atarocch_ [~atarocch@host49-185-dynamic.49-82-r.retail.telecomitalia.it] has joined #wesnoth-dev
20161006 17:20:41-!- Kwandulin [~Miranda@p200300760F2C71FEE9DFD16BDB543EF2.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161006 17:41:30-!- gfgtdf [~chatzilla@x4e3691d5.dyn.telefonica.de] has joined #wesnoth-dev
20161006 17:58:35-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has quit [Quit: leaving]
20161006 17:59:29-!- atarocch_ [~atarocch@host49-185-dynamic.49-82-r.retail.telecomitalia.it] has quit [Ping timeout: 265 seconds]
20161006 18:07:37-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161006 18:11:54-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 264 seconds]
20161006 18:11:54-!- wedge010 is now known as wedge009
20161006 18:21:05< mattsc> Btw, as far as vision is concerned, wesnoth.find_path and wesnoth.find_reach behave as I would expect them.  They include visibility of hidden units by allied sides.
20161006 18:22:47-!- mjs-de [~mjs-de@x4e301729.dyn.telefonica.de] has joined #wesnoth-dev
20161006 18:38:26< vultraz> mattsc: could you remove any of these that are no longer valid? https://wiki.wesnoth.org/EasyCoding#Improvements_to_AI
20161006 18:40:08< gfgtdf> vultraz: i wonder why you removed the gui1 section? was the ingame chat/command box ported to gui2 ?
20161006 18:40:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161006 18:40:19< gfgtdf> vultraz: on that wiki page i mean
20161006 18:40:38< vultraz> gfgtdf: no, not yet, but we don't want anyone spending time on GUI1 when we're working to get rid of it
20161006 18:41:04< vultraz> plus celmin has a WIP implementation of a floating GUI2 chatbox for in-game
20161006 18:51:41< mattsc> vultraz: I just did that a few days ago, so what’s left there is all valid
20161006 18:51:50< vultraz> mattsc: ahh :D
20161006 18:52:02< vultraz> perhaps I should add an Updated On: line
20161006 18:52:31< vultraz> (yes, ik one can see history, but it's good for people to be able to see how recent things are)
20161006 18:53:54< mattsc> vultraz: there would have to be one line like that per section then
20161006 18:54:00< vultraz> yeah
20161006 18:54:08< vultraz> i might add such a thing later
20161006 18:54:15< mattsc> ok
20161006 18:54:22< vultraz> i need to do some massive cleanup of the GUI stuff in NotSoEasyCoding
20161006 18:59:01-!- Kwandulin [~Miranda@p200300760F2C71FEE9DFD16BDB543EF2.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161006 18:59:07-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161006 19:05:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161006 19:10:18< mattsc> Btw, I have now also confirmed that an Elvish Ranger on forest counts as invisible even to the own side in [filter_vision] in WML as well (as opposed to calling the filter from Lua).
20161006 19:18:29< mattsc> zookeeper, DeFender1031: the information on the wiki as to how [filter_vision] should behave is contradictory.  This appears in several places, for example on the SUF page it says:
20161006 19:18:55< mattsc> “visible: yes or no, default yes. When "yes", this matches units that are not obscured by fog or shroud, and that are not hiding”
20161006 19:18:57< mattsc> vs.
20161006 19:19:16< mattsc> “StandardSideFilter tags and keys. Filter for who may be able to see (or not see) the unit.”
20161006 19:19:53< mattsc> You could argue that that first statement refers to a unit for which the ‘hides’ ability is active, whether or not I can see it.
20161006 19:20:08< mattsc> But the second statement i clearly saying the opposite.
20161006 19:20:44< zookeeper> well i think it's a reasonable guess that whoever wrote the first one just wasn't thinking that accurately
20161006 19:20:57< mattsc> yeah ...
20161006 19:21:04 * zookeeper will remain a bit afk
20161006 19:22:00< mattsc> So I think we agree that the filter should match for all units on the own side, and for all units on an allied side that shares vision.
20161006 19:31:08< celmin|sleep> [Oct 06@2:41:04pm] vultraz: plus celmin has a WIP implementation of a floating GUI2 chatbox for in-game
20161006 19:31:09< celmin|sleep> Sure, but it's not going to be merged anytime soon/
20161006 19:32:47< DeFender1031> mattsc, what about a unit that's hiding right next to an allied unit (hence, visible to that unit)
20161006 19:33:25< mattsc> that unit counts as “discovered"
20161006 19:33:32< mattsc> (or whatever the correct term is
20161006 19:33:41< mattsc> and is visible already the way it is.
20161006 19:33:46< DeFender1031> or, is there a case where, say, side A has a unit that can hide, side B (enemy of A) has a unit next to it, and side C (allied with B) still can't see it?
20161006 19:34:16< DeFender1031> mattsc, is it? i thought that an ally next to a hidden unit makes it still invisible to enemies
20161006 19:34:33< DeFender1031> it'd be a pretty terrible flaw if an ally standing next to you revealed your position.
20161006 19:34:57< mattsc> Oh, sorry, I misunderstood who you thought was allied with whom …
20161006 19:35:02< DeFender1031> but the point is, i think that anything which means "is visible" should go based on whether the unit is actually... well... visible.
20161006 19:35:17< DeFender1031> mattsc, in my second case, it was a different question
20161006 19:35:47< mattsc> DeFender1031: I made a three-side comparison using wesnoth.find_path, which goes directly to the pathfinding code.
20161006 19:36:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161006 19:36:30< mattsc> Sides A and B were enemies, and a side A unit was trying to move right through a hidden side B unit.
20161006 19:36:53< mattsc> In that default setup, the plotted path was through the side B unit (as expected).
20161006 19:37:11< DeFender1031> basically, there's two cases that need to be tested here in addition to what you've already covered: AB vs. C where A has a hidden unit, b has a unit next to it, is A's unit visible to B or C? (Should be yes, no, respectively) and 2. A vs BC, A has a unit that hides, B discovers it, B and C don't share vision, can C see that unit (assuming no shroud or fog)?
20161006 19:37:52< mattsc> That’s way too much for me to parse right now …  :P
20161006 19:37:58< DeFender1031> (The latter case, i'm actually asking in general as well... IS A's unit visible to the PLAYER of C?)
20161006 19:38:13< DeFender1031> sigh... should i draw a diagram or something :P
20161006 19:38:20< celmin|sleep> mattsc: I think the term is "uncovered".
20161006 19:38:30< mattsc> celmin|sleep: yes, thanks
20161006 19:38:33< mattsc> DeFender1031: no
20161006 19:38:48< celmin|sleep> If I recall, isn't it implemented as a [status]?
20161006 19:39:03< mattsc> I think so, yes
20161006 19:39:31< DeFender1031> mattsc, case 1: side with hidden unit has ally unit next to hidden unit. Does unit register as visible for ally? Does it register for enemy?
20161006 19:40:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20161006 19:40:34< DeFender1031> mattsc, case 2: side with hidden unit has enemy unit next to hidden unit. Can enemy's ally see unit? Does it register as visible via the filter?
20161006 19:41:57< zookeeper> if a unit is revealed by virtue of being adjacent to its enemy, then the unit is visible to everyone
20161006 19:41:59< mattsc> DeFender1031: let’s talk about what the behavior should be first.  
20161006 19:42:16< zookeeper> it's no longer hiding, everyone can see it
20161006 19:42:23< mattsc> Case 1: no; case 2: yes
20161006 19:42:41< mattsc> And the second is even more general, as zookeeper just pointed out.
20161006 19:42:58< DeFender1031> zookeeper, isn't that determined by the filter in the ability? Or is it hard-coded that [hides] is disabled when next to an enemy unit?
20161006 19:43:10-!- JyrkiVesterinen [~JyrkiVest@87-92-37-21.bb.dnainternet.fi] has quit [Quit: .]
20161006 19:43:45< zookeeper> it's hard-coded, you simply can't have a unit that hides next to an enemy
20161006 19:45:42< DeFender1031> zookeeper, yeah, just went and checked the canned definitions. Their filters don't contain any adjacent filtering for non-enemy, so yeah. (Which does make sense, as allowing hide when adjacent to an enemy would make the game very, very broken.)
20161006 19:46:30< zookeeper> anyway, WRT [filter_vision], i think the only intent that really makes sense is that it's supposed to test whether the unit is actually visible to the given side. the [hides] ability is simply one way a unit _can_ make a unit invisible to a given side, but the mere fact that the ability is active doesn't tell whether it is.
20161006 19:46:35< DeFender1031> mattsc, seems that the behavior SHOULD be that filter vision actually filters by vision.
20161006 19:47:11< mattsc> DeFender1031: assuming I interpret what you write correctly, I agree.
20161006 19:47:18< zookeeper> i _think_ there aren't any weird three-way corner cases that need special answers
20161006 19:47:50< DeFender1031> mattsc, meaning, [filter_vision] should be a one-to-one with whether the player can see the unit.
20161006 19:48:02< zookeeper> agreed
20161006 19:48:09< mattsc> I tired the pathfinding code on a situation with 2 sides A & B that are enemies, with a side C that is allied with both of them.
20161006 19:48:18< DeFender1031> the one question is, are there any existing cases that rely on the behavior not being such? I can't think of anything that would even want that, but...
20161006 19:48:19< mattsc> Yep, that’s what I meant.
20161006 19:48:25< zookeeper> i'm pretty sure this discussion has been had in the past though with sapient, i could try and see if i find anything interesting...
20161006 19:49:09< DeFender1031> wait... there's a way to have A and B be against each other but both allied with C?
20161006 19:49:17< mattsc> In the pathfinding functions, you can provide a ‘vision_side’ (or vision_team) parameter that does not have to be the same side as the unit moving.
20161006 19:49:27< mattsc> DeFender1031: yeah, sure
20161006 19:49:32< DeFender1031> how?
20161006 19:49:38< mattsc> used all over the place
20161006 19:49:57< mattsc> side 1: team_name = one
20161006 19:50:07< mattsc> side 2: teamname = two
20161006 19:50:16< mattsc> side 3: team_name = one,two
20161006 19:50:23< DeFender1031> ah, didn't realize that team_name accepted a list
20161006 19:50:27< DeFender1031> cool
20161006 19:50:38< DeFender1031> wait, so how does that work if allies share vision?
20161006 19:50:54< mattsc> anyways, so in the pathfinder code, if I use viewing_side=1 (team A), the path goes through the hidden unit
20161006 19:51:07< mattsc> if viewing_side=3 (team C), it goes around it
20161006 19:51:11< mattsc> just as one would expect
20161006 19:51:31< mattsc> DeFender1031: ^ that should answer your last question
20161006 19:51:33< DeFender1031> if side 2 can see something, does that mean that side 1 can because it inherits it from 3 which inherits it from 2? or is there some mitigating algorithm that tracks what side 3 has ACTUALLY seen as opposed to what its allies have seen?
20161006 19:52:01< DeFender1031> (talking shroud and fog now)
20161006 19:52:33< mattsc> A side can see what its units and the units of an allied side can see directly, not inherited
20161006 19:54:07< mattsc> Anyways, I am off in a few minutes, but it sounds that we all agree that [filter_vision] should match all the units the player of that sides can see.
20161006 19:54:12< mattsc> And currently it does not.
20161006 19:54:16< zookeeper> mattsc, random guess: filter_vision might have had that quirk to make it work correctly in replays. i'm not sure if that's actually the case and/or whether it could still present a problem, maybe not.
20161006 19:55:06< mattsc> zookeeper: hmm, okay; I do not want to mess with replay or MP OOS potentials
20161006 19:55:26< mattsc> I can work around this easily enough on the WML/Lua side.
20161006 19:56:09< zookeeper> well i'm basing my guess on some comments around 2010 the exact context of which i don't know
20161006 19:56:23< zookeeper> maybe it's unrelated
20161006 19:57:08< DeFender1031> mattsc, zookeeper, i'd still suggest looking into it, as if it's NOT actually an issue, the behavior SHOULD be intuitive.
20161006 19:57:38< DeFender1031> (And if it IS an issue, the underlying issue should be fixed so that we're not stuck with this unintuitive behavior)
20161006 19:57:42< zookeeper> any volunteers for building some kind of elaborate testcase? :p
20161006 19:58:01< DeFender1031> zookeeper, if i knew where to begin, i would.
20161006 19:58:31< DeFender1031> zookeeper, i don't even know how this applies to replays or MP at all, let alone how to test it :P
20161006 20:00:25< zookeeper> well the relation to replays would be the way you can change the point of view
20161006 20:00:29< zookeeper> (i think)
20161006 20:01:02< zookeeper> but really, i have no idea. i'd expect that if replays were an issue in this case, they'd already be broken with sighted events and the like.
20161006 20:01:20< vultraz> zookeeper: is 791 ready to go in?
20161006 20:01:56< zookeeper> vultraz, not until he says so
20161006 20:02:08 * zookeeper checks whether he did
20161006 20:03:58-!- irker022 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161006 20:04:45-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161006 20:04:54< zookeeper> yeah i guess it's fine
20161006 20:05:04< zookeeper> if you merge by hand, then add changelog entries
20161006 20:06:25< vultraz> was just gonna push the button
20161006 20:09:07< zookeeper> well, can add changelog entries separately too
20161006 20:09:24< zookeeper> hence the "if" :p
20161006 20:09:34-!- irker657 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161006 20:09:34< irker657> wesnoth: doofus-01 wesnoth:master c99af653d7a5 / data/core/ (47 files in 2 dirs): new aquatic castles terrain, but still needs keep-castle images https://github.com/wesnoth/wesnoth/commit/c99af653d7a5eaa972e9e252b826dfb1135d5e47
20161006 20:09:34< irker657> wesnoth: doofus-01 wesnoth:master 72555f17af00 / data/core/ (14 files in 3 dirs): adding keep-castle corner transitions https://github.com/wesnoth/wesnoth/commit/72555f17af000fa7b6c2c6aabfc99e3c97f1ca05
20161006 20:09:34< irker657> wesnoth: doofus-01 wesnoth:master 9d30fdacf40d / / (53 files in 22 dirs): Merge branch 'master' into merfolk_castle https://github.com/wesnoth/wesnoth/commit/9d30fdacf40deefa1386070c7989c4e4232bba18
20161006 20:09:35< irker657> wesnoth: doofus-01 wesnoth:master e0201b92391c / data/core/ (4 files in 2 dirs): start of keep-to-water transitions https://github.com/wesnoth/wesnoth/commit/e0201b92391c6baa2e48f6bbe7c1393e1ea72179
20161006 20:09:36< irker657> wesnoth: doofus-01 wesnoth:master 20ec27c68259 / / (224 files in 51 dirs): Merge branch 'master' into merfolk_castle https://github.com/wesnoth/wesnoth/commit/20ec27c682595d4edabcb357ab8f15193a55e2c1
20161006 20:09:38< irker657> wesnoth: doofus-01 wesnoth:master 4bd2c006e988 / data/core/ (9 files in 3 dirs): corner edge transition rules, and first keep-to-water transition images https://github.com/wesnoth/wesnoth/commit/4bd2c006e988d3e5eb575077814df3645ca1d0a6
20161006 20:09:40< irker657> wesnoth: doofus-01 wesnoth:master 16e730eacc80 / data/core/ (27 files in 3 dirs): more work on the transitions https://github.com/wesnoth/wesnoth/commit/16e730eacc80dc88216606311605dc5a9cfadbc6
20161006 20:09:42< irker657> wesnoth: doofus-01 wesnoth:master bfe2bb594d9c / data/core/ (33 files in 2 dirs): fixes to the gates of the keep walls https://github.com/wesnoth/wesnoth/commit/bfe2bb594d9cd5b3921465fcda7f08fcd6c9d640
20161006 20:09:44< irker657> wesnoth: Charles Dang wesnoth:master 1f3a4851340f / data/core/ (82 files in 3 dirs): Merge pull request #791 from doofus-01/merfolk_castle https://github.com/wesnoth/wesnoth/commit/1f3a4851340f72b6d3eaa92374b8cee63137a90f
20161006 20:10:05< vultraz> I really think at some point we should ask if he could make a few more transitions for the mine walls
20161006 20:10:12< vultraz> some that are more in the style of stone walls
20161006 20:10:13< zookeeper> uh.... you should have squashed it
20161006 20:10:36< vultraz> I'm feeling lazy :P
20161006 20:10:43< vultraz> it's 7 am
20161006 20:10:47< zookeeper> it takes no extra effort
20161006 20:11:15< zookeeper> now it's a mess
20161006 20:11:56< vultraz> meh
20161006 20:13:49< zookeeper> i wish github had a panic button
20161006 20:14:09< vultraz> if it's really so important I can force push 
20161006 20:14:36< zookeeper> i can't gauge how important it is
20161006 20:15:25< vultraz> also, someone tell him Kme and Ke have no transition 
20161006 20:16:47< vultraz> I'll fix the history
20161006 20:16:53< vultraz> no one pull for a few minutes..
20161006 20:17:12< zookeeper> they have no transition with any other castle
20161006 20:18:14< zookeeper> few castles do, but i guess there's a few things that could be done to pretty it up
20161006 20:19:14< zookeeper> it's impossible to do something like that collaborately, so all we can do is merge them and hope that someone finds the time to go over them and tweak things
20161006 20:19:21< zookeeper> collaboratively
20161006 20:19:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161006 20:21:36< irker657> wesnoth: doofus-01 wesnoth:master 955b5b4bec9f / data/core/ (82 files in 3 dirs): New aquatic castles terrain https://github.com/wesnoth/wesnoth/commit/955b5b4bec9f7fd881f3d88f4952c14482b8e64a
20161006 20:21:38< irker657> wesnoth: Charles Dang wesnoth:master dfd9bf12dffa / changelog: Update changelog https://github.com/wesnoth/wesnoth/commit/dfd9bf12dffaf97d79de346375ddf782b14c13f2
20161006 20:21:43< vultraz> zookeeper: ^ happy?
20161006 20:22:13-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161006 20:25:27< vultraz> I squashed everything from before into one commit
20161006 20:25:28< matthiaskrgr> fun for people that already pulled :| 
20161006 20:27:51< vultraz> matthiaskrgr: I doubt many people pulled in those 12 minutes
20161006 20:29:45< DeFender1031> besides, vultraz DID say that people shouldn't pull for a few minutes...
20161006 20:30:05< zookeeper> vultraz, very happy!
20161006 20:30:36< zookeeper> vultraz, going to post or shall i?
20161006 20:30:45< vultraz> post?
20161006 20:31:24< zookeeper> in forum thread
20161006 20:31:25< vultraz> if you mean on the forums, go ahead
20161006 20:31:28< zookeeper> okay
20161006 20:33:01< mattsc> zookeeper, DeFender1031: did some repository mining … https://github.com/wesnoth/wesnoth/commit/bb78efd8fb13a37af417d3d833eb80e847b23f27#diff-af3fd7e884f8ab9f39f9088ca4010d0dR1069
20161006 20:33:20< DeFender1031> vultraz, zookeeper, are any new terrain types being added in 1.13, or is this stuff just prettying up the existing stuff?
20161006 20:33:25< mattsc> This is the commit that introduced [filter_vision]
20161006 20:33:36< vultraz> DeFender1031: that was a new terrain that just went in
20161006 20:33:52< mattsc> And it already simply checks whether the unit is invisible or not.  (the logic was fixed shortly thereafter, but not the check itself).
20161006 20:34:00< zookeeper> i don't recall there being any new terrains on the horizon after these though
20161006 20:34:05< DeFender1031> vultraz, guess that answers my question then. :P
20161006 20:34:35< mattsc> So, it’s been like this from the very beginning.
20161006 20:34:58< vultraz> zookeeper: anyway, what do you think about asking doofus to do a few more frames for the mine walls so they're more like the wooden walls? they don't really look great in large batches, but I think there could be some interesting straight/hex combos with frames, instead of the silhouette zig-zagging everywhere.
20161006 20:35:22< vultraz> zookeeper: also, I'm going to add the popular umc Gate terrain
20161006 20:35:24< DeFender1031> mattsc, that doesn't answer whether it was that way for a reason, or whether in the interim, something was introduced that would break if that were changed.
20161006 20:36:07< vultraz> zookeeper: er, s/wooden walls/stone walls
20161006 20:36:55< zookeeper> mattsc, so that this->invisible() doesn't/didn't actually check whether the unit is invisible to the viewer specifically, just that if it was hiding?
20161006 20:37:17< DeFender1031> vultraz, zookeeper, are any existing image files or from 1.12 being changed/moved to a new path/removed, or are all new graphics being done in new file locations?
20161006 20:37:23< zookeeper> vultraz, screenshot of the gate terrain?
20161006 20:38:17< vultraz> DeFender1031: hewn cave walls have been replaced by mine walls 
20161006 20:38:39< DeFender1031> vultraz, so the files themselves have changed?
20161006 20:38:45< vultraz> yes
20161006 20:38:49< mattsc> DeFender1031: no, it does not, but this line was not changed later in the code (not its functionality at least; its syntax was changed).
20161006 20:38:56< mattsc> zookeeper: correct
20161006 20:39:42< zookeeper> mattsc, okay...
20161006 20:40:01< DeFender1031> vultraz, good to know. here's a broader question: is/will there be a complete list somewhere of things which have changed in a potentially backwards-incompatible manner between 1.12 and 1.13/1.14?
20161006 20:40:12< vultraz> yes
20161006 20:40:34< DeFender1031> Basically, a changelog stripped of all the "added feature X which doesn't matter if you were never using it" entries
20161006 20:41:21< vultraz> zookeeper: https://drive.google.com/file/d/0B-mR9s8FduLLM2VzLU55VGk0dzQ/view?usp=sharing
20161006 20:41:38< zookeeper> mattsc, i'm inclined to suggest that it should be fixed regardless
20161006 20:41:57< vultraz> (my alpha handled changes recently made the gates look kinda weird :/ )
20161006 20:42:18< zookeeper> vultraz, uh those are just scenery/gate-rusty
20161006 20:42:28< vultraz> zookeeper: but with some tg applied
20161006 20:42:58< mattsc> zookeeper: I agree.  The point I was trying to make (inexpertly) was that it all looks like this was simply a case that was forgotten, because why would you filter your own units to see whether they are visible after all, rather than because it was desired functionality.
20161006 20:43:04< vultraz> zookeeper: https://github.com/Vultraz/Shadows_of_Deception/blob/master/terrain-graphics/gates.cfg
20161006 20:43:06< mattsc> With the caveat DeFender1031 pointed out.
20161006 20:43:20< vultraz> zookeeper: credit goes to shadowm who originaly wrote that for AtS from whence i copied it
20161006 20:43:55< zookeeper> eh eh eh
20161006 20:44:43< vultraz> zookeeper: if one just uses [item], they don't display correctly next to walls
20161006 20:45:09< zookeeper> DeFender1031, i'm hoping to put up a list like that (and have people add the changes they've made to it, not to compile a comprehensive one myself alone)... although image changes wouldn't be covered as there's just too many
20161006 20:45:21< vultraz> zookeeper: also this reminds me you haven't added the new shroud terrain!
20161006 20:45:32< zookeeper> what new shroud terrain
20161006 20:46:48< zookeeper> also i have no opinion on the mine walls question
20161006 20:46:52< vultraz> zookeeper: https://drive.google.com/file/d/0B-mR9s8FduLLeXVHSGx3VjVBeHc/view?usp=sharing
20161006 20:47:01< vultraz> zookeeper: and there's a similar thing for fog
20161006 20:47:11< vultraz> credit to shadowm ofc
20161006 20:47:23< vultraz> but you said you'd think about their implementations
20161006 20:47:26< mattsc> zookeeper: I think I could probably fix this with a couple lines of code, but I cannot do more than a couple quick tests of replays or MP games.
20161006 20:47:46< zookeeper> vultraz, in that case i had completely forgotten
20161006 20:48:00< vultraz> but they're better than the IDFKWTI "shroud" and "fog" terrains we have now :P
20161006 20:48:00< DeFender1031> mattsc, which caveat did I point out?
20161006 20:48:13< zookeeper> but now that you mention it i do have a vague recollection of something along those lines
20161006 20:48:26< mattsc> DeFender1031: that something might have been added later that depends on this behavior now.
20161006 20:48:45-!- mjs-de [~mjs-de@x4e301729.dyn.telefonica.de] has quit [Remote host closed the connection]
20161006 20:48:49< mattsc> Or that there was a real reason to do so in the first place (although I think that that is very unlikely)
20161006 20:49:10< zookeeper> mattsc, well, it's hard to make tests anyway when we don't really know what exactly we should be testing for...
20161006 20:49:22< mattsc> yeah …
20161006 20:49:43< DeFender1031> zookeeper, so basically, if a content creator such as myself wanted to transition an add-on, (s)he'd just have to go through any image stuff manually to make sure it all still looked right?
20161006 20:49:47< zookeeper> i'm willing to take the risk as long as we remember the possibility whenever someone reports some weird behavior that could be related :P
20161006 20:50:19< mattsc> Yeah.  Agreed.  I think the risk of that is very low.
20161006 20:50:47< mattsc> So … should I try to get this into 1.13.6, so that it will get tested by more people as soon as possible.  Or wait so that we have a longer +dev version testing period?
20161006 20:50:59< zookeeper> DeFender1031, sadly, yes. my compulsion with trying to retain compatibility doesn't completely extend to images... except that wherever possible, we shouldn't _delete_ images even if we change some.
20161006 20:51:47< zookeeper> mattsc, into 1.13.6 sounds safer
20161006 20:52:06< zookeeper> to get it in while we still remember the whole thing :p
20161006 20:52:25< DeFender1031> zookeeper, mattsc, I concur (not that my opinion should mean much). It seems worth correcting a strange behavior which should probably be considered a bug rather than worrying that doing so would unveil some other bug. Come to think of it, if no one ever fixed bugs for fear that they're currently masking some other bug, nothing would ever get fixed.
20161006 20:52:33< mattsc> zookeeper: yeah  :P  I’ll try to do so soon then.
20161006 20:53:01< zookeeper> great
20161006 20:53:07< mattsc> DeFender1031: that’s a good point
20161006 20:55:02< DeFender1031> zookeeper, i hear that, and would probably make the same decision. You don't want to clutter up the source tree with images that are no longer used or even in the current style anymore just because something non-mainline might be using them in ways that depend on pixel-perfect behavior.
20161006 20:55:26< DeFender1031> or even not in the current style*
20161006 20:56:06< zookeeper> DeFender1031, WRT changed images, mostly one could expect problems if they depend on the exact contents of the image (IPF crops or somesuch), or use core unit frames that have been removed when their sprite got upgraded.
20161006 20:56:40< DeFender1031> zookeeper, right, exactly.
20161006 20:56:47< zookeeper> (the latter preferably shouldn't happen, but it does)
20161006 20:56:48< DeFender1031> zookeeper, actually, there's one more case I can think of.
20161006 20:57:23< DeFender1031> zookeeper, where someone created another image out of those which exist to use in some situation where it should match its surroundings.
20161006 20:57:30< zookeeper> oh, sure
20161006 20:59:07< DeFender1031> (For example, I created a merge of bridge/chasm-dock-xx-ne.png and bridge/chasm-dock-xx-sw to represent a leftover support pillar from an otherwise destroyed bridge.)
20161006 20:59:35< zookeeper> yeah, it is a bummer if/when one has to redo work like that
20161006 21:00:39< DeFender1031> eh, that only took me two minutes, though I'd imagine I might get frustrated if I encountered a whole series of changes I needed to make. (For example, I anticipate that much of the custom terrain graphics I've created will need tweaking for 1.13)
20161006 21:03:59< zookeeper> trying to start SoF crashes
20161006 21:05:11< zookeeper> DW too
20161006 21:05:15< zookeeper> all campaigns, maybe? :p
20161006 21:05:15< DeFender1031> also, it's sometimes necessary to use core unit sprites, such as when creating a custom animation for a new item, or when duplicating a unit's WML in order to provide a slightly altered version for some reason (though in the latter case, you'd just re-duplicate and make the same modification using the new version's WML)
20161006 21:05:44< DeFender1031> zookeeper, so much for getting master to be stable, eh?
20161006 21:18:34< gfgtdf> zookeeper: you have a stacktrace of that crash ?
20161006 21:18:51-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20161006 21:19:42-!- louis94 [~~louis94@91.178.242.177] has joined #wesnoth-dev
20161006 21:20:00 * vultraz keeps tweaking tooltip designs
20161006 21:21:00< celmin|sleep> vultraz, zookeeper: The gate looks good but I think it needs some kind of transition between adjacent gate tiles. Either add a pillar or make the gate continuous.
20161006 21:21:24< vultraz> yeah, it kinda does need more graphics
20161006 21:21:31< vultraz> another task for doofus, maybe? 
20161006 21:22:03< vultraz> s/more/new
20161006 21:24:58< zookeeper> gfgtdf, i tried a debugger but only came up with some low-level stuff
20161006 21:25:05< zookeeper> so dunno
20161006 21:25:12< gfgtdf> zookeeper: hmm ok thx.
20161006 21:25:46< zookeeper> vultraz, well i think the gates look so ugly that i wouldn't endorse them with a core terrain until they can actually be made to look better
20161006 21:25:58< zookeeper> which isn't necessarily a hard task
20161006 21:26:02< vultraz> new graphics it is!
20161006 21:26:46< zookeeper> but they don't need to be a terrain in order for one to be able to use [terrain_graphics] to draw them
20161006 21:27:20< vultraz> Massive convenience. 
20161006 21:27:24< vultraz> When making maps
20161006 21:27:27< vultraz> Hell, even DiD uses them
20161006 21:27:39< vultraz> but as hacky terrain replacers :|
20161006 21:30:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161006 21:31:00< vultraz> having a formula= key in the gui2 canvas drawing primitives would be nice
20161006 21:31:06< vultraz> so one could calculate values
20161006 21:31:06< zookeeper> if we try to get new graphics for them then it'd certainly make sense to also make "open" versions of them so they don't need to entirely disappear when the gate opens
20161006 21:31:34< vultraz> zookeeper: can they be animated to open, or is that Beyond Our Tech?
20161006 21:31:35< zookeeper> which might or might not mean that having 4 separate terrains for gates is kind of weird
20161006 21:32:14< zookeeper> beyond our tech
20161006 21:32:21< zookeeper> (in this case)
20161006 21:33:28< zookeeper> i might be inclined to suggest that there could be only two gate overlay embellishment terrains, which change graphics depending on whether the underlay tile is of type X* or not
20161006 21:33:40< zookeeper> hrhm
20161006 21:33:51< zookeeper> i guess that wouldn't work
20161006 21:33:58< zookeeper> so nevermind
20161006 21:34:26< zookeeper> so if we want both closed and open gates, it'd require 4 terrains
20161006 21:34:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161006 21:34:52< zookeeper> (since i doubt that even with new graphics, a N-S gate could be made to look good and recognizable)
20161006 21:36:01< vultraz> celmin|sleep: any chance you could add such a thing at a later date? or enable formulas for the color= keys? so for example, one could do color = "(0, 0, 0, alpha where alpha = 255 - step where step = abs(255 / width) )"
20161006 21:36:21< vultraz> (I probably got that totally wrong, it's early :|, but you get the gist)
20161006 21:37:14< celmin|sleep> Should be easily done. I'll put it on the TODO list I guess, but no idea if/when I'll get to it.
20161006 21:37:16< vultraz> (likely wouldn't do exactly what I'd want. anyway)
20161006 21:37:59< vultraz> im actually not sure what the formula would be for a smooth gradient line
20161006 21:38:25< celmin|sleep> You'd need [0,0,0,alpha] in that formula.
20161006 21:38:38< celmin|sleep> Or color(0,0,0,alpha) maybe, if I added a new callable type.
20161006 21:38:57< celmin|sleep> ...maybe even rgba(...)...
20161006 21:41:39< vultraz> essentially I'd need a formula that would calculate the transform rate between 0 and 255 given a distance of n but I cannot think of the right equation right now
20161006 21:42:57< gfgtdf> i wonder whether, instead of manually uploading to each addon server, it makes more sense to have a supported_version=1.13, 1.12 in the pbl wml and then only have one addon server, that only shows the compatible addons when you ask for addons, 
20161006 21:47:33< vultraz> i'd need to calculate the 0 - 255 slope and get the x value for 255 / length
20161006 21:47:35< vultraz> I think
20161006 21:49:43< zookeeper> gfgtdf, well, i guess that would make sense.
20161006 21:53:17< zookeeper> when missing, that field could be automatically filled in based on the version of the client that's being used for uploading. in that case, i guess there wouldn't be any difference from the user's or author's PoV if they do things as usual?
20161006 22:02:44< Aginor> wouldn't that require each author to update the addon?
20161006 22:05:10< zookeeper> well, if/when we'd implement this thing on a new server and not hack it into the existing 1.12/1.13 servers
20161006 22:05:24< zookeeper> i figured that'd be a given
20161006 22:06:41< Aginor> how much API breakage is it between 1.12 and 1.13 anywya?
20161006 22:07:32< Aginor> because requiering each addon to be modified by the author strikes me as it could lead to a lot of addons disappearing because they can't be bothered to update while the addons themselves might still work
20161006 22:08:43< zookeeper> i'm not sure how much, haven't got a list yet
20161006 22:08:50< zookeeper> "quite enough", let's say
20161006 22:09:24< zookeeper> anyway, the problem you describe is exactly what happens every stable-dev-stable cycle
20161006 22:09:41< Aginor> so we're breaking lots of API between stable versions without deprecating it first? :/
20161006 22:10:37< zookeeper> i think we break a lot less than we would if i wasn't constantly hitting certain people on the head for it
20161006 22:10:56< zookeeper> but yes, generally we break quite a few things between stable versions
20161006 22:11:09< zookeeper> which is really bad
20161006 22:11:12< Aginor> that's not ideal :/
20161006 22:12:19< Aginor> phasing out stuff is fine, but there should be a clear window between it
20161006 22:12:22< zookeeper> we even have Certain People advocate for specifically not having backwards compatibility for certain things even if it would be really simple to do so, in the name of forcing people to use the New Right Way of doing something because it's like more convenient or whatever.
20161006 22:12:35 * vultraz waves
20161006 22:12:39 * zookeeper stabs
20161006 22:13:03< Aginor> otherwise we're just alienating the UAC contribitors and that's where a lot of wesnoth's value comes from
20161006 22:13:03 * tad_ looks for Pitchforks.
20161006 22:14:02< zookeeper> Aginor, that's one of the biggest long-term problems i think the project has. lots of UMC falls by the wayside because it would take effort and knowhow to update them every time a new stable branch arrives.
20161006 22:14:31< Aginor> zookeeper: it's sad, because it's not hard to fix
20161006 22:14:46< Aginor> 1. Don't remove/break existing API, deprecate it
20161006 22:14:58< Aginor> 2. Introduce new API to replace deprecated API
20161006 22:15:28< Aginor> Release new version, stating a plan for how API will be managed across versions
20161006 22:15:31< gfgtdf> zookeeper: well the proposal has 2 advantages: 1) as a dev i only need to opload my addons one (currently i need to upload my addons to wensoth 1.12. and 1.3 servers. 2) the addons knows which versions it supports, for example when i update form 1.12 to 1.13 the game can just checks which instlled addons support wesnoth 1.13 and disable the other addons
20161006 22:15:35< zookeeper> i mean we do properly deprecate some things. nowadays, anyway; it used to be that we'd deprecate things for "2 releases" before removing it... but that meant two development releases :p
20161006 22:15:58< Aginor> Remove deprecated api as the usage of it drops or there has been sufficien amount of notice (2 stable releases or so)
20161006 22:16:38< Aginor> gfgtdf: it sounds like few addons will even work across versions anyway
20161006 22:17:03< zookeeper> and i don't mean that we just silently break stuff, as i think all API changes we do now have at the very least deprecation warnings or something
20161006 22:17:05< gfgtdf> Aginor: yes but currently the game doenst know which addons wrk on newer versions.
20161006 22:18:17< gfgtdf> Aginor: there are quite some addons that work on both 1.13.5 and 1.12.5
20161006 22:18:22< zookeeper> anyway, i shouldn't even be awake anymore so i'll hop off ->
20161006 22:18:37< Aginor> zookeeper: keep up the good shouting
20161006 22:19:26< zookeeper> Aginor, what i try to insist nowadays is that the API needs to work from one stable to the next (but with deprecation warnings), but not from that new stable to the next
20161006 22:20:03< zookeeper> and there are exceptions when compatibility is for whatever reason hard or impossible to keep
20161006 22:20:11< vultraz> If you insisted deprecated API stuff worked in 1.16 I would scream 
20161006 22:20:26< zookeeper> you mean, you would scream louder than now? :p
20161006 22:20:35-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20161006 22:20:45< Aginor> what would be an example of that?
20161006 22:24:42< gfgtdf> zookeeper: i dont think people intentionally break compability to force people to do the right thing.
20161006 22:27:23< Aginor> here's an interesting read on API uptake in android: http://web.cs.ucla.edu/~miryung/Publications/icsm2013-apiecosystem.pdf
20161006 22:27:51-!- boucman_work [~boucman@2a02-8428-034f-f800-9e32-0c7c-b391-6223.rev.sfr.net] has joined #wesnoth-dev
20161006 22:28:11-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161006 22:28:11-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20161006 22:34:45< vultraz> Aginor: personally I think you cannot judge API adoption on Android as long as every single phone maker has a different policy on pushing OS updates.
20161006 22:35:55< vultraz> Apple, OTHO, pushes iOS updates to users directly, meaning more people on newer versions using newer APIs, and consequently companies will be faster to update their apps.
20161006 22:37:50< Aginor> vultraz: I disagree with you there, but sure. It's also acknowledged in the article as an overall problem with the android ecosystem, and as you can see, the sudy covers a vast amount of API versions
20161006 22:38:18< Aginor> I'm sure you can find a similar studies for other APIs though
20161006 22:38:40< Aginor> in fact, just go and look at who cites that paper and you will be able to find interesting stuff
20161006 22:39:39< vultraz> We have a rather different approach, though, since stable versions of different series are *not* guaranteed to work together.
20161006 22:39:51< Aginor> but they *should* be
20161006 22:39:56< Aginor> for reasons stated above
20161006 22:40:37< vultraz> You have a point.
20161006 22:41:24< Aginor> any commercial project who is worried about retaining users of their API is very careful about breaking it
20161006 22:41:44< vultraz> But I still think it doesn't matter if work needs to be done for 1.12 -> 1.14, because even if stuff "works", there will be deprecation notices and they they'll have to update for 1.16 along with the 1.15 changes..
20161006 22:42:12< Aginor> we are in an even more precarious situation because a lot of wesnot's value-add comes from UMC and we shouldn't be alienating those developers
20161006 22:42:35< vultraz> there is never a time when users don't have to update their addons between stable series in some way
20161006 22:42:35< Aginor> vultraz: you're assuming that they are following the development releases, I think that's a flawed assumption
20161006 22:43:06< vultraz> true
20161006 22:43:09< Aginor> deprecating things is fine, it's a mechanism for saying "we want to remove this"
20161006 22:43:32< Aginor> going from one stable to another stable with breaking changes and no warning isn't
20161006 22:44:16< vultraz> We usually deprecate instead of outright remove
20161006 22:44:21< vultraz> Not always, but mostly
20161006 22:44:41< vultraz> What annoys me is when zookeeper advocates not even a noticeable deprecation notice.
20161006 22:45:14< vultraz> Such as with the new Campaign difficulty syntax
20161006 22:45:33< vultraz> he said it be relegated to console output
20161006 22:46:54< vultraz> though i suppose umc authors would run a console
20161006 22:49:48< DeFender1031> vultraz, as a umc author, i tend to only check the console if the game itself crashes, freezes, or explodes.
20161006 22:50:43-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161006 22:51:03< DeFender1031> were it me, i'd make whatever was deprecated show an actual notice, but only in debug mode.
20161006 22:53:22-!- louis94 [~~louis94@91.178.242.177] has quit [Quit: Konversation terminated!]
20161006 23:02:43< tad_> That is a good idea.
20161006 23:11:20< irker657> wesnoth: Charles Dang wesnoth:master e76db219ac36 / data/gui/widget/window_tooltip_large.cfg: Tooltips: improved design yet again https://github.com/wesnoth/wesnoth/commit/e76db219ac3623ace391d8b50b143fc3105227c7
20161006 23:11:26< vultraz> Again, feedback appreciated
20161006 23:12:21< vultraz> i might restore one of the simpler versions for more general use and keep that for dialogs like Mp Create, I'm not sure.
20161006 23:15:29< tad_> My only comment about the tooltips is, often, they obscure the text I'm trying to read and I get frustrated having to wiggle the mouse to make 'em go away.
20161006 23:22:22< vultraz> oh, huh
20161006 23:22:25< vultraz> apparently
20161006 23:22:34< vultraz> [line] thickness doesn't actually do anything
20161006 23:22:59< vultraz> not sure if it should
20161006 23:23:06< vultraz> or one should use a rectangle
20161006 23:23:29< vultraz> especially since
20161006 23:23:31< vultraz> like
20161006 23:24:28< vultraz> so you have a line from x1,y1, to x2,y2 with a thickness of 3. Should it draw from x1 to x1 + 3?
20161006 23:24:31< vultraz> or - 3?
20161006 23:25:16< vultraz> I guess it should respect the rectangle formula
20161006 23:25:57< vultraz> except lines don't have to be ... rectangular 
20161006 23:26:28< vultraz> ie, x1 or y1 doesn't need to squal x2 or y2
20161006 23:26:32< vultraz> equal 
20161006 23:26:46< DeFender1031> many graphics programs allow you to choose betwen rectangular, round, or truncated ends for a line
20161006 23:26:46< vultraz> hmm
20161006 23:31:02< DeFender1031> (Truncated meaning rectangular, but not extending past the endpoints in the direction parallell to the line, and rectangular meaning extending past the endpoints by half the width in both directions0
20161006 23:31:06< DeFender1031> )
20161006 23:31:42-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 264 seconds]
20161006 23:39:18-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161006 23:42:22-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161006 23:49:40< irker657> wesnoth: Charles Dang wesnoth:master 726100e9c2f9 / data/gui/widget/window_tooltip_large.cfg: Few further tweaks and cleanup for e76db219ac36 https://github.com/wesnoth/wesnoth/commit/726100e9c2f9b768d181601f7e21cbae02ce9fc1
20161006 23:55:09< vultraz> current tooltips
20161006 23:55:11< vultraz> https://drive.google.com/file/d/0B-mR9s8FduLLbVlpOExtREdlWUU/view?usp=sharing
20161006 23:56:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161006 23:59:11< vultraz> still slightly unsure about the bg color
--- Log closed Fri Oct 07 00:00:02 2016