--- Log opened Fri Jul 16 00:00:07 2010
20100716 00:08:27-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20100716 00:09:19-!- silene [~plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20100716 00:25:46< shadowmaster> Espreon: this will interest you: http://forums.wesnoth.org/viewtopic.php?p=442147#p442147
20100716 00:27:01< Espreon> Jeß jeß...
20100716 00:27:29< Espreon> I'll take care of it soon...
20100716 00:29:16-!- Blueblaze [~Blueblaze@adsl-76-202-21-28.dsl.hstntx.sbcglobal.net] has quit [Ping timeout: 276 seconds]
20100716 00:35:27-!- Blueblaze [~Blueblaze@adsl-76-202-21-28.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100716 00:37:58< CIA-87> espreon * r44207 /trunk/utils/java/ (68 files in 19 dirs): Ran umcpropfix and dos2unix.
20100716 00:41:53-!- silene [~plouf@wesnoth/developer/silene] has quit [Ping timeout: 260 seconds]
20100716 00:43:32< CIA-87> espreon * r44208 /trunk/data/core/images/terrain/foreground.png: Ran umcpropfix.
20100716 00:45:27< CIA-87> espreon * r44209 /trunk/images/arrows/ (teleport-in.png teleport-out.png): Ran umcpropfix.
20100716 01:03:10-!- _jbx_ [~jbailey@12.190.80.225] has quit [Quit: Dig that hole, forget the sun.]
20100716 01:04:03-!- Blueblaze [~Blueblaze@adsl-76-202-21-28.dsl.hstntx.sbcglobal.net] has quit [Quit: Blueblaze]
20100716 01:10:24-!- Blueblaze [~Blueblaze@adsl-76-202-21-28.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100716 01:10:48-!- ne0futur [~neofutur@pdpc/supporter/student/ne0futur] has joined #wesnoth-dev
20100716 01:11:10-!- Blueblaze [~Blueblaze@adsl-76-202-21-28.dsl.hstntx.sbcglobal.net] has quit [Client Quit]
20100716 01:11:20< ne0futur> I think theres a bug in the httt campaign, after defeating the griffin and taking the eggs, you are not able to recruit griffins
20100716 01:11:37< ne0futur> it was working the last time i made the campaign 1 or 2 years ago
20100716 01:14:52-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100716 01:18:40-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Ping timeout: 258 seconds]
20100716 01:21:18-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100716 01:24:27-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Ping timeout: 245 seconds]
20100716 01:32:54< jbjerk> ne0futur: you don't get to use gryphons until several scenarios later
20100716 01:33:59< jbjerk> ealier versions of HttT had gryphons come in sooner
20100716 01:35:00-!- jbjerk is now known as eleazar
20100716 01:42:04< ne0futur> ah ok ! I ll go further so ! thanks for your answer , i wanted a feedback/confirmation before creating a bug report
20100716 01:43:28-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has quit [Ping timeout: 240 seconds]
20100716 01:45:05-!- phlaem [~a@e178094009.adsl.alicedsl.de] has quit [Quit: Leaving]
20100716 01:51:13-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20100716 01:52:29< ne0futur> PS: the griffins were pretty useful for the Abez ford crossing ;( this makes the campaign harder ;(
20100716 01:55:23-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100716 01:57:55< CIA-87> espreon * r44210 /trunk/src/multiplayer_ui.o.d4RZjo: Smote an object/whatever file.
20100716 01:59:34 * Espreon glares at alink 
20100716 02:00:58< alink> oops sorry
20100716 02:01:04< alink> Espreon: thanks
20100716 02:01:23< Espreon> You're welcome.
20100716 02:01:37< alink> I indeed fought a bit with git for this commit
20100716 02:01:57< Espreon> Oh?
20100716 02:02:00< alink> git stash is nice but the interface could use some improvements
20100716 02:02:19< Espreon> Indeed.
20100716 02:24:09-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20100716 02:28:14-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has quit [Remote host closed the connection]
20100716 02:29:30< CIA-87> alink * r44211 /trunk/src/ (4 files): Clean and improves tab-completion: use units names when doing a search
20100716 02:29:32< CIA-87> alink * r44212 /trunk/src/ (menu_events.cpp menu_events.hpp play_controller.cpp): Tab-completion for :commands
20100716 02:29:40< alink> \o/
20100716 02:30:48< alink> and now I may add :debug_command_with_very_long_name ;-p
20100716 02:32:01< alink> btw console_handler code is a good example of crazy use of OO
20100716 02:32:45< alink> you need to study the whole class hierarchy and all its little quirks, just to plug a small isolated function
20100716 02:33:07< alink> and the compiler always complains about weird stuff
20100716 02:35:59-!- Gambit_ [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100716 02:37:28-!- Gambit is now known as Guest71208
20100716 02:38:14-!- Guest71208 [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Ping timeout: 240 seconds]
20100716 02:38:15-!- Gambit_ is now known as Gambit
20100716 02:44:30-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has quit [Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz]
20100716 02:53:08-!- mjs-de [~mjs-de@vpw.wh.uni-dortmund.de] has quit [Remote host closed the connection]
20100716 02:54:47-!- Appleman1234 [~Appleman1@CPE-60-226-176-19.qld.bigpond.net.au] has joined #wesnoth-dev
20100716 02:58:05-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20100716 03:29:36-!- Daltx [~Daltx@unaffiliated/daltx] has quit []
20100716 03:31:18-!- mordocai [~mordocai@66.119.9.243] has joined #wesnoth-dev
20100716 03:39:13-!- Daltx [~Daltx@unaffiliated/daltx] has joined #wesnoth-dev
20100716 03:43:43-!- alink [~alink@wesnoth/developer/alink] has quit [Remote host closed the connection]
20100716 04:16:33-!- Upth is now known as Upthorn
20100716 04:17:11-!- shadowm_laptop2 [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100716 04:18:36-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Disconnected by services]
20100716 04:18:43-!- shadowm_laptop2 is now known as shadowm_laptop
20100716 04:24:16-!- wesbot changed the topic of #wesnoth-dev to: 144 bugs, 282 feature requests, 15 patches | logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100716 04:33:26-!- KylePoole [45a4d2b5@gateway/web/freenode/ip.69.164.210.181] has joined #wesnoth-dev
20100716 04:38:36-!- Ivanovic_ [~ivanovic@dtmd-4db2c597.pool.mediaWays.net] has joined #wesnoth-dev
20100716 04:41:41< Sirp> hi KylePoole 
20100716 04:42:07-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 276 seconds]
20100716 04:42:34-!- Ivanovic_ is now known as Ivanovic
20100716 04:43:07< KylePoole> hello hello
20100716 04:47:56< crimson_penguin> hi KylePoole 
20100716 04:48:09-!- rusty [~rusty2@ppp118-210-39-37.lns20.adl2.internode.on.net] has joined #wesnoth-dev
20100716 04:48:27< rusty> KylePoole: Nice to meet you :)
20100716 04:48:28< KylePoole> hi crimson_penguin
20100716 04:48:35< KylePoole> hello there rusty
20100716 04:48:39< Espreon> Hello rusty.
20100716 04:48:53< shadowmaster> hi rusty!
20100716 04:49:11< rusty> shadowmaster: hi!  Long time no chat!
20100716 04:49:16< shadowmaster> please sign this printed copy of the modprobe man page :p
20100716 04:49:21< shadowmaster> (just kidding)
20100716 04:49:33< rusty> shadowmaster: at least it's not a body part! :)
20100716 04:50:16< crimson_penguin> hey rusty 
20100716 04:50:26< rusty> Hi crimson_penguin.
20100716 04:50:33 * crimson_penguin probably never really talked to rusty before, but vaguely remembers the name
20100716 04:50:55< rusty> crimson_penguin: I'm old... I play Wesnoth on a vt100.
20100716 04:51:10 * crimson_penguin isn't sure that's possible
20100716 04:51:22< shadowmaster> aalib
20100716 04:51:27< shadowmaster> libcaca, too
20100716 04:51:30< crimson_penguin> I suppose
20100716 04:51:42< crimson_penguin> I've been vaguely involved in Wesnoth for quite a long time myself
20100716 04:53:42-!- ancestral [~ancestral@97-116-113-21.mpls.qwest.net] has joined #wesnoth-dev
20100716 04:56:57-!- ancestral [~ancestral@97-116-113-21.mpls.qwest.net] has quit [Client Quit]
20100716 05:06:03-!- silene [~plouf@bau91-1-82-239-244-109.fbx.proxad.net] has joined #wesnoth-dev
20100716 05:06:03-!- silene [~plouf@bau91-1-82-239-244-109.fbx.proxad.net] has quit [Changing host]
20100716 05:06:03-!- silene [~plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20100716 05:06:10-!- silene [~plouf@wesnoth/developer/silene] has quit [Client Quit]
20100716 05:27:07-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Read error: Connection reset by peer]
20100716 05:43:28-!- Elvish_Pillager [~eli@71-10-224-192.dhcp.oxfr.ma.charter.com] has quit [Ping timeout: 260 seconds]
20100716 05:46:50-!- elvish_sovereign [~elvish_so@pool-173-59-71-113.phlapa.east.verizon.net] has quit [Quit: elvish_sovereign]
20100716 05:54:10< shadowmaster> wesbot: log 43955
20100716 05:54:11< wesbot> ai0867 * r43955 : Merge trunk up to r43954
20100716 05:54:12< wesbot> URL: http://svn.gna.org/viewcvs/wesnoth?view=rev&rev=43955
20100716 05:54:15< shadowmaster> k
20100716 05:55:32< shadowmaster> duh, it'd seem I missed a month of commits.
20100716 05:56:40< shadowmaster> I should consider getting a cronjob to fetchfor me.
20100716 05:57:19-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Quit: ...]
20100716 05:59:32< CIA-87> shadowmaster * r44213 /trunk/changelog: UNits comes before USer interface...
20100716 05:59:59< CIA-87> shadowmaster * r44214 /trunk/players_changelog: UNits comes before USer interface...
20100716 06:01:31-!- rusty [~rusty2@ppp118-210-39-37.lns20.adl2.internode.on.net] has quit [Quit: Leaving.]
20100716 06:04:31-!- KylePoole [45a4d2b5@gateway/web/freenode/ip.69.164.210.181] has left #wesnoth-dev []
20100716 06:04:35< shadowmaster> sigh.
20100716 06:04:37< shadowmaster> shadowm@bluecore:~/src/wesnoth$ git push
20100716 06:04:39< shadowmaster> fatal: No destination configured to push to
20100716 06:04:59< CIA-87> shadowmaster * r44215 /trunk/data/core/about.cfg: Now Shadowmaster belongs to me in the wiki
20100716 06:06:29< CIA-87> shadowmaster * r44216 /branches/1.8/data/core/about.cfg: 
20100716 06:06:29< CIA-87> Now Shadowmaster belongs to me in the wiki
20100716 06:06:29< CIA-87> (Backported from trunk, r44215.)
20100716 06:07:31-!- Blueblaze [~Blueblaze@adsl-76-202-21-28.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100716 06:22:55-!- Crab_ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100716 06:24:43-!- ancestral [~ancestral@97-116-113-21.mpls.qwest.net] has joined #wesnoth-dev
20100716 06:39:42-!- billynux [~billy@wesnoth/developer/billynux] has joined #wesnoth-dev
20100716 07:12:11-!- Crab_ [~Crab_@wesnoth/developer/crab] has quit [Quit: Leaving.]
20100716 07:14:46-!- AnMaster [~AnMaster@unaffiliated/anmaster] has joined #wesnoth-dev
20100716 07:50:13-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20100716 08:22:06-!- zookeeper [~l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20100716 08:43:26-!- timotei [~Timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20100716 08:43:43< timotei> morning
20100716 08:44:55< shadowmaster> hi there
20100716 08:46:52-!- EdB [~edb@tss37-1-89-84-18-220.dsl.club-internet.fr] has joined #wesnoth-dev
20100716 09:10:57-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Quit: night]
20100716 09:11:36-!- Ivanovic [~ivanovic@dtmd-4db2c597.pool.mediaWays.net] has quit [Changing host]
20100716 09:11:36-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100716 09:12:56< Ivanovic> moin
20100716 09:18:34< billynux> morning people (its 4:25am here :P )
20100716 09:18:43< timotei> hi billynux 
20100716 09:18:48< billynux> hi timotei 
20100716 09:18:59< timotei> why did you wake up so early?:D
20100716 09:19:10< billynux> never went to bed :P
20100716 09:19:15< timotei> :-?
20100716 09:19:21< billynux> Ivanovic, shadowmaster: Is it possible that a WML contains a "sent = " line?
20100716 09:19:22< timotei> i remember you left at a moment
20100716 09:19:41< Ivanovic> no idea, am no wml wiz
20100716 09:19:50< timotei> billynux: zookeeper could also know
20100716 09:20:02< billynux> timotei,  I did, I had a meeting with some guys that are doing their thesis work with me
20100716 09:20:07< timotei> oh
20100716 09:20:15< billynux> zookeeper, around? WML question ^
20100716 09:21:35< zookeeper> billynux, i don't get your question
20100716 09:21:49< zookeeper> is it about the quotes or what?
20100716 09:22:06< billynux> zookeeper, I'm implementing the network module, and I sometimes get a WML uncompression error
20100716 09:22:35< billynux> zookeeper, apparently some of the WML's I send have a line that looks like that
20100716 09:23:10< zookeeper> so the question is whether a key without a value is valid WML?
20100716 09:23:48< billynux> zookeeper, I guess it's one of the questions
20100716 09:24:42< zookeeper> frankly, i don't know. if i needed to know, i'd ask silene :P
20100716 09:24:55< billynux> ok, thanks zookeeper 
20100716 09:24:58< billynux> I'll ask around later
20100716 09:25:37< billynux> I'm hoping mordante will be around later today
20100716 09:25:46< zookeeper> well, actually it needs to be valid, it's used in various places
20100716 09:28:41< zookeeper> eh, just give me a sec, i'll check something...
20100716 09:28:50< billynux> zookeeper, the WML? of course, I'm getting these failed to uncompress errors, and if I get to the game I start getting out of sync errors
20100716 09:32:55< zookeeper> billynux, yeah, empty values seem to be supported just fine, so my non-coder guess would be that maybe the uncompression code just can't handle those
20100716 09:33:54< billynux> zookeeper, well, if the WML was formed right, the uncompression should handle it fine (I'm using the very same method as the old SDLnet implementation)
20100716 09:34:13< billynux> my guess is my code is sending things to people when it shouldn't :)
20100716 09:35:14< billynux> Solit0n (not the actual nick intended) might know something about it, but I'll discuss it with mordante first
20100716 09:41:27< billynux> all right, off to sleep for a while
20100716 09:41:29-!- billynux [~billy@wesnoth/developer/billynux] has quit [Quit: Leaving]
20100716 09:51:18-!- Sirp [~me@wesnoth/developer/dave] has quit [Ping timeout: 240 seconds]
20100716 09:53:04-!- Sirp [~me@pool-71-164-166-178.dllstx.fios.verizon.net] has joined #wesnoth-dev
20100716 10:14:16-!- phlaem [~a@e178089144.adsl.alicedsl.de] has joined #wesnoth-dev
20100716 10:15:47-!- ancestral [~ancestral@97-116-113-21.mpls.qwest.net] has quit [Quit: And that’s the end of THAT chapter.]
20100716 10:26:18-!- thespaceinvader [~chatzilla@wesnoth/artist/thespaceinvader] has joined #wesnoth-dev
20100716 10:30:34-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Quit: crimson_penguin]
20100716 10:35:01-!- dtiger [~dtiger@dynamic-vpdn-93-125-68-230.telecom.by] has joined #wesnoth-dev
20100716 10:53:11-!- Unnheulu [~ieuan@cpc5-pnth2-0-0-cust800.5-2.cable.virginmedia.com] has joined #wesnoth-dev
20100716 11:03:21< Ivanovic> zookeeper: do you know if this is supposed to be correct wml usage? https://gna.org/bugs/index.php?16259
20100716 11:04:12< zookeeper> Ivanovic, not intended correct usage AFAIK, and i didn't know that it used to work either.
20100716 11:04:39< Ivanovic> then leave a comment and mark it "invalid" or "won't fix" or whatever you think works
20100716 11:13:25-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-dev
20100716 11:14:22-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20100716 11:29:37-!- Unnheulu [~ieuan@cpc5-pnth2-0-0-cust800.5-2.cable.virginmedia.com] has quit [Read error: Operation timed out]
20100716 11:35:00< CIA-87> thespaceinvader * r44217 /trunk/ (7 files in 5 dirs): Add and wire new Giant Mudcrawler portrait by kitty. Update changelogs, portrait credits.
20100716 11:39:10-!- EdB [~edb@tss37-1-89-84-18-220.dsl.club-internet.fr] has quit [Read error: Connection reset by peer]
20100716 11:42:29-!- Unnheulu [52050b21@gateway/web/freenode/ip.82.5.11.33] has joined #wesnoth-dev
20100716 11:50:32-!- Unnheulu [52050b21@gateway/web/freenode/ip.82.5.11.33] has quit [Ping timeout: 252 seconds]
20100716 11:59:25-!- jbjerk [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has joined #wesnoth-dev
20100716 11:59:25-!- eleazar [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has quit [Read error: Connection reset by peer]
20100716 12:00:43-!- jbjerk_ [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has joined #wesnoth-dev
20100716 12:00:43-!- jbjerk [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has quit [Read error: Connection reset by peer]
20100716 12:00:44-!- jbjerk_ is now known as jbjerk
20100716 12:01:28-!- jbjerk_ [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has joined #wesnoth-dev
20100716 12:01:28-!- jbjerk [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has quit [Read error: Connection reset by peer]
20100716 12:01:28-!- jbjerk_ is now known as jbjerk
20100716 12:02:04-!- Crab_ [~Crab@wesnoth/developer/crab] has joined #wesnoth-dev
20100716 12:02:06-!- jbjerk [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has quit [Read error: Connection reset by peer]
20100716 12:02:23-!- jbjerk [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has joined #wesnoth-dev
20100716 12:03:19-!- jbjerk_ [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has joined #wesnoth-dev
20100716 12:03:19-!- jbjerk [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has quit [Read error: Connection reset by peer]
20100716 12:03:19-!- jbjerk_ is now known as jbjerk
20100716 12:08:53< timotei> hi Crab_ :-)
20100716 12:09:17< Crab_> hi, timotei
20100716 12:09:50< Crab_> I've seen that we've missed each other by 1 hour. np, we'll be able to catch each other sooner or later )
20100716 12:10:25< Crab_> for example, I should be at home in around +10h today
20100716 12:12:16< timotei> Crab_: yeah, yesterday had a .NET conference and didn't come back home at time
20100716 12:12:33< timotei> Crab_: there is no problem. Today I need to rework a bit the tool invoker since I don't like how it's done now:D
20100716 12:12:53< Crab_> ok
20100716 12:13:09 * Crab_ is programming using .NET right now...
20100716 12:13:21< timotei> nice :P
20100716 12:14:07< timotei> in what domain is the application?
20100716 12:38:32-!- Blueblaze [~Blueblaze@adsl-76-202-21-28.dsl.hstntx.sbcglobal.net] has left #wesnoth-dev []
20100716 12:40:48-!- fendrin [~fabi@88-134-103-91-dynip.superkabel.de] has joined #wesnoth-dev
20100716 12:40:48-!- fendrin [~fabi@88-134-103-91-dynip.superkabel.de] has quit [Changing host]
20100716 12:40:48-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100716 12:42:52-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20100716 12:45:01-!- fendrin [~fabi@88-134-103-91-dynip.superkabel.de] has joined #wesnoth-dev
20100716 12:45:01-!- fendrin [~fabi@88-134-103-91-dynip.superkabel.de] has quit [Changing host]
20100716 12:45:01-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100716 12:46:13-!- Elvish_Pillager [~eli@71-10-224-192.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20100716 12:47:56-!- kevg [~kevg@94.232.5.54] has joined #wesnoth-dev
20100716 12:48:32< kevg> Crab_: hi. What are the test results?
20100716 12:49:28< Crab_> hi, kevg. sorry, I've not tested yet (
20100716 12:50:18-!- Johannes13 [~Johannes@unaffiliated/johannes13] has joined #wesnoth-dev
20100716 12:50:37< Crab_> kevg: I'll try to start the test on this weekend, then.
20100716 12:50:59< kevg> Crab_: ok. I'm not in hurry.
20100716 13:04:23-!- ettin [~jorda@wesnoth/developer/ettin] has quit [Ping timeout: 258 seconds]
20100716 13:23:37< fendrin> hi Crab_
20100716 13:23:56< Crab_> hi, fendrin
20100716 13:24:21< fendrin> Crab_: Can you give me the link to the google frontend and help me to fill out the midterm eval final, please?
20100716 13:25:41< Crab_> I can help, but right now I'm away from my google password. so, for the link, ask Ivanovic or anyone else who has logs of #wesnoth-mentor
20100716 13:26:42< Crab_> basically, it was 'login there, and find the midterm evaluation menu item, then select the student and fill out a big form'
20100716 13:29:26< fendrin> I just hate the interface. Can't find anything, never.
20100716 13:46:38< fendrin> timotei: Hello.
20100716 13:48:17< timotei> hi fendrin 
20100716 13:52:01< timotei> shadowmaster: hehe, just got my notebook back. and nothing missing:D
20100716 13:52:41< timotei> shadowmaster: I think I won't install any BIOS upgrade anymore
20100716 13:53:48-!- kevg [~kevg@94.232.5.54] has left #wesnoth-dev []
20100716 13:58:12-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100716 14:13:21-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has joined #wesnoth-dev
20100716 14:13:44-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100716 14:14:55< boucman> hey all
20100716 14:14:57< boucman> wesbot: seen alink
20100716 14:14:58< wesbot> boucman: The person with the nick alink last spoke 11h 41m ago.  10h 31m ago was here and on the channel #wesnoth with the message: Remote host closed the connection
20100716 14:15:36< timotei> hi boucman 
20100716 14:17:32-!- Johannes13_ [~Johannes@unaffiliated/johannes13] has joined #wesnoth-dev
20100716 14:21:41-!- Johannes13 [~Johannes@unaffiliated/johannes13] has quit [Ping timeout: 265 seconds]
20100716 14:39:30-!- silene [~plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20100716 14:44:25-!- alink [~alink@wesnoth/developer/alink] has joined #wesnoth-dev
20100716 14:45:00< alink> thanks wesbot
20100716 14:45:03< alink> boucman: looking for me?
20100716 14:51:00< boucman> yup, I saw your new feature in the terrain engine, but I have two questions about it, before I try switching to using it everywhere...
20100716 14:51:31< boucman> 1) will the same random number always be taken at the same place (answer is yes IIRC, just making sure)
20100716 14:52:24< boucman> 2) I didn't see it handling the fact that some images are missing, and the way you do stats as cumulative don't make it work easily for cumulative probability the way we are currently doing it
20100716 14:52:35< alink> 1) yes random seed work like old random rules
20100716 14:52:36-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Read error: Connection reset by peer]
20100716 14:53:24< alink> 2) missing images handling are handled before that, but that's the next step of my plan
20100716 14:53:50< alink> and yes I plan to adjust probability with missing images
20100716 14:54:02< alink> btw don't start using it yet, WML interface helper will be added
20100716 14:55:05< alink> boucman: about missing images, that's not related to my last feature, but I plan to improve the old system too since I will need it more
20100716 14:55:23< boucman> alink: ok, I wanted to make sure you know of the "trick" we use with missing images and probability (see internal-complex.cfg) which allows us to have the right probabilities without knowing the actual number of images
20100716 14:55:44< alink> thanks, and yes I know it
20100716 14:56:14< boucman> good, in that case i'll just leave it to you, ping me once you think it's ready for general consumption and i'll update the macros...
20100716 14:56:55< alink> next step is: old system parse and generate tons of rules and then check if valid (detect missing images mostly). Which causes 95% (IIRC) of the terrain rules to be rejected. I want to fix that
20100716 14:57:09< boucman> hmm, having fixed and non-fixed probability might be tricky though... we have _RANDOM_ variations and _P variations, both are used...
20100716 14:57:31< alink> Mostly by validate them during parsing (which allow early break)
20100716 14:57:36< boucman> 65%, but I'd like to fix the macro side myself if that's fine with you....
20100716 14:57:44< boucman> once you tell me the code side is ready
20100716 14:59:01< alink> boucman: I don't plan to touch the macro (but I will probably try to write one using my new features to see what works)
20100716 14:59:54< boucman> ok, great...
20100716 15:00:12< alink> and for mixed probability, I will probably provide a syntax trick to auto-generate them when needed.
20100716 15:00:42< boucman> how about a boolean cumulative_prob= attribute in the [terrain-graphics]
20100716 15:01:00< boucman> this way depending on how I use it with macros I can use whichever is best
20100716 15:01:51< alink> Do you really like cumulative_prob? I think it's very unintuitive (proof is that it need comment to describe what we want)
20100716 15:02:54< boucman> no, I don't, but it's an easier tool in some cases... so if we get rid of these cases i'm fine with getting rid of it.
20100716 15:03:21< boucman> However the cleanest way to solve these problems might be to add a simple flag (not sure, but it's worth giving 5' thinking)
20100716 15:04:52< alink> ok my plan to get rid of that (and few other cumbersome thing). If it fails than I'll try flag to manage them
20100716 15:04:57-!- Unnheulu [~ieuan@cpc5-pnth2-0-0-cust800.5-2.cable.virginmedia.com] has joined #wesnoth-dev
20100716 15:05:18< boucman> well, we have basically two cases for usage of probability in macros
20100716 15:05:41< boucman> the case of the "we don't know the number of images but want even probability" which I pointed earlier
20100716 15:05:59< alink> btw, to be sure, did you notice that my new probability key is not at the same tag level as the old one
20100716 15:06:19< boucman> and the second case is the "we have one or two low probability terrains and a catch all terrain" which is on a case by case in terrain-graphics.cfg
20100716 15:06:34< boucman> no, I hadn't... at what level is it ?
20100716 15:06:40< boucman> in [image] ?
20100716 15:06:47< alink> ah ok, I'll explain
20100716 15:07:15< alink> Basically it makes more use of the ToD [variant] tag which is into [image]
20100716 15:07:26< alink> because it only affect images
20100716 15:07:42< alink> old probability key affect the whole rule
20100716 15:08:17< alink> and is in fact more poweful but very overkill for common use
20100716 15:08:37< boucman> ok... that's going to be harder to integrate into macros... 
20100716 15:09:34< alink> not sure, the two can coexist, and as i said, I plan to add wml syntax helper to ease macro use
20100716 15:10:53< alink> but better talk about it after I experiment with that, I have few different ideas that I want to test
20100716 15:11:25< alink> and since all is currently backward compatible (and will stay like that), there is no hurry
20100716 15:11:47< boucman> yes, overall I like the idea, but you have to understand that the decision of how many images and what probability basically can come from the top of the macro stack, and we have to push it all  the way down to the block construction, which is a bit tricky
20100716 15:12:16< boucman> the best way I can see is to make the IMAGE_BUILDER idea way more complex by allowing it to fill most of the [image] block...
20100716 15:12:30< boucman> ok
20100716 15:13:01< alink> ok, I'll think I understand it, and that's precisely the main thing that I want to improve
20100716 15:13:08-!- Unnheulu_ [~ieuan@cpc5-pnth2-0-0-cust800.5-2.cable.virginmedia.com] has joined #wesnoth-dev
20100716 15:13:34-!- Unnheulu [~ieuan@cpc5-pnth2-0-0-cust800.5-2.cable.virginmedia.com] has quit [Ping timeout: 258 seconds]
20100716 15:13:40-!- Unnheulu_ is now known as Unnheulu
20100716 15:16:56< alink> also, if I am right it will optimize a big bottleneck too (rules parsing)
20100716 15:17:05-!- Appleman1234 [~Appleman1@CPE-60-226-176-19.qld.bigpond.net.au] has quit [Ping timeout: 265 seconds]
20100716 15:17:58< alink> I added a rules caching in 1.8 which helps a lot, but you still need to reparse them when switching between different campaigns etc..
20100716 15:18:33< alink> and it's not related to preprocessor cache or wml macros
20100716 15:19:39< boucman> yes, I don't consider my mcro levesl is "abusive" but it doesn't mean macro performence isn't an issue...
20100716 15:19:58< alink> and by optimizing rules parsing, I mean reduces their number by using [variant] and have more early break during parsing of invalid rules
20100716 15:19:59< Elvish_Pillager> silene: two lua questions: (1) I currently use [if] [insert_tag] name=then to execute stored WML instructions in some places; is there any way to execute stored WML instructions directly via lua?
20100716 15:20:08< boucman> the fact that using macro in "programatic" ways causes the loading to increase so fast is a bit worrying
20100716 15:20:33< Elvish_Pillager> silene: (2) what's the syntax of wesnoth.fire_event, if you want to only specify two locations (and not any weapons)?
20100716 15:20:59< silene> Elvish_Pillager: i'm not sure to understand, (1) seems to be precisely what wesnoth.fire does
20100716 15:21:00< boucman> alink: IIRC the invalid rules (at WML level) did not slow down that much, they mainly caused extra memory usage...
20100716 15:21:10-!- dtiger_ [~dtiger@dynamic-vpdn-93-125-68-230.telecom.by] has joined #wesnoth-dev
20100716 15:21:11-!- dtiger [~dtiger@dynamic-vpdn-93-125-68-230.telecom.by] has quit [Remote host closed the connection]
20100716 15:21:17< boucman> it's the handling of call stack in preprocessor that was slowing things down
20100716 15:21:41< boucman> afk ~1/2h
20100716 15:21:42< silene> Elvish_Pillager: just pass the locations: wesnoth.fire_event("moveto", x1, y1, x2, y2)
20100716 15:22:16< Elvish_Pillager> the wiki didn't make that clear to me
20100716 15:22:17< alink> boucman: I could check again, but the parsing times is very probably proportional to the number of rules
20100716 15:22:41< alink> boucman: and invalid rules have about the same cost as valid ones
20100716 15:22:41< Elvish_Pillager> for (1), I mean, I have a WML variable whose contents are a bunch of commands, and I want to execute those commands
20100716 15:22:56< boucman> alink: that doesn't contradict what I said :P
20100716 15:23:03< Elvish_Pillager> that isn't precisely what wesnoth.fire does...
20100716 15:23:36< boucman> the time is consumed each time we enter/exit a macro... it's not limited to terrain, but the number of macro calls in terrain is why it's the major cause of slowdown
20100716 15:23:58< boucman> it's totally independant of the rule's vaildity 
20100716 15:24:22< silene> Elvish_Pillager: sure, but it almost is: for k,v in ipairs(wesnoth.get_variable "commands") do wesnoth.fire(v[1], v[2]) end
20100716 15:24:23< boucman> however whenever we enter a macro, we remember the calling location to build a traceback in case of syntax error
20100716 15:24:35< boucman> and it's the traceback building IIRC that takes all the time
20100716 15:24:42< boucman> (ok, really leaving now)
20100716 15:24:46< alink> boucman: sorry I was currently speaking about the parsing of [terrain_graphics] WML data
20100716 15:24:58< boucman> oh, ok
20100716 15:25:39< alink> boucman: we need to optimize and balance the load of both: cache building and cache parsing
20100716 15:26:57< alink> ideally optimize both, reducing number of rules should allow that
20100716 15:27:18< Elvish_Pillager> silene: wesnoth.get_variable("commands") isn't an array, is it?
20100716 15:28:05< silene> Elvish_Pillager: it is, if there is a tag named [commands] in the variables
20100716 15:29:06< silene> more precisely, "commands[0]" is definitely a lua table (if it exists)
20100716 15:29:36< Elvish_Pillager> I thought that wesnoth.get_variable("commands") would return the lua table for commands[0]
20100716 15:30:01< Elvish_Pillager> and that lua table is what would contain all the instructions I want to execute
20100716 15:32:17< Elvish_Pillager> fortunately, I can work around this by using fire_event and a WML event that executes them.
20100716 15:34:29< silene> Elvish_Pillager: yes, you thought correctly; and that's also what i'm saying
20100716 15:35:14< Elvish_Pillager> oh, okay
20100716 15:35:25< silene> is there anything wrong with the lua line i suggested?
20100716 15:35:45< Elvish_Pillager> maybe I'm just still not understand either lua or something about how WML's data structures are represented
20100716 15:36:34< Elvish_Pillager> I thought that ipairs wouldn't do anything because the lua table for the variable "commands" wouldn't be indexed by integers
20100716 15:38:12< silene> Elvish_Pillager: a wml tag is represented as a lua table, attributes are indexed by their names, subtags are indexed by their number of appearance; each subtag is represented by a pair name/content (a pair is encoded as an array with two elements)
20100716 15:38:33< Elvish_Pillager> ooooh, now I get it
20100716 15:38:34< Elvish_Pillager> thank you
20100716 15:41:53< boucman> alink: yes, I'm not against that, it's just that I think that terrain macros have unearthed a couple of problems, one being that the current terrain system doesn't scale with inexistant files, but the other one is a preprocessor scaling problem which is not terrain related
20100716 15:43:29< silene> boucman: have you been able to reproduce it with a piece of code that wasn't terrain-related? if not, then it is terrain-related, by definition
20100716 15:44:03< alink> yeah terrain macros use auto-generated macros, WML macros were not done for that
20100716 15:44:08< boucman> silene: when 63% of time according to gprof is in the line building the backtrace message, it's not terrain related, whether the terrain code is calling it or not
20100716 15:44:17< boucman> a debug feature should never use 63% of cpu time
20100716 15:44:44< alink> boucman: and missing images in terrains has always annoyed me and I already worked to optimize that in the past
20100716 15:45:06< silene> boucman: on any other piece of code, it doesn't use 63% of cpu
20100716 15:46:06< boucman> it probably does use 63% of preproc time, it's just that most of preproc time is passed in terrain code
20100716 15:46:48< alink> less just say that it doesn't scale well ;)
20100716 15:46:49< silene> boucman: no, it doesn't; just profile wesnoth 1.8 (or trunk before your terrain rewrite) and you will see that it doesn't
20100716 15:47:45< alink> boucman: I suspect that new terrains macros introduced heavy macro nesting, which may be new
20100716 15:47:58< boucman> alink: indeed, 
20100716 15:48:04< boucman> but it's still a legitimate usage
20100716 15:48:34< alink> and even more, heavy use of heavily nested macro
20100716 15:49:26< boucman> yes, that's why I say I unearthed a problem in preproc, but don't consider it a problem on my side (which doesn't mean I'm against rewriting some stuff on my side to solve it)
20100716 15:49:58< boucman> as long as it doesn't force me to turn the terrain macros into the mess it was before...
20100716 15:50:40< silene> at least it was working efficiently...
20100716 15:51:25< alink> boucman: but whatever the implementation is, there is always some usage faster than others. For example, multiple parallel macros instead of nested ones.
20100716 15:52:09< boucman> alink: isn't preprocessing linear ?
20100716 15:52:52< alink> yes, what I mean is in the file 
20100716 15:53:14< silene> boucman: it is more or less linear in the amount of preprocessed text generated; if you increase the amount of text generated, then you slow down the preprocessing
20100716 15:54:08< boucman> but it's not proportional to the depth of macro calls, it's proportional to the the number of macro calls (and as you pointed quantity of text generated) 
20100716 15:54:20< silene> by nesting macros, you increase the amount of debug comments in the generated text, hence causing the slowdown
20100716 15:54:24< boucman> the fact that calls are nested or paralell doesn't change the time, does it ?
20100716 15:54:35< boucman> oh, ok
20100716 15:54:50< boucman> the "debug prefix" gets longer...
20100716 15:55:12< silene> yes
20100716 15:55:35< boucman> I don't think I go deeper than 3 or 4 levels, though... my guess is that some UMC go deeper than that...
20100716 15:56:01< alink> boucman: I believe you go much higher than that in few places
20100716 15:56:14< alink> for example water animation IIRC
20100716 15:56:41< boucman> hmm, t-g->random->base macro->indirection->builer....
20100716 15:56:50< boucman> I don't see much deeper than that...
20100716 15:56:58< alink> also they all have a lot of parameters, but not sure how parameters scale
20100716 16:01:09< alink> there is also the _PFLB system which often add levels
20100716 16:02:20< silene> boucman: run --preprocess data/ plop/ ; then look at plop/_main.cfg.plain and search for the first [terrain_graphics]; look at its content, and also look at the lines before it
20100716 16:04:39< silene> from a quick glance, i would say that debug comments for terrains amount to 80% of the generated text for wesnoth data
20100716 16:05:52< Unnheulu> esr, is wmllint meant to be unable to upgrade 1.4 campaigns?
20100716 16:05:59< Unnheulu> (ie, is that a feature or a bug)
20100716 16:07:26< silene> Unnheulu: the wmllint from wesnoth 1.6 should be able to upgrade 1.4 campaigns
20100716 16:07:41< Unnheulu> And then run the wmllint from 1.8, and then the one for svn?
20100716 16:07:49< Unnheulu> Sounds like a lot of work :/
20100716 16:09:36< boucman> alink: could you quickly test if bridges work for you in trunk ? they are broken here, but I have some local changes...
20100716 16:10:14< alink> boucman: testing..
20100716 16:10:38< Unnheulu> Map editor is slow in trunk :/
20100716 16:10:47< Unnheulu> (and starting up wesnoth for that matter)
20100716 16:11:56< Elvish_Pillager> silene: is there a way to check for simple mistakes in my Lua code that's more convenient than starting up Wesnoth each time?
20100716 16:11:58< Unnheulu> boucman, none of the stone bridges work here
20100716 16:12:09< boucman> ok, thx...
20100716 16:12:11< Unnheulu> Nor wooden bridges for that matter
20100716 16:12:20< alink> boucman: wood bridges don't work too
20100716 16:12:39< Unnheulu> Nor underground bridges
20100716 16:12:54< alink> in editor at least, and assuming I use them right (just add bridges on water ?)
20100716 16:13:23< boucman> just add a bridge over anything, and wood bridges havn't been touched in the last couple of weeks IIRC...
20100716 16:13:36< silene> Elvish_Pillager: i usually put all my code in a lua file; so i just run the lua binary, do "dofile" on the file; obviously it will fail as soon as it tries to execute it, but it will still detect all the syntax errors
20100716 16:13:37-!- e_s-iOS [~esios@pool-173-59-71-113.phlapa.east.verizon.net] has joined #wesnoth-dev
20100716 16:13:52< Elvish_Pillager> silene: ah, cool
20100716 16:15:18< alink> boucman: wood bridges seems to work on r44162 but not with current trunk
20100716 16:16:07< alink> r44162 is 2 days ago
20100716 16:16:32< Unnheulu> Even then they were working weird...
20100716 16:22:37< timotei> fendrin: around?
20100716 16:23:59< alink> boucman: correction, it's probably an editor thing, they are not visible when adding them, but reload make them visible
20100716 16:24:13< alink> I investigate
20100716 16:24:16-!- wesbot changed the topic of #wesnoth-dev to: 143 bugs, 282 feature requests, 15 patches | logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100716 16:24:36< boucman> alink: by reload you mean "using in game" or saving and reloading in editor works ?
20100716 16:25:25< alink> boucman: quitting and reload map in editor, but "Refresh Display" in menu works too
20100716 16:25:40< alink> I didn't tested in game yet
20100716 16:25:53< boucman> thx, I can test my bridges with that
20100716 16:26:22< Unnheulu> Just out of curiosity, what stops wesnoth from handling more than one overlay?
20100716 16:28:52< boucman> Unnheulu: art choice in the terrain system... it usually "doesnt look good"
20100716 16:29:13< Unnheulu> Ah
20100716 16:29:18< Unnheulu> So its a forced restriction?
20100716 16:29:50-!- _jbx_ [~jbailey@12.190.80.225] has joined #wesnoth-dev
20100716 16:30:32< boucman> yes
20100716 16:31:12< alink> boucman: ok I see the probable source of the editor bug, it has nothing to do with bridge I'll fix that soon
20100716 16:31:58< boucman> thx
20100716 16:32:27< alink> (it's the ugly code rebuilding only one hex, I always wanted to clean that one day, I guess now is the good time)
20100716 16:33:00< alink> also because I just broke it ;-)
20100716 16:33:12< boucman> hehe
20100716 16:33:29< boucman> I have a workaround, so it's not an emergency on my side...
20100716 16:33:38< Unnheulu> 1.8.0 just segfaulted :/
20100716 16:40:54< alink> Unnheulu: use 1.8.3 ;-)
20100716 16:41:11< Unnheulu> alink, I do little mp so I'm with 1.8.0 or svn :P
20100716 16:41:38< Unnheulu> Aka, I'm too lazy to compile 1.8.3
20100716 16:41:41< alink> and with the 1.8.0 bugs
20100716 16:41:56< Unnheulu> How many of the bugs are *that* significant?
20100716 16:42:53< alink> hard to tell, we sometimes fix bugs without knowing it (you clean something which had hidden side-effect) and we sometimes forget to update changelogs ;-)
20100716 16:42:53< boucman> Unnheulu: some crashes have been fixed :D
20100716 16:43:14< Unnheulu> boucman, its an mp crash, which I don't do much of :D
20100716 16:43:37< boucman> Unnheulu: if you're able to use svn to get trunk and compile it yourself, you could just follow the the 1.8 branch and compile it yourself... that's what I do
20100716 16:44:23< Unnheulu> boucman, that's what I've done other years, but I use 1.8 so little it doesn't feel worth it
20100716 16:44:34< boucman> your choice...
20100716 16:44:39< Unnheulu> Plus wesnoth takes 15mins to download
20100716 16:44:48< Unnheulu> Yeah, that's why i'm not trying to make too much of a fuss
20100716 16:46:30< Unnheulu> Humm, I'm downloading 1.8.3
20100716 16:50:47-!- jbjerk_ [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has joined #wesnoth-dev
20100716 16:50:48-!- jbjerk [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has quit [Read error: Connection reset by peer]
20100716 16:50:49-!- jbjerk_ is now known as jbjerk
20100716 16:51:25-!- jbjerk_ [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has joined #wesnoth-dev
20100716 16:51:25-!- jbjerk [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has quit [Read error: Connection reset by peer]
20100716 16:51:25-!- jbjerk_ is now known as jbjerk
20100716 16:52:22< timotei> Crab_: around?
20100716 16:52:24-!- jbjerk [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has quit [Read error: Connection reset by peer]
20100716 16:52:38< Crab_> yes, but not for long
20100716 16:52:41-!- jbjerk [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has joined #wesnoth-dev
20100716 16:52:54< timotei> I have a fast/quick questions
20100716 16:53:03< timotei> do we need to wmltool* on preproc files?
20100716 16:53:06< boucman> apparently lurker has a special talent for screwing with my macro systems :P
20100716 16:53:17< timotei> or just on the current files on which we work?
20100716 16:54:58-!- e_s-iOS [~esios@pool-173-59-71-113.phlapa.east.verizon.net] has quit [Remote host closed the connection]
20100716 16:55:37< alink> Unnheulu: svn up 1.8 branch is much faster
20100716 16:55:49< Unnheulu> -.-
20100716 16:55:57< Unnheulu> I just downloaded and extracted it...
20100716 16:56:11< alink> Unnheulu: esp. if you think we didn't change much things ;-)
20100716 16:56:11< Unnheulu> Great time to tell me :P
20100716 16:56:22< Unnheulu> heh
20100716 16:56:27< alink> Unnheulu: sry I was afk
20100716 16:56:43< alink> I would have tell you that directly if not
20100716 16:56:58< Unnheulu> Anyways, autotools seems not to work
20100716 16:57:09 * Unnheulu 'll compile later, he's playing BfM at the moment
20100716 16:58:07< alink> btw "svn up 1.8 branch is much faster" assuming you already have a svn checkout of 1.8.0
20100716 16:58:21< Unnheulu> I guess
20100716 16:59:17< Unnheulu> I'm not sure "svn up 1.8 branch" would ever work though
20100716 16:59:21< Unnheulu> :P
20100716 16:59:27< alink> which I recommend, to avoid the same problem when 1.8.4 will be about
20100716 16:59:46< alink> yeah indeed
20100716 17:00:46< alink> btw we plan to release 1.8.4 around the time you finished compiling 1.8.3, and it will have a bugfix for the crash you reported <:o)
20100716 17:02:19< fendrin> timotei: yes
20100716 17:02:26< alink> and now for something totally unrelated http://debian-art.org/content/show.php/Wesnoth?content=127482&PHPSESSID=44fb35abc28de37e14cc0dab522cee91
20100716 17:02:39< alink> ^a wesnoth GTK theme
20100716 17:02:53-!- Crab_ [~Crab@wesnoth/developer/crab] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
20100716 17:02:58< timotei> fendrin: we need to use wmllint on preprocessed files?
20100716 17:03:03< timotei> or just on the ones in workspace
20100716 17:03:03 * boucman loves it :)
20100716 17:03:20< boucman> now to find how to install it
20100716 17:03:25< timotei> alink: wow, that's nice:D
20100716 17:03:26< alink> shorter link http://debian-art.org/content/show.php/Wesnoth?content=127482
20100716 17:03:31< Unnheulu> Woah, that's wicked
20100716 17:03:31< zookeeper> timotei, uh, not needed on preprocessed files. i wonder if most preprocessed files would even pass wmllint...
20100716 17:03:42< zookeeper> i guess they probably would
20100716 17:03:53< timotei> zookeeper: they will *surelly* pass
20100716 17:04:07< timotei> zookeeper: since preprocessed = macros expanded ;)
20100716 17:04:23< timotei> zookeeper: almost the final form of a wml file
20100716 17:04:25< Unnheulu> Would be better if not for the evony ad blinking in the top of the window
20100716 17:05:01< fendrin> timotei: Well, using wmllint on preprocessed files would bring much better results for campaigns like LOW for example.
20100716 17:05:13< timotei> ok
20100716 17:05:28< fendrin> In LoW there are much macros used in [side] tags which doesn't work for wmllint at all.
20100716 17:05:28< timotei> fendrin: I'm just thinking of ways to not-duplicate the code
20100716 17:05:43< timotei> fendrin: in eclipse the files not in workspace have different classes, they are not even inherted
20100716 17:06:10< timotei> but will work in the end
20100716 17:06:17< zookeeper> yeah, i withdraw what i said. it's not "needed", but might be a good idea in some cases.
20100716 17:06:40< boucman> installed :)
20100716 17:06:57< alink> :-)
20100716 17:10:31-!- chr_ [~quassel@89.204.137.6] has joined #wesnoth-dev
20100716 17:13:48< Unnheulu> How is 1.8.x compiled?
20100716 17:13:54< Unnheulu> Autotools appears to not work
20100716 17:14:03< timotei> Unnheulu: make
20100716 17:14:18< Unnheulu> Autotools isn't working...
20100716 17:14:22< timotei> Unnheulu: what distribution you using?
20100716 17:14:23< alink> Unnheulu: used autogen.sh ?
20100716 17:14:30< Unnheulu> alink, no :P
20100716 17:14:40 * Unnheulu crosses fingers
20100716 17:14:52< alink> that often fix autotools problem
20100716 17:17:51< CIA-87> alink * r44218 /trunk/src/builder.cpp: Quick fix for broken map rebuild (which is very needed in editor)
20100716 17:18:07< alink> boucman: fixed^, and it was not where I thought
20100716 17:18:09< Unnheulu> That worked, thanks alink
20100716 17:18:19< Unnheulu> Eww, I'm not compiling svn again...
20100716 17:18:24< alink> Unnheulu: you are welcome
20100716 17:18:25-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has quit [Quit: Leaving]
20100716 17:18:31< boucman> alink: thx...
20100716 17:18:42< Unnheulu> Does make for wesnoth do the same as for xmoto (only recompiles the changes)
20100716 17:20:25-!- Unnheulu [~ieuan@cpc5-pnth2-0-0-cust800.5-2.cable.virginmedia.com] has quit [Quit: Ex-Chat]
20100716 17:20:28-!- Unnheulu [~ieuan@cpc5-pnth2-0-0-cust800.5-2.cable.virginmedia.com] has joined #wesnoth-dev
20100716 17:21:31-!- rigved [~rigved@117.98.43.146] has joined #wesnoth-dev
20100716 17:22:38-!- rigved [~rigved@117.98.43.146] has quit [Client Quit]
20100716 17:23:59< timotei> Unnheulu: yes
20100716 17:24:14< timotei> Unnheulu: the changes and the dependent files on the changed file
20100716 17:24:21< Unnheulu> Ok
20100716 17:24:34< Unnheulu> Xmoto is just a lot faster to compile...
20100716 17:24:46< timotei> wesnoth is too
20100716 17:25:41< Unnheulu> Although only one person has commit rights and all patches go through him there, so revisions are less often...
20100716 17:25:50< Unnheulu> When I'm compiling wesnoth, I'm compiling several new revisions I guess
20100716 17:26:43< alink> number of revisions doesn't matter, it's just the number of touched files
20100716 17:27:14< alink> btw ccache help in some cases
20100716 17:28:10< alink> but not sure if a user (not dev) will often use it
20100716 17:28:25< Unnheulu> But more revisions usually means more touched files ;)
20100716 17:28:45< Unnheulu> (Assuming the patches aren't all by the same person)
20100716 17:28:48< alink> Unnheulu: yes and no, we often touch the same file
20100716 17:29:14< alink> also if I revert a change, it's 2 revision and make don't see it
20100716 17:29:44< alink> meaning it will compile again the same old file
20100716 17:30:21< alink> I think ccache detect that (but not sure) and use the cached compilation
20100716 17:32:08< alink> at least ccache helps a lot when doing local revert
20100716 17:32:41< Unnheulu> "make" is just a bunch of g++'s right?
20100716 17:33:16< alink> Unnheulu: 'make' is not related to g++ or any languages 
20100716 17:33:26< Unnheulu> s/make/a makefile/
20100716 17:33:56< alink> for example, in wensoth, it also work on *.po files
20100716 17:34:47< alink> but ccache is c/c++ only
20100716 17:36:04< loonycyborg> ccache doesn't generally help whatsoever unless you're doing bisections.
20100716 17:36:08< Unnheulu> For some reason I always get conflicts with the .po's when svn upping
20100716 17:37:12< alink> loonycyborg: mmh I often see the ccache speed-up when coding, not sure precisely when though
20100716 17:38:20< alink> loonycyborg: for example, I think svn sometimes uselessly touch files when committing, and ccache seems to catch that
20100716 17:39:03< alink> and I am less sure but I suspect that it shares cache between my different build tree
20100716 17:39:11< alink> *trees
20100716 17:39:31< timotei> Unnheulu: you don't need to complie the .po's ;)
20100716 17:39:37< timotei> Unnheulu: put: NLS:false
20100716 17:39:54< Unnheulu> Doesn't explain why they cause conflicts in svn up'ing...
20100716 17:40:06< alink> Unnheulu: that's because 'make' modify them
20100716 17:41:23< Unnheulu> Ah
20100716 17:50:48-!- e_s-iOS [~esios@pool-173-59-71-113.phlapa.east.verizon.net] has joined #wesnoth-dev
20100716 17:55:30-!- e_s-iOS [~esios@pool-173-59-71-113.phlapa.east.verizon.net] has quit [Remote host closed the connection]
20100716 18:02:24-!- EdB [~edb@tss37-1-89-84-18-220.dsl.club-internet.fr] has joined #wesnoth-dev
20100716 18:02:36-!- elvish_sovereign [~elvish_so@pool-173-59-71-113.phlapa.east.verizon.net] has joined #wesnoth-dev
20100716 18:10:40< alink> loonycyborg: here ccache --show-stats reports 5826 cache hits and 10493 cache miss, so ~1/3
20100716 18:11:05< alink> that seems not bad, assuming that these numbers are meaningful
20100716 18:12:22< loonycyborg> I have 92664 hits vs 137368 misses.
20100716 18:12:48< alink> seems even better
20100716 18:17:01-!- jbjerk is now known as eleazzaar
20100716 18:17:07< loonycyborg> Because unlike many people I *do* often change compile settings back and forth and do bisections :P
20100716 18:18:08< eleazzaar> alink: i just made a fresh compile
20100716 18:18:25< eleazzaar> what do the decimal numbers mean in the editor when i press "o"?
20100716 18:18:37< eleazzaar> nevermind
20100716 18:18:43< eleazzaar> i see they are coordinates
20100716 18:18:56< eleazzaar> never noticed that before
20100716 18:19:11< alink> eleazzaar: good, btw r44218 fixed an important editor bug
20100716 18:19:20< alink> 1h ago
20100716 18:20:42-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has joined #wesnoth-dev
20100716 18:20:45-!- esr [~chatzilla@wesnoth/developer/esr] has quit [Remote host closed the connection]
20100716 18:21:11< eleazzaar> editor redraw still seems to be messed up
20100716 18:21:23< alink> after r44218 ?
20100716 18:21:54< eleazzaar> no, looks like i didn't catch that one
20100716 18:22:08< alink> it's only one small cpp change, fast to recompile ;-)
20100716 18:22:35< eleazzaar> so i shouldn't "clean all"?
20100716 18:23:22< alink> I don't know how you build wesnoth, but no I don't think so
20100716 18:23:42< eleazzaar> "compiling 1 of 1 source file" sound right
20100716 18:23:55< eleazzaar> i'll be around later today
20100716 18:24:01< Unnheulu> You should clean all?
20100716 18:24:08< timotei> loonycyborg: bisections... that sound like git or hg right? Which one?
20100716 18:24:55< loonycyborg> I've used git bisect on wesnoth in the past.
20100716 18:24:56< timotei> Unnheulu: only if you want to be *sure* everything starts from scratch
20100716 18:25:17< alink> Unnheulu: no, or if something did go wrong
20100716 18:25:34< loonycyborg> But you really don't need explicit support from VCS to do bisections :P
20100716 18:25:40< Unnheulu> So only really if something messed up?
20100716 18:26:24< alink> "clean all" if "something messed up"  sounds right ;)
20100716 18:34:01< CIA-87> esr * r44219 /trunk/data/campaigns/The_South_Guard/_main.cfg: Clean up some spellchecker messages. WML sanity checks now run clean.
20100716 18:40:45< silene> loonycyborg: explicit support helps when you know the regression can come from only part of the source tree
20100716 18:41:19< silene> for instance, i hardly ever bisect on data/ for wesnoth
20100716 18:42:05-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20100716 18:43:50-!- alink [~alink@wesnoth/developer/alink] has quit [Remote host closed the connection]
20100716 18:44:00-!- silene [~plouf@wesnoth/developer/silene] has quit [Quit: Leaving.]
20100716 18:44:42< Unnheulu> Can I tell sudo make install to install it to some where different without redoing the ./configure?
20100716 18:50:50< Unnheulu> Anyone know?
20100716 18:54:41-!- Grickit [~Grickit@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100716 19:08:17< eleazzaar> boucman: alink:  There are still some layering issues i don't understand:
20100716 19:08:19< eleazzaar> http://www.wesnoth.org/forum/viewtopic.php?p=442002&sid=062e0528b8f87d427c46a48aef357703#p442002
20100716 19:10:49< boucman> 1) i'm not sure, but for items on the same layers, there are issues with base= entering the fray... we would have to check what the base  is for the walls
20100716 19:14:46-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20100716 19:14:58< mordante> servus
20100716 19:15:06< boucman> 2) are you sure they are single images ? IIRC multihex mountains are made out of multiple tiles, but i'm not sure myself
20100716 19:16:37< eleazzaar> multiple tiles yes
20100716 19:16:45-!- EdB [~edb@tss37-1-89-84-18-220.dsl.club-internet.fr] has quit [Ping timeout: 246 seconds]
20100716 19:16:56< eleazzaar> but the very top is not it's own file
20100716 19:17:10< boucman> hmm
20100716 19:17:47< boucman> Images which are in the same layer are ordered the classic way, in the  order they are defined. <== from one of the docs page, 
20100716 19:18:21< boucman> but that doc also mentions multiple times a position= parameter which I never saw... so I'm not sure how reliable it is
20100716 19:21:55< eleazzaar> but things like trees layer as they should here
20100716 19:22:03< eleazzaar> also on layer 0
20100716 19:22:56< timotei> hi mordante :D
20100716 19:23:05< mordante> hi timotei 
20100716 19:23:16< boucman> eleazzaar: you sure they layer properly ? did you replace them with a pure color hex to be sure ? 
20100716 19:23:25< boucman> I tend to get confused fast with that sort of stuff
20100716 19:24:12< boucman> also the doc is quite confusing, sometime it says top to bottom, sometime it says in the order the rules are declared, etc...
20100716 19:24:24< eleazzaar> yeah i'm sure
20100716 19:24:40< boucman> my guess is that it's not clear when its "the order within the hex" and "the order relative to neighbouring hex.
20100716 19:25:22< boucman> could you try removing all base= parameters in the mountain definitions and see if it changes something in what you see ?
20100716 19:25:59< boucman> my guess is that withouth base= it's basically drawn top to bottom, but I could be wrong. I'm trying to simplify the problem so we can figure out what's going on...
20100716 19:26:40< eleazzaar> i'm not finding "base=
20100716 19:26:59< eleazzaar> do you mean "Terrain_Base  ?
20100716 19:27:09< boucman> let me check...
20100716 19:27:27< boucman> terrain-graphics/mountains.cfg
20100716 19:27:33< boucman> sprinkeld all around the file
20100716 19:27:43< eleazzaar> ok
20100716 19:27:46< eleazzaar> comment those out?
20100716 19:28:58< boucman> yes, it's just for testing...
20100716 19:29:15< boucman> eleazzaar: i'll stop what i'm doing and have a look at the same time
20100716 19:31:09< boucman> if you're done, tell me the results, though, I need a little time to get things working
20100716 19:31:16< eleazzaar> u
20100716 19:31:22< eleazzaar> well it made things worse
20100716 19:31:41< eleazzaar> without it moutains overlap things to the south they shouldn't
20100716 19:31:43< boucman> yes, it's for testing, not to solve the problem...
20100716 19:31:45< eleazzaar> like each other
20100716 19:31:55< boucman> could you post a screenshot ?
20100716 19:32:02< eleazzaar> just a sec
20100716 19:33:37< eleazzaar> http://img689.imageshack.us/img689/2496/picture1kd.png
20100716 19:34:11< boucman> thx
20100716 19:34:20< eleazzaar> actually it did fix #2
20100716 19:36:39< boucman> that's very weird...
20100716 19:36:42-!- alink [~alink@wesnoth/developer/alink] has joined #wesnoth-dev
20100716 19:36:48< eleazzaar> heh
20100716 19:36:54< boucman> alink: great, you arrive just in time :)
20100716 19:37:31< boucman> alink: http://img689.imageshack.us/img689/2496/picture1kd.png <= afawct everything is at layer 0 and there is no base= set
20100716 19:37:35< alink> ok, but not for long :)
20100716 19:37:41< timotei> fendrin: do mentors have the same deadline for midterm evaluation as students?
20100716 19:37:55< boucman> however the mountains seem to overlap both over and under the bridge...
20100716 19:38:01< boucman> hmm, let me try something
20100716 19:38:34< alink> there is always base set (the c++ code add it)
20100716 19:38:40< eleazzaar> bridge is set to layer 0 for me
20100716 19:38:46< alink> and the rotations code modify it
20100716 19:38:58< boucman> alink: well, ok... all base are set by C++ :P
20100716 19:39:28< alink> eleazzaar: btw about order, it's layer value first, if equal it's base.y, then rule order
20100716 19:39:55< alink> and all of that its split in 2 stacks foreground and background
20100716 19:40:46< boucman> alink: that order is within a hex, but in what order is a tile drawn relative to its neighbours ? (here, bridges are bigger than hex
20100716 19:41:21< alink> the builder code only draws hexes, but it cut big images into hexes and then order the images
20100716 19:41:28< alink> there is no link between hexes
20100716 19:42:00< boucman> ok, so bigger than hex are internally cut... this makes sense.
20100716 19:42:24< boucman> but what layer.y is given to the cut part of a bigger than hex tile ?
20100716 19:42:37< alink> btw, as suggested in forum, I will quickly add a debug tool to display the layers info of one hex
20100716 19:42:42< eleazzaar> so a multi-hex mountain image is interepreted as having differeing bases depending on what hex the cut pieces fall into?
20100716 19:43:20< boucman> that's what I understand, but my understanding is still parcelar
20100716 19:43:28< alink> boucman: I think the tiles cut code update some of these positional info (and that's why it's even more complex with rotation)
20100716 19:44:10< alink> yeah the base.xy part is still not very clear for me. For example, I don't know if it's even usefull
20100716 19:45:24< alink> but I preserved the old behavior . Just make the code more clear about what it is doing. The 'why' is still unknown to me
20100716 19:46:06< eleazzaar> who wants to throw it all away and start over ?  ;)
20100716 19:46:56< boucman> alink: the feature is usefull, It's what allows pseudo-vertical stuff to work, however i don' tknow how robust it is, though
20100716 19:47:09< alink> eleazzaar: my plan is more to progressively replace bad parts
20100716 19:47:49< eleazzaar> boucman: either we are somehow using it wrong, or it's not as robust as we could wish
20100716 19:48:08< boucman> eleazzaar: maybe a little bit of both :)
20100716 19:48:46< alink> boucman: well it's maybe used, but that seems weird. A simple layer key should be enough to do this kind of things
20100716 19:49:08< boucman> alink: if you still have time, could you explain what's going on with the image eleazzaarhas posted ? I can't understand why the bridge is overlapped both on the bottom and top sides
20100716 19:49:35< boucman> alink: the point of the base= was to work with walls, IIRC
20100716 19:49:48< eleazzaar> i set both mountains and bridges to layer 0
20100716 19:50:03< alink> boucman: and walls don't work well at least with foreground stuff
20100716 19:50:14< boucman> having the unit be in front of the wall when being under a castle hex and in the castle when in the castle hex
20100716 19:50:16< alink> eleazzaar: using grid may help for screenshot
20100716 19:50:30< boucman> (beheaded units problem if you remember)
20100716 19:51:02< eleazzaar> comming
20100716 19:51:21< eleazzaar> http://img18.imageshack.us/img18/458/picture2lu.png
20100716 19:51:31< alink> thanks
20100716 19:51:34< boucman> thx
20100716 19:52:30< eleazzaar> i forget.  I've been staring at these long enough that i know where the hex edges are within a few pixels
20100716 19:52:31< alink> btw, as I said, terrain rules order is also used. If all is equals, maybe switch the place of mountains and bridges in terrain_graphics.cfg may affect that
20100716 19:52:41-!- Unnheulu [~ieuan@cpc5-pnth2-0-0-cust800.5-2.cable.virginmedia.com] has quit [Quit: Ex-Chat]
20100716 19:52:50< alink> and IIRC there is also a "precedence" key to control that
20100716 19:53:08< boucman> I tried, but that didn't change a thing as far as I could tell
20100716 19:53:23< boucman> alink: never heard of that key... it's completely undocumented afair
20100716 19:53:34< alink> eleazzaar: and with :foreground ?
20100716 19:53:51< eleazzaar> i can't access that from editor
20100716 19:53:59< alink> ah yes :-(
20100716 19:54:58< alink> well the at least top of mountains is foreground, so it's should be on top of bridges
20100716 19:55:01 * boucman hasn't tested :foreground yet either
20100716 19:55:27< eleazzaar> bridges are defined before mountains, so if it's a question of being in the same hex bridges should overlap mountains
20100716 19:55:37< boucman> alink: i'm not so much trying to solve eleazzaar's problem at this point as trying to understand what's going on...
20100716 19:56:21< boucman> eleazzaar: isn't it the other way round ? bridge rules are applied first, so are drawn first, so are under the mountains
20100716 19:56:23-!- Gallaecio [~Gallaecio@232.158.60.213.dynamic.mundo-r.com] has joined #wesnoth-dev
20100716 19:56:59< alink> last rule go on top of first rule
20100716 19:57:11< alink> but I suggest to wait few hours, so I can eat something and code my little debug tool. That should at least display all the info we need.
20100716 19:57:27< eleazzaar> sounds good
20100716 19:57:31< boucman> sure
20100716 19:57:40< alink> after that, it will be easier to understand (I hope)
20100716 19:57:46< eleazzaar> my brains were about to stark leaking out of my ears anyway
20100716 19:57:53< eleazzaar> s/stark/start
20100716 19:58:00< boucman> eleazzaar: at least, we can explain your screenshot (imgshack, not everything in the forum post) and that's a progress
20100716 19:58:06< fendrin> timotei: no idea. the deadline is gone by now.
20100716 19:58:08-!- Gallaecio [~Gallaecio@232.158.60.213.dynamic.mundo-r.com] has quit [Remote host closed the connection]
20100716 19:58:08-!- esr [~chatzilla@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20100716 19:58:37< timotei> yeah, it's closed in 2 mins :D
20100716 19:58:43< alink> ok afk, I"ll be back soon with more info (and energy)
20100716 19:58:53< eleazzaar> alink: thanks
20100716 19:58:54< timotei> esr: hi
20100716 19:59:00< boucman> assuming that all images are set at the same base= by c++ and that c++ adjust the base=properly when cut it so it acts in a similar manner, then the rule order is the only thing that matters
20100716 19:59:32< boucman> and mountains are declared after bridges, so they end up on top
20100716 19:59:39< eleazzaar> i'm still not clear on what base= was doing
20100716 19:59:53< boucman> now let's move bridges at the bottom and see what happens :)
20100716 20:00:00< eleazzaar> is it just used for mountains?
20100716 20:00:31< boucman> eleazzaar: neither am I, I can explain the idea behind it if you want, but i'm not quite clear how it really works
20100716 20:00:40< boucman> no, it's used for walls too
20100716 20:01:09< boucman> here is the idea. Usually when we put things on hex, we draw things bottom to top
20100716 20:01:10< eleazzaar> testing with bridge WML moved...
20100716 20:01:36< eleazzaar> so far so good
20100716 20:01:50< eleazzaar> (your explanation i mean)
20100716 20:01:54< boucman> i.e if you put flowers on top of grass, it's because the flowers are "physically" on top of grass. both flowers and grass are flat, and are on top of one another
20100716 20:02:26< boucman> it's a "bird view" idea
20100716 20:02:43< eleazzaar> OK, that indeed made the bride go over the mountains on both sides
20100716 20:03:06< boucman> however, when objects that represents vertical stuff start entering the mix, it's a bit complicated, and the 45° angle of view must be accounted for
20100716 20:03:14< eleazzaar> by "walls" do you mean castles, or just cave walls?
20100716 20:03:37< boucman> great tree, units, castle walls are such objects
20100716 20:03:50< boucman> eleazzaar: i'm sure for castle walls, i'm not sure for cave walls
20100716 20:04:46< boucman> suppose a unit is in a castle hex, the wall should be drawn in front of the unit, not because the wall ins "on top" of the unit, but because it's "in front" of the unit
20100716 20:05:54< boucman> now if you have a unit that is logically in the hex under a castle hex, but overlaps the castle hex (flying units for example do that) we need to draw the unit on top, because this time it's the unit that is in front.
20100716 20:08:10< eleazzaar> understand so far
20100716 20:08:11< boucman> so to solve the problem we have this "base" system. which basically tells the engine where the represented object touches the ground. from that and the hex the object is in, the engine can give a xy position to every vertical object, and then draw them "back to front" thus having a correct stacking of image to represent the horizontal situation
20100716 20:09:07< boucman> that's the problem we solve with the base= parameter, but it's an area I don't understand well yet, and non of the macros I have rewritten so far use it (they only describe flat objects)
20100716 20:10:04< boucman> but that's one of the reasont I wanted to split horizontal and vertical overlay... I expect problem with the base parameters and that's a way to simplify it for the flat case
20100716 20:11:10< eleazzaar> hmmm
20100716 20:13:30< eleazzaar> OK, then perhaps the problem is that multi-hex terrain that are supposed to be based on a different hex are getting chopped up and treated seperately
20100716 20:14:10< eleazzaar> without taking into account that something from a more southnerly hex should always be in from of something from a more northerly hex
20100716 20:14:33< eleazzaar> i don't think i'm explaining very well
20100716 20:15:22< boucman> I have to admit I have problems understanding :P
20100716 20:15:40< boucman> moreover I am not very clear on the values to use for base=
20100716 20:15:54< eleazzaar> yeah there's 2
20100716 20:16:02< boucman> nor what the default value ends up being...
20100716 20:16:13< eleazzaar> i would only expect 1 for a pseudo y offset
20100716 20:16:24< boucman> eleazzaar: yes, it's a X,Y pair, and no, I hae no idea what X is for :P
20100716 20:19:35< eleazzaar> :P
20100716 20:23:41-!- billynux [~billy@wesnoth/developer/billynux] has joined #wesnoth-dev
20100716 20:23:51< billynux> hi all, mordante
20100716 20:26:47< mordante> hi billynux 
20100716 20:27:11< timotei> hi billynux :D
20100716 20:27:16< billynux> hi mordante, did you catch up with the logs?
20100716 20:27:18< billynux> hi timotei 
20100716 20:28:35-!- _jbx_ [~jbailey@12.190.80.225] has quit [Quit: Dig that hole, forget the sun.]
20100716 20:29:58< mordante> billynux, yeah 
20100716 20:30:30< mordante> billynux, another question how do you feel you are with the schedule, behind or on schedule
20100716 20:30:31< billynux> mordante, and have you tested the current implementation?
20100716 20:30:51< mordante> my feeling is that you're about on schedule
20100716 20:31:20< billynux> mordante, hm... it depends on the interpretation of the project
20100716 20:31:27< billynux> mordante, I feel I'm about on schedule too
20100716 20:31:34< billynux> mordante, but I would like to be ahead :)
20100716 20:31:34< mordante> the gsoc part ;-)
20100716 20:31:59< billynux> mordante, I do feel I'm a little behind if I want to redesign the API
20100716 20:31:59< mordante> good then I keep that on the review
20100716 20:32:15< billynux> mordante, and implement it before august 16
20100716 20:32:57< billynux> but looking at the project original specs, there is nothing about redesigning the API (only rewriting)
20100716 20:33:19< billynux> however, I think the job calls for a redesign :)
20100716 20:33:29< mordante> exactly and that's what we will judge you by
20100716 20:33:32< mordante> agreed 
20100716 20:33:43< billynux> mordante, so... ATM I really need to debug this out-of-sync errors
20100716 20:33:51< mordante> and we're free to change to goals if we feel the need
20100716 20:34:24< mordante> oogle trusts the mentor do what they think is the right thing to do :-)
20100716 20:34:31< mordante> Google*
20100716 20:34:46< billynux> "change to goals" (s/to/the/ ?)
20100716 20:35:06< mordante> yeah that ;-)
20100716 20:35:36< billynux> mordante, yes, the best (only?) decision by Google was leaving it up to the organizations/mentors
20100716 20:36:24< mordante> they decided a lot more but not on how the projects should do it
20100716 20:36:45< billynux> remember the old bug? It was the stupidest thing... I was waiting for the completion of an operation
20100716 20:36:53< billynux> (which requires a handler to be called)
20100716 20:37:10< billynux> from inside another handler 
20100716 20:37:34< billynux> and asio insures you one thread per each call to io_service::run
20100716 20:37:56< billynux> so, having only one thread running the service means handlers are mutually excluded
20100716 20:39:16< mordante> so you created your own async dead-lock
20100716 20:39:46< billynux> yeah :
20100716 20:39:47< billynux> :)
20100716 20:40:30< mordante> well regarding stupid things I tested all worked perfectly... with a checkout with the SDL networking stuff
20100716 20:40:36< mordante> will retest in a sec
20100716 20:40:45< mordante> afk for a short while
20100716 20:40:46-!- timotei21 [~Timotei@193.34.191.4] has joined #wesnoth-dev
20100716 20:42:53< billynux> mordante, ok, what tests "worked perfectly"? :) I have some problems with the client implementation ATM (the out-of-sync errors)
20100716 20:44:00-!- timotei [~Timotei@wesnoth/developer/timotei] has quit [Ping timeout: 258 seconds]
20100716 20:45:16-!- DesertPanther_ [~Khalid@41.235.5.229] has joined #wesnoth-dev
20100716 20:46:52-!- timotei [~Timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20100716 20:47:50-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has quit [Ping timeout: 258 seconds]
20100716 20:50:14< mordante> billynux, read the rest of the sentence ;-)
20100716 20:50:16-!- timotei21 [~Timotei@193.34.191.4] has quit [Ping timeout: 276 seconds]
20100716 20:51:03< billynux> ok, so you tested the ANA/SDL compatibility
20100716 20:51:23< billynux> I assume the ANA wesnothd + 2 (or more) SDLnet clients playing on it
20100716 20:51:33< mordante> no just used a checkout without ANA
20100716 20:51:40-!- timotei21 [~Timotei@193.34.191.4] has joined #wesnoth-dev
20100716 20:51:42< mordante> hence the need to retest ;-)
20100716 20:52:04< boucman> okay, it starts to make sense... I'm getting the grasp of that layering thingy with mountains
20100716 20:52:16< billynux> oh, ok
20100716 20:53:28< CIA-87> esr * r44220 /trunk/data/tools/wmllint: -p or --progress option for wmllint: - dumps filenames as it processes.
20100716 20:54:09-!- timotei [~Timotei@wesnoth/developer/timotei] has quit [Ping timeout: 240 seconds]
20100716 21:02:32-!- timotei [~Timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20100716 21:04:58-!- timotei21 [~Timotei@193.34.191.4] has quit [Ping timeout: 260 seconds]
20100716 21:11:45-!- Johannes13__ [~Johannes@pD95003D8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20100716 21:13:32< billynux> mordante, well, as you probably read, I don't see any problems with the server in the tests
20100716 21:14:33-!- Johannes13_ [~Johannes@unaffiliated/johannes13] has quit [Ping timeout: 240 seconds]
20100716 21:16:30-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100716 21:22:08< alink> back
20100716 21:22:15< boucman> eleazzaar: ok, I think I understand most of it...
20100716 21:22:39< boucman> I've experimentally fixed the "castle next to mountain" in your screenshot  to be sure
20100716 21:22:51-!- chr [~quassel@89.204.137.6] has joined #wesnoth-dev
20100716 21:23:13< boucman> alink, eleazzaar maybe you can help me understand...
20100716 21:24:05< boucman> mountains use vertical layering (which makes sense) however, the value for their base= should theoretically be x=<middle of hex> y=<bottom of hex>
20100716 21:24:22< boucman> however it seems these have been tweaked a couple of pixel up and left.
20100716 21:25:17< boucman> that's probably a hack to go around another layering problem... but I have no idea which...
20100716 21:25:33-!- chr_ [~quassel@89.204.137.6] has quit [Ping timeout: 265 seconds]
20100716 21:27:57< boucman> alink: I think I understand the problem...
20100716 21:28:17< boucman> or at least the place where the vertical layer don't work the way we would instinctively expect
20100716 21:28:41< boucman> suppose we have two vertical objects in hex A and B, A beind north of B
20100716 21:29:00 * eleazzaar is listening
20100716 21:29:05< boucman> and the object in A is tall enough to overlap in B
20100716 21:29:56< boucman> if the base.Y of A is in front of base.Y of B, A wil be in front of B
20100716 21:30:30-!- EdB [~edb@tss37-1-89-84-18-220.dsl.club-internet.fr] has joined #wesnoth-dev
20100716 21:30:43< boucman> however if they are equal or if base.Y of B is bigger than bese.Y of A, then B will be drawn in front of the cut part of A.
20100716 21:30:56-!- timotei21 [~timo@193.34.191.4] has joined #wesnoth-dev
20100716 21:31:08< boucman> in other word the "hex offset" of A seems not to be taken into account when calculating the base.y for the part of A that is in B
20100716 21:31:22< alink> really back now :)
20100716 21:31:48< eleazzaar> yeah, that's what i was trying to say earlier
20100716 21:31:58< boucman> I have experimented a bit with a castle in B and a frozen mountain in A, and moving the base.y of the mountain make it seems those rules are respected
20100716 21:32:22< boucman> well, I needed to try it to understand it :D
20100716 21:32:47< eleazzaar> heh, i couldn't explain it or prove it, so your time certainly wasn't wasted
20100716 21:33:47-!- EdB [~edb@tss37-1-89-84-18-220.dsl.club-internet.fr] has quit [Remote host closed the connection]
20100716 21:34:01< alink> I plan trying to display base.y value in my new tool, that should allow to verify this
20100716 21:34:12< eleazzaar> The question is: *should* he "hex offset" of A seems not to be taken into account when calculating the base.y for the part of A that is in B -- or would that mess up something else we haven't thought of?
20100716 21:35:19< boucman> alink: base.y is for one image and you can have multiple images in one hex, I'm not sure how you want to display that...
20100716 21:36:05< boucman> eleazzaar: it would probably break some stuff, but on the other hand it would work the way we instinctively expect it to...
20100716 21:36:15-!- Sirp_ [97c1dc1c@gateway/web/freenode/ip.151.193.220.28] has joined #wesnoth-dev
20100716 21:38:01< alink> boucman: don't worry about that, I have a plan :-)
20100716 21:38:05< eleazzaar> yeah, as long as it doesn't break something that's prohibitively difficult to fix, i'm all for breaking stuff if it makes things intutive
20100716 21:38:15< eleazzaar> or more intiutive
20100716 21:38:16< boucman> cool :)
20100716 21:38:28< alink> my main problem is that console don't work in editor (yet)
20100716 21:39:24-!- timotei21 [~timo@193.34.191.4] has quit [Ping timeout: 265 seconds]
20100716 21:39:24< alink> eleazzaar: btw to use :foreground in editor, use it in game then quit to main menu and start editor, :foreground will still be on
20100716 21:39:39 * boucman is probably going to rewrite his macros "yet again" tomorow :(
20100716 21:42:22-!- jbjerk [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has joined #wesnoth-dev
20100716 21:42:22-!- eleazzaar [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has quit [Read error: Connection reset by peer]
20100716 21:43:15< CIA-87> boucman * r44221 /trunk/data/core/terrain-graphics/tracks.cfg: fix an accidentally hard coded layer in bridge macros
20100716 21:44:12< jbjerk> hmm i think some of the problem is the way things get divided out into foreground and background
20100716 21:44:18< jbjerk> oop
20100716 21:44:22-!- jbjerk is now known as eleazzaar
20100716 21:45:17< mordante> billynux, just finished testing with two clients on the official server and all went well :-)
20100716 21:45:17-!- eleazzaar [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has quit [Read error: Connection reset by peer]
20100716 21:45:28-!- jbjerk [~jbjerk@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has joined #wesnoth-dev
20100716 21:45:31< alink> is_background = layer < 0 || (layer == 0 && basey < UNITPOS);   UNITPOS = 36+18
20100716 21:45:44-!- jbjerk is now known as eleazzaar
20100716 21:45:53< billynux> mordante, really? that's good. But there are still bugs in it, too bad you didn't run into them
20100716 21:46:05< billynux> mordante, right know, I'm fixing a disconnect bug in the server
20100716 21:46:25< billynux> (disconnection doesn't remove the client proxy in the server)
20100716 21:46:39< mordante> billynux, at least it means that things start to look promising :-)
20100716 21:46:46< billynux> indeed :)
20100716 21:47:17< mordante> would it be an idea to push ANA as default again?
20100716 21:47:25< boucman> alink: question, do you have any idea what base.x is for ?
20100716 21:47:38< alink> boucman: useless AFAIK
20100716 21:47:49< mordante> what problems/bugs remain?
20100716 21:48:03< billynux> mordante, it certainly wasn't before, as for right know... I don't think so either
20100716 21:48:07< mordante> also the key= issue you still have it
20100716 21:48:08< Sirp_> this might be slightly controversial due to the reason ... but Wesnoth was mentioned on CNN. :) http://www.cnn.com/2010/TECH/gaming.gadgets/07/14/top.ipad.games/index.html?iref=NS1
20100716 21:48:13< alink> boucman: ah no used in rotation maybe
20100716 21:48:15< billynux> mordante, disconnection to a server isn't working
20100716 21:48:39< billynux> mordante, and the clients seem to go into sync problems for some unknown reason
20100716 21:48:45< boucman> alink: ok, thx... it didn' make sense to me...
20100716 21:48:49< billynux> (which you CNR)
20100716 21:48:51< mordante> cool Sirp_ 
20100716 21:49:08< alink> boucman: the 2D vector base is probably rotated and so the x info go in the resulting y  (somehow)
20100716 21:49:08< mordante> CNR?
20100716 21:49:31< mordante> what kind of sync problems network or a game going out of sync?
20100716 21:49:49< boucman> ok, i'll ignore that for the moment...
20100716 21:50:16< billynux> mordante, CNR = Could Not Reproduce, the sync problems are in the game
20100716 21:50:26< billynux> mordante, but I don't know why
20100716 21:50:30< alink> boucman: that probably don't work well with perspective :-/
20100716 21:51:19< mordante> billynux, you mean a message in game that the game is out of sync?
20100716 21:51:42< billynux> mordante, yes, and further on the game *IS* in an inconsistent state
20100716 21:51:46< billynux> thus unplayable
20100716 21:52:29< billynux> the errors however are not very helpful, i.e. indicating that its the wrong place to move to, etc... (when its clearly not)
20100716 21:52:34< mordante> ok, but that can be a network problem, but also something else. That problem also occurs with SDL every now and then
20100716 21:52:39< boucman> well, I can't really see why rotation would change the base, except to put base.y at a corresponding point at the new hex, but that point would logically depend only on y
20100716 21:52:59< mordante> billynux, of course it's a bug, but not one you should worry about per se
20100716 21:53:06< boucman> the only place I can see that mix rotations and base are walls, and they seem to work well, though
20100716 21:53:11< billynux> mordante, I'm pretty sure its a network problem in my case, but I can't single it out
20100716 21:54:06< mordante> can you log what you send and what you receive? preferably of the server and client?
20100716 21:54:20-!- chr [~quassel@89.204.137.6] has quit [Read error: Connection reset by peer]
20100716 21:54:21< billynux> mordante, yes
20100716 21:54:24< mordante> then you can compare the logs when the game is out of sync
20100716 21:54:57< billynux> mordante, how can I check the messages of the saved game?
20100716 21:54:59< mordante> and should make it possible to see whether or not the network is too blame
20100716 21:55:36-!- chr [~quassel@89.204.137.6] has joined #wesnoth-dev
20100716 21:55:40< alink> boucman: yeah seems to not make sense with our current use of basey. esp. since it can change the foregound/background status just by rotate it
20100716 21:56:39< mordante> billynux, just open the saved game and start to grep
20100716 21:56:47< boucman> if you think of "rotating" the point, yes you need the x... but logically, since these ar vertical stuff... i'm not quite sure. rotation makes little sense to me 
20100716 21:57:08< boucman> walls do rotate and it makes sense, but i'm not sure what their contact point should become when rotating
20100716 21:57:32< thespaceinvader> boucman: are you busy?
20100716 21:57:39< alink> boucman: btw my tool progress well, I can now see all image url and their base.x/y and layer. :-)
20100716 21:58:46-!- Grickit [~Grickit@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Remote host closed the connection]
20100716 21:58:53< boucman> thespaceinvader: a little but I probably can discuss at the same time... what's the problem ?
20100716 22:00:18< billynux> mordante, can you elaborate as to how I can compare the saved game and what should have happened?
20100716 22:00:19< thespaceinvader> do you (or anyone else familiar with the animation capabilities) know of a way that I can do haloes that automatically flip based on unit direction?
20100716 22:00:23< billynux> mordante, I see there is a .gz file there
20100716 22:00:31< thespaceinvader> or the equivalent thereof
20100716 22:00:35< billynux> mordante, if I load it from the game and can replay it
20100716 22:00:53< mordante> my editor opens gz and shows the contents as text
20100716 22:00:55< billynux> s/and/I/
20100716 22:01:17< boucman> hmm, yes, you probably can, but the specifics are a bit vague in my head...  i'll dig for you
20100716 22:01:29-!- Johannes13_ [~Johannes@unaffiliated/johannes13] has joined #wesnoth-dev
20100716 22:01:37< mordante> but I think the easiest first is to see what did the client send to the server and did the server properly forward it, if so the blame is not the network
20100716 22:01:38-!- chr [~quassel@89.204.137.6] has quit [Remote host closed the connection]
20100716 22:01:46< boucman> in the mean time, what do you call "halo" is that the halo defined by halo= in the [unit_type] tag ?
20100716 22:01:52< thespaceinvader> boucman: thanks co much
20100716 22:01:57< thespaceinvader> boucman: yes, it is
20100716 22:02:27< mordante> then maybe look at the savegames afterwards, not even 100% that would be needed
20100716 22:02:32< billynux> mordante, ok, I got that, but how do I figure out where there is a out-of-sync error
20100716 22:03:05< billynux> mordante, I played an ana client vs. an SDL client on the official server
20100716 22:03:20< billynux> mordante, and had each player moving one hex in the y axis at every turn
20100716 22:03:24< mordante> billynux, by the popup box in game that tells you about the out-of-sync
20100716 22:03:49< billynux> yes, but I didn't understand why it was so
20100716 22:03:57< billynux> the incoming/outgoing messages looked fine
20100716 22:04:13-!- Johannes13__ [~Johannes@pD95003D8.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20100716 22:04:17< billynux> I can re check that later, but just wanted to know what the best way to debug it would be
20100716 22:04:29< mordante> like I said before out-of-sync also happens due to various bugs outside the network code
20100716 22:05:07< mordante> in your case you want to proof the problem is not the network code so best compare the send and receive logs of the network
20100716 22:05:08< billynux> mordante, maybe so, but my client goes out-of-sync far more often than the SDL implementation (as for my testing)
20100716 22:05:41< mordante> about how often does it occur?
20100716 22:05:47< billynux> mordante, I guess I could rephrase the question as follows: What is an out-of-sync error? Which two things should be in sync?
20100716 22:05:58< billynux> mordante, very often to me
20100716 22:05:58< timotei> hmm, boucman I think I've found something "bad"
20100716 22:06:24< boucman> timotei: i'm listening... but i have three things running in paralell right now
20100716 22:06:34< timotei> oh, then I'll put it later.:D
20100716 22:06:42< boucman> what area ?
20100716 22:06:50< timotei> I think it has to do with bridges.
20100716 22:07:09< timotei> one sec, I give you a print
20100716 22:07:15< mordante> out of sync means that the clients disagree about the state of the game let me explain it further
20100716 22:07:44< mordante> suppose I change the recruit cost of a unit to 5 gold and have 5 gold I can recruit the unit
20100716 22:08:17< mordante> the other player gets the command recruit the unit, but for him the unit costs 20 gold so it's impossible
20100716 22:08:32< mordante> at that point that client complains the game is out of sync
20100716 22:09:01< mordante> it can happen with different versions of addons, different versions of the game, somebody cheating...
20100716 22:09:02< billynux> ok
20100716 22:09:04< timotei> boucman: http://i31.tinypic.com/2gy0p61.png
20100716 22:09:18< boucman> thespaceinvader: ok, it seems that the fact that halos don't change orientation is hardwired.... and IIRC it was done on purpose... not sure why
20100716 22:09:20< timotei> boucman: I put bridges all over the village, and they are there... but don't know
20100716 22:09:20< mordante> another bug in the code or using some commands which are not save in MP games
20100716 22:09:36< timotei> boucman: you can see their "feet"
20100716 22:09:39< billynux> mordante, so... on one hand I have the replay (.gz)
20100716 22:09:54< mordante> and of course the network can also be a problem if a move command doesn't get send to the other side 
20100716 22:09:59< billynux> and on the other I can have all the received/sent messages from/to my ana client
20100716 22:10:06< mordante> that side thinks the unit is somewhere else
20100716 22:10:09< boucman> however you can go around the problem by setting a [halo_frame] whith whatever you want in all animations (especially the standing anim since it serves as a base for all other anims.)
20100716 22:10:36< mordante> did you compare the network logs?
20100716 22:10:37< thespaceinvader> boucman: ok, so i'd need to do a standing anim with a halo frame tag inside it?
20100716 22:10:45< billynux> mordante, not really
20100716 22:10:53< boucman> yes, a special frame for halos
20100716 22:10:53< billynux> mordante, I wanted to ask you these questions before
20100716 22:11:03< mordante> how long is the log?
20100716 22:11:21< boucman> you need to do it for all you animations, and you will have to add a standing anim (if you don't have one yet) to add it there too
20100716 22:11:25< billynux> mordante, I didn't save them ATM
20100716 22:11:32< boucman> just pastebin your cfg if you have a doubt
20100716 22:11:43< billynux> mordante, just looked at the messages and figured they looked good enough
20100716 22:11:46< boucman> timotei: i'm not sure what i'm supposed to see here...
20100716 22:11:57< billynux> mordante, do you want me to reproduce the error now and paste it somewhere?
20100716 22:12:09< timotei> well, I put some bridges over the village, and they don't replace it:|
20100716 22:12:14< timotei> their hidden back
20100716 22:12:31< timotei> don't know, I thought it's of the bridges you were talkin :-P
20100716 22:12:34< timotei> but nevermind me if not
20100716 22:12:39< boucman> in the screenshot you posted ?
20100716 22:12:52< mordante> billynux, yes please I'll be heading for bed soon, but maybe you can reproduce it before I'm off
20100716 22:12:59< thespaceinvader> boucman: thanks very much, i'll give it a try tomorrow probably
20100716 22:13:06< boucman> well, the probelm i discused with eleazzaar did involve bridges, but it was way more generic than that
20100716 22:13:17< boucman> ok, feel free to ping me
20100716 22:13:24< billynux> mordante, give me 5'
20100716 22:13:31< mordante> my gut feeling would be to blame something else as the network ;-)
20100716 22:14:00< mordante> of course we all know how well humans guess
20100716 22:14:27< timotei> boucman: yeah
20100716 22:16:52< timotei> ok guys, I'm out
20100716 22:16:53< timotei> good night
20100716 22:17:12-!- timotei [~Timotei@wesnoth/developer/timotei] has quit [Quit: Leaving]
20100716 22:17:13< mordante> night timotei 
20100716 22:17:39< billynux> mordante, done
20100716 22:17:51< billynux> mordante, where do you want them? pastebin? mail?
20100716 22:18:55< mordante> billynux, how big?
20100716 22:19:14< billynux> it's ~2k lines for my console buffer
20100716 22:19:32< mordante> then email
20100716 22:19:37< billynux> and a 28K .gz file from the replay
20100716 22:19:38< billynux> ok, 1'
20100716 22:20:48< billynux> mordante, sent
20100716 22:20:50-!- Sirp_ [97c1dc1c@gateway/web/freenode/ip.151.193.220.28] has quit [Ping timeout: 252 seconds]
20100716 22:22:30< alink> boucman: eleazzaar: quick preview of ":layers" http://img514.imageshack.us/img514/2554/layersu.png
20100716 22:22:49< alink> but still need to cut the images like they are used
20100716 22:23:07< boucman> wow
20100716 22:23:17< boucman> that. looks. great.
20100716 22:23:30< mordante> billynux, what means "Removing illegal command 'move' from: ANA. Current player is: SDL (1/3)."
20100716 22:23:37< alink> that will also show how we use a lot of transparent parts eveywhere
20100716 22:23:57< mordante> cool alink 
20100716 22:24:04< boucman> the only thing is that it probably would be much more usefull if you only showed the stack of the highlighted hex... 
20100716 22:24:19< billynux> mordante, good question, I thought that was normal
20100716 22:24:26< billynux> and forgot to ask you about it
20100716 22:24:40< alink> boucman: it does that
20100716 22:24:52< boucman> it does ? 
20100716 22:24:53< alink> <alink> but still need to cut the images like they are use   
20100716 22:24:59< billynux> mordante, I presume that it means its disregarding a command it's not supposed to interpret/show
20100716 22:25:07< alink> boucman: note the location field
20100716 22:25:08< billynux> mordante, but I don't know
20100716 22:25:44< boucman> well, why do we have the base frames of neighbouring hex in there... base frames are exactly 72x72, they shouldn't split...
20100716 22:25:59< alink> boucman: ah no, indeed small error
20100716 22:26:11< alink> that's why it was only a preview :-)
20100716 22:26:20< boucman> ok, :)
20100716 22:26:47< alink> boucman: what I mean is: it want to do that
20100716 22:26:56< boucman> :P
20100716 22:27:05< mordante> billynux, ok what network layer runs on the server
20100716 22:28:11< alink> or is it right? not sure now. I really need to cut the images to be sure
20100716 22:28:15< billynux> in this example, it's the official server, so SDL
20100716 22:28:16< alink> anyway brb
20100716 22:28:59< mordante> billynux, ok I also see several failed to uncompress messages in the log
20100716 22:29:16< mordante> are you sure you read the entire message before decompressing them
20100716 22:29:59< mordante> also when you use async_write are you sure the buffers still are alive when you are in the handler?
20100716 22:30:23< billynux> mordante, pretty much, ys
20100716 22:30:32-!- Blueblaze [~Blueblaze@adsl-76-202-21-28.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100716 22:30:40< billynux> mordante, I think most of the "failed to uncompress" are for messages with a "sent = " line
20100716 22:30:50< boucman> alink: would it also be possible to display what flags are set ?
20100716 22:30:54-!- dtiger_ [~dtiger@dynamic-vpdn-93-125-68-230.telecom.by] has quit [Remote host closed the connection]
20100716 22:31:17< billynux> mordante, it looks like all of them are
20100716 22:31:19< alink> boucman: flags?
20100716 22:31:27< alink> ah ok
20100716 22:31:32< billynux> mordante, I was asking zookeper about that last night
20100716 22:31:56< billynux> mordante, can a WML have a "sent = " line (nothing after the '=' char)
20100716 22:32:07< alink> boucman: yes, only UI problems to solve
20100716 22:32:13< alink> or implement
20100716 22:32:23< billynux> mordante, maybe I (the network layer) am supposed to fill in the " sent " information for the WML
20100716 22:32:53< boucman> ok, or as a second window you could open with a button on the bottom of this one
20100716 22:33:06< mordante> I think it's valid and not all send= fail to uncompress
20100716 22:33:12-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100716 22:33:30< mordante> maybe do the same with two SDL clients and snoop on their traffic
20100716 22:33:31< alink> boucman: yeah I plan to so something with buttons, but let's finish this first
20100716 22:33:39< boucman> k
20100716 22:35:08< alink> boucman: I also try to not create too much new dependencies. Builder is well isolated for the moment
20100716 22:35:32< billynux> mordante, maybe I'm not implementing the send_data_all_excpet method right
20100716 22:35:34< boucman> ok..
20100716 22:35:47< boucman> alink: having debug tools for terrain would be a wonderfull addition, though
20100716 22:36:13< billynux> mordante, I really don't understand why this method is invoked in the client
20100716 22:36:16< mordante> billynux, could be only don't understand why it then worked well for me an entire game
20100716 22:36:35< billynux> mordante, the implementation in the SDL version is very straight forward
20100716 22:37:26< alink> boucman: agreed and you know how I love debug tools :-)
20100716 22:37:46< boucman> we all do :)
20100716 22:38:49< billynux> :)
20100716 22:39:07< mordante> alink, our debug toolsmith :-)
20100716 22:39:22< alink> :-)
20100716 22:39:25< mordante> billynux, ok but would it be possible to see what SDL sends over the network?
20100716 22:39:53< billynux> mordante, yes, tinkering with the SDL implementation (adding a std::cout << cfg; would do it)
20100716 22:40:00< thespaceinvader> boucman: like this?
20100716 22:40:04< thespaceinvader> http://wesnoth.pastebin.com/g67D7vRq
20100716 22:40:22< billynux> mordante, apart from that, I have some stuff I haven't commited, and I'm testing with that :S
20100716 22:40:39< billynux> but I did get the out-of-sync errors before these minor changes
20100716 22:41:08< mordante> ok
20100716 22:41:14< boucman> thespaceinvader: yes, except that you should probably entirely drop the duration= part, since this is not realy an animation
20100716 22:41:21< thespaceinvader> ah ok
20100716 22:41:26< boucman> this way the engine will not refresh at all
20100716 22:41:31< mordante> but I'm about to go so will have to look at it later
20100716 22:41:42< thespaceinvader> i'll test that out and see if it works, thanks
20100716 22:42:37< billynux> mordante, ok, I'll try to commit these changes
20100716 22:42:45< billynux> mordante, fix the disconnection issue
20100716 22:43:00< billynux> mordante, and then work on these out-of-sync
20100716 22:43:02< mordante> ok 
20100716 22:43:27< mordante> good luck hunting for the bug
20100716 22:43:34< mordante> see you later, night
20100716 22:43:37< billynux> I just changed a line in the send_all_except to check for the wesnoth-assigned id instead of the local ana id
20100716 22:43:41< billynux> see you later
20100716 22:44:01< mordante> ok hope that fixes it
20100716 22:44:09-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20100716 22:45:53< thespaceinvader> boucman: doesn't seem to auto-flip
20100716 22:46:01< boucman> ???
20100716 22:46:21< boucman> it did replace standing/selection etc anims, though, didn't it ?
20100716 22:46:50< thespaceinvader> the standing anim works, and has the halo, but the halo doesn't change direction with the unit
20100716 22:46:53-!- shadowm_laptop is now known as shadowm_tty
20100716 22:47:08< boucman> if you select the unit, it keeps the halo ?
20100716 22:47:09< thespaceinvader> unless... refreshing the cache reloads stuff in add-ons, right?
20100716 22:47:12< thespaceinvader> yep
20100716 22:47:25< thespaceinvader> it did that with the basic halo= line though
20100716 22:47:43< boucman> thespaceinvader: the halo= is totally different code internally
20100716 22:47:47< thespaceinvader> ah ok
20100716 22:48:56-!- shadowm_tty is now known as shadowm_laptop
20100716 22:49:52-!- Crab_ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100716 22:51:43< boucman> thespaceinvader:  http://wesnoth.pastebin.com/8FUKKFrK <= try this
20100716 22:53:31< thespaceinvader> that works
20100716 22:53:54< thespaceinvader> the only slight oddity being that the halo remains in place when the unit moves, then disappears when it reaches the destination
20100716 22:54:01< thespaceinvader> but the solution is probably a movement anim
20100716 22:55:50< boucman> not sure that would sole your problem, the question is "should the halo inherit the frame's offset" and the answer is probably yes
20100716 22:56:37< boucman> and it should, that's weird
20100716 22:56:57< boucman> well I'm in bridge macros right now, try with a mvt anim, and if it doesn't solve the problem ping me
20100716 22:57:43< thespaceinvader> will do
20100716 22:58:01-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Ping timeout: 276 seconds]
20100716 23:02:46-!- fendrin [~fabi@88-134-103-91-dynip.superkabel.de] has joined #wesnoth-dev
20100716 23:02:46-!- fendrin [~fabi@88-134-103-91-dynip.superkabel.de] has quit [Changing host]
20100716 23:02:46-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100716 23:05:57< alink> pfff cutting these images to hex is hard :-/
20100716 23:06:12< alink> mainly  because I must pass by GUI1
20100716 23:06:27< boucman> alink: listing flags would be wonderfully usefull to me right now, if it's easier to do :P
20100716 23:07:21< thespaceinvader> boucman: movement anim didn't fix the issue
20100716 23:07:39< boucman> ok, not really a suprise, 
20100716 23:08:03< alink> boucman: well the problem is that now my local copy is full of dirty changes for this hex-image thing, but I will take a quick look
20100716 23:11:25< thespaceinvader> thanks for the help boucman
20100716 23:11:31< alink> oohoo probably a lot of luck, but that image hack worked at the first try :-)
20100716 23:11:38< thespaceinvader> i'm guessing an engine fix is needed to avert the remaining minor niggle
20100716 23:12:01< boucman> thespaceinvader: most likely, yes...
20100716 23:13:33< alink> boucman: I was not far off : http://img268.imageshack.us/img268/6514/layer2.png
20100716 23:13:39< alink> before : http://img514.imageshack.us/img514/2554/layersu.png
20100716 23:13:51< alink> there is really a lot of transparent stuff
20100716 23:14:13< boucman> ithat is suprising... we'll have to study it
20100716 23:14:58< alink> well, I was aware of it, but seeing it so precisely is different
20100716 23:15:23< boucman> I was not...
20100716 23:15:33< boucman> where do these come from ?
20100716 23:16:45< alink> all the little terrain_graphics  map= "*, *, *, 1 *, *, *" with the fact that all image are square
20100716 23:17:29< boucman> I can understand what you mean with images being square, but I'm not sure what you mean with map=
20100716 23:17:36< alink> so at least the 4 corners are added, not sure about north and south
20100716 23:17:48< alink> map key in [terrain_graphics]
20100716 23:18:05< boucman> yes, what do they do here...
20100716 23:18:33< alink> I am not sure but i believe they specify how many hexes should receive an image part
20100716 23:18:47< alink>         map="
20100716 23:18:49< alink> , *
20100716 23:18:51< alink> * , *
20100716 23:18:52< alink> , 1
20100716 23:18:54< alink> * , *
20100716 23:18:55< alink> , *"
20100716 23:19:31< boucman> ah, ok... yes they do that
20100716 23:21:12< alink> the main waste is for ToD coloring, I will probably need to fix that if/when I introduce better ToD areas
20100716 23:21:38-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20100716 23:22:35< alink> boucman: ok since :layers seems to work now, I polish a little and commit before checking your flags thing
20100716 23:23:04< boucman> thx, I'm doing thespaceinvader's fix right now, I'll use it tomorow morning if I see in the log you comitted it
20100716 23:30:22< CIA-87> billynux * r44222 /trunk/src/ (6 files in 3 dirs): Improved disconnection in ana, fixed a double free bug and improved the timeout implementation in ana's sender.
20100716 23:31:05-!- billynux [~billy@wesnoth/developer/billynux] has quit [Quit: Leaving]
20100716 23:32:33< thespaceinvader> thanks boucman
20100716 23:32:37-!- thespaceinvader [~chatzilla@wesnoth/artist/thespaceinvader] has quit [Quit: night all]
20100716 23:32:57-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20100716 23:34:10-!- Blueblaze [~Blueblaze@adsl-76-202-21-28.dsl.hstntx.sbcglobal.net] has quit [Quit: Blueblaze]
20100716 23:37:29< CIA-87> alink * r44223 /trunk/src/ (image.cpp image.hpp): 
20100716 23:37:29< CIA-87> Introduce a new image modification "~LOC(x,y,cx,cy)
20100716 23:37:29< CIA-87> allowing to create image as they are used by terrain system
20100716 23:37:29< CIA-87> Name and syntax are WiP.
20100716 23:37:34< CIA-87> alink * r44224 /trunk/src/ (5 files): 
20100716 23:37:34< CIA-87> New debug command ":layers" displaying layer info from the hex under the mouse.
20100716 23:37:34< CIA-87> Commit to start to study terrain layers, but code and UI details are dirty WiP
20100716 23:37:45< alink> boucman: done ^
20100716 23:37:57< boucman> thx... what is that new modifier exactly ?
20100716 23:37:57< alink> not much tested, but it's funny to use
20100716 23:38:26< boucman> it's game only at this point, no editor ?
20100716 23:38:55< alink> game only :-( for now, because editor has no console 
20100716 23:39:34< alink> usual tip:  use ":cutstom layers" to bind the custom command hotkey to :layers
20100716 23:40:01< boucman> k, thx
20100716 23:40:11< boucman> usual tim: don't forget to document in the wiki ;)
20100716 23:40:12< alink> ~LOC was needed because GUI1 use string for image, but terrain put location info in image::locator, so I needed a way to expose that info in a string
20100716 23:40:24< boucman> ok
20100716 23:42:06< alink> Disclaimer: code is not in a state that I consider clean enough to commit, I will fix that soon
20100716 23:42:11< CIA-87> espreon * r44225 /trunk/data/core/images/portraits/monsters/ (giant-mudcrawler.png transparent/giant-mudcrawler.png): Ran umcpropfix.
20100716 23:42:15-!- yann [~dwitch@nan92-1-81-57-214-146.fbx.proxad.net] has quit [Remote host closed the connection]
20100716 23:45:21< shadowmaster> Xan visiting the forums.
20100716 23:45:24< shadowmaster> Interesting.
20100716 23:46:28< shadowmaster> and Zebulon.
20100716 23:47:07< alink> btw, about :layers, order should be right, but it doesn't split into foreground/background yet
20100716 23:52:11< shadowmaster> also changing ACP settings without my approval :p
20100716 23:53:20-!- Johannes13__ [~Johannes@pD9502D1A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20100716 23:55:10< shadowmaster> I wonder what prompted their bisit.
20100716 23:55:13< shadowmaster> *visit
20100716 23:56:09< Gambit> shadowmaster: who?
20100716 23:56:24< shadowmaster> Zebulon and Xan
20100716 23:56:33-!- Johannes13_ [~Johannes@unaffiliated/johannes13] has quit [Ping timeout: 240 seconds]
20100716 23:56:37< shadowmaster> they've been awayfor years
20100716 23:56:48< shadowmaster> *'d been away for
--- Log closed Sat Jul 17 00:00:14 2010