If i do a GetUnitDef() of a unit twice in the game is the unitdef going to be loaded twice ? or the second time is a cache load ?
I really need to know this cause im on to improving code speed and this is important as i do quite some of these calls.
GetUnitDef() dought
Moderators: hoijui, Moderators
hmmm maybe i didnt explain myself very nicely, but those 50 minwind and 300 maxwind , i get them in any map...
i find it very weird and cant understand, the only thing it might jump out to me is that i do it on the globalai init(), so could the wind things not be initiated at that time ??
i dont really get it
i find it very weird and cant understand, the only thing it might jump out to me is that i do it on the globalai init(), so could the wind things not be initiated at that time ??
i dont really get it
Having looked at the way the AI itnerface gives the AI the unitDefs, I'm not sure that is actually true at all, but it may be true of other things about a unit.
dont bother tryignt o speed it up with caching etc, you're more likely to incur a greater cpu load by trying to streamline it than if you where to use it the way ti's used atm. For any benefits I think you'd have to go into the engine itself.
It's simply nto wortht he effort at the moment when we ahve more rpessing AI problems to sovle, such as a stable interface that doesnt provide misinformation or crash when we do thgins the player cna do all the time!!!
dont bother tryignt o speed it up with caching etc, you're more likely to incur a greater cpu load by trying to streamline it than if you where to use it the way ti's used atm. For any benefits I think you'd have to go into the engine itself.
It's simply nto wortht he effort at the moment when we ahve more rpessing AI problems to sovle, such as a stable interface that doesnt provide misinformation or crash when we do thgins the player cna do all the time!!!
In which case regardless of any improvements this gives you they will be unoticeable and next to impossible to gain any advantage from comapred to those you cna make tot he algorithms that amke your AI cpu itnensive int ehf irst palce.
Try and spread execution over update cycles and find more efficient ways fo doign the bgiger stuff. Eitherway you're gonna get this stuff laoded and if your AI doesnt do ti then AAI or NTAI or OTAI will do it for you, ro another instance of your AI or just the engine itself.
Look at AICallback::GetUnitDef() in AICallback.cpp. You'll find you're making a fuss over nothing. And eitherway any improvements you can make would ahve to be started in the spring engine not the AI.
Try and spread execution over update cycles and find more efficient ways fo doign the bgiger stuff. Eitherway you're gonna get this stuff laoded and if your AI doesnt do ti then AAI or NTAI or OTAI will do it for you, ro another instance of your AI or just the engine itself.
Look at AICallback::GetUnitDef() in AICallback.cpp. You'll find you're making a fuss over nothing. And eitherway any improvements you can make would ahve to be started in the spring engine not the AI.
ok ok, im just as i develop looking to where i can improve code speed.
and i have noted down the places where i can improve it but i still dont know if it will be that heavy until its running with all the things i want, and doing what i want.
Itll still take me time but it was just to know if that was a subject in wich i could gain code speed
and i have noted down the places where i can improve it but i still dont know if it will be that heavy until its running with all the things i want, and doing what i want.
Itll still take me time but it was just to know if that was a subject in wich i could gain code speed
Yes, that is also why I implemented a build table in JCAI with a lot of the unit properties in it, so it can read the costs and production of a unit without actually reading the FBI (Which seems to take up most of the startup time of an AI, much more than generating the metal spots with JCAI).Hmmm ok but i came up with this cuz i heard it some where that spring loads the units as it needs them, so making a getunitdef at a unused yet unit should load them and therefore take more time right ?
it seems to me that getUnitDef will use the ingame already avaiable struct for the unit, so no extra costs are involved, but dgetunitdefs will read all the fbi tag and load all the unit in the game, and this is the starting penality all ai will have for loading a complete unitdef list.
I use another approach, but I don't need all the unit def's list. If you need only the def of the thing you could build, you can read them quickly using this trick:
get the unit def of the builder (the commander at start)
get the commander buildOptions,
from that map read the string name for the unit,
get the unit def using the string unit name, using the precached defs.
when a unit is addedd, search for new defs, those will be already cached by
the game engine.
I use another approach, but I don't need all the unit def's list. If you need only the def of the thing you could build, you can read them quickly using this trick:
get the unit def of the builder (the commander at start)
get the commander buildOptions,
from that map read the string name for the unit,
get the unit def using the string unit name, using the precached defs.
when a unit is addedd, search for new defs, those will be already cached by
the game engine.
It's good practice nowadays to rely as little upon those itnerface functions as possible because they're unreliable.
Run a check on every update() possible spaced at 20 frame intervals or more, then use simple logic to derive the necessary information and make the engine calls.
A prime example of this would be the old buggy NTAI attack code versus the new AAI absed code. The AAI absed code updated its threat amtrix on Update() by using the callback itnerface, so ti had accurate information. NTAI however used the itnerface functions such as enemyenteredLOS() which meant it had totally messed up information ti could never used so ti always got error codes returned (such as 0,0,0 as many players foudn out to their horror). In an ideal situation that code should have worked but the foundations it was based on where unreliable.
The most reliable functions you can use would be Update() UnitCreated() UnitDestroyed() and UntiFinished(). Those functions can be used alogn with IAICallback* to derive all the others. UnitIdle() and UnitMoveFailed do work but they arent always called when the event occurs, hence why AI units stall.
Run a check on every update() possible spaced at 20 frame intervals or more, then use simple logic to derive the necessary information and make the engine calls.
A prime example of this would be the old buggy NTAI attack code versus the new AAI absed code. The AAI absed code updated its threat amtrix on Update() by using the callback itnerface, so ti had accurate information. NTAI however used the itnerface functions such as enemyenteredLOS() which meant it had totally messed up information ti could never used so ti always got error codes returned (such as 0,0,0 as many players foudn out to their horror). In an ideal situation that code should have worked but the foundations it was based on where unreliable.
The most reliable functions you can use would be Update() UnitCreated() UnitDestroyed() and UntiFinished(). Those functions can be used alogn with IAICallback* to derive all the others. UnitIdle() and UnitMoveFailed do work but they arent always called when the event occurs, hence why AI units stall.
