--- Log opened Mon May 14 00:00:22 2018 --- Day changed Mon May 14 2018 20180514 00:00:22< mattsc> Now, can I avoid the same problem I had with the MESSAGE commit ... 20180514 00:02:04< mattsc> Ugh. Conflicts … 20180514 00:03:39-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has joined #wesnoth-dev 20180514 00:06:57-!- louis94 [~~louis94@91.176.171.238] has quit [Ping timeout: 240 seconds] 20180514 00:07:54< mattsc> Google on how to resolve merge conflicts: talk to the other person :P 20180514 00:09:19< mattsc> Doesn’t really work when the other person is me. 20180514 00:09:24< mattsc> I don’t like talking to myself. 20180514 00:12:02< celticminstrel> XD 20180514 00:12:31< celticminstrel> When there's a merge conflict, the files with conflicts will contain merge markers, like <<<<<<< and such. 20180514 00:12:40< celticminstrel> So you can just search for that and manually fix each one. 20180514 00:12:55< celticminstrel> Then stage the files as you normally would for changed files. 20180514 00:13:00-!- lipkab [~the_new_l@109-61-8-190.adsl-fix.dravanet.hu] has joined #wesnoth-dev 20180514 00:13:32< celticminstrel> That said, the other person probably isn't yourself, it's whoever made the conflicting commit on master. 20180514 00:13:49< celticminstrel> Also, what I described only works for change-change conflicts. 20180514 00:13:59< celticminstrel> Where two people changed the same file in conflicting ways. 20180514 00:14:48-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has quit [Quit: ancestral] 20180514 00:15:28< mattsc> Well, that’s true. And in at least on of those cases the other person is you. ;) 20180514 00:16:31< mattsc> Thanks — I know in principle how to do it, I just haven’t done it in a while. And if I had more than 5 minutes at a time at the computer today, I’m sure I’d be done already. 20180514 00:18:29-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has joined #wesnoth-dev 20180514 00:18:30< mattsc> But the way it is, I’m off again. Blargh. Oh well, I guess I don’t have to rush to get it in before 1/15/0! 20180514 00:34:16<+discordbot> how come battle_context_unit_stats passes a raw unit pointer to specials_context when the function expects a unit_const_ptr (currently an intrusive_ptr)? 20180514 00:34:46< celticminstrel> Who knows! 20180514 00:35:02<+discordbot> looks like I can't use shared_ptr for unit_ptr because of this 20180514 00:35:16< celticminstrel> Unless you fix it, yes. 20180514 00:35:40< celticminstrel> Which I guess likely means snowballing the change through multiple scopes. 20180514 00:35:52<+discordbot> very difficult 20180514 00:36:41-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has quit [Quit: ancestral] 20180514 00:41:14< irker612> wesnoth: doofus-01 wesnoth:1.14 4e5dc5aa58cf / data/campaigns/Under_the_Burning_Suns/ (4 files in 2 dirs): pathfinder defense animation https://github.com/wesnoth/wesnoth/commit/4e5dc5aa58cf1a89249862f70e5acd32931fd31b 20180514 00:41:16< irker612> wesnoth: doofus-01 wesnoth:1.14 8e7e6d10ae2d / data/campaigns/Under_the_Burning_Suns/ (3 files in 2 dirs): outrider defense animation https://github.com/wesnoth/wesnoth/commit/8e7e6d10ae2d5a667093646f2c35969bc14e7a34 20180514 00:42:17< irker612> wesnoth: doofus-01 wesnoth:master fc639f6cc000 / data/campaigns/Under_the_Burning_Suns/ (4 files in 2 dirs): pathfinder defense animation https://github.com/wesnoth/wesnoth/commit/fc639f6cc00089b6549df37cc80981f15b5c01f8 20180514 00:42:19< irker612> wesnoth: doofus-01 wesnoth:master a943e1c55d69 / data/campaigns/Under_the_Burning_Suns/ (3 files in 2 dirs): outrider defense animation https://github.com/wesnoth/wesnoth/commit/a943e1c55d69c433a7705271686bb32dad32cf8e 20180514 00:55:49< celticminstrel> Oh yeah, @Vultraz still didn't say whether that was okay to merge... 20180514 00:55:59< celticminstrel> 3094 20180514 00:56:21< irker612> wesnoth: Thom Diment wesnoth:master b7b6ff34dfd0 / data/campaigns/Northern_Rebirth/maps/05a_01_The_Pursuit.map: changed SE path to remove 1-hex bottlenecks https://github.com/wesnoth/wesnoth/commit/b7b6ff34dfd0ec17e50cdaf6b676a6477f71710a 20180514 00:56:45<+discordbot> i trust the change is reasonable 20180514 00:57:20< celticminstrel> ... 20180514 00:57:26< celticminstrel> You should've used squash and merge. 20180514 00:57:34< celticminstrel> So that the campaign prefix was included. 20180514 00:57:55< celticminstrel> I was going to merge it myself after you gave the okay, actually. 20180514 00:57:57<+discordbot> but there's one one commit 20180514 00:58:01< celticminstrel> ? 20180514 00:58:11< celticminstrel> But squash still rewords the commit message. 20180514 00:58:21< celticminstrel> So it can be useful even if there's only one commit. 20180514 00:58:48<+discordbot> ah 20180514 00:58:50< irker612> wesnoth: Thom Diment wesnoth:1.14 cc4a14cf4b9e / data/campaigns/Northern_Rebirth/maps/05a_01_The_Pursuit.map: NR S5.1: changed SE path to remove 1-hex bottlenecks https://github.com/wesnoth/wesnoth/commit/cc4a14cf4b9e80bb305200f211662a7331cb6b41 20180514 00:59:01<+discordbot> well there i added the prefix to the backport 20180514 01:13:30-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has joined #wesnoth-dev 20180514 01:19:25-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has quit [Quit: ancestral] 20180514 01:20:41-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has joined #wesnoth-dev 20180514 01:22:43-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has quit [Client Quit] 20180514 01:25:32-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 01:25:34-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20180514 01:25:46-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has joined #wesnoth-dev 20180514 01:27:40-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has quit [Client Quit] 20180514 01:45:32-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has joined #wesnoth-dev 20180514 02:27:14-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180514 02:50:26< irker612> wesnoth: doofus-01 wesnoth:1.14 30c2b950d98b / data/campaigns/Under_the_Burning_Suns/ (6 files in 2 dirs): quenoth fighter attack animation https://github.com/wesnoth/wesnoth/commit/30c2b950d98ba9328f2719c2fc16ade41f232ddb 20180514 02:50:28< irker612> wesnoth: doofus-01 wesnoth:1.14 535de2dec14d / data/campaigns/Under_the_Burning_Suns/units/quenoth/Fighter.cfg: clean-up of unit cfg https://github.com/wesnoth/wesnoth/commit/535de2dec14d2587da875984bc8123fd9c17a1a4 20180514 02:51:31< irker612> wesnoth: doofus-01 wesnoth:master 90fefabc4e24 / data/campaigns/Under_the_Burning_Suns/ (6 files in 2 dirs): quenoth fighter attack animation https://github.com/wesnoth/wesnoth/commit/90fefabc4e24b2ed99791c21d75c6d2c3eaf6c19 20180514 02:51:33< irker612> wesnoth: doofus-01 wesnoth:master 16d5bc502857 / data/campaigns/Under_the_Burning_Suns/units/quenoth/Fighter.cfg: clean-up of unit cfg https://github.com/wesnoth/wesnoth/commit/16d5bc50285705c5bf1dabc3dbdd0ec1e1707e04 20180514 02:54:32< irker612> wesnoth: mattsc wesnoth:master 138107c8f6d9 / data/lua/ (backwards-compatibility.lua wml-flow.lua wml-utils.lua wml/objectives.lua): Lua code: replace deprecated wesnoth.tovconfig() calls https://github.com/wesnoth/wesnoth/commit/138107c8f6d9cfce6348fc262fbbe4f48d7d7cb8 20180514 03:04:20< irker612> wesnoth: mattsc wesnoth:master f1764d182fe3 / data/ (15 files in 8 dirs): Lua code: replace deprecated wesnoth.get_variable() calls https://github.com/wesnoth/wesnoth/commit/f1764d182fe33c4e29c6bd42761be2e946cd0c94 20180514 03:04:48< mattsc> Hmm … 20180514 03:04:57<+discordbot> hm? 20180514 03:05:34< celticminstrel> Looks like you missed most of the commits? 20180514 03:05:49< celticminstrel> Unless they had already been applied on master? 20180514 03:09:50< mattsc> I didn’t miss them. I just didn’t do them yet. 20180514 03:10:06< mattsc> Because for some reasons what I am doing causes conflicts with src/video.cpp 20180514 03:10:12< mattsc> Thus: Hmm …. 20180514 03:11:37<+discordbot> 😕 20180514 03:13:28< mattsc> I’ll get them done, don’t worry. 20180514 03:13:59< mattsc> As I said before (maybe), I am mostly running around today, coming by here occasionally for a few minutes trying to get the next step done. 20180514 03:14:15< mattsc> Not the most efficient way of doing things, but I’ll get there. Eventually. 20180514 03:17:12< irker612> wesnoth: Charles Dang wesnoth:master ba0a12b918b1 / data/core/units.cfg: Clarify the Dunefolk are human https://github.com/wesnoth/wesnoth/commit/ba0a12b918b1e4d64c122525f4f208be41f68ccb 20180514 03:18:05< irker612> wesnoth: Charles Dang wesnoth:1.14 91c0cafdaafd / data/core/units.cfg: Added Dunefolk description from master https://github.com/wesnoth/wesnoth/commit/91c0cafdaafda71ac78a92285de8a5a7434d936c 20180514 03:18:24<+discordbot> Our translators will be so happy 20180514 03:21:00<+discordbot> I wonder what the "Triaged" status for bugs is supposed to imply on the VS dev community 🤔 20180514 03:21:00< irker612> wesnoth: mattsc wesnoth:master 0f157bff27fd / data/lua/core.lua: Prevent definition of wml.variables to cause deprecation warnings https://github.com/wesnoth/wesnoth/commit/0f157bff27fd4db281695710c059b7898d394e8a 20180514 03:21:54<+discordbot> @mattsc why not just make it not use get/set_variable at all? 20180514 03:21:59<+discordbot> oh wait 20180514 03:22:00<+discordbot> I see 20180514 03:22:09<+discordbot> you can't use a metatabe before the metatable is contructed 20180514 03:22:44< mattsc> :) 20180514 03:25:13< mattsc> Btw, there are still a few instances of the FOREACH macro out there which cause a helluva lot of deprecation warnings (as in, way more than there are instances of the macro). 20180514 03:25:28< mattsc> I’ll get to those sometime over the next few days. 20180514 03:27:41<+discordbot> eep 20180514 03:27:55<+discordbot> begone, FOREACH 20180514 03:29:25 * mattsc takes a note: remember you can creep out @Vultraz by mentioning the FOREACH macro 20180514 03:30:47< celticminstrel> XD 20180514 03:31:42< celticminstrel> @Vultraz I'll eventually make it not use get/set_variable at all, though. 20180514 03:32:58< celticminstrel> ...how do they cause more warnings than there are instances... are you pressing F5 a lot? 20180514 03:32:59<+discordbot> @Vultraz Triaging a bug report means initial analysis and categorization. 20180514 03:33:38< celticminstrel> So basically what people on Wesnoth sometimes neglect... though that's getting a lot better recently, which is good. 20180514 03:34:09<+discordbot> When a bug report is triaged, the developers check if it's a duplicate of an existing report or intentional behavior, as well as categorize it and optionally assign it to a suitable developer. 20180514 03:35:02<+discordbot> I think your bug reports is likely to get assigned to Stephan T. Lavavej (STL), who is in charge of Microsoft's C++ standard library implementation. 20180514 03:35:18<+discordbot> *report 20180514 03:36:07< irker612> wesnoth: mattsc wesnoth:master ce7faae4f41f / data/ (26 files in 6 dirs): Lua code: replace deprecated wesnoth.set_variable() calls https://github.com/wesnoth/wesnoth/commit/ce7faae4f41f23f1d1f61d2b4f5ca95d4ce4f89a 20180514 03:36:13<+discordbot> Figured something like that 20180514 03:38:42-!- shiki [~Shiki@p548553E4.dip0.t-ipconnect.de] has joined #wesnoth-dev 20180514 03:38:42-!- sevu [~Shiki@p548547E5.dip0.t-ipconnect.de] has quit [Disconnected by services] 20180514 03:39:14-!- travis-ci [~travis-ci@ec2-54-211-155-161.compute-1.amazonaws.com] has joined #wesnoth-dev 20180514 03:39:15< travis-ci> wesnoth/wesnoth#18163 (master - f1764d1 : mattsc): The build passed. 20180514 03:39:15< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/378541380 20180514 03:39:15-!- travis-ci [~travis-ci@ec2-54-211-155-161.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180514 03:39:42<+discordbot> I actually filed 2 additional bugs 20180514 03:39:58<+discordbot> one for the compiler error that cropped up in the dispatcher when switching to c++17 mode 20180514 03:40:08<+discordbot> and the other one for the warning celmin said was spurious 20180514 03:40:48< celticminstrel> What was that, again? 20180514 03:40:54< celticminstrel> ...oh right, the std::get thing. 20180514 03:40:56<+discordbot> discarding value 20180514 03:41:02<+discordbot> of function with nodiscard 20180514 03:41:42<+discordbot> i expect that one might come back invalid in the end 20180514 03:41:48<+discordbot> but the other one is definitely a bug 20180514 03:42:01< celticminstrel> Yeah, "nodiscard" doesn't really make sense on a function that returns a reference, unless it's also satisfied by assigning to the reference. I don't know if this is a compiler bug (nodiscard behaving inappropriately) or a library bug (the function being inappropriately marked nodiscard). 20180514 03:42:15< celticminstrel> Where is this issue filed? 20180514 03:43:08<+discordbot> https://developercommunity.visualstudio.com/content/problem/251812/spurious-c4834-warning.html 20180514 03:43:11<+discordbot> https://developercommunity.visualstudio.com/content/problem/251769/invalid-syntax-error-when-building-variable-with-t.html 20180514 03:43:24<+discordbot> https://developercommunity.visualstudio.com/content/problem/251213/stdfilesystemfile-time-type-does-not-allow-easy-co.html 20180514 03:43:28<+discordbot> the three issues I filed 20180514 03:45:46< celticminstrel> It's possible that the second one is a case where the typename keyword should be used. 20180514 03:45:58< celticminstrel> Or no, the template keyword I guess. 20180514 03:46:11< irker612> wesnoth: Charles Dang wesnoth:master 8f93d0a7c67f / src/ (9 files in 3 dirs): Saved Game: reame "starting pos" to "starting point" to avoid confusion https://github.com/wesnoth/wesnoth/commit/8f93d0a7c67f77e3917c5a24c55a9d450579a423 20180514 03:46:25<+discordbot> If that's the case, why did it not appear until I switched to c++17 mode? 20180514 03:46:40< celticminstrel> Dunno. 20180514 03:46:45< celticminstrel> But does this work? 20180514 03:46:48< celticminstrel> dispatcher::template signal_type& signal = dispatcher_implementation::event_signal(*ritor_widget.first, ritor_widget.second); 20180514 03:47:03<+discordbot> I didn't test 20180514 03:47:10< celticminstrel> Or maybe dispatcher::template signal_type& signal = dispatcher_implementation::template event_signal(*ritor_widget.first, ritor_widget.second); 20180514 03:47:34< celticminstrel> Might be useful to try it though. 20180514 03:47:56< celticminstrel> I do think the use of auto is preferable, but knowing whether those versions work could maybe be useful for the bug report? 20180514 03:48:10< celticminstrel> I think the second version is unlikely FTR. 20180514 03:48:42< celticminstrel> There's also this to consider: typenanem dispatcher::signal_type& signal = dispatcher_implementation::event_signal(*ritor_widget.first, ritor_widget.second); 20180514 03:48:47< celticminstrel> ... 20180514 03:48:58< celticminstrel> That should be typename at the beginning. 20180514 03:49:03< celticminstrel> typename dispatcher::signal_type& signal = dispatcher_implementation::event_signal(*ritor_widget.first, ritor_widget.second); 20180514 03:49:10<+discordbot> first one gives Error C2760 syntax error: unexpected token '<', expected 'declaration' 20180514 03:49:18< EliDupree> Well this is definitely an interesting situation. I have an on_mouse_action callback that invokes [delay]. If you click again during the delay, that second click becomes a unit move – but the move doesn't happen until the first callback returns, *and its destination is determined by the position of the mouse AFTER the first callback returns* 20180514 03:49:21< celticminstrel> Hmm, okay. 20180514 03:49:39<+discordbot> same for the second 20180514 03:50:02< celticminstrel> Hmm, okay. 20180514 03:50:07< celticminstrel> And the third? 20180514 03:50:25< celticminstrel> Admittedly these were all long shots since "dispatcher" doesn't look like a template type. 20180514 03:50:27<+discordbot> same for the third 20180514 03:51:56<+discordbot> EliDupree: the engine reads the position of the mouse when it starts processing the click event. 20180514 03:52:05<+discordbot> In other words, after the [delay]. 20180514 03:52:10<+discordbot> It's expected behavior. 20180514 03:52:29< celticminstrel> IMO expected behaviour would be that mouse clicks are dropped during the delay? 20180514 03:52:35< EliDupree> yeah 20180514 03:52:37<+discordbot> celmin: I just need to wait and see what they say 20180514 03:52:38< celticminstrel> At least left clicks. 20180514 03:52:52< EliDupree> You shouldn't be able to give move orders during a callback of any kind 20180514 03:53:37< irker612> wesnoth: mattsc wesnoth:master 64f7ad256022 / data/ (lua/core.lua test/scenarios/test_clear.cfg): Lua code: replace deprecated wesnoth.get_all_vars() calls https://github.com/wesnoth/wesnoth/commit/64f7ad256022426040ef9e13ad7941b6bec789a8 20180514 03:53:39< irker612> wesnoth: mattsc wesnoth:master f153279e87aa / data/scenario-test.cfg: Lua code: replace deprecated helper.get_variable_proxy_array() call https://github.com/wesnoth/wesnoth/commit/f153279e87aa8b5a22c3f0d371bb40d9580f09eb 20180514 03:53:39< celticminstrel> I think delay calls the mouse_action function so that the game doesn't become completely unresponsive during the delay, allowing you to quit to the menu for example. 20180514 03:53:41< irker612> wesnoth: mattsc wesnoth:master f0bb40590fe1 / / (40 files in 5 dirs): Lua code: replace deprecated helper.get_child() calls https://github.com/wesnoth/wesnoth/commit/f0bb40590fe1a9c2c6683157f9aa93b631848251 20180514 03:53:43< irker612> wesnoth: mattsc wesnoth:master 7c137e1a3365 / data/ (14 files in 5 dirs): Lua code: replace deprecated helper.child_range() calls https://github.com/wesnoth/wesnoth/commit/7c137e1a336559acdd6f797192a9516135480b2e 20180514 03:53:45< irker612> wesnoth: mattsc wesnoth:master 3c792fc7d774 / data/ (5 files in 4 dirs): Lua code: replace deprecated helper.[gs]et_variable_array() calls https://github.com/wesnoth/wesnoth/commit/3c792fc7d774c96ef467847a6267a71a2f731f96 20180514 03:53:47< irker612> wesnoth: mattsc wesnoth:master 08a000a7daab / data/ai/scenarios/scenario-AI_Arena_small.cfg: Lua code: remove deprecated helper.set_wml_var_metatable() call https://github.com/wesnoth/wesnoth/commit/08a000a7daabb74f6dd7370c1b2b95f3e83e5501 20180514 03:53:49< irker612> wesnoth: mattsc wesnoth:master 1684e2f5daa6 / data/ (8 files in 5 dirs): Remove unnecessary inclusions of helper.set_wml_action_metatable {} https://github.com/wesnoth/wesnoth/commit/1684e2f5daa6b84906186b101c83a6a017b07581 20180514 03:53:51< irker612> wesnoth: mattsc wesnoth:master 4b6681a300f2 / / (38 files in 12 dirs): Do not load helper.lua where it is not used any more https://github.com/wesnoth/wesnoth/commit/4b6681a300f29eab3b5adcf3b12df8bc6ad455dd 20180514 03:53:53-!- travis-ci [~travis-ci@ec2-54-92-247-212.compute-1.amazonaws.com] has joined #wesnoth-dev 20180514 03:53:54< travis-ci> wesnoth/wesnoth#18164 (master - 0f157bf : mattsc): The build passed. 20180514 03:53:54< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/378544154 20180514 03:53:54-!- travis-ci [~travis-ci@ec2-54-92-247-212.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180514 03:54:05< mattsc> So nice when there are no conflicts ... 20180514 03:54:11< mattsc> I think that’s all now ^ 20180514 03:54:13< celticminstrel> \o/ 20180514 03:54:31< EliDupree> I'm not totally sure why this happens in on_mouse_action but not another events (e.g. when I call [delay] in an unsynced menu item and you click during the delay, this problem doesn't happen) 20180514 03:54:35<+discordbot> these are als on 1.14? 20180514 03:54:54< celticminstrel> ? 20180514 03:55:01< celticminstrel> Oh. 20180514 03:55:06< celticminstrel> Yeah they were merged to 1.14 hours ago. 20180514 03:55:21<+discordbot> gud, gud 20180514 03:55:23<+discordbot> gud work 20180514 03:55:48 * celticminstrel drops a giant wheel of gouda on Vultraz. 20180514 03:56:21<+discordbot> 🧀 20180514 03:57:08< celticminstrel> That shows up as a box. :( 20180514 03:57:33<+discordbot> it's a cheese wedge 20180514 03:57:56< celticminstrel> Ah. 20180514 03:58:40< celticminstrel> Maybe I should use the emoji set as an inspiration for goblinese pictograms. >_> 20180514 03:58:53< mattsc> I take the cheese. I like cheese. 20180514 03:59:01< celticminstrel> It seems to have almost everything by now, after all. 20180514 03:59:34< celticminstrel> (And just FTR I don't mean Wesnoth goblins.)3 20180514 04:00:11< mattsc> Hmm, too bad. I like goblins too. 20180514 04:00:18< mattsc> Wesnoth goblins. 20180514 04:00:28< mattsc> @Vultraz I think that covers all the deprecation warnings in both 1.14 and master, except for the afore mentioned FOREACH macros. 20180514 04:00:31< celticminstrel> Well, Wesnoth goblins are orcs, so... 20180514 04:01:02< mattsc> Indeed; and some of them are more frustrated by that fact than others. 20180514 04:01:10< celticminstrel> Heh... 20180514 04:01:24< celticminstrel> Have you seen the "revisiting unit descriptions" thread? 20180514 04:01:50< mattsc> Only superficially. 20180514 04:03:56< mattsc> (that ‘frustrated’ comment was an inside joke referring to one of my campaigns) 20180514 04:06:34< EliDupree> I also detected wesnoth.current.user_can_invoke_commands flickering from "false" to "true" around when the second click happened, although I haven't determined exactly what situations cause that to happen 20180514 04:09:49< irker612> wesnoth: Severin Glöckner wesnoth:1.14 92a0441fa8d5 / data/tools/wmllint: wmllint: add campaign abilites & specials https://github.com/wesnoth/wesnoth/commit/92a0441fa8d51015e7a629180ff8169906605f2d 20180514 04:10:31< irker612> wesnoth: Severin Glöckner wesnoth:master ed46bc1d2b60 / data/tools/wmllint: wmllint: add campaign abilites & specials https://github.com/wesnoth/wesnoth/commit/ed46bc1d2b605befac33724bc396b2859e4b7e3a 20180514 04:18:23< EliDupree> Figured it out. Wesnoth explicitly constructs a command_disabler when invoking any menu item, but not for on_mouse_action; the only reason it was false was because [delay] ALSO construct a command_disabler, but that meant it was only false during delays, NOT (for instance) during [redraw]s 20180514 04:29:52-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has quit [Quit: ancestral] 20180514 04:29:54-!- travis-ci [~travis-ci@ec2-54-211-155-161.compute-1.amazonaws.com] has joined #wesnoth-dev 20180514 04:29:55< travis-ci> wesnoth/wesnoth#18167 (master - 4b6681a : mattsc): The build passed. 20180514 04:29:56< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/378549434 20180514 04:29:56-!- travis-ci [~travis-ci@ec2-54-211-155-161.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180514 04:30:51< irker612> wesnoth/wesnoth:master Thom Diment 11743b28ca DW 5 Tirigaz - Changes to orc leader dea AppVeyor: vs2015/Debug Failed 20180514 04:30:52< irker612> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-3333 20180514 04:31:27-!- APic [apic@apic.name] has quit [Ping timeout: 240 seconds] 20180514 04:32:05< EliDupree> Aha, I found a terrible, terrible work around. Simply invoke wesnoth.select_unit with fire_event = true, which has an explicit command_disabler, then do the real logic inside the select event. 20180514 04:32:28< celticminstrel> XD 20180514 04:35:03-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has joined #wesnoth-dev 20180514 04:39:00-!- APic [apic@apic.name] has joined #wesnoth-dev 20180514 04:46:42< EliDupree> Alternatively, [do_command] to fire an event – but also [allow_undo] because the only thing I need a synced context for is the fact that it has a command_disabler 20180514 04:48:16< EliDupree> Assuming said usage of allow_undo works at all, anyway… 20180514 04:57:26-!- shiki [~Shiki@p548553E4.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 20180514 04:59:43-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] 20180514 05:04:57-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has quit [Quit: ancestral] 20180514 05:17:38-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has joined #wesnoth-dev 20180514 05:32:55-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has quit [Quit: ancestral] 20180514 05:37:51-!- ancestral [~anonymous@71.34.19.123] has joined #wesnoth-dev 20180514 05:43:27-!- ancestral [~anonymous@71.34.19.123] has quit [Quit: ancestral] 20180514 05:43:54-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has joined #wesnoth-dev 20180514 06:07:41< irker612> wesnoth/wesnoth:master Thom Diment 95f5aa8439 UtBS 5: changes to scenario locations AppVeyor: vs2015/Debug Failed 20180514 06:07:42< irker612> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-3334 20180514 06:11:12-!- ancestral [~anonymous@71-34-19-123.mpls.qwest.net] has quit [Quit: ancestral] 20180514 06:27:47-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180514 06:46:29< irker612> wesnoth/wesnoth:1.14 doofus-01 07071be141 changing layering of Bcx bridges for dea AppVeyor: All builds passed 20180514 07:06:03-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Quit: Caught sigterm, terminating...] 20180514 07:06:26-!- Ivanovic [~ivanovic@p579FB6E5.dip0.t-ipconnect.de] has joined #wesnoth-dev 20180514 07:06:27-!- Ivanovic [~ivanovic@p579FB6E5.dip0.t-ipconnect.de] has quit [Changing host] 20180514 07:06:27-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev 20180514 07:19:49-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Quit: Caught sigterm, terminating...] 20180514 07:20:14-!- Ivanovic [~ivanovic@p579FB6E5.dip0.t-ipconnect.de] has joined #wesnoth-dev 20180514 07:20:34-!- Ivanovic [~ivanovic@p579FB6E5.dip0.t-ipconnect.de] has quit [Changing host] 20180514 07:20:34-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev 20180514 07:51:07<+discordbot> 20180514 03:50:27 error display: could not open image 'data/add-ons/Naia/images/units/faeries/dryad.png ' 20180514 07:51:19<+discordbot> Note the trailing whitespace. 20180514 07:51:39<+discordbot> (This comes up in the context of the difficulty menu built using the legacy menu syntax.) 20180514 07:58:26< irker612> wesnoth/wesnoth:1.14 doofus-01 8d5c148127 changing layering of Bcx bridges for dea AppVeyor: All builds passed 20180514 08:18:29<+discordbot> Huh 20180514 08:19:53<+discordbot> Also the [endlevel] call in the Naia [bug] dialog is supposed to signal defeat. I get the Victory notification instead. 20180514 08:20:26<+discordbot> (As well as the outro screen, for some mysterious reason.) 20180514 08:21:38<+discordbot> That is to say, for some reason it counts not just as a victory, but also as the end of the campaign. 20180514 08:22:49<+discordbot> hasn't that been the case for years now? 20180514 08:22:54<+discordbot> No. 20180514 08:22:57<+discordbot> I seem to recall that even in early 1.13.0 20180514 08:23:05<+discordbot> It wasn't in 1.12.x. 20180514 08:24:43<+discordbot> ping celmin about the difficulty thing 20180514 08:24:46<+discordbot> he edited it last 20180514 08:24:54<+discordbot> it was working last i checked 20180514 08:24:58<+discordbot> (befor ehis edits) 20180514 08:25:08<+discordbot> I haven't said at any point that it doesn't work. 20180514 08:25:24<+discordbot> it says could not open image 😐 20180514 08:25:33<+discordbot> Because the path has a trailing whitespace. 20180514 08:25:42<+discordbot> Or had, rather. In the WML. 20180514 08:26:02<+discordbot> oh, so it's a problem with your code 20180514 08:26:23<+discordbot> Since we don't support uploading paths with whitespace in them I don't see why Wesnoth should acknowledge trailing and leading whitespace. 20180514 08:26:59<+discordbot> It's rather late for 1.14 but it might be worth considering changing this behaviour in 1.16. 20180514 08:27:00<+discordbot> Feel free to implement removing whitespace if you want. 20180514 08:27:04<+discordbot> a boost::trim can be thrown in there somewhere 20180514 08:27:47<+discordbot> So, what's the easiest way to get Wesnoth back to the main menu from Lua? 20180514 08:29:14<+discordbot> not sure... 20180514 08:30:20<+discordbot> @jyrkive btw, been meaning to ask...I've figured out what decltype does and how its useful, but perhaps you could explain what declval is used for? 20180514 08:30:45<+discordbot> I haven't ever used declval myself. 20180514 08:31:15<+discordbot> And I'm not really interested to look up its usage, either. You can probably find something in Stack Overflow. 20180514 08:31:24<+discordbot> alright 20180514 08:31:43<+discordbot> I've tried reading its page on cppr multiple times but it doesn't seem to make much sense. >_> 20180514 08:31:57<+discordbot> so I'm guessing it's rather niche 20180514 08:32:04<+discordbot> decltype is quite useful tho 20180514 08:34:03<+discordbot> I suspect the problem is that the [endlevel] logic doesn't account for a situation where there aren't any sides defined. 20180514 08:34:24<+discordbot> because that's never supposed to happen 20180514 08:37:48<+discordbot> Yeah, there seem to be sides. 20180514 08:38:16<+discordbot> There must be something broken in the endlevel logic though. 20180514 08:42:35<+discordbot> Where is it defined? 20180514 08:47:12<+discordbot> Scheduling the [endlevel] action to run on prestart fixes my issue. 20180514 08:51:43<+discordbot> Using preload instead of prestart also works. 20180514 08:52:16<+discordbot> Apparently whe running the global [lua] code, wesnoth.current.event_context.name is _from_lua. 20180514 08:53:16<+discordbot> Also, not all wesnoth.wml_actions.wml_message calls have an effect for some reason. 20180514 08:54:03<+discordbot> I'm so completely unsurprised by this. 20180514 08:55:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 09:02:49-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has quit [Disconnected by services] 20180514 09:03:18-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev 20180514 09:07:07<+discordbot> So came up with this "fix": https://github.com/project-ethea/Naia/commit/bea066c0a59567129a7ec7ff34d58b8cebe67274 20180514 09:21:22< gfg> Most of the endlvel logic is defined in Lua 20180514 09:21:58< gfg> (endlevel.lua) 20180514 09:22:13<+discordbot> And I couldn't follow it or even inject log messages. 20180514 09:22:30<+discordbot> Half of the log messages (some of them in my campaign) seem to just vanish into the void. 20180514 09:23:34< gfg> do you use print() or std_print()? 20180514 09:24:03<+discordbot> I use wesnoth.wml_actions.wml_message. 20180514 09:25:07<+discordbot> Incidentally, I've seen a similar issue with only the last #deprecate line of some mainline macros like {MAGENTA_IS_THE_TEAM_COLOR} actually appearing in stderr. 20180514 09:25:20<+discordbot> I'm on Linux and stderr is a file. 20180514 09:25:28<+discordbot> ... a regular file, to clarify. 20180514 09:29:53< gfg> Hmm i don't see what could be wrong with wml_message, but when i debugged the whiteboard i also suffered from missing log messages and had to replace LOG_WB lines with std::cert 20180514 09:30:00< gfg> cerr* 20180514 09:30:52< irker612> wesnoth/wesnoth:master Thom Diment 11743b28ca DW 5 Tirigaz - Changes to orc leader dea AppVeyor: 2/4 builds failed 20180514 09:30:53< irker612> Details vs2015/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-3333 20180514 09:30:54< irker612> Details vs2017/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-3046 20180514 09:43:19< irker612> wesnoth/wesnoth:master Severin Glöckner ed46bc1d2b wmllint: add campaign abilites & special AppVeyor: vs2017/Debug Failed 20180514 09:43:19< irker612> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-3065 20180514 09:50:46-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180514 09:50:52-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180514 09:57:04<+discordbot> 20180514 05:56:44 info wml: error 20180514 09:57:09<+discordbot> What the heck 20180514 10:00:17<+discordbot> wesnoth.wml_actions.wml_message({ logger = loglvl_map[math.max(1, math.min(lvl, #loglvl_map))], message = "[Naia] " .. msg }) 20180514 10:00:20<+discordbot> So I have this. 20180514 10:00:32<+discordbot> And logger ends up evaluating to "error". 20180514 10:00:47<+discordbot> And that results in "error" being printed at the info loglevel. 20180514 10:10:52<+discordbot> lua wesnoth.wml_actions.wml_message { logger = "error", message = "hello world" } wesnoth.wml_actions.wml_message { logger = "error", message = "[Naia] " .. msg } wesnoth.wml_actions.wml_message { logger = "error", message = "hello world" } 20180514 10:10:57<+discordbot> Gives 20180514 10:11:02<+discordbot> 20180514 06:10:35 error wml: hello world 20180514 06:10:35 info wml: error 20180514 06:10:35 error wml: hello world 20180514 10:11:21<+discordbot> What the heck is going on??? 20180514 10:13:08-!- gfg [~androirc@tmo-106-17.customers.d1-online.com] has quit [Read error: Connection reset by peer] 20180514 10:15:58-!- gfg [~androirc@134.76.63.8] has joined #wesnoth-dev 20180514 10:17:53<+discordbot> It seems like it takes offense to message containing linebreaks. 20180514 10:18:47<+discordbot> No, that's not it. 20180514 10:19:05-!- gfgt [~androirc@tmo-106-17.customers.d1-online.com] has joined #wesnoth-dev 20180514 10:19:58-!- gfg [~androirc@134.76.63.8] has quit [Ping timeout: 240 seconds] 20180514 10:20:06<+discordbot> Oh I see. 20180514 10:20:29<+discordbot> I'm using wesnoth.textdomain() on the message. 20180514 10:22:17<+discordbot> Apparently that works fine everywhere else except on the wesnoth.wml_actions.wml_message call. 20180514 10:24:15<+discordbot> Using tostring() fixes it. :\ 20180514 10:26:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180514 10:28:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 10:38:08<+discordbot> @loonycyborg you don't have any pending changes to server.cpp do you 20180514 10:38:52<+discordbot> not atm 20180514 10:39:05<+discordbot> you want to change something there? 20180514 10:39:31-!- vladimirslavik [vslavik@nat/redhat/x-inudocdeeqnjmxsm] has joined #wesnoth-dev 20180514 10:40:17<+discordbot> Reformatting. I think I noticed a few of your crash fixes had to do with misplaced/missing brackets, so I'm reformatting some of the server files, which includes adding All The Brackets. 20180514 10:40:38<+discordbot> I'm going to be honest here. 20180514 10:40:48<+discordbot> I don't trust you to not break the server more in the process. 20180514 10:41:16<+discordbot> (Especially since you probably aren't going to bother with trying to build with fuh enabled.) 20180514 10:41:46<+discordbot> I can add fuh 20180514 10:41:59<+discordbot> but I'm not touching fuh 20180514 10:42:15<+discordbot> That was one reason, not the only reason. 20180514 10:46:02<+discordbot> Make a PR, and if you stumble upon anything that you've got the slightest doubt about what it's actually supposed to work like, ask. 20180514 10:47:38<+discordbot> Incidentally I believe I'm putting off responding to celmin with regards to a proposal I haven't seen which I suspect is controversial to some degree. 20180514 10:48:08<+discordbot> Only inasmuch as you have already seen. 20180514 10:50:00-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev 20180514 10:50:04-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Client Quit] 20180514 10:50:09<+discordbot> That doesn't tell me anything. 20180514 10:53:11<+discordbot> I wonder what Soliton's opinion is with regards to the eventual addition of Dave's PRNG as a user visible option (which you imply will be made into such in a future 1.14.x release since you're talking about allowing "more intrusive changes" in). I assume it'll remain limited to single player mode anyway. 20180514 10:53:34<+discordbot> That was the idea 20180514 10:53:50<+discordbot> Perhaps I should offer context to that remark of mine. 20180514 11:00:21<+discordbot> Dave has mentioned to me he believes we should restructure our release process so we can get things out to people faster. Which I agree with. Three-and-a-half years between major patches (from the perspective of a casual player) isn't great. He mentioned getting some buildbots set up so we could have a Dota-like model with frequent, small patches and less frequent, large patches. Which, incidentally, is something I had already been 20180514 11:00:21<+discordbot> considering before this given we now have instant, quick distribution via Steam. I even talked to you about it, I think. Obviously, we can't just suddenly switch our model overnight, but I've decided to make some small changes. For example, dispatching translation updates to Steam on a weekly basis, and loosening what is allowed in stable. There won't be any WML/Lua API changes, but things like Dave's PRNG option, ancestral's hotkey changes, 20180514 11:00:22<+discordbot> campaign map updates/changes/redraws, and some engine refactors would be allowed. I still need to work how how we'd handle the big feature releases, though, since master is right now in such a sorry state we might end up having to go through another cycle of our current model just to get it sorted. But in the meantime, less radical changes can get into players' hands quickly. Dave even basically said he wouldn't want to contribute any more 20180514 11:00:22<+discordbot> if his changes took months to get to them. 20180514 11:00:39<+discordbot> I have a nagging suspicion that you're about to steal my brand with a text wall. 20180514 11:00:50<+discordbot> And there we go 20180514 11:02:21<+discordbot> You saying Dave said that implies he was a regular contributor to begin with. 20180514 11:02:25<+discordbot> I think allowing non-bugfix changes in the stable branch is a good idea. 20180514 11:02:58<+discordbot> You probably meant to phrase it the other way around entirely. He's not been a code contributor since 2009. 20180514 11:03:44<+discordbot> Yeah, he more implied he would be likely to return if he could get his changes out to people "within a week" 20180514 11:03:48<+discordbot> If you want to say he may be persuaded to help around again with such a system that's a more reasonable argument than putting it like it's some kind of emotional blackmail on us. 20180514 11:04:03<+discordbot> I wouldn't trust that kind of promises, to be honest. 20180514 11:04:43<+discordbot> Saying that you're about to contribute is a thousand times easier than actually doing it. 20180514 11:05:39<+discordbot> Also, colour me highly skeptical of your proposal when you factor in things that are bug vectors rather than just bug fixes. 20180514 11:06:16<+discordbot> I think we should try to avoid risky changes, too. 20180514 11:06:35<+discordbot> After all you yourself have a notable track record with changes that cause more issues than they fix, and in particular that take forever to be fixed. 20180514 11:06:37<+discordbot> To be fair, he came to me just last Tuesday asking what was up with master since he had tried to build it and the result was of course broken. And he then made a commit for the first time in years since then. After having tossed the idea around both in private and on the Frogatto server. So it's not as if he's done nothing 20180514 11:06:52<+discordbot> Just to be fair 20180514 11:07:11<+discordbot> I am aware he decided to contribute a patch again after his 9 years break. 20180514 11:07:24<+discordbot> There's pretty much no way we couldn't be aware. 20180514 11:07:27<+discordbot> (that was directed at jyrki) 20180514 11:07:42< irker612> wesnoth/wesnoth:master Thom Diment 95f5aa8439 UtBS 5: changes to scenario locations AppVeyor: 2/4 builds failed 20180514 11:07:43< irker612> Details vs2015/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-3334 20180514 11:07:44< irker612> Details vs2017/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-3047 20180514 11:08:06<+discordbot> A lot of gears are turning right now, to be honest. 20180514 11:08:12<+discordbot> In a whole bunch of areas. 20180514 11:08:46<+discordbot> (and yes I took your suggestions about the thing we discussed and mentioned them) 20180514 11:10:30<+discordbot> Anyway, one thing I really hate is talking through carrier pigeons, so hopefully he'll be willing to talk about this instead of just using you to enact changes on his behalf. 20180514 11:11:19<+discordbot> After all this is still a community-developed project. 20180514 11:12:15<+discordbot> And by the way discussing ideas on a server that isn't ours doesn't count as proper discussion of ideas. 20180514 11:13:39<+discordbot> I told him he should speak to Yumi, but I did also say it'd probably be best not to immediately go talking about it in public before it was ready. I didn't expect hi to have it ready that quickly. 20180514 11:14:09<+discordbot> What does a Discord mod have to do with this? 20180514 11:14:26<+discordbot> (To be clear, I didn't tell him to discuss it on the other server, he brought it up there) 20180514 11:14:28<+discordbot> Why exactly the alternative PRNG implementation shouldn't have been discussed in public? 20180514 11:14:42<+discordbot> (Or was it something else you're talking about?) 20180514 11:14:42<+discordbot> Yumi seemed knowledgeable about the topic. 20180514 11:14:57<+discordbot> And they're not a project member. 20180514 11:15:08<+discordbot> At least not as far as I know. 20180514 11:15:26<+discordbot> They seem to have taken statistics. I referred Dave on the matter of the theoretical implementation. 20180514 11:16:03<+discordbot> I was more concerned with the whole bypassing the project thing you've got going on. 20180514 11:16:27<+discordbot> @jyrkive given the level of controversy the RNG has generated over the years, I didn't want there to be a whole lot of peanut gallery shouting before there was anything concrete to show. 20180514 11:16:31<+discordbot> I'm not against the idea of the alternative PRNG itself. 20180514 11:16:50<+discordbot> I'd very much want the peanut gallery to shout as early as possible. 20180514 11:17:02<+discordbot> Forcing changes down people's throats isn't going to do you any favours though. 20180514 11:17:18<+discordbot> Especially when those people help you keep this show running. 20180514 11:17:21<+discordbot> The worst option is that they start shouting when the change is already in a stable release and changes are difficult to make. 20180514 11:17:22<+discordbot> I'm not forcing any change. I just wanted there to be something to comment on first. 20180514 11:17:52<+discordbot> Both the fact that it's going to be in 1.14 and can be changed based on feedback are part of what I meant when I said more permissive changes 20180514 11:18:27<+discordbot> Dave never intended this to be The Final Implementation 20180514 11:18:30<+discordbot> As soon as it's in a stable release, you can bet there will be factions of players who want to change it to opposite directions. 20180514 11:18:38<+discordbot> Anyway it'd be nice if the feature could taint saves for now. 20180514 11:18:44<+discordbot> The existing implementation will be the lowest common denominator. 20180514 11:19:05<+discordbot> That is, mark them clearly as saves/replays that will break until the implementation is set in stone. 20180514 11:19:11<+discordbot> The right time to get feedback is before releasing it. 20180514 11:19:30<+discordbot> Otherwise you'd be violating the stable release compatibility grantee. 20180514 11:20:24<+discordbot> Good point 20180514 11:24:41<+discordbot> I'll admit I'm rather removed from the technical side of the PRNG discussion because I don't really fully understand the underlying mathematical and design concepts at play (right now). 20180514 11:26:41<+discordbot> So perhaps more feedback is important to developing it 20180514 11:26:53<+discordbot> Or perhaps you'd end up with too many cooks who don't know what they really want 20180514 11:27:15<+discordbot> That's what I'm afraid of. 20180514 11:27:26<+discordbot> Was that valid? I don't know 20180514 11:34:20<+discordbot> In any case, as this is an open source project, I strongly believe we should do everything in public by default. 20180514 11:34:29<+discordbot> Only security bug fixes should be an exception. 20180514 11:34:54< Soliton> i haven't read anything about "Dave's PRNG" yet (i was gone the past few days still catching up) but hearing that it's supposed to be an option is already a good sign. as has just been pointed out compatibility is perhaps the most difficult part. we don't want to tweak things and constantly break replays/saves or if necessary only replays/saves that use the new PRNG. 20180514 11:35:56< Soliton> not sure if there is much use to restrict it to sp since with save/replay considerations you're already pretty much considering mp as well. 20180514 11:39:59< Soliton> i wonder how we'd get proper feedback to fine tune a PRNG implementation though. that seems really difficult to judge. 20180514 11:40:54<+discordbot> https://github.com/wesnoth/wesnoth/pull/3104 Got that little red cross next to it. That mean I screwed up? 20180514 11:41:28< Soliton> might not be because of your change that the build failed. 20180514 11:42:00<+discordbot> https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-3047/job/7ncbkrotcvci7s2b 20180514 11:42:06< Soliton> if you just did wml/lua changes for example it's not very likely your fault. 20180514 11:42:29<+discordbot> c:\projects\wesnoth\src\desktop\windows_tray_notification.cpp(138): error C2039: 'hBalloonIcon': is not a member of '_NOTIFYICONDATAW' [C:\projects\wesnoth\projectfiles\VC14\wesnoth.vcxproj] c:\program files (x86)\windows kits\8.1\include\um\shellapi.h(1029): note: see declaration of '_NOTIFYICONDATAW' 20180514 11:42:46<+discordbot> Looks completely unrelated to UnwiseOwl's changes. 20180514 11:42:49<+discordbot> Oh. 20180514 11:42:54<+discordbot> Excellent. I love it when stuff is not my fault. 20180514 11:43:17<+discordbot> Could it be because of the bump _WIN32_WINNT bump to Windows 7? 20180514 11:43:55<+discordbot> Well, it raises more questions. 20180514 11:44:05<+discordbot> Starting from why the release builds are passing. 20180514 11:45:21<+discordbot> https://github.com/wesnoth/wesnoth/commits/master?after=ed46bc1d2b605befac33724bc396b2859e4b7e3a+69 20180514 11:45:49<+discordbot> Looks like changing _WIN32_WINNT is when these problems started. 20180514 11:46:05< Soliton> another idea about the PRNG thing. i think what most people do not like is their lack of agency when the RNG does not go their way. it might be more useful to add different ways to stack the odds in your favour. perhaps through generic modifications. (like this xp mod is somewhat in that direction? haven't tried it yet.) 20180514 11:47:01<+discordbot> https://github.com/wesnoth/wesnoth/commit/2a585118d8b6c4b37d0ff9446a72ca20419ff7f7#diff-b4c3028e3df0a310e30eee28aff9a9b9 20180514 11:47:09<+discordbot> @jyrkive Are the "release builds" (not sure what you mean since this is a master-specific change) built with Mingw-w64? 20180514 11:47:25<+discordbot> No, they're also built with Visual Studio. 20180514 11:47:34<+discordbot> Yes, but against what SDK? 20180514 11:47:44<+discordbot> I'm pretty sure you could use Mingw-w64 with VC++ if you wanted. 20180514 11:48:15<+discordbot> The point is that it tends to exhibit some differences in some regards compared to the official Windows SDK. 20180514 11:50:24<+discordbot> It's Windows 10 SDK version 10.0.26624. 20180514 11:50:28<+discordbot> https://www.appveyor.com/docs/build-environment/#windows-sdks 20180514 11:50:39<+discordbot> Same for both Debug and Release builds. 20180514 11:53:13<+discordbot> Okay, I found the problem. 20180514 11:53:37<+discordbot> In that commit, Vultraz changed _WIN32_WINNT only for the Release configuration. 20180514 11:53:56<+discordbot> It's still set to Windows XP for all other configurations, including Debug. 20180514 11:54:33<+discordbot> Apparently setting _WIN32_WINNT to pre-Vista hides hBalloonIcon. 20180514 12:16:12<+discordbot> They should really make managing those configurations easier.. 20180514 12:17:12<+discordbot> do i need to switch to each one 20180514 12:18:34<+discordbot> or is there somewhere to set settings for all of them 20180514 12:23:17<+discordbot> Have you fixed the main menu music issue when loading saves? 20180514 12:24:01<+discordbot> No 20180514 12:24:42<+discordbot> I had a fix, but I never committed it since celmin was looking at it too but I don't think anyting came o fit 20180514 12:25:03<+discordbot> Insert rant here. 20180514 12:32:13<+discordbot> @Vultraz You can select "All Configurations" to edit all configurations at once. 20180514 12:34:47<+discordbot> hm.... 20180514 12:35:25<+discordbot> except you can't do defines there? 20180514 12:41:06<+discordbot> #defines vary between configurations. It's not a good idea to override them all. 20180514 12:53:27-!- gfgt [~androirc@tmo-106-17.customers.d1-online.com] has quit [Ping timeout: 240 seconds] 20180514 12:56:06-!- gfgt [~androirc@tmo-106-17.customers.d1-online.com] has joined #wesnoth-dev 20180514 13:08:02<+discordbot> For the record, [change_theme] causes a Lua error and aborts the event if no theme= attribute is specified (specifying one set to the empty string works as expected). 20180514 13:08:15<+discordbot> I'll fix it later if I don't forget and no-one beats me to it. 20180514 13:08:44<+discordbot> Discord isn't a great 'record' 20180514 13:09:12<+discordbot> What's that supposed to mean? 20180514 13:11:54<+discordbot> Okay then. 20180514 13:12:16<+discordbot> I don't think I'll forget since the use case concerns me in particular anyway. 20180514 13:15:50< irker612> wesnoth/wesnoth:1.14 Severin Glöckner 92a0441fa8 wmllint: add campaign abilites & special AppVeyor: All builds passed 20180514 14:00:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180514 14:16:26< EliDupree> !! 20180514 14:16:38< EliDupree> While attempting to use the workaround I described yesterday, I have discovered another interesting fact: 20180514 14:17:04< EliDupree> wesnoth.select_unit() never fires events under any circumstances, regardless of whether fire_event argument is true 20180514 14:17:51< EliDupree> Because it disables commands, and mouse_handler::select_hex only enters the if branch where events are fired if commands are not disabled 20180514 14:23:09-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180514 14:23:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180514 14:36:36-!- gfgt [~androirc@tmo-106-17.customers.d1-online.com] has quit [Remote host closed the connection] 20180514 14:41:46< EliDupree> Also, I was wrong: it's not the second click that's turning into a move, it's the first click. So this is a hazard of using on_mouse_action when a unit is selected at all, hmm 20180514 14:43:19< irker612> wesnoth/wesnoth:master Severin Glöckner ed46bc1d2b wmllint: add campaign abilites & special AppVeyor: 2/4 builds failed 20180514 14:43:20< irker612> Details vs2017/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-3065 20180514 14:43:21< irker612> Details vs2015/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/build/Wesnoth-VS2015-master-3352 20180514 14:44:20< EliDupree> Haha, at least I can suppress the move by having the callback deselect the unit. Although that might not be desirable either. 20180514 14:44:27< Ravana_> would be nice if you added such info to https://wiki.wesnoth.org/LuaWML/Events#wesnoth.game_events. Currently it only has what I found out while trying to implement https://github.com/wesnoth/wesnoth/issues/2325 20180514 14:46:26< EliDupree> If I can find my wiki login… 20180514 14:48:16< EliDupree> I don't think there's any hope of me finding my wiki login 20180514 14:49:41< EliDupree> I could write a proper description for someone else to put on the wiki, but I'm not even 100% confident in my understanding, and I don't want to add MORE misinformation there 20180514 15:14:18< mattsc> Does anybody have a start-of-scenario save of DM S20 Prince of Wesnoth they could send me for testing? (compatible with 1.14) 20180514 15:14:32< mattsc> From an actual play-through, I mean, not cl-ing into it. 20180514 15:55:27-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20180514 16:12:45-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev 20180514 16:19:20-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180514 16:36:42-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev 20180514 16:38:03<+discordbot> Seems that if a weapon special changes the damage of the opponent, it's nowhere to be shown in the damage calculation dialogue. 20180514 16:43:56<+discordbot> Please fill an issue at https://bugs.wesnoth.org 20180514 16:47:30<+discordbot> Thanks. Could you eventually add the code snippet with which you experienced this? 20180514 16:55:29<+discordbot> updated. 20180514 16:58:12< mattsc> So … I am not allowed to post in the Steam discussions. :P 20180514 17:24:20<+discordbot> What do you mean? Everyone with a Steam account should be able to. 20180514 17:25:23< mattsc> “Your account is not allowed to post in Battle for Wesnoth discussions.“ 20180514 17:25:54<+discordbot> Do you not have the game or something? 20180514 17:26:21< mattsc> Not through steam, no. 20180514 17:26:40< mattsc> I’m sure it’s seom detail I need to change somewhere, no time to figure out how to do so right now. 20180514 17:26:58<+discordbot> Maybe you need to add the game to your library . 20180514 17:27:05<+discordbot> I literally don't know. 20180514 17:27:09< mattsc> I just figured I quickly give the answer to the HttT bug question, but not luck. 20180514 17:27:15< mattsc> Same here. 20180514 17:30:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 17:43:03-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection] 20180514 17:44:23-!- irker612 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20180514 18:20:50<+discordbot> Yeah you need to have the game to be able to post in steam, that's a thing...or you could get access to the wesnoth dev account, maybe? 20180514 18:21:54-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity] 20180514 18:36:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180514 18:38:25< mattsc> @UnwiseOwl Well, did that (downlaoded the game through Steam and started it once just to make sure it works), but the discussion board still tells me the same. 20180514 18:41:30< mattsc> Huh, looks like they want me to spend money on Stean first … 20180514 18:43:11<+discordbot> Ah. I think it's an anti-spam measure. 20180514 18:43:38<+discordbot> Otherwise it would be too easy for spammers to just download any random F2P game to gain ability to post in Steam. 20180514 18:45:47< mattsc> I find it somewhat sad that smething like that is necessary (which isn’t a comment about Steam …) 20180514 18:47:18<+discordbot> Steam is in fortunate enough position to have literally tens of millions of paying customers. 20180514 18:47:36<+discordbot> The same thing would be very unlikely to work anywhere else. 20180514 18:51:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 18:51:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180514 18:51:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 19:06:43-!- irker839 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20180514 19:06:44< irker839> wesnoth: Jyrki Vesterinen wesnoth:1.14 dc6818799952 / src/ (actions/attack.cpp units/unit.cpp units/unit.hpp): Allow modifying dead units in last_breath and die event handlers https://github.com/wesnoth/wesnoth/commit/dc6818799952c7b76e78c7309a30f8a6a6a7010c 20180514 19:08:39< irker839> wesnoth: Jyrki Vesterinen wesnoth:master 15446acb2ad1 / src/ (actions/attack.cpp units/unit.cpp units/unit.hpp): Allow modifying dead units in last_breath and die event handlers https://github.com/wesnoth/wesnoth/commit/15446acb2ad1fd7990e52e7194480820c4923596 20180514 19:19:40-!- vladimirslavik [vslavik@nat/redhat/x-inudocdeeqnjmxsm] has quit [Quit: Leaving] 20180514 19:20:48-!- Bhoren [~Bhoren_wh@2a01:e0a:c:2150:98ff:9d4e:d221:edc6] has joined #wesnoth-dev 20180514 19:51:18-!- atarocch [~atarocch@93.56.164.28] has quit [Remote host closed the connection] 20180514 20:23:06-!- Bhoren [~Bhoren_wh@2a01:e0a:c:2150:98ff:9d4e:d221:edc6] has quit [Quit: Leaving] 20180514 20:25:35< zookeeper> @Vultraz, @shadowm, what is this thing that looks like something being discussed that involves dave and yumi but which you don't want to name? 20180514 20:26:14<+discordbot> We have named it. It’s the PRNG option Dave added 20180514 20:27:32< zookeeper> oh, okay. i thought there was some other topic as well. 20180514 20:28:02<+discordbot> there's a thread for it too: https://forums.wesnoth.org/viewtopic.php?f=6&t=48160 20180514 20:28:41< zookeeper> so if we want to allow more intrusive changes in a stable branch, then sure, but what's the release model for _that_ then? 20180514 20:31:14-!- gfgt [~androirc@134.76.63.8] has joined #wesnoth-dev 20180514 20:31:18< zookeeper> major changes/additions tend to be buggy, so people can't just push stuff that "would be nice in stable too" if we actually want stable to be stable and not a broken mess. 20180514 20:31:27-!- atarocch [~atarocch@93.56.164.28] has joined #wesnoth-dev 20180514 20:31:30<+discordbot> To start with, more intrusive changes, more releases, more often. 20180514 20:32:13-!- sevu [~Shiki@p548553E4.dip0.t-ipconnect.de] has joined #wesnoth-dev 20180514 20:33:30< zookeeper> if we release 1.16.5 and the fancy new intrusive changes break stuff, can users easily roll it back to 1.16.4? 20180514 20:33:40< zookeeper> (in steam, that is) 20180514 20:35:02<+discordbot> No, we’d have to push a revert. 20180514 20:35:39<+discordbot> Thing is, Steam allows us to do that by merit of instantly delivering a mandatory update to everyone. And the patch sizes being small. 20180514 20:35:52<+discordbot> We add something? All the steam people have it 20180514 20:36:01<+discordbot> We need to roll something back? Likewise 20180514 20:36:50<+discordbot> There needs to be a very clear line drawn between "more intrusive changes" and ending up in a perpetual beta. 20180514 20:36:56< zookeeper> mandatory updates? well, sure, that makes sense if the update only consists of bugfixes that really don't introduce more issues. 20180514 20:37:36<+discordbot> also I'm fairly sure there's an option in Steam to turn off auto-updates 20180514 20:37:41<+discordbot> unless this is something else 20180514 20:39:19< zookeeper> i've never gotten to play portal 2 properly because of mandatory auto-updating crap and steam being crap too, so i'm kind of worried about the UX. 20180514 20:41:21<+discordbot> if nothing else, there needs to be some sort of discussion before pushing new features like the alternate PRNG into stable. Otherwise allowing everyone start start pushing new features into 1.14 probably won't end well. 20180514 20:41:24< zookeeper> well, to clarify, i'm not worried about the UX only from a technical POV. no one wants to play a game that constantly pushes updates to you that add new broken stuff that gets fixed in an update next week, and again probably breaking something else. 20180514 20:43:13< zookeeper> aside from so-called diehard fans, people just want to play the game without interruptions and especially without risk of something breaking when they update it. 20180514 20:44:04< zookeeper> and in our case, whenever an update involves intrusive changes, there's very very likely going to be varying levels of brokenness. 20180514 20:44:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20180514 20:45:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 20:52:15< sevu> mattsc, I have trouble with an micro ai 20180514 20:52:32-!- atarocch [~atarocch@93.56.164.28] has quit [Remote host closed the connection] 20180514 20:53:03-!- atarocch [~atarocch@93.56.164.28] has joined #wesnoth-dev 20180514 20:54:15-!- atarocch [~atarocch@93.56.164.28] has quit [Remote host closed the connection] 20180514 20:54:45-!- atarocch [~atarocch@93.56.164.28] has joined #wesnoth-dev 20180514 20:55:16< sevu> I used it like this. https://bpaste.net/show/c8891dd35d9a If the filter contains only the upkeep line, all loyal units of that side are controlled with it. If it contains both lines, all Dwarvish Fighters are controlled, also the non loyal ones, and other loyal units are (as expected) not matched 20180514 20:55:40< zookeeper> in principle, a rolling release model would be great, but you need some very strict procedures in place to make sure only stable and well-tested changes go in the public releases. 20180514 20:57:59-!- atarocch [~atarocch@93.56.164.28] has quit [Remote host closed the connection] 20180514 20:58:14< mattsc> @sevu: That’s strange. That should be a normal use of a [filter] tag. Let me have a look later (can’t right now) and I’ll get back to you. Does this happen when you use that filter for something else (storing units or something) also? 20180514 21:02:48< sevu> All I know right know that it works when using ids instead, will try the filter somewhere else. I can push the changes later, so we have a test case. 20180514 21:03:30-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20180514 21:03:49< zookeeper> besides, managing backwards compatibility (saves and UMC) in a rolling release model seems potentially nightmarish, if you want to still be able to make major intrusive changes. you can't push updates that for example break peoples' existing saves without warning, and it seems unlikely we could actually have such warnings (except in a pointless "we never promise your saves don't break 20180514 21:03:49< zookeeper> after an update" fashion). 20180514 21:05:23<+discordbot> also, good or bad overall, 1.14 being the first release in 3.5 years does give some leeway in terms of being able to say that there are just more people playing and finding bugs now and the significant issues will get patched asap. saying that bugs will get patched asap will start to wear rather thin after it happens a few times within a few months on what's supposed to be the stable branch, though. 20180514 21:09:00<+discordbot> also, to zookeeper's point, being able to say that every couple years or so all add-ons need to be updated to the new stable release seems like it's been something of a saving grace in terms of backwards compatibility overhead, especially given how massive Wesnoth's WML/lua/WFL APIs are. 20180514 21:10:53< zookeeper> players care much less about issues getting patched ASAP than they care about new issues being introduced in the first place. if you have a game and its developers tell you to update it because a new update has cool new stuff, and then it breaks something, then patching it ASAP is the least that can be expected. taken as a whole, it's still a screw-up that interferes with your enjoyment 20180514 21:10:53< zookeeper> of the game, no matter how quickly the issue gets patched. 20180514 21:14:46<+discordbot> zookeeper: Portal 2 has barely been updated in many years. I'm not sure why updates would interfere with you being able to play the game unless this is a dated experience? 20180514 21:15:27< zookeeper> @Denivarius, yes it's dated, from maybe 1-3 years ago... or something like that. 20180514 21:16:44-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 21:16:51<+discordbot> @zookeeper dota patches very often, and every big patch inevitably introduces new bugs 😛 20180514 21:18:08<+discordbot> I mean the only thing Portal 2 was updated for in that time period was releasing on Linux, which shouldn't have affected other platforms, and if you were on Linux, well, it was to ship out bug fixes. 20180514 21:19:37<+discordbot> and I think players appreciate getting regular updates from developers. There is a little angst if things break, but these things happen and with a rolling release they can be fixed quickly. Generally players who play multiplayer are more likely to appreciate quick update cycles than single player focused players, but I would argue that all players would enjoy a quick iteration update cycle. 20180514 21:20:58<+discordbot> I think that it would be more important to define what areas of Wesnoth would be open to more intrusive/frequent changes, rather than comparing Wesnoth to other commercial games that have things like budgets and QA teams. I would assume that changes that would break save games, UMC APIs, etc would not be done on the stable branch, for example. 20180514 21:21:00<+discordbot> but if a player is a single player user of the game and doesn't want updates that is an easy choice for them to make. 20180514 21:21:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds] 20180514 21:22:48<+discordbot> the PRNG option only for campaigns, would be an example, since it's single player only and has to be intentionally enabled/disabled. 20180514 21:23:04<+discordbot> I would argue that Wesnoth's position as an open source game makes it much more suitable for this kind of release model rather than less. We do not (or should not) have the overhead of some bureacratic QA team or whatnot that gets in the way of this kind of development. 20180514 21:24:27-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds] 20180514 21:25:45<+discordbot> But if things like save games, UMC, or even MP between different minor stable releases end up accidentally broken, that's going to push people away, regardless of new features. Ultimately users want a game that works, and works at the time they want to play it. 20180514 21:26:56<+discordbot> Of course. Developers should take care to fix these things and if a developer is developing in an area that might cause regressions like that it is something they should take responsibility for (1) testing before it is released; (2) fixing ASAP if they break it after release. 20180514 21:28:18<+discordbot> it's definitely true that we don't want someone doing development of this type if they can't show the experience and commitment to do those things. 20180514 21:31:13<+discordbot> In any case I personally think that having a rolling release schedule will more than pay for itself in the number of developers we attract. I personally have zero interest in developing for Wesnoth anymore if my changes won't end up in front of end users for a year or more. If it was a week instead of a year things would be different. I think there are other developers like that too. You get someone contributing to a project, 20180514 21:31:13<+discordbot> and they ship a change to a user within days of making it and are getting feedback from users on their change, it is going to be much easier to retain that developer. 20180514 21:34:06-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180514 21:34:16< zookeeper> i find it a very strange coincidence that my internet connection somehow broke (restarting my router worked) right when i was looking at this again in steam. 20180514 21:34:44-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180514 21:35:45<+discordbot> right. I'm not disagreeing with that part, but I would feel a lot more confident that going to such a model would ultimately work if there was some Wesnoth equivalent of the linux kernel's "Don't break userspace" rule for the stable series. As it is, I'm not entirely clear if the intent is to even keep the stable vs development branch distinction, or go full on rolling release. 20180514 21:36:43<+discordbot> wesnoth's automated unit tests are certainly not robust enough to be able to cover such a change. 20180514 21:37:20-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 21:37:40< zookeeper> all right, i'll see if this thing repeats if i launch steam again. if it does i might not go anywhere near it again in the foreseeable future. 20180514 21:38:25-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180514 21:40:43< zookeeper> having steam "downloading" (except it's apparently really not) that portal 2 update very effectively kills all my bandwidth (or something). even when steam says network traffic is in the range of 0-10kb/s 20180514 21:41:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 21:43:03<+discordbot> I mean, it does ask for a certain commitment and responsibility from developers -- yes if you ship something and it breaks people then you need to fix it and fast. Also, utilizing a beta on Steam could work wonders -- have a policy of releasing into beta and then after 24 hours if no problems ship it to all users. 20180514 21:43:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer] 20180514 21:43:18<+discordbot> or even releasing into beta and then a week later releasing to all users. 20180514 21:44:40< zookeeper> oh yeah and this was a pretty recent issue. originally installed portal 2 a year ago, tried playing it in october. yeah, well whatever. if it downloads a 400+mb update at _maybe_ 5kb/s average at best, and makes my internet connection unusable until it's finished (even though this time it didn't _kill_ it), then i'll just not play it then. -.- 20180514 21:46:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 21:48:40<+discordbot> that's not really what I'm trying to understand, though. I'd expect that if someone pushed something and it broke another thing, that they'd either fix it quickly or it'd be reverted until a fix can be implemented. What I'm trying to understand is the scope of the change being proposed. It's hard for me to form a definite opinion on allowing updates to be pushed out to users more quickly when there doesn't seem to be any 20180514 21:48:41<+discordbot> information on what type of changes we're talking about. There's a significant difference between, say, only doing rolling updates for single-player features, compared to going full rolling release and not having a stable vs development branch split. 20180514 21:52:13<+discordbot> Steam has a system to Opt-In for Betas and other such experimental builds, if you want to push stuff over steam but not just to everyone. 20180514 21:53:55<+discordbot> especially if the intention is to go full rolling release, since things like UMC API breakage have generally been handled by the release of a new stable version. right now, if a 1.12 addon or savegame doesn't work in 1.14, then the reason is just given that you can't expect those things to work between major stable releases. 20180514 21:55:23<+discordbot> but it seems like that sort of would quickly irritate UMC creators if any update could potentially break their add-on. 20180514 21:55:56<+discordbot> @Pentarctagon okay so that's a really good question and I think there are a number of ways it can be done. Let me give you one way I think could work really effectively.... 20180514 21:57:40<+discordbot> Wesnoth would have two main branches in github. The "development" branch (or "master"). The "release" branch. If as a developer, you're doing development work you develop in the development branch. You can develop your feature for however you like, an hour, a day, a week, a month. However long it takes. 20180514 21:58:23<+discordbot> As the developer of a feature, you're ready to ship your change. You merge changelists for your feature from the development branch -> release branch. Then, it ships. 20180514 21:58:54<+discordbot> for small, low-risk changes you do this fairly informally and can just do work in development branch, merge to release, ship, all within a week-long iteration 20180514 21:59:43<+discordbot> for larger riskier changes you spend a lot of time developing them in the dev branch. When you feel ready to ship you merge them, but co-ordinate with other developers. "Hey I want to ship this more risky change, so maybe I can have some help testing, and we want to ship what's in the release branch to beta for a while before we ship it to all users." 20180514 22:01:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer] 20180514 22:02:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 22:04:31<+discordbot> Git flow minus feature branches equals to high chances of breakage. Have clean master and release branches... 20180514 22:05:10<+discordbot> And even clean develop branch. 20180514 22:06:06<+discordbot> But API deprecation is decoupled from the release model changes they propose. 20180514 22:07:04<+discordbot> I'm clearly not following the API deprecation part of what's being proposed. 20180514 22:07:57<+discordbot> Because it remains the same. 20180514 22:09:00-!- irker839 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20180514 22:09:49-!- louis94 [~~louis94@91.176.171.238] has joined #wesnoth-dev 20180514 22:10:02<+discordbot> that is not particularly encouraging, given the number of API breaking changes that happened between 1.12 and 1.14. 20180514 22:10:25<+discordbot> especially since there isn't even a definiteive list of all the changes 20180514 22:10:42-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 22:11:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds] 20180514 22:11:44<+discordbot> and this is why we should switch to closed privatized development 20180514 22:11:47<+discordbot> :^) 20180514 22:13:35-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20180514 22:13:37-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180514 22:15:10-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180514 22:16:09<+discordbot> hopefully I'm not coming across as overly negative about the whole idea, but I am very worried about how UMC would be affected by frequent API breakage, since it seems like much of what has kept wesnoth alive for so long is what it enabled people to create. shadowm's and inferno8's UMC, for example, is often cited as the best of what wesnoth has to offer in terms of campaigns. 20180514 22:16:31-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20180514 22:16:55<+discordbot> ie: https://forums.wesnoth.org/viewtopic.php?f=5&t=48156&p=628160#p628151 20180514 22:18:25<+discordbot> @Pentarctagon counterpoint: the fact that so many changes were made between 1.12 and 1.14 over such a long period of time inevitably meant porting is harder, and bugs might not have been spotted. If we had API changes on a rolling release schedule, there would be a lot less for UMC authors to update, and they could probably manage to always have their addons working, as opposed to every few years having everything just possibly 20180514 22:18:25<+discordbot> NOT work 20180514 22:19:45<+discordbot> continuous integration is the future 20180514 22:19:48< zookeeper> @Vultraz, yes, you could update your add-ons a few changes at a time instead of a major port every couple of years, but it _also_ means you never get a break. you might have to do updates every couple of months or whatever. 20180514 22:19:58<+discordbot> Sure 20180514 22:20:11<+discordbot> But those changes would be small 20180514 22:20:59<+discordbot> then a lot more focus needs to be put on documenting and letting people know what those changes actually are, compared to currently. 20180514 22:21:26<+discordbot> and at a certain point, if the changes are frequent enough, then doing it all at once is actually easier. 20180514 22:22:13<+discordbot> We can more easily document changes if they're done in small batches with the expectation that users will need to know about them 20180514 22:22:16<+discordbot> Now 20180514 22:22:23<+discordbot> I'm not proposing an API change every week 20180514 22:22:30<+discordbot> in fact, I said no API changes ins table yesterday 20180514 22:22:52<+discordbot> but, once we get to full rolling release, I think a good compromise would basically be what dota does with its large feature patches 20180514 22:23:10<+discordbot> every few months they have a giant patch that changes a whole bunch of stuff 20180514 22:23:14<+discordbot> so we could do something like that 20180514 22:23:33<+discordbot> keep API changes and larger features part of less frequent, larger patches 20180514 22:23:46<+discordbot> and in the interim, push bug fixes and smaller-scope changes 20180514 22:24:16<+discordbot> so API breakage would only happen every 3 months or 6 months or whatever? 20180514 22:25:03<+discordbot> something like that 20180514 22:25:10<+discordbot> which is better than every 3 years 20180514 22:25:49<+discordbot> okay, that was what I was trying to get a feel for. 20180514 22:25:51< zookeeper> UMC authors, even authors of quality content, aren't all enthusiasts who want to live and breathe the wesnoth UMC development lifestyle. a lot of them just have their campaign or whatever and actually don't want to constantly spend time doing active maintenance on it because the platform underneath keeps changing. 20180514 22:26:09<+discordbot> yeah like if you're developing an API-breaking feature you need to message it ahead of time and get agreement with people. 20180514 22:26:16<+discordbot> and breaking API's every week isn't acceptable 20180514 22:26:31< Ravana_> for API changes it is needed to consider adding, removing and changing differently 20180514 22:26:51-!- irker002 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20180514 22:26:52< irker002> wesnoth: Severin Glöckner wesnoth:1.14 ed1ced196df8 / data/campaigns/Northern_Rebirth/ (maps/02_01_Infested_Caves.map scenarios/02_01_Infested_Caves.cfg): NR S2: balance imporvements between AIs https://github.com/wesnoth/wesnoth/commit/ed1ced196df82bf917efa3860c31e2b33f56cba0 20180514 22:27:17<+discordbot> I would suggest asking some UMC creators what they think though. 20180514 22:27:20< irker002> wesnoth: Severin Glöckner wesnoth:master fd9fc26ca00a / data/campaigns/Northern_Rebirth/ (maps/02_01_Infested_Caves.map scenarios/02_01_Infested_Caves.cfg): NR S2: balance imporvements between AIs https://github.com/wesnoth/wesnoth/commit/fd9fc26ca00a526f1ff266faab6c5283e2e7ee73 20180514 22:27:35<+discordbot> I don't count, since as far as I know or particularly care, I'm the only user of my add-on. 20180514 22:27:40<+discordbot> Having more frequent (but not too frequent) changes also means its easier to catch bugs 20180514 22:28:10<+discordbot> how extensive is the testing stuff? 20180514 22:28:28<+discordbot> We usually rely on players to catch bugs 😬 20180514 22:28:48< zookeeper> a strange thought, though: with a rolling release model, you could limit backwards-compatibility breaking to happen, say, semi-annually or something like that. like, we'd have two releases per year which are allowed to break API compatibility, and thus authors would know well beforehand when they need to make time for updating their stuff. 20180514 22:29:08<+discordbot> Yes, that is a good idea 20180514 22:29:31<+discordbot> 2 - 4 20180514 22:29:34<+discordbot> is a good number 20180514 22:30:02<+discordbot> But obviously we should try to make sure old APIs still work 20180514 22:30:06<+discordbot> but we could also say like 20180514 22:30:12<+discordbot> "we're making x change here" 20180514 22:30:21<+discordbot> "in two big releases this will be dropped" 20180514 22:30:42<+discordbot> which is kinda what we do now with stable series, but just faster 20180514 22:32:31<+discordbot> I also have to ask then, since Wesnoth has a much larger than average proportion of users from Linux - what does this mean regarding people who get Wesnoth from their distro repository? Just tell them to use Steam/the flatpak, or hope the distro packager keeps up? 20180514 22:32:47<+discordbot> Both, i suppose 20180514 22:33:11<+discordbot> I don't really care to care about people who don't like Steam for stupid reasons. 20180514 22:33:25<+discordbot> And there's flatpak 20180514 22:33:47<+discordbot> Well, there are people who care... 20180514 22:34:22<+discordbot> maybe we shouldn't miss the next debian release as we missed the new ubuntu LTS 20180514 22:34:40<+discordbot> (plenty of time still) 20180514 22:34:52<+discordbot> if wesnoth goes to rolling releases, would that even be a question though? 20180514 22:34:55< zookeeper> well, this whole rolling release thing seems potentially pretty steam-centric in the first place, considering we have no in-game update functionality. 20180514 22:35:08<+discordbot> Yes 20180514 22:35:14<+discordbot> We wouldn't be able to do it without Steam 20180514 22:35:47<+discordbot> But conversely, it would be foolish to not take advantage of what we can do with Steam 20180514 22:35:55< zookeeper> ...yeah, well, how would you handle the non-steam releases then? 20180514 22:36:06<+discordbot> we were able to ship a patch a week after 1.14.0 and have it go live to everyone with a minimal, 40 MB or so update 20180514 22:36:27<+discordbot> We need a simpler packaging process 20180514 22:36:36<+discordbot> Automate some stuff 20180514 22:36:42<+discordbot> Dave has suggested buildbots 20180514 22:37:46<+discordbot> what's the current build setup? 20180514 22:38:05<+discordbot> pretty manual, I think, except maybe the flatpak. 20180514 22:38:10<+discordbot> @hrubymar10 and @loonycyborg have to build and package things by hand 20180514 22:38:38<+discordbot> and upload them by hand 20180514 22:39:12<+discordbot> and run pot-update by hand.. 20180514 22:39:16<+discordbot> hmm 20180514 22:39:23<+discordbot> I think @lonnycyborg has a script which does the most part, that could eventualle be incorporated into sth more automatic 20180514 22:39:36<+discordbot> and we need to update the wiki, frontpage, and forums by hand... 20180514 22:39:39<+discordbot> steam by hand... 20180514 22:39:41<+discordbot> i may actually be of some help in this 20180514 22:39:57<+discordbot> flatpak and steam can be fully automated 20180514 22:41:02<+discordbot> but if we'll make automatic updates from 1.14 then commit discipline to it will have to be stricter 20180514 22:41:53<+discordbot> also, I would suggest that at least some of this discussion happen in Coders Corner on the forums, so it's available in a more readable form than the discord/IRC chat history. 20180514 22:42:23<+discordbot> My process could be easily automated 20180514 22:42:51<+discordbot> I can let my server do things and then let upload output somewhere 20180514 22:43:54<+discordbot> how often do you want release automated patches @Vultraz ? 20180514 22:44:04<+discordbot> I have to figure that out 20180514 22:45:06<+discordbot> I just don't know, if it is necessary to change release system. It works now. Yes, we can automatise it more, but that's enough IMO 20180514 22:46:47<+discordbot> It works, but I think it could be better 20180514 22:47:50<+discordbot> Well 20180514 22:48:00<+discordbot> It possibly brings problems to MP games. SourceForge versions of wesnoth won't be compatible with steam version if you won't update both packages 20180514 22:48:03<+discordbot> actually, it depends if you're talking about the technical side of pushing releases 20180514 22:48:14<+discordbot> or the actual release model 20180514 22:48:25<+discordbot> yes, I think we shuld update the SF version too 20180514 22:48:42<+discordbot> which is why I think we need buildbots and stuff to automate that so it can be uploaded easily to both 20180514 22:48:43<+discordbot> and if you will push also SF packages regullary... you know, downloading 550MB every week... 20180514 22:49:15-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 255 seconds] 20180514 22:49:44<+discordbot> That's why steam is useful 20180514 22:50:01<+discordbot> because people only download small updates 20180514 22:50:45<+discordbot> yes, steam is without problems. But if you won't implement supplemental updates into SF wesnoth then you possibly kill distribution over SF 20180514 22:50:46<+discordbot> Whatever we releasse, there are still many external packagers who will package everytime a new release is on SF. We would need to find a balance between both 20180514 22:51:41<+discordbot> yes, that's also true... loonycyborg's steam package works on every linux but there are also archlinux packages, debian packages, ubuntu packages, ... 20180514 22:51:59<+discordbot> arch I wouldn't worry about too much 20180514 22:52:00<+discordbot> 😛 20180514 22:52:28-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180514 22:52:29<+discordbot> honestly I think our current release model is already good enough 20180514 22:52:38<+discordbot> I disagree 20180514 22:52:45<+discordbot> Dev cycles go on way too long 20180514 22:52:56<+discordbot> it's not because of model 20180514 22:53:23<+discordbot> we can go as fast as we can make stuff itself work 20180514 22:53:49<+discordbot> Offtopic feature request: can we implement auto update check into SF versions? 20180514 22:53:56<+discordbot> if we change we'll gain little from it 20180514 22:54:13<+discordbot> only the way we apply it can be changed 20180514 22:54:30<+discordbot> I'm not sure 20180514 22:54:52<+discordbot> implementing our own update mechanism seems to be nih 20180514 22:55:00<+discordbot> that's what we have steam and flatpak for 20180514 22:55:05<+discordbot> It's not really worth it 20180514 22:55:32<+discordbot> not really whole update mechanism. Just 'alert' with info about new version available 20180514 22:55:51<+discordbot> hmm maybe that can be made work 20180514 22:56:15<+discordbot> we could upload some metadata file with number of latest vcersion to sf 20180514 22:56:20<+discordbot> and make client read it 20180514 22:56:25<+discordbot> exactly 20180514 22:57:32<+discordbot> something like that could work 20180514 22:58:45<+discordbot> @loonycyborg really, though, if we shorten down the dev/stable cycles to like... 6 months or so, that's more or less what we're proposing. Except that in the "stable" interim players could get more updates of more content more frequently 20180514 22:59:02<+discordbot> A release every 2 weeks provided we have something to push is perfectly good 20180514 22:59:22<+discordbot> well I'm not sure our existing model mandates particular time interval 20180514 22:59:30<+discordbot> so it's not really a model change 20180514 23:00:15<+discordbot> basically I'm fine with releasing as often as we have stuff to release 20180514 23:00:20<+discordbot> The bottom line is I want more updates more frequently 20180514 23:00:26<+discordbot> With more changes 20180514 23:00:32<+discordbot> as long as it is properly tested 20180514 23:00:38<+discordbot> *smaller releases 20180514 23:01:14<+discordbot> well it sounds little bit like stable and devel channel 20180514 23:01:28<+discordbot> if you do small updates often you don't really ever do big updates unless it's a planned marketing style release 20180514 23:01:43<+discordbot> @Demiskeleton yes, that's what Dota does 20180514 23:02:14<+discordbot> WWDD isn't a valid reason by itself 20180514 23:02:16<+discordbot> devel compiled from 1.14 every week for instance and stable after month when everything tested 20180514 23:02:47<+discordbot> it saves the devs from a lot of fatigue from sprint to meet release deadline followed by sprint to fix all the bugs 20180514 23:02:55<+discordbot> Speaking as a UMC maintainer, I get little feedback. If people come across a bug that's been introduced by an API change, they mostly leave my umc as buggy and don't come back. I get 'oh tov is a buggy mess' still and it's been stable for 4 years. 20180514 23:03:05<+discordbot> @Demiskeleton for example, this is the last "big" dota patch, the release of a new arcana. But that doesn't mean there haven't been smaller patches since then: http://www.dota2.com/feastofabcession 20180514 23:03:49<+discordbot> I'm ok with regular small changes, but would be be possible to push notify people with umc that uses the affected tags when changes are made? 20180514 23:04:20<+discordbot> there must be some way to automate the testing more 20180514 23:04:27<+discordbot> since we'd be working on a smaller scale, likely, yes 20180514 23:04:34<+discordbot> perhaps even test with umc 20180514 23:04:41<+discordbot> there'd have to be built some way to know which UMC uses those features. 20180514 23:04:57<+discordbot> i'm finishing up a devops bootcamp right now so all this stuff has been pounded into my brain the last while 20180514 23:05:07<+discordbot> I mean, just grepping for the relevanglt tgas would be a start. 20180514 23:05:22<+discordbot> Relevant tags... 20180514 23:05:55<+discordbot> I think breaking changes to umc interfaces should be disallowed in stable branch 20180514 23:06:43<+discordbot> it sounds like there'd be a "release" branch rather than a "stable" branch. 20180514 23:07:40<+discordbot> Most of te things that break my campaigns are deprecated usahes that i coukd have known about, but I don't manually check all my umc every release. I feel like the addons server could relatively easily know what addons are at risk of breaking changes and ping the maintainers. 20180514 23:08:11<+discordbot> or at least one of version components should be incremented if and only if interfaces for umc are changed 20180514 23:08:31<+discordbot> right, there would be no more"stable" branch 20180514 23:08:41<+discordbot> BUT API changes would be held off and be less often 20180514 23:09:02<+discordbot> So, like, we'd have 2 - 4 releases per year where the API changed 20180514 23:09:38<+discordbot> I don't think most umc authors will be able to keep pace 20180514 23:09:59<+discordbot> I disagree, because there would befewer changes and backwards compatibility would bepreserved for a time 20180514 23:10:01<+discordbot> one of the fields in _server.pbl is email. people could be alerted that way. 20180514 23:10:22<+discordbot> "changes" doesn't necessarily mean "breakages" 20180514 23:10:49<+discordbot> in fact, working on a smaller timescale would allow us to ensure there are fewer breakages and smoother transitions 20180514 23:10:50<+discordbot> what is even changing in the API the breaks things? 20180514 23:11:02<+discordbot> sure, it's possible 20180514 23:11:03<+discordbot> well... 20180514 23:11:05<+discordbot> xD 20180514 23:11:06<+discordbot> but changes can also mean additions 20180514 23:11:16<+discordbot> "here's a new tag!" 20180514 23:11:40<+discordbot> In fact 20180514 23:11:41<+discordbot> how much can an api command change? 20180514 23:11:49<+discordbot> These API changes could be frequently pushed to the beta channel on Steam 20180514 23:11:50<+discordbot> @Demiskeleton The known changes: https://forums.wesnoth.org/viewtopic.php?f=21&t=47614 20180514 23:12:32<+discordbot> So authors can prepare since they know what's coming 20180514 23:12:38<+discordbot> [set_variable] being implemented in lua was a big one for me 20180514 23:13:03<+discordbot> I can't keep pace right now, but that's more a reflection on me than on wesnoth :) 20180514 23:13:31<+discordbot> was I technically using the tag incorrectly? yes. But it was working before. 20180514 23:13:40<+discordbot> ^ oh my god yes 20180514 23:13:46<+discordbot> Well, I'm sorry, we can't support that 😛 20180514 23:13:57<+discordbot> Like, that's not on us 20180514 23:14:17<+discordbot> Not if everything is 100% documented without ambiguity, anyway... 20180514 23:14:42<+discordbot> yeah, well, our documentation is shoddy 20180514 23:14:56<+discordbot> there is a schema feature celmin added recently 20180514 23:15:06<+discordbot> that will help with verifying WML correctness 20180514 23:15:11<+discordbot> also 20180514 23:15:15<+discordbot> and I've said this before 20180514 23:15:21<+discordbot> hmm? 20180514 23:15:25<+discordbot> but errors need to be reported much more loudly 20180514 23:15:35<+discordbot> there are so many errors that are logged 20180514 23:15:40<+discordbot> and nobody ever sees 20180514 23:15:41<+discordbot> @zookeeper demands they be reported less loudly 20180514 23:15:54<+discordbot> because nobody looks at the log unless something visibly breaks 20180514 23:16:13<+discordbot> ^ seconded 20180514 23:16:35<+discordbot> yes 20180514 23:17:23<+discordbot> (and yes, i know that I should, but if there was an menu option to turn on loud in game errors I'd use it) 20180514 23:17:51<+discordbot> something we should do is have the schema validator print visible output 20180514 23:18:21<+discordbot> though the question is how to cordon this off for developers.. 20180514 23:18:24<+discordbot> debug mode, i guess 20180514 23:18:35<+discordbot> for umc devs only* 20180514 23:19:37<+discordbot> also, vultraz, for the love of god, document everything that was discussed here somewhere. 20180514 23:20:26<+discordbot> I feel like I'm sounding kind of like shadowm here, but really, it will make big shifts like this so much easier. 20180514 23:20:58<+discordbot> guess i need to make a forum post 20180514 23:21:40<+discordbot> thank you 20180514 23:30:32< sevu> mattsc, pushed it, and [store_unit] does interpret the filter as expected. I will see your messages when you tag me with an @ 20180514 23:31:51< mattsc> @sevu: I did too and it did not. Also, I checked the wiki and upkeep= is not a valid key in an SUF. 20180514 23:33:05< mattsc> @sevu ^ (might not work with the : after it) 20180514 23:33:25< sevu> ahh... right... that might make sense...it matches all units then 20180514 23:33:53< mattsc> Right. 20180514 23:33:55< sevu> (it wokrs with the:) 20180514 23:34:05< mattsc> (okay, good) 20180514 23:34:23< mattsc> You should be able to use upkeep via lua_function or formula though 20180514 23:34:31< sevu> I thought it could filter everything which is listed what I see with :inspect 20180514 23:37:23< EliDupree> By the way, does anyone know a way to browse all of the Wesnoth image files at once, perhaps as small (30x30px?) thumbnails? Just have them all laid out on the screen at the same time so I can look through them. 20180514 23:38:00< mattsc> @sevu: no, only what’s listed at https://wiki.wesnoth.org/StandardUnitFilter 20180514 23:38:47< Ravana_> I guess recursive copy+file manager work 20180514 23:42:59< sevu> it works with [filter_wml] =) 20180514 23:44:08< mattsc> Oh, right, forgot about that ... 20180514 23:50:32-!- louis94 [~~louis94@91.176.171.238] has quit [Ping timeout: 268 seconds] 20180514 23:53:02-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180514 23:54:45-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev --- Log closed Tue May 15 00:00:21 2018