Kael
Deity
I think TGA is gonna use this to build a Chess tutorial with the Civ4 engine.
Movement highlighting
- Thread starter The Great Apple
- Start date
Errors when loading the mod with the latest version TGA. Here are the first several before I started hitting "Enter". These all have the Python Exception error box.
Traceback (most recent call last)
File"<string>" line1, in?
File"<string>" line52, in load_module
File "CvEventInterface", line 14, in?
File"<string>" line35, in?
File"<string>" line13, in_get_code
The mod did load, but when I started a game I got more Python errors and there was no move highlighting in the game when it did start.
Traceback (most recent call last)
File"<string>" line1, in?
File"<string>" line52, in load_module
File "CvEventInterface", line 14, in?
File"<string>" line35, in?
File"<string>" line13, in_get_code
The mod did load, but when I started a game I got more Python errors and there was no move highlighting in the game when it did start.
The Great Apple
Big Cheese
Right - I have no idea what's wrong with that - looks like it might be a syntax error somewhere or something. Will have another check through.woodelf said:
Ta
The Great Apple
Big Cheese
I found me a syntax error! I forgot to comment out one of the comments.... ooops!
First post updated.
First post updated.
The Great Apple
Big Cheese
Wooohoo - more.
*curses loudly*
*curses loudly*
The Great Apple
Big Cheese
Right... I have officially no idea what's wrong.
When I get home in ~ 3 weeks I might have another go at this.
When I get home in ~ 3 weeks I might have another go at this.
12monkeys
Prince
I did follow that thread and had a look into the code. Due to the fact, that the movementCost method seems only to work for adjacent plots and the generatePath method could not be called from Python directly, I think the solution for problem will result in a huge and complex code, which very probable would be slow in execution.
I think the easiest solution for the problem would be the usage of the generatePath function. I tried to use it in one of my current projects (btw, for a very similar function as the Move Highlighter) , but I failed due to the "int*" parameter. So I started a new thread to solve this problem. I think with a small interface function made in C the problem could be solved, and the generatePath method could be used. See this link for the thread http://forums.civfanatics.com/showthread.php?t=160293
I think the easiest solution for the problem would be the usage of the generatePath function. I tried to use it in one of my current projects (btw, for a very similar function as the Move Highlighter) , but I failed due to the "int*" parameter. So I started a new thread to solve this problem. I think with a small interface function made in C the problem could be solved, and the generatePath method could be used. See this link for the thread http://forums.civfanatics.com/showthread.php?t=160293
12monkeys said:
Shortest path algorithms are simple directed graph algorithms, not hard, nor slow given the limited range of most units. (What.. 10? at the outside). So even if we had to do it ourselves, it could be done. As for inaccurate readings, we could setXY the unit all over the grid to get samplings if necessary. But I don't have time to look at it atm
. *sigh* So many fish to fry.
The Great Apple
Big Cheese
The one on the first post is the current incarnation.
A sufficiently good path finder should be no slower than using an inbuilt one, as the inbuilt one has exactly the same problems to overcome. I'm not sure the pathfinder I've got in there is the best way of doing it, though I think it'll work.
The way I'm doing it may well be quite slow... it's quite a brute force method - searches through every possible path until it runs out of moves!
A sufficiently good path finder should be no slower than using an inbuilt one, as the inbuilt one has exactly the same problems to overcome. I'm not sure the pathfinder I've got in there is the best way of doing it, though I think it'll work.
The way I'm doing it may well be quite slow... it's quite a brute force method - searches through every possible path until it runs out of moves!
TrueAce
Chieftain
so... is it working? if it is, I will put it in my mod. If not, tell me what I can do to help.
12monkeys
Prince
Mmmh! I think I make it work. I implemented a A* pathfinding algorithm. Have to do some fine tuning and optimizations but I looks quite well.
@Belizan : you're right. The algorithm is really quite fast.
Will post a version tonight or tmorrow evening.
@Belizan : you're right. The algorithm is really quite fast.
Will post a version tonight or tmorrow evening.
12monkeys
Prince
OK, here it is. It's still a beta and still far away from beeing perfect. In complex maps the algorithm fails to find all possible pathes. Have to tune it the next days (presupposed if I'll find the reason). Also, not all planned functions are working right now.
I moved everything into a seperate py file called AStar.Py to have a future Python Component.
Everybody who is interrested may test it, please. Any kind of feedback is very much appreciated.
@TGA: sorry for hijacking this one
, but this became a very interresting topic for me.
I moved everything into a seperate py file called AStar.Py to have a future Python Component.
Everybody who is interrested may test it, please. Any kind of feedback is very much appreciated.
@TGA: sorry for hijacking this one
, but this became a very interresting topic for me.
The Great Apple
Big Cheese
Absolutely no problem. Once I found out that I'd have to write a pathfinding algorithm I pretty much gave up all hope of getting it to work without access to Civ. Thanks for taking this on!12monkeys said:@TGA: sorry for hijacking this one
I've had a brief glance over your code (very brief for now) - looks good. My plan was to spam squares, tagging everyone that could be moved to until there weren't any left in the range, can you give a brief explaination of how you've done it?
Also - an idea: Maybe some additional shading colours? Red, for example, could be used for a move that would cause a combat, and maybe yellow for lands you don't have open borders on or something (or maybe ones that you could move to but are covered by FoW so you can't be sure).
Good luck finishing this off!
12monkeys
Prince
The whole thing works in two steps :
- one method to determine the movable area of the unit [highlightMovableArea()]
- one methof to find the path to a specific plot [generatePath()]
The second one uses the A* pathfinding algorithm to find a path to the a specific plot. Anyone who is interrested about how that algorithm works can have a look here.
The method returns the movement costs the unit needs to get to the targetplot. The method is not working perfect right now, because I get different results depending on the calculation of the so called heuristic value. Had to keep an eye on it.
The highlightMovableArea() method checks all adjacents plot of a given plot. Initially it is called with the units current plot and so it starts to check all adjacents of that plot. It tries to generate a path to the first adjacent using the above mentiond path finder. If a path is possible, the costs are compared with the movement costs the unit has left. If the check is OK, the plot is added to an OK list and the function is called recursivly. If the check is not OK (for any reason), the plot is put on a NotOK list and the next adjacent is checked. If no adjacent is left, the function returns. The OK list is the list of all accessable plot, which is highlighted.
About the colored plots : I exactly had the same idea, but I first want to make both algorithms work fine. I have a strange problem on complex maps, that not all possible plots are found. After this is fixed, I will start to implement the color feature.
I also want to implement some other small things, like "Ignore Fog Of War", "Ignore Enemy Units" (an enemy unit may block the only path to some other plots) and "Ignore Enemy Territory" (same problem).
Another idea I had, is not to reduce the highlighted area to the actual move and also to highlight the second or third move in a different shade or color. This may be not useful due to to high performance loss, but I'll give it a try. At least the AStar lib should be able to do it.
The last thing I would like to implement is to get it work for unit stacks. Bit this may also not very useful due to the same performance reasons.
However, will keep on working on it.
- one method to determine the movable area of the unit [highlightMovableArea()]
- one methof to find the path to a specific plot [generatePath()]
The second one uses the A* pathfinding algorithm to find a path to the a specific plot. Anyone who is interrested about how that algorithm works can have a look here.
The method returns the movement costs the unit needs to get to the targetplot. The method is not working perfect right now, because I get different results depending on the calculation of the so called heuristic value. Had to keep an eye on it.
The highlightMovableArea() method checks all adjacents plot of a given plot. Initially it is called with the units current plot and so it starts to check all adjacents of that plot. It tries to generate a path to the first adjacent using the above mentiond path finder. If a path is possible, the costs are compared with the movement costs the unit has left. If the check is OK, the plot is added to an OK list and the function is called recursivly. If the check is not OK (for any reason), the plot is put on a NotOK list and the next adjacent is checked. If no adjacent is left, the function returns. The OK list is the list of all accessable plot, which is highlighted.
About the colored plots : I exactly had the same idea, but I first want to make both algorithms work fine. I have a strange problem on complex maps, that not all possible plots are found. After this is fixed, I will start to implement the color feature.
I also want to implement some other small things, like "Ignore Fog Of War", "Ignore Enemy Units" (an enemy unit may block the only path to some other plots) and "Ignore Enemy Territory" (same problem).
Another idea I had, is not to reduce the highlighted area to the actual move and also to highlight the second or third move in a different shade or color. This may be not useful due to to high performance loss, but I'll give it a try. At least the AStar lib should be able to do it.
The last thing I would like to implement is to get it work for unit stacks. Bit this may also not very useful due to the same performance reasons.
However, will keep on working on it.
