--- Log opened Thu Jan 19 00:00:43 2012
20120119 00:00:44< anonymissimus> most importantly, the "current" in stuff referring to the info holding "to which side belongs this client" should be removed
20120119 00:01:08< anonymissimus> it can change, but only if a client owns 2+ sides
20120119 00:01:52< Crab_> yes, the meaning of 'current' is indeed confising
20120119 00:04:40< Crab_> night
20120119 00:04:44< anonymissimus> gabba: when debugging the select_unit tag I got the impressions that perhaps the giant bool expression in mouse_events.cpp:539 has to do with your bug
20120119 00:04:53-!- Crab_ [~Crab_@wesnoth/developer/crab] has quit [Quit: Do it for joy and you can do it forever]
20120119 00:05:44< anonymissimus> the basic problem is probably that a client usually isnt supposed to order any actions out-of-turn (but the wb allows it)
20120119 00:06:27< gabba> anonymissimus: I think I spotted a logic error in mouse_handler::current_unit_attacks_from, I'm currently taking it apart and heavily commenting it to make sense of it
20120119 00:06:38-!- Blueblaze [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20120119 00:07:13< gabba> anonymissimus: and yeah, you're spot on of course I had to modify a lot of the logic for out-of-turn planning, and I inevitably got confused by this mess of variables/getters
20120119 00:08:09-!- Exasperation [4a47319b@gateway/web/freenode/ip.74.71.49.155] has quit [Quit: Page closed]
20120119 00:11:32-!- mjs-de [~mjs-de@d185109.adsl.hansenet.de] has quit [Remote host closed the connection]
20120119 00:12:56-!- Blueblaze2 [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20120119 00:12:56-!- Blueblaze [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has quit [Read error: Connection reset by peer]
20120119 00:12:56-!- Blueblaze2 is now known as Blueblaze
20120119 00:13:16-!- Blueblaze [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has quit [Read error: Connection reset by peer]
20120119 00:13:20-!- Blueblaze2 [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20120119 00:13:40-!- Blueblaze2 [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has quit [Read error: Connection reset by peer]
20120119 00:13:43-!- Blueblaze [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20120119 00:14:04-!- Blueblaze2 [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20120119 00:14:04-!- Blueblaze [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has quit [Read error: Connection reset by peer]
20120119 00:14:04-!- Blueblaze2 is now known as Blueblaze
20120119 00:14:37-!- Blueblaze2 [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20120119 00:14:37-!- Blueblaze [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has quit [Read error: Connection reset by peer]
20120119 00:14:37-!- Blueblaze2 is now known as Blueblaze
20120119 00:24:45-!- horon [~horon@nttkyo324106.tkyo.nt.ngn2.ppp.infoweb.ne.jp] has joined #wesnoth-dev
20120119 00:25:37-!- Blueblaze2 [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20120119 00:25:42-!- Blueblaze2 [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has quit [Remote host closed the connection]
20120119 00:25:49-!- Blueblaze [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has quit [Read error: Connection reset by peer]
20120119 00:25:51-!- Blueblaze2 [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20120119 00:27:23-!- Blueblaze [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20120119 00:30:12< anonymissimus> shadowm: what save_index bugs other than bug #18683 and bug #19215 do you know of ?
20120119 00:30:26-!- Blueblaze2 [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has quit [Ping timeout: 272 seconds]
20120119 00:34:15-!- shadowm_laptop2 [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120119 00:35:01-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 276 seconds]
20120119 00:36:35< shadowm>  anonymissimus #18683 is hardly important; I believe it affects 1.8 too
20120119 00:37:44< shadowm> there's another symptom involving start-of-scenario saves being misrepresented when there's a cache at all
20120119 00:38:02< shadowm> (they are shown as replays, or as saves at "turn /"
20120119 00:39:44-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has quit [Ping timeout: 240 seconds]
20120119 00:40:39-!- stikonas_ is now known as stikonas
20120119 00:40:40< anonymissimus> bug #18683 is indeed present in 1.8 as well; but I recall seeing the sprite, so it was introduced in the 1.7 dev cycle probaböy
20120119 00:40:48-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has joined #wesnoth-dev
20120119 00:41:12< anonymissimus> looking at the code of extract_summary_from_config I wonder how it can ever have worked though
20120119 00:41:46< shadowm> some code related to saved games (not sure if that's one of the affected portions) was moved around during 1.9.x, I believe
20120119 00:44:36< anonymissimus> at I think I get what the save_index is for now, it skips re-parsing saves for getting the summary
20120119 00:44:40-!- Gambit [~gambit@wesnoth/developer/grickit] has quit [Remote host closed the connection]
20120119 00:46:47-!- shadowm_laptop2 [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 252 seconds]
20120119 00:49:48-!- wesbot changed the topic of #wesnoth-dev to: HARD string and feature-freeze active for trunk and the 1.10 announcment | 151 bugs, 334 feature requests, 15 patches | Logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20120119 01:00:46-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20120119 01:02:30< gabba> Ok, now I'm scared. Started a network game with server (manually started) and two clients, started a game without fog, and recruits I did on one client didn't show on the enemy client's screen.
20120119 01:03:11< gabba> not caused with what I'm currently working on, either, that's impossible
20120119 01:15:14< anonymissimus> was it with wb enabled ?
20120119 01:17:39< gabba> anonymissimus: did the recruit with wb disabled on one client, and yes wb was enabled by default on the other because of my settings
20120119 01:19:55< gabba> I can even reproduce it, this is really a wtf moment
20120119 01:21:36< anonymissimus> gabba: just to be sure to have the new lobby disabled
20120119 01:21:48< anonymissimus> with respect to your new report
20120119 01:22:11< gabba> anonymissimus: tis disabled
20120119 01:22:38< anonymissimus> then you should mention that in the report probably
20120119 01:23:26< gabba> anonymissimus: k, now I started the server from the game and not manually, and error doesn't reproduce
20120119 01:24:10< gabba> some things seem fishy when using the server standalone/under debugger, and/or connecting directly to it using the wesnoth --server command
20120119 01:24:28< gabba> Won't make a bug report until I can reproduce it again
20120119 01:26:21-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection]
20120119 01:40:19< CIA-45> gabba * r52654 /trunk/ (changelog players_changelog): Changelog entry
20120119 01:40:20< CIA-45> gabba * r52655 /trunk/src/play_controller.hpp: Comment a function
20120119 01:40:26< CIA-45> gabba * r52656 /trunk/ (changelog players_changelog src/mouse_events.cpp): 
20120119 01:40:26< CIA-45> Fix logic in mouse_handler::current_unit_attacks_from method, and heavily comment it.
20120119 01:40:26< CIA-45> Fixes bug #19142.
20120119 01:41:10< gabba> Ok, so that's a big bug fixed. See y'all tomorrow.
20120119 01:41:18< Espreon> Bye.
20120119 01:41:28-!- gabba [~gabba@wesnoth/developer/gabba] has left #wesnoth-dev []
20120119 01:50:43-!- Upth [~ogmar@108-85-91-228.lightspeed.frokca.sbcglobal.net] has joined #wesnoth-dev
20120119 01:50:43-!- Upth is now known as Upthorn
20120119 01:52:11-!- vultraz [~chatzilla@124.109.10.221] has quit [Ping timeout: 252 seconds]
20120119 02:00:42-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20120119 02:14:50-!- Gambit [~gambit@wesnoth/developer/grickit] has joined #wesnoth-dev
20120119 02:29:20-!- elias [~allefant@allegro/developer/allefant] has quit [Remote host closed the connection]
20120119 02:33:13-!- PetePorty [~quassel@unaffiliated/peterporty] has quit [Read error: Connection reset by peer]
20120119 02:33:37-!- elias [~allefant@allefant.com] has joined #wesnoth-dev
20120119 02:33:38-!- Pete-Flux [~quassel@unaffiliated/peterporty] has joined #wesnoth-dev
20120119 02:38:06-!- anonymissimus [~chatzilla@HSI-KBW-078-042-163-105.hsi3.kabel-badenwuerttemberg.de] has quit [Quit: done building targets]
20120119 02:54:33-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Quit: Computer has gone to sleep.]
20120119 03:17:43-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120119 03:18:54-!- Blueblaze [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has quit [Quit: Blueblaze]
20120119 03:24:43-!- crimson_penguin [~ben@S0106602ad06b8003.vc.shawcable.net] has joined #wesnoth-dev
20120119 03:24:43-!- crimson_penguin [~ben@S0106602ad06b8003.vc.shawcable.net] has quit [Changing host]
20120119 03:24:43-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20120119 03:28:22-!- un214 [~un214@adsl-75-45-4-106.dsl.scrm01.sbcglobal.net] has joined #wesnoth-dev
20120119 03:41:56-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 252 seconds]
20120119 03:44:03-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120119 04:13:39-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 244 seconds]
20120119 04:46:29-!- un214 [~un214@adsl-75-45-4-106.dsl.scrm01.sbcglobal.net] has quit [Remote host closed the connection]
20120119 04:49:08-!- Ivanovic_ [~ivanovic@dtmd-4db2c157.pool.mediaWays.net] has joined #wesnoth-dev
20120119 04:49:35-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120119 04:52:35-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 252 seconds]
20120119 04:53:05-!- Ivanovic_ is now known as Ivanovic
20120119 05:13:24-!- Blueblaze [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20120119 05:16:42-!- Upthorn [~ogmar@108-85-91-228.lightspeed.frokca.sbcglobal.net] has quit [Ping timeout: 272 seconds]
20120119 05:34:23-!- Elvish_Pillage2 [~eli@dhip-149.coburn.residences.colby.edu] has quit [Ping timeout: 252 seconds]
20120119 06:00:39-!- Upth [~ogmar@108-85-91-228.lightspeed.frokca.sbcglobal.net] has joined #wesnoth-dev
20120119 06:00:39-!- Upth is now known as Upthorn
20120119 06:05:35< janebot> Wesnoth Forums | Developers’ Discussions • Wesnoth on Desura.com! by Gambit [ 01-19-2012 04:40 ] [ http://r.wesnoth.org/p518942 ]
20120119 06:09:34-!- shikadibot [~shikadi@wesnoth/umc-dev/bot/shikadibot] has quit [Read error: Operation timed out]
20120119 06:11:17-!- AI0867 [~ai@wesnoth/developer/ai0867] has quit [Ping timeout: 248 seconds]
20120119 06:11:47-!- Espreon [~espreon@wesnoth/developer/espreon] has quit [Ping timeout: 260 seconds]
20120119 06:11:49-!- shadowm [~ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 245 seconds]
20120119 06:15:59< janebot> Wesnoth Forums | Developers’ Discussions • Re: Wesnoth on Desura.com! by PeterPorty [ 01-19-2012 05:13 ] [ http://r.wesnoth.org/p518944 ]
20120119 06:16:12< Gambit> eh
20120119 06:16:51< Gambit> janebot: !unsubscribe Wesnoth2
20120119 06:16:51< janebot> Gambit: Subscription removed.
20120119 06:17:09< Gambit> Until this potential spamfest goes away.
20120119 06:17:23< ancestral> Your post also showed up in #wesnoth-music
20120119 06:17:33< ancestral> :)
20120119 06:18:04< Gambit> I abused my power and made the thread a global announcement. >:]
20120119 06:18:08< Gambit> Perhaps I should undo that.
20120119 06:18:20-!- shikadibot [~shikadi@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev
20120119 06:18:22 * ancestral shrugs
20120119 06:18:34< Gambit> janebot: !subscribe Wesnoth2
20120119 06:18:34< janebot> Gambit: Subscription added.
20120119 06:18:42< ancestral> What would Shadowmaster think?
20120119 06:18:44-!- Espreon [~espreon@ai0867.net] has joined #wesnoth-dev
20120119 06:18:56< shadowm_laptop> ancestral: I would think...
20120119 06:18:58-!- shadowm [~ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120119 06:19:02< Gambit> Well I got his permission
20120119 06:19:02< shadowm_laptop> 02:04:35 <Gambit> shadowm: permission to promote testers call to global announcement?
20120119 06:19:07< Gambit> hehe
20120119 06:19:07< shadowm_laptop> 02:05:12 <shadowm> Gambit: yes
20120119 06:19:10-!- Espreon is now known as Guest96938
20120119 06:19:20< shadowm_laptop> after much deliberation with my peers
20120119 06:19:26< Gambit> (i.e. flipping a coin)
20120119 06:19:31< shadowm_laptop> Gambit: three coins
20120119 06:19:41< Gambit> How democratic.
20120119 06:19:59< ancestral> Gambit: I was hoping you were going to say "I can make decisions on my own!"
20120119 06:20:09< ancestral> But it looks like you still report to Shadowmaster :-P
20120119 06:20:14< Gambit> For now!
20120119 06:20:18-!- AI0867 [~ai@wesnoth/developer/ai0867] has joined #wesnoth-dev
20120119 06:20:32< Gambit> [insert evil laugh]
20120119 06:20:35< shadowm_laptop> 01:21:39 <Gambit> Wonder what the best way to call for desura testers is
20120119 06:20:35< shadowm_laptop> 01:21:55 <shadowm> Gambit: forums
20120119 06:20:41< shadowm_laptop> 01:23:03 <shadowm> Users'.
20120119 06:20:50< Samual> Gambit: Oh, so you guys finally got Wesnoth on Desura?
20120119 06:21:02< Gambit> Samual: Probably.
20120119 06:21:04< ancestral> Somebody hasn't read the forum post
20120119 06:22:10< Samual> ancestral: He contacted my development team earlier about setting it up, and no I didn't read it yet :P
20120119 06:22:24< ancestral> Ahhh
20120119 06:22:29< ancestral> The plot thickens!
20120119 06:22:32< Samual> just saw people complaining about announcement and read the announcement quickly
20120119 06:22:35< Samual> :P
20120119 06:22:39< Samual> hehe
20120119 06:22:54< shadowm> Desura discriminates against centennial elders.
20120119 06:23:07< Samual> Anyway, I can test it out on Windows 7 64bit for you Gambit
20120119 06:23:12< shadowm> I cannot select a birth year earlier than 1912.
20120119 06:23:18< Samual> and Arch Linux when I become not lazy
20120119 06:23:19< Gambit> shadowm: Crotchety old man
20120119 06:23:34< Samual> BTW
20120119 06:23:46< Samual> usually Desura tries out the builds before allowing them to be published
20120119 06:23:47< shadowm> Gambit: when I was your age, people looked upon us with respect.
20120119 06:23:48< ancestral> shadowm: When I first saw Desura I got it confused with "drosera" and "desunda"
20120119 06:23:52< ancestral> *desnuda
20120119 06:23:57< Samual> so, the hooks you added SHOULD already work just fine
20120119 06:24:05< shadowm> now that's an unfortunate similarity
20120119 06:24:38< Gambit> Samual: Well after an unfortunate accidental early release we got reports of it not working on ubuntu 10.04
20120119 06:24:46< Gambit> And they didn't test the windows version
20120119 06:24:55< Samual> ouch
20120119 06:25:02< Samual> but, that's weird
20120119 06:25:18< Gambit> But the early release was known to be broken anyway. I'm hoping everything is fine now.
20120119 06:25:55< Gambit> Someone from Desura uploaded 1.8.6 as an example, and then someone else saw it and revealed us to the public D:
20120119 06:26:07< Gambit> Fun times.
20120119 06:26:39< Samual> I would literally murder the person who did that
20120119 06:26:51< Samual> :D
20120119 06:26:57< Gambit> Eh it was only 36 downloads :<
20120119 06:27:02< Samual> oh
20120119 06:27:07< Gambit> "only"
20120119 06:27:07< ancestral> Now now, murdering is like SOPA for human lives
20120119 06:27:30< ancestral> (Alright, I'm getting off-topic, forgive me)
20120119 06:27:37< Gambit> Anyway I'm going to go to sleep and hopefully I'll have some invite to send out in the morning.
20120119 06:28:15< Gambit> *Invites plural even. If I'm really lucky.
20120119 06:28:18< Gambit> Hehe
20120119 06:28:26< Samual> Releasing stably and cleanly is really important, undermining that completely ruins the whole release imo -- like, Nexuiz 2.5 -- it had a major bug with the water, so 3 days later we had to release 2.5.1
20120119 06:28:36< Samual> goodnight mate ^_^
20120119 06:29:15< Samual> but anyway, that whole situation with the water bug just made the development team look like a joke :P
20120119 06:29:29< Gambit> Oh fishsticks. They didn't authorize Windows without testing.
20120119 06:29:33< Samual> "HOW DID YOU NOT NOTICE THAT WATER IS PURE WHITE, AND SPAMS THE CONSOLE WITH ERRORS?"
20120119 06:29:42< Samual> etc.
20120119 06:29:47-!- vultraz [~chatzilla@124.109.10.221] has joined #wesnoth-dev
20120119 06:45:25-!- Exasperation [4a47319b@gateway/web/freenode/ip.74.71.49.155] has joined #wesnoth-dev
20120119 06:49:48-!- wesbot changed the topic of #wesnoth-dev to: HARD string and feature-freeze active for trunk and the 1.10 announcment | 150 bugs, 334 feature requests, 15 patches | Logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20120119 07:06:40-!- Gambit [~gambit@wesnoth/developer/grickit] has quit [Quit: bah it's tomorrow]
20120119 07:30:57-!- Blueblaze [~Blueblaze@adsl-99-4-146-126.dsl.hstntx.sbcglobal.net] has quit [Quit: Blueblaze]
20120119 08:11:56-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit []
20120119 08:12:34-!- Drakefriend [~kvirc@31-19-75-43-dynip.superkabel.de] has joined #wesnoth-dev
20120119 08:17:30-!- timotei [~timotei@188.24.4.60] has joined #wesnoth-dev
20120119 08:17:31-!- timotei [~timotei@188.24.4.60] has quit [Changing host]
20120119 08:17:31-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20120119 08:28:38< vultraz> Exasperation: humm...still can't get set_dialog_value to work in that way, does that mean it needs a special case?
20120119 08:29:56< vultraz> case for labels*
20120119 08:48:58-!- EdB [~edb@tss37-1-89-82-194-231.dsl.sta.abo.bbox.fr] has joined #wesnoth-dev
20120119 08:50:07< vultraz> Exasperation: ?
20120119 08:50:38< Exasperation> sorry, was paying attention to something else
20120119 08:51:00< Exasperation> what's the code you've got now?
20120119 08:51:01< vultraz> ahhh no problem
20120119 08:51:27< vultraz> at my end or the game's end
20120119 08:51:41< Exasperation> the changes you made to set_dialog_value
20120119 08:52:15< vultraz> haven't been able to think what to do ;)
20120119 08:52:40< vultraz> I'm wondering if it needs a custom if block for labels
20120119 08:52:48< Exasperation> yeah, it does
20120119 08:52:58< Exasperation> I thought you had written one, though
20120119 08:53:25< vultraz> ahh
20120119 08:53:28< vultraz> ok I'll get at it
20120119 08:56:03< Exasperation> wait, you're talking about set_dialog_value, I thought you said get_dialog_value for some reason
20120119 08:57:01< Exasperation> you can already use set_dialog_value on label widgets, but it doesn't resize them, so the new text (or image) can't be larger than the old one
20120119 08:57:33< Exasperation> that's why I was saying to initialize them with whitespace in the forum thread
20120119 08:59:44< Exasperation> here's the testcase I was using http://pastebin.com/V5QLw0Li
20120119 09:00:00< Exasperation> (ought to look familiar) ;-)
20120119 09:01:09< Exasperation> vultraz ^
20120119 09:01:33< vultraz> looking
20120119 09:01:49< vultraz> rofl!
20120119 09:01:50< vultraz> XD
20120119 09:02:21< Exasperation> that was working for me
20120119 09:02:24< vultraz> but set_dialog_value should auto-resize w/o needing whitespace
20120119 09:02:43< Exasperation> ideally, yes it should
20120119 09:03:49< Exasperation> and somewhere, there's probably a c++ function that could be added to the fallback case to make it re-evaluate the size the widget needs to be, but I don't know what it is
20120119 09:07:17< vultraz> so just to be clear, the widget needs expanding, not the label
20120119 09:08:06-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20120119 09:08:09< Exasperation> yes
20120119 09:08:25< Exasperation> although in this case it's a widget of class tlabel
20120119 09:11:39< vultraz> and it would be written as a if block?
20120119 09:11:45< vultraz> (the solution)
20120119 09:12:10< vultraz> if block with a fallback for labels*
20120119 09:13:33< Exasperation> no, the if block is already there in this instance
20120119 09:14:38< Exasperation> here's something: try replacing the [label]s in question with [scroll_label]s
20120119 09:14:58< Exasperation> they might be able to handle resizing more gracefully already
20120119 09:16:15< vultraz> trying
20120119 09:17:36< vultraz> O.O
20120119 09:17:42< vultraz> it...works!
20120119 09:18:28< Exasperation> hooray
20120119 09:19:00< vultraz> :D :D :D
20120119 09:19:25< Exasperation> it looks like scrollbar containers (listboxes, etc.) automatically make a resizing request when their contents change, while other widgets don't
20120119 09:19:34< vultraz> interesting...
20120119 09:21:43< vultraz> now all I have to do is see if my get_dialog_value patch works :) 
20120119 09:22:10< vultraz> unfortunately the xcode download restarted 
20120119 09:22:17< Exasperation> I think it should.  And if not, it should be very close to working.
20120119 09:22:22< Exasperation> :-(
20120119 09:23:24< vultraz> now to make this dialog look nice :D
20120119 09:23:55 * vultraz heads to his lua files
20120119 09:24:10< Exasperation> one of the harder parts of UI work
20120119 09:25:05< Exasperation> I'm off for the night
20120119 09:25:18< Exasperation> good luck
20120119 09:25:35-!- Exasperation [4a47319b@gateway/web/freenode/ip.74.71.49.155] has quit [Quit: Page closed]
20120119 09:52:56-!- timotei21 [~timotei@188.24.4.60] has joined #wesnoth-dev
20120119 09:52:56-!- timotei21 [~timotei@188.24.4.60] has quit [Changing host]
20120119 09:52:56-!- timotei21 [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20120119 09:56:03-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 252 seconds]
20120119 10:05:20-!- Pete-Flux [~quassel@unaffiliated/peterporty] has quit [Read error: Connection reset by peer]
20120119 10:09:43-!- Ivanovic [~ivanovic@dtmd-4db2c157.pool.mediaWays.net] has quit [Changing host]
20120119 10:09:43-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20120119 10:10:54< Ivanovic> moin
20120119 10:13:37-!- stikonas [~gentoo@bcm-131-111-216-70.girton.cam.ac.uk] has joined #wesnoth-dev
20120119 10:13:37-!- stikonas [~gentoo@bcm-131-111-216-70.girton.cam.ac.uk] has quit [Changing host]
20120119 10:13:37-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120119 10:31:02-!- ancestral [~ancestral@67-6-35-100.mpls.qwest.net] has quit [Quit: And that’s the end of THAT chapter.]
20120119 10:33:58-!- timotei21 is now known as timotei
20120119 10:51:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20120119 11:13:57-!- vultraz [~chatzilla@124.109.10.221] has quit [Remote host closed the connection]
20120119 11:39:39-!- Crab____ [Crab____@nat/google/x-prsmzqihbjjypooj] has joined #wesnoth-dev
20120119 11:51:42-!- Crab____ [Crab____@nat/google/x-prsmzqihbjjypooj] has quit [Remote host closed the connection]
20120119 11:52:08-!- EdB [~edb@tss37-1-89-82-194-231.dsl.sta.abo.bbox.fr] has quit [Quit: Konversation terminated!]
20120119 11:56:47-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20120119 12:10:58-!- vcap_ [~vcap@AReims-551-1-135-51.w90-18.abo.wanadoo.fr] has quit [Quit: leaving]
20120119 12:21:43-!- vcap [~vcap@AReims-551-1-135-51.w90-18.abo.wanadoo.fr] has joined #wesnoth-dev
20120119 12:22:15-!- loonybot [~loonybot@ppp109-252-60-124.pppoe.spdop.ru] has joined #wesnoth-dev
20120119 12:22:15-!- loonybot [~loonybot@ppp109-252-60-124.pppoe.spdop.ru] has quit [Changing host]
20120119 12:22:15-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-dev
20120119 12:31:42-!- mjs-de [~mjs-de@g224178107.adsl.alicedsl.de] has joined #wesnoth-dev
20120119 12:47:27-!- Drakefriend [~kvirc@31-19-75-43-dynip.superkabel.de] has quit [Quit: I quit for now. Goodbye.]
20120119 13:44:13-!- Gambit [~gambit@wesnoth/developer/grickit] has joined #wesnoth-dev
20120119 13:44:46-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has quit [Ping timeout: 276 seconds]
20120119 13:48:42-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has joined #wesnoth-dev
20120119 13:56:07-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has quit [Ping timeout: 260 seconds]
20120119 14:16:14-!- Johannes13 [~Johannes@unaffiliated/johannes13] has joined #wesnoth-dev
20120119 14:25:13-!- stikonas [~gentoo@bcm-131-111-216-70.girton.cam.ac.uk] has joined #wesnoth-dev
20120119 14:25:13-!- stikonas [~gentoo@bcm-131-111-216-70.girton.cam.ac.uk] has quit [Changing host]
20120119 14:25:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120119 14:27:25-!- Crendgrim [~crend@77-22-114-250-dynip.superkabel.de] has joined #wesnoth-dev
20120119 14:45:18< CIA-45> ivanovic * r52657 /trunk/ (4 files in 3 dirs): updated Chinese (Simplified) and Hungarian translation
20120119 14:52:31-!- negusnyul [~negusnyul@dsl4E5CDBD4.pool.t-online.hu] has joined #wesnoth-dev
20120119 14:53:29-!- Elvish_Pillage2 [~eli@dhip-149.coburn.residences.colby.edu] has joined #wesnoth-dev
20120119 14:55:49-!- MeccaGod [~majs@host189-199.bornet.net] has joined #wesnoth-dev
20120119 15:03:27-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has joined #wesnoth-dev
20120119 15:04:21-!- vultraz [~chatzilla@124.109.10.221] has joined #wesnoth-dev
20120119 15:07:03-!- Crab____ [Crab____@nat/google/x-hagwfbeebsfxqxuj] has joined #wesnoth-dev
20120119 15:08:03< Crab____> Ivanovic: any further unhandled blockers for 1.10 that are worth looking at?
20120119 15:08:24< Ivanovic> Crab____: gabba mentioned one thing for the whiteboard he still wants to look at
20120119 15:08:38< Ivanovic> though i don't know if there is anything else requiring attention
20120119 15:09:05< Ivanovic> maybe you could try this one? https://gna.org/bugs/index.php?19302
20120119 15:09:28< Ivanovic> zookeeper: can you look at fixing this one? https://gna.org/bugs/index.php?19303
20120119 15:09:34-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has quit [Ping timeout: 252 seconds]
20120119 15:10:24< Ivanovic> this one looks like an interesting (non blocking) bug, too: https://gna.org/bugs/index.php?19258
20120119 15:11:52< Ivanovic> maybe also check this report including a patch: https://gna.org/bugs/?19055
20120119 15:12:46< Ivanovic> this one sounds like a rather low hanging but possibly important fruit, too: https://gna.org/bugs/?18693
20120119 15:12:56-!- horon [~horon@nttkyo324106.tkyo.nt.ngn2.ppp.infoweb.ne.jp] has quit [Quit: Leaving...]
20120119 15:13:28< Ivanovic> not sure about this one... https://gna.org/bugs/?18591
20120119 15:13:49< Ivanovic> (yes, i just went through the list of open bugs marked "important")
20120119 15:14:50< vultraz> Ivanovic: does what I'm working on - making get_dialog_value read from label and image widgets - count as a bugfix?
20120119 15:15:18< Ivanovic> i don't think so
20120119 15:15:29< Ivanovic> sounds clearly like a feature addition to me
20120119 15:16:02< vultraz> mk
20120119 15:18:01< Crab____> zookeeper, Ivanovic: ok, thanks, I'll take a look at them today.
20120119 15:21:16-!- vultraz [~chatzilla@124.109.10.221] has quit [Quit: must.free.bandwith]
20120119 15:43:25-!- Alarantalara [~Adium@CPEc0c1c09e8055-CM00252eac6d62.cpe.net.cable.rogers.com] has joined #wesnoth-dev
20120119 15:43:51< Alarantalara> Ivanovic: https://gna.org/bugs/index.php?19232
20120119 15:44:45< Ivanovic> Alarantalara: uhm, okay, good to know
20120119 15:44:53< Alarantalara> I'm not sure if this should be considered a blocker.
20120119 15:44:54< Ivanovic> so lately sdl is a real issue for osx users
20120119 15:45:04< Ivanovic> there is no way for me/us to fix this, right?
20120119 15:45:09< Ivanovic> so how can it be a blocker for us?
20120119 15:45:17< Ivanovic> what would probably work is offer two binaries
20120119 15:45:31< Ivanovic> one for osx .7+ and one for before
20120119 15:46:05< Alarantalara> The described problem happens in .7 as well (there's a forum post)
20120119 15:46:29< Alarantalara> And with enough playing around with resolution changes, I can get the earlier versions of SDL to crash on resultion changes
20120119 15:47:08< Alarantalara> when it's not 10.7
20120119 15:47:17< Ivanovic> i'd say: contact the libsdl devs about this
20120119 15:47:23< Ivanovic> no other way to handle it, really
20120119 15:49:31< Alarantalara> I suppose so.
20120119 15:52:50< timotei> Alarantalara: what about disabling full screen
20120119 15:52:52< timotei> on mac builds?
20120119 15:52:58< timotei> That would be better till SDL fixes that
20120119 15:53:15< Ivanovic> sounds like an option, too
20120119 15:53:26< Alarantalara> the problem isn't full screen
20120119 15:53:31< timotei> IDK exactly how does Lion check for full screen support
20120119 15:53:46< timotei> Oh? well, the bug is about the Full Screen, isn't it?
20120119 15:53:55< Alarantalara> Lion switches to full screen if you create a window the size of the screen
20120119 15:54:11< timotei> hmm
20120119 15:54:14< Alarantalara> The bug mentioned here appears on change from one to another
20120119 15:54:35-!- Drakefriend [~kvirc@31-19-75-43-dynip.superkabel.de] has joined #wesnoth-dev
20120119 15:54:41< Ivanovic> Alarantalara: so if there is no support for one of the two, there is no switch
20120119 15:54:43< Ivanovic> ;)
20120119 15:55:28< timotei> Alarantalara: the size of the screen meaning the entire resolution? Or all the space between the dock and the upper "menu"?
20120119 15:55:42< Alarantalara> the entire resoltuion
20120119 15:55:53< Alarantalara> *resolution
20120119 15:56:14< timotei> and by default wesnoth creates a window the size of the screen?
20120119 15:56:19< Alarantalara> but I now have it occuring outside of full screen without having ever entered it
20120119 15:56:27< timotei> Ah
20120119 15:56:58< Alarantalara> and resizing the window immediately solves the problem
20120119 15:58:13< timotei> resizing to a particular size? or a random one
20120119 15:58:22< Alarantalara> any size
20120119 15:58:48< Alarantalara> ooh, now my mouse cursor is broken
20120119 15:58:52< timotei> xD
20120119 15:59:09< Alarantalara> even with wesnoth not running :(
20120119 16:00:57< Alarantalara> ah, an easy way to recreate without going into full screen: set window size = screen resolution, restart Wesnoth
20120119 16:01:53< Alarantalara> Is it possible to disable that window size in Wesnoth if not full screen?
20120119 16:02:48< timotei> well
20120119 16:02:55< timotei> we could set the window size = screen resolution - 1
20120119 16:02:55< timotei> :)
20120119 16:03:16< timotei> Or well, a threshold minimal than the one Lion uses to give the bug
20120119 16:05:21< timotei> when doing a resize
20120119 16:05:26< Alarantalara> It looks like it has to be a size that allows the menu bar to be drawn
20120119 16:05:27< timotei> events.cpp :321
20120119 16:06:13< Alarantalara> On restart, the window is sized to fit the viewable area of the screen, while wesnoth thinks that the window is the same size as before
20120119 16:13:55-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Read error: Connection reset by peer]
20120119 16:27:23-!- Alarantalara [~Adium@CPEc0c1c09e8055-CM00252eac6d62.cpe.net.cable.rogers.com] has quit [Quit: Leaving.]
20120119 16:42:24-!- Pete-Flux [~quassel@unaffiliated/peterporty] has joined #wesnoth-dev
20120119 16:42:46< fendrin> hi Crab____
20120119 16:42:52< Crab____> hi
20120119 16:43:06< fendrin> Crab____: What kind of testcase do you need for the recruit bug fix?
20120119 16:43:28< Crab____> one which has incorrect behavior now but would have correct behavior after our fix
20120119 16:43:40< fendrin> Crab____: I thought about enhancing the test scenario that starts with wesnoth -t.
20120119 16:45:28< Crab____> I would just take an existing scenario/campaign which has 2+ enemies and join two enemy sides into 1
20120119 16:45:38< Crab____> but, any approach would work
20120119 16:52:20< CIA-45> fendrin * r52658 /trunk/data/scenario-test.cfg: Added a testcase for mulitple leaders per side, showing that the ai is not recruiting, even with a global recruit list.
20120119 16:52:26< fendrin> Crab____: ^ That was very easy. 
20120119 16:54:09-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has joined #wesnoth-dev
20120119 17:02:08< fendrin> Crab____: Another thing is, why doesn't the old leader of side2 in the testscenario try to reach a castle in order to recruit. I need to test if he did it before when he was the only leader on his side. I would consider it a bug if he doesn't move.
20120119 17:03:37< Crab____> fendrin: I can check. or you can check (run with logging for move_leader_to_keep phase enabled, to see if it's evaluated)
20120119 17:03:43< Crab____> fendrin: it's probably easier for me to check.
20120119 17:07:18-!- Upthorn [~ogmar@108-85-91-228.lightspeed.frokca.sbcglobal.net] has quit [Ping timeout: 272 seconds]
20120119 17:07:56-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has quit [Ping timeout: 255 seconds]
20120119 17:11:32-!- mjs-de [~mjs-de@g224178107.adsl.alicedsl.de] has quit [Remote host closed the connection]
20120119 17:14:51< fendrin> Crab____: Yes, I am not very firm when it comes to debugging the ai.
20120119 18:05:09-!- knotwork [~markm@unaffiliated/knotwork] has quit [Remote host closed the connection]
20120119 18:14:59-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Quit: Computer has gone to sleep.]
20120119 18:26:56-!- {V} [~V@174-76-ftth.onsneteindhoven.nl] has quit [Ping timeout: 240 seconds]
20120119 18:27:42-!- {V} [~V@174-76-ftth.onsneteindhoven.nl] has joined #wesnoth-dev
20120119 18:32:56-!- {V} [~V@174-76-ftth.onsneteindhoven.nl] has quit [Ping timeout: 240 seconds]
20120119 18:33:25-!- {V} [~V@174-76-ftth.onsneteindhoven.nl] has joined #wesnoth-dev
20120119 18:49:48-!- wesbot changed the topic of #wesnoth-dev to: HARD string and feature-freeze active for trunk and the 1.10 announcment | 149 bugs, 334 feature requests, 15 patches | Logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20120119 18:56:09-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20120119 18:56:57-!- anonymissimus [~chatzilla@HSI-KBW-078-042-163-105.hsi3.kabel-badenwuerttemberg.de] has joined #wesnoth-dev
20120119 18:57:14-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20120119 18:58:38< CIA-45> anonymissimus * r52659 /trunk/data/tools/wmllint: 
20120119 18:58:39< CIA-45> Make wmllint ignore embedded lua. There's no bug report for this.
20120119 18:58:39< CIA-45> Apparently it didn't already, it just didn't break so far, but the lua
20120119 18:58:39< CIA-45> I added in Hornshark let it choke.
20120119 18:58:39< CIA-45> wmllint ignores lines with << until a line with >> now (start and
20120119 18:58:39< CIA-45> end lines included).
20120119 18:58:40< CIA-45> esr: have a look pls
20120119 18:59:04< CIA-45> anonymissimus * r52660 /trunk/changelog: changelog update
20120119 18:59:43< anonymissimus> yes, http://gna.org/bugs/index.php?19258 appears important to me
20120119 19:00:06< anonymissimus> unfortunately ST has problems providing minimized test cases...
20120119 19:00:54< anonymissimus> about that debug mode bug, if it was for me it would have been closed since long
20120119 19:00:59< anonymissimus> same for Soliton
20120119 19:01:34< anonymissimus> its just Gambit some probably competitive-MP minded guys who think this is important
20120119 19:01:58< anonymissimus> and not that the "bug" is hald-present in 1.8 already
20120119 19:02:39< anonymissimus> but none of the people who have interest in "fixing" it are willing or able to make the fix, so since it cannot realistically be dealt with it should be closed
20120119 19:03:40< Gambit> Hm?
20120119 19:03:51< chrisoelmueller> that doesn't sound like sane reasoning.
20120119 19:04:03< Crab____> well, it's rather easy to fix it it by sending a message if a debug mode is enabled
20120119 19:04:10< Crab____> just send a msg on player's behalf
20120119 19:04:16< Crab____> all other clients already know how to handle it
20120119 19:04:16< anonymissimus> chrisoelmueller: please provide a patch doing the job
20120119 19:04:36< Crab____> it can be spoofed this way, but there's not point in spoofing it
20120119 19:04:49-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has joined #wesnoth-dev
20120119 19:04:55< Crab____> but it's not a real 'bug' to me
20120119 19:05:04< Crab____> it's more like a feature request
20120119 19:05:38-!- knotwork [~markm@142.177.233.157] has joined #wesnoth-dev
20120119 19:05:38-!- knotwork [~markm@142.177.233.157] has quit [Changing host]
20120119 19:05:38-!- knotwork [~markm@unaffiliated/knotwork] has joined #wesnoth-dev
20120119 19:06:31< Gambit> My plan is to make the client send a different version string when debug mode is enabled, and the official server won't let them on
20120119 19:06:44< Crab____> Gambit: don't do that, please
20120119 19:07:14< Crab____> Gambit: there are situations where it's worth connecting to the official server with debug mode, at least it was the case in the past.
20120119 19:07:38< Crab____> Gambit: just make a client send this as a message to other players
20120119 19:08:03< Gambit> People can use a private server for testing.
20120119 19:08:20< Crab____> yes, but it has different latency properties
20120119 19:08:31< Crab____> sometimes it can be important
20120119 19:08:47< Gambit> And to fix it that way would require a new string and probably the code required is over my head
20120119 19:08:51< timotei> Gambit: can't people bypass that anyway? :P
20120119 19:09:01< Gambit> timotei: They can bypass anything
20120119 19:09:03< timotei> Gambit: the string sending stuff?
20120119 19:09:04< Gambit> But it's much harder
20120119 19:09:41< Crab____> also note that --log-debug also allows quite a lot of cheating, and is on the same order of complexity :)
20120119 19:10:15< Gambit> Having to modify the source is preferable to any random Windows user editing a shortcut and having access to the inspect dialog
20120119 19:10:31< Gambit> Ideally yes it would alert everyone as it does for multiple clients with the same IP
20120119 19:10:40< Gambit> And then the host can decide whether or not to kick the person
20120119 19:10:49< Gambit> But I can't do  that fix.
20120119 19:10:56< Crab____> i.e. it's super-easy to know enemy recruits if you enable the necessary log domains via --log-debug
20120119 19:11:05< timotei> Gambit: then, why not just alert the host that they are using debug mode
20120119 19:11:24< timotei> Gambit: instead of forbidding them to join?
20120119 19:11:35< anonymissimus> Crab____: this is something for you to look at: https://gna.org/bugs/index.php?19086
20120119 19:11:54< anonymissimus> you can leave that UtbS bug for Esperon or so
20120119 19:12:35< Crab____> anonymissimus: lua ai would be cleaned up in the next release cycle (
20120119 19:13:42-!- Crab____ [Crab____@nat/google/x-hagwfbeebsfxqxuj] has quit [Quit: Crab____]
20120119 19:15:06< anonymissimus> it is certainly not worth sacrifing a great easy in debugging for a futile attempt to prevent cheating IMHO
20120119 19:15:23< anonymissimus> ease
20120119 19:16:53-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has quit [Ping timeout: 248 seconds]
20120119 19:21:10-!- lipk [~lipka_bol@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20120119 19:26:58< anonymissimus> Ivanovic: btw developers being bored by bugfixing is not an argument for thawing the feature freeze IMHO
20120119 19:27:17< Ivanovic> huh?
20120119 19:27:32< Ivanovic> the feature freeze is not gone before 1.10 is branched off
20120119 19:27:40-!- Samual [gitkf-e@c-71-195-88-69.hsd1.pa.comcast.net] has quit [Read error: Connection reset by peer]
20120119 19:28:39-!- Samual [gitkf-e@c-71-195-88-69.hsd1.pa.comcast.net] has joined #wesnoth-dev
20120119 19:30:40-!- Ivanovic changed the topic of #wesnoth-dev to: commit what you want in 1.10 until Saturday, January 21st, 23:59 GMT+1 | HARD string and feature-freeze active for trunk and the 1.10 announcment | 149 bugs, 334 feature requests, 15 patches | Logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20120119 19:32:48-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120119 19:35:03-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Read error: Connection reset by peer]
20120119 19:35:27-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20120119 19:42:41< CIA-45> ivanovic * r52661 /trunk/po/ (9 files in 8 dirs): updated Czech and Italian translation
20120119 19:51:03-!- lipk [~lipka_bol@host-91-147-212-174.biatv.hu] has left #wesnoth-dev []
20120119 19:51:36< Rhonda> WTF "linger mode"?
20120119 19:52:38< Ivanovic> linger mode is what you enter after a scenario is completed and before you hit "end scenario"
20120119 19:52:53< Ivanovic> there you can still save a replay, view how your units ended up, ...
20120119 19:54:49< Rhonda> "Abklingmodus"?
20120119 19:55:14< Ivanovic> hmm, could work though this sounds very artifical
20120119 19:57:30< anonymissimus> "Verweilstatus" ?
20120119 19:58:23< anonymissimus> where was that string added btw, linger mode exists since 1.3 or so
20120119 19:58:37< Rhonda> tutorial
20120119 19:58:53< Rhonda> #. [message]: speaker=narrator
20120119 19:58:53< Rhonda> #: data/campaigns/tutorial/scenarios/1_Tutorial.cfg:1177
20120119 20:02:29-!- Crab___ [~Crab_@nat4-10.ghnet.pl] has joined #wesnoth-dev
20120119 20:02:31-!- Crab___ [~Crab_@nat4-10.ghnet.pl] has quit [Changing host]
20120119 20:02:31-!- Crab___ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20120119 20:02:43-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has joined #wesnoth-dev
20120119 20:14:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20120119 20:17:15-!- stikonas [~and@bcm-131-111-216-70.girton.cam.ac.uk] has joined #wesnoth-dev
20120119 20:17:16-!- stikonas [~and@bcm-131-111-216-70.girton.cam.ac.uk] has quit [Changing host]
20120119 20:17:16-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120119 20:24:35-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has quit [Ping timeout: 255 seconds]
20120119 20:33:08-!- mordante [~mordante@roadie.xs4all.nl] has joined #wesnoth-dev
20120119 20:33:08-!- mordante [~mordante@roadie.xs4all.nl] has quit [Changing host]
20120119 20:33:08-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20120119 20:33:21< mordante> servus
20120119 20:35:14-!- Johannes13 [~Johannes@unaffiliated/johannes13] has quit [Ping timeout: 252 seconds]
20120119 20:40:12< CIA-45> ivanovic * r52662 /trunk/po/ (wesnoth-manual/de.po wesnoth-tutorial/de.po): updated German translation
20120119 20:43:20-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has joined #wesnoth-dev
20120119 20:43:42< anonymissimus> mordante: hi, if https://gna.org/bugs/?19165 isn't something that needs to be postponed, would be nice it you could fix it someway until the last 1.10 release
20120119 20:43:58-!- Guest96938 is now known as Espreon
20120119 20:44:00< anonymissimus> (siince it affects my addon, hrhr)
20120119 20:44:04-!- Espreon [~espreon@ai0867.net] has quit [Changing host]
20120119 20:44:04-!- Espreon [~espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20120119 20:46:30< anonymissimus> mordante: in https://gna.org/bugs/?19283 I have tracked down the cause sufficiently until an easy how-to-reproduce, it is perhaps also a duplicate of other :inspect crashes
20120119 20:48:54-!- Drakefriend [~kvirc@31-19-75-43-dynip.superkabel.de] has quit [Quit: I quit for now. Goodbye.]
20120119 21:08:20-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit []
20120119 21:17:29< Crab___> ok, a question about bug https://gna.org/bugs/index.php?19303
20120119 21:17:45-!- vultraz [~chatzilla@124.109.10.221] has joined #wesnoth-dev
20120119 21:18:23< Crab___> a unit is spawned in the cave wall. this happens because the scenario instructed a unit to spawn inside a cave wall. But, even if the scenario is fixed to place a unit next to a cave wall, it still can happen that the unit is placed in a cave.
20120119 21:18:31< Crab___> (that can happen if his hex is occupied)
20120119 21:18:58< Crab___> a proper solution is to use 'placement=map_passable' in the unit's description, then, when finding a vacant hex for him, passability would be considered, as well.
20120119 21:19:01< Ivanovic> yes, things like this can happen
20120119 21:19:39< vultraz> it was happening in NR 05
20120119 21:19:44-!- zookeeper2 [~lmsnie@87-100-211-108.bb.dnainternet.fi] has joined #wesnoth-dev
20120119 21:19:45< vultraz> until Espreon fixed it
20120119 21:19:46-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Read error: Connection reset by peer]
20120119 21:19:50< vultraz> naga spawned in the cave
20120119 21:19:52< vultraz> wall
20120119 21:20:03< Crab___> vultraz: it's not fully fixed
20120119 21:20:19< Crab___> the question is: when I coded placement=map_passability, was there a specific reason we didn't change the default from placement=map,recall to map_passable,recall  ?
20120119 21:20:54< Crab___> (it shouldn't be changed now due to backward compatibility, but, still, it's interesting)
20120119 21:21:37< Crab___> i.e., as I understand, the number of cases where author wants to spawn the unit inside a wall should be less than the number of places where accidental spawnings can happen..
20120119 21:21:52< Crab___> s/map_passability/map_passable
20120119 21:22:29< Crab___> and, a second (rhetorical) question, why I hadn't bothered to document it? :))
20120119 21:22:46< vultraz> true....if you wanted the unit in teh wall why not just say so
20120119 21:23:01< vultraz> instead of it happening as default
20120119 21:23:43< vultraz> then you have to specifically say NOT to spawn in the wall for all the others, which means a lot more placement= 
20120119 21:24:43< Crab___> yes, that's what I'm wondering about - as to fix this bug now and fully, it is required to place placement=map_passable to all units which are spawned mid-battle near walls.
20120119 21:25:14< Crab___> of course, it's possible to just fix the offending dwarf to not spawn in the wall by default, but still it'd be easy to get him in a wall if you place a right unit (or several) at the right place before he spawns
20120119 21:26:11< vultraz> so even if you hard-code in a correct loc you can still make him spawn in teh wrong place?
20120119 21:26:32< Crab___> yes
20120119 21:26:54< vultraz> that shouldn't be
20120119 21:26:57< vultraz> (IMO)
20120119 21:28:22< Crab___> well, that's the consequence of current default placement append list
20120119 21:28:30< Crab___> the 'map, recall' are appended to placement
20120119 21:28:39< Crab___> so, if no placement= is given, the default is 'map'
20120119 21:28:53< Crab___> which is the old behavior 'place on map if vacant tile can be found, ignore passability'
20120119 21:29:18< vultraz> so...can that be fixed for 1.11?
20120119 21:29:45< Crab___> technically, yes. but some WML will break.
20120119 21:30:12< Crab___> for example, on a survival scenario, if the ai leader is spawned inside the wall..
20120119 21:30:18< Crab___> and the wall is far away
20120119 21:30:40< Crab___> the leader (if the default for leaders would have map_passable in the append list), would go to recall list
20120119 21:30:55< Crab___> since there would be no vacant passable locations near him
20120119 21:32:08< vultraz> so...wouldn't WML authors just need to add passability=map?
20120119 21:32:19< Crab___> yes
20120119 21:33:08< Crab___> if they add 'placement=map', it would be fixed.
20120119 21:33:31< vultraz> yeah, placement
20120119 21:33:35< vultraz> typo
20120119 21:33:49< Crab___> a proper deprecation warning for that is possible, as well
20120119 21:34:00< Ivanovic> Crab___: do you think a mass check of mainline would make sense to make sure that the placement is done right?
20120119 21:34:13< Crab___> Ivanovic: I'm sure that mainline is wrong in many places.
20120119 21:34:49< Crab___> Ivanovic: all cave maps which use [unit] in events where the affected hex can be occupied by ai/player before event happens, are affected.
20120119 21:35:12< Crab___> Ivanovic: some are more affected than others, that actually depends on the way adjacent hexes are found.
20120119 21:35:19< anonymissimus> Crab___: I said before, I really dislike this placement= key
20120119 21:35:42< Crab___> anonymissimus: yes, since it's hard to split into multiple keys.
20120119 21:36:04< anonymissimus>  in the other tags, such as unstore_unit etc, there's a check_passability=yes|no
20120119 21:36:19< Crab___> anonymissimus: actually, unstore would need to be changed to placement as well :)
20120119 21:36:35< anonymissimus> i don't think its hard, it would be cleaner in wml and C++
20120119 21:36:42-!- Upth [~ogmar@108-85-91-228.lightspeed.frokca.sbcglobal.net] has joined #wesnoth-dev
20120119 21:36:42-!- Upth is now known as Upthorn
20120119 21:36:43< Crab___> anonymissimus: the problem with check_passability is that we need to somehow specify the order of checks
20120119 21:37:50< Crab___> otherwise, it'd be possible to have next_to_leader=yes/no, check_passability=yes/no, allow_to_recall=yes/no, allow_to_map=yes/no,  ....
20120119 21:38:46< anonymissimus> and what's bad about that ?
20120119 21:39:00< Crab___> anonymissimus: it's cleaner, but we need to specify the order of checks.
20120119 21:39:11< anonymissimus> why ?
20120119 21:40:55< anonymissimus> TBH, placement= always confused me
20120119 21:41:13< Crab___> anonymissimus: condider 'place on x,y' and 'place next to leader'
20120119 21:41:33< Crab___> anonymissimus: we might want to try placing on x,y first and next to leader if we fail.
20120119 21:41:47< Crab___> anonymissimus: or we might want to try placing next to leader or on x,y if we fail (i.e. if leader is dead)
20120119 21:41:54< Crab___> how the WML should differ?
20120119 21:42:20-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120119 21:42:20< anonymissimus> well we dont need to add support for that
20120119 21:42:52< anonymissimus> wml should be kept simple to understand and I feel that this placement= isn't, sort of
20120119 21:42:55< Crab___> with placement, it's simply like 'placement=map,leader' vs 'placement=leader,map'
20120119 21:43:25-!- Appleman1234 [~Appleman1@ppp59-167-222-56.qld.adsl.internode.on.net] has quit [Ping timeout: 272 seconds]
20120119 21:43:51< Crab___> well, then we need to enforce the order that allows to do everything the WML authors want
20120119 21:43:59< Crab___> then, it'd be possible to do the split into multiple subtags
20120119 21:44:06< fendrin> Crab___: Is there any usecase where the scenario designer wants a unit to be spawned in a cave wall?
20120119 21:44:08-!- Gambit [~gambit@wesnoth/developer/grickit] has quit [Read error: Connection reset by peer]
20120119 21:44:13< anonymissimus> the unit tag was special in that it can also appear in [side], there this placing next to leader comes from I think, but that's nto the case for other unit-placing tags
20120119 21:45:20< Crab___> fendrin: yes, I've seen that with some leaders where authors want to lock them away from battle, i.e. on survivals, and where the author hasn't bothered to make a passable 1-hex 'room'  for the unit.
20120119 21:45:56< Crab___> well, the placing on units on the map should use a common backend to avoid duplication of game logic
20120119 21:46:21< Crab___> so, that's why [unit] in side and in [event] is made to behave the same.
20120119 21:46:30< Crab___> but, let's think about placement and order of checks..
20120119 21:46:43< Crab___> can we find a single useful order of checks?
20120119 21:46:51< Crab___> if so, it'd be possible to split
20120119 21:46:57< fendrin> Crab___: Hmmm, that is most likely a hack. I can't think about a situation in which you really need that feature.
20120119 21:47:53< anonymissimus> fendrin: placing units into casewall certainly has its use
20120119 21:48:11-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit []
20120119 21:49:12< anonymissimus> in any case, the tags support it, and it was the default until I added check_passability in teleport, recall and unstore_unit
20120119 21:49:16< Crab___> the keys in question are like :  'can we overwrite?', 'should we find vacant hex?' 'should the hex be passable?' 'should we place next to leader?' 'can we place into recall list?'
20120119 21:50:13< fendrin> anonymissimus: And that would be?
20120119 21:51:47< anonymissimus> fendrin: just because I cant name you a usecase now doesnt mean there is none
20120119 21:52:26< anonymissimus> in fact, I find it bold of you to ask to remove a feature which was supported since long
20120119 21:52:44< anonymissimus> so you have to give reasons, not me
20120119 21:53:40< mordante> anonymissimus, I hope to find time for those bugs, but not sure I'll manage before 1.10, fear not
20120119 21:54:20< fendrin> Placing units in cavewalls is a bug itself, not a feature.
20120119 21:54:26< anonymissimus> move_unit is also a unit-placing tag
20120119 21:56:32< anonymissimus> I imagine there could be situations where all hexes are filled, and a unit could be placed too far apart, if not placed onto impassable terrain
20120119 21:57:00< anonymissimus> so thats your usecase that can also not be fixed by placing a passable terrain
20120119 21:58:25< Crab___> anonymissimus: yes, move_unit would also need changes.
20120119 21:58:46< Crab___> anonymissimus: check http://pastebin.mozilla.org/1455119
20120119 21:59:02< Crab___> anonymissimus: that's how it might look like if we get rid of placement= and switch to multiple keys.
20120119 21:59:06< Crab___> anonymissimus: what do you think?
20120119 21:59:53< CIA-45> espreon * r52663 /trunk/ (28 files in 14 dirs): Updated the Old English translation.
20120119 22:00:22< anonymissimus> the other keys don't support "placing next to leader" and such
20120119 22:00:36< anonymissimus> [unit] is the only one with many options
20120119 22:01:01< Crab___> well, it makes sense to let all the 'place unit somewhere' tags support all the options and have the same defaults
20120119 22:01:21< Crab___> but, mainly, I wanted to check if this way of getting rid of placement= looks good to you
20120119 22:01:43< Crab___> since you told that you'd prefer multiple attributes
20120119 22:05:55< CIA-45> espreon * r52664 /trunk/ (11 files in 10 dirs): Updated the Latin translation.
20120119 22:06:01-!- Pete-Flux [~quassel@unaffiliated/peterporty] has quit [Ping timeout: 252 seconds]
20120119 22:06:14< anonymissimus> place_allow_overwrite and place_search_for_vacant seems to carry the same logic
20120119 22:06:29-!- happygrue [~quassel@wesnoth/developer/wintermute] has quit [Read error: Connection reset by peer]
20120119 22:07:32< Crab___> there are three options if the hex is occupied
20120119 22:07:47< Crab___> 1) place a unit anyway, overwriting
20120119 22:07:50< anonymissimus> if overwrite is allowed, we never search fro vacant
20120119 22:07:55< Crab___> 2) search for suitable vacant hex
20120119 22:08:01< Crab___> 3) forget about it, try other ways to place a unit
20120119 22:08:24< Crab___> yes, there's no 4th option, if overwrite is allowed, we never search for vacant *if* the hex is passable or if passability is not required.
20120119 22:09:16< anonymissimus> searching for vacant means searching for empty only in my terminology, not seraching for passable ;)
20120119 22:09:26< Crab___> anonymissimus: yes
20120119 22:10:17< Crab___> anonymissimus: but, if but if there's an occupied unpassable hex (might happen, it might be passable for the unit which occupies it, actually) and we were asked to provide a passable hex, we will not overwrite
20120119 22:11:12< Crab___> anonymissimus: so, 'overwrite allowed' is not a guarantee that we won't search for another hex
20120119 22:11:29< Crab___> anonymissimus: we might need 'find nearby passable hex' function for that
20120119 22:12:06< Crab___> so, in fact, there are 4 options
20120119 22:12:57< anonymissimus> it makes no sense to add the recall-list placing to tags like [recall]
20120119 22:13:07< Crab___> it makes sence, actually
20120119 22:13:11-!- happygrue [~quassel@c-98-222-183-113.hsd1.il.comcast.net] has joined #wesnoth-dev
20120119 22:13:11-!- happygrue [~quassel@c-98-222-183-113.hsd1.il.comcast.net] has quit [Changing host]
20120119 22:13:12-!- happygrue [~quassel@wesnoth/developer/wintermute] has joined #wesnoth-dev
20120119 22:13:40< Crab___> i.e. if we would like to autorecall some units, but we don't want to lose them if there's absolutely no space to fit them in
20120119 22:14:02< Crab___> it makes sense to return them to recall list instead of simply discarding them
20120119 22:14:38< Crab___> 'placing to recall list', in cases where a map / leader placement was requested, is really a feature of last resort to avoid losing the unit if there's nowhere to put it
20120119 22:15:00< Crab___> of course, [recall] without x,y and with place_next_to_leader="no" makes little sense.
20120119 22:15:18< Crab___> since it's a noop
20120119 22:15:40< Crab___> but [recall] with x,y= or recall with place_next_to_leader="yes" actually can fail to recall due to lack of space
20120119 22:17:10< Crab___> so, returning to vacant/overwrite, there's 4 options:  1) only place if current hex is free and passable  2) search for free hex, regardless of passability 3) search for passable hex, regardless of if it's free or not  4) search for free passable hex.
20120119 22:17:24< Crab___> so, 4 options, 2 keys, all combinations of them make sense.
20120119 22:18:00< Crab___> currently, we have no option (3) implemented
20120119 22:19:03< mordante> I'm off night
20120119 22:19:11-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20120119 22:19:19< Crab___> anonymissimus: so, should we, in 1.11, replace placement= with those 5 attributes (with suitable tag names) ?
20120119 22:19:48-!- MeccaGod [~majs@host189-199.bornet.net] has quit []
20120119 22:20:16-!- oldtopman [~oldtopman@unaffiliated/oldtopman] has joined #wesnoth-dev
20120119 22:23:13< anonymissimus> Crab___: if we *need* to unify unit-placing behavior, and if that is the less-backwards-compat-breaking way, yes
20120119 22:23:44< anonymissimus> I suspect it is since I already added these check_passability to the other tags
20120119 22:24:29-!- zookeeper2 is now known as zookeeper
20120119 22:24:32-!- zookeeper [~lmsnie@87-100-211-108.bb.dnainternet.fi] has quit [Changing host]
20120119 22:24:32-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20120119 22:24:36< Crab___> anonymissimus: ok. is it ok to reuse existing attribute names where appropriate? (find_vacant, check_passability) or it's better to rename them to be more uniform?
20120119 22:25:03< anonymissimus> and indeed find_vacant_tile doesnt support searching for passable without searching for "free" as well
20120119 22:25:28< Crab___> anonymissimus: that's easy to fix (with a side effect of a change of function name :) )
20120119 22:25:37< anonymissimus> I'd say reuse
20120119 22:25:41< Crab___> anonymissimus: ok
20120119 22:25:53< anonymissimus> but as zookeeper what he thinks of teh whoe thing
20120119 22:26:14< anonymissimus> ask...the...whole
20120119 22:27:31< CIA-45> espreon * r52665 /trunk/po/wesnoth-units/la.po: Updated the Latin translation.
20120119 22:30:26< zookeeper> i wouldn't mind a concise question instead of trying to piece the whole thing together from the backlog
20120119 22:32:48< Crab___> zookeeper: there's an idea to (in 1.11) deprecate and then remove placement= and instead, in all tags that place units on map (unit, recall, ...), institute a system with 5 attributes which will work like http://pastebin.mozilla.org/1455119
20120119 22:33:13< Crab___> zookeeper: and the question is 'what do you think of this approach?'
20120119 22:33:54< anonymissimus> the tags affected (all unit-placing tags I can think of) are: move_unit, unstore_unit, recall, teleport and unit
20120119 22:35:08< zookeeper> frankly? looks like overengineering. i mean, _5_ different keys just to control where to put the unit?
20120119 22:37:25< Crab___> zookeeper: well, the default values for most cases will suit everyone. currently, all this complexity (plus some more) is hidden in one placement= tag.
20120119 22:38:20< Crab___> zookeeper: and, for some of the other tags, some of the attributes are already available and working (like find_vacant, check_passability)
20120119 22:38:32< anonymissimus> I find a single key with lots of possible attributed more confusing
20120119 22:39:03< Crab___> ^ that's why I've proposed to change to a system with split attributes.
20120119 22:39:13< anonymissimus> also, we could probably have the last one (place_to_recall_list) always "yes"
20120119 22:39:19< zookeeper> multiple keys are also confusing because you don't know how they'll interact with each other
20120119 22:39:33< Crab___> the interaction can/will be documented
20120119 22:40:52< zookeeper> well, i'm not opposed strongly enough to try to come up with an alternative, so fine by me i guess
20120119 22:41:16< Crab___> ok.
20120119 22:41:21< Crab___> a second question, related.
20120119 22:42:29< anonymissimus> if everything previously to place_to_recall_list failed, it means the unit would be discarded, so we should try to add it to the recall list no matter what
20120119 22:42:42< anonymissimus> or ignore the tag ?
20120119 22:42:46< Crab___> anonymissimus: yes, in 99.9% cases.
20120119 22:43:09< Crab___> anonymissimus: so, the 5th attribute, place_to_recall_list, would be find with default value in most cases
20120119 22:43:20< Crab___> I also want to make a default value change of 'require the hex where the unit would be placed to be passable' from 'no, don't require' to 'yes, require', with a deprecation period with some warning messages'
20120119 22:43:35< Crab___> zookeeper, anonymissimus, fendrin: what do you think of ^ ?
20120119 22:44:53< anonymissimus> Crab___: actually, it is already so
20120119 22:45:35< Crab___> anonymissimus: no, it's not the case
20120119 22:45:48< Crab___> anonymissimus: for [unit], default placement now is map,leader
20120119 22:45:52< Crab___> anonymissimus: not map_passable, leader
20120119 22:45:53< anonymissimus> the default for check_passability is always yes
20120119 22:46:10< anonymissimus> in the 4 tags other than [unit]
20120119 22:46:16< Crab___> anonymissimus: so, [unit] has, effectively, a default of check_passability=no
20120119 22:46:27< Crab___> anonymissimus: it's good to hear that in other tags it's already defaulted to yes
20120119 22:46:36< Crab___> anonymissimus: so, the default change only concerns [unit]
20120119 22:48:38< anonymissimus> you've got an old bug assigned to you regarding the stuff: v
20120119 22:48:45< anonymissimus> https://gna.org/bugs/?15113
20120119 22:49:55-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20120119 22:50:08< anonymissimus> the thing should perhaps be discussed on a wider basis, I think every addon uses those tags
20120119 22:50:14-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Remote host closed the connection]
20120119 22:50:20< anonymissimus> frequently
20120119 22:50:31-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20120119 22:51:18< anonymissimus> changing the default in unstore_unit from find_vacant=no to find_vacant=yes is critical, it's historically used for modifying units 
20120119 22:51:46< anonymissimus> so there's ton of wml that would need update
20120119 22:52:49-!- stikonas [~gentoo@bcm-131-111-216-70.girton.cam.ac.uk] has joined #wesnoth-dev
20120119 22:52:49-!- stikonas [~gentoo@bcm-131-111-216-70.girton.cam.ac.uk] has quit [Changing host]
20120119 22:52:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120119 23:01:26< Crab___> anonymissimus: that old bug is about other fun stuff :)
20120119 23:01:42< Crab___> anonymissimus: but it was related because there was a small misunderstanding of the overwrite behavior
20120119 23:02:39< Crab___> anonymissimus: that's the advantage if we actually rename the attributes - we would be able to emit proper runtime warnings
20120119 23:03:13< Crab___> anonymissimus: i.e., if a unit without 'our_new_tag_name_for_find_vacant' is unstored with [unstore_unit] on top of other unit, we can do that for a release or two, but with a warning message being printed.
20120119 23:03:55< Crab___> anonymissimus: actually, we can do that even with old attribute names, and probably should, it's just there would be more false positives.
20120119 23:06:38< anonymissimus> ok, didsn't you wanna fix that UtbS bug ?
20120119 23:06:49< Espreon> UtBS bug? Where?
20120119 23:06:54-!- negusnyul [~negusnyul@dsl4E5CDBD4.pool.t-online.hu] has quit [Quit: Konversation terminated!]
20120119 23:07:18< anonymissimus> this https://gna.org/bugs/index.php?19303
20120119 23:08:26< CIA-45> crab * r52666 /trunk/ (2 files in 2 dirs): Fixed bug #19303: UtBS: one of the dwarves was spawning in a wall.
20120119 23:08:35< anonymissimus> we have probably better things to do in 1.11, such as stabilizing the wb and the DSU emulation for finally fixing the sighted event
20120119 23:08:36< Crab___> anonymissimus: well, I'll do a minimal fix for now.
20120119 23:09:00< Crab___> anonymissimus: well, this is actually related to my long-term plan on DSU :)
20120119 23:09:13< Crab___> anonymissimus: and to wb, as well
20120119 23:09:53< Crab___> anonymissimus:  since to fix the DSU, we need to fix the wb, and to fix and improve the wb we need to extract some common code of the game engine for wb's/ai/ui use 
20120119 23:09:57< anonymissimus> well, but only related; once that a location is found, the shroud+fog updating code can be called
20120119 23:10:04< Espreon> anonymissimus: Hmmm, shame on me for not noticing it.
20120119 23:10:06< Espreon> Crab___: Thanks.
20120119 23:10:27< Crab___> anonymissimus: no, related in a different way. there's a mess that I want to gradually untangle
20120119 23:10:58< Crab___> anonymissimus: I would need to split off the game logic vs game events vs gui updates into different piles of code
20120119 23:11:04-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120119 23:11:30< Crab___> anonymissimus: then, the event system's internals are to be modified to support those 'what-if' evaluations that I has described to gabba
20120119 23:11:47< Crab___> anonymissimus: then, we would be able to make a DSU on top of wb
20120119 23:13:02< Crab___> anonymissimus: and then we can deal with the old DSU :)
20120119 23:13:50< anonymissimus> I wonder whether the whole thing will be quicker than gui2...
20120119 23:14:17< Crab___> well, there's no black magic there (i.e. external libs that we need to honour)
20120119 23:14:38< Crab___> so, it is definitely a lot less work than gui2
20120119 23:24:57< CIA-45> espreon * r52667 /trunk/po/wesnoth/ang@latin.po: Updated the Old English translation.
20120119 23:27:56-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit []
20120119 23:34:58< Ivanovic> chrber just asked me an interesting question:
20120119 23:35:08< Ivanovic> what is the difference between a tooltip and a helptip?
20120119 23:36:45< Ivanovic> there seems to be some hotkey like "Show Helptip"
20120119 23:36:56< Ivanovic> as well as some dev error message
20120119 23:37:23-!- Crendgrim [~crend@77-22-114-250-dynip.superkabel.de] has quit [Quit: Konversation terminated!]
20120119 23:38:51< vultraz> Ivanovic: what IS the diff...
20120119 23:39:03< Ivanovic> vultraz: i got no idea
20120119 23:39:08< Ivanovic> that is why i am asking here
20120119 23:39:17< Ivanovic> in fact: what the hell is a "Helptip" at all?
20120119 23:39:35< vultraz> I dunno
20120119 23:39:55< vultraz> lol
20120119 23:40:26< anonymissimus> Ivanovic: I only know that it is a strange required element in gui2 dialogs
20120119 23:40:38< Ivanovic> so mordante should know?
20120119 23:40:48< anonymissimus> but mordante can probably answer these questions
20120119 23:40:50< anonymissimus> yes
20120119 23:41:02< anonymissimus> or perhaps shadowm ?
20120119 23:41:27< anonymissimus> same for tooltip
20120119 23:41:31< Espreon> It's probably either:
20120119 23:41:40< Espreon> A. a tooltip that provides help
20120119 23:42:02< Espreon> ... Hmmm wait, that's not GUI2... Yeah, it's probably just a tooltip that provides help.
20120119 23:42:06< Espreon> But I'm not sure.
20120119 23:42:11< anonymissimus> or a helptip that provides a tool ?
20120119 23:42:20< Espreon> Also: http://en.wikipedia.org/wiki/Tooltip
20120119 23:42:22< Espreon> anonymissimus: ...
20120119 23:42:33< CIA-45> ivanovic * r52668 /trunk/po/ (wesnoth/de.po wesnoth-lib/de.po): updated German translation
20120119 23:42:49< Espreon> We really need moar # po: and // TRANSLATORS: comments...
20120119 23:42:51< Espreon> ... yeah...
20120119 23:43:19-!- Gambit [~gambit@wesnoth/developer/grickit] has joined #wesnoth-dev
20120119 23:43:42< vultraz> Espreon: is a tooltip that little dialog that pops up at the bottom of the screen when you mouse over?
20120119 23:43:48< Espreon> Yes.
20120119 23:44:02< anonymissimus> well yes, I assumed that it's somethign like that, however, I never saw an UI effect of teh elements we need to pass so far
20120119 23:45:14< vultraz> Espreon: then what that heck is a helptip
20120119 23:45:25-!- Pete-Flux [~quassel@unaffiliated/peterporty] has joined #wesnoth-dev
20120119 23:45:30< Espreon> vultraz: Read the backlog.
20120119 23:47:20< vultraz> I guess it's the same thing....
20120119 23:48:37-!- Pete-Flux is now known as PolarPanda
20120119 23:50:32-!- oldtopman [~oldtopman@unaffiliated/oldtopman] has quit [Remote host closed the connection]
20120119 23:54:34-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20120119 23:55:54-!- Exasperation [4a47319b@gateway/web/freenode/ip.74.71.49.155] has joined #wesnoth-dev
--- Log closed Fri Jan 20 00:00:52 2012