--- Log opened Thu Dec 08 00:00:47 2016
20161208 00:00:47< EliDupree> And since I only have 1.13 installed on Windows, not Linux, I don't know that much about how to do further debugging
20161208 00:01:13< Shiki> Can you check the stderr file for a message. Though I'm not sure where it is.
20161208 00:02:37< gfgtdf> EliDupree: you use 1.13.6 or lastest master ?
20161208 00:02:43< EliDupree> 1.13.6
20161208 00:04:39< gfgtdf> 1.13.6 ha a sknown bug where wml pasing erros can crash the game.  Not sure if its related but if i is you can workaroudn it by addon disable_loadingscreen_animation=yes to your preferences file
20161208 00:30:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161208 00:30:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161208 00:30:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161208 00:31:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161208 00:35:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds]
20161208 00:40:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161208 00:40:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161208 00:43:29-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20161208 00:43:29< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Release Celtic Minstrel e6cae2e: Fix lexical_cast compiler errors on MSVC 2013 Succeeded
20161208 00:43:29< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-23
20161208 00:43:29< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/e6cae2e16e40fc3e8c7190b0aa821dd7202cef8d
20161208 00:43:34-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20161208 01:00:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161208 01:07:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161208 01:08:08-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20161208 01:08:08< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Debug Celtic Minstrel e6cae2e: Fix lexical_cast compiler errors on MSVC 2013 Succeeded
20161208 01:08:08< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-23
20161208 01:08:08< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/e6cae2e16e40fc3e8c7190b0aa821dd7202cef8d
20161208 01:08:13-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20161208 01:08:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161208 01:09:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161208 01:09:50-!- Appleman1234 [~Appleman1@KD106161198145.au-net.ne.jp] has quit [Ping timeout: 258 seconds]
20161208 01:14:37-!- Appleman1234 [~Appleman1@KD106161201200.au-net.ne.jp] has joined #wesnoth-dev
20161208 01:15:16-!- travis-ci [~travis-ci@ec2-54-158-40-166.compute-1.amazonaws.com] has joined #wesnoth-dev
20161208 01:15:17< travis-ci> gfgtdf/wesnoth-old#718 (master - b8bcbb5 : gfgtdf): The build was broken.
20161208 01:15:17< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth-old/builds/182132843
20161208 01:15:17-!- travis-ci [~travis-ci@ec2-54-158-40-166.compute-1.amazonaws.com] has left #wesnoth-dev []
20161208 01:16:27< gfgtdf> any opinion on new pr #897 ?
20161208 01:22:13< vultraz> ill look further
20161208 01:32:21< vultraz> gfgtdf: I decided I'll take your advice and keep lexical_cast and lexical_cast_default as two functions
20161208 01:40:58-!- travis-ci [~travis-ci@ec2-54-158-40-166.compute-1.amazonaws.com] has joined #wesnoth-dev
20161208 01:40:59< travis-ci> gfgtdf/wesnoth-old#719 (master - 7893ebb : gfgtdf): The build was broken.
20161208 01:40:59< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth-old/builds/182137418
20161208 01:40:59-!- travis-ci [~travis-ci@ec2-54-158-40-166.compute-1.amazonaws.com] has left #wesnoth-dev []
20161208 01:41:45-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20161208 01:41:45< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Release Celtic Minstrel e6cae2e: Fix lexical_cast compiler errors on MSVC 2013 Succeeded
20161208 01:41:45< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-24
20161208 01:41:45< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/e6cae2e16e40fc3e8c7190b0aa821dd7202cef8d
20161208 01:41:50-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20161208 02:03:43-!- gfgtdf_ [~chatzilla@x4e3635fb.dyn.telefonica.de] has joined #wesnoth-dev
20161208 02:05:53-!- gfgtdf [~chatzilla@x4e368245.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20161208 02:06:07-!- gfgtdf_ is now known as gfgtdf
20161208 02:06:22-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20161208 02:06:22< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Debug Celtic Minstrel e6cae2e: Fix lexical_cast compiler errors on MSVC 2013 Succeeded
20161208 02:06:22< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-24
20161208 02:06:22< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/e6cae2e16e40fc3e8c7190b0aa821dd7202cef8d
20161208 02:06:26-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20161208 02:09:14< vultraz> god dammit
20161208 02:09:20< vultraz> wesnoth still crashing
20161208 02:09:55-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:61e4:abbc:ddc1:5f30] has joined #wesnoth-dev
20161208 02:14:21< vultraz> ah
20161208 02:14:25< vultraz> problem, I have found
20161208 02:14:37-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:61e4:abbc:ddc1:5f30] has quit [Ping timeout: 258 seconds]
20161208 02:15:21< vultraz> attribute_numeric_visitor
20161208 02:15:30< vultraz> it calls lexical_cast_default
20161208 02:15:59< vultraz> however, if it's second argument is blank, I think it essentially gets passed as 'no argument'
20161208 02:16:22< vultraz> which causes a throw
20161208 02:26:02< gfgtdf> vultraz: is that on master ?
20161208 02:26:10< vultraz> no, locally
20161208 02:28:56< vultraz> and now im getting a bad_lexical_cast starting a campaign
20161208 02:28:57< vultraz> fucking hell
20161208 02:32:31< vultraz> HOW is it firing here, I caught it 
20161208 02:33:48< vultraz> oh,
20161208 02:33:50< vultraz> hm
20161208 02:33:57< gfgtdf> vultraz: most debugger have a 'break on thor exception' feature
20161208 02:34:23< vultraz> I screwed up\
20161208 02:34:26-!- travis-ci [~travis-ci@ec2-54-92-227-250.compute-1.amazonaws.com] has joined #wesnoth-dev
20161208 02:34:27< travis-ci> gfgtdf/wesnoth-old#720 (master - f69b800 : gfgtdf): The build was broken.
20161208 02:34:27< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth-old/builds/182148719
20161208 02:34:27-!- travis-ci [~travis-ci@ec2-54-92-227-250.compute-1.amazonaws.com] has left #wesnoth-dev []
20161208 02:37:00< gfgtdf> i wonderwhy we have this IS_ALLY macro https://github.com/wesnoth/wesnoth/blob/master/data/core/macros/conditional-utils.cfg#L74 its implementation is not onyl silly (the usualy way to do such things is standard side filter )
20161208 02:37:02< gfgtdf> + allied_with
20161208 02:37:45< gfgtdf> its actuial wrong: cahcing team_mane for equalite is not sufficient, it has to check whetehr the tem_name set intesects
20161208 02:41:17< vultraz> ugh
20161208 02:53:21-!- irker620 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161208 02:59:43-!- gfgtdf_ [~chatzilla@x4e368239.dyn.telefonica.de] has joined #wesnoth-dev
20161208 03:01:53-!- gfgtdf [~chatzilla@x4e3635fb.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20161208 03:02:07-!- gfgtdf_ is now known as gfgtdf
20161208 03:04:35-!- serin|_| [~serin@209.77.159.143.dyn.plus.net] has joined #wesnoth-dev
20161208 03:05:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161208 03:07:02-!- serin| [~serin@209.77.159.143.dyn.plus.net] has quit [Ping timeout: 256 seconds]
20161208 03:20:26< vultraz> jeez, 600 MB executable for wesnoth-debug
20161208 03:21:33-!- serin|_| [~serin@209.77.159.143.dyn.plus.net] has quit [Ping timeout: 265 seconds]
20161208 03:21:50-!- irker819 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161208 03:21:50< irker819> wesnoth: Charles Dang wesnoth:master 10abf90ff30e / src/lexical_cast.hpp: Implement lexical_cast_default as its own function https://github.com/wesnoth/wesnoth/commit/10abf90ff30e0c728dd58ff5c60d9104b0e515d5
20161208 03:21:50< irker819> wesnoth: Charles Dang wesnoth:master 8c7df93d4feb / / (20 files in 8 dirs): Removed old implementation of lexical_cast_default https://github.com/wesnoth/wesnoth/commit/8c7df93d4feb3355ebc734264ff98c43ac85bb12
20161208 03:21:51< irker819> wesnoth: Charles Dang wesnoth:master 4d48ed131976 / src/ (47 files in 19 dirs): Cleaned up util.hpp includes https://github.com/wesnoth/wesnoth/commit/4d48ed13197656cf190a63505dd45e675a7072e9
20161208 03:22:01< Shiki> vultraz, about the paste i posted earlier... anything more you want to know? seems i can reproducd it now
20161208 03:22:15< vultraz> Shiki: ill look into it
20161208 03:36:45-!- gimemor [~gimemor@host-95-152-57-4.dsl.sura.ru] has joined #wesnoth-dev
20161208 03:47:13-!- travis-ci [~travis-ci@ec2-54-198-213-238.compute-1.amazonaws.com] has joined #wesnoth-dev
20161208 03:47:14< travis-ci> gfgtdf/wesnoth-old#721 (master - 5c9191a : gfgtdf): The build is still failing.
20161208 03:47:14< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth-old/builds/182165991
20161208 03:47:14-!- travis-ci [~travis-ci@ec2-54-198-213-238.compute-1.amazonaws.com] has left #wesnoth-dev []
20161208 03:56:58-!- serin| [~serin@209.77.159.143.dyn.plus.net] has joined #wesnoth-dev
20161208 04:25:41-!- gimemor [~gimemor@host-95-152-57-4.dsl.sura.ru] has quit [Ping timeout: 268 seconds]
20161208 04:27:12-!- gfgtdf [~chatzilla@x4e368239.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20161208 04:33:32-!- travis-ci [~travis-ci@ec2-54-81-32-26.compute-1.amazonaws.com] has joined #wesnoth-dev
20161208 04:33:33< travis-ci> wesnoth/wesnoth#12338 (master - 4d48ed1 : Charles Dang): The build was broken.
20161208 04:33:33< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/182169804
20161208 04:33:33-!- travis-ci [~travis-ci@ec2-54-81-32-26.compute-1.amazonaws.com] has left #wesnoth-dev []
20161208 04:35:18< vultraz> src/tests/test_config.cpp(117): error in "test_config_attribute_value": check x_int == 0 failed [2112454933 != 0]
20161208 04:35:19< vultraz> src/tests/test_config.cpp(119): error in "test_config_attribute_value": check x_dbl == 1.23456789012345678e18 failed [2112454933 != 1.2345678901234568e+18]
20161208 04:35:21< vultraz> src/tests/test_config.cpp(124): error in "test_config_attribute_value": check x_sll == 0ll failed [-1 != 0]
20161208 04:35:22< vultraz> src/tests/test_config.cpp(128): error in "test_config_attribute_value": check x_int == 0 failed [-1 != 0]
20161208 04:35:24< vultraz> src/tests/test_config.cpp(130): error in "test_config_attribute_value": check x_dbl == 1e20 failed [-1 != 1e+20]
20161208 04:35:25< vultraz> ehh??
20161208 04:43:00< vultraz> c["x"] = "01234567890123456789";
20161208 04:43:06< vultraz> 	x_int = c["x"].to_int();
20161208 04:43:07< vultraz> 		BOOST_CHECK_EQUAL(x_int, 0);
20161208 04:43:11< vultraz> how would that ever equal 0
20161208 04:43:13< vultraz> o_O
20161208 04:44:29< vultraz> more importantly, how do you get 2112454933 
20161208 04:57:47-!- JyrkiVesterinen [~JyrkiVest@87-100-161-240.bb.dnainternet.fi] has joined #wesnoth-dev
20161208 05:08:22< JyrkiVesterinen> vultraz: You are getting an integer overflow.
20161208 05:08:33< JyrkiVesterinen> 01234567890123456789 is too large a number to represent with 32 bits.
20161208 05:09:45< JyrkiVesterinen> Apparently the previous implementation of lexical_cast_default detected out-of-range values and returned a default value (0 in this case) when such a string was passed.
20161208 05:10:41< JyrkiVesterinen> 2112454933 may be the remainder of the value, i.e. what you get when you keep only the last 32 bits of the integer.
20161208 05:15:18-!- Shiki [~Shiki@141.39.226.226] has left #wesnoth-dev ["Verlassend"]
20161208 05:15:34-!- travis-ci [~travis-ci@ec2-54-198-213-238.compute-1.amazonaws.com] has joined #wesnoth-dev
20161208 05:15:35< travis-ci> gfgtdf/wesnoth-old#722 (master - f504fe7 : gfgtdf): The build was fixed.
20161208 05:15:35< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth-old/builds/182176018
20161208 05:15:35-!- travis-ci [~travis-ci@ec2-54-198-213-238.compute-1.amazonaws.com] has left #wesnoth-dev []
20161208 05:51:22-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has joined #wesnoth-dev
20161208 05:58:25-!- JyrkiVesterinen [~JyrkiVest@87-100-161-240.bb.dnainternet.fi] has quit [Quit: .]
20161208 06:08:04< vultraz> hm
20161208 06:08:07< vultraz> need that be added?
20161208 06:22:21-!- irker819 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161208 06:32:52-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has quit [Remote host closed the connection]
20161208 06:36:07-!- nore [~ncourant@sas.eleves.ens.fr] has quit [Quit: WeeChat 1.4]
20161208 06:41:20-!- nore [~ncourant@sas.eleves.ens.fr] has joined #wesnoth-dev
20161208 07:33:24-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has joined #wesnoth-dev
20161208 07:35:43-!- JyrkiVesterinen [~JyrkiVest@85-76-48-234-nat.elisa-mobile.fi] has joined #wesnoth-dev
20161208 07:38:09-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has quit [Ping timeout: 258 seconds]
20161208 07:39:49< JyrkiVesterinen> 20161208 06:08:07< vultraz> need that be added?
20161208 07:40:17< celticminstrel> gfgtdf: I assume the IF_ALLIED macro predates side filters or something; it should be rewritten to use them.
20161208 07:40:28< JyrkiVesterinen> Well, there is a unit test to ensure that lexical_cast_default returns the default value if the value extracted from the string is out of range.
20161208 07:40:44< JyrkiVesterinen> So, yes, I think your implementation needs to support it.
20161208 07:41:00< celticminstrel> vultraz: You should probably also put back the unit tests.
20161208 07:41:27< JyrkiVesterinen> It doesn't make sense to write tests for cases you don't care about, which means that someone specifically wanted lexical_cast_default to handle OOR values.
20161208 07:43:04< celticminstrel> vultraz: It doesn't make any sense to remove the unit tests just because the implementation underlying it changed.
20161208 07:43:25< celticminstrel> vultraz: Also, seriously, add a unit tests project to the CBP workspace.
20161208 07:49:04< vultraz> celticminstrel: the "new" impl has its own tests
20161208 07:49:31< celticminstrel> Oh, is that so?
20161208 07:49:32< vultraz> src/tests/test_lexical_cast.cpp
20161208 07:49:41< celticminstrel> Well, does the new implementation test the out-of-range values thing?
20161208 07:49:45< celticminstrel> Maybe it should.
20161208 07:49:50< celticminstrel> If the old one did.
20161208 07:50:01< vultraz> no
20161208 07:50:12< vultraz> also, this is a test failure in the config attribute value tests
20161208 07:50:16< vultraz> NOT the lexical_cast tests
20161208 07:50:20< celticminstrel> Fun!
20161208 07:50:44< celticminstrel> Though it could be related to lexical_cast.
20161208 07:50:51< vultraz> the problem is to_*() uses lexical_cast_default for one case
20161208 07:51:02< vultraz> meaning to_int() and stuff will currently provided bad results in case of overflow
20161208 07:52:55< celticminstrel> So maybe you should in fact add the out-of-range tests in the new implementation.
20161208 07:53:04< celticminstrel> Also, seriously, set up CBP to build tests.
20161208 07:53:54< vultraz> what good will that do me
20161208 07:54:01< vultraz> if I can't actually run them
20161208 07:54:25< celticminstrel> Why wouldn't you be able to run them?
20161208 07:54:32< vultraz> how do you run them?
20161208 07:54:55< celticminstrel> How do you run wesnoth?
20161208 07:55:07< celticminstrel> Or wesnothd?
20161208 07:55:12< celticminstrel> It's the same really.
20161208 07:55:14< vultraz> I see
20161208 07:55:42< celticminstrel> The tests produce an executable file that does the work of checking if the tests pass.
20161208 08:13:05-!- louis94 [~~louis94@91.178.241.149] has joined #wesnoth-dev
20161208 08:14:52-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20161208 08:17:19-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20161208 08:17:19< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Release Charles Dang 4d48ed1: Cleaned up util.hpp includes Failed
20161208 08:17:19< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-24
20161208 08:17:19< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/4d48ed13197656cf190a63505dd45e675a7072e9
20161208 08:17:23-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20161208 08:17:47-!- louis94 [~~louis94@91.178.241.149] has quit [Client Quit]
20161208 08:17:59-!- louis94 [~~louis94@91.178.241.149] has joined #wesnoth-dev
20161208 08:22:40-!- louis94 [~~louis94@91.178.241.149] has quit [Ping timeout: 256 seconds]
20161208 08:24:20-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20161208 08:24:20< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Debug Charles Dang 4d48ed1: Cleaned up util.hpp includes Failed
20161208 08:24:20< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-24
20161208 08:24:20< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/4d48ed13197656cf190a63505dd45e675a7072e9
20161208 08:24:25-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20161208 08:28:05< vultraz> anyway, I don't know how to detect overflow
20161208 08:39:50-!- louis94 [~~louis94@91.178.241.149] has joined #wesnoth-dev
20161208 08:44:11< JyrkiVesterinen> I'm not sure, but I think the conversion ends up using this template specialization: https://github.com/wesnoth/wesnoth/blob/10abf90ff30e0c728dd58ff5c60d9104b0e515d5/src/lexical_cast.hpp#L257-L271
20161208 08:44:24< JyrkiVesterinen> http://en.cppreference.com/w/cpp/string/byte/strtol
20161208 08:44:39< JyrkiVesterinen> "If the converted value falls out of range of corresponding return type, a range error occurs (setting errno to ERANGE) and LONG_MAX, LONG_MIN, LLONG_MAX or LLONG_MIN is returned."
20161208 08:45:46< JyrkiVesterinen> In addition, strtol() always returns a long, and the code truncates it to int without checking for overflow.
20161208 08:46:53< JyrkiVesterinen> For the long-to-int conversion, the overflow check can be done by simply comparing the long value to INT_MIN and INT_MAX (in <climits>).
20161208 08:52:58-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has joined #wesnoth-dev
20161208 08:52:59-!- RatArmy_ [~ratarmy@om126211125019.13.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20161208 08:58:39-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has quit [Ping timeout: 258 seconds]
20161208 08:59:46-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20161208 08:59:46< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Release Charles Dang 4d48ed1: Cleaned up util.hpp includes Failed
20161208 08:59:46< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-25
20161208 08:59:46< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/4d48ed13197656cf190a63505dd45e675a7072e9
20161208 08:59:50-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20161208 09:08:14-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20161208 09:08:14< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Debug Charles Dang 4d48ed1: Cleaned up util.hpp includes Failed
20161208 09:08:14< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-25
20161208 09:08:14< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/4d48ed13197656cf190a63505dd45e675a7072e9
20161208 09:08:18-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20161208 09:41:35-!- serin| [~serin@209.77.159.143.dyn.plus.net] has quit [Ping timeout: 258 seconds]
20161208 09:44:12-!- JyrkiVesterinen [~JyrkiVest@85-76-48-234-nat.elisa-mobile.fi] has quit [Quit: .]
20161208 10:19:55-!- JyrkiVesterinen [~JyrkiVest@85-76-48-234-nat.elisa-mobile.fi] has joined #wesnoth-dev
20161208 10:28:39-!- serin| [~serin@209.77.159.143.dyn.plus.net] has joined #wesnoth-dev
20161208 10:28:58-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161208 10:45:06-!- RatArmy_ [~ratarmy@om126204168069.6.openmobile.ne.jp] has joined #wesnoth-dev
20161208 11:38:11-!- Duthlet [~Duthlet@dslb-146-060-035-062.146.060.pools.vodafone-ip.de] has joined #wesnoth-dev
20161208 12:03:57-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Remote host closed the connection]
20161208 12:04:48-!- Nikitaw99 [~Nikitaw99@ppp85-140-3-133.pppoe.mtu-net.ru] has joined #wesnoth-dev
20161208 12:25:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161208 12:35:35-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161208 12:37:40-!- louis94 [~~louis94@91.178.241.149] has quit [Ping timeout: 256 seconds]
20161208 12:51:45-!- irker892 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161208 12:51:45< irker892> wesnoth: Wedge009 wesnoth:master 4ee8ee7e71ba / projectfiles/VC12/ (wesnoth.vcxproj wesnoth.vcxproj.filters): Updating VC project. https://github.com/wesnoth/wesnoth/commit/4ee8ee7e71baec5f684d33ae2d80f5d7df139af9
20161208 12:55:30-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has joined #wesnoth-dev
20161208 13:00:09-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has quit [Ping timeout: 258 seconds]
20161208 13:06:58-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161208 13:21:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161208 13:39:48-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20161208 13:46:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161208 13:50:12-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Read error: Connection reset by peer]
20161208 13:51:28-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20161208 13:53:09-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161208 13:53:16-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161208 13:54:53-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161208 13:55:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 245 seconds]
20161208 13:55:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161208 13:57:03-!- Shiki [~Shiki@141.39.226.226] has quit [Client Quit]
20161208 14:03:23-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
20161208 14:28:33-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20161208 14:28:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161208 14:36:23-!- gfgtdf [~chatzilla@x4e368239.dyn.telefonica.de] has joined #wesnoth-dev
20161208 14:37:03< gfgtdf> vultraz: the new lexcail_cast implementaion has a bug: it uses int res = strtoll(...) but it shodul be long long res = strtoll = strtoll(....)
20161208 14:37:15< gfgtdf> vultraz: same for strtoull
20161208 14:37:19< vultraz> uh
20161208 14:37:21< vultraz> why two calls?
20161208 14:37:29< gfgtdf> vultraz: hmm no
20161208 14:37:47< gfgtdf> i meant the return type shodule be ong long and not itn
20161208 14:37:52< gfgtdf> int*
20161208 14:37:56< JyrkiVesterinen> I mentioned already today that the implementation truncates long to int without checking for overflow.
20161208 14:38:01< vultraz> could someone else fix this
20161208 14:38:05< vultraz> I'll probably get it wrong
20161208 14:38:22< JyrkiVesterinen> 20161208 08:45:46< JyrkiVesterinen> In addition, strtol() always returns a long, and the code truncates it to int without checking for overflow.
20161208 14:38:46< vultraz> oh, right, you said compare against INT_MAX...
20161208 14:38:52< JyrkiVesterinen> If no one else gets around to fixing it first, I'll do it in the evening, about three hours from now.
20161208 14:38:57< vultraz> but why does the function need to return long long
20161208 14:39:02< vultraz> shouldn't it be int :/
20161208 14:41:17< JyrkiVesterinen> gfgtdf is right. I missed this earlier today.
20161208 14:41:18< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/master/src/lexical_cast.hpp#L249-L272
20161208 14:41:32< JyrkiVesterinen> To be exact, the return type it the "To" template parameter.
20161208 14:41:35< JyrkiVesterinen> *is
20161208 14:41:59< irker892> wesnoth: gfgtdf wesnoth:master 3e4d10e10030 / src/lexical_cast.hpp: fix lexical_cast<long long> https://github.com/wesnoth/wesnoth/commit/3e4d10e100307350da6c4c499bca6416af061760
20161208 14:42:13< JyrkiVesterinen> I'm not sure if it matters, though. There are distinct template specializations for long long.
20161208 14:43:50< JyrkiVesterinen> ...oh, right. The specializations for long long were wrong, too. Gfg just fixed them.
20161208 14:43:53< JyrkiVesterinen> Thanks. :)
20161208 14:44:07< gfgtdf> i wonder wheterh it still bahves correcty with size_t, from the code it looks to me liek lexical_cast<size_t> would do into the 32 bit case
20161208 14:44:19< vultraz> what is this "performance penalty" the code speaks of?
20161208 14:44:23< vultraz> " * @note is separate from the other unsigned types since a unsigned long long
20161208 14:44:25< vultraz>  * has a performance penalty at 32 bit systems."
20161208 14:45:02< gfgtdf> vultraz: that code uses strtol on <= 32 bit types and strtoll on 64 bit types
20161208 14:45:10< JyrkiVesterinen> In 32-bit builds, size_t should be exactly equal to unsigned int and the compiler should select the generic version.
20161208 14:45:28< gfgtdf> JyrkiVesterinen: yes but my qorry way about 64 it build
20161208 14:45:39< JyrkiVesterinen> And in 64-bit builds, size_t should be equal to long long and the compiler should pick the long long specialization.
20161208 14:45:47< JyrkiVesterinen> *unsigned long long
20161208 14:45:57< vultraz> I see
20161208 14:45:57< gfgtdf> "go into the 32 bit case" meant "should select the generic (32 bit) version"
20161208 14:47:13< vultraz> random: why do we use gcc's __builtin_expect in some 
20161208 14:47:16< vultraz> code
20161208 14:47:57< gfgtdf> JyrkiVesterinen: afaik sze_t is a disstinc type and not a typesef of one of the other integer types
20161208 14:48:40< gfgtdf> JyrkiVesterinen: even if they have the ame length
20161208 14:49:10< gfgtdf> vultraz: its an optimisation to tell the compiler which codeapthis more likeley
20161208 14:49:24< JyrkiVesterinen> gfgtdf: It doesn't make sense to me though. There shouldn't be any reason why the compiler would treat two integer types with the same signedness and length as distinct.
20161208 14:55:35< JyrkiVesterinen> I did a quick check. I was right. The compiler considers size_t equivalent to the corresponding unsigned integer type.
20161208 14:55:36< JyrkiVesterinen> http://ideone.com/AVV610
20161208 14:55:47< gfgtdf> JyrkiVesterinen: hmm wait i think i rmembered wrongly, it was wchar_t that is not an integral type
20161208 14:55:50< JyrkiVesterinen> (Also, now I know that Ideone compiles to 32-bit code.)
20161208 15:03:26< irker892> wesnoth: ln-zookeeper wesnoth:master 309b04e45be0 / data/core/images/items/chest-open.png: Added an open version of the chest item https://github.com/wesnoth/wesnoth/commit/309b04e45be04272ae4fa35f0cbd064c590cac1c
20161208 15:07:41-!- RatArmy_ [~ratarmy@om126204168069.6.openmobile.ne.jp] has quit [Ping timeout: 246 seconds]
20161208 15:14:50< celticminstrel> gfgtdf: Did you see my response on IF_ALLIED?
20161208 15:15:09< gfgtdf> celticminstrel: no will check
20161208 15:15:52-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161208 15:21:59-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 258 seconds]
20161208 15:29:10-!- JyrkiVesterinen [~JyrkiVest@85-76-48-234-nat.elisa-mobile.fi] has quit [Quit: .]
20161208 15:30:18-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161208 15:38:53-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161208 15:40:34-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has joined #wesnoth-dev
20161208 15:59:26-!- travis-ci [~travis-ci@ec2-184-73-62-195.compute-1.amazonaws.com] has joined #wesnoth-dev
20161208 15:59:27< travis-ci> wesnoth/wesnoth#12340 (master - 3e4d10e : gfgtdf): The build is still failing.
20161208 15:59:27< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/182296715
20161208 15:59:27-!- travis-ci [~travis-ci@ec2-184-73-62-195.compute-1.amazonaws.com] has left #wesnoth-dev []
20161208 16:07:12-!- gimemor [~gimemor@host-95-152-57-4.dsl.sura.ru] has joined #wesnoth-dev
20161208 16:22:39-!- Shiki [~Shiki@141.39.226.226] has quit [Remote host closed the connection]
20161208 16:45:25-!- serin| [~serin@209.77.159.143.dyn.plus.net] has quit [Ping timeout: 248 seconds]
20161208 16:45:31-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20161208 16:45:31< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Release ln-zookeeper 309b04e: Added an open version of the chest item Succeeded
20161208 16:45:31< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-25
20161208 16:45:31< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/309b04e45be04272ae4fa35f0cbd064c590cac1c
20161208 16:45:35-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20161208 16:46:23-!- serin| [~serin@209.77.159.143.dyn.plus.net] has joined #wesnoth-dev
20161208 16:49:52-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has quit [Read error: Connection reset by peer]
20161208 16:50:25-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has joined #wesnoth-dev
20161208 16:50:53-!- Appleman1234 [~Appleman1@KD106161201200.au-net.ne.jp] has quit [Ping timeout: 245 seconds]
20161208 16:51:34-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has quit [Remote host closed the connection]
20161208 16:54:03-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has joined #wesnoth-dev
20161208 17:12:56-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20161208 17:12:56< Appveyor> The Battle for Wesnoth (Visual Studio 2015) - Debug ln-zookeeper 309b04e: Added an open version of the chest item Succeeded
20161208 17:12:56< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-25
20161208 17:12:56< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/309b04e45be04272ae4fa35f0cbd064c590cac1c
20161208 17:13:00-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20161208 17:14:53-!- JyrkiVesterinen [~jyrki@87-100-152-132.bb.dnainternet.fi] has joined #wesnoth-dev
20161208 17:25:58< irker892> wesnoth: gfgtdf wesnoth:master 28df71d13aa8 / data/gui/widget/unit_preview_pane.cfg src/gui/widgets/unit_preview_pane.cpp: add unit preview pane hp xp mp tooltips (#897) https://github.com/wesnoth/wesnoth/commit/28df71d13aa8ba786cb6f2aceca5332b88989cb0
20161208 17:28:04-!- louis94 [~~louis94@91.178.241.149] has joined #wesnoth-dev
20161208 17:30:43< bumbadadabum> while I'm barely around recently, I would like to say I find SotA a good choice for a new mainline campaign
20161208 17:30:56< bumbadadabum> I quite enjoyed it
20161208 17:31:47< celticminstrel> Haven't there also been preparations for including OoA?
20161208 17:48:42-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20161208 17:48:42< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Release ln-zookeeper 309b04e: Added an open version of the chest item Succeeded
20161208 17:48:42< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-26
20161208 17:48:42< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/309b04e45be04272ae4fa35f0cbd064c590cac1c
20161208 17:48:47-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20161208 17:54:18-!- travis-ci [~travis-ci@ec2-54-87-113-211.compute-1.amazonaws.com] has joined #wesnoth-dev
20161208 17:54:19< travis-ci> wesnoth/wesnoth#12342 (master - 309b04e : ln-zookeeper): The build is still failing.
20161208 17:54:19< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/182302382
20161208 17:54:19-!- travis-ci [~travis-ci@ec2-54-87-113-211.compute-1.amazonaws.com] has left #wesnoth-dev []
20161208 17:56:36-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 268 seconds]
20161208 18:04:07< EliDupree> How do filters for skirmisher abilities work? Are they based on the starting position of the unit, or the position it's trying to skirmish through?
20161208 18:05:22< EliDupree> I don't see anything in the code that makes the checks depend on the mid-movement position, but I seem to remember the Distract ability working correctly in Ageless, so I'm confused
20161208 18:09:50-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161208 18:09:55< zookeeper> well, gotta be the position it's trying to skirmish through
20161208 18:10:23< zookeeper> i'd expect the relevant code to reside wherever ZoC rules are enforced
20161208 18:10:56< EliDupree> … If I use lua_function in the filter, what does it observe?
20161208 18:12:02< zookeeper> you're about to find out, perhaps :p
20161208 18:12:12< EliDupree> -_-
20161208 18:14:00-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161208 18:14:15-!- Appveyor [~Appveyor@74.205.54.20] has joined #wesnoth-dev
20161208 18:14:15< Appveyor> The Battle for Wesnoth (Visual Studio 2013) - Debug ln-zookeeper 309b04e: Added an open version of the chest item Succeeded
20161208 18:14:15< Appveyor> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-26
20161208 18:14:15< Appveyor> Commit: https://gitHub.com/wesnoth/wesnoth/commit/309b04e45be04272ae4fa35f0cbd064c590cac1c
20161208 18:14:18< celticminstrel> What did distract do?
20161208 18:14:19-!- Appveyor [~Appveyor@74.205.54.20] has left #wesnoth-dev []
20161208 18:14:45< EliDupree> It lets your OTHER units skirmish in hexes adjacent to the distract unit
20161208 18:14:46< zookeeper> nullify enemy ZoC in adjacent hexes
20161208 18:17:12< celticminstrel> Does get_ability_bool() return true if an adjacent unit confers the ability?
20161208 18:17:37< celticminstrel> It looks like checks for skirmisher are run as though the unit is at the mid-movement position.
20161208 18:18:05< celticminstrel> So if get_ability_bool() for one unit also returns true if an adjacent unit confers the ability, then I'd expect it to Just Wor.
20161208 18:18:07< celticminstrel> ^+k
20161208 18:18:43< EliDupree> hmm
20161208 18:19:30< EliDupree> I wonder if the lua_function can read the mid-movement position in any way? Maybe by reading $unit.x?
20161208 18:20:51< EliDupree> I have an ability idea that I COULD do by using a complex filter_adjacent, but I seem to remember that being a bit slow, and skirmisher is checked zillions of times (Lua functions were faster for some other things I did)
20161208 18:21:36< EliDupree> (Basically is a partial skirmisher ability that doesn't let you pass between 2 units that have only one hex between them)
20161208 18:22:14< zookeeper> doesn't sound like you'd need any lua for that, no?
20161208 18:22:34< EliDupree> Yeah, like I said
20161208 18:22:45< zookeeper> oh, right, i misread
20161208 18:23:47< EliDupree> I kind of want an ability like "skirmish that works unless you move from one zone of control'd hex to another", but I don't see a way to do that, with or without Lua
20161208 18:24:55< zookeeper> "skirmish that works unless you move from one zone of control'd hex to another", or "skirmish that works unless you move from one zone of control'd hex to another zone of control'd hex of the same enemy unit"?
20161208 18:25:11< EliDupree> The former
20161208 18:25:16< zookeeper> right, okay
20161208 18:25:23< celticminstrel> Doesn't seem like the mid-movement location would be accessible to either Lua or WFL.
20161208 18:25:34< EliDupree> There's no way to do the latter either though, is there?
20161208 18:25:43< celticminstrel> The unit itself is passed to the adjacency filter, but not its faked location.
20161208 18:25:47-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has quit [Remote host closed the connection]
20161208 18:25:49< celticminstrel> As far as I can tell.
20161208 18:25:57< EliDupree> aww
20161208 18:26:06< celticminstrel> (The adjacent units were already calculated from that faked location though.)
20161208 18:26:20< zookeeper> i dunno whether one would be easier or harder to implement, it's just that there's a marked difference in the kind of moves each allows
20161208 18:26:32< EliDupree> sure
20161208 18:26:43-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has joined #wesnoth-dev
20161208 18:27:57< celticminstrel> Pretty sure $unit.x or $other_unit.x would give the unit's real location.
20161208 18:28:03< celticminstrel> ie, the starting point of the move.
20161208 18:29:21< zookeeper> i think that ability is bad because it involves weird hidden state. like, if you load a save and your unit is next to an enemy, either it can still move into a ZoC hex without stopping, or it can't, depending on what the previous move was.
20161208 18:29:42< EliDupree> Which ability?
20161208 18:30:09< zookeeper> hrhm, wait nevermind.
20161208 18:30:14< zookeeper> i think i was misthinking it
20161208 18:30:15< celticminstrel> Skirmisher that can't move from a ZoC hex to a ZoC hex.
20161208 18:30:19< celticminstrel> Presumably.
20161208 18:31:00< celticminstrel> But yeah, if it's in a ZoC hex when you save, that means it can't move into a ZoC hex without first entering a non-ZoC hex.
20161208 18:31:25< EliDupree> It's a perfectly simple and well-defined ability, it's just that we have no features for implementing it
20161208 18:32:17< zookeeper> yeah, looks like there's no way to do it since skirmisher can be conditional only based on the hex being entered
20161208 18:32:30< EliDupree> Since all abilities are currently only determined based on ONE current position, not starting hex and ending hex
20161208 18:33:00< EliDupree> I could effectively do it using enter_hex/exit_hex, but that would make the UI be incorrect
20161208 18:33:21< celticminstrel> From looking at the code I wonder if $this_unit actually works when the filter is being matched at a faked location...
20161208 18:34:22< zookeeper> well of course in theory you could do it by pre-calculating the hexes each unit can enter/exit and give them skirmisher on those specific coordinates, and then update those whenever units are created/killed, but i don't think you want to go there... :>
20161208 18:34:50< celticminstrel> And whenever units are moved.
20161208 18:38:18< EliDupree> haha
20161208 18:39:03< EliDupree> That's actually a decent idea and not even all that difficult since I already implemented pathfinding for EoHS! Let me just think if there are any catches
20161208 18:39:49< EliDupree> One catch for that kind of thing is whether it gets updated when you undo, but fixing it during a select event might deal with that
20161208 18:40:08< EliDupree> (If you undo a move, do you have to re-select the unit to move it to a different place?)
20161208 18:40:41< zookeeper> well you can just update it on both undo and redo
20161208 18:40:47< EliDupree> how?
20161208 18:41:05< EliDupree> I didn't know there was any way to trigger a script on under/redo
20161208 18:41:19< zookeeper> there is now: https://wiki.wesnoth.org/DirectActionsWML#.5Bon_undo.5D
20161208 18:41:33< EliDupree> neat
20161208 18:41:59< zookeeper> as you can imagine, you might have to be pretty careful with it
20161208 18:42:10< EliDupree> right
20161208 18:42:38< EliDupree> OOS if the calculations are EVER imperfect
20161208 18:42:41< zookeeper> anyway, with that you can do Anything(tm) but the code can get a bit hairy sometimes: https://github.com/wesnoth/wesnoth/blob/master/data/campaigns/Under_the_Burning_Suns/utils/abilities.cfg#L617
20161208 18:43:54< EliDupree> Not hairy if you behave sensibly by doing it in lua :P
20161208 18:44:03< zookeeper> maybe!
20161208 18:45:18< EliDupree> I'm actually not sure your idea works though? I'm not sure the ability can be perfectly mimicked by simply setting skirmisher on/off in each hex
20161208 18:46:31< zookeeper> yeah i'm staring at a hexmap right now and i think it'd not work
20161208 18:46:56< EliDupree> Yeah! Imagine you are adjacent to the ONE hex that is not in zone of control. With the proper ability, you could move into the non-ZoC X and back into a ZoC hex that is adjacent to both your starting position and the safe hex, , but it would cost 2 moves
20161208 18:46:58< zookeeper> because, like... it just doesn't, it's a nonsense idea i think :P
20161208 18:47:25< EliDupree> No matter how you set the skirmisher on/off, that motion would always cost either 1 move for all your moves
20161208 18:47:56< zookeeper> oh hey what about this: simulate it with teleport? :D
20161208 18:48:13< EliDupree> I have ALSO considered that and it has a similar problem
20161208 18:48:28< zookeeper> but with teleport you can filter on both the source and destination hexes
20161208 18:48:29< EliDupree> i.e. Teleport not being able to have an increased movement cost
20161208 18:48:29< gfgtdf> EliDupree: you developing for 1.13 only now?
20161208 18:48:36< zookeeper> ah, true
20161208 18:48:54< EliDupree> gfgtdf: No, but I am willing to consider future plans
20161208 18:49:09< gfgtdf> ok
20161208 18:49:45< Shiki> Is it possible to calculate the missing movement costs and set them with modify_unit ?
20161208 18:50:02< EliDupree> They can only be set per-terrain
20161208 18:50:20< zookeeper> maybe you could just change the ability to be something like "skirmisher, but only on hexes costing 1MP" :p it's still kind of light version of skirmisher. or maybe "skirmisher, but only through ZoC projected by enemy which has >1MP on their current terrain"
20161208 18:50:23< EliDupree> Not per-hex as would be desirable
20161208 18:51:42< EliDupree> Now, what I COULD do
20161208 18:51:58-!- esr [~esr@wesnoth/developer/esr] has quit [Ping timeout: 265 seconds]
20161208 18:52:41< EliDupree> Is make teleport to a specific collection of hexes, but make the unit only have one movement point total
20161208 18:53:11< EliDupree> And recalculate the real-moves-left/teleporting after each move you make, based on my own rules'
20161208 18:53:35< EliDupree> That's even 1.12 compatible, just super weird
20161208 18:54:07-!- Duthlet [~Duthlet@dslb-146-060-035-062.146.060.pools.vodafone-ip.de] has quit [Quit: leaving]
20161208 18:54:17< EliDupree> Except maybe for the undo issue
20161208 18:54:20-!- Nikitaw99 [~Nikitaw99@ppp85-140-3-133.pppoe.mtu-net.ru] has quit [Read error: Connection reset by peer]
20161208 18:55:32-!- louis94 [~~louis94@91.178.241.149] has quit [Ping timeout: 246 seconds]
20161208 18:56:28< EliDupree> That would allow me to make almost any movement rules I want to. The only exception is that I can't stop the unit from moving to adjacent hexes
20161208 18:58:21< EliDupree> ...I could even draw my own custom footprint paths when you mouse over the hexes!
20161208 19:01:54< EliDupree> ... This raises new possibilities for my idea of making units that act like they are multiple hexes big.
20161208 19:03:16< zookeeper> i've had this idea of a multi-hex tortoise-like boss unit for the last 10 years or so and i still have never made it
20161208 19:04:03-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20161208 19:04:03-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Changing host]
20161208 19:04:03-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20161208 19:04:25< zookeeper> (tortoise because you could then "kill" its limbs which would just retract for a few turns into the invulnerable central shell)
20161208 19:05:26-!- louis94 [~~louis94@91.178.241.149] has joined #wesnoth-dev
20161208 19:06:24< JyrkiVesterinen> "multi-hex tortoise-like boss" reminds me of this: https://www.youtube.com/watch?v=AyQbf0nsdu4
20161208 19:06:33< JyrkiVesterinen> I have been in the development team of that game.
20161208 19:07:12< zookeeper> oh no, that's all wrong. it's red, not green!
20161208 19:08:31-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20161208 19:08:31-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20161208 19:08:31-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161208 19:09:58-!- travis-ci [~travis-ci@ec2-54-87-113-211.compute-1.amazonaws.com] has joined #wesnoth-dev
20161208 19:09:59< travis-ci> wesnoth/wesnoth#12343 (master - 28df71d : gfgtdf): The build has errored.
20161208 19:09:59< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/182346137
20161208 19:09:59-!- travis-ci [~travis-ci@ec2-54-87-113-211.compute-1.amazonaws.com] has left #wesnoth-dev []
20161208 19:10:06< zookeeper> but yeah, basically 4 limbs, head, tail = 7-hex boss. also another reason for the tortoiseness is that when it moves it could retract everything, bounce/slide around, and then pop out whichever limbs/heads/tails would not end up inside a wall.
20161208 19:10:55< zookeeper> so it wouldn't need to be entirely static or too easily cornered
20161208 19:25:06< Shiki> sounds interesting
20161208 19:32:32-!- louis94 [~~louis94@91.178.241.149] has quit [Ping timeout: 244 seconds]
20161208 19:49:31< JyrkiVesterinen> I'm making progress with lexical_cast fixes. Right now tests pass otherwise, but lexical_cast<double>("99999999999999999999") throws instead of rounding.
20161208 19:51:38< zookeeper> vultraz, test scenario bugs out:
20161208 19:51:39< zookeeper> 20161208 21:48:38 error general: Error while reading the WML: can't parse color string:
20161208 19:51:39< zookeeper> id = blonde
20161208 19:51:39< zookeeper> rgb = 255,255,0,255,255,128,0,0,0
20161208 19:53:29< zookeeper> perhaps whatever you've done lately removed support for rgb-style color strings, which apparently must have worked before?
20161208 19:57:49< JyrkiVesterinen> Wait a moment. It looks like lexical_cast<double> drops the fractional part and has been doing it for a long time. :S
20161208 19:58:04< JyrkiVesterinen> I'll add some unit tests for that...
20161208 20:15:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161208 20:18:31< gfgtdf> i'm quite sure that it shoudlnt not drop the fractional part, why do you think it's been doaing that for a long time ?
20161208 20:23:16< JyrkiVesterinen> The compiler chooses this template specialization: https://github.com/wesnoth/wesnoth/blob/3da8a27ae7b136e718667cd0cb48283d706e8a0e/src/lexical_cast.hpp#L219-L240
20161208 20:23:48< JyrkiVesterinen> It extracts the number with strtol(), which only retains the integral part.
20161208 20:24:30< JyrkiVesterinen> That's also the reason why my test earlier with a number that overflows long throwed bad_lexical_cast.
20161208 20:26:03-!- irker892 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161208 20:34:47< celticminstrel> Looking at that, I think it might be easier to understand if not using MPL.
20161208 20:35:23< celticminstrel> std::enable_if<std::is_same<From, char*>::value || std::is_same<From, const char*>::value>
20161208 20:35:33< celticminstrel> Or possible something involving std::remove_const
20161208 20:35:33-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has quit [Remote host closed the connection]
20161208 20:35:37< celticminstrel> ^^y
20161208 20:39:41-!- louis94 [~~louis94@91.178.241.149] has joined #wesnoth-dev
20161208 20:41:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161208 20:43:11< JyrkiVesterinen> OK, I got it fixed but broke other things...
20161208 20:43:15< JyrkiVesterinen> /home/jyrki/wesnoth/src/tests/test_config.cpp(75): error: in "test_config/test_config_attribute_value": check x_dbl == 0.0 has failed [17 != 0]
20161208 20:43:17< JyrkiVesterinen> /home/jyrki/wesnoth/src/tests/test_config.cpp(86): error: in "test_config/test_config_attribute_value": check x_dbl == 0.0 has failed [171 != 0]
20161208 20:47:03-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has joined #wesnoth-dev
20161208 20:59:38< gfgtdf> JyrkiVesterinen: maybe just adda  && is_intrgral to that specialisation?
20161208 21:00:17< gfgtdf> JyrkiVesterinen: and note that previousl we used the lexical_cast from util.hpp so lexical_cast has not been doing it for a long time
20161208 21:00:46< JyrkiVesterinen> I already added is_integral to that specialization and wrote a new specialization for floating point numbers.
20161208 21:01:13< JyrkiVesterinen> I'm currently working on rejecting hexadecimal values as the two failed unit tests require.
20161208 21:02:14< gfgtdf> JyrkiVesterinen: hmm we wouldn't we want hex support?
20161208 21:02:41< JyrkiVesterinen> Those two unit tests fail if lexical_cast<double> supports hex.
20161208 21:02:58< JyrkiVesterinen> IOW, we are explicitly testing that hex is rejected.
20161208 21:03:09< gfgtdf> JyrkiVesterinen: yes but the qurestion is why
20161208 21:03:35< gfgtdf> iceiceice: iirc you added those test do you know why we exocuitly disallow hex number of lexical_cast double ?
20161208 21:04:49< celticminstrel> Why would you want lexical_cast<double> to support hex?
20161208 21:05:12< celticminstrel> C++ itself doesn't support this. (Admittedly Java does.)
20161208 21:06:24< gfgtdf> celticminstrel: in c++ i can write int a = 0xFFEE not soure what you mean.
20161208 21:06:38< celticminstrel> gfgtdf: We're talking about double here.
20161208 21:06:49< celticminstrel> C++ does not support the 0xffeep42 syntax.
20161208 21:07:53< gfgtdf> hmm right,  somehow forgot we are talking about doubles
20161208 21:13:34< gfgtdf> celticminstrel: ub was reported in the boost unit test for the gui::tgame_stats
20161208 21:13:51< celticminstrel> Why are you telling me this.
20161208 21:13:58< celticminstrel> What kind of UB.
20161208 21:14:05< gfgtdf> celticminstrel: beasue you afaik implemented those tests
20161208 21:14:12< celticminstrel> Did I?
20161208 21:14:40< gfgtdf> celticminstrel: https://gna.org/bugs/?25105
20161208 21:19:21-!- irker143 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161208 21:19:21< irker143> wesnoth: Jyrki Vesterinen wesnoth:master 8a80af7ace1a / src/tests/test_lexical_cast.cpp: More tests for lexical_cast https://github.com/wesnoth/wesnoth/commit/8a80af7ace1ac6ffd756c4ac0ee746959ba6cfe5
20161208 21:19:21< irker143> wesnoth: Jyrki Vesterinen wesnoth:master bfeea429382b / src/ (lexical_cast.hpp tests/test_lexical_cast.cpp): Reimplement lexical_cast https://github.com/wesnoth/wesnoth/commit/bfeea429382b70521eb9e6d5340c54cf820d8c76
20161208 21:20:21< celticminstrel> Wait, why is the lexical_caster::operator() calling lexical_cast.
20161208 21:20:49< JyrkiVesterinen> The implementations can call each other.
20161208 21:20:54< irker143> wesnoth: gfgtdf wesnoth:master 8b472e8c305b / src/tests/gui/test_gui2.cpp: initilize values in dialog_tester https://github.com/wesnoth/wesnoth/commit/8b472e8c305bd012fce7b362c32bccbea9e414a4
20161208 21:21:18-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
20161208 21:21:32< JyrkiVesterinen> Previously the std::string implementations relayed to the const char* implementations. I changed it to the opposite order.
20161208 21:21:38< celticminstrel> Oh, I see, the cnar* specialization is calling the string specialization, okay.
20161208 21:21:40< celticminstrel> ^char
20161208 21:22:05-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161208 21:25:23< irker143> wesnoth: gfgtdf wesnoth:master c3174b45efab / src/gui/widgets/window.cpp: fix memleak in gui2 delay event_event https://github.com/wesnoth/wesnoth/commit/c3174b45efab882ccd33bbeb272610afb74375b6
20161208 21:30:10< gfgtdf> JyrkiVesterinen: why did you change that order? Also did you cahgne tht it still bahves tha same way? in paricular, does it still reject something liek "213124ASDGDSG" ?
20161208 21:30:57< JyrkiVesterinen> I decided to use the C++11 functions (std::stol(), etc.) for the conversion instead of C functions like strtol().
20161208 21:31:06< celticminstrel> Makes sense to me.
20161208 21:31:36< JyrkiVesterinen> Among other things, the C++ functions report overflow by throwing exceptions instead of changing errno.
20161208 21:31:46< JyrkiVesterinen> Thus, detecting overflow is easier.
20161208 21:32:38< JyrkiVesterinen> Yes, the functions should still behave in the same way. In fact, according to cppreference.com the C++ functions call the older C functions internally.
20161208 21:33:04< JyrkiVesterinen> http://en.cppreference.com/w/cpp/string/byte/strtol
20161208 21:33:59< JyrkiVesterinen> That was a wrong link. I meant to post this:
20161208 21:33:59< gfgtdf> JyrkiVesterinen: yes but afaik they don't check "*endptr != '\0'"
20161208 21:34:01< JyrkiVesterinen> http://en.cppreference.com/w/cpp/string/basic_string/stol
20161208 21:35:35< gfgtdf> JyrkiVesterinen: in particular std::stoi("9+6") for example returns 9, 
20161208 21:36:16< JyrkiVesterinen> Hmm, all right, I didn't know that.
20161208 21:36:37< gfgtdf> JyrkiVesterinen: i man thats not nessarily an issue but you have to check it doent break things
20161208 21:36:47< JyrkiVesterinen> I'd still like to keep using the C++ functions here, though. The C functions are ancient and their interface is quite bad.
20161208 21:37:24< gfgtdf> JyrkiVesterinen: except the errno think its about the same interface as the c++ function.
20161208 21:37:52< JyrkiVesterinen> Indeed, there probably isn't much code that relies on "213124ASDGDSG" not being accepted as a number.
20161208 21:38:16< JyrkiVesterinen> I'll just leave the lexical_cast implementation as it is for now. Let me know if something broke.
20161208 21:41:11< celticminstrel> ...why does stoi("9+6") return 9? :|
20161208 21:43:14< loonycyborg> you expect it to return 15? :P
20161208 21:43:17< loonycyborg> or throw?
20161208 21:43:21< celticminstrel> Throw.
20161208 21:43:37< loonycyborg> Perhaps it misparses it as e notation
20161208 21:45:26< celticminstrel> There's not e, so...
20161208 21:45:43< celticminstrel> ...also, if it did, it'd return 9000000000000000 instead.
20161208 21:46:04< loonycyborg> if it's a misparse then there could be any result
20161208 21:46:09< celticminstrel> (Except that that wouldn't actually fit.)
20161208 21:46:13< celticminstrel> ^no
20161208 21:48:38< irker143> wesnoth: gfgtdf wesnoth:master 66494fc34fd0 / src/gui/widgets/matrix.cpp: fix ub in matrix widget https://github.com/wesnoth/wesnoth/commit/66494fc34fd0eb66d37b4b11d1b71ffb3e59f283
20161208 21:49:06< celticminstrel> So basically, you need to use the second argument to see if the whole string was consumed.
20161208 21:55:17-!- gimemor [~gimemor@host-95-152-57-4.dsl.sura.ru] has quit [Ping timeout: 248 seconds]
20161208 21:58:16-!- Shiki [~Shiki@141.39.226.226] has quit [Remote host closed the connection]
20161208 22:12:00-!- louis94 [~~louis94@91.178.241.149] has quit [Ping timeout: 250 seconds]
20161208 22:16:57-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161208 22:16:57-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20161208 22:26:52-!- JyrkiVesterinen [~jyrki@87-100-152-132.bb.dnainternet.fi] has quit [Quit: .]
20161208 22:30:35< EliDupree> Hmm. I'd like to make a enter_hex event that prevents undoing, but doesn't necessarily interrupt the move.
20161208 22:32:34< zookeeper> uh... so if the event triggers mid-move, and you undo the move, it'll only undo up to that hex?
20161208 22:34:21< EliDupree> No, it's fine if the whole move is impossible to undo
20161208 22:35:20< zookeeper> right
20161208 22:35:49-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161208 22:35:53< EliDupree> I guess I could make it set a variable, then having moveto event that prevents undoing if that variable was set for that unit this turn
20161208 22:35:59-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161208 22:36:03< zookeeper> was just gonna suggest that
20161208 22:36:14< EliDupree> :)
20161208 22:36:28< zookeeper> seems like a simple workaround, just spawn a child moveto event on the spot which filters on some flag you set
20161208 22:38:23< zookeeper> or wait, if you do it like that then you don't even need a flag?
20161208 22:39:30< EliDupree> ... right, a enter_hex event is ALWAYS followed by the related moveto event
20161208 22:40:36< EliDupree> Unless a scenario fires its own fake moveto event during the enter_hex event, but there's probably no reasonable way to work around things like that
20161208 22:41:37< EliDupree> With the downside being that you might be able to undo a move that didn't do anything anyway
20161208 22:44:48-!- louis94 [~~louis94@91.178.241.149] has joined #wesnoth-dev
20161208 23:05:04-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has quit [Remote host closed the connection]
20161208 23:05:40-!- travis-ci [~travis-ci@ec2-54-91-2-8.compute-1.amazonaws.com] has joined #wesnoth-dev
20161208 23:05:41< travis-ci> wesnoth/wesnoth#12344 (master - bfeea42 : Jyrki Vesterinen): The build passed.
20161208 23:05:41< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/182409727
20161208 23:05:41-!- travis-ci [~travis-ci@ec2-54-91-2-8.compute-1.amazonaws.com] has left #wesnoth-dev []
20161208 23:08:18-!- 7IZAAP3HH [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has joined #wesnoth-dev
20161208 23:27:28-!- atarocch [~atarocch@93.56.160.28] has quit [Quit: Leaving]
20161208 23:35:25-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161208 23:37:46-!- 7IZAAP3HH [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has quit [Remote host closed the connection]
20161208 23:42:47-!- Greg-Boggs [~greg_bogg@2601:1c2:f00:9780:49cc:5cbd:4b01:83a9] has joined #wesnoth-dev
20161208 23:47:03-!- travis-ci [~travis-ci@ec2-54-166-155-108.compute-1.amazonaws.com] has joined #wesnoth-dev
20161208 23:47:04< travis-ci> wesnoth/wesnoth#12345 (master - 8b472e8 : gfgtdf): The build passed.
20161208 23:47:04< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/182410390
20161208 23:47:04-!- travis-ci [~travis-ci@ec2-54-166-155-108.compute-1.amazonaws.com] has left #wesnoth-dev []
--- Log closed Fri Dec 09 00:00:51 2016