--- Log opened Wed Jun 21 00:00:08 2017
20170621 00:15:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170621 00:16:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 00:20:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170621 02:02:12-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170621 02:02:18-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170621 02:21:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170621 02:34:17-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Quit: nurupo]
20170621 02:35:48-!- TC02 [~quassel@london.acm.jhu.edu] has joined #wesnoth-dev
20170621 02:49:09-!- Bonobo [~Bonobo@220-244-64-153.tpgi.com.au] has joined #wesnoth-dev
20170621 03:05:01-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170621 03:05:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170621 03:05:26-!- Ivanovic [~ivanovic@p4FC534A6.dip0.t-ipconnect.de] has quit [Changing host]
20170621 03:05:27-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20170621 03:16:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 03:21:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20170621 03:50:58-!- JyrkiVesterinen [~JyrkiVest@87-100-214-236.bb.dnainternet.fi] has joined #wesnoth-dev
20170621 03:53:47-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20170621 03:54:07-!- Kwandulin [~Kwandulin@p200300760F7CBA30C4797971C4E8C8A4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170621 04:06:11-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20170621 04:31:01-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has quit [Ping timeout: 240 seconds]
20170621 04:32:28-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20170621 04:41:12-!- Kwandulin [~Kwandulin@p200300760F7CBA30C4797971C4E8C8A4.dip0.t-ipconnect.de] has quit [Quit: [endlevel]]
20170621 04:45:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 04:50:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds]
20170621 05:01:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 05:06:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds]
20170621 05:40:00-!- Appleman1234 [~quassel@z190230.ppp.asahi-net.or.jp] has quit [Ping timeout: 255 seconds]
20170621 05:55:55-!- JyrkiVesterinen [~JyrkiVest@87-100-214-236.bb.dnainternet.fi] has quit [Quit: .]
20170621 06:06:17-!- mjs-de [~mjs-de@x4db69b26.dyn.telefonica.de] has joined #wesnoth-dev
20170621 06:19:02-!- irker738 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170621 06:19:02< irker738> wesnoth: Charles Dang wesnoth:accelerated_rendering 6fb518e033ac / src/sdl/ (render_utils.hpp texture.cpp): Added some inline wrappers for SDL_SetTexture* functions https://github.com/wesnoth/wesnoth/commit/6fb518e033acb464bc84ab9cd433ba163c522ba9
20170621 06:19:02< irker738> wesnoth: Charles Dang wesnoth:accelerated_rendering d0e21edee387 / src/ (display.cpp game_display.cpp halo.cpp halo.hpp): Refactored halo code to bring it in line with new drawing methods https://github.com/wesnoth/wesnoth/commit/d0e21edee38772458b940a74880000a6e3d81ca7
20170621 06:19:03< irker738> wesnoth: Charles Dang wesnoth:accelerated_rendering 37910ef3b7fd / src/units/ (animation.cpp animation_component.cpp drawer.cpp frame.cpp): Use shared_ptr::reset for clearing halo handlers https://github.com/wesnoth/wesnoth/commit/37910ef3b7fd6b79bb0884ec850e32b27f025bd7
20170621 06:19:05< irker738> wesnoth: Charles Dang wesnoth:accelerated_rendering 30f4ec11c277 / src/units/frame.cpp: Restored alpha handling of unit frames https://github.com/wesnoth/wesnoth/commit/30f4ec11c2770e22620d8697a837ed0442b67ce5
20170621 06:19:29-!- markus_ [~mjs-de@x4db5ff9b.dyn.telefonica.de] has joined #wesnoth-dev
20170621 06:19:38-!- markus_ [~mjs-de@x4db5ff9b.dyn.telefonica.de] has quit [Remote host closed the connection]
20170621 06:22:43-!- mjs-de [~mjs-de@x4db69b26.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
20170621 06:42:26-!- JyrkiVesterinen [~JyrkiVest@85-76-75-184-nat.elisa-mobile.fi] has joined #wesnoth-dev
20170621 06:59:57< JyrkiVesterinen> Heads up: I'm moving. I'll be extremely busy in real life for a couple of weeks, and I won't be contributing to Wesnoth during that time.
20170621 07:01:51-!- atarocch [~atarocch@93.56.160.37] has joined #wesnoth-dev
20170621 07:02:45< vultraz_iOS> noted
20170621 07:05:09-!- vn971 [~vasya@0896414046.static.corbina.ru] has joined #wesnoth-dev
20170621 07:06:28< vn971> Hmm, I wonder. Is the help manual correct for "Age of Heroes" Era? Visiting any Faction inside an era will only show lvl2 leaders and lvl1 recruits, whereas in reality it should be lvl3 leaders etc.
20170621 07:06:52< vn971> in 1.13.8
20170621 07:36:09-!- travis-ci [~travis-ci@ec2-54-157-75-93.compute-1.amazonaws.com] has joined #wesnoth-dev
20170621 07:36:10< travis-ci> wesnoth/wesnoth#14310 (accelerated_rendering - 30f4ec1 : Charles Dang): The build has errored.
20170621 07:36:10< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/245235215
20170621 07:36:10-!- travis-ci [~travis-ci@ec2-54-157-75-93.compute-1.amazonaws.com] has left #wesnoth-dev []
20170621 07:59:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 08:03:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170621 08:08:02-!- Kwandulin [~Kwandulin@p200300760F7CBA3128BC822D98897357.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170621 08:21:51-!- JyrkiVesterinen [~JyrkiVest@85-76-75-184-nat.elisa-mobile.fi] has quit [Quit: JyrkiVesterinen]
20170621 08:26:00-!- Duthlet [~Duthlet@dslb-178-012-099-028.178.012.pools.vodafone-ip.de] has joined #wesnoth-dev
20170621 08:27:46-!- JyrkiVesterinen [~JyrkiVest@85-76-75-184-nat.elisa-mobile.fi] has joined #wesnoth-dev
20170621 08:48:35-!- atarocch [~atarocch@93.56.160.37] has quit [Ping timeout: 240 seconds]
20170621 08:51:37-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170621 08:52:42-!- atarocch [~atarocch@93.56.160.37] has joined #wesnoth-dev
20170621 08:53:24-!- JyrkiVesterinen [~JyrkiVest@85-76-75-184-nat.elisa-mobile.fi] has quit [Quit: .]
20170621 08:57:37-!- Kwandulin [~Kwandulin@p200300760F7CBA3128BC822D98897357.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170621 09:00:29< zookeeper> vn971, of course, it's incorrect. probably because the default era and age of heroes factions have the same id's.
20170621 09:00:35 * zookeeper tries changing them
20170621 09:01:58< zookeeper> yes, that's it
20170621 09:03:19< zookeeper> i think that if i just add an AoH_ prefix to the AoH faction id's, it won't break anything in mainline, except hornshark island which needs to be adapted somehow.
20170621 09:19:35-!- irker738 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170621 09:20:55< zookeeper> actually, seeing how non-unique faction id's seem to be very common, it might be good to just internally add an era prefix to all the faction topic pages, and from the looks of it that would be very simple to do. sadly, as long as i can't compile i can't test it myself.
20170621 09:25:08< Ravana_> I guess I could play a bit with replace all to make my faction ids unique.. But then, what will happen when [multiplayer_side]choices= includes id not in surrounding [era]? If that breaks something then it is better to just not use faction help.. u.w.o already exists
20170621 09:34:15-!- JyrkiVesterinen [~JyrkiVest@85-76-75-184-nat.elisa-mobile.fi] has joined #wesnoth-dev
20170621 09:39:25-!- Duthlet [~Duthlet@dslb-178-012-099-028.178.012.pools.vodafone-ip.de] has quit [Ping timeout: 246 seconds]
20170621 09:47:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 09:52:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds]
20170621 10:46:42-!- Duthlet [~Duthlet@dslb-178-012-099-028.178.012.pools.vodafone-ip.de] has joined #wesnoth-dev
20170621 10:59:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170621 11:15:33-!- timotei__ [~timotei@wesnoth/developer/timotei] has quit [Read error: Connection reset by peer]
20170621 11:28:16-!- irker743 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170621 11:28:16< irker743> wesnoth: loonycyborg wesnoth:bcrypt_auth 7cf96cef5d27 / / (18 files in 5 dirs): Implemented support for forum auth using bcrypt as per #1761 https://github.com/wesnoth/wesnoth/commit/7cf96cef5d27f53b718825a184dae013212c10da
20170621 11:29:20< zookeeper> durr, now what's this:
20170621 11:29:23< zookeeper> utils.obj : error LNK2005: "class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl operator<<(class std::basic_ostream<char,struct std::char_traits<char> > &,struct SDL_Rect const &)" (??6@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@AAV01@ABUSDL_Rect@@@Z) already defined in rect.obj
20170621 11:32:16< zookeeper> oh, a local change. duh.
20170621 11:32:19< zookeeper> nevermind.
20170621 11:32:22< JyrkiVesterinen> Likely related to this, which moved the definition from utils.cpp to rect.cpp: https://github.com/wesnoth/wesnoth/commit/1a2561721a1d485504a9dedfd40c5e2ce485c955
20170621 11:34:26< zookeeper> build succeeded \o/
20170621 11:34:41< JyrkiVesterinen> Good. :)
20170621 11:35:37< zookeeper> i'm sure it'll break again as soon as someone does anything dependency-wise, but at least i have a narrow window to try to get a few things done :>
20170621 11:36:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 11:36:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170621 11:37:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170621 11:39:50-!- timotei_ [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20170621 11:40:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20170621 12:08:36-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170621 12:21:22-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20170621 12:33:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170621 12:33:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170621 12:36:34-!- travis-ci [~travis-ci@ec2-54-161-143-176.compute-1.amazonaws.com] has joined #wesnoth-dev
20170621 12:36:35< travis-ci> wesnoth/wesnoth#14312 (bcrypt_auth - 7cf96ce : loonycyborg): The build passed.
20170621 12:36:35< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/245325412
20170621 12:36:35-!- travis-ci [~travis-ci@ec2-54-161-143-176.compute-1.amazonaws.com] has left #wesnoth-dev []
20170621 13:13:40< vn971> BTW, I see strange behavior, probably a bug. The situation is as follows:
20170621 13:13:40< vn971> At the start of my turn, my unit stands to a "hidden" wose. Because I have a unit nearby, the wose is visible. I step aside (away from the tree) and back. Now, should the unit be "ambushed"?
20170621 13:14:01< vn971> * my unit stands near to
20170621 13:15:00< vn971> wesnoth-1.13.8 says the unit will be ambushed (as well as any other units that steps near the tree), however, it is very counter-intuitive. What kind of ambush is that if you even see the tree on the map?
20170621 13:15:24< zookeeper> uh, no you shouldn't get ambushed unless the ambusher is hidden.
20170621 13:15:34< vn971> zookeeper: a bug, then.
20170621 13:15:45< zookeeper> also "near" and "nearby" are uselessly vague
20170621 13:15:58< zookeeper> if it's not "next to" or "adjacent" then it's irrelevant
20170621 13:16:22< vn971> zookeeper: the ambusher has no units adjacent, which is what probably causes the bug.
20170621 13:16:57< vn971> zookeeper: so there is some logic in the current behavior, but if anything, I'd vote for a change.
20170621 13:17:08< zookeeper> how is the ambusher visible if it has no units adjacent? did it kill the unit which it ambushed?
20170621 13:17:22< vn971> zookeeper: yeah, I forgot the more precise wording "adjacent".
20170621 13:17:50< vn971> zookeeper: it's visible since the start of the turn, with my unit nearby.
20170621 13:18:21< zookeeper> oh, right. and when you moved that unit away, the wose stayed visible, but moving next to it still acts as an ambush?
20170621 13:18:44< vn971> zookeeper: right, exactly so.
20170621 13:19:48-!- gfgtdf [~chatzilla@x4e363d94.dyn.telefonica.de] has joined #wesnoth-dev
20170621 13:19:48< zookeeper> i see. yeah, sounds like a bug. i'd be inclined to say that it's correct for the wose to remain visible, and it's just the ambushing part that gets handled wrong.
20170621 13:20:35< gfgtdf> i wonder:; if you save & load the game after you stapped one hex away form the wose, is the wose still visible ?
20170621 13:22:02< vn971> gfgtdf: ha, the wose disappeared after I clicked _save_.:)
20170621 13:22:26< vn971> (not even "load")
20170621 13:22:35< zookeeper> nice
20170621 13:23:45< vn971> wait, that's a strange graphics bug. It disappears even when I move my cursor to the wose..
20170621 13:24:33< vn971> actually, I guess the current rules are meant to function as "wose should disappear", but graphics may get a bit buggy.
20170621 13:24:43< gfgtdf> then is not  bug in the move code, it's eigher an ui issue (the wose hex is no invalidated or soemthing) or we shoudl add somehitn like 'add state uncovered to all visible hidden unit at tunr start' 
20170621 13:25:34< vn971> Any re-rendering makes the wose disappear. However, I can easily manage to move a unit away from the tree, move the same unit or another one "back" to touch the tree, and that unit gets ambushed, even if it's skirmisher etc.
20170621 13:26:07< zookeeper> yeah, sounds like a redraw issue. other than that, the http://wiki.wesnoth.org/SingleUnitWML#Unit_State uncovered status should determine whether the ambusher is visible or not, and thus should stay consistent across save/load.
20170621 13:26:33< zookeeper> skirmisher doesn't affect ambush
20170621 13:26:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170621 13:27:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170621 13:27:42< vn971> zookeeper: yes, "skirmisher"-s just a test to differentiate between "ambush" / "standing adjacent to a lvl1+ unit".
20170621 13:27:52-!- JyrkiVesterinen [~JyrkiVest@85-76-75-184-nat.elisa-mobile.fi] has quit [Quit: Going home]
20170621 13:30:09< vn971> Would it make sense to open a question of changing "Ambushing" rules?
20170621 13:30:09< vn971> Current rules seem to be consistent (it's only a graphics bug that's being observed), but still, "ambushing" at first seeing a unit seems more natural.
20170621 13:31:05< vn971> Also, disappearance of a wose seems unnatural, because you actually know for sure your enemy is still in the place where you left it at turn start. (Presuming no ugly add-ons. But I think you know what I mean.)
20170621 13:31:38< zookeeper> yeah, i don't think ambushers should be able to disappear during anyone else's turn.
20170621 13:59:24< Soliton> someone could check 1.12 to see if it's just a regression.
20170621 14:02:48< vn971> wow cool, caught wesnoth crash. Never had any before, not even once, I think. Console says:
20170621 14:02:48< vn971> wesnoth: src/attack_prediction.cpp:1734: double {anonymous}::calculate_probability_of_debuff(double, bool, double, double, bool, double): Assertion `prob_kill >= 0.0 && prob_kill <= 1.0' failed.
20170621 14:03:09< vn971> somewhere during AI turn.
20170621 14:06:26< Soliton> had some funky units around?
20170621 14:07:53< vn971> Soliton: depends on the term funky, but yes. I have "WeaponStealingMode" add-on installed and enabled, as well as my plugin that gives units abilities. But nothing other than that.
20170621 14:08:11< vn971> Soliton: no units with negative health, or more than maximum health etc.
20170621 14:12:27< vn971> Soliton: I opened wesnoth-1.12, and the enemy Wose was still visible even after it killed my unit at the end of _his_ (woses) turn. So, it remained visible even though the turn ended, my turn began. (Actually, after the kill the wose even went to fog. But was visible back when I created a new unit in a couple of hexes from it.)
20170621 14:13:24< Soliton> sounds good. so a regression in 1.13.
20170621 14:13:59< vn971> Soliton: so, unless I can up with some another test, it's a regression. Will repeat my last test exactly, without any changes, on 1.13 to confirm.
20170621 14:14:26-!- gfgtdf_ [~chatzilla@x4e363d94.dyn.telefonica.de] has joined #wesnoth-dev
20170621 14:17:39-!- gfgtdf [~chatzilla@x4e363d94.dyn.telefonica.de] has quit [Ping timeout: 276 seconds]
20170621 14:17:50-!- gfgtdf_ is now known as gfgtdf
20170621 14:20:25< vn971> Soliton: not reproducible as a regression, the tree still remains visible in a new game created from scratch in 1.13.
20170621 14:20:41< vn971> that's hellish, I have to do more tests...
20170621 14:21:05< Soliton> looks like you have a hand for creating weird gamestates.
20170621 14:21:37< vn971> Soliton: I like playing with the rules more than just playing, that's true...)
20170621 14:22:13< Soliton> would be helpful if that assert mentioned what value prob_kill had... but the attack prediction math is there since a while odd that a bug only surfaces now.
20170621 14:22:58< Soliton> well, it might be connected to the monte carlo part which is new.
20170621 14:23:44< Soliton> did you have units with lots of HP around?
20170621 14:24:08< Soliton> 1000+ is lots, i think.
20170621 14:24:08< vn971> Soliton: no more than 100 (unmodified Fire Drake).
20170621 14:24:34< Soliton> ok, also berserkers?
20170621 14:24:44< Soliton> and slow?
20170621 14:30:59-!- irker743 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170621 14:32:04< vn971> Soliton: it was AI turn, I don't know for sure _where_ the bug was. But at the time of failure, there were both berserkers and slow-capable units on the battle field.
20170621 14:33:51< Soliton> with berserk and slow maybe even 100HP is already a lot, not sure.
20170621 14:37:22< vn971> Soliton: berserks and slows are away from the Fire Drake. Anything with slow and berserk is only about 70 or so, I guess.
20170621 14:40:39< Soliton> well, report it. ideally with steps or a savefile to reproduce.
20170621 14:43:50< vn971> Soliton: managed to reproduce. There's no replay though (because it crashed), and it's not very stable. But it crashed again after I did 5 reloads. Will try to document it on github meanwhile.
20170621 14:49:26< vn971> ok, done https://github.com/wesnoth/wesnoth/issues/1808
20170621 14:49:46< vn971> (  the savegame itself https://pointsgame.net/vn971/temp/2017.06.21_17:47:12_f5d47a0.bz2  )
20170621 14:52:47-!- gfgtdf [~chatzilla@x4e363d94.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
20170621 15:10:51-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170621 15:46:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 15:48:29-!- horrowind [~Thunderbi@p2003008E6C0B2659964452FFFE0220ED.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170621 15:58:38-!- JyrkiVesterinen [~JyrkiVest@87-92-22-234.bb.dnainternet.fi] has joined #wesnoth-dev
20170621 16:04:10< JyrkiVesterinen> Regarding the crash in calculate_probability_of_debuff(): I added that function only two weeks ago, to address https://github.com/wesnoth/wesnoth/issues/1764
20170621 16:04:39< JyrkiVesterinen> I'll investigate it as soon as possible.
20170621 16:31:13< zookeeper> weren't you supposed to be out for a few weeks? :p
20170621 16:31:40< JyrkiVesterinen> Well, I'm not completely unable to do stuff for Wesnoth.
20170621 16:32:07< JyrkiVesterinen> It's just that all the time I spend developing Wesnoth will be subtracted from my spare time and make me even busier otherwise...
20170621 16:32:29< JyrkiVesterinen> But anyway, I really don't want to just ignore regressions I have caused.
20170621 16:32:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170621 16:33:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 16:33:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170621 16:34:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 16:34:21-!- Bonobo [~Bonobo@220-244-64-153.tpgi.com.au] has quit [Ping timeout: 268 seconds]
20170621 16:39:00-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170621 16:39:41< vn971> Another interesting thing about wesnoth preferences. When I change them, they aren't actually written anywhere. So if I crash the game, all settings return to their previous value.
20170621 16:40:14< vn971> I guess clicking "Close" button on preferences window should write changes down. Dunno if it's worth a feature request..
20170621 16:40:22< JyrkiVesterinen> Yes, I have noticed the same thing.
20170621 16:40:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 16:41:05< JyrkiVesterinen> It's quite annoying in development, especially if I just close the game with "Stop Debugging" after a debugging session (which simply kills the process).
20170621 16:41:34< vn971> So it is worth a feature request, I guess. OK, will write one.)
20170621 16:41:52< vn971> JyrkiVesterinen: don't forget to rest and/or do what you want though :D
20170621 16:42:15< JyrkiVesterinen> I *only* prioritize regressions which are my fault. Nothing else.
20170621 16:42:29< JyrkiVesterinen> (But why did you have to find one now... :x )
20170621 16:49:11-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170621 16:49:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20170621 16:51:46-!- stikonas_ is now known as stikonas
20170621 16:55:31< zookeeper> i thought the preferences thing was a bug, not intended-but-mistaken behaviour
20170621 16:57:12< JyrkiVesterinen> I can't see how it could possibly be a bug.
20170621 16:57:19-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170621 16:59:18< zookeeper> well, it doesn't seem to be how 1.12 works, so can at least be called a regression then :p
20170621 16:59:26-!- atarocch [~atarocch@93.56.160.37] has quit [Read error: Connection reset by peer]
20170621 17:00:02< vn971> issue for "settings": https://github.com/wesnoth/wesnoth/issues/1809
20170621 17:00:40< vn971> zookeeper: if that is the case, I can remove the "feature request" words.
20170621 17:02:08< zookeeper> yeah, 1.12 saves them when closing preferences
20170621 17:02:37< zookeeper> i always assumed it was just a bug with the new preferences because it's so obviously the wrong behaviour
20170621 17:05:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20170621 17:07:14< vn971> hm, btw, the other thing I wrote about also works in 1.12!
20170621 17:07:53< vn971> Settings are applied instantly. The sound disappears immediately as you disable it in settings. (Or re-appears if you enable sound.)
20170621 17:08:59< vn971> in wesnoth-1.13, clicking sound settings has no effect on the sound. It's only when you click "Close" button on the bottom-right that they are applied. It's especially counter-intuitive since there is on "Apply" button, so people would assume changes are applied instantly.
20170621 17:09:21< vn971> *since there is no
20170621 17:15:39< vn971> JyrkiVesterinen: this may be of some interest to you. In the last savegame I posted, there's actually a _different_ failed assertion.
20170621 17:15:41< vn971> wesnoth: src/attack_prediction.cpp:1627: static void {anonymous}::monte_carlo_combat_matrix::scale_probabilities(const std::vector<double>&, std::vector<double>&, double, unsigned int): Assertion `std::abs(std::accumulate(target.begin(), target.end(), 0.0) - 1.0) < 0.001' failed.
20170621 17:15:46< vn971> this one ^
20170621 17:16:05< vn971> I noticed this only now, presuming it is the old one. But it's not.
20170621 17:16:11< JyrkiVesterinen> In that case, I think it's a different bug.
20170621 17:16:42< JyrkiVesterinen> Either way, since I'm the author of the Monte Carlo simulation mode, that bug is also my fault.
20170621 17:16:56< vn971> :(
20170621 17:17:18< vn971> well, I may have made some strange things in add-ons too. Dunno. I'll post the new issue.
20170621 17:20:35< vn971> JyrkiVesterinen: I'm also not sure it'll help, but I see strange behavior of units, one which I didn't see before: some enemy AI units go close to your unit, and then just stop. As if they thought they will attack, but by the time they touch my unit, they consider against that.
20170621 17:21:07< vn971> JyrkiVesterinen: then again I don't have considerable wesnoth experience so I may mistaken. I mean, maybe it's normal for the AI.
20170621 17:21:49-!- tomreyn_ is now known as tomreyn
20170621 17:22:41< vn971> JyrkiVesterinen: but it's definitely a silly tactic. If you wanted to attack, do it. If not, better stay at a defended terrain than move to a bad terrain and then just stop.
20170621 17:23:21< JyrkiVesterinen> I maintain only damage prediction, not AI.
20170621 17:24:01< JyrkiVesterinen> Granted, incorrect predictions would completely screw up the AI, but they would also be visible in the weapon selection screen.
20170621 17:24:04< vn971> JyrkiVesterinen: it maybe a symptom that could help understanding the problem.
20170621 17:24:43< JyrkiVesterinen> (Unless it's something specific to the "predict multiple battles for one unit" case, which is accessible to the AI but not to the player.)
20170621 17:25:16< vn971> JyrkiVesterinen: presumably not a lot of people play on master branch compiled between 2 and 0 weeks ago. So maybe there's a huge error lying around waiting to be found.) OK I'm speculating. Just wrote in case it can help.
20170621 17:27:04< vn971> good news is, I can't get past turn 43 on my game so I'll stop sending more bug reports for now.:DDD
20170621 17:28:47-!- Greg-Boggs [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has joined #wesnoth-dev
20170621 17:31:54< vn971> the turn that I can't finish (assertion failed): https://github.com/wesnoth/wesnoth/issues/1810
20170621 17:32:14< vn971> reproduces ~100% of the time.
20170621 17:50:03-!- Greg-Boggs [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170621 17:50:12-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170621 17:50:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170621 17:57:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 18:01:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170621 18:06:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 18:07:45-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 18:07:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20170621 18:30:36-!- atarocch [~atarocch@93.56.160.37] has joined #wesnoth-dev
20170621 18:31:29-!- gfgtdf [~chatzilla@x4e363d94.dyn.telefonica.de] has joined #wesnoth-dev
20170621 18:34:54-!- irker272 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170621 18:34:54< irker272> wesnoth: ln-zookeeper wesnoth:master 01b4a162f087 / src/help/help_impl.cpp: Fixed help topics not working right when multiple factions share an id https://github.com/wesnoth/wesnoth/commit/01b4a162f087301c75d82698498a4e70c3344411
20170621 18:35:23< zookeeper> that should fix the faction topic bug
20170621 18:42:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170621 18:43:06< gfgtdf> zookeeper: hy'd you put era_prefix  in front ? 
20170621 18:43:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170621 18:43:57< gfgtdf> i'd expect   const std::string ref_id = faction_prefix  + era["id"] + "_" + id;
20170621 18:44:07< zookeeper> because era_Default_Era_faction_Drakes seems more logical than faction_Drakes_era_Default_Era
20170621 18:44:35< gfgtdf> zookeeper: no there shodul be no 'era' att all sicne that topic dopesnt descibe am era
20170621 18:44:41< gfgtdf> an*
20170621 18:45:13< zookeeper> i don't see the logic in that.
20170621 18:45:21< gfgtdf> also it's now possible to have have factiosn and era topics with the same id (if yourr era has really weird name)
20170621 18:47:13-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20170621 18:49:45< zookeeper> but if you think faction_era_default_Drakes is better than era_era_default_faction_Drakes then sure. doesn't really matter to me, as long as it disambiguates between identical faction id's of different eras.
20170621 18:54:13< gfgtdf> zookeeper: well if you got an era named 'era_default_faction_Drakes' then it'll have te same helptopic id as the faction. :p
20170621 18:54:49< zookeeper> no, the faction would then be era_era_default_faction_Drakes_faction_Drakes?
20170621 18:55:34< zookeeper> the faction topic id, that is
20170621 18:55:50< gfgtdf> zookeeper: the addon era id woudl be the same as the mainline faction eras id.
20170621 18:56:02< zookeeper> ah yes, sure
20170621 18:56:02< gfgtdf> mainline faction help id.
20170621 18:58:44< Ravana_> that would be solved by using symbol that is invalid in era id
20170621 18:58:51< irker272> wesnoth: gfgtdf wesnoth:master 0f44669e5958 / src/help/help_impl.cpp: improve faction help ids https://github.com/wesnoth/wesnoth/commit/0f44669e59589c06964a4e88152ddd8f0e4a6d3f
20170621 19:43:18-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170621 20:19:06< vn971> BTW, I wonder what part of wesnoth is written in java. Github statistics says it takes 13% of all code.
20170621 20:19:52< JyrkiVesterinen> We have almost no Java code in the repository. Certainly not 13 percent.
20170621 20:20:08< JyrkiVesterinen> It's definitely GitHub detecting the language incorrectly.
20170621 20:20:25< JyrkiVesterinen> My guess is that GitHub thinks that WML files are Java config files.
20170621 20:21:39< vn971> JyrkiVesterinen: OK, thanks.
20170621 20:24:13< gfgtdf> JyrkiVesterinen, vn971:did you test locally that we don't ahev that much java code in wesnoth 
20170621 20:24:20< gfgtdf> ?
20170621 20:24:46< JyrkiVesterinen> No.
20170621 20:24:49< vn971> gfgtdf: not actually
20170621 20:25:04< JyrkiVesterinen> But, you know, we'd know if we had tens of thousands of lines of Java code somewhere.
20170621 20:25:54< zookeeper> WML would surely be >13%, so it's probably something else
20170621 20:26:40< irker272> wesnoth: Charles Dang wesnoth:accelerated_rendering 5657a67df0ad / src/gui/ (6 files in 3 dirs): GUI2/Window: removed empty undraw() function https://github.com/wesnoth/wesnoth/commit/5657a67df0ade4657c08a2bf54f15fa1e28f2ad2
20170621 20:26:43< irker272> wesnoth: Charles Dang wesnoth:accelerated_rendering 3d23a6d206e3 / src/ (gui/core/canvas.cpp image.cpp image.hpp sdl/render_utils.hpp sdl/window.cpp): Split texture caches into linear and NN scaled versions https://github.com/wesnoth/wesnoth/commit/3d23a6d206e3639b169b8d39fa1ddffa883e75a1
20170621 20:26:59< gfgtdf> JyrkiVesterinen: doesn't seem leik it.
20170621 20:27:14< vultraz_iOS> well there's the umc_dev plugin
20170621 20:27:45< JyrkiVesterinen> GitHub's stats say that C++ is 67 %, Python is 8,1 %, there are few languages with a couple of percents, and "Other" (including undetected, I guess) is 3,9 %.
20170621 20:28:14< JyrkiVesterinen> IMHO, WML being 13 % sounds believable.
20170621 20:28:23< gfgtdf> i dont think other includes untetected (wml)
20170621 20:28:48< zookeeper> where do you even see those stats?
20170621 20:29:09< gfgtdf> umc_dev can easily be easily >50k lines of java code
20170621 20:29:19< JyrkiVesterinen> In https://github.com/wesnoth/wesnoth press the purple line below "69,200 commits".
20170621 20:30:19< zookeeper> "press the purple line" well of course, i wonder how that didn't occur to me, it's so obvious after all -.- 
20170621 20:30:38< JyrkiVesterinen> Indeed. It's pretty bad UI design.
20170621 20:30:52< zookeeper> i just thought it was a hipsterish decoration
20170621 20:31:18< gfgtdf> JyrkiVesterinen: jou canmjust lcik on 'java and it will earh for java code'
20170621 20:31:21< zookeeper> but you can then click on the languages to see files which it thinks are of thos... yeah
20170621 20:31:24< gfgtdf> click*
20170621 20:31:36< JyrkiVesterinen> Right. I hadn't noticed that.
20170621 20:31:38< zookeeper> so umc_dev indeed
20170621 20:31:51< vn971> Counted. *.java files are 112046 lines of code, 327824 words and 3941986 letters.
20170621 20:31:53< JyrkiVesterinen> And that page shows that GitHub thinks that WML is INI files.
20170621 20:32:10< JyrkiVesterinen> Which aren't counted in the top-level statistics.
20170621 20:32:19< vn971> 458Kbytes gzipped.
20170621 20:33:50< gfgtdf> hmm this seems to allow filtering issues by language ...
20170621 20:34:07< gfgtdf> doesn't seem to do anythign though
20170621 20:37:26< JyrkiVesterinen> vn971: I think I have figured out bug #1810.
20170621 20:37:27< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/0f44669e59589c06964a4e88152ddd8f0e4a6d3f/src/attack_prediction.cpp#L2045
20170621 20:37:50< JyrkiVesterinen> The calculation for the probability that unit is hit is incorrect if slow is involved.
20170621 20:38:21< JyrkiVesterinen> If unit B is slowed, it deals significantly less damage. Thus, it's more likely that unit A is alive.
20170621 20:38:42< JyrkiVesterinen> The calculation on that line doesn't take it into account.
20170621 20:38:48< vn971> If anyone's interested, *.cpp files have 492K lines of code, 3245Kbytes gzipped.
20170621 20:40:11< JyrkiVesterinen> Monte Carlo mode can't deal with conflicting data (the reported slow probability is different from what the HP distribution gives). Thus, it ends up asserting and crashing the game.
20170621 20:41:10< JyrkiVesterinen> As a fix, I'll need to implement a correct method for calculating the "not hit" probability.
20170621 20:41:25< vn971> JyrkiVesterinen: cool! Does it affect (explain) both bugs I've raised?
20170621 20:41:35< JyrkiVesterinen> I plan to retain the existing code for the no-slow case though, as it's faster.
20170621 20:42:03< JyrkiVesterinen> It might explain bug 1808, but I don't think so.
20170621 20:42:12< JyrkiVesterinen> I'll need to investigate it separately later.
20170621 20:42:34< vn971> JyrkiVesterinen: I don't really know CPP to help though. (Though if I don't have to allocate/deallocate memory and deal with concurrency, I could help.)
20170621 20:43:16< JyrkiVesterinen> To be honest, the more difficult part in damage prediction code is that it involves quite complex mathematics.
20170621 20:43:44< JyrkiVesterinen> Seriously, I'm at my limits of how difficult math I can handle.
20170621 20:43:52< vn971> That one I even like:) Maybe I'll touch this tomorrow.
20170621 20:44:04< JyrkiVesterinen> (And I think none of the other programmers here would even be able to maintain this code.)
20170621 20:44:49< vn971> "hit me hard", that's how I like with math formulas in games, where necessary.)
20170621 20:54:22< zookeeper> vultraz_iOS, are you sure you'll remember to fix the NR bug?
20170621 20:54:37< vultraz_iOS> eventually
20170621 20:59:10< zookeeper> okay, but maybe at least post some kind of acknowledgement there, the guy's been waiting for weeks
20170621 20:59:14-!- grzywacz [~karol@163.172.154.146] has quit [Changing host]
20170621 20:59:14-!- grzywacz [~karol@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20170621 21:04:56-!- gfgtdf [~chatzilla@x4e363d94.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 54.0/20170608105825]]
20170621 21:18:20-!- Appleman1234 [~quassel@z190230.ppp.asahi-net.or.jp] has joined #wesnoth-dev
20170621 21:19:15-!- atarocch [~atarocch@93.56.160.37] has quit [Remote host closed the connection]
20170621 21:24:45< irker272> wesnoth: Jyrki Vesterinen wesnoth:master edf750104348 / src/attack_prediction.cpp: Fix wrong calculation for chance to stay unscathed with a slowing unit https://github.com/wesnoth/wesnoth/commit/edf750104348841badea50c7d85cd23584d8b1a6
20170621 21:26:17-!- Bonobo [~Bonobo@220-244-64-153.tpgi.com.au] has joined #wesnoth-dev
20170621 21:28:09-!- JyrkiVesterinen [~JyrkiVest@87-92-22-234.bb.dnainternet.fi] has quit [Quit: .]
20170621 22:09:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 22:09:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170621 22:10:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 22:10:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170621 22:10:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 22:13:27-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20170621 22:15:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 255 seconds]
20170621 22:17:06-!- Greg-Boggs [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has joined #wesnoth-dev
20170621 22:35:38-!- Duthlet [~Duthlet@dslb-178-012-099-028.178.012.pools.vodafone-ip.de] has quit [Quit: leaving]
20170621 23:09:47-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170621 23:28:45-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has quit [Ping timeout: 255 seconds]
20170621 23:30:46-!- Greg-Boggs [~greg_bogg@c-73-37-6-51.hsd1.or.comcast.net] has quit [Remote host closed the connection]
20170621 23:31:18-!- Greg-Boggs [~greg_bogg@73.37.6.51] has joined #wesnoth-dev
20170621 23:31:29-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170621 23:32:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170621 23:36:00-!- Greg-Boggs [~greg_bogg@73.37.6.51] has quit [Ping timeout: 276 seconds]
20170621 23:44:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 23:46:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170621 23:46:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170621 23:54:40-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
--- Log closed Thu Jun 22 00:00:09 2017