--- Log opened Sat Feb 20 00:00:04 2010
20100220 00:00:54< Mythological> good point
20100220 00:01:03< Mythological> I have no more objections ;)
20100220 00:06:31-!- Noyga [~noyga@wesnoth/developer/noyga] has quit [Quit: Quitte]
20100220 00:33:17-!- ilor [~user@wesnoth/developer/ilor] has quit [Ping timeout: 260 seconds]
20100220 00:46:03-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100220 00:47:55-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100220 00:54:07-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100220 00:57:25-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100220 00:58:43-!- shadowmaster_ [~ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100220 00:59:35-!- shadowmaster_ is now known as shadowm_laptop
20100220 01:05:13-!- ancestral [~ancestral@97-116-104-150.mpls.qwest.net] has joined #wesnoth-dev
20100220 01:06:00< ancestral> I've got a question: in the binary distributions, how many binary files are there? Just two (the app and the server)?
20100220 01:06:43< shadowm_laptop> probably more for distributions that include dependencies (e.g. Win32 distribution)
20100220 01:07:12< shadowm_laptop> s/probably/certainly/
20100220 01:07:38< ancestral> You mean the Wesnoth executable installs more than just the app and the server app?
20100220 01:07:50< ancestral> Like helper apps or something?
20100220 01:08:08< ancestral> All the utils and stuff are just scripts, right?
20100220 01:08:16< shadowm_laptop> the wesnoth executable installs nothing, you mean the installer executable (in win32), anyway
20100220 01:08:21< shadowm_laptop> yes to your last question
20100220 01:08:43< ancestral> shadowm_laptop: yes, I meant the installer executable
20100220 01:08:47< shadowm_laptop> the win32 distribution includes the SDL dynamic link libraries, and probably more stuff too (I lost track long ago)
20100220 01:08:59< ancestral> Ohhh, okay
20100220 01:09:02< shadowm_laptop> no idea about how the MacOS X package even works
20100220 01:09:16< ancestral> On the Mac side I only see the two, I think
20100220 01:09:26< ancestral> Actually, I could just diff and find out
20100220 01:09:37< shadowm_laptop> there are actually two additional tools (the exploder and cutter) that are probably not distributed by most packagers
20100220 01:09:54< shadowm_laptop> those are written in C++ and therefore need to be compiled into binaries
20100220 01:10:31< ancestral> Ahh there are frameworks and some nibs after all
20100220 01:10:39< shadowm_laptop> then there's the test suite, which is only useful to mainline code maintainers and it's probably not generated by anyone else.
20100220 01:11:55-!- allefant [~elias@allegro/developer/allefant] has joined #wesnoth-dev
20100220 01:13:44< loonycyborg> I heard that Macs use so-called bundles, basically those are directories containing a binary and all its dependencies.
20100220 01:13:56-!- elias [~elias@allegro/developer/allefant] has quit [Ping timeout: 245 seconds]
20100220 01:14:19< ancestral> loonycyborg: yes
20100220 01:14:25< shadowmaster> so every app includes its own dependencies?
20100220 01:14:36< shadowmaster> even if they are the same as other apps? :/
20100220 01:14:42< ancestral> No
20100220 01:14:54< ancestral> They can access systemwide frameworks
20100220 01:15:05< ancestral> For example, there are some SDL frameworks in the Wesnoth executable
20100220 01:15:22< ancestral> But if you removed those because you had them installed in /Library/Frameworks then it would just use those
20100220 01:15:55< shadowmaster> what a fancy name for those things known as "shared object libraries" in Unixish operating systems and "dynamic link libraries" in Windows
20100220 01:16:01< shadowmaster> wait- :p
20100220 01:16:23< ancestral> Mac OS X does use .dylib's
20100220 01:16:29< loonycyborg> Frameworks contain headers too :P
20100220 01:20:36< fendrin> shadowmaster: http://www.wesnoth.org/forum/viewtopic.php?p=410987#p410987 Do you think it's intended to have Kaleh being lawfull?
20100220 01:20:48< shadowm_laptop> fendrin: yes, it is
20100220 01:21:23< fendrin> sure, why?
20100220 01:21:29< shadowm_laptop> fendrin: one of the defining characteristics of the desert elves is that they *are* lawful unlike their ancestors
20100220 01:21:42< shadowm_laptop> there are plenty of in-dialogue mentions of this fact
20100220 01:22:15< fendrin> So the reporter didn't notice the other desert elves being lawfull as well?
20100220 01:23:02< shadowm_laptop> I am not the reporter so I don't know.
20100220 01:23:53< shadowm_laptop> hm.
20100220 01:24:02< shadowm_laptop> who the hell broke the desert elves' alignment?
20100220 01:24:27< shadowm_laptop> in fact, Kaleh appears neutral in trunk r41281
20100220 01:25:51< shadowm_laptop> ohhhh, I'm going to hate to work with macros in mainline thanks to esr
20100220 01:26:03< Espreon> What did he do this time?
20100220 01:26:35< shadowm_laptop> the whole "macro argument type checking" with wmllint
20100220 01:26:50< Espreon> Oh, wow...
20100220 01:27:17< shadowm_laptop> #define CENTRAL_BODY_DEATH_ANIMATION BASE_IMAGE_FUNCTION OVERLAY_IMAGE_FUNCTION got its arguments renamed ot BASE_IMAGE_AFFIX OVERLAY_IMAGE_AFFIX
20100220 01:27:39< shadowm_laptop> those names don't really convey the purpose of the arguments anymore. "affix" for what?
20100220 01:28:12< shadowm_laptop> one more reason to not have any of my campaigns butchered to fit a tool
20100220 01:31:11< shadowmaster> okay, the WML hasn't changed.
20100220 01:31:23< shadowmaster> so the bug is most likely a result in a change in the engine.
20100220 01:32:33< shadowmaster> in particular, only the elves that are spawned by the scenario code are affected; desert elves created with the debug mode option *are* lawful
20100220 01:33:31< shadowmaster> as I expected, I get a neutral Kapou'e in SotBE as well
20100220 01:36:05< shadowmaster> I'll file a bug
20100220 01:37:05< shadowmaster> fendrin: do you have 1.7.13 compiled?
20100220 01:37:17< fendrin> shadowmaster: yes
20100220 01:38:51< shadowmaster> can you start SotBE 1 and check Kapou'es alignment?
20100220 01:39:47< fendrin> shadowmaster: He is neutral.
20100220 01:40:26< shadowmaster> filed bug #15429
20100220 01:41:08< fendrin> That will make wesnoth pretty unbalanced. It's time to play rebels at the mp server ...
20100220 01:41:44< shadowmaster> yeah
20100220 01:42:04< shadowmaster> hence it has the maximum priority I could select (which is 9; the tracker didn't let me select 11)
20100220 01:44:47< shadowmaster> well, actually, as I mentioned in the report, recruits aren't affected
20100220 01:45:39< fendrin> Surely it was introduced by crab's changes on the unit tag.
20100220 01:46:14< fendrin> That was related to work on the multiplayer persistence.
20100220 01:49:16-!- Zarel [~Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20100220 01:49:42< shadowmaster> actually...
20100220 01:49:47< shadowmaster> AI0867 broke it
20100220 01:51:07< shadowmaster> AI0867: your r40928 broke wesnoth badly!
20100220 01:51:32< Espreon> He broke Wesnoth in a bald manner? Interesting...
20100220 01:51:39< Espreon> LOL, no.
20100220 01:51:46 * Espreon 's eyes tricked him again.
20100220 01:52:03< shadowmaster> although I'm not sure exactly *why* it broke wesnoth
20100220 01:54:29< shadowmaster> the logic going on there before r40928 wasn't any less broken but at least it didn't break alignments for units spawned with WML (apparently the problem now is triggered by the usual lack of explicit alignment= specifications in [unit] tags)
20100220 01:54:54-!- Skystriker [~croselius@ool-43551ca7.dyn.optonline.net] has joined #wesnoth-dev
20100220 01:54:58-!- Jozrael [~croselius@ool-43551ca7.dyn.optonline.net] has quit [Ping timeout: 248 seconds]
20100220 01:58:08< AI0867> shadowmaster: I think the proper fix would be instead to remove that else part
20100220 01:58:46< AI0867> reading the diff again, I think the previous version gave units that didn't specify a unit type (did that ever work?) a neutral alignment
20100220 01:59:17< shadowmaster> yeah, as I said the lgoic was already broken then
20100220 01:59:52< shadowmaster> although, maybe the else should be replaced by a else if(cfg["alignment"] != "") instead
20100220 02:01:31< shadowmaster> that way it'd still catch invalid alignment specifications, and whatever is filling in them when there's no explicit alignment specified in WML will still fill in the unit type's alignment
20100220 02:06:18< shadowmaster> AI0867: should I commit, or do you have something else in mind?
20100220 02:06:42-!- knotwork [~markm@142.177.233.146] has quit [Ping timeout: 248 seconds]
20100220 02:07:14< AI0867> I have other stuff lying around, you go ahead
20100220 02:07:55-!- knotwork [~markm@142.177.233.146] has joined #wesnoth-dev
20100220 02:13:59< CIA-88> shadowmaster * r41285 /trunk/ (changelog players_changelog src/unit.cpp): (log message trimmed)
20100220 02:13:59< CIA-88> Fix bug #15429
20100220 02:13:59< CIA-88> r40928 forces the Neutral alignment when it isn't overridden by
20100220 02:13:59< CIA-88> SingleUnitWML, assuming the empty/missing alignment specification to be
20100220 02:13:59< CIA-88> "invalid". The logic before that commit was also broken, so now we make
20100220 02:14:00< CIA-88> sure that empty/missing alignment specifications are ignored (they seem
20100220 02:14:01< CIA-88> to be automatically fixed to inherit the unit type's alignment later in
20100220 02:16:46-!- Zarel_ [~Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20100220 02:22:27-!- Zarel_ is now known as Zarel|laptop
20100220 02:25:37-!- knotwork [~markm@142.177.233.146] has quit [Ping timeout: 264 seconds]
20100220 02:27:31< shadowmaster> let me take this oportunity to express my opinions about the whole "Lord of Music" business.
20100220 02:28:31< shadowmaster> I think that title is cursed. Musicians leave, musicians get annoyed at your licensing policies, musicians tend to appear/disappear at irregular intervals, and musicians tend to have bad luck with their hardware: http://forums.wesnoth.org/viewtopic.php?p=409807#p409807
20100220 02:28:39< shadowmaster> s/your/our/
20100220 02:29:32< ancestral> These are true things
20100220 02:29:35< shadowmaster> oh, and musicians tend to create IRC channels in the wesnoth namespace that are ultimately abandoned in the deep well of off-topicness
20100220 02:29:50< ancestral> Hehe
20100220 02:30:01< ancestral> Where's Blueblaze?
20100220 02:30:08< ancestral> :P
20100220 02:31:44< shadowmaster> last seen 20h 45m ago
20100220 02:33:03-!- allefant [~elias@allegro/developer/allefant] has quit [Quit: Leaving]
20100220 02:38:03< shadowmaster> hm, we can write AI components in Lua now? FEATURE freeze?
20100220 02:43:29-!- ancestral [~ancestral@97-116-104-150.mpls.qwest.net] has quit [Quit: ancestral]
20100220 02:44:21-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100220 02:45:48-!- ancestral [~ancestral@97-116-104-150.mpls.qwest.net] has joined #wesnoth-dev
20100220 02:53:06-!- Crab_ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100220 02:57:58< fendrin> shadowmaster: That is why a fork would be useful. No one any longer cares for a feature freeze that is around for 5 years.
20100220 02:58:33< shadowmaster> I'm not the one that needs to be convinced, sadly ;)
20100220 02:58:40< fendrin> hi Crab_
20100220 02:58:46< Crab_> hi, fendrin
20100220 02:59:20< fendrin> Crab_: Did you enable lua for ai components?
20100220 02:59:51-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100220 03:00:58< Crab_> fendrin: yes, although it is still a proof-of-concept thing while I fix some things in it.
20100220 03:01:19< shadowmaster> feature freeze :x
20100220 03:01:25< Crab_> fendrin: I'm working on it right now, and i'll commit before next release.
20100220 03:01:58< Crab_> shadowmaster: consider this a bugfix for formula ai :)
20100220 03:02:50< Crab_> shadowmaster: moreover, if I get a combo c++/lua ai working in 1.8, I can actually package it as an addon and improve the lua part via the addon server.
20100220 03:03:25< fendrin> Damn, I wish I had the guts and would just commit everything I code straight away.
20100220 03:03:33< shadowmaster> same here
20100220 03:07:53< CIA-88> ai0867 * r41286 /trunk/src/addon_management.cpp: Don't emit warnings about a missing _info.cfg if the add-on is clearly from a different source (present PBL file or .svn/.git directory)
20100220 03:36:32-!- Zarel|laptop [~Zarel@warzone2100/developer/Zarel] has quit [Quit: This computer has gone to sleep]
20100220 03:45:40-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has quit [Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz]
20100220 03:46:21-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection]
20100220 03:55:14-!- Zarel [~Zarel@warzone2100/developer/Zarel] has quit [Ping timeout: 272 seconds]
20100220 04:08:33-!- Jozrael [~croselius@ool-43551ca7.dyn.optonline.net] has joined #wesnoth-dev
20100220 04:09:15-!- Crab_ [~Crab_@wesnoth/developer/crab] has quit [Quit: Leaving.]
20100220 04:10:49-!- Skystriker [~croselius@ool-43551ca7.dyn.optonline.net] has quit [Ping timeout: 260 seconds]
20100220 04:22:27-!- Mythological [Mythologic@77.28.120.164] has quit []
20100220 04:27:28-!- knotwork [~markm@142.177.233.146] has joined #wesnoth-dev
20100220 04:47:11-!- shadowm_laptop [~ignacio@wesnoth/developer/shadowmaster] has quit [Quit: good night - P.S. I'm impersonating myself]
20100220 05:06:15-!- Blueblaze [~nick@adsl-99-158-47-180.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100220 05:13:30-!- Espreon [~espreon@wesnoth/developer/espreon] has quit [Remote host closed the connection]
20100220 05:38:23< shadowmaster> my laptop's power adapter stopped working.
20100220 05:38:42< shadowmaster> I'm using my older broken laptop atm, but I don't think I'll be able to work on anything for a while..
20100220 05:48:18-!- Jozrael [~croselius@ool-43551ca7.dyn.optonline.net] has quit []
20100220 05:50:48-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 252 seconds]
20100220 05:51:56-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100220 05:53:44-!- Espreon [~espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20100220 07:06:06-!- Blueblaze [~nick@adsl-99-158-47-180.dsl.hstntx.sbcglobal.net] has quit [Remote host closed the connection]
20100220 07:14:41-!- Espreon [~espreon@wesnoth/developer/espreon] has quit [Quit: WRYYYYYYYYYYYYYYYYYYYY!]
20100220 07:21:39-!- [Relic] [~Relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20100220 07:42:43-!- ancestral [~ancestral@97-116-104-150.mpls.qwest.net] has quit [Quit: And that’s the end of THAT chapter.]
20100220 07:52:29-!- Espreon [~espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20100220 07:57:13-!- Espreon [~espreon@wesnoth/developer/espreon] has quit [Client Quit]
20100220 08:04:59-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Quit: crimson_penguin]
20100220 08:11:14-!- Espreon [~espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20100220 08:22:47-!- Espreon [~espreon@wesnoth/developer/espreon] has quit [Remote host closed the connection]
20100220 08:31:33-!- ilor [~user@wesnoth/developer/ilor] has joined #wesnoth-dev
20100220 08:34:41-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20100220 08:34:51< mordante> servus
20100220 08:58:58-!- dtiger [~dtiger@dynamic-vpdn-93-125-68-209.telecom.by] has joined #wesnoth-dev
20100220 09:00:26-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100220 09:15:02-!- dtiger [~dtiger@dynamic-vpdn-93-125-68-209.telecom.by] has quit [Quit: Konversation terminated!]
20100220 09:24:51-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-dev
20100220 09:25:40-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20100220 09:54:17-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 260 seconds]
20100220 09:55:22-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100220 10:23:20-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100220 10:25:57-!- Noyga [~noyga@wesnoth/developer/noyga] has joined #wesnoth-dev
20100220 10:34:24-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100220 10:36:15-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20100220 10:42:59-!- silene [~plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20100220 10:43:10< silene> hi
20100220 10:46:08< mordante> hi silene 
20100220 10:50:02< CIA-88> boucman * r41287 /branches/water_animation/ (changelog src/animated.hpp src/animated.i src/builder.cpp): Make terrain animations start randomly
20100220 10:56:03< boucman> hey silene
20100220 10:56:12< boucman> silene: you're the one that did the preprocessor ?
20100220 10:56:18< silene> yes
20100220 10:56:46< boucman> could you have a look at http://wesnoth.pastebin.com/m5f77dcd8
20100220 10:57:05< boucman> there are two macros called ANIMATION_10 there
20100220 10:57:34< boucman> however, the engine chokes on the first on (it complains that there is a line starting with a comma)
20100220 10:57:40< boucman> any idea why ?
20100220 10:58:08< silene> because there is a line that starts with a comma
20100220 10:58:15< boucman> :P
20100220 10:58:25< boucman> which one .
20100220 10:58:29< boucman> ?
20100220 10:58:39< silene> line 9 + line 35
20100220 10:58:49< silene> put the #enddef on line 8
20100220 10:59:18< boucman> oooh
20100220 10:59:20< boucman> thx
20100220 10:59:49< boucman> I was thinking of it in C term, where # markers have to be at the start of line
20100220 11:01:47< boucman> thx a million
20100220 11:02:06-!- knotwork [~markm@142.177.233.146] has quit [Ping timeout: 272 seconds]
20100220 11:26:55-!- knotwork [~markm@142.177.232.137] has joined #wesnoth-dev
20100220 11:48:06-!- Zarel [~Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20100220 12:17:35< CIA-88> silene * r41288 /trunk/src/pathfind/pathfind.hpp: Avoided missing definitions.
20100220 12:17:38< CIA-88> silene * r41289 /trunk/src/scripting/lua.cpp: Fixed custom cost function not working without a dummy unit. Improved error messages.
20100220 12:17:40< CIA-88> silene * r41290 /trunk/data/lua/helper.lua: Added helper for tile distance.
20100220 12:54:21-!- YogiHH [YogiHH@c203194.adsl.hansenet.de] has joined #wesnoth-dev
20100220 12:54:48< CIA-88> boucman * r41291 /branches/water_animation/ (59 files in 5 dirs): add torch-lit stone walls as a new terrain Xol, also rework the macros to make it easier to have animations. Will port existing animated terrains to the new system soon
20100220 12:54:57-!- YogiHH [YogiHH@c203194.adsl.hansenet.de] has quit [Changing host]
20100220 12:54:57-!- YogiHH [YogiHH@wesnoth/developer/yogihh] has joined #wesnoth-dev
20100220 12:55:01< YogiHH> hello
20100220 12:55:07< boucman> hey YogiHH
20100220 12:55:26< YogiHH> fendrin, you there?
20100220 12:56:07< mordante> hi YogiHH 
20100220 12:56:24< mordante> YogiHH, will you be around in about an hour?
20100220 12:56:37< YogiHH> mordante: probably, yes
20100220 12:57:52< mordante> good then I'd like to discuss https://gna.org/bugs/index.php?15383 with you, but I'm about to go off to lunch
20100220 13:05:09< boucman> silene: a bit more tricky, is it possible to do something similar to http://wesnoth.pastebin.com/m424bd4c6
20100220 13:06:49< CIA-88> mordante * r41292 /trunk/src/gui/widgets/tree_view.cpp: Small optimization when setting the content grid.
20100220 13:07:29< silene> boucman: no, as the enddef are not balanced
20100220 13:09:41< boucman> silene: ?? 
20100220 13:09:45< boucman> at what point ?
20100220 13:10:33< silene> boucman: the #endef on line 7 closes the #define on line 5, not the one on line 6
20100220 13:11:44< silene> boucman: rather than trying to abuse the preprocessor, wouldn't you want to just define the animation in lua instead?
20100220 13:12:28< boucman> silene: what I want to avoid is to have to redefine all the terrain macroes, so lua sort of defy the point
20100220 13:13:12< boucman> silene: but that's fine, in my last commit I found an elegant way of doing it, I need to expand it for variable timing, but that should be fairly easy
20100220 13:13:34< silene> boucman: why? the existing terrains are supposed to work, no? so no need to change their macros
20100220 13:14:30< boucman> animated terrain don't mix in the current macros well, and I like the way it works, it's actually quite clean once you got the gist of it
20100220 13:15:50< silene> boucman: you may have misunderstood me; i'm not saying that you should change the macro interfaces; i'm saying that you should change their implementation to use lua instead
20100220 13:17:03< silene> that way you would get functions for manipulating strings
20100220 13:17:45< boucman> but I would have to learn lua :P
20100220 13:18:20< boucman> more seriously, currently I don't feel constrained by the current system, but i'll keep it in mind if I ever do
20100220 13:37:16-!- Sirp [~user@wesnoth/developer/dave] has quit [Ping timeout: 272 seconds]
20100220 13:38:26-!- Sirp [~user@pool-71-164-166-178.dllstx.fios.verizon.net] has joined #wesnoth-dev
20100220 13:50:39< YogiHH> does anybody know why we have two mechanisms to end a level, one via setting play_controller::level_result_ and another via throwing an end_level_exception?
20100220 13:53:03< boucman> YogiHH: my guess is that the exception is a remanant of the past
20100220 13:53:24< YogiHH> boucman: yes, that would make sense
20100220 13:58:16-!- Blarumyrran [~Blarumyrr@81-20-159-197.levira.ee] has quit [Read error: Connection reset by peer]
20100220 13:59:02< mordante> YogiHH, regarding https://gna.org/bugs/index.php?15383
20100220 13:59:29< YogiHH> yes?
20100220 13:59:38< mordante> the problem seems to be caused by your problem to fix the start before the other player selected a leader
20100220 14:00:03< YogiHH> quite possible
20100220 14:00:48< YogiHH> mordante: do you want me to have a look at that?
20100220 14:00:48< mordante> so I wanted to fix it by calling side.set_ready_for_start(true) in connect::take_reserved_side
20100220 14:01:09< mordante> but that fails since the function is never inside the if for the game loaded
20100220 14:01:25< mordante> YogiHH, yes please, just wanted to let you know what I found thusfar
20100220 14:01:32< YogiHH> ok
20100220 14:02:18< mordante> the code starting with "// Assigns this user to a side" seems to import the side
20100220 14:03:16< mordante> so the side is already taken in the connect::take_reserved_side and the code doesn't call the set_ready_for_start(true)
20100220 14:03:34-!- stikonas [~and@bcm-131-111-247-5.girton.cam.ac.uk] has joined #wesnoth-dev
20100220 14:03:34-!- stikonas [~and@bcm-131-111-247-5.girton.cam.ac.uk] has quit [Changing host]
20100220 14:03:34-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100220 14:03:36< YogiHH> i see
20100220 14:13:09-!- zookeeper [~l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20100220 14:34:10-!- YogiHH [YogiHH@wesnoth/developer/yogihh] has left #wesnoth-dev []
20100220 14:42:22-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20100220 14:42:24-!- Blarumyrran [~Blarumyrr@81-20-159-197.levira.ee] has joined #wesnoth-dev
20100220 14:43:16-!- lukjad86 is now known as ShadowChild
20100220 14:45:47-!- ShadowChild is now known as lukjad86
20100220 14:50:20< mordante> hmm it seems the map no longer scrolls to a fight 
20100220 14:54:13< boucman> mordante: do you know a lot about the terrain drawing code ?
20100220 14:55:36< mordante> boucman, quite a bit
20100220 14:56:20< boucman> i'm trying to get terrain animations to start randomly, I thought I had nailed it, but I have a weird bug...
20100220 14:56:48< boucman> see r41287 for what I did...
20100220 14:57:36< boucman> when I draw a patch of windmills on a terrain, the part of the windmill that overlaps the neighbouring hex is desynchronized with the rest of the windmill
20100220 14:57:46< boucman> do you have any clues before I start digging ?
20100220 14:58:31< mordante> your patch tries to achieve a random timing for every tile?
20100220 14:58:37< boucman> yes
20100220 14:58:48< mordante> (didn't read the code, but I can guess)
20100220 14:59:06< boucman> we already have an animation object for each tiles (they arn't shared as I though they were) so I just randomized the starting time
20100220 14:59:45< mordante> I think the windmill is also put in several tiles, which explains the behaviour
20100220 14:59:57< boucman> ???
20100220 15:00:28< boucman> it overlaps neighbouring tiles, yes, but it's an out of hex image, not an image split on multiple hexes
20100220 15:02:02< mordante> yes and doesn't that part get a different start frame?
20100220 15:02:32< boucman> ok, now I understand what you mean...
20100220 15:02:48< boucman> tricky...
20100220 15:03:22< mordante> terrains are tricky ;-)
20100220 15:03:53< boucman> hmm
20100220 15:04:05< boucman> ok, any idea how we could achieve what I want ?
20100220 15:06:49< mordante> hmm let me think
20100220 15:09:39-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100220 15:09:48-!- stikonas [~and@bcm-131-111-247-5.girton.cam.ac.uk] has joined #wesnoth-dev
20100220 15:09:48-!- stikonas [~and@bcm-131-111-247-5.girton.cam.ac.uk] has quit [Changing host]
20100220 15:09:48-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100220 15:10:17< mordante> btw boucman src/builder.cpp round line 322 contains some debug code
20100220 15:10:56-!- sebas_ [~be2a4c6e@gateway/web/freenode/x-rttblikoyqxjixvu] has joined #wesnoth-dev
20100220 15:11:04< boucman> did I commit that ? :P
20100220 15:11:55< mordante> no, gna secretly sneaked it in the commit, just so we can blame you :-P
20100220 15:12:02< boucman> hehe
20100220 15:12:11< boucman> well, right now it's in my branch so no big deal
20100220 15:12:39< mordante> I'll complain again when it gets in trunk ;-P
20100220 15:12:59< boucman> hehe
20100220 15:13:23< mordante> would it be easy to add a flag to a terrain whether or not it's animation should be randomized
20100220 15:13:30< mordante> or should that be in a terrain rule?
20100220 15:13:54< mordante> or maybe even at the animation engine level
20100220 15:14:27< mordante> then we also might be able to "solve" the synchronized flags
20100220 15:14:50< boucman> mordante: there are very few (none at the moment) that should not be randomized
20100220 15:15:17< boucman> and even with a flag, the original problem (desynchronized neighbouring frame) would still be there
20100220 15:15:56< mordante> I want to have the flags not synchronized
20100220 15:16:23< boucman> yes, that's what I said
20100220 15:16:36< boucman> so far, no terrain want to be synchronized (though they all are)
20100220 15:16:49< mordante> ok wasn't sure which direction you meant it
20100220 15:18:18< boucman> I must admit my sentence was a bit ambiguous
20100220 15:19:44< mordante> no problem
20100220 15:19:58< mordante> where should we solve the problem, terrain or animation level?
20100220 15:21:06< boucman> c++, not wml that's for sure
20100220 15:21:39< boucman> I don't see how we could solve it at the animation level, so I'd say terrain
20100220 15:21:48< mordante> personally I think the animation level is the easiest, but we have animations that should start with frame 1 (recruit, combat etc) and some where we want randomness
20100220 15:21:54< boucman> but I might not understand clearly where you consider the different levels to be...
20100220 15:22:54-!- sebas_ [~be2a4c6e@gateway/web/freenode/x-rttblikoyqxjixvu] has quit [Quit: Page closed]
20100220 15:22:57< mordante> we could add a flag to the terrain WML that they should have random timing or give that flag to the animation WML
20100220 15:23:20 * mordante starts to look at the animation WML reference
20100220 15:23:22< zookeeper> if there's going to be a way to tell the game to sync or not sync all instances of a certain terrain animation, then that flag should go into the [terrain_graphics] tag
20100220 15:23:27-!- sebas_ [~be2a4c6e@gateway/web/freenode/x-exbfmhobnvikonjw] has joined #wesnoth-dev
20100220 15:23:34< zookeeper> and yes, having that possibility would be nice
20100220 15:23:57< mordante> but flags are not in the terrain WML and we want them to be random as well
20100220 15:24:09 * boucman has no idea how flags work
20100220 15:24:24< boucman> but I believe it's a totally different code path...
20100220 15:24:53< mordante> I think so too, but they end up in the animation engine at some point
20100220 15:25:08< boucman> the use animated.hpp, yes
20100220 15:25:34< boucman> but afair, they share a single animated<> object, which is why they are synchronized
20100220 15:26:00< boucman> (unless, like for terrain, the object is copied somewhere I missed, in which case randomizing it is trivial to do)
20100220 15:31:19< zookeeper> just for clarity, i meant "flag" in a general sense. "flags" are also the specific mechanism used in terrain graphics WML.
20100220 15:35:58< mordante> hmm the terrains don't use frames but images
20100220 15:37:09< mordante> of course we could add things to a progressive image to allow randomness, but I guess that will get ugly
20100220 15:37:20< boucman> mordante: yes, that's what I meant
20100220 15:37:35< boucman> the frame mechanism is only used with units
20100220 15:37:54< boucman> mordante: here is what I understand so far...
20100220 15:38:14< boucman> we have a structure of tiles (defined at builder.hpp:263)
20100220 15:38:35< boucman> each tile  contain a set of rules (stored in images member)
20100220 15:38:52< boucman> except these are actually pointers to the real rules (thus shared between tiles
20100220 15:39:48< boucman> at some point, we reach terrain_builder::add_image_to_cache where we fill images_background and images_foreground which are where we store a copy of the real object
20100220 15:40:15< boucman> however, at this point, I'm not sure we still know enough info to synchronize with the neighbour
20100220 15:41:44< Ivanovic> hi
20100220 15:43:46< mordante> hi Ivanovic 
20100220 15:44:50-!- elias [~elias@allegro/developer/allefant] has joined #wesnoth-dev
20100220 15:49:11< mordante> boucman, in the [frame] WML we could add a boolean random_start_frame
20100220 15:49:39< boucman> you mean [frame] in [terraing_graphics] ?
20100220 15:49:55< boucman> mordante: you sure you understand my problem ?
20100220 15:50:11< boucman> my problem is not on the WML side, it's how to have the engine actually do it correctly
20100220 15:50:23< mordante> is there a [frame] in terrain graphics??
20100220 15:50:41< boucman> no, 
20100220 15:50:44< boucman> i'm confused
20100220 15:50:52< mordante> good else I would be confused
20100220 15:51:03< mordante> ;-)
20100220 15:51:06< boucman> [frame] are for units, why are you mentionning units ? 
20100220 15:51:34< mordante> since that WML structure looks like the C++ code as well
20100220 15:51:57< mordante> so if we add it there we can select whether a frame should be random or not
20100220 15:52:08< boucman> selecting is not the problem
20100220 15:52:22< mordante> then we only need to put it in the terrain code as well (which of course is a problem)
20100220 15:52:35< boucman> we could simply add random_start=true in [tile] if we want to
20100220 15:52:48< boucman> mordante: yes, that's the only problem I have, the terrain code
20100220 15:54:55< mordante> maybe we indeed should add a random_start in [tile], let me look a bit further
20100220 15:55:06< boucman> aaagh
20100220 15:55:24< boucman> mordante: making it optional is step 2, I just want it to be mandatory for the moment
20100220 15:59:55< mordante> not sure whether I understand your last remark
20100220 16:00:33< boucman> well, what I mean is that I looked into it and right now all existing animated terrains would gain to be unsynchronized
20100220 16:00:46< boucman> moreover it's seriously needed for the new water
20100220 16:01:06-!- Ivanovic_ [~ivanovic@dtmd-4db23735.pool.mediaWays.net] has joined #wesnoth-dev
20100220 16:01:06-!- Ivanovic_ [~ivanovic@dtmd-4db23735.pool.mediaWays.net] has quit [Changing host]
20100220 16:01:06-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 16:01:14< boucman> so I think making it configurable is not a top priority, so I pushed that back for the moment
20100220 16:01:58< boucman> so we can look into adding a flag to configure it later, i just want it to work for the moment
20100220 16:03:33< mordante> but doesn't the unsynchronized terrain break the windmill?
20100220 16:04:39-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 276 seconds]
20100220 16:04:56< boucman> mordante: yes, but I would like to fix the windmill :P
20100220 16:05:19-!- Ivanovic [~ivanovic@dtmd-4db2375e.pool.mediaWays.net] has joined #wesnoth-dev
20100220 16:05:19-!- Ivanovic [~ivanovic@dtmd-4db2375e.pool.mediaWays.net] has quit [Changing host]
20100220 16:05:19-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 16:06:55< mordante> so wouldn't it be the easiest to add the flag, set it to random by default and disable it for the windmill?
20100220 16:07:54-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 276 seconds]
20100220 16:07:57< boucman> it means all animated terrain that overlap can't be random
20100220 16:08:02< boucman> quite a restriction
20100220 16:09:07-!- Ivanovic_ [~ivanovic@dtmd-4db2379b.pool.mediaWays.net] has joined #wesnoth-dev
20100220 16:09:07-!- Ivanovic_ [~ivanovic@dtmd-4db2379b.pool.mediaWays.net] has quit [Changing host]
20100220 16:09:07-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 16:09:54-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 248 seconds]
20100220 16:10:39< mordante> only animated terrain that gets out of the hex, do we have more as the wind-mill?
20100220 16:10:49< mordante> windmill*
20100220 16:11:50-!- Ivanovic [~ivanovic@dtmd-4db2e2f0.pool.mediaWays.net] has joined #wesnoth-dev
20100220 16:11:50-!- Ivanovic [~ivanovic@dtmd-4db2e2f0.pool.mediaWays.net] has quit [Changing host]
20100220 16:11:50-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 16:11:55< boucman> no
20100220 16:13:32-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 256 seconds]
20100220 16:14:45-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 16:14:54< boucman> mordante: I see you point, but I don't like the idea...
20100220 16:15:40< mordante> I'm just not sure whether it's possible to do much better with the current system
20100220 16:15:43< boucman> i don't really see the point of having synchronized animations (though zookeeper seemed to have ideas) and I don't like the idea of having a WML flag to tell the engine about one of its own limitations
20100220 16:15:53< boucman> indeed
20100220 16:15:55< mordante> I'm not going to say it's perfect ;-)
20100220 16:16:03< boucman> ...
20100220 16:16:18-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 248 seconds]
20100220 16:16:41< zookeeper> boucman, there's no cases i can think of right now for synced anims, but someone might want to do it for some special case.
20100220 16:16:57< boucman> zookeeper: thx
20100220 16:17:01< mordante> just that I also prefer to have it better, but I think the current engine setup limits it
20100220 16:17:46< boucman> mordante: could we store the "hex origin" of each rule in the images member, next to the rule pointer ?
20100220 16:18:16< boucman> if we do that, we could attach a "random seed" to each hex and use it to sync anims coming from neighbouring hex
20100220 16:18:43< zookeeper> boucman, well, basically there is no "hex origin"
20100220 16:18:51-!- Ivanovic [~ivanovic@dtmd-4db2385e.pool.mediaWays.net] has joined #wesnoth-dev
20100220 16:18:57-!- Ivanovic [~ivanovic@dtmd-4db2385e.pool.mediaWays.net] has quit [Changing host]
20100220 16:18:57-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 16:19:03< boucman> zookeeper: ??
20100220 16:19:05< mordante> boucman, sounds possible but tricky and hacky
20100220 16:19:11-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 246 seconds]
20100220 16:19:17< boucman> i'll see what I can do
20100220 16:19:19< zookeeper> i mean, a [terrain_graphics] isn't associated with any hex. i guess a [tile] is...
20100220 16:20:20< boucman> zookeeper: we were speaking of internal c++ concepts here :)
20100220 16:20:55< mordante> boucman, just some other thought, if we move to OGL we shouldn't be bound to inside hexes anymore, would that make solving the issue easier
20100220 16:20:57-!- Ivanovic_ [~ivanovic@dtmd-4db2a08f.pool.mediaWays.net] has joined #wesnoth-dev
20100220 16:20:57-!- Ivanovic_ [~ivanovic@dtmd-4db2a08f.pool.mediaWays.net] has quit [Changing host]
20100220 16:20:57-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 16:21:28< zookeeper> boucman, i know, but i assumed "rules" correspond with the WML rules
20100220 16:21:57< boucman> mordante: probably yes, but i don't know much about OGL, so my guess is not very reliable
20100220 16:23:46-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 248 seconds]
20100220 16:24:15< mordante> I also don't know too much about it, but from what I know we need to redraw everything every frame
20100220 16:24:38-!- sebas_ [~be2a4c6e@gateway/web/freenode/x-exbfmhobnvikonjw] has quit [Quit: Page closed]
20100220 16:24:40< mordante> and now we're heavily optimizing to redraw as little as possible
20100220 16:25:22-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 248 seconds]
20100220 16:26:59-!- Ivanovic_ [~ivanovic@dtmd-4db2d11a.pool.mediaWays.net] has joined #wesnoth-dev
20100220 16:29:33-!- Ivanovic [~ivanovic@dtmd-4db2a9d8.pool.mediaWays.net] has joined #wesnoth-dev
20100220 16:29:33-!- Ivanovic [~ivanovic@dtmd-4db2a9d8.pool.mediaWays.net] has quit [Changing host]
20100220 16:29:33-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 16:31:57-!- Ivanovic_ [~ivanovic@dtmd-4db2d11a.pool.mediaWays.net] has quit [Ping timeout: 276 seconds]
20100220 16:34:36-!- Zarel|laptop [~Zarel@c-75-72-160-179.hsd1.mn.comcast.net] has joined #wesnoth-dev
20100220 16:42:34-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 75 bugs, 249 feature requests, 8 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100220 16:50:24< fendrin> hello
20100220 16:52:40< mordante> hi fendrin 
20100220 16:53:38< fendrin> mordante: The only change to the map_data attribute I can think off is to remove the starting position numbers from it. I guess removing a feature won't be problematic and makes the handling more easy.
20100220 16:54:10< fendrin> But that is not an urgent issue. Only a thought for the future.
20100220 16:55:37< mordante> fendrin, I'm not sure whether or not we need it for the anchors in the tile data, but we can let the scenario override the position
20100220 16:58:20< fendrin> mordante: Yes, but this is only a backend thing. I am fine with how the map_data works right now. Adding stuff in wml is much more easier for me since I am familiar with the config class.
20100220 16:59:47< fendrin> mordante: If we want to integrate some of the features into the map_data (for what I see no need for) everything can be done behind an interface. This has not to be discussed during the design phase of the new features.
20100220 17:03:00< mordante> if we start to change the map format I like to have it discussed since it will probably break compatibility in a lot of ways
20100220 17:03:25< mordante> and to be honest the goal was to keep things editable by hand
20100220 17:03:42< mordante> by embedding things in the map data will make it much harder
20100220 17:04:59< mordante> I went to the change of a map format once ;-)
20100220 17:06:41< ilor> mordante: as far as I gathered the idea is *not* to change the map_data string format, except maybe make a map file proper WML
20100220 17:07:59< ilor> right now maps are one of the few data bits that aren't ;)
20100220 17:08:03< mordante> ilor, the last time I had this discussion with esr it was the idea to change the string format itself
20100220 17:08:42< ilor> I am fairly confident that nobody wants to mess with the large text string format, only add some structured WML data alongside
20100220 17:08:49< mordante> true the last time I wanted to change that part it was kind of shot down (years ago)
20100220 17:09:12< mordante> ^ regarding the parts in the string that aren't part of the map data itself
20100220 17:09:54< mordante> ilor, like I said that was esr's plan the last time we talked about it ;-)
20100220 17:10:33< ilor> anyway, I think whatever backward incompatibility there might be, it's worth it, even if we only do named map regions
20100220 17:10:51< mordante> if we want to add a [map] tag with fields like border and usage and one called data which contains the pure string I've no problem with that
20100220 17:11:04< ilor> mordante: that is what I'd expect
20100220 17:11:34< mordante> and if it gets sub tags like [item] I'm not sure whether that is is a good idea
20100220 17:11:54< ilor> except maybe moving the starting position info outside the string, like someone suggested, but it's not really important
20100220 17:12:17< ilor> mordante: but placing items in the editor is really what could be very useful
20100220 17:12:26< mordante> _if_ that's wanted I rather see some different tags like [map] [mask] [terrain_rule_map]
20100220 17:12:34< ilor> especially if we get eventualy get lots of decoration items
20100220 17:13:04< ilor> I don't think anyone would mind a more powerful map decoration system than the current items ;)
20100220 17:14:25< ilor> at any rate, I think map areas are the most important of the lot, since other stuff can be just done once in the scenario and then the creator can just move the areas around
20100220 17:15:24< mordante> I'm not against a more powerful tool for editing scenarios, I'm just not sure bolting it on top of the map editor is a good idea
20100220 17:15:33< mordante> and I really like the map area idea
20100220 17:16:03< ilor> mordante: I'd like to "bolt" some of these things in the editor because a lot of what's needed is already there
20100220 17:16:18< ilor> the editor does selections which is largely what the map areas will be
20100220 17:16:39< ilor> mordante: also, I think it's important to have one tool for editing how the map *looks*
20100220 17:17:38< ilor> mordante: in other news, any ideas as to why the lobby layout breaks down after it's left idling for a longer while?
20100220 17:19:00< mordante> I agree that some things seem to be right to add to the editor, I just fear that soon everything will get bolted on top of it and it slowly be becomes a jack of all trades
20100220 17:20:14< mordante> ilor, yes I expect at some point it tries to request a reduce height, fails, ????, falls back to adding scrollbars to the window
20100220 17:20:41< mordante> at the ???? it should first try to reduce the size more aggressively but that's not implemented yet
20100220 17:21:15< ilor> mordante: what about just setting the sizes to be constant with respect to the total size available?
20100220 17:21:19< mordante> as long as there're no invalidate layouts it goes well a long time, but once they kick is all falls down
20100220 17:23:09< mordante> ilor, not fond of that idea (I might do it when needed for 1.8) since it hides a bug in the layout engine
20100220 17:23:49< ilor> hides a bug but makes the interface more predictable
20100220 17:24:07< mordante> but before I want to look whether or not it's fixable before 1.8 I first want to fix the other listbox glitches
20100220 17:24:31< ilor> okay, I take it you noticed my rants about disappearing items?
20100220 17:24:47< mordante> I agree it makes the UI more predictable, but fixing the bug would also do that and I prefer to use that solution
20100220 17:24:59< mordante> yes I ran into them as well
20100220 17:25:36< mordante> at the moment I'm trying to polish the tree_view code for handing its own sizing and want to port that to the listbox afterwards
20100220 17:25:41< ilor> mordante: okay. I wasn't able to reproduce that overflow in gamelist diff you mentioned once, other than that the lobby code seems stable and reasonably fast
20100220 17:26:00< mordante> in the tree view I haven't had "blanks" thisfar
20100220 17:26:19< ilor> mordante: I had a go at incremental updates for the playerlist, but it gets real messy real quick to cover all the cases
20100220 17:26:43< mordante> too bad
20100220 17:26:46< ilor> mordante: keep in mind the playerlist is simply redone from scratch, might not show some of the bugs ;)
20100220 17:27:52< mordante> it's not redone from scratch it only clears the nodes and recalculates its size in that phase
20100220 17:28:01< mordante> but less as the listbox
20100220 17:28:15< mordante> you don't run into the gamelist overflow?
20100220 17:28:36< ilor> mordante: inceremetal updates are not easy because a diff from a server can result in a lot of shuffling between the playerlists. I'll try to have another go today, fresh look and all that
20100220 17:28:46< mordante> ok
20100220 17:28:55< ilor> mordante: I meant that vector overflow you had in the gamelist diff uptade function
20100220 17:29:10< esr> mordante: You write: "I agree that some things seem to be right to add to the editor, I just fear that soon everything will get bolted on top of it and it slowly be becomes a jack of all trades"  There's a hard upper limit; a viusual-domain editor can't do procedural stuff.
20100220 17:30:24< mordante> ilor, me to, but did you get it or not?
20100220 17:30:28< esr> Short of that, what your fear is inevitable, so you might as well relax and enjoy it.  
20100220 17:30:57< mordante> esr, the newest idea is already to add units as well
20100220 17:30:59< ilor> mordante: not once
20100220 17:31:12< mordante> ilor, odd I had it a few times today
20100220 17:31:46< esr> mordante: Like I said, it's inevitable, so relax and enjoy it :-)
20100220 17:32:04< mordante> esr, "Short of that, what your fear is inevitable, so you might as well relax and enjoy it." please stop that kind of bullshit else it makes no sense to discuss anything
20100220 17:32:57< esr> No, I meant that seriously.  What you're fighting is *exactly what contnrt designers want* - a visual toolthat does as much as possible.
20100220 17:33:45< mordante> me too
20100220 17:34:11< esr> Sooner or later that pressure is going to push as much as can go into the editor into the editor.  
20100220 17:34:35< esr> That's why I say you might as well relax and enjoy it.
20100220 17:35:06< mordante> can you stop with the bullshit, like I said before I'm not against having more powerful tools only do they need to be in the editor
20100220 17:35:15< esr> Yes, they do.
20100220 17:35:36< esr> Because content designer don't want multiple tools.
20100220 17:35:43< mordante> and keeping stating it as a fact doesn't help
20100220 17:36:03< Ivanovic> esr: then please propose a usable interface, too
20100220 17:36:14< Ivanovic> atm there *is not enough space* for everything
20100220 17:36:28< Ivanovic> right now things are already broken in the lowest supported resolution (800x480)
20100220 17:36:46< Ivanovic> and even in 800x600 things are not really usable!
20100220 17:36:54< esr> Ivanovic: That's true.  Means the editor is going to have to grow pop-up panels for some functions.
20100220 17:37:29< Ivanovic> the problem that mordante fears (and yeah, i think the fear is valid) is that the editor will again be a maintanence hell
20100220 17:38:07< Ivanovic> and with the "almost endless growth" things will get less usable, too
20100220 17:38:17< ilor> esr, Ivanovic: interface wise, we have a lot of space for the terrain palette, which we can re-use while dealing with nakmed areas for instance
20100220 17:38:45< Ivanovic> ilor: start the map editor in 800x480 and repeat this!
20100220 17:38:54< esr> The alternative it to try to build smaller tools with overlapping functions.  The trouble witythat theory is that from the point of view of a scenario designer that approach is user-interface hell.
20100220 17:38:54< Ivanovic> ilor: the interface is broken in this resolution
20100220 17:39:23< Ivanovic> personally i think the best approach is to have a map editor
20100220 17:39:45< Ivanovic> and then tools that somehow use the gameview and allow you to select place and the likes there to place stuff
20100220 17:39:52< esr> The question that would repeatedly come up is: "Why do I havce to hop my eyes and my attention between multiple tools?"
20100220 17:40:25< esr> This is why talk of "not in the map editor" is doomed.
20100220 17:40:44< boucman> mordante: do you have 5' for me .
20100220 17:40:46< ilor> Ivanovic: 800x480 is below the design res of 800x600 :P
20100220 17:40:46< boucman> me ?
20100220 17:40:54< Ivanovic> somehow like a (tiny!!!) scenario editor that shows some general functionality (eg "add sceletton code for $eventtype in turn X")
20100220 17:41:13< Ivanovic> basically some kind of switch in "current edit level"
20100220 17:41:29< Ivanovic> the problem with "everything in one tool" is "which file to load"
20100220 17:41:45< esr> It's bad enough that we already have a tool split between the map editor and a text editor for WML. A third tool would make it worse, and not just 1/3 worse but 3-factorial worse.
20100220 17:41:46< mordante> boucman, yes
20100220 17:41:47< ilor> Ivanovic: there will be one file with the map, named areas and all
20100220 17:41:48< Ivanovic> you could load the scenario file which finds out the map file and all other files belonging there, too
20100220 17:42:10< ilor> Ivanovic: because they don't make any sense outside of the map
20100220 17:42:18< mordante> esr, there have also been complains about the speed of the map editor, due to all transitions 
20100220 17:42:23< Ivanovic> ilor: the matter is, once we add "static objects" to the map users want "usable objects" there, too
20100220 17:42:34< esr> Ivanovic: See my ML posting.  Files that are partly hand-edited and partly machine edited are a recipe for pain.
20100220 17:42:37< boucman> mordante: i have added a random seed to the tile class, and I know how to pass it around to the place where I need it
20100220 17:42:48< mordante> esr, if we have a separate scenario editor it wouldn't need to do transitions
20100220 17:42:57< ilor> Ivanovic: and if we manage to do that, where's the pain?
20100220 17:43:01< Ivanovic> ilor: that is at least some "do place the skelleton code for me" part
20100220 17:43:03< boucman> now I need to find out the source of each images
20100220 17:43:13< ilor> mordante: transitions happen when editing the terrain and only then
20100220 17:43:21< esr> mordante: This is UI hell yo are advocating, IMO.
20100220 17:43:39< boucman> my bet is that I have that info in apply_rule, 
20100220 17:43:56< mordante> esr, no you have a dedicated tool for doing maps if you care about transitions and a simpler version if you don't care
20100220 17:44:11< mordante> esr, remember terrain artists also you the editor a lot
20100220 17:44:28< ilor> mordante: and I think its *very* important to be able to add some water in a map and mark the expanded area as the_ocean in one tool
20100220 17:45:08< esr> I think the correct solution for "transitions are slow" is "wait a few months for machines to get faster", rather than making the design bad for content authors.
20100220 17:45:18< mordante> boucman, are we talking WML or C++
20100220 17:45:26< boucman> c++
20100220 17:45:45< boucman> mordante: on second thought I'm a bit short on time, so we might as well discuss that later
20100220 17:45:48< boucman> sorry about that
20100220 17:46:03< mordante> esr, how many years before my netbook has a fast enough CPU?
20100220 17:46:11< mordante> boucman, ok then we'll look later
20100220 17:46:13< ilor> I don't get what the problem with transitions is. Transitions happen when you edit the terrain, so if you are rearranging map areas, no transitions will be recalculated, and things will be fast
20100220 17:46:40< ilor> and if performance is a problem you can turn transitions off
20100220 17:47:18< esr> mordante: At Moore's law doubling rates, sooner than you think.  Besides, I don't think we need to tarhet netbooks as content-development machines as long as they can play the game.
20100220 17:47:29< mordante> ilor, and content designers don't change terrains in their map?
20100220 17:47:53< mordante> esr, yes we should target netbooks, I use one for development every now and then
20100220 17:48:00< ilor> mordante: yes they do. and they probably want to see how it looks with the transitions anyway.
20100220 17:48:21< mordante> why?
20100220 17:48:33< ilor> mordante: and while placing items there will be no transitions anyway
20100220 17:48:43< esr> mordante: As ilor says.  You're actually reinforcing the argument for a single tool.
20100220 17:48:54< ilor> mordante: if not, there is the option to disable transitions in the editor
20100220 17:50:52< mordante> esr, if you want to read it like that fine with me, seems doesn't matter what I say anyway
20100220 17:54:18< fendrin> Ivanovic: I don't mind if the interface of the editor is broken with very low resolutions. Map making on an IPod can't be a design goal.
20100220 17:54:41< Ivanovic> fendrin: maybe not on an ipod
20100220 17:54:45< Ivanovic> but what about netbooks?
20100220 17:54:55< Ivanovic> there are some 8" netbooks that have exactly this res!
20100220 17:55:03< fendrin> no 
20100220 17:55:03< esr> mordante: No, it matters.  I take your criticisms seriously as a rool,  It's just that in this case I think your premises are deeply mistaken.
20100220 17:55:11< esr> s/rool/rule/
20100220 17:55:25< fendrin> Eclipse is a developer tool as well and doesn'T work with that resolutions any more.
20100220 17:56:51< esr> Ivanovic: I agree with fendrin that worrying about low resolutions is not really useful.
20100220 17:57:27< fendrin> The menus of the editor are empty. Much room to add tools.
20100220 17:58:08< ilor> the problem with low resolutions is that the always-visible palette we have is not really working there. We'd need to redesign this.
20100220 17:58:51< esr> Given trends in display sizes I don't see a lot of point in worrying about resolutions below 1024x768 for developers tools. It's still worth making the game *play* at lower resolutions, though. 
20100220 17:59:31< mordante> esr, I just want to discuss it normally and constant claiming that I'm wrong without arguments doesn't help
20100220 17:59:33< ilor> esr: that said 1024*600 is wildly common in netbooks and I'd like for the editor to keep working there
20100220 17:59:59< ilor> it does now, even if it only shows 6 terrains at a time
20100220 18:00:16 * fendrin has send more mail to the ml.
20100220 18:00:18< mordante> esr, netbooks still have small screens and the new faster handheld devices (Pandora) still have small screens
20100220 18:00:25< esr> mordante: I thionk you're not listening to the arguments, then.  Try thinking about the tool design not as a programmwer but as a *user*.
20100220 18:00:27 * mordante is still answering a post
20100220 18:01:08< mordante> esr, I am listening, but I still get no answers to where we want to take the editor
20100220 18:01:44< mordante> my problem with adding some features is getting on the slipperly slope of turning the editor in a jack of all trades
20100220 18:01:45< fendrin> mordante: I have answered that in a mail. 
20100220 18:02:15< esr> We have three design objectives laid out: Named areas, labels, and pick and place scenery.  We have fourth - unit placement - in discussion.  Why is this not sufficient?
20100220 18:02:33< fendrin> sound sources
20100220 18:02:50 * grzywacz wakes up
20100220 18:02:51< esr> Ah, yes, sound sources.
20100220 18:03:05< fendrin> No more seems realy usefull to me. 
20100220 18:03:23< esr> I can't think of anything else either.
20100220 18:03:26< fendrin> Wrong, bouncman wanted to set some village related stuff as well. That is reasonable.
20100220 18:03:35< esr> Ah.
20100220 18:04:02< Ivanovic> teleporter?
20100220 18:04:42< fendrin> Ivanovic: Don't think so. Can be handled with the named_location feature.
20100220 18:04:42< esr> Ivanovic: I think that case would be handled well enough by named labels.
20100220 18:04:56< mordante> that kind of what I mean with the slippery slope, it starts with one idea and slowly the list becomes larger
20100220 18:05:07< esr> I mistyped. I concur with fendrin.
20100220 18:05:28< mordante> and this is what we can think of in just a few days
20100220 18:05:49< Ivanovic> i bet that we will find possible new stuff that would make sense to add to the "scenario editor"
20100220 18:06:01< esr> mordante: Yes.  I find it entertaining that you think this can be avoided.  It cannot be, not if the design is driven by what users want.
20100220 18:06:16< Ivanovic> that is: once the current proposals are in and we think "okay, now it is complete enough!"
20100220 18:06:27< mordante> esr, that's why I wonder whether it should all be bolted on top of the editor
20100220 18:06:54< esr> Thea lternative is multiple editing tools and UI hell.
20100220 18:07:21< mordante> esr, I'm not against better tools, I just fear the editor becomes some kind of abomination
20100220 18:07:23< fendrin> mordante: Designing the terrain and placing items / labels is one working process. It has to be in one application. That can't be denied.
20100220 18:08:08< ilor> mordante: I think we'd be able to reject pointless cruft with the argument that one can just put a named location and do the rest in WML
20100220 18:08:26< mordante> fendrin, it can and I will, designing terrains has nothing to do with the other two, if you mean designing maps then they are closely related
20100220 18:09:44< fendrin> mordante: Right you got it. Designing the terrain and placing items /labels are the subtasks of designing maps and can't be divided. 
20100220 18:10:57< mordante> fendrin, please talk about designing maps, when you talk about designing terrains I think about something different
20100220 18:11:03< ilor> fendrin: mordante means designing a single terrain graphics-wise
20100220 18:14:01< fendrin> ilor: I don't get that sentence. Please try to express it in another way.
20100220 18:14:19< ilor> fendrin: creating a terrain type
20100220 18:14:56< fendrin> Well, full sentences would be helpfull :-)
20100220 18:15:30< ilor> :P
20100220 18:16:23< ilor> fendrin: designing terrain types is not essential and very common in map editing
20100220 18:16:57< fendrin> Okay, understood.
20100220 18:17:08< ilor> actually, s/and/or/
20100220 18:22:25-!- Noyga [~noyga@wesnoth/developer/noyga] has quit [Ping timeout: 240 seconds]
20100220 18:34:18-!- Blarumyrran [~Blarumyrr@81-20-159-197.levira.ee] has quit [Ping timeout: 240 seconds]
20100220 18:35:03-!- Noyga [~noyga@wesnoth/developer/noyga] has joined #wesnoth-dev
20100220 18:38:26-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20100220 18:43:33< fendrin> mordante: mail sent
20100220 18:44:34-!- Ivanovic_ [~ivanovic@dtmd-4db2f3d9.pool.mediaWays.net] has joined #wesnoth-dev
20100220 18:44:35-!- Ivanovic_ [~ivanovic@dtmd-4db2f3d9.pool.mediaWays.net] has quit [Changing host]
20100220 18:44:35-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 18:47:03-!- Ivanovic__ [~ivanovic@dtmd-4db2bded.pool.mediaWays.net] has joined #wesnoth-dev
20100220 18:47:03-!- Ivanovic__ [~ivanovic@dtmd-4db2bded.pool.mediaWays.net] has quit [Changing host]
20100220 18:47:03-!- Ivanovic__ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 18:47:14-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 248 seconds]
20100220 18:47:21-!- Ivanovic__ is now known as Ivanovic
20100220 18:49:54-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 248 seconds]
20100220 18:50:54< mordante> fendrin, got it
20100220 18:51:27< CIA-88> ilor * r41293 /trunk/src/gui/dialogs/lobby_main.cpp: add a code check for an overflow problem in lobby gamelist diff update code Mordante once saw
20100220 18:51:47< CIA-88> ilor * r41294 /trunk/src/gui/dialogs/ (lobby_main.cpp lobby_main.hpp): remove the lobby delayed gamelist diffs as it is not needed with working diff joining in the lower level
20100220 18:52:09< mordante> fendrin, esr it would be nice if one of you could send an email what you want to add to the editor and what you don't want to add
20100220 18:52:49< mordante> it still remains a bit fuzzy
20100220 18:53:19< mordante> ilor, thanks, but I've seen it more than once ;-)
20100220 18:53:57< fendrin> mordante: No, that is not possible. The set of items that I don't want to add is infinite.
20100220 18:54:33< fendrin> mordante: And all features I want to add are already covered by the mails I sent. 
20100220 18:55:47< fendrin> mordante: items, labels. named locations. soundsoucres, units, maybe some village settings, bouncman  wants. Nothing more. What is fuzzy about that list?
20100220 18:56:18-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 248 seconds]
20100220 18:58:52< Noyga> would it still allow to edit plain map (only terrain tiles) ? if not it's bad 
20100220 19:01:03< fendrin> Noyga: The version for 1.9/1.10 definitely. Maybe later that can dropped but I have no strong opinion about that.
20100220 19:02:22-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100220 19:02:38< mordante> fendrin, for example what can be edited on a unit in your proposal only place them or edit them further
20100220 19:02:58< mordante> if not where is the unit stored is that location human editable
20100220 19:03:33< CIA-88> mordante * r41295 /trunk/src/gui/widgets/ (23 files): 
20100220 19:03:33< CIA-88> Rename twidget::set_size to place.
20100220 19:03:33< CIA-88> This avoids the overload on set_size, avoid hiding it in sub classes.
20100220 19:03:37< CIA-88> mordante * r41296 /trunk/src/gui/widgets/ (4 files): 
20100220 19:03:37< CIA-88> Made a separate function to size the children.
20100220 19:03:37< CIA-88> Rewrote the entire sizing as well to use this new way of sizing.
20100220 19:03:39< CIA-88> mordante * r41297 /trunk/src/about.cpp: 
20100220 19:03:39< CIA-88> Remove a variable which is only assinged.
20100220 19:03:39< CIA-88> Issue found by cppcheck.
20100220 19:03:40< CIA-88> mordante * r41298 /trunk/src/gui/widgets/ (tree_view_node.cpp tree_view_node.hpp): Rename ttree_view_node::indention_level().
20100220 19:03:48< CIA-88> mordante * r41299 /trunk/src/display.cpp: 
20100220 19:03:49< CIA-88> Remove a variable which is only assinged.
20100220 19:03:49< CIA-88> Issue found by cppcheck.
20100220 19:03:50< CIA-88> mordante * r41300 /trunk/src/server/simple_wml.cpp: 
20100220 19:03:51< CIA-88> Remove a variable which is only assinged.
20100220 19:03:51< CIA-88> Issue found by cppcheck.
20100220 19:03:55< CIA-88> mordante * r41301 /trunk/src/storyscreen/render.cpp: 
20100220 19:03:55< CIA-88> Remove a variable which is only assinged.
20100220 19:03:55< CIA-88> Issue found by cppcheck.
20100220 19:04:39-!- Blarumyrran [~Blarumyrr@81-20-159-197.levira.ee] has joined #wesnoth-dev
20100220 19:05:07< Noyga> fendrin, the thing is you may want to use the map editor to design terrain masks, things like that ...
20100220 19:05:35< CIA-88> mordante * r41302 /trunk/changelog: Update changelog.
20100220 19:05:44< fendrin> mordante: The unit is stored in [map] [unit] your values. The interface should at least ask for all mandatory attributes and offers the possibility to bind an id to the unit. This unit tag is human editable. And the editor can reload the edited unit, that should be doable.
20100220 19:12:25< mordante> all mandatory attributes sounds scary unless we have a way to validate that
20100220 19:12:50< mordante> but I'm more concerned about something else
20100220 19:13:16< mordante> what if you add a unit there and the user modifies it, loads some macros in the unit
20100220 19:13:40< mordante> what happens now if you load the map, edit it (including the unit) and save it again
20100220 19:13:42< fendrin> Well, I don't do macro preprocessing
20100220 19:13:50< mordante> do we want to keep the macros?
20100220 19:13:59< mordante> and formatting
20100220 19:14:01< fendrin> macros can't be used there.
20100220 19:14:15< fendrin> [map] will need to stay macroless.
20100220 19:15:32< mordante> so no macros at all in generated units?
20100220 19:15:56< ilor> I think we should keep in mind we'll be able to restrict things to a comfortable subset and say "if you want more, use a named location and place the unit normally"
20100220 19:16:41< fendrin> mordante: What ilor says. And you of course can use macros in event generated units.
20100220 19:17:19< ilor> that's also why I would like to skip units for a while, because it seems to be the most complex one of the lot
20100220 19:17:39< fendrin> ilor: Right, unit is the very last feature to be implemented.
20100220 19:18:07< mordante> ilor, of course we can restrict things, but I like to know upfront what we plan
20100220 19:18:45< fendrin> It is not a problem to use the macro preprocessor before reading [map]
20100220 19:19:11< fendrin> but it maybe very complicated to handle the case a user wants to write into a macro.
20100220 19:19:47< fendrin> mordante: Ah, no it won't.
20100220 19:19:54< mordante> I'm not worried about the reading, more about writing back the expanded macros
20100220 19:20:04< mordante> fendrin, ?
20100220 19:20:24< fendrin> It will just remove the macro and replace it with the modified full wml code. That is fine.
20100220 19:21:31< mordante> you mean it reads the macro and writes the expanded macro back?
20100220 19:21:41< fendrin> yes, that would happen
20100220 19:22:10< mordante> that sounds bad I rather see macros forbidden instead
20100220 19:22:44< mordante> if you expand the macros fixes to the macro are no longer "updated" in your unit
20100220 19:22:59-!- Ivanovic [~ivanovic@dtmd-4db2a9ca.pool.mediaWays.net] has joined #wesnoth-dev
20100220 19:22:59-!- Ivanovic [~ivanovic@dtmd-4db2a9ca.pool.mediaWays.net] has quit [Changing host]
20100220 19:22:59-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 19:23:15< mordante> one of the reasons to use a macro is the hide the complexity of the implementation of the macro, which you suddenly get back
20100220 19:23:27< Ivanovic> if you leave any messages for me today, don't expect me to get them
20100220 19:23:37< Ivanovic> looks like my dsl connection has a *real* problem atm...
20100220 19:25:52< mordante> fendrin, would it be an idea to let the unit defined in [map][unit] to be merged with another unit in the main data?
20100220 19:26:20< mordante> then the one in [map] only needs to contain the basics to show the unit in the editor
20100220 19:26:57< mordante> the user can still use macros and doesn't need to be afraid his macros get mutilated by the editor
20100220 19:28:10< mordante> so the unit gets created from the main data, tests whether there's a unit with the same id in [map] and overwrites the fields defined there
20100220 19:29:56-!- teaser [~teaser@h-37-106.A254.priv.bahnhof.se] has quit [Ping timeout: 246 seconds]
20100220 19:30:42< fendrin> mordante: Sounds like a solution.
20100220 19:31:07< CIA-88> mordante * r41303 /trunk/ (changelog src/multiplayer_connect.cpp): 
20100220 19:31:07< CIA-88> Allow a 1-sides game to be started.
20100220 19:31:07< CIA-88> The code to forbid a 0-sided game was a bit too aggressive, to reduced
20100220 19:31:07< CIA-88> the strictness of the test.
20100220 19:31:07< CIA-88> Fixes Debian bug #568029.
20100220 19:37:41< fendrin> mordante: Can you point me to a gui2 example that does the same or similar to the pastebin http://wesnoth.pastebin.com/d1308310e ?
20100220 19:51:47-!- Ivanovic_ [~ivanovic@dtmd-4db2b540.pool.mediaWays.net] has joined #wesnoth-dev
20100220 19:51:48-!- Ivanovic_ [~ivanovic@dtmd-4db2b540.pool.mediaWays.net] has quit [Changing host]
20100220 19:51:48-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 19:53:41-!- Ivanovic__ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 19:53:56-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 245 seconds]
20100220 19:55:54-!- Ivanovic [~ivanovic@dtmd-4db2ab43.pool.mediaWays.net] has joined #wesnoth-dev
20100220 19:55:54-!- Ivanovic [~ivanovic@dtmd-4db2ab43.pool.mediaWays.net] has quit [Changing host]
20100220 19:55:54-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 19:56:02-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 248 seconds]
20100220 19:57:00-!- Ivanovic__ [~ivanovic@wesnoth/developer/ivanovic] has quit [Read error: Operation timed out]
20100220 20:09:47-!- Ivanovic_ [~ivanovic@dtmd-4db2a327.pool.mediaWays.net] has joined #wesnoth-dev
20100220 20:09:48-!- Ivanovic_ [~ivanovic@dtmd-4db2a327.pool.mediaWays.net] has quit [Changing host]
20100220 20:09:48-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100220 20:10:44-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20100220 20:13:06-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 272 seconds]
20100220 20:13:23-!- Ivanovic_ is now known as Ivanovic
20100220 20:18:37-!- MikeJB [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20100220 20:19:01< mordante> fendrin, there isn't and there won't be. The whole idea behind gui2 is that everything is coded in .cfg files so people can start skin Wesnoth if they want to
20100220 20:19:39-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100220 20:27:25-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20100220 20:27:29-!- YogiHH [YogiHH@c186122.adsl.hansenet.de] has joined #wesnoth-dev
20100220 20:27:40-!- YogiHH [YogiHH@c186122.adsl.hansenet.de] has quit [Changing host]
20100220 20:27:40-!- YogiHH [YogiHH@wesnoth/developer/yogihh] has joined #wesnoth-dev
20100220 20:27:54< YogiHH> hello
20100220 20:28:41< mordante> hi YogiHH 
20100220 20:34:29< fendrin> hi YogiHH
20100220 20:37:14< fendrin> mordante: Does that mean that I need to define a new  c++ class for that dialog?
20100220 20:38:20< mordante> fendrin, yes the whole goal was to make it possible for a user to redefine every dialog
20100220 20:39:47< mordante> that's the problem with the gui1 theming you can only skin a little bit which means if you change a different kind of theme it looks bad with the default theme
20100220 20:40:02< mordante> (think for example spacenoth)
20100220 20:40:51-!- silene [~plouf@wesnoth/developer/silene] has quit [Read error: No route to host]
20100220 20:42:29-!- Blueblaze [~nick@adsl-99-158-47-180.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100220 21:00:49-!- Noyga [~noyga@wesnoth/developer/noyga] has quit [Remote host closed the connection]
20100220 21:02:54-!- Noyga [~noyga@wesnoth/developer/noyga] has joined #wesnoth-dev
20100220 21:04:13< CIA-88> jhinrichs * r41304 /trunk/ (changelog src/multiplayer_connect.cpp): Fix Bug #15383 (Multiplayer Campaigns can't be loaded from savegame.
20100220 21:04:58< YogiHH> fendrin: ^
20100220 21:05:58< fendrin> YogiHH: cool
20100220 21:08:13< mordante> nice YogiHH 
20100220 21:14:05-!- shadowm_laptop [~ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100220 21:16:01< mordante> can somebody confirm https://gna.org/bugs/index.php?15436 ?
20100220 21:17:29< shadowmaster> Ivanovic: did you notice that blocker bug?
20100220 21:17:51< mordante> shadowmaster, the one I posted 10 seconds ago?
20100220 21:17:54< shadowmaster> no
20100220 21:18:17< shadowmaster> https://gna.org/bugs/?15429
20100220 21:18:36< mordante> boring you fixed it ;-)
20100220 21:18:41< shadowmaster> but nice to know that there's another blocker :|
20100220 21:19:09< mordante> well would be nice if somebody can confirm it
20100220 21:19:21< mordante> fendrin, didn't you want to look into this bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561580 ?
20100220 21:20:03< shadowmaster> mordante: I confirm that it works fine at r41285
20100220 21:20:04< fendrin> mordante: yes, that is on my todo.
20100220 21:20:18< shadowmaster> that is, whenever side 1 and 2's units move for anything, the map scrolls accordingly
20100220 21:21:56< mordante> fendrin, ok will you be able to fix it before 1.8?
20100220 21:22:08< shadowmaster> and now I'm recompiling at HEAD. This is going to take a while.
20100220 21:24:54< shadowmaster> long while. I didn't notice someone touched the pathfinding interfaces.
20100220 21:27:38< happygrue_> mordante: it works for me
20100220 21:28:18< shadowmaster> happygrue_: what version is that?
20100220 21:28:34< mordante> hmm really odd fails for me, both with head and r41285
20100220 21:28:44 * mordante starts the bisect engine
20100220 21:28:50< happygrue_> 1.7.13
20100220 21:28:54< shadowmaster> mordante: myabe you disabled the map-tracking thingy
20100220 21:29:18< happygrue_> shadowmaster: your bug also affects leaders in MP I think
20100220 21:29:26< shadowmaster> affected
20100220 21:29:50< happygrue_> nm then :)
20100220 21:32:42< mordante> shadowmaster, good one, never seen that option before...
20100220 21:32:51< mordante> now I wonder how it got turned off
20100220 21:33:00-!- Noyga [~noyga@wesnoth/developer/noyga] has quit [Quit: Quitte]
20100220 21:33:20< ilor> mordante: C-x C-m butterfly somewhere else on earth? :P
20100220 21:33:26< shadowmaster> mordante: laptop? touchpad?
20100220 21:34:14< mordante> ilor, ah great so I can blame emacs :-)
20100220 21:34:34< mordante> shadowmaster, no normal mouse and no animals around to walk over keyboards
20100220 21:34:47< shadowmaster> I'd have blamed touchpad tapping otherwise
20100220 21:35:48< mordante> ah well at least I fixed a blocker :-)
20100220 21:35:52< ilor> BTW regarding editor interface in low res and all... I'll be more careful about it now. Got myself a 1024 by 600 netbook
20100220 21:36:36< shadowmaster> Ivanovic: can't we have a 1.3.14 sooner now that https://gna.org/bugs/?15429 is fixed?
20100220 21:36:39< mordante> IMO everything should work properly at 800x600 and preferably on 800x480
20100220 21:36:50< shadowmaster> Ivanovic: 1.7.14, I mean
20100220 21:37:08< mordante> shadowmaster, your version numbers keep going back ;-)
20100220 21:37:47< mordante> but I think Ivanovic wants to have some more lobby fixes before 1.7.14
20100220 21:38:08< mordante> also Ivanovic's internet connection is flacky today so he might miss log items
20100220 21:38:34< shadowmaster> well, let's allow everyone to play with true neutral "heroes" then
20100220 21:38:41< shadowmaster> ;)
20100220 21:41:27< mordante> I always wanted to play a neutral orc ;-)
20100220 21:48:32< CIA-88> shadowmaster * r41305 /trunk/ (3 files in 2 dirs): 
20100220 21:48:32< CIA-88> Fixed ANL causing the game to end before the start of turn 1 when empty
20100220 21:48:32< CIA-88> sides are specified in the MP game setup - yet another consequence of
20100220 21:48:32< CIA-88> strict unit unstoring mechanics
20100220 21:48:32< CIA-88> (From http://forums.wesnoth.org/viewtopic.php?f=4&t=28961)
20100220 21:53:22-!- Crab_ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100220 21:54:09< shadowmaster> ohhh, I got a female assassin named "Bra" while trying to reproduce a bug
20100220 21:55:03< Smar> that’s wesnoth for you.
20100220 21:55:51< YogiHH> zookeeper, you there?
20100220 21:56:16< zookeeper> YogiHH, yeah
20100220 21:56:52< shadowmaster> well, confirmed bug #15425
20100220 21:56:57< YogiHH> zookeeper: i need some help to understand end_level. For example i found in the code, that theoretically it is possible to end the level in the prestart event. Does that make sense?
20100220 21:57:10< fendrin> shadowmaster: Rename her to Wonder Bra after she reached level3.
20100220 21:57:19< shadowmaster> fendrin: she *is* L3
20100220 21:57:21< zookeeper> YogiHH, yeah, sure
20100220 21:57:42< YogiHH> zookeeper: can you give me an example?
20100220 21:58:12< shadowmaster> silene: maybe you know what's causing bug #15425?
20100220 21:58:21< fendrin> YogiHH: The storyscreen only scenarios in LoW.
20100220 21:58:32< zookeeper> fendrin, they end in the start event
20100220 21:58:34< fendrin> YogiHH: Have a look at scenario 8 for example.
20100220 21:59:01< zookeeper> YogiHH, i think it'd be really rare to want to do that, i can't think of an example right now
20100220 22:00:31< YogiHH> fendrin, zookeeper: start event works fine, too. The code exits the level by throwing an exception, which means that any further event handling or interaction is discarded. Is that necessary?
20100220 22:01:30< zookeeper> YogiHH, you mean that whenever [endlevel] is used, no further events will trigger after the current one has finished?
20100220 22:01:53< YogiHH> zookeeper: i think so, yes
20100220 22:02:19< YogiHH> the background of this question is that it seems to prohibit entering into linger mode, which is important for mp campaigns
20100220 22:03:15< zookeeper> only when used in prestart events, right?
20100220 22:04:05< YogiHH> zookeeper: well, prestart was just an example, basically my question targets all kind of events
20100220 22:04:12< Crab_> YogiHH: note that linger mode makes little sense for scenarios with a dummy map - e.g. some story-only scenarios in LoW were done this way (it even crashed wesnoth at some point)
20100220 22:04:45< zookeeper> YogiHH, i meant the "seems to prohibit entering into linger mode" part
20100220 22:04:46< YogiHH> Crab_: well, for mp campaigns it makes a lot of sense
20100220 22:05:18< zookeeper> there's that linger_mode=yes|no key for [endlevel]. if it doesn't work in some situation then i'd classify it as a bug
20100220 22:05:39< YogiHH> zookeeper: end_level_exceptions prohibit linger mode and they are thrown at various places, mostly event handling it seems
20100220 22:06:03< Crab_> YogiHH: see https://gna.org/bugs/index.php?14244
20100220 22:06:37< YogiHH> zookeeper: ah, that's a good hint. What's the default for that?
20100220 22:06:58< zookeeper> YogiHH, the default's yes
20100220 22:07:34< zookeeper> so as far as i'm concerned, using [endlevel] from a prestart event should drop you into linger mode unless you've given it linger_mode=no
20100220 22:08:28< zookeeper> but if there's a technical problem with it, i don't think it matters at all if prestart is an exception. if you want linger mode, then you could just as well use a start event and it'd end up looking exactly the same.
20100220 22:08:35-!- silene1 [~plouf@ASte-Genev-Bois-152-1-5-240.w82-121.abo.wanadoo.fr] has joined #wesnoth-dev
20100220 22:08:58< YogiHH> zookeeper: i see, that helps quite a bit, thanks
20100220 22:09:18< zookeeper> (of course an exception like that should be documented in the wiki)
20100220 22:09:21< mordante> silene1, I think your changes to titlescreen.cpp introduced this bug http://forums.wesnoth.org/viewtopic.php?f=4&t=28946
20100220 22:09:32< mordante> do you have time to look into it?
20100220 22:11:13< silene1> mordante: i don't understand what's broken from the screenshots
20100220 22:11:16-!- silene1 is now known as silene
20100220 22:11:31< zookeeper> YogiHH, great
20100220 22:11:56< mordante> the text of the source is through the buttons on the right instead of inside the tip box
20100220 22:12:19< silene> shadowmaster: did someone confirm the bug? (because the same user posted an invalid one around the same time, so i don't want to chase a nonexisting bug)
20100220 22:12:41< silene> mordante: oh right
20100220 22:12:44< shadowmaster> silene: I did confirm it
20100220 22:12:57< silene> shadowmaster: do you have a testcase?
20100220 22:13:51< shadowmaster> yes, take that code, append it to the test scenario, play the test scenario, recruit a unit, end your turn, check your recruited unit's description with mouse-over on the sidebar on the next turn
20100220 22:15:12< shadowmaster> instead of having the unit type's description, it will have no description at all
20100220 22:18:45-!- teaser [~teaser@h-37-106.A254.priv.bahnhof.se] has joined #wesnoth-dev
20100220 22:19:30< silene> right, and i see why: the code for outputting unit wml is explicitly writing an empty description instead of no description; funny the issue did not occur sooner
20100220 22:28:36-!- k23z__ [~k23z__@188.26.49.63] has joined #wesnoth-dev
20100220 22:41:18< YogiHH> fendrin: can i mark 15382 as fixed?
20100220 22:41:36< fendrin> YogiHH: Give me some time to test it. 
20100220 22:41:43< YogiHH> sure
20100220 22:42:34-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 74 bugs, 249 feature requests, 8 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100220 22:49:16< Crab_> silene: hi, I'm trying to solve the  'I want to allow the lua ai to be defined in the external file' problem, and I've got a small problem. See http://pastebin.mozilla.org/703944 . I am thinking about returning the ai as a table of closures.
20100220 22:49:36< Crab_> silene:  if I just use wesnoth.require('path/to/file'),  then I need to allow all the functions in that file, too, to be closures using external variable 'data'. how can it be done? or there's some other way ?
20100220 22:51:14< silene> i don't understand what you mean; just pass the table to the external file and let it add the functions itself
20100220 22:51:35< Crab_> how can I pass the table to external file ?
20100220 22:51:36< fendrin> YogiHH: Seems to work. I will fill a new bug report over night if there are still problem left.
20100220 22:51:45< YogiHH> ok
20100220 22:52:07< silene> Crab_: define a function in that external file and call it; didn't i explain that already?
20100220 22:53:18< Crab_> silene: no, I guess that I've not understood you fully, hence asking again. so, make that file return a function with arguments (ai,data) which'll add new  functions to the ai ?
20100220 22:54:07< YogiHH> fendrin: Getting in touch with WML experts is really needed. play_controller.linger_ is initialized with "false" in the constructor :/
20100220 22:54:56< fendrin> YogiHH: Sorry, I don't get the context.
20100220 22:54:59< silene> Crab_: no; first, a "require"d file returns a table, not a function; have this table contain a "init" function (or whatever you want to call it); then call it and pass it your ai table
20100220 22:55:58< YogiHH> fendrin: Never mind, i mixed something up. I was referring to zookeeper's statement that the default for linger mode is "yes", but play_controller.linger_ has another meaning, it seems
20100220 22:56:59< Crab_> silene: ok, understood. thanks. btw, I've reworked code to 'add' all those "move/attack/recruit" functions to the ai table from the c++ side, to avoid any need to use the side argument from lua side.
20100220 22:58:38< fendrin> YogiHH: Please note that in singleplayer the default seems to be controller=ai, in multiplayer it seems to be human. But this is not true for the first scenario in MP where it defaults to ai again.
20100220 22:59:08< Crab_> silene: another questions. how can I write a  c++ lua handler function that'll accept either 0 or 1 arguments ? just check if that argument is 'nil' ? or there's a way to find out the number of arguments actually given to function ?
20100220 22:59:12< YogiHH> fendrin: yes, i have seen your comments about that. What is your preferred behaviour?
20100220 23:00:06< fendrin> YogiHH: Let's have just one default. I would go for ai.
20100220 23:00:22< YogiHH> ok
20100220 23:00:35< Crab_> silene: example use case - recruit function can be used both in 'recruit on hex X' or 'recruit on any suitable hex' variants.
20100220 23:00:59< silene> Crab_: no, test if it is "noneornil", or you could also access "gettop" if the function were to have an arbitrary number of arguments
20100220 23:01:11< Crab_> ok, thanks again.
20100220 23:01:21< fendrin> I need some help with a design pattern.
20100220 23:02:23< fendrin> Please have a look at map_labels.hpp/cpp. It is a container for the map labels but also the painter for them. And this class can serialize/deserialze the labels into from wml. 
20100220 23:03:00< fendrin> It is used in display.hpp/cpp to handle the onscreen labels.
20100220 23:03:57< fendrin> I need everything from that class to use in editor/map_context.cpp/hpp but not the drawing stuff but only the container features.
20100220 23:04:37-!- lukjad86 is now known as aninsanelylongni
20100220 23:05:02< fendrin> So I thought to make 2 classes, labels and map_labels where labels is just a container and the derriving class map_labels extends the drawing features.
20100220 23:05:16-!- aninsanelylongni is now known as lukjad86
20100220 23:05:57< fendrin> But there is drawing code in the contained class, terrain_label as well that can't be handled from a labels class that misses that features.
20100220 23:06:28< fendrin> That is why I need to split this class as well in terrain_label and a simple label that doesn't have the drawing included.
20100220 23:07:19< fendrin> My problem is that I wanted to reuse most of the code that the mother classes provide.
20100220 23:07:40-!- Espreon [~espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20100220 23:07:50< fendrin> But I don't know how to handle the type difference between the mother and child classes.
20100220 23:08:37< Crab_> fendrin: I'd extract all the drawing code to operate on data, e.g. fully separate the data and the drawing logic.
20100220 23:09:31-!- mjs-de [~mjs-de@vpw.wh.Uni-Dortmund.DE] has quit [Remote host closed the connection]
20100220 23:09:56< fendrin> Crab_: Isn't that what I am trying to do?
20100220 23:12:41-!- elias [~elias@allegro/developer/allefant] has quit [Ping timeout: 245 seconds]
20100220 23:13:02< Crab_> fendrin: my proposed split is somewhat different... e.g.  'a class to contain all map label data'  'a class which represents a map data element'  'a class (or several) which has a reference on map label data and can draw them'
20100220 23:13:16< Crab_> with no inheritance
20100220 23:14:42< fendrin> Ah, I see.
20100220 23:17:24< mordante> I'm off night
20100220 23:17:54-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20100220 23:17:54< YogiHH> night mordante
20100220 23:17:56< CIA-88> jhinrichs * r41306 /trunk/ (changelog src/playsingle_controller.cpp): Fixes bug #15398 (Multiplayer Campaign aborted after endlevel).
20100220 23:18:35< YogiHH> fendrin: more for you to test ;)
20100220 23:19:06< fendrin> YogiHH: Okay
20100220 23:20:07-!- Espreon [~espreon@wesnoth/developer/espreon] has quit [Quit: WRYYYYYYYYYYYYYYYYYYYY!]
20100220 23:39:47< CIA-88> silene * r41307 /trunk/src/unit.cpp: Prevented the engine from storing empty descriptions. (Fix for bug #15425.)
20100220 23:39:54< CIA-88> silene * r41308 /trunk/src/ (text.cpp text.hpp): Added support for text alignment.
20100220 23:39:57< CIA-88> silene * r41309 /trunk/src/titlescreen.cpp: Fixed position of tip source for RTL languages.
20100220 23:40:01< CIA-88> silene * r41310 /trunk/src/font.cpp: Fixed broken tooltips for RTL languages.
20100220 23:40:33< shadowmaster> the changelog needs more love
20100220 23:43:37-!- ilor [~user@wesnoth/developer/ilor] has quit [Ping timeout: 264 seconds]
20100220 23:45:29< CIA-88> jhinrichs * r41311 /trunk/ (changelog src/playcampaign.cpp): Fixes bug #15399 (Leaders of the ai sides in LoW multiplayer scenario2 are missing). It is no longer necessary to explicitly define "controller=ai" for AI sides.
20100220 23:56:38< fendrin> YogiHH: how con I thest 41306?
20100220 23:57:45< YogiHH> fendrin: play the campaign like usual on the mp server. You should be entering linger mode at the end of the scenario, with only the host being able to advance. All clients will have to wait until the host sent the next scenario.
20100220 23:58:14< fendrin> YogiHH: That is working exactly like you describe it.
20100220 23:58:37< YogiHH> fendrin: So no client can advance before the host did now
20100220 23:59:47< fendrin> YogiHH: There is still a message window explaining it is now blah blub's turn after the endlevel triggered. Can this be removed?
--- Log closed Sun Feb 21 00:00:12 2010