15 replies to this topic

[ribez]

hi, i've just dowloaded alpha 9 and found one problem, that you probably already know, about women get stucked

the map is Battle for the Tiber. If you want, i have also the savegame

As you can see, a woman try to reach the Civic Centre, while the other try to reach the field, and they get stucked with two trees

Attached Thumbnails

• 
• 
• 

[FeXoR]

ribez, on 15 March 2012 - 07:22 PM, said:

hi, i've just dowloaded alpha 9 and found one problem, that you probably already know, about women get stucked

the map is Battle for the Tiber. If you want, i have also the savegame

As you can see, a woman try to reach the Civic Centre, while the other try to reach the field, and they get stucked with two trees

Yes, something like that often leads to piled up AI peasants at a single tree even if its in the middle of free space. AIs shouldn't send more then about 6 units to the same entity to gather there. That makes the game lag and prevents the AI from gathering anything.

[wraitii]

FeXoR, on 16 March 2012 - 08:30 AM, said:

Yes, something like that often leads to piled up AI peasants at a single tree even if its in the middle of free space. AIs shouldn't send more then about 6 units to the same entity to gather there. That makes the game lag and prevents the AI from gathering anything.

That's actually nearly impossible to prevent given how the AI/UnitAI/Pathfinding is currently implemented. These issues, imo, could be solved by the improved pathfinding Philip is working on, and some sort of "target_unreachable" event for the AIs.

[FeXoR]

wraitii, on 16 March 2012 - 10:47 AM, said:

That's actually nearly impossible to prevent given how the AI/UnitAI/Pathfinding is currently implemented. These issues, imo, could be solved by the improved pathfinding Philip is working on, and some sort of "target_unreachable" event for the AIs.

I perfectly agree!

But historic_bruno said to a similar matter: Post

historic_bruno, on 04 March 2012 - 11:55 PM, said:

I don't think pathfinding will have any impact on this, the new pathfinder is being designed to behave more or less identically to the old, except more precise and consistent.

Edited by FeXoR, 16 March 2012 - 11:29 AM.

[wraitii]

What could also help to solve such thing would be to have the game register entities interacting with each other. When clicking on a tree, the "tree" would remember the ID of the unit assigned to it until it's no more, so the AI can know at each time how many units are working on a resource. This could also be useful for attacks.
It sorta can be hacked in by the AIs using metadatas, but it's not nearly as efficient.

Edited by wraitii, 16 March 2012 - 12:43 PM.

[FeXoR]

wraitii, on 16 March 2012 - 12:42 PM, said:

What could also help to solve such thing would be to have the game register entities interacting with each other. When clicking on a tree, the "tree" would remember the ID of the unit assigned to it until it's no more, so the AI can know at each time how many units are working on a resource. This could also be useful for attacks.
It sorta can be hacked in by the AIs using metadatas, but it's not nearly as efficient.

Why not have the unit remember the ID of the given order's target?
Would make more sense to me

[quantumstate]

FeXoR, on 16 March 2012 - 01:13 PM, said:

Why not have the unit remember the ID of the given order's target?
Would make more sense to me

This approach works to some extent but you get issues when units you assigned to one tree finish gathering and automatically choose a nearby tree to gather from. In this case the AI has no reasonable way of finding out which tree the unit is gathering from.

[FeXoR]

quantumstate, on 16 March 2012 - 02:23 PM, said:

This approach works to some extent but you get issues when units you assigned to one tree finish gathering and automatically choose a nearby tree to gather from. In this case the AI has no reasonable way of finding out which tree the unit is gathering from.

Why? It can do something like:
For all own units add target to a list.
For all different targets in the list count the occurrence.
If the occurrence is greater than wanted and the own unit can 'gather from' the target unit, pick one of those units and send them doing something else (for example give explicit order to harvest from another tree)

What's wrong with that?

[quantumstate]

FeXoR, on 16 March 2012 - 03:02 PM, said:

Why? It can do something like:
For all own units add target to a list.
For all different targets in the list count the occurrence.
If the occurrence is greater than wanted and the own unit can 'gather from' the target unit, pick one of those units and send them doing something else (for example give explicit order to harvest from another tree)

What's wrong with that?

Hopefully I am understanding you correctly. Currently the problem is that the AI has no way to tell what the target of a unit is. More code needs to be added to the AI api to connect it with the UnitAI code.

[wraitii]

That would work too, FeXor, though as Quantumstate said not now... But it implies you have to loop through every worker unit every time you want to know. I think doing this in the engine would be more efficient and more elegant, since it "basically" should only involve a putting stuff in a variable instead of looping through entities, counting stuff, returning the result. If it's done at the "UnitAI" level, it would also make it easier to make sure no case have been forgotten, I think.

The UnitAI definitely needs improvement with AI Interface, however.

Edited by wraitii, 16 March 2012 - 05:13 PM.

[FeXoR]

quantumstate, on 16 March 2012 - 03:42 PM, said:

Hopefully I am understanding you correctly. Currently the problem is that the AI has no way to tell what the target of a unit is. More code needs to be added to the AI api to connect it with the UnitAI code.

Yes, there has to be a way to find out.

I just wanted to point out that IMO the unit should get some kind of 'getTarget()' function (or just a variable 'target' or 'tagetOfAction' or whatever) that returns (holds) the target object (Like: 'point', 'actor' or 'template' or so) or just information that grants access to the target object (like ["point", [x, z]] or ["entity", ID])
Within the information it returns (holds) has to be a way to find it's location or other information (if point maybe it's just point.x/point.z, if it's a unit maybe there's some way to find out with somewhat like 'map.getEntityById()').
I think this is much more intuitive than adding to the tree something like 'this.unitsGatheringFromMeIds([ID1, ID2, ID3, ...])'.

The unitAI don't need to be involved in my opinion. Though I seldom change my gather positions I never run into problems like 20 peasants chop the same tree and block each other trying to get to the tree to chop it or get to the next deposit. So it seams more like an playerAI problem than an unitAI problem to me. So if the playerID had a way to get this information (which may or may not be possible yet, no idea) would be ok. The playerAI has to be able to get information like that anyway for more improved versions that, for example, avoid chasing enemies half across the map or hunt chicken in an enemy base or try gather from enemy fields or this kinds of issues. Of cause that's a question of taste and priority but this information has to be available for the playerAI anyways. So in my opinion the problem can be solved there.

It would be nice though if the unitAI or the pathfinding routine would avoid this in the first place, of cause. But it seams to be under heavy development already at the moment.

Edited by FeXoR, 16 March 2012 - 05:56 PM.

[historic_bruno]

FeXoR, on 16 March 2012 - 11:27 AM, said:

But historic_bruno said to a similar matter: Post

This is quite a different situation, because units are able to move from a passable area into an impassable area but can't get back out, due to a mismatch in the behavior of the long and short range pathfinders. It would be better if they couldn't move into the impassable square to begin with, but also if the pathfinder could be more accurate in determining the gap between the trees. Philip's new pathfinder takes a completely different approach and this is one of the things it should prevent, as described here.

[FeXoR]

historic_bruno, on 16 March 2012 - 09:21 PM, said:

This is quite a different situation, because units are able to move from a passable area into an impassable area but can't get back out, due to a mismatch in the behavior of the long and short range pathfinders. It would be better if they couldn't move into the impassable square to begin with, but also if the pathfinder could be more accurate in determining the gap between the trees. Philip's new pathfinder takes a completely different approach and this is one of the things it should prevent, as described here.

OK, perhaps we are talking about different things here.

In the other post I meant the problem with units trying to chop trees that are so close to the border that they couldn't be reached.
As far as I get it the unitAI (perhaps because of the pathfinder) tells them to chop the nearest tree and that next tree was outside the reachable map area.
However, they didn't stuck there. You could select them and send them to the map center, no problem. The main problem was that the player AI didn't do that (Maybe because there's no way for the playerAI to tell).
That might change with the pathfinder if the unit AI tells to chop the tree because it's told by the pathfinder that it is reachable (I don't know how the unitAI uses the pathfinder ).
But you told me you doubt it. (So I assume the unitAi acts not as I think )

In the OP its about 2 units inside a gap each small enough to pass but not at the same time.
This might change with the pathfinder as well because the unit facing the civil center could take another way and might recognize the block.
However, I have seen units blocking each other with no obstacles near just walking left and right to avoid each other in sync
They both used the short range pathfinder I think ^^.

What I meant here is that, if a player/playerAI (mainly qBot) has tons of peasants, many of them might try to chop the same tree.
The first 10 succeed and begin to chop. The next could reach the target before, but now can't because other units surround it.
After the first citizens got full loaded they try to bring the wood back, but they can't because the later units surround them .
That is a very similar matter to the map border issue IMO because the peasants not capable of reaching the tree (in the surrounding issue the outer/later peasants) didn't tell anyone and the playerAI has no chance to know (If I get quantumstate right).

I don't see how this should be resolved by the new pathfinder. Indeed there IS a way at the moment the unitAt tells to seek the next tree but later it's blocked by other peasants.
And Ykkrosh said himself "...assuming no dynamic obstacles (i.e. other units) get in the way...".

So what I mean is just that it isn't a good idea in my opinion to let the tree 'decide' whether a unit can gather from it or not (Like in Empire earth where only 6 or 7 workers could gather from one source). That's unintuitive and unrealistic. However it could be solved in different ways: The unitAI could seek another tree if the unit doesn't move fare since many rounds or tell 'broke up previously accepted order ', the pathfinder could cry out 'darn, i can't get through ' or the playerAI could check how many of their units are chopping the same tree. All assuming the code allowed that of cause.
I hope this did lower the chance of misunderstanding... and that the new pathfinding will solve it all

Edited by FeXoR, 16 March 2012 - 11:40 PM.

[wraitii]

Yeah, there are two kinds of problems here:

-One, the case where something is unreachable but the AI asks to gather it anyway. In this case, the AI has no way of knowing that, and thus can't react. My best guess at fixing it would be to send to the AI an "unreachable_destination" event that would give the ID of the unit. Then the AI can process it (I dislike having UnitAI do that itself for the AI, as it can be too unpredictable/not react as wanted).

-Two, the "lone tree on the map with 50 villagers around" case. This is specific, it happens to qBot and Marilyn when chopping for wood. Sometimes, workers surround the tree, and then a new wave of workers surround the first wave, and so on, until everyone is stuck around the tree. Again, in this case, there is the "short term" solution of having an "unreachable_destination" event, but also a more long term solution which should, imo, be implemented:
We need a way for the AI to know what a unit (entity at large) is targeting. This way, we could count how many units are gathering from a tree/attacking a unit. This can only be done efficiently at the unitAI level, because the player AI is fairly "abstract", and acts a lot like a player. Sometimes, units react autonomously because of unitAI, and right now the AI can't know that, so it might get stuck. Therefore, the UnitAI must store the target (I studied that script a bit, I imagine it would be "fairly" easy to do and pass to the AIs).

I also suggested an optimization: when setting a unit to a new target, add this unit to a list on the targeted entity, and remove it when it's unassigned from that entity. This would allow to, by checking from a tree, know how many units are gathering it, instead of having to recount every time.

Edited by wraitii, 17 March 2012 - 07:36 AM.

[FeXoR]

wraitii, on 17 March 2012 - 07:33 AM, said:

-One, the case where something is unreachable but the AI asks to gather it anyway. In this case, the AI has no way of knowing that, and thus can't react. My best guess at fixing it would be to send to the AI an "unreachable_destination" event that would give the ID of the unit. Then the AI can process it (I dislike having UnitAI do that itself for the AI, as it can be too unpredictable/not react as wanted).

I just want to add that in case of a human player there should be a sound or some other feedback.
And just a tweak, if not reachable and the target is an entity the unit should not start to walk towards it (an exception would be an garrison order to a ship for example) but if it's a point it should try to get near it as it is right now but still warn.

wraitii, on 17 March 2012 - 07:33 AM, said:

-Two, the "lone tree on the map with 50 villagers around" case. This is specific, it happens to qBot and Marilyn when chopping for wood. Sometimes, workers surround the tree, and then a new wave of workers surround the first wave, and so on, until everyone is stuck around the tree. Again, in this case, there is the "short term" solution of having an "unreachable_destination" event, but also a more long term solution which should, imo, be implemented:
We need a way for the AI to know what a unit (entity at large) is targeting. This way, we could count how many units are gathering from a tree/attacking a unit. This can only be done efficiently at the unitAI level, because the player AI is fairly "abstract", and acts a lot like a player. Sometimes, units react autonomously because of unitAI, and right now the AI can't know that, so it might get stuck. Therefore, the UnitAI must store the target (I studied that script a bit, I imagine it would be "fairly" easy to do and pass to the AIs).

Sounds good to me

wraitii, on 17 March 2012 - 07:33 AM, said:

I also suggested an optimization: when setting a unit to a new target, add this unit to a list on the targeted entity, and remove it when it's unassigned from that entity. This would allow to, by checking from a tree, know how many units are gathering it, instead of having to recount every time.

Oh, ok, you don't mean the tree should prevent a worker from gathering if too many peasants are working on it but just to make it easy to get the number of units (and their IDs) chopping it. That's ok! Sry, I got that wrong. When the unit AI changes the target by player order it still has to tell the old target that the unit is not targeting it any longer.

The best way IMO for the playerAI to have full control without to many checks would still need the unitAI to send an event like 'targetChanged(ID)' if the gathered resource entity runs out. In combination with target stored in unitAI and assigned gatherers stored in the tree this should work fine.

Edited by FeXoR, 17 March 2012 - 10:13 AM.

[Bzzz]

Hi,

maybe this is related. I placed a building quite close to that hill, and every person that is able to walk uphill is then trapped. Manual routing is not possible, and reloading the game doesn't help either (I had a pathfinding problem earlier that game with siege equipment, was fixed by saving and reloading it later)
Also, zooming down finally clips the texture and one can see the otherwise buried model of the building.

Attached Thumbnails

• 
• 
• 
• 

Edited by Bzzz, 30 March 2012 - 07:39 AM.