--- Log opened Wed Sep 30 00:00:06 2015
20150930 00:03:13< celticminstrel> Hm. Should I leave the asserts in?
20150930 00:03:25< celticminstrel> Probably not, right?
20150930 00:03:58< celticminstrel> Eh, I can take them out again at any time.
20150930 00:04:22< celticminstrel> gfgtdf: Updated PR507 (or whatever the number is)
20150930 00:08:50-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20150930 00:10:28< gfgtdf> celticminstrel: hmm i think after we have tested the code once with configs and once with vconfigs we can remove those asserts ?
20150930 00:10:43-!- Guest62975 [~quassel@london.acm.jhu.edu] has joined #wesnoth-dev
20150930 00:15:30-!- Guest62975 [~quassel@london.acm.jhu.edu] has quit [Ping timeout: 240 seconds]
20150930 00:15:33-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 256 seconds]
20150930 00:16:53-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 00:19:23-!- Appleman1234 [~Appleman1@KD111239024198.au-net.ne.jp] has quit [Ping timeout: 264 seconds]
20150930 00:21:21-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 252 seconds]
20150930 00:26:26-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 00:28:06-!- Shackra [~Jorge@186.177.2.148] has quit [Ping timeout: 240 seconds]
20150930 00:32:36-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 250 seconds]
20150930 00:32:52-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 00:38:41< celticminstrel> gfgtdf: This was my test code: http://pastebin.com/H11zSfjs
20150930 00:38:57< celticminstrel> I also tested on normal configs by adding .__literal to every instance of cfg.
20150930 00:39:02-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Excess Flood]
20150930 00:42:18-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 00:44:05< celticminstrel> Why are there *.vcxproj.user files in the repo?
20150930 00:45:29-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Excess Flood]
20150930 00:46:20-!- travis-ci [~travis-ci@ec2-54-161-214-78.compute-1.amazonaws.com] has joined #wesnoth-dev
20150930 00:46:21< travis-ci> gfgtdf/wesnoth-old#552 (sync_choice_split - 30b302d : gfgtdf): The build was broken.
20150930 00:46:21< travis-ci> Build details : https://travis-ci.org/gfgtdf/wesnoth-old/builds/82846198
20150930 00:46:21-!- travis-ci [~travis-ci@ec2-54-161-214-78.compute-1.amazonaws.com] has left #wesnoth-dev []
20150930 00:46:23< gfgtdf> celticminstrel: hm ok i think we can remove teh asserts then
20150930 00:46:24-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 00:46:32< gfgtdf> oh no
20150930 00:47:08< celticminstrel> The other option would be replacing them with a call to helper.wml_error() or even just error().
20150930 00:47:15-!- TC01 [~quassel@london.acm.jhu.edu] has joined #wesnoth-dev
20150930 00:47:23< celticminstrel> (In order to give a better error message.)
20150930 00:49:33< celticminstrel> vultraz: It was default= image= label= description=, right?
20150930 00:49:46< vultraz> yes
20150930 00:49:58< vultraz> But I recommend you keep message= instead of description 
20150930 00:50:01< vultraz> for compatibility 
20150930 00:50:30< vultraz> (description is col 3)
20150930 00:50:32< celticminstrel> I'll allow both.
20150930 00:51:00< celticminstrel> If there's message= but not label= or image=, it will be taken as old syntax.
20150930 00:51:04< gfgtdf> celticminstrel: hmm is there really a good change that these assertions ever fail? I mean i think pairs already failss if cfg is not a table.
20150930 00:51:34-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 246 seconds]
20150930 00:51:55-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 00:52:07< celticminstrel> gfgtdf: Well, it fails for number, boolean, and string, at least. And nil.
20150930 00:52:22< celticminstrel> So I guess so.
20150930 00:52:57< vultraz> celticminstrel: so... uh.. should people convert all uses of message= to description later?
20150930 00:53:10< celticminstrel> Probably.
20150930 00:53:15< gfgtdf> celticminstrel: so if the pairs call already fails then i think there is no reason to do the assert() after it i'd think
20150930 00:53:35< celticminstrel> gfgtdf: Okay. It was mainly there as a sanity test of the iterator itself, I guess.
20150930 00:53:52< celticminstrel> Same for the second assert?
20150930 00:54:12< gfgtdf> i'd say yes.
20150930 00:54:35-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20150930 00:56:50-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 240 seconds]
20150930 00:59:38-!- travis-ci [~travis-ci@ec2-54-161-214-78.compute-1.amazonaws.com] has joined #wesnoth-dev
20150930 00:59:39< travis-ci> wesnoth/wesnoth#7532 (master - a849e86 : Charles Dang): The build passed.
20150930 00:59:39< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/82843151
20150930 00:59:39-!- travis-ci [~travis-ci@ec2-54-161-214-78.compute-1.amazonaws.com] has left #wesnoth-dev []
20150930 01:00:21-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Remote host closed the connection]
20150930 01:00:39-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20150930 01:02:52< irker609> wesnoth: gfgtdf wesnoth:master cd91b54e29ec / src/ (replay_controller.cpp replay_controller.hpp): remove unused member variable http://git.io/vcZsB
20150930 01:02:54< irker609> wesnoth: gfgtdf wesnoth:master 65655fbb67b1 / src/ (7 files): enable 'skip animation' button in mp replays http://git.io/vcZsR
20150930 01:02:56< irker609> wesnoth: gfgtdf wesnoth:master 2c90513738c4 / src/hotkey_handler_sp.cpp: fix file inclusions http://git.io/vcZs0
20150930 01:02:58< irker609> wesnoth: gfgtdf wesnoth:master 9ca66784794f / src/ (21 files in 3 dirs): Make is possible to switch from replay directly into normal play http://git.io/vcZsE
20150930 01:03:00< irker609> wesnoth: gfgtdf wesnoth:master 703519669269 / src/ (7 files in 2 dirs): remove ticks paramter from play_controllers constructor http://git.io/vcZsu
20150930 01:03:02< irker609> wesnoth: gfgtdf wesnoth:master 9546596ad4d4 / src/ (3 files in 2 dirs): remove story parameter from playsingle_controller::play_scenario http://git.io/vcZsz
20150930 01:03:04< irker609> wesnoth: gfgtdf wesnoth:master 7eec2d810548 / src/ (3 files in 2 dirs): move playsingle_controller::report_victory function http://git.io/vcZsg
20150930 01:03:06< irker609> wesnoth: gfgtdf wesnoth:master 5a82b19335d6 / src/ (game_state.cpp game_state.hpp play_controller.cpp play_controller.hpp): move end_level_data_ to gamestate class http://git.io/vcZs2
20150930 01:03:08< irker609> wesnoth: gfgtdf wesnoth:master c169150d0751 / src/ (7 files): rename mp_replay_controller to replay_controller http://git.io/vcZsa
20150930 01:03:10< irker609> wesnoth: gfgtdf wesnoth:master 9ebfec99e191 / src/ (3 files in 2 dirs): fix scenario transition after replays http://git.io/vcZsV
20150930 01:03:12< irker609> wesnoth: gfgtdf wesnoth:master 7fc9a974a051 / src/ (20 files in 5 dirs): refactor playcampaign http://git.io/vcZsw
20150930 01:03:14< irker609> wesnoth: gfgtdf wesnoth:master 4fa11dd3e448 / src/ (game_state.cpp game_state.hpp play_controller.cpp): partly revert 'simplify game_state construction' http://git.io/vcZsr
20150930 01:03:16< irker609> wesnoth: gfgtdf wesnoth:master 35df343caabe / src/ (replay_controller.cpp replay_controller.hpp): remove unused code http://git.io/vcZso
20150930 01:03:18< irker609> wesnoth: gfgtdf wesnoth:master 7f24dd190758 / data/themes/_initial.cfg: add 'continue game' button to replaytheme http://git.io/vcZs6
20150930 01:04:11< celticminstrel> Whoa!
20150930 01:04:33-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 01:04:46< celticminstrel> What does 65655fbb67b1 do?
20150930 01:05:10-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Excess Flood]
20150930 01:05:29< celticminstrel> Does it mean you can start watching replay but then decide to skip it instead?
20150930 01:07:16< gfgtdf> celticminstrel: hm not yet, in 1.13 it currently possible (although experimental) to load autosaves in networked mp. When this happenes the game game be replayed to teh current gamestate and durign that replay it was previously not possible to toggle the skip repla ybuton
20150930 01:11:01-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 01:11:11< gfgtdf> celticminstrel: the main intention of those commits was to implement https://gna.org/bugs/?23833 and do a litte refactoring
20150930 01:14:09< celticminstrel> Ah, that's a good idea.
20150930 01:14:26< celticminstrel> Do those commits implement that request though?
20150930 01:14:33< celticminstrel> Oh, I suppose that's the last commit.
20150930 01:15:10-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 240 seconds]
20150930 01:15:14< gfgtdf> celticminstrel: the last commit onyl adds the button to te themecfg :)
20150930 01:15:20-!- Appleman1234 [~Appleman1@KD118156247208.au-net.ne.jp] has joined #wesnoth-dev
20150930 01:15:41< celticminstrel> Ah... 9ca66784794f
20150930 01:16:17-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20150930 01:17:15-!- TC01 [~quassel@london.acm.jhu.edu] has quit [Ping timeout: 265 seconds]
20150930 01:21:04-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 01:25:12-!- Guest35835 [~quassel@london.acm.jhu.edu] has joined #wesnoth-dev
20150930 01:25:59-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 264 seconds]
20150930 01:26:51-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 01:28:03-!- gfgtdf [~chatzilla@78.54.142.31] has quit [Quit: ChatZilla 0.9.92 [Firefox 41.0/20150917150946]]
20150930 01:30:18-!- Guest35835 [~quassel@london.acm.jhu.edu] has quit [Ping timeout: 265 seconds]
20150930 01:31:14-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 260 seconds]
20150930 01:34:58-!- travis-ci [~travis-ci@ec2-54-159-162-144.compute-1.amazonaws.com] has joined #wesnoth-dev
20150930 01:34:59< travis-ci> wesnoth/wesnoth#7533 (master - 4410f2e : Charles Dang): The build has errored.
20150930 01:34:59< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/82843414
20150930 01:34:59-!- travis-ci [~travis-ci@ec2-54-159-162-144.compute-1.amazonaws.com] has left #wesnoth-dev []
20150930 01:50:38-!- MotorMe [~MotorMe@111.203.197.141] has joined #wesnoth-dev
20150930 01:58:13< vultraz> You know, these new control wml tags will really change the way wml is done 
20150930 01:59:03< celticminstrel> The foreach and stuff?
20150930 01:59:24< vultraz> [break] [continue] [return]
20150930 01:59:27< celticminstrel> Oh those.
20150930 02:00:57< celticminstrel> ...I think I still haven't documented them on the wiki...
20150930 02:01:28< vultraz> regarding foreach and stuff, you should change the macros to use them
20150930 02:01:32< vultraz> also repeat 
20150930 02:01:46< celticminstrel> Repeat certainly.
20150930 02:19:31< vultraz> actually, I'll deal with repeat
20150930 02:21:01< vultraz> hm
20150930 02:21:12< vultraz> celticminstrel: so all the action wml is in a [do] subtag??
20150930 02:21:39< vultraz> Can't it be done without one?
20150930 02:21:48< vultraz> It seems to just add another level of indent
20150930 02:22:44< celticminstrel> Yeah.
20150930 02:22:56< celticminstrel> It's mainly just for consistency with [while].
20150930 02:23:07< celticminstrel> It could've been done without the nested [do].
20150930 02:24:30< vultraz> I would suggest changing it to remove the nested do
20150930 02:25:03< vultraz> or do you midn of I do it
20150930 02:25:05< vultraz> mine
20150930 02:25:06< vultraz> mind
20150930 02:25:08< vultraz> :|
20150930 02:25:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20150930 02:25:38< celticminstrel> People on the forum seemed to like having the nested [do] for consistency with [while], and I think zookeeper approved it (though I think he didn't have a strong opinion either way).
20150930 02:26:11< celticminstrel> I also don't really have a strong opinion either way.
20150930 02:26:43< celticminstrel> I think it makes sense for [for], [foreach], [repeat] to all have the nested [do] for consistency with [while] where it's required.
20150930 02:27:03< celticminstrel> It's entirely possible to eliminate it though, except in [while].
20150930 02:33:39< vultraz> It's needed in [while] because you need to separate conditionals from the actions 
20150930 02:33:43< vultraz> rest could be eliminated
20150930 02:38:59-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 240 seconds]
20150930 02:39:27< celticminstrel> Could be, but consistency isn't a bad idea.
20150930 02:40:10-!- [Relic] [~Relic]@2602:306:33a3:6d30:8c16:682c:8546:eade] has quit [Quit: I press the magic X and all the weirdos go away!]
20150930 02:48:56-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 02:50:09-!- [Relic] [~Relic]@2602:306:33a3:6d30:8c16:682c:8546:eade] has joined #wesnoth-dev
20150930 02:52:45-!- [Relic] [~Relic]@2602:306:33a3:6d30:8c16:682c:8546:eade] has quit [Client Quit]
20150930 02:55:16< Aginor> so everyone, how do we feel about multithreading? I'm thinking having one event thread and one game thread :)
20150930 02:57:34< fabi> Aginor: hmmmm
20150930 02:57:52< shadowm> How many developers do we have able to work with multithreaded programs?
20150930 02:58:16< shadowm> (Also, what kind of events are we talking about?)
20150930 02:58:37< Aginor> shadowm: SDL events
20150930 02:58:52< celticminstrel> Events must be handled in the main thread.
20150930 02:59:00< shadowm> vultraz: I can't review code atm, you will either have to wait or get someone else to approve and merge it and remind me to look at it if you feel my opinion is still needed after that.
20150930 02:59:16< Aginor> in the simplest form, the thread would simply look for the events and pass it over to the game thread
20150930 02:59:28< shadowm> What benefits would this bring us?
20150930 02:59:53< celticminstrel> Are things thread-safe enough for that?
20150930 03:00:00< shadowm> Certainly not.
20150930 03:00:06< Aginor> at the moment I strongly suspect there's a loss of events on certain occasions, and there's an ugly hack in gui2 to alleviate the issue
20150930 03:00:44< celticminstrel> I dunno if this is related, but I've occasionally noticed that sometimes the game things the mouse is several miles west of its real location.
20150930 03:00:48< shadowm> But more importantly, event queue processing (note the overly specific wording) hasn't ever proved to be a bottleneck AFAIK.
20150930 03:01:04< Aginor> (rendering takes too long, filling the X11 event buffer on the SDL side)
20150930 03:01:25< shadowm> (Do note in particular that this wording specifically excludes reactions to events.)
20150930 03:01:42< Aginor> the problem is that pumpevents isn't called often enough, which is what's been added inside gui2 to not drop events
20150930 03:02:01< shadowm> I thought SDL actually did event generation on a separate thread, in fact.
20150930 03:02:06< celticminstrel> I've seen loss-of-event warnings, but I think they're usually when it loses focus halfway through (eg, if you press the mouse button but then alt-tab out before releasing the button).
20150930 03:02:10< celticminstrel> SDL might do that.
20150930 03:02:13< celticminstrel> I dunno.
20150930 03:02:36< Aginor> unfortunately, certain events will invalidate references that are held, for example to a surface during a resize. Which means it's bad to pump the events when you have a reference to the surface that you will keep using
20150930 03:04:02< Aginor> alternatively (which may be easier), I go and implement double buffering for the rendering
20150930 03:04:18< celticminstrel> Double-buffering sounds like a very good idea.
20150930 03:04:54< celticminstrel> Why isn't that being done already?
20150930 03:05:08< Aginor> celticminstrel: I don't know, I'm new :)
20150930 03:05:20< Aginor> SDL probably does a lot of that for us
20150930 03:05:29< Aginor> so it might in turn be tribple buffering :)
20150930 03:05:41< Aginor> so it might in fact turn out be tribple buffering :)
20150930 03:05:58< celticminstrel> I think when you create a surface you specify if it's double-buffered.
20150930 03:06:13< fabi> Aginor: The Tribples are the ones from StarTrek?
20150930 03:06:36< celticminstrel> That's tribbles.
20150930 03:06:38< Aginor> celticminstrel: yeah, but we'd need to not rely on SDL
20150930 03:06:55< Aginor> fabi: I apologize for my confusing typoes :)
20150930 03:07:00< celticminstrel> So what are you really suggesting?
20150930 03:07:02< fabi> :-)
20150930 03:07:27< shadowm> I think this channel sees far worse typo/minute rates every day.
20150930 03:08:09< celticminstrel> Draw screen onto an offscreen surface first, then copy it to the window?
20150930 03:08:20< Aginor> celticminstrel: pretty much
20150930 03:08:43< shadowm> But this introduces screen update latencies.
20150930 03:09:21< shadowm> As long as we are doing system VM surfaces*, that doesn't sound like a good thing at all.
20150930 03:12:07< Aginor> shadowm: does the * stand for anything?
20150930 03:12:22< shadowm> Yes, it stands for a footnote I've not written yet, give me a minute.
20150930 03:12:30< Aginor> ok, sorry
20150930 03:13:11< shadowm> #if !(defined(_WIN32) || defined(__APPLE__))
20150930 03:13:22< shadowm>     flags |= SDL_HWSURFACE;
20150930 03:13:46< shadowm> * (Exactly what does the SDL_HWSURFACE flag really do?)
20150930 03:14:02< Aginor> in SDL2, nothing. Those flags are all deprecated and ignored
20150930 03:14:33< shadowm> And in SDL 1.2 it was supposed to do something but I once checked and didn't see any performance differences without it on X11.
20150930 03:18:44< celticminstrel> Pretty sure it was supposed to specify that, if possible, the surface should live in graphics memory.
20150930 03:19:33< Aginor> http://stackoverflow.com/questions/14909528/any-difference-between-sdl-hwsurface-and-sdl-swsurface-concerning-speedperforma
20150930 03:21:49< Aginor> shadowm: I don't think it'll introduce much latency, there should only be an additional memcopy. It would however fix the crash without requiering major changes outside the window/display classes
20150930 03:21:59< shadowm> So it's like the inline keyword in C++.
20150930 03:22:56< shadowm> Just a hint that SDL is free to ignore in case the current platform/backend/weather does not support the option according to unspecified criteria.
20150930 03:23:23< shadowm> Aginor: So there is a crash?
20150930 03:23:41-!- Appleman1234 [~Appleman1@KD118156247208.au-net.ne.jp] has quit [Ping timeout: 256 seconds]
20150930 03:23:44< Aginor> shadowm: in sdl2 during resize
20150930 03:23:55< shadowm> Oh, it's that crash.
20150930 03:24:06< Aginor> becase sdl invalidates memory that the game keeps references to
20150930 03:24:07< shadowm> Well, it doesn't happen with SDL 1.2. Why?
20150930 03:24:27< Aginor> probably because they've changed the implementation since
20150930 03:24:41< shadowm> Do we even need to reference that memory? I assume this is the screen framebuffer.
20150930 03:25:26< shadowm> I thought the game generally didn't assume its address or properties were constant and whoever needed to access it did so through CVideo.
20150930 03:25:39< Aginor> which the game acquiers by asking SDL for a reference that it then caches
20150930 03:26:03< shadowm> CVideo also handles resolution change operations triggered by windowing events, though.
20150930 03:26:20< shadowm> So it should be able to update its internal reference accordingly.
20150930 03:26:41< Aginor> shadowm: the problem is that SDL invalidates the memory during the SDL_PumpEvents call. GUI2 has a couple of these added in the rendering code, causing the game to be in the middle of a rendering cycle when the memory reference points to bad memory
20150930 03:27:08< Aginor> shadowm: taking out the calls to SDL_PumpEvents fixes the crash, but at the cost of lost events.
20150930 03:27:16< shadowm> Or maybe it doesn't handle that, actually. Who handles the resolution switching?
20150930 03:27:47< shadowm> Or does SDL do it automatically?
20150930 03:29:18< Aginor> shadowm: video.cpp requests SDL to change the window size
20150930 03:29:46< shadowm> Yes, but not in reaction to events.
20150930 03:30:01-!- MotorMe [~MotorMe@111.203.197.141] has quit [Read error: Connection timed out]
20150930 03:30:10< shadowm> Searching for uses of setMode() didn't give me any matches in event-handling code at laest.
20150930 03:30:17< Aginor> shadowm: it doesn't crash in SDL1 because there is a flag requesting the surface to be resizable, causing SDL1.2 to not invalidate it
20150930 03:30:40< celticminstrel> ...XCode's syntax completion broke again. :|
20150930 03:30:55< celticminstrel> code competion
20150930 03:31:48< shadowm> Aginor: SDL_RESIZABLE?
20150930 03:31:56< Aginor> https://www.libsdl.org/release/SDL-1.2.15/docs/html/sdlsetvideomode.html
20150930 03:32:10-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20150930 03:32:23< Aginor> all of those flags are deprecated and ignored in SDL2
20150930 03:32:38< shadowm> The documentation doesn't say that the flag in question does what you say it does.
20150930 03:33:43< Aginor> true actually
20150930 03:34:21< Aginor> but the main point stands. The screen surface is updated through actions driven by the game, not driven by SDL receiving external events from X11
20150930 03:34:41< shadowm> Just checked the code, the only thing it does in X11 is instruct SDL to set the X11 window hints accordingly.
20150930 03:35:20< shadowm> If the surface's configuration is updated by the game then we should just enforce a policy of not allowing anyone to hold persistent references to it.
20150930 03:35:26-!- MotorMe [~MotorMe@111.203.197.141] has joined #wesnoth-dev
20150930 03:36:04< Aginor> src/gui/widgets/grid.cpp:920 and 958 is the cause of the bug
20150930 03:36:23< Aginor> which is a workaround for a different bug
20150930 03:36:37-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20150930 03:36:53< Aginor> but in SDL2, that workaround causes a crash, because the frame_buffer->pixels points to invalid memory from then onwards.
20150930 03:37:04< Aginor> causing subsequent blit operations to segfault
20150930 03:38:05< shadowm> It's not possible to defer the resolution change to the next safe point somehow?
20150930 03:38:17< celticminstrel> Can you get a new reference to the screen?
20150930 03:38:30< shadowm> That too.
20150930 03:38:34< Aginor> celticminstrel: yes, that we can do, but that breaks architecture and abstraction
20150930 03:38:53< celticminstrel> Though I suppose if you're in the middle of drawing and the window size changes, you actually need to start over.
20150930 03:39:02< Aginor> and any callers of the function would STILL have a reference to the wrong memory
20150930 03:39:22< shadowm> Is the surface ref always supposed to point to the screen framebuffer or can it point to some other surface?
20150930 03:39:32< shadowm> (In pratice.)
20150930 03:40:01< celticminstrel> Is it invalidated by PumpEvents no matter what, or only if there actually is a resize event?
20150930 03:40:28< celticminstrel> If it's the latter, maybe you can tell SDL to defer the resize until GUI2 is finished what it's doing, using event filters or something.
20150930 03:40:43< Aginor> shadowm: I am going to try making that surface point to a surface that is disjoint from the sdl window surface. The call to flip than blits that surface onto the sdl window surface
20150930 03:40:45< celticminstrel> It's not ideal (since it'll have to redraw everything after the resize), but...
20150930 03:40:56< Aginor> celticminstrel: no, you cannot tell sdl2 to defer the resize
20150930 03:41:25< Aginor> celticminstrel: it's only invalidated if there's been a resize
20150930 03:41:27< shadowm> Aginor: I was questioning the design of these methods.
20150930 03:41:55< Aginor> shadowm: the flip and setmode?
20150930 03:42:09< shadowm> gui2::tgrid::impl_draw_children()
20150930 03:42:18< shadowm> Both overloads.
20150930 03:42:30< Aginor> yes?
20150930 03:42:48< shadowm> Yes.
20150930 03:43:05< shadowm> (Or was that the answer to my question?)
20150930 03:43:12< Aginor> what's the problem with overloading?
20150930 03:43:25< celticminstrel> I don't think that's the problem.
20150930 03:43:29< shadowm> I didn't say there was a problem with overloading the method.
20150930 03:43:39< shadowm> 00:39:24 <shadowm> Is the surface ref always supposed to point to the screen framebuffer or can it point to some other surface?
20150930 03:44:14< Aginor> shadowm: it can point to any surface, but in practise it always points to the video framebuffer or fake framebuffer
20150930 03:44:49< shadowm> I guess there might be an actual use case for allowing the parameter to be an arbitrary surface: hidden and offscreen widgets.
20150930 03:45:01< Aginor> yes
20150930 03:45:25< shadowm> For example, in a well-populated listbox pretty much 90% of its children are offscreen at all times.
20150930 03:46:12< shadowm> So the issue is that this hack, which is in violation of the methods' contract, is needed.
20150930 03:46:42< Aginor> shadowm: are you referring to SDL_PumpEvents now?
20150930 03:47:00< shadowm> Yes, that's the hack.
20150930 03:47:09< Aginor> yes
20150930 03:47:30< Aginor> I think we should leave that in place for now
20150930 03:48:20< shadowm> We technically can pile up more hacks on top of that without having to change the framebuffer usage policy.
20150930 03:48:56< Aginor> I wouldn't touch gui2 at all
20150930 03:49:07< Aginor> I'd change the backing implementation in video.cpp
20150930 03:50:03< shadowm> if(frame_buffer->get() == get_display_frame_buffer()->get()) { fb_needs_update = true; } SDL_PumpEvents(); if(fb_needs_update) { frame_buffer = get_display_frame_buffer(); }
20150930 03:50:44< shadowm> Pseudocode. As it is it suggests having frame_buffer be passed by value rather than ref.
20150930 03:51:08< Aginor> no, I think that's the wrong approach
20150930 03:51:41< shadowm> The reason being...?
20150930 03:51:42< Aginor> you're putting responsibility of frame buffer management and updating into some arbitrary gui2 class, as opposed to in video.cpp which is responsible for it
20150930 03:52:18< shadowm> I don't see it like that. I'm just having this class take full responsibility for the hack it was already using in the first place.
20150930 03:52:54< shadowm> OTOH I guess the caller is still a problem, so never mind that.
20150930 03:53:03< Aginor> exactly
20150930 03:53:26< Aginor> the fact that it's a wrapper class and passed by reference could be the saving grace, but I'd not want to rely on that
20150930 03:53:35< shadowm> (We could tell the caller we're going to modify its parameter. :p)
20150930 03:53:36< Aginor> what I proposed earlier would work
20150930 03:53:51< Aginor> I do not think adding out parameters is a good idea :)
20150930 03:54:04< celticminstrel> Wait, is it calling SDL_PumpEvents directly?
20150930 03:54:07< shadowm> Then what would the backing buffer's characteristics be in order to make its location in memory constant across resizes?
20150930 03:54:11< Aginor> celticminstrel: yes.
20150930 03:54:35< Aginor> shadowm: I'd create a new surface with the same size and pixel mode as the screen surface
20150930 03:54:57< celticminstrel> So, it's just instructing SDL to put the events in its queue.
20150930 03:54:58< shadowm> But then if I resize the screen that surface still needs to be recreated.
20150930 03:55:04< celticminstrel> It's not handling any of them.
20150930 03:55:08< Aginor> shadowm: when there's a flip(), that new surface is blitted to the screen surface
20150930 03:55:26< celticminstrel> Isn't there an option to tell SDL to do that in a separate thread?
20150930 03:56:07< Aginor> shadowm: but control is in the game's hand, and there might be a delayed render cycle during resize but there wouldn't be a crash
20150930 03:57:04< shadowm> But then the double-buffering ceases to be transparent because somebody needs to know when it's safe to update the front buffer.
20150930 03:57:47< shadowm> Back buffer, I mean.
20150930 03:58:07< shadowm> The one we manages, not the one SDL manages (which would be the front buffer).
20150930 03:59:38< Aginor> shadowm: no. It'd be indistuinguishable from the current state
20150930 04:01:17< shadowm> By "update" I mean update its size and resolution and format to match the back buffer's.
20150930 04:01:33< celticminstrel> Well, anyway, time to see if the new syntax is working in [message].
20150930 04:01:41< celticminstrel> After I make sure the old syntax still works.
20150930 04:01:56< Aginor> shadowm: which will be ensured to happen when the game invokes setmode
20150930 04:02:50< shadowm> Okay, wait, so the whole conundrum can basically be boiled down to "SDL 2 now changes the screen size without the application's consent"? :\
20150930 04:03:36-!- irker609 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20150930 04:04:35< Aginor> shadowm: yes
20150930 04:05:24< shadowm> In that case it doesn't make sense that it even allows us to access the screen surface directly.
20150930 04:05:26< Aginor> shadowm: except that the application is consenting by calling PumpEvent
20150930 04:05:39< shadowm> Riiight.
20150930 04:06:45< celticminstrel> That doesn't seem like consent to me.
20150930 04:07:09< celticminstrel> But, that it's even necessary to call PumpEvents seems like a desgin flaw to me...
20150930 04:07:14< celticminstrel> ^design
20150930 04:07:25< Aginor> celticminstrel: yes, but that flaw is in GUI2
20150930 04:07:31< celticminstrel> I meant in SDL.
20150930 04:07:51< Aginor> celticminstrel: it isn't necissary. PollEvent does it for you
20150930 04:07:51< shadowm> It's bad design.
20150930 04:07:57< celticminstrel> Oh.
20150930 04:08:12< celticminstrel> So why does GUI2 need to do it, and why does events::pump() do it?
20150930 04:08:36< shadowm> (It being SDL_PumpEvents breaking things behind your back.)
20150930 04:09:03< celticminstrel> What happens if GUI2 doesn't do it? You said it was working around another bug.
20150930 04:10:15< shadowm> Anyway, my general stance on this: if GUI2 needs to be fixed, GUI2 needs to be fixed. If we get some concrete benefit other than not having to fix GUI2 from double-buffering, then okay, let's do that instead.
20150930 04:10:50-!- MotorMe [~MotorMe@111.203.197.141] has quit [Ping timeout: 272 seconds]
20150930 04:11:03< celticminstrel> The existence of flip() makes me think double-buffering is already happening.
20150930 04:11:09< shadowm> (The point being is that we can't treat GUI2 as an immovable blackbox forever, especially if we eventually want to look into GPU rendering.)
20150930 04:11:55< Aginor> celticminstrel: because the time it takes to render seems to be too long
20150930 04:13:02< celticminstrel> Specifically to render a dialog?
20150930 04:13:12< Aginor> celticminstrel: or a window, or a game window...
20150930 04:13:31< celticminstrel> Wasn't it a GUI2 problem?
20150930 04:13:47< shadowm> For the record, CVideo:flip() is just a convenient wrapper for a logic to only update a portion of the screen if only a portion needs to be updated.
20150930 04:13:52< Aginor> celticminstrel: main game window for example
20150930 04:14:07< celticminstrel> Okay, fair enough.
20150930 04:14:08< shadowm> (Since screen updates are usually queued beforehand in a rectangle-wise fashion.)
20150930 04:14:18< celticminstrel> Assuming you mean the main menu.
20150930 04:14:41-!- genbattle [~genbattle@122-57-89-170.jetstream.xtra.co.nz] has joined #wesnoth-dev
20150930 04:14:42< celticminstrel> Ah.
20150930 04:15:01< celticminstrel> Isn't there something like SDL_Flip() already?
20150930 04:15:28< shadowm> That's what it calls when it knows it needs to update the whole screen, otherwise it calls SDL_UpdateRects(). (With SDL 1.2, anyway.)
20150930 04:15:41< celticminstrel> Ah.
20150930 04:15:51< celticminstrel> So it is using double-buffering.
20150930 04:16:21< shadowm> You could say that, except that SDL_Flip() is also able to work without double-buffering.
20150930 04:16:31< shadowm> " On hardware that doesn't support double-buffering, this is equivalent to calling SDL_UpdateRect(screen, 0, 0, 0, 0)"
20150930 04:17:02< shadowm> There is a SDL (1.2) option to use double buffering, but we do *not* use it.
20150930 04:17:08< celticminstrel> Ah.
20150930 04:17:59< celticminstrel> Any particular reason why not?
20150930 04:19:25< shadowm> I suspect the only person who knows that (IF there is a reason) is 2003 Dave. :p
20150930 04:19:48< celticminstrel> Which implies not 2015 Dave.
20150930 04:20:14-!- Appleman1234 [~Appleman1@KD111239019250.au-net.ne.jp] has joined #wesnoth-dev
20150930 04:20:18< shadowm> (CVideo is the probably the oldest class around, present in Wesnoth 0.1.)
20150930 04:20:22< celticminstrel> Does that option still work in SDL2, or is it deprecated too?
20150930 04:20:37< celticminstrel> Or does SDL2 automatically use it by default if possible?
20150930 04:20:45< shadowm> So, version 0.1 (which is not in the repository) did not use double-buffering.
20150930 04:21:05< shadowm> However, it seems double-buffering was introduced later and then removed again in commit a2b3c84ea0c06b34eb5a0226686c2711447ed818, in October 2003, by Dave.
20150930 04:21:17< shadowm> The commit message (1 line): "made display draw more efficiently"
20150930 04:21:22< celticminstrel> Uh, okay.
20150930 04:21:54< shadowm> Originally introduced in commit 8c687712acab0192410e557d34714cc13611ba38, "Changed to user video hardware surfaces where possible".
20150930 04:22:36< shadowm> So the SDL_DOUBLEBUF flag was quickly dropped, but SDL_HWSURFACE has remained since then.
20150930 04:22:54< shadowm> I'd like to think there was a good reason for that.
20150930 04:24:39< celticminstrel> According to the comment, removing the SDL_PumpEvents call causes a black area.
20150930 04:24:53< shadowm> Ultimately, we won't know for sure unless someone goes and tests it and checks the performance and footprint implications.
20150930 04:25:05< celticminstrel> So I guess not using the whole window.
20150930 04:26:03< shadowm> (I suspect a 1920x1080 8BPC RGB surface on system RAM isn't something you want multiple instances of.)
20150930 04:26:40< celticminstrel> Does SDL2 automatically use double-buffering if the hardware supports it?
20150930 04:26:57< celticminstrel> Or would you still have to specify the SDL_DOUBLEBUF flag?
20150930 04:29:08< shadowm> 5.93 MiB assuming uncompressed storage.
20150930 04:31:13-!- genbattle [~genbattle@122-57-89-170.jetstream.xtra.co.nz] has quit [Ping timeout: 246 seconds]
20150930 04:31:25< celticminstrel> Yeah, probably not.
20150930 04:44:07< celticminstrel> BTW shadowm, is there any particular reason why the config iterators are not default-constructible?
20150930 04:44:36< celticminstrel> That you know of.
20150930 04:45:47-!- [Relic] [~Relic]@2602:306:33a3:6d30:1511:17e6:dad8:8197] has joined #wesnoth-dev
20150930 04:57:18-!- [Relic] [~Relic]@2602:306:33a3:6d30:1511:17e6:dad8:8197] has quit [Quit: I press the magic X and all the weirdos go away!]
20150930 04:57:41< celticminstrel> vultraz: So, I have it working, I think,
20150930 04:59:56< celticminstrel> If message= is the only key present, then it assumes legacy format.
20150930 05:00:06< celticminstrel> Otherwise message= is a synonym for label=
20150930 05:00:32< shadowm> celticminstrel: What would you do with a default-constructed iterator?
20150930 05:00:48< celticminstrel> shadowm: Assign different things to it depending on if statements.
20150930 05:01:22< celticminstrel> Then use it for iteration.
20150930 05:01:35< celticminstrel> Of course you'd have to make sure that something is assigned to it before using it for iteration.
20150930 05:02:24< celticminstrel> The underlying standard container iterators are default-constructible.
20150930 05:05:54-!- oldlaptop [~quassel@50.36.238.180] has quit [Ping timeout: 240 seconds]
20150930 05:18:02-!- oldlaptop [~quassel@50.36.238.180] has joined #wesnoth-dev
20150930 05:23:53-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has joined #wesnoth-dev
20150930 05:24:47-!- celmin [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20150930 05:24:47-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Disconnected by services]
20150930 05:24:48-!- celmin is now known as celticminstrel
20150930 05:24:59-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Read error: Connection reset by peer]
20150930 05:25:25-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has joined #wesnoth-dev
20150930 05:26:03-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20150930 05:26:25-!- Jozrael [~Jozrael@192.91.144.16] has quit [Ping timeout: 240 seconds]
20150930 05:31:51-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Ping timeout: 244 seconds]
20150930 05:34:44-!- MotorMe [~MotorMe@111.203.197.141] has joined #wesnoth-dev
20150930 05:35:33-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has joined #wesnoth-dev
20150930 05:36:16-!- [Relic] [~Relic]@2602:306:33a3:6d30:dcce:d21b:ca2:3e3e] has joined #wesnoth-dev
20150930 05:39:32-!- [Relic] [~Relic]@2602:306:33a3:6d30:dcce:d21b:ca2:3e3e] has quit [Client Quit]
20150930 05:42:28< celticminstrel> vultraz: PR513 whenever you're around
20150930 05:47:41-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 252 seconds]
20150930 05:58:31-!- MotorMe [~MotorMe@111.203.197.141] has quit [Ping timeout: 246 seconds]
20150930 06:00:11-!- MotorMe [~MotorMe@111.203.197.141] has joined #wesnoth-dev
20150930 06:03:22-!- prkc [~prkc@catv-89-134-159-103.catv.broadband.hu] has quit [Remote host closed the connection]
20150930 06:04:24-!- celticminstrel is now known as celmin|sleep
20150930 06:18:47-!- MotorMe [~MotorMe@111.203.197.141] has quit [Ping timeout: 264 seconds]
20150930 06:20:03-!- Kwandulin [~Miranda@p5B008DAB.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150930 06:20:38-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20150930 06:28:08-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20150930 06:31:25-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has joined #wesnoth-dev
20150930 06:42:48-!- MotorMe [~MotorMe@111.203.197.141] has joined #wesnoth-dev
20150930 06:48:34< wedge009> gfgtdf: Uh, no? I've been focusing on investigating/fixing bugs and helping with SDL2 development/testing.
20150930 06:49:27-!- genbattle [~genbattle@122-57-89-170.jetstream.xtra.co.nz] has joined #wesnoth-dev
20150930 06:50:43< wedge009> And what a can of worms this SDL2 blit business has been. I only followed the discussion at a high level, but I get the gist that the SDL2 deprecates/ignores some flags preventing reference invalidation, which then exposes the pump events work-around used in gui2 in an attempt to avoid dropping events.
20150930 06:53:35< wedge009> Two possible solutions: double/triple-buffering or multi-threading... was there any consensus as to the direction we should go?
20150930 07:15:02-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20150930 07:23:24-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 250 seconds]
20150930 07:26:23-!- timotei_ [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20150930 07:29:04-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20150930 07:32:23-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Ping timeout: 268 seconds]
20150930 07:35:29< vultraz> celmin|sleep: suggestion. instead of [while] cond [do] actions, [while]  [conditions] cond [/conditions] actions 
20150930 07:35:55< Aginor> wedge009: try to fix gui2
20150930 07:36:18< Aginor> I implemented triple buffering and it's exhibiting the same behaviour as not pumping
20150930 07:36:42< Aginor> wedge009: I've also reproduced the olour cursor business
20150930 07:37:09< wedge009> The not-pumping behaviour was good or bad?
20150930 07:38:03< wedge009> I saw the confirmation, thanks. I was going to ask what you did to reproduce it, wondering if doing the reverse would help in any way. I also confirmed that the colour cursors are broken on the R9 290 with radeon as well as fglrx.
20150930 07:41:39-!- Kwandulin_2 [~Miranda@p5B008F3F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150930 07:41:45< Aginor> wedge009: I paid attention and actually enabled the colour cursors :)
20150930 07:42:02< Aginor> I had not paid much attention and thought I was using them when I wasn't
20150930 07:42:18< Aginor> sorry for asking you for stuff when I was being silly
20150930 07:42:29< Aginor> wedge009: not-pumping behaviour is bad
20150930 07:42:36< wedge009> Ah! Well, it sounds like it's out of our hands then, unless someone else with an ATI/AMD GPU can confirm a working colour cursor.
20150930 07:42:43< wedge009> Nah, it's fine, you've been doing a lot.
20150930 07:43:03< wedge009> And okay, so sounds like fixing gui2 is the only option after all.
20150930 07:43:05< wedge009> Ouch.
20150930 07:43:54< Aginor> I'm not sure how feasible that is in the nearterm either
20150930 07:44:18< Aginor> I'll investigate further
20150930 07:44:21-!- Kwandulin [~Miranda@p5B008DAB.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
20150930 07:45:16< wedge009> Let me know if you want me to test/check anything on Windows or whatever.
20150930 07:45:28< Aginor> wedge009: thanks :)
20150930 07:46:00< Aginor> we need to figure out that entire icon business too
20150930 07:47:40< wedge009> I'd say it's low priority, certainly not game-breaking. But I wish I knew what triggers its flipping between working and non-working states.
20150930 07:48:01< Aginor> yeah, that'd be useful
20150930 07:48:18< wedge009> The image appears to be loading fine even when it doesn't show, so I don't think it's an issue with the file or file access.
20150930 07:50:54< Aginor> no, I think that your timing0related guess is a good one
20150930 07:51:08-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 250 seconds]
20150930 07:51:21< wedge009> I thought shadowm said it wasn't timing-related? Or maybe that was referring to my remark about the SDL1.2 comment.
20150930 07:58:04-!- Kwandulin_2 [~Miranda@p5B008F3F.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
20150930 08:00:41< Aginor> I thought that was related to sdl1.2
20150930 08:01:21-!- Appleman1234 [~Appleman1@KD111239019250.au-net.ne.jp] has quit [Ping timeout: 256 seconds]
20150930 08:02:33-!- Kwandulin [~Miranda@p5B008F3F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150930 08:05:46-!- MotorMe [~MotorMe@111.203.197.141] has quit [Ping timeout: 244 seconds]
20150930 08:06:15-!- boucman_work [~jrosen@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20150930 08:06:15-!- boucman_work [~jrosen@bob75-2-81-56-46-209.fbx.proxad.net] has quit [Changing host]
20150930 08:06:15-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20150930 08:14:12-!- genbattle [~genbattle@122-57-89-170.jetstream.xtra.co.nz] has quit [Ping timeout: 264 seconds]
20150930 08:28:19-!- joet [~joet@host86-163-223-204.range86-163.btcentralplus.com] has joined #wesnoth-dev
20150930 08:46:36-!- Kwandulin [~Miranda@p5B008F3F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150930 08:58:43-!- Appleman1234 [~Appleman1@KD111239030064.au-net.ne.jp] has joined #wesnoth-dev
20150930 09:39:38-!- mjs-de [~mjs-de@f048213148.adsl.alicedsl.de] has joined #wesnoth-dev
20150930 09:43:06< vultraz> celmin|sleep: your PR passes travis 
20150930 09:47:01-!- Kwandulin [~Miranda@p5B008F3F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150930 10:12:13-!- Kwandulin [~Miranda@p5B008F3F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150930 10:17:24-!- MotorMe [~MotorMe@27.189.14.82] has joined #wesnoth-dev
20150930 10:21:34-!- MotorMe [~MotorMe@27.189.14.82] has quit [Ping timeout: 246 seconds]
20150930 10:24:11-!- joet [~joet@host86-163-223-204.range86-163.btcentralplus.com] has quit [Remote host closed the connection]
20150930 10:26:23-!- joet [~joet@host86-163-223-204.range86-163.btcentralplus.com] has joined #wesnoth-dev
20150930 10:27:30-!- joet [~joet@host86-163-223-204.range86-163.btcentralplus.com] has quit [Client Quit]
20150930 10:27:46-!- joet [~joet@host86-163-223-204.range86-163.btcentralplus.com] has joined #wesnoth-dev
20150930 11:22:18-!- Kwandulin [~Miranda@p5B008F3F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150930 11:39:18-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20150930 11:41:30-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20150930 11:41:30-!- wedge010 is now known as wedge009
20150930 11:49:28-!- MotorMe [~MotorMe@27.189.14.82] has joined #wesnoth-dev
20150930 12:11:07-!- MotorMe [~MotorMe@27.189.14.82] has quit [Ping timeout: 268 seconds]
20150930 12:12:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20150930 12:37:43-!- prkc [~prkc@89.134.159.103] has joined #wesnoth-dev
20150930 12:52:58-!- Kwandulin [~Miranda@p5B008F3F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150930 13:07:30-!- Kwandulin [~Miranda@p5B008F3F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150930 13:27:01-!- irker315 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20150930 13:27:01< irker315> wesnoth: Charles Dang wesnoth:master 96fc657d41c2 / data/campaigns/Eastern_Invasion/scenarios/10_Lake_Vrug.cfg: E1 S10: end scenario when research begins if enemies are defeated (bug #23899) http://git.io/vccMq
20150930 13:29:09< irker315> wesnoth: Charles Dang wesnoth:1.12 a1759666106d / data/campaigns/Eastern_Invasion/scenarios/10_Lake_Vrug.cfg: E1 S10: end scenario when research begins if enemies are defeated (bug #23899) http://git.io/vccDk
20150930 13:57:02< vultraz> celmin|sleep: is it just me or is the message implementation really overly complicated. It's spread across lua, C++, and lua/c++ :/
20150930 14:16:52-!- Kwandulin [~Miranda@p5B008F3F.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds]
20150930 14:17:15-!- travis-ci [~travis-ci@ec2-54-226-161-190.compute-1.amazonaws.com] has joined #wesnoth-dev
20150930 14:17:16< travis-ci> wesnoth/wesnoth#7542 (master - 96fc657 : Charles Dang): The build has errored.
20150930 14:17:17< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/82928407
20150930 14:17:17-!- travis-ci [~travis-ci@ec2-54-226-161-190.compute-1.amazonaws.com] has left #wesnoth-dev []
20150930 14:56:23-!- Appleman1234 [~Appleman1@KD111239030064.au-net.ne.jp] has quit [Ping timeout: 268 seconds]
20150930 15:18:52-!- joet [~joet@host86-163-223-204.range86-163.btcentralplus.com] has quit [Ping timeout: 246 seconds]
20150930 15:21:20-!- joet [~joet@host86-163-220-173.range86-163.btcentralplus.com] has joined #wesnoth-dev
20150930 15:27:17-!- aquileia [95acd0d3@gateway/web/freenode/ip.149.172.208.211] has joined #wesnoth-dev
20150930 15:32:41< aquileia> Now that 1.13.2 is on the horizon, I should finish the patch installer scripts... my main problem is the inclusion in scons. I'm having a hard time wrapping my head around builders and it doesn't help that I can't test the script because the 'wesnoth' target requires gcc
20150930 15:33:42< aquileia> Not to forget a heap of dependencies that aren't recognized because I'm on Windows
20150930 15:35:22< aquileia> Perhaps one of the Python people that offered their help might look at the scons files? They could use some maintenance as well, I guess. After all, it's based on Python.
20150930 15:44:53< aquileia> Ahem... I guess that's a copy-paste error from data-dist: "binary-dist = make data tarball as wesnoth-binaries.tar.bz2"
20150930 16:02:02-!- Jozrael [Jozrael@cpe-23-243-161-16.socal.res.rr.com] has joined #wesnoth-dev
20150930 16:04:49-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 250 seconds]
20150930 16:12:47< celmin|sleep> vultraz: No objections from me on [while][conditions], except that it's probably a bit late to change something like that now.
20150930 16:13:07< celmin|sleep> I dunno if the message implementation is overly complicated?
20150930 16:23:11-!- [Relic] [~Relic]@2602:306:33a3:6d30:ecf9:8908:f654:dd58] has joined #wesnoth-dev
20150930 16:26:23-!- Appleman1234 [~Appleman1@KD118156246121.au-net.ne.jp] has joined #wesnoth-dev
20150930 16:28:29-!- Jozrael [Jozrael@cpe-23-243-161-16.socal.res.rr.com] has quit [Ping timeout: 244 seconds]
20150930 16:30:55-!- joet [~joet@host86-163-220-173.range86-163.btcentralplus.com] has quit [Quit: Leaving]
20150930 16:31:29-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20150930 16:31:32-!- irker315 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20150930 16:32:19-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has joined #wesnoth-dev
20150930 16:32:54-!- horrowind [~Icedove@2a02:810a:8b00:1c54:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20150930 16:41:20-!- Jozrael [~Jozrael@192.91.144.19] has joined #wesnoth-dev
20150930 16:44:50-!- Kwandulin [~Miranda@p5B008F3F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150930 17:09:33-!- gfgtdf [~chatzilla@f054059118.adsl.alicedsl.de] has joined #wesnoth-dev
20150930 17:09:43< gfgtdf> aquileia: you are working on teh automatic updater again ?
20150930 17:10:57< aquileia> Currently only the manual patch installer, the automatic one won't require much additional work on the NSIS & Scons scripts though
20150930 17:13:25< celmin|sleep> gfgtdf: I forget, did you see the update to my child_range?
20150930 17:13:30-!- celmin|sleep is now known as celticminstrel
20150930 17:15:40< gfgtdf> celticminstrel: y i saw it the helper.child_range implementation looks good to me now
20150930 17:21:50-!- Appleman1234 [~Appleman1@KD118156246121.au-net.ne.jp] has quit [Ping timeout: 250 seconds]
20150930 17:24:58< gfgtdf> vultraz, celticminstrel: you have an opiotion on http://gna.org/bugs/?23914?, (whihc of the 2 options would you prefer ?)
20150930 17:28:26< aquileia> gfgtdf: Current scons snippet to generate patches http://pastebin.com/uRT7kxT1
20150930 17:28:55< gfgtdf> celticminstrel: i rmember that you changed game_lua_kernal::run_filter to also accept function expressions but somehow i cnanotz find that in teh c++ code :s
20150930 17:29:45< celticminstrel> It's not in master.
20150930 17:30:00< gfgtdf> celticminstrel: ah ok
20150930 17:30:01< celticminstrel> It's in my filters branch.
20150930 17:30:03-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20150930 17:30:07-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 246 seconds]
20150930 17:30:15< aquileia> The NSIS patch installer basically applies the patch.7z and deletes all files listed in deletelist.txt
20150930 17:31:09< gfgtdf> aquileia: so the 1.12.6 patch (just an example) will ontain all changes from 1.12.0 onwards ?
20150930 17:31:11< aquileia> Downloading the patch.7z would be simple as well
20150930 17:31:20< aquileia> yes
20150930 17:31:33-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 17:31:42< celticminstrel> Regarding custom effects, the first syntax (wesnoth.effects.*) seems better, but I'm questioning whether we actually need custom effects rather than just adding an apply_to=set_variables.
20150930 17:33:58< gfgtdf> celticminstrel: but teh seconds function also alolows to store the function irectly into the [effect] (function= <<function(u,c) .. end>>) so that you dont have to make sure teh function is present in every scenario that it appears on :s
20150930 17:34:26< gfgtdf> celticminstrel: in the addson i have played people often tried to implement cusom effect via complicated events
20150930 17:35:38< celticminstrel> Now that global-level [lua] is possible, as well as era- and campaign-level [lua], I don't think there's an issue with making sure the function is present in every scenario that it appears in.
20150930 17:38:07< gfgtdf> celticminstrel: hmm mmaybe you are right, in the worst acsae on can implement effect=lua using wesnoth.effects.lua :p
20150930 17:38:42< celticminstrel> True.
20150930 17:58:37-!- horrowind [~Icedove@2a02:810a:8b00:1c54:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20150930 18:18:23-!- louis94 [~~louis94@109.129.205.202] has joined #wesnoth-dev
20150930 18:19:23< gfgtdf> vultraz: you broke the campaign  'An Orcish Incursion' please fix it
20150930 18:19:27-!- Appleman1234 [~Appleman1@KD106161087242.au-net.ne.jp] has joined #wesnoth-dev
20150930 18:27:47< celticminstrel> How'd he break it? New difficulty syntax?
20150930 18:28:07-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20150930 18:28:36< gfgtdf> celticminstrel: y, it wont start anymore
20150930 18:29:15< celticminstrel> What about the other campaigns?
20150930 18:30:13< gfgtdf> celticminstrel: i didn't test all campaigns
20150930 18:30:35< celticminstrel> Do HTTT and UtbS work?
20150930 18:30:41< celticminstrel> I think he was testing it on those.
20150930 18:31:10< celticminstrel> If they don't work, it might be an error in the macro definitions.
20150930 18:34:36-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 264 seconds]
20150930 18:42:04< vultraz> just AOI broken :(
20150930 18:47:05< celticminstrel> vultraz: Did you have a problem with the [message] implementation of the new syntax?
20150930 18:58:13-!- markus__ [~mjs-de@x4db51259.dyn.telefonica.de] has joined #wesnoth-dev
20150930 18:58:32-!- Shackra [~Jorge@186.177.2.148] has joined #wesnoth-dev
20150930 19:01:49-!- mjs-de [~mjs-de@f048213148.adsl.alicedsl.de] has quit [Ping timeout: 268 seconds]
20150930 19:03:55-!- [Relic] [~Relic]@2602:306:33a3:6d30:ecf9:8908:f654:dd58] has quit [Quit: I press the magic X and all the weirdos go away!]
20150930 19:10:39< vultraz> celticminstrel: code wise it looks sound
20150930 19:10:57< vultraz> I just didn't realize how complex that code is
20150930 19:11:22< celticminstrel> Then shall I merge it?
20150930 19:11:43< vultraz> Yes
20150930 19:12:17-!- irker340 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20150930 19:12:17< irker340> wesnoth: Celtic Minstrel wesnoth:master 114b31c90c25 / / (6 files in 5 dirs): New syntax for [message][option]message= similar to new [campaign][difficulty] http://git.io/vclTe
20150930 19:12:17< irker340> wesnoth: CelticMinstrel wesnoth:master d964aeecb521 / / (6 files in 5 dirs): Merge pull request #513 from CelticMinstrel/descriptionwml http://git.io/vclTv
20150930 19:12:35-!- [Relic] [~Relic]@2602:306:33a3:6d30:6cc0:3677:ec9e:722] has joined #wesnoth-dev
20150930 19:14:17< vultraz> That fully deprecates the old syntax in all places, I think?
20150930 19:14:25-!- louis94 [~~louis94@109.129.205.202] has quit [Read error: Connection reset by peer]
20150930 19:14:35< celticminstrel> Think so.
20150930 19:14:44< vultraz> :D
20150930 19:14:49-!- louis94 [~~louis94@109.129.205.202] has joined #wesnoth-dev
20150930 19:18:39-!- markus__ [~mjs-de@x4db51259.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20150930 19:19:03< celticminstrel> Does still need changelog entry, I guess.
20150930 19:19:48< vultraz> I see no reason against merging 507 too
20150930 19:21:12-!- lww5064 [~louis@pool-72-94-81-85.phlapa.fios.verizon.net] has joined #wesnoth-dev
20150930 19:21:22< celticminstrel> Which was the vconfig, right?
20150930 19:21:39< vultraz> lua vconfig yes
20150930 19:21:41-!- Kwandulin [~Miranda@p5B008F3F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150930 19:21:42< celticminstrel> gfgtdf: Agreed on that?
20150930 19:22:03< gfgtdf> celticminstrel: i see no reason aginst merging currently
20150930 19:22:07< gfgtdf> vultraz: you already fixed AOI?
20150930 19:22:25< vultraz> I'm trying to figure out what's wrong with it
20150930 19:22:55< vultraz> apparently the gamestate isn't valid when you try to launch it :/ 
20150930 19:22:55< irker340> wesnoth: Celtic Minstrel wesnoth:master e46070fdbe87 / src/scripting/lua_common.cpp: Lua API: Add iteration metamethods for vconfig http://git.io/vclLD
20150930 19:22:57< irker340> wesnoth: Celtic Minstrel wesnoth:master 03a38c529419 / data/lua/helper.lua: Lua API: More helper functions for configs http://git.io/vclLy
20150930 19:22:59< irker340> wesnoth: Celtic Minstrel wesnoth:master 8e228edc3409 / src/scripting/lua_common.cpp: Lua API: Fix ipairs(vconfig) to match ipairs(config) http://git.io/vclLS
20150930 19:23:01< irker340> wesnoth: Celtic Minstrel wesnoth:master 376b8ac76b09 / src/scripting/lua_common.cpp: Use userdata instead of indices for the vconfig iterator upvalues http://git.io/vclL9
20150930 19:23:03< irker340> wesnoth: Celtic Minstrel wesnoth:master 7fb0831da600 / data/lua/helper.lua: Use ipairs for the helper functions http://git.io/vclLH
20150930 19:23:05< irker340> wesnoth: Celtic Minstrel wesnoth:master 2c337d411547 / data/lua/helper.lua src/scripting/lua_common.cpp: Use ipairs() for helper.child_range http://git.io/vclLQ
20150930 19:23:07< irker340> wesnoth: Celtic Minstrel wesnoth:master 9aa015a57a9e / data/lua/helper.lua: Fix helper.child_range to work on config and vconfig alike http://git.io/vclL7
20150930 19:23:09< irker340> wesnoth: CelticMinstrel wesnoth:master f31084da84ec / data/lua/helper.lua: Remove asserts http://git.io/vclL5
20150930 19:23:11< irker340> wesnoth: CelticMinstrel wesnoth:master 320372d6b880 / data/lua/helper.lua src/scripting/lua_common.cpp: Merge pull request #507 from CelticMinstrel/lua-vconfig http://git.io/vclLd
20150930 19:23:22-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20150930 19:23:25< celticminstrel> I'll put together a changelog entry at some point.
20150930 19:23:32< celticminstrel> Unless someone else gets to it first.
20150930 19:23:40< celticminstrel> Ditto for editing the wiki;
20150930 19:23:42< celticminstrel> ^.
20150930 19:23:44< vultraz> game_initialization/singleplayer.cpp:121 is the error I'm getting for it
20150930 19:25:01< gfgtdf> vultraz: uhm i think its much easer to look at at the changes in AOI than to debugg the issue.
20150930 19:25:43< vultraz> probably a good idea
20150930 19:27:15-!- louis94 [~~louis94@109.129.205.202] has quit [Ping timeout: 244 seconds]
20150930 19:28:37< vultraz> weird...
20150930 19:28:52< vultraz> it's just the difficulty syntax like all the others
20150930 19:32:35< vultraz> ohhhhhhh
20150930 19:32:44< vultraz> found the problem
20150930 19:34:38< gfgtdf> :)
20150930 19:35:28< irker340> wesnoth: Charles Dang wesnoth:master 9e24258b5f5b / data/campaigns/An_Orcish_Incursion/_main.cfg: AOI: used macros for difficulty levels and restored missing define http://git.io/vclGX
20150930 19:35:32< vultraz> gfgtdf: ^
20150930 19:36:04< gfgtdf> vultraz: looks good ty
20150930 19:36:27-!- louis94 [~~louis94@109.129.205.202] has joined #wesnoth-dev
20150930 19:47:34< vultraz> gfgtdf: can we merge https://github.com/wesnoth/wesnoth/pull/356 ?
20150930 19:49:09< gfgtdf> vultraz: i see no reason agsint but i dont really know how it works
20150930 19:49:38< celticminstrel> Likewise.
20150930 19:54:06-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20150930 19:54:16< iceiceice> hi
20150930 19:54:47< fabi> hi iceiceice
20150930 19:54:56< iceiceice> hi
20150930 19:56:50< vultraz> hello iceiceice 
20150930 19:57:07< iceiceice> hello vultraz 
20150930 19:58:25-!- ancestral [~ancestral@213.sub-70-197-206.myvzw.com] has joined #wesnoth-dev
20150930 20:01:18< gfgtdf> celticminstrel: you know whether i can ina for loop do somtthing liek this: 'for i = 1,10 do ... if ... then i = i - 1 end end' ?
20150930 20:01:32< gfgtdf> celticminstrel: to repeat the current iteration step i mean
20150930 20:01:39< celticminstrel> Lemme check.
20150930 20:03:19< vultraz> iceiceice: what should we do with your remaining non-wip PRs? Mainly...uh.. 318, possibly 339, 379 (maybe), and 380
20150930 20:04:00< celticminstrel> gfgtdf: Seems not.
20150930 20:04:13< celticminstrel> I guess you'll have to use a while loop.
20150930 20:05:01< celticminstrel> The [for] tag is implemented with a while loop.
20150930 20:08:51< iceiceice> vultraz: i think 318 was okay
20150930 20:08:56< iceiceice> but it was a really long time ago
20150930 20:09:04< iceiceice> like that was almost a year ago i think
20150930 20:09:17< iceiceice> and iirc fabi suggested (and i agree) that probably it owuld be better to just eliminate fractional zooming entirely
20150930 20:09:23< iceiceice> since its kind of pointless
20150930 20:09:26< iceiceice> and that would side step the entire issue
20150930 20:09:32< iceiceice> i think thats why i did not merge it
20150930 20:09:42< vultraz> Ah, yes
20150930 20:09:47< vultraz> I think I agreed with that
20150930 20:09:47< celticminstrel> Fractional zooming means...?
20150930 20:10:04< vultraz> say, 1.67 zoom
20150930 20:10:06< iceiceice> celticminstrel: currently in the game, you have this scaling slider, you can zoom in to like, 108% size or someting
20150930 20:10:07< iceiceice> sure
20150930 20:10:12< iceiceice> the problem wiht it is,
20150930 20:10:13< vultraz> instead of fixed intervals 
20150930 20:10:20< iceiceice> you get tons of visual artifacts, tearing at hex edges,
20150930 20:10:24< vultraz> I supported .5 fixed percentage 
20150930 20:10:27< iceiceice> and all the sprites look like crap because you ruin the pixel art sort of
20150930 20:10:43< celticminstrel> I think it'd be completely reasonable to have the same fixed values as the accelerated speed allows.
20150930 20:10:51< celticminstrel> Or, something similar at least.
20150930 20:10:55< iceiceice> i think the engine currently just uses linear interpolation on the spirtes
20150930 20:11:07< iceiceice> celticminstrel: in 1.13 branch i added that xBRZ patch
20150930 20:11:10< vultraz> I have no idea why we didn't implement the fixed steps
20150930 20:11:12< iceiceice> so the fixed integer scaling is like, nicely done
20150930 20:11:22< iceiceice> you could porbably even like, allow 1, 1.5, 2, 2.5
20150930 20:11:30< iceiceice> if you do a combination of xbrz and linear
20150930 20:11:40< iceiceice> i think there are some people who use fractianl, i think beetlenaut said this on forums once
20150930 20:12:02< vultraz> Oh, yeah
20150930 20:12:20< vultraz> Or did he just say he used < 1?
20150930 20:12:28< iceiceice> i dont remember anymore
20150930 20:12:29< vultraz> Maybe we can support .5
20150930 20:12:45< celticminstrel> The main problem with the arbitrary scaling is that it's almost impossible to get back to an exact 100%  (for example).
20150930 20:12:52< iceiceice> vultraz: 339 is like, barely any content
20150930 20:12:56< celticminstrel> In my opinion.
20150930 20:13:10< iceiceice> maybe there is some person who cares to reduce the code duplication tehre
20150930 20:13:29< iceiceice> you could close it as moot if you want, or leave it up, i dont think it matters that muc
20150930 20:14:00< iceiceice> vultraz: i think 379 is probably a very worthwhile patch
20150930 20:14:01< iceiceice> but
20150930 20:14:07< iceiceice> i cannot vouch for it not creating bugs right now
20150930 20:14:24< iceiceice> someone woudl basically need to adopt it and test it and possibly change it if there are new issues
20150930 20:14:55< iceiceice> vultraz: i guess i should close 254
20150930 20:15:05< iceiceice> that patch is actually just pointless, the correct way to do that is using boost::fusion
20150930 20:15:14< iceiceice> i didnt know about that lib at the time i made the patch
20150930 20:15:42< iceiceice> 222 should defintiley be closed
20150930 20:15:52-!- Appleman1234 [~Appleman1@KD106161087242.au-net.ne.jp] has quit [Ping timeout: 246 seconds]
20150930 20:21:22-!- [Relic] [~Relic]@2602:306:33a3:6d30:6cc0:3677:ec9e:722] has quit [Quit: I press the magic X and all the weirdos go away!]
20150930 20:30:58-!- travis-ci [~travis-ci@ec2-54-159-162-144.compute-1.amazonaws.com] has joined #wesnoth-dev
20150930 20:30:59< travis-ci> wesnoth/wesnoth#7544 (master - d964aee : CelticMinstrel): The build passed.
20150930 20:30:59< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/82990567
20150930 20:30:59-!- travis-ci [~travis-ci@ec2-54-159-162-144.compute-1.amazonaws.com] has left #wesnoth-dev []
20150930 20:42:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20150930 20:48:50-!- [Relic] [~Relic]@2602:306:33a3:6d30:1163:5aa3:23fc:81e] has joined #wesnoth-dev
20150930 21:10:03-!- lww5064 [~louis@pool-72-94-81-85.phlapa.fios.verizon.net] has quit [Quit: leaving]
20150930 21:13:06-!- travis-ci [~travis-ci@ec2-54-226-181-67.compute-1.amazonaws.com] has joined #wesnoth-dev
20150930 21:13:07-!- Guest37880 [~quassel@london.acm.jhu.edu] has joined #wesnoth-dev
20150930 21:13:07< travis-ci> wesnoth/wesnoth#7545 (master - 320372d : CelticMinstrel): The build passed.
20150930 21:13:07< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/82992447
20150930 21:13:07-!- travis-ci [~travis-ci@ec2-54-226-181-67.compute-1.amazonaws.com] has left #wesnoth-dev []
20150930 21:13:38-!- Appleman1234 [~Appleman1@KD111239009061.au-net.ne.jp] has joined #wesnoth-dev
20150930 21:17:34-!- Guest37880 [~quassel@london.acm.jhu.edu] has quit [Ping timeout: 250 seconds]
20150930 21:18:58-!- ancestral [~ancestral@213.sub-70-197-206.myvzw.com] has quit [Read error: Connection reset by peer]
20150930 21:22:45< gfgtdf> celticminstrel: maybe u:to_map() coudl have a placement parmaeter like [unit] has ato place it to an adjacent location if the location is alredy occupied ?
20150930 21:23:12< celticminstrel> Maybe.
20150930 21:24:16-!- louis94 [~~louis94@109.129.205.202] has quit [Ping timeout: 246 seconds]
20150930 21:24:51-!- [Relic] [~Relic]@2602:306:33a3:6d30:1163:5aa3:23fc:81e] has quit [Quit: I press the magic X and all the weirdos go away!]
20150930 21:27:33< gfgtdf> celticminstrel: hm or mabye this is not needed since lua already exposes find_vacant_tile
20150930 21:27:40-!- [Relic] [~Relic]@2602:306:33a3:6d30:9490:86bb:ae89:c5dc] has joined #wesnoth-dev
20150930 21:28:45< celticminstrel> It's definitely not needed, but might be convenient.
20150930 21:39:39-!- [Relic] [~Relic]@2602:306:33a3:6d30:9490:86bb:ae89:c5dc] has quit [Quit: I press the magic X and all the weirdos go away!]
20150930 21:45:01-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20150930 21:47:53-!- louis94 [~~louis94@109.129.205.202] has joined #wesnoth-dev
20150930 22:06:27-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20150930 22:07:37-!- fabi [~quassel@176.4.83.34] has joined #wesnoth-dev
20150930 22:07:37-!- fabi [~quassel@176.4.83.34] has quit [Changing host]
20150930 22:07:37-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20150930 22:14:42-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Quit: tomreyn]
20150930 22:21:19-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20150930 22:28:36-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has joined #wesnoth-dev
20150930 22:35:40-!- irker340 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20150930 22:42:13-!- ancestral [~ancestral@71-220-62-196.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20150930 22:52:33-!- louis94 [~~louis94@109.129.205.202] has quit [Quit: Konversation terminated!]
20150930 23:12:49-!- travis-ci [~travis-ci@ec2-54-226-161-190.compute-1.amazonaws.com] has joined #wesnoth-dev
20150930 23:12:50< travis-ci> wesnoth/wesnoth#7546 (master - 9e24258 : Charles Dang): The build passed.
20150930 23:12:50< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/82994862
20150930 23:12:50-!- travis-ci [~travis-ci@ec2-54-226-161-190.compute-1.amazonaws.com] has left #wesnoth-dev []
20150930 23:39:18-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20150930 23:41:35-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds]
20150930 23:42:50-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20150930 23:42:50-!- wedge010 is now known as wedge009
20150930 23:53:30< gfgtdf> vultraz: you know how to get a unit defenses in lua? i dont want to use __cfg and unit_defense(u, string) only works for terrain_codes like 'Ww' not for strings like 'frozen'
--- Log closed Thu Oct 01 00:00:15 2015