0000498: callback & CGlobalAI function bugs

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000498

public

2007-03-24 22:37

2010-12-12 19:18

Reporter

Reth

Assigned To

abma

Priority

normal

Severity

minor

Reproducibility

N/A

Status

resolved

Resolution

fixed

Summary

0000498: callback & CGlobalAI function bugs

Description

[minor]
callback->GiveOrder(unit, &c)
[Description]: when c.id=CMD_RECLAIM & c.params[0]="the id of a reclaimable" - the order will do nothing
HOIJUI EDIT: { DONE
relevant code can be found in CBuilderCAI::ExecuteReclaim in file rts/Sim/Units/CommandAI/BuilderCAI.cpp
c.params[0]="the id of a reclaimable" has to be:
for a unit: the unitId to reclaim
for a feature: MaxUnits + the featureId to reclaim
}

[minor]
callback->GiveOrder(unit, &c)
[Description]: once an 'immobile constructor' such as a 'Vehicle Plant' has been given a CMD_WAIT, additional given commands are ignored. When I was testing this, I was trying to issue a CMD_STOP after the CMD_WAIT had been issued.

[very minor]
callback->GetUnitTeam(enemy)
callback->GetUnitAllyTeam(enemy)
[Description]: returns 0 for, both, units of team 0 and enemies that are outside of LOS but in Radar. In this case, it may be a better choice to return -1 on error.
HOIJUI EDIT: { DONE
done with commit: cc690de0d634d943a95b9301d2a137b0c93b86f7
}

[very minor]
callback->GetElevation(x,z)
[Description]: fails when used at a location with water
HOIJUI EDIT: { FEEDBACK
need more info:
* spring crashes?
* always the same value returned?
* water level returned?
* earth-level returned (eg. sea ground)?
what do you expect?
}

[spring crash]
callback->GetFeatureDef(int feature)
callback->GetFeatureHealth(int feature)
callback->GetFeatureReclaimLeft(int feature)
callback->GetFeaturePos(int feature)
[Description]: occurs if the feature id is no longer valid or never was valid. Due to this, it is impossible to check if a feature still exists
[easily reproduced], "callback->GetFeatureDef(5001);"
HOIJUI EDIT: { DONE
fixed, do not know when, somewhen... in the past.
}

[minor]
void UnitDestroyed(int unit)
[Description]: fails to execute, if an immobile constructor's construction, such as a 'Vehicle Plant' building a 'Jeffy', is canceled by a human player on the same team as the AI.
[easily reproduced]

[rare occurrence]
void UnitIdle(int unit)
void UnitMoveFailed(int unit)
[Description]: passes a unknown 'unit id'.
[Testing]: the events will occur in this order for the given 'unit id':
1) UnitCreated()
2) UnitFinished()
3) UnitDestroyed()
    4) occurs immediately after 3)
4) UnitIdle() and/or UnitMoveFailed()
    - from this point on, no more events for this unit will occur.
HOIJUI EDIT: { WONT-FIX
not sane to try to fix this with only this info,
especially as it is likely fixed already by now
}

[rare occurrence]
void EnemyEnterLOS(int enemy)
void EnemyLeaveLOS(int enemy)
void EnemyEnterRadar(int enemy)
void EnemyLeaveRadar(int enemy)
[Description]: passes a unknown 'enemy id'.
[Testing]: the events will occur in this order for the given 'enemy id':
1) EnemyEnterRadar() and/or EnemyEnterLOS()
2) EnemyDestroyed()
    3) occurs immediately after 2).
3) EnemyLeaveRadar() and/or EnemyLeaveLOS()
    - from this point on, no more events for this unit will occur.
HOIJUI EDIT: { WONT-FIX
not sane to try to fix this with only this info,
especially as it is likely fixed already by now
}

[extremely rare occurrence - likely the cause of many unexplainable AI crashes]
void UnitDestroyed(int unit)
void EnemyDestroyed(int enemy,int attacker)
[Description]: both UnitDestroyed() & the opposing team's EnemyDestroyed() event will fail to trigger.
[Testing]: 1AI vs 1AI, the events will occur in this order:
1)first ai - UnitCreated()
    - unknown time difference between 1) and 2)
2)second ai - EnemyEnterLOS() and/or EnemyEnterRadar()
    - from this point on, no more events for this unit are triggered on either team.
    - in Update(), the check [cb->GetUnitDef() == 0] is preformed every 3 seconds for all units.
3)first ai - Update(), 0-36+ seconds after the previous event - the above condition returns true.
[My Comments]: I personally can't make much sense of what causes this, but it's definitely a problem that needs to be fixed, since most AIs assume UnitDestroyed() triggers properly, this can easily cause an AI to crash during an Update().
HOIJUI EDIT: { WONT-FIX
not sane to try to fix this with only this info,
especially as it is likely fixed already by now.
give more specific info if it still occurs. a replay would be best.
}

[rare occurrences]
void EnemyEnterLOS(int enemy)
void EnemyLeaveLOS(int enemy)
void EnemyEnterRadar(int enemy)
void EnemyLeaveRadar(int enemy)
void EnemyDestroyed(int enemy,int attacker)
[Description]: EnemyEnterRadar&EnemyEnterLOS will not be triggered while EnemyDestroyed() will be.
[Testing]: 1AI vs 1AI, events occur in the following order:
1) first ai - UnitCreated()
    2) occurs immediately after 1)
2) first ai - UnitDestroyed()
2) second ai - EnemyDestroyed()
- from this point on, no more events for this unit will occur.

[common, but does not occur in ffa games]
void EnemyDestroyed(int enemy,int attacker)
[Description]: EnemyDestroyed() will not be triggered 'at all' for specific teams && I suspect EnemyDestroyed() will sometimes be triggered for the wrong team.
[Testing]: If a game is setup as 2AIs vs 2AIS vs 2AIs, then EnemyDestroyed() will never occur for the fourth/fifth/sixth AIs & additionally the EnemyDestroyed() event passed to the second&third AIs will commonly have an unknown 'enemy id'.
[My Conclusion]: Basically allyteam is being used to determine which team will receive the event - there may be more to it that than, but it will be difficult to test until this and the other mentioned problems with EnemyDestroyed() have been fixed.
HOIJUI EDIT: { DONE (assumption)
i am pretty sure that this was fixed somewhen in a few commits a while ago
}

[rare occurrence]
int HandleEvent (int msg,const void *data)
void EnemyEnterLOS(int enemy)
void EnemyLeaveLOS(int enemy)
void EnemyEnterRadar(int enemy)
void EnemyLeaveRadar(int enemy)
[Description]: AI_EVENT_UNITGIVEN & AI_EVENT_UNITCAPTURED does not trigger for ally ai teams.
[Testing]: 2AIs vs 2AIs, the first&second AIs on team 1, the third&fourth AIs on team 2, events occur in the following order:
1) first ai - UnitCreated()
2) first ai - UnitFinished()
3) third&fourth ai - EnemyEnterLOS() and/or EnemyEnterRadar()
4) first ai - HandleEvent(AI_EVENT_UNITCAPTURED)
4) third ai - HandleEvent(AI_EVENT_UNITGIVEN)
    - at this point the first & third ais have the correct information.
    - the second ai ~potentally~ has an enemy running around in it's territory that is unknown - since no ai events informed it that the captured unit is now an enemy within LOS/Radar.
    - the fourth ai has a enemy id on its 'enemy list' that is now an allied unit.
[My Suggestions]: To fix this problem there are 2 possible solutions:
    (1) - trigger EnemyEnterLOS/EnemyEnterRadar, when appropriate, for the allies of the unit's oldteam & trigger EnemyExitLOS/EnemyExitRadar, when appropriate, for the allies of the unit's newteam.
    or (2) - the HandleEvent(AI_EVENT_UNITGIVEN & AI_EVENT_UNITCAPTURED) should be sent to the whole ally team and not just the team who's unit was captured/given to.

[extremely rare occurrence]
void UnitDestroyed(int unit)
void EnemyDestroyed(int enemy,int attacker)
int HandleEvent (int msg,const void *data)
[Description]: if a unit is destroyed at about the same time as being captured, the events AI_EVENT_UNITGIVEN & AI_EVENT_UNITCAPTURED are still triggered & neither EnemyDestroyed() or UnitDestroyed() will be triggered properly for the newteam of the captured unit.
[Testing]: 1AI vs 1AI, events occur in the following order:
1) first ai - UnitCreated()
2) first ai - UnitFinished()
3) second ai - EnemyEnterLOS() and/or EnemyEnterRadar()
4) first ai - UnitDestroyed()
    5) occurs immediately after 4)
5) first ai - HandleEvent(AI_EVENT_UNITCAPTURED)
5) second ai - HandleEvent(AI_EVENT_UNITGIVEN)
    - from this point on, no more events for this unit will occur.

Date Modified	Username	Field	Change
Issue History
2007-03-24 22:37	Reth	New Issue
2009-09-13 14:54	hoijui	Description Updated
2009-09-13 15:11	hoijui	Description Updated
2010-12-12 19:18	abma	Note Added: 0006069
2010-12-12 19:18	abma	Status	new => resolved
2010-12-12 19:18	abma	Resolution	open => fixed
2010-12-12 19:18	abma	Assigned To	=> abma

Relationships