--- Log opened Fri Dec 28 00:00:09 2018 20181228 01:13:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181228 01:59:52< irker297> wesnoth/wesnoth:master newfrenchy83 6f848a44af Merge branch 'master' into patch-6 AppVeyor: All builds passed 20181228 02:30:52<+wesdiscordbot> Maybe yetis just really like bony friends 20181228 04:34:25< irker297> wesnoth/wesnoth:master newfrenchy83 1373696148 Update scenario-test.cfg AppVeyor: All builds passed 20181228 05:34:33<+wesdiscordbot> Sevu y u do dis o.o 20181228 05:36:32< celticminstrel> Why not? 20181228 05:37:00<+wesdiscordbot> huh, autotools 20181228 05:54:36< irker297> wesnoth/wesnoth:master newfrenchy83 c8182ab114 Update scenario-test.cfg AppVeyor: All builds passed 20181228 06:35:36-!- celticminstrel is now known as celmin|sleep 20181228 07:54:05< irker297> wesnoth/wesnoth:1.14 mattsc 2c94696f83 Forest Animals MAI: fix AI crash when us AppVeyor: All builds passed 20181228 10:18:31< irker297> wesnoth/wesnoth:master mattsc 8b3c6b1fa9 Forest Animals MAI: fix AI crash when us AppVeyor: All builds passed 20181228 10:42:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20181228 12:34:38-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181228 13:18:40-!- irker297 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20181228 13:49:56-!- irker762 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20181228 13:49:56< irker762> wesnoth/wesnoth:master Reuben Rakete 65f9b59be3 Change hotkey filter to use multi word s AppVeyor: All builds passed 20181228 13:55:21< galegosimpatico> Good old 1.6 wesnoth. 20181228 14:43:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20181228 15:56:18-!- celmin|sleep is now known as celticminstrel 20181228 16:50:09-!- irker762 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20181228 17:03:13<+wesdiscordbot> @Konrad2 Thanks for the new replay! 😃 I'll reply on the thread once I've watched it. 20181228 17:51:47-!- gfgtdf [~Daniel@x4d062b26.dyn.telefonica.de] has joined #wesnoth-dev 20181228 17:51:51< gfgtdf> 20181224 15:29:54<+wesdiscordbot> gfgtdf, rhonda backported the lua patch for Debian. Could you have a look at it? 20181228 17:51:54< gfgtdf> looks good to me 20181228 17:56:34< gfgtdf> 20181226 23:20:38<+wesdiscordbot> do any events fire before creating the scenario start autosave? I mean HttT-Foo.gz, not HttT-Foo-AutoSave1.gz 20181228 17:57:11< gfgtdf> josteph: no there isn't that file is created before the gamestate (playsingle_controller) of the scenario is created. 20181228 17:57:16< celticminstrel> Pinging @sevu and @josteph for you. 20181228 17:57:31< gfgtdf> josteph: the last even is probably the scenario_end event of the last scenario 20181228 17:57:36< gfgtdf> event* 20181228 17:57:52< celticminstrel> gfgtdf: So just to be sure, even Lua on_save is not called before the start-of-scenario save? 20181228 17:58:35< gfgtdf> no it's not, it cannot be as there is not lua state object at that point. 20181228 17:58:40< celticminstrel> 'kay 20181228 17:58:46< gfgtdf> (except the 'application lua kernel' of course) 20181228 17:58:56< celticminstrel> (Which doesn't count of course) 20181228 17:59:54< gfgtdf> this is where the sos save is created https://github.com/wesnoth/wesnoth/blob/master/src/game_initialization/playcampaign.cpp#L404 20181228 18:00:07< celticminstrel> ...heh, SOS save. >_> 20181228 18:00:27< gfgtdf> this is where the gamestate is created https://github.com/wesnoth/wesnoth/blob/master/src/game_initialization/playcampaign.cpp#L282 20181228 18:03:26< gfgtdf> hmm here is calls to_config https://github.com/wesnoth/wesnoth/blob/master/src/game_initialization/playcampaign.cpp#L216 at then end of the lastscenario 20181228 18:04:04< gfgtdf> so it could be that on_save os called but also in the prvious scenario. 20181228 18:04:07< gfgtdf> hmm 20181228 18:04:16< celticminstrel> "also"? 20181228 18:04:30< celticminstrel> Do you mean it might be called twice? 20181228 18:05:05< gfgtdf> no that also means 'just liek the scenario_end event' 20181228 18:05:12< celticminstrel> ??? 20181228 18:05:49< celticminstrel> I think that would mean the "also" is misplaced then... 20181228 18:06:01< gfgtdf> dunno maybe my english is wrong, in germal 'too' and 'also' are more or less the same word (don't count me on that) 20181228 18:06:19< celticminstrel> They're pretty much the same in English too, though I think there are slight usage differences. 20181228 18:07:02< celticminstrel> Anyway, I guess what you meant to say is that it might be called at the end of the previous scenario, but it's not called just before making the start-of-scenario save. 20181228 18:07:14< gfgtdf> yes 20181228 18:08:19< gfgtdf> last time i tested it it was not called though, but that was probably in 1.10 or 1.11 20181228 18:08:36< gfgtdf> and i know that i refactored that code since then, so things might hev changed. 20181228 18:17:16<+wesdiscordbot> gfgtdf, thanks for the pointers 20181228 18:17:23<+wesdiscordbot> celmin, thanks for the ping 20181228 18:27:17< gfgtdf> is there a differnce between putting [objectives] in start or prestart events ? 20181228 18:27:28< celticminstrel> Probably not? 20181228 18:28:24< gfgtdf> ok 20181228 18:37:50<+wesdiscordbot> gfgtdf, https://github.com/wesnoth/wesnoth/issues/3544#issuecomment-421652251 20181228 18:38:52< gfgtdf> ok thx 20181228 19:04:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181228 19:05:07-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20181228 19:30:22< gfgtdf> is it actualyl possible to create an illuminated ability that does _not_ illuminate the adjacent hexes? for exampel an ability that onyl imlluminates the hex in the direction the unit is facing ? 20181228 19:30:57< celticminstrel> Good question... 20181228 19:33:12<+wesdiscordbot> should be, yes 20181228 19:33:46<+wesdiscordbot> you can make a variation on the [illuminates] ability that affects only one adjacent direction (n, ne, s, se, sw, nw) at a time 20181228 19:33:57<+wesdiscordbot> and then check the direction the unit is facing and swap the ability accordingly 20181228 19:34:07< celticminstrel> Should be able to pick the direction using variables? 20181228 19:34:15<+wesdiscordbot> (hacky solution, perhaps with lua or some other method there's a cleaner one) 20181228 19:34:17<+wesdiscordbot> should be yes 20181228 19:34:23< celticminstrel> IIRC you have $this_unit, so, $this_unit.facing should work, right? 20181228 19:34:26<+wesdiscordbot> perhaps just direction = $unit.facing 20181228 19:34:29<+wesdiscordbot> yea 20181228 19:35:21< gfgtdf> no the point is that illuminates wil always illuminate all adjacent hexes, an [illuminates] ability woith [affect_adjacent] will then give the illuminates abiltiy too all adjacent units which will basicialyl illuminate heyes ina 2 tile range 20181228 19:35:42< gfgtdf> note how the mainlien illuminates ability does not have a [affect_adjacent] 20181228 19:35:50< gfgtdf> mainline* 20181228 19:38:08< celticminstrel> I see. 20181228 19:38:10< celticminstrel> Maybe add it? 20181228 19:38:29< gfgtdf> then it'll illumniate all hexes ina 2 tile range as i said. 20181228 19:38:39<+wesdiscordbot> seems hardcoded, tod_manager::get_illuminated_time_of_day 20181228 19:40:53< gfgtdf> we coudl change it, the question is 1) whether it's an acceptable compabiltiy break (users not have to put [affet_adjacent] in their illuminates), and 2) whetehr there is a reason for this behviour (maybe because of how it interacts with terrain illumination?) 20181228 19:45:13< Ravana> note that unit facing can be unsynced 20181228 19:47:43< gfgtdf> Ravana: yes, that was just an example. Also it's probably possible to get a synced version by storing a synced facing after each unit move in the units variables (that then might no longer match the visual facing though). 20181228 20:47:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20181228 20:47:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20181228 20:55:53<+wesdiscordbot> @Konrad2 Yes, it is. Whatever the motion range of the unit is is unfogged. 20181228 20:56:13<+wesdiscordbot> Oops, wrong channel. 20181228 21:01:02-!- irker584 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20181228 21:01:02< irker584> wesnoth/wesnoth:master newfrenchy83 ecd6cbfa5f Update scenario-test.cfg AppVeyor: vs2017/Release Failed 20181228 21:01:02< irker584> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/21274445 20181228 21:36:03< irker584> wesnoth: mattsc wesnoth:master 6c8e7280a390 / changelog.md src/ai/actions.cpp: RCA AI: remove possibility of infinite candidate action loops https://github.com/wesnoth/wesnoth/commit/6c8e7280a3902ac5429972bcb2ff3f44d5885c2e 20181228 22:15:10< celticminstrel> IMO unit facing should be synched. WTH isn't it? 20181228 22:26:15< gfgtdf> celticminstrel: facing is partly handled by the animation code, which is not synced, in particular it iirc might be skipped if animations are skipped. 20181228 22:27:50< gfgtdf> celticminstrel, that's also why the facing attribute in unit.hpp is marked as 'mutable'. 20181228 22:30:40< gfgtdf> celticminstrel, also display code is often skipped when the action is inside fog which is also differnt on each client point of view. 20181228 22:44:07< celticminstrel> Ugh... 20181228 22:44:44< celticminstrel> Surely it would be possible to make sure the facing direction is synced after every move or attack, though? 20181228 23:16:36< gfgtdf> probably, but you have to be careful not to miss things, also moving&attackign might not be the only actions that change direction, healing also changes the facing a healer iirc 20181228 23:26:40< celticminstrel> Leadership 20181228 23:34:17< gfgtdf> yes leadership aswell, my first step on fixing this issue if i wanted it woudl probably be todo a textsearch for set_facing in the c++ code. 20181228 23:34:38< gfgtdf> also possibly wml-induced moves [move_unit] 20181228 23:53:26-!- gfgtdf [~Daniel@x4d062b26.dyn.telefonica.de] has quit [Quit: Leaving] --- Log closed Sat Dec 29 00:00:10 2018