--- Log opened Sat Aug 27 00:00:49 2016
20160827 00:01:00< celmin> Ugh, it looks impossible to be const-correct here...
20160827 00:02:08 * celmin even has to break out the const_cast...
20160827 00:13:27-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160827 00:17:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20160827 00:17:27-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160827 00:25:46-!- RatArmy [~RatArmy@133.15.175.65] has joined #wesnoth-dev
20160827 00:26:13-!- Appleman1234 [~Appleman1@KD036012022172.au-net.ne.jp] has joined #wesnoth-dev
20160827 00:33:45-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Ping timeout: 258 seconds]
20160827 00:34:39-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Ping timeout: 264 seconds]
20160827 00:38:28-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160827 00:39:58-!- RatArmy [~RatArmy@133.15.175.65] has quit [Quit: Konversation terminated!]
20160827 00:42:10-!- oldlaptop [~quassel@162.247.150.37] has quit [Ping timeout: 250 seconds]
20160827 00:42:40-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160827 00:45:14-!- hay207_ [~hay207@41.34.62.239] has joined #wesnoth-dev
20160827 00:45:51< tad_> celticminstrel: You on?
20160827 00:45:56-!- oldlaptop [~quassel@162.247.150.37] has joined #wesnoth-dev
20160827 00:47:51-!- hay207 [~hay207@41.34.3.180] has quit [Ping timeout: 276 seconds]
20160827 00:48:42-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160827 00:49:08< celmin> tad_: Yes, I'm here.
20160827 00:49:29< tad_> celmin: Any ideas on that crash from earlier today? 
20160827 00:50:00< celmin> I can't seem to remember what it was.
20160827 00:50:07< tad_> My system locked up, and my wife dragged me away. So I missed a bit. In the interim I bisected and have the bad commit #
20160827 00:50:13< celmin> Somehow I can only remember fabi's crash from yesterday.
20160827 00:50:20< celmin> Which may or may not be related, I dunno.
20160827 00:50:39< celmin> (It's after dismissing objectives in the test scenario. Possibly in any scenario with custom unit statuses.)
20160827 00:50:56< celmin> So which is the commit, then?
20160827 00:50:59< tad_> I cleared ~/.cache, ~/.config and ~/.local/share/wesnoth for all 1.13 files and the engine dies on starting a new game.
20160827 00:51:35< tad_> Backtrace indicated it was in Lua C++ support code attempting to load the starting positions.
20160827 00:51:55< celmin> Oh, I remember now.
20160827 00:52:02< tad_> 9dbae3944839f2e55086f0e7c221ef7083c6be06 is the first bad commit commit 9dbae3944839f2e55086f0e7c221ef7083c6be06 Author: Celtic Minstrel <celtic.minstrel.ca@some.place> Date:   Wed Aug 24 18:45:40 2016 -0400      Minor code cleanup regarding special map locations
20160827 00:52:13< celmin> So it was that commit after all, huh.
20160827 00:52:44< tad_> I am testing a revert on it now. Dunno why it didn't expose the issue earlier. Perhaps I didn't revert properly.
20160827 00:53:59< tad_> I did notice during testing for bisect that if I started a game on a 'bisect good' commit then it did NOT cause the failure. I had to hand-clear the files for each bisect test to be sure it failed.
20160827 00:54:32< celmin> What scenario does it occur in?
20160827 00:54:40< tad_> Any.
20160827 00:55:10< celmin> I'm not getting such a crash though… either I've already fixed it locally, or it's system-dependent...
20160827 00:55:16< celmin> More likely the latter.
20160827 00:55:20< tad_> Clear files. Start engine. No loads at all and default config. Attempt to start any mainline campaign. Crashes with segfault after map during prestart
20160827 00:55:38< celmin> So it doesn't happen if there's cache sitting around?
20160827 00:55:44< tad_> Yep.
20160827 00:56:03< celmin> I'll try clearing my cache then, once I've finished with the current commit I'm working on.
20160827 00:56:23< tad_> And I cleared cache (et al) because I wanted to get to a known-clean state for a bug/question for vultraz about the leaders on Load panel he added
20160827 00:56:58< tad_> Might want to wait for my build to finish. My luck it won't repeat even though bisect says it will :P
20160827 00:57:02< celmin> I've been getting a lot of corrupt cache warnings recently, actually...
20160827 00:58:01< tad_> I'm also getting a lot of errors about sound underruns. But that's probably my VM sound isn't set up. I disable all sounds in Preferences and it goes away.
20160827 00:59:10< celmin> Hmm, I wonder if ipairs is smart enough to call the __len metamethod if no __ipairs metamethod is defined...
20160827 01:13:57< tad_> How did this ever compile? -	push_locations_talbe(L);  +	push_locations_table(L);
20160827 01:14:37< celmin> I changed the name and the sole reference in the same commit.
20160827 01:14:57< celmin> gfgtdf seems to not bother checking his spelling.
20160827 01:15:27< tad_> Ah. OK.
20160827 01:15:45< celmin> Wah, so close. All my tests worked until I tried to set the damage of a unit's attack.
20160827 01:16:41< tad_> Looks to me like what you're doing is pushing the map location (x,y) directly instead of using a temp table, and eliminating that temp struct. I don't know the code well but it makes a certain amount of send looking at just the commit
20160827 01:16:51< tad_> send --> sense
20160827 01:17:22< celmin> You mean the coordinate struct, right?
20160827 01:17:52< tad_> yea. At the todo comment. Mainly you were just trying to do the todo?
20160827 01:18:13< celmin> That, and I wanted to call luaW_pushlocation with it, which requires a map_location.
20160827 01:19:12< tad_> It's that reference to map_location which caused me to look here to begin with. It's so close to the backtrace .. not exact but it seemed clsoe enough
20160827 01:19:56< celmin> What reference?
20160827 01:20:19< tad_> About starting locations, in the trace between prestart and the crash
20160827 01:21:12< tad_> And map_locations in this patch
20160827 01:21:43< celmin> The commit definitely does touch something related to starting locations.
20160827 01:24:21< tad_> Build finished. Cleared the files. Tested. upstream/master fails. revert your commit and it runs. So bisect was right, that's the culprit
20160827 01:52:12-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160827 02:00:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160827 02:05:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 255 seconds]
20160827 03:06:45< celmin> Okay, so I don't understand why this value is not changing. I clearly see it getting assigned, but when I next look, it's back to what it was.
20160827 03:07:51< celmin> If I inspect in the debugger just after it's changed, the change is shown.
20160827 03:08:14< celmin> Its address there is the same as the address when it's first looked up in the unit's attack list.
20160827 03:19:49< celmin> Suddenly std::bad_cast. o.o
20160827 03:30:48< celmin> I feel like it must be getting copied somewhere somehow, but that seems impossible...
20160827 03:38:45< celmin> XCode's insistence on crashing whenever I try to peek into the unit makes this very hard to debug.
20160827 03:39:03< celmin> I'm not sure if it's a sign that the unit is invalid or just some weird bug in the debugger.
20160827 03:41:51< celmin> Wonder if I could get anywhere with gdb instead of lldb...
20160827 03:53:00-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160827 03:57:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160827 04:03:53< celmin> Well, it doesn't crash, which is a plus, but it doesn't really help either.
20160827 04:18:14-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160827 04:19:21< celmin> :|
20160827 04:19:58< celmin> I dunno, should I commit this for now and hope someone else can figure it out soon…?
20160827 04:32:23-!- Bonobo [~Bonobo@2001:44b8:254:3200:68a2:ff0d:2746:2f3e] has joined #wesnoth-dev
20160827 04:59:44-!- Kwandulin [~Miranda@p200300760F6F2FEC9DB0E566DCC9E1C1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160827 05:13:46-!- Kwandulin_2 [~Miranda@p200300760F6F2FEC9DB0E566DCC9E1C1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160827 05:13:58-!- Kwandulin [~Miranda@p200300760F6F2FEC9DB0E566DCC9E1C1.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20160827 05:21:17< celmin> Well, somehow I managed to track down the issue. \o/
20160827 05:26:46-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160827 05:28:14< celmin> Solving it, however, is harder...
20160827 05:32:45< celmin> I feel like static_casting a temporary to a const reference could be dangerous...
20160827 05:38:40< celmin> Though I guess that's just explicitly doing something the compiler normally does implicitly...
20160827 05:42:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160827 05:47:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160827 05:47:10-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160827 05:47:11-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160827 06:06:52< celmin> Well, it doesn't work. Fixes unit attacks but breaks unit type attacks.
20160827 06:09:35< vultraz> celmin: what is the problem?
20160827 06:09:54< celmin> unit_type::attacks() returns std::vector<attack_type>
20160827 06:10:07< celmin> unit::attacks() returns const std::vector<attack_type>&
20160827 06:10:18< celmin> I had u ? u->attacks() : ut->attacks()
20160827 06:10:34< celmin> Since the right operand is not a reference, this causes the middle operand to be copied.
20160827 06:10:53< celmin> I'm going to move the unit adapter from AI into the units/ folder and use that.
20160827 06:11:09< vultraz> why not just change the types?
20160827 06:11:59< celmin> The reason unit_type returns by value is that it stores its data in a config, so it needs to transfer it to the vector.
20160827 06:12:32< celmin> I could of course make it store a std::vector as well, but...
20160827 06:38:55< celmin> I really should sleep… :/
20160827 06:39:07< celmin> But I wanted to at least finish this and check out tad's bug first.
20160827 06:43:58-!- Bonobo [~Bonobo@2001:44b8:254:3200:68a2:ff0d:2746:2f3e] has quit [Ping timeout: 255 seconds]
20160827 06:44:45-!- Bonobo [~Bonobo@2001:44b8:254:3200:d0f4:e548:a043:70cb] has joined #wesnoth-dev
20160827 06:55:04-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160827 06:55:04-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160827 06:56:32< celmin> Guess I'll put off the bugs until tomorrow.
20160827 06:56:42< celmin> That one, mattsc's one, and maybe fabi's one.
20160827 06:56:53< celmin> Well, I guess mattsc's one is also tad's really.
20160827 06:57:12-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160827 06:57:38< vultraz> celticminstrel: could these be combined as so? http://pastebin.com/igdbHSeX
20160827 06:58:19< vultraz> (top simplified, bottom expanded)
20160827 07:02:46< vultraz> (I dunno if the static casts are necessary - relation is an enum value)
20160827 07:05:13< celticminstrel> Why can't I view that without a browser...
20160827 07:05:24 * celticminstrel using the raw link.
20160827 07:09:18< celticminstrel> The fonts really are too big.
20160827 07:14:39-!- Greywhin1 [~Greywhind@c-71-232-29-126.hsd1.ma.comcast.net] has joined #wesnoth-dev
20160827 07:16:52-!- Greywhind [~Greywhind@c-71-232-29-126.hsd1.ma.comcast.net] has quit [Ping timeout: 240 seconds]
20160827 07:16:53-!- Jetrel_bot [~Jetrel@ec2.happyspork.com] has quit [Ping timeout: 240 seconds]
20160827 07:18:18-!- Jetrel_bot [~Jetrel@ec2.happyspork.com] has joined #wesnoth-dev
20160827 07:21:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160827 07:22:49-!- celticminstrel is now known as celmin|sleep
20160827 07:26:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20160827 07:27:35-!- Kwandulin [~Miranda@p200300760F6F2F475D451EB614E12EB2.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160827 07:30:19-!- Kwandulin_2 [~Miranda@p200300760F6F2FEC9DB0E566DCC9E1C1.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20160827 07:40:24-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160827 07:41:15-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160827 07:50:59-!- Kwandulin [~Miranda@p200300760F6F2F475D451EB614E12EB2.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160827 07:51:51-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160827 08:08:29-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160827 08:15:35-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160827 08:17:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160827 08:20:29-!- Kwandulin [~Miranda@p200300760F6F2F4740270D89011DCC5D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160827 08:25:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160827 08:30:56-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160827 08:48:10-!- Bonobo [~Bonobo@2001:44b8:254:3200:d0f4:e548:a043:70cb] has quit [Ping timeout: 255 seconds]
20160827 09:17:52-!- atarocch [~atarocch@93.56.160.28] has quit [Ping timeout: 252 seconds]
20160827 09:28:11-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160827 09:31:45-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 276 seconds]
20160827 09:31:45-!- wedge010 is now known as wedge009
20160827 09:32:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160827 09:34:03-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160827 09:37:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160827 10:23:24< vultraz> what... exactly is this supposed to do...
20160827 10:23:27< vultraz> DBG_LB << "lobby info: closing room " << name << " " << static_cast<void*>(r) << "\n";
20160827 10:30:46< zookeeper> print output regarding closing of a room..?
20160827 10:31:16< zookeeper> but if you just meant that cast, then naturally i have no idea :p
20160827 10:34:30< vultraz> yes, the cast
20160827 10:48:06< nore> vultraz: for me, it looks like this would print the pointer to the room
20160827 10:48:35< nore> Ad to why you would do that, I have no idea
20160827 10:49:00< vultraz> like 0xLeNumbersHere?
20160827 10:49:03-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160827 10:49:09< nore> s/Ad/As/
20160827 10:49:49< nore> I guess so
20160827 11:36:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160827 11:40:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20160827 11:47:28-!- oldlaptop [~quassel@162.247.150.37] has quit [Ping timeout: 252 seconds]
20160827 11:49:47-!- gfgtdf [~chatzilla@x4e363e27.dyn.telefonica.de] has joined #wesnoth-dev
20160827 11:49:54< gfgtdf> 20160819 11:42:24< zookeeper> gfgtdf, so, in 1.12 if you have a last breath event which declares defeat, the following die event won't trigger. in 1.13.5, it does. this is probably due to the [endlevel]-related changes, but i don't really recall the specifics of what all changed and why.
20160827 11:50:25< gfgtdf> zookeeper: i'm actuall qute surprisd about this 1.12 behaviour, but i dont know whta changed it
20160827 11:50:43< gfgtdf> zookeeper: are your sure that behaves liek that on 1.12 ?
20160827 11:54:14< gfgtdf> 20160822 07:06:17< celticminstrel> But are you sure it's unsupported to have an era with id=xyz and also a modification with id=xyz?
20160827 11:54:53< gfgtdf> celmin|sleep: the code the loads the options into the scenario expected both the typename, and the scenario/mod/.. id, thats wha i used array/pair keys there
20160827 11:55:26< gfgtdf> celmin|sleep: we can change thiswhen we drop the gui1 lobby.
20160827 11:57:57< gfgtdf> 20160827 10:23:27< vultraz> DBG_LB << "lobby info: closing room " << name << " " << static_cast<void*>(r) << "\n";
20160827 11:58:40< gfgtdf> vultraz: well it prints the memeorty adrss of the room object which usuall uniqueley indentifies it during its liftile
20160827 12:00:45-!- gfgtdf [~chatzilla@x4e363e27.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0/20160726073904]]
20160827 12:48:42-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Ping timeout: 276 seconds]
20160827 13:22:39-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160827 13:25:47-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160827 13:30:08< zookeeper> gfgtdf, yeah pretty sure, i tested the TRoW scenario on 1.12 too and there it works right.
20160827 13:59:29-!- Kwandulin [~Miranda@p200300760F6F2F4740270D89011DCC5D.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160827 14:00:51-!- gfgtdf [~chatzilla@x4e363e27.dyn.telefonica.de] has joined #wesnoth-dev
20160827 14:04:27< vultraz> ah, hey there gfgtdf 
20160827 14:04:29< gfgtdf> zookeeper: well, in 1.12 and in 1.13 [endlevel] afaik just sets a variable https://github.com/wesnoth/wesnoth/blob/1.12/src/game_events/action_wml.cpp#L765 (force_end_level sets a it) that it then checked in after the current action is executed in 1.12 here https://github.com/wesnoth/wesnoth/blob/1.12/src/playsingle_controller.cpp#L813 . 'after the current action is executed' should imply...
20160827 14:04:31< gfgtdf> ...'after the die event has fired' so i cant se how it could effect whether the die event is triggered in 1.12
20160827 14:04:55< gfgtdf> vultraz: hi
20160827 14:05:15< zookeeper> gfgtdf, maybe it's triggered but fast-forwarded just like when you press esc? just a guess.
20160827 14:09:17-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 244 seconds]
20160827 14:09:51< vultraz> gfgtdf: should the fix you made to tlistbox::set_row_shown (this: https://github.com/wesnoth/wesnoth/blob/master/src/gui/widgets/listbox.cpp#L202) also be added to the other overload?
20160827 14:10:00< vultraz> also im considering if we need those invalidate_layout calls
20160827 14:10:45-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160827 14:11:15< gfgtdf> vultraz: i think it makes esne to add it to the other overoad aswell
20160827 14:14:27< vultraz> okw ill do
20160827 14:16:19< mattsc> zookeeper: while I am updating the high XP attacks, you could check out the assassin AI for HttT:S8  ;)
20160827 14:19:21< zookeeper> mattsc, hmm, yes, i suppose i could try it out right now
20160827 14:19:59< zookeeper> mattsc, i'll just need to copy the [ai] block from the demo scenario and the corresponding lua file, right?
20160827 14:20:39< mattsc> zookeeper: well, I’d test it in the demo scenario first, but other than that, yes
20160827 14:21:18< zookeeper> okay
20160827 14:23:28< mattsc> that scenario is set up to be similar to that in HttT, specifically for that purpose.
20160827 14:28:37< zookeeper> ok, seems to be working
20160827 14:29:07< celmin|sleep> Yawn.
20160827 14:29:58-!- celmin|sleep is now known as celticminstrel
20160827 14:30:18< mattsc> good morning
20160827 14:30:30< celticminstrel> It actually is morning, too.
20160827 14:30:42< mattsc> I know.  It’s even morninger here.
20160827 14:30:45< celticminstrel> And I even had breakfast, which is rare.
20160827 14:31:20< mattsc> celticminstrel: which of my bugs were you going to look into?
20160827 14:31:26< zookeeper> why do all menus have massive horizontal spacing between the elements now...
20160827 14:31:39< zookeeper> s/horizontal/vertical
20160827 14:33:03< celticminstrel> The TSG2 aspect error.
20160827 14:33:22< mattsc> Ah, okay.
20160827 14:33:32< mattsc> 20160827 14:28:37< zookeeper> ok, seems to be working <— is that about the AI?
20160827 14:33:39< zookeeper> yes
20160827 14:33:52< mattsc> cool; does it do what you imagined it should do?
20160827 14:35:09< zookeeper> yeah
20160827 14:35:28< zookeeper> although in this particular case it might be almost inevitable that they end up going swimming
20160827 14:36:01< mattsc> Hmm.  In my case they were circling around the north.
20160827 14:36:37< mattsc> I guess this could be influenced by their starting positions, or by the map design, of course.
20160827 14:36:59< mattsc> Another question I am having is whether it is worth turning this into a Micro AI.
20160827 14:37:08< zookeeper> sure, as said the map probably needs to be at least widened a bit to accommodate the assassins
20160827 14:37:18< mattsc> yeah
20160827 14:37:25< celticminstrel> I suddenly wonder whether SUF can filter on traits.
20160827 14:37:37-!- oldlaptop [~quassel@162.247.150.37] has joined #wesnoth-dev
20160827 14:38:04< zookeeper> celticminstrel, of course it can, it can filter on anything
20160827 14:38:18< vultraz> ah, celticminstrel returns
20160827 14:38:23< celticminstrel> You mean [filter_wml]?
20160827 14:38:30< zookeeper> yes
20160827 14:38:37< vultraz> zookeeper: i added more vertical spacing
20160827 14:38:42< celticminstrel> Hmm, how would that work...
20160827 14:38:43< vultraz> vertical spacing is gud
20160827 14:39:02< zookeeper> celticminstrel, [filter_wml] [modifications] [trait] id=strong ?
20160827 14:39:07< celticminstrel> Would [filter_wml][modifications][trait]id=whatever be enought though?
20160827 14:39:11< celticminstrel> ^enough
20160827 14:39:23< celticminstrel> I forget exactly how WML filters work actually...
20160827 14:39:32< zookeeper> mattsc, the assassins seem to be doing their job quite right
20160827 14:40:37< mattsc> zookeeper: yay!
20160827 14:41:01< zookeeper> i'm too much of an AI newbie to say whether it should be a micro AI or not. i guess it's kind of basic behavioral archetype, so maybe?
20160827 14:41:27< celticminstrel> Is there any particular reason why unit attacks consider the ID immutable?
20160827 14:42:22< celticminstrel> (ie, the name key)
20160827 14:42:40 * zookeeper doesn't understand the question
20160827 14:42:57< celticminstrel> You can't change the ID of an existing attack in the C++ API.
20160827 14:43:17< mattsc> zookeeper: Yeah, I actually “recently” found a comment saying “assassin MAI” in my notes.  I don’t remember what exactly I had in mind with that (it’s from way before we started talking about this one), but my guess is that it was something similar.
20160827 14:43:19< celticminstrel> I was wondering if there's a reason for that.
20160827 14:43:47< zookeeper> celticminstrel, uh, so what happens if i... do change it via WML?
20160827 14:44:08< celticminstrel> Well, in that case, the attack is recreated with the new ID.
20160827 14:44:25< zookeeper> celticminstrel, sounds mysterious
20160827 14:44:27< celticminstrel> Because store/unstore recreates the unit.
20160827 14:44:59< celticminstrel> Well then, unless gfgtdf or someone objects in the next five minutes, I guess I'll go ahead and change it.
20160827 14:45:05< zookeeper> mattsc, the only other place where i might have asked about "assassin" AIs would be EI:04a
20160827 14:45:10< vultraz> celticminstrel: you never replied to my paste last night
20160827 14:45:38< celticminstrel> Because I couldn't view it without a browser and wasn't ready to launch the browser at that time.
20160827 14:45:47< mattsc> zookeeper: I’m pretty sure that it was not in this channel that somebody asked about it.
20160827 14:45:53< zookeeper> celticminstrel, so is there specific code that is clearly intended to prevent the attack name from being changed..?
20160827 14:46:14< celticminstrel> zookeeper: Not quite, it's more like there's a lack of code allowing you to change it.
20160827 14:47:42< zookeeper> celticminstrel, right. the only concern that springs to my mind is whether changing the name mid-combat could lead to Bad Things (tm) happening.
20160827 14:47:57< celticminstrel> Good question, I'll try that.
20160827 14:48:33< mattsc> zookeeper: So let me turn this into an MAI.  I agree that it is likely sufficiently generic that some folks might find it useful (and it’s quite easy to do so from here).
20160827 14:48:43< zookeeper> mattsc, sure, sounds good
20160827 14:48:58< mattsc> I think the current input parameters ([filter], target_id, ca_score) are probably the only ones we need for now.
20160827 14:49:09< celticminstrel> So I managed to get tad's crash.
20160827 14:49:14< celticminstrel> It only happens in campaigns.
20160827 14:49:28< mattsc> After that, it’s going to be trivial to include it HttT, EI or wherever (or not doing so).
20160827 14:49:36< vultraz> celticminstrel: alright, let me know when you can look at it
20160827 14:50:02< celticminstrel> Looks like it was a trivial issue - forgetting to update the stack index.
20160827 14:50:42< celticminstrel> ie, I missed something when changing luaW_pushlocation
20160827 14:51:49< celticminstrel> Well, I suppose I should say it doesn't happen in my test scenario but does in a campaign (though I didn't get it in the tutorial either). I didn't test any other scenarios.
20160827 14:53:18< gfgtdf> celticminstrel: 'Well then, unless gfgtdf or someone objects in the next five minutes, I guess I'll go ahead and change it.' hmm what do you wan to change ? 
20160827 14:53:48< celticminstrel> gfgtdf: Adding attack_type::set_id()
20160827 14:54:01< celticminstrel> So that you can do atk.name = "whatever" in Lua
20160827 14:54:31-!- Shiki [~Shiki@141.39.226.227] has joined #wesnoth-dev
20160827 14:54:50< zookeeper> mattsc, hmm, will it be possible to add location filtering too, to for example exclude certain areas of the map from being considered?
20160827 14:54:51< gfgtdf> celticminstrel: hmm note that the lua ttack proxy ididtifies attacks by id, so wiritng atk.name = "whatever" will automatically invalidate the atk object
20160827 14:55:09< celticminstrel> I already changed that, it now stores a pointer to the attack instead.
20160827 14:55:10< zookeeper> mattsc, not that i think it's needed right now, but that's the only other thing that comes to mind that might be useful in some cases
20160827 14:55:21< gfgtdf> celticminstrel: hmm ok
20160827 14:55:35< gfgtdf> celticminstrel: so how to you guard against invalid pointers when accessing attacks ?
20160827 14:55:53< mattsc> zookeeper: in form of an [avoid] tag?  Sure that should not be too hard.
20160827 14:56:23< celticminstrel> gfgtdf: It also stores a reference to the unit that owns the attack. If the unit becomes invalid, it assumes the attack is also invalid. That's admittedly not perfect though...
20160827 14:56:46< mattsc> The code already uses custom path finding, so we could simply add an impossibly large movement cost to avoided locations.
20160827 14:56:53< zookeeper> mattsc, something like that, yeah.
20160827 14:57:38< mattsc> zookeeper: … and then you could use that to force the assassins to circle around the north
20160827 14:57:58< gfgtdf> celticminstrel: unit::attacks_; is a std::vector<attack_type>, so when for examepla  a new attack is added it can happen that the whole content of the emempty os moves around so that the pointers are invalid then
20160827 14:58:06< zookeeper> mattsc, or to force forest-ambushing assassins to stay in forests, etc
20160827 14:58:07< celticminstrel> Right.
20160827 14:58:17< celticminstrel> Like I said, it's not perfect.
20160827 14:58:18< mattsc> sure
20160827 14:58:44< gfgtdf> celticminstrel: i think we should solve these problems before deciding atto atta writable .name
20160827 14:59:09< celticminstrel> Supposing the problems were resolved, would you then object to writable .name?
20160827 15:00:15< gfgtdf> celticminstrel: hmm i guess not.
20160827 15:00:28< mattsc> zookeeper: hmm, there are two possible ways of doing this.  1. Never cross avoided terrain.  2. Don’t stop on avoided terrain.
20160827 15:00:40< mattsc> Because of the way how the AI is set up, 1. is easy, 2. not so much.
20160827 15:00:52< mattsc> but I’m sure it could be done somehow
20160827 15:00:53< zookeeper> mattsc, i'm pretty sure 1 is fine
20160827 15:01:14< celticminstrel> Idea 1: Store attack index instead of pointer. Idea 2: Store copy along with the pointer.
20160827 15:01:25< mattsc> zookeeper: Okay, I’ll do that then.  We can always add additional behavior later, if it’s found useful.
20160827 15:01:26< zookeeper> mattsc, would it still cross the avoided terrain to attack the target?
20160827 15:01:35< celticminstrel> Leaning towards #2 actually.
20160827 15:01:46< mattsc> zookeeper: yes — the attacks are left to the default AI.
20160827 15:02:01< zookeeper> mattsc, oh, good
20160827 15:02:56< vultraz> celticminstrel: so, I'm curious... for maps.. isn't *(map.find(foo)) the same as map[foo]
20160827 15:03:08< celticminstrel> vultraz: No.
20160827 15:03:22-!- Kwandulin [~Miranda@p200300760F6F2F47F8A3DD6A76337431.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160827 15:03:29< celticminstrel> *maps.find(foo) accesses an invalid iterator if the element is not in the map.
20160827 15:03:48< celticminstrel> map[foo] adds the element to the map if it was not already there, with a default-constructed value.
20160827 15:04:05< celticminstrel> In other words, don't do *maps.find(foo).
20160827 15:06:40< celticminstrel> Hmm, I don't see this weird aspect warning in TSG2 when going to the citadel, and the breakpoints didn't trigger either.
20160827 15:11:16-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160827 15:12:46< celticminstrel> tad_: You might be happy to hear that I just fixed it, though it'll be a bit longer before I push. I just had to change the -3's in luaW_pushlocation to -2.
20160827 15:13:06< celticminstrel> At least, I got the crash in TB before doing that and didn't get it in TSG after doing it.
20160827 15:15:46< mattsc> zookeeper: well, I semi-retract my last statement.  The way the AI is set up currently, it would not cross the avoided terrain right around the target, but I will make sure that it does.
20160827 15:17:11< zookeeper> mattsc, great! if an assassin can strike then it shouldn't really have other considerations at that point
20160827 15:18:59< mattsc> zookeeper: right; but there’s also the problem of general pathfinding, and if a target sits in the plains with a “forest assassin”, the assasin might never get there.
20160827 15:19:39< mattsc> That’s all solvable, I just need to take some time to think it through.
20160827 15:20:07< zookeeper> mattsc, sure, but i think that can be left to the scenario designer
20160827 15:21:16< mattsc> Well, yes, in principle.  But it would be nice if it weren’t possible to move Konrad into the water in the HttT scenario and thus render the AI useless.
20160827 15:21:30< mattsc> And you can be sure that somebody would figure that out if it were the case.  ;P
20160827 15:22:33< mattsc> Also, I think it would be too restrictive to require that all hexes must be bordering at least one forest tile, and that all forest tiles must be contiguous on a map.
20160827 15:22:51< celticminstrel> Ugh, this really is a lot more complicated than I thought, huh...
20160827 15:23:00< mattsc> Anyway, as I said, it’s just a technical question of how to solve it.
20160827 15:23:25< mattsc> It might be as simple as assigning avoided hexes a high movement cost, but not an infinite one.
20160827 15:23:31< zookeeper> mattsc, well those are solvable by just crafting the location filter appropriately.
20160827 15:23:42< celticminstrel> The attack should remain valid if the attacks are moved in memory, after all.
20160827 15:23:43< mattsc> zookeeper: true
20160827 15:24:18< celticminstrel> On the other hand, if you have a reference to the second attack of the unit, and that attack is removed and a new one is added, the reference should not now point to the new attack.
20160827 15:25:32< zookeeper> mattsc, i'm just trying to let you keep the AI simple while having the WML be able to control all the fancier details if necessary
20160827 15:26:35< zookeeper> like, if konrad can get in the water and be untouchable, then that's something you can avoid by [and] [filter] id=Konrad [/filter] radius=6 [/and] or something
20160827 15:29:47< zookeeper> and i think that's a perfectly reasonable amount of work to offload to the scenario designer
20160827 15:30:19< tad_> I don't know anything about the assassin work you're discussing in HttT S08 but that is one of the scenario where I don't like the way the villages detract Li'sar's army from the task at hand. But when I tell them to ignore villages, they hit Konrad much harder. And, since 'balance' is a black art, I backed away from making the change.
20160827 15:30:46< mattsc> zookeeper: agreed with all of that
20160827 15:32:53< zookeeper> tad_, what mattsc has done is an AI for a squad of units (fencers/assasins/etc) that will try to avoid engagement with other units and slip through to attack konrad (or anyone we specify)
20160827 15:33:34< celticminstrel> If there was a way to ask "has this pointer been deleted", this would be simpler.
20160827 15:33:48< zookeeper> tad_, the idea being to replace the silly cave ambush with actual skirmishing assassins which would be hard to protect against
20160827 15:35:10< tad_> Ah. Well, the main reason the cave attack is so silly is it's so obvious even to a noob ("What's that cave down there?") would be better to simply ambush from forest and not use a big red flag which says "Here is something! Look HERE!"
20160827 15:35:37< tad_> But I like the idea for that Fencer.
20160827 15:36:22< celticminstrel> Oh, actually, vultraz will hate this idea, but I could store the unit attacks in that smart_list container.
20160827 15:36:31< celticminstrel> Instead of a vector.
20160827 15:36:33< tad_> As is, when I play it, I just ignore him. When Li'sar calls on him he's too far from Konrad to make it through my lines. Having him be more focused on his target, though, would change that.
20160827 15:36:55< celticminstrel> Though not sure how many things rely on the attacks being random-access; if there are a lot, that'd be a bad idea.
20160827 15:37:12-!- travis-ci [~travis-ci@ec2-54-234-78-72.compute-1.amazonaws.com] has joined #wesnoth-dev
20160827 15:37:13< travis-ci> spixi/wesnoth#14 (chart_engine - 8e11d8d : Spixi): The build is still failing.
20160827 15:37:13< travis-ci> Build details : https://travis-ci.org/spixi/wesnoth/builds/155590463
20160827 15:37:13-!- travis-ci [~travis-ci@ec2-54-234-78-72.compute-1.amazonaws.com] has left #wesnoth-dev []
20160827 15:49:43< vultraz> SMMARRTTT LIISTT D:
20160827 15:51:36-!- Shiki [~Shiki@141.39.226.227] has quit [Ping timeout: 244 seconds]
20160827 15:51:37< zookeeper> tad_, well nothing prevents us from combining both. the assassin squad can spring up as a surprise on turn X from various randomized directions instead of being there from the beginning.
20160827 15:51:59-!- Shiki [~Shiki@141.39.226.227] has joined #wesnoth-dev
20160827 15:53:14< vultraz> celticminstrel: new paste of the thing from last night with the full before/after http://pastebin.com/5b3HLJ84
20160827 15:53:30< vultraz> trying to figure out if I need that extra if block.
20160827 16:00:20< vultraz> if I'm reading the logic right it's supposed to prioritize relation over name
20160827 16:00:41< tad_> zookeeper: Between wifely distractions and a system lock-up I'm not sure I have everything we wanted for TSG. (1) back off ending changes (2) take a look at S05 conversation flow in particular exposing the lich as a doppleganger.
20160827 16:04:59< zookeeper> tad_, i think that was all... although 1 doesn't need to be total backing off, could just... uh, edit it somehow
20160827 16:06:45< tad_> zookeeper: It does need something. Backing out the change is easy. I'll take another look at how to ease out of the campaign after I think through S05 and all the paths to win and lose it.
20160827 16:07:19< zookeeper> sure
20160827 16:10:21< tad_> celticminstrel: With the revert I have a runnable engine so I'll just watch for a commit fixing the crash. Going offline to cogitate about TSG S05 script and blocking.
20160827 16:14:06-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160827 16:19:28< vultraz> hm..
20160827 16:19:46< vultraz> title.replace(title.begin(), title.end(), '\n', ' '); seems to render the string empty or something...
20160827 16:19:56< vultraz> ('title' is a string)
20160827 16:20:06< vultraz> and title.replace(title.begin(), title.end(), "\n", " "); causes a crash
20160827 16:20:10< vultraz> perhaps I am using replace wrong..
20160827 16:23:26< vultraz> oh
20160827 16:23:29< vultraz> durr
20160827 16:23:37< vultraz> replace doesn't do what I think it does
20160827 16:27:27< vultraz> blah
20160827 16:27:30 * vultraz pings celticminstrel
20160827 16:33:54 * vultraz decides to use boost::replace_all(title, "\n", " "); instead
20160827 16:37:13-!- Samual [~Samual@xonotic/core-team/Samual] has quit [Ping timeout: 250 seconds]
20160827 16:39:54-!- Samual [~Samual@xonotic/core-team/Samual] has joined #wesnoth-dev
20160827 16:45:27< gfgtdf> vultraz: what you want is mostlikeley std::replace
20160827 16:45:45< gfgtdf> vultraz: repalce(title.begin(), title.end(), '\n', ' ')
20160827 16:48:55-!- Samual [~Samual@xonotic/core-team/Samual] has quit [Ping timeout: 250 seconds]
20160827 16:49:16< vultraz> hm, that works for just a space
20160827 16:49:34< vultraz> but i decided to actually replace it with " - " (except using an em-dash)
20160827 16:49:53< vultraz> boost::replace_all works for that, std::replace isn't
20160827 17:06:09-!- DeFender1031 [~DeFender1@46-116-114-128.bb.netvision.net.il] has joined #wesnoth-dev
20160827 17:08:29-!- irker956 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160827 17:08:29< irker956> wesnoth: Charles Dang wesnoth:master ae2a3c53e08b / src/gui/widgets/listbox.cpp: tlistbox: applied af58971727828f to second set_row_shown overload https://github.com/wesnoth/wesnoth/commit/ae2a3c53e08b8a7ef4b29340a292dbbf2040dbc7
20160827 17:08:30< irker956> wesnoth: Charles Dang wesnoth:master d6cff9b089e7 / / (2 files in 2 dirs): MP Create: display game title in details area https://github.com/wesnoth/wesnoth/commit/d6cff9b089e7971749c281666ca5972a0b959f3a
20160827 17:09:50< vultraz> i wonder if i should work on a gui2 mp connect screen
20160827 17:11:15< vultraz> first the chat area needs to be widget-ized
20160827 17:27:58-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160827 17:32:41< celmin> vultraz: You're using std::string::replace wrong.
20160827 17:32:57< celmin> The iterators you pass point to the beginning and end of the part of the string you want to replace.
20160827 17:33:03< celmin> Not the whole string.
20160827 17:33:19< celmin> So if you pass begin and end, of course the string would be emptied.
20160827 17:33:54< celmin> I'm now looking at your pastebin. What should I be looking for?
20160827 17:35:04-!- Samual [~Samual@2601:547:1000:86f:a0ba:892a:fe0c:fd1a] has joined #wesnoth-dev
20160827 17:35:04-!- Samual [~Samual@2601:547:1000:86f:a0ba:892a:fe0c:fd1a] has quit [Changing host]
20160827 17:35:04-!- Samual [~Samual@xonotic/core-team/Samual] has joined #wesnoth-dev
20160827 17:36:10-!- Kwandulin [~Miranda@p200300760F6F2F47F8A3DD6A76337431.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160827 17:37:47< celmin> Hmm.
20160827 17:38:16< celmin> This sorting seems a little weird.
20160827 17:41:32< Shiki> Hi. If I enable the new lobby and klick on create local game instead of connect to an server, then the game crashes.
20160827 17:43:56< vultraz> hmm
20160827 17:44:03< vultraz> Shiki: what is the stacktrace?
20160827 17:45:15-!- Samual [~Samual@xonotic/core-team/Samual] has quit [Ping timeout: 250 seconds]
20160827 17:45:35< Shiki> here: https://bpaste.net/show/e8d1fc936a23
20160827 17:45:54< vultraz> hm hm
20160827 17:46:15< celmin> Sounds like out-of-range menuitem.
20160827 17:46:24< vultraz> indeed
20160827 17:46:24-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160827 17:47:40< celmin> Invalid prefs?
20160827 17:48:00-!- Samual [~Samual@xonotic/core-team/Samual] has joined #wesnoth-dev
20160827 17:48:06< celmin> Suggested repro: Select SP campaigns. Relaunch without debug mode.
20160827 17:48:18-!- JyrkiVesterinen [~JyrkiVest@87-92-34-95.bb.dnainternet.fi] has joined #wesnoth-dev
20160827 17:48:28< celmin> (I guess you'd need to actually start the campaign.)
20160827 17:48:45< tad_> I want to try an experiment which has an event occuring 2 turns after a moveto triggers. I can't seem to get $() to work at all on [event]name= and I'm not seeing what I'm doing wrong inside a [filter_condition] trying to add 2 to turn_number (moveto) and compare to turn_number(now)
20160827 17:49:21< vultraz> except it explicitly checks that the selection isn't sp campaigns..
20160827 17:49:32< celmin> Well, [event] at scenario level isn't variable-substituted, so $() of course wouldn't work there.
20160827 17:49:48< tad_> It's a nested event.
20160827 17:49:50< celmin> (Or, to be more precise, it's only substituted at run time, not add time.)
20160827 17:49:57< celmin> So what is the goal?
20160827 17:50:20< vultraz> interesting
20160827 17:50:23< tad_> [event]name=moveto ... [event]name=$(...) ... [/event][/event]
20160827 17:50:25< vultraz> it will still show sp campaigns
20160827 17:50:29< vultraz> even without debug mode..
20160827 17:50:37< celmin> That's not good?
20160827 17:50:46-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160827 17:50:51< vultraz> it won't appear in the dropdown
20160827 17:50:54< vultraz> but it will in the list
20160827 17:51:00< vultraz> how to combat this..
20160827 17:51:16< celmin> As far as I know, that should work, tad_ 
20160827 17:51:31< celmin> Not sure if you'd need to set delayed_variable_substitution though.
20160827 17:51:39< tad_> celmin: OK. I must not be seeing it. I'll keep at it.
20160827 17:51:47< vultraz> hm..
20160827 17:51:57< vultraz> level types are removed from the list if they have no entries...
20160827 17:52:01< celmin> tad_: After the moveto, you could check the inspector to see if the event was added.
20160827 17:52:11< celmin> vultraz: That could be the culprit.
20160827 17:52:18< celmin> Hide them instead of removing them?
20160827 17:52:37-!- Samual [~Samual@xonotic/core-team/Samual] has quit [Ping timeout: 250 seconds]
20160827 17:52:58< tad_> vultraz: Oh, I just remembered, you asked about the new leader list on Load. I like it but it has bugs. The list keeps growing as I keep re-loading. Sometimes it shows "?" and sometimes it shows the leader's image. I checked against current master once I got it to run.
20160827 17:53:12< vultraz> level_type is an int, right?
20160827 17:53:17< celmin> Think so.
20160827 17:53:20< vultraz> tad_: that really shouldn't happen..
20160827 17:53:26< celmin> Or maybe an enum.
20160827 17:54:22< vultraz> maybe this 'saving selection' thing was a bad idea
20160827 17:54:28< celmin> ?
20160827 17:54:30< celmin> No?
20160827 17:55:00< tad_> celmin: I check with inspect and I see things like ' name="$turn_number + 4" ' and ' name="$($turn_number) + 4)" ' but this is turn 1 and I cannot get ' name="turn 5" '
20160827 17:55:21< celmin> tad_: That's definitely not right.
20160827 17:55:31< celmin> Are you using delayed_variable_substitution=yes?
20160827 17:55:50< vultraz> hmm ok..
20160827 17:56:07< vultraz> how do I check if an int value...is valid in a vector of enums :|
20160827 17:56:25< celmin> Well, an enum is an int, so… std::find?
20160827 17:56:35< celmin> If it's a MAKE_ENUM, find_if.
20160827 17:56:44< tad_> celmin: Both yes and no (and not present). So I decided it's not working and tried [filter_condition] and that's not working either. So I was hoping someone would be able to say "Look at campaign/scenario for an example."
20160827 17:56:49< celmin> With std::bind(&enum_class::v, _1) as the predicate.
20160827 17:57:13< celmin> tad_: So it doesn't work regardless of whether variable substitutio is delayed?
20160827 17:57:51< celmin> Wait no, that's not the right predicate.
20160827 17:58:04< vultraz> there's always from_int..
20160827 17:59:12< tad_> celmin: The $() beats me up every time I try to use it. Well, I have a working $() someplace .. just can't remember where. I'll get back to it.
20160827 17:59:17-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160827 17:59:46< vultraz> er
20160827 17:59:48< vultraz> wait
20160827 17:59:49< vultraz> it's a vector of pairs..
20160827 17:59:57< celmin> Ah, he left. I was about to say that I think I got it working somewhere too, maybe in my campaign.
20160827 17:59:59< vultraz> ok, find_if I need
20160827 18:00:01< celmin> Though that's 1.12...
20160827 18:03:22< vultraz> this look alright?
20160827 18:03:24< vultraz> 	const bool valid_saved_selection = std::find_if(level_types_.begin(), level_types_.end(), [](level_type_info& info) {
20160827 18:03:25< vultraz> 		return info.first == ng::level::TYPE::from_int(preferences::level_type());
20160827 18:03:27< vultraz> 	}) != level_types_.end();
20160827 18:06:21-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160827 18:07:29< tad_> celmin: see, I just needed to bitch about it.  Got it. Needed to say "$($($turn_number| + 2))" single eval didn't cut it. eval-the-eval did the trick
20160827 18:07:44< celmin> What, that's weird...
20160827 18:07:59< celmin> vultraz: Um, just what are you doing?
20160827 18:08:11< celmin> That find roughly looks okay, out of context.
20160827 18:08:39< vultraz> celmin: checking that the saved selection int matches a value in the level_types_ vector, which is a vector of pairs
20160827 18:09:16< celmin> Okay, so that's fine, but there was a separate issue about the combobox not always containing all options, right?
20160827 18:09:49< vultraz> no
20160827 18:09:53-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Client Quit]
20160827 18:10:01< celmin> If you select Scenarios, and then go into the editor and create a new map and save it, Scenarios should still be selected the next time you look eve though (if I recall correctly) User Maps appears above Scenarios.
20160827 18:10:05< vultraz> that's handled correctly
20160827 18:10:08< celmin> It is?
20160827 18:10:15< celmin> Well, alright then.
20160827 18:10:24< celmin> ^even
20160827 18:10:28< vultraz> tho
20160827 18:10:30< vultraz> hm
20160827 18:10:35< vultraz> what you describe is uh...
20160827 18:10:42< vultraz> well, User Maps doesn't appear above scenarios
20160827 18:10:50< celmin> What was the order again?
20160827 18:12:08< vultraz> S, C, UM, US, RM, SpC
20160827 18:13:51-!- hay207_ [~hay207@41.34.62.239] has quit [Quit: Konversation terminated!]
20160827 18:14:51< vultraz> ok, my code works
20160827 18:14:53< celmin> Okay, so attacks being random-access is relied upon in places.
20160827 18:15:36< celmin> vultraz: Okay, so new example. You have no user maps or scenarios, and you go select Random Maps. Then you go to the editor, create and save a new map or scenario, and go back to MP Create. Random Maps should still be selected, rather than User Maps or User Scenarios.
20160827 18:15:57< vultraz> obviously
20160827 18:16:12< vultraz> not sure if it is, though..
20160827 18:16:40< vultraz> hm
20160827 18:16:48< vultraz> i seem to not have fixed the crash..
20160827 18:17:14< vultraz> if i remove my user maps/scenarios i still get it
20160827 18:17:36< vultraz> this... frustrates me
20160827 18:18:27< celmin> Want me to look at it?
20160827 18:19:23< vultraz> it's rather impossible to debug here since scrollbars throw exceptions for some godforsaken reason
20160827 18:19:37< vultraz> celmin: let me commit my code
20160827 18:19:54< celmin> Well, I can't look at it until I've finished the Lua stuff anyway.
20160827 18:23:52< vultraz> (do I really need to use from_int?
20160827 18:23:55< vultraz> not sure
20160827 18:24:10< vultraz> the existing check does not
20160827 18:24:12< vultraz> preferences::level_type() != ng::level::TYPE::SP_CAMPAIGN
20160827 18:24:17< vultraz> so perhaps I don't
20160827 18:29:35< vultraz> hm
20160827 18:29:50< vultraz> perhaps I don't need to call display_games_of_type directly in pre_show
20160827 18:29:55< vultraz> and should call update_games_list
20160827 18:29:58< vultraz> blah
20160827 18:30:01< vultraz> i'll work on this later
20160827 18:34:05< celmin> from_int is for if you have an int and want to get the corresponding enum.
20160827 18:34:33< celmin> However if you just want to compare to a known enum, it's probably not needed.
20160827 18:35:58-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160827 18:36:33-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160827 18:40:11< celmin> Okay, so, let me see if I can enumerate my needs...
20160827 18:40:47< celmin> 1. A reference to an existing attack on a unit should always point to that attack on that unit, but if that attack is removed from the unit, the attack reference should still point to a copy.
20160827 18:41:12< celmin> …wait, did I just sum up all the requirements in a single sentence?
20160827 18:41:42< celmin> So, most of the requirements would be solved by storing the index of the attack, rather than a pointer to it.
20160827 18:41:53< celmin> But that fails two requirements:
20160827 18:42:01< celmin> 1. Attacks removed from a unit are still valid attacks.
20160827 18:42:20< celmin> 2. If you remove an attack and add a new one, references to the original attack still reference the original one rather than the new one.
20160827 18:43:21< JyrkiVesterinen> Has anyone tried the scenario editor recently?
20160827 18:43:40< JyrkiVesterinen> Open the map editor, select File -> New Scenario, add a side, and attempt to place a unit.
20160827 18:43:43< celmin> Last time I tried it was when doing GUI2 windows, a few days ago.
20160827 18:43:49< celmin> I didn't try placing a unit then, though.
20160827 18:43:51< JyrkiVesterinen> The editor crashes when you do that.
20160827 18:44:01< celmin> I think I've heard this before.
20160827 18:44:09< JyrkiVesterinen> It appears to have been happening since this commit: https://github.com/wesnoth/wesnoth/commit/6235e18bbd12751631df0d6d457b8a358354e183
20160827 18:44:28< JyrkiVesterinen> I'm trying to figure out how to fix it.
20160827 18:44:33< celmin> Makes sense.
20160827 18:44:51< celmin> resources::gameboard is not defined for the editor.
20160827 18:44:57< celmin> Instead of a game_board it has a map_context,
20160827 18:45:31< celmin> So instead of getting teams or units from the game board, it should get them from the map_context.
20160827 18:45:45< celmin> (Both extend display_context, so that part of the interface is the same.)
20160827 18:46:11< JyrkiVesterinen> Yes, unit::get_ability_bool() should get a reference to the map_context in some way.
20160827 18:46:42< JyrkiVesterinen> I'm a little surprised no one found this crash in over two weeks.
20160827 18:46:50< celmin> Actually, get_abilty_bool should not even be called in the editor, honestly.
20160827 18:46:59< celmin> I think the crash was found but never addressed.
20160827 18:47:28< JyrkiVesterinen> Unit_drawer queries if the unit is invisible, and unit::invisible() calls get_ability_bool().
20160827 18:47:37< celmin> Yeah.
20160827 18:47:52< celmin> For some reason I seem to recall discovering this myself.
20160827 18:48:30< celmin> So get_ability_bool accesses resources::gameboard->teams()?
20160827 18:49:04< JyrkiVesterinen> Yes, in line 156.
20160827 18:49:10< celmin> …you know, it might help a lot if each unit held a pointer to their team in addition to the side number.
20160827 18:49:33< celmin> Though I dunno if it would fix this bug (might just defer it to a different location).
20160827 18:50:46< JyrkiVesterinen> That would be quite large refactoring. I could attempt it later, but right now I'd like to just fix the crash.
20160827 18:51:10< celmin> Yeah, it would, so not something to attempt lightly, I guess.
20160827 18:51:52< celmin> I wonder why resources::gameboard has to be a game_board though rather than a display_context.
20160827 18:52:35< celmin> If it was a display_context, and the editor properly assigned it whenever switching maps or whatever, then these sorts of problems would just disappear.
20160827 18:53:47< celmin> I don't know if any uses of it access things that aren't in display_context.
20160827 18:54:41-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160827 18:55:01-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20160827 18:55:02-!- wedge010 is now known as wedge009
20160827 18:56:21< JyrkiVesterinen> Hmm, most reasonable fix I can see is passing the siaply_context to unit::invisible() and subsequently to get_ability_bool().
20160827 18:56:27< celmin> Grep suggests that the majority of uses would be fine if it was just a display_context, though there are definitely some that aren't.
20160827 18:56:28< JyrkiVesterinen> *display_context
20160827 18:56:35< celmin> That would work, yeah.
20160827 18:57:02< celmin> Passing it around as necessary is probably better than using globals.
20160827 18:57:17< celmin> Actually, you could pass whatever it accesses from the display_context, rather than the whole display_context.
20160827 18:57:38< celmin> Unless it accesses multiple things.
20160827 18:59:19< celmin> I feel like my goal would be best served by storing boost::intrusive_ptr<attack_type> instead of attack_type...
20160827 18:59:43< JyrkiVesterinen> The only thing it accesses is the list of teams.
20160827 19:00:04< JyrkiVesterinen> But I just feel that passing the entire display_context expresses the intent a bit more clearly.
20160827 19:00:12< celmin> Fair enough, I guess.
20160827 19:00:17< JyrkiVesterinen> Copying a reference is cheap in any case.
20160827 19:00:21-!- fabi [~fabi@176.5.22.123] has joined #wesnoth-dev
20160827 19:00:21< celmin> True, true.
20160827 19:00:34< celmin> Which just means that there's no difference in efficiency between the two.
20160827 19:01:42-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160827 19:01:58-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 255 seconds]
20160827 19:03:38 * celmin pokes vultraz 
20160827 19:07:35< celmin> I wonder if the game uses non-const unit_types anywhere...
20160827 19:08:25-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160827 19:08:47< celmin> Unrelatedly, I also wonder if it supports unit variations with sub-variations.
20160827 19:16:07-!- Kwandulin [~Miranda@p200300760F6F2F47ECE99BE6ACD8A009.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160827 19:26:18< fabi> hi
20160827 19:26:33< celmin> 'lo
20160827 19:36:46-!- gfgtdf [~chatzilla@x4e363e27.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0/20160726073904]]
20160827 19:38:35-!- gfgtdf [~chatzilla@x4e363e27.dyn.telefonica.de] has joined #wesnoth-dev
20160827 19:38:46< gfgtdf> vultraz: is gui2 mp create now complete?
20160827 19:39:52-!- jswensen [~jswensen@cpe-98-145-147-33.natnow.res.rr.com] has joined #wesnoth-dev
20160827 19:41:40< gfgtdf> vultraz: alos, does it fix http://gna.org/bugs/?21156 ?
20160827 19:43:18< vultraz> gfgtdf: it's almost complete
20160827 19:43:46< vultraz> and yes, I think it fixes that
20160827 19:44:02< vultraz> gfgtdf: there are just a few small issues to smooth out
20160827 19:44:13< vultraz> celmin: what is it?
20160827 19:44:17< gfgtdf> vultraz: hmm for example ?
20160827 19:44:37< celmin> vultraz: Considering using intrusive_ptr for attacks.
20160827 19:44:46< vultraz> celmin: no opinion
20160827 19:45:22< vultraz> gfgtdf: well, one is that if you apply a player number filter and then switch game types, when you move the filter back  to Any no games of the new type displays
20160827 19:45:39-!- fabi [~fabi@176.5.22.123] has quit [Ping timeout: 244 seconds]
20160827 19:46:10< vultraz> right now im working on a different bug
20160827 19:46:28< vultraz> but if someone could look into that one it'd be nice
20160827 19:46:43< vultraz> i haven't confirmed whether it happens with text filters
20160827 19:47:17-!- fabi [~fabi@176.5.22.123] has joined #wesnoth-dev
20160827 19:47:22< JyrkiVesterinen> I found a bug in the unit list dialog: https://github.com/wesnoth/wesnoth/commit/cfd205e3a46b71ed1fb2db77c7a4fc76ec62e74c#diff-2d6e3849f710570403a918c11425b48bR163
20160827 19:47:52< JyrkiVesterinen> It shows the slowed icon for petrified units, invisible icon for slowed units and petrified icon for invisible units.
20160827 19:48:06< JyrkiVesterinen> I can just as well fix that while I'm touching the code here.
20160827 19:50:45< jswensen> Great news! I finally got all of the dependencies and codebase to compile in an XCode project for iOS real device and iOS simulator. There is still a lot of work to get a 1.13+ version for iOS, but the foundation is laid (including documentation about how to get all the dependencies built in an almost-automated manner).
20160827 19:52:19< JyrkiVesterinen> Excellent. Thank you. :)
20160827 19:53:57< celmin> Ahaha, what.
20160827 19:54:15< celmin> And jswensen, good to hear.
20160827 19:54:33< celmin> Does it run on the simulator too?
20160827 19:54:40< celmin> Obviously UI work would be needed, but...
20160827 19:55:20< jswensen> Is should. I made all the dependencies as “fat” libraries so they have support for “i386 x86_64 armv7 armv7s arm64” all rolled into the libraries.
20160827 19:55:45< celmin> Huh, arm too.
20160827 19:56:11< jswensen> Currently I don’t have any of the work done to actually set up an OpenGL context and get SDL drawing to it. I basically have an empty app with the project compiling all the Wesnoth sources. It loads, but just shows a blank screen for now.
20160827 19:56:48< celmin> I see.
20160827 20:15:23< vultraz> JyrkiVesterinen: ah, derp :|
20160827 20:15:25< vultraz> can you fix?
20160827 20:15:45< JyrkiVesterinen> Already fixed locally.
20160827 20:15:57< vultraz> sweet :)
20160827 20:16:49-!- gfgtdf [~chatzilla@x4e363e27.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0/20160726073904]]
20160827 20:17:44-!- ancestral [~ancestral@209.181.254.220] has joined #wesnoth-dev
20160827 20:18:58< vultraz> I dunno how I screwed that up, tbh
20160827 20:23:47< vultraz> celmin: would you object if I made menu_button::set_selected automatically select 0 if the provided value is bad?
20160827 20:24:49< celmin> I guess menu_button, unlike drop_down_list, must have a selection.
20160827 20:25:26< celmin> I'm not sure if silently selecting 0 if the value is bad is a good idea.
20160827 20:25:30< vultraz> right now it asserts
20160827 20:25:45< celmin> It's better than asserting, but there's also the possibility to not change the selection at all.
20160827 20:25:57< vultraz> true
20160827 20:26:32< vultraz> I'm debating the best way to handle this problem
20160827 20:26:36< celmin> I think a lot of the uses of assert could be replaced by VALIDATE. Then it'd dump to menu instead of crashing.
20160827 20:26:47< celmin> After showing an error dialog.
20160827 20:27:10< celmin> Of course, there could still be a problem if the error dialog, loading screen, or title screen caused an assert, but...
20160827 20:27:21< celmin> Well, we're pretty sure that's not the case, right?
20160827 20:27:32< vultraz> what?
20160827 20:28:08< celmin> Which part do you not understand?
20160827 20:28:17< vultraz> [07:27:09]	celmin	Of course, there could still be a problem if the error dialog, loading screen, or title screen caused an assert, but...
20160827 20:28:22< vultraz> why would they?
20160827 20:28:49< celmin> I know no reason why they would.
20160827 20:29:02< celmin> As long as they don't change, I'm pretty sure they wouldn't assert.
20160827 20:33:24-!- RatArmy [~RatArmy@om126212248171.14.openmobile.ne.jp] has joined #wesnoth-dev
20160827 20:36:07< JyrkiVesterinen> I opened a PR about my fixes: https://github.com/wesnoth/wesnoth/pull/760
20160827 20:36:35< vultraz> I thought that bug was caused by something else...
20160827 20:36:37< vultraz> huh
20160827 20:36:52< vultraz> though perhaps I'm misremembering and that was indeed the default cause
20160827 20:38:06< vultraz> looks like for such an extensive change... I think you should do as you suggest
20160827 20:38:25< celmin> Sounds like we disagree.
20160827 20:38:33< celmin> Assuming you're talking about what I just commented on.
20160827 20:38:39< vultraz> yes
20160827 20:38:46< vultraz> I guess I'll defer to you
20160827 20:42:17 * vultraz has just written code with three nested lambdas :|
20160827 20:42:22< celmin> Oh my!
20160827 20:42:29< celmin> I'm curious to see this.
20160827 20:43:21< celmin> JyrkiVesterinen: Why'd you move the intf_unit_ability function?
20160827 20:43:58< vultraz> http://pastebin.com/DKepr0KL
20160827 20:44:01< JyrkiVesterinen> Just to get access to game_lua_kernel::board().
20160827 20:44:12< vultraz> at this point I think I should just make level_types_ a map
20160827 20:44:17< celmin> Well, I mean, you moved its definition within the source file.
20160827 20:45:07< celmin> vultraz: That looks somehow over-complicated.
20160827 20:45:16< vultraz> it feels so
20160827 20:45:38< vultraz> I had it simpler, but I though maybe I could make a way to do it where I didn't need to duplicate that if() block..
20160827 20:45:40< celmin> vultraz: Actually, I think it might be better to store the pref as an enum instead of an integer.
20160827 20:45:43< vultraz> and I've ended up here :|
20160827 20:45:50< JyrkiVesterinen> celmin: I moved the definition to move it together with other member functions.
20160827 20:45:58< celmin> Though it would render old prefs incompatible, it would make it all a lot simpler, right?
20160827 20:46:15< JyrkiVesterinen> vultraz: Your outermost lambda is so long that I recommend making it a regular member function.
20160827 20:46:20< celmin> JyrkiVesterinen: I didn't think there was any particular grouping between them...?
20160827 20:46:46< celmin> I mean, I didn't think the member intf_* / impl_* / cfun_* functions were all grouped in one place.
20160827 20:46:48< vultraz> celmin: it level_types_ were also a map, yes
20160827 20:46:57< celmin> What is level_types_?
20160827 20:47:17< vultraz> vector of pair of type and string
20160827 20:47:41< JyrkiVesterinen> They aren't grouped like that. Instead, standalone/free functions are before the member functions.
20160827 20:48:17< celmin> Certainly a lot of member functions are grouped near the bottom, but those aren't intf_* / impl_* / cfun_*
20160827 20:48:42< vultraz> though I dunno how one would get an int from a map
20160827 20:48:57< vultraz> (does the same find method work?)
20160827 20:50:11< vultraz> what I'm thinking is using std::map<ng::level::type, std::string> instead of std::vector<std::pair<ng::level::type, std::string>>
20160827 20:50:28< celmin> What's the string value mean?
20160827 20:50:45< vultraz> translated name of type
20160827 20:50:50< vultraz> to appear in the menu
20160827 20:50:57< celmin> So why isn't it t_string?
20160827 20:51:04 * vultraz shrugs
20160827 20:51:09< vultraz> should it be?
20160827 20:51:10< JyrkiVesterinen> Hmm, a closer looks shows that the functions indeed weren't grouped. I just thought so because the unit functions (all of which were free functions before my change) were grouped.
20160827 20:51:22< JyrkiVesterinen> I'll move it back with some history rewriting.
20160827 20:51:32< celmin> If it's translatable it's probably best to keep it t_string as long as possible.
20160827 20:51:39< vultraz> I never know when to use stuff like size_t and t_string
20160827 20:52:10< vultraz> anyway, I'll try this with a map
20160827 20:52:20< celmin> Especially when passing it to something like set_label, since that takes a t_string to begin with.
20160827 20:52:58< celmin> You know about config::attribute_value::to_enum<>() right?
20160827 20:54:10< vultraz> say what now?
20160827 20:54:34< celmin> Prefs could return the value as a ng::level_type instead of as an int.
20160827 20:54:51< celmin> cfg["mp_level_type"].to_enum<ng::level_type>() if I recall correctly.
20160827 20:54:58< celmin> It requires a MAKE_ENUM though, not sure if that is one.
20160827 20:55:41< vultraz> type is a make_enum, yes
20160827 20:56:11< vultraz> what about the setter?
20160827 20:56:13< vultraz> still int?
20160827 20:57:48 * vultraz ponders his code
20160827 21:00:59< celmin> You'd probably want both sides to take an enum.
20160827 21:01:03-!- ancestral [~ancestral@209.181.254.220] has quit [Quit: i go nstuf kthxbai]
20160827 21:01:06< vultraz> hm
20160827 21:01:13< vultraz> this doesn't really simply anything..
20160827 21:01:18< celmin> For setting the attribute value to the enum, I'm not sure if you need to use the string cast.
20160827 21:01:19< vultraz> using a map, that is
20160827 21:01:30< celmin> Why not?
20160827 21:01:48< celmin> On another note, does anyone think there's any point in encrypting saved user passwords?
20160827 21:02:12 * vultraz ponders what the whole point of this is
20160827 21:02:25< celmin> Even just a rudimentary XOR or key cipher.
20160827 21:02:38< JyrkiVesterinen> There are two views on that.
20160827 21:02:44< vultraz> ensure the saved type in prefs is valid
20160827 21:02:57< vultraz> haven't even touched level yet :|
20160827 21:03:04< celmin> vultraz: Saving it as an enum would ensure it's valid.
20160827 21:03:06< JyrkiVesterinen> We'd have to use reversible encryption, so a skilled attacker would still trivially get the password from the file.
20160827 21:03:11< celmin> Right.
20160827 21:03:25< JyrkiVesterinen> On the other hand, even rudimentary encryption would make it a harder target.
20160827 21:03:30< vultraz> celmin: there's no guarantee that there will be any games of that type
20160827 21:03:40< celmin> Given that they have access to the source code, they wouldn't even need to guess the algorithm.
20160827 21:03:53< celmin> vultraz: If there's no games of that type, then default to the first available type?
20160827 21:04:03< vultraz> yes
20160827 21:04:09< vultraz> that's what I'm trying to do
20160827 21:04:20< JyrkiVesterinen> For example, the FileZilla FTP client saves passwords in plain text, and I have heard that malware often looks for the FZ configuration file. It's just so easy to get FTP passwords from there.
20160827 21:04:21< celmin> JyrkiVesterinen: So do you think there's any point?
20160827 21:04:24< vultraz> except the whole condition is actually
20160827 21:04:25< vultraz> if((game_config::debug || saved_value != ng::level::TYPE::SP_CAMPAIGN) && saved_selection != level_types_.end())
20160827 21:04:27< vultraz> :|
20160827 21:04:30< JyrkiVesterinen> Well, I don't know.
20160827 21:04:43< celmin> Ah, I see what you mean, using even rudimentary encryption could foil automated things.
20160827 21:04:57< celmin> (As long as they aren't written specifically for Wesnoth.(
20160827 21:04:58< celmin> ^)
20160827 21:05:43< vultraz> i could remove the need for a function by not calling display_games_of_type directly, but then I need to get rid of saving the game selection
20160827 21:05:46< vultraz> which i guess we don't want?
20160827 21:05:49< celmin> vultraz: Instead of explicitly testing for SP_CAMPAIGN, simply don't add it to level_types_
20160827 21:06:13< vultraz> but it is added in debug mode...
20160827 21:06:15< vultraz> er
20160827 21:06:17< vultraz> hm
20160827 21:06:22< vultraz> if it's not added outside of debug mode..
20160827 21:06:26< vultraz> then find won't find it
20160827 21:06:28< vultraz> ...
20160827 21:06:30< vultraz> so why is this check here :|
20160827 21:06:44< celmin> There was probably a reason once which disappeared at some point. :P
20160827 21:06:59< vultraz> i dunno
20160827 21:07:00< vultraz> you added it
20160827 21:07:03< celmin> But the check was never removed because no-one bothered to check if it was still needed.
20160827 21:07:16< celmin> Did I? I don't remember why I did that though.
20160827 21:07:57< vultraz> I suppose this function needs to return an int...
20160827 21:10:14< celmin> Which function?
20160827 21:11:18< vultraz> how does one get an int from a map?
20160827 21:11:42< vultraz> std::find as with a vector?
20160827 21:12:11< celmin> What do you want an int for?
20160827 21:12:18< vultraz> initial selection?
20160827 21:12:25< vultraz> for the menu_item?
20160827 21:12:26< celmin> You can't get that from the map.
20160827 21:12:31< celmin> Get it from the enum instead?
20160827 21:12:34 * vultraz groans
20160827 21:12:37< celmin> .v
20160827 21:12:38< vultraz> HOW
20160827 21:12:43< celmin> You can get an int from the map.
20160827 21:12:50< vultraz> ...
20160827 21:12:52< vultraz> . . .
20160827 21:12:53< celmin> But it may give a different ordering.
20160827 21:13:05< celmin> Actually, thinking about it, it probably wouldn't.
20160827 21:13:14< vultraz> there is no to_int method in make_enum
20160827 21:13:15< celmin> Since the enums probably compare on their initial value, and the map is basically sorted.
20160827 21:13:23< celmin> It's not needed, you can use .v
20160827 21:13:28< vultraz> oh
20160827 21:13:39< celmin> Anyway, if you want to get it from the map, std::distance(.begin(), std::find())
20160827 21:13:44< celmin> But using .v is probably better.
20160827 21:14:10< celmin> Since std::distance walks through the map. Though it's a small map, so it probably doesn't matter that much.
20160827 21:14:29< celmin> Still, it means you're walking through it twice - once to find the element, and once to get the distance.
20160827 21:14:35< celmin> Kinds silly.
20160827 21:15:11< celmin> std::distance(iter1, iter2) returns (if I recall correctly) iter2 - iter1, except that it works for non-random-access iterators.
20160827 21:15:32-!- RatArmy [~RatArmy@om126212248171.14.openmobile.ne.jp] has quit [Ping timeout: 240 seconds]
20160827 21:16:18 * vultraz curses
20160827 21:16:40< celmin> What's wrong now?
20160827 21:17:34< vultraz> cannot use .v on an enum value directly
20160827 21:17:37< vultraz> makes sense
20160827 21:17:43< vultraz> I guess I'll just hardcode a 0
20160827 21:17:52< celmin> What?
20160827 21:18:10< celmin> .v on the enum object returns the direct enum value.
20160827 21:18:18< celmin> So if you have a literal specific enum, just use it as-is.
20160827 21:18:40< celmin> ie, if you have ng::level_type::SP_CAMPAIGN, that's implicitly convertible to int.
20160827 21:18:57< vultraz> i see
20160827 21:19:03< shadowm> :\
20160827 21:19:04< celmin> I thought you have an ng::level_type object though.
20160827 21:19:07< celmin> In which case, .v
20160827 21:19:16 * celmin hugs shadowm 
20160827 21:19:27 * shadowm squeaks.
20160827 21:20:31-!- JyrkiVesterinen [~JyrkiVest@87-92-34-95.bb.dnainternet.fi] has quit [Quit: Going to bed]
20160827 21:20:56< vultraz> blah
20160827 21:21:02< vultraz> now i need to rework the removal of members from the map...
20160827 21:22:33< vultraz> why am I even keeping a map now...
20160827 21:22:46< celmin> I have no idea what you're doing or why you're doing it.
20160827 21:22:57< celmin> The map was to look up the translated name, right?
20160827 21:22:59< vultraz> i had it as a vector before for easy access to types via index for displaying new types
20160827 21:23:18< celmin> Maybe you don't need that, because you can just pass in the translated names when initially setting up the menu button.
20160827 21:23:38< celmin> Displaying new types?
20160827 21:23:52< vultraz> yes
20160827 21:23:59< vultraz> display_games_of_type
20160827 21:24:16< vultraz> takes a type
20160827 21:24:28< vultraz> so i figured if i keep a vector that has the type
20160827 21:24:43< vultraz> i can just do vec[i] where i is the index of the selection in the menu
20160827 21:24:58< vultraz> now, I realized I can just do type::from_int(i)
20160827 21:25:07< vultraz> or maybe not..
20160827 21:25:25< vultraz> yeah, no..
20160827 21:25:31< vultraz> because some types aren't shown
20160827 21:25:38< vultraz> that's why they were removed from the vector..
20160827 21:25:43< celmin> You do need to keep a list of which types are shown, yeah.
20160827 21:25:52< vultraz> so now i have another problem
20160827 21:25:54< vultraz> since it's a map
20160827 21:25:58< vultraz> i cannot get the type
20160827 21:26:15-!- Polsaker [~Polsaker@wikimedia/botters.Polsaker] has quit [Ping timeout: 264 seconds]
20160827 21:26:31< celmin> auto iter = map.begin(); std::advance(iter, i); display_games_of_type(iter->first);
20160827 21:26:37< vultraz> doing level_types_.find(type::from_int(i).first is ridiculous 
20160827 21:26:52< celmin> That's the equivalent of display_games_of_type(vec[i]);
20160827 21:26:59-!- trewe [~trewe@2001:8a0:d10f:8d01:ecd:cc20:df97:d63b] has joined #wesnoth-dev
20160827 21:27:03< vultraz> I see
20160827 21:27:14-!- trewe [~trewe@2001:8a0:d10f:8d01:ecd:cc20:df97:d63b] has quit [Max SendQ exceeded]
20160827 21:27:24< celmin> vec[i].first that is
20160827 21:29:05-!- Shiki [~Shiki@141.39.226.227] has quit [Remote host closed the connection]
20160827 21:29:08< vultraz> alright, but now i need to figure out how to delete members from the map..
20160827 21:31:13< vultraz> map.erase takes iterators..
20160827 21:32:15-!- Shiki [~Shiki@141.39.226.227] has joined #wesnoth-dev
20160827 21:32:45< celmin> Yes.
20160827 21:32:50< celmin> But you have the iterator.
20160827 21:32:55< celmin> Don't you?
20160827 21:33:02< vultraz> ...no?
20160827 21:33:16< celmin> Well, there's also a form that takes a key.
20160827 21:33:34< vultraz> i need to remove any map[type] if  create_engine_.get_levels_by_type_unfiltered(type).empty()
20160827 21:33:43< celmin> Still, didn't you just get the iterator with the advance() thing I showed yout?
20160827 21:33:45< celmin> ^you
20160827 21:34:10< celmin> I think that's actually not a good idea.
20160827 21:34:17< vultraz> this is a different place
20160827 21:34:43< vultraz> im taking a break
20160827 21:34:50< celmin> ;kay
20160827 21:34:51< vultraz> this is getting too complicated
20160827 21:34:53< celmin> ^'kay
20160827 21:35:09< vultraz> i need to step back and re-evaluate what it is I need to do
20160827 21:35:22< zookeeper> vultraz, i've been looking at the new loading screen a lot of times, and i still think it was better with the BfW text in it.
20160827 21:35:35 * vultraz shrugs
20160827 21:35:42< vultraz> it's cleaner this way, i think
20160827 21:35:43< zookeeper> it's so plain and black and empty without it
20160827 21:35:48< celmin> I agree with zookeeper.
20160827 21:36:04< celmin> You do a lot of things just because of nebulous reasons like that, huh.
20160827 21:36:25< celmin> Also, I think it's interesting that the logo disappears if a dialog pops up.
20160827 21:36:29< celmin> Is that a bug?
20160827 21:40:30-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160827 21:40:38< celmin> Anyone have any idea what the heck is going on here? https://github.com/wesnoth/wesnoth/commit/2111f7d36a07320a86bba3582984129dee587074#diff-4c2a342c15a3df89e60ad73d7d3a8ba7R802
20160827 21:40:53< celmin> Maybe mattsc would have an idea, since it's AI.
20160827 21:41:05< celmin> Mainly I want to know why there are two attack vectors.
20160827 21:42:08< celmin> And would anyone even notice if I silently broke that function? Since FormulaAI isn't used much these days.
20160827 21:43:31< mattsc> Uh, no idea.
20160827 21:43:38< celmin> Ah, it's used in the FormulaAI recruitment, huh.
20160827 21:43:52< celmin> data/ai/formula/recruitment.fai
20160827 21:44:13< celmin> Waaait, no, that's max_possible_damage_with_retaliation, a different function.
20160827 21:44:19-!- Appleman1234 [~Appleman1@KD036012022172.au-net.ne.jp] has quit [Ping timeout: 244 seconds]
20160827 21:44:32< celmin> It is however used in data/ai/formula/opening.fai
20160827 21:44:45< celmin> Whatever that is.
20160827 21:45:04< celmin> That seems to be its sole use in mainline, and I have no idea if that script is even used anywhere.
20160827 21:45:54< celmin> Given the comment, it could probably be rewritten to use the unit_adapter, huh...
20160827 21:48:49< celmin> mattsc: Do the formulas on lines 822 and 832 of that diff look equivalent to you?
20160827 21:49:49< celmin> Kinda looks like they are, okay.
20160827 21:51:33< mattsc> celmin: they are not the same equations, if that’s what you mean
20160827 21:52:29< celmin> Yeah, but looks like damage_from and resistance_against essentially return the same thing (though the former has additional options).
20160827 21:52:41< mattsc> In general, it looks like one is an evaluation with a unit on the map, and the other one for a unit_type, generically speaking
20160827 21:52:46< celmin> Right.
20160827 21:53:30< mattsc> I see.
20160827 21:57:35< celmin> Wait, I thought min_range and max_range had been removed...
20160827 22:00:38-!- Kwandulin [~Miranda@p200300760F6F2F47ECE99BE6ACD8A009.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160827 22:01:48< celmin> I wonder if they actually work.
20160827 22:02:01< celmin> They're checked at src/actions/attack.cpp:132
20160827 22:02:12< celmin> Someone should test them sometime.
20160827 22:02:34< mattsc> celmin: opening.fai is used in the data/scenario-formula.cfg test scenario
20160827 22:03:55< mattsc> which, I guess, does not exist in 1.13 any more
20160827 22:04:06< celmin> It was moved to data/ai/scenarios
20160827 22:04:09< celmin> I think
20160827 22:04:20< mattsc> right, just found it using grep
20160827 22:15:57< celmin> BTW, did you get tad's warning too in TSG2?
20160827 22:16:06< celmin> I didn't get it.
20160827 22:16:36< celmin> Should I maybe try his branch?
20160827 22:19:10< mattsc> I haven’t gotten around to trying yet.  I didn’t know there was a question about that.
20160827 22:19:30< celmin> I'm talking about the invalid aspect warning from awhile ago.
20160827 22:20:05-!- Polsaker [~Polsaker@wikimedia/botters.Polsaker] has joined #wesnoth-dev
20160827 22:20:05< mattsc> right, that’s what I assumed
20160827 22:20:22< celmin> Oh.
20160827 22:21:47< mattsc> I never tested that; I was away at the time when tad posted this, and afterward I was under the impression that the two of you had it under control
20160827 22:21:59< mattsc> the process at least
20160827 22:22:21< celmin> I see.
20160827 22:22:35< celmin> I suppose I should talk to him about it next time he pops in.
20160827 22:24:02< mattsc> Let me know if there is anything I can help with.
20160827 22:36:10< celmin> Well, this builds, now to decide what to test to make sure I didn't break anything...
20160827 22:38:37< celmin> fabi: I recall someone saying that it was you who added min_range and max_range, is this true?
20160827 22:39:16< celmin> mattsc: By the way, do you have any objection to setting -fsanitize=address for debug builds in the XCode project?
20160827 22:39:52< celmin> http://clang.llvm.org/docs/AddressSanitizer.html#introduction
20160827 22:40:23< celmin> I want to ask ancestral too, but I keep missing him.
20160827 22:41:30-!- Appleman1234 [~Appleman1@KD036012021118.au-net.ne.jp] has joined #wesnoth-dev
20160827 22:45:33< mattsc> celmin: I don’t know enough about it to know whether I should have objections.  So, no, no objections.
20160827 22:48:45< celmin> Theoretically it should make it easier to detect invalid memory accesses, at the cost of slower runtime.
20160827 22:49:25-!- jswensen [~jswensen@cpe-98-145-147-33.natnow.res.rr.com] has quit [Quit: jswensen]
20160827 22:49:58-!- jswensen [~jswensen@cpe-98-145-147-33.natnow.res.rr.com] has joined #wesnoth-dev
20160827 22:51:37< mattsc> runtime of the application or of the debugger?
20160827 22:51:45< celmin> The application.
20160827 22:51:58< mattsc> so Wesnoth will be twice as slow suddenly?
20160827 22:52:40< celmin> Probably.
20160827 22:53:04< mattsc> Hmm
20160827 22:53:12< celmin> I haven't noticed any difference the times I tried it, but I didn't really try hard to compare.
20160827 22:53:29< mattsc> I guess I could always turn it off if it’s a problem for my AI testing
20160827 22:54:18< celmin> True… though that means a perpetually edited XCode file, which would be a pain on my end at least (maybe newer XCodes have fixed that).
20160827 22:54:40< celmin> (If an external program modifies the XCode project, XCode collapses all groups in all tabs.)
20160827 22:55:11< mattsc> Yeah, I’ll have to see.
20160827 22:55:23< mattsc> Anyway, go ahead and I’ll see if it’s a problem when we get to it.
20160827 22:55:56< celmin> Or you could add it yourself and try it (it goes in Other C/C++ Flags). I'd also like to hear if ancestral has an opinion before doing it.
20160827 22:56:44< mattsc> I won’t get around to doing that for a while, so don’t wait for me.
20160827 22:57:04< mattsc> And right now I’ll be afk for quite a while again; TTYL.
20160827 23:27:55-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160827 23:31:01< celmin> Unexpectedly found a use for const_clone.
20160827 23:31:10-!- Shiki [~Shiki@141.39.226.227] has quit [Quit: Verlassend]
20160827 23:31:15< celmin> Though I wish it was actually called that, rather than utils::tconst_clone.
20160827 23:44:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160827 23:49:29-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20160827 23:50:33-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
--- Log closed Sun Aug 28 00:00:25 2016