--- Log opened Tue Apr 22 00:00:00 2014
20140422 00:06:41-!- prophile [~alynn@oftn/member/prophile] has joined #wesnoth-dev
20140422 00:12:39-!- happygrue [~happygrue@2601:6:4380:7df:ddeb:febb:bdee:1c07] has joined #wesnoth-dev
20140422 00:12:39-!- happygrue [~happygrue@2601:6:4380:7df:ddeb:febb:bdee:1c07] has quit [Changing host]
20140422 00:12:39-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140422 00:13:15< mattsc> Ivanovic: the 1.11.3 OS X package is on SF as well
20140422 00:13:28< mattsc> *1.11.13  (grr)
20140422 00:16:03-!- irker520 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20140422 00:16:03< irker520> wesnoth: mattsc wesnoth:1.12 1d42a85e9542 / projectfiles/Xcode/ (3 files in 2 dirs): Xcode project update for 1.11.13 http://git.io/TmT48w
20140422 00:17:46-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140422 00:24:04-!- gfgtdf [~chatzilla@f054052202.adsl.alicedsl.de] has joined #wesnoth-dev
20140422 00:25:10< gfgtdf> is it currently possible to print miliseconds in logs?
20140422 00:25:35< gfgtdf> and if not is there any reason against implementing it (maybe commandline -optional) ?
20140422 00:26:36< gfgtdf> in wesnothlogs i mean, not in orclogs
20140422 00:26:42< gfgtdf> the stderr thing
20140422 00:36:01-!- markus_ [~mjs-de@p508C8047.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20140422 00:37:32< gfgtdf> also: how do we currently prevent static initialisation error on log ? (meaning other code using log.hpp during static initialisation)
20140422 00:41:02< shadowm> We moved to locally initializing log domains per object file to solve that, didn't we?
20140422 00:41:03< mattsc> shadowm: so after some more testing, when I do debug builds using the latest SDK (OS X 10.9 for me), I don’t get the problem with the missing sys/types.h.
20140422 00:41:05< mattsc> When I do release builds (10.4 SDKs for backward compatibilty), I get the error.  The SDKs haven’t changed though.  In fact, I copy them into Xcode as they don’t come by default any more, so it must be something else.
20140422 00:42:01< mattsc> Anyways, not asking for an answer from you, but that’s the reason why I hadn’t noticed this before.
20140422 00:43:25< shadowm> I'd be stumped if faced with a similar conundrum here, that's for sure.
20140422 00:44:04< shadowm> Oh wait, the SDK version varies.
20140422 00:44:43< gfgtdf> shadowm: but there are still static variables in log.cpp linr 50.
20140422 00:44:47< shadowm> Okay, then that's the cause. The exact reason? Most likely just that sys/types.h is included by another header file in one version and not the other.
20140422 00:46:04< mattsc> That would be my guess.  I’ll try to figure out how to fix this without having to add anything into any files in src/, but either way I have a workaround that lets me build the release packages for the time being.
20140422 00:55:21-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140422 01:08:42-!- Aishiko_laptop [~unknown@2606:a000:bcc1:2b00:226:5eff:fe65:125c] has quit [Ping timeout: 240 seconds]
20140422 01:09:42< gfgtdf> shadowm: does any1 here has a 1.11.13 (witout dev) version ?
20140422 01:09:52< gfgtdf> locally
20140422 01:10:08-!- sachith500 [~kvirc@112.134.138.241] has joined #wesnoth-dev
20140422 01:10:52< mattsc> gfgtdf: is this what you mean?  http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.11.13/
20140422 01:11:51< shadowm> You can fetch and checkout or archive tags too...
20140422 01:11:55< gfgtdf> mattsc: ye ty, i was already scared because the mp didnt work at all but i guess i just forgot to rebild the local mp server too.
20140422 01:12:07< gfgtdf> s/too/again
20140422 01:16:20< gfgtdf> shadowm: no it still doesn't work can anyone else  tell me whether  he has the  same probolem ?
20140422 01:21:47-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140422 01:23:42< gfgtdf> hm seems to work now  idk what i did before.
20140422 01:24:47-!- gfgtdf [~chatzilla@f054052202.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 28.0/20140314220517]]
20140422 01:29:19-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Quit: Ik ga weg]
20140422 01:39:41-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140422 01:44:15-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 252 seconds]
20140422 02:06:42-!- TC01 [~quassel@128.220.109.252] has joined #wesnoth-dev
20140422 02:11:34-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140422 02:12:15-!- Ivanovic_ [~ivanovic@frnk-4d016b49.pool.mediaWays.net] has joined #wesnoth-dev
20140422 02:15:22-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 245 seconds]
20140422 02:16:09-!- Ivanovic_ is now known as Ivanovic
20140422 02:16:37-!- vultraz [~chatzilla@124.109.10.167] has quit [Ping timeout: 245 seconds]
20140422 02:21:00-!- Sulfur [~Miranda@p5B327256.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140422 02:22:46-!- Ivanovic [~ivanovic@frnk-4d016b49.pool.mediaWays.net] has quit [Changing host]
20140422 02:22:46-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20140422 02:27:08-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140422 02:38:18-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Ping timeout: 240 seconds]
20140422 02:38:35< iceiceice> gfgtdf, Soliton: i am thinking that it might be a good idea to revert the server-side controller tweaks stuff on 1.12 branch
20140422 02:39:01< iceiceice> i think it does help to fix some minor bugs, but as we are finding out it also creates some bugs, and ther may also be more we dont know about
20140422 02:39:42< iceiceice> i'm not sure if theres actually a compelling reason for it to be on 1.12, any bug that it was fixing might be easier to just patch some other way for 1.12
20140422 02:42:14< iceiceice> let me know your thoughts if any on the matter
20140422 02:48:27-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140422 02:51:26-!- prophile [~alynn@oftn/member/prophile] has quit [Quit: The Game]
20140422 02:53:09-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 252 seconds]
20140422 02:53:26-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140422 03:01:07-!- sachith500 [~kvirc@112.134.138.241] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140422 03:15:07-!- Sulfur [~Miranda@p5B327256.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20140422 03:18:26-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 276 seconds]
20140422 03:19:57-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140422 04:06:50-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140422 04:14:29-!- sachith500 [~kvirc@112.134.89.9] has joined #wesnoth-dev
20140422 04:21:22-!- sachith500 [~kvirc@112.134.89.9] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140422 04:28:20-!- iwaim [~iwaim@2001:2c0:40e:2002:0:4:14:80] has quit [Quit: Tiarra 0.1+svn-39209: SIGTERM received; exit]
20140422 04:31:22-!- iwaim_ [~iwaim@2001:2c0:40e:2002:0:4:14:80] has joined #wesnoth-dev
20140422 04:33:25-!- vultraz_iOS [uid24821@gateway/web/irccloud.com/x-amkkcpruhgwuoppx] has joined #wesnoth-dev
20140422 04:42:09-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Remote host closed the connection]
20140422 05:01:17-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140422 05:09:14-!- iwaim_ [~iwaim@2001:2c0:40e:2002:0:4:14:80] has quit [Excess Flood]
20140422 05:09:38-!- iwaim_ [~iwaim@2001:2c0:40e:2002:0:4:14:80] has joined #wesnoth-dev
20140422 05:13:57-!- Aishiko [~Aishiko@cpe-065-191-176-226.nc.res.rr.com] has quit [Remote host closed the connection]
20140422 05:47:18-!- cib_ [~cib@p5DD2330A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140422 05:54:33-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140422 05:57:52-!- cib_ [~cib@p5DD2330A.dip0.t-ipconnect.de] has quit [Quit: Leaving]
20140422 05:58:15-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20140422 06:19:34-!- wesbot [~wesbot@wesnoth/bot/wesbot] has quit [Ping timeout: 250 seconds]
20140422 06:20:37-!- wesbot [~wesbot@wesnoth/bot/wesbot] has joined #wesnoth-dev
20140422 06:34:42-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20140422 06:38:03-!- Gallaecio_ [~quassel@84.120.115.132.dyn.user.ono.com] has quit [Remote host closed the connection]
20140422 06:52:23-!- boucman_work [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20140422 06:58:02-!- boucman_work [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20140422 07:05:55-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140422 07:06:47-!- boucman_work [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20140422 07:11:44-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140422 07:19:35-!- kex [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140422 07:27:48-!- mjs-de [~mjs-de@p508C8047.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140422 07:55:57-!- Octalot [~noct@27.74.208.46.dyn.plus.net] has joined #wesnoth-dev
20140422 07:56:41-!- vultraz [~chatzilla@124.109.10.167] has quit [Ping timeout: 264 seconds]
20140422 08:03:58-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 240 seconds]
20140422 08:07:45-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140422 08:15:52< Soliton> iceiceice: sounds reasonable, then we got enough time to work out any issues until 1.14.
20140422 08:16:06-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140422 08:37:14-!- Ardonik [~user@adsl-75-28-103-78.dsl.irvnca.sbcglobal.net] has quit [Ping timeout: 240 seconds]
20140422 08:40:45-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: i go nstuf kthxbai]
20140422 08:47:12-!- vultraz_iOS [uid24821@gateway/web/irccloud.com/x-amkkcpruhgwuoppx] has quit [Quit: Connection closed for inactivity]
20140422 08:49:49-!- Ardonik [~user@adsl-75-28-103-78.dsl.irvnca.sbcglobal.net] has joined #wesnoth-dev
20140422 09:00:48-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140422 09:05:36-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 265 seconds]
20140422 09:19:11-!- mjs-de [~mjs-de@p508C8047.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20140422 09:21:46-!- bagzie [~bag@85-76-132-6-nat.elisa-mobile.fi] has joined #wesnoth-dev
20140422 09:22:52-!- DCW [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginm.net] has joined #wesnoth-dev
20140422 09:26:22-!- Anakonda [Anakonda@88-148-200-195.bb.dnainternet.fi] has joined #wesnoth-dev
20140422 09:40:42-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20140422 09:42:04-!- irker520 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20140422 10:07:51-!- ejls_ [~ejls@ejls.fr] has joined #wesnoth-dev
20140422 10:08:07-!- ejls [~ejls@ejls.fr] has quit [Read error: Connection reset by peer]
20140422 10:14:01-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140422 10:30:35-!- c74d [~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766] has quit [Excess Flood]
20140422 10:34:10-!- c74d [~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766] has joined #wesnoth-dev
20140422 10:34:43-!- _8680_ [~8680@2002:4404:712c:0:c48f:8e8a:878a:127d] has quit [Ping timeout: 252 seconds]
20140422 10:35:39-!- _8680_ [~8680@2002:4404:712c:0:2559:304:61dc:5f94] has joined #wesnoth-dev
20140422 10:36:49-!- prophile [~alynn@oftn/member/prophile] has joined #wesnoth-dev
20140422 10:37:09-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20140422 10:37:36-!- DCW [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginm.net] has quit [Remote host closed the connection]
20140422 10:39:50-!- EdB [~edb@37.163.124.249] has joined #wesnoth-dev
20140422 10:41:28-!- prophile [~alynn@oftn/member/prophile] has quit [Client Quit]
20140422 10:42:45-!- Spoffy [~sailfish@host86-168-246-14.range86-168.btcentralplus.com] has joined #wesnoth-dev
20140422 10:42:45-!- Spoffy [~sailfish@host86-168-246-14.range86-168.btcentralplus.com] has quit [Client Quit]
20140422 10:43:31-!- Spoffy [~sailfish@host86-168-246-14.range86-168.btcentralplus.com] has joined #wesnoth-dev
20140422 10:48:34-!- prophile [~alynn@oftn/member/prophile] has joined #wesnoth-dev
20140422 10:48:58-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140422 10:50:27-!- ejls_ is now known as ejls
20140422 10:53:41-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 264 seconds]
20140422 10:54:17-!- cib [~cib@132.231.178.148] has joined #wesnoth-dev
20140422 10:54:41-!- cib is now known as Guest67335
20140422 11:01:19-!- fendrin_ [~fabi@91-67-44-108-dynip.superkabel.de] has quit [Remote host closed the connection]
20140422 11:02:50-!- fabi [~fabi@91-67-44-108-dynip.superkabel.de] has joined #wesnoth-dev
20140422 11:02:50-!- fabi [~fabi@91-67-44-108-dynip.superkabel.de] has quit [Changing host]
20140422 11:02:50-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20140422 11:04:08-!- prophile [~alynn@oftn/member/prophile] has quit [Quit: The Game]
20140422 11:09:44-!- prophile [~alynn@oftn/member/prophile] has joined #wesnoth-dev
20140422 11:20:09-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140422 11:24:44-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 255 seconds]
20140422 11:30:38-!- Guest67335 [~cib@132.231.178.148] has quit [Quit: Leaving]
20140422 11:43:54-!- mjs-de [~mjs-de@p508C8047.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140422 11:48:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140422 11:52:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140422 11:52:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20140422 11:53:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140422 11:57:14-!- bagzie [~bag@85-76-132-6-nat.elisa-mobile.fi] has quit [Ping timeout: 240 seconds]
20140422 11:59:17-!- EdB [~edb@37.163.124.249] has quit [Quit: Konversation terminated!]
20140422 11:59:39< AI0867> aquileia: changed and pushed (the SDL/ include thing)
20140422 12:02:29-!- bagzie [~bag@85-76-73-55-nat.elisa-mobile.fi] has joined #wesnoth-dev
20140422 12:10:28-!- boucman_work [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20140422 12:13:22-!- boucman_work [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20140422 12:20:10-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140422 12:20:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 265 seconds]
20140422 12:21:49-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Quit: Konversation terminated!]
20140422 12:23:12-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20140422 12:28:03-!- happygrue [~happygrue@2601:6:4380:7df:2c2a:560c:fcad:f710] has joined #wesnoth-dev
20140422 12:28:03-!- happygrue [~happygrue@2601:6:4380:7df:2c2a:560c:fcad:f710] has quit [Changing host]
20140422 12:28:03-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140422 12:31:47-!- Spoffy [~sailfish@host86-168-246-14.range86-168.btcentralplus.com] has quit [Ping timeout: 252 seconds]
20140422 12:32:58-!- stikonas_ is now known as stikonas
20140422 12:35:50-!- Spoffy [~sailfish@host86-168-246-14.range86-168.btcentralplus.com] has joined #wesnoth-dev
20140422 12:42:29-!- cib [~cib@132.231.178.196] has joined #wesnoth-dev
20140422 12:42:53-!- cib is now known as Guest46218
20140422 12:51:12-!- prophile [~alynn@oftn/member/prophile] has quit [Quit: The Game]
20140422 12:53:17-!- prophile [~alynn@oftn/member/prophile] has joined #wesnoth-dev
20140422 12:53:19-!- spoffy_ [~spoffy@host86-168-246-14.range86-168.btcentralplus.com] has joined #wesnoth-dev
20140422 12:54:24-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Quit: Konversation terminated!]
20140422 12:54:52-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Read error: Connection reset by peer]
20140422 12:55:36-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20140422 12:57:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140422 13:01:44-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140422 13:06:38-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has joined #wesnoth-dev
20140422 13:07:30-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140422 13:48:31-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Computer's napping]
20140422 13:56:47-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140422 13:59:05-!- Guest46218 [~cib@132.231.178.196] has quit [Ping timeout: 264 seconds]
20140422 14:00:31-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140422 14:17:10-!- Dugi [93fbd156@gateway/web/freenode/ip.147.251.209.86] has joined #wesnoth-dev
20140422 14:23:46-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Computer's napping]
20140422 14:42:04-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has quit [Quit: leaving]
20140422 14:44:03-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140422 14:51:33-!- mjs-de [~mjs-de@p508C8047.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20140422 14:59:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140422 14:59:26-!- cib [~cib@p5DD22284.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140422 14:59:50-!- cib is now known as Guest56175
20140422 14:59:55-!- Spoffy [~sailfish@host86-168-246-14.range86-168.btcentralplus.com] has quit [Ping timeout: 252 seconds]
20140422 15:03:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140422 15:07:45< mattsc> gfgtdf (and maybe iceiceice): I just tripped an assert in my AI test suite trying to execute a move from a right-click menu option.
20140422 15:07:53< mattsc> Assertion failed: (synced_context::get_syced_state() == synced_context::UNSYNCED), function init, file /mats/misc/Wesnoth/wesnoth/src/synced_context.cpp, line 301.
20140422 15:08:09< mattsc> It happens with master and 1.11.13, but not 1.11.12.
20140422 15:09:37< mattsc> If this is something you’re working on already, I can wait.  I don’t need the latest version for my tests at the moment, and I have not been following your discussions in enough detail to know if this has been discussed.
20140422 15:10:16< mattsc> As a minor aside, I assume you know that get_syced_state() is misspelled?
20140422 15:14:52-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140422 15:17:02-!- gfgtdf [~chatzilla@f054052202.adsl.alicedsl.de] has joined #wesnoth-dev
20140422 15:18:20< gfgtdf> mattsc: no i dint know get_syced_state is misspelled, alos can you give me a stacktace of this bug ?
20140422 15:19:23< mattsc> gfgtdf: Umm, I can try to remember how to do that (haven’t done it in ages).
20140422 15:19:53< gfgtdf> mattsc: also i dont know how rightg clicks menus can be involved with in ai things, i tought right chick menus are only availyble durign human turns
20140422 15:20:29-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140422 15:20:43< mattsc> gfgtdf: I’m not using them in an AI turn.  The process how it works is this:
20140422 15:21:52< gfgtdf> mattsc: what do you think is a better spelling for get_syced_state?
20140422 15:22:08< mattsc> gfgtdf: add the missing ’n’ ?
20140422 15:22:19< gfgtdf> ah yes now i see :)
20140422 15:22:30< mattsc> :)
20140422 15:22:36< mattsc> I have a test scenario in which two AI sides play each other.  At some point, I see a bad move, droid one of the sides to human control, and save a replay.  I play the replay to the beginning of the turn with the bad move and ave the game.
20140422 15:23:18< mattsc> The I load that saved game (in debug mode with a falg set to ‘true’ in one of the Lua files, which changes the side to human control and sets up the menu options.
20140422 15:23:49< mattsc> The right click menu option then allow selective calling to the AI evaluation and execution functions.
20140422 15:24:53< mattsc> It’s a somewhat complicated process to set up, but it’s essential to efficient testing of the grunt rush AIs.
20140422 15:24:56-!- Kevin_Xi [~kevin@223.72.182.158] has joined #wesnoth-dev
20140422 15:27:05< Kevin_Xi> Ivanovic: Hi, my proposal of AI has been accepted, may I ask for push access?
20140422 15:27:20< gfgtdf> what type of dialog to you use to choose the the action ?
20140422 15:27:41< gfgtdf> a wml [message][option] or something different ?
20140422 15:27:43-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140422 15:28:54< gfgtdf> mattsc: ^
20140422 15:29:05< mattsc> There’s no dialog.  The CA is set by another menu option (although there’s really just one that is of interest in this case) and you then have different options for either just evaluation or eval+exec.
20140422 15:29:51< gfgtdf> mattsc: you youdon't use wmls [set_menu_item] ?
20140422 15:31:59< mattsc> gfgtdf: yes, I do, but there’s no dialog triggered by any of the menu options:  http://imagebin.org/306993
20140422 15:32:59< mattsc> gfgtdf: https://github.com/mattsc/AI-demos/blob/master/lua/eval_exec_CA.lua#L46
20140422 15:34:19< gfgtdf> mattsc: and how do you ensure replay saveness ?  i mean it seems like you are executing lua decision-taking during teh wmlmenauitems [command].
20140422 15:34:23< mattsc> gfgtdf: and just to make sure there isn’t a misunderstanding, this is nothing new.  I’ve been using this through many versions, through 1.11.12 it has always worked.
20140422 15:34:50< gfgtdf> mattsc: but wa sit replay save in previous  versions ?
20140422 15:34:53< gfgtdf> was it
20140422 15:35:41< mattsc> gfgtdf: It doesn’t have to be.  I don’t care.  I save the replay to get to a certain situation, then I test things for that turn to see what causes the problem and to be able to play with changed eval/exec functions.
20140422 15:35:58< mattsc> It’s a test/debug suite only.
20140422 15:37:51< gfgtdf> mattsc: the intention of the previous patch was to make most things replaysave,  guess i just didnt thought of somethings like this to be intented because it wasn't replaysave. Which doesnt mean it's impossible to make it posssible
20140422 15:38:42< mattsc> But that aside, why would this not be replay safe (assuming that the Lua files don’t get changed, of course)?
20140422 15:40:22< gfgtdf> mattsc: because the move_unit, .. attack_unit could try to save things in the replay, resulting is those get executed twice in a replay
20140422 15:42:12< gfgtdf> becasue in the replay it could be executed twice, once during the excution of the click_menu_item and one curing teh execution of attack_unit
20140422 15:42:13-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Read error: Connection reset by peer]
20140422 15:42:30-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20140422 15:42:49< mattsc> Hmmm, okay, but that’s always an option isn’t it.  For example, I can do all kinds of completely unsafe stuff from within the AI in Lua.  It’s up to the AI coder to make sure that doesn’t happen.
20140422 15:43:03< mattsc> This is an honest question, not an argument.  I might be missing something.
20140422 15:43:26< gfgtdf> mattsc: your you can do unsave stulff in lua even without at code
20140422 15:43:32< gfgtdf> ai code*
20140422 15:43:36< mattsc> right
20140422 15:43:37< gfgtdf> or in wml
20140422 15:44:05< gfgtdf> but you cannot invoke the  attack_unit, or move_unit fuction without ai code
20140422 15:44:09< gfgtdf> function*
20140422 15:47:12< mattsc> gfgtdf: ok - well, in either case, it’s essential for the AI development that I am doing that something like this is possible.  I don’t really care if I need to change things a little, but I spent a lot of effort setting up this testing suite, I’d really prefer not having to rewrite it entirely.
20140422 15:48:48-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: i go nstuf kthxbai]
20140422 15:48:49< gfgtdf> mattsc: hm ye maybe i can just change it with ~20 line sof code in sycned_context.cpp by callng a function like 'run_in_synced_context_if_not_already' instead of 'run_in_synced_conext' in ai code
20140422 15:48:54< gfgtdf> of*
20140422 15:49:52< mattsc> gfgtdf: okay - I really haven’t followed exactly what/how you are doing this, so I can’t comment.
20140422 15:50:45< mattsc> gfgtdf: btw, this might or might not have anything to do with this (I am not using it here), but do you know that there is an ai.synced_command() function executing Lua code in a replay-safe way?
20140422 15:51:10< mattsc> Just pointing that out in case it causes problems with this too, as it is used in at least a couple places in mainline.
20140422 15:51:12< gfgtdf> i thought that exaclty what ai.sycned command does ?
20140422 15:51:26< gfgtdf> that's
20140422 15:52:08< mattsc> Ah, yes, I think that’s it.  Okay, sorry, as I said, I haven’t really followed what you are doing and what this is all about.
20140422 15:52:09< gfgtdf> 	mattsc: just like with move and other action you currently (1.11.13) cannot usign whle execution another sanced action like wml emnu items
20140422 15:53:01< mattsc> What?  (I don’t mean the typos, I cannot parse the sentence)
20140422 15:53:56< gfgtdf> when you are execution a snced action which are for example move, atack, menu_item, recruit, ai.synced_command ...
20140422 15:54:04< gfgtdf> then you cannot invoke another sanced action
20140422 15:54:09< gfgtdf> ayned action
20140422 15:54:12< gfgtdf> synced
20140422 15:54:37< mattsc> Oh, you mean from within those?  Okay, missed that connection.  Yes.
20140422 15:54:47< gfgtdf> yes
20140422 15:54:55-!- Kevin_Xi [~kevin@223.72.182.158] has quit [Quit: Zzz.]
20140422 15:55:37< mattsc> gfgtdf: anyways, I have to do some (non-Wesnoth) work now.  I’ll be online and can reply to questions, but won’t have time for discussions or testing for the next … some hours.
20140422 15:56:01< mattsc> I hate it when real life interferes with my fantasy world!  :P
20140422 15:59:27-!- happygrue [~happygrue@2601:6:4380:7df:5157:1fbe:9a4d:ed34] has joined #wesnoth-dev
20140422 15:59:27-!- happygrue [~happygrue@2601:6:4380:7df:5157:1fbe:9a4d:ed34] has quit [Changing host]
20140422 15:59:27-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140422 15:59:29< mattsc> gfgtdf: to summarize, I’d really like this functionality back, but there’s no rush, I can do the testing with 1.11.12 for the time being.
20140422 16:00:16< mattsc> gfgtdf: and I also don’t really care how it is done, as long as it does not require me to rewrite everything completely (small changes are fine).  If this only worked with a special CL option, that’s fine too.
20140422 16:00:36< mattsc> There’s already an (unused AFAIK) —debug-ai flag that could be used for this.
20140422 16:04:11-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20140422 16:15:26-!- boucman_work [~rosen@wesnoth/developer/boucman] has quit [Ping timeout: 252 seconds]
20140422 16:17:41< gfgtdf> shadowm, Ivanovic: i want to add an optional 'show milliseconds in strerr output' for debugging, since its a feature and also contains string for the commandline option, it wont go into 1.12 like this. Is it okay if i add the underlaying code in a if(false){...}  into 1.12 so that one could only enable it hardcoded by hardcodting true insed of false, an and it will have no ffect for people...
20140422 16:17:43< gfgtdf> ...whi don't ?
20140422 16:18:07< gfgtdf> who dont cahnge it to true
20140422 16:20:25< Ivanovic> the string would still appear
20140422 16:20:36< Ivanovic> in the po files that is
20140422 16:28:35< gfgtdf> Ivanovic: no i would just add code in log.cpp in both and the code actionvaing it via commandline option just in 1.13, like commitign this to 1.12: https://github.com/gfgtdf/wesnoth-old/commit/16c8dc371316c95d0967cf505274f3de46b80e6c
20140422 16:28:48< gfgtdf> activating 
20140422 16:29:04< Ivanovic> gfgtdf: the gettext tools do not compile the program to find out which parts are active and which ones not
20140422 16:29:14< Ivanovic> so even code in dead paths will appear inside the po files
20140422 16:29:26< Ivanovic> that is: the strings in there marked as translateable
20140422 16:29:49< gfgtdf> but in te commit that i want in 1.12 (see above) doenst conatins trnsslatable string
20140422 16:30:16< gfgtdf> only the commit that uses it in commandline optiosn will contain translatable strings
20140422 16:30:19< gfgtdf> i used
20140422 16:30:26< gfgtdf> used it*
20140422 16:30:49< gfgtdf> Ivanovic: ^
20140422 16:31:38-!- Guest56175 [~cib@p5DD22284.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20140422 16:33:18-!- Gallaecio [~quassel@84.120.115.132.dyn.user.ono.com] has joined #wesnoth-dev
20140422 16:33:48-!- Sulfur [~Miranda@p5B0080A9.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140422 16:43:16-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20140422 16:47:47< mattsc> Coffee_irc: is the old animation syntax still going to work in 1.14?
20140422 16:51:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140422 16:56:31-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140422 17:05:45< iceiceice> gfgtdf: maybe you can use a preprocessor macro instead of if (false)? afaik that happens before gettext
20140422 17:05:57< iceiceice> s/that/the c preprocessor
20140422 17:06:33< shadowm> xgettext doesn't use the C preprocessor.
20140422 17:06:45< gfgtdf> iceiceice: um the commit im talking about is https://github.com/gfgtdf/wesnoth-old/commit/16c8dc371316c95d0967cf505274f3de46b80e6c, i dont see how trnslatable strins are effected by it
20140422 17:06:48< iceiceice> but also another thing you could do is, just take your commit and use "git format-patch" to make it a patch file, and just apply the patch whenever you want it
20140422 17:07:23< iceiceice> that way there isn't dead code in the release version
20140422 17:07:29< Ivanovic> iceiceice: the reason is not inside the application
20140422 17:07:34< Ivanovic> it is in tools which scan for strings
20140422 17:07:59< iceiceice> hmm i geuss i am confused then about how the internationalization process works
20140422 17:08:01< Ivanovic> *but*, as gfgtdf pointed out, the commit he wants to have in 1.12 would not affect the strings at all
20140422 17:08:08< iceiceice> ok i will reread
20140422 17:08:28< gfgtdf> the intention was to have 2 commits one implementing the precise log in log.cpp which does not taing strings, and one using it with commandline options, and my questions was wether i van out the first in 1.12
20140422 17:08:38< gfgtdf> can put*
20140422 17:09:14< gfgtdf> mattsc: do you know what stopunit_result/ execute_stopunit_action does?
20140422 17:10:25< mattsc> gfgtdf: well, on the Lua side, ai.stop_unit*()  [there are three total], take away moves, attacks or both
20140422 17:10:46< mattsc> Withut having time to look into this right now, my guess is that the Lua functions calls these.
20140422 17:10:58< gfgtdf> mattsc: hm and why should we allow this ? i means humman cannot so that why shoudl ai be able to do that ?
20140422 17:11:06< shadowm> iceiceice: Have you ever used `git log --format=oneline` or any other equivalent subject-only commit listing?
20140422 17:11:07< mattsc> Oh, there’s also ai.check_stopunit_*().
20140422 17:11:29< mattsc> gfgtdf: Umm, if you want a unit to not do anything, you need a way of removing moves and/or attacks.
20140422 17:11:42< mattsc> And that’s the synced way of doing it.
20140422 17:11:48< shadowm> Actually, my mistake, that question is for gfgtdf .
20140422 17:11:53< iceiceice> shadowm: no but is it relevant?
20140422 17:11:54< iceiceice> oh
20140422 17:11:59< gfgtdf> mattsc: hmm but in a scenario where you have a 'kill all units with  attaks left' attack that seems liek a cheat
20140422 17:12:31< gfgtdf> 	shadowm: yes  usualy use git log --oneline
20140422 17:13:02< gfgtdf> why do yoou ask ?
20140422 17:13:05< shadowm> How do you manage to read these "fix bug <N>" subjects and still know what you were talking about without checking the bug report in a web browser?
20140422 17:13:13< mattsc> gfgtdf: I don’t understand what you mean.
20140422 17:14:00< gfgtdf> 	shadowm: hm i have never been in a situaltion where i have git available but no web  browser.
20140422 17:14:24< shadowm> I don't want to use a web browser to understand what I'm reading in the commit log.
20140422 17:14:42< mattsc> gfgtdf: why would you have an attack like that?  At the next AI turn, all AI units will have attacks left again anyway.
20140422 17:14:58< shadowm> Summary lines are supposed to be a bit more descriptive than "fix bug <N>" and variations thereof.
20140422 17:15:36< shadowm> <https://github.com/wesnoth/wesnoth/commit/92822790715f2048fad18c6f21fad674b8eead3d> is a perfect example of a commit message where the order of information is backwards.
20140422 17:15:55-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140422 17:16:33< shadowm> Also, you and iceiceice both seem to have an aversion to English first-word sentence capitalization.
20140422 17:16:36< gfgtdf> mattsc: no it was just an example, i was more worried about wml code that might depend on unit.attacks_left might get confused
20140422 17:16:52< shadowm> And Ivanovic too.
20140422 17:17:46< mattsc> gfgtdf: ai.stop_unit_moves() is just like ai.move().  It’s an AI action to take (I could also just move the unit in a circle), and it is essential for the CA mechanism to work correctly.
20140422 17:18:07< iceiceice> shadowm: Yeah i guess that's just a bad habit, often happens when I write an email / chat message quickly
20140422 17:18:12< gfgtdf> mattsc: so it should be synced over teh replay/network i think just like moves ?
20140422 17:18:20< mattsc> gfgtdf: in fact, it is entirely equivalent to ai.move_full() to the location the unit is on already (except that the latter complains about the “empty move”)
20140422 17:18:29< mattsc> gfgtdf: it _is_ synced.
20140422 17:18:35< shadowm> Unfortunately, unlike IRC this stuff is archived permanently and for a lot of people to read at a later time.
20140422 17:18:43< mattsc> AFAIK
20140422 17:18:45< gfgtdf> mattsc: i you sure it's synced ?
20140422 17:18:56< mattsc> AFAIK
20140422 17:18:57< gfgtdf> dsynced commands usually add someting in the replay
20140422 17:18:57< shadowm> In particular, me, in order to know exactly what happened between 1.11.12 and 1.11.13 to be able to write an announcement.
20140422 17:19:00< gfgtdf> synced*
20140422 17:19:15< mattsc> And this does not?
20140422 17:19:30< gfgtdf> i didnt find code, but ofc i mjight have overseen something
20140422 17:19:52< iceiceice> Alright, 
20140422 17:20:08< mattsc> Hmm, I just always assumed that it was synced, but I guess I have never tested that.  So I might have to take back that statement.
20140422 17:20:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 276 seconds]
20140422 17:20:14< iceiceice> I'm not sure if it is realistic that I could start consistently capitalizing things in irc,
20140422 17:20:27< iceiceice> but i will make an effort to do so in commit messages
20140422 17:20:56< gfgtdf> mattsc: but usually the do_execute functions in ai/actions.cpp add something to the replay and i couldn't find it for stopunit_result
20140422 17:21:06< iceiceice> also fwiw i'm pretty sure i've made some commits that are like "fix bug N", although sometimes its also "fix blah blah, bug N"
20140422 17:21:29< iceiceice> or "fix blah (bug #n)"
20140422 17:21:54< mattsc> gfgtdf: okay, I stand corrected then.  But these are absolutely essential commands for the custom AIs to work, so we cannot remove them.  If something needs to be done, then the syncing needs to be added.
20140422 17:22:09< gfgtdf> hm ok
20140422 17:23:07< iceiceice> mattsc: do all the micro ai's use this?
20140422 17:23:17< iceiceice> like messenger for example?
20140422 17:23:24< mattsc> iceiceice: probably not all, but lots of them.
20140422 17:24:09< iceiceice> if messenger was using stuff that modified the game state but didnt record stuff in the replay,
20140422 17:24:30< iceiceice> then i would guess that some scenario like the UTBS one, you would not be able to successfully save replays of
20140422 17:25:05< mattsc> iceiceice: as far as I know, taking moves/attacks away counts as a change of gamestate.
20140422 17:25:31< iceiceice> yes
20140422 17:25:44< mattsc> iceiceice: oh, sorry, didn’t see the second part before I replied.
20140422 17:26:01< mattsc> iceiceice: no, not necessarily, I think.
20140422 17:26:17< mattsc> The replay records what was done, not why it was done.
20140422 17:26:48< mattsc> If a unit does not move, it doesn’t matter whether it did not move because it had no move, or because the AI chose not to move it for some other reason.
20140422 17:27:48-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has joined #wesnoth-dev
20140422 17:28:00< iceiceice> ok i think i understand now
20140422 17:28:12< mattsc> So gfgtdf is right.  If it does not get synced and you have some WML/Lua that makes a decision based on moves/attacks left of a unit on another side, it could cause OOS errors.
20140422 17:29:08< mattsc> I guess I always assumed that this gets synced, but TBH, I have no recollection what that assumption is based on.
20140422 17:30:02< gfgtdf> mattsc: i made a commit for the things you said earlier: https://github.com/gfgtdf/wesnoth-old/commit/395be4bf2adebbd389501382b248332fa930744d
20140422 17:30:25< gfgtdf> mattsc: is a 1.11.12+dev based commit, you can wait for tre travis to pass if you like
20140422 17:31:14< mattsc> gfgtdf: I have no time right now (and possibly today, don’t know yet) to test this anyway.  I’ve bookmarked it though.
20140422 17:31:27< mattsc> gfgtdf: 1.11.12+dev or 1.11.13+dev?
20140422 17:31:49< gfgtdf> ah i left get_rng_for_attack in the hpp file but it isnt used so it shouldn't casue problems.
20140422 17:32:42< gfgtdf> mattsc: uhm outting it onto 1.11.13 should work
20140422 17:32:47< gfgtdf> putting*
20140422 17:33:21< mattsc> gfgtdf: okay, I’ll try that - but as I said, that might not be until tomorrow.
20140422 17:33:30< gfgtdf> hm ok
20140422 17:37:32< shadowm> "You shouldn't undo moves done in a 1.11.12 save when you reload it in 1.11.13."
20140422 17:37:47< shadowm> What would happen in the event that the player didn't heed this warnigng?
20140422 17:37:53< shadowm> warning
20140422 17:38:34< gfgtdf> shadowm: i didnt test.
20140422 17:38:49< shadowm> What would you expect to happen, as a coder?
20140422 17:39:13< shadowm> OOS? Assertion check failure? Memory corruption? Segmentation fault?
20140422 17:39:40< shadowm> Or just nothing would happen? That'd be the best case scenario for the poor ignorant players.
20140422 17:40:17< gfgtdf> hm have to look at the code
20140422 17:40:33< shadowm> I thought this was part of your changes?
20140422 17:41:16< shadowm> I'm unsure how changes to the RNG infrastructure should affect undoing deterministic actions, in any case, but I'm just quoting R_N here.
20140422 17:41:17< gfgtdf> 	shadowm: that doesnt mean i know 100% of the code before the changes, without looking at the code
20140422 17:42:55< shadowm> Sure, but if you (or someone else?) added this note it means you (or someone else) knew why players shouldn't do that.
20140422 17:44:59< gfgtdf> shadowm: i think i maybe miswrote: you shoudnt redo an action.
20140422 17:47:14< shadowm> What would happen in that case?
20140422 17:49:03< gfgtdf> shadowm: you'll get corrupt  replays (but you'll get that anywa when you relaod a 1.11.12 save), and if there was a verycompicated moveto events you might get OOS error
20140422 17:49:23< gfgtdf> or a medium complicated
20140422 17:49:30< gfgtdf> undoable movetoevent ofc
20140422 17:51:05< shadowm> "[*]Using Undo/Redo with moves that were recorded in saved games from 1.11.12 and earlier will cause replay corruption and even result in [acronym=Out Of Sync]OOS[/acronym] errors under certain circumstances."
20140422 17:53:28< gfgtdf> shadowm: i think i already implied the first in: 'You can also load other saves from 1.11.12 but you wont get a valid replay then'
20140422 17:54:00< shadowm> Yes, but I rewrote that.
20140422 17:54:06< shadowm> http://pastebin.com/7NtharbH
20140422 17:56:01< gfgtdf> hm but it still implies that.
20140422 17:56:27< shadowm> The OOS should be expected during the game or during the generated replay? That makes the difference.
20140422 17:56:43< shadowm> I presume it's both.
20140422 17:59:11< gfgtdf> ye, but happening during the game should be rare, and when you'll waltch the replay you'll get a OOS much earlier before the position where the save was reloaded, because of above
20140422 17:59:37< shadowm> So it may happen mid-game but it's "rare".
20140422 18:00:12< shadowm> The frequency is irrelevant. What really matters is whether there's a possibility of it happening or not, so the warning stays.
20140422 18:02:00< gfgtdf> ye im ok with it, just the part 'cause replay corruption and' could be left out i think since the replay will already be currupt from reloading it.
20140422 18:02:53-!- Aishiko [~Aishiko@cpe-065-191-176-226.nc.res.rr.com] has joined #wesnoth-dev
20140422 18:08:05-!- ancestral [~ancestral@17.114.45.51] has joined #wesnoth-dev
20140422 18:11:29-!- kex [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140422 18:12:02-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140422 18:14:52-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140422 18:16:23-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 252 seconds]
20140422 18:21:45< shadowm> "* Added missing translation mark for mp-related idle notification string"
20140422 18:21:51< shadowm> Is this the change Ivanovic reverted?
20140422 18:22:13< Ivanovic> jepp
20140422 18:22:23< shadowm> You didn't update the changelog afterwards.
20140422 18:28:10-!- mordante [~mordante@roadie.xs4all.nl] has joined #wesnoth-dev
20140422 18:28:10-!- mordante [~mordante@roadie.xs4all.nl] has quit [Changing host]
20140422 18:28:10-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20140422 18:28:25< mordante> servus
20140422 18:30:08< mordante> lipkab, around?
20140422 18:30:28< lipkab> mordante: Yes, hello.
20140422 18:36:18< shadowm> "* Server now generates PR 121 compliant replay files."
20140422 18:37:13< shadowm> I guess this isn't worth mentioning in the release notes since I don't understand what it's supposed to mean.
20140422 18:41:51-!- kex [~kex@77.28.14.175] has joined #wesnoth-dev
20140422 18:42:16< Ivanovic> that the replay format changed
20140422 18:42:17< shadowm> You fixed so much player-relevant stuff this time around and didn't include even half of the changes in players_changelog.
20140422 18:44:02< shadowm> "* Fix bug #20871: Attack related events are now mpsave."
20140422 18:44:11< shadowm> It's spelled "MP-safe".
20140422 18:45:10< iceiceice> shadowm: it probably shouldn't be in release notes or i would have added it, 
20140422 18:45:23< iceiceice> it just notes that you could now load server replay files without crashing your client
20140422 18:47:06< shadowm> Also how many times have I said that "Miscellaneous and bug fixes" should always be the last section. :p
20140422 18:48:22< iceiceice> idk i just grepped the string "last section" in irc logs and i didnt find you saying that :p
20140422 18:48:40< iceiceice> so, i guess just not in the last 2 months?
20140422 18:50:18< shadowm> gfgtdf: "All random generation now behaves like the rng for attacks used to behave." IIUC the point is that the RNG seed is now randomized all the time so that predictability-based cheats are no longer trivial to use.
20140422 18:50:52< shadowm> But how long ago did the RNG for attacks use to be unpredictable as implied in that sentence?
20140422 18:51:39< gfgtdf> shadowm: in 1.10 they are and i don't know earlier versions
20140422 18:51:51-!- Sulfur [~Miranda@p5B0080A9.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20140422 18:52:32< shadowm> So they changed during 1.11.x before? Hm.
20140422 18:53:11< iceiceice> gfgtdf: you might want to weigh in on this forum thread about mp sync stuff, i'm not sure if i actually know the right answers here: http://forums.wesnoth.org/viewtopic.php?f=21&t=35677
20140422 18:53:23< iceiceice> right answers for 1.12+ i mean
20140422 18:56:20< gfgtdf> shadowm: i dont thik they changes duirng 1.11.x but im not sure
20140422 18:56:23< gfgtdf> think
20140422 18:57:28< gfgtdf> there are xhanges*
20140422 18:57:31< gfgtdf> changes*
20140422 18:59:24< shadowm> ... Okay, then you can't say "used to".
20140422 18:59:40< shadowm> That implies it stopped being the case at some point.
20140422 19:00:16< gfgtdf> ok
20140422 19:00:52< shadowm> "Random number generation during WML events will always make the last move non-undoable." Is this an accurate description of the new situation?
20140422 19:01:14-!- _8680_ [~8680@2002:4404:712c:0:2559:304:61dc:5f94] has quit [Remote host closed the connection]
20140422 19:01:46< shadowm> Or did I misunderstand this changelog entry? "Invoking the rng will now always make undoing impossible."
20140422 19:03:24-!- kex [~kex@77.28.14.175] has quit [Remote host closed the connection]
20140422 19:04:02-!- kex [~kex@77.28.14.175] has joined #wesnoth-dev
20140422 19:05:48< gfgtdf> yes, but when you recruit a unit with [unit] the rng is also involved for traits, gender, names .. so that also makes undoing  impossible.
20140422 19:06:07 * shadowm scratches head.
20140422 19:07:11< shadowm> So if I want to have a moveto event handler that randomly performs a non-synchronized action such as an earthquake effect (see {QUAKE}), the player will never be able to undo their moves?
20140422 19:07:58< shadowm> (If you don't want to check the implementation of {QUAKE}, it's a series of [scroll], [delay], and [sound] actions, thus doesn't need to be synchronized and doesn't alter any gamestate.)
20140422 19:08:37< gfgtdf> shadowm: i dotn see how the rng is involved there
20140422 19:08:40< gfgtdf> don't 
20140422 19:08:41-!- kex [~kex@77.28.14.175] has quit [Ping timeout: 252 seconds]
20140422 19:08:53-!- _8680_ [~8680@2002:4404:712c:0:fd44:44d6:968d:8e32] has joined #wesnoth-dev
20140422 19:08:57< shadowm> I said "randomly performs".
20140422 19:09:11-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Quit: Vannak idők, mikor menni kell]
20140422 19:09:43< shadowm> For example, this: http://pastebin.com/0GwA6C0B
20140422 19:10:04< shadowm> Assume safe_random() calls the implementation of [set_variable] rand=. Will this still allow undoing moves in 1.11.13?
20140422 19:10:12-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140422 19:10:57< gfgtdf> shadowm: yes, and im quet sure that undoing such moves in earlier version would lead to corrupt replays/ OOS in mp ?
20140422 19:11:15< gfgtdf> 	shadowm: if you use luas math.random it's fine
20140422 19:11:29< shadowm> Okay are you saying 'yes' or 'no'?
20140422 19:12:05< gfgtdf> you cannot undo that
20140422 19:12:23< shadowm> So the [allow_undo] has no effect?
20140422 19:12:26< gfgtdf> yes
20140422 19:12:57-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140422 19:13:02< shadowm> Right, I could use math.random I guess.
20140422 19:13:23< shadowm> We are going to need a whole WML page on randomness in WML events and its traps.
20140422 19:13:56< shadowm> Because I don't think there is any yet? And those traps have existed since like forever.
20140422 19:14:29< iceiceice> i think its actually much simpler now actually shadowm
20140422 19:14:44< shadowm> Okay, so this is trivially solved there because I was already implementing the handler in Lua.
20140422 19:15:02< gfgtdf> like i said, i dont know what happened before 1.10 so i cannot talk about 'forever'
20140422 19:15:03< iceiceice> i havent read all the sync code so i may be wrong but i think in most cases if you are using the rng, or if the engine is using rng, you cant undo
20140422 19:15:08< shadowm> But most WML coders don't know Lua and there's a single random generation WML action that's always synced.
20140422 19:15:37-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20140422 19:15:50< shadowm> Is sound file list selection still done using unsynced C calls, though?
20140422 19:16:24< shadowm> Hm, seems like it.
20140422 19:16:36< gfgtdf> shadowm: i dint find anything sounds related when writing this
20140422 19:17:30< gfgtdf> so guess yes
20140422 19:19:07-!- EdB [~edb@85.69.242.6] has joined #wesnoth-dev
20140422 19:19:33< iceiceice> my understanding is based on looking at a small amount of sync code and discussions on irc, but from what i understand, the system is now someting like:
20140422 19:19:38< iceiceice> you may always undo unless
20140422 19:19:45< iceiceice> 1) you got new vision
20140422 19:19:48< iceiceice> 2) you drew from the rng
20140422 19:20:02< iceiceice> there was a discussion at some point about when you can undo a recruit of a unit
20140422 19:20:14< shadowm> Yeah, that makes sense, but it's not always obvious when (2) happens.
20140422 19:20:18< iceiceice> in many cases that leads to randomness being used in the name and traits
20140422 19:20:41< iceiceice> so i guess gfgtdf has tried to reduce the number of exceptions, and eliminate unncecessary uses of randomness
20140422 19:20:51< shadowm> For instance, people may be unaware that random_traits=yes, generate_name=yes, random_gender=yes may affect the RNG state, because I think it didn't use to do so?
20140422 19:20:51< iceiceice> for instnace, by default you can now undo the recruit of a ghost,
20140422 19:21:41< iceiceice> i mean they should have guessed that random traits should affect this
20140422 19:21:57< gfgtdf> iceiceice: im not sure whether you can unto recruiting a ghose in 1.1.13
20140422 19:22:04< gfgtdf> ghost
20140422 19:22:24< shadowm> Ah, 1.1.13, good times.
20140422 19:22:26< iceiceice> hmm ok, maybe im not remembering the whole story
20140422 19:22:37< gfgtdf> iceiceice: i'm not sure hwther https://github.com/wesnoth/wesnoth/commit/6ec8d8026088695b4a474749e55634c6e76ff026 was backported
20140422 19:22:42< gfgtdf> whether
20140422 19:22:56< shadowm> (1.1.13 != 1.11.13 and both exist.)
20140422 19:23:18< shadowm> We were able to undo deterministic recruits before, in fact.
20140422 19:23:32< iceiceice> shadowm: i dont think anyone was confused about this typo
20140422 19:23:45< shadowm> But I think the only factor that determined whether they qualified as such was trait generation. Not sure.
20140422 19:24:08< iceiceice> hmm,
20140422 19:24:08< gfgtdf> there were changes about units generation in 1.11.x
20140422 19:24:19< gfgtdf> liek maiking namesgeneration synced
20140422 19:24:21< gfgtdf> making
20140422 19:24:38< iceiceice> tbh i strongly suspect that the new system is actually much simpler than the old system
20140422 19:24:50< iceiceice> in terms of what actions will lead to OOS, what actions will be undoable
20140422 19:25:17< iceiceice> if you feel like we need a page to explain it, i think i agree, but that page is probably much simpler than it would be 1.10
20140422 19:25:20< iceiceice> *for 1.10
20140422 19:29:25-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Quit: Leaving]
20140422 19:31:29< shadowm> Aishiko: You are Aishiko on GitHub, right?
20140422 19:32:27< Aishiko> shadowm, yes
20140422 19:33:03-!- stikonas__ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140422 19:33:18< Aishiko> its all stealthy like
20140422 19:33:26-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 276 seconds]
20140422 19:33:57< shadowm> Aishiko: You now have push access and Developers group membership in the forums, congratulations!
20140422 19:34:08< shadowm> There's a new PM awaiting in your inbox.
20140422 19:35:06< Aishiko> thank you shadowm I'll read it in a bit, a little busy at the moment
20140422 19:35:48< shadowm> iceiceice, gfgtdf, mattsc, Ivanovic : Th announcement draft (sans file sizes) is up: http://forums.wesnoth.org/viewtopic.php?f=33&t=40346
20140422 19:36:06< shadowm> The first three really should read it since it talks a lot about your changes.
20140422 19:36:52< shadowm> Please notify me if you find anything that needs to be clarified or is plain wrong.
20140422 19:41:03-!- _8680_ [~8680@2002:4404:712c:0:fd44:44d6:968d:8e32] has quit [Ping timeout: 252 seconds]
20140422 19:41:58-!- _8680_ [~8680@2002:4404:712c:0:f563:93c0:70e3:c19a] has joined #wesnoth-dev
20140422 19:42:00< mattsc> shadowm: you do have a way with words 
20140422 19:42:48< vultraz> mattsc: do you happen to know if there's any code in place for using the 2x size images on Retina displays?
20140422 19:42:55< mattsc> shadowm: the one change I’d make in the MAI section, I really mean “adding functionality _from_ future versions” in the changelog, that’s not a typo.
20140422 19:43:17< mattsc> vultraz: I am not aware of any
20140422 19:43:18< shadowm> Uh, how can you add functionality from the future without a time machine and a feature freeze exemption?
20140422 19:43:42< mattsc> Maybe the sentence makes more sense im my mind…  :)
20140422 19:44:02< shadowm> Improving decision-making algorithms?
20140422 19:44:25< mattsc> I mean “adding AI behavior/functionality from a future version of Wesnoth to your UMC add-on in the current version".
20140422 19:44:52< mattsc> Maybe the problem is that I use this as if all 1.13 version were future to all 1.12 version.
20140422 19:45:07< mattsc> That’s probably an incorrect use of the term.
20140422 19:45:08< shadowm> Oh, I think I get it now.
20140422 19:45:34< shadowm> 1.13.x is actually in the future compared to 1.12.x regardless of the commit dates, so...
20140422 19:45:40< mattsc> What I mean is: there is functionality in the MAIs in master that somebody might want to use in 1.12, but that cannot be added to 1.12 because of the feature freeze.
20140422 19:46:01< mattsc> This is a real situation: I already had two request for that.
20140422 19:46:27< mattsc> And here’s how you do it:  http://wiki.wesnoth.org/Micro_AIs#Using_Development_.281.13.29_Version_Micro_AIs_in_your_Stable_.281.12.29_Version_Add-on
20140422 19:47:05< shadowm> Yeah, makes sense.
20140422 19:47:40< mattsc> Feel free to reformulate to something that is clearer to others.  I’m probably too close to it to see the problems with my wording.
20140422 19:49:12< shadowm> mattsc: I've just edited the draft.
20140422 19:49:43< shadowm> So, you might want to check that section again -- the revised version is too long for IRC due to the wiki link.
20140422 19:50:22< mattsc> shadowm: I like that.  Thanks.
20140422 19:52:54-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140422 20:12:53-!- prophile [~alynn@oftn/member/prophile] has quit [Quit: The Game]
20140422 20:14:23-!- DHost [~Pcy@vps.plok.fr] has quit [Ping timeout: 276 seconds]
20140422 20:22:52-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has quit [Quit: leaving]
20140422 20:26:36< mordante> I'm off bye
20140422 20:26:52-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20140422 20:29:07-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Ping timeout: 252 seconds]
20140422 20:29:41-!- ancestral [~ancestral@17.114.45.51] has quit [Quit: ancestral]
20140422 20:37:20-!- DHost [~Pcy@vps.plok.fr] has joined #wesnoth-dev
20140422 20:38:38-!- trademark_ [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has quit [Ping timeout: 240 seconds]
20140422 20:41:30< gfgtdf> shadowm: when do bugs/ feature requests on gna get closed ?
20140422 20:43:08-!- EdB [~edb@85.69.242.6] has quit [Quit: Konversation terminated!]
20140422 20:43:32-!- stikonas__ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140422 20:44:52-!- wesbot changed the topic of #wesnoth-dev to: released 1.11.13, announcing "soon" | string+feature freeze active on 1.12 | 240 bugs, 347 feature requests, 28 patches | Logs: http://irclogs.wesnoth.org | Alternate logs: http://wesnoth.debian.net | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20140422 20:46:16< gfgtdf> shadowm: i marked https://gna.org/bugs/?15917 and https://gna.org/bugs/?15917 as fixed because wml menu hotkeys they are already implemented in a previous 1.11.x version.
20140422 20:46:53-!- ancestral [~ancestral@17.114.45.51] has joined #wesnoth-dev
20140422 20:47:12< shadowm> OK, but both links are identical.
20140422 20:47:15-!- cib [~cib@p5DD22284.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140422 20:47:39-!- cib is now known as Guest82
20140422 20:49:01< shadowm> Also, did you check the announcement draft as I requested?
20140422 20:51:24< gfgtdf> shadowm: i meant https://gna.org/bugs/?20709 and  https://gna.org/bugs/?1591
20140422 20:52:06< shadowm> I assume the last one is #15917 as above and not #1591. :)
20140422 20:52:34< shadowm> Yeah, sure, that's what we are supposed to do with bugs fixed in existing releases.
20140422 20:53:31< shadowm> It's only bugs that are fixed in a release that hasn't happened yet that may not be Closed (as opposed to marked as Fixed) immediately. Also, bugs that never affected a release in the first place may be Closed immediately.
20140422 20:57:25-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140422 20:59:14-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20140422 20:59:36< Anakonda> There are errors in CMakeLists. Only when compiling windows and not using Microsoft Visual though
20140422 21:06:04-!- Grickit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20140422 21:07:02-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Ping timeout: 276 seconds]
20140422 21:24:55-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20140422 21:41:17-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Quit: tomreyn]
20140422 21:46:42-!- Anakonda [Anakonda@88-148-200-195.bb.dnainternet.fi] has quit [Quit: Leaving]
20140422 21:47:14< shadowm> gfgtdf: So, I'm going to ask a last time: did you review the bits of the announcement draft concerning your changes?
20140422 21:47:30< gfgtdf> shadowm: ye i did
20140422 21:47:55< shadowm> You know, so I can move forward, update the downloads page, rebuild wesnothd,  and publish the thing.
20140422 21:48:03< shadowm> Is everything correct?
20140422 21:53:17< zookeeper> "Random number generation during WML events will always make the last move non-undoable." <- _always_? no MP-unsafe alternative which retains undo?
20140422 21:54:07< gfgtdf> luas unsave rng is that alternitive
20140422 21:54:11< shadowm> math.random()
20140422 21:54:14< gfgtdf> yes
20140422 21:54:46< zookeeper> okay then
20140422 21:54:56< gfgtdf> shadowm: wait
20140422 21:55:11< gfgtdf> shadowm: "WML start and prestart events are now MP-safe, except for UI actions during prestart." appearign twice intented ?
20140422 21:55:11< shadowm> Or alternatively the dice operator in inline formulas, assuming it hasn't been removed or reengineered to use the synced RNG yet.
20140422 21:55:38< shadowm> gfgtdf: Once in a the MP section and again in the WML section.
20140422 21:56:02< shadowm> Because I have to assume readers have the attention span of my dog and won't necessarily read both sections.
20140422 21:57:06< gfgtdf> shadowm: hm ok, ypou could also mention that turn end events are mpsave,.
20140422 21:57:39< shadowm> Uh?
20140422 21:57:52< shadowm> That wasn't in the changelog.
20140422 21:58:37< shadowm> It's still "MP-safe", btw, not "mpsave". "Safe" and "save" are two different words, an adjective/noun and noun/verb, respectively.
20140422 22:00:29-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140422 22:01:39< gfgtdf> hmm, i'm sure they are MPsave, and i think (i'm not 100% sure) that they weren't MPsave before.
20140422 22:02:18< shadowm> I'm only doing what the changelog told me to do because I found the full git log too confusing.
20140422 22:02:57< gfgtdf> ye i think that's why we have the changelog
20140422 22:03:07< shadowm> "use synced context: sync the turn ... events and prestart events."
20140422 22:03:36< shadowm>     //RAII block
20140422 22:03:56< shadowm> You know you can place braces anywhere without having to use a control structure in order to create a subscope, right?
20140422 22:04:17< gfgtdf> 	shadowm: i thought so but i wans't 100% sure
20140422 22:04:26< shadowm> void foo() { /* ... */  {  /* this is still a subscope without a control structure */ }  /* ... */ }
20140422 22:05:29< shadowm> Later in the diff there's a comment in the middle of a block instead of at the beginning.
20140422 22:05:44< shadowm> Now I remember why I didn't want to look at diffs anymore... :p
20140422 22:06:50< gfgtdf> shadowm: you mean te commented out code in play_controller ? or was there another comment i deleted in a later commit ?
20140422 22:07:42< shadowm> Commit aabb5b650c688bd8c5ff86f3391c81359883d0dd , replay_controller.cpp has a seemingly downwards-shifted instance of the "block for RAII" comment.
20140422 22:08:36< shadowm> Anyway that's not relevant. The point is that 'turn end' events were previously OOS vectors and now they are fixed? This was an issue specific to those and not their 'turn refresh' and 'side turn'/'turn' (start) siblings?
20140422 22:11:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140422 22:11:49< shadowm> "[*]WML [tt]attack[/tt] and [tt]turn end[/tt] events and variations thereof ([tt]attack hits[/tt], [tt]side X turn Y end[/tt], etc.) are now MP-safe (see also bug [bug]20871[/bug])."
20140422 22:11:53< shadowm> More accurate?
20140422 22:12:41-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 276 seconds]
20140422 22:12:47< shadowm> ... I lumped them together because both have parametric variations, unlike start and prestart.
20140422 22:14:12< gfgtdf> https://gna.org/bugs/?21652
20140422 22:14:59< gfgtdf> i personaly don't reember whether they have been unsave before.
20140422 22:15:10< gfgtdf> but according to the link they were
20140422 22:15:54< gfgtdf> so your text is good.
20140422 22:16:02< shadowm> Unsafe. I trust EP's judgment because he does a lot of fancy stuff with WML and with multiple versions.
20140422 22:48:58-!- ancestral [~ancestral@17.114.45.51] has quit [Quit: ancestral]
20140422 22:56:55-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140422 22:56:55-!- gfgtdf [~chatzilla@f054052202.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 28.0/20140314220517]]
20140422 22:57:35< iceiceice> gfgtdf: did you see my comments earlier this morning?
20140422 23:01:57< iceiceice> shadowm: a very small comment on the release announcement
20140422 23:02:09< iceiceice> In multiplayer/replay engine changes section, this sentence:
20140422 23:02:14< iceiceice> "The MP server now includes controller changes in replays."
20140422 23:02:24< iceiceice> i think it might be slightly easier to follow if it reads something like
20140422 23:02:58< iceiceice> "The MP server now includes controller changes in the replays that are sent to observers and saved in replay files."
20140422 23:03:03-!- gfgtdf [~chatzilla@f054052202.adsl.alicedsl.de] has joined #wesnoth-dev
20140422 23:03:04< iceiceice> idk you be the judge
20140422 23:03:33< gfgtdf> iceiceice: you meant about reverting mp controller tweaks ?
20140422 23:03:38< iceiceice> yeah
20140422 23:03:47< gfgtdf> i thought it's alreay too late ? :O
20140422 23:03:58< iceiceice> too late in what sense
20140422 23:04:02< gfgtdf> any do you know and bugs with them ?
20140422 23:04:18< gfgtdf> any*
20140422 23:04:24< gfgtdf> that 1.11.13 is unstoppable :)
20140422 23:04:36< iceiceice> i know i'm not concerned about that, i mean for 1.12
20140422 23:05:19< gfgtdf> hm if there are no known bugs idk why we should revnert it, i think we still have.
20140422 23:06:04-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20140422 23:06:05< iceiceice> ok well we still didnt really fix this apparently, https://gna.org/bugs/?21939
20140422 23:06:10< iceiceice> we didnt fix:
20140422 23:06:36< gfgtdf> i made a commit that might effect 21939
20140422 23:06:52< gfgtdf> iceiceice: https://github.com/wesnoth/wesnoth/commit/986002b44880093e848e7c10a8a08581d53e3796
20140422 23:07:02< iceiceice> we didnt really fix this:
20140422 23:07:02< iceiceice> https://gna.org/bugs/?21903
20140422 23:07:24-!- Xenius__ [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20140422 23:07:26< iceiceice> i guess we agreed to just change how lingermode works in networked mp
20140422 23:07:42< iceiceice> idk users could quite reasonably report the new behavior as a bug though
20140422 23:07:43< gfgtdf> iceiceice: we did this that
20140422 23:08:13< iceiceice> the thing is its cost benefit analysis
20140422 23:08:15< gfgtdf> iceiceice: not beeing able to ckick end scneario while tho has didnt clicked is was the intened behaviour before
20140422 23:08:29< gfgtdf> the host*
20140422 23:08:31-!- kex [~kex@78.157.29.205] has joined #wesnoth-dev
20140422 23:08:32< iceiceice> the server controller tweaks thing didnt fix any severe bugs afaik, it was just a common sense change
20140422 23:08:45< iceiceice> it turned out that it lead to more bugs than we expected and we continue to find them
20140422 23:08:55< iceiceice> i'm not sure it can be totally fixed without introducing more code
20140422 23:09:11< iceiceice> i'm not sure what it costs us to just revert it
20140422 23:09:27< iceiceice> the only reason would be if it would confuse devs i guess who have gotten used to it
20140422 23:09:33< iceiceice> but master and 1.12 have to diverge
20140422 23:10:19< iceiceice> idk its hard to review exactly what bug fixes it was associated with, 
20140422 23:10:20-!- Necrosporus_ [~Necrospor@unaffiliated/necrosporus] has quit [Ping timeout: 255 seconds]
20140422 23:10:26< iceiceice> i would have to make an experimental branch and test it
20140422 23:10:41< gfgtdf> the controllew teweaks ?
20140422 23:10:44< iceiceice> but right now for example there are plenty of minor bugs assocaited with it
20140422 23:11:05< iceiceice> like, if you play an mp campaign, whenever you transition you are going to get the server sending messages complaining about whiteboard i guess
20140422 23:11:28< iceiceice> is that a blocker? probably not
20140422 23:11:31< iceiceice> is it good? no
20140422 23:11:46-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Ciao]
20140422 23:11:47< iceiceice> can we fix it without changing lots of things? tbh i dont really see how right now
20140422 23:12:14< gfgtdf> 	iceiceice: ugly server messages are definitely someting to avoid for 1.12
20140422 23:12:18< iceiceice> i think the smallest band-aid fix is something like this: https://github.com/wesnoth/wesnoth/pull/156
20140422 23:12:42< iceiceice> the real fix is probably, use a new game object server-side when we transition
20140422 23:12:49< iceiceice> but that is definitely not appropriate for 1.12
20140422 23:13:29< iceiceice> idk theres many ways to fix it but reverting might be the easiest
20140422 23:13:50< iceiceice> at least as far as i can see
20140422 23:14:43< happygrue> iceiceice: gfgtdf, I think that fix for linger mode is probably best as it was implemented.  As long as it's explained in the changelog then we can point to that if anyone reports it as a bug.  It seems a fair way to do it, IMO
20140422 23:15:38< iceiceice> did it go into the release notes?
20140422 23:15:53< iceiceice> also, one way that it could be improved imo,
20140422 23:16:05< gfgtdf> iceiceice: i dont get teh whiltebord data currently in 1.11.13
20140422 23:16:05< iceiceice> its only necessary to do that when the host is actually sending a new level later
20140422 23:16:12< iceiceice> really?
20140422 23:16:27< iceiceice> i was getting consistently when moving LoW 1 -> LoW 2
20140422 23:16:29< gfgtdf> at least not in the one game i just tested
20140422 23:18:03< iceiceice> ok well anyways regardless of what you are seeing in tests, it is obvious from the code that the clients are going to get the change_controller messages
20140422 23:18:16< iceiceice> when the host transitions
20140422 23:18:40-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140422 23:18:48< iceiceice> idk, maybe we can change how they are handled? maybe they should ignore it in linger mode?
20140422 23:18:59< iceiceice> i mean theres lots of possibilities, but its as likely to create more bugs than it fixes
20140422 23:19:14< iceiceice> if we just revert we largely won't have to think about it
20140422 23:19:22< iceiceice> at least i hope
20140422 23:19:43< gfgtdf> iceiceice: but i didnt get them
20140422 23:19:58< gfgtdf> iceiceice: but if we revert be also caue another imcompability
20140422 23:20:04< iceiceice> do you have log-debug on?
20140422 23:20:08< gfgtdf> no
20140422 23:20:09< iceiceice> log-debug=network?
20140422 23:20:12< gfgtdf> no
20140422 23:20:24< iceiceice> did you test LoW 1 or LoW 2?
20140422 23:20:34< gfgtdf> LoW chapter 1
20140422 23:20:44< gfgtdf> advancing to chapter 2
20140422 23:21:42< iceiceice> i see so the linger mode fix just covers it up
20140422 23:22:03< iceiceice> do you still get any controller problems?
20140422 23:22:16< gfgtdf> iceiceice	: but i still gte the .. has no controller but should whe stating in chapter 3
20140422 23:22:31< gfgtdf> and advance to the next scenario
20140422 23:22:36< iceiceice> ok, well i would be interested what happens if we revert
20140422 23:22:48-!- Dugi [93fbd156@gateway/web/freenode/ip.147.251.209.86] has quit [Ping timeout: 240 seconds]
20140422 23:22:49< gfgtdf> with the host controlling 3 sides as 'local player'
20140422 23:22:50< iceiceice> i dont think anyone wrote any code besides me that relies on the controller types this way
20140422 23:23:18< gfgtdf> iceiceice: my code just relys on is  null controller
20140422 23:23:21< iceiceice> idk i dont see how it could be a compatibility problem, 
20140422 23:23:35< iceiceice> its just going to be are the contorllers already in the level or not
20140422 23:23:49< gfgtdf> iceiceice: you think clients with and without controller tweak code can play against eachother ?
20140422 23:23:57< iceiceice> no they definitely cant
20140422 23:24:01< iceiceice> errr
20140422 23:24:05< gfgtdf> i dont know much about teh serversided code really
20140422 23:24:23< iceiceice> i dont know it depends on the server used i guess
20140422 23:24:46< iceiceice> i dont know what happens if the client makes tweaks and the server also makes the same tweaks, probably nothing
20140422 23:25:01< iceiceice> *nothing bad
20140422 23:26:06< gfgtdf> do you know when 1.12 will be released ?
20140422 23:26:30-!- loonycyborg [~loonycybo@wesnoth/developer/loonycyborg] has quit [Quit: ZNC - http://znc.sourceforge.net]
20140422 23:26:31< iceiceice> no, i dont think anyone does
20140422 23:26:48< iceiceice> i mean strictly speaking, it will be released when Ivanovic decides to release it
20140422 23:26:55< iceiceice> but i dont think he will release it until the bugs are fixed
20140422 23:27:14< iceiceice> meaning, the blocker bugs that would prevent people from playing
20140422 23:27:26-!- spoffy_ [~spoffy@host86-168-246-14.range86-168.btcentralplus.com] has quit [Ping timeout: 276 seconds]
20140422 23:28:01< gfgtdf> iceiceice: when i seelct 'p' (the name of teh host) instead of 'local player' it works, so i guess teh server has problems with the annynymuls local plays
20140422 23:28:03< gfgtdf> player
20140422 23:28:27< gfgtdf> iceiceice: im optimistic that we can solvemost problems with teh cintroller tweaks
20140422 23:28:37< gfgtdf> s/with/about*
20140422 23:29:10< iceiceice> gfgtdf: i'm also very optimistic about that. but i wont make any guesses about "when"
20140422 23:29:30< iceiceice> it depends on how much testing happens and how many we discover
20140422 23:29:39< iceiceice> and what strategy we take
20140422 23:29:44< iceiceice> for fixing
20140422 23:30:49< iceiceice> idk all i'm saying is if i knew what i know now, i'm not sure if i would have cherry-picked the controller tweaks to 1.12
20140422 23:31:13< iceiceice> even if it helps some bugs
20140422 23:32:58< iceiceice> the way i am looking it is,
20140422 23:33:12< iceiceice> i am hoping that the next release will be a release candidate
20140422 23:33:14-!- Guest82 [~cib@p5DD22284.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds]
20140422 23:33:30< iceiceice> and that after that we won't ever have to introduce new code at all
20140422 23:33:41< iceiceice> just fix minor issues in existing code that we find after testing
20140422 23:33:49< iceiceice> i guess we dont have like a "code freeze" policy but
20140422 23:33:58< iceiceice> or a "no new code" policy,
20140422 23:34:19< iceiceice> but still i would prefer to be closer to that than further away
20140422 23:35:06< iceiceice> idk i will have to review what bugs are currently on the 1.12 branch, i havent been developing for a few days
20140422 23:36:35< iceiceice> gfgtdf: i'm going to modify shadowm's draft to mention the changes to lingermode
20140422 23:37:10< gfgtdf> iceiceice: hm ok
20140422 23:37:27< gfgtdf> iceiceice: but you shoudl tell shadowm
20140422 23:38:13< iceiceice> shadowm: i'm going to modify the draft to have the changes i mentioned above and mention the changes to linger mode in MP
20140422 23:40:28-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140422 23:41:16< iceiceice> gfgtdf: this is really not a good commit message: https://github.com/wesnoth/wesnoth/commit/c1dcd4629ff45a2cc6012bfb557b1bb29b9ad050
20140422 23:41:32< iceiceice> first of all it is disabling mp:connect not mp:configure, that is something else
20140422 23:41:41< iceiceice> second of all it is only relevant when using debug mode,
20140422 23:41:53< iceiceice> which is a key detail which didnt make it into the message
20140422 23:43:41< iceiceice> gfgtdf: did we test at all what will happen in the new networked MP linger mode?
20140422 23:43:51< iceiceice> what will happen if there is no scenario to transition to and the game ends?
20140422 23:44:43< iceiceice> there are some UMC mp scenarios that end with linger mode 
20140422 23:45:02< iceiceice> idk i want to write down whatever it is that happens for the release notes
20140422 23:46:54-!- irker162 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20140422 23:46:54< irker162> wesnoth: mattsc wesnoth:master ddfdae5e520c / data/ai/lua/battle_calcs.lua: battle_calcs.lua: fix a variable name http://git.io/z-EbeA
20140422 23:47:49< irker162> wesnoth: mattsc wesnoth:1.12 8ffcc6eefc33 / data/ai/lua/battle_calcs.lua: battle_calcs.lua: fix a variable name http://git.io/eYCtHw
20140422 23:47:50< shadowm> iceiceice: Isn't replay data propagated to all clients by the server regardless of whether it's an observer or not?
20140422 23:48:06< iceiceice> shadowm: the difference is when an observer joins what happens
20140422 23:48:17< shadowm> That is, I'm under the impression that the whole networked multiplayer gimmick is a glorified incremental replay.
20140422 23:48:26< iceiceice> when someone joins as an observer, they get the game state from the server, not the host
20140422 23:48:46< iceiceice> via the initial "level" config sent from the host,
20140422 23:48:46< shadowm> Clients never connect to the game 'host'.
20140422 23:48:48< iceiceice> and the server's replay
20140422 23:49:05< iceiceice> of course thats right but in principle they might request a snapshot from the host via the server
20140422 23:49:14< iceiceice> thats not what we do, its easy to overlook
20140422 23:49:39< shadowm> Snapshot? I thought it was always the whole thing even if you didn't want it.
20140422 23:49:46< gfgtdf> iceiceice: i just tested the normal mp scenarios to test, but im sure that this was the intented behaviour i just restored it.
20140422 23:49:54< shadowm> Which was the whole reason why Quick Replays weren't actually quick as I recall.
20140422 23:50:11< iceiceice> shadowm: that's not really true
20140422 23:50:21< iceiceice> when you join the game, the server just sends its hisotry of the game
20140422 23:50:31< iceiceice> it doesnt have a snapshot available, otherwise you could jump to that
20140422 23:51:05< iceiceice> i think most users dont understand this most likle,y which is why i think the first and second sentences might seem confusing to them
20140422 23:51:14< mattsc> Is it possible to cherry-pick a commit from a different fork without switching to it?
20140422 23:51:35< mattsc> Specifically, I’m talking about this one from this morning:  https://github.com/gfgtdf/wesnoth-old/commit/395be4bf2adebbd389501382b248332fa930744d
20140422 23:52:06< iceiceice> mattsc: when you use the word fork do you mean branch or fork?
20140422 23:52:53< iceiceice> normally you dont switch to the branch you are cherry-picking from, you switch to the branch you are cherry-picking to
20140422 23:52:54< mattsc> iceiceice: IDK  :P   I want to test that commit from gfgtdf in 1.11.13+dev or master.  What’s the easiest way to do that?
20140422 23:53:21< mattsc> As far as I understand things, that’s in a different fork, isn’t it?
20140422 23:53:25< gfgtdf> mattsc: on 1.11.13+dev is better since i have a lot of bugfixed not pushed yet to master
20140422 23:54:10< mattsc> gfgtdf: well, as I said, I want to check that commit _only_, without all the other baggage going along with it.  :)
20140422 23:54:25< mattsc> … going along with that fork or branch or whatever it is.
20140422 23:54:32< iceiceice> i also want to point it out because its easy for someone reading IRC to think that the replays held by the server are only relevant to the replays generated by the server
20140422 23:54:38< iceiceice> in fact that's not the case,
20140422 23:54:48< gfgtdf> no you dont need the fork but you might need come commits that are in 1.11.13 but not in 1.13 yet
20140422 23:55:01< mattsc> I could just copy the code into those files, it’s not that much.  Unless it depends on something else.
20140422 23:55:03< iceiceice> the commit i made "server now generates PR 121 compliant replays" was actually pretty crucial, if that didnt happen then observers would crash whenever they joined a game that was already started
20140422 23:55:22< iceiceice> shadowm: ^
20140422 23:55:58< iceiceice> Soliton wrote a few days ago that we shouldnt get worried about the server generated replay files because we can fix them post release on server side
20140422 23:56:02< shadowm> iceiceice: So there is no snapshot, that's what I was saying?
20140422 23:56:08< mattsc> Okay.  gfgtdf, well if it’s more work than just dealing with this commit in isolation, I’d rather wait.  I’m pretty busy with lots of other things atm.
20140422 23:56:08< iceiceice> but i think its actually important to get this part of it right
20140422 23:56:44< mattsc> … and with all that, nobody has actually answered my question yet.  :)
20140422 23:58:13< shadowm> iceiceice: So, when should I expect to see the section on linger mode so I can proofread it?
20140422 23:58:21< shadowm> Also, seriously, what happened to RELEASE_NOTES this time?
20140422 23:58:31< shadowm> And players_changelog.
20140422 23:58:45< iceiceice> well gfgtdf didnt answer my questions above so i am forced to test it myself
20140422 23:59:00< shadowm> Actually, the word 'linger' last appeared in the changelog block for 1.11.11, so...
20140422 23:59:15< shadowm> Yeah, what changes and why aren't they in any of the changelogs? :p
20140422 23:59:22< iceiceice> y frankly gfgtdf you should be the oen writing this, you made the linger mode commit
20140422 23:59:31< gfgtdf> mattsc: maybe you coudl try to fetch and then cherrypick
20140422 23:59:46< iceiceice> ok i'm going to wash my hands of it now
--- Log closed Wed Apr 23 00:00:03 2014