--- Log opened Thu Sep 10 00:00:00 2009
20090910 00:00:26< Soliton> not sure what that stuff in the filter is.
20090910 00:00:53< shadowmaster> what does this su error message mean? http://wesnoth.pastebin.com/d689c8609
20090910 00:01:42< Soliton> since movement_costs is a tag not an attribute.
20090910 00:01:59-!- norbert_ [n=norbert_@82-171-70-54.ip.telfort.nl] has joined #wesnoth-dev
20090910 00:02:02< shadowmaster> fabi: once you can add the code to wesnoth-umc-dev I'll check it
20090910 00:02:05< Soliton> shadowmaster: it says it in the error su must be setuid to work.
20090910 00:02:24-!- boucman [n=rosen@wesnoth/developer/boucman] has quit ["Leaving."]
20090910 00:02:32< norbert_> server is down, do we need to report that?
20090910 00:02:42< shadowmaster> Soliton: but it is :P
20090910 00:03:05< Crab_> shadowmaster: does the mount permit suid files on it ?
20090910 00:03:18< shadowmaster> I think so, I haven't touched it since December.
20090910 00:03:28-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090910 00:03:59-!- stikonas [n=and@ctv-213-164-125-176.vinita.lt] has joined #wesnoth-dev
20090910 00:04:17< Crab_> shadowmaster: 'which su' ?
20090910 00:04:20< Soliton> shadowmaster: show an ls -l
20090910 00:04:28< alink> "<Soliton> since movement_costs is a tag not an attribute. "    same thing for  cfg.has_attribute("defense") few lines above ?
20090910 00:04:38< shadowmaster> shadowm@bluecore:~$ ls -l `which su`
20090910 00:04:38< shadowmaster> -rwsr-xr-x 1 root root 33112 2008-11-22 15:13 /bin/su
20090910 00:04:54< Soliton> alink: yeah, that looks all bogus.
20090910 00:05:35< alink> rule #1 of messy code, it's even more messy than you think :-/
20090910 00:05:50< shadowmaster> su - root works though
20090910 00:06:56< Soliton> and as root can you change to another user?
20090910 00:07:14< shadowmaster> yup
20090910 00:07:20< cib0> is the 1.6 server down now?
20090910 00:07:24< Soliton> yes.
20090910 00:07:44< Soliton> back up.
20090910 00:08:10< Soliton> bad_alloc strikes again.
20090910 00:08:33< Soliton> hrm.
20090910 00:08:49< Crab_> shadowmaster: any shell aliases on su ?
20090910 00:08:59< shadowmaster> alright, it seems to be a shell problem
20090910 00:09:00< norbert_> what do all these disconnects from people mean, is that a bad_alloc issue on their machines?
20090910 00:09:07< Soliton> actually not up again since the port is still bound.
20090910 00:09:16< Soliton> so you'll have to wait a while.
20090910 00:09:26< Soliton> norbert_: what?
20090910 00:09:31< grzywacz> shadowmaster, alias?
20090910 00:09:32< shadowmaster> or something... I can use su - on users using bash or dash, but not busybox
20090910 00:09:46< Soliton> command -V su
20090910 00:10:01< shadowmaster> "su is hashed (/bin/su)" ?
20090910 00:10:06< norbert_> Soliton: I mean when the client says "<person> disconnected" and they have to rejoin as observers so we can :control <nr> <person> them
20090910 00:10:11< norbert_> Soliton: happens all the time
20090910 00:10:28< Soliton> then that person.. disconnected.
20090910 00:10:38< Soliton> happens all the time on the internet.
20090910 00:10:50< Crab_> shadowmaster: what about using /bin/su ?
20090910 00:11:17< norbert_> Soliton: happens more in multiplayer Wesnoth than on the rest of the web :)
20090910 00:11:18< shadowmaster> Crab_: same suid error
20090910 00:11:29< Soliton> norbert_: define the web.
20090910 00:11:34< shadowmaster> fixed if I change that user from busybox to bash or dash
20090910 00:11:44< norbert_> Soliton: neh, I don't feel like playing games
20090910 00:11:56< Soliton> norbert_: it's pretty difficult to disconnect from a webserver unless you load huge pages.
20090910 00:12:12< CIA-62> silene * r38558 /trunk/data/lua/wml-tags.lua: Added error message to [clear_variable].
20090910 00:12:17< Soliton> other games might indeed be a good indicator.
20090910 00:12:18< CIA-62> silene * r38559 /trunk/src/scripting/lua.cpp: Fixed vconfig child accessor.
20090910 00:12:21< CIA-62> silene * r38560 /trunk/src/scripting/lua.cpp: Prevented segfault on accessing missing vconfig.
20090910 00:12:48< Soliton> but web as in websites has pretty much no relevance.
20090910 00:13:42< Soliton> alink: oh wait...
20090910 00:14:07< Soliton> alink: that config is the filter WML.
20090910 00:15:01< norbert_> in comparison with multiplayer Quake, for example, I would say Wesnoth multiplayer has way more disconnects
20090910 00:15:26-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has quit [Remote closed the connection]
20090910 00:15:30< Soliton> well, quake is udp based, no?
20090910 00:15:41-!- elynia [n=shyde@wesnoth/umc-dev/misc/elynia] has quit [Nick collision from services.]
20090910 00:15:45-!- elynia [n=shyde@wesnoth/umc-dev/misc/elynia] has joined #wesnoth-dev
20090910 00:15:47< Soliton> either way it's impossible to tell, really.
20090910 00:16:23< norbert_> I Quake and Wesnoth
20090910 00:16:37< norbert_> both me and other people disconnect more in multiplayer Wesnoth
20090910 00:16:38< Crab_> Soliton: well, it's also possible to get a disconnect because of a firewall or nat router breaking connection on no-activity-in-X-seconds
20090910 00:16:49< norbert_> there are many people disconnecting in multiplayer Wesnoth
20090910 00:17:05< shadowmaster> haven't seen complaints about that yet though
20090910 00:17:13< noy> none here
20090910 00:17:17< norbert_> in fact, it's so common that if I play Colosseum with people and someone is a bit late playing with his unit, we usually assume someone disconnected
20090910 00:17:21< norbert_> it happens _all the time_
20090910 00:17:46< Soliton> 57% of statistics are made up on the spot.
20090910 00:17:49< shadowmaster> maybe you are just playing with people who don't have very stable connections
20090910 00:17:59< noy> norbert_: honestly I play _all the time_ too and I have not seen that many disconnects
20090910 00:18:37-!- elynia [n=shyde@wesnoth/umc-dev/misc/elynia] has quit [Client Quit]
20090910 00:19:12< Soliton> 75% of people with bad connections prefer playing wesnoth to quake, btw.
20090910 00:19:32< shadowmaster> I'll send that to the local newspapers!
20090910 00:21:33< Ivanovic> corn, deekay: do not forget to submit your SoC code to google
20090910 00:21:46< CIA-62> silene * r38561 /trunk/data/lua/wml-tags.lua: Adapted code to cope with vconfig objects.
20090910 00:22:14< Ivanovic> time for me to head off to bed, n8
20090910 00:23:28-!- shikadibot_ [n=shikadi@190.22.69.37] has joined #wesnoth-dev
20090910 00:23:36-!- shikadibot_ [n=shikadi@190.22.69.37] has quit [Client Quit]
20090910 00:24:55-!- elynia [n=shyde@wesnoth/umc-dev/misc/elynia] has joined #wesnoth-dev
20090910 00:28:44< Soliton> http://www.wesnoth.org/cgi-bin/collection3/bin/index.cgi?hostname=wesnoth.wesnoth.org&plugin=memory&plugin=processes&timespan=3600&action=show_selection&ok_button=OK
20090910 00:28:53< Soliton> i guess we really ran out of memory?
20090910 00:29:48< Soliton> the log shows one bad_alloc that got caught and ignored and then 5min later another one that terminated wesnothd.
20090910 00:29:54-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"]
20090910 00:30:11< Crab_> Soliton: it is strange that it run out of memory fairly quickly..
20090910 00:31:00< Soliton> it ran about 4 days. that's indeed not much.
20090910 00:32:14< Soliton> ah you mean http://www.wesnoth.org/cgi-bin/collection3/bin/graph.cgi?hostname=wesnoth.wesnoth.org;plugin=processes;plugin_instance=wesnothd-1.6;type=ps_rss;begin=-3600 ?
20090910 00:32:22< Crab_> Soliton: yes
20090910 00:32:44< Soliton> first bad alloc got caught 23:54:36
20090910 00:33:02< Soliton> second 23:58:04
20090910 00:33:26-!- Blueblaze [n=nick@adsl-76-202-22-1.dsl.hstntx.sbcglobal.net] has quit [Read error: 60 (Operation timed out)]
20090910 00:33:30< Soliton> so the memory increase after that is probably from writing the core file?
20090910 00:33:58< Crab_> Soliton: we can look at cpu usage to find this out
20090910 00:34:17< Soliton> cpu usage stopped on the second bad alloc pretty much.
20090910 00:34:52< Crab_> Soliton: yes, so after that is probably a core dump
20090910 00:35:42< Soliton> so ir could allocate ~500MB after the bad alloc was thrown...
20090910 00:35:54< Ivanovic> but what was using up this much ram *before*?
20090910 00:36:01< Soliton> more like 600MB even.
20090910 00:36:30< Soliton> Ivanovic: well, 1GB is fairly normal usage for wesnoth-1.6 i think.
20090910 00:36:58< Soliton> look at what apache2 is eating up. :-O
20090910 00:37:25-!- norbert_ [n=norbert_@82-171-70-54.ip.telfort.nl] has quit ["must... play... more... wesnoth"]
20090910 00:37:32< Crab_> Soliton: s.w.o. ?
20090910 00:37:57< Soliton> hmm?
20090910 00:38:14< Soliton> it's all on wesnoth.org if that's what you mean.
20090910 00:38:14< Ivanovic> anyway, time for bed
20090910 00:38:30< Crab_> Soliton: i.e., wesnoth.org apache runs as a frontend for many things - stats.wesnoth.org, forums, wiki, etc
20090910 00:39:02< Crab_> Soliton: so, I was wondering, requests to which part of wesnoth.org have caused such memory usage
20090910 00:39:40< Crab_> Soliton: since new stats uploading was enabled only a few days ago, in 1.7.5, I naturally think about 'is it some issue with it ?'
20090910 00:40:49< Soliton> i have no idea if the apache memory usage increased recently.
20090910 00:40:59< Crab_> anyway, using apache as a frontend is a bad idea. (specialized frontend server like nginx or lighttpd will be better in terms of memory usage)
20090910 00:42:37< Crab_> Soliton: is there a long-term graph of apache memory usage ?
20090910 00:43:10< Soliton> nope, i only enabled it a few days ago.
20090910 00:44:27< Soliton> either way if wesnothd was able to allocate 500+MB to save the core dump we didn't really run out of memory.
20090910 00:45:03< Crab_> Soliton: that machine has swap enabled ?
20090910 00:45:04< Soliton> which should result in an oom-killer run only anyway.
20090910 00:45:09< Soliton> yes.
20090910 00:45:28< Crab_> Soliton: so, it'll more like a wrong alloc size...
20090910 00:45:53-!- elynia [n=shyde@wesnoth/umc-dev/misc/elynia] has quit ["nyu"]
20090910 00:46:35-!- silene [n=plouf@wesnoth/developer/silene] has quit ["Leaving."]
20090910 00:47:10< Soliton> yes, but i'm out of ideas on how to track it down.
20090910 00:48:10< Crab_> Soliton: will it help, if you make it immediately dump core on bad allocation ?
20090910 00:49:24< Soliton> it might help if std::bad_alloc would tell me the requested size.
20090910 00:50:00< Soliton> otherwise i have to litter the code with try/catch blocks even more than it already is now.
20090910 00:50:01< Crab_> Soliton: well,if it'll *immediately* dump core, then the requested size would be in the dump..
20090910 00:51:00< Crab_> Soliton: e.g., not by spamming try-catch blocks, but by wrapping the memory allocator (i.e. 'do a nothrow alloc,if null, dump core')
20090910 00:51:33< Crab_> Soliton: then both the size and the stack trace will be available.
20090910 00:52:45< Soliton> is that much different?
20090910 00:54:26< Crab_> Soliton: 'requested size' part is not different at all
20090910 00:55:29< Crab_> Soliton: but (if I'm not mistaken) the stack would be unwinded when it will search for a suitable "catch" block to catch that bad_alloc
20090910 00:55:53< Soliton> yeah, that's why the core dumps i have are not muc use.
20090910 00:56:44< Crab_> Soliton: so, by dumping immediately at the failed alloc, we'll get better view at the server state.
20090910 00:58:43< Soliton> right, so similar to try/catch blocks i have to check for null all over the place, no?
20090910 00:59:59< corn> Ivanovic: ok, will do right now
20090910 01:00:14< Crab_> Soliton: well, it's possible to link with other memory allocator implementation, which will wrap standard one
20090910 01:04:22< cib0> hm, where can i find wmllint on debian?
20090910 01:04:34< Soliton> install wesnoth-tools
20090910 01:05:31< Soliton> so the last crash was in this code: http://nopaste.com/p/aX26c2Bkg
20090910 01:08:15< Soliton> bt: http://nopaste.com/p/azUz8zS6c
20090910 01:08:49< Soliton> i guess it doesn't show me where in the document constructor because it was inlined?
20090910 01:09:09< fabi> esr: There is still a task left for NR.
20090910 01:09:21< Crab_> probably, yes. that bt is not interesting (
20090910 01:09:40< cib0> Soliton: did.. ah, found it
20090910 01:10:42< Soliton> unfortunately that was with older code anyway which didn't have all the recently added try/catch blocks.
20090910 01:11:56< Soliton> it'd be really much easier to debug if std::bad_alloc would tell me the allocation size.
20090910 01:15:16< esr> fabi: What is needed?
20090910 01:17:48< stikonas> Chusslove: here?
20090910 01:18:05< Soliton> ah, that binary actually wasn't that old which makes me wonder why the bad alloc wasn't caught somewhere in simple_wml.
20090910 01:19:37< fabi> esr: I have replaced some of the story parts to new macros. But this is a annoying cut & paste orgy. Can you do that with the help of wmllint?
20090910 01:20:20< esr> fabi: Maybe, if you can define the conversion precisely enough.
20090910 01:20:57< Soliton> Crab_: so any ideas how to proceed?
20090910 01:20:58< stikonas> Chusslove: I'll email you lithuanian wesnoth--overlay.png (already optimized with optipng)
20090910 01:22:20< CIA-62> alink * r38562 /trunk/data/game_config.cfg: Fix r38526 forget to update the red_to_green_scale WML key
20090910 01:22:21< Crab_> Soliton: what about simply overriding 'operator new' with a wrapped version which will do 'standard new, nothrow edition, if got null, dump core' ?
20090910 01:24:25< Crab_> Soliton: since we're not messing with memory pools and simply delegating to old implementatin, then, replacing those several 'new' operators will give us a just-in-time backtrace, with allocation size sitting as a local variable at the top frame.
20090910 01:24:41-!- ardesh [n=ardesh@port-92-195-112-21.dynamic.qsc.de] has quit ["Quis custodiet ipsos custodes"]
20090910 01:25:11< stikonas> Chusslove: please wait a bit, I made 1 mistake
20090910 01:25:41< Soliton> Crab_: sounds good, no idea how to do that though so if you'd like to that that'd be great.
20090910 01:25:59< fabi> esr: Please have a look at scenario 08a. Every part that contains a background= must be converted to {STORY_PART_$name (the text)}
20090910 01:26:57< Crab_> Soliton: I can try to do that (when I'll have some free time this weekend). It's definitely doable (e.g. cjhopman has done something like this when profiling memory usage)
20090910 01:27:35 * Soliton checks whether cjhopman is around. :->
20090910 01:28:51< CIA-62> alink * r38563 /trunk/ (data/game_config.cfg src/game_config.cpp src/game_config.hpp): 
20090910 01:28:51< CIA-62> Add and use a second red-to-green color scale for font
20090910 01:28:51< CIA-62> (darker, adjusted to the not-fully-white color of normal wesnoth font)
20090910 01:29:52< Crab_> Soliton: note http://www.gnu.org/software/libtool/manual/libc/Hooks-for-Malloc.html
20090910 01:29:53< stikonas> esr: are you the maintainer of great-continent.xcf?
20090910 01:30:27-!- Blueblaze [n=nick@adsl-76-202-22-1.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20090910 01:30:52< stikonas> esr: Bitter Swamp parchment in various maps is in 2 different locations. Is this OK?
20090910 01:31:32< corn> has anyone run wesnoth through valgrind? I am sure that we have lots of little memory leaks that no one has ever noticed
20090910 01:31:45< CIA-62> alink * r38564 /trunk/src/game_display.cpp: After r38563, make def% on main map use again the old brighter colors
20090910 01:32:17< Crab_> corn: yes, there were some, afair. but it was months ago..
20090910 01:32:45< Crab_> corn: and there are no symptoms of a 'leak' here...
20090910 01:34:04< corn> Crab_: yes, I was just wondering about this, although valgrind catches other kinds of memory errors as well
20090910 01:34:25< Crab_> corn: well, we don't want the overhead of running wesnoth 1.6. mp server under valgrind :)
20090910 01:35:35< Soliton> Crab_: does new use malloc?
20090910 01:36:20< Crab_> Soliton: implementation-specific, afair
20090910 01:36:37< Crab_> Soliton: it might. new/delete can be overridden
20090910 01:41:26< deekay> Wasn't Sirp's work on pool_alloc based on malloc overloading?
20090910 01:42:13< cib0> hm... if i check a unit for, say. unit.hitpoints, i will get the base value without [object]s, right? any way to take into account [object]s?
20090910 01:45:58-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090910 01:52:17< alink> grmblm, I am starting to suspect that there is a RNG hidden in ThemeWML :-/
20090910 01:53:50-!- dlr365 [n=doug@S010600248c02a7d3.cg.shawcable.net] has joined #wesnoth-dev
20090910 01:55:29< Crab_> Soliton: is there any known stress test that can be used to get that error in wesnothd ?
20090910 01:57:01< CIA-62> fendrin * r38565 /trunk/data/campaigns/Legend_of_Wesmere/scenarios/ (19_Costly_Revenge.cfg 21_Elvish_Assassins.cfg): LoW 19,21: New code for Landar's side.
20090910 01:57:27< fabi> Crab_: I still get a duplicated Cleodil in scenario 21.
20090910 01:57:36< Crab_> fabi: how-to-reproduce ?
20090910 01:58:39< fabi> Crab_: svn update; start low ; debug to scenario 19 ; debug to 21
20090910 01:59:00< Crab_> fabi: svn up for wml-only changes?
20090910 02:01:14< CIA-62> alink * r38566 /trunk/data/themes/ (default.cfg experimental.cfg): 
20090910 02:01:14< CIA-62> Switch new terrain defense and moves in main sidebar,
20090910 02:01:14< CIA-62> (to place terrain def% next to weapons)
20090910 02:02:52< alink> my bad Mr ThemeWML, I just didn't noticed that you overwrite *some* values for other resolutions :-/
20090910 02:05:12< fabi> Crab_: yes
20090910 02:05:35< Crab_> fabi: unable to reproduce
20090910 02:05:38< Crab_> fabi: got 1 cleodil
20090910 02:05:38-!- mjs-de [n=mjs-de@vpw.wh.uni-dortmund.de] has quit ["On the road again"]
20090910 02:06:09< Crab_> svn up - start low - cl 19 - cl 21
20090910 02:07:08< fabi> Crab_: hmmm, must be on my side. Thank you.
20090910 02:08:02< Crab_> night
20090910 02:08:18-!- Crab_ [n=Crab_@wesnoth/developer/crab] has quit ["Leaving."]
20090910 02:09:41< Soliton> Crab_: bad_alloc was thrown when reloading this savegame files.wesnoth.org/soliton/Random_map_Turn_85_(4365).gz  but no idea if that reproduces it...
20090910 02:10:22-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"]
20090910 02:10:59-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection]
20090910 02:31:06< CIA-62> fendrin * r38567 /trunk/data/campaigns/Legend_of_Wesmere/scenarios/17_Breaking_the_siege.cfg: LoW 17: Made Uradreadia's side persistent.
20090910 02:32:12< CIA-62> fendrin * r38568 /trunk/data/campaigns/Legend_of_Wesmere/scenarios/22_Northern_Battle.cfg: LoW 22: Made Uradredia's side persistent. Gave him the loyals to the recall list.
20090910 02:47:45< cib0> what am i doing wrong.. i renamed a campaign, config file and its scenario.. cleared the cache.. but its still showing me the old version o.0
20090910 02:50:10< alink> cib0: bad directory ? user or mainline. And if build and installed yourself, then there is the build directory and the installed directory
20090910 02:51:01< cib0> alink: user.. deleting it completely and clearing the cache removes it, so im guessing im working on the right files
20090910 02:53:57< alink> "src/wesnoth --log-info=filesystem ."     show which files are parsed, maybe you will spot something there
20090910 02:54:59< cib0> alright, thanks
20090910 03:06:09< cib0> huh, what the heck, it is loading from atleast two different user directories o.0
20090910 03:07:32< Soliton> on windows?
20090910 03:07:50< cib0> nope, debian
20090910 03:08:02< alink> "two different users" directories or  two different "user directories" ?
20090910 03:08:03< Soliton> the same binary? nope.
20090910 03:08:30< Soliton> you can specify the dir with --config-dir or so though.
20090910 03:10:07< cib0> right, it isn't. it's just loading its data from somewhere unexpected
20090910 03:11:58< alink> I always thought that science-fiction should explore the theme of space-time portal in filesystem <:o)
20090910 03:13:30< alink> when i was a kid, I hacked FAT to show future date or impossible size on floppy disk. I remember that some easily impressed friend was very puzzled :-)
20090910 03:15:05< cib0> ... grep saves the day
20090910 03:15:18< cib0> there is another version of that scenario in ageless era
20090910 03:15:35< cib0> why is there a scenario in an era? that's overkill. whatever.
20090910 03:16:35< cib0> *deletes all scenarios in the era*
20090910 03:26:27< alink> cib0: I am pretty sure that --log-info=filesystem could show the source of this problem. To avoid wasted time hunting this, I'll go back ~20 min in the past to tell you about it
20090910 03:26:34< alink> :-)
20090910 03:27:03< cib0> alink, alright =)
20090910 03:27:33< alink> yeah, sorry, time-traveller have too much time on their hands ;-)
20090910 03:34:22-!- DDR is now known as DDR_away
20090910 03:39:51< cib0> hm.. is there a way in 1.6 to have the AI be really dumb and not do too much calculation before moving?
20090910 03:42:03< alink> I don't think so, but that's a nice FR for 1.8 AI parameters , allow fast-dumb AI. And possibly easy to implement.
20090910 03:42:09< alink> Crab_ ^
20090910 03:54:58< Soliton> hrm, still don't get why everything works fine in the game except the unit description gets all default values except for stuff that is overridden in the unit type config.
20090910 03:58:32< alink> Soliton: have you checked what movement_costs are stored in [unit] in the savegame file (to see if data are right but badly accessed)
20090910 04:00:15< Soliton> savegame data is fine.
20090910 04:00:28< Soliton> it's the same that is used in game which works fine.
20090910 04:01:22< alink> so the problem is just in help.cpp ?
20090910 04:01:37< Soliton> maybe.
20090910 04:01:42< alink> which uses unit_type only
20090910 04:03:00< Soliton> the funny thing is that also defense values get the defaults while i haven't touched those yet.
20090910 04:03:24< Soliton> i've only refactored movement_cost() so far.
20090910 04:03:29< alink> are you sure that current trunk doesn't have the bug too
20090910 04:04:01< Soliton> a good question i suppose. can you check?
20090910 04:04:55-!- DDR_away is now known as DDR
20090910 04:04:58< Soliton> it seems like it really can't be only from my changes.
20090910 04:05:44< alink> ok, can you point me a case potentially showing the problem ?
20090910 04:06:12< Soliton> any unit.
20090910 04:06:45< Soliton> only units that override the movetype values show some correct values.
20090910 04:06:55< Soliton> like the elvish ranger or the bat.
20090910 04:07:35< alink> All my elves seems fine, both for def% and MP cost
20090910 04:07:52< Soliton> ok.
20090910 04:09:02< Soliton> i'll update to HEAD and try again.
20090910 04:10:22< alink> i sometimes see a t->movement_type().get_parent()->get_cfg(), maybe you don't pass the good cfg in your new parameter
20090910 04:10:57< alink> mmh no it's in unit.cpp
20090910 04:11:49< alink> but there is also a parent system in unit_type
20090910 04:13:06< Soliton> is that for variations?
20090910 04:13:27< Soliton> i pass the parent pointer as a parameter as well though.
20090910 04:14:05< Soliton> and i tried setting it to NULL for the unit_movement_type call as well but that didn't change anything.
20090910 04:15:07< Soliton> i guess i could revert the unit_movement_type function back to the original and see if that fixes it to confirm that the problem is there..
20090910 04:16:11< alink> mmh if you pass the a non-const reference to the cache, is it possible that you clear it somewhere into the function ?
20090910 04:17:04< alink> note that it's a mutable, which can hide a const tricks
20090910 04:17:11< Soliton> the cache is a non-const reference indeed.
20090910 04:17:18< Soliton> yeah, i wondered about that.
20090910 04:18:35< Soliton> but i didn't change the logic since i just adapted the original function a bit to take the passed in parameters instead of the member variables.
20090910 04:21:21< alink> well, i am short of ideas, but if you paste the code maybe someone will spot some STL trap or something
20090910 04:23:00< Soliton> if i use a const reference i can still call insert on it?
20090910 04:23:14< Soliton> and what's the point of the const then?
20090910 04:24:01< alink> no you can't use a const there (that's why i knew that you used a non-const)
20090910 04:24:16< Soliton> right, ok.
20090910 04:27:34< alink> but you could put each cache system out of the movement_cost parsing function.
20090910 04:28:48< Soliton> http://nopaste.com/p/aRNeXLrX1  that's the unified function.
20090910 04:29:30< Soliton> should be pretty much the same as either of the currently used functions.
20090910 04:30:57< Soliton> how it's getting called: http://nopaste.com/p/axYi0Cnc7
20090910 04:36:47< Soliton> the help and the ai seem to be the only code that calls the movement_type part.
20090910 04:40:19< alink> I can't see the problem
20090910 04:40:36< crimson_penguin> Ivanovic: Behdad replied to my mail, just saying "CC'ing gtk-i18n-list so you get feedback from Pango OS X developers."
20090910 04:41:26< alink> wait you changed a int res = -1; into int res = impassable
20090910 04:41:43< Soliton> yes, that part was not in sync before.
20090910 04:41:45< alink> and there is a if res <= 0 later
20090910 04:41:58< Soliton> that only made the help wrong.
20090910 04:43:05< Soliton> because it made it so when you don't specify a movement cost it'd get -1 instead of impassable (like for unit) and would later change to 0 meaning 100% defense.
20090910 04:43:30< Soliton> so the help would show 100% defense while it was really 0%.
20090910 04:44:04< Soliton> that was what started me in removing the code duplication... ;-)
20090910 04:45:21< alink> but in your code when the " res = parent->movement_cost(map, terrain);" is reached ?
20090910 04:46:21< Soliton> hmm, good point.
20090910 04:46:37< Soliton> maybe this parent stuff is important. :-P
20090910 04:47:08< Soliton> so indeed now that is never reached even if parent is non-null.
20090910 04:47:55< Soliton> i wonder if <= 0 has any relevance though.. i guess i can just test for impassable now.
20090910 04:48:27< Soliton> hmm, or maybe it has to be an invalid value?
20090910 04:48:59< alink> yes parent seems to be the actual basic movement_type defined for the unit_type
20090910 04:49:04< Soliton> though -1 isn't really invalid either...
20090910 04:49:12< Soliton> ahhh
20090910 04:49:29< alink> -1 break the pathfinding but i think we check it later
20090910 04:49:38< alink> but probably with assert
20090910 04:49:48< Soliton> i think i can leave it as impassable.
20090910 04:50:05< Soliton> the atoi can be either if we're unlucky.
20090910 04:52:06< Soliton> ok, now the movement costs show right.
20090910 04:52:17< alink> "i guess i can just test for impassable now" <- must be sure that we don't use the c++ impassable value in WML
20090910 04:52:41< Soliton> alink: as much as we need to be sure not to use -1 in WML.
20090910 04:52:53< alink> indeed :-)
20090910 04:53:38< Soliton> if we want to be sure we should use a different value to remember whether we did the atoi or not.
20090910 04:53:40< alink> but i mean if i define impassible, i don't want the parent overwrite my value
20090910 04:54:00< alink> but if i use invalid -1, i need to be overwrited  
20090910 04:54:00< Soliton> yeah ok, i'll fix that.
20090910 04:54:22< Soliton> wait, do you mean the -1 had any use?
20090910 04:54:38< Soliton> if i want it overwritten i just leave it out, no?
20090910 04:55:24< Soliton> seems to me the parent call should just be done if the value is not empty.
20090910 04:55:29< Soliton> err, empty.
20090910 04:56:23< alink> the -1 indicated that we don't find anything, if you replace it by impassable, there is a small confusion with the case where we found something=impassable
20090910 04:56:36< Soliton> i want to replace it by nothing.
20090910 04:57:01< Soliton> just ask the parent right when we don't find a value in the config.
20090910 04:57:12< alink> seems good too
20090910 04:57:31< Soliton> that -1 hack was just not neccessary.
20090910 04:58:07< Soliton> thanks for finding that though!
20090910 04:58:13< alink> np
20090910 04:59:01< alink> since you are rewriting it, could as well cache try to cache  the "return impassable;" seems that any WML causing this  error could slow things down by being never cached
20090910 04:59:41< alink> not really sure what the error is, so maybe not important
20090910 04:59:50< Soliton> indeed.
20090910 05:00:07< Soliton> no point in coming to the same conclusion again, i suppose.
20090910 05:00:25< alink> plus it will flood errors
20090910 05:00:36< Soliton> especially when i plan to remove the explicit impassable values from WML.
20090910 05:04:21 * alink afk
20090910 05:17:00< Soliton> oh, we actually have to ask the parent also when there was no override in the cfg..
20090910 05:22:03-!- cib__ [n=cib@p5DC435F9.dip.t-dialin.net] has joined #wesnoth-dev
20090910 05:31:47-!- silene [n=plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20090910 05:39:02-!- cib0 [n=cib@p5DD34904.dip.t-dialin.net] has quit [Read error: 101 (Network is unreachable)]
20090910 05:40:56< cib__> does the advance event trigger after an AMLA?
20090910 05:56:11-!- Chusslove [n=Chusslov@brsg-d9bef920.pool.mediaWays.net] has quit [Read error: 110 (Connection timed out)]
20090910 05:56:15< silene> no, it triggers before, its post advance that triggers after
20090910 06:00:05< cib__> eh, more precisely: do the advance events trigger before/after an AMLA? :p
20090910 06:00:56< cib__> i already did a work around, checking whether the unit is maximum level in advance, saving that in a var, then using that in post advance
20090910 06:03:12-!- Chusslove [n=Chusslov@brsg-d9beec37.pool.mediaWays.net] has joined #wesnoth-dev
20090910 06:13:27< Soliton> alink: would it be bad for path finding if i make the impassable value for unit_movement_type 99 (unit_movement_type::UNREACHABLE) as well?
20090910 06:15:11< alink> I don't think it's a problem
20090910 06:16:00< Soliton> ok, wouldn't be difficult to increase anyway.
20090910 06:16:08< alink> well currently 99 is a bit low, but that's because we still don't use max_movement of unit, which we should do
20090910 06:18:12< alink> i hope some UMC don't give 100 MP to unit :-)
20090910 06:19:36< Soliton> there is UMC where you can buy MP... ;-)
20090910 06:20:00< Soliton> i think 100 is a bit much still though.
20090910 06:20:51< alink> anyway, for the patfinding, after that i add the check against max_movement, all MP cost > max_cost will be translated to GetNoPathValue=42424242
20090910 06:21:44< alink> but as often there is details to check  (current MP > max_MP,  slowed units etc..)
20090910 06:21:46< Soliton> makes sense.
20090910 06:27:18< alink> doesn't matter, but I see that slowed unit will see impassable as 99*2 MP cost
20090910 06:27:42< alink> really impassable :)
20090910 06:29:01< Soliton> well, i can skip the slowed check when impassable is returned.
20090910 06:30:04< Soliton> seems like that'd be better?
20090910 06:31:36< alink> I suppose, it's also a little optimization, but OTOH Crab_ has well optimized the slow check
20090910 06:32:42< alink> it's just that i suspect that if some future code start yo check movement_cost against the now standard 99, slow will bite
20090910 06:32:52< alink> s/yo/to
20090910 06:32:56< Soliton> yeah, exactly.
20090910 06:33:19-!- dlr365 [n=doug@S010600248c02a7d3.cg.shawcable.net] has quit [Remote closed the connection]
20090910 06:35:08< alink> btw, it's too late, but this slow rule always seems odd to me, reducing max_cost look simpler
20090910 06:35:21< alink> s/max_cost/max_movement
20090910 06:38:05< Soliton> then you have to deal with rounding though.
20090910 06:39:27< alink> well, if have odd max_moves and all terrain_cost are doubled and thus are even, you will always waste 1MP, so in fact there is already a hidden rounding
20090910 06:40:11-!- silene [n=plouf@wesnoth/developer/silene] has quit [Read error: 110 (Connection timed out)]
20090910 06:40:36-!- silene [n=plouf@ASte-Genev-Bois-152-1-55-206.w82-121.abo.wanadoo.fr] has joined #wesnoth-dev
20090910 06:40:54< Soliton> if all terrain_costs are integers. :-P
20090910 06:44:14 * alink doesn't comment because he is the one having introduced (internally) fractional movement cost into pathfinding ;-)
20090910 06:55:23< CIA-62> soliton * r38569 /trunk/data/core/units/drakes/ (Hurricane.cfg Sky.cfg): fixed messed up formatting
20090910 06:55:28< CIA-62> soliton * r38570 /trunk/ (6 files in 3 dirs): 
20090910 06:55:28< CIA-62> * changed the Drake Glider movetype to have 40% defense almost everywhere
20090910 06:55:28< CIA-62> macrofied some similar movetypes along the way
20090910 06:55:33< CIA-62> soliton * r38571 /trunk/data/core/ (units/monsters/Cave_Spider.cfg units.cfg): some more movetype refactoring
20090910 06:55:40< CIA-62> soliton * r38572 /trunk/src/ (unit.cpp unit.hpp unit_types.cpp unit_types.hpp): unified movement_cost and defense_modifer functions from unit and unit_type fixing a couple of bugs and inconsistencies along the way
20090910 06:55:50< CIA-62> soliton * r38573 /trunk/data/core/units.cfg: removed all UNREACHABLE terrain definitions from [movetype]s since the built-in defaults work just as well
20090910 06:57:31< CIA-62> soliton * r38574 /branches/1.6/src/server/simple_wml.cpp: more debugging code...
20090910 06:58:32< CIA-62> soliton * r38575 /trunk/src/server/simple_wml.cpp: more debugging code...
20090910 06:58:37 * alink will check the final result later
20090910 07:00:43< alink> now i want to try my new time-travel machine. I set it to ~12h into the future.
20090910 07:01:05< alink> See you later (and in few seconds for me)
20090910 07:01:12< alink> Zaaap
20090910 07:01:14-!- alink [n=alink@wesnoth/developer/alink] has quit [Remote closed the connection]
20090910 07:01:57< Soliton> i'll try that machine as well.
20090910 07:27:56-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has quit []
20090910 07:28:45-!- valgor [i=596fb03c@gateway/web/freenode/x-mxebnznperlvmsan] has joined #wesnoth-dev
20090910 07:31:46-!- valgor [i=596fb03c@gateway/web/freenode/x-mxebnznperlvmsan] has quit [Ping timeout: 180 seconds]
20090910 07:39:27-!- DDR [n=chatzill@66.183.125.196] has quit ["Time flies like an arrow. Fruit files like a bannana."]
20090910 08:21:37-!- zookeeper [n=l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20090910 08:32:34-!- ancestral [n=ancestra@97-116-118-217.mpls.qwest.net] has joined #wesnoth-dev
20090910 08:32:59-!- stikonas [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20090910 08:43:36-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090910 08:47:53< CIA-62> silene * r38576 /trunk/ (changelog data/lua/wml-tags.lua src/scripting/lua.cpp): Simplified handling of superseded WML action handlers.
20090910 08:47:57< CIA-62> silene * r38577 /trunk/src/scripting/lua.cpp: Typo.
20090910 08:48:03< CIA-62> silene * r38578 /trunk/src/scripting/lua.cpp: Stopped polluting the lua_ namespace. Made function roles clearer.
20090910 08:48:07< CIA-62> silene * r38579 /trunk/src/scripting/lua.cpp: Rewrote wml_config_of_table in a Lua style.
20090910 08:48:16< CIA-62> silene * r38580 /trunk/src/scripting/lua.cpp: Factored metatable detection.
20090910 08:48:20< CIA-62> silene * r38581 /trunk/src/scripting/lua.cpp: Optimized access to the registry.
20090910 08:53:10-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has joined #wesnoth-dev
20090910 09:00:48-!- euschn [n=chatzill@wesnoth/developer/euschn] has joined #wesnoth-dev
20090910 09:03:19< CIA-62> caslav_ilic * r38582 /trunk/ (5 files in 2 dirs): Updated localized images for Lithuanian.
20090910 09:24:14-!- ancestral [n=ancestra@97-116-118-217.mpls.qwest.net] has quit ["And that’s the end of THAT chapter."]
20090910 09:49:10-!- silene [n=plouf@wesnoth/developer/silene] has quit ["Leaving."]
20090910 10:06:20-!- stikonas [n=and@ctv-213-164-125-176.vinita.lt] has joined #wesnoth-dev
20090910 10:07:18< Ivanovic> moin
20090910 10:08:25-!- cib__ [n=cib@p5DC435F9.dip.t-dialin.net] has quit [Remote closed the connection]
20090910 10:10:21-!- noy [n=Noy@wesnoth/developer/noy] has quit []
20090910 10:33:17-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090910 10:42:51-!- Blueblaze [n=nick@adsl-76-202-22-1.dsl.hstntx.sbcglobal.net] has quit [Remote closed the connection]
20090910 10:48:12-!- fabi [n=fabi@wesnoth/developer/fendrin] has quit [Remote closed the connection]
20090910 11:06:24-!- mjs-de [n=mjs-de@vpw.wh.uni-dortmund.de] has joined #wesnoth-dev
20090910 11:38:53< Ivanovic> Rhonda: what is the status of 1.6.5 in debian?
20090910 11:39:54< Rhonda> uploaded? :)
20090910 11:40:05< Rhonda> http://Packages.debian.org/unstable/wesnoth-core
20090910 11:40:31< Ivanovic> ah, nice
20090910 11:40:50< Rhonda> amd64 + i386 are also already built and in the pool.
20090910 11:42:44-!- loonybot [n=loonybot@79.139.139.133] has joined #wesnoth-dev
20090910 11:43:30-!- loonycyborg [n=sergey@79.139.139.133] has joined #wesnoth-dev
20090910 11:49:09-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has quit ["leaving"]
20090910 11:51:28-!- YogiHH [i=d4ca9d15@wesnoth/developer/yogihh] has joined #wesnoth-dev
20090910 11:51:40< YogiHH> hello
20090910 11:52:32< CIA-62> ivanovic * r38583 /branches/1.6/changelog: ups, forgot to bump the (normal) changelogs version to 1.6.5... (no, I will not retag because of this!)
20090910 11:54:13-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has joined #wesnoth-dev
20090910 12:12:59< Ivanovic> 1.6.5 announcement: http://www.wesnoth.org/forum/viewtopic.php?f=5&t=27026
20090910 12:20:44-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has quit ["leaving"]
20090910 12:25:20-!- fendrin [n=fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20090910 12:59:58-!- euschn [n=chatzill@wesnoth/developer/euschn] has quit ["ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]"]
20090910 13:28:16-!- Ivanovic changed the topic of #wesnoth-dev to: 92 bugs, 243 feature requests, 12 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20090910 13:28:44< Ivanovic> Soliton: have you already updated the motd on the server(s) listing 1.6.5 as latest stable release?
20090910 13:45:30< Ivanovic> the frontpage is updated
20090910 14:22:36-!- stikonas [n=and@ctv-213-164-125-176.vinita.lt] has joined #wesnoth-dev
20090910 14:23:18-!- ardesh [n=ardesh@port-92-195-108-200.dynamic.qsc.de] has joined #wesnoth-dev
20090910 14:29:16< Soliton> Ivanovic: nope, i'm not listing latest release for 1.6.
20090910 14:34:40-!- EdB [n=edb@79.95.12.19] has joined #wesnoth-dev
20090910 14:43:41-!- happygrue [n=George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20090910 14:45:41-!- happygrue_ [n=George@c-67-176-145-41.hsd1.in.comcast.net] has joined #wesnoth-dev
20090910 14:47:12-!- happygrue [n=George@wesnoth/developer/wintermute] has quit [Read error: 104 (Connection reset by peer)]
20090910 14:48:35-!- happygrue [n=George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20090910 14:49:20-!- happygrue__ [n=George@c-67-176-145-41.hsd1.in.comcast.net] has joined #wesnoth-dev
20090910 14:49:21-!- happygrue [n=George@wesnoth/developer/wintermute] has quit [Read error: 104 (Connection reset by peer)]
20090910 14:50:07-!- happygrue_ [n=George@c-67-176-145-41.hsd1.in.comcast.net] has quit [Read error: 104 (Connection reset by peer)]
20090910 14:54:22-!- YogiHH [i=d4ca9d15@wesnoth/developer/yogihh] has left #wesnoth-dev []
20090910 14:58:31-!- happygrue__ [n=George@c-67-176-145-41.hsd1.in.comcast.net] has quit [Read error: 104 (Connection reset by peer)]
20090910 14:59:15-!- happygrue [n=George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20090910 15:00:02< Ivanovic> Soliton: ah, okay
20090910 15:21:20< Ivanovic> corn: i updated the summary of your code tarball
20090910 15:21:44< Ivanovic> corn: if i understood things correctly they were meant to be named accordingly to the (sub)project name in gsoc
20090910 15:22:02< Ivanovic> deekay: your tarball ist still missing, please do not forget to upload it
20090910 15:22:12< deekay> Ivanovic: No worries
20090910 15:22:18< deekay> I'll upload it tomorrow
20090910 15:22:21< Ivanovic> okay
20090910 15:22:47< Ivanovic> just want to be sure that you don't start complaining along the lines of "hey, why does crab_ already have his shirt and mine is not here?!?"
20090910 15:22:49< Ivanovic> ;)
20090910 15:32:55< Ivanovic> fendrin: for you or some engine bug (eg for silene)? https://gna.org/bugs/index.php?14270
20090910 15:41:01-!- happygrue_ [n=George@c-67-176-145-41.hsd1.in.comcast.net] has joined #wesnoth-dev
20090910 15:41:40-!- happygrue [n=George@wesnoth/developer/wintermute] has quit [Read error: 104 (Connection reset by peer)]
20090910 16:14:07-!- Sirp [n=user@wesnoth/developer/dave] has joined #wesnoth-dev
20090910 16:16:56-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090910 16:17:32-!- stikonas [n=and@ctv-213-164-125-176.vinita.lt] has joined #wesnoth-dev
20090910 16:25:52< Soliton> fendrin: http://www.wesnoth.org/forum/viewtopic.php?f=2&t=27028  sounds good to me.
20090910 16:26:26-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 104 (Connection reset by peer)]
20090910 16:26:46-!- stikonas [n=and@ctv-213-164-125-176.vinita.lt] has joined #wesnoth-dev
20090910 16:28:50-!- EdB [n=edb@79.95.12.19] has quit [Remote closed the connection]
20090910 16:46:33< fendrin> Soliton: :-)
20090910 16:48:37< Ivanovic> loonycyborg: can you have a look at #wesnoth
20090910 16:48:44< Ivanovic> [16:46:35] <kaan_> hi, i'm having serious sound lag with wesnoth 1.6.5 under windows, i tryed changing sample rate and sound buffer and it didn't help.
20090910 17:05:35-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20090910 17:08:44-!- rosso_ [n=rosso@dslb-088-070-093-041.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)]
20090910 17:16:56< loonycyborg> http://www.wesnoth.org/forum/viewtopic.php?p=383379#p383379 <- Man! That's some thread necromancy :P
20090910 17:20:48-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has joined #wesnoth-dev
20090910 17:22:51-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090910 17:23:53< Ivanovic> pah, only something more than 3 years
20090910 17:23:59< Ivanovic> not this much of necromancy
20090910 17:24:01< Ivanovic> ;)
20090910 17:24:53-!- stikonas [n=and@ctv-213-164-125-176.vinita.lt] has joined #wesnoth-dev
20090910 17:25:10-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090910 17:25:41-!- stikonas [n=and@ctv-213-164-125-176.vinita.lt] has joined #wesnoth-dev
20090910 17:34:12-!- DDR [n=chatzill@66.183.125.196] has joined #wesnoth-dev
20090910 17:36:50-!- rosso [n=rosso@dslb-088-070-068-063.pools.arcor-ip.net] has joined #wesnoth-dev
20090910 18:01:01-!- blarumyrran [n=minaise@81-20-159-197.levira.ee] has joined #wesnoth-dev
20090910 18:03:40-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["KVIrc 3.4.2 Shiny http://www.kvirc.net/"]
20090910 18:04:07-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection]
20090910 18:06:57< blarumyrran> the tile images used by [map] tag on the forum could use an update
20090910 18:32:12-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20090910 18:42:29-!- Noyga [n=lame-z@AVelizy-151-1-61-203.w82-124.abo.wanadoo.fr] has joined #wesnoth-dev
20090910 18:47:01-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20090910 19:19:38-!- noy [n=Noy@wesnoth/developer/noy] has quit [Read error: 131 (Connection reset by peer)]
20090910 19:22:12-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20090910 19:26:11-!- mordante [n=mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20090910 19:26:26< mordante> servus
20090910 19:29:57-!- noy [n=Noy@wesnoth/developer/noy] has quit [Read error: 60 (Operation timed out)]
20090910 19:30:00< fendrin> hi mordante
20090910 19:30:35< mordante> hi fendrin 
20090910 19:41:41-!- happygrue_ [n=George@c-67-176-145-41.hsd1.in.comcast.net] has quit [Remote closed the connection]
20090910 19:51:36-!- lizard_r [n=Miranda@wesnoth/umc-dev/developer/lizard] has joined #wesnoth-dev
20090910 20:01:51-!- rosso [n=rosso@dslb-088-070-068-063.pools.arcor-ip.net] has quit [Remote closed the connection]
20090910 20:16:22< CIA-62> mordante * r38584 /trunk/src/gui/dialogs/campaign_selection.cpp: Left find_widget() do the valiation.
20090910 20:16:28< CIA-62> mordante * r38585 /trunk/src/gui/dialogs/field.hpp: Left find_widget() do the valiation.
20090910 20:16:36< CIA-62> mordante * r38586 /trunk/src/gui/dialogs/lobby_main.cpp: Left find_widget() do the valiation.
20090910 20:16:43< CIA-62> mordante * r38587 /trunk/src/gui/dialogs/message.cpp: Left find_widget() do the valiation.
20090910 20:16:49< CIA-62> mordante * r38588 /trunk/src/gui/dialogs/mp_create_game.cpp: Left find_widget() do the valiation.
20090910 20:16:57< CIA-62> mordante * r38589 /trunk/src/gui/dialogs/transient_message.cpp: Left find_widget() do the valiation.
20090910 20:17:06< CIA-62> mordante * r38590 /trunk/src/gui/dialogs/wml_message.cpp: Left find_widget() do the valiation.
20090910 20:28:36-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090910 20:29:05-!- stikonas [n=and@ctv-213-164-125-176.vinita.lt] has joined #wesnoth-dev
20090910 20:37:10-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has joined #wesnoth-dev
20090910 20:55:34-!- silene [n=plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20090910 20:55:45< silene> hi
20090910 20:57:01< Ivanovic> hi silene
20090910 20:58:24-!- Noyga [n=lame-z@wesnoth/developer/noyga] has left #wesnoth-dev ["Quitte"]
20090910 21:03:54< mordante> hi silene 
20090910 21:06:44-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20090910 21:32:57-!- giusef [n=giusef@unaffiliated/giusef] has joined #wesnoth-dev
20090910 21:35:28-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090910 21:37:18-!- stikonas [n=and@213.164.125.176] has joined #wesnoth-dev
20090910 21:39:31-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090910 21:44:40-!- stikonas [n=and@ctv-213-164-125-176.vinita.lt] has joined #wesnoth-dev
20090910 21:45:04-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090910 21:51:49-!- stikonas [n=and@ctv-213-164-125-176.vinita.lt] has joined #wesnoth-dev
20090910 22:06:15< mordante> shadowmaster, the font sizes for the new storyscreens are hard coded and not even ifdeffed for TINYGUI
20090910 22:07:04< mordante> shadowmaster, would be nice to use a standard from either gui or gui2 
20090910 22:07:13< mordante> shadowmaster, (preferably the latter but might be harder since it's a macro)
20090910 22:07:37< mordante> fendrin, ^
20090910 22:11:14< mordante> I'm off night
20090910 22:11:52-!- mordante [n=mordante@wesnoth/developer/mordante] has quit ["Leaving"]
20090910 22:20:40-!- silene [n=plouf@wesnoth/developer/silene] has quit ["Leaving."]
20090910 22:22:19-!- DDR is now known as DDR_away
20090910 22:23:05-!- loonybot [n=loonybot@79.139.139.133] has joined #wesnoth-dev
20090910 22:24:04-!- loonycyborg [n=sergey@79.139.139.133] has joined #wesnoth-dev
20090910 22:30:27-!- Blueblaze [n=nick@adsl-76-202-22-1.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20090910 22:39:28-!- DDR_away is now known as DDR
20090910 22:41:05-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090910 22:48:31-!- stikonas [n=and@ctv-213-164-125-176.vinita.lt] has joined #wesnoth-dev
20090910 23:06:16-!- zookeeper [n=l@wesnoth/developer/zookeeper] has quit []
20090910 23:17:55-!- blarumyrran [n=minaise@81-20-159-197.levira.ee] has quit []
20090910 23:18:03-!- noy [n=Noy@wesnoth/developer/noy] has quit [Read error: 110 (Connection timed out)]
20090910 23:31:29-!- Blueblaze [n=nick@adsl-76-202-22-1.dsl.hstntx.sbcglobal.net] has quit [Remote closed the connection]
20090910 23:35:11-!- Appleman1234 [n=Appleman@131.181.100.205] has joined #wesnoth-dev
20090910 23:44:24-!- giusef [n=giusef@unaffiliated/giusef] has quit ["exit (-1);"]
20090910 23:50:19-!- lizard_r [n=Miranda@wesnoth/umc-dev/developer/lizard] has quit ["Saurian Augur - I'll heal you by 4 hp if you leave next to me"]
20090910 23:55:47-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 54 (Connection reset by peer)]
20090910 23:57:58-!- Sapient [n=patrickp@wesnoth/developer/sapient] has joined #wesnoth-dev
20090910 23:58:42-!- stikonas [n=and@ctv-213-164-125-176.vinita.lt] has joined #wesnoth-dev
--- Log closed Fri Sep 11 00:00:09 2009