--- Log opened Mon Oct 07 00:00:42 2013
20131007 00:01:04< flix> mattsc: around?
20131007 00:01:19< mattsc> flix: on and off, yes
20131007 00:02:22< irker800> wesnoth: mattsc wesnoth-old:master c68070605682 / data/campaigns/Son_Of_The_Black_Eye/scenarios/06_Black_Flag.cfg: SotBE S6: clear variable 'random' after use http://git.io/7cPWBw
20131007 00:03:55< irker800> wesnoth: mattsc wesnoth-old:master a53f1e60a6f5 / data/campaigns/Son_Of_The_Black_Eye/scenarios/06_Black_Flag.cfg: SotBE S6: remove key set to default from [unit] tag http://git.io/vYRxVA
20131007 00:03:59-!- exciton [chuck-the-@89.208.169.104] has quit [Ping timeout: 260 seconds]
20131007 00:05:28-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 00:06:59< flix> mattsc: I played with friends again today (with 500 gold for the AIs). There is another thing that caught my attention: I was wondering why one AI didn't change to the state SAVE_GOLD. Then I remembered that the AI won't switch to SAVE_GOLD when it can figure out that it will loose gold (e.g. because the income is negative). So the AI spent all 500 gold at once. It confused me a bit and I thought about removing this extra-check. Did you und
20131007 00:08:27< irker800> wesnoth: mattsc wesnoth-old:master e0125c50bbbb / data/campaigns/Son_Of_The_Black_Eye/scenarios/06_Black_Flag.cfg: SotBE S6: remove an event that does nothing http://git.io/qo0kLw
20131007 00:09:28< mattsc> flix: your message was truncated.  Are you still typing?
20131007 00:10:01< flix> mattsc: stupid pidgin. I try to send it again
20131007 00:10:10< flix> mattsc: I played with friends again today (with 500 gold for the AIs). There is another thing that caught my attention: I was wondering why one AI didn't change to the state SAVE_GOLD. Then I remembered that the AI won't switch to SAVE_GOLD when it can figure out that it will loose gold (e.g. because the income is negative). So the AI spent all 500 gold at once. It confused me a bit and I thought about removing this extra-check. Did you und
20131007 00:11:33< mattsc> flix: same thing  :P
20131007 00:11:38< flix> strange
20131007 00:11:48< Soliton> there's a message limit on IRC it's not going to help to repeat the same message if pidgin doesn't respect it.
20131007 00:12:09< flix> mattsc: http://pastebin.com/FNgc490U
20131007 00:12:26< flix> Soliton: I see, thanks
20131007 00:13:39< mattsc> flix: I think this is okay like that.  The point of saving gold now is to have more available later (not spend it on upkeep), so that the AI has more units available later on, isn't it?
20131007 00:13:57< mattsc> flix: if so, there' no point in saving gold when the income is already negative
20131007 00:14:37< mattsc> flix: so the scenario designer has the choice to give the AI enough starting villages to keep income positive to make save_gold make sense.
20131007 00:14:38< AI0867> well, what if there are uncaptured villages?
20131007 00:15:21< mattsc> AI0867: sure, in principle that should be taken into account - the question is whether that's realistically doable.
20131007 00:15:21< flix> mattsc: Right, but on the other hand: if the threshold is this high (begin: 1.5), the AI will very often have negative income
20131007 00:16:10< mattsc> flix, AI0867: I'd argue that this is okay for the default, but maybe another key save_on_negative_income= (or something) could be added?
20131007 00:16:19< flix> mattsc, AI0867: My "income estimation" will try to guess "village gain" and "unit loss" and take this into account
20131007 00:18:21< flix> mattsc: Yes I had the same idea, but would you use "save_on_negative_income"? And what should be the default value?
20131007 00:21:53< mattsc> flix: I _might_ use it.  I can come up with use case in which I would.  I am not sure that I would want to use such a case, but I am sure that some UMC authors would.
20131007 00:21:56< flix> mattsc: In general I'm fine with how it is right now. It just confused me a second. And also I had this idea that if you give AIs in MP-Games a large amount of gold they are still "beatable" (because they'll recruit in waves). I thought this could be a long and fun game.
20131007 00:22:24< mattsc> flix: my experience is: if you can think up an options, somebody will want to use it somewhere.  There's a lot of creativity out there.  :)
20131007 00:22:57< mattsc> flix: I'd make it default to how it is right now.
20131007 00:26:18< flix> mattsc: Okay, I'll do it.
20131007 00:26:49< mattsc> flix: maybe make it an integer, rather than a boolean?
20131007 00:27:01< flix> mattsc: explain
20131007 00:27:03< mattsc> flix: save_on_gold_greater_than= ?
20131007 00:27:47< mattsc> flix: So, set it to 0, you get the current default, set to -10 (or so), we save as long as income is not vastly negative
20131007 00:28:01< mattsc> flix: and set it to -999 or something, and the AI will always save.
20131007 00:28:18< flix> mattsc: keep in mind that the AI also tries to guess village gain and unit loss.
20131007 00:28:54< mattsc> flix: sure, just a suggestion.  It might not makes sense then.  You know this better than I.
20131007 00:30:43< flix> mattsc: Okay, good idea, but I think a boolean will work better in this case.
20131007 00:38:27< irker800> wesnoth: flix wesnoth-old:master 4b13787d9ba0 / src/ai/recruitment/recruitment.cpp: Change behavior of recruitment_save_gold. http://git.io/KLgvRQ
20131007 00:39:52< mattsc> flix: that's good (that latest commit), because we're coming up on some scenarios in SotBE with several allied AI sides.  :)
20131007 00:40:48-!- gfgtdf [~chatzilla@f054136031.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds]
20131007 00:43:14< flix> mattsc: Okay, sometimes the allied AIs will now recruit, even if the "team-ratio" is over the begin threshold (1.5). But I think thats fine.
20131007 00:43:23< irker800> wesnoth: mattsc wesnoth-old:master c76eef0698f0 / data/campaigns/Son_Of_The_Black_Eye/scenarios/06_Black_Flag.cfg: SotBE S6: use only one variable to store away the shamans http://git.io/B1G6jA
20131007 00:43:56< mattsc> flix: sure.  We'll send you feedback as we keep working our way through scenarios ...
20131007 00:44:08< flix> mattsc: great
20131007 00:57:16-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Ping timeout: 245 seconds]
20131007 01:00:13-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 01:05:27-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 01:25:30< irker800> wesnoth: flix wesnoth-old:master a3af62c136c9 / data/ai/utils/default_config.cfg src/ai/recruitment/recruitment.cpp: Add key save_on_negative_income. http://git.io/GFI4tA
20131007 01:26:01< flix> mattsc: ^ Did it like discussed. Inclusive wiki entry.
20131007 01:26:01-!- Ard0nik [~ardonik@adsl-75-28-105-125.dsl.irvnca.sbcglobal.net] has quit [Read error: Connection reset by peer]
20131007 01:26:39-!- Ard0nik [~ardonik@adsl-75-28-107-173.dsl.irvnca.sbcglobal.net] has joined #wesnoth-dev
20131007 01:34:41< mattsc> flix: great!  I'm sure I'll be testing it at some point (but no immediate plans)
20131007 01:52:49< irker800> wesnoth: flix wesnoth-old:master 5bb392f45526 / changelog src/commandline_options.cpp src/commandline_options.hpp: Rename "--repeat" to "--multiplayer-repeat". http://git.io/GPTiTw
20131007 02:02:10-!- mjs-de [~mjs-de@d120131.adsl.hansenet.de] has quit [Remote host closed the connection]
20131007 02:02:29< irker800> wesnoth: mattsc wesnoth-old:master 8caa0dfad3dd / data/campaigns/Son_Of_The_Black_Eye/scenarios/02_The_Human_Army.cfg: SotBE S2: remove unnecessary keys from [side] tag http://git.io/Z85WLA
20131007 02:05:24< irker800> wesnoth: mattsc wesnoth-old:master 990961c0bd39 / data/campaigns/Son_Of_The_Black_Eye/scenarios/03_Toward_Mountains_of_Haag.cfg:  SotBE S3: remove unnecessary keys from [side] tag http://git.io/DoSiLQ
20131007 02:07:57< irker800> wesnoth: mattsc wesnoth-old:master 181e398b7896 / data/campaigns/Son_Of_The_Black_Eye/scenarios/04_The_Siege_of_Barag_Gor.cfg:  SotBE S4: remove unnecessary keys from [side] tag http://git.io/-yhPEg
20131007 02:13:24< irker800> wesnoth: mattsc wesnoth-old:master 48f99bdddd25 / data/campaigns/Son_Of_The_Black_Eye/scenarios/04_The_Siege_of_Barag_Gor.cfg: SotBE S4: add recruiting of Troll Whelps back in http://git.io/rIs3eQ
20131007 02:14:52< irker800> wesnoth: flix wesnoth-old:master d42e949a390e / doc/man/wesnoth.6: Update manpage. http://git.io/IKOA1A
20131007 02:16:13-!- love1cat [~Adium@c-76-119-168-240.hsd1.ma.comcast.net] has left #wesnoth-dev []
20131007 02:16:20< flix> mattsc: you can now repeat --multiplayer games with --multiplayer-repeat. This may be helpful for you when you are batch-testing things (with --nogui).
20131007 02:16:36< irker800> wesnoth: mattsc wesnoth-old:master 9efbf47dd310 / data/campaigns/Son_Of_The_Black_Eye/scenarios/05_To_the_Harbor_of_Tirigaz.cfg: SotBE S5: remove unnecessary keys from [side] tag http://git.io/aJwL7A
20131007 02:17:15< mattsc> flix: yeah, I saw that earlier.  You are making all my nice little shell scripts unnecessary !  :D
20131007 02:18:45-!- ancestral [~ancestral@174-20-209-41.mpls.qwest.net] has joined #wesnoth-dev
20131007 02:18:55< flix> mattsc: Well, when you use --multiplayer-repeat, the same factions are used over and over again. So they are only chosen randomly once. (I should leave a note somewhere)
20131007 02:19:23< mattsc> flix: did you implement the kill-unit-from-context menu (or with shift-k) in debug mode?
20131007 02:19:41< mattsc> flix: Or was that one of the other GSoC applicants?
20131007 02:20:13< flix> mattsc: I reviewed this patch and committed it. Something wrong?
20131007 02:20:32< mattsc> No, but a minor request for something that could be added.
20131007 02:21:18< mattsc> flix: when you use it, it triggers kill and last_breath events just fine.  It would be nice whether it would also check the enemies_defeated condition and trigger that event if applicable.
20131007 02:21:47< mattsc> flix: if that's difficult, it's not a big deal.  But it would make some debugging actions just a little bit more convenient.
20131007 02:21:56< flix> mattsc: Let me take a look
20131007 02:22:03< mattsc> flix: thanks
20131007 02:24:02< irker800> wesnoth: mattsc wesnoth-old:master 55b0626bdf84 / data/campaigns/Son_Of_The_Black_Eye/scenarios/06_Black_Flag.cfg: SotBE S6: remove unnecessary keys from [side] tag http://git.io/H6u7eA
20131007 02:40:48-!- Ard0nik [~ardonik@adsl-75-28-107-173.dsl.irvnca.sbcglobal.net] has quit [Ping timeout: 240 seconds]
20131007 02:58:19-!- Ardonik [~ardonik@adsl-75-28-107-173.dsl.irvnca.sbcglobal.net] has joined #wesnoth-dev
20131007 02:58:38-!- flix [~flix@37-5-10-145-dynip.superkabel.de] has left #wesnoth-dev []
20131007 03:01:01-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 245 seconds]
20131007 03:21:37-!- ancestral [~ancestral@174-20-209-41.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20131007 03:22:01-!- ancestral [~ancestral@174-20-209-41.mpls.qwest.net] has joined #wesnoth-dev
20131007 03:27:08-!- ancestral [~ancestral@174-20-209-41.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20131007 03:27:30-!- ancestral [~ancestral@174-20-209-41.mpls.qwest.net] has joined #wesnoth-dev
20131007 03:51:31-!- ancestral [~ancestral@174-20-209-41.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20131007 03:52:48-!- ancestral [~ancestral@174-20-209-41.mpls.qwest.net] has joined #wesnoth-dev
20131007 03:58:34-!- ancestral [~ancestral@174-20-209-41.mpls.qwest.net] has quit [Quit: And that’s the end of THAT chapter.]
20131007 04:14:05-!- Ivanovic_ [~ivanovic@x2f4c969.dyn.telefonica.de] has joined #wesnoth-dev
20131007 04:17:16-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 245 seconds]
20131007 04:17:21-!- Ivanovic_ [~ivanovic@x2f4c969.dyn.telefonica.de] has quit [Changing host]
20131007 04:17:22-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20131007 04:18:15-!- Ivanovic_ is now known as Ivanovic
20131007 04:51:08< irker800> wesnoth: mattsc wesnoth-old:master beac96055dd8 / data/campaigns/Son_Of_The_Black_Eye/scenarios/06_Black_Flag.cfg: SotBE S6: transport galleons now return after delivering troops http://git.io/6u3cPQ
20131007 05:23:21< irker800> wesnoth: mattsc wesnoth-old:master 18c9fd858a6a / data/campaigns/Son_Of_The_Black_Eye/scenarios/06_Black_Flag.cfg: SotBE S6: simplify the transport galleon code http://git.io/FJJggg
20131007 05:27:32< irker800> wesnoth: mattsc wesnoth-old:master aa2b5c3839c0 / data/campaigns/Son_Of_The_Black_Eye/scenarios/06_Black_Flag.cfg: SotBE S6: don't need 'landed' variable any more http://git.io/s8eBWg
20131007 06:16:58-!- esr [~esr@wesnoth/developer/esr] has quit [Read error: Connection reset by peer]
20131007 06:18:18-!- nurupo is now known as nurupo|away
20131007 06:19:34-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20131007 06:19:34-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Changing host]
20131007 06:19:34-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20131007 06:30:02-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 06:35:18-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 06:39:03-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 06:40:18-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 06:41:02-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 06:45:19-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 06:47:22-!- trademark_ [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has joined #wesnoth-dev
20131007 06:47:31-!- mattsc [~mattsc@154.20.32.246] has quit [Quit: Ciao]
20131007 06:48:02-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 06:50:19-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 06:55:03-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 06:55:19-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 06:57:07-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20131007 07:00:02-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 07:04:18-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20131007 07:06:18-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 07:07:03-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 07:11:18-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 07:12:07-!- tomreyn_ [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20131007 07:15:02-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 07:15:28-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Ping timeout: 240 seconds]
20131007 07:16:18-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 07:31:02-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 07:31:16-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 07:31:25-!- trademark_ [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has quit [Ping timeout: 246 seconds]
20131007 07:32:34< irker800> wesnoth: Ignacio R. Morelle wesnoth-old:master 299081932529 / data/tools/unit_tree/update-wmlunits: units.w.o: Upload to baldras.w.o instead of asheviere.w.o http://git.io/r4x5Pg
20131007 07:33:02-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 07:33:52-!- EliDupree [~quassel@66-189-34-122.dhcp.oxfr.ma.charter.com] has quit [Ping timeout: 246 seconds]
20131007 07:36:16-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 07:38:02-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 07:46:28-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 07:48:02-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 07:55:09-!- tomreyn_ is now known as tomreyn
20131007 07:56:28-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 08:14:27-!- exciton [chuck-the-@89.208.169.104] has quit [Ping timeout: 260 seconds]
20131007 08:30:37-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 08:38:04-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20131007 08:46:50-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Quit: Bye]
20131007 08:51:17-!- boucman_work [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20131007 09:05:03-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 09:05:18-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 09:10:20-!- exciton_ [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 09:13:15-!- exciton [chuck-the-@89.208.169.104] has quit [Ping timeout: 260 seconds]
20131007 09:19:19-!- exciton_ [chuck-the-@89.208.169.104] has quit [Ping timeout: 260 seconds]
20131007 09:20:18-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 09:27:15-!- exciton [chuck-the-@89.208.169.104] has quit [Ping timeout: 260 seconds]
20131007 09:31:21-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 09:39:42-!- Ard0nik [~ardonik@adsl-75-28-103-252.dsl.irvnca.sbcglobal.net] has joined #wesnoth-dev
20131007 09:42:42-!- Ardonik [~ardonik@adsl-75-28-107-173.dsl.irvnca.sbcglobal.net] has quit [Ping timeout: 264 seconds]
20131007 10:03:34-!- Crendgrim [~crend@77-23-29-102-dynip.superkabel.de] has quit [Quit: Konversation terminated!]
20131007 10:07:16-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Quit: tomreyn]
20131007 10:30:31-!- LordBob_ [~LordBob_@2a01:e34:ee82:47e0:21e:c2ff:fe01:261f] has left #wesnoth-dev []
20131007 10:31:37-!- Crendgrim [~crend@77-23-29-102-dynip.superkabel.de] has joined #wesnoth-dev
20131007 10:38:50-!- H-Hour [~H-Hour@cpc7-sgyl35-2-0-cust428.18-2.cable.virginmedia.com] has joined #wesnoth-dev
20131007 11:16:40-!- Ard0nik [~ardonik@adsl-75-28-103-252.dsl.irvnca.sbcglobal.net] has quit [Quit: Cats, devils, 'n porcupines]
20131007 11:39:15-!- alkenrinnstet [~alkenrinn@175.156.14.192] has joined #wesnoth-dev
20131007 11:47:02-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 264 seconds]
20131007 12:10:20-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 12:10:34-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 12:11:07-!- DCW [~Thunderbi@cpc1-finc14-2-0-cust12.4-2.cable.virginmedia.com] has joined #wesnoth-dev
20131007 12:13:24-!- alkenrinnstet [~alkenrinn@175.156.14.192] has quit [Quit: alkenrinnstet]
20131007 12:13:43-!- alkenrinnstet [~alkenrinn@175.156.14.192] has joined #wesnoth-dev
20131007 12:15:15-!- alkenrinnstet [~alkenrinn@175.156.14.192] has quit [Client Quit]
20131007 12:15:38-!- alkenrinnstet [~alkenrinn@175.156.14.192] has joined #wesnoth-dev
20131007 12:35:55-!- {V} [~V@139-79-ftth.on.nl] has quit [Read error: Connection reset by peer]
20131007 12:36:22-!- {V} [~V@139-79-ftth.on.nl] has joined #wesnoth-dev
20131007 12:41:22-!- alkenrinnstet [~alkenrinn@175.156.14.192] has quit [Quit: alkenrinnstet]
20131007 12:41:39-!- alkenrinnstet [~alkenrinn@175.156.14.192] has joined #wesnoth-dev
20131007 13:18:19-!- Kostic [~marko@85.202.113.22] has joined #wesnoth-dev
20131007 13:32:11-!- horon [~horon@nttkyo176024.tkyo.nt.ngn2.ppp.infoweb.ne.jp] has joined #wesnoth-dev
20131007 13:33:28-!- Turuk [~Turuk@cpe-65-29-217-233.cinci.res.rr.com] has joined #wesnoth-dev
20131007 13:33:52-!- Turuk is now known as Guest19347
20131007 13:35:24-!- irker800 [~irker@ai0867.net] has quit [Quit: transmission timeout]
20131007 13:40:51-!- gfgtdf [~chatzilla@c231252.adsl.hansenet.de] has joined #wesnoth-dev
20131007 13:52:35< gfgtdf> wesbot: seen mordante 
20131007 13:52:35< wesbot> gfgtdf: The person with the nick mordante last spoke 15h 9m ago.  15h 8m ago was here and on the channel #wesnoth-de with the message: Quit: Leaving
20131007 14:15:11-!- exciton [chuck-the-@89.208.169.104] has quit [Ping timeout: 260 seconds]
20131007 14:16:48-!- boucman_work [~rosen@wesnoth/developer/boucman] has quit [Ping timeout: 240 seconds]
20131007 14:17:52-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 14:21:22-!- mjs-de [~mjs-de@g224189012.adsl.alicedsl.de] has joined #wesnoth-dev
20131007 14:36:41-!- DCW [~Thunderbi@cpc1-finc14-2-0-cust12.4-2.cable.virginmedia.com] has quit [Remote host closed the connection]
20131007 14:52:31-!- Guest19347 [~Turuk@cpe-65-29-217-233.cinci.res.rr.com] has quit [Ping timeout: 245 seconds]
20131007 15:08:28-!- mattsc [~mattsc@207.230.251.234] has joined #wesnoth-dev
20131007 15:19:45-!- irker180 [~irker@ai0867.net] has joined #wesnoth-dev
20131007 15:19:46< irker180> wesnoth: mattsc wesnoth-old:master 813f70e16446 / data/campaigns/Son_Of_The_Black_Eye/scenarios/06_Black_Flag.cfg: SotBE S6: give units 2 MP after disembarking http://git.io/uOiDhw
20131007 15:19:46< irker180> wesnoth: mattsc wesnoth-old:master 3c5aab0c25d9 / data/campaigns/Son_Of_The_Black_Eye/scenarios/06_Black_Flag.cfg: SotBE S6: make it impossible to block gelleon landing sites http://git.io/V7CAKQ
20131007 15:23:01< mattsc> Hi zookeeper.  In SotBE S6 (Black Flag), I think it would make more sense for the transports to unload their units on the beach rather than in the water (if possible).  Currently, they are simply placed on the central hex with find_vacant=yes, and thus always come out on the top and left.
20131007 15:23:08< mattsc> Is there an easier way to do this in WML other than looping over all hexes within radius=1?  With a filter somehow maybe?
20131007 15:27:40< AI0867> SLF for sand hexes adjacent to the ship?
20131007 15:28:24-!- flix [~flix@37-5-10-145-dynip.superkabel.de] has joined #wesnoth-dev
20131007 15:28:51< mattsc> AI0867: but you still need to go through them and see if there are enough of them (and unoccupied) to unload all the units, right?
20131007 15:29:12< mattsc> You don't want the units to appear 2 hexes from the galleon, because there are not enough open sand hexes ...
20131007 15:29:44< mattsc> So, it'll still have to be a two-step process of some sort, if I understand this correctly.
20131007 15:30:05< AI0867> well, I'm not too familiar with the scenario, but you could make the ship unload over multiple turns if the beach is full (makes it vulnerable to blocking)
20131007 15:30:48-!- EliDupree [~quassel@66.189.34.122] has joined #wesnoth-dev
20131007 15:30:48< AI0867> and you could use the SLF to check for occupancy too
20131007 15:31:03< AI0867> that is, a SUF in the SLF would do the trick I believe
20131007 15:31:08< mattsc> AI0867: yeah, I think I'd rather have them unload in the water than make it possible to be taken down by the player (this is the enemy AI)
20131007 15:31:10< AI0867> [not]-wrapped
20131007 15:31:49< mattsc> AI0867: yeah, I think I'll do something like that, fill open beach hexes, then just unload the rest wherever ...
20131007 15:33:55< mattsc> AI0867: in the previous version, it was possible to keep the transports from unloading entirely by putting a unit on the landing side.  I just made that impossible up there ^.  (This is as a semi-related comment to your "makes it vulnerable to blocking".)
20131007 15:34:22< mattsc> It was just screaming abuse.  Check out where the transport is going to land, reload previous turn, put unit there ...
20131007 15:34:41< AI0867> well, you could also make the ship try to find unblocked beach
20131007 15:36:19< mattsc> Yeah, I considered that and didn't do it because of the way how the ships are coded.  I didn't see a huge advantage in that approach and was too lazy to rewrite things for that to work.
20131007 15:37:01< zookeeper> mattsc, right, yeah, i think they should rather try to find enough unblocked beach to land on, but if that fails then prefer solid ground when unloading. you'd just need to store all surrounding vacant hexes and do loops and all that.
20131007 15:37:33< zookeeper> don't the ships in clash of armies already do that, though?
20131007 15:37:52< zookeeper> dunno if the code is easily portable
20131007 15:37:54< mattsc> zookeeper: you mean the ships should try to find enough unblocked beach, or the units?
20131007 15:38:07< zookeeper> the ships
20131007 15:38:26< mattsc> Currently, the destination is chosen when a ship appears, and it gets there 4 or so turns later.
20131007 15:38:40< zookeeper> that is, when deciding on a destination, they should prefer a destination that has enough vacant land adjacent to it over destinations which don't
20131007 15:39:03< zookeeper> ah, i thought i made them randomize the destination each turn
20131007 15:39:45< AI0867> well, 4 turns ahead is too early, but they could redirect when they come into range
20131007 15:39:54< AI0867> ahead of time
20131007 15:39:59< AI0867> argh, my keyboard is lagging
20131007 15:40:05< AI0867> and my repairs missed a few things
20131007 15:40:44< mattsc> zookeeper: hmm, I should look at that again.  I might have inadvertently turned the off yesterday.  :P
20131007 15:40:58< zookeeper> uh, okay :>
20131007 15:41:31< mattsc> I thought it only did this for new transports, but I might have misread something...
20131007 15:41:41< mattsc> ... but even if it was that way, it never considered enemy units when choosing a location.
20131007 15:42:12< mattsc> (sorry that sounded wrong: I'm not doubting that it was, most likely I messed up.)
20131007 15:44:14< zookeeper> regardless, i wrote the ships for black flag before the ones in clash of armies, so the latter are naturally a bit more advanced
20131007 15:46:00< mattsc> zookeeper: https://github.com/wesnoth/wesnoth-old/blob/beac96055dd81f3be439e3d07354e2eeb2c5116c/data/campaigns/Son_Of_The_Black_Eye/scenarios/06_Black_Flag.cfg#L343
20131007 15:46:13< mattsc> That's the version before I made the change.
20131007 15:47:08< mattsc> In lines 366 etc., it just chooses the goto_x/y from what's stored in the unit, and that only gets reset above for units which don't have a location set yet, doesn't it?
20131007 15:47:46< mattsc> I'm not trying to argue, just making sure that I understand what's going on ...
20131007 15:47:57< zookeeper> no, the loop in 298-341 randomizes each ship's destination and 361-368 just sets the gotos
20131007 15:48:15< zookeeper> so each turn, the destination gets randomized
20131007 15:48:32< zookeeper> oh wait
20131007 15:48:41< mattsc> even with the filer in l.285-292?
20131007 15:48:47< mattsc> s/filer/filter
20131007 15:48:52< zookeeper> yeah you're right, i missed that filter
20131007 15:49:19< mattsc> okay, so we should reinstate that version, but replace that filter with [not]landed=yes ?
20131007 15:49:40< mattsc> And then also add a condition for this not being occupied by enemies?
20131007 15:50:23< mattsc> zookeeper: I just saw what the code was doing and figured that was intentional, and replaced it by a simpler version that does the same.  Sorry for that.  :P
20131007 15:52:02< zookeeper> not sure, if the ship is already close to the shore and then decides to head for a destination further along the coast, it's prone to end it's turn next to the shore or shallow water and be very vulnerable to attack
20131007 15:52:37< mattsc> zookeeper: true
20131007 15:53:41< zookeeper> maybe 1) randomize destination each turn, picking one that has vacant surroundings but 2) if any shore hex is within reach this turn, move there and unload no matter what?
20131007 15:53:57< zookeeper> eh, in that case it'd be perhaps too easy to catch them at the tip of the peninsula(s?) or something
20131007 15:54:03< mattsc> In that case, the ...
20131007 15:54:11< mattsc> yes, that's what I was just going to write.
20131007 15:54:26< zookeeper> hmh
20131007 15:54:28 * zookeeper ponders
20131007 15:55:10< mattsc> It seems like one of those situations where it's difficult to take all eventualities into account (and teach the AI how to do it)
20131007 15:55:52< mattsc> zookeeper: this is the reason why I set it up to unload even if it cannot get to the destination hex, so that it's not possible to block it from unloading altogether.
20131007 15:56:05< mattsc> But that's definitely an imperfect solution also.
20131007 15:57:11< zookeeper> yeah. so... i'm starting to lean towards any destination with at least one vacant hex for landing a unit onto being ok
20131007 15:57:26< zookeeper> and then of course landing units on land hexes if possible
20131007 15:57:55< mattsc> and check for that every turn?
20131007 15:58:27< mattsc> I'd also like to avoid the ships going back and forth between parts of the made because the goal gets changed all the time.
20131007 15:58:38< mattsc> s/made/map
20131007 15:58:47< zookeeper> check for a destination with at least one free hex? yeah
20131007 15:59:05< zookeeper> i mean sure, the destination doesn't need to be randomized each turn
20131007 15:59:41< mattsc> So, how about, we check for such a hex as close to the original destination as possible each turn.
20131007 16:01:06< zookeeper> maybe the easiest would be to 1) check when the ship is in range of the destination and then 2) find the exact landing location the same way as before, but this time only limited to the area the ship can reach this/next turn
20131007 16:02:19< zookeeper> but really, this is just fine polishing and most people would just be thrilled if they could catch some enemy units in the water so whatever you come up with is fine
20131007 16:02:31< mattsc> I think that makes sense.  I'll try that tonight or so.
20131007 16:03:59-!- flix [~flix@37-5-10-145-dynip.superkabel.de] has quit [Remote host closed the connection]
20131007 16:04:01< mattsc> Sure, but that's what I am trying to avoid (making it too easy on people).  I also gave all units 2 MP after landing, so as to make it a bit harder.   :x 
20131007 16:04:33< zookeeper> you mean they can move on the same turn as they land?
20131007 16:04:43< mattsc> zookeeper: yes
20131007 16:04:52< mattsc> but only one hex, in general
20131007 16:05:01< zookeeper> can they attack?
20131007 16:05:12< mattsc> yes - they already could do that before.
20131007 16:05:18< zookeeper> oh, right
20131007 16:05:54< mattsc> zookeeper: and I think that makes sense - if you land a boat, you expect the troops to be jumping out and attack right away, but maybe not be able to get as far as on a normal turn.
20131007 16:06:01< mattsc> Well, it makes sense to me, at least.
20131007 16:06:55< zookeeper> well apparently i didn't think them being able to attack immediately is a big problem back then. the reason why i'd generally avoid that is that it can make for a rather nasty tomato surprise, at least when you play for the first time and don't know what those ships will do exactly
20131007 16:07:40< zookeeper> if they can also move then they could potentially ZoC some of your units which would be much more lethal
20131007 16:08:06< mattsc> zookeeper: I agree - but my preference would be to add a line into the dialog, maybe by the local orcs warning Kapou'e that this is going to happen, rather than not having them attack.
20131007 16:08:10-!- flix [~flix@37-5-10-145-dynip.superkabel.de] has joined #wesnoth-dev
20131007 16:08:15< zookeeper> yeah i was just about to suggest that :p
20131007 16:08:23< mattsc> The way it is, if you know what is going to happen, they make for really easy bait.
20131007 16:08:50< mattsc> So it's an inverse tomato surprise, in a way.
20131007 16:09:19< mattsc> My thought of changing that was to at least give them a chance to get on slightly better terrain.
20131007 16:09:47< zookeeper> just have someone say that they see human soldiers on deck and suggest that you stay clear of the beach and it ought to be fine
20131007 16:10:17< mattsc> Yeah.  If you disagree with any of this, just let me know.  I don't have my heart set on any of this, and am just trying to do what makes sense to me and don't want to bug you with every single thing.
20131007 16:10:31< mattsc> zookeeper: I also made the galleons return to their starting point once they are done unloading.  It didn't make sense.  That's more from a "story" perspective than for gameplay.  It didn't make sense to me that they'd just sit around to be slaughtered.  Any objections?
20131007 16:10:49< mattsc> I mean: it didn't make sense TO ME (again) ...
20131007 16:11:27< mattsc> flix: Hi - you did implement the new goto CA behavior, right?
20131007 16:11:59< flix> mattsc: hi! yes
20131007 16:12:12< mattsc> flix: it seems that it throws an E_NOT_REACHED_DESTINATION now if a unit cannot get to the final destination on the current turn.
20131007 16:12:38< mattsc> flix: I believe that it did not do that before (but am not 100% sure of that)
20131007 16:13:25< irker180> wesnoth: flix wesnoth-old:master c630bb2e1a22 / src/menu_events.cpp: Check for victory when killing a unit. (debug) http://git.io/6h4-zw
20131007 16:13:58< mattsc> flix: ooo, nice.  I have to try that...
20131007 16:14:30< mattsc> flix, zookeeper: right now I have to be off for 30min or so though.  I'll check the logs when I get back online.
20131007 16:14:32< zookeeper> free XP? :P the only reason not to have them sail back is that it might be a bit confusing about what they're doing now (are they going to land again, or what?), but that's probably not a big deal. alternatively they could be armed (i think transport galleons don't have a ranged attack, right?) and just sail straight _onto_ the beach so it'd seem like they're really not intending on turning 
20131007 16:14:32< zookeeper> back anytime soon
20131007 16:14:34< zookeeper> me too
20131007 16:14:38< flix>  mattsc: :). E_NOT_REACHED_DESTINATION: You can only see this in stderr right?
20131007 16:15:05< mattsc> flix: right - or in the terminal, if you start Wesnoth on the CL
20131007 16:15:29< flix> mattsc: okay, I have a guess why it is like it is. let me check
20131007 16:15:37< flix> mattsc:  see you later
20131007 16:15:43< mattsc> flix: actually, it might be stdout, I don't remember.  Both show up in the terminal in my case.
20131007 16:15:52< mattsc> flix: by for now
20131007 16:16:05-!- mattsc [~mattsc@207.230.251.234] has quit [Quit: Computer's napping]
20131007 16:19:28-!- alkenrinnstet [~alkenrinn@175.156.14.192] has quit [Ping timeout: 240 seconds]
20131007 16:20:51-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20131007 16:22:19-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20131007 16:34:00-!- horon [~horon@nttkyo176024.tkyo.nt.ngn2.ppp.infoweb.ne.jp] has quit [Quit: Leaving...]
20131007 16:38:16-!- mattsc [~mattsc@fw.hia.nrc.ca] has joined #wesnoth-dev
20131007 16:46:06< mattsc> flix: just tested your last commit.  Works perfectly and is very convenient for some things, thanks!
20131007 16:46:49< mattsc> zookeeper: how about I write a LuaAI CA to control the ships?
20131007 16:47:48< mattsc> There are some other effects of the current method that I don't quite like and that would be really hard to get rid of using WML only.
20131007 16:48:35< mattsc> For example, a ship might end up next to a land tile on its way to a landing point and be vulnerable to attack there before it even gets to its destination.
20131007 16:53:04-!- mattsc [~mattsc@fw.hia.nrc.ca] has quit [Quit: mattsc]
20131007 16:55:36-!- mattsc [~mattsc@fw.hia.nrc.ca] has joined #wesnoth-dev
20131007 17:09:06-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has quit [Ping timeout: 268 seconds]
20131007 17:10:25-!- Vandal [Ganrao@cpe-65-189-245-210.woh.res.rr.com] has quit []
20131007 17:10:26-!- trademark_ [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has joined #wesnoth-dev
20131007 17:19:54< irker180> wesnoth: flix wesnoth-old:master 6472560ca74f / src/ai/ (contexts.cpp contexts.hpp testing/ca.cpp): Pass unreach_is_ok in move-action. http://git.io/jlLbKA
20131007 17:20:58< zookeeper> mattsc, as long as it works, sure
20131007 17:21:20< flix> mattsc: ^ This is more a error suppression, but I think in this case it is fine. Also it saves runtime.
20131007 17:21:45< mattsc> zookeeper: I think I can make it work better than with WML (although not sure by how much)
20131007 17:22:20< mattsc> zookeeper: any additional comments in that case concerning the desired behavior?
20131007 17:22:55< mattsc> flix: testing
20131007 17:24:07< mattsc> flix: this suppresses the error only for the goto CA, right?  (Because in other cases I do want to know about it.)
20131007 17:24:48< flix> mattsc: yes. And it suppresses only this particular error
20131007 17:27:03< mattsc> flix: looks good.  Thanks (yet again) !
20131007 17:27:10< zookeeper> mattsc, i'm sure the logic could be completely reimagined if you're basically re-implementing the whole thing anyway, but i don't really have any particular suggestions.
20131007 17:27:29< zookeeper> why did i dash one word but not the other? durr.
20131007 17:27:51< flix> mattsc: also the functionality was already there (https://github.com/flixx/wesnoth-old/blob/master/src/ai/actions.cpp#L438), I just passed over some boolean parameters
20131007 17:27:58< flix> mattsc:  no problem
20131007 17:28:07< mattsc> zookeeper: okay - I am currently thinking about it in very broad terms:
20131007 17:28:17< mattsc> - Set destination when ship appears
20131007 17:28:26< mattsc> - Keep ship in deep water until very last move
20131007 17:28:48< mattsc> - On last move, find "safe" landing spot, as close to original location as possible
20131007 17:29:00< mattsc> The trick if going to be to define what 'safe' means.
20131007 17:33:54-!- boucman_work [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20131007 17:36:38< zookeeper> mattsc, you want it to actually consider safety rather than just the number of vacant hexes?
20131007 17:37:29-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20131007 17:37:36< lipkab> Espreon: How do you say "chestnut" in Classical Nahuatl?
20131007 17:37:39< mattsc> zookeeper: well, I used the term safety loosely here.  I meant it as: want to be able to unload units on land rather than in the water.
20131007 17:37:49< zookeeper> okay
20131007 17:38:37< mattsc> So, hexes not adjacent to an enemy unit are usually preferable.
20131007 17:39:03< mattsc> But simply counting the accessible land hexes should (probably) do the trick.
20131007 17:42:33< zookeeper> btw, "keep ship in deep water" should probably mean "keep ship in deep water but _not_ adjacent to shallow water" since otherwise you can still get to attack the ship before unloading
20131007 17:42:43< zookeeper> s/but/and
20131007 17:44:52< mattsc> zookeeper: agreed - but I think that means making some minor changes to the map also, otherwise the ship might have a hard time getting into the harbor.
20131007 17:45:15< zookeeper> fine by me
20131007 17:45:45< mattsc> I don't think it would change gameplay at all, as there already is no path through the water across the harbor.
20131007 18:09:36-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has quit [Ping timeout: 248 seconds]
20131007 18:10:16-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20131007 18:12:37-!- {V} [~V@139-79-ftth.on.nl] has quit [Read error: Connection reset by peer]
20131007 18:12:52-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has quit [Read error: Connection reset by peer]
20131007 18:13:30-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20131007 18:13:49-!- {V} [~V@139-79-ftth.on.nl] has joined #wesnoth-dev
20131007 18:26:41-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has quit [Ping timeout: 245 seconds]
20131007 18:26:53-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20131007 18:29:15-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has quit [Read error: Connection reset by peer]
20131007 18:29:55-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20131007 18:34:02-!- lipkab2 [~the_new_l@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20131007 18:34:14-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has quit [Ping timeout: 240 seconds]
20131007 18:56:23-!- boucman_work [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20131007 19:00:11-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 19:05:27-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 19:21:56-!- mjs-de [~mjs-de@g224189012.adsl.alicedsl.de] has quit [Remote host closed the connection]
20131007 19:27:53< gfgtdf> mordante: i just tested and i could sucesfully generate the gzip error on linux with a small test programm so this is definitely not a windows-only issue, maybe you have a older version of boost (< 1.44) installed or no addon that has a empy config file (that are mainly  MP mappacks or other resources like "asof Music")
20131007 19:30:01-!- lipkab2 [~the_new_l@host-91-147-212-174.biatv.hu] has quit [Ping timeout: 245 seconds]
20131007 19:38:03-!- lipkab2 [~the_new_l@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20131007 19:42:42-!- lipkab2 [~the_new_l@host-91-147-212-174.biatv.hu] has quit [Ping timeout: 264 seconds]
20131007 19:44:04-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20131007 19:52:58-!- Kostic [~marko@85.202.113.22] has quit [Remote host closed the connection]
20131007 19:55:21-!- Kostic [~marko@85.202.113.216] has joined #wesnoth-dev
20131007 20:10:45-!- EdB [~edb@abo-152-221-68.trs.modulonet.fr] has joined #wesnoth-dev
20131007 20:15:01-!- mjs-de [~mjs-de@wh.uni-dortmund.de] has joined #wesnoth-dev
20131007 20:19:57-!- irker180 [~irker@ai0867.net] has quit [Quit: transmission timeout]
20131007 20:27:21-!- irker568 [~irker@ai0867.net] has joined #wesnoth-dev
20131007 20:27:21< irker568> wesnoth: flix wesnoth-old:master 516154c3d18d / / (11 files in 2 dirs): Refactor ai-test-suite (python script). http://git.io/Y8ctFQ
20131007 20:28:07< flix> mattsc: Belongs this^ into the release notes?
20131007 20:30:57< mattsc> flix: probably not.  The total number of people who use this at the moment might be something like 2 (I have my own test scripts, so I'm not one of those 2).
20131007 20:31:18< flix> mattsc: okay
20131007 20:33:12-!- EdB [~edb@abo-152-221-68.trs.modulonet.fr] has quit [Quit: Konversation terminated!]
20131007 20:41:26-!- prkc [~negusnyul@catv-89-134-173-191.catv.broadband.hu] has joined #wesnoth-dev
20131007 20:49:15-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20131007 20:52:45-!- flix [~flix@37-5-10-145-dynip.superkabel.de] has quit [Quit: Leaving.]
20131007 20:52:58< bumbadadabum> https://github.com/wesnoth/wesnoth-old/pull/78
20131007 20:53:07< bumbadadabum> I updated the HttT anims to the new syntax
20131007 20:53:58-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20131007 20:55:11-!- thunderstruck [~zaibotren@cpc5-sgyl29-2-0-cust174.sgyl.cable.virginmedia.com] has joined #wesnoth-dev
20131007 20:55:32-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Remote host closed the connection]
20131007 20:55:44-!- Ivanovic [~ivanovic@x2f4c969.dyn.telefonica.de] has joined #wesnoth-dev
20131007 20:55:44-!- Ivanovic [~ivanovic@x2f4c969.dyn.telefonica.de] has quit [Changing host]
20131007 20:55:44-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20131007 20:56:35-!- trewe [~trewe@87.196.48.104] has joined #wesnoth-dev
20131007 20:56:50< thunderstruck> ping _Coffee 
20131007 20:59:44-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has quit [Ping timeout: 248 seconds]
20131007 21:03:59-!- exciton [chuck-the-@89.208.169.104] has quit [Ping timeout: 260 seconds]
20131007 21:04:34-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20131007 21:06:26-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 21:16:01-!- Kostic [~marko@85.202.113.216] has quit [Ping timeout: 246 seconds]
20131007 21:52:00-!- mjs-de [~mjs-de@wh.uni-dortmund.de] has quit [Ping timeout: 248 seconds]
20131007 21:58:08-!- mjs-de [~mjs-de@wh.uni-dortmund.de] has joined #wesnoth-dev
20131007 22:06:06-!- mjs-de [~mjs-de@wh.uni-dortmund.de] has quit [Ping timeout: 264 seconds]
20131007 22:08:08-!- mjs-de [~mjs-de@wh.uni-dortmund.de] has joined #wesnoth-dev
20131007 22:21:09-!- Kostic [~marko@net106-1-245-109.mbb.telenor.rs] has joined #wesnoth-dev
20131007 22:22:56-!- mjs-de [~mjs-de@wh.uni-dortmund.de] has quit [Ping timeout: 245 seconds]
20131007 22:24:14-!- trademark_ [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has quit [Ping timeout: 264 seconds]
20131007 22:25:47-!- mattsc [~mattsc@fw.hia.nrc.ca] has quit [Quit: Ciao]
20131007 22:35:00-!- mjs-de [~mjs-de@wh.uni-dortmund.de] has joined #wesnoth-dev
20131007 22:55:10-!- thunderstruck [~zaibotren@cpc5-sgyl29-2-0-cust174.sgyl.cable.virginmedia.com] has quit [Quit: leaving]
20131007 22:59:38< _Coffee> just missed thunderstuck :P
20131007 23:00:14-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer]
20131007 23:05:29-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev
20131007 23:11:38-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20131007 23:11:53< zookeeper> bumbadadabum, how does the timing of the new leading anims work? doesn't for example konrad's leading anims now make him raise the sword at time 0?
20131007 23:12:28< bumbadadabum> zookeeper: It should, yeah
20131007 23:13:32< zookeeper> but that's not how it _should_ be. he should do the anim _during_ the attack, not after the enemy's already been struck (or missed)
20131007 23:13:57< bumbadadabum> eh, maybe
20131007 23:14:18< bumbadadabum> Yeah, I might change that then
20131007 23:14:24< _Coffee> nice to see that animation timings are being discussed
20131007 23:14:30< zookeeper> if he starts the anim at time 0 then it's more like "you hit him, yay" :p
20131007 23:14:51-!- LordBob_ [~LordBob_@2a01:e34:ee82:47e0:21e:c2ff:fe01:261f] has joined #wesnoth-dev
20131007 23:15:12< bumbadadabum> hmm
20131007 23:15:24< _Coffee> yeah that is true
20131007 23:15:33< bumbadadabum> it seems the leading anim without a transition frame it acts weirdly
20131007 23:15:35< _Coffee> most of the arrows hit at time=0 and such
20131007 23:15:44< bumbadadabum> scrap one it
20131007 23:15:59< zookeeper> _everything_ should hit at time 0
20131007 23:16:00< _Coffee> time=0 is now supposed to be uniformly(ish) when the unit hits another unit
20131007 23:16:04< zookeeper> yeah
20131007 23:16:14< bumbadadabum> Yeah
20131007 23:16:22< bumbadadabum> It was a tiny bit of my silliness
20131007 23:16:26< bumbadadabum> I'll change it
20131007 23:16:26< _Coffee> bumbadadabum: you actually fixed up a lot of it ;)
20131007 23:17:16< zookeeper> the old timing of being from -150 to 150 is good, although i'm still not sure if that results in the frame being displayed for the whole duration of the attack (which might have been what you were referring to when you said it acts weirdly)
20131007 23:17:43< bumbadadabum> hmm
20131007 23:17:50< _Coffee> zookeeper: the problem was that the units finished at different times and it didn't work well
20131007 23:17:57< bumbadadabum> the anim without the transition frame makes it never lower it
20131007 23:19:07< zookeeper> at least in the past, all anims got "padded" not with the base frame of the unit, but the first/last frame of the anim. like if the attack takes 600ms and a leading anim only 300ms, then the missing 300ms will get padded with the first and last frames of the leading anim
20131007 23:19:10< _Coffee> zookeeper: as far as I can tell the animations were never from -150 to 150, but rather some random start time
20131007 23:19:12< zookeeper> dunno if that's still the case
20131007 23:19:49< zookeeper> sounds weird. sounds like you might need to summon boucman
20131007 23:20:05< _Coffee> zookeeper: this was looked at http://forums.wesnoth.org/viewtopic.php?f=9&t=38983
20131007 23:20:31< _Coffee> I did a bit of work with boucman when changing the syntax to allow for combining of frames
20131007 23:20:32< boucman> _Coffee: in theory animations start at the min of all frames start time
20131007 23:20:45< _Coffee> hi boucman
20131007 23:20:48< zookeeper> yeah unfortunately some new animations have gotten their sound timings all messed up
20131007 23:20:50< _Coffee> yeah
20131007 23:21:03< bumbadadabum> I think we fixed most of them
20131007 23:21:12< _Coffee> zookeeper: some always had bad animation timings :P
20131007 23:21:19< boucman> if it's a sound frame, the rule still applies, so you need to add a zero duration as padding at the start
20131007 23:21:20< _Coffee> bumbadadabum fixed many of them
20131007 23:21:32< _Coffee> boucman: I'd like to fix that bug
20131007 23:21:46< bumbadadabum> balrog: Also with halos
20131007 23:21:48< boucman> (since the first frame is used from the real start time until the start time specified for the animation)
20131007 23:21:53< zookeeper> _Coffee, well... new == animations introduced after i retired from being the acting animation nazi :>
20131007 23:21:57< bumbadadabum> *boucman
20131007 23:21:58< bumbadadabum> ugh
20131007 23:22:02< bumbadadabum> tab completion
20131007 23:22:09< boucman> yes, with haloes too.
20131007 23:22:29< bumbadadabum> zookeeper: Want to take back that position?
20131007 23:22:32< bumbadadabum> it's needed at times
20131007 23:22:36< _Coffee> the main problem with animations at the moment in terms of consistency is the random start time
20131007 23:22:39< boucman> _Coffee: and that's how it's intended, not a bug (at least from what I understand from your discussion)
20131007 23:23:16< boucman> _Coffee: you sure it's random ? not just the min of all anim start time ?
20131007 23:23:50< _Coffee> boucman: in data/cor/macros/animation-utils.cfg: defense_anim, putting in the fake duration 1 sound frame
20131007 23:24:10< zookeeper> bumbadadabum, not really
20131007 23:24:10< _Coffee> boucman: sorry, I was referring to the spread not being uniform across all units
20131007 23:24:14< bumbadadabum> zookeeper: Pushed a change
20131007 23:24:21< boucman> _Coffee: i need to go afk, let's discuss it another time, sorry
20131007 23:24:28< _Coffee> boucman: the leadership animation is hard to time then
20131007 23:24:30< bumbadadabum> zookeeper: I've kinda been doing that for the dwarves
20131007 23:24:52< _Coffee> boucman: ok
20131007 23:24:58< zookeeper> all the really new melee anims for instance are dreadfully slow compared to the older ones, which produces a kind of a mismatch
20131007 23:25:01< bumbadadabum> being an anim nazi
20131007 23:25:06< _Coffee> suppose it is a different time in france
20131007 23:25:27< bumbadadabum> zookeeper: Well, the fps just needs to improve for them
20131007 23:25:28< zookeeper> old ones used to be like from -300 to 250 or so, and the new ones are... i dunno, probably at least a second long D:
20131007 23:25:38< bumbadadabum> let me check
20131007 23:26:00-!- lipkab [~the_new_l@host-91-147-212-174.biatv.hu] has quit [Quit: Távozom]
20131007 23:26:05< bumbadadabum> zookeeper: 900ms for the dwarves
20131007 23:26:21< zookeeper> right
20131007 23:26:39< bumbadadabum> I decided not to mess with Jet's timings, but I could shorten them if people want that
20131007 23:26:54< zookeeper> since no one can convince jetrel that the anims should be shorter, the best course of action would likely to bump all melee anims (even the old ones) to the same dreadfully long length
20131007 23:27:06< zookeeper> then they'd be consistent and people could just bump their acceleration slider up a notch
20131007 23:27:25< bumbadadabum> zookeeper: The problem is creating the uniform
20131007 23:27:58< bumbadadabum> animations will keep getting longer, if we follow the current trend
20131007 23:28:22< zookeeper> creeping longerism
20131007 23:28:36< zookeeper> biggerism was bad enough already
20131007 23:28:39-!- Samual_ [diotecktec@xonotic/core-team/Samual] has joined #wesnoth-dev
20131007 23:28:43< bumbadadabum> I think the current length is ideal
20131007 23:28:51< bumbadadabum> (for 2x speed)
20131007 23:29:02< bumbadadabum> current as in for the new anims
20131007 23:30:46< bumbadadabum> Also, I don't feel like increasing the 100ms anims' length to 1 second would be the most pleasant for the player
20131007 23:31:32< bumbadadabum> watching a unit-attack.png for 1 second isn't that fun
20131007 23:31:44< zookeeper> if there's any 100ms attack anims then someone's screwed up bad
20131007 23:31:49< bumbadadabum> well
20131007 23:31:59-!- Ingmar__ [~ingmar@tchaikovsky.exherbo.org] has joined #wesnoth-dev
20131007 23:32:00< bumbadadabum> there are some pretty short ones
20131007 23:32:27< zookeeper> but surely none below 300ms? except maybe in some silly UtBS unit
20131007 23:32:58< bumbadadabum> 250ms for some ranged attacks
20131007 23:33:28< zookeeper> hrhm
20131007 23:33:40< zookeeper> unfortunately i gotta head to bed, but i
20131007 23:33:43< zookeeper> 'll read the logs
20131007 23:33:44< bumbadadabum> yeah, most of the very old anims are about 300ms
20131007 23:33:51< bumbadadabum> yeah, I need to be off as well
20131007 23:34:01< zookeeper> we need a new animations nazi
20131007 23:34:12< bumbadadabum> I'll think about it
20131007 23:34:49-!- Samual [diotecktec@xonotic/core-team/Samual] has quit [Ping timeout: 245 seconds]
20131007 23:34:51-!- iwaim_ [~iwaim@2001:2c0:40e:2002:0:4:14:80] has quit [Ping timeout: 245 seconds]
20131007 23:34:51-!- _Coffee [~david@ppp121-45-28-250.lns20.adl2.internode.on.net] has quit [Ping timeout: 245 seconds]
20131007 23:34:52-!- Ingmar [~ingmar@exherbo/developer/ingmar] has quit [Ping timeout: 245 seconds]
20131007 23:37:09-!- iwaim_ [~iwaim@2001:2c0:40e:2002:0:4:14:80] has joined #wesnoth-dev
20131007 23:38:21-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 245 seconds]
20131007 23:39:16-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Quit: Bye]
20131007 23:40:58-!- Coffee_irc [~david@ppp121-45-28-250.lns20.adl2.internode.on.net] has joined #wesnoth-dev
20131007 23:41:52< Coffee_irc> hello again
20131007 23:42:25< Coffee_irc> had to register a nick, because the ones I could come up with were taken
20131007 23:45:22-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20131007 23:45:40-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20131007 23:45:59-!- gfgtdf_ [~chatzilla@f054139031.adsl.alicedsl.de] has joined #wesnoth-dev
20131007 23:48:06-!- gfgtdf [~chatzilla@c231252.adsl.hansenet.de] has quit [Ping timeout: 264 seconds]
20131007 23:48:09-!- gfgtdf_ is now known as gfgtdf
20131007 23:50:54< Espreon> lipkab: No idea. Why?
20131007 23:51:31< Espreon> lipkab: I somehow doubt they have a word for it.
20131007 23:57:30-!- Kostic [~marko@net106-1-245-109.mbb.telenor.rs] has quit [Quit: Kostic]
--- Log closed Tue Oct 08 00:00:54 2013