--- Log opened Fri Dec 21 00:00:18 2018
20181221 00:10:12-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 250 seconds]
20181221 00:22:09-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20181221 00:39:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20181221 01:30:34< irker881> wesnoth/wesnoth:master newfrenchy83 ec2adbb4f2 resolve conflict AppVeyor: All builds passed
20181221 03:16:52-!- celmin}away is now known as celticminstrel
20181221 04:31:11-!- irker881 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout]
20181221 04:55:06-!- celticminstrel is now known as celmin|sleep
20181221 07:56:45-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20181221 10:16:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20181221 12:33:18-!- gfgtdf [~Daniel@x4d017068.dyn.telefonica.de] has joined #wesnoth-dev
20181221 13:23:17-!- celmin|sleep is now known as celmin|away
20181221 14:20:08-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20181221 15:36:11-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20181221 15:38:51<+wesdiscordbot> <mattsc> I'd be interested to know if anybody has comments/opinions on this: https://github.com/wesnoth/wesnoth/issues/2345#issuecomment-449420222
20181221 15:54:03< Soliton> in my opinion that is not a good first issue at all. :-P
20181221 15:54:37< Soliton> changing ai behaviour in an event does seem useful, i'd say.
20181221 15:55:24< Soliton> so some way to stop a candidate action after each move seems required as you say there.
20181221 15:55:56< mattsc> Well, yes, on the “good first issue”.  That designation was given before anybody looked into what it entails.  :P
20181221 15:57:45< Soliton> the issue with making a CA not move all units has come up before as well, right? so maybe the solution here can help in other situations as well.
20181221 15:58:04< mattsc> On the rest: yeah, probably.  I might need some pointers how to do that in practice (on the C++ part, I mean; in principle I know what’s needed).
20181221 15:58:20< mattsc> Hmm, interesting point.
20181221 15:58:52< mattsc> Yes, I have adding an [exclude_units] tag (or something along those lines) to CAs on my extended task list.
20181221 16:00:39< mattsc> Although so far I did not envision that being dynamically changeable during the CA execution.
20181221 16:02:19< Soliton> yeah, that doesn't seem to quite fit.
20181221 16:02:54< mattsc> I’ve removed the “good first issue” label.
20181221 16:05:08< mattsc> ai/compisite/ai.hpp is loaded by all the files that are needed for adding an interrupt flag, so that might be the place to include this; or maybe one of the contexts.hpp files.
20181221 16:06:33< mattsc> Hmm, I should try to see what happens if an event removes the CA that is currently being executed.  :P
20181221 16:20:49-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20181221 16:28:34-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20181221 16:59:24< Soliton> in case removing a CA includes actually deleting data it's working on then that is not a good idea. i rather guess it just means it's removed from some list so the next time we go through the list it's not used.
20181221 17:12:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20181221 17:27:30< mattsc> That’s what it seems to be doing, yes.
20181221 18:46:24< Ravana> > 20181221 20:45:08 error replay: Our next unit id is 24 but during the original the next unit id was 21
20181221 18:46:31< Ravana> feels like some word is missing in the message
20181221 18:47:31<+wesdiscordbot> <shadowm> Probably "session" or "gamestate"
20181221 18:47:41<+wesdiscordbot> <shadowm> As in the thing the replay pertains to
20181221 18:48:17-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20181221 19:38:47< Ravana> is this message still relevant? https://github.com/wesnoth/wesnoth/blob/1.14/src/units/map.cpp#L184
20181221 19:40:36<+wesdiscordbot> <jyrkive> Probably not. Git blame tells that these lines were last touched seven years ago, and it was in a generic "strip trailing whitespace" commit.
20181221 19:41:29< Ravana> while investigating for https://github.com/vgaming/CreepWars/issues/2 I noticed that I could likely get this error message by asking people save and reload game 10 times
20181221 21:31:04< gfgtdf> Ravana: there was recently a bug fix that casues 'error replay: Our next unit id is 24 but during the original the next unit id was 21' it was about using planning mode in coop games. But it was fixed by a serverpatch so it is probably not the cause.
20181221 21:35:44< Ravana> initial message was exactly with 24 and 21, after reload difference became 1
20181221 21:41:11< gfgtdf> in the mreport you said it probabyl happens becasue it changes the gamestateu during a preload event which is indeed likely.
20181221 21:41:24< gfgtdf> (if he does that that is)
20181221 21:41:52< Ravana> https://github.com/vgaming/CreepWars/blob/master/Creep_War_Dev/lua/init_state.lua#L9-L33
20181221 21:42:35< Ravana> https://github.com/vgaming/CreepWars/blob/master/Creep_War_Dev/lua/lua_events.cfg#L20
20181221 21:44:10< gfgtdf> yes that looks like it could be the reason, units created during unsynced events will be assigned a 'fake id' (basicially a redicously high integer as underlying id so that it does nto clash with the usualy units) and the game as some point assumes that these are basicially just helper for drawing, liek for example the 'ghost' unit used by aplnniang mode
20181221 23:35:47-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20181221 23:47:45-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
--- Log closed Sat Dec 22 00:00:20 2018