--- Log opened Fri Jun 28 00:00:56 2019 20190628 01:06:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190628 01:07:25-!- higgins [~higgins@static.38.6.217.95.clients.your-server.de] has quit [Ping timeout: 246 seconds] 20190628 01:08:54-!- higgins [~higgins@static.38.6.217.95.clients.your-server.de] has joined #wesnoth-dev 20190628 01:47:38-!- celmin|away is now known as celticminstrel 20190628 03:19:15-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] 20190628 05:27:00<+wesdiscordbot> to require someone to enter a game's password to be able observe, would it just be changing the line https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/multiplayer/lobby.cpp#L971 to if(!join_data.empty() && game.password_required) {? 20190628 06:26:39-!- heirecka [~heirecka@exherbo/developer/heirecka] has quit [Remote host closed the connection] 20190628 06:27:22-!- heirecka [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev 20190628 07:50:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190628 08:11:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190628 11:41:24<+wesdiscordbot> @Pentarctagon I think it won't be good to require game password to observe 20190628 11:41:56<+wesdiscordbot> I think that people use password to make their freinds only to join 20190628 11:42:30<+wesdiscordbot> if they wanted to forbid people from watching the game, they would turn off the specs 20190628 12:11:45<+wesdiscordbot> @EarthCake I'm not talking about play styles, about whether leader should be in the front lines or not. 20190628 12:12:07<+wesdiscordbot> @EarthCake I'm saying, if everyone who won a scenario had to take a 50% of losing at one point, then the scenario is not balanced well. 20190628 12:12:48<+wesdiscordbot> @EarthCake When I play, if my leader has a 50% to survive and survives, I consider him to have died. 20190628 13:13:05-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20190628 14:00:07<+wesdiscordbot> @EarthCake The problem being then that there's no way to only partially limit who can observe, it's all or none. 20190628 14:03:14<+wesdiscordbot> Is there a way for me to get some logs on a crash on iOS (version from appstore)? Or is the only right way to compile and run it from xcode to get the logs? 20190628 14:07:21<+wesdiscordbot> @sinda ^ 20190628 15:39:01<+wesdiscordbot> zookeeper, in EI is Grug supposed to have upkeep="full" or upkeep="loyal" when he joins the party? 20190628 15:39:23<+wesdiscordbot> He has upkeep="full" but I assume he should have upkeep="loyal" http://sprunge.us/VrMfGT ? 20190628 16:25:42<+wesdiscordbot> @LawnCable You can enable crash reporting in iOS settings, including “share with developer” option. Then I will receive the log and can get it to you, if you wish, or hopefully fix it. 20190628 16:51:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190628 16:55:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer] 20190628 16:55:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190628 17:26:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 268 seconds] 20190628 17:33:45< zookeeper> @josteph he has the loyal trait, doesn't that already make him cost no upkeep? he shouldn't have upkeep=full but neither should upkeep=loyal need to be explicitly given. 20190628 18:00:57<+wesdiscordbot> zookeeper, No. He has upkeep=full and costs upkeep. 20190628 18:01:19<+wesdiscordbot> If I :debug him to upkeep=loyal I see a change in the upkeep paid per turn 20190628 18:04:52< zookeeper> oh right, he's given to you via [modify_unit]. so, yeah, either some engine change caused that, or 2e2cc6756 always did. i'd just change it back to [unit] instead of [modify_unit], much safer that way (as we can see here). 20190628 18:05:54< zookeeper> but i think it suspicious that the unit does have upkeep=full _and_ that the loyal trait doesn't override it. 20190628 18:07:10<+wesdiscordbot> zookeeper, Interesting. {NAMED_LOYAL_UNIT} doesn't set upkeep=loyal explicitly. 20190628 18:08:57< zookeeper> i don't see why we should suddenly need to set upkeep=loyal when historically it was almost never necessary? 20190628 18:09:27<+wesdiscordbot> Let me check where upkeep is set to "loyal" 20190628 18:09:37<+wesdiscordbot> Would that be in C++/Lua/WML ? 20190628 18:10:52< zookeeper> C++ ultimately, i don't think the low-level unit creation has been luafied much? 20190628 18:15:29<+wesdiscordbot> modify_unit ultimately reaches this line https://github.com/wesnoth/wesnoth/blob/0b45d5e5adfb432c6571dbd99b9ec0839e02a095/data/lua/wml/modify_unit.lua#L13 20190628 18:17:59< zookeeper> well, the code that applies traits' effects would be relevant too? i mean, that [modify_unit] does add the loyal trait to the unit, which should cause its effect to be applied, but apparently that doesn't work. 20190628 18:19:12<+wesdiscordbot> I looked at it from the other way, I looked for all the places that handle the value "loyal" 20190628 18:19:20<+wesdiscordbot> the only one I found is src/scripting/lua_unit.cpp:425 20190628 18:24:11< zookeeper> ok, so, i wouldn't be surprised if something subtle like that had always been "broken" engine-side (quotes because it's not crystal clear how that stuff should work). 20190628 18:24:39< zookeeper> WRT [modify_unit], that is 20190628 18:27:37<+wesdiscordbot> I looked more and I see how it works in the NAMED_LOYAL_UNIT case now. 20190628 18:28:04<+wesdiscordbot> NAMED_LOYAL_UNIT calls TRAIT_LOYAL which installs effect apply_to=loyal. That effect is implemented in C++ as setting upkeep=loyal 20190628 18:28:31<+wesdiscordbot> I'm not sure what happens in modify_unit, maybe the [modifications] tag gets ignored ? 20190628 18:28:37<+wesdiscordbot> Grug's ellipses are red, not purple 20190628 18:29:05< zookeeper> right, ok, sounds like a [modify_unit] problem then. in master, i presume, not 1.14? 20190628 18:29:18<+wesdiscordbot> I only checked 1.14 20190628 18:31:47<+wesdiscordbot> I think in master the schema validation would catch this, if it were run with the campaign define ? 20190628 18:32:45< zookeeper> what exactly do you think it would catch? the WML is according to spec, is it not? 20190628 18:37:05<+wesdiscordbot> yeah, only for a moment I thought it wasn't 20190628 18:40:54<+wesdiscordbot> zookeeper, https://github.com/wesnoth/wesnoth/issues/4137 20190628 18:43:56< zookeeper> better mention the ellipse problem too? i mean it sounds like there's a bigger problem there and it's not specific to the loyal trait. 20190628 18:44:49< zookeeper> oh wait. the ellipses should be red, of course. so if he has purple pants and a red ellipse, all is good. 20190628 19:37:37<+wesdiscordbot> zookeeper, yes, he has purple pants and a red ellipse 20190628 19:38:20< zookeeper> yeah, so specific to upkeep/loyal/etc. 20190628 19:40:01<+wesdiscordbot> to built-in [effect]s, probably 20190628 21:39:40-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 258 seconds] 20190628 23:54:05-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev --- Log closed Sat Jun 29 00:00:58 2019