--- Log opened Tue Nov 01 00:00:34 2016
20161101 00:18:36-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161101 00:18:53-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Write error: Broken pipe]
20161101 00:20:21-!- Ivanovic [~ivanovic@p579FBF3F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161101 00:20:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20161101 00:20:50-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Remote host closed the connection]
20161101 00:20:51-!- wedge010 is now known as wedge009
20161101 00:20:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20161101 00:21:07-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161101 00:21:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161101 00:21:40-!- DeFender1031 [~DeFender1@46-116-17-86.bb.netvision.net.il] has quit [Write error: Broken pipe]
20161101 00:21:57-!- DeFender1031 [~DeFender1@46-116-17-86.bb.netvision.net.il] has joined #wesnoth-dev
20161101 00:53:54-!- louis94 [~~louis94@91.178.241.125] has quit [Quit: Konversation terminated!]
20161101 00:57:02-!- travis-ci [~travis-ci@ec2-54-221-165-92.compute-1.amazonaws.com] has joined #wesnoth-dev
20161101 00:57:03< travis-ci> wesnoth/wesnoth#11823 (master - 0f6a779 : Timotei Dolean): The build has errored.
20161101 00:57:03< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/172147459
20161101 00:57:03-!- travis-ci [~travis-ci@ec2-54-221-165-92.compute-1.amazonaws.com] has left #wesnoth-dev []
20161101 01:05:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161101 01:07:43-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161101 01:09:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20161101 01:27:55< celticminstrel> ...oh, time differences.
20161101 01:28:52< celticminstrel> Hmm, why did the build error...
20161101 01:29:08< celticminstrel> I guess it's a problem with Travis itself.
20161101 01:29:38< celticminstrel> Oh, wait, that's not the master build.
20161101 01:29:48< celticminstrel> So it errored because I force-pushed twice in a row.
20161101 01:30:13< celticminstrel> And as a result the old HEAD was gone.
20161101 01:30:25< celticminstrel> The master build's error looks like just a random failure...
20161101 01:41:56-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20161101 01:42:30-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161101 01:55:21-!- irker070 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161101 02:05:59< tad_carlucci> 20161031 20:46:40 error addons-client: add-on 'Water_Era' has an icon which cannot be found: 'projectiles/merman.png'
20161101 02:05:59< tad_carlucci> 20161031 20:46:41 error display: ~BLIT(): image not found: 'hits/blade-3.png'
20161101 02:06:47< tad_carlucci> Dunno if these mean anything to the engine or are just complaining about a problem with an addon on the server.
20161101 02:07:57< vultraz> Water Era has had a broken icon for many many releases now
20161101 02:08:01< vultraz> it's entirely the fault of the author
20161101 02:08:08 * tad_carlucci nods.
20161101 02:08:29< tad_carlucci> Hung the game for me. Let me check without a debugger attached.
20161101 02:09:33< vultraz> In early 1.13 I added a pre-upload validation check for image path
20161101 02:09:33< tad_carlucci> Clean start, current release build. Addons button.  Description button for first addon listed.  I'm hung.
20161101 02:09:42< vultraz> tad_carlucci: oh, yeah, known
20161101 02:09:52< tad_carlucci> OK. Ignoring that, then.
20161101 02:10:04< vultraz> tad_carlucci: same bug as this https://gna.org/bugs/index.php?25130
20161101 02:10:26< vultraz> will be fixed if I ever finish the bloody addons manager
20161101 02:10:32 * vultraz mutters darkly
20161101 02:10:47< tad_carlucci> Disable the button and push the release :>
20161101 02:10:51< vultraz> :p
20161101 02:11:27< tad_carlucci> Well, back to what I was looking at ...
20161101 02:11:27-!- vultraz changed the topic of #wesnoth-dev to: 1.13.6 planned for Sunday, November 6th | 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
20161101 02:15:04-!- gfgtdf_ [~chatzilla@x4e36890d.dyn.telefonica.de] has joined #wesnoth-dev
20161101 02:18:06-!- gfgtdf [~chatzilla@x4e36aa37.dyn.telefonica.de] has quit [Ping timeout: 250 seconds]
20161101 02:18:13-!- gfgtdf_ is now known as gfgtdf
20161101 03:20:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161101 03:20:05-!- gfgtdf [~chatzilla@x4e36890d.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]]
20161101 03:39:51-!- 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.]
20161101 04:04:11-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161101 04:13:52< vultraz> celticminstrel: map::emplace returns the existing V if adds nothing right?
20161101 04:13:59< vultraz> it adds
20161101 04:32:51< vultraz> "or the already-existing element if no insertion happened"
20161101 04:32:54< vultraz> ok this code should work..
20161101 04:34:50< vultraz> i suppose map<string, vector> and search on every run isn't any more significantly inefficient 
20161101 04:34:55< vultraz> though i suppose slightly
20161101 04:35:35< vultraz> still, since type is already passed to the function using a wrapper map allows for automatic handling of a vector for every type
20161101 04:35:52< vultraz> instead of adding multiple vectors to the class
20161101 04:36:57< vultraz> and it isn't any more efficient anyway since the vectors would be initialized size-0
20161101 04:39:40< celticminstrel> Why do you keep asking the same thing day after day. :/
20161101 04:39:52< vultraz> because i keep forgetting
20161101 04:39:56< celticminstrel> Try to remember.
20161101 04:44:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161101 04:47:15< vultraz> i have now read the docs on cppreference
20161101 04:47:20< vultraz> so i should remember
20161101 04:48:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20161101 04:55:26< vultraz> (yes, I know it's annoying to hear the same question, I'm sorry)
20161101 04:58:08< vultraz> Also, I might be busy over the next few months
20161101 04:58:27< vultraz> No guarantee I will be able to be as active in the code department as I've been 
20161101 05:03:51-!- JyrkiVesterinen [~JyrkiVest@87-100-240-18.bb.dnainternet.fi] has joined #wesnoth-dev
20161101 05:16:45-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: End Transmission.]
20161101 05:35:19-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Read error: Connection reset by peer]
20161101 05:47:32-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20161101 06:23:09-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161101 06:32:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161101 06:37:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161101 07:18:06-!- JyrkiVesterinen [~JyrkiVest@87-100-240-18.bb.dnainternet.fi] has quit [Quit: .]
20161101 08:10:19-!- JyrkiVesterinen [~JyrkiVest@194.157.54.14] has joined #wesnoth-dev
20161101 08:21:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161101 08:25:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 256 seconds]
20161101 08:39:34-!- Appleman1234 [~Appleman1@KD106161196101.au-net.ne.jp] has joined #wesnoth-dev
20161101 08:39:58-!- Appleman1234 [~Appleman1@KD106161196101.au-net.ne.jp] has quit [Remote host closed the connection]
20161101 08:40:44-!- Appleman1234 [~Appleman1@KD106161196101.au-net.ne.jp] has joined #wesnoth-dev
20161101 08:41:36-!- Appleman1234 [~Appleman1@KD106161196101.au-net.ne.jp] has quit [Remote host closed the connection]
20161101 08:42:43-!- Nikitaw99 [2e00a83b@gateway/web/freenode/ip.46.0.168.59] has joined #wesnoth-dev
20161101 08:43:19-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161101 08:48:03-!- Appleman1234 [~Appleman1@KD106161196101.au-net.ne.jp] has joined #wesnoth-dev
20161101 08:49:04-!- Appleman1234 [~Appleman1@KD106161196101.au-net.ne.jp] has quit [Remote host closed the connection]
20161101 08:50:52-!- Appleman1234 [~Appleman1@KD106161196101.au-net.ne.jp] has joined #wesnoth-dev
20161101 09:01:33-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161101 09:06:27-!- Ivanovic [~ivanovic@p579FBF3F.dip0.t-ipconnect.de] has quit [Changing host]
20161101 09:06:27-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20161101 09:14:48-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 250 seconds]
20161101 09:26:09-!- mjs-de [~mjs-de@x4db65565.dyn.telefonica.de] has joined #wesnoth-dev
20161101 09:28:56-!- mjs-de [~mjs-de@x4db65565.dyn.telefonica.de] has quit [Remote host closed the connection]
20161101 09:30:14-!- heirecka [~heirecka@exherbo/developer/heirecka] has quit [Quit: Bye]
20161101 09:31:22-!- heirecka [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev
20161101 09:37:56-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 260 seconds]
20161101 09:38:35-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161101 09:51:06-!- Nikitaw99 [2e00a83b@gateway/web/freenode/ip.46.0.168.59] has quit [Quit: Page closed]
20161101 10:09:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161101 10:14:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20161101 10:41:01-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161101 11:30:30-!- irker886 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161101 11:30:30< irker886> wesnoth: Nils Kneuper wesnoth:master df801eca636f / / (5 files in 4 dirs): updated Polish translation https://github.com/wesnoth/wesnoth/commit/df801eca636f039742daa02fb6c6686e5a7117a0
20161101 11:50:03-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
20161101 11:57:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161101 12:02:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20161101 12:44:25-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161101 12:51:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161101 12:52:38-!- louis94 [~~louis94@91.178.241.185] has joined #wesnoth-dev
20161101 12:53:51-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161101 13:00:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 250 seconds]
20161101 13:00:22-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161101 13:02:11-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161101 13:04:57-!- gfgtdf [~chatzilla@x4e36890d.dyn.telefonica.de] has joined #wesnoth-dev
20161101 13:16:20-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 250 seconds]
20161101 13:27:47< irker886> wesnoth: mattsc wesnoth:master 70b9aea5a45c / data/ai/lua/ca_high_xp_attack.lua: High-XP Attack CA: do not use AI leader for this type of attack https://github.com/wesnoth/wesnoth/commit/70b9aea5a45c88c6449c09e5500571b185bf5a2b
20161101 13:52:35-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20161101 14:41:00-!- stikonas_ is now known as stikonas
20161101 14:41:42-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161101 15:03:05-!- mjs-de [~mjs-de@x4db65565.dyn.telefonica.de] has joined #wesnoth-dev
20161101 15:13:48-!- louis94 [~~louis94@91.178.241.185] has quit [Quit: Konversation terminated!]
20161101 15:14:29-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20161101 15:35:17-!- Nikitaw99 [2e00a83b@gateway/web/freenode/ip.46.0.168.59] has joined #wesnoth-dev
20161101 15:35:37< Nikitaw99> can anybody tell me if there is a elvish civillian unit in mainline? I need it for my UMC Campaign
20161101 15:36:56-!- Appleman1234 [~Appleman1@KD106161196101.au-net.ne.jp] has quit [Ping timeout: 265 seconds]
20161101 15:39:28-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20161101 15:40:55-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161101 15:43:24-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161101 15:51:26< pydsigner> Nikitaw99: I think that LoW uses an Elvish Civ
20161101 15:52:06< pydsigner> Nope
20161101 15:52:15< pydsigner> There's one in UMC though already
20161101 16:01:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161101 16:02:48< Nikitaw99> pydsigner: Thank you. I have "The Golden Age" installed, so probably I am going to be using the Elvish Civilian from it.
20161101 16:08:36-!- JyrkiVesterinen [~JyrkiVest@194.157.54.14] has quit [Quit: .]
20161101 16:08:44< pydsigner> Nikitaw99: It's probably the same one floatig around throughout UMC
20161101 16:13:42< Nikitaw99> pydsigner: Still though, I want to be careful, so I want to use the variant from 'The Golden Age' (and add it the addon as a dependency).
20161101 16:14:02< Nikitaw99> Is there any way to specify that I want to use TGA's Elvish Civilian variant?
20161101 16:14:34< Nikitaw99> (in my campaign, of course)
20161101 16:16:03< pydsigner> I'd not recommend adding the whole add-on as dep
20161101 16:16:20< pydsigner> It's literally used dozens of places though UMC
20161101 16:16:45< pydsigner> Just figure out who originally did it and copy the files, cite in credits
20161101 16:18:09< Nikitaw99> but I am planning to use some units from that addon...
20161101 16:18:14< Nikitaw99> some other units**
20161101 16:18:24< Nikitaw99> but oh well
20161101 16:18:33< Nikitaw99> thanks for advice, though
20161101 16:20:13< Nikitaw99> hm, just delved into TGA's unit files, and found this line: "#textdomain wesnoth-Invasion_from_the_Unknown"
20161101 16:20:42< Nikitaw99> so I guess the original creator of the unit is The author of "Invasion From The Unknown"
20161101 16:27:58-!- irker886 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161101 16:28:23-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161101 16:32:56< Nikitaw99> uh
20161101 16:33:40< Nikitaw99> i am getting an error...
20161101 16:34:12< Nikitaw99> the campaign says that 'Elvish Civilian' is undefined...
20161101 16:34:17< Nikitaw99> here's my code: https://gist.github.com/Nikitaw99/136a1511721bb87d9d845cfb15061786
20161101 16:34:30< Nikitaw99> i am not sure what the problem is
20161101 16:35:52< zookeeper> it means you don't have a [unit_type] with id=Elvish Civilion in a .cfg file in ~add-ons/The_Invasion/units/
20161101 16:37:09< zookeeper> also remove the {~add-ons/The_Invasion/images} line which does nothing
20161101 16:37:45< Nikitaw99> zookeeper: I've added some images that the unit uses into it, so I won't.
20161101 16:38:00< zookeeper> ...
20161101 16:38:08< zookeeper> i was not mistaken in what i said
20161101 16:38:23< Nikitaw99> ???
20161101 16:38:33< Nikitaw99> so, i guess i remove the line?
20161101 16:38:49< Nikitaw99> ok...
20161101 16:39:03< Nikitaw99> anyway
20161101 16:39:38< Nikitaw99> There IS a unit with that id in the units folder...
20161101 16:39:58< Nikitaw99> http://i.imgur.com/3Vytyy7.png
20161101 16:40:22< Nikitaw99> http://i.imgur.com/tjxNN5h.png
20161101 16:40:51< zookeeper> no, it's in units/Elves/
20161101 16:42:12< Nikitaw99> i thought it included folders in units/ too...
20161101 16:46:38-!- Appleman1234 [~Appleman1@KD106161196101.au-net.ne.jp] has joined #wesnoth-dev
20161101 16:47:13< Nikitaw99> now, the game can't find the unit's icon
20161101 16:47:46< mattsc> Is [transform_unit] still supposed to play the “going white” animation in current master?
20161101 16:47:57< mattsc> At least for me, it does not seem to do so.
20161101 16:48:12< zookeeper> Nikitaw99, maybe you don't have the image in images/units/elves-wood/civilian.png
20161101 16:48:35< zookeeper> mattsc, still as in you're sure it used to do it?
20161101 16:49:00< mattsc> zookeeper: yes; in 1.12 that’s what it did/does.
20161101 16:49:16< Nikitaw99> (i am currently developing for 1.12)
20161101 16:50:24< Nikitaw99> zookeeper: I do have it in there...
20161101 16:50:26< zookeeper> mattsc, well in that case i guess it should play it.
20161101 16:50:38< Nikitaw99> http://i.imgur.com/TH5df5b.png
20161101 16:51:02< zookeeper> i was looking at the ADVANCE_UNIT/TRANSFORM_UNIT stuff recently and i found something to be weird about it but i don't recall what all that might have been
20161101 16:51:07< mattsc> Hmm. Actually it doesn’t transform the unit either.  Need to check whether that’s a problem with the tag or some new incompatibility or change in behavior from 1.12 to 1.13..
20161101 16:51:15< mattsc> There are way more of those than I expected ...
20161101 16:51:28< zookeeper> Nikitaw99, no you don't
20161101 16:52:01< Nikitaw99> zookeeper: ????
20161101 16:52:13< Nikitaw99> now i am confused...
20161101 16:52:33< mattsc> Nikitaw99: zookeeper’s right; it’s not just the image that has to be right, but the path also.
20161101 16:53:24< Nikitaw99> ohhh, i forgot that it's in images/elves-wood and not images/units/elves-wood
20161101 16:55:51-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161101 16:56:12< mattsc> Hmm, there’s definitely something fishy about [transform_unit] in master ...
20161101 16:56:23< mattsc> No time to investigate right now though.
20161101 16:57:12< mattsc> I think I’ll stop porting my campaigns to 1.13 for now though.  It’s just not worth it yet.  :|
20161101 16:57:41< Nikitaw99> mattsc: same, I am only planning it when my campaign is completed.
20161101 17:02:07< mattsc> Nikitaw99: my campaigns are complete (or at least as complete as they’re ever going to be)
20161101 17:06:27< pydsigner> Fwiw, my campaign ran as-is on 1.13
20161101 17:08:25< pydsigner> For a WIP campaign it's probably worth it to support both now.
20161101 17:09:44-!- louis94 [~~louis94@91.178.241.185] has joined #wesnoth-dev
20161101 17:14:27< mattsc> pydsigner: agreed; for a WIP campaign I might even consider doing it only in master. But for “just quickly porting” complete campaigns to 1.13, I am finding that I spend too much time finding workarounds for things that aren’t quite stable yet. I have bigger fish to fry at the moment for that to be worth it for me.
20161101 17:14:52< mattsc> And I’m not blaming anybody for that, that’s the nature of development releases.
20161101 17:15:06-!- louis94 [~~louis94@91.178.241.185] has quit [Quit: Konversation terminated!]
20161101 17:15:59-!- louis94 [~~louis94@91.178.241.185] has joined #wesnoth-dev
20161101 17:16:21-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161101 17:19:41< celticminstrel> mattsc: Do you get a crash when attempting to load a map in the editor?
20161101 17:20:45< mattsc> celticminstrel: I’m here in part because I saw that you pinged me and to ask what you needed me to test.  Just open any map in the editor?
20161101 17:21:04< celticminstrel> If you can see the load dialog at all, you pass.
20161101 17:21:14< celticminstrel> You don't actually need to load a map.
20161101 17:22:33< Nikitaw99> scenarios dont exactly need seperate map files
20161101 17:22:50< Nikitaw99> you could just literally paste the map data in the map_data key
20161101 17:22:54< mattsc> celticminstrel: well, I can see the dialog and load a map (current master)
20161101 17:23:46< mattsc> Nikitaw99: that’s not the point here; Wesnoth should not crash when you try to load a map in the editor (or ever, in fact)
20161101 17:23:57< Nikitaw99> mattsc: Oh, I see...
20161101 17:24:07< celticminstrel> Okay, I think that should make my issue not a blocker then.
20161101 17:24:47< celticminstrel> Maybe I won't even see it in ancestral's release build.
20161101 17:24:59< celticminstrel> Hopefully.
20161101 17:25:20< celticminstrel> (Just like the missing team colour.)
20161101 17:25:48< mattsc> Wow, the load map dialog let’s me access my computer’s root directory …   :O 
20161101 17:26:04< celticminstrel> Is that a problem?
20161101 17:26:27< mattsc> I do not know.  It’s just … surprising.
20161101 17:26:37< celticminstrel> Why is it surprising?
20161101 17:26:50< mattsc> I don’t know enough about security issues to know whether that’s a problem.  Probably not.
20161101 17:29:00< mattsc> I don’t know if it is surprising, it just surprised me.  This depends on the definition of “is”, or something …  :P
20161101 17:29:19< celticminstrel> Okay whatever.
20161101 17:29:32< mattsc> Exactly.
20161101 17:29:33< celticminstrel> Accessing /Volumes works, right?
20161101 17:29:50 * celticminstrel asks because I can't seem to access it over ssh.
20161101 17:30:06-!- louis94 [~~louis94@91.178.241.185] has quit [Remote host closed the connection]
20161101 17:30:07< mattsc> It does.
20161101 17:30:26< celticminstrel> (Which is a totally different case and there's not really any reason to assume it'd be equivalent to this.)
20161101 17:30:33< celticminstrel> <_<
20161101 17:31:02 * mattsc goes back to working on Fred then
20161101 17:31:22< celticminstrel> I suppose we should think about making an exploration AI sometime...
20161101 17:32:38< mattsc> It’s on my A.I. list under “whenever”.
20161101 17:32:44< celticminstrel> Heh, okay.
20161101 17:33:02< mattsc> Lots of other things on it with higher priority.
20161101 17:33:09< celticminstrel> I seem to recall there were some Lua API issues with respect to detecting fog, shroud, and hidden units...
20161101 17:33:45< mattsc> Well, they aren’t issues in the sense that it is not working as advertised.
20161101 17:34:01< mattsc> And they aren’t just Lua API issues, it goes all the way back to the C++ code.
20161101 17:34:09< celticminstrel> Wait, it does?
20161101 17:34:56< mattsc> Yep.  The C++ pathfinding code considers shrouded terrain as unreachable; and there is no way to disable shroud separately from fog at the moment.
20161101 17:35:18< celticminstrel> What do you mean? (The second statement)
20161101 17:35:55< mattsc> You can either choose “see all” or “see nothing”.  But not “see terrain under shroud, but not hidden units under fog"
20161101 17:36:09< celticminstrel> Considering shrouded terrain as unreachable is probably pretty close to what you'd want, though giving it just a high cost might also work.
20161101 17:36:53< celticminstrel> So basically what you mean is that the AI can be made to respect both shroud and fog, or neither?
20161101 17:36:55-!- JyrkiVesterinen [~JyrkiVest@89-166-115-71.bb.dnainternet.fi] has joined #wesnoth-dev
20161101 17:37:07< mattsc> It depends with what you mean with “what you want”.  On a theoretical level and for lots of purposes, yes, but a bunch of AI code just does not work then.
20161101 17:37:35< mattsc> celticminstrel: no, I mean the pathfinding code can be made to respect both or neither.
20161101 17:37:49< mattsc> There are ways to work around that in the AI.  It’s just not done (yet).
20161101 17:38:27< mattsc> And I am only talking about the Lua AIs.  I am not going to touch the default C++ CAs.
20161101 17:38:58< mattsc> I’m going to wait until 1.13.6 is out, and then adapt the Lua AIs.
20161101 17:39:16< celticminstrel> But the pathfinding code is fairly generic, is it not?
20161101 17:39:23< celticminstrel> I mean, it's even used by the map generator.
20161101 17:39:34< mattsc> That’s why I do not want to touch it, really.
20161101 17:39:47< mattsc> Because under most circumstances it makes sense to work that way.
20161101 17:40:23< celticminstrel> Since it's fairly generic it should be possible to craft a cost function that respects whatever you want.
20161101 17:40:24< mattsc> But if you wanted to add (yet) another flag to find_routes(), you won’t hear any objections from me.
20161101 17:40:36< celticminstrel> Hmm.
20161101 17:40:51-!- louis94 [~~louis94@91.178.241.185] has joined #wesnoth-dev
20161101 17:40:52< mattsc> I had a quick look at the code, it does not look all that difficult.  I just personally do not want to do it.
20161101 17:41:02< celticminstrel> Which file is that in?
20161101 17:41:17< mattsc> And yes, on the cost functions, but there are simpler solutions (for the Lua AI purposes).
20161101 17:41:29< mattsc> src/pathfind/pathfind.cpp
20161101 17:41:54< celticminstrel> Whoa, that function is insane.
20161101 17:42:03< mattsc> :D
20161101 17:42:29< celticminstrel> Is that the generic pathfinder called from the Lua API, or...
20161101 17:42:56< mattsc> It’s the main Wesnoth pathfinding function, called from all over the place.
20161101 17:43:09< celticminstrel> Hmm.
20161101 17:43:12< mattsc> Well, maybe not called directly from all over the place, but used everywhere
20161101 17:44:48< celticminstrel> The Lua API calls a_star_search directly...
20161101 17:45:14< celticminstrel> (And the mapgen kernel's version of it needs updating.)
20161101 17:47:59< gfgtdf> celticminstrel: why that ?
20161101 17:48:07< celticminstrel> gfgtdf: What?
20161101 17:48:19< gfgtdf> celticminstrel: the mapgen kernels version updating
20161101 17:48:31< celticminstrel> Because it's different from the game lua kernel's version.
20161101 17:48:50< celticminstrel> It looks like it's missing some things.
20161101 17:49:10< JyrkiVesterinen> Why isn't it in lua_kernel_base then? Does it need to be different in the mapgen kernel?
20161101 17:49:19< celticminstrel> I have no idea.
20161101 17:49:32< celticminstrel> Maybe because it's not needed in the application_lua_kernel or something.
20161101 17:49:36< gfgtdf> celticminstrel: that's intentional, the normal version is mostly designed for units paths while the map mpagens version is mstly for generation maps
20161101 17:49:54< celticminstrel> Does it need to be different though?
20161101 17:50:09< celticminstrel> I think it could be confusing for it to be different.
20161101 17:51:01< celticminstrel> As far as I can tell, find_routes is not calling a_star_search anywhere...
20161101 17:51:15< gfgtdf> celticminstrel: also the mapgens function doesnt know about 'map' so its needs the map size passed as a third argument.
20161101 17:51:39< celticminstrel> Shouldn't that be third and fourth argument...
20161101 17:51:51< celticminstrel> Or wait, it could be in the form {w,h} I guess.
20161101 17:52:02< celticminstrel> But anyway it wouldn't hurt to allow that in game_lua_kernel.
20161101 17:52:05< gfgtdf> celticminstrel: no that is the path desintatio  liek in the norma find_path
20161101 17:53:54< gfgtdf> celticminstrel: the third and foruth prameter i mean
20161101 17:54:18< celticminstrel> You've lost me now.
20161101 17:54:38< celticminstrel> Anyway, besides needing the map size passed explicitly, is there any other reason for them to be different?
20161101 17:55:24< gfgtdf> celticminstrel: yes the mapgen function doesnt support 'path_options' as parmeter 5 since those are onyl about finding paths for units, a cost_function must be provided here
20161101 17:55:33< gfgtdf> those options*
20161101 17:55:40< celticminstrel> Uh, only three of the four options are irrelevant for mapgen.
20161101 17:55:58< celticminstrel> Oh, but I see, the options are in place of the cost function.
20161101 17:56:05< celticminstrel> So I guess it makes sense not to support them.
20161101 17:56:40< celticminstrel> I feel like max_cost could make sense even with a cost function...
20161101 17:56:52< celticminstrel> Can that be done in the cost function itself? I don't see how...
20161101 17:57:01< celticminstrel> Not that important though.
20161101 17:57:59< gfgtdf> celticminstrel: my guess would be that it can but not sure.
20161101 17:59:51< gfgtdf> celticminstrel: the lua cave mapgen also uses find_path to generate the passages (not rleatedot my previous message).
20161101 18:00:00< celticminstrel> I know.
20161101 18:00:18< celticminstrel> BTW gfgtdf, did you have any commits that need a changelog entry? If so you'd better add that asap.
20161101 18:00:44< celticminstrel> The default mapgen probably uses the pathfinder to generate roads, too.
20161101 18:01:58< celticminstrel> Oh, the third argument of the cost function seems like it could be used to implement a maximum path cost.
20161101 18:02:29< gfgtdf> celticminstrel: hmm no i did only bugfixes recently mainly to fix ub/crashes
20161101 18:02:50 * celticminstrel pokes vultraz about the same thing.
20161101 18:02:53< vultraz> what?
20161101 18:02:57< vultraz> uh
20161101 18:02:59< celticminstrel> Changelog.
20161101 18:03:03< vultraz> not that i can think of
20161101 18:03:15< celticminstrel> The new multiplayer UI is already there, then?
20161101 18:03:26 * celticminstrel should know but can't remember...
20161101 18:03:46< vultraz> maybe not, actually..
20161101 18:04:08< celticminstrel> Well, you should consider going through your recent commits, anyway.
20161101 18:04:14< celticminstrel> To see if anything was missed.
20161101 18:04:35< celticminstrel> Also, some PRs you merged may need changelog entries.
20161101 18:05:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161101 18:06:50 * celticminstrel wonders if all of tad's changes are in the changelog yet.
20161101 18:23:45< gfgtdf> vultraz: did you test that mp campagsn still wokr in the gui2 m stagin dialog? I meanw when in LoW you advance from chapter 1 to chapter 2 the mp staging dialog shown in between to let players choose a player for t new side 3. Did you test that ?
20161101 18:23:56< vultraz> no
20161101 18:26:41< gfgtdf> fom the code it seems liek this always calls https://github.com/wesnoth/wesnoth/blob/master/src/game_initialization/playcampaign.cpp#L355 code wlaywas calls mp::goto_mp_wait which alwaysuses the gui1 dialog.
20161101 18:26:55< gfgtdf> vultraz: the gui1 dialog still works i assume?
20161101 18:27:02< vultraz> I guess
20161101 18:27:08< vultraz> I haven't paid attention to it
20161101 18:28:02< celticminstrel> I think it does, but feel free to test it.
20161101 18:28:31< celticminstrel> So I guess on Sunday I can start mass-renaming GUI classes, right?
20161101 18:28:37< celticminstrel> And then merge it in once the release is tagged.
20161101 18:29:01< gfgtdf> celticminstrel: you mena like gui2 -> gui, gui ->gui_old ?
20161101 18:29:16< celticminstrel> No, I mean like tlistbox -> widgets::listbox
20161101 18:29:26< celticminstrel> (Well, gui2::widgets::listbox)
20161101 18:29:33< gfgtdf> celticminstrel: why woudl you want that?
20161101 18:29:40< gfgtdf> celticminstrel: that woudl brak all the t convention in the gui code
20161101 18:29:44< celticminstrel> Because the t prefix makes no sense whatsoeaver.
20161101 18:29:52< celticminstrel> Yes, the point is changing that t convention.
20161101 18:30:05< celticminstrel> Because it makes no sense whatsoever and leads to some very bizarre names.
20161101 18:30:22< vultraz> tone!
20161101 18:30:27< vultraz> terror!
20161101 18:30:34< celticminstrel> Mind you, I'm not entirely settled on the target naming strategy.
20161101 18:31:22< celticminstrel> I have two strategies in mind: dialogs are dlg_xxx and widgets are wgt_xxx; or using namespaces. (All non-dialog non-widget classes would just drop the t.)
20161101 18:31:55< gfgtdf> well specialyl when you have a lot of template code like in the gui2 evenhandling cpode its sure useful to see at first sight whether a name refers to a type or not.
20161101 18:32:50< celticminstrel> Can you point me at specific lines?
20161101 18:33:16< celticminstrel> So I can get a good example of what you mean.
20161101 18:36:13< gfgtdf> hmm searching
20161101 18:36:27< celticminstrel> ...my list of branches fills the console.
20161101 18:36:35< celticminstrel> I should do something about this.
20161101 18:36:55< vultraz> do you run console at 800x600 too? :P
20161101 18:37:06< celticminstrel> Consoles don't work that way.
20161101 18:37:22< celticminstrel> (Terminal is probably a better way to refer to it, since console refers to something else on Mac.)
20161101 18:37:32< vultraz> ah, right
20161101 18:37:47< celticminstrel> The default is apparently 100x24.
20161101 18:37:56< celticminstrel> But that's characters, not pixels.
20161101 18:38:00< vultraz> long time, since used macOS, have I
20161101 18:38:23< celticminstrel> I don't think that even works as a Yoda-ism.
20161101 18:38:52< celticminstrel> Yoda's reversals may sound bizarre, but I'm fairly sure they still work as valid (if obscure) English grammar.
20161101 18:38:56< celticminstrel> But that line does not.
20161101 18:39:21< celticminstrel> Plus it doesn't even have a verb.
20161101 18:39:21-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161101 18:39:32< celticminstrel> Well, a main verb. There's a verb in the sub-clause.
20161101 18:39:35-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20161101 18:41:15< gfgtdf> hmm can't find currnetly
20161101 18:44:34 * Nikitaw99 doesn't like gfgtdf's giant amount of typos for some reason.
20161101 18:45:00< Nikitaw99> (the ping was unintentional)
20161101 18:47:40< celticminstrel> I wish he could at least keep them out of the source, changelog, release notes, etc.
20161101 18:48:55< zookeeper> ah, i did it. it's so pretty, too: https://gist.github.com/ln-zookeeper/88dc602c68e821e0c87d6f9503903c93
20161101 18:49:54< Nikitaw99> zookeeper: did you know github gists support syntax highlighting for WML code?
20161101 18:50:05< Nikitaw99> just add the .cfg file extension in the end, hehe
20161101 18:50:14< celticminstrel> Nikitaw99: Uhh. Pretty sure that's not WML syntax highlighting.
20161101 18:50:26-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161101 18:50:27< Nikitaw99> celticminstrel: Well, it's something similar, I guess.
20161101 18:50:41-!- gfgtdf [~chatzilla@x4e36890d.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]]
20161101 18:50:49< Nikitaw99> i think that WML is built on some sort of other language (which is similar to XML)
20161101 18:51:09< shadowm> WML is WML.
20161101 18:51:21< Nikitaw99> [internal_confusion]
20161101 18:51:43< celticminstrel> Nikitaw99: My suspicion is that WML grew out of the conf file format.
20161101 18:51:59< celticminstrel> But I don't know the history, so that's just a suspicion.
20161101 18:52:09< shadowm> It's got nothing to do with XML except for a very slight resemblance. Even if you replaced square brackets with angular brackets you wouldn't get valid XML.
20161101 18:52:25< celticminstrel> Well, that's not entirely true.
20161101 18:52:52< celticminstrel> But parsing it as XML would treat the attributes as arbitrary text.
20161101 18:53:04< celticminstrel> Rather than as attributes.
20161101 18:53:17< shadowm> Okay. You wouldn't get valid XML that would actually correspond to the original contents.
20161101 18:53:22< celticminstrel> Yeah.
20161101 18:53:44< shadowm> That said, what I said is actually 100% true with Wesnoth version 0.1.
20161101 18:53:57< celticminstrel> How so?
20161101 18:54:02< celticminstrel> Did it not have closing tags yet?
20161101 18:54:10< shadowm> All closing tags were [end].
20161101 18:54:32< celticminstrel> Ah.
20161101 18:54:46< celticminstrel> Is 0.1 the first ever version?
20161101 18:54:54< shadowm> No.
20161101 18:54:58< shadowm> But yes. 
20161101 18:55:12< celticminstrel> So quantum.
20161101 18:55:40< shadowm> 0.1's tarball contained an even older tar in it with a previous version of the engine.
20161101 18:57:00< shadowm> All that said, WML is inspired by XML in that the author wanted to make a new language rather than use XML like everyone at the time was doing.
20161101 18:57:27< shadowm> But the resemblance ends with [end], which only went away like five releases later.
20161101 18:58:09< shadowm> Version 0.4.4.
20161101 19:04:02-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161101 19:08:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161101 19:28:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161101 19:29:16-!- louis94 [~~louis94@91.178.241.185] has quit [Ping timeout: 260 seconds]
20161101 19:56:51< vultraz> blah
20161101 19:57:03 * vultraz is sad reverse range-for doesn't exist
20161101 20:07:04< vultraz> I wonder if find_if/find works with boost::ptr_vector
20161101 20:07:06< vultraz> i'd assume so
20161101 20:07:56< vultraz> ah wait
20161101 20:07:58< vultraz> duh
20161101 20:08:04< vultraz> it takes an iterator >_>
20161101 20:08:07 * vultraz needs coffee
20161101 20:10:23-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20161101 20:18:00< vultraz> iiinteresting
20161101 20:18:44< vultraz> even though it's a ptr vector the values get accessed by reference..?
20161101 20:18:56< vultraz> let's see..
20161101 20:20:48 * vultraz should really make this a vector<unique_ptr<ttree_view_node>> at some point
20161101 20:22:08-!- louis94 [~~louis94@91.178.241.185] has joined #wesnoth-dev
20161101 20:22:27-!- Nikitaw99 [2e00a83b@gateway/web/freenode/ip.46.0.168.59] has quit [Quit: Page closed]
20161101 20:23:43-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161101 20:26:16< vultraz> ah, ok, i can't use std::find since ttree_view_node doesn't implement operator==
20161101 20:26:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161101 20:26:58-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161101 20:27:09 * vultraz wonders why find doesn't use an address-of comparison in lieu of operator==
20161101 20:28:20-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161101 20:29:42< JyrkiVesterinen> I suppose that using address-of comparison would be problematic if the programmer had intended to find an object with an identical value. Automatic address-of comparison would take away some compile-time safety.
20161101 20:30:23< JyrkiVesterinen> For example, if tpoint didn't implement operator==, and you wanted to find if the point (4,2) exists somewhere in a vector.
20161101 20:30:48< JyrkiVesterinen> An obvious way to check it is to construct a temporary tpoint and pass it to std::find().
20161101 20:31:20< JyrkiVesterinen> But if operator== didn't exist and std::find() fell back to address comparison, the find operation would compile and never find anything.
20161101 20:31:42< JyrkiVesterinen> Whereas without the automatic address-of it would fail to compile, alerting the programmer to fix it.
20161101 20:31:57< vultraz> ahh, I see what you mean
20161101 20:33:42-!- louis94 [~~louis94@91.178.241.185] has quit [Ping timeout: 265 seconds]
20161101 20:37:25< vultraz> would this be correct? 	bool operator==(ttree_view_node& node) { return this == &node; }
20161101 20:41:29< JyrkiVesterinen> Hmm, hard to say, actually.
20161101 20:41:30< vultraz> seems to build
20161101 20:41:49< JyrkiVesterinen> It depends on how comfortable you're with operator overloading.
20161101 20:42:13< JyrkiVesterinen> Operator== is usually supposed to mean "are the objects identical?"
20161101 20:42:39< vultraz> well, wouldn't this mean that?
20161101 20:42:57< JyrkiVesterinen> If you think it's fine for operator== to return true only when you're comparing the node with itself, then your implementation is correct.
20161101 20:43:11< vultraz> oh, hm..
20161101 20:43:59< JyrkiVesterinen> On the other hand, if you think it would be reasonable to expect it to perform a recursive comparison or something, you could just use std::find_if() instead of overloading operator==.
20161101 20:44:33< vultraz> I figured this might be a way to make it so find_if didn't have to be used for simple address-of comparison
20161101 20:44:45< vultraz> ie
20161101 20:44:47< vultraz> auto itor = std::find(parent_children.begin(), parent_children.end(), *node);
20161101 20:44:49< vultraz> instead of
20161101 20:45:01< vultraz> auto itor = std::find_if(parent_children.begin(), parent_children.end(), [node](ttree_view_node& child_node) { return &child_node == node; });
20161101 20:45:58< JyrkiVesterinen> If you prefer that, then it's fine. :)
20161101 20:47:13< vultraz> btw, what does it mean if an operator is declared as friend?
20161101 20:47:55< JyrkiVesterinen> It is possible to declare operators outside the class.
20161101 20:48:16< JyrkiVesterinen> You can make such an operator a friend function, just like any freestanding function.
20161101 20:50:04< shadowm> Friend methods or classes have access to members of the current class with the same visibility as the friend declaration.
20161101 20:50:37-!- mjs-de [~mjs-de@x4db65565.dyn.telefonica.de] has quit [Remote host closed the connection]
20161101 20:50:40< shadowm> So e.g. class A { protected: friend class B; }; -- class B now can access protected members of class A without having to be a subclass of A.
20161101 20:51:56< shadowm> Without friend declarations the usual visibility rules apply. Private members may only be accessed by members of the same class, and protected members may only be accessed by subclasses.
20161101 20:52:58< vultraz> hmm
20161101 20:54:03< vultraz> giving all that, I still cannot see why this operator was declared friend: https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/multiplayer/mp_options_helper.hpp#L45
20161101 20:54:51< JyrkiVesterinen> Declaring that as friend doesn't make any sense.
20161101 20:55:36< shadowm> That's defining bool operator<(const option_source&, const option_source&) as a non-member friend function.
20161101 20:55:36< JyrkiVesterinen> It's within the struct declaration and has access to everything inside the struct even without the "friend" keyword. I didn't even know the keyword is allowed there.
20161101 20:55:59< JyrkiVesterinen> Besides, all members of the struct are public anyway.
20161101 20:56:42< shadowm> I don't think I've seen comparison operators be class members in the first place.
20161101 20:57:40< vultraz> they're not supposed to be?
20161101 20:58:11< shadowm> Not with that signature.
20161101 20:58:30< JyrkiVesterinen> That operator is a one-liner. IMO, its definition belongs in the header.
20161101 20:58:41< JyrkiVesterinen> I'd prefer if you just removed the "friend" keyword.
20161101 20:59:14< shadowm> That's not going to work well.
20161101 20:59:55< shadowm> The friend keyword is there to define the operator as a non-member function. Binary operator overloads aren't supposed to have that signature if they are member methods.
20161101 21:00:33< shadowm> I believe as a member method it'd have to be something like T& operator$(const T&) instead.
20161101 21:00:57< JyrkiVesterinen> Oh, right. The operator receives two option_source object references, and apparently can't access "this".
20161101 21:01:29< shadowm> As for why the friend specifier is needed, option_source is a private type to tmp_options_helper, so an operator defined in the parent namespace shouldn't be able to access option_source regardless of its own members' visibility.
20161101 21:01:52< shadowm> *private type belonging to
20161101 21:01:55 * vultraz attempts to understand this
20161101 21:02:21< JyrkiVesterinen> As a member function, its declaration would be "bool operator<(const option_source& b)" and the object currently accessible as "a" would be "*this".
20161101 21:03:35< shadowm> Oh right, operator< is supposed to return bool, not *this. :p
20161101 21:03:54< shadowm> I had written it above as if it were the latter.
20161101 21:04:07< vultraz> wait, so friend T operator& can take more than one argument
20161101 21:04:09< vultraz> huh
20161101 21:04:15< vultraz> s/&/$
20161101 21:04:54< JyrkiVesterinen> I didn't know about that either.
20161101 21:05:10< JyrkiVesterinen> (I haven't had a need to overload operators that much.)
20161101 21:05:25< vultraz> but why did you just say it can't access 'this' but then said it could use '*this'...
20161101 21:05:29 * vultraz is confused :|
20161101 21:05:55< shadowm> Okay, see the convenient table here for the operator signatures for member operators vs. non-members: http://en.cppreference.com/w/cpp/language/operators
20161101 21:06:17< JyrkiVesterinen> The operator, as currently implemented (binary operator) can't access "this". It receives the first object as "a".
20161101 21:07:04< JyrkiVesterinen> If someone changes its signature to "bool operator<(const option_source& b)", it gains access to "this" (formerly a)" and no longer receives an "a" parameter.
20161101 21:07:29< shadowm> Whether an operator that can be either a member or non-member should be either depends on the use case, really.
20161101 21:09:07< shadowm> I've always declared binary operators as non-members because it seems more natural to have the correct number of arguments than have one of them become `this`.
20161101 21:09:21-!- bobbytables [~bobbytabl@ec2-54-173-117-95.compute-1.amazonaws.com] has joined #wesnoth-dev
20161101 21:10:15< shadowm> As for the particular use of the `friend` keyword that gets involved here see http://en.cppreference.com/w/cpp/language/friend case #2.
20161101 21:10:48< vultraz> hmmm
20161101 21:10:52< vultraz> ok, I get it
20161101 21:12:12< vultraz> ok, what was I doing before all this..
20161101 21:12:33< vultraz> I was refactoring the options helper to avoid unnecessary node recreation, yes.
20161101 21:23:43-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161101 21:24:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161101 21:27:05< vultraz> using clear() on a vector of pointers deletes the pointers, right?
20161101 21:28:15< JyrkiVesterinen> Yes, it deletes the pointers themselves.
20161101 21:28:40< JyrkiVesterinen> If they are raw pointers (i.e. std::vector<T*>), the clear() function doesn't delete anything else.
20161101 21:29:17< JyrkiVesterinen> If they are smart pointers, e.g. std::vector<std::shared_ptr<T>>, then clear() may delete target objects as well.
20161101 21:30:09< vultraz> raw pointers in this case, so I'm good
20161101 21:30:22-!- irker118 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161101 21:30:22< irker118> wesnoth: Jyrki Vesterinen wesnoth:fixed-size-chatbox 2275939230b4 / / (8 files in 3 dirs): WIP: a widget that forces its child widget to a fixed size https://github.com/wesnoth/wesnoth/commit/2275939230b42f930ab206cd0526e00400d90b39
20161101 21:30:22< irker118> wesnoth: Jyrki Vesterinen wesnoth:fixed-size-chatbox 25aefd9c1971 / / (8 files in 3 dirs): Minor fixes https://github.com/wesnoth/wesnoth/commit/25aefd9c1971215d81f842ae57e61dd063dfb0f0
20161101 21:30:22< irker118> wesnoth: Jyrki Vesterinen wesnoth:fixed-size-chatbox 467892f8ffcc / data/gui/ (macros/_initial.cfg schema.cfg widget/size_lock_default.cfg): The WML part https://github.com/wesnoth/wesnoth/commit/467892f8ffcc89583104c372e4ec0437097851df
20161101 21:30:23< irker118> wesnoth: Jyrki Vesterinen wesnoth:fixed-size-chatbox a40533849061 / src/gui/widgets/size_lock.cpp: Fix crashes https://github.com/wesnoth/wesnoth/commit/a405338490612db50db83d7937fedd834350d2e5
20161101 21:37:11-!- JyrkiVesterinen [~JyrkiVest@89-166-115-71.bb.dnainternet.fi] has quit [Quit: Going to bed]
20161101 21:44:07< vultraz> blah, code gets complicated once once stops doing exclusive clears
20161101 21:49:58< vultraz> hmmm
20161101 21:50:08< vultraz> ok, so std::remove_if doesn't actually remove anything
20161101 21:51:42< vultraz> hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
20161101 21:51:54< vultraz> vector::erase takes an iter range
20161101 21:52:19< vultraz> and remove_if returns a new past-end iterator
20161101 21:52:48< vultraz> celticminstrel: is vector.erase(std::remove_if(stuff), vector.end()) is correct?
20161101 21:53:20< vultraz> er, ignore the second 'is'
20161101 21:56:59< vultraz> I suppose one could also loop over the vector and do conditional check on each element
20161101 21:57:11< vultraz> still, dunno if that would even work
20161101 21:57:26< vultraz> wouldn't iterating over a container and removing elements within that loop invalidate the loop?
20161101 21:58:38< bobbytables> Is the "map diff tool" specified here http://wiki.wesnoth.org/EasyCoding still relevant?
20161101 21:59:51< celticminstrel> vultraz: Reverse range-for isn't too hard to make work. I think we might even do it in the quit confirmation class.
20161101 21:59:52< vultraz> yes
20161101 21:59:52< celticminstrel> [Nov 01@5:27:05pm] vultraz: using clear() on a vector of pointers deletes the pointers, right?
20161101 21:59:53< celticminstrel> Uhh. No.
20161101 22:00:07< vultraz> (that was to bobbytables)
20161101 22:00:29< vultraz> hm. quit_confirmation uses boost::adaptors::reverse
20161101 22:00:33< celticminstrel> That line is correct if you want to erase the elements found by remove_if.
20161101 22:00:58< vultraz> yes, that is what I want.
20161101 22:01:21< celticminstrel> std::remove_if moves the matched members to the end of the list and returns an iterator to the first of them.
20161101 22:02:39< celticminstrel> For the record, most binary non-assignment operators are better defined as global functions rather than class members IMO.
20161101 22:04:13 * celticminstrel kind of wishes that .* could be overloaded, and also that -> could be more generically overloaded.
20161101 22:06:00-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 260 seconds]
20161101 22:06:37< celticminstrel> In particular, I wish you could overload -> for enum types.
20161101 22:07:04< celticminstrel> I'm forced to use (*e).x instead of e->x because of this.
20161101 22:13:22< celticminstrel> ...wait! In C++17, custom operator&& and operator|| can short-circuit? O_O
20161101 22:13:26< celticminstrel> How does this work...?
20161101 22:18:28< celticminstrel> Maybe the page is wrong about that? Google doesn't seem to turn up anything...
20161101 22:24:35< celticminstrel> Ooh, folds for template parameter packs sound useful.
20161101 22:25:23-!- louis94 [~~louis94@91.178.241.185] has joined #wesnoth-dev
20161101 22:56:18-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
20161101 22:59:03-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161101 23:08:01-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161101 23:19:32-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Read error: Connection reset by peer]
20161101 23:24:32-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161101 23:33:51-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161101 23:36:27-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Client Quit]
--- Log closed Wed Nov 02 00:00:06 2016