Fri 17 Oct 2008 02:55:15 PM UTC, comment #11:
Thanks so much for identifying this shortcoming.
I was wondering about the case of having a stack of 8 all the way cross a river and into a friendly city... the stack would zip across the water without ever losing all of it's movement points.
I'm fairly sure that we have achieved the same behaviour as WL2... with the same drawbacks.
|
Fri 17 Oct 2008 02:50:41 PM UTC, comment #10:
Hehe, IMHO it's OK to be closed now.
Still, there is this situation where you can jump a few tiles into the ocean if there exists already some stacks of sufficient size between.
movement direction: --------->
[2,city][8,boat][8,boat][free,ocean]
Note, that this could be misused to build a bridge ;-).
The correct behavior would be:
> as long as "boarding ships" take all remaining movement points of a stack, ships must be blockers for stacks that are about to board a ship (-> movement algorithm).
(file #16690)
|
Fri 17 Oct 2008 12:35:43 PM UTC, comment #9:
Nice analysis! Thanks for following up. fixed in svn.
okay to close?
|
Fri 17 Oct 2008 10:37:06 AM UTC, comment #8:
> the crash is fixed in svn.
I agree.
However, consider the attached "jumping_ghosts.sav" in which you should look near the city closest to the sea for a situation as follows:
moving direction: ---->
[7 ghosts et al][2 ghosts][1 ghost/destination]: 7 is blocked by 2
[7 ghosts et al][2 ghosts][1 ghost][empty/destination]: 7 is not blocked
This looks like you currently allow jumping if there is a free tile reachable within this turn. But it suffices to look for a tile with sufficient capacity.
(file #16686)
|
Fri 17 Oct 2008 01:19:11 AM UTC, comment #7:
okay the crash is fixed in svn.
Can you test it some more?
Let me know when you think this bug is okay to close.
|
Fri 17 Oct 2008 12:17:04 AM UTC, comment #6:
Thanks for the saved-game file.
I suppose the path gets short-circuited when the stack goes into a boat, and then a stack join operation tries to happen and fails horribly.
Actually it seems to loop over and over again on the stack join operation.
|
Thu 16 Oct 2008 11:10:27 PM UTC, comment #5:
SVN Version: The game now crashes if you try to "jump" over a ship in certain situations. Look in the attached save game at the two seas-side cities and find the following situation:
[worms in the city][ship at the shore][free sea tile]
It seems that the stacks get combined and exceed the size of some data structure.
Conclusion: As long as "boarding ships" take all remaining movement points of a stack, ships must be blockers for stacks that are about to board a ship (-> movement algorithm).
---
A side note on pathfinding: Usually the number of shortest routes is bigger than 1. In unresolvable blocking situations it would be nice to make use of them. But I'm not sure if this is a low-hanging fruit.
(file #16684)
|
Thu 16 Oct 2008 09:53:32 PM UTC, comment #4:
I think dragging a stack to make a tentative path is bugged, and it's unrelated to this feature.
|
Thu 16 Oct 2008 08:53:28 PM UTC, comment #3:
I have committed this feature.
Right now it is broken wrt dragging a stack, so I'm leaving this bug open for now.
Please test this, especially with boats and such.
|
Thu 16 Oct 2008 08:00:12 PM UTC, comment #2:
First, thank you for your feedback. Just to clarify: As you said, right now, paths are not calculated to go around friendly stack and this results in the problem that an "army of 1" can block a full stack. Also I agree that it is not a good thing to spend movement points, if it is not really necessary.
As far as I see it, a movement within a turn is an atomic operation: There is a stack, a destination, a path and x movement points are to be spent. The movement algorithm should move the stack to the farthest suitable location along the path. Regarding your concern that two friendly stacks will occupy the same tile for a short amount of time: If this a problem for the GUI, then save and remove the blocking stack before you move; and re-add it after the moving stack has passed. It should look like the moving army is above the friendly stack. If there are other problems that I don't see, describe them and I'll find a solution ;-).
An alternative solution for most blocking situations would be to break up the stack and move each unit individually. This would cover most cases except where the blocking stack is of size 8, of course.
|
Thu 16 Oct 2008 07:21:24 PM UTC, comment #1:
Thanks for the bug report.
Your description of the problem makes it sound like paths get calculated to go around all friendly stacks, but this is not the case. Movement is indeed allowed over existing friendly stacks that have a "sufficient capacity".
Friendly stacks with insufficient capacity currently block movement. For example, a scout's path will not be rerouted around a stack of 8 army units. When the scout is told to travel along it's path, it will stop at the tile prior to the stack of 8 army units.
My immediate take on this is that movement points are a precious resource in the game, and the lone scout should not have it's path calculated to go around the stack of 8 army units.
Your suggested solution of letting the lone stack pass by the stack of 8 army units is a good one, and is indeed how Warlords II works. My main concern is that two friendly stacks will occupy the same tile for a short amount of time. From what I know of the code, it's a risky state to be in.
|
Thu 16 Oct 2008 06:41:18 PM UTC, original submission:
Using development snapshot 0.1.3: Existing stacks along a path are not considered while pathfinding. Depending on how you see it, either
1) the pathfinding algorithm should automatically compute a bypass
OR
2) the movement should be allowed over existing, friendly stacks
if a field with sufficient capacity exists down the path that
is reachable within the current turn (my suggestion).
If prefer 2) because most of these situation happen if you move armies to another location and can be easily resolved manually by moving the blocking stack first
|