NTai XE10.1b
Moderators: hoijui, Moderators
-
1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24
XTA config is finished for both arm and core, the full shbang. about 15 hours of work here! Im going to release a series of SP missions, which use all four of the main AIs; ranging from easy (2v2 on comet, you and a KAI vs two AAIs) to medium (you + KAI vs two NTAI) to hard (you + AAI vs KAI n NTAI) and impossible (You Vs KAI, NTAI, RAI)
however, been testing them, and atm NTAI is too hungry on the system.
I dont know any techinical stuff but you could try limiting the number of commands a frame, or doubling the time between checks, or cutting out useless checks etc, because im running a top range PC and by the 25 minute mark NTAI has got the framerate to a single figure, somthing needs optimising.
In terms of how it plays, it still does not mop up the last low threat enemy units at the end of a game (mex + solar), that'll be somthing to do with how the threat system works. Units that retreat for repairs never seem to receive orders again. the commander works better in NTAI than in any mod except KAI 0.12, reclaiming attackers and retreating intelligently. the only problems remaining are;
the new reclaiming
the unintelligent attack system
laaaagg
but if you can fix the laaaagggg then its ready to go because with a good config it can still take the other AIs to school.
http://spring.unknown-files.net/file/33 ... AA_CONFIG/
it plays both sides and is complete.
what mod should I config now?
however, been testing them, and atm NTAI is too hungry on the system.
I dont know any techinical stuff but you could try limiting the number of commands a frame, or doubling the time between checks, or cutting out useless checks etc, because im running a top range PC and by the 25 minute mark NTAI has got the framerate to a single figure, somthing needs optimising.
In terms of how it plays, it still does not mop up the last low threat enemy units at the end of a game (mex + solar), that'll be somthing to do with how the threat system works. Units that retreat for repairs never seem to receive orders again. the commander works better in NTAI than in any mod except KAI 0.12, reclaiming attackers and retreating intelligently. the only problems remaining are;
the new reclaiming
the unintelligent attack system
laaaagg
but if you can fix the laaaagggg then its ready to go because with a good config it can still take the other AIs to school.
http://spring.unknown-files.net/file/33 ... AA_CONFIG/
it plays both sides and is complete.
what mod should I config now?
There's two causes of slow downs in NTai, you have to remember that because it is so flexible it also gives you enough rope to hang yourself.
The first issue is build placement, this is what makes NTai cpu hungry. Try to keep the number of construction tasks / vehicles building stuff to a manageable level if you have 20 construction vehicles all trying to build a solar for instance you will see heavy cpu usage.
The second issue is overloading the engine, I found this was largely down to retreating units, you can alleviate this by setting more base pos tags in your config, this spreads the retreated (and now useless) units around the base and stops them jamming up and overloading the engine. You can see if this is your problem because the ping time will get progressively higher...
For me the top priority is to try get the retreated units operational again, after that look at a different threat matrix or something to make the attacking a bit smarter. The problem is AF doesn't have much time so we're going to need to get some C++ skills and do some stuff to help...
The first issue is build placement, this is what makes NTai cpu hungry. Try to keep the number of construction tasks / vehicles building stuff to a manageable level if you have 20 construction vehicles all trying to build a solar for instance you will see heavy cpu usage.
The second issue is overloading the engine, I found this was largely down to retreating units, you can alleviate this by setting more base pos tags in your config, this spreads the retreated (and now useless) units around the base and stops them jamming up and overloading the engine. You can see if this is your problem because the ping time will get progressively higher...
For me the top priority is to try get the retreated units operational again, after that look at a different threat matrix or something to make the attacking a bit smarter. The problem is AF doesn't have much time so we're going to need to get some C++ skills and do some stuff to help...
Reconciling the attack system to use the new task system would be ideal, it would completely change how attacking is structured and open up a huge number of options for attack behaviours that could be reached within 5-10 lines of code in a new task.
Trepans next big set of commits includes the LuaParser class which means that TdfParser is no longer reliable as that gamedata.tdf may be a gamedata.lua
So lua is going to have to be a future dependency of NTai.
Trepans next big set of commits includes the LuaParser class which means that TdfParser is no longer reliable as that gamedata.tdf may be a gamedata.lua
So lua is going to have to be a future dependency of NTai.
-
1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24
-
1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24
I'd like to see the attack system have some sort of priority based method. Identifying targets by their efficiency, proximity to its high value units and the level of defensive cover they have.
This should cover circumstances such as a LRPC being built with little defences to cover it, an undefended fusion reactor or units attacking the NTai commander. The key to it is the speed at which the calculations are done. Obviously the more often the method is updated the higher the cpu usage so its critical how efficient this method is.
I'm not sure how difficult this would be to implement but i don't think it would be too difficult...
Another thought I had was about retreating units, currently they're set to retreat to prevent the move failed problem. I've noticed that resurrected units head straight back off into battle, would it be possible to re-initialize the unit instead of calling retreat? By this I mean consider it destroyed and re create it as if it had been resurected? this is a full blown hack but might be worth testing...
This should cover circumstances such as a LRPC being built with little defences to cover it, an undefended fusion reactor or units attacking the NTai commander. The key to it is the speed at which the calculations are done. Obviously the more often the method is updated the higher the cpu usage so its critical how efficient this method is.
I'm not sure how difficult this would be to implement but i don't think it would be too difficult...
Another thought I had was about retreating units, currently they're set to retreat to prevent the move failed problem. I've noticed that resurrected units head straight back off into battle, would it be possible to re-initialize the unit instead of calling retreat? By this I mean consider it destroyed and re create it as if it had been resurected? this is a full blown hack but might be worth testing...
possibly,
G->UnitDestroyed(unit);
G->UnitCreated(unit);
G->UnitFinished(unit);
It would be asigned to a new attack group tho so ti may just sit there for while untill the new group fills up.
Also learning values are already used for targetting, theres also hard defined targetting values but toolkit doesnt support them.
I think an Epic style demand based system for attacking might be appropriate withnumerous subsystems generating demand for a position to be attacked and modifying the values of demand.
G->UnitDestroyed(unit);
G->UnitCreated(unit);
G->UnitFinished(unit);
It would be asigned to a new attack group tho so ti may just sit there for while untill the new group fills up.
Also learning values are already used for targetting, theres also hard defined targetting values but toolkit doesnt support them.
I think an Epic style demand based system for attacking might be appropriate withnumerous subsystems generating demand for a position to be attacked and modifying the values of demand.
-
1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24
I didnt implement it because I find winforms needs a lot of nannying and it would need a lot of controls.
Hard targetting values would also quickly spiral out of control.
For a mod with 150 units, for each unit you would define 150 values.
That means at least 22,500 values to account for.
Hence why it was used in nanoblobz after argh requested hard targetting values.
Hard targetting values would also quickly spiral out of control.
For a mod with 150 units, for each unit you would define 150 values.
That means at least 22,500 values to account for.
Hence why it was used in nanoblobz after argh requested hard targetting values.
The newest NTai has tremendous exponential lag (like 30s between updates), and retarded geo builders (look at the down right builder on the map Major_Madness3.0).
Can I have a NTai.dll just like the one I had included in Kernel Panic 1.3, but compiled for Spring75b2? This one worked very well in KP.
Can I have a NTai.dll just like the one I had included in Kernel Panic 1.3, but compiled for Spring75b2? This one worked very well in KP.