--- Log opened Sun Oct 23 00:00:10 2016
20161023 00:01:00-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161023 00:31:21-!- Bonobo [~Bonobo@2001:44b8:254:3200:e4b5:c14d:1fff:4741] has joined #wesnoth-dev
20161023 00:41:05-!- Bonobo [~Bonobo@2001:44b8:254:3200:e4b5:c14d:1fff:4741] has quit [Ping timeout: 260 seconds]
20161023 00:59:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161023 01:02:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161023 01:17:28-!- skeletenchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 265 seconds]
20161023 01:20:03-!- skeletenchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20161023 01:41:13-!- gfgtdf_ [~chatzilla@x4e3685ea.dyn.telefonica.de] has joined #wesnoth-dev
20161023 01:43:49-!- gfgtdf [~chatzilla@x4e363e7a.dyn.telefonica.de] has quit [Ping timeout: 276 seconds]
20161023 01:43:52-!- gfgtdf_ is now known as gfgtdf
20161023 01:44:33-!- gfgtdf [~chatzilla@x4e3685ea.dyn.telefonica.de] has quit [Client Quit]
20161023 01:57:33-!- crimson_penguin [~crimson_p@ec2.happyspork.com] has quit [Changing host]
20161023 01:57:33-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20161023 02:23:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161023 02:36:46-!- Bonobo [~Bonobo@2001:44b8:254:3200:e4b5:c14d:1fff:4741] has joined #wesnoth-dev
20161023 02:45:42< irker109> wesnoth: Gregory A Lundberg wesnoth:master bc67f01909b6 / data/core/macros/ai_controller.cfg: AI Controller Bug fix: deprecation message https://github.com/wesnoth/wesnoth/commit/bc67f01909b6b23d9b89b5b9d690c04be3835985
20161023 02:45:44< irker109> wesnoth: Charles Dang wesnoth:master cc91cdff4a2f / data/core/macros/ai_controller.cfg: Merge pull request #838 from GregoryLundberg/GL_option_message https://github.com/wesnoth/wesnoth/commit/cc91cdff4a2f78d352d24780826192730bd30b84
20161023 02:51:17-!- Bonobo [~Bonobo@2001:44b8:254:3200:e4b5:c14d:1fff:4741] has quit [Ping timeout: 260 seconds]
20161023 03:51:24-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 250 seconds]
20161023 04:06:15-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161023 04:11:02-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 04:44:38-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
20161023 04:47:10-!- Bonobo [~Bonobo@2001:44b8:254:3200:e4b5:c14d:1fff:4741] has joined #wesnoth-dev
20161023 04:54:26-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161023 05:00:32-!- Bonobo [~Bonobo@2001:44b8:254:3200:e4b5:c14d:1fff:4741] has quit [Ping timeout: 260 seconds]
20161023 05:41:02-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161023 05:45:59-!- irker109 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161023 06:18:37-!- karthago [~edgrey@178.205.0.69] has joined #wesnoth-dev
20161023 06:19:33-!- onon_ [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has joined #wesnoth-dev
20161023 06:21:15< onon_> "this is not a multiplayer save"
20161023 06:21:24< onon_> the bane of my existence
20161023 06:46:31< vultraz> heh
20161023 06:53:13-!- karthago [~edgrey@178.205.0.69] has quit [Ping timeout: 256 seconds]
20161023 07:01:14-!- Bonobo [~Bonobo@2001:44b8:254:3200:e4b5:c14d:1fff:4741] has joined #wesnoth-dev
20161023 07:25:23-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161023 07:33:39< vultraz> celticminstrel: I'm curious if this is possible: foo* ptr; ptr = dynamic_cast<std::result_of<func()>::value>(ptr);
20161023 07:40:11< vultraz> or something like this: template<typename T> T* get(); foo* ptr; decltype(ptr) bar = dynamic_cast<std::result_of<func()>::value>(ptr); get<bar>();
20161023 07:40:18< vultraz> celticminstrel: is that in any way possible?
20161023 07:42:13< matthiaskgr> are saurian skirmishers supposed to walk on implassible terrain?! o_O
20161023 07:43:05< vultraz> likely not
20161023 07:46:37-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161023 08:00:46< vultraz> blah, I need iceiceice or someone who's skilled with c++
20161023 08:08:44-!- irker728 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161023 08:08:44< irker728> wesnoth: Gregory A Lundberg wesnoth:master 8da524d984bb / data/core/macros/ai_controller.cfg: AI Controller Fix bug: infinite recusion https://github.com/wesnoth/wesnoth/commit/8da524d984bb61dad64fc144c82076ff858018cc
20161023 08:08:44< irker728> wesnoth: Charles Dang wesnoth:master 668183bbfe23 / data/core/macros/ai_controller.cfg: Merge pull request #839 from GregoryLundberg/GL_stop_infinite_recursion https://github.com/wesnoth/wesnoth/commit/668183bbfe23ed69b8e31a17863d7936b47234b8
20161023 08:09:18< tad_carlucci> vultraz, Be sure zookeeper sees those last two. He'll want to take them off his backlog.
20161023 08:09:29< vultraz> ok
20161023 08:12:14-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161023 08:18:44-!- 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.]
20161023 08:34:27< onon_> so no one have advice on how to solve "this is not a multiplayer save" ?
20161023 08:35:24< vultraz> use multiplayer saves :)
20161023 08:38:17-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161023 08:41:18< celticminstrel> vultraz: I'm not sure what you're going for with that but it looks wrong to me.
20161023 08:41:41< celticminstrel> Maybe if you explained the intent rather than trying to guess the method?
20161023 08:41:50< vultraz> nothing that i particularly need but i was just wondering if it could be done
20161023 08:42:12< celticminstrel> Like I said, it looks wrong to me.
20161023 08:42:21< celticminstrel> Specifically std::result_of<func()>
20161023 08:42:41< celticminstrel> But I have no idea what you intend it to do. There may be a way.
20161023 08:43:34 * celticminstrel definitely needs to stop staying up so late though.
20161023 08:43:59< vultraz> In this case I realize there wouldn't be, since you cannot store typenames.
20161023 08:43:59-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20161023 08:46:07< vultraz> though I suppose it could be managed
20161023 08:46:14< vultraz> differently
20161023 08:46:31< vultraz> say, a bunch of overloads returning different types
20161023 08:48:38-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161023 08:49:35< vultraz> [19:08:43]	irker728	wesnoth: Gregory A Lundberg wesnoth:master 8da524d984bb / data/core/macros/ai_controller.cfg: AI Controller Fix bug: infinite recusion https://github.com/wesnoth/wesnoth/commit/8da524d984bb61dad64fc144c82076ff858018cc
20161023 08:49:37< vultraz> [19:08:43]	irker728	wesnoth: Charles Dang wesnoth:master 668183bbfe23 / data/core/macros/ai_controller.cfg: Merge pull request #839 from GregoryLundberg/GL_stop_infinite_recursion https://github.com/wesnoth/wesnoth/commit/668183bbfe23ed69b8e31a17863d7936b47234b8
20161023 08:49:38< vultraz> [19:09:16]	tad_carlucci	vultraz, Be sure zookeeper sees those last two. He'll want to take them off his backlog.
20161023 08:54:48< zookeeper> i think in "those two" he didn't include the merge commit :P
20161023 08:55:43< zookeeper> i have no idea what that infinite recursion thing is/was about
20161023 08:57:19-!- karthago [~edgrey@178.205.86.117] has joined #wesnoth-dev
20161023 09:19:52-!- mjs-de [~mjs-de@x4db5056f.dyn.telefonica.de] has joined #wesnoth-dev
20161023 09:36:31-!- astrelyon [~astrelyon@dh207-109-91.xnet.hr] has joined #wesnoth-dev
20161023 09:36:48-!- Appleman1234 [~Appleman1@KD106181178136.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20161023 10:10:48< irker728> wesnoth: Charles Dang wesnoth:master 2e2bee75752e / src/gui/dialogs/multiplayer/mp_options_helper.cpp: MP Options Helper: further refactoring https://github.com/wesnoth/wesnoth/commit/2e2bee75752e1e854c0d4e54872963877357e1f2
20161023 10:12:05< vultraz> could someone perhaps tell me why the hell this doesn
20161023 10:12:09< vultraz> 't build: https://github.com/Vultraz/wesnoth/commit/bdc621f84f268f052d67c3cf00a05d799671c7ca
20161023 10:12:22-!- Appleman1234 [~Appleman1@KD106181178136.au-net.ne.jp] has joined #wesnoth-dev
20161023 10:12:24< vultraz> mp_options_helper.cpp|76|error: template-id 'update_options_data_map<>' for 'void gui2::tmp_options_helper::update_options_data_map(gui2::tmenu_button*, const gui2::tmp_options_helper::option_source&, const config&)' does not match any template declaration|
20161023 10:12:27< vultraz> I don't get it :|
20161023 10:26:03< Aginor_> that's the implementation, has it been declared anywhere?
20161023 10:26:57< vultraz> the declaration is in the commit too..
20161023 10:29:24< Aginor_> it is, but without the template tag
20161023 10:29:33< Aginor_> that may be a problem
20161023 10:29:55< Aginor_> I'm not very knowledgable about templates
20161023 10:29:57-!- Aginor_ is now known as Aginor
20161023 10:31:10-!- Aginor [~andreas@apollo.alternating.net] has quit [Changing host]
20161023 10:31:10-!- Aginor [~andreas@unaffiliated/aginor] has joined #wesnoth-dev
20161023 10:35:43< matthiaskgr> hm :( 
20161023 10:35:51< matthiaskgr> looks like the planning mode crash reappeared
20161023 10:35:56< matthiaskgr> when moving recruited units
20161023 10:36:06< matthiaskgr> ( planned recruit)
20161023 10:38:21-!- onon_ [d2564fc3@gateway/web/freenode/ip.210.86.79.195] has quit [Ping timeout: 260 seconds]
20161023 10:49:57< irker728> wesnoth: Wedge009 wesnoth:master 5d144595945a / src/tod_manager.cpp: Initialise member has_tod_bonus_changed_ in constructor (bug #25218) https://github.com/wesnoth/wesnoth/commit/5d144595945ae3a5614433105d621eef2298f657
20161023 11:02:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161023 11:26:41-!- wesnoth [52ee2fc0@gateway/web/freenode/ip.82.238.47.192] has joined #wesnoth-dev
20161023 11:29:32-!- louis94 [~~louis94@91.178.241.241] has joined #wesnoth-dev
20161023 11:30:17-!- wesnoth [52ee2fc0@gateway/web/freenode/ip.82.238.47.192] has left #wesnoth-dev []
20161023 11:31:17-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161023 11:33:05< vultraz> the template tag isn't (shouldn't) be the problem
20161023 11:34:30< vultraz> I'll ask jyrki if he comes around later..
20161023 11:39:49< vultraz> (also good god, just how much UB do we have P_P )
20161023 11:46:44-!- Neoriceisgood [5658167a@gateway/web/freenode/ip.86.88.22.122] has joined #wesnoth-dev
20161023 11:47:01< Neoriceisgood> Sup you stinky old danger dogs
20161023 11:48:20< vultraz> o_O
20161023 11:48:30 * Neoriceisgood goes AFK immediately :)
20161023 11:48:45-!- louis94 [~~louis94@91.178.241.241] has quit [Ping timeout: 244 seconds]
20161023 11:49:05< vultraz> ... well then
20161023 11:54:25< vultraz> Neoriceisgood: why have you returned?
20161023 12:36:39-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161023 12:59:53-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20161023 13:00:28-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
20161023 13:06:20-!- louis94 [~~louis94@91.178.241.241] has joined #wesnoth-dev
20161023 13:11:31-!- Appleman1234 [~Appleman1@KD106181178136.au-net.ne.jp] has quit [Ping timeout: 276 seconds]
20161023 13:23:20< Neoriceisgood> Hi.
20161023 13:28:55-!- JyrkiVesterinen [~JyrkiVest@87-100-144-97.bb.dnainternet.fi] has joined #wesnoth-dev
20161023 13:30:44-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161023 13:32:53-!- Appleman1234 [~Appleman1@KD106181166126.au-net.ne.jp] has joined #wesnoth-dev
20161023 13:48:07-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161023 13:50:31-!- irker728 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161023 13:51:26-!- Neoriceisgood [5658167a@gateway/web/freenode/ip.86.88.22.122] has quit [Ping timeout: 260 seconds]
20161023 13:53:37-!- irker032 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161023 13:53:37< irker032> wesnoth: Jyrki Vesterinen wesnoth:master e7c2105c48f0 / / (6 files in 4 dirs): Add a script to simulate heavy lobby traffic https://github.com/wesnoth/wesnoth/commit/e7c2105c48f0dd0b0b43c489357f2beb65fbd57c
20161023 14:00:40< tad_carlucci> zookeeper, The "last two" I was referring to were the changed to the AI Controller script. I eliminated the messages about [option]message=, completing the upgrade for that in mainline, and the messages about inifinte recusion being stopped. We'd talked about the macro a couple months ago and you said you'd get to it someday. Beat you to it.
20161023 14:01:30< tad_carlucci> There's an old-ish bug report on gna about slowing down in the macro. This completes the fix for that.
20161023 14:02:11< zookeeper> if there's a report relating to the recursion thing, please link
20161023 14:02:38 * vultraz pings JyrkiVesterinen
20161023 14:02:47< JyrkiVesterinen> What do you need?
20161023 14:03:17< vultraz> JyrkiVesterinen: any idea why this doesn't buld  https://github.com/Vultraz/wesnoth/commit/bdc621f84f268f052d67c3cf00a05d799671c7ca
20161023 14:03:24< vultraz> [21:12:21]	vultraz	mp_options_helper.cpp|76|error: template-id 'update_options_data_map<>' for 'void gui2::tmp_options_helper::update_options_data_map(gui2::tmenu_button*, const gui2::tmp_options_helper::option_source&, const config&)' does not match any template declaration|
20161023 14:03:28< vultraz> it
20161023 14:03:35< tad_carlucci> ok. it'll take some digging. I was testing to see if it still occurred andnot the messages. I'm idling in case more is needed for the Lua upgrade and had nothing to do. I'll get that link in a moment
20161023 14:03:41< vultraz> 's exactly the same as the specialization under it :/
20161023 14:08:20-!- gfgtdf [~chatzilla@x4e3685ea.dyn.telefonica.de] has joined #wesnoth-dev
20161023 14:09:18< JyrkiVesterinen> vultraz: A couple of things you can try.
20161023 14:09:34< JyrkiVesterinen> First, you can try moving the definition(s) of the template function to the header.
20161023 14:10:02< JyrkiVesterinen> Second, I'm not sure if the template specialization syntax here is 100% correct. This might work:
20161023 14:10:28< JyrkiVesterinen> void tmp_options_helper::update_options_data_map<tmenu_button>(tmenu_button* widget, const option_source& source, const config& cfg)
20161023 14:10:49< JyrkiVesterinen> (The difference is the addition of the <tmenu_button> part.)
20161023 14:11:23< gfgtdf> JyrkiVesterinen: i donwer why wesnoth,random was used n the lua kernel base, i mena in the aplpication kernel there is realyl n prblme with just using math.random
20161023 14:11:48< JyrkiVesterinen> gfgtdf: I explained that in the commit message.
20161023 14:11:57< JyrkiVesterinen> Math.random() uses a fixed seed.
20161023 14:12:22< JyrkiVesterinen> As a result, all the clients performed the exact same actions. I found that by simply testing my script.
20161023 14:12:43< gfgtdf> JyrkiVesterinen: also did you test that wesnoth-random still wokrs in map gnereator, ? not that the map generator kernel needs a different implmementation of wesnoth.random
20161023 14:13:19< gfgtdf> note*
20161023 14:13:57< JyrkiVesterinen> No, I didn't test that.
20161023 14:14:22< JyrkiVesterinen> Its behavior shouldn't have changed at all, though. I merely moved the code from game_lua_kernel to lua_kernel_base.
20161023 14:15:17< JyrkiVesterinen> vultraz: I thought a bit more about your code. The function you added shouldn't be a template specialization at all, as it has different parameters than the template.
20161023 14:15:27< tad_carlucci> zookeeper, https://gna.org/bugs/index.php?24598
20161023 14:15:31< vultraz> ...ahh
20161023 14:17:28< vultraz> so you can't overload a templated function with one with different parameters?
20161023 14:17:38< gfgtdf> JyrkiVesterinen: yes but the map gernerator doesn't use that function, if the map generator code would now use that function defined in the kernel base instead of of the map gernertor wesnoth.random that'd be bad.
20161023 14:18:02< JyrkiVesterinen> vultraz: Indeed, you can't.
20161023 14:18:10< vultraz> Interesting
20161023 14:19:40< JyrkiVesterinen> gfgtdf: which map generator are you even talking about?
20161023 14:19:45-!- DeFender1031 [~DeFender1@46-116-17-86.bb.netvision.net.il] has quit [Quit: I'm not back now.]
20161023 14:19:53< gfgtdf> JyrkiVesterinen: the lua map gernerator
20161023 14:20:12< JyrkiVesterinen> With a quick search I found only data/lua/cave_map_generator.lua, and it does use wesnoth.random as far as I can tell.
20161023 14:20:13< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/e7c2105c48f0dd0b0b43c489357f2beb65fbd57c/data/lua/cave_map_generator.lua#L3
20161023 14:21:56< gfgtdf> JyrkiVesterinen: yes i know the my quetion is whether it works teh same way, mening  it shodul not use the code that you moved to teh kernel_base.
20161023 14:22:43< JyrkiVesterinen> Uh, the map generator already used the same function before.
20161023 14:23:12< vultraz> huh, and this even works
20161023 14:23:13< vultraz> options_data_[source][widget->id()] = cfg.child_range("item")[widget->get_value()]["value"].str();
20161023 14:23:16 * vultraz ponders why
20161023 14:23:28< gfgtdf> JyrkiVesterinen: no it used a diffetn function, as the wesnoth,randm was defined in 2 differnt wqays in the mpagen lua kernel and the game lua kernel
20161023 14:23:49< vultraz> I thought child_range was an iterator range
20161023 14:24:01< vultraz> so why does it seem to function as an indexed list 
20161023 14:25:21< JyrkiVesterinen> gfgtdf: Ah, I see. We have a separate mapgen_lua_kernel, and it has its own wesnoth.random() function.
20161023 14:25:23< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/e7c2105c48f0dd0b0b43c489357f2beb65fbd57c/src/scripting/mapgen_lua_kernel.cpp#L41-L44
20161023 14:25:42< JyrkiVesterinen> (IMHO, duplicating that function was never a good idea to begin with...)
20161023 14:26:04< JyrkiVesterinen> I'll investigate if there are differences.
20161023 14:26:52< gfgtdf> JyrkiVesterinen: my question was , does the mapgenl wesnot,hrnadom still work in the expected way, or does the wesnoth.random in kernel_base now overwrite teh one from the mapgen kernel ?
20161023 14:28:34< JyrkiVesterinen> Looks like it's implementation defined.
20161023 14:28:57< JyrkiVesterinen> mapgen_lua_kernel constructor runs after the lua_kernel_base constructor.
20161023 14:29:13< JyrkiVesterinen> It uses luaL_setfuncs() to register the callbacks.
20161023 14:29:47< JyrkiVesterinen> The documentation of luaL_setfuncs() doesn't say anything about what happens if functions with the same names are already registered.
20161023 14:29:54< irker032> wesnoth: Charles Dang wesnoth:master b1d886baea87 / src/gui/dialogs/multiplayer/ (mp_options_helper.cpp mp_options_helper.hpp): MP Options Helper: fixed choice options saving indexes instead of values https://github.com/wesnoth/wesnoth/commit/b1d886baea8740504ff44f418c8276e7ece0aaaa
20161023 14:32:52< zookeeper> tad_carlucci, that says nothing about any "messages about infinite recursion"
20161023 14:32:59< zookeeper> what messages?
20161023 14:33:54< tad_carlucci> I was testing with the last scene from liberty doing the ally ia instructions and the stderr messages were about deprecation and loop snubbed.
20161023 14:33:57-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161023 14:34:00< vultraz> ok, one other bug...
20161023 14:34:14< vultraz> for some reason, the Default button resets options outside its node..
20161023 14:34:41< zookeeper> tad_carlucci, i can't make any sense of your words
20161023 14:34:43< vultraz> which is odd
20161023 14:36:49< vultraz> I wonder if it's because the containers use copies
20161023 14:36:54< vultraz> and not pointers?
20161023 14:37:43< zookeeper> tad_carlucci, also bug #24598 is obviously an engine bug, so if you workaround an engine bug in WML you should say so in the commit message
20161023 14:38:03< vultraz> hm
20161023 14:38:06< vultraz> ok, so option data is..
20161023 14:38:08< vultraz> std::map<option_source, option_map> options_data_;
20161023 14:38:14< vultraz> and option_source is a struct
20161023 14:38:45< vultraz> I wonder how the map distinguishes them..?
20161023 14:39:04-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 14:40:42< gfgtdf> vultraz: it uses operator <
20161023 14:40:58< vultraz> hm ok
20161023 14:41:02< gfgtdf> vultraz: but it seems like operator < is implemented wrongly
20161023 14:41:07< vultraz> hm?
20161023 14:41:11< tad_carlucci> zookeeper, The fix in the engine was to stop the recusion and display a message. My fix prevents the recusion so no message
20161023 14:41:48< zookeeper> tad_carlucci, what fix in the engine?
20161023 14:41:53< gfgtdf> vultraz:  "a.level_type < b.level_type && a.id < b.id;" is looks wrong
20161023 14:42:10< vultraz> what would it be otherwise?
20161023 14:42:39< gfgtdf> vultraz: "a.level_type < b.level_type || ( a.level_type == b.level_type && a.id < b.id);"
20161023 14:44:58< tad_carlucci> To stop [insert_tag] creating an infinite loop
20161023 14:45:58< zookeeper> infinite loop means that the game freezes. IIRC no one has told me that the AI controller freezes.
20161023 14:46:08< zookeeper> nor does it in my experience
20161023 14:46:22< zookeeper> so i still have no idea what this is about
20161023 14:48:42< vultraz> gfgtdf: that works thanks
20161023 14:50:14< irker032> wesnoth: Charles Dang wesnoth:master e6122aefcaab / src/gui/dialogs/multiplayer/mp_options_helper.hpp: MP Options Helper: correctly implement option_source::operator< https://github.com/wesnoth/wesnoth/commit/e6122aefcaab170ac7767d479f2d621880826cc0
20161023 14:50:41< vultraz> still might consider a unique_ptr in the future tho
20161023 14:52:10< vultraz> i dunno if it would be more efficient
20161023 14:52:44-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 260 seconds]
20161023 14:56:41< tad_carlucci> zookeeper, The gna comment is about message options I chose the ai controller because it does a lot of that in a loop. the messaages on the screen were than the engine prvented the loop. I killed the messages. 
20161023 14:59:40< vultraz> TFW you find out your gui2 options helper code is half the side of the gui1 code : )
20161023 15:00:59< vultraz> size*
20161023 15:01:11< vultraz> still a few things i'd like to optimize, though
20161023 15:01:19< zookeeper> tad_carlucci, yes, i know because that's what you've been saying.
20161023 15:01:44< vultraz> for example, every time Defaults are reset or game/era/mods change, ALL the nodes are reset
20161023 15:01:53-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161023 15:02:10< zookeeper> tad_carlucci, i still have no idea what this is about. what engine bug? what recursion? why was a warning added? what does it check? what commit, what bug number, what anything?
20161023 15:02:48< zookeeper> i started by saying i have no idea what this is about, and that means i can't deduce anything from vague references to something i don't know about
20161023 15:04:18< tad_carlucci> zookeeper, I don't know when the check was added to [insert_tag] the warning was obviously added because it had to say something for the throw() I don't know if there was a bug number; git blame will find the commit if it's important.
20161023 15:04:49< zookeeper> if you have better things to do than dig up the relevant pieces of context for me then that's fine, but i'm just saying that i was specifically made aware of a change and that means i'm expected to be able to assess it somehow, but i can't.
20161023 15:05:10< tad_carlucci> zookeeper, The reason I thought you'd be interested in my commits is back when I did Liberty we talked about these messages and you said someday you'd get to them.
20161023 15:05:49< zookeeper> i can dig it up from my irclogs if you give me something to search by
20161023 15:06:28< tad_carlucci> zookeeper, And the reason I was looking at Liberty was I was browsing the open gna notes from the past year or so and it ran a bell so I tested.
20161023 15:07:04< tad_carlucci> zookeeper, As to checking IRC logs, I guess search for the library merge and look around.
20161023 15:07:12< tad_carlucci> *liberty
20161023 15:10:15< zookeeper> well we've never discussed recursion... using the word recursion, anyway
20161023 15:10:56< zookeeper> since this is not going to go anywhere anytime soon, i'll go make some foodsy things instead ->
20161023 15:12:29-!- Bonobo [~Bonobo@2001:44b8:254:3200:e4b5:c14d:1fff:4741] has quit [Quit: Leaving]
20161023 15:14:33-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161023 15:16:43< tad_carlucci> zookeeper, To see the messages I'm referring to, fire up Liberty, ;cl glory ;throw turn 4 then rt click on the new leader and run through the AI controller "ally instructions" and watch stderr
20161023 15:20:50-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161023 15:21:04< gfgtdf> zookeeper: wherde is an engine bug ?
20161023 15:21:20-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 15:27:48< tad_carlucci> gfgtdf, It was fixed long ago. I was just cleaning up some residuals
20161023 15:28:30< gfgtdf> ok
20161023 15:30:23< vultraz> hm, I think I'll make these use a shared_ptr
20161023 15:31:42-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161023 15:32:08< vultraz> best to make sure the stuff in these two containers points to the same object
20161023 15:36:20< vultraz> er... hm.. wait, how does one do this..
20161023 15:42:44< vultraz> I think I designed this pretty badly
20161023 15:45:17< vultraz> ok
20161023 15:45:56< vultraz> I don't think I can make both the vector and map use a shared_ptr..
20161023 15:46:39< vultraz> Or could I?
20161023 15:47:16< vultraz> I suppose I could, but I think I'll just make the vector use it..
20161023 15:47:24< vultraz> keep the object storage in the container
20161023 15:47:55 * vultraz wonders where objects actually get stored when you use 'new' or make_shared/unique
20161023 15:48:56< vultraz> not really, related to this, but I'm just wondering... if you do something like T* foo = new obj(); foo is a pointer to an instance of obj, but where is obj actually?
20161023 15:49:52< JyrkiVesterinen> In that situation "obj" is in the heap. It's not specified where exactly it is stored.
20161023 15:50:20< vultraz> I see.
20161023 15:51:01-!- louis94 [~~louis94@91.178.241.241] has quit [Quit: Konversation terminated!]
20161023 15:51:24-!- louis94 [~~louis94@91.178.241.241] has joined #wesnoth-dev
20161023 15:53:07< vultraz> I assume a smart pointer stores the object in itself or something?
20161023 15:54:14< JyrkiVesterinen> No, smart pointers don't care where the object is stored.
20161023 15:54:23< vultraz> I see
20161023 15:54:49< JyrkiVesterinen> Make_shared() and make_unique() store the objects in the heap just like the "new" operator.
20161023 15:54:57< vultraz> I see
20161023 16:03:21-!- skeletenchi [enchilado@defocus/yummy/enchilado] has quit [Read error: Connection reset by peer]
20161023 16:12:24< tad_carlucci> vultraz, Think of a smart pointer as a pointer to an internal object which has a pointer and a reference count. When that count goes to zero the internal pointed object is deleted.
20161023 16:13:00< vultraz> isn't that a shared_ptr
20161023 16:13:10< tad_carlucci> oops
20161023 16:13:25< vultraz> pretty sure unique_ptr is different
20161023 16:13:45< tad_carlucci> very. faster less memory but there can be only one
20161023 16:16:59< vultraz> ok, so I'll make this a vector<unique_ptr<T>> then
20161023 16:17:11< vultraz> instead of storing two copies of the same thing
20161023 16:18:05< vultraz> also need to make some changes to the storage structure...
20161023 16:18:53< tad_carlucci> if you have two vectors of unique_ptr, an object can only be in one vector or the other.
20161023 16:20:21< vultraz> well, I'm going to make it vector<unique_ptr<T>> and map<T, map<F, B>>
20161023 16:20:35< vultraz> instead of just another vector<T> which means two copies
20161023 16:21:19< tad_carlucci> what are you trying to achieve?
20161023 16:22:30< vultraz> https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/multiplayer/mp_options_helper.hpp#L72-L73
20161023 16:22:40< tad_carlucci> seems to me the vector is redundant if you're using a map and the pair (F, B) is T
20161023 16:23:15< vultraz> options_data_ is the data for all options encountered, and visible_options_ is the visible, active ones.
20161023 16:23:26< vultraz> as you can see each keeps a copy of option_source
20161023 16:24:00< vultraz> simply because when i coded that (not too long ago), I thought a copy was needed for map lookup...
20161023 16:25:19< tad_carlucci> I'm trying to grok options_source vs options_map .. you're saying more than one source can share a map? Or more than one map can share a source?
20161023 16:25:45< vultraz> Former
20161023 16:26:15< vultraz> (I need to add documentation... :P )
20161023 16:26:22< vultraz> option_map is essentially widget.... value
20161023 16:26:40< vultraz> option_source is game/era/mod id and type
20161023 16:27:25< vultraz> so, say you select an era with mods. you get an option_source entry with the era's id, and the type set to "era", and then sub-map entries for all its options.
20161023 16:27:34-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has joined #wesnoth-dev
20161023 16:27:34-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has quit [Changing host]
20161023 16:27:34-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20161023 16:27:38< vultraz> but I realized I coded this rather backwards.
20161023 16:27:47< mordante> servus
20161023 16:28:11< vultraz> I initialize a new option_source object and push it to the visible_options vector
20161023 16:28:21< tad_carlucci> I think you'll need shared_ptr for both options_source on those lines.
20161023 16:28:46< vultraz> instead of first setting up in options_data_ and keeping a pointer in visible_options
20161023 16:28:48< vultraz> uh...
20161023 16:28:50< vultraz> why?
20161023 16:29:11< vultraz> mordante: hey. had any chance to look at that surface bug yet? :)
20161023 16:29:26< tad_carlucci> The visible list if it's unique_ptr when you remove from the list you're deleting the target which is still on the map
20161023 16:29:55< vultraz> true...
20161023 16:30:11< tad_carlucci> shared object keeps it alive until removed from both
20161023 16:30:24< tad_carlucci> shared_ptr
20161023 16:30:25< vultraz> what if it were just a regular pointer... I guess that would cause the same issue...
20161023 16:30:45< vultraz> hm...
20161023 16:30:54< vultraz> ok, so I guess first off, I need a ctor for the struct..
20161023 16:31:11< vultraz> make_shared doesn't work with aggregate initialization, it seems.
20161023 16:31:55< tad_carlucci> This all seems, at first blush, like a lot of work to handle a badly designed class heirarchy and you'd do better to step back and do some analysis, first.
20161023 16:31:56< vultraz> which seems odd, but oh well
20161023 16:32:11< mordante> vultraz, no not really
20161023 16:32:25< vultraz> tad_carlucci: perhaps you're right, yes..
20161023 16:32:49< vultraz> tad_carlucci: the only reason I used a sub-map was to avoid having to use find_if 
20161023 16:33:32< vultraz> however, I should perhaps reconsider the general design..
20161023 16:34:12-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161023 16:34:13< tad_carlucci> Not saying it's a wrong or bad design, but is feels like it. Could just be I don't understand all the why's and therefor's
20161023 16:34:26< vultraz> well right now it's certainly badly put together
20161023 16:34:31-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 16:34:32< mordante> just curious, but what's wrong with std::find_if ?
20161023 16:34:57< vultraz> mordante: nothing, it's just cleaner in this case to use map::operator[]
20161023 16:34:57-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161023 16:35:18-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 16:35:23 * vultraz ponders.
20161023 16:35:30< vultraz> I wonder if I even *need* visible_options_..
20161023 16:35:45-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161023 16:36:02< vultraz> it's essential use is a loop in get_options_config
20161023 16:36:11-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 16:36:33-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161023 16:36:45-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161023 16:36:55< vultraz> iterate over that, take each member, then iterate over each sub-map of options_data_[vec_item]....
20161023 16:36:56-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 16:37:04< vultraz> yeah, that seems rather inelegant now that you say it out loud :/
20161023 16:37:21-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161023 16:37:41< vultraz> *especially* since the current design keeps a *copy* of option_source in both containers
20161023 16:37:43-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 16:37:47< vultraz> what was I thinking >_>
20161023 16:38:05< mordante> ah ok
20161023 16:38:09-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161023 16:38:36-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 16:38:57-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161023 16:39:20-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 16:39:37< vultraz> visible_options_ should just be a vector of pointers
20161023 16:39:45-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161023 16:40:08< zookeeper> tad_carlucci, looks like the recursion check has basically always been there (since c6b6c20bd9c ), although i can't read the logic and figure out what it really does.
20161023 16:40:10-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 16:40:33-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Client Quit]
20161023 16:40:39< vultraz> it most certainly should not be used for tracking
20161023 16:41:15< vultraz> celticminstrel: is it correct that make_shared doesn't work with aggregate initialization?
20161023 16:41:31< celticminstrel> Like make_shared({...})?
20161023 16:41:42< vultraz> yes
20161023 16:41:52< celticminstrel> I don't know any reason why it wouldn't, but...
20161023 16:42:04< celticminstrel> Maybe there is one?
20161023 16:42:31< tad_carlucci> zookeeper, Took me some thinking to see it, too. Basically, it is keeping a list of the variables which have been inserted into this [insert_tag] and if one recurs, it throws(). If you remove that, the AI Controller _was_ creating an infinite loop. So, instead of throwing I eliminated the recursion
20161023 16:43:27-!- Kwandulin [~Miranda@p5DDD2B8F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161023 16:43:50< vultraz> I'll just add a ctor
20161023 16:43:58< zookeeper> tad_carlucci, ah, i see
20161023 16:45:00< tad_carlucci> zookeeper, Part of the reason I wanted you to look at these was vultraz merged so quickly and I'd have preferred making sure you were copasetic with the work beforehand.
20161023 16:45:04< celticminstrel> Oh, aggregate initialization of a struct, huh...
20161023 16:45:18< vultraz> yes
20161023 16:45:32< zookeeper> (that's a word..? looks like it is)
20161023 16:45:47< celticminstrel> Well, it uses variabid templates to select a constructor. Aggregate initialization of a struct isn't a constructor, I guess.
20161023 16:45:52< celticminstrel> ^variadix
20161023 16:45:54< celticminstrel> ^variadc
20161023 16:45:57< celticminstrel> ^variadic
20161023 16:46:01 * celticminstrel sigh
20161023 16:46:08 * tad_carlucci emulates his Beatnick father .oO ( Copasetic, man, copasetic! )
20161023 16:46:26 * tad_carlucci snaps his fingers.
20161023 16:46:45< vultraz> hm
20161023 16:46:46< vultraz> http://stackoverflow.com/questions/35298989/using-c-aggregate-initialization-in-stdmake-shared
20161023 16:46:50< vultraz> both of these are ugly :|
20161023 16:47:32< zookeeper> tad_carlucci, ok, yes i'm... copasetic with it :p
20161023 16:47:52 * tad_carlucci chuckles.
20161023 16:48:18< tad_carlucci> ok. gtg. bbl
20161023 16:48:21-!- 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.]
20161023 16:49:39< vultraz> hmmmm
20161023 16:50:04< vultraz> ok, i just realized something here..
20161023 16:50:37< vultraz> in the class ctor, I insert saved pref data into options_data_...
20161023 16:50:56< vultraz> then when I update options, I want to work on that same thing rather than the visible_options vector..
20161023 16:50:58< vultraz> but..
20161023 16:50:59< celticminstrel> JyrkiVesterinen: Do you think we can delete intf_random from mapgen_lua_kernel.cpp now?
20161023 16:51:31< JyrkiVesterinen> I looked at it. The problem is that mapgen_lua_kernel allows the random number seed to be set.
20161023 16:51:37< vultraz> how does one check if a shared_ptr of an object exists in the map!
20161023 16:51:41< celticminstrel> I see...
20161023 16:51:54 * vultraz groans
20161023 16:52:06-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 16:52:06< vultraz> this, actually, is probably why it's best to use the vector...
20161023 16:52:18< vultraz> wait, no
20161023 16:52:21< celticminstrel> Okay then, that does kinda make sense.
20161023 16:52:27< vultraz> I'd need ANOTHER vector!
20161023 16:52:39< celticminstrel> A vector of vectors of vectors!
20161023 16:52:57< JyrkiVesterinen> IMO, it doesn't make sense that mapgen_lua_kernel overrides wesnoth.random() with a slightly different implementation. I'd expect a function of the same name to do the same thing.
20161023 16:53:03< celticminstrel> (Sorry, I don't actually know what you're talking about, vultraz.)
20161023 16:53:31< vultraz> celticminstrel: how would one say "create a new object and add a shared_ptr of it to a map only if any of the pointers already in the map do not point to an object with the same id and level_type keys?" :)
20161023 16:53:32< JyrkiVesterinen> I have thought that maybe it should provide a different API, for example wesnoth.create_deterministic_rng().
20161023 16:53:46< gfgtdf> vulyou: dont know why what you are currently talikng about, but it soudn liek your might want to use boost::multi_index
20161023 16:54:00< vultraz> *gasp* 
20161023 16:54:08< JyrkiVesterinen> That function could return a table that offers a function to generate a random number.
20161023 16:54:32< gfgtdf> JyrkiVesterinen: hmm wha woudl one want that ?
20161023 16:54:54< JyrkiVesterinen> Assuming that you meant "why": principle of least surprise.
20161023 16:55:12< vultraz> perhaps..
20161023 16:55:15< vultraz> perhaps...
20161023 16:55:22< vultraz> but isn't multi_index very complicated :|
20161023 16:55:22< gfgtdf> also there is a the 'Rgn' table added by iceiceice.
20161023 16:55:26< vultraz> do we have any code examples?
20161023 16:55:35< celticminstrel> Wait, that table does exist?
20161023 16:55:47< JyrkiVesterinen> The documentation in wiki.wesnoth.org says that wesnoth.random() is a synchronized RNG (e.g. it returns the same values for all players in multiplayer).
20161023 16:55:49< celticminstrel> I assumed it had been replaced when wesnoth.random was made available.
20161023 16:55:59< gfgtdf> 'Rng' see https://wiki.wesnoth.org/MapGeneratorWML but it might also be avialble outside the mapgen lua kernel
20161023 16:56:20< JyrkiVesterinen> That documentation doesn't say anything about the seed.
20161023 16:56:21< gfgtdf> celticminstrel: not sure, i sw no reason to assume that
20161023 16:56:34< vultraz> oh...kay multi_index is a monster :|
20161023 16:56:41 * vultraz heads to bed
20161023 16:56:47 * vultraz will evaluate tomorrow
20161023 16:56:48< JyrkiVesterinen> Hence, it would be logical for someone writing a map generator in Lua to assume that wesnoth.random() does *not* have a configurable seed.
20161023 16:57:22< gfgtdf> JyrkiVesterinen: that wiki mostlikeley oynl applies to the ingame wesnoth.random function.
20161023 16:57:51< JyrkiVesterinen> Correct, but a developer has no reason to expect that the function is different in map generator Lua.
20161023 16:58:13< gfgtdf> JyrkiVesterinen: wesnoth.random is tries to be 'smart'  meaing it returns 'synced' results in syncted evnewrt,s unsynced resutl in unsynced events, and seeded numbers in the when generating a map.
20161023 16:58:20< JyrkiVesterinen> I didn't even *know* that there is a separate map generator Lua kernel before you pointed it out.
20161023 17:00:20< gfgtdf> JyrkiVesterinen: i think having the same syntex to get rnadom numbers in the mapgen and in normal game, realyl does make wiritng addons easier.
20161023 17:00:51< JyrkiVesterinen> I think it makes it *harder*. Familiar syntax but slightly different semantics.
20161023 17:01:14< gfgtdf> JyrkiVesterinen: the sameanticas are the same: jsut use wensothrandom if you need a randm number
20161023 17:02:23< JyrkiVesterinen> More accurately: if you need a seedable random number, use the Rng table. Except if you're writing a map generator, in which case you can use wesnoth.random().
20161023 17:02:33< gfgtdf> JyrkiVesterinen: usually the mapgen code lua code doesnt need to know that it the mapgen ui in the editor has a 'seed' option, just like a lot of wml developery dont know the internals of mp sync.
20161023 17:03:02< gfgtdf> JyrkiVesterinen: you cannt 'seed' wesnoth.rnadom from inside the lua code
20161023 17:03:15< JyrkiVesterinen> The mere fact that there is a difference between ingame scripts and map generators can cause confusion.
20161023 17:03:55< JyrkiVesterinen> That wesnoth.random() can't be re-seeded from Lua doesn't really change my point.
20161023 17:04:12< gfgtdf> JyrkiVesterinen: it does since its not a 'seedable rng' form the lua point of view
20161023 17:05:14< JyrkiVesterinen> I disagree. In map generator code I can imagine situations where the number doesn't need to depend on the seed, and situations where it needs to depend on it. There is a difference.
20161023 17:05:39< JyrkiVesterinen> (For the former kind, an example is if the generator code needs to check something with Monte Carlo simulation.)
20161023 17:05:54< JyrkiVesterinen> (Propably not a practical example, but not completely unimaginable.)
20161023 17:06:10< gfgtdf> JyrkiVesterinen: why couldn't you want to use the wesnoth.random there ?
20161023 17:06:28< gfgtdf> JyrkiVesterinen: wouldn't
20161023 17:07:00< JyrkiVesterinen> Indeed, you can still use wesnoth.random() for numbers which don't need to depend on the seed... as long as the number of calculations themselves is fixed.
20161023 17:08:01< gfgtdf> JyrkiVesterinen: acualyl evne with mote caros simulation it can happen that the it retuns differtn tresults with when you sue math.random whcih coudl result in diffetn maps at the end.
20161023 17:11:38< JyrkiVesterinen> OK, I give up. We can indeed override wesnoth.random() in the map generator Lua kernel.
20161023 17:11:59-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161023 17:12:01< gfgtdf> vultraz: yes boost:::multi_index is a monster, we currently use in the wesnothd inplemenation and somehere in the whiteboard code, 
20161023 17:12:10< JyrkiVesterinen> I'll change the documentation to mention this, and ensure that wesnoth.random() uses the map generator Lua kernel version.
20161023 17:12:46< gfgtdf> vultraz: the point is that its aslo quite bug-prone to tave multiple vectors/mps and to make sure that tehy stay in a vaid state
20161023 17:12:58< gfgtdf> vultraz: for exampel when implemeting somthing liek bidiectional map
20161023 17:13:02< gfgtdf> vultraz: ok thx
20161023 17:13:17< gfgtdf> vultraz: not sure about your usecase.
20161023 17:14:10< gfgtdf> JyrkiVesterinen: ok thx
20161023 17:19:51< irker032> wesnoth: Jyrki Vesterinen wesnoth:master 525345502179 / src/scripting/mapgen_lua_kernel.cpp: Ensure that mapgen Lua kernel overrides wesnoth.random() https://github.com/wesnoth/wesnoth/commit/52534550217947982249c3bf4dc42603266da658
20161023 17:50:04-!- TC02 [~quassel@venus.arosser.com] has quit [Remote host closed the connection]
20161023 17:52:11-!- TC02 [~quassel@venus.arosser.com] has joined #wesnoth-dev
20161023 18:00:48-!- louis94 [~~louis94@91.178.241.241] has quit [Ping timeout: 260 seconds]
20161023 18:07:04 * vultraz returns
20161023 18:07:58< vultraz> celticminstrel: does emplace use the same method for is-value-present checking as find?
20161023 18:08:01< vultraz> ie, operator<?
20161023 18:08:06< celticminstrel> That probably wasn't necessary, but I guess it doesn't hurt.
20161023 18:08:28< celticminstrel> vultraz: Comparison has nothing to do with emplace or find specifically.
20161023 18:08:38< celticminstrel> I mean, they're both defined in unordered maps too.
20161023 18:08:59< celticminstrel> But yes, when you emplace in a map, it inserts it into its position as determined by operator<3
20161023 18:09:02< celticminstrel> ...
20161023 18:09:06< celticminstrel> ...
20161023 18:09:07< celticminstrel> ...
20161023 18:09:14< vultraz> xD
20161023 18:09:18< celticminstrel> ...that's the worst place for an accidental 3.
20161023 18:09:53< celticminstrel> By the way, map::emplace and map::insert are the same operation.
20161023 18:10:45< vultraz> i was just wondering if one did map.emplace({foo, bar}) it would correctly not add if one already did map[{foo, bar}] earlier
20161023 18:11:11< celticminstrel> Uh, there is no situation in which both of those are valid.
20161023 18:11:27< celticminstrel> Did you mean map[foo]=bar?
20161023 18:11:41< vultraz> er, assume both have a value of bat
20161023 18:12:01< celticminstrel> So you meant map.emplace({foo,bar}, bat)?
20161023 18:12:17< vultraz> yes, let's say that for this example
20161023 18:12:32< celticminstrel> The map's operator[] should be just a wrapper around insert.
20161023 18:12:59< celticminstrel> And insert and emplace are the same thing, so emplacing wouldn't replace something added with operator[].
20161023 18:13:19< vultraz> ok, ok
20161023 18:13:24< vultraz> good... I guess..
20161023 18:14:03< vultraz> I'm pondering just dropping visible_options_ and added a visible flag to option_source...
20161023 18:15:16< vultraz> so as long as emplace wouldn't replace anything..
20161023 18:15:32< vultraz> could work..
20161023 18:16:13< celticminstrel> I'm sure we've been over this before, but insert returns an iterator to the element with that key.
20161023 18:16:31< celticminstrel> Plus true/false depending on whether that element is new or was already present (in the latter case the value could be different).
20161023 18:16:58< celticminstrel> So it never replaces anything.
20161023 18:17:08< celticminstrel> And again, emplace is exactly the same as insert.
20161023 18:17:09< vultraz> ahh yes
20161023 18:17:13< vultraz> I remember this
20161023 18:17:59< vultraz> so one could perfectly do auto iter = map.end(); bool success = false; std::tie(iter, success) = map.emplace(... stuff ...);
20161023 18:20:21 * vultraz back to bed
20161023 18:27:49-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161023 18:32:28-!- louis94 [~~louis94@91.178.241.241] has joined #wesnoth-dev
20161023 18:38:26-!- louis94 [~~louis94@91.178.241.241] has quit [Ping timeout: 250 seconds]
20161023 18:46:33-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161023 18:49:34< tad_carlucci> gfgtdf, Confirming repo for https://gna.org/bugs/index.php?25186 added the following to HttT S01 and fired by hand .. pastebin.com/Jrd1Crgn .. OK button does seem to behave odd and after 30 or so times on the test option the game hung and could not be closed using "X"
20161023 18:50:18-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Client Quit]
20161023 19:01:47< gfgtdf> tad_carlucci: hmm yes i think the simplest way to figues out what happens migth be to run this test with a profler attached.
20161023 19:03:39< gfgtdf> wedge009: wedge maybe you codul try to test https://gna.org/bugs/index.php?25186 with a profiler ? (i think msvc15 has profler buildin)
20161023 19:10:15-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20161023 19:10:30-!- boucman [~rosen@2a02-8428-034f-f800-5d40-08cf-1fd4-2c8d.rev.sfr.net] has joined #wesnoth-dev
20161023 19:10:41-!- boucman [~rosen@2a02-8428-034f-f800-5d40-08cf-1fd4-2c8d.rev.sfr.net] has quit [Changing host]
20161023 19:10:41-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161023 19:14:30-!- Neoriceisgood [5658167a@gateway/web/freenode/ip.86.88.22.122] has joined #wesnoth-dev
20161023 19:14:34< Neoriceisgood> Heyy
20161023 19:16:57< gfgtdf> Neoriceisgood: hi
20161023 19:17:10-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161023 19:19:39< Neoriceisgood> What's up, girlfriend got dadfingers?
20161023 19:21:12< pydsigner> Is that what that stands for? Heh
20161023 19:30:00< gfgtdf> pydsigner: no its just random buttonmashes.
20161023 19:30:24-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Ping timeout: 260 seconds]
20161023 19:33:06-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161023 19:48:02< Neoriceisgood> But it -could- stand for that~
20161023 20:04:21-!- JyrkiVesterinen [~JyrkiVest@87-100-144-97.bb.dnainternet.fi] has quit [Quit: .]
20161023 20:05:06< zookeeper> Neoriceisgood, so are you looking for suggestions on what to work on?
20161023 20:09:42< Neoriceisgood> I think my ideas are much better when I just shoot in the dark
20161023 20:09:43< Neoriceisgood> https://snag.gy/g03oak.jpg
20161023 20:09:45< Neoriceisgood> for example
20161023 20:09:53< Neoriceisgood> look at my latest creation: Extremely extremely buff troll
20161023 20:11:29< zookeeper> as you wish
20161023 20:20:17-!- irker032 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161023 20:24:59< Neoriceisgood> (unless someone's looking for really fun monsters)
20161023 20:31:00< pydsigner> Troll Boxer
20161023 20:31:14< Neoriceisgood> serious request?
20161023 20:31:24< pydsigner> No taht's what that troll is
20161023 20:31:41< pydsigner> * that's
20161023 20:31:47< pydsigner> In your snaggy
20161023 20:32:39< Neoriceisgood> ohh
20161023 20:33:06< Neoriceisgood> https://snag.gy/8Efgud.jpg
20161023 20:33:14< Neoriceisgood> I was thinking you needed something like this
20161023 20:34:46< pydsigner> Yeah no lol heh
20161023 20:35:21-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20161023 20:36:13-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161023 21:00:15-!- mjs-de [~mjs-de@x4db5056f.dyn.telefonica.de] has quit [Remote host closed the connection]
20161023 21:15:33-!- louis94 [~~louis94@91.178.241.241] has joined #wesnoth-dev
20161023 21:24:21-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161023 21:33:30-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 250 seconds]
20161023 21:37:36-!- Neoriceisgood [5658167a@gateway/web/freenode/ip.86.88.22.122] has quit [Quit: Page closed]
20161023 21:41:16-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20161023 21:52: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.]
20161023 21:53:55-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161023 22:05:32-!- karthago [~edgrey@178.205.86.117] has quit [Ping timeout: 256 seconds]
20161023 22:41:00-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161023 22:45:14-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161023 23:05:13-!- Shiki [~Shiki@141.39.226.226] has quit [Remote host closed the connection]
20161023 23:13:05-!- louis94 [~~louis94@91.178.241.241] has quit [Ping timeout: 256 seconds]
20161023 23:29:22-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161023 23:29:54-!- ancestral [~ancestral@75-168-80-79.mpls.qwest.net] has joined #wesnoth-dev
20161023 23:56:19-!- bumba [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161023 23:57:33-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 245 seconds]
--- Log closed Mon Oct 24 00:00:19 2016