Weird findings in UnitAI. Possible bug in AI system?

[rjs23]

As i was trying to track a unit's target ID, I found a weird behavior in how its target ID changes.

Every time a unit was order to attack or gather, its target ID given is valid thus does not cause unknown entity ID error yet.

However, when a unit was assigned a "move" command after it was assigned to gather/attack any object, its target ID changes to the new number to where entity doesn't exist in entity array given by gameState. It simply does not exist, and it returns undefined, yet the number keeps increasing...

What concerns me is that there may be a memory leak or possible undetected bug in this system. Because each time order a unit to gather something then order that same unit to move, the target ID are new and does not seem to be found in entity array. Each time you repeat this command (gather, then move, then gather, then move) the target ID keeps increasing over and over but no entity for it exists which may cause some errors in AI bots that are trying to track entity's targets.

I'm not sure but it seems illogical to assign target ID to a unit under moving command. The correct value would have been left undefined, in my opinion, each time you order a unit to move. It shouldn't return nonexist entity id.

The scenario looks like this: (I used "Display selection state" to prove this)

1. Order a female to gather tree. Its target id is that tree id (458 in this scenario)

2. Before it gathers that tree, order the female to move near that tree (target id changes to 1250, which is undefined according to gameState.)

3. As it moves, order it to gather that same tree (target ID then changes back to 458)

4. Then order it to move to near that tree again (target ID changes to 1251, notice how the target ID keeps increasing each time you order a unit that was previously under ordered?)

5. Gather it, (changes back to 458)

6. Move it. (changes to 1252).

Each time you order a move command that was different than its previous command, its target ID increases for some reason.

I'm just advertising this weird finding.

It might lead to memory leak or unexpected logic behavior.

Is this normal or is this a unintended behavior?

Edit: When I restart the game (by clicking X on window and restart it) , this bug disappears. I could not reproduce it anymore. It seems like this bug is triggered by something.and causes the UnitAI to act incorrectly.

Edited August 9, 2012 by rjs23

[Zeta1127]

I have seen a weird bug were builders can't be ordered to hunt.

[Deiz]

Are you sure you're remembering correctly?

What you're describing sounds a lot like formation behaviour, however female citizens can never be members of formations. Formations are implemented as pseudo-entities which all formation members target and attempt to move with. They're destroyed as soon as the formation is disbanded, and the engine intentionally doesn't re-use entity IDs.

A formation will be formed any time you have multiple formation-capable entities selected. For example, if you move two soldiers they form a formation and each target it. Say its ID is 1000, when they reach their destination it will disband. If you then give them a new move order, they will be in a formation with ID 1001, and so on.

[rjs23]

Are you sure you're remembering correctly?

What you're describing sounds a lot like formation behaviour, however female citizens can never be members of formations. Formations are implemented as pseudo-entities which all formation members target and attempt to move with. They're destroyed as soon as the formation is disbanded, and the engine intentionally doesn't re-use entity IDs.

A formation will be formed any time you have multiple formation-capable entities selected. For example, if you move two soldiers they form a formation and each target it. Say its ID is 1000, when they reach their destination it will disband. If you then give them a new move order, they will be in a formation with ID 1001, and so on.

That explains it. I was using soldiers, not a female worker. I had it mixed up, my apology for the confusion. I reproduced this and it confirms what you're saying. So, it depends on unit's target attribute for formation to work? Shouldn't it be using have its own attribute instead of sharing with target attribute?