Spring RTS Engine

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.

well sorry but my doughts keep coming, why is it that when i get the min wind and max wind of the map at the game start, i get 50.0 and 300.0 values respectively ???

Not sure on the first, but for the latter, check to make sure it's giving different values. Those might be the minimum values for the map. I don't know off hand the equation for wind gens, but I think they only produce a fractional value of the wind speed.

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

GetUnitDef simply returns a pointer, so there's not really any copying involved and minimal improvement gained from caching them yourself.

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 ?

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!!!

but you dont get it, my ai will be very cpu heavy.
I know it and i want to try to reduce it as much as i can, thats why it is actually important for me to know this.
Allthough i understand how important a stable and misinformation free interface is.

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.

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

The stages in our AI's I've noticed take up the most time and lag are mostly where we're doing file IO at startup.

What exactly are you planning on anyways?

lolol shhhhh secret!
as soon as it gets quite more worked out , ill come out with it
for the moment its only on test's purposes as it only builds resources.

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 ?

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).

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.

Oh well , as to mind wind question i was getting those weird values cause the wind values arent initiated at the call of GlobalAi.init().
only after that they are initiated

ok it has been brought up allready in other threads , but is it really an engine bug say in globalai.EnemyEnteredRadar(int enemy) giving a wrong enemy ? whats going on with this ?
as i do cb->GetUnitDef(enemy); i get a fancy null pointer...

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.

Hmmm but these bugs should be worked on with some speed, as ai's cant grow nice without 'em