--- Log opened Tue Mar 29 00:00:40 2016
20160329 00:09:33-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has quit [Ping timeout: 276 seconds]
20160329 00:10:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160329 00:14:31< vultraz> Interesting
20160329 00:14:47< celticminstrel> ?
20160329 00:15:05< vultraz> By removing the progress bar from the loadscreen, I think it reduces loadtimes
20160329 00:15:19< vultraz> Since it no longer takes times to draw the progress bar and increment progress.
20160329 00:15:31< celticminstrel> I've already said that removing it is unacceptable.
20160329 00:15:55< vultraz> shadowm doesn't think so
20160329 00:16:09< celticminstrel> I missed him saying this.
20160329 00:18:53< shadowm> I never said such a thing in this channel, that's why.
20160329 00:20:06< celticminstrel> I still think it's a very bad idea.
20160329 00:20:11-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160329 00:20:52< shadowm> I really doubt being convinced that it's a very bad idea will suffice to dissuade the new regime from adopting such drastic measures.
20160329 00:21:16-!- prkc [~prkc@192.40.89.13] has joined #wesnoth-dev
20160329 00:21:18< celticminstrel> What's that supposed to mean?
20160329 00:21:37< vultraz> It means I like to do things in the face of people saying it's a bad idea.
20160329 00:21:50< shadowm> Yep.
20160329 00:21:50< vultraz> well, despite
20160329 00:22:07< shadowm> Notice how he doesn't bother denying that.
20160329 00:22:11< celticminstrel> :|
20160329 00:23:05 * celticminstrel notices that shadowm neither confirmed nor denied whether he thinks this change is acceptable.
20160329 00:23:29< shadowm> This is the conversation in question: http://pastebin.com/raw/0JxkHZyJ
20160329 00:24:42< celticminstrel> :|
20160329 00:24:49< shadowm> The tl;dr of it is that I do not find it to be unacceptable but unlike vultraz I'd be sure to consider other people's opinions on the matter.
20160329 00:25:26< vultraz> I do want other people's opinions, but not just celmin's.
20160329 00:27:32< shadowm> The point is that unless you are either 1) a developer; 2) a content author; 3) a user following a developer's instructions for a troubleshooting or debugging procedure; the semi-verbose load screen serves no purpose.
20160329 00:27:57< celticminstrel> I wouldn't mind removing the names of the load stages.
20160329 00:28:00< shadowm> You could just have a pretty splash screen in its stead, optionally with a very minimalistic progress meter.
20160329 00:28:31< celticminstrel> I mean, I like having them there, but the most important thing to me is simply that the loadscreen is not static - it needs to change somehow as it progresses.
20160329 00:29:14< shadowm> A spinning dots animation or something could serve that purpose just as well.
20160329 00:29:23< shadowm> It doesn't have to be an actual progress meter.
20160329 00:29:39< shadowm> The corner case that concerns me is the broken AE-style add-ons that take forever to load, as I said in that log.
20160329 00:29:58< shadowm> (No, that's not an invitation to go on another philosophical tangent about WML's design.)
20160329 00:30:02< celticminstrel> A spinning dots animation doesn't give any indication of progress, though. It's better than nothing, admittedly.
20160329 00:30:26< shadowm> Okay, so am I the only one who's ever taken a look at the loading screen code? The progress counter is _not_ precise.
20160329 00:30:38< vultraz> I've been looking at it since yesterday
20160329 00:30:53< shadowm> It's calibrated around mainline content (HttT, to be specific) and doesn't have a real notion of how long it takes to load an arbitrary lump of WML.
20160329 00:30:53< celticminstrel> It doesn't need to be precise.
20160329 00:31:14< shadowm> Imprecise progress bars is what caused me yesterday to go on an angry tirade against Microsoft.
20160329 00:31:42< celticminstrel> If it advanced the same amount for each stage, that would be fine with me. (Currently it does a little better than that.)
20160329 00:32:00< shadowm> Each stage takes a different amount of time.
20160329 00:32:14< vultraz> celticminstrel: now I'm confused.. do you want a progress bar, or an animated loading screen
20160329 00:32:30< shadowm> You have no way to know before hand how long the preprocessor|parser stage will take -- hell, you don't even know beforehand if the cache will get involved.
20160329 00:32:52< celticminstrel> I want at least a minimalistic progress bar.
20160329 00:32:55< shadowm> And this is not just because of WML's byzantine design.
20160329 00:33:16< shadowm> It's because every system call involving I/O, by definition, is a non-deterministic operation that can take any amount of time to complete.
20160329 00:33:48< shadowm> So having progress bars when the number of files to read is already an unknown quantity just doesn't make sense.
20160329 00:34:55< celticminstrel> A series of dots, one for each stage, filled in as the stages are completed, could be sufficient.
20160329 00:34:56< shadowm> Finally, the load screen needs to be reengineered to use a managed UI module (preferably GUI2) so you might as well make it simpler while at it.
20160329 00:35:34< shadowm> (Although I have honestly no idea how you'd port it to GUI2 without dragging the parser and preprocessor into a ****fest of bad architecture design.)
20160329 00:36:36< vultraz> Create it as a non-modal window that closes when the global loadscreen destructor is called, maybe?
20160329 00:37:10< shadowm> GUI2 non-modal windows are as real as unicorns and gnomes.
20160329 00:37:25< vultraz> shadowm: the tooltips are non-modal windows
20160329 00:37:36< shadowm> Okay, then you figured it out in the meantime, congratulations.
20160329 00:41:37< vultraz> twindow::show_non_modal()
20160329 00:42:00< celticminstrel> Whoops, I crashed Wesnoth. (1.12)
20160329 00:42:59-!- irker922 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160329 00:42:59< irker922> wesnoth: mattsc wesnoth:master ff11fecfe3db / data/ai/micro_ais/scenarios/guardians.cfg: Guardians MAI test scenario: update portrait paths https://github.com/wesnoth/wesnoth/commit/ff11fecfe3db7a1e3de9c2685f34f53cc2498e84
20160329 00:47:09< mattsc> celticminstrel: I figured out why the bats don’t go back out again in the Goto test scenario.  I have not decided yet whether I want to fix the underlying cause, or devlare it a feature.
20160329 00:47:45< mattsc> The latter would involve that you always have to declare a ca_id if you want to delete or change it later …
20160329 00:49:16< celticminstrel> So... it would mean it is impossible to delete (using the [micro_ai] tag, at least) if you do not have a ca_id?
20160329 00:50:26< celticminstrel> I think using a ca_id should be highly recommended if you want to delete it later; however, I'm not sure if it's reasonable for it to be required...
20160329 00:50:32< celticminstrel> (Or change it later.)
20160329 00:51:04< celticminstrel> BTW, not really related, but won't using a lot of MicroAIs and adding and deleting them a lot result in lots of dead [micro_ai] tags in the engine [data]?
20160329 00:55:31< vultraz> I have a good idea how to make a gui2 loadscreen dialog...
20160329 00:56:40< mattsc> celticminstrel: IIUYC, this comment refers to your last question:
20160329 00:56:41< mattsc> https://github.com/wesnoth/wesnoth/blob/master/data/ai/micro_ais/micro_ai_helper.lua#L41
20160329 00:58:32-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160329 01:01:40-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20160329 01:01:40-!- wedge010 is now known as wedge009
20160329 01:02:27< celticminstrel> I think it would be sorta nice if [micro_ai] could be used in [side] and [unit] (or [side][ai] and [unit][ai]).
20160329 01:03:05< celticminstrel> Yeah, that comment is probably what lead to the question. I wonder if there's any good way to clear out the dead ones.
20160329 01:04:44< celticminstrel> Maybe I can use messenger escort instead of [leader_goal] in my campaign's swamp scenario...
20160329 01:07:16< celticminstrel> Oh, currently I'm using goto...
20160329 01:07:29< celticminstrel> ...and also leader_goal...
20160329 01:07:59< celticminstrel> I'm not sure which of those two takes precedence, probably goto...
20160329 01:15:17-!- nos__ is now known as Nosaj
20160329 01:15:50< celticminstrel> Huh, I crashed Wesnoth (1.12) again.
20160329 01:15:58-!- Nosaj is now known as NosajIRL
20160329 01:18:32-!- NosajIRL [~nos@208.91.185.104] has quit [Remote host closed the connection]
20160329 01:20:21-!- nos__ [~nos@208.91.185.104] has joined #wesnoth-dev
20160329 01:20:31-!- travis-ci [~travis-ci@ec2-54-167-70-137.compute-1.amazonaws.com] has joined #wesnoth-dev
20160329 01:20:32< travis-ci> wesnoth/wesnoth#9088 (master - ff11fec : mattsc): The build has errored.
20160329 01:20:32< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119124139
20160329 01:20:32-!- travis-ci [~travis-ci@ec2-54-167-70-137.compute-1.amazonaws.com] has left #wesnoth-dev []
20160329 01:24:32< vultraz> dammit
20160329 01:24:38< vultraz> now I've crashed wesnoth 1.13 :|
20160329 01:25:20-!- nos__ is now known as NosajIRL
20160329 01:26:00< vultraz> dammit
20160329 01:33:09< vultraz> this is a bit more complicated than I thought..
20160329 01:43:17< vultraz> ok, I have... something
20160329 01:43:32< vultraz> I just have to figure out why the non-modal dialog isn't working properly
20160329 01:52:34< vultraz> gaah
20160329 01:56:28< mattsc> “celticminstrel: I'm not sure which of those two takes precedence, probably goto…” — depends on what CA eval score you use.
20160329 02:02:23< vultraz> GAH
20160329 02:08:23< vultraz> ...wha???
20160329 02:08:47< vultraz> show_non_modal() sets show_mode_ to modal :|
20160329 02:10:32< vultraz> I need Aginor for this
20160329 02:13:17< mattsc> celticminstrel: if you’re interested in an AI behavior for your campaign that cannot be done with the existing MAIs, let me know.  I haven’t done that in a while.  :)
20160329 02:24:09-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160329 02:29:42< vultraz> AH
20160329 02:29:46< vultraz> I needed to call events::pump();
20160329 02:35:48< vultraz> I now have a mostly-working implementation of a gui2 loadscreen
20160329 02:38:18-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160329 02:54:25< celticminstrel> A GUI2 loadscreen? O_O Wow.
20160329 03:04:32< vultraz> celticminstrel: with the tiny problem that it blocks all input in-game :P
20160329 03:04:40< celticminstrel> Eh?
20160329 03:04:43< celticminstrel> What input?
20160329 03:05:03< celticminstrel> It's a loadscreen. The only input you might ever want is Cmd+Q or equivalent.
20160329 03:05:17< vultraz> I mean once you get in-game you can't do anything
20160329 03:05:20< vultraz> I'm investigating..
20160329 03:05:32< vultraz> I *think* I know why
20160329 03:05:32< celticminstrel> Well, it shouldn't be open once you get in-game.
20160329 03:05:37< vultraz> yeah
20160329 03:05:45< vultraz> I think it's being left open in the background
20160329 03:07:06< vultraz> eh...
20160329 03:07:10< celticminstrel> Oh, I'm probably using goto instead of messenger because messenger doesn't yet support [filter_second], or something...
20160329 03:09:23< vultraz> got it
20160329 03:09:45< vultraz> game_launcher::launch_game() was invoking a loadscreen instance
20160329 03:10:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 03:10:59< mattsc> [filter_second] for … ?
20160329 03:11:09< celticminstrel> The messenger escort. In 1.12.
20160329 03:11:32< celticminstrel> According the the wiki, [filter_second] was added in 1.13.0.
20160329 03:12:06< celticminstrel> I wish the forum would tell me I have an unclosed quote tag instead of complaining about quotes being too deeply nested.
20160329 03:12:13< mattsc> Hmm, that’s probably true then.
20160329 03:12:56< mattsc> It’s pretty simply to take the 1.13 MAIs and put them into your 1.12 add-on though.  (I’m sure you’re aware of that.)
20160329 03:13:32< celticminstrel> Yeah, I imagine it is.
20160329 03:13:43< celticminstrel> I guess what you'd do is overwrite the [micro_ai] tag.
20160329 03:14:04< mattsc> There’s even a section at the end of the wiki page that tells you how to do that, although I have not checked if it’s still up to date.
20160329 03:14:22-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160329 03:14:28< mattsc> Well, what I suggest doing is creating a [micro_ai_my_campaign] (or whatever) tag.
20160329 03:14:57< celticminstrel> Nah, I'd overwrite [micro_ai]. Then all I need to do when updating to 1.14 is delete a chunk of code.
20160329 03:14:58< mattsc> *what is suggested at the end of the wiki page.
20160329 03:15:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20160329 03:15:33< mattsc> So, celticminstrel, let’s assume I have two instances of the same MAI and I do a [micro_ai]action=remove without an id, what do you think is the correct behavior in that case?
20160329 03:15:57< mattsc> Remove the first it encounters?
20160329 03:16:00< celticminstrel> Uh. Were they added with an ID?
20160329 03:16:00< mattsc> Remove both?
20160329 03:16:30< mattsc> Let’s assume I don’t know what their IDs are.
20160329 03:16:30< celticminstrel> I think I'd expect it to remove either the first one that was added with no ID or all those that were added with no ID... I guess that still leaves the question open.
20160329 03:16:36< mattsc> Remove neither?
20160329 03:16:47< celticminstrel> I'm not sure...
20160329 03:16:51< mattsc> Remove the one with the standard ID, but only if it exists?
20160329 03:17:16< mattsc> Yeah, exactly.  Me neither.
20160329 03:17:31< mattsc> That’s why I am contemplating making the id required for removal.
20160329 03:18:19< celticminstrel> I've noted that the instructions don't apply to 1.13.5 onward. Presumably they can be updated at some point, though.
20160329 03:18:36< mattsc> Yeah, I am aware of that …
20160329 03:18:38< celticminstrel> Yeah, I think maybe the ID should be required for removal. However...
20160329 03:18:49< mattsc> And, as you, I am not looking forward to updating that.
20160329 03:18:56< mattsc> But at some point I probably will.
20160329 03:19:09< celticminstrel> [Mar 28@11:16:51pm] mattsc: Remove the one with the standard ID, but only if it exists?
20160329 03:19:11< celticminstrel> This sounds like the best option of those you listed - either that or do nothing.
20160329 03:19:32< celticminstrel> Yeah, for now I just edited the page to note that the instructions are out-of-date.
20160329 03:19:47< mattsc> Well, that’s what it does at the moment, but then it runs into a different problem (which is what happens in the Goto scenario).
20160329 03:20:13< celticminstrel> Okay, what's this different problem?
20160329 03:20:19< mattsc> Apparently, wesnoth.sides[side].__cfg is not updated right after you remove a CA.
20160329 03:20:54< mattsc> And thus, a change, which is a delete directly followed by an add, creates a CA with incremented id.
20160329 03:21:11< celticminstrel> I honestly have no idea when that's updated, but I suspect that if you used wesnoth.get_sides() it might work.
20160329 03:21:36< mattsc> But that does not contain the [micro_ai] tags, does it?
20160329 03:22:04< mattsc> Which is then not the standard any more, and you end up with two CAs with the same score and the old one takes preference in the case of the Goto scenario.
20160329 03:22:12< mattsc> So that’s what’s happening there.
20160329 03:22:21< celticminstrel> wesnoth.sides is populated from wesnoth.get_sides(), actually. I think wesnoth.sides might possibly be slated for deprecation (though I personally prefer it to wesnoth.get_sides(), so maybe not).
20160329 03:23:19< mattsc> Hmm …
20160329 03:23:26< celticminstrel> get_sides takes a filter.
20160329 03:23:53< celticminstrel> I think the C++ initialization code calls it with an empty table and assigns the result to wesnoth.sides.
20160329 03:24:03< mattsc> Hmm.
20160329 03:24:30< mattsc> That sounds like a workaround that might break if anything about either function is ever changed.
20160329 03:25:07< celticminstrel> I think it would make more sense for wesnoth.sides to have a metatable whose __index function calls wesnoth.get_sides.
20160329 03:25:18< mattsc> I have a couple possiblities of dealing with this (either on the deleting or adding of MAIs side), but I am just wondering if they are worth it.
20160329 03:25:22< celticminstrel> Though maybe that could be less efficient in some use-cases, I dunno...
20160329 03:25:32< mattsc> It sounds to me that requiring an id for removal is not a big hurdle.
20160329 03:25:48< mattsc> After all, it’s not like you’ll ever be in this situation: oh, 
20160329 03:26:02< celticminstrel> Yeah, probably not. AI components require one too. (Well okay, they do also accept integer indexes and *, but whatever.)
20160329 03:26:10< mattsc> I am in this scenario and somebody else added these MAIs and now I want to remove them but don’t know their ids…
20160329 03:26:28< mattsc> Yeah, I thought about allowing ‘*’, but then, why?
20160329 03:27:14< mattsc> I’ll sleep on it and see what I thin tomorrow, but most likely that (requiting and id) is what I’ll do.
20160329 03:27:16< celticminstrel> I dunno. Maybe someone added 50 guardian MAIs and wants to remove them all at once.
20160329 03:27:27< mattsc> Yeah, maybe.
20160329 03:27:33< mattsc> Could happen, esp. with macros.
20160329 03:27:34< celticminstrel> Because the way the guardian MAIs are currently set up, you need one per unit.
20160329 03:27:52< mattsc> Some of them, yes.
20160329 03:28:07< mattsc> You can do zone guardians for a whole bunch of them.
20160329 03:28:26< celticminstrel> Oh, yeah, I can see how that might work.
20160329 03:28:41< celticminstrel> As long as you don't need station_x|y
20160329 03:29:53< celticminstrel> Is "ai_special=guardian" considered to be deprecated in favour of "[status]guardian=yes"?
20160329 03:31:16< vultraz> yes, but no one really wants to use the new syntax
20160329 03:31:41< vultraz> so it's not a hard deprecation
20160329 03:31:59< celticminstrel> I do think it's a little weird for it to be done as a status effect; I'd prefer something like [ai]special=guardian (maybe a different key-name, I dunno).
20160329 03:46:50< mattsc> Hmm, I use 133 calls to the transparent portraits in my campaigns …
20160329 03:47:14< celticminstrel> If I recall correctly, the engine does detect and convert them if necessary.
20160329 03:47:23< celticminstrel> As does wmllint.
20160329 03:47:46< mattsc> The engine did not do it in the Guardians test scenario
20160329 03:47:56< celticminstrel> Or Find In Files in TextWrangler.
20160329 03:48:10< celticminstrel> Really? Huh. I thought vultraz coded for that.
20160329 03:48:12< mattsc> Yeah, it’s really pretty easy to do.
20160329 03:48:40< vultraz> but i did code it for that..
20160329 03:48:52< celticminstrel> Oh, wait.
20160329 03:49:07< celticminstrel> He probably only did that for unit portraits, not for uses of the images elsewhere, eg in [message].
20160329 03:49:23< celticminstrel> ie, the auto-conversion may only work for portraits set in the unit type.
20160329 03:49:28< vultraz> ah, right
20160329 03:49:29< vultraz> yes
20160329 03:49:54< vultraz> one needs to run wmllint
20160329 03:49:57< celticminstrel> Maybe a couple of lines could be added in [message] to handle it, too.
20160329 03:50:20< celticminstrel> I think gfgtdf added something to check if a file exists.
20160329 03:50:38< celticminstrel> ...though that may be more for config files than binary files.
20160329 03:51:36< vultraz> look at the adjust_profile function
20160329 04:07:03< celticminstrel> I wonder if [set_variable]random= would be slow with a list of 300 or so items.
20160329 04:11:47< vultraz> celticminstrel: I think I asked this before, but I forgot - you don't need 'explicit' for a 0-argument constructor, right?
20160329 04:11:56< celticminstrel> Nope.
20160329 04:12:24< celticminstrel> Explicit is only for constructors that can be called with exactly 1 argument.
20160329 04:12:51< celticminstrel> (And in C++11, for conversion operators.)
20160329 04:13:06< celticminstrel> (Which is kinda like a reverse constructor.)
20160329 04:59:15< vultraz> ALMOST got this loadscreen working
20160329 04:59:49< vultraz> just a few minor issues
20160329 05:00:21< vultraz> * game starts with a white screen before the loadscreen shows
20160329 05:00:33< vultraz> * loadscreen doesn't show when connecting to mp game...
20160329 05:01:07< vultraz> celticminstrel: btw, do you get an assert when trying to end turn
20160329 05:01:18< vultraz> if not, I broke something :|
20160329 05:02:46< celticminstrel> I don't recall such a think ever happening. Except in the test scenario.
20160329 05:03:06< celticminstrel> Though that was awhile ago (like, months) and I'm not sure if it was specifically an assert.
20160329 05:03:43< vultraz> I mean with current master
20160329 05:04:04< vultraz> can you test if ending a turn produces an assert 
20160329 05:04:18< celticminstrel> It never happened when I was testing MAIs.
20160329 05:04:31< celticminstrel> Should I try in a campaign? Or multiplayer?
20160329 05:04:38< vultraz> either
20160329 05:06:15-!- Kwandulin [~Miranda@p200300760F191C183CB7A62CF2270237.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160329 05:06:18 * celticminstrel has spent the last hour or so working out probabilities for my campaign. Lots of math.
20160329 05:10:35< celticminstrel> Note: I did at one point push a commit that would produce assert when an AI side begins its turn, so if you're not completely up-to-date on master you might still have that. On latest master I'm not getting any asserts when ending a turn.
20160329 05:16:17< Aginor> 13:37 < shadowm> GUI2 non-modal windows are as real as unicorns and gnomes.
20160329 05:16:35< Aginor> shadowm: I will make unicorns and gnomes appear soon then :)
20160329 05:16:50< celticminstrel> New unit lines? :P
20160329 05:17:18 * Aginor has a cunning plan
20160329 05:22:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 05:27:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20160329 05:43:43< irker922> wesnoth: Celtic Minstrel wesnoth:master aed87126eed7 / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: XCode: Remove empty testing group https://github.com/wesnoth/wesnoth/commit/aed87126eed77e300fc3bc7b3f13632ec3834f66
20160329 06:12:57< vultraz> Aginor: I've already done it
20160329 06:13:16< vultraz> the functionality was already here
20160329 06:14:43< vultraz> Aginor: but if you're around I have some questions
20160329 06:17:52< vultraz> celticminstrel: ah, I pulled and the assert went away
20160329 06:33:30-!- travis-ci [~travis-ci@ec2-54-205-57-183.compute-1.amazonaws.com] has joined #wesnoth-dev
20160329 06:33:31< travis-ci> wesnoth/wesnoth#9090 (master - aed8712 : Celtic Minstrel): The build has errored.
20160329 06:33:31< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119160919
20160329 06:33:31-!- travis-ci [~travis-ci@ec2-54-205-57-183.compute-1.amazonaws.com] has left #wesnoth-dev []
20160329 06:39:18-!- celticminstrel is now known as celmin|sleep
20160329 06:43:45< Aginor> vultraz: I was gone, now I am not
20160329 06:44:48< vultraz> so I'm working on a gui2 loading screen
20160329 06:46:42< vultraz> however, since it's gui2, gui2 needs to be initialized before I can show it
20160329 06:46:52< vultraz> meaning there's noa  period after launch when the screen is white
20160329 06:46:54< vultraz> how would you deal with this
20160329 06:46:57< vultraz> now*
20160329 06:50:47< Aginor> render screen black at initialisation
20160329 06:51:09< Aginor> that sounds like a silly answer, right?
20160329 06:51:24< vultraz> that's what I was thinking
20160329 06:51:32< vultraz> just wanted to know if it was the 'right' way to do it
20160329 06:51:34< Aginor> but what I mean is, render it black, to make sure it's initialised. If GUI2 renders it white during initialisation, change it
20160329 06:51:52< Aginor> make the SDL window paint itself black when it's initialised
20160329 06:51:53< vultraz> oh, I thought sdl2 did that
20160329 06:51:58< Aginor> is what I'd argue for
20160329 06:52:06< Aginor> nope
20160329 06:53:33< Aginor> vultraz: so, you've made non-modal GUI2 dialogs?
20160329 06:54:21< vultraz> the functionality was already there
20160329 06:54:27< vultraz> tooltips were non-modal windows
20160329 06:54:46< vultraz> I simply copied the code in tpopup 
20160329 06:54:52-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20160329 06:55:00< vultraz> we might want to add a show_non_modal function to tdialog, I'm not sure
20160329 06:55:17< vultraz> I did have to add an events::pump() call to twindow::show_non_modal() to make it work, though
20160329 06:55:36< Aginor> yeah...
20160329 06:55:41< vultraz> and keep in mind i have no idea if it works in say, the main game
20160329 06:55:42< Aginor> I want to take them all out :)
20160329 06:56:05< Aginor> instead call play_slice
20160329 06:56:10< vultraz> will be some minor conflicts with renderpathfixes
20160329 06:56:12< Aginor> which will update events
20160329 07:05:26 * Aginor wants less calls to events::pump(), not more
20160329 07:05:47< Aginor> simplify, decouple, DRY!
20160329 07:06:25< vultraz> Aginor: it's just one extra call :P
20160329 07:06:54< Aginor> it's yet another call for me to root out and remove now
20160329 07:07:05< Aginor> adding yet another layer of complexity for me to decomplexify
20160329 07:07:53< vultraz> sorry :/
20160329 07:08:20< Aginor> it's alright
20160329 07:08:30< vultraz> I can't do better until rpf is merged
20160329 07:08:46< Aginor> I just figured that I'd go on a rant because it's contrary to the work I'm doing
20160329 07:08:50< Aginor> rpf?
20160329 07:09:55< vultraz> renderpathfixes
20160329 07:10:16< vultraz> but look at it this way
20160329 07:10:27< Aginor> it's alright
20160329 07:10:34< Aginor> I won't kill that in renderpathfixes
20160329 07:10:34-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160329 07:10:39< vultraz> moving the loadscreen to gui2 is another step towards unifying the handling
20160329 07:10:48< vultraz> of dialogs
20160329 07:11:15< Aginor> we need more than just dialogs though, we need to strive towards main game window being GUI2 too
20160329 07:13:18< vultraz> one step at a time
20160329 07:13:41< vultraz> the discovery that it's possible to have non-modal dialogs is a big thing
20160329 07:22:41< Aginor> it saves us a wee bit of trouble
20160329 07:26:35< zookeeper> regarding the loading screen progress bar: an imprecise progress bar is still better than no progress bar. a spinning whatevers which give you absolutely no feedback about whether it's getting anywhere are annoying, unless it always takes only a few seconds max.
20160329 07:27:13< Aginor> zookeeper: I fully agree
20160329 07:27:32< zookeeper> i was looking at the progress bad code a while back and AFAICT it's basically based on mainline-derived magic values which are likely obsolete and should at the very least be re-calculated.
20160329 07:27:47< irker922> wesnoth: Andreas Löf wesnoth:renderpath_redo 5114137e1610 / src/gui/core/event/handler.cpp: Make GUI2 properly forward pre- and post-draw events. https://github.com/wesnoth/wesnoth/commit/5114137e1610a29a058d643329c0cf287c7fc5da
20160329 07:29:04< vultraz> zookeeper: my new design sans bar actually gives faster load times
20160329 07:29:08< vultraz> I'd say that is more important
20160329 07:29:22< zookeeper> well, what are the numbers?
20160329 07:29:42< vultraz> That's the point - it doesn't spend time drawing the bar.
20160329 07:29:57< vultraz> The existing numbers weren't that far off
20160329 07:30:10< zookeeper> by numbers i mean the times you measured
20160329 07:30:14< zookeeper> how much faster is it?
20160329 07:30:28< Aginor> the time spent drawing those bars ought to be close to negligible
20160329 07:30:45< vultraz> I'd say up to half a second shaved off
20160329 07:30:58< zookeeper> from how much?
20160329 07:31:25< Aginor> vultraz: repeatable? with controlled load on the system and IO?
20160329 07:31:25< vultraz> I haven't done scientific measurements :|
20160329 07:31:35< Aginor> what's the variance?
20160329 07:31:38< Aginor> ah
20160329 07:31:46< Aginor> crap numbers like I had a week ago :)
20160329 07:31:46< zookeeper> i'm not asking for scientific measurements
20160329 07:31:51< vultraz> Aginor: it's not the time drawing the bars, it's the time animating the progress
20160329 07:31:55< Aginor> mine were very crap
20160329 07:32:13< vultraz> cut that out and the time you spend on a loading screen is noticeably shorter.
20160329 07:32:37< Aginor> vultraz: it redraws the entire screen though. If redrawing the entire screen a few times takes ~500ms there's something horribly wrong
20160329 07:33:48 * Aginor goes to break the FPS counter
20160329 07:34:15< zookeeper> vultraz, so i'm just going to go and assume that you shaved off 0.5s from, say, 15s. in which case no i don't think that's worth losing the progress bar.
20160329 07:34:35< vultraz> ...15??!
20160329 07:34:46< vultraz> if your loading screen takes 15 seconds you have a problem
20160329 07:34:48< zookeeper> you'll tell me when you know the actual number
20160329 07:35:38< zookeeper> in the meantime i'll continue to agonize over the fact that i still have no idea what to do about this: cl : Command line error D8036: '/FoReleaseDEBUG\utils' not allowed with multiple source files
20160329 07:36:39< Aginor> if I want to introduce a new class for counting FPS, where's a good place to put it? (new file)
20160329 07:36:43< Aginor> util?
20160329 07:36:46< Aginor> tool?
20160329 07:37:27< Aginor> just directly in src?
20160329 07:38:13< vultraz> yes
20160329 07:38:58< Aginor> fair enough
20160329 07:39:22< Aginor> I'll go and introduce a fps-class there then
20160329 07:39:57< vultraz> hmm
20160329 07:40:08< vultraz> seems gui2 isn't what colors the window whitwe
20160329 07:40:10< vultraz> white
20160329 07:41:04< zookeeper> as for the progress bar being slow, i'm pretty sure that's just because increment_progress() gets called for every [terrain_graphics] rule and every [unit_type], and every one of those involves a redraw. if you just fix that, then i'm pretty sure the problem goes away.
20160329 07:41:30< zookeeper> i'd tell you how many rules there are if i could compile.
20160329 07:41:51< vultraz> or maybe it is..?
20160329 07:42:27< vultraz> what is doing this!
20160329 07:42:45< zookeeper> or, in other words, increment_progress() should just increment a counter, and the redraw should happen separately whenever the renderer/whatever has time.
20160329 07:43:09< zookeeper> or alternatively progress could just be incremented every 10th time.
20160329 07:43:24< zookeeper> ...which would be super simple to do
20160329 07:43:43< zookeeper> (i think)
20160329 07:48:30< vultraz> something is setting it to white :|
20160329 07:49:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 07:50:41< Aginor> I agree with zookeeper 
20160329 07:54:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160329 07:54:30< vultraz> Aginor: I can manually set the screen to black with fill_rect but I don't think that's the best solution
20160329 08:00:24< Aginor> vultraz: figure out what fills it with white then
20160329 08:01:51< irker922> wesnoth: ln-zookeeper wesnoth:master 4336e0fb0340 / data/core/ (27 files in 2 dirs): Merged slightly modified sand shores into the beach waves animation https://github.com/wesnoth/wesnoth/commit/4336e0fb0340145d452a664a84ac87cb97cab202
20160329 08:19:59< vultraz> Aginor: ok I think I figured it out
20160329 08:20:21< vultraz> the twindow (sdl) class calls fill(0,0,0) in its constructor
20160329 08:20:43< vultraz> however, that doesn't take effect for some reason
20160329 08:20:54< vultraz> it does if I call flip() right after "window.reset(new sdl::twindow("", x, y, w, h, video_flags, SDL_RENDERER_SOFTWARE));"
20160329 08:20:59< vultraz> in video.cpp
20160329 08:21:50< vultraz> Aginor: or, I can call render() at the end of the twindow constructor (SDL_RenderPresent() wrapper)
20160329 08:21:52< vultraz> that works too
20160329 08:21:57< vultraz> Aginor: which would you rather I do?
20160329 08:27:15-!- Greywhind [~Greywhind@c-71-232-29-126.hsd1.ma.comcast.net] has quit [Ping timeout: 248 seconds]
20160329 08:27:27-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 264 seconds]
20160329 08:28:03-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20160329 08:28:16-!- Greywhind [~Greywhind@c-71-232-29-126.hsd1.ma.comcast.net] has joined #wesnoth-dev
20160329 08:59:50-!- travis-ci [~travis-ci@ec2-23-23-47-74.compute-1.amazonaws.com] has joined #wesnoth-dev
20160329 08:59:51< travis-ci> wesnoth/wesnoth#9092 (master - 4336e0f : ln-zookeeper): The build has errored.
20160329 08:59:51< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119180658
20160329 08:59:51-!- travis-ci [~travis-ci@ec2-23-23-47-74.compute-1.amazonaws.com] has left #wesnoth-dev []
20160329 09:10:34< wedge009> zookeeper: Not really... was it fixed? I can't get master to compile as at 09:00 UTC.
20160329 09:11:31< wedge009> Linking error in lua_object, relating to store() and to_type().
20160329 09:12:12< wedge009> And aspect_attacks compiled object.
20160329 09:12:59< zookeeper> wedge009, no, it still persists
20160329 09:13:11< wedge009> What are you compiling with?
20160329 09:13:23< zookeeper> VS 2013
20160329 09:14:15< wedge009> Honestly, I don't use ReleaseDEBUG option - I made my own Debug and Release builds based on the originals, which cater for SDL2.
20160329 09:14:36-!- travis-ci [~travis-ci@ec2-23-23-47-74.compute-1.amazonaws.com] has joined #wesnoth-dev
20160329 09:14:37< travis-ci> wesnoth/wesnoth#9091 (renderpath_redo - 5114137 : Andreas Löf): The build has errored.
20160329 09:14:37< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119174516
20160329 09:14:37-!- travis-ci [~travis-ci@ec2-23-23-47-74.compute-1.amazonaws.com] has left #wesnoth-dev []
20160329 09:14:43< zookeeper> well, i'm assuming it's not specific to ReleaseDEBUG
20160329 09:14:54< Aginor> vultraz: have the sdl-window class use SDL or its own functions if possible. That way it doesn't have any external dependencies
20160329 09:15:04< vultraz> ok
20160329 09:53:45< Aginor> does anyone know of the benchmark mode that I've found references to in display.cpp
20160329 09:53:48< Aginor> is it still used?
20160329 09:53:50-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20160329 09:55:48-!- Kwandulin [~Miranda@p200300760F191C183CB7A62CF2270237.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160329 10:31:52-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160329 10:31:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 10:34:35< irker922> wesnoth: Charles Dang wesnoth:master 576a88ea7d1c / src/sdl/window.cpp: Properly rendering background fill color when creating SDL windows https://github.com/wesnoth/wesnoth/commit/576a88ea7d1c78c63a2ec492d10f7dd278915e1c
20160329 10:34:38< irker922> wesnoth: Charles Dang wesnoth:master 60910506c620 / src/gui/widgets/window.cpp: GUI2: call events pump when showing non-modal dialogs https://github.com/wesnoth/wesnoth/commit/60910506c620a3fb325c63a5d7f37d20a4b1d383
20160329 10:34:41< irker922> wesnoth: Charles Dang wesnoth:master 465f5eece176 / / (20 files in 8 dirs): Implement new GUI2 loadscreen https://github.com/wesnoth/wesnoth/commit/465f5eece176258b63e9138d1b30f0adeb9083eb
20160329 10:35:12< vultraz> Aginor: ^
20160329 10:36:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds]
20160329 10:37:31-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160329 10:43:45-!- Nobun [~nobun@5.170.195.86] has joined #wesnoth-dev
20160329 10:45:09< vultraz> One downside to having it use GUI2 is that GUI2 needs to initialize before it can show up 
20160329 10:46:29< vultraz> Will investigate a solution
20160329 10:47:14-!- travis-ci [~travis-ci@ec2-54-167-70-137.compute-1.amazonaws.com] has joined #wesnoth-dev
20160329 10:47:15< travis-ci> wesnoth/wesnoth#9093 (master - 465f5ee : Charles Dang): The build failed.
20160329 10:47:15< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119207585
20160329 10:47:15-!- travis-ci [~travis-ci@ec2-54-167-70-137.compute-1.amazonaws.com] has left #wesnoth-dev []
20160329 10:48:13< vultraz> Currently, you can't call gui2::init(); before an sdl window exists.. for some reason
20160329 10:50:55< vultraz> It takes about 0.6 seconds to parse the whole gui2 config block 
20160329 10:53:35< irker922> wesnoth: Charles Dang wesnoth:master cc368b181100 / src/ (CMakeLists.txt SConscript): Fixup cmake and scons https://github.com/wesnoth/wesnoth/commit/cc368b18110036360c8a829dcbebfe11b999f32a
20160329 10:57:49< Nobun> vultraz: only a suggestion, seeing what happened in past
20160329 10:58:28< Nobun> I suggest to you devs to consider to allow user to choose from classical aspect of the GUI with the new one you are implementing
20160329 10:58:39< Nobun> (if possible)
20160329 10:59:10< Nobun> so, if someone finds the new GUI structure not confortable to use, they could revert back to the classical aspect
20160329 11:00:11< Nobun> (it is off-topic, but I'm evaluating on using wesnoth 1.10 for map and scenarios develpoment... I found the old map editor mor confortable than the new one)
20160329 11:00:59-!- Nobun [~nobun@5.170.195.86] has quit [Quit: Salve a tutti]
20160329 11:12:44-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160329 11:18:54-!- Kwandulin [~Miranda@p200300760F191C18F4811BBC10D1D014.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160329 11:56:53< irker922> wesnoth: ln-zookeeper wesnoth:master 0eed39ff23be / data/ (5 files in 2 dirs): Changed terrain code of desert mountains from Mdy to Mdd https://github.com/wesnoth/wesnoth/commit/0eed39ff23be490e8ea1c151cab191bc57b260e2
20160329 11:56:55< irker922> wesnoth: ln-zookeeper wesnoth:master cb2e8bc412ed / changelog: Updated changelog https://github.com/wesnoth/wesnoth/commit/cb2e8bc412ed4134d0e0124c49b879cbeeebb417
20160329 12:21:13-!- solvents [~quassel@69-196-152-213.dsl.teksavvy.com] has joined #wesnoth-dev
20160329 12:30:29-!- solvents [~quassel@69-196-152-213.dsl.teksavvy.com] has quit [Remote host closed the connection]
20160329 12:37:17-!- Kwandulin [~Miranda@p200300760F191C18F4811BBC10D1D014.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds]
20160329 12:55:09-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160329 12:56:52-!- mjs-de [~mjs-de@f049100065.adsl.alicedsl.de] has joined #wesnoth-dev
20160329 12:58:25-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160329 13:01:56-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20160329 13:01:57-!- wedge010 is now known as wedge009
20160329 13:03:50-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160329 13:08:15-!- NosajIRL [~nos@208.91.185.104] has quit [Ping timeout: 276 seconds]
20160329 13:09:59< celmin|sleep> For the record, vultraz, have some unscientific old loading screen numbers - 3-7 seconds for initial load, 5-7 seconds to load an MP game in my test scenario (combined from before and after the create dialog), 5-15 seconds to load HTTT (and for some reason the bar reset halfway through), 2 seconds to reload from title screen, 10 seconds to load ANL in MP.
20160329 13:10:00< celmin|sleep> Nobun: That kind of option would be a maintenance nightmare, sorry.
20160329 13:10:01< celmin|sleep> wedge009/zookeeper: What's this about a link error?
20160329 13:10:16< zookeeper> only what i've mentioned
20160329 13:11:05< celmin|sleep> I think it was wedge009 who mentioned the link error, but I thought you confirmed it or something.
20160329 13:12:21< celmin|sleep> My first suggestion is adding extern to the template declaration at the bottom of lua_object.hpp (though I think that's a C++11 feature).
20160329 13:16:04< celmin|sleep> (But I think it's also one of those C++11 features that was added because several compilers were supporting it already.)
20160329 13:21:35< zookeeper> and where is that file?
20160329 13:22:05< zookeeper> nevermind
20160329 13:22:50< zookeeper> so what should i add?
20160329 13:24:10< celmin|sleep> And now, some unscientific numbers for the new loading screen - 2 seconds for initial load, 2 seconds for ANL (it no longer shows up at all between or after the MP create screens. o_o ), 5-8 seconds for HTTT, 2 seconds to reload from the title screen.
20160329 13:25:04< celmin|sleep> zookeeper: At the bottom of the file (in src/ai/lua), there's a template function declaration. I'm proposing adding extern to the beginning of that line.
20160329 13:25:24< celmin|sleep> BTW, the new loadscreen is about as terrible as I anticipated.
20160329 13:25:24< zookeeper> lua_object.hpp(206): error C2059: syntax error : ''template<''
20160329 13:25:44< celmin|sleep> Extern would go on the line after that.
20160329 13:26:01< zookeeper> well you could have said so
20160329 13:26:14< zookeeper> lua_object.hpp(207): warning C4630: 'ai::lua_object<ai::aspect_attacks_lua_filter>::to_type' : 'extern' storage-class specifier illegal on member definition
20160329 13:26:37< celmin|sleep> Hmm, okay. I guess that's not going to work, then. :/
20160329 13:28:00< celmin|sleep> I really don't want to have to move that whole function into the header (from lua_object.cpp) if I can avoid it, but... that would be a way of fixing that link error, if I understand it correctly.
20160329 13:28:49-!- celmin|sleep is now known as celticminstrel
20160329 13:28:49< irker922> wesnoth: Celtic Minstrel wesnoth:master 49fc414cc614 / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: Update XCode project https://github.com/wesnoth/wesnoth/commit/49fc414cc614bad8c4cf9ca65c4474a4493c65bc
20160329 13:31:56-!- Kwandulin [~Miranda@p5DDD14D4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160329 13:35:29< mattsc> celticminstrel: umm, protect_unit is working now ...
20160329 13:36:03< celticminstrel> Huh, okay. Maybe one of the other fixes I've been pushing also fixed it.
20160329 13:36:37< mattsc> I assume so.
20160329 13:36:58< mattsc> It would be interesting to go back and figure out what happened, but … I guess I don’t care enough.
20160329 13:40:25< zookeeper> celticminstrel, so what exactly do i need to move to exactly where?
20160329 13:40:51-!- gfgtdf [~chatzilla@f054048082.adsl.alicedsl.de] has joined #wesnoth-dev
20160329 13:42:06< celticminstrel> zookeeper: The function declared at the bottom of lua_object.hpp is defined in lua_object.cpp; you would need to copy the braced portion (including the braces) and paste it into lua_object.hpp to replace the semicolon in the declaration. You would also need to add one or two includes to the top of lua_object.hpp (and probably remove them from lua_object.cpp).
20160329 13:44:03< zookeeper> ok. and i can leave the .cpp unchanged?
20160329 13:44:29< celticminstrel> Oh right, you'd also need to add inline where I previously suggested adding extern.
20160329 13:44:41< celticminstrel> I'm not sure if you can leave the .cpp unchanged; feel free to try it.
20160329 13:44:54-!- gfgtdf [~chatzilla@f054048082.adsl.alicedsl.de] has quit [Client Quit]
20160329 13:46:52< zookeeper> no luck, just masses of errors.
20160329 13:48:45< celticminstrel> :/
20160329 13:49:07< celticminstrel> mattsc: I've been thinking about implementing something along these lines, any thoughts? https://wiki.wesnoth.org/User:Celtic_Minstrel/UnitBehaviourProposal
20160329 13:49:10< mattsc> celticminstrel: I am done testing the ExpAI and the MAIs then (except for the Fast AI).  Everything appears to be working.
20160329 13:49:21< celticminstrel> Okay.
20160329 13:51:21< mattsc> celticminstrel: Looks okay, my main questions is why add yet a different way of doing things?
20160329 13:51:29< mattsc> And I think I know what you will say ...
20160329 13:51:53< celticminstrel> Because the unit formulas approach feels more convenient for some kinds of situations.
20160329 13:52:19< mattsc> Yes, that’s what I expected.  But can you be more specific?
20160329 13:52:34< celticminstrel> More specific as in... suggesting some situations?
20160329 13:52:39< mattsc> Why is adding a tag to a unit more convenient than adding another tag with a filter to an event?
20160329 13:52:51< mattsc> s/another/a different
20160329 13:55:38-!- Appleman1234 [~Appleman1@KD106161136087.au-net.ne.jp] has quit [Ping timeout: 244 seconds]
20160329 13:57:34< mattsc> celticminstrel: Just asking.  I have no general objections.
20160329 13:57:49< zookeeper> celticminstrel, taking out everything relating to to_type() in lua_object.*pp does fix the compilation issue
20160329 13:57:52< zookeeper> err
20160329 13:57:56 * zookeeper facepalms
20160329 13:58:06< zookeeper> it does _not_ fix the compilation issue
20160329 13:58:09< celticminstrel> ...I can't think of a reason... putting it in a unit does mean it's directly linked to the unit, but I'm not sure that's about convenience... I suppose it could mean that AI behaviour can be carried between scenarios (though in many cases you wouldn't actually want that).
20160329 13:58:10< zookeeper> so presumably it's not that
20160329 13:59:04< celticminstrel> (But in some cases you might want it, like an enemy unit who shows up repeatedly and, I dunno, behaves cowardly by running away as soon as he takes any damage.)
20160329 13:59:42< mattsc> celticminstrel: Hmm, yes, that would be a reason, I guess.
20160329 14:00:11< mattsc> I’m not sure if that were enough of a reason for me to add this, but then, I don’t have to do the work.  ;)
20160329 14:00:21< celticminstrel> It does also feel more convenient somehow for guardians or patrols, but I think I can't attribute that to anything more than a feeling.
20160329 14:00:49< mattsc> celticminstrel: I do agree with that feeling though.  But also that it is only a feeling.
20160329 14:01:58< mattsc> Btw, the guardians and patrols used to be BCAs, and we changed that at some point going through the same kind of arguments: that we could not come up with a good reason not to, and because then you can apply some of them to multiple units at the same time.
20160329 14:02:46< celticminstrel> Weren't BCAs just a [candidate_action] tag with special parameters?
20160329 14:03:20< mattsc> I don’t think so, unless I misunderstand you.  They were attached directly to a unit.
20160329 14:03:34< mattsc> Well, they still are, I think.  You didn’t remove them, right?
20160329 14:03:45< celticminstrel> I think so. I clearly don't really understand how they work.
20160329 14:04:14< mattsc> Well, and you might quite well right when it comes to how they work.  But from the user side they were attached to the unit.
20160329 14:04:31< celticminstrel> How do you declare a BCA?
20160329 14:04:37< celticminstrel> In the WML.
20160329 14:05:07< mattsc> https://wiki.wesnoth.org/Lua_AI_Legacy_Methods_Howto#Behavior_.28Sticky.29_Candidate_Actions
20160329 14:06:59< celticminstrel> Ah, a different WML tag.
20160329 14:07:17< celticminstrel> But ultimately it is just a [candidate_action] tag with special parameters.
20160329 14:07:23< celticminstrel> This is hidden from the user, but still.
20160329 14:07:37< mattsc> Yeah.
20160329 14:07:39-!- travis-ci [~travis-ci@ec2-107-20-97-135.compute-1.amazonaws.com] has joined #wesnoth-dev
20160329 14:07:40< travis-ci> wesnoth/wesnoth#9096 (master - 49fc414 : Celtic Minstrel): The build has errored.
20160329 14:07:40< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119243288
20160329 14:07:40-!- travis-ci [~travis-ci@ec2-107-20-97-135.compute-1.amazonaws.com] has left #wesnoth-dev []
20160329 14:09:03< celticminstrel> (So you could declare it as such instead of using the WML tag, if you wanted to.)
20160329 14:10:15< mattsc> Sure.
20160329 14:10:50< mattsc> celticminstrel: btw, I don’t know if I said that, I like what you did with the MAI code.
20160329 14:11:09< mattsc> Was there anything else I said I would do?
20160329 14:11:20< celticminstrel> You mean the wesnoth.micro_ais table?
20160329 14:11:28< celticminstrel> I don't remember anything else you said you would do.
20160329 14:11:47< mattsc> Among other things; also how tags are now dealt with etc.
20160329 14:12:05< mattsc> I’ll still fix the bats in the Goto scenario and test the Fast MAI after you’re done with the aspect.
20160329 14:12:45< mattsc> But besides that, I think I’ll go back to working on AIs for a bit, rather than the AI framework.  :)
20160329 14:13:34-!- Horus2 [~Horus2@91.83.185.113.pool.invitel.hu] has joined #wesnoth-dev
20160329 14:13:57< mattsc> I still want to set up a series of AIs that can play through HttT on medium sometime.
20160329 14:24:18< celticminstrel> vultraz: I suspect the loading screen possibly should be showing after the MP create dialogs. Not entirely sure, but there was a noticeable delay, at least - around 4 seconds.
20160329 14:35:47-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160329 14:39:09 * zookeeper waits for gfgtdf in case he knows how to fix the error
20160329 14:47:51< zookeeper> i mean, i presume it has got something to do with src/utils and/or src/tests/utils
20160329 14:48:34< zookeeper> can i just exclude src/tests somehow?
20160329 14:49:09< celticminstrel> That should be possible, yeah; src/tests is the unit tests.
20160329 14:49:21< celticminstrel> src/utils on the other hand is required.
20160329 14:51:27< zookeeper> nope, didn't help.
20160329 14:52:21< zookeeper> i would have liked to see how bad the loading screen is now
20160329 14:53:39< celticminstrel> It's not quite as bad as I'd anticipated, mainly because the loading times are actually reduced significantly.
20160329 14:53:56< celticminstrel> I still think it needs some kind of animation though.
20160329 14:57:00-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160329 15:02:48< mattsc> celticminstrel: one more thing on my list: fix up one of the test scenarios you moved into the ai/ directory  (the othe two appear to be working)
20160329 15:03:02< celticminstrel> Which one isn't working?
20160329 15:03:36< mattsc> formula
20160329 15:04:01< celticminstrel> That was at least partially working when I tested it - the guardian, the priority test, and the patrol all worked.
20160329 15:04:46< mattsc> well, it produces a bunch of errors in the terminal, so there’s at least something wrong
20160329 15:05:15< celticminstrel> I dunno, there could be. I didn't look too closely.
20160329 15:05:23< celticminstrel> There's more things going on there than I tested, as well.
20160329 15:05:42< celticminstrel> The formula engine seems to dictate exact recruits for the first four or so turns.
20160329 15:05:58< mattsc> Yeah; the attacks and the patrol seem to be working; but at least recruit has some errors
20160329 15:06:11< mattsc> I’ll check it out sometime.
20160329 15:06:33-!- prkc [~prkc@192.40.89.13] has quit [Ping timeout: 276 seconds]
20160329 15:07:53-!- gfgtdf [~chatzilla@f054048082.adsl.alicedsl.de] has joined #wesnoth-dev
20160329 15:10:35< gfgtdf> zookeeper: my wesnoth build is currently busy by changing to msvc14, but my guess that teh error eigher occurs because aspect_attacks_lua_filter is an incomplet type or becasue the defintion is not in the header.
20160329 15:11:18< celticminstrel> It is, in fact, not a complete type at the time of the declaration. It should be a complete type at definition time though...
20160329 15:11:54< celticminstrel> Though the definition is not in the header, I did declare the specialization in the header, and that compiled for me. :/
20160329 15:12:42< celticminstrel> If I recall correctly, attempting to include the header that contains the incomplete type led to compile errors from circular dependencies.
20160329 15:12:47< celticminstrel> Though that might've been a different header.
20160329 15:13:03< gfgtdf> zookeeper: the second one coudl easily tested by moving the defintion in the header, for exampel by chaging the function to template <>
20160329 15:13:04< gfgtdf> inline boost::shared_ptr<aspect_attacks_lua_filter> lua_object<aspect_attacks_lua_filter>::to_type(lua_State *L, int n)
20160329 15:13:06< gfgtdf> { return aspect_attacks_lua_filter_to_type(L, n); }
20160329 15:13:08< gfgtdf> so that aspect_attacks_lua_filter> is then a simple function ddeclared in the header. but i'd give that a < 50% chance to fix the issue
20160329 15:13:17< celticminstrel> Another solution might be for the template specialization to delegate all its work to a non-template function.
20160329 15:13:32< celticminstrel> Oh wait, that's what you said, isn't it...
20160329 15:13:59< celticminstrel> I'm still not quite sure what the issue is.
20160329 15:17:32< mattsc> gfgtdf: did you see my comment that sides in MP games started with -m from the commandline have empty recruit lists?
20160329 15:17:49< mattsc> Is that related to what you fixed for tst scenarios?
20160329 15:17:58< gfgtdf> mattsc: not sure what teh cause is
20160329 15:18:21< gfgtdf> mattsc: are thse scenarios that you start  normal [multiplayer] sceanrios ?
20160329 15:18:51< mattsc> yes; just start with -m, nothing else needed
20160329 15:19:05< celticminstrel> In which case it's The Freelands, I think.
20160329 15:19:10< celticminstrel> So yeah, [multiplayer].
20160329 15:19:15< mattsc> yes
20160329 15:19:58< zookeeper> i've removed all relating to aspect_attacks_lua_filter and that doesn't fix the error
20160329 15:20:02< zookeeper> like, everywhere
20160329 15:21:05< celticminstrel> Sounds like you might have a project settings error.
20160329 15:21:15-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has joined #wesnoth-dev
20160329 15:21:18< zookeeper> well of course that's what the error implies
20160329 15:21:37-!- Kwandulin [~Miranda@p5DDD14D4.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160329 15:22:09< celticminstrel> But does it point to lua_object.cpp at all, or to any other source file?
20160329 15:22:25< zookeeper> cl : Command line error D8036: '/FoRelease\utils' not allowed with multiple source files
20160329 15:22:52< gfgtdf> zookeeper: hmm this usually means that you have multiplre cpp files with the same name
20160329 15:23:33< gfgtdf> zookeeper: you shoudl change the output dir for at lest one of them
20160329 15:23:39< celticminstrel> I can't find "FoRelease" in any of the VC project files.
20160329 15:23:52< celticminstrel> Or the solution file.
20160329 15:24:15< zookeeper> you're not supposed to
20160329 15:24:28< celticminstrel> ?
20160329 15:24:42< zookeeper> it is not something you would find there
20160329 15:24:55< zookeeper> so the fact that you do not, means nothing
20160329 15:25:05< celticminstrel> Sure, whatever.
20160329 15:25:27< zookeeper> gfgtdf, well, sure... if i knew which one(s) and how
20160329 15:25:47< gfgtdf> zookeeper: hmm i
20160329 15:26:11< gfgtdf> 'd think they they are called utils.cpp not sure tough
20160329 15:27:53< zookeeper> more likely it's about the two utils/ dirs, seeing how there's only one set of utils.*pp
20160329 15:29:53< gfgtdf> hmm when i try to compile with msvc14 i get a lot of warnings ...
20160329 15:30:05< celticminstrel> I'm not surprised.
20160329 15:30:19< gfgtdf> celticminstrel: well with msvc10 there were 0 warnings
20160329 15:30:26< celticminstrel> I imagine Microsoft added a zillion new warnings, only two of which are useful.
20160329 15:30:45< celticminstrel> (Or six, or whatever other number you prefer.)
20160329 15:31:28< gfgtdf> hmm using snprintf with time_t now gives a warning
20160329 15:32:57< gfgtdf> and msvc now tried to integrate with git
20160329 15:35:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 15:35:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160329 15:35:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 15:36:54< gfgtdf> ok i disabled git integration
20160329 15:40:16< gfgtdf> disabled all warning in wesnothlib
20160329 15:42:48-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160329 15:51:33-!- Kwandulin [~Miranda@p200300760F191C4229FECBBF0B85EA14.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160329 15:56:08< celticminstrel> How do I get a terrain_type from a t_translation::t_string...
20160329 15:56:16< celticminstrel> ^t_terrain
20160329 15:57:32< celticminstrel> Oh, found it.
20160329 15:58:26< zookeeper> gfgtdf, so, does it compile for you?
20160329 15:59:22< gfgtdf> zookeeper: i'll pull the latest commits after imy current try to update to msvc14
20160329 16:00:03< gfgtdf> zookeeper: that could take some time.
20160329 16:01:10-!- Horus2 [~Horus2@91.83.185.113.pool.invitel.hu] has left #wesnoth-dev []
20160329 16:01:13-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has quit [Ping timeout: 244 seconds]
20160329 16:03:21< zookeeper> uh, okay.
20160329 16:19:24< celticminstrel> zookeeper: I'm adding weapon filter support to standard unit filters; do you have a better tag name than [has_weapon]?
20160329 16:21:16< zookeeper> sounds good to me, although i'm not sure if it should be weapon or attack
20160329 16:21:45< celticminstrel> I chose [has_weapon] mainly just because it already existed as a key (which is less flexible).
20160329 16:22:00< zookeeper> right
20160329 16:22:45< zookeeper> i'm kind of leaning towards attack though, since that's simply more accurate, and is used in a lot of other contexts (AnimationWML, etc)
20160329 16:23:55< zookeeper> it's unfortunate that it's inconsistently used atm
20160329 16:24:23-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160329 16:24:30< celticminstrel> Hmm. In [event] you have [filter_attack]; [effect] uses an inline weapon filter; and animations also use [filter_attack].
20160329 16:24:39< celticminstrel> Should I use [filter_attack] in SUF, then?
20160329 16:25:14-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160329 16:25:14-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160329 16:26:41< zookeeper> i guess that works too
20160329 16:26:56< zookeeper> although
20160329 16:27:16< zookeeper> [has_weapon] would leave less room for confusion when you for example filter for an attack in an event filter
20160329 16:28:16< celticminstrel> Hmm, yeah, I suppose [event][filter_attack] could be confused with [event][filter][filter_attack] which would have a different meaning...
20160329 16:29:09< celticminstrel> Other options include [has_attack] or [filter_weapon].
20160329 16:29:38-!- irker922 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160329 16:32:25< celticminstrel> It's complete, I'm just waiting on the decision of tag name now.
20160329 16:32:58< celticminstrel> I tested it using the Lua console.
20160329 16:34:10< zookeeper> i'd go with [has_attack] then
20160329 16:34:57< zookeeper> even if [*_weapon] is probably more common, "attack" is simply more correct, so...
20160329 16:42:27< celticminstrel> Aginor, vultraz, gfgtdf: Does anyone have any idea how to fix the issues scroll labels have when text wraps?
20160329 16:42:51-!- irker645 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160329 16:42:51< irker645> wesnoth: Celtic Minstrel wesnoth:master 7b6dea55c848 / src/units/ (filter.cpp formula_manager.cpp formula_manager.hpp): Move filtering code out of the unit formula manager. https://github.com/wesnoth/wesnoth/commit/7b6dea55c848f6e30b90d5681491c218968b41d9
20160329 16:42:51< irker645> wesnoth: Celtic Minstrel wesnoth:master d8ee9dca290e / changelog src/units/filter.cpp: Expose second unit to unit filter formulas https://github.com/wesnoth/wesnoth/commit/d8ee9dca290e260d2fe95fce74ee3a892949b6d1
20160329 16:42:52< irker645> wesnoth: Celtic Minstrel wesnoth:master 0f072f34f2da / / (7 files in 5 dirs): Several expansions to filters https://github.com/wesnoth/wesnoth/commit/0f072f34f2da7f2d38c6d265443b73374ff3e161
20160329 16:55:09< gfgtdf> celticminstrel: which issue you mean ?
20160329 16:56:38< celticminstrel> gfgtdf: I'm not quite sure how to describe it, but it's something to do with the scrolling. It can be triggered by entering the MP lobby (GUI2 verison of course) and sending a very long message. Normally, the chat automatically scrolls to the bottom whenever a message is sent, but once a wrapped line is present it stops doing that. The Lua console also demonstrates the issue.
20160329 17:03:12-!- gfgtdf [~chatzilla@f054048082.adsl.alicedsl.de] has quit [Ping timeout: 244 seconds]
20160329 17:04:34< irker645> wesnoth: Celtic Minstrel wesnoth:master 07116154812b / data/gui/window/lua_interpreter.cfg: tlua_interpreter: Eliminate horizontal scrollbar on 800x600 https://github.com/wesnoth/wesnoth/commit/07116154812be3cebfee1055adb741b95bffcfb5
20160329 17:04:36< irker645> wesnoth: Celtic Minstrel wesnoth:master 7c5c79aa207c / / (10 files in 3 dirs): Update all FormulaAI scripts for renamed keys https://github.com/wesnoth/wesnoth/commit/7c5c79aa207cdb6b6e6b92c9e0456a6c465d3148
20160329 17:05:43< celticminstrel> By the way, LoW's copy of patrol.fai is identical to the one in data/ai/formula. Should I delete the copy and make it reference the other one?3
20160329 17:06:43-!- frainz_ [~Frainz@mmisc.de] has joined #wesnoth-dev
20160329 17:07:31-!- frainz [~Frainz@mmisc.de] has quit [Ping timeout: 268 seconds]
20160329 17:07:32-!- EliDupree_ [~quassel@idupree.com] has quit [Ping timeout: 268 seconds]
20160329 17:07:53-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160329 17:26:39-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has quit [Ping timeout: 260 seconds]
20160329 17:28:01< mattsc> celticminstrel: Sure, why not.  It sounds like that makes sense if they’re really identical.
20160329 17:28:32-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160329 17:28:32-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160329 17:29:38< mattsc> Uh …
20160329 17:29:44< mattsc> “Faction 'Rebels' is not available for side 1”
20160329 17:29:57< celticminstrel> Is that related to your -m problem?
20160329 17:30:03< mattsc> When starting with “-m --side 1:Rebels”
20160329 17:30:10< mattsc> Possibly.
20160329 17:30:34< mattsc> I was just quickly trying to see whether they would have a recruit list if I actually specify the faction.
20160329 17:30:36< celticminstrel> This seems to imply that it's not loading the eras...
20160329 17:30:45< mattsc> My guess is those are two manifestations of the same problem.
20160329 17:30:50< mattsc> yeah
20160329 17:33:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160329 17:34:12-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160329 17:38:16-!- prkc [~prkc@192.40.89.72] has joined #wesnoth-dev
20160329 17:38:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 17:43:01-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160329 17:53:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 18:01:43-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 18:04:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160329 18:04:20-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160329 18:05:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160329 18:07:31-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160329 18:09:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 18:09:14-!- travis-ci [~travis-ci@ec2-54-167-70-137.compute-1.amazonaws.com] has joined #wesnoth-dev
20160329 18:09:15< travis-ci> wesnoth/wesnoth#9098 (master - 7c5c79a : Celtic Minstrel): The build has errored.
20160329 18:09:15< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119302731
20160329 18:09:15-!- travis-ci [~travis-ci@ec2-54-167-70-137.compute-1.amazonaws.com] has left #wesnoth-dev []
20160329 18:13:03< celticminstrel> wesnoth.require() seems to not work like default require(). Not really a problem, I suppose.
20160329 18:13:17 * celticminstrel means in terms of what you pass to it, not its behaviour when called.
20160329 18:14:29-!- esr [~esr@wesnoth/developer/esr] has quit [Read error: No route to host]
20160329 18:15:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160329 18:15:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160329 18:19:40-!- prkc [~prkc@192.40.89.72] has quit [Ping timeout: 244 seconds]
20160329 18:20:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160329 18:20:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 18:21:10-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20160329 18:22:13< mattsc> celticminstrel: you didn’t test that all the FAIs still work after your recent tests, did you?
20160329 18:22:31< mattsc> At least the MP Dev AI with exp. recruitment is now broken.
20160329 18:22:43< mattsc> Produces a dvide by zero error and does not recruit.
20160329 18:23:00< mattsc> Poisoning still seems to work, I have not tested anything else yet.
20160329 18:24:37< mattsc> On a separate note, I find it very annoying that in the debug unit selection dialog you cannot scroll through the unit list after typing a few letters in the filter without clicking on the list first any more.
20160329 18:24:49< mattsc> That latter one might be for vultraz, I don’t know.
20160329 18:25:40< celticminstrel> This combine_maps_div() call is confusing me.
20160329 18:25:43< mattsc> Sorry, I don’t mean scroll.
20160329 18:25:55< mattsc> I mean moving up and down through the units with the cursor keys.
20160329 18:27:32< celticminstrel> It almost looks like the FAI recruitment is relying on something that I thought didn't work.
20160329 18:27:58< celticminstrel> Oh wait, no, it's the opposite of what I'm thinking of.
20160329 18:28:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160329 18:29:40< celticminstrel> At one point I was trying to get a function like "def f(a,b) a where c = 5" to work when called as "f(c * 3)" (returning 15 in this case), but the FAI recruitment is doing the opposite - having a function "def f(a,b) c * 3" and calling it as "f(a,b) where c = 5".
20160329 18:29:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 18:31:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: No route to host]
20160329 18:31:35-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 18:31:45-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160329 18:32:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 18:35:30-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has joined #wesnoth-dev
20160329 18:42:22-!- EdB [~edb@89.193.129.77.rev.sfr.net] has joined #wesnoth-dev
20160329 18:54:23< celticminstrel> Okay, so I have set up a test function that 1) calls ai.get_attacks() 10,000 times; 2) obtains the first facet from the AI config 10,000 times; 3) calls my new function 10,000 times.
20160329 18:54:59< celticminstrel> It's not a perfect test since there are currently no attacks facets defined, but...
20160329 18:55:16< celticminstrel> (I guess I should test it on an AI with several attacks facets.)
20160329 18:55:44< celticminstrel> But anyway, once it starts responding again, I can get some idea of their relative efficiencies.
20160329 18:55:47< mattsc> You should also test it in a scenario with a gazillion attack combinations possible.
20160329 18:56:38< celticminstrel> Well, that won't actually make a difference to the two I really want to compare, though.
20160329 18:57:21< celticminstrel> Or wait, I suppose maybe it will.
20160329 18:57:41< celticminstrel> Hmm, the test isn't quite fair yet - my new function is finding all the units, while the old method is only grabbing the filter.
20160329 18:58:02< celticminstrel> Oh, it finally finished. That took forever.
20160329 18:59:06< celticminstrel> So I guess I should in fact try it in the fast AI test scenario, though I think I'll reduce it to 1000 times, or maybe 2000 or 5000...
20160329 18:59:21< mattsc> yeah
20160329 18:59:48< celticminstrel> I'm pretty sure get_attacks() is doing more work than the other two.
20160329 18:59:57< celticminstrel> Though on the other hand, get_attacks() is cached.
20160329 19:00:19-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160329 19:01:07< celticminstrel> The 10,000 repetitions gives an average of 0.009 for get_attacks(), 0.0063 for the original method, and 0.0127 for the new method. I'm assuming this is milliseconds.
20160329 19:01:07< mattsc> get_attacks(), I believe, does not only find the attacks, but also simulates combar
20160329 19:01:20< celticminstrel> I don't think it does a full combat simulation, but it does certainly do some sort of rating of each attack.
20160329 19:01:32< celticminstrel> I could be wrong, maybe it does do a full simulation.
20160329 19:01:50< mattsc> The other thing is that, for an AI in practice, this step might not be the most important for making it fast (I don’t know if it is without checking out the code).
20160329 19:02:02< mattsc> I think the rating comes out of the simulation, IIRC.
20160329 19:02:47< mattsc> For example, in my AIs I start with steps that take significantly more time than get_attacks(), in order to then be faster on the stuff that I need to do a gazillion times.
20160329 19:03:15< mattsc> But as I said, without looking at the code of the Fast AI, I don’t remember if that matters here.
20160329 19:03:23< celticminstrel> Well, get_attacks() is cached, so it won't actually be calculated for every time it's called.
20160329 19:03:39< celticminstrel> If you call it a hundred times in the evaluation of one move, it's calculated only once.
20160329 19:04:16< celticminstrel> (This is related to the invalidation keys.)
20160329 19:07:17< celticminstrel> Is there a way to say "droid this side for just this turn"?
20160329 19:08:24< celticminstrel> I suppose I could use debug_ai and call the stage.
20160329 19:10:13< celticminstrel> Okay, now to wait for it to find all grunt-burner combinations 4001 times...
20160329 19:10:49< celticminstrel> Though only one of those times actually pairs them up.
20160329 19:11:18< celticminstrel> (I added an attacks aspect so that only grunt-on-burner attacks are considered on turn 1.)
20160329 19:11:53< celticminstrel> The map keeps being drawn over GUI2 dialogs. This is kinda annoying. Are you fixing this, Aginor?
20160329 19:12:02< celticminstrel> Oh, it's done already.
20160329 19:12:15< celticminstrel> Well, done enough to update the dialog. Still not quite.
20160329 19:12:52< celticminstrel> Argh, error.
20160329 19:14:27< celticminstrel> get_attacks() took 0.0495; original method tool 0.0155; new method crashed, so I didn't get to see the time.
20160329 19:15:00< celticminstrel> Oh wait, I used require instead of dofile, so it's just going to crash again. Whoops.
20160329 19:16:40< celticminstrel> ^took
20160329 19:17:27< vultraz> [05:24:35]	mattsc	On a separate note, I find it very annoying that in the debug unit selection dialog you cannot scroll through the unit list after typing a few letters in the filter without clicking on the list first any more.
20160329 19:17:29< celticminstrel> Hmm, get_attacks() wasn't reduced that much by the caching - it's no 0.0475.
20160329 19:17:33< vultraz> mattsc: it's either one or the other
20160329 19:17:45< celticminstrel> vultraz: I'm not so sure about that.
20160329 19:18:59< celticminstrel> Unrelatedly, the Lua console history doesn't seem to be working well for me. First, it only remembers any history if the command box is non-empty; second, it only seems to recall one line of history.
20160329 19:19:07< mattsc> vultraz: it worked that way, and still does, in 1.12
20160329 19:19:17< vultraz> that was gui1
20160329 19:19:19< vultraz> this is gui2
20160329 19:19:35< celticminstrel> vultraz: It should still be doable.
20160329 19:19:38< mattsc> I didn’t make any comment about what version of gui it is.
20160329 19:19:51< vultraz> [01:24:16]	celticminstrel	vultraz: I suspect the loading screen possibly should be showing after the MP create dialogs. Not entirely sure, but there was a noticeable delay, at least - around 4 seconds.
20160329 19:19:57< vultraz> yes, this is a small regression
20160329 19:20:11< vultraz> I think renderpath_fixes *might* fix that, so I'm waiting to see
20160329 19:20:36< celticminstrel> Previously I suspect that the MP create dialogs were opened on top of the loadscreen.
20160329 19:20:53< mattsc> vultraz: “small” is a non-quantitative word, so I cannot tell you that you are wrong with that statement.  ;)
20160329 19:21:08< celticminstrel> BTW, does the loadscreen still have a stub for progress updates, or am I going to have to put that back?
20160329 19:22:02< vultraz> The new loadingscreen has 0 code to keep track of progress
20160329 19:22:15< celticminstrel> So I have to put that back.
20160329 19:22:20< celticminstrel> Or you do.
20160329 19:22:50< vultraz> I would prefer if you did not until we heard more feedback, and even if we were to, came up with a better design for it.
20160329 19:23:09< celticminstrel> I was only thinking of a stub - a function that does nothing, but is called in all the relevant places.
20160329 19:23:19< celticminstrel> So that we can decide later exactly what to do when it's called.
20160329 19:23:27< celticminstrel> Without having to also figure out where to call it.
20160329 19:24:13< celticminstrel> And/or potentially a function that sets an internal value identifying the current "stage" of the loading.
20160329 19:25:03< celticminstrel> Okay, so now get_attacks took 0.048, old method took 0.0155, and new method took 0.022. Slightly less efficient, then.
20160329 19:25:22< celticminstrel> I'll integrate it into the AI and see how it actually works in practice.
20160329 19:25:33< mattsc> vultraz: but it also doesn’t mean that I have to agree with you  (on the “small” bit; sorry, got distracted by something else)
20160329 19:26:07< vultraz> mattsc: little confused what you're disagreeing with.
20160329 19:26:18< mattsc> That this is a small regression.
20160329 19:26:35< mattsc> I think it is a significant regression.
20160329 19:26:38< vultraz> What, the removal of the progress bar or the loading screen no longer showing after mp create?
20160329 19:26:42< celticminstrel> Though, are you talking about what he quoted me on, or the create unit thing?
20160329 19:26:58< celticminstrel> Because it was the missing loading screen after the game settings dialog that he was calling a small regression. 
20160329 19:27:16< vultraz> ^
20160329 19:27:28< mattsc> No, that I have to switch between mouse and keyboard in the create-unit dialog
20160329 19:27:35< vultraz> Ah, yes
20160329 19:27:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160329 19:27:59< mattsc> I personally don’t like the missing progress bar either, but I don’t have as strong an opinion about that as others.
20160329 19:32:26-!- gfgtdf [~chatzilla@f054048082.adsl.alicedsl.de] has joined #wesnoth-dev
20160329 19:34:03< zookeeper> gfgtdf, still compiling? :P
20160329 19:35:41< gfgtdf> zookeeper: No progress has been made since last conversation.
20160329 19:35:49< zookeeper> okay
20160329 19:37:23< celticminstrel> vultraz: Why did you comment out a cursor::set(cursor::WAIT) in wesnoth.cpp?
20160329 19:37:44< vultraz> I was trying to make the loadscreen handle changing the cursor
20160329 19:37:50< vultraz> but it doesn't work, for some reason :|
20160329 19:38:13< gfgtdf> is teh new loadscreen already in master ?
20160329 19:38:19< celticminstrel> Yes.
20160329 19:38:33< gfgtdf> celticminstrel: does it react on mouse input ?
20160329 19:38:49< celticminstrel> Eh?
20160329 19:38:52< vultraz> eh?
20160329 19:39:20< gfgtdf> celticminstrel: is it possible to close wesnoth during loading sceen (by red cross in corner) ?
20160329 19:39:27< celticminstrel> Oh.
20160329 19:39:31< celticminstrel> I haven't tried yet.
20160329 19:39:45< celticminstrel> I wouldn't call that mouse input, though.
20160329 19:40:28< gfgtdf> celticminstrel: y my ortiginal question was more about whether it looks like wesnoth freezed if you try to click anywhere during the loadingscreen.
20160329 19:41:14< celticminstrel> I would say it does look like it's frozen during the loadscreen.
20160329 19:41:27< celticminstrel> There's no animation whatsoever. It's completely static. The worst possible loadscreen.
20160329 19:42:27< zookeeper> really?
20160329 19:42:34< zookeeper> maybe i don't want to see it with my own eyes after all
20160329 19:42:38< celticminstrel> XD
20160329 19:43:01< celticminstrel> It does however take less time to load than it used to.
20160329 19:43:23< celticminstrel> Still, it definitely needs some animation at the very least, and preferably an approximate progress indicator.
20160329 19:43:39< gfgtdf> celticminstrel: hmm no i meanst usually when you don't call sdl_pump often enough windows will usually grey out the whole window and give you a "wesnoth.exe diesnt reacto do yu wnt to kill it?" promt.
20160329 19:43:42< zookeeper> so let me get this straight... vultraz changes the loading screen to be completely static, and wants feedback on it?
20160329 19:44:15< celticminstrel> gfgtdf: Oh, the Mac equivalent would be getting a beachball... I don't think that's happened recently.
20160329 19:44:31< celticminstrel> On the new loadscreen, I mean.
20160329 19:44:45< celticminstrel> zookeeper: It looks nice, admittedly. It's terrible from a functional standpoint, but it looks nice.
20160329 19:50:34-!- prkc [~prkc@catv-80-98-243-98.catv.broadband.hu] has quit [Ping timeout: 244 seconds]
20160329 19:50:53< zookeeper> Aginor, mind if i assign https://gna.org/bugs/?24366 to you now that i've done more or less all i can about it on the WML side?
20160329 19:51:30< gfgtdf> celticminstrel: well i think that the previously progressbar wasnt that useful eigher, specialyl since it usuualy got stuck in the middle for quiet some time.
20160329 19:51:49< gfgtdf> vultraz: what you coudl add  at lest is a labels that shows what its currently doing.
20160329 19:52:11< celticminstrel> That would be an improvement, yes.
20160329 19:52:16< vultraz> ehhh
20160329 19:52:21< celticminstrel> Though something actually moving from left to right would be better.
20160329 19:52:30< vultraz> well we'd have to come up with better labels then the one ones
20160329 19:53:39< vultraz> I'd like to have some sort of animation, potentially
20160329 19:54:07< celticminstrel> Something that's not a loop is preferable, but even a loop is better than nothing at all.
20160329 19:54:29< celticminstrel> I'm thinking maybe a light moving across the bar might look okay.
20160329 19:54:53< celticminstrel> Of course there's also the possibility of actually using the bar like a normal progress bar - ie, change its colour starting from the left.
20160329 19:58:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 20:00:02< gfgtdf> celticminstrel: iirs the main problen is not that the previous pogressbar is bas but that gui2 is bad with animation in general
20160329 20:00:25< vultraz> yeah
20160329 20:00:31< zookeeper> Aginor, well, i did it anyway
20160329 20:00:59< celticminstrel> I've added a stub for indicating progress. It's not called quite as often as the old loadscreen called it (I removed two cases in source files that are part of the server, and reduced the number of calls in terrain loading by an order of magnitude), and it does nothing whatsoever at the moment.
20160329 20:03:53-!- prkc [~prkc@192.40.89.13] has joined #wesnoth-dev
20160329 20:04:54-!- irker645 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160329 20:06:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160329 20:06:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 20:11:48-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20160329 20:12:50< celticminstrel> gfgtdf: Clicking the X while the loadscreen is up now quits unconditionally (at least for the opening loadscreen).
20160329 20:13:06< celticminstrel> So that's one improvement with the new loadscreen.
20160329 20:13:43< gfgtdf> celticminstrel: it quits immidiateley after you click on the x ?
20160329 20:13:49< celticminstrel> Yes.
20160329 20:14:25< gfgtdf> celticminstrel: hmm that'd be a big improvement i'd say but i shoudl still test whether thats also the case on windows
20160329 20:14:34< gfgtdf> hmm msvc14 gives me linking erros: CVTRES : fatal error CVT1100: Doppelte Ressource. type:MANIFEST, name:1, language:0x0409
20160329 20:14:44< gfgtdf> does anyone have expereince with this ?
20160329 20:15:05< celticminstrel> Duplicate resource?
20160329 20:15:22< gfgtdf> celticminstrel: yes
20160329 20:15:25-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160329 20:15:36 * celticminstrel points vultraz to what I said just before he pinged out.
20160329 20:17:49< vultraz> the stub loading process?
20160329 20:18:01< celticminstrel> Yes.
20160329 20:19:32< vultraz> just... don't add a progress bar
20160329 20:20:05< celticminstrel> I'm not changing anything about the GUI, just adding functionality that can be expanded later.
20160329 20:20:30< vultraz> I'm probably going to remove the mp connect progress bar too, soon. That, at least, is one progress bar that's absolutely useless.
20160329 20:21:04< celticminstrel> If I recall correctly, doesn't it jump to the end almost right away and stay there until done?
20160329 20:22:01< vultraz> It jumps to the end of '0/0', then starts over and jumps to the end
20160329 20:23:33< celticminstrel> Okay yeah, that's pretty useless.
20160329 20:25:14< vultraz> plus, the second time it says '36 B' or something
20160329 20:25:19< vultraz> 36 bytes?
20160329 20:25:20< vultraz> no idea
20160329 20:25:53< celticminstrel> Fast AI still seems fast to me.
20160329 20:26:06< celticminstrel> Oh wait, that's because I didn't integrate that yet. Whoops. XD
20160329 20:26:12< celticminstrel> ie, nothing has changed in it.
20160329 20:26:25< celticminstrel> At least I figured out how to call the stage.
20160329 20:27:42< celticminstrel> mattsc: I suppose making ca_fast_combat_leader ignore the attacks aspect would be silly?
20160329 20:28:27< celticminstrel> I can't see any good way to do this except "filter for all units, then go through and pick the first with canrecruit=yes".
20160329 20:29:18< celticminstrel> Or I could add an "is_leader" param to the utils function, couldn't I. Let's go with that.
20160329 20:29:40-!- frainz_ is now known as frainz
20160329 20:30:07< celticminstrel> mattsc: Should I leave in my benchmarking function?
20160329 20:33:19-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160329 20:36:03-!- {V} [~V@105-70-ftth.on.nl] has quit [Ping timeout: 244 seconds]
20160329 20:36:31-!- {V} [~V@105-70-ftth.on.nl] has joined #wesnoth-dev
20160329 20:44:05-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160329 20:46:19< mattsc> celticminstrel: sure, why not.  Might come in handy again sometime.
20160329 20:57:59-!- NosajIRL [~nos@208.91.185.104] has joined #wesnoth-dev
20160329 21:03:20-!- Kwandulin [~Miranda@p200300760F191C4229FECBBF0B85EA14.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160329 21:05:55< zookeeper> gfgtdf, celticminstrel, wedge009, etc: i've made sure that /Fo isn't coming from anywhere in the project file itself, but i still run into the same error and /Fo's show up in the build logs for the individual build/link commands.
20160329 21:06:57< zookeeper> CL.exe /c /I..\..\src /I..\..\..\external\include /Zi /nologo /W3 /WX- /O2 /Oi /Oy- /D WIN32 /D _WINDOWS /D _CRT_SECURE_NO_WARNINGS /D HAVE_PYTHON /D USE_GZIP /D NO_HAVE_FRIBIDI /D HAVE_LIBPNG /D NOMINMAX /D _SCL_SECURE_NO_WARNINGS /Gm /EHsc /MD /GS- /Gy /arch:SSE2 /fp:precise /Zc:wchar_t /Zc:forScope /openmp /Fo"Release\utils" /Fd"Release\vc120.pdb" /Gd /TP /analyze- /errorReport:prompt 
20160329 21:06:57< zookeeper> ..\..\src\utils\make_enum.cpp ..\..\src\utils\sha1.cpp
20160329 21:06:57< zookeeper>      1>cl : Command line error D8036: '/FoRelease\utils' not allowed with multiple source files
20160329 21:09:55< gfgtdf> zookeeper: hmm mabye you orgot a backslash somehwere? So that it treats the diectory as file ?
20160329 21:11:28< zookeeper> yeah actually that's probably it
20160329 21:11:36< zookeeper> Fo"Release\Units\\"
20160329 21:11:38< zookeeper> Fo"Release\utils"
20160329 21:12:19< zookeeper> but where the heck is something like that defined
20160329 21:13:04< Aginor> sorry zookeeper, I was still asleep
20160329 21:13:33< gfgtdf> zookeeper: do you you the vc9 projectfile or did you update you prpjectfiles yourself 
20160329 21:13:58< zookeeper> both
20160329 21:15:28< vultraz> Aginor: I committed the new loadscreen 
20160329 21:15:38< zookeeper> by which i mean that what i did is both, not that i did both
20160329 21:22:23 * Aginor compiles master to check
20160329 21:23:24< zookeeper> ah i think i found the problem
20160329 21:23:25 * zookeeper tests
20160329 21:24:19< Aginor> vultraz: I really think we need some form of progress indicator
20160329 21:24:36< Aginor> vultraz: I _really_ think we need some form of progress indicator
20160329 21:24:38-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160329 21:24:55< Aginor> apart from that I think it's nice
20160329 21:25:16< vultraz> If GUI2 had animations it would be a lot easier :|
20160329 21:27:54< Aginor> ok
20160329 21:27:58< Aginor> let's make animations
20160329 21:28:13< Aginor> how do we want animations to be controlled?
20160329 21:28:22< Aginor> should there be a toplevel animation class?
20160329 21:28:41< Aginor> or do we just make a new widget that contains animated stuff?
20160329 21:28:57< Aginor> making a widget may be best
20160329 21:28:58< vultraz> I think any widget should be able to define animations
20160329 21:29:49< vultraz> or at least, should be able to be animated
20160329 21:29:56< vultraz> like say, we want a label to fade out
20160329 21:30:10< vultraz> or have a 'glow' effect on hover
20160329 21:31:51< celticminstrel> The clock and the progress bar prove that animations are possible.
20160329 21:32:23< vultraz> those are pseudo-animations
20160329 21:32:52 * celticminstrel shrugs.
20160329 21:33:15< celticminstrel> I'll push the progress indicator stub soon, anyway.
20160329 21:47:21< gfgtdf> celticminstrel: i'm also getting linker erros from lua_object<aspect_attacks_lua_filter>::to_type I think you need to explicitly instanciate the lua_object<aspect_attacks_lua_filter> class in the cpp file
20160329 21:48:50< celticminstrel> I thought it was instantiated in the header and defined in the cpp...
20160329 21:50:04< gfgtdf> celticminstrel: i see no instnciation in the header.
20160329 21:50:25< celticminstrel> That line near the bottom doesn't count?
20160329 21:50:52< gfgtdf> celticminstrel: no that just a normal function declaration
20160329 21:50:55< Aginor> vultraz: this is how you do an animation:
20160329 21:51:15< Aginor> make a new GUI2 class for your animated component so it's decoupled
20160329 21:51:31< Aginor> make your animated component register for DRAW events
20160329 21:51:34< zookeeper> hey i think i solved it
20160329 21:51:54< Aginor> keep track of time between each event received, update animation state according to the time spent
20160329 21:52:11< Aginor> that's general animation :)
20160329 21:52:48< Aginor> now, if you want fade-in or fade-out effects for windows, you need to do that in the same fashion, but you need to do it on the window
20160329 21:52:53< vultraz> you make it sound so simple :|
20160329 21:53:00< Aginor> it is simple :)
20160329 21:53:08< vultraz> not for me
20160329 21:53:19< celticminstrel> gfgtdf: So do you mean I need something like "class lua_object<blah>;"?
20160329 21:53:26< vultraz> I'm still not very good with c++
20160329 21:53:27< celticminstrel> zookeeper: Yay.
20160329 21:53:28< zookeeper> celticminstrel, i'm assuming this is your fault: in the wesnoth.vcproj and wesnoth.vcxproj files, a whole bunch of cases of "utils" are missing a trailing \
20160329 21:53:49< celticminstrel> It's possible it might be my fault.
20160329 21:54:05< gfgtdf> celticminstrel: yes, template class lua_object<blah>; actually
20160329 21:54:30< gfgtdf> celticminstrel: in the cpp file that defines that function.
20160329 21:57:40< gfgtdf> celticminstrel: hmm i just tested on windows and it seems likepressing the cross during loadingscreen does not work here
20160329 21:57:47< celticminstrel> Wait, not in the header?
20160329 21:57:48< gfgtdf> celticminstrel: it is sure faster at loading though
20160329 21:57:56< gfgtdf> celticminstrel: in the cpp file
20160329 21:58:14< celticminstrel> You added that and it worked, then?
20160329 21:58:23< gfgtdf> celticminstrel: you coudl mostlikele also put it in the haeder since the cpp file includes the header :).
20160329 21:58:34< celticminstrel> Sure.
20160329 21:59:08< gfgtdf> celticminstrel: hmm that migth nt work though since other files taht include that header are unable to instanciate that class becasue they lack the definieiton of the to_type function
20160329 21:59:24< gfgtdf> celticminstrel: y it worked for me.
20160329 21:59:38< gfgtdf> celticminstrel: the new loading screen is sure faster though
20160329 21:59:40< celticminstrel> Okay, are you going to commit it then?
20160329 22:00:20< gfgtdf> celticminstrel: hmm i hvae some other uncommited changes, and unpushed commit, i can, but not today.
20160329 22:01:13< gfgtdf> the difference in sped in the new loadingscreen is indeed very notiable.
20160329 22:01:19< celticminstrel> I might do it before then. Or, I dunno, maybe zookeeper might.
20160329 22:01:25< zookeeper> celticminstrel, so i take it that you'll fix those ASAP?
20160329 22:01:53< Aginor> vultraz: let's go and make an animated widget together then
20160329 22:01:59< celticminstrel> "those" -> you mean the missing slashes in the project file, or the link error, or both, or...?
20160329 22:02:18< Aginor> this has very little to do with c++ and more about general development principles/patterns
20160329 22:03:07< zookeeper> celticminstrel, the missing slashes causing the link errors
20160329 22:03:46 * celticminstrel thought the link error (caused by that template thing gfgtdf was mentioning) was something separate from the missing slashes thing.
20160329 22:03:54-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160329 22:04:01< zookeeper> the template thing never had anything to do with it AFAICT
20160329 22:04:25< zookeeper> as i strongly implied way back then
20160329 22:04:30< gfgtdf> celticminstrel: yes it was something different
20160329 22:04:56< gfgtdf> celticminstrel: but zookeeper also reported errors related to lua_obectbefore.
20160329 22:05:34< zookeeper> those were only due to the fixes he suggested
20160329 22:05:40< zookeeper> nothing to do with the original problem
20160329 22:06:05< gfgtdf> vultraz: i tink we shodul try to use different threads for the ui and the actual work in teh loadscreen dialog.
20160329 22:06:19< vultraz> gfgtdf: the loadscreen is non-modal
20160329 22:08:31< Aginor> gfgtdf: I think shadowm's reasons against using threads is a good reason
20160329 22:08:40< Aginor> many people will struggle with them
20160329 22:08:49< celticminstrel> No, don't use threads in the loadscreen.
20160329 22:08:59< gfgtdf> celticminstrel: why not ?
20160329 22:09:22< celticminstrel> I think the loadscreen should be synchronous. Otherwise it might continue updating even when nothing is happening.
20160329 22:10:00< gfgtdf> celticminstrel: what do you mean by 'updating' ?
20160329 22:10:28< celticminstrel> For example, if the progress animation were spinning dots like in a browser (which I don't recommend, but just as an example), I think it's better for it not to just spin at a constant rate, but rather move to the next spin stage each time the game tells it to advance the progress indicator.
20160329 22:13:30< gfgtdf> celticminstrel: hmm well even if we did you threads e coudl still use teh loadscreen indicator
20160329 22:13:35< vultraz> no, we should have a spinning indicator
20160329 22:13:40< vultraz> or something like it
20160329 22:14:34< celticminstrel> vultraz: I'd prefer something that doesn't loop.
20160329 22:14:38< zookeeper> we should have someone knock sense into you so you stop repeating "we should have a <insert trendy UI trope>" every day
20160329 22:14:39< vultraz> why
20160329 22:15:55< vultraz> have you even looked at the new loadscreen
20160329 22:16:14< Aginor> vultraz: it's pretty but it's not very HCI friendly
20160329 22:16:19< Aginor> design != usability
20160329 22:16:22< vultraz> HCI?
20160329 22:16:25< zookeeper> of course i haven't
20160329 22:16:37< vultraz> ...
20160329 22:16:40< Aginor> zookeeper like usability/HCI
20160329 22:16:48< vultraz> well you'll see it eventually
20160329 22:16:52< vultraz> not like you can avoid it
20160329 22:16:54< Aginor> vultraz: Human Computer Interaction
20160329 22:17:41< Aginor> vultraz: I do not like the new loadscreen. I am firmly in the side of zookeeper here.
20160329 22:17:51< celticminstrel> vultraz: Because something that loops informs you things are happening, but gives no indication of progress.
20160329 22:17:57< vultraz> celticminstrel: that's the point
20160329 22:18:06< Aginor> I strongly think the loading screen need to have a progress indicator
20160329 22:18:07< celticminstrel> That's all very well when you haven't the slightest clue about the progress.
20160329 22:18:13< celticminstrel> For example, when connecting to a server.
20160329 22:18:26< celticminstrel> But that's not the case in the loadscreen.
20160329 22:18:38< Aginor> and even then it needs to do *something* so you know the program is still working!
20160329 22:18:46< vultraz> There's a design I was considering, but I don't know if it's possible
20160329 22:19:18< vultraz> If possible, we could make that decoration bar grow bilaterally from the center as progress increases.
20160329 22:20:32< Aginor> while we're on the topic of usability
20160329 22:20:53< Aginor> the modified menu buttons are terrible, there's no indication that they are actually buttons
20160329 22:21:11< Aginor> it also breaks the existing paradigms within our user interface
20160329 22:21:13< vultraz> Yes, I need to add a hovered effect
20160329 22:21:58< vultraz> Optimally the text could glow or something
20160329 22:22:03< vultraz> But I'll have to do with something else
20160329 22:22:12< vultraz> First I'd like to fix the rendering
20160329 22:22:40< gfgtdf> vultraz: so the current loadinscreen basically just draws an image and closes the dialog immidiateley ?
20160329 22:22:50< vultraz> yes
20160329 22:23:27< Aginor> vultraz: how does that work with resizing the window?
20160329 22:23:59-!- NosajIRL [~nos@208.91.185.104] has quit [Remote host closed the connection]
20160329 22:24:53< gfgtdf> Aginor: it doesnt take any input during the ladinsscreen, inclusing the resizing.
20160329 22:24:58< gfgtdf> loadingscreen*
20160329 22:25:38< Aginor> in that case it's another problem, as it will need to pump events during those ~15 seconds of doing other stuff
20160329 22:25:50< Aginor> (on a slow computer)
20160329 22:26:00< gfgtdf> well yes, use threads.
20160329 22:26:12< Aginor> gfgtdf: SDL comes with limitations on threads
20160329 22:26:24< Aginor> gfgtdf: all rendering and event pumping have to be in the same thread
20160329 22:27:01< Aginor> so yes, you can have a producer/consumer model with your event/render thread being the task producer
20160329 22:27:07< gfgtdf> Aginor: hmm, still the roker threads shodul need to handle input, it shoudl just set some variable that contains teh current process.
20160329 22:27:19< gfgtdf> worker threads*
20160329 22:27:20< Aginor> gfgtdf: roker?
20160329 22:27:31< Aginor> worker?
20160329 22:27:59< vultraz> resizing basically works like it does on the titlescreen
20160329 22:28:02< gfgtdf> Aginor: the thread that does the actual loading, e.g. readon the cfg files.
20160329 22:28:04< vultraz> short delay before it gets resized
20160329 22:28:06< celticminstrel> We're not going to be using SDL threads though, right?
20160329 22:28:14< vultraz> but that should be fixed in renderpathfixes
20160329 22:28:26 * celticminstrel would say use Boost.Thread. Even with C++11.
20160329 22:28:51< Aginor> gfgtdf: we can speculate about what it should be able to do as much as we want, but that doesn't change that SDL doesn't have thread-safe rendering and event processing
20160329 22:29:34< Aginor> so we go and multithead the application
20160329 22:29:40< Aginor> how many threads are appropriate?
20160329 22:29:52< Aginor> are we targeting a low-end system?
20160329 22:30:00< Aginor> how many cores does it have? 1?
20160329 22:30:16< zookeeper> build succeeded \o/
20160329 22:30:19< Aginor> if it has 1 core, we just decreased performance by introducing the overhead of threading
20160329 22:30:38< Aginor> 2 cores?
20160329 22:30:58< Aginor> we now have 1 thread doing eventing/rendering (being mostly idle) and 1 thread doing all loading
20160329 22:31:08< Aginor> no significant gain I expect
20160329 22:31:09< zookeeper> ok, so, now i've seen it. yeah, graphically it looks nice, but the lack of any indication that it's doing anything is terrible.
20160329 22:31:18< celticminstrel> zookeeper: Do I need to commit anything related to your issues, or will you be committing it?
20160329 22:31:19< zookeeper> which of course is no surprise to anyone at this point
20160329 22:31:21< Aginor> so we target 8 cores
20160329 22:31:28< zookeeper> celticminstrel, you should
20160329 22:31:31< celticminstrel> 'kay
20160329 22:31:43< zookeeper> i don't want to port my mess to the actual VC9 files
20160329 22:32:09< Aginor> now we can have lots of worker threads to do stuff, but we need to coordinate them and they may have interdependant states. not a problem, we synchronise them using synchronisation points, conditionals, mutexes and whatnot
20160329 22:32:39< Aginor> and pray they're not IO intensive or we're going to thrash the disk and decrease performance
20160329 22:32:41-!- EdB [~edb@89.193.129.77.rev.sfr.net] has quit [Quit: Konversation terminated!]
20160329 22:33:08< gfgtdf> Aginor: my idea was to have 2 threads: one the reads the files and does the other work of loaing the game cnfig, and teh other one handles the user input during loadingscreen.
20160329 22:33:32< celticminstrel> Okay, so, when do start using C++11?
20160329 22:33:45-!- SpoOkyMagician [~chatzilla@2607:fcc8:be59:b00:40a8:7d70:629f:ea7c] has joined #wesnoth-dev
20160329 22:33:48< Aginor> gfgtdf: that won't yield any significant performance increases though
20160329 22:34:11< Aginor> and we need to worry about synchronisation
20160329 22:34:21< Aginor> is it worth the increase in complexity
20160329 22:34:41< Aginor> gfgtdf: how many people besides you are comfortable with multithreading?
20160329 22:34:42< gfgtdf> Aginor: well it will alow us to better react on user input during te loadingscreen which was my main intention.
20160329 22:35:27< Aginor> vultraz: I don't think my branch will fix that delay you were mentioning
20160329 22:35:52< Aginor> gfgtdf: we could just simply pump events between each stage in the loading screen
20160329 22:36:00< vultraz> Aginor: really? but it improved gui2 responsiveness 10fold
20160329 22:36:26< Aginor> vultraz: so it's not the window going black you're talking about?
20160329 22:36:42< vultraz> no
20160329 22:36:46< Aginor> because it goes black on purpose and there's a timeout before it starts rendering again
20160329 22:36:58< vultraz> though I wouldn't know, since the loadscreen's background is black to begin with
20160329 22:37:08< zookeeper> why is anyone even considering multithreading the loading screen? i see no indication that there's any problem with making the old progress bar be just as fast as the new screen.
20160329 22:37:44< vultraz> we're not bringing the old progress bar back 
20160329 22:39:56< zookeeper> i've seen no indication that you're making an informed decision either :p
20160329 22:40:36< celticminstrel> vultraz: I think it would be good to use the old progress bar for the addons manager though.
20160329 22:40:45< Aginor> let's compromise :)
20160329 22:40:51< celticminstrel> It's not very useful for MP connect, but it's fitting for addons.
20160329 22:40:51< gfgtdf> Aginor: hmm yes but we cannot realy guarnatee that pump i called often enough becasue the time between 2 loading stages migth be long
20160329 22:40:56< Aginor> let's add a progress indicator to the new screen
20160329 22:41:11< vultraz> celticminstrel: ...what?
20160329 22:41:22< vultraz> celticminstrel: there is aprogress bar when you connect to the addons server
20160329 22:41:37< vultraz> That hasn't changed
20160329 22:41:39< celticminstrel> vultraz: I know, that's not quite what I'm referring to though.
20160329 22:41:49< celticminstrel> Also, that's GUI1 at the moment, according to you.
20160329 22:42:00< vultraz> No THAT progress bar is GUI2
20160329 22:42:10< vultraz> the mp connect one is gui1 and I'll axe that 
20160329 22:42:17< Aginor> let's make the spinny/blinky ui for when we don't have any clear diea when something will finish/time out and a proper progress indicator when we know when the task finishes
20160329 22:42:21< celticminstrel> Basically, connecting to a server, whether it's the MP server or the addons server, doesn't really need a progress bar, but downloading data is a good place to have a progress bar.
20160329 22:42:28< celticminstrel> Ah, I got confused then, sorry.
20160329 22:42:29< vultraz> the addons server gets the gui2 progress bar because it uses asio
20160329 22:43:01< celticminstrel> We should connect to the MP server with asio too.
20160329 22:43:22< vultraz> loonycyborg is working on such a thing
20160329 22:43:29< vultraz> Aginor: that sounds reasonable
20160329 22:44:02< zookeeper> vultraz, it seems clear that you do not understand the old progress bar yet you're unilaterally removing it and claiming that "we" won't bring it back like ever. if you actually knew what you're doing and why then that'd be fine.
20160329 22:44:27< celticminstrel> I'm talking about converting the client-side, not the server-side, though that would be good too. They're two separate tasks though - you could easily convert one but not the other.
20160329 22:44:41< vultraz> zookeeper: I do know what I'm doing
20160329 22:45:01< zookeeper> it doesn't show
20160329 22:45:19< celticminstrel> I'm going to revert that commented cursor set, until such time as it actually works in the loading screen pre/post show,
20160329 22:46:06< vultraz> I just don't want the *old* progress bar back
20160329 22:46:28< vultraz> If we really want a progress indicator, then let's make a new one of reasonable design 
20160329 22:46:34< celticminstrel> I'm not attached to the old bar specifically, so I don't really care if it doesn't come back.
20160329 22:46:44< zookeeper> no one's saying that a progress indicator needs to look like the old brick
20160329 22:46:49< celticminstrel> But I do say that having no progress indicator is completely unacceptable.
20160329 22:47:37-!- irker962 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160329 22:47:37< irker962> wesnoth: Celtic Minstrel wesnoth:master 41095c11e6a4 / projectfiles/VC9/wesnoth.vcproj src/ai/lua/lua_object.cpp: MSVC fixups https://github.com/wesnoth/wesnoth/commit/41095c11e6a49745849ec6481a1b634547bc5949
20160329 22:47:37< irker962> wesnoth: Celtic Minstrel wesnoth:master d535ec4fa9eb / src/ (9 files in 4 dirs): tloadscreen: Stub for progress/stage indicator https://github.com/wesnoth/wesnoth/commit/d535ec4fa9eb052304cd7bf68cceb18f063046b3
20160329 22:48:12< celticminstrel> Finally I can test the Fast MAI again.
20160329 22:49:08-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160329 22:50:05< celticminstrel> Oh right, and then the FAI recruitment which apparently broke with the renames.
20160329 22:50:07< zookeeper> oh, and assert from external boost/smart_ptr/shared_ptr.cpp:648
20160329 22:50:21< vultraz> fixed in current master, I think
20160329 22:50:25< celticminstrel> zookeeper: What's the stack like?
20160329 22:50:30< zookeeper> no idea
20160329 22:50:37< celticminstrel> Oh, if it's related to the attacks aspect, then yeah, it's fixed.
20160329 22:50:48< celticminstrel> MSVC should show you the stack when an assert happens...
20160329 22:50:51< zookeeper> okay
20160329 22:52:50< vultraz> celticminstrel: for some reason the loadscreens seem longer after your stub progress implementation :/
20160329 22:54:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160329 22:54:29< celticminstrel> Hmm, it might be...
20160329 22:54:46 * celticminstrel just counted during one, got to ~8 seconds.
20160329 22:54:59< celticminstrel> That's not a good test though.
20160329 22:55:04< celticminstrel> Because I launched with -t
20160329 22:55:19< celticminstrel> So it's really the combination of two loading screens.
20160329 22:55:26-!- SpoOkyMagician [~chatzilla@2607:fcc8:be59:b00:40a8:7d70:629f:ea7c] has quit [Quit: fail]
20160329 22:55:33< Aginor> befor and after loading screen: : std::cout << SDL_GetTicks() << "\n";
20160329 22:55:53< celticminstrel> Aginor: Maybe in the pre_show and post_show?
20160329 22:55:54< Aginor> may or may not need a lexical cast
20160329 22:56:05< celticminstrel> I doubt you'd need a lexical cast.
20160329 22:56:15< Aginor> celticminstrel: I haven't looked at the implementation at all :)
20160329 22:56:34< Aginor> I'm busy refactoring display.?pp and the editor
20160329 22:57:49-!- Appleman1234 [~Appleman1@KD106161151082.au-net.ne.jp] has joined #wesnoth-dev
20160329 23:00:37-!- mjs-de [~mjs-de@f049100065.adsl.alicedsl.de] has quit [Remote host closed the connection]
20160329 23:00:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 23:02:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160329 23:02:27< zookeeper> well, now that i reverted my temporary code changes, i do get tons of errors from lua_object: lua_object.cpp(44): error C2512: 'ai::aspect_attacks_lua_filter' : no appropriate default constructor available
20160329 23:02:28< zookeeper> etc etc
20160329 23:02:53< celticminstrel> What kind of default constructor does it expect?
20160329 23:03:18< zookeeper> are you asking me? i couldn't possibly know someone else's code
20160329 23:03:37< celticminstrel> I mean I can't tell how to fix it from that error message alone.
20160329 23:03:55< celticminstrel> It sounds like it's implicitly deleting the default constructor.
20160329 23:03:59< celticminstrel> Or something.
20160329 23:04:24< celticminstrel> So get_attacks() is no 0.047, old method 0.033, new method 0.044.
20160329 23:04:28< celticminstrel> ^now
20160329 23:04:30< zookeeper> ah, i forgot to revert a few other files
20160329 23:04:35< celticminstrel> Oh.
20160329 23:10:26< gfgtdf> celticminstrel: whats teh intention in "gui2::tloadscreen::progress("init gui"); // Does nothing since there's no loadscreen yet" ?
20160329 23:11:08< gfgtdf> vultraz: what excatly is teh differene betweena  modal and a nonmodal dialog ?
20160329 23:11:28< vultraz> modal means you can't do anything else while it's up
20160329 23:11:38< celticminstrel> gfgtdf: I more or less just reverted the parts of vultraz's original commit that removed hooks into the loadscreen. There's no real reason to keep that particular line unless we want to remind ourselves to show some kind of loading indicator while initializing the GUI.
20160329 23:12:05< vultraz> basically, if the loadscreen were modal, it'd show up and sit there, waiting for input
20160329 23:12:31< gfgtdf> celticminstrel: hmm but since teh loadscreen dialog is  agui2 dialog we mostlikeley can never show it before inilizing gui2
20160329 23:12:41< vultraz> gfgtdf: exactly
20160329 23:13:01< celticminstrel> gfgtdf: Right, if we wanted a loading indicator while GUI is being initialized, it would have to be separate from the loadscreen.
20160329 23:14:03< gfgtdf> actualyl i wonder whetehr teh same is true for init fonts. shouldn't gui2 use fonts aswell?
20160329 23:14:22-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160329 23:18:20< gfgtdf> celticminstrel: "gui2::tloadscreen::progress("load data");" this seems to be very unspecific.
20160329 23:18:49< celticminstrel> Yeah, I see that. I wasn't paying close attention to most of the stage strings.
20160329 23:19:08< gfgtdf> celticminstrel: are you currently wokring on the loadingscreen ?
20160329 23:19:13< celticminstrel> Like I said, I started with a partial revert.
20160329 23:19:20< celticminstrel> No, I'm currently working on AI stuff.
20160329 23:19:39< celticminstrel> So feel free to make that more descriptive or whatever.
20160329 23:19:51< celticminstrel> Mind you, I'm not sure these strings would actually be shown to the user.
20160329 23:19:59< vultraz> they weren;t
20160329 23:20:03< celticminstrel> They might instead be used as keys to look up strings in a table.
20160329 23:20:04< vultraz> that was the stage ID
20160329 23:20:16< celticminstrel> vultraz: I know they weren't, which is partly why I'm mentioning it now.
20160329 23:24:25< celticminstrel> Okay, with a less restrictive attacks aspect, get_attacks() is 0.047, old method 0.0325, new method 0.0425...
20160329 23:25:03< zookeeper> so now the loading screen is basically getting re-implemented to show progress? you know, just like the old one?
20160329 23:25:30< celticminstrel> Not just like the old one, but plans to show progress are being made.
20160329 23:26:24< celticminstrel> Oh wait, an error in my scenario means that that wasn't less restrictive after all. :( That explains why the times were so close, I suppose.
20160329 23:26:56< zookeeper> well, i guess re-implementing stuff is one way to spend time.
20160329 23:27:38< celticminstrel> Vultraz seems to like doing that, which in a way is a good thing since it's a prerequisite for porting anything from GUI1 to GUI2.
20160329 23:28:35< vultraz> zookeeper: moving it to gui2 was a reimplementation onto itself
20160329 23:28:47< vultraz> consider it that I simply left something out in the move
20160329 23:28:49< celticminstrel> Just an incomplete one. :P
20160329 23:29:16< zookeeper> the stage counting had nothing to do with that AFAICT
20160329 23:32:54< zookeeper> if you want to re-implement the stage and progress counting logic then sure that's fine. hopefully the time spent results in something better than the old one.
20160329 23:33:14-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160329 23:33:16-!- travis-ci [~travis-ci@ec2-54-158-206-31.compute-1.amazonaws.com] has joined #wesnoth-dev
20160329 23:33:17< travis-ci> wesnoth/wesnoth#9099 (master - d535ec4 : Celtic Minstrel): The build has errored.
20160329 23:33:17< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/119389395
20160329 23:33:17-!- travis-ci [~travis-ci@ec2-54-158-206-31.compute-1.amazonaws.com] has left #wesnoth-dev []
20160329 23:33:21< celticminstrel> Another GUI2 problem - sliders don't seem to respond to clicks.
20160329 23:34:47-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160329 23:35:30< vultraz> wha??
20160329 23:35:52< vultraz> I just checked, they're fine..
20160329 23:36:09< celticminstrel> So if you click on it, the thumb moves under the mouse?
20160329 23:36:12-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20160329 23:36:28< vultraz> yes
20160329 23:36:55< celticminstrel> Hmm, doesn't work for me.
20160329 23:36:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160329 23:37:13< celticminstrel> I can't interact with the slider at all, only with the thumb.
20160329 23:37:17< celticminstrel> Testing in prefs.
20160329 23:38:24< vultraz> ...OH I misunderstood your question
20160329 23:38:31< gfgtdf> vultraz: why do you need show_non modal if the dialog closed isself immidiatley anyways ?
20160329 23:39:05< celticminstrel> Huh? Since when is it closing itself immediately?
20160329 23:39:09< vultraz> gfgtdf: because the dialog has to remain open for the duration of the loading process and then close itself
20160329 23:39:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160329 23:39:12< celticminstrel> It closes in the destructor, right?
20160329 23:39:33< vultraz> if i don't use show_non_modal, it opens and sits there
20160329 23:39:43< vultraz> show_non_modal allows the loading to happen concurrently 
20160329 23:40:22< gfgtdf> celticminstrel: display is implementd as "tloadscreen().show(video)2 hishc just creates a temporarily tloadscreen object
20160329 23:41:41< celticminstrel> ...oh. That is kinda weird.
20160329 23:42:24< celticminstrel> I think instead what should happen is, remove display() and declare an instance when you need the loadscreen.
20160329 23:42:34< celticminstrel> Use bare {} to create a scope if necessary.
20160329 23:44:20< gfgtdf> celticminstrel: well it currently seems leik thedialog beeing a temporaily is intended
20160329 23:44:52-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds]
20160329 23:45:04< celticminstrel> I think that interacts poorly with my changes; I missed it, otherwise I probably would've changed it myself.
20160329 23:45:24< gfgtdf> celticminstrel: i thought you didnt do any changes '?
20160329 23:45:41< celticminstrel> I added the progress stub.
20160329 23:46:36< vultraz> ...huh
20160329 23:46:44< vultraz> maybe that's why the cursors don't work?
20160329 23:47:09< celticminstrel> Maybe, dunno.
20160329 23:47:46< celticminstrel> I suggest removing display(), maybe call show() from the constructor (or even remove it).
20160329 23:47:47< vultraz> I'll change the calls to display to class instances
20160329 23:47:55< celticminstrel> 'kay
20160329 23:48:15< celticminstrel> Make sure to remove the set cursor call in do_game_loop before declaring that it fixes cursors.
20160329 23:48:21< celticminstrel> Since I put that back.
20160329 23:57:06< vultraz> that doesn't fix it and instead breaks it :|
20160329 23:57:23< celticminstrel> Breaks what?
20160329 23:57:39< vultraz> now if you go into the editor the loadscreen remains as the 'background'
20160329 23:57:52< celticminstrel> Use bare {} to introduce a scope if necessary.
20160329 23:58:30< celticminstrel> Like { gui2::tloadscreen loader; /*loading code here*/ } /* now the loader is closed */
--- Log closed Wed Mar 30 00:00:34 2016