--- Log opened Fri Nov 07 00:00:18 2014
20141107 00:01:02< duncan_shriek> src/ana/src/asio_server is 4 years old. The branch asio_wesnothd is 2 1/2 years old. I'm wondering wether it's worth to resurrect one of those projects or if it's better to start over
20141107 00:02:09-!- Appleman1234 [~Appleman1@pool-173-74-87-52.dllstx.fios.verizon.net] has quit [Ping timeout: 272 seconds]
20141107 00:04:55< iceiceice> gfgtdf: i make a patch to try to fix the mp create slowness:
20141107 00:04:55< iceiceice> https://github.com/wesnoth/wesnoth/pull/327
20141107 00:07:04< iceiceice> okay it won't fix but i think it might help
20141107 00:07:22< gfgtdf> iceiceice: how will cachign help here ? I think the report was not about slowdownas when you select another map but rather about when you start the the mp create screen the first load takes too long
20141107 00:08:06< Dugi> Good night.
20141107 00:08:10-!- Dugi [93fbd29f@gateway/web/freenode/ip.147.251.210.159] has quit []
20141107 00:08:12< iceiceice> you said you thought its because of minimap calculation
20141107 00:08:31< iceiceice> caching it will mean that we don't have to redo that
20141107 00:08:47< gfgtdf> iceiceice: yes but teh problme is that even doing it once takes too long
20141107 00:08:50< iceiceice> hmm is it the case that we calculate *all* minimaps when you open the screen
20141107 00:09:00< iceiceice> or just the one
20141107 00:09:05< gfgtdf> iceiceice: hmm
20141107 00:09:13< gfgtdf> iceiceice: acutaly it was some time ago
20141107 00:09:50< iceiceice> gfgtdf: it seems that caching will help for usability if the minimap creation function is actually slow
20141107 00:09:52< gfgtdf> iceiceice: wait i'll redo my test that i did when i answered in that report
20141107 00:10:02< iceiceice> because if it takes 6 seconds to make a minimap,
20141107 00:10:08< iceiceice> at least i wont have to do it again if i am clicking around
20141107 00:10:28< iceiceice> i would believe that its the minimap creation function since iirc that thing is new in 1.12
20141107 00:10:47-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: ancestral]
20141107 00:10:48< iceiceice> and i believe it does some crazy stuff like, render the entire map at enormous resolution off screen, and then scale down
20141107 00:11:14< iceiceice> rather than just draw at the appropriate size
20141107 00:11:26< gfgtdf> iceiceice: i think taht bnot teh probem
20141107 00:11:28< gfgtdf> not*
20141107 00:11:51< gfgtdf> iceiceice: gamemap s construcor calls create_terrain_maps
20141107 00:13:01< gfgtdf> iceiceice: we parse that [terrain_type] information from game_config again for every previwe map we create
20141107 00:13:32-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141107 00:14:33< gfgtdf> iceiceice: thats the main cause of the slowdown in that report i think
20141107 00:14:35-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Client Quit]
20141107 00:17:36-!- Appleman1234 [~Appleman1@pool-173-74-87-52.dllstx.fios.verizon.net] has joined #wesnoth-dev
20141107 00:18:28< gfgtdf> iceiceice: ok my test right now didnt prove that, but that may be also becasue i didnt have much addonds that add [terrain_type]s during the test-
20141107 00:18:51< iceiceice> yeah why do we run this int he gamemap ctor
20141107 00:18:59< iceiceice> it seems totally pointless it doesnt have anything to do with the map
20141107 00:21:15< iceiceice> gfgtdf: i think instead these lists should be in some adjunct class of the game_config_manager
20141107 00:21:26< iceiceice> and updated when the game_config_manager is asked to change modes
20141107 00:22:09< gfgtdf> iceiceice: maybe we shoudl still load it lazyly so that for example we dont load them for frontpage/campaign_selection when we dont neeed them
20141107 00:22:29< iceiceice> gfgtdf: we kind of do need them there, if you open the help browser
20141107 00:22:39< iceiceice> but i dont think lazy is a problem
20141107 00:28:37< iceiceice> gfgtdf: do you think there's a reason not to merge the image cache thing anyways?
20141107 00:29:01< iceiceice> i may try to make a terrain_type_manager next
20141107 00:32:44< gfgtdf> iceiceice: did you test that si actauyl was faster ?
20141107 00:32:48-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141107 00:32:56< gfgtdf> iceiceice: the pr i mean
20141107 00:33:10< iceiceice> i tested that it didn't break anything
20141107 00:33:17< iceiceice> if minimap calculation is nontrivial then it will surely be faster
20141107 00:33:52< iceiceice> its hard for me to test this stuff because my new computer is much better than my old one,
20141107 00:33:57< iceiceice> i dont really get any noticeable slowdowns
20141107 00:34:16< iceiceice> it would be a lot of work to profile it, and right now i just dont see that there could be a downside
20141107 00:34:35< gfgtdf> iceiceice: note hat for random maps the previwe maps changes evertime you click on it
20141107 00:34:38< gfgtdf> that*
20141107 00:34:54< iceiceice> yeah,
20141107 00:35:02< iceiceice> actually i dont see why that's good, it seems like a minor bug
20141107 00:35:09< iceiceice> it seems it should only change when you click regenerate
20141107 00:35:12< gfgtdf> iceiceice: that intendd
20141107 00:35:20< gfgtdf> iceiceice: hm ok
20141107 00:35:30< iceiceice> but i looked at code, it seems it was designed this way ig uess
20141107 00:35:37< iceiceice> idk i dont want to fuss about it right now
20141107 00:35:50< gfgtdf> iceiceice: well i guess whether chaning selection shodul invoke regenerate is discussable
20141107 00:36:08< iceiceice> the only way the caching will hurt performance is if theres so much stuff cached that it uses a lot of memory
20141107 00:36:23< iceiceice> but if you look at how stuff works in game in image.cpp,
20141107 00:36:43< iceiceice> we cache like, 3 or 4 versions of every sprite of every animation frame of every unit
20141107 00:36:52< iceiceice> we cache the raw version,
20141107 00:36:55< iceiceice> we cache the scaled version,
20141107 00:37:05< iceiceice> for terrains, we cache the raw version,
20141107 00:37:11< iceiceice> the version which is cut to be the size of a hex,
20141107 00:37:22< iceiceice> we cache the scaled and hexed version,
20141107 00:37:28< iceiceice> we cache the tod colored version...
20141107 00:37:29< gfgtdf> iceiceice: the hash think is to make sure the preview map get updates when we regenrate a map ?
20141107 00:37:37< iceiceice> yeah
20141107 00:38:01< iceiceice> or if it changes some other way
20141107 00:38:16< iceiceice> i guess thats the only way right now
20141107 00:38:54< gfgtdf> iceiceice: hm ok i see no reason against but i also dont really know about how surface or mp create works eigher.
20141107 00:39:20< iceiceice> ok, maybe i leave it open for a bit
20141107 00:41:58-!- oldlaptop [~quassel@50-108-67-218.adr01.mskg.mi.frontiernet.net] has quit [Ping timeout: 258 seconds]
20141107 00:42:31-!- oldlaptop [~quassel@50-108-67-218.adr01.mskg.mi.frontiernet.net] has joined #wesnoth-dev
20141107 00:46:42-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20141107 00:47:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20141107 00:48:03-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Computer's napping]
20141107 00:58:02-!- roland_ [~roland@2a01:1e8:e100:8618::24] has joined #wesnoth-dev
20141107 00:59:19-!- duncan_shriek [~roland@2a01:1e8:e100:8618::24] has quit [Read error: Connection reset by peer]
20141107 01:01:46-!- roland_ [~roland@2a01:1e8:e100:8618::24] has quit [Client Quit]
20141107 01:08:53-!- gfgtdf [~chatzilla@e177145093.adsl.alicedsl.de] has quit [Read error: Connection reset by peer]
20141107 01:30:38-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20141107 01:55:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 255 seconds]
20141107 02:18:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20141107 02:24:21-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141107 02:30:06-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Read error: Connection reset by peer]
20141107 02:49:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 265 seconds]
20141107 03:14:18-!- Ivanovic_ [~ivanovic@frnk-d9333220.pool.mediaWays.net] has joined #wesnoth-dev
20141107 03:15:17-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141107 03:17:40-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 255 seconds]
20141107 03:18:12-!- Ivanovic_ is now known as Ivanovic
20141107 03:25:35-!- SpoOkyMagician [~chatzilla@cpe-74-132-242-221.swo.res.rr.com] has quit [Quit: meh]
20141107 03:35:56< iceiceice> fabi: there?
20141107 03:36:05< fabi> iceiceice: yes
20141107 03:36:13< iceiceice> quick question:
20141107 03:36:21< fabi> iceiceice: I was just thinking about contacting you.
20141107 03:36:28< iceiceice> is there any particular reason that the editor map is a derived class of the gamemap?
20141107 03:37:01< fabi> well the normal inheritence stuff
20141107 03:37:13< fabi> display works with maps
20141107 03:38:03< iceiceice> so at least in my experience i try not to use inheritance unless it's extremely convenient for some reason, and i try to favor composition instead
20141107 03:38:08< fabi> and editor_display is therefore derived from display
20141107 03:38:14< iceiceice> like it could just be a regular class that owns a copy of a gamemap privately
20141107 03:38:20< iceiceice> and can return a const reference to such
20141107 03:38:45< iceiceice> otherwise it can get very inflexible if you need to change how gamemap works
20141107 03:39:43< fabi> worth a thought
20141107 03:39:53< iceiceice> okay just thought i would ask, i dont have plans to change it right now
20141107 03:40:06< iceiceice> im tryign to change gamemap though
20141107 03:40:16< fabi> the whole display theme gui1 stuff
20141107 03:40:21< fabi> needs some refactoring
20141107 03:41:04< fabi> iceiceice: I have redone the core and failsave fallback solutions.
20141107 03:41:37< iceiceice> i see, what's the update?
20141107 03:42:04< fabi> more error handling
20141107 03:42:16< fabi> every found core gets now validated
20141107 03:42:36< fabi> if loading the wml stuff fails we first try to go without addons
20141107 03:42:44< fabi> if that fails we try the default core
20141107 03:42:58< fabi> the failsave core is then more or less obsolete
20141107 03:43:31< fabi> --core <id> can be used to load a specific core
20141107 03:44:14< fabi> Add-ons containing cores must own a cores.cfg files at their toplevel.
20141107 03:45:09< fabi> The next step is to implement a more fine grained dependency system.
20141107 03:45:23< fabi> Then I call the feature done, for now.
20141107 03:46:11< iceiceice> so what is your vision for how cores work
20141107 03:46:19< iceiceice> are people with different cores loaded compatible?
20141107 03:46:25< iceiceice> i guess not, right?
20141107 03:46:44< iceiceice> are you supposed to have to go to the title screen to change cores, or is it supposed to happen automatically as a dependency resolution?
20141107 03:47:49< fabi> That are good questions.
20141107 03:48:21-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 264 seconds]
20141107 03:49:15< fabi> I don't know much about MP.
20141107 03:49:46< fabi> How is it handled with missing dependencies currently?
20141107 03:50:50-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20141107 03:52:59< iceiceice> fabi: so normally it just greys things out and you can't do whatever the action is
20141107 03:53:02< iceiceice> that's fairly annoying
20141107 03:53:04< fabi> I wonder how the user should be informed when the add-ons are disabled.
20141107 03:53:08< iceiceice> there is now a dependency manager
20141107 03:53:18< iceiceice> that is suppsoed to help user resolve dependencies and conflits
20141107 03:53:39< iceiceice> i also made a branch to make it so that if you try to join a game and the dep manager says you need an addon, 
20141107 03:53:47< iceiceice> it will prompt you to download the missing addon in one click
20141107 03:54:12< iceiceice> so if you want to see what is working right now on current master,
20141107 03:54:28< iceiceice> fire it up and download tekelili's WC 2 addon
20141107 03:54:35< iceiceice> then go to the random maps section
20141107 03:54:45< fabi> maybe that can be recycled to manage core switching
20141107 03:54:51< iceiceice> fabi: yeah maybe
20141107 04:01:21-!- happygrue [~Laptop@wesnoth/developer/wintermute] has quit [Remote host closed the connection]
20141107 04:01:30< fabi> is there already a way to display message on the titlescreen?
20141107 04:01:48-!- markus_ is now known as mjs-de
20141107 04:01:54< fabi> Currently I see the Version number.
20141107 04:02:59< iceiceice> fabi: i think the title screen is a gui2 window,
20141107 04:03:01< iceiceice> you could add labels to it
20141107 04:03:26< fabi> Most likely the Version Number is already a label
20141107 04:04:04< fabi> I search for a place to display "Add-ons disabled".
20141107 04:04:52-!- timotei [~timotei@79.119.105.71] has joined #wesnoth-dev
20141107 04:04:55-!- timotei [~timotei@79.119.105.71] has quit [Changing host]
20141107 04:04:55-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20141107 04:08:10-!- Kexoth [~kex@78.157.29.160] has quit [Remote host closed the connection]
20141107 04:33:56-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141107 04:39:08-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141107 05:04:28< fabi> shadowm: Hello
20141107 05:07:33< shadowm> Hi.
20141107 05:10:48< fabi> shadowm: I think about a UI thing to control whether the add-ons are being loaded or not.
20141107 05:11:22< fabi> The add-on control center you mentioned earlier is surely the right place for such a thing.
20141107 05:22:19-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141107 05:45:35-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20141107 05:56:32-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141107 05:58:18-!- Sulfur [~Miranda@p5B32782B.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141107 05:58:26-!- EliDupree [~quassel@66-189-34-122.dhcp.oxfr.ma.charter.com] has quit [Ping timeout: 256 seconds]
20141107 06:01:32-!- EliDupree [~quassel@66-189-34-122.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20141107 06:01:33-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 264 seconds]
20141107 06:21:06-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: ancestral]
20141107 06:21:43-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141107 06:27:16-!- sachith500 [~kvirc@112.135.154.88] has joined #wesnoth-dev
20141107 06:28:32-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: End Transmission.]
20141107 06:41:56-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141107 06:46:29-!- kex [~kex@78.157.29.160] has quit [Ping timeout: 245 seconds]
20141107 06:49:08-!- Ivanovic [~ivanovic@frnk-d9333220.pool.mediaWays.net] has quit [Changing host]
20141107 06:49:08-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20141107 06:50:26-!- sachith500 [~kvirc@112.135.154.88] has quit [Read error: Connection reset by peer]
20141107 06:50:43-!- sachith500 [~kvirc@112.135.154.88] has joined #wesnoth-dev
20141107 07:04:05-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20141107 07:05:04-!- rayblade53 [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20141107 07:05:07-!- rayblade53 is now known as vultraz
20141107 07:06:49-!- sachith500 [~kvirc@112.135.154.88] has quit [Read error: Connection reset by peer]
20141107 07:16:51-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141107 07:17:03-!- kex [~kex@78.157.29.160] has quit [Remote host closed the connection]
20141107 07:23:15< iceiceice> fabi: there?
20141107 07:35:26-!- Dugi [93fb407b@gateway/web/freenode/ip.147.251.64.123] has joined #wesnoth-dev
20141107 08:17:05-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20141107 08:18:54-!- Coffee_irc [~david@ppp118-210-90-49.lns20.adl2.internode.on.net] has joined #wesnoth-dev
20141107 08:23:58-!- Dugi [93fb407b@gateway/web/freenode/ip.147.251.64.123] has quit [Ping timeout: 246 seconds]
20141107 08:25:34-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141107 08:35:12-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20141107 08:36:28-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has joined #wesnoth-dev
20141107 08:36:49-!- sachith500 [~kvirc@112.135.154.88] has joined #wesnoth-dev
20141107 08:45:55-!- boucman_work [~jrosen@247.37.0.109.rev.sfr.net] has joined #wesnoth-dev
20141107 08:45:55-!- boucman_work [~jrosen@247.37.0.109.rev.sfr.net] has quit [Changing host]
20141107 08:45:55-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20141107 09:10:11-!- Sulfur [~Miranda@p5B32782B.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20141107 09:59:31-!- duncan_shriek [~roland@2a01:1e8:e100:8618::24] has joined #wesnoth-dev
20141107 10:17:24-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 256 seconds]
20141107 10:30:07-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20141107 10:36:11-!- cib0 [~cib@132.231.178.7] has joined #wesnoth-dev
20141107 10:50:14-!- cib0 [~cib@132.231.178.7] has quit [Ping timeout: 245 seconds]
20141107 11:03:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20141107 11:13:20-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 258 seconds]
20141107 11:13:22-!- sachith500 [~kvirc@112.135.154.88] has quit [Ping timeout: 240 seconds]
20141107 11:13:53-!- sachith500 [~kvirc@112.135.148.50] has joined #wesnoth-dev
20141107 11:24:09-!- sachith500 [~kvirc@112.135.148.50] has quit [Read error: Connection reset by peer]
20141107 11:24:27-!- sachith500 [~kvirc@112.135.148.50] has joined #wesnoth-dev
20141107 11:28:02-!- Anakonda [Anakonda@87-92-195-246.bb.dnainternet.fi] has joined #wesnoth-dev
20141107 12:13:10-!- kex [~kex@77.28.4.239] has joined #wesnoth-dev
20141107 12:20:29-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20141107 12:34:54-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20141107 12:43:38-!- DCW [~Thunderbi@cpc66866-finc15-2-0-cust47.4-2.cable.virginm.net] has joined #wesnoth-dev
20141107 12:49:51-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20141107 12:57:23-!- DCW [~Thunderbi@cpc66866-finc15-2-0-cust47.4-2.cable.virginm.net] has quit [Quit: DCW]
20141107 13:30:23-!- cib0 [~cib@132.231.178.130] has joined #wesnoth-dev
20141107 13:38:06-!- Coffee_irc [~david@ppp118-210-90-49.lns20.adl2.internode.on.net] has quit [Quit: Konversation terminated!]
20141107 13:38:07-!- kex [~kex@77.28.4.239] has quit [Remote host closed the connection]
20141107 13:40:16-!- kex [~kex@77.28.4.239] has joined #wesnoth-dev
20141107 13:56:45-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Ping timeout: 265 seconds]
20141107 13:56:55-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20141107 13:57:03-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Computer's napping]
20141107 14:09:06-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20141107 14:27:43-!- DCW [~Thunderbi@cpc66866-finc15-2-0-cust47.4-2.cable.virginm.net] has joined #wesnoth-dev
20141107 14:43:06-!- Crendgrim_ [~crend@wesnoth/forum-moderator/crendgrim] has joined #wesnoth-dev
20141107 14:43:50-!- Crendgrim [~crend@wesnoth/forum-moderator/crendgrim] has quit [Read error: Connection reset by peer]
20141107 14:55:14-!- kex [~kex@77.28.4.239] has quit [Remote host closed the connection]
20141107 14:57:41-!- kex [~kex@77.28.4.239] has joined #wesnoth-dev
20141107 15:02:22-!- kex [~kex@77.28.4.239] has quit [Ping timeout: 255 seconds]
20141107 15:06:30-!- Crendgrim_ is now known as Crendgrim
20141107 15:10:10-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Computer's napping]
20141107 15:18:35-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141107 15:24:11-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141107 15:25:28-!- Elvish_Hunter [9710d9e8@gateway/web/freenode/ip.151.16.217.232] has joined #wesnoth-dev
20141107 15:25:50< Elvish_Hunter> Hi all
20141107 15:26:25-!- irker276 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20141107 15:26:25< irker276> wesnoth: Elvish_Hunter wesnoth:1.12 055913194195 / data/tools/GUI.pyw: wml tools GUI: backported all improvements and bugfixes from master http://git.io/g4jyAw
20141107 15:26:25< irker276> wesnoth: Elvish_Hunter wesnoth:1.12 40f73c8c57d0 / changelog src/unit_display.cpp: [animate_unit]: backported fix for death and victory animations from master http://git.io/OkGbuA
20141107 15:31:39-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20141107 15:32:36-!- kex [~kex@77.28.4.239] has joined #wesnoth-dev
20141107 15:33:08< vultraz> hello Elvish_Hunter 
20141107 15:33:22< Elvish_Hunter> Hi vultraz!
20141107 15:33:48< Elvish_Hunter> Finally I backported the wml tools GUI improvements to the stable series!
20141107 15:34:24< vultraz> Does it include any fixes for the Browse function?
20141107 15:35:31< Elvish_Hunter> The Browse function will fix itself when we'll switch to the 1.12 version number.
20141107 15:36:08< vultraz> Oh
20141107 15:36:33< Elvish_Hunter> The explanation is at line 41: the constant is WESNOTH_SERIES="1.13" on 1.13 and "1.12" on 1.12.
20141107 15:36:54< Elvish_Hunter> There was no point in fixing it for a series number that is soon to be abandoned.
20141107 15:37:03< vultraz> Right
20141107 15:37:08< Elvish_Hunter> With this, I mean for the 1.11 series.
20141107 15:37:37< Elvish_Hunter> However, I had no luck in adding the tooltips - at least for now :-(
20141107 15:38:22< vultraz> Looking to the final RC today/tomorrow and then the final 1.12 release next week
20141107 15:39:24< Elvish_Hunter> Good, good. I'll relay the news on the Italian forum as well.
20141107 15:40:04-!- DCW [~Thunderbi@cpc66866-finc15-2-0-cust47.4-2.cable.virginm.net] has quit [Remote host closed the connection]
20141107 15:42:12< vultraz> http://wesnoth.org/start/1.12/ if you want to see the announcement.
20141107 15:44:20-!- oldlaptop [~quassel@50-108-67-218.adr01.mskg.mi.frontiernet.net] has quit [Remote host closed the connection]
20141107 15:44:40< vultraz> GUI.pyw is mentioned down near the bottom
20141107 15:45:40-!- Elvish_Hunter [9710d9e8@gateway/web/freenode/ip.151.16.217.232] has quit [Ping timeout: 246 seconds]
20141107 15:47:10-!- Elvish_Hunter [9710d9e8@gateway/web/freenode/ip.151.16.217.232] has joined #wesnoth-dev
20141107 15:48:38< Elvish_Hunter> Nice announcement! Not only for the mention of GUI.pyw, but also because of its look.
20141107 15:49:06< Elvish_Hunter> Now it resembles mor a modern looking website, with webfonts and rounded corners.
20141107 15:49:57< Elvish_Hunter> *more, not mor
20141107 15:50:08< mattsc> Elvish_Hunter: hi.  Indeed - vultraz, shadowm and a few others put a lot of effort into it.
20141107 15:51:02< Elvish_Hunter> Yes, and I'm sorry that I couldn't have been part of this effort, due to time issues.
20141107 15:51:04-!- cib0 [~cib@132.231.178.130] has quit [Ping timeout: 245 seconds]
20141107 15:51:24< vultraz> Just a good thing you got your fixes backported
20141107 15:51:56< Elvish_Hunter> However, there is one possible improvement that may be done: use a CSS animation to change the header image every, say, ten seconds.
20141107 15:52:53< Elvish_Hunter> But I'm aware that such modification will put more strain on the servers and require more bandwidth.
20141107 15:53:01< vultraz> Not really feasible. It would require a lot of bandwidth
20141107 15:54:44< vultraz> Plus given the length of the thing, it would get kinda repetitive starting at the same few pics going past :P
20141107 15:55:24< Elvish_Hunter> Or maybe, we can replace the "Download Now" button with three buttons: one for Windows, one for Mac and one for Linux/source code.
20141107 15:56:36< vultraz> If you clicked it, you'll noticed it just scrolls down to the Downloads section, which has those links.
20141107 15:57:07< vultraz> Said section also has bunch of other useful info
20141107 15:59:53< Elvish_Hunter> Yes, I noticed. I was thinking of three buttons with the direct links, instead of moving to another section.
20141107 16:00:49< Elvish_Hunter> Oh well, I'll try editing the page and see what happens. Should I like the result, I'll let you know, OK?
20141107 16:01:33< vultraz> Any edit suggestions would have to be non-textual; we already string-froze it a few weeks ago.
20141107 16:01:58< vultraz> er, non-text-related*
20141107 16:04:53< Elvish_Hunter> OK, I'll keep that in mind.
20141107 16:08:32-!- gfgtdf [~chatzilla@e177145093.adsl.alicedsl.de] has joined #wesnoth-dev
20141107 16:09:02-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141107 16:17:09-!- kex [~kex@77.28.4.239] has quit [Remote host closed the connection]
20141107 16:17:23-!- EdB [~edb@89-158-11-138.rev.numericable.fr] has quit [Quit: Konversation terminated!]
20141107 16:43:11< Elvish_Hunter> Well, now I have to go. Bye!
20141107 16:43:16-!- Elvish_Hunter [9710d9e8@gateway/web/freenode/ip.151.16.217.232] has quit [Quit: Ciao!]
20141107 16:44:54-!- DHost [~Pcy@vps.ponchy.fr] has quit [Ping timeout: 258 seconds]
20141107 16:52:09< gfgtdf> iceiceice: about https://github.com/wesnoth/wesnoth/pull/328 with wich wml can a scenario add new wml ?
20141107 16:52:19< gfgtdf> new terrains*
20141107 16:52:49< iceiceice> gfgtdf: i thoguht a scenario cannot do that
20141107 16:53:17< gfgtdf> iceiceice: you said "which is that when a scenario introduces a new terrain type by merging" ...
20141107 16:53:28< iceiceice> oh
20141107 16:53:51< gfgtdf> iceiceice: ok maybe i just dotn knwo what meged errains ar
20141107 16:53:59< iceiceice> these "merge terrains"
20141107 16:54:09< iceiceice> i don't really know what it is for sure tbh,
20141107 16:54:31< iceiceice> it looks like there is some code for this, if you change the terrain of a place where a village is,
20141107 16:54:46< iceiceice> even if the village + X terrain is not defined, the game will try to figure it out or something
20141107 16:55:01< iceiceice> idk i want to ask fabi about this actually
20141107 16:55:13< gfgtdf> iceiceice: ok
20141107 16:56:41-!- kex [~kex@77.28.4.239] has joined #wesnoth-dev
20141107 16:56:54< iceiceice> gfgtdf: hmm i thnk maybe what i said isn't it,
20141107 16:57:11< iceiceice> i think that you only define "basic" terrain types, when you make new terrain types
20141107 16:57:31< iceiceice> and you make the rules how they can be combined as base and overlay, what is supposed to happen
20141107 16:57:45< iceiceice> but when the game reads a combination terrain in the map, it adds a new entry to its database
20141107 16:58:16< iceiceice> i think that's what try merge terrain does
20141107 16:58:53< iceiceice> so in current code, whenever you load a map you get the gameconfig, scan it entirely for terrains, process those,
20141107 16:59:03< iceiceice> then process the map and all the merged terrain entries
20141107 16:59:13< iceiceice> what i want to do in the commit is,
20141107 16:59:20< iceiceice> keep a global terrain data data base
20141107 16:59:28< iceiceice> only throw it out when you change game configs
20141107 16:59:42< iceiceice> and carry over the merged terrain records from each scenario to the next
20141107 17:00:31-!- cib0 [~cib@p5DD215E3.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141107 17:02:38< gfgtdf> iceiceice: i wanted to know your opinion on https://github.com/wesnoth/wesnoth/pull/321. The problem with the new way to determine whether a side is local, is that if we rejoin a game, the game might think that a side is locally contrlled during the "rejoin replay" because the client ids match. Ofc i could add a "never consider a side local during a 'rejoin replay'" code, but idk wher i...
20141107 17:02:40< gfgtdf> ...should do that since the main point of that patch was to simplyfy that code.
20141107 17:04:28< iceiceice> gfgtdf: i guess this was also an old bug
20141107 17:04:45< iceiceice> that if you quit a game and later rejoin it as an observer, your client gets confused and goes out of sync
20141107 17:04:54< iceiceice> because the name matches
20141107 17:04:59< gfgtdf> iceiceice: old = when ?
20141107 17:05:03< iceiceice> very old
20141107 17:05:11< gfgtdf> iceiceice: was it fixed ?
20141107 17:05:14< iceiceice> yes
20141107 17:05:59< iceiceice> gfgtdf: it might be that its good for the server to tell everyone exactly what sides they should be having
20141107 17:06:17< iceiceice> because then all the decisions are made in one place
20141107 17:06:32< iceiceice> idk just thinking
20141107 17:06:32-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 245 seconds]
20141107 17:07:05< iceiceice> we could ask Soliton
20141107 17:07:23< iceiceice> gfgtdf: also i guess i would thik that,
20141107 17:07:28-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20141107 17:07:40< iceiceice> if the game is doing rejoin replay, so it means it has replay moves for a side,
20141107 17:07:48< iceiceice> i think it should lock out the player from making input
20141107 17:07:55< iceiceice> until theres no more replay moves
20141107 17:08:21< iceiceice> is the issue about synchronization?
20141107 17:08:24< gfgtdf> iceiceice: what do you men by 'lock' and 'input' ?
20141107 17:08:31< gfgtdf> mean*
20141107 17:08:41< iceiceice> when you write thsi "the game might think that a side is locally contrlled during the "rejoin replay" because the client ids match."
20141107 17:08:45< iceiceice> what are you concerned of
20141107 17:08:54< gfgtdf> iceiceice: especaiyl, do you include "chat" in "input" ?
20141107 17:08:56< iceiceice> that the game will stop and wait for input?
20141107 17:09:32< gfgtdf> iceiceice: no tht teh cleint assumes teh cise is laooly contrlled and allows tah pleays to do things leik move units
20141107 17:09:42< gfgtdf> the side*
20141107 17:10:04< gfgtdf> s/laooly/locally, s/leik/like
20141107 17:10:34< iceiceice> gfgtdf: why can they do this?
20141107 17:10:45< iceiceice> if there are still [replay] commands to execute
20141107 17:11:11-!- DHost [~Pcy@vps.ponchy.fr] has joined #wesnoth-dev
20141107 17:12:13< iceiceice> gfgtdf: i think it might be good to have a "bool local_control_" in class team
20141107 17:12:33< iceiceice> and not try to deduce it from the name
20141107 17:13:00< iceiceice> because if it is based on the name then all these corner cases will be a lot harder, where players are joining and rejoining and have different status observer vs player etc.
20141107 17:13:10< gfgtdf> iceiceice: currently we do it ba checking controller == "network" || "network_ai"
20141107 17:13:14< iceiceice> yeah
20141107 17:13:33< gfgtdf> iceiceice: actuayl i think that'll be teh onyl conerner case
20141107 17:14:10< iceiceice> yeah but how will you solve it without getting info from the server
20141107 17:14:12< iceiceice> and remembering igt
20141107 17:14:17< iceiceice> *it
20141107 17:16:12< gfgtdf> iceiceice: actualy what was the reason for: https://github.com/wesnoth/wesnoth/commit/8e5572a239eb0b24e37135cc7825d7462599295c ?
20141107 17:17:16< iceiceice> it's much simpler
20141107 17:17:45< iceiceice> the old way, whenever side controls were changed, the server would rewrite the past
20141107 17:17:50< iceiceice> and pretend that side always controlled it
20141107 17:18:29< iceiceice> if you don't do this it's not possible for an observer to watch the replay and actually follow the game controller changes
20141107 17:18:59< gfgtdf> iceiceice: and why is taht simpler? esp, why should it be importatn who controlled a side in teh past ?
20141107 17:19:28< iceiceice> well for one thing you need to know if its human vs ai
20141107 17:19:37< iceiceice> so that you have the accurate representation when you catch up
20141107 17:19:43< iceiceice> or you will get OOS, which can happen in 1.10
20141107 17:21:01< iceiceice> gfgtdf: it means that if you use "side.controller", it won't automatically break in mp
20141107 17:21:04-!- prkc [~prkc@catv-89-134-173-244.catv.broadband.hu] has quit [Read error: Connection reset by peer]
20141107 17:21:12< iceiceice> if you dont have these records, then side.controller has a random value
20141107 17:21:15< iceiceice> hwen an observer joins the game
20141107 17:21:25< gfgtdf> iceiceice: hm ok, but is it also important which client controlled a side in teh past ?
20141107 17:21:33< iceiceice> if you want to watch the replay,
20141107 17:21:36< iceiceice> and the replay looks at side.controller,
20141107 17:21:37< iceiceice> then yes
20141107 17:22:23< gfgtdf> iceiceice: side.controller doesnt tell me whether iceiceice or gfgtdf controlled a side.
20141107 17:22:58< iceiceice> yeah but you can't even figure out if its human or ai
20141107 17:23:03< iceiceice> without these records
20141107 17:23:30< iceiceice> if sides are being droided and undroided, then in 1.10 the server is rewriting the [replay_start] to reflect this
20141107 17:24:35< iceiceice> idk its clear to me that it's much more complicated
20141107 17:24:49< gfgtdf> iceiceice: on of the main points o teh patch is to split the "human vs ai" from that "iceiceice vs gfgtdf" information, so i can soter store "human vs ai"  in teh records and "iceiceice vs gfgtdf" in the level_ .
20141107 17:24:53< iceiceice> and any time you look at a server replay, if you care about the controller types you would have to keep this behaviro in mind
20141107 17:24:59< gfgtdf> of the pr
20141107 17:26:33< iceiceice> gfgtdf: what is gained by rewriting the history?
20141107 17:26:49-!- DHost [~Pcy@vps.ponchy.fr] has quit [Quit: leaving]
20141107 17:27:02-!- DHost [~Pcy@vps.ponchy.fr] has joined #wesnoth-dev
20141107 17:27:05< gfgtdf> iceiceice: that i dont have to to serverseided controller wteaks
20141107 17:27:31-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20141107 17:28:24< iceiceice> do you also care to keep the leader names in sync?
20141107 17:28:46< iceiceice> if you don't store records of "iceiceice took control..."
20141107 17:28:58< iceiceice> then the names of the leaders will be different when you watch the replay
20141107 17:30:24< iceiceice> gfgtdf: i think that actually,
20141107 17:30:36< iceiceice> the patch you have is taking the game back to how it was in wesnoth 1.8 or something
20141107 17:31:02< iceiceice> and the controller HUMAN, AI, NETWORK, NETWORK_AI, was introduced to fix problems
20141107 17:31:16< iceiceice> because, just because the name is the same as yours doesn't mean it should be you
20141107 17:31:22< iceiceice> it might be "a different gfgtdf"
20141107 17:31:25< iceiceice> or "past gfgtdf"
20141107 17:31:37< iceiceice> and the server is who can most easily figure that out
20141107 17:32:01< gfgtdf> iceiceice: the server doesnt allow multiple clients with the same name
20141107 17:32:36< gfgtdf> iceiceice: i'd be happy to knwo which problem were there in 1.8 
20141107 17:32:53-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141107 17:33:37< gfgtdf> iceiceice: also even 1.0 has teh "netowrk" controller type: https://github.com/wesnoth/wesnoth/blob/1.0/src/team.hpp#L87
20141107 17:33:51< gfgtdf> "network"
20141107 17:34:06< iceiceice> https://gna.org/bugs/?func=detailitem&item_id=17533
20141107 17:34:07< gfgtdf> iceiceice: so i dont take it back to 1.x
20141107 17:36:25< iceiceice> gfgtdf: i don't think there's any point to store things in level_,
20141107 17:36:36< iceiceice> it is much simpler if it is just a starting position
20141107 17:36:41< iceiceice> even for me, if i want to debug an mp problem
20141107 17:36:49< iceiceice> i would rather have the accurate history and the change records
20141107 17:37:19< iceiceice> i dont actually see how changing that helps to get rid of server controller tweaks
20141107 17:37:55< iceiceice> you also don't answer this: "do you also care to keep the leader names in sync?"
20141107 17:38:10< iceiceice> if you store accurate game state in the level_, and just store the change messages,
20141107 17:38:16< iceiceice> then each observer can reconstruct an accurate game state
20141107 17:38:51< iceiceice> if you start rewriting stuff, it is bound to introduce oos, even only in unusual cases where someone uses a unit's name in an important way
20141107 17:39:50< iceiceice> gfgtdf: i think you should ask soliton,
20141107 17:40:02< iceiceice> because he will know the actual history and old bugs better than me
20141107 17:40:11< iceiceice> i didn't look at any of the bug reports about it for like a year
20141107 17:40:34< iceiceice> i remember that in 1.10, all the tweaks were client side and not server side
20141107 17:40:42< iceiceice> actually there were multiple "tweaks" functions
20141107 17:40:49< iceiceice> some in playcampaign, some in play controller
20141107 17:41:10< iceiceice> and they had all this hacky code to compare team.name with preferences::login() etc. to figure out if i should take control
20141107 17:41:39< iceiceice> i wiped out and unified most of that, then soliton said he thought it should be all server side
20141107 17:41:48< iceiceice> so then i moved to server side
20141107 17:42:18< iceiceice> *also it woudl be doing different functions for io_type server, iotype client etc...
20141107 17:43:24< iceiceice> gfgtfd: idk in my opinion the server-sided code could be cleaned up more surely, but it's not really much more complicated to have this,
20141107 17:43:32< iceiceice> you will always have to support the server being able to change controllers
20141107 17:43:55< iceiceice> the "server-sided tweaks" function just calls that function sometimes at game starts, to make sure everything is synced up properly.
20141107 17:44:03< iceiceice> *some number of times
20141107 17:44:16-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20141107 17:47:29-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20141107 17:53:40-!- iwaim [~iwaim@2001:2c0:40e:2002:0:4:14:80] has joined #wesnoth-dev
20141107 17:56:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20141107 17:59:18< gfgtdf> iceiceice: i think i can handle the leader names thing, also i thin using names for non vuisual things is always a source of OOS just as for any other trnslatable string
20141107 18:00:15< iceiceice> gfgtdf: the names aren't translatable
20141107 18:00:21< iceiceice> they are player login names
20141107 18:00:33< gfgtdf> iceiceice: yes but normal unit names are
20141107 18:01:03< iceiceice> gfgtdf: i think its just ugly to rewrite the history, i still dont see how it helps anything
20141107 18:01:39< iceiceice> what is the problem you are trying to solve with this
20141107 18:02:26< gfgtdf> iceiceice: mainly im trying to get rid of "network_ai" and "network" controllers
20141107 18:02:43< iceiceice> why does rewriting the history help with that
20141107 18:06:42< gfgtdf> iceiceice: it helps me becasue otherwise i get back https://gna.org/bugs/?func=detailitem&item_id=17533
20141107 18:07:20< iceiceice> i think there's a better solution though
20141107 18:07:25< iceiceice> than rewriting the history
20141107 18:07:44< iceiceice> it sounds to me like there's a problem in the client-side logic,
20141107 18:08:14< iceiceice> if i still have messages in the [replay] queue,
20141107 18:08:23< iceiceice> it doesn't make sense that i would allow the player to start making moves
20141107 18:08:43< iceiceice> or take control, or do anything
20141107 18:08:46< iceiceice> until the replay is finished
20141107 18:09:24< iceiceice> because doing that is obviously going to create oos if new events get jammed into the history
20141107 18:09:42< gfgtdf> iceiceice: i dont see why
20141107 18:09:52< iceiceice> the clients should all have matching [replay] basically
20141107 18:09:57< gfgtdf> iceiceice: how*
20141107 18:10:09< iceiceice> it's not safe to add new events to the history until you are synced in time with the other clients
20141107 18:10:50< iceiceice> i never solved this issue, because the bug went away when we made the server tweaks
20141107 18:12:19< iceiceice> but there's clearly a bug in the "execute replay" code somewhere
20141107 18:16:07< iceiceice> gfgtdf: i don't remember all the different bugs that got solved by the server controller tweaks,
20141107 18:16:09< iceiceice> there were a few i think
20141107 18:16:14< iceiceice> it is probably in the changelog
20141107 18:16:33< iceiceice> it took me like a month or two to develop and test this.
20141107 18:17:00< iceiceice> i think you shouldn't merge #321 until we have some more rigorous testing, like if can make networked mp unit tests
20141107 18:17:19< gfgtdf> iceiceice: y networked unit tests woudl becool
20141107 18:17:41< iceiceice> yeah its too tedious to debug all this stuff by ahnd
20141107 18:21:06< iceiceice> i will be back later
20141107 18:21:07-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20141107 18:31:20-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has joined #wesnoth-dev
20141107 18:56:17-!- sachith500 [~kvirc@112.135.148.50] has quit [Ping timeout: 264 seconds]
20141107 19:05:49-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141107 19:10:55-!- lipkab [~the_new_l@host-91-147-211-128.biatv.hu] has quit [Quit: Sűrű sötét az éj, dühöng a déli szél]
20141107 19:17:28-!- kex [~kex@77.28.4.239] has quit [Remote host closed the connection]
20141107 19:21:20-!- kex [~kex@77.28.4.239] has joined #wesnoth-dev
20141107 19:28:38-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141107 19:29:42-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20141107 19:37:29-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20141107 19:49:08-!- prkc [~prkc@catv-89-134-173-244.catv.broadband.hu] has joined #wesnoth-dev
20141107 19:53:26-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Bye for now]
20141107 19:54:35-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141107 20:00:16-!- irker276 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20141107 20:19:17-!- Sulfur [~Miranda@p5B3279D5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141107 20:22:53-!- kex [~kex@77.28.4.239] has quit [Remote host closed the connection]
20141107 20:23:26-!- kex [~kex@77.28.4.239] has joined #wesnoth-dev
20141107 20:28:04-!- kex [~kex@77.28.4.239] has quit [Ping timeout: 260 seconds]
20141107 20:28:49-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: ancestral]
20141107 20:33:39-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141107 20:39:05-!- Coffee_irc [~david@ppp118-210-90-49.lns20.adl2.internode.on.net] has joined #wesnoth-dev
20141107 20:44:23-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141107 20:47:18-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20141107 20:53:27-!- duncan_shriek [~roland@2a01:1e8:e100:8618::24] has quit []
20141107 21:16:47-!- Sulfur [~Miranda@p5B3279D5.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20141107 21:19:44-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20141107 21:31:13-!- irker746 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20141107 21:31:13< irker746> wesnoth: Chris Beck wesnoth:master 2b388ab5b276 / src/ (3 files in 2 dirs): remove a useless argument in play_replay http://git.io/szzZqA
20141107 21:40:03-!- oldlaptop [~quassel@50-108-67-218.adr01.mskg.mi.frontiernet.net] has joined #wesnoth-dev
20141107 21:45:07-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Ping timeout: 255 seconds]
20141107 22:07:23-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20141107 22:18:00< irker746> wesnoth: Fabian Müller wesnoth:master c6e118f08487 / src/ (commandline_options.cpp commandline_options.hpp): Add the "core" command line option. http://git.io/Zm6w9A
20141107 22:18:02< irker746> wesnoth: Fabian Müller wesnoth:master 632ce4aa44bd / src/game_launcher.cpp: Set the core_id preferences item at game launch. http://git.io/fIxc1Q
20141107 22:18:04< irker746> wesnoth: Fabian Müller wesnoth:master 21484aa5bc89 / src/ (game_config.cpp game_config.hpp): Add no_addon item to the game_config:: namespace. http://git.io/-nQB3Q
20141107 22:18:06< irker746> wesnoth: Fabian Müller wesnoth:master 42c947517387 / src/game_config_manager.cpp: Load addons based on game_config::no_addons instead of command line. http://git.io/M1bA5g
20141107 22:18:08< irker746> wesnoth: Fabian Müller wesnoth:master d98240e4f6ce / src/ (preferences.cpp preferences.hpp wesnoth.cpp): Removed the core file path from the preferences. http://git.io/df44SQ
20141107 22:18:10< irker746> wesnoth: Fabian Müller wesnoth:master 7b073484cb53 / data/cores.cfg: Made the "broken" core less broken. http://git.io/87PH2A
20141107 22:18:12< irker746> wesnoth: Fabian Müller wesnoth:master 6f9ee7a82893 / src/game_config_manager.cpp: Redesigned the core loading procedure. http://git.io/P7fOug
20141107 22:27:41-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20141107 22:36:53-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20141107 22:37:18< irker746> wesnoth: Fabian Müller wesnoth:master 7fd093d7c0bb / src/game_launcher.cpp: Propagate the noaddons command line switch value to the game config. http://git.io/7dYDzw
20141107 22:37:26< iceiceice> fabi: i think this commit breaks the unit tests again
20141107 22:37:28< iceiceice> https://github.com/wesnoth/wesnoth/commit/42c947517387c53451c6a715b31e5c2ec2474531
20141107 22:37:32< iceiceice> oh
20141107 22:37:34-!- cib0 [~cib@p5DD215E3.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20141107 22:37:35< iceiceice> you fixed it just now ;)
20141107 22:37:49< fabi> hi iceiceice
20141107 22:38:00-!- cib0 [~cib@p5DD215E3.dip0.t-ipconnect.de] has joined #wesnoth-dev
20141107 22:38:06< iceiceice> hi
20141107 22:38:28< iceiceice> hmm actualy im not sure
20141107 22:38:49< iceiceice> because the unit test doesn't use a game_launcher object: https://github.com/wesnoth/wesnoth/blob/master/src/tests/test_mp_connect.cpp#L65
20141107 22:41:02-!- travis-ci [~travis-ci@ec2-54-160-207-63.compute-1.amazonaws.com] has joined #wesnoth-dev
20141107 22:41:03< travis-ci> wesnoth/wesnoth#4669 (master - 2b388ab : Chris Beck): The build was fixed.
20141107 22:41:03< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/40339154
20141107 22:41:03-!- travis-ci [~travis-ci@ec2-54-160-207-63.compute-1.amazonaws.com] has left #wesnoth-dev []
20141107 22:42:03< iceiceice> fabi what do you think about making it `		if (!game_config::no_addons && !cmdline_opts_.noaddons)
20141107 22:42:03< iceiceice> 			load_addons_cfg();
20141107 22:42:03< iceiceice> `
20141107 22:43:02-!- cib0 [~cib@p5DD215E3.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds]
20141107 22:46:23< fabi> iceiceice: I don't know. Every other command line is propagated to game::config in game_launcher.cpp. 
20141107 22:46:40< iceiceice> is that true?
20141107 22:46:53< iceiceice> mm i will read
20141107 22:47:02< fabi> Maybe not.
20141107 22:47:09< fabi> It just happens for a lot of them.
20141107 22:48:33< iceiceice> just path, debug, delay, sound, and now noaddons
20141107 22:48:57< iceiceice> idk in this case, i think if i pass --noaddons at command-line,
20141107 22:49:02< iceiceice> it means i definitely dont want any addons
20141107 22:49:22< iceiceice> so that if i run a unit test they will never get enabled somehow
20141107 22:49:57< iceiceice> does game_config get written back out by the game?
20141107 22:52:24< fabi> written back out?
20141107 22:52:43< fabi> only those values which are also in preferences if I understood correctly.
20141107 22:53:18< iceiceice> ok
20141107 22:56:23-!- gfgtdf_ [~chatzilla@f054170051.adsl.alicedsl.de] has joined #wesnoth-dev
20141107 22:56:55< fabi> iceiceice: Which unit tests are failing?
20141107 22:57:07< iceiceice> no, it makes them load the addons
20141107 22:57:08< iceiceice> and spam warnings
20141107 22:57:21< iceiceice> the c++ tests
20141107 22:57:24-!- zookeeper [zookeeper@wesnoth/developer/zookeeper] has quit [Ping timeout: 250 seconds]
20141107 22:57:33< iceiceice> they dont fail
20141107 22:58:26-!- gfgtdf [~chatzilla@e177145093.adsl.alicedsl.de] has quit [Ping timeout: 256 seconds]
20141107 22:58:33-!- gfgtdf_ is now known as gfgtdf
20141107 22:58:38< fabi> iceiceice: So there are several different things to do: 1) Change the merge terrain output from err to log. 2) Your proposed change around load_addons_cfg().
20141107 22:59:00< iceiceice> fabi: its not just a problem with the spam,
20141107 22:59:06< iceiceice> the tests should not run after loading addons at all
20141107 22:59:15< iceiceice> they should run in a clean environment
20141107 22:59:28< fabi> Yes. I got that.
20141107 22:59:45< iceiceice> it was fixed iwth this commit: https://github.com/wesnoth/wesnoth/commit/365001f86e517f9130c3eb6f50e3d1ac0d4e5f10
20141107 22:59:54< iceiceice> so (1) won't solve it
20141107 23:00:26< irker746> wesnoth: Chris Beck wesnoth:master d4c5930d6c62 / src/ (game_config_manager.cpp game_launcher.cpp): Don't ignore noaddons commandline opt in game_config_manager http://git.io/LzdNiA
20141107 23:02:11< iceiceice> idk or you could refactor thunderstrucks' unit test
20141107 23:02:15< iceiceice> but i dont see much point in that
20141107 23:03:48< iceiceice> fabi: i have a different question about merge terrain,
20141107 23:03:59< iceiceice> do you have a moment to answer?
20141107 23:04:09< fabi> yes
20141107 23:05:34< fabi> the floating point emulation unit test fails on my system.
20141107 23:06:08< fabi> iceiceice: Is the c++ unit test suite also running the new wml unit tests?
20141107 23:06:28< iceiceice> fabi: i reported the floating point emulation unit test failure on bug tracker
20141107 23:06:36< iceiceice> its a gcc 4.9 thing apparently
20141107 23:06:48< iceiceice> the c++ unit test suite is separate from the wml unit tests
20141107 23:06:58< iceiceice> the former is the ./test executable,
20141107 23:07:09< iceiceice> the latter is run with a shell script ./run_wml_tests
20141107 23:07:14< fabi> iceiceice: Wasn't travis also responsible for doing the unit tests?
20141107 23:07:23< iceiceice> yeah but travis uses gcc 4.8
20141107 23:08:16< iceiceice> fabi: i am trying to make a change to exactly when terrain data is loaded,
20141107 23:08:24< iceiceice> because there were bug reports that it takes 6 seconds to go to mp create window
20141107 23:08:32< iceiceice> even when they just go back from configure window
20141107 23:08:43< iceiceice> and it was profiled (not by me) to reveal that its during terrain reading from game config
20141107 23:09:01< iceiceice> i have a patch where i split up the terrain type parsing out of the gamemap class,
20141107 23:09:05< iceiceice> and put it in a subsidiary:
20141107 23:09:17< iceiceice> https://github.com/wesnoth/wesnoth/pull/328
20141107 23:09:55< iceiceice> in this version, the game config manager also keeps track of a pointer to the parsed terrain type data from the current game config
20141107 23:10:11< iceiceice> and maps are constructed from map + terrain type data, rather than map + game config
20141107 23:10:42< iceiceice> however i tried to make an optimization where, when the game map goes through and creates merged terrain types,
20141107 23:10:58< iceiceice> those get added to the global database for the whole game_config, and shared with other maps
20141107 23:11:05< iceiceice> rather than redoing that work with each map load
20141107 23:11:13< iceiceice> i want to ask you though, do you think that is safe?
20141107 23:11:19< iceiceice> or should each map make its own copy before doing that
20141107 23:12:06-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 265 seconds]
20141107 23:12:44< fabi> iceiceice: I am not sure that I understand everything.
20141107 23:14:13< iceiceice> fabi: ok let me try to explain a different way also:
20141107 23:14:26< iceiceice> basically there were reports that this line is very slow:
20141107 23:14:27< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/map.cpp#L175
20141107 23:14:57< iceiceice> and it's in the constructor gamemap... 
20141107 23:15:01< iceiceice> *of gamemap
20141107 23:15:52< iceiceice> basically i define a caching object "terrain_type_data" whose job is to run that function on the game config
20141107 23:16:05< iceiceice> https://github.com/wesnoth/wesnoth/pull/328/files#diff-bb6877c2dfcc63167f861c974be6e449R25
20141107 23:16:27< iceiceice> and pass pointers around to this guy
20141107 23:16:44< iceiceice> so that it is not redone for every gamemap
20141107 23:17:03< iceiceice> however, gamemaps also modify the data that results sometimes
20141107 23:17:18< iceiceice> for instance just after the constructor calls "read": https://github.com/wesnoth/wesnoth/blob/master/src/map.cpp#L190
20141107 23:17:19-!- kex [~kex@78.157.29.160] has joined #wesnoth-dev
20141107 23:17:47< iceiceice> and read calls "try_merge" https://github.com/wesnoth/wesnoth/blob/master/src/map.cpp#L266
20141107 23:18:21< iceiceice> i had to move the "try_merge_terrains" and "merge_terrains" functions to the caching object
20141107 23:18:43< iceiceice> what i am asking you now is, do you think it can break things if maps are sharing this stuff?
20141107 23:18:56< iceiceice> is it possible that merging terrains will result in one thing on one map, and another thing on another?
20141107 23:19:09< iceiceice> even if they are using the same game config and base terrain definitions/
20141107 23:24:00-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20141107 23:24:47-!- markus_ [~mjs-de@f048007246.adsl.alicedsl.de] has joined #wesnoth-dev
20141107 23:26:44-!- ancestral [~ancestral@71-34-14-121.mpls.qwest.net] has joined #wesnoth-dev
20141107 23:28:05-!- mjs-de [~mjs-de@g228032039.adsl.alicedsl.de] has quit [Ping timeout: 250 seconds]
20141107 23:29:16< fabi> iceiceice: Sorry, I honestly don't know.
20141107 23:30:39< iceiceice> ok, well i have read the code and i'm pretty sure it can't happen
20141107 23:30:48< iceiceice> so i think i will just commit and we will see if people report bugs
20141107 23:31:49< fabi> iceiceice: Have you considered that create_terrain_maps might be slow because it does io?
20141107 23:31:54< fabi> The output?
20141107 23:32:31< iceiceice> you mean the logging output?
20141107 23:32:38< fabi> yes
20141107 23:32:44< fabi> and the ERR 
20141107 23:33:00< iceiceice> hmm i guess i dont understand how the loggers work
20141107 23:33:11< iceiceice> they dont become a no op if the logger is off?
20141107 23:34:04< iceiceice> fabi: so even if the function itself can be sped up, in my playtests the caching also makes a big difference
20141107 23:34:30< fabi> Okay, let's see if it breaks anything...
20141107 23:35:08< iceiceice> fabi: i think you are right,
20141107 23:35:14< iceiceice> maybe we should move some of the logic into the header
20141107 23:35:18< iceiceice> so that it can be inlined
20141107 23:35:39< iceiceice> i think the compiler should be smart enough to make it a no op if you dont have log channel activated
20141107 23:35:44< fabi> Well, inlining does not magically make io fast.
20141107 23:35:54< iceiceice> no but the compiler should know that it doesnt need to generate all the output
20141107 23:35:55< fabi> io is slow because you need context switches
20141107 23:35:59< iceiceice> because it will just be thrown away
20141107 23:36:06< iceiceice> i think you are right right now,
20141107 23:36:10< iceiceice> like, if i have some line
20141107 23:36:24< iceiceice> DBG_NG << game_config.debug();
20141107 23:36:29-!- happygrue [~Laptop@wesnoth/developer/wintermute] has joined #wesnoth-dev
20141107 23:36:33< iceiceice> that will always force it to stringize the entire game config
20141107 23:36:37< iceiceice> even if no logging is in
20141107 23:36:39< iceiceice> *is on
20141107 23:37:00< iceiceice> ideally htat would expand to something like
20141107 23:37:27< iceiceice> if (serverity > ...) { std::cerr << game_config.debug(); }
20141107 23:37:54< iceiceice> but it think the way it works right now, it expands to
20141107 23:38:09< iceiceice> std::ostream temp = (some ostream from another compilation unit)
20141107 23:38:13< iceiceice> temp << game_config.debug()
20141107 23:38:42< iceiceice> so it always computes the logging stuff even if it could skip it
20141107 23:40:55< fabi> good catch
20141107 23:41:02< fabi> should be easy to fix
20141107 23:47:14< irker746> wesnoth: Fabian Müller wesnoth:master 2effae3f131f / src/terrain.cpp: Changed the output form err to log for merging terrain. http://git.io/iV0BGw
20141107 23:49:05< iceiceice> fabi: yeah i will try
20141107 23:51:12-!- travis-ci [~travis-ci@ec2-54-160-207-63.compute-1.amazonaws.com] has joined #wesnoth-dev
20141107 23:51:12< travis-ci> wesnoth/wesnoth#4671 (master - 6f9ee7a : Fabian Müller): The build was fixed.
20141107 23:51:13< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/40344168
20141107 23:51:13-!- travis-ci [~travis-ci@ec2-54-160-207-63.compute-1.amazonaws.com] has left #wesnoth-dev []
20141107 23:54:18-!- Anakonda [Anakonda@87-92-195-246.bb.dnainternet.fi] has quit [Read error: Connection reset by peer]
--- Log closed Sat Nov 08 00:00:31 2014