Page 1 of 1
Note on GetUnitDef(enemyunit)...
Posted: 10 Jan 2006, 16:06
by krogothe
I think that the enemy unitdef problem you are all experience is not a bug in the interface (zaphod and the SYs are too great to create ugly bugs IMO
), but just a setting:
Code: Select all
const UnitDef* CAICallback::GetUnitDef(int unitid)
{
CUnit* unit=uh->units[unitid];
if(unit && (unit->losStatus[gs->AllyTeam(team)] & LOS_INLOS)){
return unit->unitDef;
}
return 0;
}
so it wont allow you to get a def an an enemy unit if they are in radar only, which makes sense since humans cant tell what the unit is just from the radar blip.
In fact, i bet a good part of the AI instability issues across the board are due to enemies being saved and their defs getting called after the enemy left LOS (or say killed the only unit that could see it). Or say trying to get a unitdef of a unit that is in radar but not LOS.
Might also be worth noting that the cheat interface giving all enemy units is pretty useless since the AI is not allowed to find the position or def of the units returned by it. It should simply give the AI LOS for the whole map.
Hope this helps
Posted: 10 Jan 2006, 16:28
by submarine
what did you exspect?
iirc its also mentioned somewhere in the ai documentation... i thought every ai dev would know that
Posted: 10 Jan 2006, 16:46
by krogothe
I dont expect anything, just thought id share, since people are thinking the interface is more buggy than it is
Posted: 10 Jan 2006, 18:04
by jcnossen
I dont expect anything, just thought id share, since people are thinking the interface is more buggy than it is
It's mainly AF who thinks that, but he has no proof though. Also me and submarine never had unexpected results with the AI interface, (other than units getting stuck to buildings, but that a pathfinding problem I think)
Might also be worth noting that the cheat interface giving all enemy units is pretty useless since the AI is not allowed to find the position or def of the units returned by it. It should simply give the AI LOS for the whole map.
That is very true though, it really has to be fixed sometime.
Posted: 10 Jan 2006, 18:24
by krogothe
zaph im looking more and more into the spring source each day so ill probably start helping out with a few things once im good enough in c++. Do i just send you source files with changes?
Posted: 10 Jan 2006, 20:33
by AF
I know this because I rant ests with atatck code.
EnemyUnitEnteredLOS(){
check the position of the enemy unit
if returned position is 0,0,0 or 0,1,0 then give error "failed unit location"
else do attack code
}
The above will always return failed unit location. Sometimes it doesnt, sometimes ti does. I ran tests where if an enemy entered LOS (Not radar, LOS), then the AI would put down a marker. Of course I then tested this out and 9/10 trials in identical circumstances, it failed totally.
I ran similair test using markers and messages for many fo them. Of all the interface functions enemyenteredLOS is the most unreliable, mainly because if you call the engine for information on that unit you dont always get an answer.
Posted: 11 Jan 2006, 02:02
by Chocapic
well in EnemyEnterLOS(int enemy) i also get a fancy null pointer trying to reach out is unitdef, but now i should get the right one as it is in LOS right ?
Posted: 11 Jan 2006, 02:33
by jcnossen
zaph im looking more and more into the spring source each day so ill probably start helping out with a few things once im good enough in c++. Do i just send you source files with changes?
send me a SVN diff file, can be generated with something like
"svn diff directory/source files"
Posted: 11 Jan 2006, 11:13
by krogothe
Chocapic wrote:well in EnemyEnterLOS(int enemy) i also get a fancy null pointer trying to reach out is unitdef, but now i should get the right one as it is in LOS right ?
probably, but maybe you have to delay your unitdef by a frame, give it a go
Posted: 11 Jan 2006, 13:53
by Chocapic
lol, before u said that i did that yesterday, i gave it a 30frame delay!
it works ok its just not the kind of code i was expecting