--- Log opened Mon May 28 00:00:12 2018 20180528 00:00:48< Ravana_> https://github.com/wesnoth/wesnoth/commit/d41f4934d52f770143236fac7c761e3543c814a9 20180528 00:02:06< celticminstrel> Well, I have no idea why that was done, but that was 1.10, so... 20180528 00:02:21< mattsc> celticminstrel: we said that combining the check for moves and other filtering into one SUF is only useful if the check for moves is fast _and_ we can guarantee that it gets executed first. 20180528 00:02:31< Ravana_> 1.6 even 20180528 00:02:49< mattsc> So if I want to test that I can guarantee the order, I want a fast chec kfor moves filter, and a second one that takes much longer. 20180528 00:03:01< mattsc> It does not matter for that whether it checks for the same thing or not. 20180528 00:03:38< mattsc> and a second one = a second filter of some sort 20180528 00:03:53< celticminstrel> Still don't really get it, but I think either you or I must be misunderstanding something. 20180528 00:04:02< celticminstrel> What exactly were you proposing to do? 20180528 00:04:20< celticminstrel> Using both in the same filter, I mean, what would the resultant filter look like> 20180528 00:04:22< celticminstrel> ^? 20180528 00:04:41< mattsc> You proposed combining using ‘formula = moves > 0’ together with the rest of the filtering. 20180528 00:05:07< mattsc> All in one, not separating between simple (fast) and complex (slow) filters. 20180528 00:05:21< celticminstrel> Right, but you said combining formula-"moves>0" and formula="$this_unit.moves>0" in one filter. 20180528 00:05:49< mattsc> That’s only always fast if 1. that formula is fast’ and 2. it gets evaluated before the other filter. 20180528 00:06:00< mattsc> You also proposed using ‘[and]’ for that. 20180528 00:06:11< mattsc> I want to test that that actually works, doing some timing tests. 20180528 00:06:24< celticminstrel> Yeah. Basically [filter]moves=0 [and]rest of filter 20180528 00:06:35< mattsc> So I need a filter that is slow compared to ‘formula = moves > 0’. 20180528 00:06:40< celticminstrel> (Or substitute formula=moves>0 for moves=0.) 20180528 00:06:51< celticminstrel> Oh, I think I get what you mean... 20180528 00:06:54< mattsc> :) 20180528 00:07:06< mattsc> This is just for testing, not for the final product. 20180528 00:17:29< Ravana_> at least the only filter where I use $this_unit.side has other variables anyways, formula="$this_unit.side!=$units_with_freezing_aura[$i].side" 20180528 00:20:04< celticminstrel> Well, keep in mind that that would work even if you were comparing the side to a literal number. 20180528 00:20:17< celticminstrel> Because that compiles down to a formula of the form "5 = 3" or some such. 20180528 00:20:56< celticminstrel> And the WML .side has the correct value, only the WFL .side is offset by 1. 20180528 00:21:22< celticminstrel> ie formula="$this_unit.side = 1" works, formula="side = 1" does not, but formula="side = 0" will match side 1 units, I guess. 20180528 00:21:41< celticminstrel> Oh, I think I know why WFL offsets the side by 1 though... 20180528 00:21:50< celticminstrel> It's so that the side can be used as an array index. 20180528 00:23:55< Ravana_> as API change it won't go to 1.14 anyways, so there is time to announce that this behavior changes 20180528 00:31:10< celticminstrel> I mean there's merit to using it as an array index. 20180528 00:31:39< celticminstrel> But like you mentioned, it does mean comparing with a literal gives unexpected results. 20180528 00:42:14< irker141> wesnoth/wesnoth:master Pentarctagon 23ffa43f75 Add a couple missing things from the PR AppVeyor: All builds passed 20180528 01:03:02-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20180528 01:20:49-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has quit [Remote host closed the connection] 20180528 01:46:04-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180528 01:46:10-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180528 02:43:46<+discordbot1> @shadowm let's make the announcement public 20180528 02:50:15<+discordbot1> Okay. 20180528 02:52:48<+discordbot1> @Vultraz Topic id 48265 20180528 02:54:12< irker141> wesnoth: Charles Dang wesmere:master 66c536036802 / static/docroot/index.php: Updated frontpage links for 1.14.2 https://github.com/wesnoth/wesmere/commit/66c536036802d8fd6dcfb54f08d232c5ad986528 20180528 02:56:16<+discordbot1> got it, thanks 20180528 02:56:42<+discordbot1> ok, updated the frontpage... 20180528 02:56:43<+discordbot1> the wiki 20180528 02:56:48<+discordbot1> the announcement is out.. 20180528 02:56:52<+discordbot1> just twitter and discord 20180528 02:58:40<+discordbot1> twitter done 20180528 03:02:59< irker141> wesnoth: Iris Morelle website:master 4e86db9e381b / start/1.14/ (58 files in 2 dirs): announcement/1.14: pofix pass for 1.14.2 https://github.com/wesnoth/website/commit/4e86db9e381bb709ca43dd4b5ef4e959de71d287 20180528 03:03:24< irker141> wesnoth: Iris Morelle wesnoth:1.14 9c30032ab4ff / utils/pofix.py: pofix: Update with 1.14.1 -> 1.14.2 rules for the website https://github.com/wesnoth/wesnoth/commit/9c30032ab4fff63f2fac24bfcb5568f2d1f07d43 20180528 03:03:32< irker141> wesnoth: Iris Morelle wesnoth:master 0ca822795903 / utils/pofix.py: pofix: Update with 1.14.1 -> 1.14.2 rules for the website https://github.com/wesnoth/wesnoth/commit/0ca822795903e7f0ac93e410b7dde0b8012048fe 20180528 03:05:34<+discordbot1> https://cdn.discordapp.com/attachments/259976436490829825/450494816019808277/unknown.png 20180528 03:05:41<+discordbot1> those fancy buttons 😮 20180528 03:05:46<+discordbot1> you can do that on forum posts now? 20180528 03:06:39<+discordbot1> No. That's only for the release announcement. 20180528 03:06:52<+discordbot1> urgh okay 20180528 03:07:52<+discordbot1> now.... I guess I should add a Steam post 20180528 03:12:14<+discordbot1> steam is not cooperating 20180528 03:17:55<+discordbot1> bbcode is the worst 20180528 03:19:16<+discordbot1> 94% of 598 reviews on Seam are positive 20180528 03:19:48<+discordbot1> @ancestral looks like it stabilized 1% higher than you predicted 20180528 03:28:44-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180528 03:28:50-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180528 03:31:49<+discordbot1> curious what the 6% said 20180528 04:15:04< irker141> wesnoth: Charles Dang wesnoth:master c5ba6f01a824 / src/serialization/string_utils.cpp: Cleaned up utils::apply_modifier a bit https://github.com/wesnoth/wesnoth/commit/c5ba6f01a824d4ec633930ceb8f3dceef2f2d435 20180528 04:15:07< irker141> wesnoth: Charles Dang wesnoth:master ed8a8a48f701 / src/ (8 files in 7 dirs): Used std::string::front() and back() in more places https://github.com/wesnoth/wesnoth/commit/ed8a8a48f70174dae128afbdb07b1488b5a8d1d9 20180528 04:15:10< irker141> wesnoth: Charles Dang wesnoth:master 40d9b9953b85 / src/ (17 files in 5 dirs): Cleaned up some unused stuff from the display class https://github.com/wesnoth/wesnoth/commit/40d9b9953b8556b06462405da0a4fa564aa16e0b 20180528 04:16:37<+discordbot1> ed8a8a48f70174dae128afbdb07b1488b5a8d1d9... why. It's been suggested that the announcements on Steam could use some padding so they don't display weird on the game library, btw. 20180528 04:16:52<+discordbot1> https://cdn.discordapp.com/attachments/259976436490829825/450512761122979841/unknown.png 20180528 04:17:25<+discordbot1> Also, I think [0] is more intuitive than .front(). 20180528 04:17:27<+discordbot1> Actually, I guess back() is at least simpler than doing size maths. 20180528 04:18:15<+discordbot1> The codebase avoiding both is a holdover from the VC++ 6.0 days, incidentally. 20180528 04:19:06<+discordbot1> TBH, I don't usually even remember that std::string has those methods. 20180528 04:22:23<+discordbot1> I only used front() in two places where back() was also used, for symmetry 20180528 04:22:50<+discordbot1> but back() is definitely better than size maths 20180528 04:28:12<+discordbot1> @shadowm i can't do anything about it running into one line 20180528 04:30:19<+discordbot1> Yes, but at least it helps if the announcement starts with a paragraph that covers some or most of the available space. 20180528 04:30:46<+discordbot1> https://cdn.discordapp.com/attachments/259976436490829825/450516259486826497/unknown.png 20180528 04:34:40<+discordbot1> I see 20180528 04:37:59-!- travis-ci [~travis-ci@ec2-54-196-139-215.compute-1.amazonaws.com] has joined #wesnoth-dev 20180528 04:38:00< travis-ci> wesnoth/wesnoth#18402 (master - 40d9b99 : Charles Dang): The build was broken. 20180528 04:38:00< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/384572920 20180528 04:38:00-!- travis-ci [~travis-ci@ec2-54-196-139-215.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180528 04:57:14-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] 20180528 05:12:21< irker141> wesnoth: Charles Dang wesnoth:master 3cc854448879 / src/actions/undo.cpp: Fixup 40d9b99 (unused variables) https://github.com/wesnoth/wesnoth/commit/3cc8544488790f743de38365c92054fd11be1fa9 20180528 05:23:55-!- gallaecio [~quassel@188.79.96.255] has joined #wesnoth-dev 20180528 05:32:48-!- travis-ci [~travis-ci@ec2-54-159-180-202.compute-1.amazonaws.com] has joined #wesnoth-dev 20180528 05:32:50< travis-ci> wesnoth/wesnoth#18403 (master - 3cc8544 : Charles Dang): The build is still failing. 20180528 05:32:50< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/384584670 20180528 05:32:50-!- travis-ci [~travis-ci@ec2-54-159-180-202.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180528 05:42:07-!- gallaecio [~quassel@188.79.96.255] has quit [Remote host closed the connection] 20180528 05:45:07< irker141> wesnoth: Charles Dang wesnoth:master 3c4da4035f34 / src/scripting/game_lua_kernel.cpp: Fixup 40d9b99 again (more unused variables) https://github.com/wesnoth/wesnoth/commit/3c4da4035f34a6bd9f63f79ab194b3611578d545 20180528 06:07:36-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180528 06:08:57-!- travis-ci [~travis-ci@ec2-54-92-152-130.compute-1.amazonaws.com] has joined #wesnoth-dev 20180528 06:08:58< travis-ci> wesnoth/wesnoth#18404 (master - 3c4da40 : Charles Dang): The build was fixed. 20180528 06:08:58< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/384591527 20180528 06:08:58-!- travis-ci [~travis-ci@ec2-54-92-152-130.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180528 06:29:43< irker141> wesnoth/wesnoth:1.14 doofus-01 e3616104fb graphics update for giant ant unit AppVeyor: All builds passed 20180528 06:31:38-!- gallaecio [~quassel@220.red-79-150-211.dynamicip.rima-tde.net] has joined #wesnoth-dev 20180528 06:55:40< irker141> wesnoth: Charles Dang wesnoth:master 019848a28fae / src/ (display.cpp events.cpp events.hpp): Events: removed unused sdl_handler virtual functions https://github.com/wesnoth/wesnoth/commit/019848a28fae3d120d756ac091908b5b2c0c2e18 20180528 07:00:28< zookeeper> @Vultraz, HttT rewrite again, eh? the last time we did that with jetrel it was 2007, i still have some of the ideas written down... :p 20180528 07:00:45<+discordbot1> We tossed some ideas around 20180528 07:00:56<+discordbot1> Obviously now isn't a good time for anyone 20180528 07:01:18<+discordbot1> Frogatto is hoping to launch on Steam late this year 20180528 07:02:32<+discordbot1> So any such project wouldn't be until next year at the earliest 20180528 07:03:06< zookeeper> of course. any concrete ideas you want to share early? 20180528 07:05:28<+discordbot1> We discussed better characterization for Li'sar. Right now she doesn't have much agency in the story, even though she ostensibly becomes queen in the end? And there's really no reason for her to marry Konrad. 20180528 07:08:24<+discordbot1> Jet suggested a good way to go would be to flesh out her backstory as a princess, showing that the people she would be around would all be conniving, Machiavellian, and opportunistic, and Konrad would essentially be the first really non-selfish, stuck-up ass noble she runs into. 20180528 07:08:29<+discordbot1> Which I think is good 20180528 07:08:59<+discordbot1> We also discussed allowing more of the story to alternate between Konrad and Li'sar's viewpoints 20180528 07:09:25<+discordbot1> Also potentially actually giving the player branching narratives that actually had lasting impact 20180528 07:09:41<+discordbot1> Ie, you won' get elvish recruits if you don't take the elvish path 20180528 07:09:47<+discordbot1> Stuff like that 20180528 07:10:25<+discordbot1> Also the possibility of more interesting campaign-specific mechanics like lasting buffs for specific recruited unit types 20180528 07:10:56<+discordbot1> He also mentioned making the story a bit less linear, though I'm not entirely sure what he had in mind 20180528 07:11:11< zookeeper> well, better characterization and reasoning for her would certainly be good. and that backstory bit sounds like a good way to go about it. 20180528 07:15:55< zookeeper> any rewrite will likely end up making the campaign shorter, but i think that's fine especially when it's compensated with some meaningful branching. 20180528 07:16:14<+discordbot1> Probably 20180528 07:16:27<+discordbot1> It is quite long 20180528 07:16:57<+discordbot1> Oh, he also mentioned we should probably develop the idea of political factions more 20180528 07:17:40<+discordbot1> Ala Game of Thrones. Queen whatsherface is supposed to have basically stolen the throne, so it would make sense that various groups would either back, oppose, or vie for the claim themselves. 20180528 07:18:13<+discordbot1> As far as I remember, the story as currently told basically has everyone sitting on their asses for 20 years waiting for Konrad to grow up 20180528 07:19:14<+discordbot1> Except Wesnoth isn't aware of Konrad's existence. 20180528 07:19:24<+discordbot1> So they're not waiting for anything. 20180528 07:19:28<+discordbot1> exactly 20180528 07:19:37< zookeeper> everyone in GoT was (mostly) sitting on their asses for 15 years waiting for the story to start, too :p 20180528 07:20:06<+discordbot1> Robert was legit though 20180528 07:20:41<+discordbot1> And Dany and Viswhatsthatgoldenhairedjackass'sname were children. 20180528 07:20:54<+discordbot1> Also I love how you basically decided to sweep the rug from underneath my feet to get rid of my only reason to not convert the difficulty menu syntax in my campaigns. 20180528 07:20:59<+discordbot1> Every classy move. 20180528 07:21:02<+discordbot1> *Very 20180528 07:21:15<+discordbot1> The new layout is really bad. 20180528 07:21:42<+discordbot1> Oh, how could you participate in this rewriting stuff? 20180528 07:22:33<+discordbot1> We might field ideas from the community in time, but no one has time right now to commit to a rewrite right this second 20180528 07:22:57<+discordbot1> @Vultraz can I get your opinion on this sprite again 20180528 07:23:02<+discordbot1> https://cdn.discordapp.com/attachments/259976436490829825/450559609271353344/nightmare.png 20180528 07:23:05<+discordbot1> or maybe shadowm 20180528 07:23:15<+discordbot1> I recolored it with a modified palette 20180528 07:23:48<+discordbot1> year="300 AF" 20180528 07:24:00<+discordbot1> Did someone actually decide to date UtBS? 😐 20180528 07:24:24<+discordbot1> @shadowm I had been considering the hard-coded gray for a long time, but I couldn't decide whether #777 (font::GRAY_COLOR) or #888 (what you used) looked better. But once you told me you weren't switching to the new syntax, I decided to add he gray and switch GRAY_COLOR to #888 since it looked better 20180528 07:24:24<+discordbot1> and yes 20180528 07:24:29<+discordbot1> celmin did when he added sorting by date 20180528 07:24:38<+discordbot1> I don't care about the colour, I said layout. 20180528 07:24:59<+discordbot1> you said both 20180528 07:25:04<+discordbot1> I said layout. 20180528 07:25:10<+discordbot1> previously 20180528 07:25:12<+discordbot1> I said "the new layout is really bad". 20180528 07:25:24<+discordbot1> what's bad about it? 20180528 07:25:45<+discordbot1> @Yumi better, but still a bit too blue... and facing the camera. 20180528 07:25:49<+discordbot1> You decided to make it all a single column of text. 20180528 07:26:09<+discordbot1> It only further highlights the fact that the dialog is a redundant UI element. 20180528 07:26:34<+discordbot1> To clarify, it currently suffers from 80s UI design syndrome. 20180528 07:26:41<+discordbot1> .....oh dear 20180528 07:26:52<+discordbot1> Where instead of doing an operation in one go, you need to go through prompt after prompt to accomplish a task. 20180528 07:27:04<+discordbot1> In this case there's two prompts: the Campaigns menu, and the Difficulty menu. 20180528 07:27:21<+discordbot1> There's absolutely no workflow reason for the latter to not be integrated into the former. 20180528 07:27:29<+discordbot1> Alright, I'll do so 20180528 07:27:30<+discordbot1> facing the camera bit can't be helped, but I suppose it could use some more contrast 🤔 20180528 07:27:42<+discordbot1> (It'd also solve the irritating issue where if you dismiss the Difficulty menu you come back to Campaigns with the top entry selected instead of your previous selection.) 20180528 07:27:55<+discordbot1> I think UtBS is dated for chronological purposes? 20180528 07:28:06<+discordbot1> But more to the point, 300 years after the Fall is extremely little. 20180528 07:28:18<+discordbot1> Does anything in the UI display this? 20180528 07:28:42<+discordbot1> I don't think so 20180528 07:28:45<+discordbot1> It seems like it's a purely internal thing, but I'm pretty sure I saw relevant strings in the Spanish catalogue. 20180528 07:28:52<+discordbot1> For BW and YW. 20180528 07:29:36<+discordbot1> cpp std::string irdya_date::to_string() const { utils::string_map args {{"year", std::to_string(year)}}; switch(epoch.v) { case EPOCH::BEFORE_WESNOTH: // TRANSLATORS: "Before Wesnoth" - format for years prior to the founding of Wesnoth return VGETTEXT("$year BW", args); case EPOCH::WESNOTH: // TRANSLATORS: "Year of Wesnoth" - format for years after the founding of Wesnoth return 20180528 07:29:37<+discordbot1> VGETTEXT("$year YW", args); case EPOCH::BEFORE_FALL: // TRANSLATORS: "Before the Fall" - format for years prior to the fall of Wesnoth return VGETTEXT("$year BF", args); case EPOCH::AFTER_FALL: // TRANSLATORS: "After the Fall" - format for years after the fall of Wesnoth return VGETTEXT("$year AF", args); } return ""; } 20180528 07:29:37<+discordbot1> yes 20180528 07:29:41<+discordbot1> they are translatable 20180528 07:29:43<+discordbot1> but not displayed 20180528 07:29:54<+discordbot1> Then what is the point of this function? 20180528 07:30:14<+discordbot1> im not sure 20180528 07:31:00<+discordbot1> I think it was added just in case it would be useful later. 20180528 07:31:04<+discordbot1> I'll just set it to 9999 AF for my campaigns lol 20180528 07:32:54< zookeeper> jyrkive, did you notice discussion about the hitpoints lua error in TRoW that was caused by the disallowing of negative hp units? 20180528 07:32:59< zookeeper> +the 20180528 07:33:18< zookeeper> oops, maybe @jyrkive too 20180528 07:34:10<+discordbot1> It was in TRoW? 20180528 07:34:16<+discordbot1> @Vultraz If you look carefully at the menu, you'll also notice that it appears like the two lines are two independent widgets with a margin, rather than a single widget with a newline at the end of the first line. 20180528 07:34:17<+discordbot1> https://cdn.discordapp.com/attachments/259976436490829825/450562436974772224/unknown.png 20180528 07:34:42<+discordbot1> They are two independent widgets with a margin 20180528 07:34:43<+discordbot1> The vertical positioning here is a bit dodgy in general. 20180528 07:35:22<+discordbot1> I guess if this were integrated into the campaigns menu it would be a dropdown? 20180528 07:36:19<+discordbot1> Either that or it would be a second page on the right-side panel that appears once you press OK. 20180528 07:36:26< zookeeper> @jyrkive, yeah? prompted by https://forums.wesnoth.org/viewtopic.php?f=4&t=48263 20180528 07:36:53<+discordbot1> (Which could be relabeled "Play", btw.) 20180528 07:37:14<+discordbot1> I'm not going to advocate for a dropdown because it'd decrease its visibility. 20180528 07:37:40< zookeeper> @jyrkive, oh right, i suppose gfgtdf saying "other addons" was misleading. 20180528 07:37:41<+discordbot1> I'll comeup with somthing 20180528 07:38:30<+discordbot1> zookeeper: As well as the save file name being in Portuguese. I has absolutely no idea what AFdW means. 20180528 07:38:37<+discordbot1> *had 20180528 07:38:43<+discordbot1> if(!(*v > 0 || loc_ == dying_unit_loc)) { 20180528 07:39:04-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev 20180528 07:39:38<+discordbot1> suggest if(*v < 0 && loc_ != dying_unit_loc) {, that way hitpoints=0 will be valid 20180528 07:39:51<+discordbot1> It's not supposed to be valid. 20180528 07:40:04<+discordbot1> Damage prediction cannot tolerate a damage with zero hitpoints being alive. 20180528 07:40:05-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Client Quit] 20180528 07:40:08<+discordbot1> *a unit 20180528 07:40:13<+discordbot1> then we have a problem 20180528 07:40:19<+discordbot1> https://github.com/wesnoth/wesnoth/blob/1.14/data/campaigns/The_Rise_Of_Wesnoth/scenarios/07_Return_to_Oldwood.cfg#L145-L149 20180528 07:40:26-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev 20180528 07:40:34<+discordbot1> The code unstores the unit and attempts to heal it right after that. 20180528 07:40:46<+discordbot1> It would be better to heal it first. 20180528 07:40:53< zookeeper> the WML fix is trivial to do 20180528 07:41:06<+discordbot1> or edit the hitpoints v 20180528 07:41:09<+discordbot1> ariable 20180528 07:41:18<+discordbot1> That's exactly what I meant. 20180528 07:42:05<+discordbot1> well 20180528 07:42:07<+discordbot1> i guess it's acceptable 20180528 07:42:16< zookeeper> is such an all-encompassing ban on <=0hp units really necessary, can't the damage prediction code simply treat it as 1hp? there's no telling where similar breakage might occur. 20180528 07:42:20<+discordbot1> if other people are relying on this behavior 20180528 07:42:30<+discordbot1> when they shouldnt be 20180528 07:43:13<+discordbot1> zookeeper: I considered adding the check to the AI code instead. At the beginning of each AI turn, cycle through all units. If any of them has <= 0 HP, show an error. 20180528 07:43:35<+discordbot1> The problem with that is that it doesn't give UMC authors any help about how they ended up creating such a unit. 20180528 07:44:53< zookeeper> probably no one's relied on "oh cool, i'm allowed to have <=0hp units", they're likely all cases where the player would never see a unit having <=0hp (except in die events etc) even though technically they briefly exist. such as in this case. 20180528 07:45:18<+discordbot1> Exactly. No one is intentionally creating such units. 20180528 07:45:39<+discordbot1> I guess the strict Validation is good then 20180528 07:45:42<+discordbot1> And that's why I prefer the game to give an error message immediately so that they can debug it easier. 20180528 07:46:17< zookeeper> i'd imagine that it's not uncommon to store a unit on death, then sometime later unstore it and _then_ immediately heal it. 20180528 07:46:42<+discordbot1> Yeah. Maybe I need to think of some way to get that to work. 20180528 07:47:30<+discordbot1> Maybe, instead of showing an error immediately when unstoring, the game could wait until an event handler has run, and then scan all units to check if any has <= 0 HP? 20180528 07:48:13< zookeeper> sounds a lot safer, if it can be done 20180528 07:50:17< zookeeper> i was about to suggest simply letting [unstore_unit] do "if hp <= 0 then hp = 1", but that would probably somehow mess with storing/unstoring of the dying unit in some die/last_breath events... unless you can keep excluding that context, such as the code apparently does now in some way. 20180528 07:51:00<+discordbot1> In general, I prefer when mistakes are easier to notice, instead of swept under the rug. 20180528 07:51:22< zookeeper> @EliDupree, btw, do you intentionally create units with <=0hp somewhere for some purpose? :p 20180528 07:52:01< zookeeper> @jyrkive, yeah, but there was no way we were going to notice this in time. 20180528 07:52:39< zookeeper> unless by mistake you meant the author not explicitly guarding against unstoring a <=0hp unit... which isn't that much of a mistake if it's always worked 20180528 07:53:17<+discordbot1> With "mistake", I simply meant creating/unstoring a unit without healing it afterwards. 20180528 07:54:00<+discordbot1> If code that has used to work no longer does, that's on us. 20180528 07:54:57< zookeeper> uh, sure. incidentally, a lot of mainline campaigns used to have that problem; units got stored in scenario A then unstored in scenario B and they just had their old hp and mp and all, urgh... -.- 20180528 07:55:54<+discordbot1> Well, that's still better than crashing the game (like <= 0 HP does). 20180528 07:56:46< zookeeper> unfortunately, we _do_ also happen to have this mention here: https://wiki.wesnoth.org/DirectActionsWML#.5Bunstore_unit.5D "Units can be unstored with negative (or zero) hit points. [...]" :p 20180528 08:04:48<+discordbot1> I rewrote the paragraph to match the planned behavior. 20180528 08:05:12<+discordbot1> Sigh. I had no idea that ability to create <= 0 HP units was documented. 20180528 08:29:01<+discordbot1> Only by unstoring and it says you should heal it by the end of the event 20180528 08:30:26<+discordbot1> Of course it says, because I added that text half an hour ago. 20180528 08:31:17<+discordbot1> And it doesn't matter in how many ways ability to create such units is documented. The engine was supposed to support existence of such units. 20180528 08:31:57<+discordbot1> If someone had pointed out that documentation before release, I'd have changed damage prediction code to tolerate such units instead of adding this validation. 20180528 08:37:16<+discordbot1> Well 20180528 08:37:30<+discordbot1> Are we going keep this validation 20180528 08:37:51<+discordbot1> Yes. It's already in a stable release. Removing it would be another API change. 20180528 08:38:38<+discordbot1> I didn't know that adding the validation was an API change. Only changes to documented behavior are API changes. 20180528 08:49:52< zookeeper> if in 1.14.2 you have something that breaks that never broke previously, and then in 1.14.3 it again doesn't break, then that hardly counts as two API changes. technically, sure, but in practise no one's going to take advantage of the new behavior and then be disappointed when in 1.14.3 their code... well, no longer breaks. 20180528 08:51:04<+discordbot1> So, you think I should just remove the validation entirely? 20180528 08:51:11<+discordbot1> What about you, Vultraz? 20180528 08:54:11< zookeeper> if you can fix the attack prediction problem without the general-purpose validation, then yeah, at least in 1.14 that seems like the safer choice. it doesn't sound like there was a reason to introduce it beyond the attack prediction fix? 20180528 08:55:09<+discordbot1> To my knowledge, the attack prediction code is the only thing that crashes when encountering <= 0 HP units. 20180528 08:57:42< zookeeper> anyone who adjusts their code to deal with the 1.14.2 behavior isn't going to be inconvenienced if/when the behavior in 1.14.3 reverts back to the old one. or at least that possibility seems largely theoretical. 20180528 09:08:45< zookeeper> even in 1.15 the fact is that problems resulting from the change would be laborious to find (until a hapless user stumbles across one and reports it, obviously), and might often be problems undiscoverable by cursory testing with debug mode or whatever, only triggered in specific circumstances. 20180528 09:24:57-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has joined #wesnoth-dev 20180528 09:29:39-!- gfgtdf [~gfgtdf@134.76.63.8] has joined #wesnoth-dev 20180528 09:37:45< gfgtdf> i'd also prefer changing that attaks prediction code instad and mostly reverting the hp>0 check otherwise, i also think that the current code has also too many exception: lua unit hp setter can set the unit hp to 0 but unsore_unit cannot. unsore_unit can set in the units hp to below zero in some special cases (also note that that you can still call wesnoth.simulate_combat in those cases and probably crash wesnoth with that.) 20180528 09:39:24< gfgtdf> if w want a check for hp<=0 i suggest running it at the end of every synced action (instead of at the beginning of each ai turn) to let them notice it eariler. 20180528 09:50:09< irker141> wesnoth/wesnoth:1.14 Iris Morelle 9c30032ab4 pofix: Update with 1.14.1 -> 1.14.2 rule AppVeyor: All builds passed 20180528 09:59:45-!- matth1askrgr [matthiaskr@gateway/shell/panicbnc/x-mezwhxqzmzfmdzie] has joined #wesnoth-dev 20180528 10:01:22-!- Netsplit *.net <-> *.split quits: matthiaskrgr 20180528 10:11:16<+discordbot1> @jyrkive TBH, when I first saw the bug that started all of this I thought the fix would be something along the lines of what you had done previously when there was a problem in the attack code, exit exit early, or clamp or round some value. I was surprised when you added the more comprehensive fix. So... little torn on what to do. On one hand, it does seem in hindsight like it could break a lot of things. On the other HP < 0 20180528 10:11:16<+discordbot1> validation in some cases could catch slightly flawed WML, as we see in the TRoW case..... Perhaps the best solution would be to retain a check for HP < 0 as a warning, but revert the strict validation? 20180528 10:19:01<+discordbot1> Well, the TRoW WML is supposed to work. It heals the unit right after unstoring it. 20180528 10:28:03<+discordbot1> I wonder if we should add a restore= yes key to [store_unit] 20180528 10:28:47<+discordbot1> Even if we can add it, it should be a 1.15 addition. 20180528 10:42:42< zookeeper> yes, the TRoW case was _not_ a case of flawed WML by any standard 20180528 11:02:10<+discordbot1> I see 20180528 11:05:56-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Quit: Konversation terminated!] 20180528 11:11:46-!- gfgtdf [~gfgtdf@134.76.63.8] has quit [Ping timeout: 264 seconds] 20180528 11:48:20< irker141> wesnoth/wesnoth:master Charles Dang 3c4da4035f Fixup 40d9b99 again (more unused variabl AppVeyor: All builds passed 20180528 11:52:36-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev 20180528 12:13:10-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180528 12:13:16-!- janebot_ [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180528 12:13:18-!- janebot_ is now known as janebot 20180528 12:22:27<+discordbot1> we can push a patch to Steam once the unit thing is resolved. 20180528 12:23:42<+discordbot1> We should definitely make such an update available in SourceForge as well. 20180528 12:39:29<+discordbot1> You don't happen to remember the circumstances that prompted this commit, do you? I very much doubt it, since it's been over 2 years, but still... 20180528 12:39:30<+discordbot1> https://github.com/wesnoth/wesnoth/commit/126ba58a44925d1a5489221a3dc2cd6edf6884eb 20180528 12:39:41<+discordbot1> I'm wondering if that code can be removed, or it should remain 20180528 12:41:15<+discordbot1> Who are you asking? 20180528 12:41:28<+discordbot1> I joined the project in summer 2016, long after that commit was made. 20180528 12:42:02<+discordbot1> ...oops 20180528 12:42:11<+discordbot1> I must have misread the blame graph 20180528 12:42:13<+discordbot1> 😬 20180528 12:42:23< EliDupree> zookeeper, @jyrkive, @Vultraz: Haha I've never purposefully left any units with 0 or less HP after the end of an event stack, but I do rely on the exact behavior of last_breath/die events for a bunch of things. In particular, if unstoring a unit with <=0 HP was forbidden, that would break any script that modifies a unit during its last_breath event (e.g. to change its appearance as it dies) 20180528 12:42:39<+discordbot1> sorry 20180528 12:43:01<+discordbot1> EliDupree: 1.14.2 does allow unstoring such units in last_breath events. 20180528 12:44:54< EliDupree> I also simulate combat during other events by explicitly reducing unit hitpoints and then firing those events myself 20180528 12:45:20<+discordbot1> why did zookeeper ask you specifically? 20180528 12:45:32< EliDupree> Because I do all kinds of weird stuff with scripts 20180528 12:45:39<+discordbot1> I see 20180528 12:45:41<+discordbot1> 🤔 20180528 12:46:04<+discordbot1> I hope not things one should not 😛 20180528 12:46:36< EliDupree> I can't read those symbols (emoji?) over here on IRC 20180528 12:46:45<+discordbot1> emoji, yes 20180528 12:47:06<+discordbot1> one is :thinking: and the other is :P 20180528 12:47:37< Ravana_> I consider that realtime tetris most impressive use of wesnoth engine 20180528 12:47:37< EliDupree> So… exactly what behavior changes happened in 1.14.2? 20180528 12:47:53<+discordbot1> You might be able to see the emoji with a different IRC client or font. 20180528 12:48:35<+discordbot1> I added validation to disallow creation/unstoring of units with zero or less HP, except if the unit is already dying. 20180528 12:48:44< EliDupree> If they apply to wesnoth.put_unit(), then I believe they break part of EoHS 20180528 12:49:04<+discordbot1> Yes, it does. 20180528 12:49:11<+discordbot1> I'm planning to revert it, though. 20180528 12:49:38<+discordbot1> Zookeeper pointed out that ability to create such units was actually documented, and thus disallowing it was an API change. 20180528 12:49:47< EliDupree> Well that's good at least. Behavior changes in the stable version :-( 20180528 12:50:07<+discordbot1> Indeed. 20180528 12:50:17<+discordbot1> Sorry that I missed the documentation. 😦 20180528 12:50:34< EliDupree> This is still going to mean that we'll have out of sync errors whenever someone on 1.14.2 plays a game with someone on 1.14.something_else. I suppose I'll add a script to detect that and a warning message 20180528 12:56:00<+discordbot1> Do you think it worth only allowing latest stable in MP 20180528 12:56:40<+discordbot1> I think it's not a good idea. It would result in losing players. 20180528 12:57:32< EliDupree> The idea of stable versions is that they should always have the same behavior as each other, so no. But it might be good to exclude or at least give warning when you have a known buggy version like 1.14.2 20180528 12:57:57<+discordbot1> blah 20180528 12:58:42< EliDupree> I remember in the past I had errors from people running, IIRC, 1.10.5, when it had some sort of unique bug (1.10.4 and 1.10.6 both worked), and that was hard to debug 20180528 12:58:50<+discordbot1> I'm not gonna lie I wish we didn't have to support manual package installs and could entirely rely on distribution services with auto-update features 20180528 12:59:14< EliDupree> I also wish that programming for humans was easy and never had any inconveniences 20180528 13:01:10< EliDupree> But unfortunately, our only options are "do the work properly ourselves" and "dump the fallout on everyone else" 20180528 13:01:47<+discordbot1> That doesn't follow what I said. 20180528 13:02:13<+discordbot1> Having a distribution method that always ensured people had the latest version, as Steam does, would save us a damn lot of hassle. 20180528 13:03:16<+discordbot1> Such "ensuring" is a last-resort option, I'm afraid. 20180528 13:03:25< EliDupree> Yes, it would save us a lot of hassle if we didn't have to do all of the work to support all users who have reasonable preferences about their convenience or security. 20180528 13:04:40<+discordbot1> App Store and Google Play have auto-updates too. Still, Angry Birds Stella and Nibblers (two commercial games I have worked on) have their own "forced update" implementations on top of that, because deploying an update does NOT magically push it to everyone's phones immediately. 20180528 13:04:49<+discordbot1> And we only invoked them when we had to. 20180528 13:04:51< EliDupree> I know that I personally try to minimize how many programs I permit to install arbitrary code on my computer without my direct involvement 20180528 13:05:15<+discordbot1> You can't argue that downloading the game again in its entirety every release is in any way more convenient than a 40 MB update or so on Steam. 20180528 13:05:40<+discordbot1> (I don't know if flatpak has incremental updates) 20180528 13:05:46< EliDupree> I can easily argue that downloading the game again in its entirety *not* every release is more convenient than that 20180528 13:06:08<+discordbot1> I don't agree at all. 20180528 13:06:23<+discordbot1> The game is nearing 500 MB. The updates have been 20 - 40. 20180528 13:07:03<+discordbot1> points out that the size matters much less with a fast Internet connection :P 20180528 13:07:24<+discordbot1> even if you download every other release,in that case you just downloaded 1 GB over over 40 - 80 MB 20180528 13:07:31<+discordbot1> er 20180528 13:07:32< EliDupree> The experience of trying to log on to the server in order to play, while my friends are waiting for me, only to have to delay the process because there's a required update, is much more unpleasant than simply the time spent waiting when I get around to it at my leisure 20180528 13:07:39<+discordbot1> 60 - 120* 20180528 13:07:58<+discordbot1> It happens in Dota 20180528 13:09:02<+discordbot1> But having auto, incremental updates doesn't necessairily mean disallowing previous stable versions in MP 20180528 13:09:16<+discordbot1> those are mutually exclusive. 20180528 13:09:44<+discordbot1> the former only means we have the reasonable expectation that most users will have the latest update and therefor won't need to be as stringent with our API changes. 20180528 13:09:54<+discordbot1> And would ease the implementation of a rolling release model. 20180528 13:10:01< EliDupree> That does not follow. 20180528 13:10:24< Ravana_> having incremental upgrades without auto would be nice 20180528 13:10:55<+discordbot1> Unfortunately automatic updates can't be disabled in Steam. 20180528 13:10:59< EliDupree> In all cases where you allow old stable releases to play with the freshest one, there is literally zero permissible changes to the APIs between those stable releases 20180528 13:11:56<+discordbot1> That is trie 20180528 13:11:58<+discordbot1> true 20180528 13:12:15< EliDupree> So I don't know what you mean by "less stringent" 20180528 13:17:31<+discordbot1> I guess those two are not mutually exclusive 20180528 13:18:22<+discordbot1> essentially, if there can be a reasonable assumption made by us that the vast majority of players have the latest version, then we can made API changes outside a dev cycle 20180528 13:19:09< EliDupree> Only if you also exclude old versions from the multiplayer server. 20180528 13:19:12<+discordbot1> not every day, mind you, zookeeper raises an idea of a twice-yearly "big" release with API changes. I think 3 or 4 is better, but the concept's the same. 20180528 13:19:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180528 13:20:13< EliDupree> Isn't that the same as having dev versions and stable versions, just with more frequent stable versions? 20180528 13:20:44<+discordbot1> somewhat 20180528 13:20:46<+discordbot1> yes 20180528 13:21:01< EliDupree> Unless you are specifically planning to release API changes without having any time for testing first, i.e., planning to frequently break the game for ordinary users 20180528 13:21:52<+discordbot1> the rolling release model would essentially switch us from dev/stable/dev/stable to a single release branch into which features are merged and pushed as necessary. API changes or larger refactors would go into specific larger releases every few months. 20180528 13:21:52<+discordbot1> But 20180528 13:22:00<+discordbot1> I don't know if we can reasonably implement that now 20180528 13:22:04<+discordbot1> given the state of master 20180528 13:22:10<+discordbot1> we might need another stable/dev cycle 20180528 13:23:29<+discordbot1> I don't know how to handle 1.14 in the meantime 20180528 13:24:29<+discordbot1> We're obviously going to focus on 1.14 as long as 1.14 releases are being made. 20180528 13:24:43<+discordbot1> Changes to the stable branch get to the hands of players much faster. 20180528 13:25:16<+discordbot1> I shall need to decide a cutoff point 20180528 13:25:53<+discordbot1> Thing is 20180528 13:26:27<+discordbot1> there are already some API changes made on master that shouldn't need to languish for a year or two or three waiting on all the other changes in master to finish and stabilize 20180528 13:27:04<+discordbot1> as well as other changes such as the real table for unit types thing 20180528 13:27:06<+discordbot1> ya know? 20180528 13:27:22<+discordbot1> That's one of the biggest reasons why software projects often have a "keep master in a releasable state at all times" policy. 20180528 13:27:34< EliDupree> No, I don't know. 20180528 13:28:02<+discordbot1> Under my rolling release plan, those changes would get to players while we work on master. 20180528 13:28:38< EliDupree> I would much rather fix all the breakages at once every couple years than have to monitor Wesnoth year-round just to make sure people can still play EoHS. 20180528 13:29:26<+discordbot1> Perhaps until we get to 1.16 and can fully implement the plan, we could at some point release a "mini" new stable series in conjunction with loony's versioning change proposal 20180528 13:29:42<+discordbot1> end of the year, maybe 20180528 13:30:47< EliDupree> My pattern for working on EoHS has basically been "something like once per year, at random, get interested in it again and work on it a bunch, then lose interest a month or 2 later". I have other things in my life, and I'm not so committed to EoHS that I would want to be on-call to maintain it more frequently than that. 20180528 13:31:11< EliDupree> So if breakages were more frequent, it might stop being worth it to maintain it at all 20180528 13:31:30< EliDupree> I imagine a lot of other add-on developers would feel the same way 20180528 13:31:39<+discordbot1> The counter to that is that if their scope would also be smaller 20180528 13:32:21<+discordbot1> But now I'm just retreading ground 20180528 13:33:12<+discordbot1> I should have considered this problem before master and 1.14 diverged 20180528 13:38:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 264 seconds] 20180528 13:39:43< EliDupree> I count about 11 separate EoHS breakages between 1.12 and 1.14, or about 3 and a half years. If they were spread out evenly, there would be a breakage every 4 months 20180528 13:41:41< irker141> wesnoth/wesnoth:master Charles Dang 019848a28f Events: removed unused sdl_handler virtu AppVeyor: All builds passed 20180528 13:44:21<+discordbot1> breakages because of API changes or because of bugs? 20180528 13:44:38< EliDupree> From my perspective, it doesn't matter 20180528 13:45:18<+discordbot1> or breakages because you were using buggy or undocumented behavior? 20180528 13:45:51< EliDupree> Most of them were not the result of my unholy magics. 20180528 13:46:08<+discordbot1> To be fair, this case with negative-HP units is documented. I just missed that, and thought it was undocumented (and thus free to change even in stable releases). 20180528 13:46:34< EliDupree> They were mostly things that anyone could run into if they used the features reasonably. 20180528 13:46:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180528 13:47:24<+discordbot1> I wonder if any of your unholy magicks would become sanctified using new features 😛 20180528 13:47:49< EliDupree> For example, one breakage was the result of someone changing set_dialog_value() to trigger set_dialog_callback() callbacks, which for me, caused an infinite loop. 20180528 13:48:15<+discordbot1> Oh, sorry. That was me, too. 20180528 13:48:23<+discordbot1> I though it was gfgtdf 20180528 13:48:23<+discordbot1> It was a side effect of a GUI bug fix. 20180528 13:48:47<+discordbot1> triggering it is logical 20180528 13:49:03< EliDupree> Yeah, I used unholy magic to detect clicks, and now you can detect clicks legitimately (although it's still difficult to use because of idiosyncrasies). Are you using that as an argument that I should approve of more frequent changes? It doesn't convince me 20180528 13:49:40<+discordbot1> I don't even want to know what abomination you used to detect clicks 20180528 13:49:49< EliDupree> ;-) ;-) ;-) 20180528 13:50:14<+discordbot1> we don't support the use of unholy abominations 20180528 13:50:47<+discordbot1> We do, as long as all its building blocks are documented. 20180528 13:50:51< EliDupree> Anyway, that particular unholy abomination DID NOT BREAK 20180528 13:51:40< EliDupree> Anyway, doesn't matter whose fault it was for each individual breakage – the only thing that matters is whether there's a solid plan to make sure such breakages are less likely to happen in the future. And they're clearly isn't, so I cannot approve of making the stable version more volatile. 20180528 13:52:02< EliDupree> If there was such a plan, I might be able to be convinced. 20180528 13:52:41<+discordbot1> It's not really your decision to make. I know such a thing is necessary, however. 20180528 13:53:18<+discordbot1> The main crux of my argument is that smaller, more frequent changes make it easier to notice when something breaks and goes wrong 20180528 13:53:20<+discordbot1> Even if UMC authors don't have the power to make the decision, it definitely wouldn't be nice to just ignore their objections. 20180528 13:53:22<+discordbot1> it's either a, b, or c 20180528 13:53:27<+discordbot1> not anything from a to zzz 20180528 13:54:23<+discordbot1> if anything, this debacle with the unit HP is a perfect, if unintended, illustration. 20180528 13:54:28<+discordbot1> an API change was made 20180528 13:54:40<+discordbot1> breakage was discovered quickly 20180528 13:55:02<+discordbot1> and it can be resolved quickly and a fix deployed within days 20180528 13:55:14<+discordbot1> imagine if this had been in say 20180528 13:55:15<+discordbot1> 1.13.5 20180528 13:55:24<+discordbot1> it might have gone undiscovered for months 20180528 13:56:06<+discordbot1> granted, once it was found it could still be fixed just as quickly 20180528 13:56:17<+discordbot1> but what if jyrki had left the project? 20180528 13:56:28<+discordbot1> what if we didn't remember the original issue? 20180528 13:56:35<+discordbot1> what if it broke people's addons in the interim? 20180528 13:56:56<+discordbot1> EliDupree: for the record, this is the commit that caused set_dialog_value() to trigger the callbacks: https://github.com/wesnoth/wesnoth/commit/8be7de39f90493ff5955c663f78361c23460282d#diff-c97c027abe664f38a6da294301c618dd 20180528 13:57:04<+discordbot1> (Took me a while to find it.) 20180528 13:57:07<+discordbot1> no one really plays the dev versions 20180528 13:57:21-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180528 13:57:51< EliDupree> Yeah, that mistake is understandable and I've made similar mistakes in my own code 20180528 13:58:20<+discordbot1> what mistake? 20180528 13:58:38<+discordbot1> (are you replying to me or to jyrki) 20180528 13:58:44< EliDupree> jykri 20180528 13:59:19<+discordbot1> The set_dialog_value() change wasn't a mistake. 20180528 13:59:33<+discordbot1> It was for a dev release, where API changes are allowed. 20180528 14:00:09-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180528 14:00:21< EliDupree> Oh, you intended it to apply to set_dialog_value()? I misread, I thought someone said it was unintentional 20180528 14:00:32<+discordbot1> EliDupree: hopefully you can see how the unit HP thing supports my point. 20180528 14:00:45< EliDupree> Which point? 20180528 14:00:47<+discordbot1> I didn't really intend that to happen, but I didn't care that it did. 20180528 14:01:09<+discordbot1> When I heard about it, I figured "neat, it may be useful to UMC authors too". 20180528 14:01:16<+discordbot1> EliDupree: the benefits of small changes that happen more freqently 20180528 14:01:34<+discordbot1> and how issues with them can bediscovered and fixed easily and quickly 20180528 14:01:47< EliDupree> At no point have I argued that they don't have ANY benefits 20180528 14:02:22<+discordbot1> I didn't say you said that 20180528 14:02:31<+discordbot1> You said you'd need to be convinced 20180528 14:02:41<+discordbot1> to which I presented an argument in favor 20180528 14:03:59< EliDupree> In fact, as an add-on developer, I certainly spent plenty of time during 1.12 thinking "I wish I had this 1.13 feature already". But my eagerness to see new features and bugfixes is much smaller than my desire for the entire add-on I've implemented thus far to continue working reliably. 20180528 14:08:08<+discordbot1> Also consider your maintenance time would be a lot lower 20180528 14:08:17< EliDupree> oh? 20180528 14:10:34< EliDupree> When I said I would need to be convinced, I meant convinced by someone presenting a new plan or commitment, not by arguments that the changes you've proposed so far are good enough. In fact, your hypothetical scenario of someone changing the HP thing in 1.13.5 actually sounds MORE pleasant for me as an add-on developer than what actually happened, because at worst, I only have to deal with it in the same batch as all the other breakages 20180528 14:10:34< EliDupree> (although I do understand the trade-off) 20180528 14:15:38<+discordbot1> alright. 20180528 14:26:34< EliDupree> (Fortunately it was easy for me to add a warning message to EoHS, so at least if anyone's running 1.14.2, they'll know why stuff is broken and they can update) 20180528 14:40:10-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20180528 14:42:27-!- gallaecio [~quassel@220.red-79-150-211.dynamicip.rima-tde.net] has quit [Ping timeout: 240 seconds] 20180528 14:42:49-!- gallaecio [~quassel@143.red-81-32-24.dynamicip.rima-tde.net] has joined #wesnoth-dev 20180528 14:43:26<+discordbot1> Personally, it sounds like what would be better than a straight rolling release style would be to take a couple pages from how gcc/clang(for example) do releases and also how android manages API changes. That is - be able to specify an API version, and then eventually (once a year?) drop older API versions. ie: APIv1(unmaintained/legacy, next to be removed), APIv2(deprecated, low priority), APIv3(current, high priority), 20180528 14:43:26<+discordbot1> and API-dev(may change whenever). Then after a year, APIv1 would be deleted, APIv2 would become unmaintained/legacy, APIv3 would become deprecated, and API-dev would become APIv4/current. This way everyone would have access to the new dev API changes/features if they wanted, but also wouldn't have to deal with frequent breakages if they'd rather not. Though I don't know if that would be practical to actually do. 20180528 14:47:12-!- gallaecio [~quassel@143.red-81-32-24.dynamicip.rima-tde.net] has quit [Ping timeout: 252 seconds] 20180528 14:47:34< EliDupree> Yeah, that would be a good plan, but since we haven't been doing it all along, it would require invasive changes all over the wesnoth engine 20180528 14:48:28-!- gallaecio [~quassel@143.red-81-32-24.dynamicip.rima-tde.net] has joined #wesnoth-dev 20180528 14:48:50<+discordbot1> I kinda figured. 20180528 14:50:25<+discordbot1> at the moment though, I remain unconvinced that simply switching over to a straight rolling release model with API breakage 4 times a year will end well, especially for more complex UMC. Not to mention constantly breaking old save files. 20180528 14:51:58< EliDupree> And it (the API versions) might not even be as practical for Wesnoth, since "the API" is essentially the entire behavior of the game. While a compiler puts much more work into internal optimizations that don't change the API 20180528 14:53:31< EliDupree> (But I can imagine drawing some reasonable lines around what's part of "the API", e.g. you could add more unit graphics and balance changes across all versions, even though UMC can technically be dependent on them) 20180528 14:56:07<+discordbot1> yeah, stuff like art and music don't break things if they are/aren't present, so I was really even considering them as things that would need to be considered by the versioning. 20180528 14:57:09<+discordbot1> balance changes are sort of an in-between case, since a change to a unit used in MP will then cause OOS errors with old clients while a campaign-specific unit would not. 20180528 14:57:31< EliDupree> The unit stats could be made dependent on the host of the game, the way the scenario is 20180528 14:59:05<+discordbot1> that sounds like it would be ideal anyway, honestly. 20180528 14:59:29< Ravana_> some API additions could be exposed to Lua, like python has __future__ 20180528 15:00:03<+discordbot1> I thought python was removed/replaced with lua a while ago? 20180528 15:00:36< Ravana_> python in general, not in wesnoth 20180528 15:01:36<+discordbot1> ah 20180528 15:02:31-!- gfgtdf [~gfgtdf@134.76.63.8] has joined #wesnoth-dev 20180528 15:03:51<+discordbot1> sure - I'm not particularly attached to any particular way of going about doing it. 20180528 15:04:24-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180528 15:05:15<+discordbot1> as long as there aren't potentially breaking changes being done every three months 20180528 15:18:33< EliDupree> (Example of a balance change soft-breaking a UMC: A New Order was balanced around the assumption that you hardly ever have arcane damage – the enemies were super weak to it – so when Elvish Sorceresses were added as an alternate advancement for Elvish Shaman, some of the scenarios became laughably easy) 20180528 15:26:24< mattsc> gfgtdf: I’ve been doing some more evaluation time tests on using filters and apparently I don’t understand how SUFs are evaluated. 20180528 15:26:44< gfgtdf> you have a concrete question ? 20180528 15:26:49< mattsc> Here are some snippets of what i am using: https://pastebin.com/r94ESjQx 20180528 15:26:54< mattsc> gfgtdf: getting there ... 20180528 15:27:17< mattsc> Both of those filters are set up so that they don’t match any unit on the map. 20180528 15:27:48< mattsc> So I figured that if the first filter does not match a unit, then since there’s an [and] between them, the second would not be evaluated. 20180528 15:28:13< mattsc> But no matter what I try, the time needed is always the sum of the time needed for the two individual filters. 20180528 15:28:54< mattsc> So what am I misunderstanding or doing wrong here? 20180528 15:30:49< gfgtdf> hmm sounds like a bug actually. 20180528 15:31:01< mattsc> I was wondering about that. 20180528 15:31:04< gfgtdf> it lways evenaulates [and] even it it shouldn-t 20180528 15:33:00< irker141> wesnoth: gfgtdf wesnoth:1.14 7be39c937d92 / src/units/filter.cpp: fix unit filter always evaluating [and] even if it is not needed. https://github.com/wesnoth/wesnoth/commit/7be39c937d927ee559d91df309f7669e12a56fa8 20180528 15:33:09< gfgtdf> mattsc: try now ^ 20180528 15:34:27< mattsc> gfgtdf: Wow, that was quick! (I can’t do this right this moment, but should be able to get to it in a couple hours.) 20180528 15:34:31< mattsc> I’ll get back to you. 20180528 15:34:41<+discordbot1> forward-port 20180528 15:34:56< mattsc> @Vultraz: let’s test it first. :) 20180528 15:37:29<+discordbot1> EliDupree: true, though that's also something of a one-off occurrence. I can't imagine that any mainline faction(aside from perhaps the Dunefolk, which are known to be imbalanced and are separated into a their own era) would be getting changed to have an entirely new L1->L2 advancement these days. 20180528 15:38:11-!- gallaecio [~quassel@143.red-81-32-24.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 20180528 15:38:14< EliDupree> True, I just figured it was an interesting example 20180528 16:06:41-!- gallaecio [~quassel@188.79.96.255] has joined #wesnoth-dev 20180528 16:07:59< gfgtdf> 20180528 13:48:23<+discordbot1> I though it was gfgtdf 20180528 16:08:23< gfgtdf> no i fixed to match the 1.12 behviour again. 20180528 16:11:04< gfgtdf> i think that we shoudl think about some way to add new api to stables, as a umc and engine developer it can be really frutrating to to be able to do think in umc that woudl basicially be oneliners in the engine. 20180528 16:12:06< gfgtdf> but of not breakin changes (but addin new apitis usually unrelated to braking old things so this doe not realyl change the point) 20180528 16:16:41< gfgtdf> it probably also make sense to make releases on steam always 2 days before the release announcement, simply becasue breaking things on steam 'is not as bad' becasue we can fix it immidiateley iiuc. 20180528 16:22:27<+discordbot1> I direct the packagers to prioritize steam 20180528 16:23:06<+discordbot1> they're the easiest player group to get update to 20180528 16:23:08<+discordbot1> updates 20180528 16:23:12<+discordbot1> so they get them first 20180528 16:24:08<+discordbot1> and yes, adding new APIs to stable might be something to consider 20180528 16:25:44< EliDupree> That's an interesting idea, although the new features would at least have to be carefully labeled so that developers of multiplayer add-ons don't accidentally use them in a manner breaking compatibility with older stable releases 20180528 16:27:02<+discordbot1> part of the point of stable releases that they're supposed to be compatible with each other? 20180528 16:27:08<+discordbot1> *isn't 20180528 16:28:25< EliDupree> It's probably fine if people use new APIs in campaigns only 20180528 16:30:23< EliDupree> And I wouldn't mind having opt-in newer APIs in multiplayer, as long as there was a strict system where (1) you can't use them unless you flagged your add-on to use them, and (2) users can't join a game that uses APIs they don't have, with a clear label like "you need wesnoth 1.16.8 to join this game" 20180528 16:33:55< gfgtdf> EliDupree: i thought the same (1), but that bring to problme on how to handle the addons that use a custom compability code liek if wesnoth_ersion >= 1.14.10 then do stuff else do compability stuff end 20180528 16:34:14< gfgtdf> (2) is probably easy to implement 20180528 16:34:43< EliDupree> 2: How is it easy to implement without 1? How can the engine tell whether your script uses the new APIs? 20180528 16:35:24< EliDupree> 1: if you use wesnoth.current.version in multiplayer at all, you're already taking your own risks regarding synchronization, so I don't see the problem 20180528 16:36:25< EliDupree> I guess maybe there could be something where scripts could detect the minimum version among all players and then decide what APIs to use based on that 20180528 16:37:12< gfgtdf> EliDupree: my thought was more about thinks that have mo mltiplayer problem like colring things 20180528 16:38:32< gfgtdf> so if wesnoth woudl disable a certain api unless your addon has a min_wesnoth version flag couldn't support both versions. 20180528 16:39:19< EliDupree> Ah, yeah, that makes sense for campaigns. I was just thinking about multiplayer because that's the trickier system to handle 20180528 16:41:01< gfgtdf> i wonder whether we cna por the standard mapgen to lua nd if yes whether it'd be slower 20180528 16:59:14-!- matth1askrgr [matthiaskr@gateway/shell/panicbnc/x-mezwhxqzmzfmdzie] has quit [Changing host] 20180528 16:59:14-!- matth1askrgr [matthiaskr@unaffiliated/matthiaskrgr] has joined #wesnoth-dev 20180528 16:59:14-!- matth1askrgr [matthiaskr@unaffiliated/matthiaskrgr] has quit [Changing host] 20180528 16:59:14-!- matth1askrgr [matthiaskr@gateway/shell/panicbnc/x-mezwhxqzmzfmdzie] has joined #wesnoth-dev 20180528 16:59:24-!- matth1askrgr is now known as matthiaskrgr 20180528 17:16:13< mattsc> gfgtdf: That fix to the [filter][and] evaluation works, thanks. Two quick follow-up questions just to confirm that I understand this correctly. 20180528 17:16:51< mattsc> 1. I assume this applies to all filters, not just SUFs? 2. Is it guaranteed that the [and] tags are executed in the order in which they appear inside [filter]? 20180528 17:17:09< mattsc> The latter certainly seems to apply for the test I have done so far. 20180528 17:17:46< mattsc> *tests 20180528 17:17:51< gfgtdf> 2) yes, 1) what exactly do you mean by 'this' ? 20180528 17:18:22< gfgtdf> usually all filter are impleented distictly (they share no code currently) 20180528 17:18:33< mattsc> on 1) “this” = the fix you did to the [and] tag. 20180528 17:18:52< mattsc> Ah, okay, so that’s a “no” on 1. then 20180528 17:19:27< mattsc> I didn’t actually check out where your fix was applied in the C++ code. 20180528 17:19:40< mattsc> Does it need to be applied to the other filters too then? 20180528 17:19:40< gfgtdf> well they shre no coe but its sill likeley that the ll bheve liek that in that regard 20180528 17:20:15< gfgtdf> i'd basicially ned to chek all the filter implementations (unitside,location,attack i think?) 20180528 17:20:29< mattsc> Okay. 20180528 17:20:31< gfgtdf> side filter are somewhat special 20180528 17:20:33< gfgtdf> becasue 20180528 17:21:09<+discordbot1> Trying to debug the "negative HP causes damage prediction to assert" bug. 20180528 17:21:23<+discordbot1> It has calculated a nice -75% chance to kill the enemy. 20180528 17:21:27< gfgtdf> there the 'get_all_matches' is not implemented as 'foreach loc: if matches(log) res.add(loc' 20180528 17:21:35<+discordbot1> (Not a typo. Negative 75 percent.) 20180528 17:22:36< gfgtdf> jyrkive: can' you just make the damage predicction code exit early in that case ? usually a unit has no hp=> no attacks will be made => final outcome is the same as the initial state 20180528 17:22:40< mattsc> jyrkive: maybe it’s a unit with the plague special? ;) 20180528 17:23:10< mattsc> 75% chance of having two units afterward! 20180528 17:23:24< mattsc> (I’m just kidding, in case that wasn’t clear) 20180528 17:23:32<+discordbot1> I'd prefer to figure out why exactly it's happening. 20180528 17:23:41<+discordbot1> For one thing, neither unit has drain. 20180528 17:24:47< gfgtdf> mattsc:becasue some speciasl failters can be implement faster, for example get_locations{x=9,y=7} will immidiateley just return (9,7) which (that it it does not compare for every he whether its x is 9 and its x is 7) 20180528 17:25:14< gfgtdf> so optmizing location filters is somewhat harder than optimizing unit filters 20180528 17:26:14< mattsc> gfgtdf: Okay. Well, the application I need is for SUFs anyway. 20180528 17:27:00< mattsc> I think I can now change the method of finding units with moves that satisfy a give filter quickly, without having to split things up into a “basic filter” and an “advanced filter". 20180528 17:28:09< gfgtdf> that filter location canprobably also be moved toa formula= (if formula has a distance beween hexes function, whihc i think it does) 20180528 17:28:39< mattsc> “that filter”? The one in my example? 20180528 17:28:50< gfgtdf> ye 20180528 17:29:16< mattsc> Ah, okay. That was really just an example. I was secifically looking for a filter that has a long evaluation time, and that one did nicely. 20180528 17:29:23< gfgtdf> ah ok 20180528 17:29:46< mattsc> Oh, I do have one more question. 20180528 17:30:08< mattsc> You said that formulas including $ do not get compiled and are therefore slower. 20180528 17:30:24< mattsc> Does that apply only to the formula part of the filter, or the entire filter? 20180528 17:31:24< mattsc> As in, if my first [and] contains ‘formual = moves > 0’ only, will that part still be fast? 20180528 17:31:57< mattsc> … even if there’s something with $this_unit in the next [and] tag? 20180528 17:32:11< gfgtdf> for the entire filter but it more relevant for formula attributes as there comiling really can be slow, 'compiling' somethign like 'level=8' is rather fast 20180528 17:32:30< mattsc> Okay. 20180528 17:33:28< gfgtdf> also using $this_unit also always invokes an implicit [store_unit] for the filtered unit 20180528 17:34:00< mattsc> Okay. 20180528 17:34:05< mattsc> Actually, I just tested it. 20180528 17:34:24< gfgtdf> so what was your result? 20180528 17:34:46< mattsc> Patience, I am trying to copy/paste something. I’m not that fast. ;) 20180528 17:35:20< mattsc> If I change the second filter from my examples above to: “{ 'and', { formula = '$this_unit.moves = 0' } }” then: 20180528 17:35:48< mattsc> It’s slow when that is the first filter, but if I put the one without $this_unit first, it is as fast as if the second were not there. 20180528 17:36:01< mattsc> Only if no units match the first filter, of course. 20180528 17:36:06< mattsc> So yes, it is still fast. 20180528 17:36:53< mattsc> So, as far as my current use case is concerned, I am good. Thanks. 20180528 17:37:15< mattsc> That was a “good bug” to get fixed! 20180528 17:37:21< gfgtdf> yes every attrobute gets comiled o its own, if one atribute has $this_unit the other attributes (that don't contai $) get compiled normalls. 20180528 17:38:21< gfgtdf> i somehow fear that it casues oos when the second filter has side effects, but i think it's worth it. i don't think there are addons that rely on that 20180528 17:38:58< mattsc> What kind of side effects? 20180528 17:41:33< gfgtdf> for example formula="2d2 = 2" in a synced context for filters that matche a unit randomly 20180528 17:42:23< mattsc> Hmm … 20180528 17:42:56< Ravana_> that has chance to not match anything at all, so would need to be handled in separate code anyways 20180528 17:43:57< EliDupree> … Imagine a leadership ability that used random numbers to determine whether a unit gets led 20180528 17:45:42< mattsc> gfgtdf: Is this issue new because of the change you made earlier, or was it already present before (I do understand that it is different now; I think) 20180528 17:46:04< gfgtdf> whihc issue? 20180528 17:46:18< mattsc> The potential for OOS. 20180528 17:49:06< gfgtdf> that's my last chnge, but i still say it's worth it. 20180528 17:51:48< mattsc> Okay. Yes, I think that was a bug that needed to be fixed. 20180528 18:06:30<+discordbot1> https://github.com/wesnoth/wesnoth/commit/fe83a30c68604c0e4cbcf00ff32395929cc8efa2#diff-ba78ed15e0546fba9e33170000e9a1a4R899 20180528 18:06:47<+discordbot1> ...just what is that division (at line 899 back then) trying to do? 20180528 18:07:24<+discordbot1> From what I can tell, it should apply to the whole formula, not only the second part. And it should be multiplication, not division. 20180528 18:08:11<+discordbot1> That line is causing liiiiiittle problems now when I have finally corrected the calculation of alive_prob and it's zero like it should... 20180528 18:12:37< mattsc> @jyrkive I think I agree with your assessment. 20180528 18:12:53< mattsc> … having thought about it a whole lot less than you. 20180528 18:13:51< mattsc> No … wait ... 20180528 18:15:03< mattsc> Probability of opponent being alive is 1 - prob of it being dead. But prob of being dead only exists when the attacker is alive. 20180528 18:15:21< mattsc> So I think it should be a multiplication, but only apply to the second part of the equation. 20180528 18:15:49<+discordbot1> As far as I can tell, the reason to bring alive_prob into it is: if we're dead, the opponent won't attack us. 20180528 18:16:19< mattsc> Right. 20180528 18:16:23<+discordbot1> So it's used to scale the probability of being attacked. 20180528 18:17:08< mattsc> But also of the opponent being attacked - which is what this line is about, is it not? 20180528 18:17:38<+discordbot1> one_strike_fight() is used only when both opponents have one (or zero) attacks. 20180528 18:18:22<+discordbot1> (If the opponent has first strike, combatant::fight() calls itself with the combatants reversed. "We" always refers to the unit that hits first.) 20180528 18:18:45<+discordbot1> Thus, at this point we have already attacked and only the opponent's counterattack is left. 20180528 18:20:17< mattsc> So alive_prob is the probability that we survived, right? 20180528 18:20:39<+discordbot1> The probability we're alive at the start of the battle. 20180528 18:20:58<+discordbot1> The AI can call attack prediction with units which may be either alive or dead. 20180528 18:21:21< mattsc> right 20180528 18:21:42<+discordbot1> one_strike_fight() doesn't account at all for the possibility that the units may be guaranteed dead at the start of the battle, due to the negative HP thing. 20180528 18:22:14< mattsc> And opp.summary[0][0] is the chance that opponent is dead when ? 20180528 18:22:44<+discordbot1> Probability they're dead after our only strike. 20180528 18:23:27<+discordbot1> BTW, looks like I got the issue fixed. My "probability to kill is negative" breakpoint is still hit, though. reporting a probability of -1.1102230246251565e-016. 20180528 18:23:33< mattsc> Right, so I still think what I said earlier is correct? 20180528 18:23:40<+discordbot1> I may need to add some clamping here... 20180528 18:25:20< mattsc> As in, it should be a multiplication, but only on the second part of the equation in l.899. 20180528 18:25:47<+discordbot1> one_strike_fight() has been updated after that commit. hit_chance is now adjusted for alive_prob, and thus opp.summary0 (now renamed to opp_hp_dist[0]) already takes into account that the attacker may be already dead. 20180528 18:26:07< mattsc> Okay … 20180528 18:26:18< mattsc> I thought I was replying to your earlier question. 20180528 18:27:04< mattsc> 20180528 18:07:24<+discordbot1> From what I can tell, it should apply to the whole formula, not only the second part. And it should be multiplication, not division. 20180528 18:27:49<+discordbot1> Well, there are two things to consider: 1) because attacker may be already dead, the probability to kill defender is lower, and 2) the defender won't bother to attack at all if the attacker is already dead. 20180528 18:28:07<+discordbot1> And I think that line is trying to adjust for 2). 20180528 18:28:33<+discordbot1> But completely screwing it up, by applying to a wrong part of the equation and using a wrong operator. 20180528 18:31:38< mattsc> Tell me if I should stop bugging you with it, but I still haven’t wrapped my head around it completely. 20180528 18:32:18< mattsc> So, let’s say alive_prob = 33%. Meaning I have a 2/3 chance of being killed before this fight even started, right? 20180528 18:32:39<+discordbot1> Yes, that's what it means. 20180528 18:32:48< mattsc> Let’s also say that I have no chance to kill the opponent with my one strike. 20180528 18:33:02< mattsc> That means opp.summary[0][0] = 0 ? 20180528 18:33:18<+discordbot1> Yes. 20180528 18:33:23-!- irker141 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20180528 18:33:41< mattsc> So, in that case, opp_alive_prob should be 1, right? 20180528 18:34:00< mattsc> The opponent is guarenteed to survive in that situation? 20180528 18:34:12<+discordbot1> I'm not sure. 20180528 18:34:25<+discordbot1> The probability that the opponent is alive is 1, obviously. 20180528 18:34:31< mattsc> Sorry, actually opp.summary[0][0] = 0 ... 20180528 18:34:51< mattsc> Oh, right, that’s what I said, sorry. :P 20180528 18:35:02< mattsc> (looked at the wrong line) 20180528 18:35:10<+discordbot1> I think that variable is also serving the additional duty of telling the probability the opponent will counterattack. 20180528 18:35:38< mattsc> Oh, okay, that is a different thing. 20180528 18:36:26< mattsc> I just went by what the variable name says, and not by what is done with it later. Sorry. 20180528 18:37:02<+discordbot1> It's okay. This code is really difficult to understand. :/ 20180528 18:37:43< mattsc> I’d suggest in that case to change the variable name (if it’s still the same in the current version), so that it is not accidentally used for two things that don’t have the same value. 20180528 18:38:01<+discordbot1> And apparently no one has noticed that one_strike_fight() is giving completely wrong results when invoked by AI for units which are likely to be dead... 20180528 18:38:26<+discordbot1> (It helps that attacks with just one strike are rare, I guess.) 20180528 18:38:27< mattsc> Yeah, I know this thing is complex. I do some of those things in my own AI code. It always takes me a while to figure out what’s going on even in the coe I wrote myself. 20180528 18:39:02< mattsc> Well, it also has no directly visible effect when that happens. 20180528 18:39:12< mattsc> So the AI might chose a slightly sub-ideal attack. 20180528 18:39:32< mattsc> The AI does all kinds of sub-ideal things, this might simply not stick out as one of the bad offenders. 20180528 18:40:29< mattsc> I got to go right now though (saying that since you won’t see me log out from irc). We can pick this up again later, if there’s anything left. 20180528 18:43:58-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20180528 19:04:45-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180528 19:10:40-!- irker528 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20180528 19:10:40< irker528> wesnoth: Jyrki Vesterinen wesnoth:1.14 8fbf58e10a71 / src/actions/attack.cpp: Revert "Allow modifying dead units in more event handlers" https://github.com/wesnoth/wesnoth/commit/8fbf58e10a71bd02b98ff45dcbfb27fa9c1b4b0c 20180528 19:10:40< irker528> wesnoth: Jyrki Vesterinen wesnoth:1.14 76652d5905e4 / src/ (game_events/pump.cpp game_events/pump.hpp units/unit.cpp): Revert "Throw a Lua exception when creating a negative-HP unit in a Lua context" https://github.com/wesnoth/wesnoth/commit/76652d5905e4b8fe8e9f2108442f028126c39c80 20180528 19:10:41< irker528> wesnoth: Jyrki Vesterinen wesnoth:1.14 ca96a2ba6107 / src/ (actions/attack.cpp units/unit.cpp units/unit.hpp): Revert "Allow modifying dead units in last_breath and die event handlers" https://github.com/wesnoth/wesnoth/commit/ca96a2ba61073bc2ef309b3ee5cf60ac94478eca 20180528 19:10:42< irker528> wesnoth: Jyrki Vesterinen wesnoth:1.14 43c964fe3f41 / src/ (scripting/lua_unit.cpp units/unit.cpp): Revert "Disallow units with negative HP" https://github.com/wesnoth/wesnoth/commit/43c964fe3f41092443eeb35c1eec9155d7845096 20180528 19:10:43< irker528> wesnoth: Jyrki Vesterinen wesnoth:1.14 00c056616322 / src/attack_prediction.cpp: Fix #3042: attack prediction gives wrong results for HP <= 0 units https://github.com/wesnoth/wesnoth/commit/00c05661632237f4d6d4b3638fcf8e8c025d524d 20180528 19:10:45< irker528> wesnoth: Jyrki Vesterinen wesnoth:1.14 6d8957ca5c7a / changelog.md: Changelog entries https://github.com/wesnoth/wesnoth/commit/6d8957ca5c7a017d01105fd28f091d8bec491fc1 20180528 19:15:24< irker528> wesnoth: Jyrki Vesterinen wesnoth:master 70be1d2932be / src/actions/attack.cpp: Revert "Allow modifying dead units in more event handlers" https://github.com/wesnoth/wesnoth/commit/70be1d2932be67e19dff5afd680c8405b3325b57 20180528 19:15:26< irker528> wesnoth: Jyrki Vesterinen wesnoth:master 58dca3a8848b / src/ (game_events/pump.cpp game_events/pump.hpp units/unit.cpp): Revert "Throw a Lua exception when creating a negative-HP unit in a Lua context" https://github.com/wesnoth/wesnoth/commit/58dca3a8848b66f92e4f2b228e775dde1b000634 20180528 19:15:28< irker528> wesnoth: Jyrki Vesterinen wesnoth:master 050bb3fa2c8d / src/ (actions/attack.cpp units/unit.cpp units/unit.hpp): Revert "Allow modifying dead units in last_breath and die event handlers" https://github.com/wesnoth/wesnoth/commit/050bb3fa2c8d3e1422fe11e56909cfaba63d9aac 20180528 19:15:30< irker528> wesnoth: Jyrki Vesterinen wesnoth:master 0200487aad71 / src/ (scripting/lua_unit.cpp units/unit.cpp): Revert "Disallow units with negative HP" https://github.com/wesnoth/wesnoth/commit/0200487aad71816b843a8c542b3b0c394c5c87d8 20180528 19:15:32< irker528> wesnoth: Jyrki Vesterinen wesnoth:master 472b0cbbfbcd / src/attack_prediction.cpp: Fix #3042: attack prediction gives wrong results for HP <= 0 units https://github.com/wesnoth/wesnoth/commit/472b0cbbfbcdde4e32f26a1cb5afaa5ffd6c7a88 20180528 19:15:34< irker528> wesnoth: Jyrki Vesterinen wesnoth:master ae8baa63560b / changelog.md: Changelog entries https://github.com/wesnoth/wesnoth/commit/ae8baa63560bd89ffb6c0319fda4ee708ff40ff5 20180528 19:19:44< mattsc> @jyrkive I like the amount of explanation you provide in your commit messages! 20180528 19:23:07< mattsc> And just to add to my previous point, I once had a rather serious bug in one of my AIs where I calculated percentage damage done in follow-up attacks w.r.t to the original HP (before the first fight) rather than w.r.t to the HP going into the current battle. 20180528 19:23:33< mattsc> It actually even had a rather serious consequence in that the AI preferred to attack units with full HP rather than taking easy kills. 20180528 19:23:56< mattsc> But it still took forever to make the connection to this bug, as it is not at all obvious why an AI does what it does sometimes. 20180528 19:24:08< mattsc> So it does not surprise me that this has gone unnoticed for so long. 20180528 19:25:09<+discordbot1> Heh, AI preferring to attack fully-healed units sounds quite funny. 😄 20180528 19:26:51< mattsc> It is. But you could even ascribe a certain logic to it. If you calculate damage done as HP / max_HP * unit_value, you can do much more damage when you attack a unit with lots of HP. 20180528 19:27:02< mattsc> Which is what I thought was going on, until I found the bug. 20180528 19:27:53< mattsc> I figured that the weighting of HP damage vs. kill damage was off. 20180528 19:27:53< Ravana_> trying to avoid overkilling then 20180528 19:28:23< mattsc> But no, that was just fine, it was just a simple bug that had a one-line fix. 20180528 19:33:10< mattsc> Ah, I misremembered. It was actually the other way around: https://github.com/mattsc/AI-demos/commit/f551ca61373440518adab3ecdcbce8d2029297a7 20180528 19:33:26< mattsc> But the overall point I am trying to make is still the same. :P 20180528 19:34:00< mattsc> Anyway, I’ll stop blathering now ... 20180528 19:39:42-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20180528 19:55:42-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180528 20:45:53-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20180528 21:56:10-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds] 20180528 22:15:17<+discordbot1> double free or corruption (!prev) 20180528 22:16:05<+discordbot1> I got this completely randomly just now by launching the tutorial, skipping dialogues, toggling Planning Mode, returning back to the main menu, setting language to Spanish, and trying to launch the tutorial again. I think it happened on the loading screen. 20180528 22:16:12<+discordbot1> I don’t expect to see it happen again. 20180528 22:16:22< irker528> wesnoth/wesnoth:1.14 gfgtdf 7be39c937d fix unit filter always evaluating [and] AppVeyor: All builds passed 20180528 22:16:42<+discordbot1> This is a message from GNU libc (followed by SIGABRT) informing of heap corruption, btw. 20180528 22:17:26<+discordbot1> Oh hey, I'm pleasantly surprised. It actually keeps happening. 20180528 22:18:16<+discordbot1> I just need to start the game, launch the Tutorial, press Escape thrice, go back to the main menu, and launch the Tutorial again. No extra steps needed. 20180528 22:20:13<+discordbot1> I don't have time to produce or look at a debug build right now but you can see the backtrace in an -O3 clearly involving the loadscreen near the top of the stack: https://pastebin.com/7wPXYwK2 20180528 22:25:04-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20180528 22:38:42< gfgtdf> hmm doesn't happen to me (officil 1.14.2 windows release) 20180528 22:41:48<+discordbot1> Colour me unsurprised. 20180528 22:42:07<+discordbot1> If it involves the loading screen it's bound to behave differently for everyone. That's why it was a mistake to make it threaded in the first place. 20180528 22:47:50-!- gallaecio [~quassel@188.79.96.255] has quit [Remote host closed the connection] 20180528 22:52:04-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20180528 23:18:27-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180528 23:51:04-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20180528 23:52:07<+discordbot1> How about this? https://pastebin.com/BQcQnYdU 20180528 23:53:03<+discordbot1> What else can I do to help debug this infrequent but rather embarassing issue? 20180528 23:55:21< gfgtdf> you could add 'disable_loadingscreen_animation=yes' in your prefernces file and see whether it still happens 20180528 23:56:35< celticminstrel> That's quite a mouthful. --- Log closed Tue May 29 00:00:13 2018