--- Log opened Mon Jul 16 00:00:39 2012
20120716 00:21:00< CIA-87> alarantalara * r54744 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: Delete two more empty sides
20120716 00:28:23-!- MeccaGod [majs@host189-199.bornet.net] has quit []
20120716 00:41:04-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20120716 00:41:07< CIA-87> alarantalara * r54745 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: Delete variables for amulet and secret door opening
20120716 00:49:35< CIA-87> alarantalara * r54746 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: no more tentacles on dry land
20120716 01:05:24< CIA-87> alarantalara * r54747 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: Further cleanup of tentacle spawning
20120716 01:10:34< CIA-87> alarantalara * r54748 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: do not store the same set of locations 3 times in a row
20120716 01:17:45< CIA-87> alarantalara * r54749 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: Units that can recruit already have free upkeep
20120716 01:28:08< CIA-87> alarantalara * r54750 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: Realize some commented out dialog
20120716 02:02:58< CIA-87> alarantalara * r54751 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: Use move_unit instead of move_unit_fake to retreat Zurg
20120716 02:43:09-!- ToBeFree [~tobefree@unaffiliated/tobefree] has quit [Remote host closed the connection]
20120716 02:44:39-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection]
20120716 03:03:04-!- jamit [~james@pool-173-61-167-63.cmdnnj.east.verizon.net] has quit [Quit: Leaving.]
20120716 03:07:08-!- LordNasty [~NaSTy@93-43-160-229.ip92.fastwebnet.it] has quit [Read error: Operation timed out]
20120716 03:07:17-!- LordNasty [~NaSTy@93-43-160-229.ip92.fastwebnet.it] has joined #wesnoth-dev
20120716 03:16:45-!- eirikvw [189a49d2@gateway/web/freenode/ip.24.154.73.210] has joined #wesnoth-dev
20120716 03:21:24< CIA-87> alarantalara * r54752 /trunk/data/campaigns/Under_the_Burning_Suns/ (2 files in 2 dirs): Some tunnel expansion. The slight increase in movement this provides should help balance the delay caused by not killing the other dwarf earlier.
20120716 03:42:32< CIA-87> alarantalara * r54753 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: The terrain id grass has been flat for a long time. Also, there is no shallow water nearby.
20120716 03:47:45< CIA-87> alarantalara * r54754 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: Zurg is a Troll Shaman not a Whelp
20120716 03:55:23-!- un214 [~un214@108.221.231.209] has joined #wesnoth-dev
20120716 03:58:58< CIA-87> alarantalara * r54755 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: Make movement of Zurg actually visible (instead of before the tunnel is revealed)
20120716 04:10:21< CIA-87> alarantalara * r54756 /trunk/data/campaigns/Under_the_Burning_Suns/ (4 files in 2 dirs): Make a macro to shake the screen. Fixes several instances where the direction was incorrect on the second shake.
20120716 04:13:30-!- eirikvw [189a49d2@gateway/web/freenode/ip.24.154.73.210] has left #wesnoth-dev []
20120716 04:15:07-!- Alarantalara [~Adium@CPEc0c1c09e8055-CM00252eac6d62.cpe.net.cable.rogers.com] has quit [Quit: Leaving.]
20120716 04:17:00-!- LordNasty [~NaSTy@93-43-160-229.ip92.fastwebnet.it] has quit [Ping timeout: 248 seconds]
20120716 04:18:06-!- LordNasty [~NaSTy@93-43-160-229.ip92.fastwebnet.it] has joined #wesnoth-dev
20120716 04:23:47-!- Ivanovic_ [~ivanovic@dtmd-4db27825.pool.mediaWays.net] has joined #wesnoth-dev
20120716 04:26:44-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 260 seconds]
20120716 04:27:41-!- Ivanovic_ is now known as Ivanovic
20120716 05:19:31-!- Gambit [~gambit@wesnoth/developer/grickit] has quit [Remote host closed the connection]
20120716 05:33:05-!- un214 [~un214@108.221.231.209] has quit [Remote host closed the connection]
20120716 05:37:02-!- horon [~horon@nttkyo331099.tkyo.nt.ngn2.ppp.infoweb.ne.jp] has joined #wesnoth-dev
20120716 05:42:45< shadowm> !file /trunk/src/actions.cpp
20120716 05:42:45< shikadibot> shadowm: Web interface URL to file trunk/src/actions.cpp: http://svn.gna.org/viewcvs/wesnoth/trunk/src/actions.cpp?view=markup
20120716 06:06:06-!- Upth [~ogmar@108-85-91-228.lightspeed.frokca.sbcglobal.net] has joined #wesnoth-dev
20120716 06:08:28-!- Upthorn [~ogmar@108-85-91-228.lightspeed.frokca.sbcglobal.net] has quit [Ping timeout: 245 seconds]
20120716 06:10:36-!- Upth [~ogmar@108-85-91-228.lightspeed.frokca.sbcglobal.net] has quit [Ping timeout: 248 seconds]
20120716 06:53:43-!- trademark_ [~trademark@mon69-1-82-67-23-185.fbx.proxad.net] has joined #wesnoth-dev
20120716 07:07:40-!- Gallaecio [~quassel@84.120.114.134.dyn.user.ono.com] has joined #wesnoth-dev
20120716 07:12:23-!- Ivanovic [~ivanovic@dtmd-4db27825.pool.mediaWays.net] has quit [Changing host]
20120716 07:12:23-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20120716 07:44:07-!- trademark_ [~trademark@mon69-1-82-67-23-185.fbx.proxad.net] has quit [Ping timeout: 246 seconds]
20120716 08:05:02-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20120716 08:27:56-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20120716 09:26:36-!- neXyon [~neXyon@84-119-52-87.dynamic.xdsl-line.inode.at] has joined #wesnoth-dev
20120716 09:28:44-!- horon [~horon@nttkyo331099.tkyo.nt.ngn2.ppp.infoweb.ne.jp] has quit [Quit: Leaving...]
20120716 09:37:34-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20120716 09:48:38-!- LordNasty [~NaSTy@93-43-160-229.ip92.fastwebnet.it] has quit [Ping timeout: 246 seconds]
20120716 09:55:07-!- ejls [~Epsilon01@mszy.domu.7un.net] has quit [Ping timeout: 240 seconds]
20120716 10:02:39-!- PolarPanda [~quassel@unaffiliated/peterporty] has joined #wesnoth-dev
20120716 10:15:25-!- PolarPanda [~quassel@unaffiliated/peterporty] has quit [Read error: Connection reset by peer]
20120716 10:16:18-!- PolarPanda [~quassel@unaffiliated/peterporty] has joined #wesnoth-dev
20120716 10:18:26-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20120716 11:27:13-!- negusnyul [~negusnyul@1F2EBB6E.dsl.pool.telekom.hu] has joined #wesnoth-dev
20120716 11:28:02-!- PolarPanda [~quassel@unaffiliated/peterporty] has quit [Remote host closed the connection]
20120716 11:37:08-!- MeccaGod [majs@host189-199.bornet.net] has joined #wesnoth-dev
20120716 11:41:18-!- mjs-de [~mjs-de@d119146.adsl.hansenet.de] has joined #wesnoth-dev
20120716 11:56:49-!- negusnyul [~negusnyul@1F2EBB6E.dsl.pool.telekom.hu] has quit [Quit: Konversation terminated!]
20120716 11:57:26-!- Gallaecio [~quassel@84.120.114.134.dyn.user.ono.com] has quit [Ping timeout: 246 seconds]
20120716 11:59:39-!- Gallaecio [~quassel@84.120.114.134.dyn.user.ono.com] has joined #wesnoth-dev
20120716 12:05:09-!- stikonas [~quassel@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120716 12:16:39-!- horon [~horon@nttkyo331099.tkyo.nt.ngn2.ppp.infoweb.ne.jp] has joined #wesnoth-dev
20120716 13:02:13-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-dev
20120716 13:43:14-!- Netsplit *.net <-> *.split quits: zookeeper
20120716 13:43:25-!- Netsplit *.net <-> *.split quits: iwaim
20120716 13:44:34-!- Netsplit over, joins: zookeeper, iwaim
20120716 14:04:21-!- ToBeFree [~tobefree@unaffiliated/tobefree] has joined #wesnoth-dev
20120716 14:21:16-!- Crab_ [Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20120716 14:22:00-!- Ayne [~Ayne@cpc2-sgyl34-2-0-cust493.sgyl.cable.virginmedia.com] has joined #wesnoth-dev
20120716 14:22:55< Crab_> hi, Ayne
20120716 14:23:19< Ayne> hi
20120716 14:23:29< Crab_> how it's going? any questions at the moment?
20120716 14:28:04< Ayne> Yes, I do have a question: when loading and saving turn savegames, should the gamedata be saved and loaded directly or should it be saved as part of carryover_info or something else and then transferred?
20120716 14:29:13< Crab_> I think that all in-game data should be part of the snapshot in the save, and should be saved and loaded via game_state's methods.
20120716 14:29:32< Ayne> ok
20120716 14:30:00< Crab_> also see https://gna.org/bugs/index.php?19872 
20120716 14:30:09< Crab_> do you think, can it be related to your changes?
20120716 14:30:50< Crab_> (please let me know if you'll need help with the bug, or if you'll reach the conclusion that it's not related to your changes)
20120716 14:34:11< Crab_> also note that we'll need, in the future, to have more top-level sections in the savegame
20120716 14:34:37< Crab_> for example, if we would want to add 'restart from lower difficulty level' option to the save, we'll need to keep the following in the save:
20120716 14:35:04< Ayne> Hm, could be related to my changes. There was a bug with start of scenario saves not showing recall units that anonymissimus pointed out to me on the 29th June. It only affected singleplayer campaigns and I fixed it the same night and committed the fix before I went on my holidays
20120716 14:35:19< Crab_> ok, that might be the same one.
20120716 14:35:49< Crab_> in that case, verify the bug and if it's no longer present, close it with the message like 'fixed in rREVISION_NUMBER'
20120716 14:36:07< Crab_> in the save, we'll need snapshot (with in-game state and out-of-game carryover info) to load the save.
20120716 14:36:26< Crab_> in the save, we'll need replay_start (with in-game state and carryover info) to load the replay.
20120716 14:36:50< Crab_> in the save, we'll need start-of-scenario (without in-game state, but with carryover info) to restart from other difficulty level
20120716 14:37:08< Crab_> note that those are 3 slightly different carryover infos
20120716 14:37:51< Crab_> and, as you see, gamedata and carryover_info are to be stored separately
20120716 14:38:52< Crab_> and since we don't want to keep 2+ copies of carryover info & unit maps & teams around, we'll store replay_start and start-of-scenario data in serialized config format.
20120716 14:40:48< Crab_> so, game_state would have something like 'config replay_start; config replay_data; config starting_pos; carryover_info carryover_sides; ... '
20120716 14:41:11< Crab_> and replay_start and starting_pos would actually include the old carryover info in serialized form
20120716 14:42:17< Crab_> and, when writing the turn save, we'll need to ask the game_state to write the snapshot for us. that would take the gamedata and carryover_info, and save them together into a snapshot config.
20120716 14:42:54< Crab_> and, game_state might be the object resposible for that write, having a write_snapshot(config &cfg) method
20120716 14:43:18< Crab_> it has this method now, btw.
20120716 14:43:33< Ayne> ok
20120716 14:43:45< Crab_> it now can't cleanly separate two parts of the snapshot (in-game and out-of game)
20120716 14:44:36< Crab_> and if we do separate it, we'll have problems upon loading games (remember that part of your project where we'll need to ensure that old saves work)
20120716 14:45:26< Crab_> but, I think that it's better to change the format of the saves slightly to cleanly separate out-of-game info vs in-game info and just convert old saves upon loading them.
20120716 14:46:15< Crab_> but, it might be quicker to just leave current info as it is
20120716 14:49:35< Crab_> the end result should be something like this : 
20120716 14:50:08< Crab_> mid-turn save = snapshot (in-game info + out-of-game info) +  starting_pos (carryover_info) + replay (replay_start(in-game info + out-of-game info) + replay_data)
20120716 14:50:41< Crab_> and start_of_scenario save = 'starting_pos (carryover_info)'
20120716 14:51:11< Crab_> and replay = replay (replay_start(in-game info + out-of-game info) + replay_data)
20120716 14:51:32< Crab_> note that replay_start is just a snapshot at the start of the replay
20120716 14:51:52< Crab_> the exact location of those pieces in the save might be subject to compatability issues
20120716 14:52:06< Crab_> i.e. we might want to store the pieces in a way which is more-or-less compatible with old saves.
20120716 14:52:27< Crab_> or, we might want to overhaul the savegame format and load old saves via a compatability layer
20120716 14:53:18< Crab_> and since game_state knows about all those pieces, it's a perfect place to place methods which assemble (or help assemble) the saves
20120716 14:53:52< Crab_> Ayne: btw, after doing that, you can finally try to implement some of the useful features
20120716 14:54:29< Crab_> for example, after having proper starting_pos in the game_state, you'll have enough information to implement the 'restart the scenario in easier difficulty level' button.
20120716 14:55:41< Crab_> That's an optional goal but having it done would be super cool.
20120716 14:57:22< Crab_> Ayne: anything that I can help you with?
20120716 15:02:29< Ayne> I just checked and that bug is still there, so I'm looking into that now. Then I will have to add gamedata to the snapshot and make sure that works correctly. Is there an easy/obvious way to keep an eye on and verify in-game data other than log outputs?
20120716 15:04:20< Crab_> A) create a debug method which would write the data to a set of files, call this method from in-game console.
20120716 15:04:41< Crab_> B) extend gamestate_inspector to show you some debug output about the gamestate. then use :inspect from in-game console
20120716 15:05:12< Crab_> note about (B): it might not work with displaying long and large configs due to crashes, but it would perfectly work with some aggregate data.
20120716 15:05:49< Ayne> ok, thanks
20120716 15:06:07< Crab_> for (A), you can create a directory on your hdd and make a function which will write 5-6 files in plain text format there with configs inside. then, run it from in-game console (add a new console command, for example)
20120716 15:06:22< Crab_> it's very easy to add functions to it
20120716 15:06:25< Crab_> and it's easy to run
20120716 15:07:46< Crab_> of course, you can use standard logging, as well. if you redirect the log to file, I guess that some sed/grep trickery can extract the relevant pieces of configs to files. yet, doing from within the game might be faster.
20120716 15:20:07-!- neXyon [~neXyon@84-119-52-87.dynamic.xdsl-line.inode.at] has quit [Quit: bye]
20120716 15:22:33-!- Elvish_Pillager [~eli@71-10-229-241.dhcp.oxfr.ma.charter.com] has quit [Ping timeout: 246 seconds]
20120716 15:37:36-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120716 15:56:04-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20120716 15:57:07-!- Samual_ [diotecktec@c-71-195-88-69.hsd1.pa.comcast.net] has joined #wesnoth-dev
20120716 15:57:07-!- Samual_ [diotecktec@c-71-195-88-69.hsd1.pa.comcast.net] has quit [Changing host]
20120716 15:57:07-!- Samual_ [diotecktec@xonotic/core-team/Samual] has joined #wesnoth-dev
20120716 15:57:43-!- Samual [diotecktec@xonotic/core-team/Samual] has quit [Ping timeout: 255 seconds]
20120716 15:58:07-!- horon [~horon@nttkyo331099.tkyo.nt.ngn2.ppp.infoweb.ne.jp] has quit [Quit: Leaving...]
20120716 16:05:13-!- negusnyul [~negusnyul@1F2EBB6E.dsl.pool.telekom.hu] has joined #wesnoth-dev
20120716 16:05:46-!- negusnyul [~negusnyul@1F2EBB6E.dsl.pool.telekom.hu] has quit [Client Quit]
20120716 16:06:11< lipkab> http://forums.wesnoth.org/viewtopic.php?f=4&t=37217#p533432
20120716 16:06:26< Ayne> Crab_: The cause of the bug is that the save_id is missing from the scenario cfg in Tales of Two Brothers, which is what I use to match the carryover sides.. I don't think there's an elegant way of fixing it from my side, but I can try to find a match using some other information if the save_id is missing
20120716 16:06:35< lipkab> shadowm: I don't think your last answer will make him happy there ^
20120716 16:06:49< shadowm> lipkab: Why?
20120716 16:06:58< lipkab> It seems to me that he simply doesn't know about this linebreak-stuff
20120716 16:07:10< Crab_> Ayne: let's check the documentation first
20120716 16:07:57< lipkab> shadowm: imo, you should just say that some add-ons use different chars for lineends, use an editor which supports them
20120716 16:09:02< Crab_> Ayne: docs at http://wiki.wesnoth.org/SideWML say that persistent=1 by default for sides with human controller yet the behavior without save_id is undefined.
20120716 16:09:20< Crab_> Ayne: I'd say "fix it on the other side, in scenario, not on your side"
20120716 16:09:23< shadowm> lipkab: If that's the case then he should consult the Internet.
20120716 16:09:45< Crab_> Ayne: since you're doing the right thing in matching carryover sides by save id
20120716 16:09:46< shadowm> You know, that cloudy thing that seems to be all around us nowadays. I'm fairly certain it has answers.
20120716 16:10:33-!- mattsc [~mattsc@fw.hia.nrc.ca] has joined #wesnoth-dev
20120716 16:10:40< shadowm> And more generally, if someone posts in TS, I assume they can understand what I'm posting somehow.
20120716 16:10:49< Ayne> Cra 
20120716 16:10:53< shadowm> If they don't, then that's frequently a sign that the post is misplaced.
20120716 16:11:23< Crab_> Ayne: but, a good thing would be to check the other campaigns/scenarios in mainline to see if they have the same error somewhere (no side_id for player's side)
20120716 16:11:46< Ayne> Crab_: should I fix it myself since I know what the problem is or add it to the bug report/add a new bug report?
20120716 16:11:58< Ayne> Crab_: yes, I was going to do that
20120716 16:12:02< Crab_> fixing it by yourself is easiest, probably
20120716 16:12:39< Crab_> unless you're feeling lazy. in that case add info to bug report and find the victim to do it. yet, adding save_id seems easy enough, even if you're unfamiliar with the WML of those campaigns
20120716 16:12:51< shadowm> Crab_: Hm, that should be yes, not 1. IIRC 1 no longer acts like a boolean true value since 1.9.0 or so.
20120716 16:13:17< Crab_> shadowm: yes, I meant "yes" :))
20120716 16:13:34< lipkab> shadowm: That's all nice and true, but the problem could be dealt with much faster if you just told him to use Notepad++ (and you could still place some educational notes on "consulting the Internet")...
20120716 16:13:52< Crab_> Ayne: but, if there's any campaign where you're not sure what the authors wanted to do with the recall lists, just ping the campaign maintainers or leave a bug for them.
20120716 16:14:03< lipkab> ...by the way, I could do that just as well... hmmm.
20120716 16:14:11< shadowm> lipkab: By all means, go ahead.
20120716 16:14:41< shadowm> But I assumed that since he was using Windows, he was already using a third-party text editor.
20120716 16:15:48 * shadowm just corrected the persistent attribute description to use yes/no instead of 1/0.
20120716 16:17:41< Crab_> Ayne: note that you might need to change quite a few of campaigns that way. yet, the fact that it worked before was a bug or a hack :)
20120716 16:17:58-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Quit: This computer has gone to sleep]
20120716 16:18:55< shadowm> Crab_: Incidentally, I thought save_id defaulted to the first matched canrecruit=yes unit's id when not specified.
20120716 16:19:48< Crab_> shadowm: probably it has, but it's not documented anywhere.
20120716 16:19:54< shadowm> That wiki page says it defaults to 'description'.
20120716 16:20:19< shadowm> Since there isn't a side.description there, I think it means the original side.description, which became side.id and was always the leader unit id.
20120716 16:20:39< Crab_> shadowm: so, it was just not updated there?
20120716 16:21:07< shadowm> Perhaps. I'd need to track down when that line was added and see if it was before the name -> id renaming or not.
20120716 16:21:23< Crab_> Ayne: then wait with the fix of scenarios for a while
20120716 16:22:02< shadowm> Before: http://wiki.wesnoth.org/index.php?title=SideWML&oldid=11097
20120716 16:22:04< Crab_> if the intent was to make it default to side.id (if it present, with leader-defined-in-side),  then it can be easily fixed at load time
20120716 16:22:10< Ayne> id does seem to be what was used before when save_id was missing, yes
20120716 16:22:20< shadowm> *description -> id
20120716 16:22:56< Ayne> and what I would have used instead of save_id if save_id is empty
20120716 16:22:58< Crab_> Ayne: so, you just need to populate the save_id from [side] id=FOO [/side], if it's set.
20120716 16:23:47< Crab_> and since you need to match save_id vs in-scenario-side-definitions, you will have side.id available at that time.
20120716 16:26:45< mattsc> Hi, Crab_.  Brief question: is there are (guaranteed) order in which CA's are evaluated?
20120716 16:27:30< shadowm> lipkab: Mac OS X currently prefers the Unix format, by the way.
20120716 16:28:10< lipkab> Really? I bet that when I first stumbled upon this issue it wasn't so.
20120716 16:28:50< shadowm> I don't know first-hand, but it's what [DI've been told.
20120716 16:29:19< Crab_> mattsc: hi. no, there's no guaranteed order.
20120716 16:29:33< Crab_> mattsc: implementation uses 'sort by max score descending'
20120716 16:30:03< lipkab> shadowm: Perhaps I read something so ancient that it mentioned pre-OSX Macs.
20120716 16:30:26< Crab_> mattsc: in practice, you can depend on that not changing for a year or two :0
20120716 16:31:17< mattsc> Crab_: thanks, that's what I thought.  It probably wouldn't be good to make the score of one CA depend on the outcome of another CA's evaluation anyway.
20120716 16:31:31< mattsc> You change something and suddenly it doesn't work any more.
20120716 16:32:03< Crab_> mattsc: you can do it if you do in differently..
20120716 16:32:26< lipkab> Crab_: I noticed that the header guard's name in Akihara's stuff isn't derived from the file's path. Shouldn't that be so?
20120716 16:32:45< Crab_> lipkab: no, that's a violation of coding conventions :)
20120716 16:34:02< Crab_> mattsc: actually, it's hard to do in a way that I was thinking :)) so, if you explain your usecase to me, I'll think about it again
20120716 16:34:31< Akihara> lipkab: oh! what must i change?
20120716 16:35:42< mattsc> In my grunt rush AI, I want recruitment to be the last thing to be done so that it can be adjusted based on units that have died during the turn.  However, sometimes I want to move the leader out for an attack early on during the turn.
20120716 16:36:20< mattsc> In that case, recruitment needs to be done earlier, so it's score should be higher if the move_leader_out CA finds that it is about to do that.
20120716 16:37:07< lipkab> Akihara: AKIHARA_AI_HPP_INCLUDED should be AI_AKIHARA_RECRUITMENT_HPP_INCLUDED.
20120716 16:37:25< lipkab> Since the hpp's path is ai/akihara/recruitment.hpp
20120716 16:37:30< Akihara> lipkab: okay :) didn't know. I will change it :) thanks
20120716 16:43:25< Crab_> mattsc: (thinking...)
20120716 16:44:03< mattsc> Crab_: I've come up with two possible ways to do that, but am not sure yet which one is better, or if I like them
20120716 16:44:38< mattsc> 1. The leader_attack exec could call the recruiting exec first if it is about to move the leader.
20120716 16:45:44-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20120716 16:46:02< mattsc> 2. both leader_attack and recruiting could call the same evaluation function that returns scores for both CA's, with some flag set that says whether the other CA has already called this eval function (so that it doesn't get done twice, because it's pretty expensive)
20120716 16:46:45< mattsc> Not quite sure how to make sure the flag gets set on each move (rather than just beginning of turn), but I can probably figure that out.
20120716 16:47:40< mattsc> Crab_: either way, this whole thing (the grunt rush) is getting pretty complicated...  :P
20120716 16:47:45< Crab_> :)
20120716 16:48:47< mattsc> In addition to the above issues, I potentially have to move units off the keep first for any of this to happen...
20120716 16:51:07< mattsc> Crab_: btw, somebody else is already using the external CA mechanism (maybe you saw that)
20120716 16:51:46< Crab_> no, haven't seen yet. but I expect more people to start using them
20120716 16:52:24< mattsc> http://forums.wesnoth.org/viewtopic.php?f=10&t=36642&start=30#p533354
20120716 16:53:00< mattsc> And there was even a wiki page to point him to.  Documentation is good!
20120716 16:53:18< Crab_> yes, that's great
20120716 16:55:29< Crab_> mattsc: I've got some code (theoretical :) )
20120716 16:55:42< Crab_> please check this : http://pastebin.com/ggmmDEBQ
20120716 16:56:47< Crab_> the idea is to set some kind of flag after CA executes, not after CA evaluates
20120716 16:57:01< Crab_> since we actually have guarantees on the order of the execution of CAs :)
20120716 16:57:16< Crab_> as the highest-scoring CA is executed
20120716 16:58:22< Crab_> as you can store variables inside ai, the only problematic spot here is the CA3, where you somehow need to tell the AI to recruit (run one of the CAs). for that we might need a new API.
20120716 16:59:00< mattsc> So setting a variable inside the AI table counts as a gamestate change?
20120716 16:59:31< Crab_> no, but for that purpose, it doesn't matter - you can afford to be blacklisted here
20120716 17:00:02< Crab_> yet, there's a concept of 'minor gamestate change' in the ai
20120716 17:00:22< mattsc> In CA 1?  doesn't that depend on not getting blacklisted?
20120716 17:00:41< Crab_> not if you have 1 leader
20120716 17:01:09< mattsc> Oh, I see.  Well, here's another complication: moving the leader is not necessarily the first thing to happen.  :D
20120716 17:01:22< mattsc> Early on, yes, but not always the first.
20120716 17:01:25< Crab_> why it's a complication?
20120716 17:01:39< Crab_> the CA1 test is      IF "it is time to attack with leader and (ai.get_ai_variable(attack_with_leader) != true)"
20120716 17:02:11< Crab_> It can be not the first thing, right. if you give it a proper max_score it won't ever be evaluated until those 'first things' happen
20120716 17:02:26< mattsc> ok, maybe I don't understand what you mean...  Let me think for a moment.
20120716 17:03:09< mattsc> Ah, well, but then I depend on the order in which things get evaluated again.
20120716 17:03:22< Crab_> how do you depend on it?
20120716 17:03:24< mattsc> right?
20120716 17:03:43< Crab_> no, if things are evaluated in 'bad order' you'll only get a couple of extra evaluations of your expensive condition
20120716 17:03:43-!- neXyon [~neXyon@84-119-52-87.dynamic.xdsl-line.inode.at] has joined #wesnoth-dev
20120716 17:03:53< Crab_> but, the variable is set in execution
20120716 17:05:05< Crab_> also note that if you want to truly minimize the number of executions of that expensive condition, you can add another value to mean 'we don't want to attack with leader this turn'
20120716 17:06:21< mattsc> Crab_: I really don't seem to get it...  The way I read your pseudo code, CA's 2-4 depend on CA 1 to be evaluated first.  Otherwise they don't know if attack_with_leader is set.
20120716 17:06:29-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has quit [Read error: Connection reset by peer]
20120716 17:06:41-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20120716 17:07:35< Crab_> mattsc: what will happen if CA2,3,4 are evaluated before CA1?
20120716 17:08:09< Crab_> if conditions for leader's attack are not met, nothing would happen
20120716 17:08:18< Crab_> if conditions for leader's attack are met, CA1 would be selected for execution with highest score
20120716 17:08:25< mattsc> some other CA would be executed.
20120716 17:08:41< mattsc> oh ...
20120716 17:08:58< Crab_> well, if CA1 has a really high score, no other CA would interfere if CA1 would want to run
20120716 17:09:09< mattsc> right ...
20120716 17:09:22< Crab_> with current C++ code, it would be blacklisted (as we have no api to set minor gamestate change flag)
20120716 17:09:31< Crab_> but it'll be blacklisted after the fact
20120716 17:09:43< Crab_> so, the variable would be set
20120716 17:11:32< Crab_> for extra cleanness, we definitely need the concept of 'per-ca-evaluation-loop' and 'per-turn' variables. but, there's a number of hacks that can be used to set the variable to proper initial value.
20120716 17:12:21< Crab_> the easiest way is to A) use some global variable and clear it's state from WML. or B) just store the turn number in the variable instead of true/false - then, ignore values from previous turns
20120716 17:13:06< mattsc> Crab_: ok, I get it now - apparently I need some more coffee...  :)   But I still think it might be a problem if the attack by leader is not necessarily the first thing that happens, unless you work very carefully withmax_score
20120716 17:14:06< Crab_> max_score should not affect execution at all
20120716 17:14:14< Crab_> max_score only allows to skip some evaluations
20120716 17:15:24< Crab_> but if you meant 'maximum score', then yes, you're right
20120716 17:15:55< Crab_> if CAs which are bound to 'ATTACK_WITH_LEADER' variable (CA2 CA3 CA4) have higher score than any else non-bound CA, then they'll run in proper order after the hint is set.
20120716 17:17:02< Crab_> yet, in this case, you actually want to run a mini-ca-loop
20120716 17:19:19< mattsc> Crab_: yes, I think this will work.  My hesitation so far was because of something else I am doing with the leader_attacks CA, but I think I can solve that by simply separating those thing out into separate CAs, without additional penalty.
20120716 17:20:19< Crab_> i.e. a similar logic can be written (not with current C++, but) as something like      http://pastebin.com/B84ffJ3R
20120716 17:21:41< mattsc> And the decision whether it's time do attack with leader is done in CA 1.
20120716 17:21:53< Crab_> no, it can be there, as well
20120716 17:22:10< Crab_> it's not easy to express what you want in candidate actions, because candidate actions are 'if the situation looks like THIS, do THAT'
20120716 17:22:17< Crab_> but you, here, actually want something different
20120716 17:22:50< mattsc> Exactly...
20120716 17:22:52< Crab_> you want 'if I want to move the leader away from keep, then I want to recruit, then I want to remove units from keep so I can recruit'
20120716 17:23:17< Crab_> it's actually 'if the intent looks like that, do this'
20120716 17:24:08< mattsc> Right.  And if this were always the first thing to happen, I could give it its own stage.  But it isn't.
20120716 17:24:38< mattsc> So I need a stage inside a stage, in a way.  I think your code will work for that.
20120716 17:24:55< Crab_> well, my code (2nd example) is slightly cheating. 
20120716 17:25:02< Crab_> first one is better (but probably slower)
20120716 17:26:42-!- stikonas [~quassel@wesnoth/translator/stikonas] has quit [Ping timeout: 276 seconds]
20120716 17:26:42-!- stikonas_ [~quassel@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120716 17:26:54-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20120716 17:26:55< mattsc> Your second example is essentially what I meant with my first potential solution way up there ^.  But that can very quickly get very messy.  (Since this isn't the only case where I want to do something like this)
20120716 17:27:10< Crab_> I think that we need an elegant way to solve this 
20120716 17:27:22< mattsc> So, yes, I like your first solution.
20120716 17:27:42< mattsc> That would be cool.  Next year's GSoC?
20120716 17:27:52< Crab_> no, it's very easy to fix
20120716 17:28:04< mattsc> oh ok.
20120716 17:28:34< mattsc> Btw, I'm sorry that every time I ask you a "quick question", it turns into a major discussion.  :D
20120716 17:28:54< mattsc> Especially when it's being cause by me being too dense to understand you...
20120716 17:29:54< Crab_> it means that you ask good questions :)
20120716 17:30:48< mattsc> Well, I don't know.  Sometimes I feel like I barely keep up with my own code any more.  :P
20120716 17:31:33< Crab_> :)
20120716 17:31:40< Crab_> I'll have an example in a few minutes
20120716 17:31:46< mattsc> But at least for the grunt rush on Freelands, I'm at the point where the RCA AI doesn't stand a chance any more, so that's pretty cool.  Of course, all those multiplayers still kill it mercilessly.
20120716 17:32:17< mattsc> Ok, cool.  I'll put some more caffeine into my system.
20120716 17:35:17-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has quit [Quit: And away we go]
20120716 17:43:20-!- Heyub [189eecb1@gateway/web/freenode/ip.24.158.236.177] has joined #wesnoth-dev
20120716 17:53:18< Crab_> mattsc: take a look at safer but not-optimized version at http://pastebin.com/m1M90x4b
20120716 17:55:04< Crab_> mattsc: and a slightly more unsafe version - http://pastebin.com/R1uxYSU6
20120716 17:55:21< Crab_> the problem here is that recruiting can actually break the conditions for your attacks CA
20120716 17:55:54< Crab_> i.e. if you recruit on a castle hex that you wanted to use to attack, or move away units with illuminate which affected your planned attack, etc
20120716 17:56:16< Crab_> so, not checking the possibility of attacking with leader after recruiting is unsafe
20120716 17:57:24< Crab_> note that the safe version is still faster than trivial version
20120716 17:57:49< mattsc> Crab_: Thanks much, that makes sense.  But a couple more questions:
20120716 17:58:20< Crab_> and it's correctness depends on the fact that regardless of the evaluation order, CA1 would run if flag is not set.
20120716 17:58:43< mattsc> How does this: 'AI.ADD_TEMPORARY_VARIABLE_FOR_NEXT_RUN(MOVE_LEADER_OUT_OF_KEEP)' avoid blacklisting?
20120716 18:00:45< Crab_> it's a supposed new function that would signal the RCA loop that it should not blacklist this function (up to 100 times, if called in a row), and that it should repeat the RCA loop with a flag set
20120716 18:01:01< Crab_> and, actually, it's possible to slightly optimize the code here
20120716 18:01:17< mattsc> oh, ok.  So it is not something I have available yet?
20120716 18:03:16< Crab_> no, but for this specific use case, you can emulate it (just use 2 different CAs and let the first blacklist itself :) ) - like I've did in the first example 
20120716 18:03:26-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20120716 18:03:37< Crab_> mattsc the slightly more optimized version is at - http://pastebin.com/pFAuxh0C
20120716 18:03:48< mattsc> Crab_: yes, ok, that's fine.  I was just wandering what I was missing this time.
20120716 18:04:17< Crab_> if recruiting is not possible, then your expensive "it is time to attack with leader" would be only evaluated twice (once if we add a way to force blacklisting)
20120716 18:05:11< Crab_> but note that there's a second speed problem here
20120716 18:05:44< Crab_> if "it is time to attack with leader" would evaluate to false at the end of the evaluation (so, without failing early), it'll be slow (since it'll run each time) 
20120716 18:06:50< mattsc> yeah, that is already true for the code even without this mini loop.
20120716 18:07:10< mattsc> and that's actually the reason why I have it combined with some other actions.
20120716 18:07:25< Crab_> yes, makes sense.
20120716 18:07:37< Crab_> but, using approach like (1) you can make it slightly faster.
20120716 18:08:07< mattsc> True.  To be honest, speed is not really my concern at the moment.
20120716 18:08:17< Crab_> then just go with simplest thing that would work :)
20120716 18:09:16< mattsc> Or any kind of optimization, in fact.  I am just trying to figure out the behavior.  And I am reverting about 75% percent of what I am writing anyway, so putting time into non-trivial optimization is just a waste.  :)
20120716 18:09:43< Crab_> :))
20120716 18:09:53< mattsc> (I'm reverting it not because it doesn't work, but because it doesn't actually make the AI any better)
20120716 18:10:04< mattsc> yes  :D
20120716 18:10:17< Crab_> I'll look if it'll be easy to add that .add_temporary_variable_for_next_run() in some form
20120716 18:10:29< mattsc> Plus, those MPers are used to waiting a long time for the opponent anyway, so a half-second delay is not a big deal.
20120716 18:10:31< Crab_> if you're interested.
20120716 18:10:54< Crab_> it can be used to do 'now rerun the loop knowing X'
20120716 18:11:10< Crab_> i.e. 'now rerun the loop knowing I want to recruit'
20120716 18:11:24< Crab_> or 'now rerun the loop knowing that I want to move leader out of keep'
20120716 18:11:28< mattsc> Crab_: in general, yes.  However, everything I am doing right now needs to work with the 1.10 capabilities, so I would not use it for this anyway.
20120716 18:12:16< mattsc> Once 1.11 comes out and people start using it, there'll be a long rat's tail of changes to make.
20120716 18:13:17< mattsc> But right now a lot of the problems are still more difficult conceptually than from the coding perspective, so we're  good.
20120716 18:13:38< Crab_> ok
20120716 18:14:43< mattsc> Thanks much for your help.  I hope you're having some fun with, or at least interest in, this as well, or I'd feel bad for wasting so much of your time.  :)
20120716 18:15:27-!- ejls [~Epsilon01@mszy.domu.7un.net] has joined #wesnoth-dev
20120716 18:16:30< Crab_> yes, it's fun and it helps to find proper interesting stuff to do for neph :))
20120716 18:18:10< mattsc> Glad to be of service.  :P  I'm off now, real life can only be ignored so long...
20120716 18:21:25-!- mattsc [~mattsc@fw.hia.nrc.ca] has quit [Quit: bye]
20120716 18:28:32< CIA-87> ayne * r54757 /trunk/src/ (gamestatus.cpp play_controller.cpp): Fixes savegame incompatibility with campaigns that don't use save_id
20120716 18:43:55-!- trademark_ [~trademark@mon69-1-82-67-23-185.fbx.proxad.net] has joined #wesnoth-dev
20120716 18:51:18-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20120716 18:54:05< Crab_> Ayne: note that if your change fixes a known bug, you can reference its number in the commit message and it'll be automatically mentioned on the bug page
20120716 18:54:32< Ayne> oh, ok, I didn't know that. Will remember it for the future
20120716 18:54:51< Crab_> it looks for strings like "bug 33321"
20120716 18:55:03< shadowm> The format is "bug #12345" or "patch #12345"; the pound sign is required.
20120716 18:55:44< Crab_> shadowm: thanks :) being sleepy :))
20120716 19:16:46< AI0867> mordante: nope, but I told noy that I hadn't replied, so I suppose he has
20120716 19:36:10-!- mjs-de [~mjs-de@d119146.adsl.hansenet.de] has quit [Remote host closed the connection]
20120716 19:40:22< timotei> .
20120716 19:48:32-!- stikonas [~quassel@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120716 19:49:03-!- stikonas_ [~quassel@wesnoth/translator/stikonas] has quit [Ping timeout: 276 seconds]
20120716 19:49:46-!- negusnyul [~negusnyul@1F2EBB6E.dsl.pool.telekom.hu] has joined #wesnoth-dev
20120716 19:49:51-!- wesbot changed the topic of #wesnoth-dev to: 181 bugs, 337 feature requests, 17 patches | Logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20120716 19:55:50-!- Ayne [~Ayne@cpc2-sgyl34-2-0-cust493.sgyl.cable.virginmedia.com] has quit [Quit: Leaving]
20120716 20:05:14-!- mjs-de [~mjs-de@wh.uni-dortmund.de] has joined #wesnoth-dev
20120716 20:08:58-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev
20120716 20:10:32-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20120716 20:10:47< mordante> servus
20120716 20:11:09< lipkab> hi mordante
20120716 20:11:23< mordante> hi lipkab 
20120716 20:14:12< mordante> AI0867, no noy also hasn't replied :-(
20120716 20:30:25-!- Heyub [189eecb1@gateway/web/freenode/ip.24.158.236.177] has quit [Ping timeout: 245 seconds]
20120716 20:49:14-!- mjs-de [~mjs-de@wh.uni-dortmund.de] has quit [Ping timeout: 244 seconds]
20120716 21:05:22-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has joined #wesnoth-dev
20120716 21:17:08< mordante> I'm off night
20120716 21:17:55-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20120716 21:18:38-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has quit [Ping timeout: 252 seconds]
20120716 21:28:54-!- trademark_ [~trademark@mon69-1-82-67-23-185.fbx.proxad.net] has quit [Ping timeout: 252 seconds]
20120716 21:30:43-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has joined #wesnoth-dev
20120716 21:32:26-!- trademark [~trademark@mon69-1-82-67-23-185.fbx.proxad.net] has joined #wesnoth-dev
20120716 21:34:29< CIA-87> ivanovic * r54758 /trunk/ (16 files in 15 dirs): updated Lithuanian translation
20120716 21:38:09-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has quit [Quit: And away we go]
20120716 21:38:37< CIA-87> ivanovic * r54759 /branches/1.10/ (16 files in 15 dirs): updated Lithuanian translation
20120716 21:38:43-!- Crab_ [Crab_@wesnoth/developer/crab] has quit [Ping timeout: 240 seconds]
20120716 21:40:07-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Quit: SIGKILL]
20120716 21:40:08-!- negusnyul_ [~negusnyul@1F2EBB6E.dsl.pool.telekom.hu] has joined #wesnoth-dev
20120716 21:40:08-!- negusnyul [~negusnyul@1F2EBB6E.dsl.pool.telekom.hu] has quit [Read error: Connection reset by peer]
20120716 21:53:11-!- grzywacz [~grzywacz@89-67-177-27.dynamic.chello.pl] has joined #wesnoth-dev
20120716 21:53:11-!- grzywacz [~grzywacz@89-67-177-27.dynamic.chello.pl] has quit [Changing host]
20120716 21:53:11-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20120716 22:22:54-!- Heyub [189eecb1@gateway/web/freenode/ip.24.158.236.177] has joined #wesnoth-dev
20120716 22:30:56-!- happygrue [~quassel@wesnoth/developer/wintermute] has quit [Read error: Connection reset by peer]
20120716 22:32:43-!- happygrue [~quassel@c-98-222-183-113.hsd1.il.comcast.net] has joined #wesnoth-dev
20120716 22:32:43-!- happygrue [~quassel@c-98-222-183-113.hsd1.il.comcast.net] has quit [Changing host]
20120716 22:32:43-!- happygrue [~quassel@wesnoth/developer/wintermute] has joined #wesnoth-dev
20120716 22:32:52-!- anonymissimus [~chatzilla@HSI-KBW-078-042-163-105.hsi3.kabel-badenwuerttemberg.de] has joined #wesnoth-dev
20120716 22:34:26-!- oldtopman [~oldtopman@unaffiliated/oldtopman] has joined #wesnoth-dev
20120716 22:48:05-!- trademark [~trademark@mon69-1-82-67-23-185.fbx.proxad.net] has quit [Ping timeout: 246 seconds]
20120716 22:53:42-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has quit [Remote host closed the connection]
20120716 23:25:08-!- Gallaecio [~quassel@84.120.114.134.dyn.user.ono.com] has quit [Remote host closed the connection]
20120716 23:25:49-!- anonymissimus [~chatzilla@HSI-KBW-078-042-163-105.hsi3.kabel-badenwuerttemberg.de] has quit [Quit: ChatZilla 0.9.88.2 [Firefox 11.0/20120312181643]]
20120716 23:27:46-!- Gambit [~gambit@wesnoth/developer/grickit] has joined #wesnoth-dev
20120716 23:38:57-!- Crab_ [Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20120716 23:45:29-!- Elvish_Pillager [~eli@71-10-229-241.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20120716 23:53:22-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
--- Log closed Tue Jul 17 00:00:39 2012