--- Log opened Tue May 27 00:00:08 2014
--- Day changed Tue May 27 2014
20140527 00:00:08< iceiceice> and we can refer to the tests if we ever decide we are interested to do somethign with it
20140527 00:00:15< iceiceice> or if someone wants to write a scenario using hte behavior
20140527 00:02:37< irker669> wesnoth: Chris Beck wesnoth:master ec5ec4fb3818 / data/test/scenarios/prestart_settings.cfg wml_test_schedule: add tests of modify_turns tag http://git.io/QGoFtQ
20140527 00:02:39< irker669> wesnoth: Chris Beck wesnoth:master 254c38e9af9f / src/ (7 files): Merge branch 'master' of git://github.com/wesnoth/wesnoth http://git.io/I08scA
20140527 00:06:44< iceiceice> does anyone know what this means?
20140527 00:06:45< iceiceice> replays do not work if variables are set in a prestart or start event that affect gameplay (e.g. setting number of turns, time of day, or gold, adding units, etc.) and game is reloaded
20140527 00:06:49< iceiceice> the part about "time of day"
20140527 00:06:55< iceiceice> does that mean using a time area tag?
20140527 00:07:35< iceiceice> is there someway to overwrite the scenario wide tod schedule?
20140527 00:08:04< iceiceice> oh, replace schedule i guess...
20140527 00:10:15< gfgtdf> iceiceice: do you kniw whether https://gna.org/bugs/index.php?21798 is still present ?
20140527 00:10:29< iceiceice> i didnt change it
20140527 00:10:42< iceiceice> actually, those tests i tried to write yesterday with set_global_Variable didnt work
20140527 00:10:50< iceiceice> so i'm not sure if that is still wroking at all
20140527 00:11:00< gfgtdf> iceiceice:  if what is working ?
20140527 00:11:08< iceiceice> the whole global variable thing
20140527 00:11:22< gfgtdf> there is q known bug with it but in general it works 
20140527 00:11:23< gfgtdf> a
20140527 00:11:27< iceiceice> hmm ok
20140527 00:12:27< gfgtdf> iceiceice: the known bug: https://gna.org/bugs/?21093
20140527 00:13:02-!- aboutGod [~aboutGod@static-72-66-66-50.washdc.fios.verizon.net] has left #wesnoth-dev []
20140527 00:13:24< iceiceice> y i dont know anything about the implementation
20140527 00:13:31< iceiceice> ididnt try to do anything with this
20140527 00:14:41< gfgtdf> iceiceice: i dot know whether there is anyone wno knows about the implementtion
20140527 00:14:42< irker669> wesnoth: Chris Beck wesnoth:master b272239ea901 / data/test/scenarios/prestart_settings.cfg wml_test_schedule: add replace_schedule in prestart test http://git.io/6GfVig
20140527 00:14:46< iceiceice> gfgtdf:
20140527 00:14:50< iceiceice> yeah i guess its like whiteboard
20140527 00:16:34< iceiceice> ok i have tested all of the examples coffee listed
20140527 00:16:35< iceiceice> http://forums.wesnoth.org/viewtopic.php?f=10&t=38487
20140527 00:16:41< iceiceice> for variables being set in prestart causing OOS
20140527 00:16:48< iceiceice> so i think we can X that off
20140527 00:17:17< iceiceice> idk maybe i need to test mp instead of replay?
20140527 00:17:21< iceiceice> but i expect that its fixed
20140527 00:17:43< iceiceice> oh its only if game is reloaded
20140527 00:19:15< iceiceice> be back later
20140527 00:19:16-!- iceiceice [~chris@207-237-132-91.ny.subnet.cable.rcn.com] has quit [Quit: Leaving]
20140527 00:25:53-!- travis-ci [~travis-ci@ec2-54-211-38-232.compute-1.amazonaws.com] has joined #wesnoth-dev
20140527 00:25:53< travis-ci> [travis-ci] wesnoth/wesnoth#2812 (master - d28a1d6 : gfgtdf): The build was broken.
20140527 00:25:53< travis-ci> [travis-ci] Build details : http://travis-ci.org/wesnoth/wesnoth/builds/26086145
20140527 00:25:53-!- travis-ci [~travis-ci@ec2-54-211-38-232.compute-1.amazonaws.com] has left #wesnoth-dev []
20140527 00:34:54-!- travis-ci [~travis-ci@ec2-54-83-250-234.compute-1.amazonaws.com] has joined #wesnoth-dev
20140527 00:34:54< travis-ci> [travis-ci] wesnoth/wesnoth#2813 (master - 254c38e : Chris Beck): The build was broken.
20140527 00:34:54< travis-ci> [travis-ci] Build details : http://travis-ci.org/wesnoth/wesnoth/builds/26088206
20140527 00:34:54-!- travis-ci [~travis-ci@ec2-54-83-250-234.compute-1.amazonaws.com] has left #wesnoth-dev []
20140527 00:35:17-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has quit [Ping timeout: 252 seconds]
20140527 00:36:33-!- DDR [~david@ec2.happyspork.com] has quit [Ping timeout: 252 seconds]
20140527 00:47:16-!- DDR [~david@ec2.happyspork.com] has joined #wesnoth-dev
20140527 00:47:42-!- crimson_penguin [~crimson_p@ec2.happyspork.com] has joined #wesnoth-dev
20140527 00:50:01-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140527 00:58:30-!- travis-ci [~travis-ci@ec2-54-227-86-191.compute-1.amazonaws.com] has joined #wesnoth-dev
20140527 00:58:30< travis-ci> [travis-ci] wesnoth/wesnoth#2814 (master - b272239 : Chris Beck): The build was broken.
20140527 00:58:30< travis-ci> [travis-ci] Build details : http://travis-ci.org/wesnoth/wesnoth/builds/26088733
20140527 00:58:30-!- travis-ci [~travis-ci@ec2-54-227-86-191.compute-1.amazonaws.com] has left #wesnoth-dev []
20140527 01:00:59-!- crimson_penguin [~crimson_p@ec2.happyspork.com] has quit [Changing host]
20140527 01:00:59-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20140527 01:04:56-!- aquileia [2edf524c@gateway/web/freenode/ip.46.223.82.76] has quit [Quit: Page closed]
20140527 01:09:04< gfgtdf> is it teh intended bahaviour that i dont the teh time bonus for mp immideately but onyl for teh next turn ?
20140527 01:09:07< gfgtdf> the*
20140527 01:09:39-!- WinterD [~quassel@177.196.200.77.rev.sfr.net] has joined #wesnoth-dev
20140527 01:10:34-!- mjs-de [~mjs-de@f049244162.adsl.alicedsl.de] has quit [Remote host closed the connection]
20140527 01:10:46< gfgtdf> is it the intended behaviour that i do't get the time bonus for actions (attack/recruit) immideately but only on the next turn ?
20140527 01:11:03< gfgtdf> happygrue: ^ (i heraed you play a lot mp)
20140527 01:19:18-!- pyromancer2 [~pyromance@pool-173-63-201-238.nwrknj.fios.verizon.net] has joined #wesnoth-dev
20140527 01:19:45-!- pyromancer2 [~pyromance@pool-173-63-201-238.nwrknj.fios.verizon.net] has quit [Client Quit]
20140527 01:21:31-!- Necrosporus_ [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20140527 01:22:33-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140527 01:22:39< happygrue> gfgtdf: you are correct, that is intentional for the default timer
20140527 01:22:52< happygrue> however, myself and some others have wished to change the default timer for a long time
20140527 01:23:18< happygrue> but Sapient (who wrote it) really likes it the way it is.
20140527 01:23:40< iceiceice> well why dont we make several modes?
20140527 01:23:48< iceiceice> i think many mp players wish it worked differnetly also
20140527 01:24:11< iceiceice> but maybe its just about the default settings
20140527 01:24:22< iceiceice> the roudn bonus really needs to be longer in the default setting imo
20140527 01:24:25< happygrue> it would be ideal to have several modes AND that the default settings be much more intuitive than the current default
20140527 01:24:32< happygrue> which confuses new players quite a lot
20140527 01:24:37-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has quit [Ping timeout: 252 seconds]
20140527 01:24:48< happygrue> and frustrates verterans to who forget to change it to something more sane ;)
20140527 01:24:59< happygrue> http://forums.wesnoth.org/viewtopic.php?f=15&t=21342
20140527 01:25:21< happygrue> this is an old thread that is relevant
20140527 01:25:52< happygrue> IMO the default should be 4 or maybe 5  minutes flat
20140527 01:26:16< happygrue> no bonuses, just that much time each turn.  ANd let people tweak settings if they want something more interesting.
20140527 01:27:11< happygrue> another feature that I would love to see implemented with the timer is a "timeout button" with a checkbox to set it while creating a game
20140527 01:27:46< happygrue> that is: if set, then when you run out of time your turn isn't over, but rather the other team/player gets a little something that they can choose to click (or not) which forces the turn to end
20140527 01:28:39< happygrue> this allows someone to say "going afk a few minutes) without forcing everyone to save and resume the game, or for people who don't really want to force end turns (which can totally ruin a game that has lasted hours already), but want to make sure people keep moving at a good pace
20140527 01:30:25< gfgtdf> iceiceice: is there wml/lua to modify the timeout =
20140527 01:30:37< happygrue> gfgtdf: the idea behind the default timer is that if you move more stuff each turn, you get more time.  The *problem* with that is that you could move nothing and get less than a minute next turn, when NEXT turn is when you want to move all of your units and make a major attack (due to ToD)
20140527 01:30:59< iceiceice> what timeout/
20140527 01:31:00< happygrue> but it really is bad for new players, because they have no idea why they keep running out of time at first
20140527 01:31:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140527 01:31:29< iceiceice> y i think the whole thing is based on a faulty assumption
20140527 01:31:36< iceiceice> that the amount of thinking you do is related to the amount of units you move
20140527 01:31:45< iceiceice> it basically screws over the defending player
20140527 01:31:47< gfgtdf> happygrue: ye thats why i asked teh question where the curretn version is raly intended
20140527 01:31:49< gfgtdf> the*
20140527 01:31:54< gfgtdf> whether*
20140527 01:31:57< gfgtdf> really*
20140527 01:32:10< iceiceice> * the amount of time you need to think is related to the amount of units you move
20140527 01:34:00< gfgtdf> iceiceice: well my origianl intention is to move code out of playmp_controller, and t move teh timout calculation to team.cpp (wherer the data is stored)
20140527 01:34:54< iceiceice> hmm
20140527 01:35:36< iceiceice> i guess i dont know the code at hand
20140527 01:35:43< iceiceice> do you need to have like a timer object to do it?
20140527 01:35:53< iceiceice> or you are just moving the artihmetic out
20140527 01:36:30< gfgtdf> 	iceiceice: idk yet but i think i'll just move the arethmetic out first
20140527 01:36:42< iceiceice> y that sounds like a good idea
20140527 01:37:50< iceiceice> gfgtdf: do you have an opinion on the thing i'm proposing here? http://forums.wesnoth.org/viewtopic.php?f=16&p=570936#p570885
20140527 01:41:42< happygrue> regarding the timer:  I think you would have wide (VERY wide) support of the MP community for making the default timer very simple, such as a flat X minutes/turn, I'd suggest 5.  Adding better stuff for the timer would also be nice, but just making the default settings more sane I fully support
20140527 01:41:56< happygrue> wesbot: seen Sapient
20140527 01:41:56< wesbot> happygrue: The person with the nick Sapient last spoke 55d 21h ago.  55d 21h ago they left with the message: Quit: cya later. have fun
20140527 01:42:49< happygrue> I don't think Sapient is very active these days though he's still around on the forums, so it would be good to mention/talk to him about it first, as when I have tried last he felt very strongly about the timer.
20140527 01:43:14< iceiceice> happygrue: we could also ask Velensk to make a suggestion for default timer settings
20140527 01:43:25< happygrue> but I don't recall if it was more "just go do it yourself" or "I really don't want this changed"
20140527 01:43:41< iceiceice> i dont actually know what good timer values are i think, i rarely play with timer
20140527 01:43:53< happygrue> sure, he would agree with me I'm sure, as would basically anyone you ask on the server I think, though we could quibble about how many minutes is ideal
20140527 01:44:35< happygrue> since it can be set easily, that isn't too important.  But a great many people play with 4-6 minutes/turn
20140527 01:45:36< happygrue> something more complicated would also work, and would be what *I* would play with, but as a default setting just make it 5 min/turn so that everyone understands it perfectly
20140527 01:46:03< happygrue> ideal timers tend to be something like 4-5 min/turn with 6-8 minute "bank"
20140527 01:46:26< happygrue> so you can save up time up to a max of, say 6 minutes, but you only get 4 minutes more every turn
20140527 01:46:29< gfgtdf> iceiceice: hmm i think pervent all abuses of the get side names while still preserving all useful features f it migth be hard. especialy note that [message] is not the only way to print text to the user (lua gui2 dialogs for example!). Also i wouldn't  suspend that there is a harmess feature that migth want to store the names of the users persistently. for example to know who playerd a save...
20140527 01:46:31< gfgtdf> ...before a relaod or something.
20140527 01:47:08< iceiceice> y so my change woudl just be
20140527 01:47:14< iceiceice> add to team.hpp 
20140527 01:47:18< iceiceice> a "get_sanitized_name"
20140527 01:47:32< iceiceice> and also a "parse_sanitized_name_strings"
20140527 01:47:44< iceiceice> the gui would run parse_sanitized_name_strings in game,
20140527 01:48:00< iceiceice> wml / lua would always get sanitized names
20140527 01:48:08< iceiceice> theres onyl a few places they can get the names from anyways
20140527 01:48:30< iceiceice> i woudl think that save games dont need tob e sanitized
20140527 01:48:35< iceiceice> or even old replays, it doesnt matter
20140527 01:48:42< iceiceice> if they arent sanitifzed everything will just work as it is
20140527 01:49:07< iceiceice> all that would have to happen is that when wml or lua stores a side they get a sanitized string,
20140527 01:49:17< iceiceice> and make sure then when leaders names are intiailzied they are getting a sanitized string
20140527 01:49:51< iceiceice> idk maybe theres a leak i'm missing but i cant think of what it is
20140527 01:50:18< iceiceice> i guess it depends a bit on how the save dialogs work?
20140527 01:50:28< iceiceice> if they read the names from [side] or from units
20140527 01:52:10< iceiceice> the idea is that everything would work exactly as is, except that units and wml variables would have the sanitized values 
20140527 01:52:33< iceiceice> and the gui elements that are active *while playing the game* which is only a few, should make sure to parse
20140527 01:52:46< iceiceice> i wouldnt change the values in team objects for example
20140527 01:53:04< iceiceice> *lua variables also
20140527 01:54:00< gfgtdf> iceiceice: hm i still fear the the complication of the code isn't worth it.
20140527 01:54:04< iceiceice> ok
20140527 01:54:31< iceiceice> thats a pretty good point :)
20140527 01:55:48< iceiceice> gfgtdf: did you see that master is broken atm?
20140527 01:56:08< gfgtdf> iceiceice: ye i'll fix
20140527 02:08:47< gfgtdf> iceiceice: it's just a raning abouit an unused member and it onyl accect one of teh builds
20140527 02:08:52< gfgtdf> iceiceice: but ill fix it
20140527 02:20:18-!- sachith500 [~kvirc@112.134.58.128] has joined #wesnoth-dev
20140527 02:26:01-!- Sulfur [~Miranda@p5B008507.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140527 02:26:33< irker669> wesnoth: gfgtdf wesnoth:master c621bfde1400 / src/ (playmp_controller.cpp playsingle_controller.cpp playturn.cpp playturn.hpp): remove turn_info::team_num_ http://git.io/37WmCg
20140527 02:26:35< irker669> wesnoth: gfgtdf wesnoth:master e80fc181aea8 / src/ (5 files): simplfy the use of turn_info http://git.io/TSci2g
20140527 02:26:37< irker669> wesnoth: gfgtdf wesnoth:master 0f5dc4febb44 / data/test/scenarios/prestart_settings.cfg wml_test_schedule: Merge branch 'master' of https://github.com/wesnoth/wesnoth http://git.io/9Xrg_w
20140527 02:26:44< gfgtdf> iceiceice: ^
20140527 02:30:01-!- Ivanovic_ [~ivanovic@frnk-5f74d5d8.pool.mediaWays.net] has joined #wesnoth-dev
20140527 02:32:04-!- groggy [~chatzilla@75-131-166-139.dhcp.spbg.sc.charter.com] has joined #wesnoth-dev
20140527 02:33:04< gfgtdf> iceiceice: (that's not trelate dto the timer thing just to the build)
20140527 02:33:04-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 276 seconds]
20140527 02:33:55-!- Ivanovic_ is now known as Ivanovic
20140527 02:37:39-!- gfgtdf [~chatzilla@f054137115.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 29.0.1/20140506152807]]
20140527 02:39:55-!- Necrosporus_ is now known as Necrosporus
20140527 02:40:38-!- sachith500 [~kvirc@112.134.58.128] has quit [Read error: Connection reset by peer]
20140527 03:00:02-!- travis-ci [~travis-ci@ec2-54-227-86-191.compute-1.amazonaws.com] has joined #wesnoth-dev
20140527 03:00:02< travis-ci> [travis-ci] wesnoth/wesnoth#2815 (master - 0f5dc4f : gfgtdf): The build was fixed.
20140527 03:00:02< travis-ci> [travis-ci] Build details : http://travis-ci.org/wesnoth/wesnoth/builds/26093033
20140527 03:00:02-!- travis-ci [~travis-ci@ec2-54-227-86-191.compute-1.amazonaws.com] has left #wesnoth-dev []
20140527 03:10:50-!- sachith500 [~kvirc@112.134.58.128] has joined #wesnoth-dev
20140527 03:11:40-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140527 03:17:19-!- Sulfur [~Miranda@p5B008507.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20140527 03:25:31-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Ping timeout: 240 seconds]
20140527 03:34:00-!- kex [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140527 03:34:33-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140527 03:35:27< irker669> wesnoth: Chris Beck wesnoth:master f664b4e5af16 / data/test/scenarios/facing.cfg wml_test_schedule: add test of [modify_unit] facing= attribute http://git.io/KJxZug
20140527 03:35:29< irker669> wesnoth: Chris Beck wesnoth:master 991d334388c8 / src/ (6 files): Merge branch 'master' of git://github.com/wesnoth/wesnoth http://git.io/T_mreg
20140527 03:38:14-!- groggy [~chatzilla@75-131-166-139.dhcp.spbg.sc.charter.com] has quit [Remote host closed the connection]
20140527 03:38:43-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 240 seconds]
20140527 03:55:47-!- cib [~cib@p5DD21C4B.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140527 03:56:11-!- cib is now known as Guest82786
20140527 04:00:28-!- Guest82786 [~cib@p5DD21C4B.dip0.t-ipconnect.de] has quit [Client Quit]
20140527 04:00:48-!- cib_ [~cib@p5DD21C4B.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140527 04:01:22-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Traveling until May 31]
20140527 04:08:25-!- sachith500 [~kvirc@112.134.58.128] has quit [Read error: Connection reset by peer]
20140527 04:09:12-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Remote host closed the connection]
20140527 04:17:51-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140527 04:24:03< iceiceice> gfgtdf: do you think that the directions that units are facing should be synced?
20140527 04:24:18< iceiceice> i never realized that if its not specified, its just based on unsynced rand()
20140527 04:25:01-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 240 seconds]
20140527 04:26:52-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140527 04:50:21-!- sachith500 [~kvirc@112.134.58.128] has joined #wesnoth-dev
20140527 05:06:21-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20140527 05:38:30-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20140527 05:45:14-!- cib_ [~cib@p5DD21C4B.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20140527 05:54:56-!- sachith500 [~kvirc@112.134.58.128] has quit [Ping timeout: 246 seconds]
20140527 05:57:00-!- Ivanovic [~ivanovic@frnk-5f74d5d8.pool.mediaWays.net] has quit [Changing host]
20140527 05:57:00-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20140527 06:08:14-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Read error: Connection reset by peer]
20140527 06:08:43-!- sachith500 [~kvirc@112.134.58.128] has joined #wesnoth-dev
20140527 06:08:43-!- sachith500 [~kvirc@112.134.58.128] has quit [Client Quit]
20140527 06:08:52-!- sachith500 [~kvirc@112.134.58.128] has joined #wesnoth-dev
20140527 06:09:08< zookeeper> iceiceice, yes, they should definitely be synced
20140527 06:09:48< zookeeper> otherwise you can't make some things be dependant on direction, which is surely something some UMC somewhere would like to do (like for a proper backstab ability)
20140527 06:12:17-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140527 06:15:44< iceiceice> zookeeper: do you consider that a bug?
20140527 06:15:53< iceiceice> i think it would be a one line change to sync in 1.12
20140527 06:17:09< zookeeper> not necessarily, but it's not stated to be unsynced either so the assumption is going to be that it is.
20140527 06:17:41-!- sachith500 [~kvirc@112.134.58.128] has quit [Ping timeout: 246 seconds]
20140527 06:30:54-!- sachith500 [~kvirc@112.134.58.128] has joined #wesnoth-dev
20140527 06:40:20-!- cib [~cib@132.231.178.13] has joined #wesnoth-dev
20140527 06:40:44-!- cib is now known as Guest16600
20140527 06:46:03-!- sachith500 [~kvirc@112.134.58.128] has quit [Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/]
20140527 07:00:58-!- boucman_work [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20140527 07:14:27< iceiceice> zookeeper: ok
20140527 07:14:29< iceiceice> gfgtdf: ^
20140527 07:16:49< irker669> wesnoth: Ignacio R. Morelle glamdrol:master 60a341e136e7 / Glamdrol.php: Remove AdSense code, we haven't had ads for years http://git.io/EV9Hfg
20140527 07:20:26-!- mjs-de [~mjs-de@f049244162.adsl.alicedsl.de] has joined #wesnoth-dev
20140527 07:30:14-!- mjs-de [~mjs-de@f049244162.adsl.alicedsl.de] has quit [Ping timeout: 258 seconds]
20140527 07:35:37-!- mjs-de [~mjs-de@f049244162.adsl.alicedsl.de] has joined #wesnoth-dev
20140527 07:35:54-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has joined #wesnoth-dev
20140527 07:40:51-!- sachith500 [~kvirc@112.134.58.128] has joined #wesnoth-dev
20140527 07:44:43-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 240 seconds]
20140527 07:45:22< irker669> wesnoth: Chris Beck wesnoth:master 30c179b92da2 / src/ (7 files): refactor enum casts: prefer lexical cast default and cfg["x"].str() http://git.io/I1GxLg
20140527 07:52:47-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20140527 07:59:25-!- Guest16600 [~cib@132.231.178.13] has quit [Ping timeout: 252 seconds]
20140527 08:07:26-!- boucman_work [~rosen@wesnoth/developer/boucman] has quit [Ping timeout: 255 seconds]
20140527 08:21:40-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140527 08:25:14-!- molgrum [~molgrum@212.85.89.43] has quit [Read error: Connection reset by peer]
20140527 08:25:22-!- sachith500 [~kvirc@112.134.58.128] has quit [Ping timeout: 276 seconds]
20140527 08:26:26-!- molgrum [~molgrum@212.85.89.43] has joined #wesnoth-dev
20140527 08:27:39-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 252 seconds]
20140527 08:29:49-!- shadowm_desktop [ignacio@186.9.66.169] has joined #wesnoth-dev
20140527 08:30:22-!- shadowm_desktop is now known as Guest38415
20140527 08:45:18-!- EdB [~edb@85.69.242.6] has joined #wesnoth-dev
20140527 08:49:37-!- boucman_work [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20140527 09:01:07-!- Guest38415 [ignacio@186.9.66.169] has quit [Ping timeout: 245 seconds]
20140527 09:19:41-!- EdB [~edb@85.69.242.6] has quit [Quit: Konversation terminated!]
20140527 09:21:41-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: End Transmission.]
20140527 09:28:41-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Ping timeout: 258 seconds]
20140527 09:41:13< AI0867> iceiceice: Which compiler failed to terminate on assert? We blacklist NDEBUG for that exact reason
20140527 09:51:19-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140527 10:19:01-!- Guest16600 [~cib@132.231.178.13] has joined #wesnoth-dev
20140527 10:27:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds]
20140527 10:27:03-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140527 10:44:13-!- mjs-de [~mjs-de@f049244162.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds]
20140527 10:45:59-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140527 10:47:01-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140527 10:50:08-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has joined #wesnoth-dev
20140527 10:51:23-!- stikonas__ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140527 10:51:53-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 255 seconds]
20140527 10:52:18-!- stikonas__ is now known as stikonas
20140527 10:53:14-!- Guest16600 [~cib@132.231.178.13] has quit [Remote host closed the connection]
20140527 10:58:49-!- mjs-de [~mjs-de@f049244162.adsl.alicedsl.de] has joined #wesnoth-dev
20140527 11:06:47-!- mjs-de [~mjs-de@f049244162.adsl.alicedsl.de] has quit [Ping timeout: 252 seconds]
20140527 11:10:18-!- irker669 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20140527 11:18:26-!- mjs-de [~mjs-de@f049244162.adsl.alicedsl.de] has joined #wesnoth-dev
20140527 11:23:13-!- kex [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140527 11:23:49-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140527 11:28:08-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 255 seconds]
20140527 11:42:05-!- EdB [~edb@85.69.242.6] has joined #wesnoth-dev
20140527 11:47:08-!- irker163 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20140527 11:47:08< irker163> wesnoth: Alexander van Gessel wesnoth:1.12 c55f3cd4c74b / src/unit_display.cpp: Move animationless moving unit hiding to a more appropriate place http://git.io/ybtjMQ
20140527 11:56:46< irker163> wesnoth: Alexander van Gessel wesnoth:master e701fe68b03b / src/unit_display.cpp: Move animationless moving unit hiding to a more appropriate place http://git.io/p1eTpA
20140527 12:29:37-!- gfgtdf [~chatzilla@f054137115.adsl.alicedsl.de] has joined #wesnoth-dev
20140527 12:30:49< gfgtdf> iceiceice: ye maybe synced facing direction woud be good
20140527 12:31:19< gfgtdf> iceiceice: but also not that this will break compability once again sice the random results will be shifted by one.
20140527 12:32:19< gfgtdf> iceiceice: also note that this will make undoing recuits impossible n any case (in current master we ccan for example undo recuits of ghosts)
20140527 12:33:00< gfgtdf> iceiceice: maybe we should not make then random but instead "look away from the recuiter" or something ?
20140527 12:33:51< gfgtdf> AI0867: about asserts in msvc: 20140526 22:21:58< gfgtdf> iceiceice: hm maybe idk how it is on other os, on windows i'll get a pop-up giving me the options "terminate" "ignore" "attach debugger"
20140527 12:34:46-!- TooLmaN [~TooLmaN@mx1.thomsonplastics.com] has joined #wesnoth-dev
20140527 12:35:52< AI0867> gfgtdf: are recruit facings random?
20140527 12:36:13< AI0867> https://github.com/wesnoth/wesnoth/pull/29
20140527 12:37:25< gfgtdf> AI0867: from 20140527 
20140527 12:37:26< gfgtdf> 04:24:03< iceiceice> gfgtdf: do you think that the directions that units are facing should be synced?
20140527 12:37:28< gfgtdf> 20140527 04:24:18< iceiceice> i never realized that if its not specified, its just based on unsynced rand()
20140527 12:37:29< gfgtdf> i assum that it is
20140527 12:38:21< AI0867> gfgtdf: it's 20140527 here
20140527 12:38:28< AI0867> 201405271438 to be precise
20140527 12:38:47-!- EdB [~edb@85.69.242.6] has quit [Quit: Konversation terminated!]
20140527 12:39:53< gfgtdf> AI0867: ye its the same date here to, the data obove was from the quote
20140527 12:40:25< gfgtdf> AI0867: the pr 29 still seelms to use rand() whih can lead to unsynced facins it seems
20140527 12:40:30< gfgtdf> eems
20140527 12:40:35< gfgtdf> seems
20140527 12:42:11< AI0867> myeah
20140527 12:42:26< AI0867> I haven't looked at it very much, but it might be a good place to start
20140527 12:43:07< gfgtdf> AI0867: but facing toward the next enemy unit seems to be a good idea to me.
20140527 12:49:17< zookeeper> umm, why would syncing directions mean invalidating undo?
20140527 12:50:18< zookeeper> if undead had randomly generated names, would recruiting one of those not be undoable?
20140527 12:53:06< gfgtdf> zookeeper: yes currently calling synced rng causes immideatley undoing impossibl
20140527 12:53:21< zookeeper> urgh, that's just... well, dumb really :P
20140527 12:54:16< gfgtdf> zookeeper: well calling teh synced rng causes asking teh server for a rng whih is sended too all cliens by teh server
20140527 12:54:38< gfgtdf> zookeeper: you cannot undo something that has been sended to all clients already
20140527 12:54:47< gfgtdf> asking for a seed*
20140527 12:54:49< AI0867> unrelated bug: trait descriptions (and possibly others) may not be properly updated if extra weapons that they affect are added afterwards
20140527 12:56:30< gfgtdf> zookeeper: previoulsy undoing those also this also caused oos because the rng would be off by 1 in some clients.
20140527 12:57:30< gfgtdf> zookeeper: also in 1.12 we can never undo recruits, we could enable it but it would break compability.
20140527 12:57:50< zookeeper> how about recalls?
20140527 12:58:49< gfgtdf> zookeeper: they are undoable
20140527 12:58:57< zookeeper> great
20140527 12:59:28< gfgtdf> zookeeper: (except for some event without allow_undo or use set_variable=rand)
20140527 13:01:45< irker163> wesnoth: Alexander van Gessel wesnoth:master 038ff82a02d5 / data/scenario-test.cfg: Test case for two interface bugs http://git.io/V7Q8JQ
20140527 13:01:47< irker163> wesnoth: Alexander van Gessel wesnoth:master d8cd6be83cc9 / src/unit_types.cpp: Add _" and " between shared weapon effects. http://git.io/_TlW9w
20140527 13:01:48< AI0867> Necrosporus: ^
20140527 13:02:22< gfgtdf> zookeeper: 6ec8d802608869 and f941c70081019
20140527 13:03:35-!- gfgtdf [~chatzilla@f054137115.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 29.0.1/20140506152807]]
20140527 13:10:08-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140527 13:11:47-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has quit [Quit: Lost terminal]
20140527 13:12:28-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140527 13:14:59-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 255 seconds]
20140527 13:19:04-!- sachith500 [~kvirc@112.134.201.107] has joined #wesnoth-dev
20140527 13:20:57< AI0867> gfgtdf: it looks like #29 only uses rand if no enemies can be found
20140527 13:21:10< AI0867> in which case you might want to face away from the leader isntead
20140527 13:21:23< iceiceice> y that seems simpler
20140527 13:21:36< iceiceice> just use get_relative_dir between priimary and secondary unit
20140527 13:21:48< iceiceice> alternatively, if we want to keep the current behavior but have it synced,
20140527 13:22:02< iceiceice> one thing we could do is have an "undoable" rng used only for fluff things
20140527 13:22:49< AI0867> Coffee_irc: we're discussing PR #29
20140527 13:22:55< AI0867> you may be interested
20140527 13:23:05< iceiceice> idk though i guess when i mentioned last night, zookeeper was saying someone mgiht want to have a backstab ability or something that actually checks the facing parameter, so maybe its not a good idea what i said
20140527 13:23:50< zookeeper> yeah i think facing for recruited units should just be deterministic one way or another
20140527 13:23:51< AI0867> I'd prefer to have it all just deterministic
20140527 13:28:35< AI0867> wesbot: seen Coffee_irc 
20140527 13:28:35< wesbot> AI0867: Queried user last spoke 2d 8h ago.  Coffee_irc is currently in this channel.
20140527 13:37:32-!- TooLmaN [~TooLmaN@mx1.thomsonplastics.com] has quit [Quit: Off to save the world!]
20140527 13:42:24< AI0867> okay, I have a much smaller version of PR #29 locally, which adheres to our requirements
20140527 13:42:35< AI0867> now I just have to write a bunch of unit tests
20140527 13:43:16< AI0867> iceiceice: could you advise me on if and how to make OOS tests here?
20140527 13:43:31< iceiceice> for what case?
20140527 13:43:31< AI0867> s/if/if it's possible to/
20140527 13:43:52< AI0867> well,
20140527 13:44:01< iceiceice> AI0867: all of the tests are automatically replayed to check for oos
20140527 13:44:22< AI0867> case 1: there are enemy units. Face towards the closest one (where distance is reduced by unit level)
20140527 13:44:36< AI0867> case 2: there are no enemy units, but you have a leader. Face away from the leader
20140527 13:44:48< iceiceice> ok
20140527 13:44:51< AI0867> case 3: there are no enemy units and no leader, face towards the center of the map
20140527 13:45:10< AI0867> iceiceice: I mean, how best to trigger OOS (replay failure) if the facings are random
20140527 13:45:43< iceiceice> hmm
20140527 13:45:53< iceiceice> one thing to try is 
20140527 13:46:03< iceiceice> store the variable for which way the unit ends up facing
20140527 13:46:10< iceiceice> then use synchronize choice i guess?
20140527 13:46:34< iceiceice> and you will have the original version in one variable and the replay version in a different variable
20140527 13:47:48< iceiceice> i guess the easiest way to make oos is probably either not having enough gold to recruit? or moving to the wrong spot or something/
20140527 13:48:26< iceiceice> i guess if you are testing recruiting anyways, you could have wml that says "if the new variable and the syncrhonize choice record don't match, then have the leader step off the keep"
20140527 13:48:27< AI0867> could you pastebin me some sample code?
20140527 13:48:39< iceiceice> ok
20140527 13:49:36< iceiceice> so you can also look at this one, its sort of relevant:
20140527 13:49:36< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/data/test/scenarios/break_replay_with_lua_random.cfg
20140527 13:49:49< iceiceice> thats the replay check sanity test one,
20140527 13:50:01< iceiceice> what it does is, call the unsynced lua random every turn, from range (0,200)
20140527 13:50:07< iceiceice> give that amount of gold,
20140527 13:50:12< iceiceice> and recruit woses until you cant anymore
20140527 13:50:41< iceiceice> so in the replay if the number is less than it was in the original version, you wont be able to recruit all the woses you are supposed to so its oos
20140527 13:52:13< iceiceice> i wrote this test of the facing attribute yesterday b/c of a forum post, https://github.com/wesnoth/wesnoth/blob/master/data/test/scenarios/facing.cfg
20140527 13:52:19< iceiceice> i guess i might modify it as follows:
20140527 13:55:43< iceiceice> hmm i guess also could just make an assertion that will fail in the replay?
20140527 13:55:47< iceiceice> i havent tried that but i think it should work
20140527 13:57:57< iceiceice> AI0867: i think something like this should work:
20140527 13:57:57< iceiceice> http://pastebin.com/FLupsh1B
20140527 13:58:33< iceiceice> however, i think actually the current unit test mechanism doesnt check if the replay gives the same answer as the original play of the test...
20140527 13:58:37< iceiceice> however i could patch that easily
20140527 13:58:55< iceiceice> withe current code,
20140527 13:59:00< iceiceice> the thing i wrote could become, instead of ASSERT,
20140527 13:59:02< iceiceice> idk soething like 
20140527 13:59:23< iceiceice> {IF_VAR ... ( [do_command] [move] (leader) (somewhere else) [/move] [/do_command] ) }
20140527 13:59:35< iceiceice> and that should make oos from not being a keep
20140527 14:05:30-!- gfgtdf [~chatzilla@f054137115.adsl.alicedsl.de] has joined #wesnoth-dev
20140527 14:06:01< gfgtdf> iceiceice: the "undoable rng" is current the unsynced 
20140527 14:06:20< iceiceice> gfgtdf: the thing thouhg is,
20140527 14:06:30< iceiceice> it gives different results on differnet machines
20140527 14:06:44< iceiceice> so you could imagine to have an rng with not only "get_next_random"
20140527 14:06:50< iceiceice> but also "put_random_back"
20140527 14:07:01< iceiceice> and allows you to undo actions
20140527 14:07:12< gfgtdf> iceiceice: well it not possible sice get_next_ranom causes send data oer the network immideateöy
20140527 14:07:33< gfgtdf> iceiceice: becasue we want  a seed from the server
20140527 14:07:36< iceiceice> idk this one might not need to talk to network at all
20140527 14:07:42< iceiceice> just take one seed at the start and never reseed
20140527 14:08:00< iceiceice> the point is, nothing important for strategy shoudl come that way, it would just be for fluff that we want to have synchronized
20140527 14:08:06< iceiceice> but maybe its a bad idea anyways for other reasons
20140527 14:09:20< iceiceice> like zookeeper mentioned, someone might want to make a mod where stuff like "facing" has strategic importance
20140527 14:09:29< iceiceice> so deterministic is probably better
20140527 14:10:25< gfgtdf> iceiceice: in theory we sill have the "determinisic rng" which we for example use for [side] initilisation that doesnt casue network traffic. But the general thouht was eigher it has no effect on the gamestate (only visual) in this case rand() is the choice or it has and in this case it is information gain which shouldnt be undoable.
20140527 14:11:10< iceiceice> y so for the visual stuff its a bit funny
20140527 14:11:24< iceiceice> i think that when you reload games for instance, units can be facing different directions or smth like this?
20140527 14:11:33< iceiceice> i cant remember now.. i feel like thats a thing though
20140527 14:11:41< gfgtdf> iceiceice: no in the current implemenation not
20140527 14:11:44< iceiceice> ok
20140527 14:11:48< iceiceice> in 1.10 though?
20140527 14:11:52< iceiceice> or did i totally make it up
20140527 14:11:55< gfgtdf> idk about 1.10
20140527 14:11:56< iceiceice> ok
20140527 14:12:11< iceiceice> maybe i just got suspcious for no reason when i reloaded once but its slightly disorienting
20140527 14:12:30< iceiceice> if you are trying to figure out if your reloaded game worked and some unit is facing differently but nothing else is wrong...
20140527 14:12:34< iceiceice> might have been in my head though
20140527 14:12:36< AI0867> 20140527 16:12:10 warning scripting/lua: function returned to wesnoth.synchronize_choice a table which was partially invalid
20140527 14:12:54< iceiceice> AI0867: hmm 
20140527 14:13:04< AI0867> maybe store only the facing?
20140527 14:13:04< iceiceice> i guess my lua is bad, i dont actually know lua :X
20140527 14:13:04< gfgtdf> AI0867: ye that function passes to sync choice have to return a vlid wml table
20140527 14:13:50< iceiceice> gfgtdf: do you see a bug here? http://pastebin.com/FLupsh1B
20140527 14:14:11< AI0867> I can't get it to fail with a pre-patch version of wesnoth...
20140527 14:14:39< gfgtdf> iceiceice: hmm that looks valid t teh first look
20140527 14:15:11< iceiceice> AI0867: it looks like the unit test mechanism actually does check for failure of the test on replay
20140527 14:15:14< iceiceice> so i did it right the first time
20140527 14:15:47< iceiceice> hmm can you send your code in a pastebin?
20140527 14:18:10< iceiceice> zookeeper, AI0867: so besides the recruit code,
20140527 14:18:19< iceiceice> there's also code that just makes a unit, like {UNIT ...}
20140527 14:18:26< iceiceice> i think that also generates unsynced random for facing
20140527 14:19:16< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/unit.cpp#L326
20140527 14:19:26< gfgtdf> iceiceice: also using {UNIT } which generates random traity/names also autiomaticly causes the current action to be non undoable.
20140527 14:19:26< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/unit.cpp#L586
20140527 14:19:43< iceiceice> y thats true
20140527 14:20:02< iceiceice> but if we're now deciding that in some mod, unit.facing could affect a custom backstab special or something,
20140527 14:20:10< iceiceice> that would go out of sync
20140527 14:20:15< zookeeper> that needs to be deterministic as well
20140527 14:20:18< gfgtdf> iceiceice: ye it would
20140527 14:20:29< zookeeper> well, that or just use synced random
20140527 14:21:02< zookeeper> if you create a unit in an event then there's no way that event is going to be undoable anyway
20140527 14:21:38< gfgtdf> zookeeper: i tihnk (not sure) that you can pass an exipit name/traits to unit creation?
20140527 14:21:45< zookeeper> yes
20140527 14:21:55< zookeeper> you can create whatever kind of unit you want, naturally
20140527 14:23:05< gfgtdf> zookeeper: in that case the rng be involved and teh action should be undoable
20140527 14:23:12< gfgtdf> isnt involved
20140527 14:23:33< iceiceice> idk i think we should have an 'undoable rng'
20140527 14:23:39< iceiceice> thats just rand with a buffer attached
20140527 14:23:44< zookeeper> no, the game cannot know how to undo the unit creation
20140527 14:23:53< iceiceice> and grep through and replace rand() calls with that
20140527 14:24:04< iceiceice> in most cases
20140527 14:24:18< iceiceice> and i guess add to the undo code also
20140527 14:25:10< iceiceice> because then none of that stuff will become OOS vectors in mp
20140527 14:25:51< iceiceice> hmm i guess in case of our rand,
20140527 14:25:53< gfgtdf> zookeeper: hmm but the engine will accpet [allow_undo] (in 1.13) for example in case you just create a unit to test teh damage remove it after, and modify the recalled unit acording to that value
20140527 14:25:56< irker163> wesnoth: Alexander van Gessel wesnoth:1.12 03a03ad8fef7 / src/unit_types.cpp: Add _" and " between shared weapon effects. http://git.io/rgpIOg
20140527 14:26:00< iceiceice> we can even explicitly invert the state step function
20140527 14:26:05< iceiceice> so we wouldnt need a buffer
20140527 14:26:33< gfgtdf> iceiceice: ut note that currently rand() is mainly used by only grahical things
20140527 14:26:45< gfgtdf> iceiceice: especiyl or things taht onyl happen one one client
20140527 14:26:47< iceiceice> y but are they things that can be read by wml?
20140527 14:27:52< gfgtdf> iceiceice: well assume: local result = wesnoth.synchronize_choice(
20140527 14:27:54< gfgtdf>                   function()
20140527 14:27:55< gfgtdf>                     return { value = math.random(200) }
20140527 14:27:57< gfgtdf>                   end)
20140527 14:27:59< gfgtdf> if we used a synced but undoble rang here we would immideately get oos because tone client of off by one rng call
20140527 14:28:02< gfgtdf> one
20140527 14:28:13< iceiceice> oh
20140527 14:28:18< iceiceice> i'm not saying to use it in lua rng
20140527 14:28:28< iceiceice> or to allow wml to access the unodable one
20140527 14:28:35< iceiceice> just like, for facing or some other things
20140527 14:28:44< iceiceice> maybe names?
20140527 14:28:51< gfgtdf> iceiceice: names are synced
20140527 14:28:57< iceiceice> y but is that necessary?
20140527 14:29:04< iceiceice> its just a graphical thing
20140527 14:29:24< gfgtdf> iceiceice:  well wml can read names, i think it was mattsc who made names sanced
20140527 14:29:32< iceiceice> hmm
20140527 14:29:45< iceiceice> idk if we made names undoable,
20140527 14:29:49< iceiceice> then you could undo wose recruits
20140527 14:29:53< iceiceice> same as skeletons
20140527 14:30:10< gfgtdf> iceiceice: SKELETIONS HAVE NAMES ß
20140527 14:30:14< gfgtdf> sry for caps
20140527 14:30:17< gfgtdf> acidently
20140527 14:30:20< zookeeper> gfgtdf, right, i guess so
20140527 14:30:51< iceiceice> hmm well if names are important enought o sync then why is facing not important enough to sync?
20140527 14:31:09< gfgtdf> i thought tthe plan ws to make it deterministic
20140527 14:31:17< iceiceice> ok
20140527 14:32:08< gfgtdf> iceiceice: the curent synced rng is smarth enough t notice whether we are in a syncronize choice and calls rand() in this case, so we can create units inside a synconize choice
20140527 14:32:24< gfgtdf> iceiceice: and delete then later ..
20140527 14:33:16< gfgtdf> iceiceice: but foreample insode a synconize choice it doesnt matter whether to call math.random or halper.rand
20140527 14:34:52< AI0867> for some reason, this keeps failing when the recently recruited unit is actually facing ne
20140527 14:34:55< AI0867> {ASSERT ({VARIABLE_CONDITIONAL unit.facing equals ne)})}
20140527 14:35:03< AI0867> ideas?
20140527 14:36:03< iceiceice> should ne be in quotes?
20140527 14:36:16< iceiceice> hmm so another thing you can do,
20140527 14:36:18< iceiceice> run it in --showgui
20140527 14:36:24< iceiceice> then type :debug , :inspect
20140527 14:36:28< iceiceice> and see whats going on
20140527 14:36:32< AI0867> I did
20140527 14:36:35< AI0867> facing does equal ne
20140527 14:36:49< iceiceice> oh theres a typo
20140527 14:36:52< iceiceice> )} should be })
20140527 14:36:57< iceiceice> orr..
20140527 14:37:01< iceiceice> idk theres something mismatched
20140527 14:37:05< AI0867> quotes don't help
20140527 14:37:08< iceiceice> the thing after ne should be a }
20140527 14:37:14< iceiceice> to match {VARIABLE_CONDITIONAL
20140527 14:37:35< gfgtdf> ye thereis one ( but two )
20140527 14:37:38< AI0867> there it is
20140527 14:37:44< AI0867> mismatched parens
20140527 14:38:39< AI0867> does [recruit] in replay mode also contain the facing?
20140527 14:38:53< AI0867> probably not...
20140527 14:39:10< AI0867> so then why do all units seem to recruit in ne mode in my old binary?
20140527 14:39:59< gfgtdf> AI0867: it doesnt contain the facing
20140527 14:40:20< gfgtdf> AI0867: usualy the same code should be executed in replays or whe a human  recruites
20140527 14:40:52< iceiceice> AI0867: most of that kind of stuff, that actually implements the change, is in synced_commands now
20140527 14:41:01< iceiceice> *synced_commands.cpp
20140527 14:58:19-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140527 15:01:06-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140527 15:01:23-!- kex [~kex@89.205.75.19] has quit [Read error: Connection reset by peer]
20140527 15:02:12-!- gfgtdf [~chatzilla@f054137115.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 29.0.1/20140506152807]]
20140527 15:15:33-!- TooLmaN [~TooLmaN@mx1.thomsonplastics.com] has joined #wesnoth-dev
20140527 15:18:50< AI0867> iceiceice, gfgtdf: I can't find a way to test the codepath where leader_loc is map_location::null_location
20140527 15:19:03< AI0867> as I can't recruit in that case
20140527 15:19:17< AI0867> hmm, maybe recalls?
20140527 15:19:35< iceiceice> idk maybe can remove the leader in precrecruit event?
20140527 15:19:38< iceiceice> idk if that even makes sense
20140527 15:21:02< AI0867> that *might* work
20140527 15:28:34-!- sachith500 [~kvirc@112.134.201.107] has quit [Read error: Connection reset by peer]
20140527 15:30:58< irker163> wesnoth: Alexander van Gessel wesnoth:master 311d7bad807a / src/actions/create.cpp: Make recruit facing direction deterministic http://git.io/xX2Txg
20140527 15:31:00< irker163> wesnoth: Alexander van Gessel wesnoth:master 4d7de12e4735 / data/test/scenarios/recruit_facing.cfg wml_test_schedule: Unit tests for deterministic unit facings http://git.io/ROX2BA
20140527 15:31:03< AI0867> gfgtdf, iceiceice, Coffee_irc: ^
20140527 15:35:01-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140527 15:52:39-!- riksteri [~riksteri@dsl-tkubrasgw3-54f96b-216.dhcp.inet.fi] has joined #wesnoth-dev
20140527 15:53:23-!- boucman_work [~rosen@wesnoth/developer/boucman] has quit [Ping timeout: 255 seconds]
20140527 16:07:49< timotei> store.steampowered.com/app/202090/ :D
20140527 16:14:40< AI0867> what about it?
20140527 16:32:45-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Ping timeout: 252 seconds]
20140527 16:35:44-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Traveling until May 31]
20140527 16:38:46-!- iceiceice [~chris@207-237-132-91.ny.subnet.cable.rcn.com] has joined #wesnoth-dev
20140527 16:42:57-!- TooLmaN [~TooLmaN@mx1.thomsonplastics.com] has quit [Quit: Off to save the world!]
20140527 16:43:31-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has joined #wesnoth-dev
20140527 16:46:35-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has quit [Quit: leaving]
20140527 16:54:32-!- sachith500 [~kvirc@112.134.201.107] has joined #wesnoth-dev
20140527 17:04:03< Necrosporus> Do you think it's better to use 1.11.15 or HEAD to play and report bugs?
20140527 17:04:18-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20140527 17:05:57< vultraz> either works
20140527 17:06:25< iceiceice> they aren't that much diverged yet, although they are getting more so...
20140527 17:06:33< iceiceice> also by HEAD you mean master, right?
20140527 17:06:47< iceiceice> git checkout HEAD doesn't actually do anything
20140527 17:06:52< Necrosporus> 1.12 with latest commits
20140527 17:06:54-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20140527 17:07:07< Necrosporus> git checkout 1.12 && git pull ?
20140527 17:07:18< Necrosporus> or even git fetch && git checkout 1.12 && git pull ?
20140527 17:07:26-!- sachith500 [~kvirc@112.134.201.107] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140527 17:07:31< iceiceice> y that works
20140527 17:07:42< iceiceice> git checkout HEAD^ will go to the commit previous to where you currently are,
20140527 17:07:48< iceiceice> git checkout HEAD^^ will go back two commits...
20140527 17:07:55< iceiceice> but git checkout HEAD doesn't have an effect i dont think
20140527 17:07:59< iceiceice> at least not on the HEAD
20140527 17:08:07< Necrosporus> What's difference between it and HEAD~ ?
20140527 17:08:16< iceiceice> i dont actually know sry
20140527 17:08:22< iceiceice> i never use that syntax
20140527 17:12:52< c74d> `commit~` is the parent of `commit`.
20140527 17:12:56< c74d> `commit^` is the parent of `commit`.
20140527 17:13:20< c74d> `commit~~` is the parent of `commit~`.
20140527 17:13:32< c74d> `commit^^` is the *second parent* of `commit`.
20140527 17:13:50< c74d> (A merge commit will have multiple parents.)
20140527 17:14:08< c74d> `commit~~~` is the parent of `commit~~`.
20140527 17:14:20< c74d> `commit^^^` is the third parent of `commit`.
20140527 17:14:28< c74d> And so on.
20140527 17:15:03< Necrosporus> commit^^~ is parent of second parent of commit?
20140527 17:15:18< c74d> So, `git checkout HEAD^^` will not go back two commits.
20140527 17:15:22< c74d> Necrosporus, yes.
20140527 17:16:11< Necrosporus> what if I have linear chain of commit and only one branch? it would be same as commit^ ?
20140527 17:16:39< c74d> One can also have `commit~3` (or whatever number), which is the same as `commit~~~`.
20140527 17:17:42< c74d> No, I think if `commit` has only a single parent then trying to get its `n`-th parent with `n > 1` would fail.
20140527 17:18:26< c74d> …Er.
20140527 17:18:59-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140527 17:19:18< c74d> Apparently, `^` does the same thing as `~` when the commit has only a single parent. :/
20140527 17:20:48< c74d> I advise the exclusive use of `~` in general, reserving `^` for when one wants to get a parent other than the first.
20140527 17:22:23< iceiceice> mordante:
20140527 17:22:29< iceiceice> i can reliably reproduce the inspect dialog assertion failure
20140527 17:23:16< c74d> So… `git checkout HEAD^^` *will* go back two commits if `HEAD` has only a single parent, but its use for such is discouraged (not just by me).
20140527 17:26:44< c74d> Moving to the start of this discussion, `HEAD` only has meaning within a repository; alternatively, `HEAD` has as much meaning across multiple repositories as `$PWD` has across multiple shell instances.
20140527 17:27:23-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140527 17:27:34< c74d> Indeed, I think of `HEAD` as being much like one’s current working directory, except in time rather than space.
20140527 17:27:42< Necrosporus> There's a umc dev complaining his lua code make things desynced in #wesnoth
20140527 17:27:49< iceiceice> http://pastebin.com/FF3CCazi
20140527 17:29:33< Necrosporus> iceiceice, do you reproduce it in 1.11.15?
20140527 17:29:38< iceiceice> on master
20140527 17:29:46< Necrosporus> What about 1.11.15?
20140527 17:30:01< iceiceice> hmm so it would require a modification to the procedure,
20140527 17:30:07< iceiceice> because i encountered it when writing a unit test
20140527 17:30:12< iceiceice> and unit tests dont exist on 1.12
20140527 17:30:27< iceiceice> but probably its the same, you could just replace [test] with scenario i guess
20140527 17:31:55-!- vultraz [~chatzilla@124.109.10.167] has quit [Read error: Network is unreachable]
20140527 17:32:38-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20140527 17:32:43-!- Aishiko [~Aishiko@cpe-065-191-176-226.nc.res.rr.com] has quit [Ping timeout: 240 seconds]
20140527 17:36:38-!- Aishiko [~Aishiko@cpe-065-191-176-226.nc.res.rr.com] has joined #wesnoth-dev
20140527 17:41:17-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has quit [Quit: Leaving]
20140527 17:42:36-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20140527 17:48:28-!- DCW [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginm.net] has joined #wesnoth-dev
20140527 17:48:49< irker163> wesnoth: Chris Beck wesnoth:master cad6edf1825e / data/test/scenarios/test_relative_dir.cfg: add comment to test_relative_dir.cfg http://git.io/KSuhAw
20140527 17:56:40< irker163> wesnoth: Chris Beck wesnoth:1.12 447a6162896e / .gitignore: add "do_build_and_tests.sh" to .gitignore http://git.io/YNBVxQ
20140527 18:08:44-!- DCW [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginm.net] has quit [Remote host closed the connection]
20140527 18:09:34-!- fabi__ [~fabi@wesnoth/developer/fendrin] has quit [Quit: Konversation terminated!]
20140527 18:13:04< RiftWalker> In multiplayer_create_engine, the level class contains a copy of the config for a level, and it makes changes to the config. I can't see where that config goes though, after mp_create. Is it used during the game? Am I missing something?
20140527 18:13:18< RiftWalker> makes changes to its copy of the config*
20140527 18:15:27< Soliton> presumably it's sent to the other players upon game start.
20140527 18:15:49< Necrosporus> is there a campaign with khalifate uits or somethig to access them without debug?
20140527 18:16:46< zookeeper> no
20140527 18:16:52< zookeeper> except the era
20140527 18:17:16< Necrosporus> what era?
20140527 18:17:44< happygrue> Necrosporus: you can select "default+khalifate" era when creating a mp (or local) game
20140527 18:17:46< zookeeper> the default+khalifate era, what else?
20140527 18:17:50< iceiceice> Necrosporus: i reproduced on 1.11.15
20140527 18:18:37< iceiceice> can you try to reproduce my report?
20140527 18:18:46< iceiceice> it should be quite easy,
20140527 18:18:54< iceiceice> you simple download my .patch file,
20140527 18:18:56< iceiceice> checkout 1.12
20140527 18:19:00< iceiceice> use git apply to apply the patch
20140527 18:19:18< iceiceice> then launch wesnoth from command line, and should get crash as soon as you click units in inspect from that position
20140527 18:19:43< iceiceice> i get assertion failure and crash every time
20140527 18:24:55< iceiceice> RiftWalker: level is ultimately sent to the server
20140527 18:24:58< iceiceice> in mutliplayer_connect_engine
20140527 18:25:02< iceiceice> update and send diff function
20140527 18:25:19< iceiceice> is used to transmit host side changes to the other connected players while the game is being set up
20140527 18:25:38< iceiceice> when the host sends "[start]" the level is basically finalized and the game begins
20140527 18:26:06< iceiceice> in mp there are some functions in mp_game_utils called things like "level_to_gamestate"
20140527 18:26:11< iceiceice> which initialize the gamestate from the level config
20140527 18:26:17< iceiceice> after that the level is basically discarded
20140527 18:29:13< RiftWalker> Right, I was trying to see specifically how. From what I can tell, it's stored in mp_game settings and accessed from multiplayer.cpp by multiplayer_create::get_parameters. My main question is, after multiplayer create, we've completely stopped using config_manager and are now working from an (editable) copy of our level config?
20140527 18:29:46< RiftWalker> I've pretty much answered my own questions
20140527 18:30:01-!- lipkab [~lipkab@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140527 18:31:07< iceiceice> y thats right i think
20140527 18:31:29< RiftWalker> thanks
20140527 18:33:43-!- TC01_ [~quassel@venus.arosser.com] has joined #wesnoth-dev
20140527 18:33:55-!- TC01_ [~quassel@venus.arosser.com] has quit [Remote host closed the connection]
20140527 18:37:40-!- Aishiko [~Aishiko@cpe-065-191-176-226.nc.res.rr.com] has quit [Ping timeout: 276 seconds]
20140527 18:43:44< iceiceice> mordante: I made a more detailed bug report: https://gna.org/bugs/?22095
20140527 18:44:38-!- Aishiko [~Aishiko@cpe-065-191-176-226.nc.res.rr.com] has joined #wesnoth-dev
20140527 18:58:49-!- gfgtdf [~chatzilla@f054137115.adsl.alicedsl.de] has joined #wesnoth-dev
20140527 19:02:09-!- lipkab [~lipkab@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 258 seconds]
20140527 19:05:49< irker163> wesnoth: gfgtdf wesnoth:master 8a95d36c61fc / src/minimap.cpp: optimize minimap.cpp http://git.io/-3Q4YQ
20140527 19:05:49-!- Kexoth [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140527 19:06:25-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140527 19:10:47-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 252 seconds]
20140527 19:16:17-!- lipkab [~lipkab@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140527 19:20:39-!- lipkab_ [~lipkab@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140527 19:21:12-!- lipkab [~lipkab@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 276 seconds]
20140527 19:23:22-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20140527 19:26:34< irker163> wesnoth: Chris Beck wesnoth:master e5015214d07b / src/game_events/pump.cpp: fix bug in [wml_message] which caused wml errors not to be flushed http://git.io/TXgTSw
20140527 19:31:29-!- lipkab_ [~lipkab@host-91-147-212-189.biatv.hu] has quit [Read error: Connection reset by peer]
20140527 19:31:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140527 19:34:24< irker163> wesnoth: Chris Beck wesnoth:1.12 d4cead0d8775 / src/game_events/pump.cpp: fix bug in [wml_message] which caused wml errors not to be flushed http://git.io/F5Wxag
20140527 19:38:03-!- lipkab [~lipkab@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140527 19:45:25-!- lipkab [~lipkab@host-91-147-212-189.biatv.hu] has quit [Read error: Connection reset by peer]
20140527 19:48:31< irker163> wesnoth: gfgtdf wesnoth:master 28bfa6037c72 / src/minimap.cpp: optimize minimap.cpp http://git.io/Zs8vNQ
20140527 19:54:28-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140527 19:54:50-!- aquileia [2edf524c@gateway/web/freenode/ip.46.223.82.76] has joined #wesnoth-dev
20140527 19:56:22-!- DCW [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginm.net] has joined #wesnoth-dev
20140527 19:56:50-!- prophile [~alynn@oftn/member/prophile] has joined #wesnoth-dev
20140527 19:57:00< aquileia> iceiceice: Just a random idea... is there a flag to run a different core? If so I'd say unit tests should use it for failsafe mode
20140527 19:57:15< irker163> wesnoth: gfgtdf wesnoth:1.12 8d5440756e3e / src/minimap.cpp: optimize minimap.cpp http://git.io/GSZLjQ
20140527 19:57:33< iceiceice> y thats a good idea
20140527 19:57:42< iceiceice> thats more reliable than the old mechanism imo
20140527 19:58:27< iceiceice> it would also be good if we made some tests to sanity check the game_config_manager...
20140527 19:58:39< iceiceice> i dont really have any idea why we cant load start of scenario saves for example
20140527 19:58:47< iceiceice> alternate core may be a good way to figure out whats going on
20140527 19:58:49-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has quit [Quit: leaving]
20140527 20:00:11< aquileia> iceiceice: Well, the failsafe core can't prevent bugs that don't rely on addons I think
20140527 20:00:39< iceiceice> y thats true
20140527 20:00:39< aquileia> But it should be faster, cleaner & safer
20140527 20:02:26< aquileia> by the way... except for Windows all supported platforms have the unix timeout, right?
20140527 20:04:17< aquileia> A fellow student gave me a tip how to implement a proper timeout via the WinAPI, I'll try to test it this evening. Perhaps we can get rid of --timeout?
20140527 20:05:20< aquileia> Or is it necessary for other purposes?
20140527 20:08:51< Ivanovic> gfgtdf: does the optimization of the minimap fix a bug?
20140527 20:09:18< gfgtdf> Ivanovic: well it removed painfull slowness (at least for me) in some cases
20140527 20:10:18-!- DCW [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginm.net] has quit [Quit: DCW]
20140527 20:10:29< gfgtdf> Ivanovic: the calculation for teh minimap terrain is quiet slow if the map is very large, now it is at least not calculated if i disable it
20140527 20:11:27< Ivanovic> hmm, extreme slowness could be counted as bug...
20140527 20:13:07< gfgtdf> Ivanovic: but the slownsess is still there if the minimap tearrain coding is enabled. What we need is a faster alternative of scale_surface_sharp. But with this commit it is at least not calculated if it is disabled.
20140527 20:19:40< iceiceice> aquileia: we could perhaps, its only for tests
20140527 20:19:44-!- riksteri [~riksteri@dsl-tkubrasgw3-54f96b-216.dhcp.inet.fi] has quit [Quit: riksteri]
20140527 20:20:07< iceiceice> Ivanovic, gfgtdf: it was reported as a bug by slowthinker
20140527 20:20:11< iceiceice> on the bug tracker
20140527 20:20:16< shadowm> You mean if the minimap is disabled?
20140527 20:20:42< iceiceice> Ivanovic, gfgtdf: oh but i guess thast only the specific case of lobby
20140527 20:21:44< gfgtdf> shadowm: if if(!preferences_minimap_draw_villages && !preferences_minimap_draw_terrain)  we can skip some calculations.
20140527 20:21:56< shadowm> Ah, those options.
20140527 20:21:59< gfgtdf> iceiceice: no this is not related to lobby
20140527 20:22:08< Necrosporus> cript says: "Unknown condition, ignoring."
20140527 20:22:29< gfgtdf> iceiceice: its more related to slow movement in fog
20140527 20:22:37< Necrosporus> How can I find out what exact condition does lua engine complain at?
20140527 20:22:40< shadowm> Necrosporus: What's the context for that? Executing an [if] action?
20140527 20:22:49< Necrosporus> I do not know
20140527 20:22:50< shadowm> If so, what is the code?
20140527 20:23:11< iceiceice> Necrosporus: thats in my patch?
20140527 20:23:14< Necrosporus> I do not know which event or whatever causes it
20140527 20:23:18< Necrosporus> nope
20140527 20:23:23< iceiceice> its in your add-on?
20140527 20:23:30< Necrosporus> yes
20140527 20:23:34< shadowm> Well, I can't find any matches for "unknown condition" in the 1.12 source.
20140527 20:23:48< shadowm> data/lua/wml/objectives.lua:101:                                wesnoth.message "Unknown condition, ignoring."
20140527 20:23:52< shadowm> Except this.
20140527 20:24:03< Necrosporus> So it's objectives
20140527 20:24:22< shadowm> It seems this means you provided an [objective] that's not condition=win or condition=lose.
20140527 20:24:27< Necrosporus> yes
20140527 20:24:30< iceiceice> i think we shoudl switch most lua error messages like that over to use [wml_message]
20140527 20:24:31< Necrosporus> just forgot to add it
20140527 20:24:35< shadowm> Or possibly forgot to-- yeah.
20140527 20:25:06< Necrosporus> Can't error messages be a little more verbose?
20140527 20:25:11< shadowm> I remember I intended [wml_message] to be used for WML-generated messages, not engine generated messages.
20140527 20:25:27< Necrosporus> Like unknown 'condition in objective <description text>'
20140527 20:25:37< shadowm> I also remember discussing this with somebody but I forgot what the outcome of the discussion was.
20140527 20:26:46< iceiceice> in the other channel, c74d claimed that lua has elaborate backtrace abilities built-in
20140527 20:26:48< shadowm> It may be just me, but I'd find it easier if there was a clear distinction between both message sources.
20140527 20:26:52< iceiceice> there must be some way to enable that stuf anyways
20140527 20:27:17< iceiceice> i'm a total lua noob anyways :)
20140527 20:27:44< iceiceice> why cant we just make a C++ interpreter :)
20140527 20:27:45< Necrosporus> shadowm, I guess he wants lua message to be directed to stderr 
20140527 20:27:50< iceiceice> nooo
20140527 20:27:52< iceiceice> not to stderr
20140527 20:27:52< shadowm> It is already.
20140527 20:27:53< iceiceice> that is bad
20140527 20:28:04< shadowm> No, it's not bad.
20140527 20:28:12< Necrosporus> shadowm, it's not unless --log-debug=scripting/lua is used
20140527 20:28:14< shadowm> It's only bad when it's *only* printed in stderr.
20140527 20:28:20< gfgtdf> iceiceice: shadowm, Ivanovic: i just testes with x16 speed, 200x200 map with fog, 1.13-dev, and my optmisation: with minimap enabled it takes >100 seconds to move from one corner to the other, and with minimap disables it takes <20 secs.
20140527 20:28:28< iceiceice> ii think its better to go through the logger mechanisms
20140527 20:28:36< iceiceice> otherwise the unit tests cant detect when tags implemented in lua are borked
20140527 20:28:46< shadowm> gfgtdf: You mean with those specific minimap options enabled, right?
20140527 20:28:55< iceiceice> maybe there should be a lg::lua_error object
20140527 20:28:57< Necrosporus> shadowm, anyway, the bigger problem is you have to grep source to find the source of error message
20140527 20:29:18< shadowm> The player generally doesn't get the option to disable the minimap and that doesn't happen unless they are using a theme that lacks a minimap widget (like in a few UMC scenarios).
20140527 20:29:18< iceiceice> y and there is a great C++ mechanism which does this already...
20140527 20:29:46< Necrosporus> it doesn't say something like "Lua error: scenario-1.cfg:55 Unknown condition '' " for example
20140527 20:29:48< gfgtdf> shadowmye it tested once with if(!preferences_minimap_draw_villages && !preferences_minimap_draw_terrain)  and once without
20140527 20:30:02< shadowm> When I said stderr I kind of assumed it was though the loggers. ;)
20140527 20:30:06< iceiceice> ok :)
20140527 20:30:12< gfgtdf> shadowmthat are those buttong near teh minimpa image
20140527 20:30:18< gfgtdf> buttons
20140527 20:30:24< iceiceice> afaik lua actually does just print right to std::cout or std::cerr
20140527 20:30:35< iceiceice> or ignores the console enitrely and just writes chat
20140527 20:30:47< Necrosporus> shadowm, do you think it's possible to make error loggin more verbose?
20140527 20:30:51< Necrosporus> and strict
20140527 20:30:52< shadowm> gfgtdf: I know, just saying that it is possible to get rid of the minimap entirely if you want, but it's usually not an option the user has.
20140527 20:31:03< iceiceice> Necrosporus: i implemented the strict
20140527 20:31:20< iceiceice> also the verbose in some sense
20140527 20:31:28< iceiceice> in 1.13, if you run with log-strict=warning,
20140527 20:31:48< iceiceice> hmm
20140527 20:31:51< iceiceice> i guess i had to change it,
20140527 20:31:55< iceiceice> it only affects unit tests right now
20140527 20:31:59< Necrosporus> iceiceice, imagine a case: I have unit_type=something instead of type=something
20140527 20:32:00< iceiceice> i had a versino that would throw an exception in that case
20140527 20:32:22< iceiceice> y so in 1.13 there are more fixes like this
20140527 20:32:33< iceiceice> for instnace if you typed "defeat_condition=no_leaders_left"
20140527 20:32:42< iceiceice> which is an error since it should be no_leader_left,
20140527 20:32:45< Necrosporus> there must be a way to see it immediately instead of 
20140527 20:32:47< iceiceice> in normal play it will go to default,
20140527 20:32:49< iceiceice> in debug mode,
20140527 20:32:54< iceiceice> you will get a gui window warning you
20140527 20:33:04< Necrosporus> that's good
20140527 20:33:12< iceiceice> this is also true if you use the wrong campaign_type or some other fields...
20140527 20:33:15< iceiceice> i guess alignment?
20140527 20:33:16< Necrosporus> though it should be called 'no_leaders_left' I think
20140527 20:33:18< iceiceice> i forget what else i changed over
20140527 20:33:27< iceiceice> y it would be nice if we could support both
20140527 20:33:40< Necrosporus> iceiceice, maybe make it alias?
20140527 20:33:44< iceiceice> y
20140527 20:34:23< iceiceice> y i had a version that would immediately throw an exception if any warning or error occurred,
20140527 20:34:32< iceiceice> but it was bad because the exception has to be thrown before you get the error message :/
20140527 20:35:45< Necrosporus> I have a non-first scenario, should I define leader in [side]?
20140527 20:36:07< Necrosporus> or it's recalled so no need to do that?
20140527 20:37:49< Necrosporus> I guess it's better to define it, so it would fall back to default if there was no leader in recall ?
20140527 20:38:11< Necrosporus> (like player used a cheat to get to the scenario immediately
20140527 20:38:35< Necrosporus> but what about units?
20140527 20:38:52< Necrosporus> If I define a unit, would one from recall replace it automatically?
20140527 20:39:17< iceiceice> gahhhh
20140527 20:39:23< iceiceice> i hate when i forget that i need [then] inside IFVAR
20140527 20:39:29< iceiceice> that is so frustrating
20140527 20:39:52-!- Gambit [~derek@pa-67-234-108-206.dhcp.embarqhsd.net] has joined #wesnoth-dev
20140527 20:39:55-!- Gambit [~derek@pa-67-234-108-206.dhcp.embarqhsd.net] has quit [Changing host]
20140527 20:39:55-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20140527 20:42:05< Necrosporus> iceiceice, use other macro?
20140527 20:42:08< iceiceice> no
20140527 20:42:11< Necrosporus> IFVARTHEN
20140527 20:42:15< iceiceice> i think [if] should report an error when it matches nothing
20140527 20:42:21< iceiceice> liek if there are no [else], or [then]
20140527 20:42:24< iceiceice> i'm looking at implementation
20140527 20:42:48< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/data/lua/wml-tags.lua#L336
20140527 20:42:53< iceiceice> why do we support having multiple [else] tags?
20140527 20:42:55< iceiceice> that's kind of insane
20140527 20:43:51< zookeeper> we do?
20140527 20:44:50< zookeeper> neat
20140527 20:45:34< Necrosporus> iceiceice, if there are it would just execute them like if their content was in one?
20140527 20:45:48< iceiceice> y
20140527 20:46:00< iceiceice> it makes no gramatical sense but w/e
20140527 20:46:03< Necrosporus> but no multiple [then]?
20140527 20:46:14< iceiceice> no you can have multiple [then] also
20140527 20:46:22< iceiceice> if you have multiple [elseif], that only does the first matched one
20140527 20:48:09< Necrosporus> What's the best way to handle hero carriover properly?
20140527 20:49:40< Necrosporus> zookeeper, maybe [if] [have_unit] id=hero search_recall=yes [/] [then] [recall] [/] [else] [unit] ?
20140527 20:50:08< zookeeper> the usual way is the best way
20140527 20:50:25< Necrosporus> just [recall] ?
20140527 20:51:20< zookeeper> yes
20140527 20:52:13< Necrosporus> And then imagine your forgot to make an event with defeat on hero death
20140527 20:52:25< Necrosporus> Then in next scenario assume hero exists
20140527 20:53:23< Necrosporus> There's a campaign I found out I have no hero I should have 7 scenarios away from the point where I should have got it into recall
20140527 20:54:19-!- nurupo is now known as nurupo_
20140527 20:54:21-!- nurupo_ is now known as nurupo
20140527 21:16:12-!- gfgtdf_ [~chatzilla@f050181028.adsl.alicedsl.de] has joined #wesnoth-dev
20140527 21:18:24-!- gfgtdf [~chatzilla@f054137115.adsl.alicedsl.de] has quit [Ping timeout: 265 seconds]
20140527 21:18:37-!- gfgtdf_ is now known as gfgtdf
20140527 21:36:39< gfgtdf> Soliton: about do you knwo why we skip human sides with no units ?
20140527 21:38:56< gfgtdf> iceiceice: from looking at the code it seems liek turn end events are not fires if a side has no units i think this is a bugif a side has no unit 
20140527 21:39:00< gfgtdf> like*
20140527 21:39:03< gfgtdf> fired*
20140527 21:40:18< iceiceice> y i agree that sounds like a bug
20140527 21:45:39< gfgtdf> iceiceice: hm maybe i was wrogn i'll test
20140527 21:47:01< gfgtdf> iceiceice:  no i was right but that onyl aplies to human sides
20140527 21:47:41< Soliton> no idea. probably not a conscious decision. i agree that sounds like it should be changed.
20140527 21:47:43< iceiceice> how did you catch it?
20140527 21:47:55< iceiceice> just stumbled on it?
20140527 21:48:24< gfgtdf> iceiceice: ye i was inspecing teh play_turn method
20140527 21:48:27< gfgtdf> inspecing
20140527 21:48:32< iceiceice> hmm ok
20140527 21:49:16< iceiceice> i would write a unit test but i'm deep in a different one atm...
20140527 21:49:31< iceiceice> that kind of thing is pretty easy to test for though
20140527 21:51:21< gfgtdf> iceiceice: i think the original reason for skipping those sides was teh assumtion that with no units you cannot do anything anyway. And teh side turn end events were implemented after that
20140527 21:51:38< iceiceice> hmm
20140527 21:51:49< gfgtdf> iceiceice: i wonder whether this assumtion si still sure with many posibilites for umc, maybe you shoudl make it optional in 1.13
20140527 21:51:55< gfgtdf> is still*
20140527 21:51:59< gfgtdf> we*
20140527 21:52:04< gfgtdf> s/you/we
20140527 21:53:13< iceiceice> i dont think it makes sense
20140527 21:53:18< iceiceice> if they want to skip a side,
20140527 21:53:21< iceiceice> set controller=null
20140527 21:53:59< Soliton> i wouldn't worry too much about the original intentions.
20140527 21:54:07-!- prophile [~alynn@oftn/member/prophile] has quit [Quit: The Game]
20140527 21:54:16< iceiceice> y i think it should just be as simple and make as much sense as possible
20140527 21:54:41< iceiceice> there are lots of workarounds if someone was relying on that for some reason
20140527 21:54:55< iceiceice> imo it would be very questionable to decide to rely on that anyways
20140527 21:55:12< iceiceice> everything that starts has an end. why would side end turn events not fire when the start ones fired.
20140527 21:55:16< Soliton> i think at some point i added the part where at least the dead sides end the turn since the server couldn't know what sides are dead and got confused which side's turn it was.
20140527 21:56:07< Soliton> why they were skipped to begin with, who knows. some optimisation or stuff didn't work right with no units or whatever...
20140527 21:56:15< happygrue> if humans have turn bell turned on and their turn isn't skipped, is that going to cause lots of popups?
20140527 21:56:37< happygrue> *turn dialog, rather, not turn bell
20140527 21:57:05< Soliton> i don't think the turn bell factors into this.
20140527 21:57:36< iceiceice> its a question i guess what happens when a side's turn is skipped 
20140527 21:57:50< iceiceice> normally i get a popup when its someone elses turn, do we skip that for sides with no units?
20140527 21:57:58< iceiceice> but anyways that shoudl be independent of side turn end events
20140527 21:58:00< Soliton> well, not sure what all happens in play_side().
20140527 21:58:24< gfgtdf> iceiceice: http://gna.org/bugs/?5817
20140527 21:58:49< happygrue> if their turn isn't skipped, won't they have to click end turn to move the game on?
20140527 21:59:09< gfgtdf> happygrue: ye i think that is teh intention fo this bahaviour
20140527 21:59:15< gfgtdf> the*
20140527 21:59:20< gfgtdf> of*
20140527 21:59:28< iceiceice> i think we would still skip their turn
20140527 21:59:34< iceiceice> just fire wml events that should be notified 
20140527 21:59:58< gfgtdf> iceiceice: but in umc it is even possible to do think without units like wml menu hotkeys
20140527 22:00:05< gfgtdf> things
20140527 22:00:46< Soliton> it's also possible to have a hidden dummy unit somewhere...
20140527 22:00:53< iceiceice> y
20140527 22:00:58< iceiceice> so maybe should check like
20140527 22:00:59< iceiceice> if they have no units
20140527 22:01:04< iceiceice> and no wml rihgt clik menu items
20140527 22:01:09< iceiceice> then they clearly cant do anything
20140527 22:01:19< iceiceice> its kind of tedious though
20140527 22:01:46< Soliton> i wouldn't try to find all the things that might be possible to do (now and in the future).
20140527 22:02:11< Soliton> if we want to allow not skipping a turn when there are no units make that an option somewhere.
20140527 22:03:27< Soliton> i wouldn't put too much work into maybe, potentially useful features in the future though.
20140527 22:04:48< Soliton> there are simple workarounds now if needed and if there is a real use case at some point we can add a proper feature for the wanted behaviour.
20140527 22:09:04-!- prophile [~alynn@oftn/member/prophile] has joined #wesnoth-dev
20140527 22:14:42< gfgtdf> iceiceice:  also in https://github.com/wesnoth/wesnoth/blob/master/src/playsingle_controller.cpp#L646 tha log turn_start always hapens but the log_turn_end obnly happens if non interactive
20140527 22:14:56< gfgtdf> iceiceice: i dot knwo whta it does  but it looks strange
20140527 22:15:47< iceiceice> y it is kind of wierd
20140527 22:15:57< iceiceice> i think its not too important though, the aitesting stuff only is used in noninteractive
20140527 22:16:06< iceiceice> all it does is display a console message
20140527 22:16:22< iceiceice> at least im pretty sure
20140527 22:16:29< gfgtdf> iceiceice:  hm ok 
20140527 22:16:33< iceiceice> i'll make sure
20140527 22:16:49< gfgtdf> iceiceice: i'll put the first in a if too then
20140527 22:17:06< gfgtdf> iceiceice: ok so you think we want an autosave if we have no units ?
20140527 22:17:18< iceiceice> i dont see why not
20140527 22:17:41< iceiceice> the ai testing stuff adds a record to the replay
20140527 22:17:45< iceiceice> of the ai's private variables
20140527 22:17:58< iceiceice> actually of stats related to how its doing in the game
20140527 22:18:10< iceiceice> [ai_log] tags
20140527 22:18:18< iceiceice> i think its pretty harmless, probly only want in noninteractive
20140527 22:20:52< gfgtdf> but it confused me thats very mean.
20140527 22:22:46-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20140527 22:25:56< gfgtdf> but i think there is much meaner code here.
20140527 22:30:42-!- Samual_ [~dioteckte@xonotic/core-team/Samual] has quit [Ping timeout: 245 seconds]
20140527 22:33:32< Necrosporus> Why are there so few units wielding and drawing their weapons?
20140527 22:33:54< Necrosporus> IRL a warrior won't hold his weapon out of sheath all the time
20140527 22:34:15< Necrosporus> Anyway, are there any?
20140527 22:34:26-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20140527 22:35:48< shadowm> Because we don't have full-time paid artists.
20140527 22:40:20< irker163> wesnoth: gfgtdf wesnoth:master 3b66f522980a / src/playsingle_controller.cpp: fix skip turn when a side has no units http://git.io/hLvboA
20140527 22:40:30< gfgtdf> iceiceice: ^
20140527 22:41:05-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 255 seconds]
20140527 22:45:16-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-dev
20140527 22:45:32-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has quit [Client Quit]
20140527 22:45:40-!- skyfaller [~skyfaller@ool-2f11697b.dyn.optonline.net] has joined #wesnoth-dev
20140527 22:45:40-!- skyfaller [~skyfaller@ool-2f11697b.dyn.optonline.net] has quit [Changing host]
20140527 22:45:40-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-dev
20140527 22:47:27< Necrosporus> shadowm, but in same time, I see cases where animated sprites are replaced with non-animated
20140527 22:48:12< shadowm> Because we don't have full-time paid artists.
20140527 22:48:41< irker163> wesnoth: gfgtdf wesnoth:master 4eb40973dd35 / src/play_controller.cpp: fix indention & remove commented out code http://git.io/yLmuqQ
20140527 22:48:58< Necrosporus> There's two choices, to replace a sprite or don't replace a sprite
20140527 22:49:36< Necrosporus> I don't think it depends on presence/absence of ft paid artists
20140527 22:50:27< Necrosporus> Why not to wait for new sprite to be animated and then replace instead of replacing right away?
20140527 22:50:35< shadowm> The animations that get or don't get done depend on the presence/absence of full-time paid artists.
20140527 22:50:42< Necrosporus> Yes
20140527 22:51:00< shadowm> Replacing a sprite or not replacing a sprite solely depends on the decisions of our art director.
20140527 22:51:16< Necrosporus> But I'm talking about the cases when a previously animated sprite was replaced with new one which is not animated. Like horsemen and scorpion
20140527 22:51:53< Necrosporus> Jetrel_
20140527 22:52:14< Necrosporus> I wonder, if there's a general policy determining whenever sprites are replaced
20140527 22:55:13< Necrosporus> shadowm, though why are you sure a paid artist would be better than volunteering?
20140527 22:55:22< gfgtdf> iceiceice: when a side gets reassignes is the time also prtopery sended to the new client currently ?
20140527 22:55:43< gfgtdf> in a mp game with a timer
20140527 22:56:32< iceiceice> no i think the new player gets more time
20140527 22:56:46< iceiceice> but i think also no one is complaining about this
20140527 22:56:54< gfgtdf> iceiceice:  so teh new player start with the original time ?
20140527 22:57:09< iceiceice> i dont think the server knows anything about the times ever
20140527 22:57:12< iceiceice> it is entirely managed by your client
20140527 22:57:24< iceiceice> and if your client is gone i think the info is gone
20140527 22:57:30< iceiceice> it goes into save files,
20140527 22:57:32< iceiceice> i know that
20140527 22:57:37< iceiceice> but i think that might be the only place
20140527 22:57:48< iceiceice> i dont know if your save has knwoledge of the other guys time actually
20140527 22:58:34< gfgtdf> iceiceice: hmm i think teh clients send each other the time left sometimes: https://github.com/wesnoth/wesnoth/blob/master/src/replay.cpp#L260
20140527 22:59:09< shadowm> Necrosporus: You have the option to make 200 sprites for project A for free, or make 200 sprites for project B and paid an amount for every sprite done. Which one will you pick?
20140527 22:59:10< gfgtdf> but i think that doesnt happen when a side gets reassigned
20140527 23:00:06< iceiceice> hmm
20140527 23:00:10< iceiceice> i dont think they do anything with this info
20140527 23:00:18< iceiceice> at least i have never observed it
20140527 23:00:20-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20140527 23:00:43< Necrosporus> shadowm, whichever's sprites are appealing for me more... like if I would prefer to draw fantasy warriors or tanks
20140527 23:00:47< iceiceice> i think it just goes into the replay files
20140527 23:00:49< iceiceice> and is otherwise dead code
20140527 23:00:50< iceiceice> http://pastebin.com/dr9RXgc2
20140527 23:00:55< shadowm> Necrosporus: Are you an artist?
20140527 23:01:10< shadowm> Do you have a well-paid job?
20140527 23:01:15< Necrosporus> Isn't code art?
20140527 23:01:41< Necrosporus> Personal questions.
20140527 23:01:48< Necrosporus> Ok, let's say it more clearly
20140527 23:01:51< shadowm> Yeah, I knew I was wasting my time but I didn't expect you to confirm my suspicion that quickly.
20140527 23:02:30< shadowm> Try to put yourself in the shoes of someone who needs to earn money for a living.
20140527 23:02:47< Necrosporus> In this case paid job is more preferable
20140527 23:02:59< iceiceice> Necrosporus: there is no policy
20140527 23:02:59< shadowm> Now try to find a compromise between that and doing an enormous amount of work for free in your spare time.
20140527 23:03:08< iceiceice> the policy is Jetrel's good taste
20140527 23:03:11< iceiceice> he is the dictator
20140527 23:03:13< iceiceice> it has gone well so far
20140527 23:03:27< shadowm> Then you'll realize why a lot of animations simply haven't materialized yet.
20140527 23:03:33< iceiceice> if you want the old sprites put them in your add-on
20140527 23:04:20< Necrosporus> I just wonder if there's any rule to weight a better but single sprite against a set of maybe worse, but animated sprites
20140527 23:07:07< Necrosporus> shadowm, I know there are reason why a lot of animations are missing, my question was about animation which was present but then lost
20140527 23:07:28-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20140527 23:08:56-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has quit []
20140527 23:10:21< iceiceice> ok
20140527 23:10:30< iceiceice> there is something really messed up going on with [chat] and [wml_message]
20140527 23:10:36< iceiceice> in master right now
20140527 23:11:14< iceiceice> http://pastebin.com/uznEUpPu
20140527 23:11:18< iceiceice> it looks like,
20140527 23:11:26< iceiceice> when you set a variable from $array.length,
20140527 23:11:38< iceiceice> it still has value "blank"? until the end of the event?
20140527 23:13:56-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-dev
20140527 23:14:09< iceiceice> i dont even know
20140527 23:14:28< iceiceice> here's version two: 
20140527 23:14:28< iceiceice> http://pastebin.com/hxQTHuNb
20140527 23:14:32< iceiceice> its extremely strange
20140527 23:14:42< iceiceice> if you look in the inspect dialog, you get the right value
20140527 23:14:50< iceiceice> but the [chat] and [wml_message] output is blank
20140527 23:15:04< iceiceice> even in the next event
20140527 23:18:09< iceiceice> is it just that there are no vconfigs in chat and wml_message??
20140527 23:27:59< gfgtdf> iceiceice: i just tested and i git no rpblems
20140527 23:28:23< iceiceice> look at the chat
20140527 23:28:26< iceiceice> and look at the inspect dialog
20140527 23:28:31< iceiceice> * look at console output also
20140527 23:28:54< gfgtdf> iceiceice: also in console output i got teh correct value
20140527 23:29:01< iceiceice> you dont get a blank line?
20140527 23:29:20< iceiceice> and it doesn't say "not 442"?
20140527 23:29:54< iceiceice> oh
20140527 23:30:02< iceiceice> do you have log-debug=wml on?
20140527 23:30:14< iceiceice> here's the output i'm getting that's wierd:
20140527 23:30:25< iceiceice> http://pastebin.com/L9PPNHv7
20140527 23:30:30< iceiceice> i've been inserting engine debugging output,
20140527 23:30:36< iceiceice> it looks like in [wml_message] handler,
20140527 23:30:48< iceiceice> when it parses the config with message = "$answers.length"
20140527 23:30:55< iceiceice> the parsed config has value "message =442"
20140527 23:30:55< gfgtdf> hm no
20140527 23:31:03< iceiceice> but when it parses "get_ans_num"
20140527 23:31:04< iceiceice> it gets ""
20140527 23:31:21< iceiceice> and also i get "not 442" in the tests
20140527 23:31:28< iceiceice> and even in the next event!
20140527 23:31:35< iceiceice> but by the time i get the inspect dialog,
20140527 23:31:39< iceiceice> get_ans_num = 442
20140527 23:31:45< gfgtdf> iceiceice:  what is     get_ans_num supposed to contain ?
20140527 23:31:54< iceiceice> it shoudl be equal to $answers.length
20140527 23:31:55< gfgtdf> hm
20140527 23:32:04< iceiceice> it is set to that using {VARIABLE}
20140527 23:32:32< iceiceice> i'm going to start adding debugging output to get the value of variable set
20140527 23:36:13< gfgtdf> iceiceice: i tested with http://pastebin.com/R084YAh7 and got the expected behavuoir
20140527 23:36:40< iceiceice> that's not the test
20140527 23:36:42< iceiceice> that one is working fine
20140527 23:36:44< iceiceice> the part thats broken is,
20140527 23:36:57< iceiceice> oh
20140527 23:37:06< iceiceice> no so it needs to actually be an array i think
20140527 23:37:29< iceiceice> try it with an actual array so that array.length has to be computed from the array
20140527 23:37:50< gfgtdf> iceiceice: hm i hev nerver used wml arrays before
20140527 23:37:52< gfgtdf> have
20140527 23:38:04< iceiceice> you can use [split] to split a comma separated string
20140527 23:38:07< iceiceice> or [set_variables] i guess
20140527 23:38:08< gfgtdf> iceiceice: i always use serialized lua tables
20140527 23:38:15< gfgtdf> iceiceice: hm ok i'll try
20140527 23:38:15< iceiceice> hmm wel maybe test with that
20140527 23:40:05< gfgtdf> iceiceice: http://pastebin.com/JidUrmir also gabe me the epsected result (3)
20140527 23:40:10< gfgtdf> gave
20140527 23:40:59< iceiceice> ok i'll run your test
20140527 23:42:46< iceiceice> wow
20140527 23:42:48< iceiceice> i thought my machine crashed
20140527 23:42:55< iceiceice> it froze for like 30 seconds
20140527 23:43:02< iceiceice> and said WML error (3) 2
20140527 23:43:16< gfgtdf> WML errror 3 2
20140527 23:43:19< gfgtdf> is espected
20140527 23:43:33< gfgtdf> the means it got two times "Wml error 3"
20140527 23:43:48< gfgtdf> it notices when it gets teh same message multiple times
20140527 23:44:20< gfgtdf> but froze for 30 secns is strange
20140527 23:44:25< iceiceice> i'm going to do a clean build or something
20140527 23:44:44< iceiceice> idk this is wierd my machine has never been unstable like this...
20140527 23:44:49< iceiceice> i think i will reboot
20140527 23:45:35< iceiceice> btrb
20140527 23:45:39-!- iceiceice [~chris@207-237-132-91.ny.subnet.cable.rcn.com] has quit [Remote host closed the connection]
20140527 23:50:10-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has quit [Ping timeout: 265 seconds]
20140527 23:51:38-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has joined #wesnoth-dev
20140527 23:54:13-!- apoi [~andi@85-126-180-242.volume.xdsl-line.inode.at] has quit [Ping timeout: 252 seconds]
20140527 23:59:24-!- sachith500 [~kvirc@112.134.96.45] has joined #wesnoth-dev
--- Log closed Wed May 28 00:00:59 2014