--- Log opened Sun Feb 10 00:00:12 2019 20190210 01:43:24< irker321> wesnoth/wesnoth:master nemaara 8b7e6415f6 DiD S6: dialogue/gameplay fixes AppVeyor: All builds passed 20190210 02:32:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190210 03:09:18< irker321> wesnoth/wesnoth:master nemaara f5b1002093 DiD S10: updated objectives AppVeyor: All builds passed 20190210 04:33:07-!- gfgtdf [~Daniel@x4d030c49.dyn.telefonica.de] has quit [Ping timeout: 240 seconds] 20190210 05:36:37< irker321> wesnoth/wesnoth:oos_debug_info gfgtdf 6d7af26654 how activemods in server log AppVeyor: All builds passed 20190210 07:04:51-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20190210 07:41:54< irker321> wesnoth/wesnoth:master equal-l2 bdc313bb83 Don't append ICU libs to LIBS AppVeyor: All builds passed 20190210 10:28:55< irker321> wesnoth: Nils Kneuper wesnoth:1.14 a5c2b23c52fc / po/ (wesnoth-aoi/fr.po wesnoth-ei/fr.po wesnoth-help/fr.po wesnoth-tutorial/fr.po): updated French translation https://github.com/wesnoth/wesnoth/commit/a5c2b23c52fccfaaf72c8ae74eecbe5583c3827b 20190210 10:29:06< irker321> wesnoth: Nils Kneuper wesnoth:master 095edb36a1b4 / po/ (wesnoth-aoi/fr.po wesnoth-ei/fr.po wesnoth-help/fr.po wesnoth-tutorial/fr.po): updated French translation https://github.com/wesnoth/wesnoth/commit/095edb36a1b4d06d8ab904e3d622e94ac9d65308 20190210 11:11:26< irker321> wesnoth/wesnoth:1.14 doofus-01 c02e9fe189 fixes to lancer defensinve animations, t AppVeyor: All builds passed 20190210 11:19:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190210 12:48:30-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20190210 14:02:30-!- madmax28 [~madmax28@xdsl-87-78-204-203.nc.de] has joined #wesnoth-dev 20190210 14:04:08< madmax28> Hi, I noticed that the observer icon is no longer shown when in a game. Is this intended (i haven't played in quite a while)? 20190210 14:57:35-!- irker321 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20190210 15:04:05-!- celmin|sleep is now known as celticminstrel 20190210 15:04:18< celticminstrel> Doubt it. 20190210 15:15:29-!- TheJJ [~rofl@ipbcc08e97.dynamic.kabel-deutschland.de] has quit [Ping timeout: 246 seconds] 20190210 15:17:06-!- TheJJ [~rofl@ipbcc089f4.dynamic.kabel-deutschland.de] has joined #wesnoth-dev 20190210 15:27:54< madmax28> @celticminstrel i'm not getting it with 1.14.5 from the arch linux repos. However, I just built from source and it's showing there, so i guess if there was a problem it's fixed by now 20190210 15:29:17< Ravana> https://github.com/wesnoth/wesnoth/issues/3543 20190210 15:31:49< madmax28> yep, that must be it 20190210 17:07:40-!- irker264 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20190210 17:07:40< irker264> wesnoth/wesnoth:1.14 Nils Kneuper a5c2b23c52 updated French translation AppVeyor: All builds passed 20190210 18:34:05<+wesdiscordbot> 1.14.6 will be released in two weeks, including that fix 20190210 19:08:56< celticminstrel> ...I really don't think we should be asking PR authors to do refactoring for us. 20190210 19:09:39< celticminstrel> And even if they do, it should really be in a separate commit from the actual goal of the PR. 20190210 19:09:44< celticminstrel> ^ Josteph 20190210 19:10:22< celticminstrel> (Regarding 3800) 20190210 19:12:30< celticminstrel> ... 20190210 19:12:39< celticminstrel> Why can't people properly label issues! 20190210 19:13:02< celticminstrel> Every time a new issue is posted, someone should add labels as soon as they see it! 20190210 19:13:40< celticminstrel> https://github.com/wesnoth/wesnoth/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+no%3Alabel 20190210 19:13:45< celticminstrel> Someone please label those. 20190210 19:13:45<+wesdiscordbot> Remember that we're all volunteers here. You can hardly demand people to do anything. 20190210 19:13:50< celticminstrel> Maybe I will later. 20190210 19:14:08< celticminstrel> Eh... you have a point. 20190210 19:14:11< celticminstrel> Still... 20190210 19:14:37< celticminstrel> It's not like it's difficult (usually; some issues are hard to classify). 20190210 19:28:51< irker264> wesnoth/wesnoth:master Nils Kneuper 095edb36a1 updated French translation AppVeyor: All builds passed 20190210 20:27:27<+wesdiscordbot> celticminstrel, what's the question for me again? 20190210 20:27:53< celticminstrel> It wasn't a question, just a comment. 20190210 20:32:05<+wesdiscordbot> yeah, the PR could've been split into two commits or more 20190210 20:32:25<+wesdiscordbot> the change to get_special_children could've been separated, for example 20190210 20:33:08<+wesdiscordbot> but the patch isn't too large as it is, and I didn't want to tire the submitter with more back and forths 20190210 20:33:50< celticminstrel> I see. 20190210 20:34:08<+wesdiscordbot> also, you do know the patch has been outstanding for several weeks now ? 20190210 20:34:19<+wesdiscordbot> I was afk and I asked others to take over reviewing and no one has 20190210 20:34:31< celticminstrel> It was merged, wasn't it? 20190210 20:34:38<+wesdiscordbot> I merged it to master 20190210 20:34:49<+wesdiscordbot> it hasn't been merged to 1.14, pending decision on whether it might cause OOS 20190210 20:34:55< celticminstrel> Oh. 20190210 20:35:13 * celticminstrel tries to remember the PR title without returning to GitHub... 20190210 20:35:25<+wesdiscordbot> consider firststrike inactive 20190210 20:35:27< celticminstrel> Oh right. 20190210 20:35:57< celticminstrel> I definitely think it should be merged to 1.14 if possible. 20190210 20:36:12< celticminstrel> It doesn't seem to me like the sort of thing that would cause OOS, but I might be missing something. 20190210 20:36:34<+wesdiscordbot> gfgtdf said it'd cause OOS https://github.com/wesnoth/wesnoth/pull/3800#issuecomment-450238042 20190210 20:37:23<+wesdiscordbot> Personally I'd love to see this backported if possible 20190210 20:38:14< celticminstrel> I think gfgtdf's example of a filter using the formula dice operator could potentially cause OOS even without this change... 20190210 20:38:31< celticminstrel> And furthermore, filters are supposed to have no side-effects. 20190210 20:38:48< celticminstrel> They can have side-effects but they're not supposed to. 20190210 20:39:13<+wesdiscordbot> is that documented for UMC authors ? 20190210 20:39:22< celticminstrel> AFAIK the only two ways they could have side-effects are... 1. They use lua_function to call code that has side-effects or 2. They use a formula with a dice operator. 20190210 20:39:28< celticminstrel> I'm not sure if it's explicitly documented. 20190210 20:39:39< celticminstrel> For me at least, it seems implicitly obvious. 20190210 20:40:25< celticminstrel> Formulas themselves are not supposed to have side-effects, so the dice operator is kind of a violation of their very premise... probably far too late to do anything about that now though. 20190210 20:40:52<+wesdiscordbot> I'm sure there are UMC authors who use lua functions with side effects 20190210 20:40:58< celticminstrel> Unless the dice operator can be changed to not produce side-effects? 20190210 20:41:03< celticminstrel> Yeah, I wouldn't be surprised. 20190210 20:41:04<+wesdiscordbot> the question is just if we have documentation we can point to to tell them they are at fault and not us 20190210 20:41:15<+wesdiscordbot> could the dice use sync'd random numbers? 20190210 20:41:25< celticminstrel> Well, that still has side-effects. 20190210 20:41:36< celticminstrel> The side-effect being that the random number generator's state has changed. 20190210 20:41:47<+wesdiscordbot> it won't cause OOS though then, will it? 20190210 20:41:52< celticminstrel> You'd probably need a very different way of generating the random numbers in order to avoid side-effects. 20190210 20:41:59< celticminstrel> Right, it wouldn't cause OOS, but it still has side-effects. 20190210 20:42:17<+wesdiscordbot> I'm not sure if it's possible to generate random numbers without side effects 20190210 20:42:25< celticminstrel> I think it's possible. 20190210 20:42:41< celticminstrel> At least in theory. 20190210 20:43:00< celticminstrel> But likely not in a way that would work equally on all computers with arbitrary formulas that may use many dice operators. 20190210 20:43:05<+wesdiscordbot> when are the rolls supposed to come out the same, and when not ? 20190210 20:43:44< celticminstrel> The two ideas I'm thinking of are... 1) use a newly-seeded generator for each roll (or at least, a newly-seeded generator per formula) or 2) use an actual true random device. 20190210 20:43:57< celticminstrel> What do you mean by "come out the same"? 20190210 20:44:33< celticminstrel> For OOS problems involving formulas using random numbers, what should probably be done is somehow evaluating the formula on only one client and then syncing the result. 20190210 20:44:50< celticminstrel> Rather than syncing the random number generator directly.. 20190210 20:44:57<+wesdiscordbot> Using a newly-seeded RNG for each "random number" is just useless community (essentially a poor man's hash). Just use the seed directly. 20190210 20:45:04<+wesdiscordbot> *complexity 20190210 20:45:45< celticminstrel> Well, unless I'm mistaken, running the seed through the generator at least ensures your random numbers are not monotonically increasing if you use eg the current timestamp as the seed. 20190210 20:46:01< celticminstrel> If you're using a random device, then of course there's no point in running it through a generator. 20190210 20:46:22<+wesdiscordbot> In that case, you can just use a hash function. 20190210 20:46:29< celticminstrel> Hmm. 20190210 20:46:34< celticminstrel> Hash the timestamp, you mean> 20190210 20:46:35< celticminstrel> ^? 20190210 20:46:40<+wesdiscordbot> Yes. 20190210 20:46:52< celticminstrel> I see... that does sound like it could work. 20190210 20:47:19<+wesdiscordbot> And what about filters that don't use dice? 20190210 20:47:23<+wesdiscordbot> celticminstrel: I've added labels to those 4 issues 20190210 20:47:30< celticminstrel> What about them, Josteph? 20190210 20:47:30<+wesdiscordbot> (in context of 3800) 20190210 20:47:33< celticminstrel> Thanks, Pentarctagon. 20190210 20:47:41<+wesdiscordbot> we started by asking whether 3800 would cause oos 20190210 20:47:53<+wesdiscordbot> AFAIK the only two ways they could have side-effects are... 1. They use lua_function to call code that has side-effects or 2. They use a formula with a dice operator. 20190210 20:48:43< celticminstrel> AFAIK there's no way for a formula to cause side-effects other than the dice operator, and that's also the only way for the formula to produce an output that differs on different clients, assuming the inputs are the same on all clients. 20190210 20:49:11< celticminstrel> IOW, formulas not using dice should only be desynched if something else they're based on was already desynched. 20190210 20:49:20<+wesdiscordbot> filters, not formulas 20190210 20:49:23< celticminstrel> As for lua_function... 20190210 20:49:50< celticminstrel> I don't think there's a good solution there, and certainly not one that could be implemented on 1.14. 20190210 20:49:53<+wesdiscordbot> UMC can implement lua_function filters that cause OOS, I'm sure 20190210 20:50:11<+wesdiscordbot> we should document that they shouldn't 20190210 20:50:13< celticminstrel> I think ideally you'd somehow run the lua_function filter in an immutable Lua state so that they can't change anything. 20190210 20:50:19<+wesdiscordbot> but what I'm trying to ask is, if 3800 can be backported or not 20190210 20:50:29< celticminstrel> But of course that'll break all plugins that were misbehaving in the past. 20190210 20:51:29< celticminstrel> About whether it can be backported, I think it likely can be. 20190210 20:51:56< celticminstrel> My reasoning: the ways in which you could get OOS from a filter after the PR would likely also produce OOS before the PR as well, so it's not new OOS caused by the PR. 20190210 20:52:06< celticminstrel> Again though, I'm not 100% certain, and I could be missing something. 20190210 20:52:47< celticminstrel> I'll post this on the issue so gfgtdf can read it and respond. 20190210 20:53:03<+wesdiscordbot> thanks celticminstrel 20190210 20:54:50<+wesdiscordbot> it merges with a minor conflict 20190210 20:55:02< celticminstrel> We should probably do something about the dice operator and lua_function eventually though... 20190210 20:55:10< celticminstrel> And also, document that filters are not supposed to have side-effects. 20190210 20:55:38<+wesdiscordbot> I'll file an issue for the first 20190210 20:56:01< celticminstrel> Just FTR, WFL is supposed to be a pure-functional language, which means nothing has side-effects. 20190210 20:57:00<+wesdiscordbot> why does WFL have dice in the first place? 20190210 20:57:09< celticminstrel> No idea. 20190210 20:57:53< celticminstrel> I wonder if hashing the timestamp would actually give a reasonably-random output. 20190210 20:58:07< celticminstrel> I guess hash outputs are supposed to be random, so maybe it would. 20190210 20:58:42<+wesdiscordbot> the problem isn't that it'd be random. 20190210 20:58:45<+wesdiscordbot> it'd be predictable 20190210 20:58:55< celticminstrel> I'm not so sure about that? 20190210 20:59:04<+wesdiscordbot> if I'm in a match, I could cheat by taking the md5() of every second in the next minute 20190210 20:59:21<+wesdiscordbot> over many minutes, it'd tend to be a uniform distribution.. but in any particular minute it might be skewed 20190210 20:59:34< celticminstrel> Hmm. 20190210 20:59:42<+wesdiscordbot> salted hashes help with that 20190210 20:59:44< celticminstrel> This assumes the timestamp has a resolution of seconds. 20190210 20:59:48<+wesdiscordbot> in some use cases.. 20190210 20:59:56< celticminstrel> I don't know if salted hashes are possible in this case. 20190210 21:00:31< celticminstrel> Anyway, if the timestamp has a resolution of milliseconds or microseconds or nanoseconds, your method would be less reliable, no? 20190210 21:00:40<+wesdiscordbot> the AWS bill would be larger 20190210 21:00:49< celticminstrel> AWS? 20190210 21:00:53<+wesdiscordbot> but yeah, for nanoseconds it'd probably be a uniform distribution 20190210 21:00:57<+wesdiscordbot> cloud computing 20190210 21:01:01<+wesdiscordbot> aws.amazon.com 20190210 21:01:05< celticminstrel> Oh right. 20190210 21:01:13<+wesdiscordbot> I wonder if we can just remove dice outright 20190210 21:01:17<+wesdiscordbot> as in, what what that break 20190210 21:01:23< celticminstrel> Hmm. 20190210 21:01:44<+wesdiscordbot> even specifying a strict order of evaluation of formulas won't help, in case a formula is evaluated a different number of times on different clients 20190210 21:02:02< celticminstrel> Not sure what you're getting at there. 20190210 21:02:28<+wesdiscordbot> trying to solve the conflict between "dice are random" and "WFL should be a pure functional language" 20190210 21:03:17< celticminstrel> Maybe it could has the formula string and mix in the timestamp somehow. :P 20190210 21:03:23< celticminstrel> ^hash 20190210 21:04:27< celticminstrel> This sounds like quite a significant bug: https://wiki.wesnoth.org/index.php?title=UnitTypeWML&curid=1553&diff=60176&oldid=60158 20190210 21:04:44< celticminstrel> Basically it's saying that attack/defense weight don't do what they're advertised to do. 20190210 21:04:57<+wesdiscordbot> zooming out for a minute... what should the damage prediction dialog say when a weapon special filter uses dice? 20190210 21:05:07< celticminstrel> ... 20190210 21:05:15< celticminstrel> Uhhhh... 20190210 21:05:21<+wesdiscordbot> the monte carlo version would probably get it right 20190210 21:05:28<+wesdiscordbot> but the non-monte carlo would do... what? 20190210 21:05:37<+wesdiscordbot> Nah, it's not aware of special filters either. 20190210 21:05:52< celticminstrel> I don't think it's possible to get that right without actually parsing the formula. 20190210 21:06:19< celticminstrel> The monte carlo version might get it right if it evaluates the formula many, many times, I guess. 20190210 21:06:42<+wesdiscordbot> The current implementation doesn't. 20190210 21:06:56<+wesdiscordbot> It's optimized for speed and doesn't deal with any custom stuff. 20190210 21:07:13<+wesdiscordbot> How does it work, in broad strokes? 20190210 21:07:27<+wesdiscordbot> Just run the battle many times ignoring weapon special filters? 20190210 21:07:43<+wesdiscordbot> Just run a battle simulation many times. 20190210 21:08:05<+wesdiscordbot> https://github.com/wesnoth/wesnoth/blob/095edb36a1b4d06d8ab904e3d622e94ac9d65308/src/attack_prediction.cpp#L1503 20190210 21:08:13< irker264> wesnoth/wesnoth:master newfrenchy83 f813394118 Fix berserk ability could used value min AppVeyor: All builds passed 20190210 21:08:26<+wesdiscordbot> celmin, https://github.com/wesnoth/wesnoth/issues/3922 20190210 21:09:14< irker264> wesnoth: Maximilian Fricke wesnoth:1.14 ce9873700cf3 / src/units/unit.cpp: unit: Fix bug in unit movement animation https://github.com/wesnoth/wesnoth/commit/ce9873700cf3d459d6756111bec20e804c37e32c 20190210 21:09:18< irker264> wesnoth: Maximilian Fricke wesnoth:master 2b975e65a77c / src/units/unit.cpp: unit: Fix bug in unit movement animation https://github.com/wesnoth/wesnoth/commit/2b975e65a77cf36dea8045a4b8c9859936ee9f48 20190210 21:10:14<+wesdiscordbot> @jyrkive 5000 times, I see. Thanks. 20190210 21:10:48< celticminstrel> We should open an issue for the attack/defense weight too... 20190210 21:10:51< celticminstrel> Maybe I'll do that later. 20190210 21:12:04<+wesdiscordbot> and we also need to document that lua_function shouldn't have side effects 20190210 21:12:40<+wesdiscordbot> https://wiki.wesnoth.org/OOS_(Out_of_Sync)#How_to_make_your_code_safe looks like a good place 20190210 21:41:04< celticminstrel> (Or should we get octalot to file this issue? https://wiki.wesnoth.org/index.php?title=UnitTypeWML&curid=1553&diff=60176&oldid=60158 ) 20190210 21:42:51< Ravana> octalot was just the one to document how it works now, not the one to find that issue 20190210 21:43:03< celticminstrel> I see. 20190210 21:44:02< Ravana> if you follow his link you find my link to https://forums.wesnoth.org/viewtopic.php?p=638187#p638187 20190210 21:47:04< irker264> wesnoth/wesnoth:master newfrenchy83 3c80b15718 Check whether special is active by tag n AppVeyor: vs2015/Release Failed 20190210 21:47:05< irker264> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-7lnpw/builds/22261542 20190210 21:47:49< celticminstrel> https://wiki.wesnoth.org/index.php?title=OOS_(Out_of_Sync)&curid=6031&diff=60189&oldid=60154 20190210 21:47:56< celticminstrel> Maybe ask gfgtdf to look that over, too. 20190210 21:48:03< celticminstrel> In case I overlooked something or misinterpreted something. 20190210 21:48:49< celticminstrel> Did we ever add lua_function support to SSF or SWF? 20190210 21:49:07< celticminstrel> It was originally only in SUF and I know it was added to SLF, but IIRC it never made it into the other two. 20190210 21:59:54< celticminstrel> https://github.com/wesnoth/wesnoth/issues/3923 20190210 22:00:01< celticminstrel> (I'll add labels shortly) 20190210 22:13:52< irker264> wesnoth/wesnoth:master newfrenchy83 03c5cb8560 Check whether special is active by tag n AppVeyor: vs2017/Release Failed 20190210 22:13:53< irker264> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/22261544 20190210 22:21:56-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds] 20190210 23:09:44< irker264> wesnoth/wesnoth:1.14 Andrius Štikonas 11727624d1 Fix some spelling issues AppVeyor: All builds passed 20190210 23:42:14-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] --- Log closed Mon Feb 11 00:00:13 2019