Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#3295 closed defect (fixed)

building placement broken for the ai

Reported by: mimo Owned by: mimo
Priority: Release Blocker Milestone: Alpha 19
Component: AI Keywords: pathfinding patch
Cc: Patch:

Description

The AI used the passability map (foundationObstruction class) to be aware of obstruction of already built structures. This class is no more available with the new pathFinder, so the AI has now no way to know which passable areas are obstructed for construction. This is particularly true for fields whose construction is presently broken: the AI builds successfully the first field, but then tries to build the following fields at the same location.

Attachments (2)

passClasses.patch (17.4 KB ) - added by Itms 9 years ago.
AIBuilding.diff (7.7 KB ) - added by mimo 9 years ago.
AI patch to be applied in addition of Itms patch

Download all attachments as: .zip

Change History (12)

comment:1 by Itms, 9 years ago

Keywords: pathfinding added

comment:2 by agentx, 9 years ago

pressing thumbs this is solvable.

comment:3 by sanderd17, 9 years ago

Would it be enough if the AI can access a "CheckBuilingPlacement" function in the Engine? Just like the GUI can.

Then we only need to clone the Obstruction Map to the AIManager or AIInterface, together with the terrain obstruction map, and call a static version of the CheckBuildingPlacement function using that data.

This function is rather fast (when placing a building with the GUI, it must also be executed every frame without causing lag), but using only a "check" function might be too little for the AI.

In any case, it should be solvable by adding a new pathfinding class with the old behaviour.

comment:4 by mimo, 9 years ago

Yes, accessing CheckBuildingPlacement would do it (although I wonder if that could give problems when we will run the AI in a different thread), but I'm afraid of performances because basically the AI needs to check every possible tile to find the best one. With the previous grid, this was really fast and the obstruction test was the first done when looping on all tiles. We can change the order of tests and check the obstruction only at the end (i.e. only for tiles satisfying other AIs criteria for a good placement) but that can still make a lot of calls.

Restoring the old behaviour even as a temporary solution would be very useful, not only for AI dev but also to check the pathFinder.

Edit: in fact, we could still use the present grid with the passability criteria to eliminate most of the non buildable tiles, and only call the checkBuildingPlacement at the end to catch the few cases of passable-but-non-buildable, that would decrease the number of needed calls to checkBuildingPlacement.

Last edited 9 years ago by mimo (previous) (diff)

comment:5 by Itms, 9 years ago

Keywords: review patch added

This patch should lay out the basis of a somewhat different design with "pathfinding passability classes" and "non-pathfinding pass classes".

I have still some comments to rewrite in accordance to these changes, but I'd like to see if it works for you.

So you now need to use "building-land" instead of "default-no-clearance" for building placement, and you still have "default-terrain-only" at your disposal. I couldn't imagine a situation where "default-no-clearance" would be needed now. Let me know if I'm wrong.

If everything works well enough, I'll commit that and this new pass classes design should allow me to fix a number of bugs in Atlas in a nice way.

by Itms, 9 years ago

Attachment: passClasses.patch added

comment:6 by sanderd17, 9 years ago

As obstructions have multiple block flags ( http://trac.wildfiregames.com/browser/ps/trunk/source/simulation2/components/CCmpObstruction.cpp#L162 ), wouldn't it be better to use these flags instead of one IgnoreObstructions flag in the pathfinder xml?

The different flags can be combined to one mask on pathfinder init, to avoid slowdowns. As now, with one IgnoreObstructions flag, it's unclear whether a field counts as an obstruction, if an open gate counts as an obstruction, if a unit counts as an obstruction, ... For one part of the code, it should, for another, it shouldn't

Also, what certainly needs to be tested are the special cases wrt building. Like if the AI can still build docks, and if a player can still build a wall (when building a second stretch of wall, there's a wall piece that overlaps with the first tower, but should still be build).

comment:7 by mimo, 9 years ago

I've tested the patch (some corrections are needed to adapt the AI), and placement building for the AIs is working with it. I did test several maps, even naval maps, and the AIs were able to build. There is only one map (which I have to investigate) "Cycladic Archipelago (3)" with 3 AIs where one of them was unable to build houses. But this should be a different problem.

Last edited 9 years ago by mimo (previous) (diff)

by mimo, 9 years ago

Attachment: AIBuilding.diff added

AI patch to be applied in addition of Itms patch

comment:8 by Itms, 9 years ago

In 16784:

Changes the general behavior of non-pathfinding passability classes, in order to make the handling of foundation obstructions less difficult. This will allow the AI to be fixed, as reported in #3295.

Also some cleanup and comments updates.

Refs #3295.

comment:9 by mimo, 9 years ago

Owner: set to mimo
Resolution: fixed
Status: newclosed

In 16785:

adapt the AI to r16784, fixes #3295

comment:10 by mimo, 9 years ago

Keywords: review removed
Note: See TracTickets for help on using tickets.