--- Log opened Sun Jun 27 00:00:31 2010
20100627 00:09:06< crimson_penguin> loonycyborg: I wonder if you would package official releases of Frogatto for Windows? I'm building it currently, but I have no experience with installers and stuff, and that would probably be good for a real release
20100627 00:09:34< crimson_penguin> I don't think we have any dependencies that Wesnoth doesn't have... err... other than OpenGL, GLEW, and GLU
20100627 00:10:58< shadowmaster> libpng
20100627 00:11:19< shadowmaster> ah well, the Wesnoth binary also has to include it for SDL
20100627 00:12:56< loonycyborg> crimson_penguin: Sure. I can look into it. Does it already have windows releases?
20100627 00:14:52< loonycyborg> That is does 'I'm building it currently' mean that you're doing them? :P
20100627 00:15:42< crimson_penguin> loonycyborg: Yeah
20100627 00:16:19< crimson_penguin> loonycyborg: I make Windows and Mac "releases", but they're just random svn revisions - we haven't made a proper release yet (but we plan on it soon!)
20100627 00:20:38-!- Elvish_Pillager [~eli@71-10-224-192.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20100627 00:21:24-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20100627 00:32:37-!- ancestral [~ancestral@mobile-166-137-140-008.mycingular.net] has joined #wesnoth-dev
20100627 00:35:53-!- ancestral_ [~ancestral@mobile-166-137-141-178.mycingular.net] has joined #wesnoth-dev
20100627 00:39:13-!- ancestral [~ancestral@mobile-166-137-140-008.mycingular.net] has quit [Ping timeout: 258 seconds]
20100627 00:39:14-!- ancestral_ is now known as ancestral
20100627 00:43:38-!- zookeeper [~l@wesnoth/developer/zookeeper] has quit []
20100627 00:45:53-!- Johannes13 [~Johannes@unaffiliated/johannes13] has quit [Ping timeout: 260 seconds]
20100627 00:46:46-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20100627 00:53:07-!- Gallaecio [~Gallaecio@232.158.60.213.dynamic.mundo-r.com] has quit [Remote host closed the connection]
20100627 00:56:32-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100627 01:00:48-!- Gallaecio [~Gallaecio@232.158.60.213.dynamic.mundo-r.com] has joined #wesnoth-dev
20100627 01:03:24-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20100627 01:05:14-!- ancestral [~ancestral@mobile-166-137-141-178.mycingular.net] has quit [Quit: Colloquy for iPhone - http://colloquy.mobi]
20100627 01:08:10-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has quit [Quit: I ATE'NT DEAD]
20100627 01:08:54-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20100627 01:08:59-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection]
20100627 01:11:34-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20100627 01:13:49-!- e_s-iOS [~esios@pool-108-2-88-55.phlapa.east.verizon.net] has joined #wesnoth-dev
20100627 01:17:43-!- Gallaecio [~Gallaecio@232.158.60.213.dynamic.mundo-r.com] has quit [Remote host closed the connection]
20100627 01:22:32-!- e_s-iOS is now known as brahmsboy
20100627 01:25:29-!- brahmsboy is now known as e_s-iOS
20100627 01:27:21-!- Bocom_ [~Bocom@36.247.95.91.static.ter-ks.siw.siwnet.net] has joined #wesnoth-dev
20100627 01:27:29-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has quit [Quit: Leaving]
20100627 01:28:51-!- Bocom [~Bocom@36.247.95.91.static.ter-ks.siw.siwnet.net] has quit [Ping timeout: 260 seconds]
20100627 01:36:47-!- wajimba [~Andrew_Ah@64.202.242.252] has joined #wesnoth-dev
20100627 01:51:50-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-dev
20100627 01:52:16-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20100627 01:57:47-!- meric [~Eric@124-170-218-153.dyn.iinet.net.au] has quit [Quit: meric]
20100627 02:10:30-!- e_s-iOS [~esios@pool-108-2-88-55.phlapa.east.verizon.net] has quit [Read error: No route to host]
20100627 02:11:01-!- e_s-iOS [~esios@pool-108-2-88-55.phlapa.east.verizon.net] has joined #wesnoth-dev
20100627 02:12:35-!- e_s-iOS [~esios@pool-108-2-88-55.phlapa.east.verizon.net] has quit [Remote host closed the connection]
20100627 02:22:08-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has quit [Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz]
20100627 02:22:37-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection]
20100627 02:32:33-!- wesbot changed the topic of #wesnoth-dev to: 133 bugs, 280 feature requests, 14 patches | logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100627 02:41:41< CIA-87> eleazar * r43742 /trunk/data/core/images/scenery/ (lighthouse.png trash.png): a couple scenery replacements from Blarumyrran.
20100627 03:15:13-!- wajimba [~Andrew_Ah@64.202.242.252] has quit [Ping timeout: 260 seconds]
20100627 03:18:11-!- wajimba [~Andrew_Ah@64.202.242.252] has joined #wesnoth-dev
20100627 03:40:29-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has quit [Remote host closed the connection]
20100627 03:54:36-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 260 seconds]
20100627 03:56:06-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100627 04:07:42-!- Blueblaze [~nick@99.188.135.67] has quit [Ping timeout: 240 seconds]
20100627 04:23:44-!- knotwork [~markm@142.177.232.37] has quit [Remote host closed the connection]
20100627 04:32:58-!- mode/#wesnoth-dev [+o shadowmaster] by ChanServ
20100627 04:33:12-!- mode/#wesnoth-dev [-o shadowmaster] by shadowmaster
20100627 04:33:12-!- wajimba [~Andrew_Ah@64.202.242.252] has quit [Read error: Connection reset by peer]
20100627 04:37:52-!- knotwork [~markm@142.177.232.37] has joined #wesnoth-dev
20100627 04:45:20-!- Elvish_Pillager [~eli@71-10-224-192.dhcp.oxfr.ma.charter.com] has quit [Quit: Hi! I'm a quit message virus vaccine. If you see a quit message virus, don't replace your quit message with it!]
20100627 04:47:55-!- knotwork [~markm@142.177.232.37] has quit [Remote host closed the connection]
20100627 04:52:28-!- knotwork [~markm@142.177.232.37] has joined #wesnoth-dev
20100627 04:58:34-!- fendrin [~fabi@88-134-103-91-dynip.superkabel.de] has joined #wesnoth-dev
20100627 04:58:34-!- fendrin [~fabi@88-134-103-91-dynip.superkabel.de] has quit [Changing host]
20100627 04:58:34-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100627 05:12:18-!- elvish_sovereign [~Zoltan@pool-108-2-88-55.phlapa.east.verizon.net] has quit [Quit: elvish_sovereign]
20100627 05:22:57-!- elvish_sovereign [~Zoltan@pool-108-2-88-55.phlapa.east.verizon.net] has joined #wesnoth-dev
20100627 05:23:32-!- elvish_sovereign [~Zoltan@pool-108-2-88-55.phlapa.east.verizon.net] has left #wesnoth-dev []
20100627 05:23:43-!- elvish_sovereign [~Zoltan@pool-108-2-88-55.phlapa.east.verizon.net] has joined #wesnoth-dev
20100627 05:23:48-!- elvish_sovereign [~Zoltan@pool-108-2-88-55.phlapa.east.verizon.net] has left #wesnoth-dev []
20100627 05:28:31-!- ancestral [~ancestral@97-116-120-9.mpls.qwest.net] has joined #wesnoth-dev
20100627 05:34:02-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Quit: Though to our health we drank a thousand times, it's time to ramble on.]
20100627 05:50:23-!- Appleman1234 [~Appleman1@CPE-60-226-176-215.qld.bigpond.net.au] has joined #wesnoth-dev
20100627 05:54:57< CIA-87> espreon * r43743 /trunk/utils/java/ (58 files in 27 dirs): Ran umcpropfix.
20100627 05:57:14-!- Blueblaze [~irchon@166.205.14.121] has joined #wesnoth-dev
20100627 05:59:16-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Quit: ...]
20100627 06:07:20-!- Blueblaze [~irchon@166.205.14.121] has quit [Remote host closed the connection]
20100627 06:07:47< CIA-87> eleazar * r43744 /trunk/ (changelog data/core/images/items/anvil.png): adding in Eternal's long neglected anvil item.
20100627 06:08:14-!- Blueblaze [~irchon@166.205.14.121] has joined #wesnoth-dev
20100627 06:13:47< CIA-87> espreon * r43745 /trunk/ (changelog players_changelog): Fixed a typo in the changelogs.
20100627 06:18:32< CIA-87> espreon * r43746 /trunk/data/core/images/items/anvil.png: 
20100627 06:18:32< CIA-87> Ran wesnoth-optipng:
20100627 06:18:32< CIA-87> Overall statistics (only for files with a smaller recompressed size):
20100627 06:18:32< CIA-87> Original size: 3 KiB on 1 files
20100627 06:18:32< CIA-87> Optimized size: 0 KiB
20100627 06:18:33< CIA-87> Total saving: 2 KiB = 73% decrease
20100627 06:19:50-!- Blueblaze [~irchon@166.205.14.121] has quit [Quit: Blueblaze]
20100627 06:21:46< CIA-87> espreon * r43747 /trunk/changelog: Fixed a couple of typos in the changelog.
20100627 06:28:00< shadowmaster> Wesnoth is getting anvilicious now? o O
20100627 06:28:29< ABCD> what anvil are you trying to drop? :D
20100627 06:29:16< shadowmaster> that Undead are evil
20100627 06:29:27< shadowmaster> and that Elves rock
20100627 06:29:29< shadowmaster> (not)
20100627 06:31:26-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20100627 06:31:39-!- Blueblaze [~irchon@166.205.14.121] has joined #wesnoth-dev
20100627 06:31:44-!- Aethaeryn is now known as `\
20100627 06:32:34-!- Blueblaze [~irchon@166.205.14.121] has quit [Client Quit]
20100627 06:33:56-!- `\ is now known as Aethaeryn
20100627 06:35:44-!- Blueblaze [~irchon@166.205.14.121] has joined #wesnoth-dev
20100627 06:36:54-!- Aethaeryn is now known as `\
20100627 06:40:46-!- Blueblaze [~irchon@166.205.14.121] has quit [Quit: Blueblaze]
20100627 06:42:59-!- Blueblaze [~irchon@166.205.14.121] has joined #wesnoth-dev
20100627 06:43:56-!- Blueblaze [~irchon@166.205.14.121] has quit [Client Quit]
20100627 06:45:35-!- `\ is now known as Aethaeryn
20100627 07:01:24-!- Valkier [~IceChat7@c-174-55-104-2.hsd1.pa.comcast.net] has quit [Quit: Take my advice. I don't use it anyway]
20100627 07:01:40-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Quit: <Insert witty phrase here.>]
20100627 07:02:05-!- MikeJB [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20100627 07:02:25-!- MikeJB is now known as Aethaeryn
20100627 07:22:06-!- ettin [~jorda@wesnoth/developer/ettin] has quit [Ping timeout: 258 seconds]
20100627 07:23:08-!- ettin [~jorda@wesnoth/developer/ettin] has joined #wesnoth-dev
20100627 07:39:00-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Ping timeout: 265 seconds]
20100627 08:05:32-!- crimson_penguin [~ben@64.201.60.211] has joined #wesnoth-dev
20100627 08:05:32-!- crimson_penguin [~ben@64.201.60.211] has quit [Changing host]
20100627 08:05:33-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20100627 08:15:01-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100627 08:16:03-!- dtiger [~dtiger@dynamic-vpdn-93-125-67-78.telecom.by] has joined #wesnoth-dev
20100627 08:22:15-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Quit: ...]
20100627 08:27:39-!- rigved [~rigved@116.72.163.243] has joined #wesnoth-dev
20100627 08:29:31 * rigved  «®©®» Seen Crab_ «®©®» 
20100627 08:29:47< shadowm_laptop> rigved: uh?
20100627 08:29:50< boucman> wesbot: seen Crab_
20100627 08:29:51< wesbot> boucman: The person with the nick Crab_ 2d 10h ago they left with the message: Quit: Leaving.
20100627 08:29:55< boucman> there you go
20100627 08:30:51< rigved> boucman: thanks
20100627 08:37:37-!- rigved [~rigved@116.72.163.243] has quit [Ping timeout: 258 seconds]
20100627 08:41:57-!- silene [~plouf@bau91-1-82-239-244-109.fbx.proxad.net] has joined #wesnoth-dev
20100627 08:47:50-!- ancestral [~ancestral@97-116-120-9.mpls.qwest.net] has quit [Quit: And that’s the end of THAT chapter.]
20100627 09:16:44-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Quit: crimson_penguin]
20100627 09:20:24-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has joined #wesnoth-dev
20100627 09:20:24-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has quit [Changing host]
20100627 09:20:24-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100627 09:52:47-!- Blarumyrran [~Blarumyrr@unaffiliated/blarumyrran] has joined #wesnoth-dev
20100627 10:01:34< silene> i profiled wesnoth startup, 60% of the time is spent inside tokenizer::skip_comment (guess who was the last to massively modify it?)
20100627 10:01:56< silene> still that doesn't explain why 1.8 is not impacted; did someone make a mess with mainline wml?
20100627 10:03:50< shadowmaster> I don't think so. The main larger chan ges have been in the terrain graphics macros and in introducing typography changes to translatable strings (courtesy of Espreon)
20100627 10:03:53< shadowmaster> changes
20100627 10:05:38< boucman> terrain graphoc macros do use macros much more than the used to...
20100627 10:07:36< shadowmaster> I iwish I had saved the command line I once used to count macro inclusions using wesnoth's console output
20100627 10:08:12< shadowmaster> s/iwish/wish/; s/inclusions/expansions/;
20100627 10:19:09-!- meric [~Eric@124-170-218-153.dyn.iinet.net.au] has joined #wesnoth-dev
20100627 10:19:35-!- meric [~Eric@124-170-218-153.dyn.iinet.net.au] has quit [Client Quit]
20100627 10:34:35-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds]
20100627 10:41:26-!- zookeeper [~l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20100627 10:42:31-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has joined #wesnoth-dev
20100627 10:42:31-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has quit [Changing host]
20100627 10:42:31-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100627 10:42:37-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20100627 10:42:51-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100627 10:47:45< silene> boucman: it seems you are indeed the one responsible for the massive startup slowdown some people have experienced on trunk
20100627 10:48:05< boucman> oh :(
20100627 10:48:24< Espreon> What is to be done?
20100627 10:48:38< boucman> it should only be at cache building, though...
20100627 10:48:50< boucman> and apparently zookeeper experience it at every start
20100627 10:49:27< zookeeper> yeah, i do. i'm not sure if it's longer when there's an actual need for cache rebuilding or not.
20100627 10:49:36< zookeeper> but in any case, it's a lot slower in both cases
20100627 10:49:42-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds]
20100627 10:49:43< silene> boucman: zookeeper modifies wml, so cache building may well happen at every start
20100627 10:49:59< boucman> good point
20100627 10:51:04-!- Blueblaze [~nick@adsl-99-188-135-67.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100627 10:51:06< boucman> not sure what's to be done... without macros to clarify the code, terrain would be unmanageable... I might be able to reduce their number a little by not expanding some stuff that shouldn't be changed in the common cases (less ganeric)
20100627 10:51:28< boucman> but if I drop the whole organization it's going to be a huge work to rework
20100627 10:53:09< Ivanovic> boucman: what about trying to seperate the caching files a little?
20100627 10:53:16< Ivanovic> to have a separate cache for terrains
20100627 10:53:18< boucman> ??
20100627 10:53:22< boucman> hmm
20100627 10:53:26< Ivanovic> like we currently have separate chaches for campaigns
20100627 10:53:37< boucman> that would be nice, but that's absolutely not my area... :P
20100627 10:53:44< zookeeper> so, wait...it's all caused by terrain graphics macros?
20100627 10:53:48< Ivanovic> maybe silene can help with it?
20100627 10:56:13< silene> i can, but not before two weeks; entrance exams are about to begin, so i will be overwhelmed for the next two weeks; in fact, i have a phone meeting with the other examinators in a few minutes, so i shouldn't even be there talking on irc...
20100627 10:57:15< Ivanovic> ugh
20100627 10:57:20< Ivanovic> okay, silene, good luck
20100627 10:58:10< silene> Ivanovic: i don't need luck, i just need more than 24 hours a day; it's the candidates who will need luck :-)
20100627 10:58:26< zookeeper> boucman, so _how_ much more complicated is the macro usage now? i can't understand how anything short of infinite recursion would cause such a massive slowdown
20100627 10:58:31< Ivanovic> silene: i thought with enough luck you can make days last for some 48 hours
20100627 10:58:41< Ivanovic> at least 32h should easily possible
20100627 10:58:58< Ivanovic> the day has 24h, add the night (roughly 8h) and you are done
20100627 10:59:00< Ivanovic> ;)
20100627 10:59:57< zookeeper> boucman, so could you point me to some example macro call in terrain-graphics.cfg which leads to horribly many other macro calls?
20100627 11:00:02< boucman> zookeeper: the "complete" variation which handle "everything" through a simple call will expend to a macro which call 5 macros (3..0 sided variation)
20100627 11:00:14< boucman> which each expand to 10 variations (random tiles)
20100627 11:00:18< boucman> of the top of my head
20100627 11:00:46< boucman> loot at data/core/terrain-graphics/base and see how it expands
20100627 11:00:57< boucman> look
20100627 11:01:23 * zookeeper loots it
20100627 11:02:08-!- Blueblaze [~nick@adsl-99-188-135-67.dsl.hstntx.sbcglobal.net] has quit [Ping timeout: 258 seconds]
20100627 11:04:53< zookeeper> boucman, i shouldn't have asked. it's such a huge web of macros that i can't really wrap my mind around it -.-
20100627 11:05:05< zookeeper> especially that BUILDER system is so...urgh...
20100627 11:06:29< zookeeper> i mean, let's say i want to check out how TERRAIN_BASE works
20100627 11:06:41< zookeeper> it first leads me to internal-generic.cfg
20100627 11:06:50< zookeeper> then that takes me to builder.cfg
20100627 11:07:17< zookeeper> then i have to backtrack to base.cfg since that's where the IMAGE_SINGLE comes from
20100627 11:07:39< zookeeper> then that takes me back to builder.cfg where IMAGE_SINGLE is defined
20100627 11:08:35< boucman> zookeeper: well, it's a layered system, the whole point of layered system is that you don't have to think at more than one level at a time
20100627 11:08:54< zookeeper> yeah, but that only works if you _know_ which parts you don't have to think about
20100627 11:08:57< boucman> so just ignore the builder system for the moment, that part is not usefull to understand for the moment
20100627 11:09:05< zookeeper> i don't know which parts i can ignore and which i have to understand
20100627 11:09:34< boucman> zookeeper: well, it's made in such a way that users don't have to look into the internal-* but you're not a normal user here :P
20100627 11:10:14< boucman> start by looking at internal-generic
20100627 11:10:47< zookeeper> ok, well, i still don't see anything horribly macro-heavy
20100627 11:11:05< boucman> that one is the "low level" it only defines the _PLFB macros for 1..3 neighbours
20100627 11:11:24< boucman> move on to internal-complex
20100627 11:11:46< boucman> this one use the generic to implement random variations
20100627 11:12:11< boucman> "complete" at the bottom buts everything together
20100627 11:12:32< zookeeper> ok...
20100627 11:13:38< zookeeper> oh, i see
20100627 11:13:56-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit []
20100627 11:14:20< boucman> but the things is that there is a certain number of these macros that are used both internally and externally, which makes things a bit confusing
20100627 11:14:38< zookeeper> well, first of all, does anything use 11 variations?
20100627 11:15:12< zookeeper> i can see 8 variations in sand and desert
20100627 11:15:29< zookeeper> right, desert plants use 11
20100627 11:16:10< zookeeper> well, i don't think you'll be surprised when i say that such a variation system should rather be supported by [terrain_graphics] directly, instead of requiring such a complicated macro system
20100627 11:17:40< boucman> zookeeper: if we do that we move calculation time out of loading time into the main game execution time... and we hardcode the game
20100627 11:17:55< boucman> (granted it's probably less costly at game execution, but still...)
20100627 11:18:46< zookeeper> we wouldn't be hardcoding, people could still use the current system if they needed to
20100627 11:19:01< boucman> then I don't understand what you mean
20100627 11:20:27< zookeeper> i don't know how it'd work exactly, but i mean something with which i could just give a [terrain_graphics] the list of variations and then the engine would simply pick from those randomly
20100627 11:21:50< boucman> zookeeper: hmm, 
20100627 11:22:10< boucman> ok, I need to leave, but something needs to be done, we'll give it more thought later
20100627 11:22:15< zookeeper> ok, great
20100627 11:25:25-!- Elvish_Pillager [~eli@71-10-224-192.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20100627 11:25:58-!- Johannes13 [~Johannes@unaffiliated/johannes13] has joined #wesnoth-dev
20100627 11:26:13< zookeeper> something like that would cut down the amount of variation-related WML hugely. frankly i think it could be as simple as this: if you have "name=hills/dry" and use_random_variations=yes then the game automatically goes and looks for hills/dry2.png, hills/dry3.png etc, and distributes all found tiles randomly.
20100627 11:29:16-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has joined #wesnoth-dev
20100627 11:29:16-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has quit [Changing host]
20100627 11:29:17-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100627 11:47:21-!- loonybot [~loonybot@ppp79-139-137-245.pppoe.spdop.ru] has joined #wesnoth-dev
20100627 11:47:21-!- loonybot [~loonybot@ppp79-139-137-245.pppoe.spdop.ru] has quit [Changing host]
20100627 11:47:22-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-dev
20100627 11:48:14-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20100627 11:55:16< CIA-87> ivanovic * r43748 /trunk/po/ (4 files in 4 dirs): updated Vietnamese translation
20100627 11:55:18< CIA-87> ivanovic * r43749 /branches/1.8/po/ (4 files in 4 dirs): updated Vietnamese translation
20100627 12:08:02-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100627 12:38:51-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20100627 12:39:07-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100627 12:54:02-!- Upth [ogmar@adsl-75-26-178-38.dsl.scrm01.sbcglobal.net] has quit [Ping timeout: 240 seconds]
20100627 12:58:12-!- Upth [~ogmar@adsl-75-26-178-38.dsl.scrm01.sbcglobal.net] has joined #wesnoth-dev
20100627 13:02:49-!- dtiger [~dtiger@dynamic-vpdn-93-125-67-78.telecom.by] has quit [Remote host closed the connection]
20100627 13:05:35-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20100627 13:11:35< Elvish_Pillager> Hmm, hang on. CAN add-ons pollute each other's macro namespaces?
20100627 13:16:03< zookeeper> of course they can
20100627 13:16:13< zookeeper> unless i've missed something big
20100627 13:16:44< Elvish_Pillager> well, as far as I remember, I can't refer to macros that I've carelessly defined (and included) in a different add-on....
20100627 13:18:04< Elvish_Pillager> e.g. right now I have a macro SCOPED_VAR defined in eps_generalized_macros and I say {SCOPED_VAR foo} in EoHS and Wesnoth tells me that it doesn't know what {SCOPED_VAR} is.
20100627 13:21:44< zookeeper> maybe the latter is simply preprocessed before the former
20100627 13:22:10< Elvish_Pillager> :(
20100627 13:22:38< zookeeper> that's why you should never try to use macros from another add-on without actually including their macro defs yourself
20100627 13:23:00< Elvish_Pillager> shouldn't you never try to use macros from another add-on at all?
20100627 13:26:32< zookeeper> that's right generally, but i guess there could be some rare special cases
20100627 13:26:58< zookeeper> like checking if another add-on is installed and then doing something differently
20100627 13:27:55< Elvish_Pillager> wouldn't it be better to check that with #ifhave?
20100627 13:28:10< Elvish_Pillager> if you're working with the dev version anyway :/
20100627 13:28:52< zookeeper> if
20100627 13:29:05 * zookeeper is afk
20100627 13:35:45< stikonas> #kubuntu-dev
20100627 13:35:48< stikonas> sorry
20100627 13:36:25< Elvish_Pillager> Does {VARIABLE_OP foo to_variable an_array} work, or do you have to use [set_variables] to copy an array?
20100627 13:42:27-!- Blitzmerker [~Blitzmerk@p3EE0A2EE.dip0.t-ipconnect.de] has joined #wesnoth-dev
20100627 13:42:59< Elvish_Pillager> ...wonderful. to_variable in [set_variable] doesn't work with arrays and to_variable in [set_variables] doesn't work with strings/
20100627 13:43:19< Elvish_Pillager> And unless I'm mistaken, there's not even any simple way to detect whether a variable is an array or a string.
20100627 13:51:05< silene> Elvish_Pillager: there is a simple way, but it is one line of lua
20100627 13:52:04< Espreon> ... and the solution is almost always resorting to witchcraft.
20100627 13:52:21< silene> wesnoth.set_variable("var_is_an_array", type(wesnoth.get_variable("my.variable.name")) == "table")
20100627 13:54:17< Elvish_Pillager> silene: and does it work to simply put that in a [lua] tag as in the first example on http://wiki.wesnoth.org/LuaWML ?
20100627 13:54:41< silene> Elvish_Pillager: yes
20100627 13:54:46< Elvish_Pillager> okay, cool
20100627 13:56:28< silene> Elvish_Pillager: note that the variable names (both the input and the destination) have to be simple; for instance, unit.attacks[0].damage is simple, unit.attacks[$i].damage is not
20100627 13:57:53< Elvish_Pillager> would I not be able to avoid that by not enclosing the value of code= in strong quote (so WML would expand the $ before calling the lua script)?
20100627 13:58:44< Elvish_Pillager> ...oh, the quotes
20100627 13:58:52< silene> yes, it would work, but i would suggest defining a wml tag instead if you need it
20100627 14:03:25-!- stikonas_ [~and@ctv-79-132-162-160.vinita.lt] has joined #wesnoth-dev
20100627 14:03:25-!- stikonas_ [~and@ctv-79-132-162-160.vinita.lt] has quit [Changing host]
20100627 14:03:25-!- stikonas_ [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100627 14:03:37-!- mjs-de [~mjs-de@p3EE2375E.dip.t-dialin.net] has joined #wesnoth-dev
20100627 14:05:21-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 252 seconds]
20100627 14:05:51< silene> Elvish_Pillager: something like http://wesnoth.pastebin.com/vmCW8Tsa put in a preload event; then you get a new tag [is_array] with two attributes "name" and "result"
20100627 14:06:02-!- Appleman1234 [~Appleman1@CPE-60-226-176-215.qld.bigpond.net.au] has quit [Ping timeout: 240 seconds]
20100627 14:06:07-!- stikonas_ is now known as stikonas
20100627 14:07:08< Elvish_Pillager> silene: I have found a simpler way to copy a variable: use both [set_variable] and [set_variables].
20100627 14:08:47< silene> Elvish_Pillager: be careful, i wouldn't be surprised if one were to overwrite the other, depending on the order
20100627 14:08:57< Elvish_Pillager> I have tested it; it works in all orders
20100627 14:10:17< silene> that's good then; because the code creates both a string variable and an array variable if you use both [set_variable] and [set_variables]
20100627 14:11:35< Elvish_Pillager> hmm. That's interesting, it really does.
20100627 14:11:55< Elvish_Pillager> Well, sort of...
20100627 14:12:31< Elvish_Pillager> If you use this mechanism to copy an array, you also get an empty string variable by the same name, which will be functionally equivalent to the variable not existing...
20100627 14:12:45< Elvish_Pillager> but if you use it to copy a string, you don't get an array variable.
20100627 14:13:02< Elvish_Pillager> (because arrays of length zero never exist as a WML variable)
20100627 14:13:11< silene> right
20100627 14:13:46< Elvish_Pillager> so I'm fine - the worst-case scenario is that I end up with a bunch of empty junk variables.
20100627 14:14:21-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 265 seconds]
20100627 14:19:04-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has quit [Quit: I ATE'NT DEAD]
20100627 14:19:25-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection]
20100627 14:20:54< Upth> Hey, I noticed that one of my saved games was loading really really slowly, and tracked the cause down to the image::cache_type::contents_ vector being resized lots and lots
20100627 14:21:39< Upth> I experimented with changing it from a std::vector<...> to a std::map<int,...> and load time was reduced by several minutes
20100627 14:22:20< Upth> should I commit this change, or is there a good reason for the contents_ of image::cache_type to be stored in a map?
20100627 14:25:23< boucman> Upth: keep the modif a couple of days, play a little, and if everything is safe, commit I guess...
20100627 14:27:33< Upth> ok.
20100627 14:29:25< silene> Upth: if you have lots of resize, you should report that as a bug to your standard library provider; vector resizing is supposed to be O(1) amortized; if it isn't for you, it's a really bad bug
20100627 14:33:03-!- alink [~alink@wesnoth/developer/alink] has joined #wesnoth-dev
20100627 14:33:30< Upth> silene: http://wesnoth.pastebin.com/q07WLHrV << this code is being called repeatedly with index > 40000
20100627 14:33:40< Upth> and then again with a larger one, and then again with a larger one
20100627 14:34:25< alink> while(static_cast<size_t>(index) >= content_.size()) { content_.push_back(cache_item<T>()); } looks inefficent
20100627 14:34:40< alink> should use resize
20100627 14:35:17< silene> alink: unless the standard library is broken, there shouldn't be much performance difference (though i agree that resize would be more readable)
20100627 14:35:18< Upth> at first I changed it to if(static_cast<size_t>(index) >= content_.size() { content_.resize(index+1,cache_item<T>()); }
20100627 14:35:27< Upth> but it did not make much difference
20100627 14:36:03< alink> silene: I assumed that STL could allow memory more efficiently by knowing how mush is needed
20100627 14:36:33< Upth> however if I change content_ to std::map<int,cache_item<T>>, and that function to http://wesnoth.pastebin.com/BdE9Vmqb
20100627 14:36:45< alink> s/mush/much
20100627 14:36:48< Upth> there is a large performance difference
20100627 14:38:24< Upth> the lowest index I've seen used is > 42000, so it should save a reasonable amount of memory as well
20100627 14:38:53< alink> and by using reserve(40000) ?
20100627 14:38:59< silene> Upth: then you should rather track why the lowest index is 42000
20100627 14:39:15< Upth> silene: I tried but could not figure out where the index value is coming from.
20100627 14:39:39< Upth> at the very least, the cache indices do not seem to be being used linearly
20100627 14:42:45< silene> they are, see image.cpp:118
20100627 14:42:59< silene> perhaps it's caused by boucman's terrain rewrite; and it would explain the slowdown experienced by zookeeper
20100627 14:43:15-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has quit [Remote host closed the connection]
20100627 14:44:00< boucman> silene: so far I havn't touched c++, but yes, I have probably pushed the preprocessor to its limits
20100627 14:44:28< silene> boucman: i'm not talking about the preprocessor there; could it be that you are creating lots of images?
20100627 14:44:50< silene> boucman: Upth has 42k images unaccounted for
20100627 14:45:19< boucman> hmm, I do test for the existence of many images that don't exist, I'm not sure if these count
20100627 14:45:32< alink> Upth: if the size of the container is so big, using std::map may have a bigger access cost (O(log(N)) instead of O(1)) when reading this cache
20100627 14:45:33< boucman> I don't load many more "real" images, that's for sure
20100627 14:46:00< Upth> boucman: that may indeed be what is causing it
20100627 14:46:06< boucman> hmm
20100627 14:46:39< Upth> if it is causing image::locator::in_cache() to be called
20100627 14:46:40< boucman> Upth: edit data/core/terrain-graphics/internal-complex, for each *RANDOM* macro only keep the last line
20100627 14:46:42< Upth> bool in_cache(cache_type<T>& cache) const { return index_ == -1 ? false : cache.get_element(index_).loaded; }
20100627 14:46:47< boucman> and tell me if that reduce the size
20100627 14:47:11-!- Bocom_ [~Bocom@36.247.95.91.static.ter-ks.siw.siwnet.net] has quit [Quit: Lämnar]
20100627 14:47:27-!- meric [~Eric@124-170-218-153.dyn.iinet.net.au] has joined #wesnoth-dev
20100627 14:48:06< Upth> oh I think I have found the problem.
20100627 14:49:43< Upth> image::locator::init_index uses image::locator::last_index_ and then increments last_index_ if it can't find its location
20100627 14:50:00< Upth> last_index_ is static, and never gets decremented
20100627 14:50:45< Upth> so if a cache is created, filled with all the terrain images, and then destroyed or disused for any reason, and then another cache is created and filled with all the terrain images...
20100627 14:51:01< silene> caches are not supposed to be destroyed
20100627 14:54:04< alink> boucman: do you use more filename with ".." for terrains ?
20100627 14:54:15< boucman> what do you mean ?
20100627 14:54:28< alink> ".." in file paths
20100627 14:54:40< alink> of image obviously
20100627 14:55:00< boucman> hmm no, I can't think of any case like that in mainline terrain
20100627 14:55:12< alink> boucman: ok
20100627 15:00:08< alink> AI0867 around ?
20100627 15:01:48 * Upth waits for wesnoth to recompile after reverting image::cache_type::content_ to a vector
20100627 15:03:03< Upth> and adding a line to log the index number when get_element happens.
20100627 15:06:34-!- yann [~dwitch@nan92-1-81-57-214-146.fbx.proxad.net] has joined #wesnoth-dev
20100627 15:23:46< Upth> perhaps the source ought to be refactored so that image.hpp doesn't have to be included in so many other files...
20100627 15:26:37-!- Gallaecio [~Gallaecio@232.158.60.213.dynamic.mundo-r.com] has joined #wesnoth-dev
20100627 15:33:54-!- Crab_ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100627 15:40:42< Upth> okay, looks like locators are being created basically in order, but even with only the last line from each *RANDOM* macro in terain-graphics/internal-complex.cfg, it's up to 15000+ and I'm not sure it's done
20100627 15:40:52-!- Kiba [~user@adsl-176-42-69.asm.bellsouth.net] has joined #wesnoth-dev
20100627 15:44:11< boucman> that's a lot, i'm not sure the terrain code is responsible for all that, could you print the file names ?
20100627 15:44:33< Upth> okay, it got up to 15423
20100627 15:44:50< alink> I see one thing that i can improve
20100627 15:45:00< Upth> err, and I just closed it
20100627 15:45:13< Upth> how would I print the file names of all the open images in the cache?
20100627 15:45:30< alink> and the we currently check a lot of filename.png.png for log wml error
20100627 15:45:52< alink> boucman: I will paste something
20100627 15:46:21 * Upth restores internal-complex.cfg and checks how large it gets.
20100627 15:46:27-!- Bocom [~Bocom@c-b7cfe255.013-31-6b736412.cust.bredbandsbolaget.se] has joined #wesnoth-dev
20100627 15:49:18< alink> mmh seems to big for my clipboard
20100627 15:49:39< Upth> paste in parts?
20100627 15:50:10< alink> seems to be only firefox/pastebin clipboard, checking more
20100627 15:50:20< alink> got it
20100627 15:51:14-!- e_s-iOS [~esios@pool-108-2-88-55.phlapa.east.verizon.net] has joined #wesnoth-dev
20100627 15:51:16< alink> 60000 lines
20100627 15:51:33< Espreon> Wow, over nine thousand lines...
20100627 15:51:35 * Upth whistles.
20100627 15:51:59< Upth> (what nine thousand? etc etc)
20100627 15:52:11< Espreon> Upth: What?
20100627 15:52:19< Espreon> Oh.
20100627 15:52:49< Espreon> ... and 60,000 is at least one hundred, so... two memes were invoked today.
20100627 15:53:33< Upth> Ironically the over nine thousand meme is a mistranslation/typo in the dub script and the power level in question was actually only over eight thousand.
20100627 15:53:36< alink> this is very slow
20100627 15:54:43< alink> code http://wesnoth.pastebin.com/VnbHFeee
20100627 15:55:29< alink> result on test-scenario http://wesnoth.pastebin.com/qmE5pJgX  
20100627 15:55:48< Upth> I was about to say "that is a lot less than 60000 lines"
20100627 15:56:04< alink> :)
20100627 15:56:32< alink> btw, seems heavy  on my firefox
20100627 15:56:46< Upth> perhaps I should chrome this
20100627 15:57:23< alink> but i will improve this number by fixing a bug in "image precache file existence" code
20100627 15:57:54< Espreon> Upth: ... everyone knows that.
20100627 15:57:56< alink> and the .png.png thing warning must be changed too
20100627 15:58:15 * Espreon wonders if Upth knew about "at least one hundred" prior to today.
20100627 15:58:17< Crab_> alink: you can always 'just download' the file, without viewing it in the browser.  e.g., http://wesnoth.pastebin.com/download.php?i=qmE5pJgX
20100627 15:58:54< alink> Crab_: well, good to know, but in this case I uploaded it ;)
20100627 15:59:13< Upth> Espreon: looking it up on knowyourmeme now
20100627 15:59:15< alink> which means that pastebin opened the result for me
20100627 15:59:37< Crab_> alink: yes, it's slow 9
20100627 15:59:40 * Espreon thinks that Upth should look it up on the classiest wiki in all of existence.
20100627 15:59:47< Upth> tvtropes?
20100627 16:00:19< Espreon> Uh, no!
20100627 16:02:04< Upth> I cannot think of a classier wiki than tvtropes!
20100627 16:03:03 * Espreon rolls his eyes
20100627 16:03:49< Espreon> Anyway, did you find out moar about "at least one hundred"?
20100627 16:06:26< Espreon> Upth: If you want a hint about its origin: http://www.google.com/search?hl=en&client=firefox-a&hs=H7s&rls=org.gentoo%3Aen%3Aunofficial&q=%22at+least+100%22+site%3Aen.wikipedia.org&aq=f&aqi=&aql=&oq=&gs_rfai=
20100627 16:08:00< boucman> ok, there is a couple of things I see right away in that list...
20100627 16:08:21< boucman> we search for image.png.png in some cases, that's very weird
20100627 16:08:32< boucman> and some images are searched up to three times
20100627 16:08:54< boucman> up to 7 times :P
20100627 16:08:59< alink> boucman: as I mentioned that's just for logging a error about missing png extension, easy to fix
20100627 16:08:59< Upth> I will guess that it originates either from the top listed wikipedia article or the frequency of wikipedia articles listed
20100627 16:09:11< boucman> alink: ok, misssed that
20100627 16:09:18< Espreon> Upth: The frequency.
20100627 16:09:31< Espreon> ... same goes for "some argue".
20100627 16:09:31< Upth> I see that at least one hundred articles are listed
20100627 16:09:35< Espreon> Heh...
20100627 16:09:52< alink> boucman: I am about to improve the "file existence cache", which should helps a lot of "terrain/" images
20100627 16:10:13< Espreon> "Some argue" is such a great fragement; it instantly gives anything a NPoV.
20100627 16:10:28< Upth> indeed.
20100627 16:10:34< alink> boucman: because that code is currently very dumb. I was probably tired when I wrote it
20100627 16:10:39< Espreon> ... but... it's just so hollow that it's pathetic.
20100627 16:10:44< boucman> that's great, I guess the original author thought the feature of not crashing on missing file as a cool feature, but it's now a basis for the macro system
20100627 16:11:21-!- Bob_The_Mighty [~chatzilla@cpc8-brig15-2-0-cust40.know.cable.virginmedia.com] has joined #wesnoth-dev
20100627 16:11:42-!- Bob_The_Mighty [~chatzilla@cpc8-brig15-2-0-cust40.know.cable.virginmedia.com] has quit [Client Quit]
20100627 16:12:41< Espreon> Upth: http://www.google.com/search?hl=en&client=firefox-a&hs=vEt&rls=org.gentoo%3Aen%3Aunofficial&q=%22some+argue%22+site%3Aen.wikipedia.org&btnG=Search&aq=f&aqi=&aql=&oq=&gs_rfai=
20100627 16:13:14< alink> boucman: actually this is a get_binary_file_location optimization, but I should have helped the image cache too
20100627 16:14:49< Upth> some argue has more results than at least one hundred, but some would argue that user and talk pages shouldn't count
20100627 16:15:12< Espreon> Heh...
20100627 16:15:17< Upth> I am not very reflexive today, more's the pity.
20100627 16:15:52 * Espreon thinks that crashing due to a missing file is such an awesome feature (if it is told which file is missing)
20100627 16:16:05< Espreon> *crashing/aborting/whatevering
20100627 16:18:02< boucman> Espreon: huh ? that means we would have to hardwire all the files in the terrain config
20100627 16:18:37< boucman> right now we have a philosophy of "if a two sided transition exists, then use it, else use two one sided transitions" we couldn't do that if we crashed at the first missing files
20100627 16:18:59< Espreon> Well, I mean in cases where it would be practical.
20100627 16:19:03< boucman> and either all terrains would have to have exactly the same number of frames or we wouldn't be able to use any macros at all
20100627 16:19:22< boucman> Espreon: i think it's more or less the case everywhere except terrains
20100627 16:20:28< Upth> so, I did a similar thing to alink's, except it gives the index number and the file name in such a way that it can easily be logged to file without any other log output
20100627 16:21:46< Upth> I'm running it with both versions of terrain-graphics/internal-complex to see what differences occur
20100627 16:21:50-!- e_s-iOS [~esios@pool-108-2-88-55.phlapa.east.verizon.net] has quit [Remote host closed the connection]
20100627 16:23:51< zookeeper> boucman, so what do you think of my fancy idea?
20100627 16:24:17< boucman> what idea ?
20100627 16:24:27< Upth> something bugging me in the log, though
20100627 16:24:31< Upth> "New image 15454 Loaded: 
20100627 16:24:33< alink>  code http://wesnoth.pastebin.com/VnbHFeee I guess
20100627 16:24:44< alink> boucman: ^
20100627 16:24:47< zookeeper> boucman, <zookeeper> something like that would cut down the amount of variation-related WML hugely. frankly i think it could be as simple as this: if you have "name=hills/dry" and use_random_variations=yes then the game automatically goes and looks for hills/dry2.png, hills/dry3.png etc, and distributes all found tiles randomly.
20100627 16:24:49< Upth> note the lack of a file name? All the other images have files
20100627 16:25:02< alink> boucman: ah the fancy idea, sry nevermind 
20100627 16:25:03< Upth> it showed up in alink's as well, but I assumed it was from pasting issues
20100627 16:25:32< zookeeper> i don't care about the specifics, but i do really think the current way of specifying variations is hopelessly too complicated and verbose
20100627 16:25:56< boucman> zookeeper: it's totally hidden to the user, so it's not verbose at all
20100627 16:26:22< Espreon> ... in their eyes...
20100627 16:26:30< boucman> and any change in the [terrain_graphics] have to be moved up the macro stack as a new parameters...
20100627 16:26:46< zookeeper> boucman, well the users aren't the players but the poor developers who try to wire in new terrains :p
20100627 16:26:57< boucman> not counting that some macros (like bridges) can place a dozen images... some of which have variations but not all
20100627 16:27:06< boucman> yes, that's what I meant
20100627 16:27:11< zookeeper> (and make it work efficiently, which clearly isn't simple considering the performance issue we have right now...)
20100627 16:27:36< boucman> if you look at terrain-graphics.cfg which is the only file someone trying to add terrain should look at, it's fairly straightforward
20100627 16:28:55< alink> zookeeper: IIUC that looks indeed more efficient. The current probability code try all rules and drop mos of them when "rand()  < prob" (in pseudo code), so it's a lot of wasted work
20100627 16:29:05< alink> s/mos/most
20100627 16:29:39< alink> zookeeper: btw, you also need a syntax to get different probability distribution
20100627 16:29:48< boucman> alink: fyi, we don't use rand() we do a randomization based on loc.x loc.y to make sure we always have the same result, but it's the same idea
20100627 16:29:54< alink> like make dry3.png more rare
20100627 16:30:09< boucman> alink: that's not the problem
20100627 16:30:16< alink> boucman: I know I coded the noise function :-)
20100627 16:30:21< boucman> hehe
20100627 16:31:40< zookeeper> alink, maybe. although those cases should be rare enough that you could use the current method for them. of course such a syntax would be nice to have, but IMO not having that wouldn't be a catastrophy.
20100627 16:31:42< boucman> alink: that's not the real problem with zookeeper's idea (sorry zookeeper) the problem is that macros hide the complexity of terrain layout, and by using zoo's solution we have to pass for every [terrain_graphics] block (after expansion) wether or not it has random tiles... and a macro can expand to dozen such blocks
20100627 16:32:11< boucman> which means that we have to have as many parameters to specify what block we should target.... the readability would be horrible
20100627 16:32:34< zookeeper> boucman, well, my idea would also involve re-working the current terrain base and transition macros
20100627 16:33:24< zookeeper> "as many parameters to specify what block we should target" <- not sure what you mean
20100627 16:33:28< alink> boucman: I know nothing about the macro stuff, but he mentioned a new key use_random_variations=yes, could we use that to simplify macros ?
20100627 16:33:39< zookeeper> or rather, i think i know what you mean, but that's not how i intended it to work :)
20100627 16:33:45< boucman> zookeeper: what I meant is that your system is incompatible with macros... since each terrain has a variable number of tiles, each transition has a variable number of tiles, basically writers would have to use one macro per generated [terrain_graphics] which would be a horrible mess
20100627 16:34:22< boucman> alink, zookeeper: ok, so you don't understand what i'm saying :P i'l try to be more clear
20100627 16:34:47< zookeeper> i'm guessing you don't understand what i'm saying, but since i don't understand what you're saying either, i'm not completely sure ;)
20100627 16:35:03< boucman> zookeeper: I think I do (but that's subject to caution)
20100627 16:35:40< boucman> suppose you use the TRANSITION_COMPLETE macro... which is the basis of 90% of transitions in terrain graphics
20100627 16:39:14< Espreon> Goodbyez.
20100627 16:39:17 * Espreon disappears
20100627 16:39:22< zookeeper> oh my, that's horribly complicated
20100627 16:40:06< boucman> it's semantic is TRANSITION_COMPLETE <terrain> <adjacent> this will add transitions between terrain and adjacent, it will look if it's possible to add a six sided transition, then 5 sided... and so on down to one for a total  6 blocks... (assuming we don't have random, so we are in zookeeper's case)
20100627 16:40:13< zookeeper> for each transition having variations, BORDER_COMPLETE_LFB is used, and that expands to...a lot
20100627 16:40:34-!- Valkier [~IceChat7@c-174-55-104-2.hsd1.pa.comcast.net] has joined #wesnoth-dev
20100627 16:40:45< boucman> well, the one sided transition might have random variations, but not the 2 sided one, or some one sided transitions, but not all...
20100627 16:41:11< boucman> since we can't just set "has random variations" everywhere, we need to set it only at the right place
20100627 16:41:29< zookeeper> hmmh
20100627 16:41:30< Upth> okay so final analysis with my particular savegame
20100627 16:41:49< boucman> which means that we need to pass 6 extra parametes, for 1..6 sided transitions, not even looking at directional constraints
20100627 16:42:06< Upth> simplified *RANDOM* macros -> 15472 images cached, normal *RANDOM* macros -> 42588 images cached
20100627 16:42:46< zookeeper> boucman, ok, i think i have a very vague idea of what you mean, but it's still hard to visualize since frankly i still can't understand how the whole thing works
20100627 16:42:57< boucman> and I don't see how reworking macros might avoid that problem... we need to move the info "where are the duplicates" from the terrain-graphics.cfg level down to each [terrain_graphics] block individually
20100627 16:43:22< boucman> zookeeper: :P it's not that complicated, but you need to wrap your head around it...
20100627 16:44:21< alink> Upth: fixing the .png.png thing also halves this number
20100627 16:44:23< zookeeper> now, i know i'm not particularly good at wrapping my head around this kind of stuff, but i do think it'd be very nice if someone of my understanding could actually figure it out :P
20100627 16:44:48< alink> Upth: I am about to test my new precache code to improve this more
20100627 16:45:05< zookeeper> the web of macros just seems to get more and more complicated all the time (i'm not sure if that's really the case)
20100627 16:46:17< zookeeper> however, i'll go wrap my head around making some dinner for a moment...
20100627 16:46:22< boucman> zookeeper: it is the case... my idea was that terrain makers wouldn't need to understand the macros, I could teach you how it works if you want, but the assumption was that terrain makers would have everything they have to know in http://wiki.wesnoth.org/TerrainMacrosWML
20100627 16:46:46< Upth> posting logs of loaded images for in case it might be helpful somehow: http://dl.dropbox.com/u/75343/log_simplified.txt http://dl.dropbox.com/u/75343/log_normal.txt
20100627 16:47:23< alink> Upth: btw when you said "images cached", I assume you mean just the index thing, not real SDL images ?
20100627 16:48:28< Upth> that's with an out in the index_ = last_index_++; block
20100627 16:48:28< alink> ok it's not real images
20100627 16:48:58< Upth> yeah it can't be real images because it includes a null string filename
20100627 16:50:18< alink> yeah that's locator::value stuff, which are not tiny either
20100627 16:51:39< alink> ok, my new code seems to divide these numbers by 3
20100627 16:52:16< Upth> so the 42588 -> 14196?
20100627 16:52:17< alink> so with the previous .png.png fix, that go from ~60000 to ~13000
20100627 16:52:54< alink> all approximate numbers
20100627 16:53:13< Upth> now that I have a little more information about what is going on here
20100627 16:53:35< alink> Upth: and with macro changes that could be improved more
20100627 16:53:46< Upth> I wonder why the hell changing it to a std::map accelerated savegame load for me
20100627 16:54:13< alink> Upth: btw does your macro change modify something important ?
20100627 16:55:15< Upth> Probably. Boucman told me to do it and see if it changed the numbers
20100627 16:55:48< Upth> <boucman> Upth: edit data/core/terrain-graphics/internal-complex, for each *RANDOM* macro only keep the last line << this
20100627 16:56:34< boucman> this removes all random variations
20100627 16:56:59< boucman> but since we don't try to see if a variation exists for all files, it should basically divide the number of terrains by 11
20100627 16:58:23< Upth> in fact it did reduce the image cache entries by 27116
20100627 16:58:40< alink> Upth :I think i see why using std::map may be better here. The index going in there are only the one from rendered images
20100627 16:59:16< Upth> Ah. so it might actually be a reasonable change?
20100627 16:59:50< alink> Upth which means that if I loaded 20000 image and only render the 20000th, the vector container will grow up to 20000 to register the index of that image
20100627 17:00:38< Upth> That is what was happening to me
20100627 17:00:54< Upth> only the index was 42579
20100627 17:01:05< alink> Upth: maybe, I am still concerned about the access cost, because I don't think you measure it
20100627 17:02:17< Upth> perhaps if we initialize the vector with image::locator::last_index_
20100627 17:02:55< alink> Upth yeah that's why I suggested using vector::reserve(40000) earlier 
20100627 17:05:11< alink> but I am not fan of this lru cache layer placed on top of the image cache, they should be combined somehow
20100627 17:05:58 * alink often wanted to improve this
20100627 17:06:30< alink> anyway, afk now, bbl
20100627 17:08:08-!- dtiger [~dtiger@dynamic-vpdn-93-125-66-139.telecom.by] has joined #wesnoth-dev
20100627 17:09:49< Upth> I'm trying to work out where/when the call would have to be placed in order to grow the vector as frequently as needed but not every single time last_index_ changes
20100627 17:10:45< boucman> Upth IIRC the vector has a given size, and when it's full, it will double its size...
20100627 17:11:02< boucman> so it shouldn't be every time the element is inserted
20100627 17:11:51< silene> right, as i said earlier this afternoon, (14:29:25) silene: Upth: if you have lots of resize, you should report that as a bug to your standard library provider; vector resizing is supposed to be O(1) amortized; if it isn't for you, it's a really bad bug
20100627 17:12:11< Upth> silene: it is not the stl's fault
20100627 17:12:29< silene> Upth: if resize appears in the profile, it definitely is
20100627 17:13:14< Upth> silene: when the vector has 168 elements and suddenly needs to grow to 40000
20100627 17:13:31< Upth> it is not the STL's fault that it has to be resized
20100627 17:14:29< silene> Upth: no, it is not, but you said that it was "being resized lots and lots", and that is stl's fault
20100627 17:16:22< Upth> silene: when the algorithm to grow it to accommodate 40000 is "while (index >= contents_.size()) contents_.push_back()", I do not blame the STL
20100627 17:17:13< silene> Upth: you should; and you should also look up what "amortized" means, you don't seem to know
20100627 17:17:19< Upth> it hits 256 elements has to resize, hits 512 elements, has to resize, hits 1024 elements, has to resize, hits 2048 elements, has to resize...
20100627 17:17:54< silene> Upth: so what, your computer is not even able to do 16 allocations in a row?!
20100627 17:18:42< Upth> well each element is a non-trivial structure and each time it resizes it has to move all of them to a new space in memory that fits the new size
20100627 17:19:26< silene> come on, moving 128k elements has a negligible cost; this is not where the issue is
20100627 17:19:59-!- knotwork [~markm@142.177.232.37] has quit [Ping timeout: 276 seconds]
20100627 17:20:50< boucman> i'd be suprised if it was a sdl bug (this thing tend to be tested in and out) but I must admit that the time spent in resize is weird (to say the lease)
20100627 17:21:21< boucman> Upth: do you know the number of time resize was called (as silene said, it should be called ~16 times)
20100627 17:21:51< Upth> boucman: I do not have a count of how many times it was called, no
20100627 17:22:13< Upth> the thing is, I'm sure I've seen other people complain about slowness in related issues
20100627 17:22:59< Upth> and I'm sure I'm the only one using msvc's STL.
20100627 17:23:33< Upth> though the precise amount of slowness I've seen has been insanely variable
20100627 17:24:06< Upth> from one time when I tried to load a save in the tutorial and it took 40 minutes, to today when I loaded a save and it took ~6
20100627 17:24:15< Upth> *the same save
20100627 17:24:57-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20100627 17:26:58< Upth> I got the impression that somehow several image caches were being created to store the same data
20100627 17:27:44< Upth> as though the caches were existing at function scope
20100627 17:30:21< Upth> anyway it is 8:30 AM and I need to sleep. alink seems to know how to fix it so the issue isn't worth pursuing further until and unless it is not resolved by the code he commits toward fixing it.
20100627 17:30:58-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has joined #wesnoth-dev
20100627 17:32:08-!- hhyloc [71a6a94a@gateway/web/freenode/ip.113.166.169.74] has joined #wesnoth-dev
20100627 17:32:40-!- hhyloc [71a6a94a@gateway/web/freenode/ip.113.166.169.74] has quit [Client Quit]
20100627 17:32:55-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has left #wesnoth-dev []
20100627 17:42:06< Gambit> "anyway it is 8:30 AM and I need to sleep" ouch.
20100627 17:42:33< zookeeper> boucman, ok, well, my idea of making the engine do more of the work (instead of the macros doing it) is in this case also intended to get us better performance. as we can see, the macro system has a really large amount of overhead because of things like 1) having rules for 6/5/4/3/2/1-sided transitions even when the particular terrain doesn't use that many and 2) having rules for 11 tile variants even if the particular terrain doesn't have th
20100627 17:42:59< zookeeper> ... and 2) having rules for 11 tile variants even if the particular terrain doesn't have that many.
20100627 17:43:22< boucman> zookeeper: well, their are 2 other ways of doing it
20100627 17:43:38< boucman> 1) have the terrain-programmer give us the info (impratical because of macros)
20100627 17:43:59< zookeeper> maybe not impractical if you generated those with meta-macros?
20100627 17:44:14< boucman> 2) have the engine test for the existence of files (which is more or less what it's doing,except we could hardcode it instead of having macros telling it)
20100627 17:44:20-!- knotwork [~markm@142.177.232.37] has joined #wesnoth-dev
20100627 17:44:20< boucman> i'm not sure either really help
20100627 17:44:29-!- loonybot [~loonybot@ppp79-139-137-245.pppoe.spdop.ru] has joined #wesnoth-dev
20100627 17:44:29-!- loonybot [~loonybot@ppp79-139-137-245.pppoe.spdop.ru] has quit [Changing host]
20100627 17:44:29-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-dev
20100627 17:45:24-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20100627 17:45:25< zookeeper> so instead of {TERRAIN_BASE_RANDOM Hh hills/regular} which tries to use 11 variants, you could have a meta-macro generated TERRAIN_BASE_RANDOM_2VARIANTS, TERRAIN_BASE_RANDOM_3VARIANTS etc and you could call the correct one like {TERRAIN_BASE_RANDOM_4VARIANTS Hh hills/regular} (if hills happened to have just 4 variants)
20100627 17:47:40< boucman> hmm, meta-macros couldn't generate that, it would have to be done by hand, but it makes more work on the user side, which is exactly what I'm trying to avoid with my macro rewrite...
20100627 17:53:35< boucman> zookeeper: (fyi, the only thing meta-macro is to do a "default value" for parameters...)
20100627 17:54:31< boucman> there might be a trick to make it work by having macro parameters expending in macro names... but it would be trick
20100627 17:57:03< zookeeper> boucman, hmmh? ok, i thought the meta-macro system was a bit more versatile than that
20100627 17:58:15< boucman> by doing something similar to the BUILDER type macros, there might be a way around that limitation to do what you want, but not sure that's a good idea, readability-wise
20100627 17:58:50< zookeeper> anyway, i don't think it's really more work on the user side. all the macro calls would be identical and you'd just change the number depending on how many variations you have.
20100627 17:59:09< zookeeper> and if you'd get it wrong, it'd actually still work
20100627 18:00:08< zookeeper> anyway, as i've said, i don't care about the specifics that much, but i think we can agree that _something_ should be done about the apparent inefficiency in the current macro system, right?
20100627 18:02:42< boucman> zookeeper: ok, we already agreed on that earlier, no prob :P
20100627 18:03:17< boucman> I personaly think that if a file doesn't exist, it shouldn't have an entry in the cache at all, it's not the parsing that is long apparently, it's the saving of the data in the cache
20100627 18:03:38< boucman> i.e i'd rather not start changing the macro system if something is wrong at another level
20100627 18:05:20< zookeeper> sure
20100627 18:08:01< alink> bouvman: well, the general image cache need to store if a file is missing, otherwise any missing standing animation frame would cause IO access every few frames
20100627 18:08:32< alink> boucman: but i am fixinf the code specific of terrain images which deals with all the missing images there
20100627 18:08:41< alink> s/fixinf/fixing
20100627 18:09:26< boucman> ok, so you detect the missing files earlier.. makes sense
20100627 18:12:42< alink> initial code was added because looking after a non-existent file could be costly, and terrain code do that a lot
20100627 18:13:08< alink> and strangely it didn't scale well with the number of add-ons installed
20100627 18:13:35< alink> because a file could be in any of the active binary paths
20100627 18:14:05< alink> so we need to look into all of them
20100627 18:34:52-!- Blitzmerker [~Blitzmerk@p3EE0A2EE.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds]
20100627 18:37:46-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20100627 18:42:37< alink> seeems that terrain WML must add the .png extension these days. Am I correct ?
20100627 18:45:13< alink> ok, it's fresh from r43555
20100627 18:45:53< boucman> alink: yes, we had to change that to allow the use of the ~ magic path in terrain
20100627 18:46:05-!- Crab_ [~Crab_@wesnoth/developer/crab] has quit [Quit: Leaving.]
20100627 18:46:08< alink> boucman: make sense
20100627 19:19:42-!- meric [~Eric@124-170-218-153.dyn.iinet.net.au] has quit [Quit: meric]
20100627 19:28:02-!- yann [~dwitch@nan92-1-81-57-214-146.fbx.proxad.net] has quit [Ping timeout: 276 seconds]
20100627 19:31:32< alink> Terrain image 'terrain/forest' misses the '.png' extension
20100627 19:31:44< alink> Terrain image 'terrain/' misses the '.png' extension
20100627 19:31:56-!- Bob_The_Mighty [~chatzilla@cpc8-brig15-2-0-cust40.know.cable.virginmedia.com] has joined #wesnoth-dev
20100627 19:32:17< alink> using trunk with my last commit r43751
20100627 19:36:49-!- Blueblaze [~nick@adsl-99-188-135-67.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100627 19:38:57< Elvish_Pillager> Hmm. Is there any way to advance a unit without animating it?
20100627 19:40:14-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has joined #wesnoth-dev
20100627 19:40:14-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has quit [Changing host]
20100627 19:40:14-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100627 19:43:11< boucman> Elvish_Pillager: through WML ?
20100627 19:43:18< Elvish_Pillager> boucman: yeah
20100627 19:43:45< boucman> not that I know of, what's the name of the WML action (so i can have a look
20100627 19:44:31< Elvish_Pillager> [unstore_unit] with advance=true when the unit has the needed XP
20100627 19:44:41< Elvish_Pillager> (advance=true is the default, but it shouldn't be)
20100627 19:45:07< alink> can you provide your own advance animation (and then use a dummy one) ?
20100627 19:45:28< Elvish_Pillager> alink: I can, but I assume it would still scroll to the unit and redraw, which I don't want.
20100627 19:45:46< alink> Elvish_Pillager: ok
20100627 19:46:32< boucman> Elvish_Pillager: no you can't, and it's not "trivial" (probably still easy to do, I havn't looked that far)
20100627 19:46:42< Elvish_Pillager> okay
20100627 19:50:12< boucman> you can probably add it to EasyCoding, though :P
20100627 19:50:51< Elvish_Pillager> heh...
20100627 19:53:07< zookeeper> btw, i second the idea of making advance= default to no
20100627 19:54:35< Elvish_Pillager> (it caused a fairly major bug in EoHS recently)
20100627 19:54:37< zookeeper> at least unless all OOS and other issues relating to it are solved
20100627 19:55:33< alink> Terrain image 'terrain/forest' misses the '.png' extension <-- fixed (was a test-scenario error)
20100627 19:56:07-!- Bob_The_Mighty [~chatzilla@cpc8-brig15-2-0-cust40.know.cable.virginmedia.com] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.4/20100611143157]]
20100627 19:57:10-!- phlaem [~a@e178087037.adsl.alicedsl.de] has joined #wesnoth-dev
20100627 20:04:43-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20100627 20:04:49< zookeeper> so has anyone checked all [terrain_graphics] uses in mainline? there's a few in core/utils/image-utils.cfg for instance
20100627 20:06:10-!- Shakey [HydraIRC@c-71-201-89-187.hsd1.il.comcast.net] has joined #wesnoth-dev
20100627 20:06:42< alink> data/core/macros/image-utils.cfg
20100627 20:06:55< zookeeper> oops, right
20100627 20:07:21< alink> and indeed, there seems to miss png extension
20100627 20:07:24< zookeeper> those at least don't have any .png e...yeah
20100627 20:07:48< alink> and my last commit should now report them (when used)
20100627 20:10:39< zookeeper> looks like CIA isn't working then
20100627 20:11:20< alink> yeah he is dead since >1h
20100627 20:11:37-!- ancestral [~ancestral@mobile-166-137-141-178.mycingular.net] has joined #wesnoth-dev
20100627 20:16:25< alink> Upth: with my last change, I seems to win only few % or (few 100ms) to load test-scenario :-|
20100627 20:16:46< zookeeper> so, i'll fix the ones in image-utils.cfg?
20100627 20:16:47< alink> Upth: tell me if it improves more your test-case
20100627 20:17:12< alink> zookeeper: ok
20100627 20:17:36< CIA-87> alink * r43750 /trunk/src/ (builder.cpp image.cpp image.hpp): 
20100627 20:17:36< CIA-87> Improve precaching of terrain images existence by also skipping any image cache record.
20100627 20:17:36< CIA-87> This reduces the index numbers used.
20100627 20:17:37< CIA-87> Also temporary disable a log::wml_error about missing ".png" extension
20100627 20:18:52< alink> Upth: btw, few% for starting the whole test-scenario, not just the image loading
20100627 20:19:52< CIA-87> alink * r43751 /trunk/src/builder.cpp: Fix small error in previous commit and restore wml warning about missing png extension
20100627 20:20:12< zookeeper> alink, ok, done
20100627 20:20:25< alink> zookeeper: thanks
20100627 20:21:03< alink> there is still a ' ' used somewhere, but I suppose we will need a trick to find where
20100627 20:22:18< zookeeper> hm?
20100627 20:22:20< CIA-87> alink * r43752 /trunk/data/scenario-test.cfg: 
20100627 20:22:21< CIA-87> remove a terrain rule from test-scenario
20100627 20:22:37< CIA-87> Pobably broken since a long-time, used a directory instead of an image
20100627 20:22:38< alink> "Terrain image 'terrain/' misses the '.png' extension"
20100627 20:26:10< CIA-87> zookeeper * r43753 /trunk/data/core/macros/image-utils.cfg: Added the new .png extensions to [terrain_graphics] tags used in image-utils.cfg.
20100627 20:26:51< alink> '' seems to comes the first rule checked
20100627 20:26:55< alink> +from
20100627 20:29:36< silene> alink: in the logs you posted earliers, some images had multiple indices; do your patches fix it?
20100627 20:30:23< alink> silene: I think so
20100627 20:30:49< alink> except maybe for the ones having a ".." in their paths
20100627 20:31:07< alink> but they should be very rare
20100627 20:35:06< alink> silene: correction, that multiple indices thing is not fixed, I investigate why
20100627 20:38:07< alink> updated log output http://wesnoth.pastebin.com/3Wzzd49X
20100627 20:39:51< alink> ok found the cause
20100627 20:39:52< silene> right, still lots of duplicates, six by terrains
20100627 20:40:18< alink> I'll update a clearer output 
20100627 20:41:19< alink> http://wesnoth.pastebin.com/SWKEnX33
20100627 20:41:31< alink> there is a parameter different
20100627 20:41:59< alink> ( added loc_ which may be different, even with same filename_)
20100627 20:42:39< alink> but maybe there is possible WML/GFX optimisations here
20100627 20:42:45-!- akeenanr__ [~quassel@cpe-74-74-148-190.rochester.res.rr.com] has quit [Ping timeout: 240 seconds]
20100627 20:44:14< alink> unless all these images have few pixels (because of the hex cutting)
20100627 20:54:02-!- yann [~dwitch@nan92-1-81-57-214-146.fbx.proxad.net] has joined #wesnoth-dev
20100627 20:54:21-!- Valkier [~IceChat7@c-174-55-104-2.hsd1.pa.comcast.net] has quit [Ping timeout: 260 seconds]
20100627 21:01:31< CIA-87> silene * r43754 /trunk/src/ (image.cpp image.hpp reports.cpp): 
20100627 21:01:31< CIA-87> Moved image cache definitions out of the header file.
20100627 21:01:31< CIA-87> Fixed double element copy on cache copy and cache query.
20100627 21:01:31< CIA-87> Simplified code by explicit resizing.
20100627 21:01:32< CIA-87> Fully flushed caches on F5.
20100627 21:07:48-!- ancestral [~ancestral@mobile-166-137-141-178.mycingular.net] has quit [Ping timeout: 258 seconds]
20100627 21:09:09-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100627 21:11:41< CIA-87> silene * r43755 /trunk/src/scripting/lua.cpp: Fixed missing 'type' attribute for units.
20100627 21:13:00-!- happygrue [~George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20100627 21:13:40< alink> mmh if my debug code is correct, more than half of the images are fully transparent ones (when rendering test scenario full map)
20100627 21:14:35< alink> correctly RLE encoded, they should be cheap, once cached, but there is processing cost before that (hex cutting, ToD, etc..)
20100627 21:15:08< silene> fully transparent? how come?
20100627 21:15:40< alink> silene: I believe it comes from the terrain images cutting bigger images in several hexes
20100627 21:16:04< alink> depending of the sprite, some hex may receive no opaque pixels
20100627 21:16:30< alink> but that's just a guess from past experience
20100627 21:17:08< CIA-87> silene * r43756 /branches/1.8/src/scripting/lua.cpp: 
20100627 21:17:08< CIA-87> Fixed missing 'type' attribute for units.
20100627 21:17:08< CIA-87> Backported from trunk r43755.
20100627 21:18:42< alink> some vilage are horrible for that, using 200x200 mother surface
20100627 21:18:49< alink> *villages
20100627 21:19:21< silene> really? let's truncate them then
20100627 21:19:56-!- Tycale [~Thibault@viki-network.net] has joined #wesnoth-dev
20100627 21:20:11< alink> I agree we should, but they are currently cutted by WML terrain rules I think
20100627 21:20:19< alink> so need to update too I guess
20100627 21:20:30< alink> *update them
20100627 21:20:35 * alink is tired
20100627 21:21:10< alink> on a related note, why some images use 64bpp png encoding ?
20100627 21:21:22< alink> like village/cave.png
20100627 21:21:49< alink> SDL/wesnoth convert that to 32bpp
20100627 21:22:36< alink> anyway, I need to validate/check my debug code first
20100627 21:22:39< Espreon> alink: If you wanna convert everything, get AI0867 on the case. ;)
20100627 21:22:43< alink> and before that I need a break
20100627 21:23:12< Espreon> He'll read the big, bad ImageMagick documentation.
20100627 21:24:33< alink> ok, but now I'll go, I will give more debug info about these empty images later, afk
20100627 21:30:51-!- Shakey [HydraIRC@c-71-201-89-187.hsd1.il.comcast.net] has quit [Quit:  HydraIRC -> http://www.hydrairc.com <- Nine out of ten l33t h4x0rz prefer it]
20100627 21:36:13-!- e_s-iOS [~esios@pool-108-2-88-55.phlapa.east.verizon.net] has joined #wesnoth-dev
20100627 21:41:50-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100627 21:46:07-!- e_s-iOS [~esios@pool-108-2-88-55.phlapa.east.verizon.net] has quit [Quit: Colloquy for iOS - client quit]
20100627 21:48:33-!- e_s-iOS [~esios@pool-108-2-88-55.phlapa.east.verizon.net] has joined #wesnoth-dev
20100627 22:12:00-!- e_s-iOS [~esios@pool-108-2-88-55.phlapa.east.verizon.net] has quit [Remote host closed the connection]
20100627 22:14:08-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has quit [Remote host closed the connection]
20100627 22:16:19-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100627 22:23:27-!- Johannes13_ [~Johannes@unaffiliated/johannes13] has joined #wesnoth-dev
20100627 22:25:40-!- silene [~plouf@bau91-1-82-239-244-109.fbx.proxad.net] has quit [Quit: Leaving.]
20100627 22:27:26-!- Johannes13 [~Johannes@unaffiliated/johannes13] has quit [Ping timeout: 276 seconds]
20100627 22:39:34-!- dtiger [~dtiger@dynamic-vpdn-93-125-66-139.telecom.by] has quit [Remote host closed the connection]
20100627 22:39:41-!- happygrue_ [~George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20100627 22:41:27-!- Gallaecio [~Gallaecio@232.158.60.213.dynamic.mundo-r.com] has quit [Remote host closed the connection]
20100627 22:43:17-!- happygrue [~George@wesnoth/developer/wintermute] has quit [Ping timeout: 265 seconds]
20100627 22:44:25-!- knotwork_ [~markm@142.177.232.154] has joined #wesnoth-dev
20100627 22:47:41-!- knotwork [~markm@142.177.232.37] has quit [Ping timeout: 240 seconds]
20100627 22:54:49-!- Bob_The_Mighty [~chatzilla@cpc8-brig15-2-0-cust40.know.cable.virginmedia.com] has joined #wesnoth-dev
20100627 22:55:03-!- eleazar [~eleazar@ppp-70-226-197-86.dsl.spfdil.ameritech.net] has joined #wesnoth-dev
20100627 22:56:30< shadowmaster> Espreon: you say it
20100627 22:56:34 * eleazar just reviewed the log
20100627 22:56:52< eleazar> alink: you are right terrain should only have 32bpp
20100627 22:57:01< zookeeper> oh, hi eleazar
20100627 22:57:09< eleazar> zookeeper: hi
20100627 22:57:28< zookeeper> the grass in your latest grass post looked pretty great
20100627 22:57:35< shadowmaster> er, I didn't know the PNG format supperted anything greater than 32 bpp/RGBA
20100627 22:57:51< Espreon> eleazar: shadowmaster and I believe that the new dark road is a bit blurry. (Sorry if I sound a bit uncouth)
20100627 22:57:53< eleazar> zookeeper:  thanks, i'm pretty happy with it ;)
20100627 22:59:22< eleazar> Espreon: i lowered the contrast a bit 
20100627 23:00:02< eleazar> it still has rather shaper definition than most terrain
20100627 23:00:20< boucman> hey eleazar :)
20100627 23:00:31< eleazar> boucman: yup...
20100627 23:00:47-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100627 23:00:59< boucman> eleazar: i'm struggling with the new bridges, but if I manage to fit it in the generic bridge macro, we'll have something absolutely great able to handle anything we throw at it :)
20100627 23:01:56< eleazar> boucman: i admit that discussion seems pretty complicated
20100627 23:02:34< boucman> well, lurker obviously first draw everything, then cut it how he felt, then did the rules...
20100627 23:02:43< boucman> so they are barely hex based :P
20100627 23:03:15< boucman> but i'll manage... :)
20100627 23:03:33-!- elvish_sovereign [~Zoltan@pool-108-2-88-55.phlapa.east.verizon.net] has joined #wesnoth-dev
20100627 23:04:54< eleazar> boucman:  about villages.  is it still neccesary to have such large files for villages that extend outside the hex?
20100627 23:05:05< eleazar> large image dimensions i mean
20100627 23:05:45< eleazar> 180x216
20100627 23:05:57< boucman> hmm, my knowledge of file size vs positioning is not as good as I would like, but AFAIU as long as the center of the image doesn't move you should be able to crop...
20100627 23:06:12< boucman> though testing it is the best way to know
20100627 23:06:57< eleazar> actually i think some of these don't even extend outside the hex...
20100627 23:07:02< zookeeper> no, it's not necessary, but if you change the size you'll need to tweak the WML too
20100627 23:07:23< zookeeper> unless they're centered already, but i think they aren't
20100627 23:07:42< eleazar> villages are more or less centered
20100627 23:07:48< boucman> zookeeper: ??? you sure ? all [image] are out of [tile] now, and the center field is correctly set afaik
20100627 23:08:15< boucman> zookeeper: I think they are, if they wern't, with the current macro, the would be totally of center of the hex
20100627 23:08:43< eleazar> any changes in the last couple weeks relevant to this, i.e. do i need to recompile to test?
20100627 23:09:22< boucman> hmm, the last change was the .jpg change, so unless everything is broken, it means you are already past that point and should be fine
20100627 23:09:44< eleazar> k
20100627 23:10:07< zookeeper> boucman, ok, then my memory is simply out of date
20100627 23:10:42< eleazar> if it made a significant different to speed, i'd be willing to get rid of the option to adjust the probability of a given tile.
20100627 23:10:54< eleazar> ie. "VILLAGE_PB"
20100627 23:11:50< boucman> eleazar: noted... though I'm not sure it would change much, unless we drop all variations on villages, which is too high a price to pay
20100627 23:12:09< boucman> the time seems to be related to the number of file we test for existance, not the actual number of macros
20100627 23:17:58-!- ancestral [~ancestral@12.145.225.25] has joined #wesnoth-dev
20100627 23:19:34< eleazar> hmm, cropping a village works fine.  I didn't even have to restart wesnoth to see it in the right place.
20100627 23:20:04< boucman> :)
20100627 23:20:07< eleazar> -- on this test i cropped to 72x72
20100627 23:20:20-!- shadowmaster [~ignacio@wesnoth/developer/shadowmaster] has quit [Read error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number]
20100627 23:20:40-!- shadowmaster [~ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100627 23:21:54< eleazar> ... now to look at the 106 others...
20100627 23:26:40< eleazar> looks like a few villages are already bigger than 72x72 but smaller than 180x216
20100627 23:26:43-!- Kiba [~user@adsl-176-42-69.asm.bellsouth.net] has quit [Ping timeout: 240 seconds]
20100627 23:29:40-!- knotwork__ [~markm@142.177.178.67] has joined #wesnoth-dev
20100627 23:32:45-!- knotwork_ [~markm@142.177.232.154] has quit [Ping timeout: 240 seconds]
20100627 23:33:56-!- happygrue [~George@c-67-175-144-211.hsd1.in.comcast.net] has joined #wesnoth-dev
20100627 23:34:00-!- happygrue [~George@c-67-175-144-211.hsd1.in.comcast.net] has quit [Changing host]
20100627 23:34:01-!- happygrue [~George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20100627 23:37:13-!- mjs-de [~mjs-de@p3EE2375E.dip.t-dialin.net] has quit [Remote host closed the connection]
20100627 23:37:54-!- happygrue_ [~George@wesnoth/developer/wintermute] has quit [Ping timeout: 265 seconds]
20100627 23:41:48< boucman> night all
20100627 23:41:52-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20100627 23:42:04< freim> maybe sprite sheets would be the way to go
20100627 23:42:17< freim> to increase performance
20100627 23:42:33< freim> did that become a gsoc?
20100627 23:42:33< Aethaeryn> yes
20100627 23:42:40< Aethaeryn> I think it's planned.
20100627 23:43:11< freim> Freeciv uses sheets for everything, I must say I prefer it from an artist pov also
20100627 23:43:55-!- noy [~Noy@70.70.255.54] has joined #wesnoth-dev
20100627 23:44:00-!- noy [~Noy@70.70.255.54] has quit [Changing host]
20100627 23:44:00-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100627 23:45:14< freim> eleazar: new grass looks really great btw :)
20100627 23:45:24< eleazar> :)
20100627 23:46:29-!- ancestral [~ancestral@12.145.225.25] has quit [Remote host closed the connection]
20100627 23:46:57< Aethaeryn> yeah
20100627 23:47:02< Aethaeryn> I might have to include flat in my maps now
20100627 23:47:09< Aethaeryn> to the disappointment of those who like long games
20100627 23:49:42< freim> eleazar: so much improvememts lately that desert mountains sticks out even more as really in need of a replacement
20100627 23:50:13< freim> eleazar: maybe someone could work of my new test tile and make something usefull, I got a bit stuck on it
20100627 23:50:34-!- happygrue_ [~George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20100627 23:51:40< eleazar> at the moment, i think it would be more useful to create transitions that let you standard mountains transition nicely with desert, and other terrrains --- i expect to get to that this summer
20100627 23:52:41< freim> eleazar: ok, how do you plan to approach it?
20100627 23:53:15< eleazar> boucman has added the capacity to make multi-hex transitions
20100627 23:53:46< eleazar> At the moment the mountains use the green hill transition at the bottom
20100627 23:53:54-!- happygrue [~George@wesnoth/developer/wintermute] has quit [Ping timeout: 245 seconds]
20100627 23:54:48< eleazar> for desert, i'd use a desert-colored hill transition instead-- and it would extend up into the mountains hex a bit to blend the colors
20100627 23:55:19-!- happygrue [~George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20100627 23:55:28< zookeeper> wouldn't the easiest way to make "ok" desert mountains be to colour-edit the current mountains, changing the green bits to look more sandy? or would that just end up looking horrible?
20100627 23:56:53< freim> don't think that would look any good
20100627 23:57:09< freim> should be a different kind of mountains
20100627 23:57:37< eleazar> zookeeper:  yes that would be easier, but i'd like the normal mountains to be able to transition to other kinds of terrain
20100627 23:57:39< freim> I think the colors I used in my example tile is ok, but the shape didn't work out
20100627 23:57:49< freim> I wouldn't mind some others pitching in there
20100627 23:57:55-!- happygrue__ [~George@c-67-175-144-211.hsd1.in.comcast.net] has joined #wesnoth-dev
20100627 23:59:15-!- happygrue_ [~George@wesnoth/developer/wintermute] has quit [Ping timeout: 260 seconds]
20100627 23:59:57< eleazar> heh-- mountains and castles are the two thing i wouldn't want to do from scratch
--- Log closed Mon Jun 28 00:00:08 2010