--- Log opened Thu Nov 28 00:00:25 2013
20131128 00:13:36-!- mattsc [~mattsc@fw.hia.nrc.ca] has quit [Quit: Computer's napping]
20131128 00:46:48-!- mattsc [~mattsc@154.20.32.246] has joined #wesnoth-umc-dev
20131128 00:57:55-!- irker469 [~irker@ai0867.net] has joined #wesnoth-umc-dev
20131128 00:57:55< irker469> wesnoth-umc-dev: doofus-01 * r19382 /trunk/Trinity/scenarios/ZZ_Dark_Planet.cfg: 
20131128 00:57:55< irker469> wesnoth-umc-dev: fixed (I think) village and item image handling between map-swaps
20131128 01:13:48-!- Alarantalara [~Adium@192-0-128-11.cpe.teksavvy.com] has joined #wesnoth-umc-dev
20131128 01:14:55-!- Alarantalara1 [~Adium@192-0-128-11.cpe.teksavvy.com] has joined #wesnoth-umc-dev
20131128 01:14:56-!- Alarantalara [~Adium@192-0-128-11.cpe.teksavvy.com] has quit [Read error: Connection reset by peer]
20131128 01:25:46-!- mattsc [~mattsc@154.20.32.246] has quit [Quit: Computer's napping]
20131128 01:47:44-!- mattsc [~mattsc@154.20.32.246] has joined #wesnoth-umc-dev
20131128 02:11:24-!- Crendgrim [~crend@37-4-131-59-dynip.superkabel.de] has quit [Quit: No Ping reply in 180 seconds.]
20131128 02:11:40-!- Crendgrim [~crend@37-4-131-59-dynip.superkabel.de] has joined #wesnoth-umc-dev
20131128 02:26:13-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 248 seconds]
20131128 02:47:58< mattsc> Alarantalara1: hi
20131128 02:48:35< mattsc> I didn't have much time to clean up the custom cost function code today, but here's what I have so far: http://pastebin.com/bQhdyXdR
20131128 02:50:26< mattsc> So this applies a penalty to specific hexes, but only if the unit's move would end on that hex, not if the unit only passes through (currently hard-coded to no_path_value, meaning hexes marked with it are avoided entirely)
20131128 02:50:54< mattsc> Anyways, I'll be on and off (mostly off) throughout the evening, just thought I show you in case you have comments.
20131128 02:54:22-!- shadowm_desktop [~ignacio@186.11.1.128] has joined #wesnoth-umc-dev
20131128 02:54:46-!- shadowm_desktop is now known as Guest28983
20131128 03:15:41-!- Alarantalara1 [~Adium@192-0-128-11.cpe.teksavvy.com] has quit [Quit: Leaving.]
20131128 03:16:10-!- Alarantalara [~Adium@192-0-128-11.cpe.teksavvy.com] has joined #wesnoth-umc-dev
20131128 03:16:40< Alarantalara> Sorry, I was not actually the one using the computer
20131128 03:22:23< mattsc> No worries.  I am mostly doing household chores anyway, just stopping by from time to time to see if anything has happened.  I can't stay around right this moment either.
20131128 03:32:02-!- Guest28983 is now known as shadowm_desktop
20131128 03:32:05-!- shadowm_desktop [~ignacio@186.11.1.128] has quit [Changing host]
20131128 03:32:05-!- shadowm_desktop [~ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-umc-dev
20131128 03:33:34< Alarantalara> I'm not exactly sure what you have there. It looks like you penalize moving to locations that use up exactly the remaining movement or have already gone near an avoided location
20131128 03:36:39< mattsc> That's pretty much it.
20131128 03:37:47< mattsc> I want to apply a penalty (for example an "infinite" penalty for avoided hexes, or a finite penalty for hexes that are threatened), but only if the unit would stop on that hex at the end of a move.
20131128 03:38:01< mattsc> If it would just move through, there's no reason to penalize the hex.
20131128 03:39:19< mattsc> The problem with that is that the "did I move up all my MP" condition is sometimes checked when evaluating the next hex, and there is no record of where the unit came from.
20131128 03:39:35< mattsc> s/move up/use up
20131128 03:39:55< Alarantalara> The way A* works, this actually isn't too hard (you just have to track some of the same information A* does
20131128 03:40:26< mattsc> Sure, that's what I am doing ther
20131128 03:40:28< mattsc> e
20131128 03:41:00< mattsc> My main question is whether there's an easier (or more cost effective) way of doing this.
20131128 03:42:19< mattsc> And I don't want to rewrite the A* search, but use the already existing cost function functionality in wesnoth.find_path
20131128 03:42:59< Alarantalara> As you may have noticed, the cost function shouldn't be called more than once per hex
20131128 03:43:13< irker469> wesnoth-umc-dev: doofus-01 * r19383 /trunk/Trinity/scenarios/ (6 files): 
20131128 03:43:14< irker469> wesnoth-umc-dev: breaking last scenario down into smaller files
20131128 03:44:18< mattsc> Well, the A* revisits hexes as the result can be different depending on what the previous hex was, but beside that, I am not calling it more than once.
20131128 03:44:28< Alarantalara> or is that hex pair?
20131128 03:44:44< mattsc> yes, that is probably true.
20131128 03:45:33< mattsc> If you uncomment lines 51-53 in the pastebin, it actually does a graphical representation of how the A* works.  It's pretty cool to watch.
20131128 03:46:38< Alarantalara> As far as I can tell, by the time you're done, you'll effectively have duplicated the data used by A* search in Lua, such that all the C++ code does is decide which hex to examine next
20131128 03:47:53< Alarantalara> Since you'll be storing the costs to move to all hexes examined to see if you would be moving back to that hex
20131128 03:48:23< mattsc> Well, yes, but that's what a custom cost function does.  It replaces the existing cost function.
20131128 03:48:50< Alarantalara> and then checking the adjacent hexes you would not be reversing to move to to see if they would make you stop
20131128 03:49:30< Alarantalara> but, and this is the bad part, you might stop on a hex going one way but not another, so how do you penalize that?
20131128 03:49:55< mattsc> sorry, I don't understand that
20131128 03:50:20< Alarantalara> You are on the edge between hills and grass
20131128 03:50:27< Alarantalara> you have one move point left
20131128 03:50:28< mattsc> The Wesnoth A* only goes in one direction.
20131128 03:50:45< Alarantalara> if you move onto hills, you have to stop where you are
20131128 03:50:54< Alarantalara> if you move onto grass you get one more move
20131128 03:51:09< Alarantalara> you don't yet know if the shortest route goes around or through the hills
20131128 03:51:42< mattsc> I don't need to.
20131128 03:51:56< mattsc> I only need to know how much it takes to enter the hex I am currently entering.
20131128 03:52:21< Alarantalara> cost to enter is 1, you will have 1 movement left after entering
20131128 03:52:25< mattsc> And in addition to that, I need to evaluate whether that gets me over the limit for the previous move.
20131128 03:52:46< Alarantalara> cost to enter next hex is 2 on hills, so you would have to stop here
20131128 03:52:58< mattsc> exactly.
20131128 03:53:10< Alarantalara> unless you go around the hill and it costs only one
20131128 03:53:14< mattsc> that's what l.34ff does
20131128 03:53:39< mattsc> but that's in a different sub path of the A*
20131128 03:54:00< mattsc> Maybe I should tell you what I am actually doing here?
20131128 03:54:22< Alarantalara> What this means is that the cost of the hex changes depending on which way you go, which violates A*
20131128 03:54:53< mattsc> But that's what the Wesnoth A* does...  (the C++ code, not mine)
20131128 03:55:14< mattsc> May I suggest something?
20131128 03:55:30< Alarantalara> it doesn't, because it adds the cost to the hill hex which would be entered the next turn
20131128 03:55:52< mattsc> okay, yes.
20131128 03:56:17< mattsc> I guess I am too stupid to understand what the problem is then.  :)
20131128 03:57:07< Alarantalara> Let me draw a picture to help me explain first
20131128 03:57:30< mattsc> As far as I can tell, I am using exactly the same algorithm as the C++ code, just that I have added a penalty to it.
20131128 03:58:58< mattsc> Oh, you mean that if I end the turn on the hex, I add the penalty, while if I take a different path there, I don't?
20131128 03:59:08< mattsc> And that changes the rating of the hex?
20131128 03:59:28< Alarantalara> So far, yes, but it doesn't look like it will do what you want
20131128 04:00:04< mattsc> I have tested it for a bunch of different cases and for everything I have thought up so for, it does.
20131128 04:02:21< mattsc> There's one special case involving the final hex that is not covered yet, but (I think) that's pretty easy to take care of.
20131128 04:03:57< Alarantalara> I have this suspicion that you might end up with no route results in some cases where stopping a hex earlier and not following a path the entire way would give better results
20131128 04:05:11< Alarantalara> It depends on how big the avoid set gets
20131128 04:05:19< mattsc> Umm, yes, that might be true, but the current algorithm does that too.
20131128 04:06:02< Alarantalara> What do you mean by current algorithm?
20131128 04:06:21< mattsc> The C++ code.  Check out SotBE S16 from before I messed with it (1.11.6 or so) and watch what the units are doing.
20131128 04:06:26< mattsc> The units on the left.
20131128 04:07:12< mattsc> There's an avoided zone in the center (for the first 4 or 5 turns) that is supposed to split the units up going north and south around it, and instead they just sit there.
20131128 04:08:06< mattsc> Btw, don't get me wrong, I _really_ don't want to duplicate what the C++ code already does.  But I can't change the C++ myself, and nobody who could seems to be available.
20131128 04:08:19< mattsc> So I am looking for some ways to make it work for the time being.
20131128 04:09:59< Alarantalara> For something like that, wouldn't just making all avoid locations have the extreme cost be sufficient?
20131128 04:10:35< mattsc> No, the I cannot move across them.
20131128 04:10:41< mattsc> s/the/then
20131128 04:11:15< Alarantalara> and you want to allow cutting across the edge?
20131128 04:11:32< mattsc> yes - the current method works like that too
20131128 04:11:35< mattsc> I have tried.
20131128 04:12:08< mattsc> As in, you set an [avoid] tag for the AI, and it will happily move through that area, as long as it doesn't stop in it.
20131128 04:12:31< mattsc> The other method (entirely avoiding that area) has been in the Goto MAI for quite some time now.
20131128 04:13:07< mattsc> It's the "apply penalty only to the end of move" bit that's the problem.
20131128 04:13:23< Alarantalara> why does the AI not move with the current arrangement?
20131128 04:13:34< mattsc> Sorry?
20131128 04:13:50< mattsc> Oh, in that scenario?
20131128 04:14:03< Alarantalara> with the old value, what is happening? Do all possible good routes end up in the avoid area so it doesn't move?
20131128 04:14:12< mattsc> Yes.
20131128 04:14:49< mattsc> I have tried avoiding that by giving the avoid area a triangular shape and all other kinds of tricks, and it just doesn't work very well.
20131128 04:15:02< mattsc> So in 1.11.7 I just removed the avoided area altogether.
20131128 04:15:36< mattsc> https://github.com/wesnoth/wesnoth-old/commit/fa1fd7484548ebc8e22e52a26a78b491c322b0c1
20131128 04:15:48< Alarantalara> For something like that, what you have will probably work fine. I was thinking you were trying to create an area defined by enemy movement to avoid
20131128 04:16:13< Alarantalara> so that you might want to move up to the edge of the enemy reach or otherwise go around it
20131128 04:16:17< mattsc> I am interested in that as well, yes
20131128 04:16:26< irker469> wesnoth-umc-dev: doofus-01 * r19384 /trunk/Trinity/scenarios/ (5 files): 
20131128 04:16:27< irker469> wesnoth-umc-dev: now those last scenario pieces work together
20131128 04:16:39< Alarantalara> which is where I suspect the suddenly frozen units might start appearing
20131128 04:16:58< mattsc> Well, I'll give it a try tomorrow and will let you know.
20131128 04:17:57< mattsc> In the meantime, I would encourage you to try it out with those lines 51-53 uncommented, it's really quite educational (and fun).
20131128 04:18:14< mattsc> Well, for people like me who don't know these things.  You probably know all this already.  :)
20131128 04:19:06< Alarantalara> indeed :)
20131128 04:19:19< Alarantalara> anyway, I should go to sleep
20131128 04:19:28< Alarantalara> good night
20131128 04:19:32-!- Alarantalara [~Adium@192-0-128-11.cpe.teksavvy.com] has quit [Quit: Leaving.]
20131128 04:19:56< mattsc> good night
20131128 04:20:57-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Remote host closed the connection]
20131128 04:30:04< mattsc> Alarantalara:  (I'm pretty sure you read the logs)  I think I see now what you are saying.  And yes, that method might have some restrictions, but so does the C++ method.
20131128 04:31:10< mattsc> I'll just do some more testing and see in which situations it works and in which it doesn't.  I'm pretty sure I can get it to work for a couple things that I'd really like to be able to do.
20131128 05:49:59-!- mattsc [~mattsc@154.20.32.246] has quit [Quit: Ciao]
20131128 06:42:37-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-umc-dev
20131128 06:51:51-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-umc-dev
20131128 09:01:57-!- shadowm_desktop [~ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 248 seconds]
20131128 11:01:20-!- irker469 [~irker@ai0867.net] has quit [Quit: transmission timeout]
20131128 14:45:24-!- mattsc [~mattsc@fw.hia.nrc.ca] has joined #wesnoth-umc-dev
20131128 14:57:29-!- Octalot [~noct@245.176.90.146.dyn.plus.net] has joined #wesnoth-umc-dev
20131128 15:48:49-!- Alarantalara [~Adium@192-0-128-11.cpe.teksavvy.com] has joined #wesnoth-umc-dev
20131128 16:08:42-!- Alarantalara [~Adium@192-0-128-11.cpe.teksavvy.com] has quit [Ping timeout: 240 seconds]
20131128 17:41:11-!- Octalot [~noct@245.176.90.146.dyn.plus.net] has quit [Read error: Operation timed out]
20131128 18:17:03-!- irker182 [~irker@ai0867.net] has joined #wesnoth-umc-dev
20131128 18:17:03< irker182> wesnoth-umc-dev: doofus-01 * r19385 /trunk/Trinity/scenarios/ (ZZ_Dark_Planet-events.cfg ZB_Dark_Planet-switching.cfg): 
20131128 18:17:03< irker182> wesnoth-umc-dev: adding an event to last scenario
20131128 19:15:59-!- Octalot [~noct@245.176.90.146.dyn.plus.net] has joined #wesnoth-umc-dev
20131128 21:20:50-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20131128 21:25:52-!- irker182 [~irker@ai0867.net] has quit [Quit: transmission timeout]
20131128 21:33:29-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-umc-dev
20131128 21:49:02< mattsc> Alarantalara, I did a bunch more tests over lunch and I think I encountered one of those cases that you tried to explain to me yesterday and that I was too stupid to understand...
20131128 21:50:04< mattsc> I get it now, and if I understand that right, it seems to be fundamental problem of how the A* search works and there's not really anything I can do about it.  :(   (I believe you tried to tell me that yesterday also)
20131128 21:51:39< mattsc> So, I can do the "stay out of avoided area altogether" thing quite easily, but applying a penalty only at the end of each move just doesn't quite work ...
20131128 22:25:48< mattsc> ... actually, no, I take that back.  It would work, if I can have additional piece of information available.
20131128 22:27:02< mattsc> Am I allowed to add the current hex to the parameters transferred to the cost function here: https://github.com/wesnoth/wesnoth-old/blob/master/src/pathfind/astarsearch.cpp#L216
20131128 22:27:13< mattsc> Id' like to change that to:
20131128 22:27:30< mattsc> double cost = n.g + calc->cost(locs[i], n.g), n.curr;
20131128 22:27:40< mattsc> Oops  :P
20131128 22:27:49< mattsc> double cost = n.g + calc->cost(locs[i], n.g, n.curr);
20131128 22:33:41< mattsc> AI0867: I'd have to make sure that I don't get the "unused parameter" warning again if I do that  :P
20131128 22:50:02-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds]
20131128 22:57:48-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-umc-dev
20131128 23:07:33-!- Alarantalara [~Adium@192-0-128-11.cpe.teksavvy.com] has joined #wesnoth-umc-dev
--- Log closed Fri Nov 29 00:00:12 2013