--- Log opened Wed Nov 20 00:00:02 2013
--- Day changed Wed Nov 20 2013
20131120 00:00:02-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 00:02:36-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20131120 00:06:20-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 00:09:45-!- noy_ [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20131120 00:11:40-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 246 seconds]
20131120 00:11:41-!- noy_ is now known as noy
20131120 00:24:09-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20131120 00:24:30-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20131120 00:29:54-!- gfgtdf [~chatzilla@d220041.adsl.hansenet.de] has joined #wesnoth-dev
20131120 00:44:37-!- mattsc [~mattsc@fw.hia.nrc.ca] has quit [Quit: Computer's napping]
20131120 00:47:53-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20131120 00:48:13-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Ping timeout: 252 seconds]
20131120 00:53:24-!- tomreyn [~tomreyn@p549FC93E.dip0.t-ipconnect.de] has joined #wesnoth-dev
20131120 00:53:25-!- tomreyn [~tomreyn@p549FC93E.dip0.t-ipconnect.de] has quit [Changing host]
20131120 00:53:25-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20131120 00:57:42< fabi_> shadowm, AI0867: http://imagebin.org/277959
20131120 00:58:38< AI0867> fabi_: difference is the terrain description?
20131120 00:58:54< AI0867> unrelated: someone complained about hotkeys in the 1.11.7 release topic
20131120 00:59:35< fabi_> Removed the box around the end turn button. Added time of day counter right to the tod image. Extra status box for the terrain description.
20131120 00:59:51< fabi_> Changed the icons of the buttons left to the minimap.
20131120 01:01:12< fabi_> AI0867: That is strange, I did not do much to the system this time.
20131120 01:03:39< fabi_> AI0867: Can't find the complain, would you point me to it, please?
20131120 01:04:58< fabi_> Well, I am getting a bit too little feedback on the whole UI thing. LordBob is not around so I am doing that alone. Don't complain after 1.12 is out if you don't like the new UI.
20131120 01:05:37-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has joined #wesnoth-dev
20131120 01:09:31< AI0867> fabi_: lots of posts from here on: http://forums.wesnoth.org/viewtopic.php?p=562785#p562785
20131120 01:10:33< fabi_> Hmmm
20131120 01:10:44< fabi_> The F5 key used to be hardcoded in the gui2 dialog.
20131120 01:10:59< fabi_> Was it changed to use the hotkey system? Who did it?
20131120 01:12:03-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 252 seconds]
20131120 01:13:28-!- mattsc [~mattsc@154.20.32.246] has joined #wesnoth-dev
20131120 01:14:12-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20131120 01:15:07-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20131120 01:19:24-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 240 seconds]
20131120 01:21:59-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20131120 01:32:26-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20131120 01:35:07< mattsc> Btw, the turn_number behavior is already like this in 1.10, so it's not something that got changed in one of the 1.11 refactoring efforts.
20131120 01:44:36-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20131120 01:48:28-!- shadowm_desktop [ignacio@186.11.28.91] has joined #wesnoth-dev
20131120 01:48:51-!- shadowm_desktop is now known as Guest51292
20131120 01:50:47< shadowm>  /37
20131120 02:07:46-!- Guest51292 [ignacio@186.11.28.91] has quit [Changing host]
20131120 02:07:46-!- Guest51292 [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20131120 02:07:50-!- Guest51292 is now known as shadowm_desktop
20131120 02:17:12-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20131120 02:20:28-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has joined #wesnoth-dev
20131120 02:32:05-!- gfgtdf [~chatzilla@d220041.adsl.hansenet.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]]
20131120 02:54:07< mattsc> Is anybody opposed to me just fixing that turn_number thing myself?  It's really quite simple.
20131120 03:07:26< mattsc> My proposal is this: there's an internal function turn() in C++, and that's what wesnoth.current.turn in Lua shows.  It has value 1 during prestart and start events.
20131120 03:07:46< mattsc> The WML variable turn_number should display that same value.
20131120 03:08:54< mattsc> In addition, this can be modified during prestart and start events, so that should also be handled consistently between Lua and WML.  Both of them should always show whatever the value of turn() is.
20131120 03:09:26< mattsc> Whether turn() should be zero at the beginning of the first prestart event rather than 1 is a separate question that I don't want to touch right now.
20131120 03:12:54< mattsc> I believe that that (setting it to 0 before Turn 1) would cause issues with the ToD manager etc.
20131120 03:13:37-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Quit: tomreyn]
20131120 03:14:16-!- Upthorn [~ogmar@c-71-193-56-99.hsd1.ca.comcast.net] has joined #wesnoth-dev
20131120 03:22:56-!- Ivanovic_ [~ivanovic@x2f49452.dyn.telefonica.de] has joined #wesnoth-dev
20131120 03:26:39-!- Ivanovic [~ivanovic@x2f4e224.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20131120 03:26:50-!- Ivanovic_ is now known as Ivanovic
20131120 03:58:47-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 272 seconds]
20131120 04:00:11-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20131120 04:12:26-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Remote host closed the connection]
20131120 04:51:42-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Remote host closed the connection]
20131120 04:58:25-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20131120 05:01:51-!- Chusslove [~Chusslove@unaffiliated/chusslove] has quit [Ping timeout: 272 seconds]
20131120 05:02:52-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has joined #wesnoth-dev
20131120 05:04:29-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has quit [Client Quit]
20131120 05:04:56-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has joined #wesnoth-dev
20131120 05:27:51-!- Chusslove [~Chusslove@unaffiliated/chusslove] has joined #wesnoth-dev
20131120 05:50:57-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20131120 06:07:38-!- fabi__ [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20131120 06:11:16-!- fabi_ [~fabi@wesnoth/developer/fendrin] has quit [Ping timeout: 264 seconds]
20131120 06:30:50-!- Upthorn [~ogmar@c-71-193-56-99.hsd1.ca.comcast.net] has quit [Ping timeout: 245 seconds]
20131120 06:31:58-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20131120 06:43:03-!- Upthorn [~ogmar@c-71-193-56-99.hsd1.ca.comcast.net] has joined #wesnoth-dev
20131120 06:44:02-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20131120 07:03:45-!- Upthorn [~ogmar@c-71-193-56-99.hsd1.ca.comcast.net] has quit [Ping timeout: 245 seconds]
20131120 07:15:30-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Quit: Ik ga weg]
20131120 07:25:32-!- Rh0nda is now known as Rhonda
20131120 07:38:44-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20131120 07:48:44-!- boucman_work [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20131120 07:52:27-!- boucman_work1 [~rosen@193.56.60.160] has joined #wesnoth-dev
20131120 07:53:03-!- boucman_work [~rosen@wesnoth/developer/boucman] has quit [Ping timeout: 245 seconds]
20131120 07:56:26-!- trademark [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has joined #wesnoth-dev
20131120 07:57:44-!- Gallaecio [~quassel@84.120.115.29.dyn.user.ono.com] has quit [Read error: Connection reset by peer]
20131120 08:37:31-!- mjs-de [~mjs-de@f049043101.adsl.alicedsl.de] has joined #wesnoth-dev
20131120 09:32:19-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 241 seconds]
20131120 09:52:25-!- DCW [~Thunderbi@cpc1-finc14-2-0-cust12.4-2.cable.virginm.net] has joined #wesnoth-dev
20131120 10:03:51-!- exciton [chuck-the-@89.208.169.104] has quit [Ping timeout: 260 seconds]
20131120 10:05:31-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 10:13:58-!- boucman_work1 is now known as boucman_work
20131120 10:14:06-!- boucman_work [~rosen@193.56.60.160] has quit [Changing host]
20131120 10:14:06-!- boucman_work [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20131120 10:22:47-!- DCW [~Thunderbi@cpc1-finc14-2-0-cust12.4-2.cable.virginm.net] has quit [Ping timeout: 252 seconds]
20131120 10:27:25-!- stikonas [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has joined #wesnoth-dev
20131120 10:27:25-!- stikonas [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has quit [Changing host]
20131120 10:27:25-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20131120 10:40:09-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20131120 10:52:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 246 seconds]
20131120 10:52:17-!- stikonas_ [~gentoo@46.246.48.19] has joined #wesnoth-dev
20131120 10:52:17-!- stikonas_ [~gentoo@46.246.48.19] has quit [Changing host]
20131120 10:52:17-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20131120 10:54:57< zookeeper> mattsc, sounds good to me from the WML side.
20131120 11:22:17-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20131120 11:28:29-!- horon [~horon@nttkyo210231.tkyo.nt.ngn2.ppp.infoweb.ne.jp] has joined #wesnoth-dev
20131120 11:41:13-!- kex [~kex@89.205.75.19] has quit [Remote host closed the connection]
20131120 11:41:52-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20131120 11:46:55-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 272 seconds]
20131120 12:03:42-!- Kostic [~marko@85.202.113.252] has joined #wesnoth-dev
20131120 12:28:45-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20131120 12:29:48-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Client Quit]
20131120 12:30:02-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20131120 12:42:14-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20131120 12:47:00-!- stikonas [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has joined #wesnoth-dev
20131120 12:47:00-!- stikonas [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has quit [Changing host]
20131120 12:47:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20131120 13:06:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 246 seconds]
20131120 13:06:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20131120 13:26:34-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20131120 13:31:15-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 252 seconds]
20131120 13:50:11< zookeeper> mattsc, durr, i get a crash (assert at game_display.cpp:1022) when trying to load a replay for testing. i thought that previously it was because of the old build i was using, but apparently not.
20131120 13:52:32< zookeeper> so how is one supposed to tell which rev was used for a release, anyway?
20131120 13:52:50< zookeeper> it's not like there's those awfully convenient tagging commits anymore, it seems.
20131120 13:55:52< vultraz> zookeeper: click on Releases on the Github page
20131120 13:57:50< vultraz> the release was 6e73f02
20131120 14:02:38< zookeeper> that doesn't show up when i view the log though
20131120 14:02:50< zookeeper> i guess i need to pull first
20131120 14:04:09< zookeeper> but yeah, thanks
20131120 14:08:08< zookeeper> i dunno, git's just weird. i viewed the log, searched for "bump", it only found pre-1.11.7 matches but otherwise showed recent commits, then i pulled, and now i can find the version bump commit by searching for "bump"
20131120 14:17:42-!- irker310 [~irker@ai0867.net] has quit [Quit: transmission timeout]
20131120 14:18:34< mattsc> zookeeper: 'git tag' and 'git show 1.11.7' ?
20131120 14:21:19-!- TooLmaN [~TooLmaN@mx1.thomsonplastics.com] has joined #wesnoth-dev
20131120 14:23:32-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has joined #wesnoth-dev
20131120 14:24:02< zookeeper> mattsc, meh, i don't touch the command line unless absolutely necessary
20131120 14:24:04< zookeeper> however...
20131120 14:24:30< zookeeper> i tested with 1.11.7 and can confirm that when playing a replay, units are stored in reverse order than when playing normally
20131120 14:25:19< zookeeper> i just stored units in an event and then did a simple {FOREACH foo i}    {DEBUG_MSG "$foo[$i].name"}    {NEXT i}
20131120 14:25:37< zookeeper> and the names came out in reverse order when watching a replay
20131120 14:25:54< bumbadadabum> really?
20131120 14:25:58< zookeeper> yep
20131120 14:26:00< bumbadadabum> that would break a lot of things
20131120 14:26:19< zookeeper> i'd think so too
20131120 14:26:28< mattsc> zookeeper: that would certainly explain the OOS error in SotBE
20131120 14:26:49< bumbadadabum> well, I don't know really
20131120 14:26:58< mattsc> (and might explain a couple problems I've had way back with Grnk, actually ...)
20131120 14:27:13< bumbadadabum> would a LOOKUP_INDEX in a replay return the same thing or the 'right' thing?
20131120 14:27:30< zookeeper> bumbadadabum, although i don't think most WML breaks if the order changes
20131120 14:27:45< bumbadadabum> zookeeper: some of it will
20131120 14:27:51< zookeeper> certainly
20131120 14:31:08< zookeeper> also, the crash i mentioned only happens when loading a replay which was saved in linger mode, i think
20131120 14:31:17< zookeeper> (and it happens with plain 1.11.7 too)
20131120 14:33:56< mattsc> zookeeper: looks like I have two more bugs to look into: order reversed in replays and linger mode replay crash
20131120 14:34:23< zookeeper> you're welcome :}
20131120 14:34:40< mattsc> yay!
20131120 14:35:55< zookeeper> if my diagnosis of the order bug is correct, then i wonder for how big portion of the replay OOS problems it might account for
20131120 14:36:51< mattsc> indeed
20131120 14:37:13-!- mattsc [~mattsc@154.20.32.246] has quit [Quit: Computer's napping]
20131120 14:43:16-!- horon [~horon@nttkyo210231.tkyo.nt.ngn2.ppp.infoweb.ne.jp] has quit [Quit: Leaving...]
20131120 14:47:26-!- mattsc [~mattsc@207.230.251.234] has joined #wesnoth-dev
20131120 14:50:01-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 14:50:15-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 15:00:01-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 15:00:15-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 15:06:01-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 15:06:08-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20131120 15:06:15-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 15:07:23< mattsc> zookeeper: could you do me a favor?  Repeat your test, but display both name and id of the units.
20131120 15:10:01-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 15:10:42-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20131120 15:11:15-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 15:12:20< mattsc> zookeeper: also, I do not get the crash when saving a replay in linger mode.  Any more instructions on how to reproduce it?
20131120 15:13:20< mattsc> A crash like that did happen for versions 1.11.1 - 1.11.6 under certain circumstance, but it should have been fixed in 1.11.7 ...
20131120 15:14:02< mattsc> https://gna.org/bugs/?func=detailitem&item_id=20564
20131120 15:15:04< mattsc> zookeeper: oh, did you maybe start the game from a start-of-scenario save you made with an earlier version?  In that case, you'd still get that crash, as it is a problem with the information stored in the replay rather than the Wesnoth version used for showing the replay.
20131120 15:16:53< mattsc> or rather: a problem with the information (not) stored in the start-of-scenario save (rather than the replay)
20131120 15:19:19-!- exciton [chuck-the-@89.208.169.104] has quit [Ping timeout: 260 seconds]
20131120 15:26:23-!- TooLmaN [~TooLmaN@mx1.thomsonplastics.com] has quit [Ping timeout: 245 seconds]
20131120 15:27:16-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has quit [Ping timeout: 246 seconds]
20131120 15:27:21-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 15:28:28-!- mattsc [~mattsc@207.230.251.234] has quit [Ping timeout: 245 seconds]
20131120 15:31:00-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 15:31:53-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has joined #wesnoth-dev
20131120 15:37:57-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 15:38:06-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20131120 15:38:09-!- zookeeper2 [~lmsnie@37.35.27.57] has joined #wesnoth-dev
20131120 15:41:37-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 246 seconds]
20131120 15:42:04-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20131120 15:42:47-!- zookeeper2 [~lmsnie@37.35.27.57] has quit [Ping timeout: 272 seconds]
20131120 15:43:12-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has joined #wesnoth-dev
20131120 15:47:31-!- molgrum [~molgrum@h-94-220.a230.priv.bahnhof.se] has quit [Quit: Lämnar]
20131120 15:47:50-!- mattsc [~mattsc@fw.hia.nrc.ca] has joined #wesnoth-dev
20131120 16:10:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 248 seconds]
20131120 16:10:21-!- stikonas_ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has joined #wesnoth-dev
20131120 16:10:22-!- stikonas_ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has quit [Changing host]
20131120 16:10:22-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20131120 16:19:15-!- trademark [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has quit [Ping timeout: 272 seconds]
20131120 16:20:24< mattsc> zookeeper: so what I am seeing in my test scenario is that units are unstored in the same order, but with different names.
20131120 16:20:49< zookeeper> O.o ok, i didn't check for that possibility myself
20131120 16:21:03< mattsc> In fact, if I simply recruit a keep of units on the first turn, save a replay and play it, all recruited units have different names.
20131120 16:21:31< mattsc> This does not happen in 1.10, so I bet it has to do with the refactoring that was done earlier in 1.11.
20131120 16:21:47< mattsc> zookeeper: also, did you see my note on the replay crash?
20131120 16:22:10< zookeeper> nope, but i did now :P
20131120 16:23:36< zookeeper> i'm gonna go eat something, and i'll do the test after that
20131120 16:23:49< mattsc> zookeeper: bon appetit
20131120 16:34:25-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20131120 16:36:19-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20131120 16:43:39< zookeeper> ok, let's see...
20131120 16:44:00< zookeeper> mattsc, the replay crash was when i ended the scenario in a start event, then saved in linger mode
20131120 16:44:22< zookeeper> didn't happen when i moved the scenario end to turn 2
20131120 16:45:23< mattsc> zookeeper: interesting.  I can imagine that that's a situation that wasn't considered when redoing how replays work.
20131120 16:49:01< zookeeper> mattsc, ok, tested. it's not just the names changing; according to the id's, the unit order is still getting reversed.
20131120 16:49:12-!- molgrum [~molgrum@h-94-220.a230.priv.bahnhof.se] has joined #wesnoth-dev
20131120 16:50:15< mattsc> zookeeper: hmm, ok.  In my case the order did not change, so there seems to be something more to it.
20131120 16:50:51< mattsc> What I did is recruit two units, had them stored in a moveto event, and their names/ids displayed in another moveto event.
20131120 16:51:12< zookeeper> i didn't recruit at all, i just relied on the units created in prestart
20131120 16:51:59< zookeeper> let's see what happens with recruits...
20131120 16:53:08-!- Octalot [~noct@87.114.171.23] has quit []
20131120 16:53:26< mattsc> I've been looking into the saves created from playing through this, and from saving from the replay.  There are quite a few differences, but I don't know which of them are important.
20131120 16:53:35< zookeeper> (interesting sidenote: units are also getting stored in the order at which they've appeared in the scenario)
20131120 16:54:33< zookeeper> ha. playing back a replay, the recruits do get new random names.
20131120 16:54:48< zookeeper> forgot to look at the traits, though
20131120 16:56:36< mattsc> from what I have seen, traits do stay the same
20131120 16:59:01< zookeeper> yeah, the units stay the same, only the name changes
20131120 16:59:11< zookeeper> which is... weird?
20131120 17:02:04< zookeeper> i recruited three units, and whenever i re-load the replay, two of them get the same names (which also appeared when making the original replay) but the third one gets a completely random one
20131120 17:03:05< mattsc> Hmm, in my case all of them have different names
20131120 17:03:57< zookeeper> maybe it's relevant that i made the replay on turn 1 after i had recruited, and there's for example no recruited enemy units
20131120 17:05:30-!- boucman_work [~rosen@wesnoth/developer/boucman] has quit [Read error: Operation timed out]
20131120 17:05:59< mattsc> I did the same thing
20131120 17:06:44< zookeeper> right...
20131120 17:09:03< mattsc> zookeeper: it seems to have nothing to do with replays, names are apparently not synced.
20131120 17:09:29< zookeeper> huh. so in MP, recruits have different names for all players? O.o
20131120 17:09:50< mattsc> uh, good question.
20131120 17:10:17< mattsc> If I take a savegame, recruit, then load the same one again and recruit the same units, they have the same traits etc., but different names
20131120 17:11:03< mattsc> Since replays just recreate what was done (rather than saving the units), they won't have the same names in the replays either.
20131120 17:13:09< mattsc> zookeeper: do you want to try in MP quickly?  Or are you set up to do it all by yourself
20131120 17:13:29< zookeeper> i can do it myself, just a sec
20131120 17:13:38< mattsc> okay, good
20131120 17:13:57< bumbadadabum> About the names thing
20131120 17:13:59< bumbadadabum> that's true
20131120 17:14:01< bumbadadabum> I can confirm
20131120 17:15:05< zookeeper> ohh, tray notifications of whose turn it is, neat
20131120 17:15:27< bumbadadabum> Although they don't really work properly for me
20131120 17:15:48-!- R2D2C3PO [57a140a1@gateway/web/freenode/ip.87.161.64.161] has joined #wesnoth-dev
20131120 17:15:54< bumbadadabum> they seem to get cluttered after a while
20131120 17:16:13< bumbadadabum> when using the chat, anyway
20131120 17:16:33< zookeeper> yes, i confirm the differing names as well
20131120 17:19:56< mattsc> zookeeper: okay, interesting.
20131120 17:20:44< mattsc> This seems to be separate from the order of units being different though.  Did you get the same or a different order for this for recruited units?
20131120 17:21:13-!- trademark [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has joined #wesnoth-dev
20131120 17:22:01< zookeeper> mattsc, i'll double-check
20131120 17:30:32-!- Gallaecio [~quassel@84.120.115.29.dyn.user.ono.com] has joined #wesnoth-dev
20131120 17:32:12< zookeeper> uh, i'm not sure, because... the unit id's change. when playing i might get Merman Fighter-20, Merman Fighter-19, Merman Fighter-18, but when i play the replay of that i get Merman Fighter-23, Merman Fighter-22, Merman Fighter-21
20131120 17:33:49< zookeeper> also, again if i recruit say 4 units, then when playing the replay the names of the first (or last, i'm getting confused) will get recycled and only one will get a completely new random name
20131120 17:34:40 * zookeeper goes afk for 20 minutes or so
20131120 17:37:28-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20131120 17:39:16-!- Kostic [~marko@85.202.113.252] has quit [Quit: Kostic]
20131120 17:39:32< mattsc> zookeeper: yes, I have noticed that as well.  names, underlying ids and ids change.  One could argue that neither of them are essential for avoiding OOS problems, so that could be considered a feature rathe than a bug.
20131120 17:39:51< mattsc> zookeeper: I just recruited units of different type, which made it quite obvious.  :)
20131120 17:40:39-!- molgrum [~molgrum@h-94-220.a230.priv.bahnhof.se] has quit [Quit: Lämnar]
20131120 17:43:44-!- DCW [~Thunderbi@cpc1-finc14-2-0-cust12.4-2.cable.virginm.net] has joined #wesnoth-dev
20131120 17:48:46-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20131120 17:48:54-!- Chusslove [~Chusslove@unaffiliated/chusslove] has quit []
20131120 17:56:21-!- DCW [~Thunderbi@cpc1-finc14-2-0-cust12.4-2.cable.virginm.net] has quit [Remote host closed the connection]
20131120 17:57:43-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20131120 17:58:08-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has joined #wesnoth-dev
20131120 18:07:10-!- molgrum [~molgrum@h-94-220.a230.priv.bahnhof.se] has joined #wesnoth-dev
20131120 18:07:44< zookeeper> mattsc, well, i think they're definitely bugs (underlying_id _maybe_ not)
20131120 18:08:43< mattsc> zookeeper: sure - I just think that this looks like an intentional omission rather than something that got forgotten.
20131120 18:08:45-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20131120 18:09:36< zookeeper> i mean, i bet people use id's to store "pointers" to units in some WML structures and expect the id's to remain constant. i'd be really surprised if it was an intentional omission when it comes to names and/or id's, really.
20131120 18:10:09< mattsc> zookeeper: true
20131120 18:10:40< mattsc> underlying id and id use the same numbering system when they are created automatically though, so it's either fixing none or both
20131120 18:10:54< zookeeper> let's go with both :p
20131120 18:11:15< mattsc> zookeeper: sounds good to me
20131120 18:11:20< zookeeper> great
20131120 18:11:32< mattsc> now what about the order of units  :)
20131120 18:11:50< zookeeper> is there anything else specific that you'd like me to test? this whole thing seems complicated enough that i'm getting confused when trying to test things.
20131120 18:11:55< zookeeper> yeah, that.
20131120 18:12:18< mattsc> that's the last thing really and seems to be a separate issue
20131120 18:13:39-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 246 seconds]
20131120 18:13:53-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20131120 18:14:00< zookeeper> ok, testing that...
20131120 18:17:34< zookeeper> i'm not getting the inverse order now, but it might just be my testcase influencing things, trying something else...
20131120 18:17:35-!- Kostic [~marko@85.202.113.165] has joined #wesnoth-dev
20131120 18:18:47< mattsc> zookeeper: did one more test myself and it's very interesting
20131120 18:19:16< mattsc> If I put a bunch of units onto the map in the start event, and then recruit some, the recruited ones are in the same order, and the original ones in opposite order.
20131120 18:20:53< zookeeper> yes
20131120 18:21:00< mattsc> weird
20131120 18:23:49< mattsc> zookeeper: I also confirmed the crash of a replay saved in linger mode entered from a start event
20131120 18:24:20< zookeeper> yes, pre-placed units get stored in reverse order, recruited do not
20131120 18:24:25< zookeeper> cool
20131120 18:25:13< mattsc> actually, it has nothing to do with linger mode.  If you go on to the next scenario, the auto replay save also crashes.
20131120 18:25:38< zookeeper> right
20131120 18:25:41< mattsc> ... and I also know (from fixing that other bug), what causes that.  But I am not sure exactly how to fix it ...
20131120 18:26:34-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds]
20131120 18:26:39-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has joined #wesnoth-dev
20131120 18:27:01< mattsc> https://github.com/wesnoth/wesnoth-old/commit/ef0ffef5b02282954c2f9b7871a6417bd079adde
20131120 18:27:05< zookeeper> i'd expect the fact that (at least) the pre-placed units get stored in the order they originally were placed in might be a decent hint towards the reverse-order bug
20131120 18:27:58< mattsc> turn_number here is set to, say, 15 (or wherever you ended the previous scenario), and thus the condition does not kick in.
20131120 18:28:54< mattsc> Of course, the proposed fix we talked about yesterday has turn_number = 1 in start/prestart events, so it won't work either.
20131120 18:29:49< mattsc> zookeeper: so if I see that right, I have 4 things on my plate (in addition to Kapou'e and Fred and Grnk and ...):
20131120 18:30:02< mattsc> 1. Set turn_number correctly for [pre]start events
20131120 18:30:14< mattsc> 2. Fix that replay crash we just talked about
20131120 18:30:48< mattsc> 3. Figure out why the order of some stored units is inverted (and see whether that fixes the OOS problem in SotBE S11)
20131120 18:31:06< mattsc> 4. Make name, id, underlying_id be synced
20131120 18:31:13< mattsc> :P  Did I forget something?
20131120 18:31:50< zookeeper> i don't think so
20131120 18:31:57< zookeeper> it's a good start in any case ;)
20131120 18:32:20< mattsc> I think I should have my forum title changed to Exterminator
20131120 18:33:18< mattsc> (no, please don't do that)
20131120 18:34:29-!- ancestral [~ancestral@71-215-216-1.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20131120 18:40:02-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 18:40:16-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 19:01:23-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has quit [Remote host closed the connection]
20131120 19:01:41-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has joined #wesnoth-dev
20131120 19:15:01-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 19:15:15-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 19:15:55-!- esr [~esr@wesnoth/developer/esr] has quit [Quit: WeeChat 0.4.1]
20131120 19:18:29-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has quit [Remote host closed the connection]
20131120 19:18:47-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has joined #wesnoth-dev
20131120 19:21:16-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20131120 19:21:16-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Changing host]
20131120 19:21:16-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20131120 19:21:43-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has quit [Remote host closed the connection]
20131120 19:22:45< fabi__> mattsc, zookeeper: http://imagebin.org/277985
20131120 19:24:18-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has joined #wesnoth-dev
20131120 19:27:14-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has quit [Remote host closed the connection]
20131120 19:27:15-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20131120 19:27:54-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has joined #wesnoth-dev
20131120 19:29:49< mattsc> fabi__: looks good to me
20131120 19:30:01-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 19:30:16-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 19:30:50-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has quit [Remote host closed the connection]
20131120 19:31:18-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has joined #wesnoth-dev
20131120 19:34:03-!- kex [~kex@89.205.75.19] has quit [Remote host closed the connection]
20131120 19:34:39-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20131120 19:35:01-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 19:35:16-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 19:36:09< fabi__> mattsc: Yeah, I had a few design tips and art support from Jetrel.
20131120 19:37:10-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has quit [Read error: Connection reset by peer]
20131120 19:38:01-!- stikonas__ [~gentoo@cpc18-sgyl27-2-0-cust35.18-2.cable.virginm.net] has joined #wesnoth-dev
20131120 19:38:45-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 245 seconds]
20131120 19:50:01-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 19:50:16-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 19:54:01-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 19:55:16-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 19:56:41< mattsc> zookeeper: umm, replays do not contain anything from prestart and start events, so what's the point in having a replay safe from one of those then?
20131120 19:57:16-!- R2D2C3PO [57a140a1@gateway/web/freenode/ip.87.161.64.161] has quit [Quit: Page closed]
20131120 19:57:29< zookeeper> mattsc, does not compute
20131120 19:57:53< mattsc> zookeeper: yeah, hold on ...
20131120 20:03:59-!- exciton [chuck-the-@89.208.169.104] has quit [Ping timeout: 260 seconds]
20131120 20:05:17-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 20:05:21< mattsc> so, yes, I was right ...
20131120 20:05:34< mattsc> In 1.11, replays start _after_ the start event.
20131120 20:05:56< mattsc> I checked as far back as 1.11.5, so it's not due to anything I have done between 1.11.6 and 1.11.7
20131120 20:06:08< mattsc> zookeeper: ^
20131120 20:06:56< zookeeper> okay, i see. i just can't wrap my mind around the implications of that WRT these bugs.
20131120 20:07:02-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 20:08:17< mattsc> zookeeper: well, let's take it a step at a time.  Should that (replays not including start/prestart messages etc.) be considered a bug?
20131120 20:09:10< zookeeper> dunno about prestart, but at least start events should be played IMO
20131120 20:10:18-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 20:10:36< zookeeper> i don't really see any reason why even prestarts should be omitted, though
20131120 20:10:48< mattsc> agreed, I think (and they are in 1.10).  I'm not sure that I can fix that one though.
20131120 20:12:57< mattsc> sorry for the delay, yes, the opening dialog of HttT is played in the 1.10.7 replay, but not in 1.11.5.  And that is in a start event.
20131120 20:13:20< mattsc> zookeeper: okay, so there's another bug ...  :P
20131120 20:13:30< zookeeper> yippee
20131120 20:14:01< mattsc> I think I need to find another hobby ...
20131120 20:14:17< mattsc> I'm also surprised that nobody has complained about this yet.
20131120 20:14:23< zookeeper> so i take it that you know who/why/when that part of code was worked on and these bugs introduced?
20131120 20:14:34< zookeeper> i haven't been following, so i have no idea
20131120 20:15:05< mattsc> Well, Ayne did a lot of refactoring of these things.  I assume that these are left-ver bugs from that work.
20131120 20:17:08< zookeeper> i see
20131120 20:30:01-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131120 20:30:16-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131120 20:37:51-!- Kostic [~marko@85.202.113.165] has quit [Ping timeout: 246 seconds]
20131120 20:51:08-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20131120 20:51:09-!- Chusslove [~Chusslove@unaffiliated/chusslove] has joined #wesnoth-dev
20131120 20:52:14-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20131120 20:54:58-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20131120 21:05:55-!- Ivanovic [~ivanovic@x2f49452.dyn.telefonica.de] has quit [Changing host]
20131120 21:05:55-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20131120 21:07:48< Ivanovic> re
20131120 21:07:55< Ivanovic> boucman: no, i contacted noone at valve about this
20131120 21:08:06< boucman> could be an idea...
20131120 21:08:41< mattsc> thunderstruck: hi
20131120 21:08:45-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20131120 21:09:36-!- TooLmaN [~TooLmaN@mx1.thomsonplastics.com] has joined #wesnoth-dev
20131120 21:10:01< Ivanovic> boucman: yeah, it could, but i am just back from a business trip and had no time on the side (at all)
20131120 21:13:12< Ivanovic> AI0867: i don't think that we will participate at GCI this year
20131120 21:13:43< Ivanovic> i talked about this with Crab_ during the conference and we came to the conclusion that we neither have the manpower to support it nor the amount of well suited tasks (at least right now)
20131120 21:14:42< Ivanovic> shadowm: did everything go well regarding the release?
20131120 21:14:51< Ivanovic> (yeah, I was really cut off of my usual world...)
20131120 21:15:42< thunderstruck> mattsc: hi
20131120 21:16:09< mattsc> thunderstruck: you don't happen to know why replays in 1.11 do not play the prestart and start events any more, do you?
20131120 21:17:11< thunderstruck> mattsc: No. I don't think I touched events code. Are you talking about all the games or just MP?
20131120 21:17:53< mattsc> I'm investigating SP campaigns at the moment, but I think this applies to both SP and MP.
20131120 21:18:21< mattsc> https://github.com/wesnoth/wesnoth-old/blob/master/src/replay_controller.cpp#L291
20131120 21:18:47< mattsc> If I do a blame on this, it points to jamit, but it looks like he fixed a problem with it, rather than introducing it.
20131120 21:19:10< fabi__> Ivanovic: 
20131120 21:19:13< fabi__> Ivanovic: Hello
20131120 21:19:20< fabi__> Ivanovic: Do you have a few minutes for me?
20131120 21:19:53< thunderstruck> mattsc: I recall that he was refactoring events code. But that's basically all I know.
20131120 21:20:06< thunderstruck> Anyway, any particular reason why do you ask me about this?
20131120 21:20:13< shadowm> Ivanovic: Can't think of anything that could've gone wrong.
20131120 21:20:33< mattsc> thunderstruck: I thought that there was an outside chance it might have something to do with MP safety.  :)
20131120 21:20:51< mattsc> Well, mostly I wanted to confirm that it did not.
20131120 21:21:05< shadowm> Ivanovic: That is, the Windows and OS X builds became available within 12 hours or so following the tagging.
20131120 21:21:54< thunderstruck> mattsc: Never heard of it :)
20131120 21:22:05< Ivanovic> fabi__: i am not in a condition to do anything productive right now
20131120 21:22:19< Ivanovic> all i can do is unpack my stuff from travel, drink a little and fall into bed
20131120 21:23:03-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20131120 21:23:28< Ivanovic> shadowm: world could have collapsed with some huge bug breaking everything
20131120 21:23:47< Ivanovic> fabi__: if it is about the pandora version: i got some problem there meaning the last working release i got is 1.11.4
20131120 21:24:18< Ivanovic> fabi__: during my vacation time (starting mid december and lasting until the first week of january) i will need to check which commit broke it
20131120 21:24:25< Ivanovic> it segfaults right at startup
20131120 21:25:06< bumbadadabum> Rhonda: You're the debian packager, right?
20131120 21:25:06< mattsc> zookeeper: I think I figured out what is happening: https://gna.org/bugs/?20272
20131120 21:25:10< Ivanovic> fabi__: what you should keep in mind is that there are basically two playing modes for the pandora version in 800x480
20131120 21:25:13< fabi__> Ivanovic: Well, you are the only 800x480 user I know of. One of my questions is what you think about removing the tod image at the pandora's resolution to get some space.
20131120 21:25:24< fabi__> Ivanovic: Two modes?
20131120 21:25:49< Ivanovic> 1) hold the pandora in the left hand, use the thumb to move around with the d-pad (arrow keys) and make any inputs with the touchscreen (a small pen is shipped with it)
20131120 21:26:00< mattsc> zookeeper: it was the fix to this bug, but it was done incorrectly (I think)
20131120 21:26:37< zookeeper> mattsc, let's hope that's it
20131120 21:26:49< Ivanovic> 2) hold the pandora in two hands, use the thumb of the left hand with the arrow keys to move the map, switch the thumb to the left analog stick and move the mouse, use the right analog stick for clicking (move to left: leftclick, right: rightclick, up: doubleclick, down: middleclick)
20131120 21:26:59< zookeeper> i'm going to bed in a minute, but i'll read the logs tomorrow...
20131120 21:27:27< Ivanovic> fabi__: you should consider this when thinking about which elements need to be shown in that resolution (e.g. some "end turn" button which is not too hard to hit (e.g. like a unit) makes a lot of sense
20131120 21:27:32< mattsc> zookeeper: the replay_start situation is currently saved _after_ the start event.  Which means, if you also play through [pre]start events, you get units put on the map twice.
20131120 21:27:45< Ivanovic> the minimap as it is though probably makes less sense
20131120 21:28:02< mattsc> zookeeper: good night.  I should stop this for now anyway, I'll hook back up with you tomorrow.
20131120 21:28:16< mattsc> but I think I know what I need to do to fix this.
20131120 21:28:32< Ivanovic> fabi__: does this help you?
20131120 21:28:36< fabi__> Ivanovic: The minimap makes no sense at low resolutions?
20131120 21:28:39< Ivanovic> for anything more i recommend we chat tomorrow
20131120 21:28:54< Ivanovic> fabi__: switch to the low resolution on a highres screen
20131120 21:29:05< Ivanovic> you won't see any single units unless the map is smaller than 10x10 hex
20131120 21:29:27< Ivanovic> those 800x480 pixel are on a 3.7" screen
20131120 21:30:35< Ivanovic> the only help the minimap provides is that you have an idea where on the battle field the current part of the map is
20131120 21:30:50< Ivanovic> but that is about it, all the other info like terrains or units are barely visible
20131120 21:31:00-!- Chusslove [~Chusslove@unaffiliated/chusslove] has quit [Read error: Connection reset by peer]
20131120 21:32:19< fabi__> Ivanovic: The 1.10.6 version works great in 800x480 on my monitor (24" 1680x1050). I can see units and stuff easily.
20131120 21:32:47< Ivanovic> yes, you have maybe half the DPI
20131120 21:32:56< fabi__> Ivanovic: Yes, let's discuss that when you are fit again.
20131120 21:33:20-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20131120 21:36:05-!- iceiceice [~chris@207-237-132-90.ny.subnet.cable.rcn.com] has joined #wesnoth-dev
20131120 21:38:11-!- Chusslove_ [~Chusslove@unaffiliated/chusslove] has joined #wesnoth-dev
20131120 21:38:59-!- Chusslove_ is now known as Chusslove
20131120 21:44:10-!- shadowm_desktop2 [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20131120 21:44:21-!- shadowm_desktop2 [ignacio@wesnoth/developer/shadowmaster] has quit [Remote host closed the connection]
20131120 21:47:13-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 272 seconds]
20131120 21:48:01-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20131120 21:57:54-!- Kostic [~marko@net92-1-245-109.mbb.telenor.rs] has joined #wesnoth-dev
20131120 21:58:21-!- trademark [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has quit [Read error: Operation timed out]
20131120 22:00:04-!- TooLmaN [~TooLmaN@mx1.thomsonplastics.com] has quit [Quit: Off to save the world!]
20131120 22:06:30< mattsc> zookeeper, all:  I've filed a bug report explaining the missing [pre]start events from replays and asking whether there is something I might be missing.
20131120 22:06:39< mattsc> https://gna.org/bugs/index.php?21289
20131120 22:07:21< mattsc> If I don't hear back about this within a couple days, I will fix it.
20131120 22:08:15< mattsc> zookeeper: the replay crash bug you encountered will be fixed as a side effect of this.  The others require separate fixes, I believe.
20131120 22:10:27-!- Kostic [~marko@net92-1-245-109.mbb.telenor.rs] has quit [Ping timeout: 252 seconds]
20131120 22:10:32-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has quit [Quit: leaving]
20131120 22:12:00-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20131120 22:26:35< mattsc> zookeeper: I also just fixed the turn_number issue for prestart and start events (but irker seems to be down or very slow)
20131120 22:26:37< mattsc> https://github.com/wesnoth/wesnoth-old/commit/3bfbf58097ce19aaf2c93196bb54d993b841200b
20131120 22:36:00-!- irker924 [~irker@ai0867.net] has joined #wesnoth-dev
20131120 22:36:00< irker924> wesnoth: mattsc wesnoth-old:master 3bfbf58097ce / src/play_controller.cpp: Set WML variable turn_number correctly in [pre]start events http://git.io/mUDhkA
20131120 22:44:28< mattsc> zookeeper: and one more (this one is about unit names not being synced): https://gna.org/bugs/index.php?21290 
20131120 22:45:17< mattsc> I actually do not believe any more that this would cause OOS errors, but it seems inelegant.  I posted this as a bug report again because there might be some reason that I am not aware of.
20131120 22:50:07-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20131120 22:50:38-!- kex [~kex@78.157.29.205] has joined #wesnoth-dev
20131120 22:58:23-!- Gallaecio [~quassel@84.120.115.29.dyn.user.ono.com] has quit [Remote host closed the connection]
20131120 23:02:17-!- gfgtdf [~chatzilla@e177127199.adsl.alicedsl.de] has joined #wesnoth-dev
20131120 23:15:49-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Remote host closed the connection]
20131120 23:21:48-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20131120 23:23:44-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20131120 23:34:06-!- mattsc [~mattsc@fw.hia.nrc.ca] has quit [Quit: Computer's napping]
20131120 23:54:46-!- iceiceice [~chris@207-237-132-90.ny.subnet.cable.rcn.com] has quit [Remote host closed the connection]
20131120 23:58:41-!- mattsc [~mattsc@154.20.32.246] has joined #wesnoth-dev
20131120 23:59:39-!- mjs-de [~mjs-de@f049043101.adsl.alicedsl.de] has quit [Remote host closed the connection]
--- Log closed Thu Nov 21 00:00:58 2013