--- Log opened Fri Oct 14 00:00:22 2016
20161014 00:08:13< vultraz> I just realized... I think our display of sorting options is backwards 
20161014 00:09:31< vultraz> when the sort arrow points down, it's A ... Z. when it's pointed up, it's Z...A.
20161014 00:09:33< DeFender1031> vultraz, "Oh, oh, that's much better. Wait... wait. Oh, my! What have you done? I'm BACKWARDS. You flea-bitten furball! Only an overgrown mop-head like you would be stupid enough to..."
20161014 00:09:45< vultraz> isn't it supposed to be the other way around.
20161014 00:10:31< DeFender1031> I think most systems use down arrow to mean "ascending"
20161014 00:10:45< vultraz> but on Windows the up arrow is ascending :/
20161014 00:11:09< DeFender1031> you just said when it's down it's A-Z
20161014 00:11:43< vultraz> I'm comparing wesnoth to windows.
20161014 00:11:52< DeFender1031> oh
20161014 00:11:59< DeFender1031> hmm
20161014 00:12:05< DeFender1031> no idea, i'm on linux.
20161014 00:12:11< vultraz> in wesnoth, down arrow = A...Z. in windows, up arrow = A..Z
20161014 00:12:21< vultraz> celmin: what is it on Mac OS?
20161014 00:13:01< shadowm> Wesnoth's behavior matches Qt on Linux/X11.
20161014 00:13:23< DeFender1031> I have a few programs open here though that have that sort of sortable header, and I just tested, they all treat down arrow as A-Z, or 0-99999999999999999 or whatever
20161014 00:13:44< vultraz> then why is Windows randomly different :/
20161014 00:13:56< DeFender1031> Frankly, down for ascending makes more sense to me, as it's showing the direction of the order.
20161014 00:14:07< shadowm> I wouldn't worry about it, really.
20161014 00:14:28< shadowm> Most people will not look at the arrow, but rather where the items are heading to.
20161014 00:14:35< DeFender1031> "why is Windows randomly different" is a question which has no doubt been asked millions of times in hundreds of thousands of contexts.
20161014 00:20:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161014 00:20:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161014 00:20:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161014 00:23:10-!- irker336 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161014 00:23:10< irker336> wesnoth: Ignacio R. Morelle wesnoth:master 9542417dcd2c / src/campaign_server/ (campaign_server.cpp campaign_server.hpp): campaignd: Don't allude to signals that don't exist, on Windows https://github.com/wesnoth/wesnoth/commit/9542417dcd2c57ff2f48d294c3c8f5cc7e510d53
20161014 00:23:13< irker336> wesnoth: Ignacio R. Morelle wesnoth:master 3b741b620999 / src/campaign_server/campaign_server.hpp: campaignd: Delete copy ctor now that we're C++11 https://github.com/wesnoth/wesnoth/commit/3b741b620999faf351846fbd35b42a5d30224c4a
20161014 00:32:48< irker336> wesnoth: Ignacio R. Morelle wesnoth:master d99817a6392c / src/campaign_server/campaign_server.hpp: campaignd: Drop unimplemented method declaration on Windows https://github.com/wesnoth/wesnoth/commit/d99817a6392cc13a70bec288370cb446f78a6f5d
20161014 00:32:51< irker336> wesnoth: Ignacio R. Morelle wesnoth:master 5a57f0c5cf7e / src/campaign_server/ (campaign_server.cpp campaign_server.hpp): campaignd: Code formatting https://github.com/wesnoth/wesnoth/commit/5a57f0c5cf7ef933db1aa17fcb036446ff6b7d50
20161014 00:35:08< irker336> wesnoth: Charles Dang wesnoth:master 425e55491513 / src/gui/widgets/ (listbox.cpp listbox.hpp): Listbox: added functions to set/get sorting order https://github.com/wesnoth/wesnoth/commit/425e5549151316c12d9f1f9181c41b19830eeb5e
20161014 00:35:11< irker336> wesnoth: Charles Dang wesnoth:master 1d820b2fa681 / src/gui/dialogs/unit_recall.cpp: Unit Recall: initially sort by level and preserve any sort settings through dial https://github.com/wesnoth/wesnoth/commit/1d820b2fa681349724cd570d22d3b5191a9e517b
20161014 00:35:59-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Remote host closed the connection]
20161014 00:36:43-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 250 seconds]
20161014 00:37:06-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20161014 00:38:14-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20161014 00:39:31< shadowm> The hotkey list in preferences could also use an initial sorting order.
20161014 00:43:05< vultraz> by what?
20161014 00:43:43< shadowm> By what do you think? Action name, obviously.
20161014 00:50:30< vultraz> hm.
20161014 00:55:09-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 258 seconds]
20161014 01:19:52< celmin> vultraz, DeFender1031: Up-pointing triangle means sorted in increasing order in the Max Finder. So it's not just Windows that's different here.
20161014 01:20:14< celmin> (I dunno if it's relevant that it's a triangle rather than an arrow.)
20161014 01:20:27< DeFender1031> It's usually a triangle, no?
20161014 01:20:43< DeFender1031> (The stuff I have all is anyway.)
20161014 01:26:49< celmin> As far as I know.
20161014 01:27:16< celmin> I could see logical arguments for both ways.
20161014 01:28:05< tad_carlucci> I look at the triangle and the wider part is "greater", the pointy end is "least" and so if I want "A" at the top that's the direction I want the pointy-end.
20161014 01:29:11< celmin> You could say "It's pointing up, so that means ascending"
20161014 01:29:45< celmin> For the opposite, you could say "The entries increase in the direction it's pointing".
20161014 01:30:41< tad_carlucci> But, sometimes I get confused about stuff like "Installed on" and so I click and if it's not right, I click the other, until it seems right.
20161014 01:32:24-!- un214 [~un214@104.220.56.173] has joined #wesnoth-dev
20161014 01:33:28-!- tadcarlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161014 01:34:45-!- tadcarlucci [~lundberg@173.217.65.103] has quit [Client Quit]
20161014 01:35:00-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Off to reserve the merge conflict between the 'wife' and 'husband' branches of real life.]
20161014 01:35:07-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161014 01:36:00-!- un214 [~un214@104.220.56.173] has quit [Remote host closed the connection]
20161014 01:39:02-!- gfgtdf [~chatzilla@x4e363e64.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]
20161014 01:52:27-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161014 01:58:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161014 02:09:09-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 248 seconds]
20161014 02:58:13-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Switching to Unix to get some real work done.]
20161014 03:18:06-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20161014 03:21:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161014 03:22:28-!- JyrkiVesterinen [~JyrkiVest@87-100-152-117.bb.dnainternet.fi] has joined #wesnoth-dev
20161014 03:25:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20161014 03:35:30-!- irker336 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161014 03:58:10-!- JyrkiVesterinen [~JyrkiVest@87-100-152-117.bb.dnainternet.fi] has quit [Quit: .]
20161014 05:09:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161014 05:12:51-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20161014 05:13:24-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161014 05:14:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 258 seconds]
20161014 05:15:02-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161014 05:50:31-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Switching to Unix to get some real work done.]
20161014 05:51:09-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161014 06:14:35-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161014 06:17:08-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20161014 06:32:56< tad_carlucci> vultraz, What version of Boost is installed on the Travis/CI 
20161014 06:33:06< vultraz> no idea
20161014 06:33:14< vultraz> probably something far behind what any of us use
20161014 06:33:54-!- irker668 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161014 06:33:54< irker668> wesnoth: Ignacio R. Morelle wesnoth:master 6e5633929b37 / data/gui/widget/text_box_default.cfg src/gui/widgets/text.cpp: gui2/ttext_: Disable blinking cursor https://github.com/wesnoth/wesnoth/commit/6e5633929b37cd8ed9c978c43713dfb6a9278cc0
20161014 06:34:05< vultraz> nuuuuuuuuuuuuuuuuuu
20161014 06:34:12< tad_carlucci> vultraz My clang changes are failing. I think because the patched boost is for 1.61 .. I guess I'll need to figure out patches for older versions.
20161014 06:34:22< vultraz> :|
20161014 06:35:11< tad_carlucci> vultraz, The Upgrade Lua failed, too, because the tests were attempting to test a deprecated function. I'm waiting to see if I fixed Travis by removing that test.
20161014 06:40:36< tad_carlucci> vultraz, It was the change to use -include which got Travis/CI upset. When I was #including it either Travis/CI never did the include, or it was happy with the patched include.
20161014 06:43:52-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20161014 06:47:37-!- Kwandulin [~Miranda@p200300760F2C7134EC53588CEC21028A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161014 06:51:25< tad_carlucci> vultraz, The answer is if you get the problem on Boost 1.56 through 1.59, tough. The patch is for 1.60 and 1.61 only.
20161014 06:51:48< vultraz> The problem only occurred in 1.60+
20161014 06:53:27-!- atarocch [atarocch@nat/redhat/x-hkctanzlfhmpaqlp] has joined #wesnoth-dev
20161014 06:53:30-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161014 06:53:58< tad_carlucci> And will be fixed in 1.63.  I forgot the patch is also for 1.62.  Anyway, just pushed up a fix which should get Travis happy with my R
20161014 06:57:01-!- Kwandulin [~Miranda@p200300760F2C7134EC53588CEC21028A.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20161014 06:57:46< vultraz> hmmm
20161014 06:57:56< vultraz> problem in my sorting functions :/
20161014 06:58:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161014 06:58:07< vultraz> so, listbox sorting preserves the selection
20161014 06:58:09< vultraz> as it should
20161014 06:58:31< vultraz> but then if you apply an initial sort, the initially selected row won't be the first displayed one :
20161014 06:58:33< vultraz> :/
20161014 06:59:37< vultraz> it does raise a question, though, whether certain lists should be generated in a specific order
20161014 06:59:39< JyrkiVesterinen> Making sure that the initially selected row is displayed is responsibility of tlistbox::place() (I rewrote that code recently).
20161014 07:00:04< JyrkiVesterinen> I'm not surprised that initial sorting happens after layout.
20161014 07:00:58< vultraz> I need a way to select the first sorted row...
20161014 07:01:25< JyrkiVesterinen> The "show initially displayed row" code: https://github.com/wesnoth/wesnoth/blob/6e5633929b37cd8ed9c978c43713dfb6a9278cc0/src/gui/widgets/listbox.cpp#L344-L354
20161014 07:01:47< vultraz> right
20161014 07:01:54< vultraz> but I think you rather misunderstand the issue
20161014 07:02:00< vultraz> the issue is not that the selected row is displayed
20161014 07:02:13< vultraz> it's that the selected row remains the first row pre-sort
20161014 07:02:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20161014 07:02:29< JyrkiVesterinen> Ah, I see.
20161014 07:02:46< vultraz> ie, if you have rows with numbers 4, 2, 3,1, and you sort 1, 2, 3, 4, the row with '4' is still selected
20161014 07:03:10< vultraz> and indexes are absolute and not affected by sorting
20161014 07:03:15< vultraz> so the 4 is still row index 0
20161014 07:03:33< vultraz> (which is desires behavior, btw)
20161014 07:03:38< vultraz> desired*
20161014 07:03:40< vultraz> just not in this case
20161014 07:03:59< JyrkiVesterinen> Hmm, you need to know if the player has manually selected the row (must not change selection on sort) or if it's the implicit "select first row" selection (should select the first post-sort row).
20161014 07:04:57< vultraz> One solution is to sort the container used to fill the listbox, as I said above.
20161014 07:05:30< JyrkiVesterinen> That sounds good to me.
20161014 07:08:24< vultraz> Another solution is to find if the generator code has appropriate index converters
20161014 07:08:27< vultraz> I think it might
20161014 07:08:45< vultraz> potentially get_item_at_ordered
20161014 07:09:18-!- atarocch [atarocch@nat/redhat/x-hkctanzlfhmpaqlp] has quit [Ping timeout: 250 seconds]
20161014 07:09:20< vultraz> but it's protected...
20161014 07:09:42< JyrkiVesterinen> You can make it public, you know.
20161014 07:10:07< vultraz> yes, I'm just wondering if that's wise
20161014 07:10:30< vultraz> it's pure virtual.
20161014 07:11:57-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161014 07:15:19-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Client Quit]
20161014 07:15:42< vultraz> ah, this works
20161014 07:23:38-!- atarocch [atarocch@nat/redhat/x-lpfhplomtxblwszt] has joined #wesnoth-dev
20161014 07:35:36-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20161014 07:35:38-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Off to resolve a merge conflict between the wife and husband branches of my real life.]
20161014 07:41:52-!- boucman_work [~boucman@159.195.204.77.rev.sfr.net] has joined #wesnoth-dev
20161014 07:42:43< irker668> wesnoth: Charles Dang wesnoth:master 60e81be6e62f / src/gui/widgets/generator.hpp: GUI2/Generator: expose a few functions as public https://github.com/wesnoth/wesnoth/commit/60e81be6e62fe85f107816f28569b1908de3a245
20161014 07:42:46< irker668> wesnoth: Charles Dang wesnoth:master 198150613ffa / src/gui/widgets/ (listbox.cpp listbox.hpp): Listbox: added second argument to set_active_sorting_option to allow selecting f https://github.com/wesnoth/wesnoth/commit/198150613ffaa786d201e61c91b69870f10f966e
20161014 07:42:49< irker668> wesnoth: Charles Dang wesnoth:master cf0e780ac10f / src/gui/dialogs/preferences_dialog.cpp: Preferences: initially sort hotkey list by name https://github.com/wesnoth/wesnoth/commit/cf0e780ac10ffb44b84d8c872d21eaa366b4c3ba
20161014 07:44:57< vultraz> I even added... D O C U M E N T A T I O N :D
20161014 07:45:32< zookeeper> lies
20161014 07:45:36< zookeeper> no one adds documentation
20161014 07:54:51-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20161014 08:07:39-!- travis-ci [~travis-ci@ec2-54-158-216-7.compute-1.amazonaws.com] has joined #wesnoth-dev
20161014 08:07:40< travis-ci> wesnoth/wesnoth#11522 (master - 6e56339 : Ignacio R. Morelle): The build has errored.
20161014 08:07:41< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/167560535
20161014 08:07:41-!- travis-ci [~travis-ci@ec2-54-158-216-7.compute-1.amazonaws.com] has left #wesnoth-dev []
20161014 08:21:57-!- boucman_work [~boucman@159.195.204.77.rev.sfr.net] has quit [Ping timeout: 248 seconds]
20161014 08:31:45-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161014 08:46:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161014 08:50:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161014 09:17:00-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Read error: Connection reset by peer]
20161014 09:17:43-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161014 09:18:00-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161014 09:18:37-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Client Quit]
20161014 09:20:48-!- boucman_work [~boucman@159.195.204.77.rev.sfr.net] has joined #wesnoth-dev
20161014 09:20:53-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20161014 09:26:30-!- Kwandulin [~Miranda@p200300760F2C71A40585E0A545BE2E3F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161014 09:29:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161014 09:48:06-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161014 09:52:48-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Remote host closed the connection]
20161014 10:09:30< vultraz> dammit, we're 2 days from the scheduled release date and this blocker isn't fixed :|
20161014 10:11:17< JyrkiVesterinen> How about postponing the release to an unspecified time? IMO, it's not a good idea to release with such severe bugs, and we have no idea when someone would get around to fixing it.
20161014 10:11:50< vultraz> Might be a good idea, yes.
20161014 10:15:16-!- Bonobo [~Bonobo@2001:44b8:254:3200:60f5:81ea:8ba6:34ba] has joined #wesnoth-dev
20161014 10:34:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161014 10:34:55-!- vultraz changed the topic of #wesnoth-dev to: 1.13.6 tentatively planned for end of October | 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
20161014 10:35:18< vultraz> Oh well, now we have more time to fix things.
20161014 10:35:26-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 258 seconds]
20161014 10:38:49< zookeeper> deadlines, they keep-a-shifting
20161014 10:39:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20161014 10:40:53-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161014 10:40:56< zookeeper> but that's good, now i can slack off and worry about stuff some other day
20161014 10:43:03-!- irker668 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161014 10:43:57-!- Kwandulin [~Miranda@p200300760F2C71A40585E0A545BE2E3F.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20161014 10:44:50-!- Kwandulin [~Miranda@p200300760F2C71A40585E0A545BE2E3F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161014 10:53:10< DeFender1031> zookeeper, I think that's explicitly the opposite of the point.
20161014 10:53:16< DeFender1031> :P
20161014 10:57:43-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20161014 11:17:44< zookeeper> nah...
20161014 11:21:16-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161014 11:51:23-!- gfgtdf [~chatzilla@x4e36a4df.dyn.telefonica.de] has joined #wesnoth-dev
20161014 11:54:55< vultraz> gfgtdf: so i was thinking, what if i move the entry point selection to tmp_create_game::post_show before config_engine_->write_parameters(). Will the settings be saved correctly then?
20161014 11:55:39-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20161014 12:01:41-!- boucman_work [~boucman@159.195.204.77.rev.sfr.net] has quit [Ping timeout: 248 seconds]
20161014 12:08:13< gfgtdf> vultraz: i'd think yes but not sure
20161014 12:09:24-!- Kwandulin [~Miranda@p200300760F2C71A40585E0A545BE2E3F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161014 12:22:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161014 12:26:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds]
20161014 12:29:30-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161014 12:53:59-!- Kwandulin [~Miranda@p200300760F2C71A42D025E4D82B77487.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161014 12:54:54-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161014 12:55:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161014 12:58:07-!- Bonobo [~Bonobo@2001:44b8:254:3200:60f5:81ea:8ba6:34ba] has quit [Quit: Leaving]
20161014 12:58:50-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20161014 12:59:49-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 248 seconds]
20161014 13:04:16-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161014 13:05:32-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161014 13:10:29-!- Appleman1234 [~Appleman1@KD106154005182.au-net.ne.jp] has quit [Ping timeout: 248 seconds]
20161014 13:22:41-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 260 seconds]
20161014 13:26:58-!- boucman_work [~boucman@159.195.204.77.rev.sfr.net] has joined #wesnoth-dev
20161014 13:46:18< vultraz> hmmmm
20161014 13:48:33< vultraz> I wonder if there's a race condition here
20161014 13:50:08< vultraz> or maybe not?
20161014 13:50:59< vultraz> well, there's something..
20161014 13:51:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 258 seconds]
20161014 13:51:46< vultraz> seems under certain circumstances, changing the team in staging results in a widget not found error..
20161014 13:51:48< vultraz> or a crash :/
20161014 13:53:41< vultraz> is it possible that the network handler fires between these two functions...? https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/multiplayer/mp_staging.cpp#L350..L354
20161014 13:55:07< vultraz> or perhaps it's this call here.. https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/multiplayer/mp_staging.cpp#L171
20161014 14:02:05< gfgtdf> vultraz: hmm no the network_handler shoudl be called on the main thread 
20161014 14:03:16< vultraz> hmmm
20161014 14:03:22< vultraz> well, there's a problem somewhere..
20161014 14:06:04< DeFender1031> if there's threading, doesn't that mean that it could theoretically be called at any time?
20161014 14:07:04-!- Appleman1234 [~Appleman1@KD106154002031.au-net.ne.jp] has joined #wesnoth-dev
20161014 14:34:41-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20161014 14:35:46< Soliton> gfgtdf: we could make the replay saving async, sure. i don't think that 10 second leave_game is actually an issue if it occurs once a blue moon. the average was ~50 ms which seems fine.
20161014 14:43:17-!- DeFender1031 [~DeFender1@46-116-17-86.bb.netvision.net.il] has quit [Quit: I'm not back now.]
20161014 15:01:30-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161014 15:05:55-!- jesusalva [~jesusalva@186.214.170.254] has joined #wesnoth-dev
20161014 15:10:16-!- boucman_work [~boucman@159.195.204.77.rev.sfr.net] has quit [Remote host closed the connection]
20161014 15:11:52-!- jesusalva [~jesusalva@186.214.170.254] has quit [Quit: Good bye, God bless you.]
20161014 15:12:52< mattsc> celmin: do you have an ETA for the ai.get_attacks() changes yet?
20161014 15:13:27< celmin> ...timing.
20161014 15:13:33< celmin> I just woke up.
20161014 15:13:36< celmin> ...
20161014 15:13:41-!- celmin is now known as celticminstrel
20161014 15:14:42< mattsc> Well, sorry for assaulting you right way.  ;)  While we’re at it, just also said at some point that you might add an iterator for unit.attacks.
20161014 15:15:18< mattsc> That’s not at all as important as get_attacks() for the AIs, just wondering if that’s something your still planning to do.
20161014 15:16:08< celticminstrel> I thoguht I added that already.
20161014 15:16:23< celticminstrel> Maybe I'm imagining things.
20161014 15:16:24< celticminstrel> ^thought
20161014 15:16:34< mattsc> Hmm.
20161014 15:16:51< mattsc> I thought you can get unit.attacks, but ipairs() over it doesn’t work.
20161014 15:17:04< mattsc> That’s how it was last time I tried at least, which was quite some while ago.
20161014 15:23:45< mattsc> celticminstrel: Just checked again and it works now.  Thanks.
20161014 15:24:46< celticminstrel> Can someone instruct vultraz on pofix.
20161014 15:26:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161014 15:27:41-!- gfgtdf [~chatzilla@x4e36a4df.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]
20161014 15:30:48< mattsc> celticminstrel: so what about get_attacks?
20161014 15:31:13< celticminstrel> Not sure, maybe I'll look at it today.
20161014 15:32:11< mattsc> That would be great!  (I’d really like to still add the attacks aspect to the high-xp-attack CA before 1.13.6 is released, that’s why I keep bugging you about it.)
20161014 15:40:34< celticminstrel> Does get_attacks only include reachable units, or does it include all units?
20161014 15:42:24-!- iwaim__ [~iwaim@rasteenie.alib.jp] has quit [Ping timeout: 260 seconds]
20161014 15:43:19< mattsc> AFAIK, it only includes units that can actually be attacked.
20161014 15:43:49< mattsc> Actually, I am sure of that, because it can be used to select the doable attacks.
20161014 15:45:05< celticminstrel> Hmm, so if ai.aspect.attacks should also only include reachable units, then I need to do some pathfinding...
20161014 15:45:21< mattsc> Hmm … which means that with the new ai.get_attacks, I might be able to speed up some of the ai_helper functions too.  That would be cool.
20161014 15:46:13< mattsc> celticminstrel: that’s an interesting question ...
20161014 15:46:27< mattsc> As in, what the preferred way of doing it would be.
20161014 15:47:04< mattsc> I think if it simply returned all units matching the two filters, that would be fine.
20161014 15:47:35< celticminstrel> Okay, I'll do that then. If someone wants to add pathfinding later, they can.
20161014 15:47:43< mattsc> Sounds good.
20161014 15:48:05< mattsc> All the AIs currently using it currently do their own pathfinding anyway.
20161014 15:51:04< mattsc> Is it possible to be next to an enemy unit and not being able to see it?  As in, do visbility, the hides ability, fog or shroud have any customizable settings that would cause adjacent enemies to be invisible?
20161014 15:51:22-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161014 15:51:30< mattsc> I am wondering whether the AIs also need to check whether adjacent enemies are visible …
20161014 15:51:42< mattsc> Or whether it can be assumed that they are.
20161014 15:52:13< celticminstrel> So, what should the keys be?
20161014 15:52:25< celticminstrel> ai.aspects.attacks.???
20161014 15:52:34< celticminstrel> enemies and attackers fine?
20161014 15:52:44< celticminstrel> Or maybe own and attacker, to match the filter tags?
20161014 15:52:51-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161014 15:52:58< celticminstrel> I mean enemy not attacker.
20161014 15:53:17< mattsc> Right.  Yeah, the latter is probably good.
20161014 15:53:55 * mattsc wonders whether zookeeper knows the answer to my question a few lines up there ^
20161014 15:59:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161014 15:59:55-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161014 16:00:16-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Client Quit]
20161014 16:01:28-!- atarocch [atarocch@nat/redhat/x-lpfhplomtxblwszt] has quit [Ping timeout: 260 seconds]
20161014 16:01:37< tad_carlucci> Where are the boost unit tests which run on Travis/CI?
20161014 16:02:34< celticminstrel> vultraz: I don't like the new tooltips.
20161014 16:02:47< celticminstrel> They might make sense if tooltips always appeared to the right of what they apply to, but that's not the case.
20161014 16:02:57< celticminstrel> More often they appear sort of above-ish.
20161014 16:03:09< celticminstrel> Also, tooltip placement was broken at some point.
20161014 16:03:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161014 16:05:37< tad_carlucci> #9  0x00000000008aab0e in lua::lua_rounding_invoker() ()
20161014 16:05:38< tad_carlucci> #10 0x00000000007eebb7 in boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() ()
20161014 16:06:05< celticminstrel> tad_carlucci: You mean the ones in src/tests?
20161014 16:06:07< tad_carlucci> Where to I find the source to lua::lua_rounding_invoker() et al
20161014 16:06:20< celticminstrel> No idea, I'd just grep src for it.
20161014 16:06:34< tad_carlucci> celticminstrel, No hits. I'll look again.
20161014 16:07:14-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has joined #wesnoth-dev
20161014 16:07:14-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has quit [Changing host]
20161014 16:07:14-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20161014 16:07:28< mordante> servus
20161014 16:07:39< tad_carlucci> No hits.
20161014 16:08:06-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161014 16:08:48< celticminstrel> That's weird?
20161014 16:09:25< tad_carlucci> [lundberg@Arch src]$ grep -ri lua_rounding_invoker .
20161014 16:09:25< tad_carlucci> [lundberg@Arch src]$ 
20161014 16:09:51< celticminstrel> I normally use git grep.
20161014 16:09:56< celticminstrel> 'git grep blah src'
20161014 16:10:10< celticminstrel> But I doubt that would give different results...
20161014 16:10:49< tad_carlucci> [lundberg@Arch src]$ git grep -i lua_rounding_invoker .
20161014 16:10:50< tad_carlucci> [lundberg@Arch src]$ 
20161014 16:13:24< tad_carlucci> Can't fix the Travis/CI failures if I can't see what's failing. Given it's rounding it's probably a test against the IEEE 754 'fake' feature which does not exist any more.
20161014 16:13:55-!- Kwandulin [~Miranda@p200300760F2C71A42D025E4D82B77487.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161014 16:17:36< tad_carlucci> Let
20161014 16:25:29< tad_carlucci> zookeeper, Do you know where the Travis/CI source code is? No master:src/tests but the source code for the boost unit tests such as lua::lua_rounding_invoker? Or do you know who might now?
20161014 16:26:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161014 16:27:11-!- louis94 [~~louis94@91.178.241.181] has joined #wesnoth-dev
20161014 16:28:25-!- JyrkiVesterinen [~JyrkiVest@87-92-32-82.bb.dnainternet.fi] has joined #wesnoth-dev
20161014 16:29:28-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161014 16:35:25-!- vincent_c [~bip@vcheng.org] has quit [Quit: Coyote finally caught me]
20161014 16:36:11-!- vincent_c [~bip@vcheng.org] has joined #wesnoth-dev
20161014 16:42:55< celticminstrel> Hmm, it looks like ai.aspects.advancements might've never worked.
20161014 16:48:32-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161014 16:48:36< tad_carlucci> celticminstrel, do you have a directory ~wesnoth/test sitting next to ~wesnoth/src ?
20161014 16:50:24< celticminstrel> mattsc: So I have it almost working, except... for some reason enemy is the same as own. :/
20161014 16:50:30< celticminstrel> tad_carlucci: Huh? No?
20161014 16:51:13< tad_carlucci> I'm looking at the shell script which runs the debugger and it refernces that directory.
20161014 16:51:35< celticminstrel> Oh wait, next to src.
20161014 16:51:40< celticminstrel> Maybe.
20161014 16:52:00< celticminstrel> Hmm, still no though.
20161014 16:52:07 * tad_carlucci sighs
20161014 16:52:27< tad_carlucci> Who is the go-to person for our Travis/CI runs?
20161014 16:52:48< celticminstrel> Not quite sure.
20161014 16:53:05< mattsc> celticminstrel: huh …
20161014 16:53:28< celticminstrel> mattsc: I probably have a logic error somewhere.
20161014 16:53:49< tad_carlucci> It really makes me nervous to that the Lua upgrade is failing the tests with a hard crash and I can't find the source kit for the tests.
20161014 16:57:17-!- irker037 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161014 16:57:17< irker037> wesnoth: Celtic Minstrel wesnoth:lua_aspect_attacks_get d5d30a228662 / src/ai/ (composite/aspect.hpp lua/core.cpp): Lua: Make ai.aspects.attacks return only the units rather than the attack analys https://github.com/wesnoth/wesnoth/commit/d5d30a228662935dc11aa5e93b20ecad83df6dae
20161014 16:57:43< celticminstrel> Can someone take a look at that?
20161014 16:57:54< celticminstrel> The "own" and "enemy" arrays for some reason contain the same units.
20161014 16:58:15< celticminstrel> Even though the "attackers" and "enemies" vectors appear to have the correct content.
20161014 16:58:49< mattsc> celticminstrel: umm, we said we would have ai.get_attacks() return this and leave ai.aspects.attacks as it was, didn’t we?
20161014 16:59:53< mattsc> I’ll have a look at it later, need to do some actual work right now.
20161014 17:00:48-!- gfgtdf [~chatzilla@x4e36a4df.dyn.telefonica.de] has joined #wesnoth-dev
20161014 17:01:01< celticminstrel> I thought it was the other way around.
20161014 17:01:12< celticminstrel> Note that that's not in master since it's not quite functional yet.
20161014 17:01:21< mattsc> right, I saw that
20161014 17:01:59< mattsc> I thought we would leave ai.aspects.attacks as it was, for backward compatibility, as that is what the syntax for all the aspects is moving toward
20161014 17:02:31< mattsc> And use something new for get_attacks(), as all the get_aspect() function will be removed at some point
20161014 17:05:39-!- iwaim [~iwaim@rasteenie.alib.jp] has joined #wesnoth-dev
20161014 17:05:50< celticminstrel> Well, given that ai.aspects.attacks is completely new, leaving it as it was for backwards compatibility sounds silly.
20161014 17:06:23< mattsc> But it isn’t.  It’s just the new syntax for accessing the same thing.
20161014 17:10:29< mattsc> celticminstrel: Looked back in the logs and you are right, that’s how we said it.  So since I agreed back then, I am not going to object now.  :P
20161014 17:13:40-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161014 17:13:49< tad_carlucci> celticminstrel, AH .. I see .. hidden in the macros. So nice of Boost to make an entry in the IOCCC like that.
20161014 17:14:20< mattsc> celticminstrel: your code looks okay to me, as far as I can tell...
20161014 17:16:53-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 248 seconds]
20161014 17:16:53-!- wedge010 is now known as wedge009
20161014 17:17:23< celticminstrel> That's why I'm confused about it not working...
20161014 17:17:54< mattsc> In the new line 805, I assume you can assign two spearate pointers that way in one line in C++?
20161014 17:18:15< celticminstrel> Those aren't pointers, so it's fine.
20161014 17:19:12< mattsc> Right.  Okay.
20161014 17:51:34< zookeeper> mattsc, no it's not possible
20161014 17:52:20< zookeeper> mattsc, at least not in normal play. maybe you could put DSU up, give a unit more than normal MP and then move it to the very edge of the shroud under which there's an enemy unit? not sure if even that could work.
20161014 17:53:25< zookeeper> tad_carlucci, no idea
20161014 17:53:53< mattsc> zookeeper: thanks, that’s what I thought, just wanted to be sure; and the latter case is something the AI wouldn’t have to worry about, I think, if it even worked
20161014 17:54:01< tad_carlucci> zookeeper, Found it, finally. Hidden in boost macros.
20161014 17:55:53< zookeeper> mattsc, and yeah i just tested that particular trick and it seems to work... but there's always plenty of ways to break things in debug mode so doesn't seem very relevant.
20161014 17:56:44< mattsc> zookeeper: okay, thanks; and yes
20161014 17:57:00< zookeeper> although of course a scenario/modification/whatever could effectively do the same (give a unit more MP than they have vision), but that causes ickiness all around so...
20161014 17:58:16< mattsc> Hmm, but once I have moved a unit, it would see what’s next to it, right?  In the AI code, I mean.
20161014 17:58:47< zookeeper> i did get an assert when toggling shroud off in that situation, but that could be a more general problem
20161014 17:59:04< zookeeper> well, so i'd expect
20161014 17:59:44< mattsc> Anyways, seems like I don’t need to worry about it for now at least.
20161014 18:00:39< zookeeper> i mean, normal game rules can't take a unit to a situation where they can't see an adjacent unit. i could imagine situations where it could be true though, such as for example an AI unit getting spawned next to an enemy and shroud not being updated for an AI side the same way it does for human sides.
20161014 18:01:33< mattsc> zookeeper: hmm ...
20161014 18:02:14< zookeeper> just random guesses, is all... :p
20161014 18:02:18< mattsc> I guess since my current goal is to toughen up AIs to deal with unexpected things thrown at it, I will just add the test for visibility.  It’s easy enough to do.
20161014 18:03:57< zookeeper> well are you doing it to prevent a possible crash, or to make the AI unable to attack an adjacent invisible unit because that'd be cheating, or..?
20161014 18:04:22< zookeeper> the former is probably a good idea, the latter seems redundant
20161014 18:05:41< mattsc> both, actually
20161014 18:06:43< zookeeper> i can't imagine it would hurt, so there's that
20161014 18:09:41-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20161014 18:12:29-!- louis94 [~~louis94@91.178.241.181] has quit [Ping timeout: 260 seconds]
20161014 18:40:43< tad_carlucci> vultraz, Can you look at something for me?
20161014 18:42:02-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161014 18:43:19-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Client Quit]
20161014 18:48:56-!- louis94 [~~louis94@91.178.241.181] has joined #wesnoth-dev
20161014 18:49:50-!- yaiyan_ [~yaiyan@46.101.48.31] has joined #wesnoth-dev
20161014 18:51:53-!- Netsplit *.net <-> *.split quits: Yaiyan, Elsi, Sirp_, boucman, esr
20161014 18:51:59-!- yaiyan_ is now known as Yaiyan
20161014 18:57:29-!- Netsplit over, joins: boucman
20161014 18:57:29-!- Sirp [~Sirp@u17402953.onlinehome-server.com] has joined #wesnoth-dev
20161014 18:57:50-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20161014 18:57:50-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Changing host]
20161014 18:57:50-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20161014 19:00:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161014 19:03:21-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 258 seconds]
20161014 19:05:46-!- Elsi [~Elsi@luwin.ulrar.net] has joined #wesnoth-dev
20161014 19:10:20-!- pydsigner [~pydsigner@unaffiliated/pydsigner] has quit [Ping timeout: 258 seconds]
20161014 19:14:38-!- matthiaskrgr [matthiaskr@gateway/shell/panicbnc/x-dwkrzmqijmetuoqq] has joined #wesnoth-dev
20161014 19:15:02-!- matthiaskrgr is now known as Guest56222
20161014 19:16:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161014 19:16:39-!- pydsigner [~pydsigner@unaffiliated/pydsigner] has joined #wesnoth-dev
20161014 19:18:07< gfgtdf> Elvish_Hunter: since you were the one who aded support for bit32 lua llibary, do you see any problem in removing it when updating to lua 5.3 ?
20161014 19:28:16-!- Jetrel [~Jetrel@2001:558:6014:1e:2422:435:dd84:bbf3] has quit [Read error: Network is unreachable]
20161014 19:29:30-!- Sirp [~Sirp@u17402953.onlinehome-server.com] has quit [Ping timeout: 258 seconds]
20161014 19:29:52-!- Jetrel [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has joined #wesnoth-dev
20161014 19:30:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161014 19:31:02-!- Sirp [~Sirp@u17402953.onlinehome-server.com] has joined #wesnoth-dev
20161014 19:31:48-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 258 seconds]
20161014 19:32:18-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161014 19:33:49-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20161014 19:35:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20161014 19:53:43-!- louis94 [~~louis94@91.178.241.181] has quit [Ping timeout: 250 seconds]
20161014 19:53:56-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20161014 19:56:35-!- JyrkiVesterinen [~JyrkiVest@87-92-32-82.bb.dnainternet.fi] has quit [Quit: .]
20161014 19:57:22-!- irker037 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161014 20:24:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161014 20:29:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161014 20:34:05-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20161014 20:35:46-!- louis94 [~~louis94@91.178.241.181] has joined #wesnoth-dev
20161014 20:43:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161014 20:46:49< tad_carlucci> When optaining a float from Lua you can no longer use luaL_checkinteger or other *integer functions to obtain a rounded value.
20161014 20:48:03-!- atarocch [~atarocch@93.56.160.28] has quit [Remote host closed the connection]
20161014 20:48:06< tad_carlucci> Lua *integer functions will throw an error if called on a float which (a) has a fractional part or (b) the whole part is outside the integer range.
20161014 20:49:01< gfgtdf> tad_carlucci: well those testswere mainly to prevent OOS by clients rounding diffeently so if now they give and error thats fine, as long as they behave the same.
20161014 20:49:05< tad_carlucci> To obtain a rounded float, you must call luaL_checknumber or some other *number function, which yeilds a float and then round it as you choose (cast, ceil, floor, whatever).
20161014 20:50:02< tad_carlucci> gfgtdf, Awaiting final Travis/CI run but I'm confident it will finally pass. So all of my current PRs now pass Travis/CI.
20161014 20:52:02< tad_carlucci> gfgtdf, What all that means if if the hardware function returns a different value, you'll get OOS. But, now, you can't blame Lua for that.
20161014 20:58:02< gfgtdf> tad_carlucci: we shoudl just use luaL_checkinteger  in the wesnoth pi ten
20161014 21:02:23< tad_carlucci> I ran though all /lua[_a-zA-Z]*int/ and did a glance at each. It does not appear we use floating-point rounding in the C++.
20161014 21:07:20-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161014 21:16:52< tad_carlucci> vultraz, You available?
20161014 21:25:36-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161014 22:24:14-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161014 22:37:10< celticminstrel> gfgtdf, tad_carlucci, any idea what's wrong with https://github.com/wesnoth/wesnoth/commit/d5d30a228662935dc11aa5e93b20ecad83df6dae ?
20161014 22:39:50-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161014 22:40:28-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds]
20161014 22:43:03< gfgtdf> celticminstrel: sr i dont really know that ai code, what are the symptons of the error ?
20161014 22:43:41< celticminstrel> ai.aspects.attacks.own[1] == ai.aspects.attacks.enemy[1]
20161014 22:43:57< celticminstrel> ie, the two vectors pushed into the table contain the same units
20161014 22:44:50-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161014 22:47:02-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 250 seconds]
20161014 23:00:26-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161014 23:02:21< gfgtdf> celticminstrel: hmm cant see the erro looks correct to me
20161014 23:02:47< celticminstrel> :/
20161014 23:08:16-!- louis94 [~~louis94@91.178.241.181] has quit [Ping timeout: 250 seconds]
20161014 23:13:53-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has quit [Quit: leaving]
20161014 23:21:16-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161014 23:32:00-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Quit: I'll be back!]
20161014 23:38:26-!- Guest56222 [matthiaskr@gateway/shell/panicbnc/x-dwkrzmqijmetuoqq] has quit [Changing host]
20161014 23:38:26-!- Guest56222 [matthiaskr@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161014 23:38:26-!- Guest56222 [matthiaskr@unaffiliated/matthiaskrgr] has quit [Changing host]
20161014 23:38:26-!- Guest56222 [matthiaskr@gateway/shell/panicbnc/x-dwkrzmqijmetuoqq] has joined #wesnoth-dev
20161014 23:38:32-!- Guest56222 is now known as matthiakrgr
20161014 23:41:44-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 258 seconds]
20161014 23:50:16-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Off to resolve a merge conflict between the wife and husband branches of my real life.]
--- Log closed Sat Oct 15 00:00:44 2016