NTai XE10.1b
Moderators: hoijui, Moderators
Oh and anyone who compiles on linux, could you send me a copy of the .so?
Also has anyone any issues using ExSAI.dll to load SAI? It should load up then in turn load SAI but use exception handling to attempt to prevent game crashes. If people are using it or want, I can make extra copies for JCAI/KAI and the other AI's
Also has anyone any issues using ExSAI.dll to load SAI? It should load up then in turn load SAI but use exception handling to attempt to prevent game crashes. If people are using it or want, I can make extra copies for JCAI/KAI and the other AI's
Linux porting
Don't know if you saw my post about the AIClasses earlier in this thread (page 17)? If you can answer that I'll send you the diffs for my linux porting for AMD64 and you can have an AMD64 .so file. If no-one else steps up, I can look at producing a 32bit .so as well on my other machine.AF wrote:Oh and anyone who compiles on linux, could you send me a copy of the .so?
If anyone else out there is working on a linux port for NTAI XE 8.0, I'd be interested in knowing what issues, if any, you have had with compiling this.
Last point - the SVN now holds NTAI XE7.5, not XE4, so it's a lot more up to date than it used to be. It also has the build trees for XE7.5. That went in a few weeks ago - I haven't looked at the logs to see who did it.
Cheers,
Toby Haynes
Fun with Factor.cpp
More questions about the source. Is Factor.cpp supposed to be in the source tarball? I noticed that #include "Factor.h" is commented out in the include.h headers and of course Factor.cpp blows major chunks without it. I'm not working with the VC projects so I'm having to feel my way around a bit.
Cheers,
Toby Haynes
Cheers,
Toby Haynes
Not all the files in the source are to be compiled, they're ust for reference or to help people.
As I said there are 2 copies of krogs metal class, one is used and compiles, the other is a raw copy extracted from the v3 downlaod which hasnt bene ported.
XE8 should compile under linux as most of the work needed to get it working underlinux was done under XE4
one in /helpers/ and one in /helpers/terrain/
The latter is v2 and is the one to be compiled. The first one(v3) in /helpers/ is not to be compiled, neither is factor.cpp/h.
Look at include.h and compile any files for which the header is included. The necessary stuff is all setup in the VS 2003 project file, and it should compile in vs 2003 if the source is extracted to the correct place withint he spring source.
Also do not compile CBitmap.cpp it's there for reference.
Of course since XE7.5 wa an estimated 5600 lines of code and XE8 is an estimated 12000 lines of code, I presume ther emay be a few linux issues there I may have overlooked with capitalisation...
As I said there are 2 copies of krogs metal class, one is used and compiles, the other is a raw copy extracted from the v3 downlaod which hasnt bene ported.
XE8 should compile under linux as most of the work needed to get it working underlinux was done under XE4
one in /helpers/ and one in /helpers/terrain/
The latter is v2 and is the one to be compiled. The first one(v3) in /helpers/ is not to be compiled, neither is factor.cpp/h.
Look at include.h and compile any files for which the header is included. The necessary stuff is all setup in the VS 2003 project file, and it should compile in vs 2003 if the source is extracted to the correct place withint he spring source.
Also do not compile CBitmap.cpp it's there for reference.
Of course since XE7.5 wa an estimated 5600 lines of code and XE8 is an estimated 12000 lines of code, I presume ther emay be a few linux issues there I may have overlooked with capitalisation...
- Lindir The Green
- Posts: 815
- Joined: 04 May 2005, 15:09
AF wrote:Lindir, my point is that the XTA buildtree is at fault here

Remember the screen of NTAI pounding OTAI with relentless attacking?
That is the Same Exact buildtree as the one in the NTAI download.
The only difference between the really great NTAI and the current broken NTAI is the NTai.dll. It used to have a very leniant anti-staller, but now its anti-staller in too strict, preventing NTAI from building advanced factories.
And so that is what I blame.
I sent you an updated buildtree anyway, though.
XE8 in that build had NO antistall algorithm.
I removed the antistall algorithm from when B_MEX,B_FACTORY_CHEAP, B_METALMAKER, and when a unitname is specified, even though you asked that the antistall algorithm be added to every part to prevent stalls.
I've posted some documentation in another thread which cotnians a bit on tags for the antistall algorithm..
I removed the antistall algorithm from when B_MEX,B_FACTORY_CHEAP, B_METALMAKER, and when a unitname is specified, even though you asked that the antistall algorithm be added to every part to prevent stalls.
I've posted some documentation in another thread which cotnians a bit on tags for the antistall algorithm..
Compiles...
Thanks to your directions I got the binary built. Now I'm troubleshooting...
I'm getting crashes (SIGSEGV) in Global::InLOS. It appears that either the position being passed down to this function is bogus or the maths in InLOS are messed up. I'm guessing the former but I don't know the codebase well enough to anticipate the answer.
Here's part of the stack:
The position looks like this:
With those x and z values, InLOS is trying to access the 1,370,867 entry in the losMap array and SIGSEGVs. What are reasonable limits for z and x in this function? I'm guessing 0<x<512 and 0<z<512 based on the allocation of 512kbytes for losMap.
Cheers,
Toby Haynes
[/list][/list]
I'm getting crashes (SIGSEGV) in Global::InLOS. It appears that either the position being passed down to this function is bogus or the maths in InLOS are messed up. I'm guessing the former but I don't know the codebase well enough to anticipate the answer.
Here's part of the stack:
Code: Select all
#0 0x00002aaab116e1d9 in Global::InLOS (this=0x254da20, pos=@0x7fffffabfe50)
at AI/Global/NTAI/Core/helper.cpp:532
#1 0x00002aaab113bbc4 in Scouter::UnitIdle (this=0x259ce60, unit=4836)
at AI/Global/NTAI/Agents/Scouter.cpp:170
#2 0x00002aaab116e149 in Global::UnitIdle (this=0x254da20, unit=4836) at AI/Global/NTAI/Core/helper.cpp:329
#3 0x00002aaab116d9a4 in CGlobalAI::UnitIdle (this=0x2022f60, unit=4836)
at AI/Global/NTAI/Core/GlobalAI.cpp:175
Code: Select all
(gdb) print pos
$1 = (float3 &) @0x7fffffabfe50: {static binder = {class_ = 0xc6ce50, base = 0x0, flags = 3,
memberRegistrator = 0xc584a8, name = 0x7593a8 "float3", size = 12, constructor = 0, destructor = 0,
nextBinder = 0xc5b5e0, static binderList = 0xaf52e0,
static classes = {<std::_Vector_base<creg::Class*,std::allocator<creg::Class*> >> = {
_M_impl = {<std::allocator<creg::Class*>> = {<__gnu_cxx::new_allocator<creg::Class*>> = {<No data fields>}, <No data fields>}, _M_start = 0xc70dc0, _M_finish = 0xc70e48,
_M_end_of_storage = 0xc70ec0}}, <No data fields>}}, static memberRegistrator = 0xc584b0, {{
x = 2148.85205, y = 0, z = 1628.60205}, xyz = {2148.85205, 0, 1628.60205}}, static maxxpos = 8191,
static maxzpos = 8191}
Cheers,
Toby Haynes
[/list][/list]
- Lindir The Green
- Posts: 815
- Joined: 04 May 2005, 15:09
That explains some stuff. I still think that there should be a very leniant anti-staller that will just block stuff that is too expensive (especially factories.) Because then in the buildtrees we can err to the side of too many factories, and trust that NTAI will correct a different amount depending on how far in-game it is and which map.AF wrote:XE8 in that build had NO antistall algorithm.
I removed the antistall algorithm from when B_MEX,B_FACTORY_CHEAP, B_METALMAKER, and when a unitname is specified, even though you asked that the antistall algorithm be added to every part to prevent stalls.
I've posted some documentation in another thread which cotnians a bit on tags for the antistall algorithm..
That's actually what I thought the antistaller already did.
Wait! Doesn't the cheap_multiplier do something like that? So the anti-staller is only present for the B_RULE stuff?
If so, sorry for all the nagging. The anti-staller doesn't need to be integrated into anything but B_RULE, if the cheap_multiplier does that. I really hope it does... plz plz plz... That would be awesome...
- Lindir The Green
- Posts: 815
- Joined: 04 May 2005, 15:09
I agree:Fanger wrote:Could I commission someone to make a buildtree thingy for my mod, as I cant seem to wrap my head around how to do it, and Im sure NTAI could preform 300% better than it does with this standard set up..
http://img506.imageshack.us/img506/2061 ... 0122jc.jpg
yellow = one very early playable version of some crappy AI ->URC
red = remains of 6 allied Ntais, 3 GD and 3 URC, in dire need for a good buildtree!
- unpossible
- Posts: 871
- Joined: 10 May 2005, 19:24
NTai <3 GD nuclear reactors :)krogothe wrote:I agree:Fanger wrote:Could I commission someone to make a buildtree thingy for my mod, as I cant seem to wrap my head around how to do it, and Im sure NTAI could preform 300% better than it does with this standard set up..
http://img506.imageshack.us/img506/2061 ... 0122jc.jpg
yellow = one very early playable version of some crappy AI ->URC
red = remains of 6 allied Ntais, 3 GD and 3 URC, in dire need for a good buildtree!
Cheap multiplier is used mainly in FACTORY_CHEAP, and I'llmake the adjustments you suggested.
I already ahve quite leniant defautl values, it multiplies the energy and metal incomes by 1.3 (30%) increase, and does the same for metal and energy stored.
Cheap multiplier works by seeing how much energy/emtal is stored. If the cost of the item is smaller than the stored resources then it says ok youcan build it else dont. The cheap multiplier is applied to the resources stored. The problem is it is possible to build without having the full cost stored in resources, which si where cheap_multiplier fails.
Your best bet is to take the antistall tags and set the incoemmultipliers to 1, and the stored multipliers to whatever value you have for cheap_multiplier and it should start workign morelike the cheap_multiplier tag.
Also XE8 under EE likes to stall metal too, I didnt have much time to buidl the EE buildtree just get it going. It worked better when it didnt have the antistall algorithms in.
XE8.1 should have a new targetting system and much better idle attacking scouting (atm they wander aimelssly in a random direction). Also predictive dgunning, and cosntruction units that either run away, orif they can do ti quicklyenough reclaim the enemy.
Also instead of just filtering out dgunning of bad things, I'm taking a slightly diffeent approach.
If no enemy weapons in range, capture
if reclaim enemy quickly then reclaim
if enemy commander reclaim
else dgun.
Also EE may find it useful to take advantage of the existing DT ring routines. the current buildtrees dotn take advantage of ti at all, even tho it's capable of creating rings similar to those placed around defences in the start up loading screens of EE. The rings are OTAI style however they've bene changed so as wella s around the starting position, smaller rings are placed around factories, and more of them in layers, such as two close rings, then 2000 ticks away 3 close rings for the starting position. Any wall structure will be placed on a ring as such...
I already ahve quite leniant defautl values, it multiplies the energy and metal incomes by 1.3 (30%) increase, and does the same for metal and energy stored.
Cheap multiplier works by seeing how much energy/emtal is stored. If the cost of the item is smaller than the stored resources then it says ok youcan build it else dont. The cheap multiplier is applied to the resources stored. The problem is it is possible to build without having the full cost stored in resources, which si where cheap_multiplier fails.
Your best bet is to take the antistall tags and set the incoemmultipliers to 1, and the stored multipliers to whatever value you have for cheap_multiplier and it should start workign morelike the cheap_multiplier tag.
Also XE8 under EE likes to stall metal too, I didnt have much time to buidl the EE buildtree just get it going. It worked better when it didnt have the antistall algorithms in.
XE8.1 should have a new targetting system and much better idle attacking scouting (atm they wander aimelssly in a random direction). Also predictive dgunning, and cosntruction units that either run away, orif they can do ti quicklyenough reclaim the enemy.
Also instead of just filtering out dgunning of bad things, I'm taking a slightly diffeent approach.
If no enemy weapons in range, capture
if reclaim enemy quickly then reclaim
if enemy commander reclaim
else dgun.
Also EE may find it useful to take advantage of the existing DT ring routines. the current buildtrees dotn take advantage of ti at all, even tho it's capable of creating rings similar to those placed around defences in the start up loading screens of EE. The rings are OTAI style however they've bene changed so as wella s around the starting position, smaller rings are placed around factories, and more of them in layers, such as two close rings, then 2000 ticks away 3 close rings for the starting position. Any wall structure will be placed on a ring as such...
- Lindir The Green
- Posts: 815
- Joined: 04 May 2005, 15:09
Which ones? Making cheap_multiplier work for everything while only using anti-stall for B_RULE? Using the anti-staller for almost everything (including unitnames)?AF wrote:Cheap multiplier is used mainly in FACTORY_CHEAP, and I'll make the adjustments you suggested.
I have suggested a myriad of conflicting adjustments, but I only currently want 1 of the 2 above, because it would allow me to control an anti-stall system that will prevent the construction of that gantry until the 2nd/3rd time around when there are enough resources.
Edit:
It seems that the cheap_multiplier is outdated, and that the anti-staller can do the same thing as it if configured correctly. So I want the antistaller used for unitnames, or if that is too much, every factory.
I could work with every factory, but I can't work with the current almost everything but unitnames, because I prefer to use unitnames for most things, even things that could cause stalling if they are built too easily.
Noticed a few bugs while playing earlier today-
Mines placed inside a factory
Plus, on wideopencombat, with 2v2 bots, only the bot in the top left had built any metal mines. Also, it seems like on a lot of maps, all the teams like sending units to gather up in the very top left corner of the map, and a lot of them will end up stuck trying to climb an impossible slope.
Dont know if any of the bugs might have been map related tho, i'm kinda a newbie to this whole spring thing.
Mines placed inside a factory
Plus, on wideopencombat, with 2v2 bots, only the bot in the top left had built any metal mines. Also, it seems like on a lot of maps, all the teams like sending units to gather up in the very top left corner of the map, and a lot of them will end up stuck trying to climb an impossible slope.
Dont know if any of the bugs might have been map related tho, i'm kinda a newbie to this whole spring thing.
mwha those bugs seem a little outdated, as if they where XE6 bugs.
the mex in the lab one ahs an explanation though.
It's part of a spring engine bug todo with open factorys and dealing with yardmaps.
I did try to get a version of the closestbuildsite() routine working in NTai so that i could make this go away, and make building placement in nanoblobz more efficient, and nonblocking mines blocking but I didnt have enough time...
However I'll attempt to fix this.
Is that an all metal map?
AA isnt exactly supported very well, but I'll look into it.
Oh and lindir, B_RULE and B_RULE_EXTREME dont quite work the way you think.
B_RULE just checks a set of rules and chooses a universal build routine accordingly.
For example say we needed power, B_RULE's pwoer rule would return true and the B_RULE would be treated as if you ahd written B_POWER in the buildtree, so there'd be no difference between that and when you had typed B_POWER.
However this is affecting more than just XTA so for now I'll make the antistall algorithm optional and have a tag to turn it on in XE8.1.
the mex in the lab one ahs an explanation though.
It's part of a spring engine bug todo with open factorys and dealing with yardmaps.
I did try to get a version of the closestbuildsite() routine working in NTai so that i could make this go away, and make building placement in nanoblobz more efficient, and nonblocking mines blocking but I didnt have enough time...
However I'll attempt to fix this.
Is that an all metal map?
AA isnt exactly supported very well, but I'll look into it.
Oh and lindir, B_RULE and B_RULE_EXTREME dont quite work the way you think.
B_RULE just checks a set of rules and chooses a universal build routine accordingly.
For example say we needed power, B_RULE's pwoer rule would return true and the B_RULE would be treated as if you ahd written B_POWER in the buildtree, so there'd be no difference between that and when you had typed B_POWER.
However this is affecting more than just XTA so for now I'll make the antistall algorithm optional and have a tag to turn it on in XE8.1.
Try it out.
I'm sending a test run of XE8.1 to lindir, after which i have only to perfect predictive dgunning then release.
AA is supported but only by consequence, nobody ahs made specific AA buildtrees, so it will play AA but it could do it 1000x better if someone made the necessary data.
Also try to make sure in multiplayer games that everyone has XE8 installed, having a copy of NTai from XE7 might bugger up the whole thing. The same for any other skirmish AI, renaming another AI to the same dll name will get spring started but I suspect it issues commands which are accepted from multiple people even though there should only be one instance of NTai
I'm sending a test run of XE8.1 to lindir, after which i have only to perfect predictive dgunning then release.
AA is supported but only by consequence, nobody ahs made specific AA buildtrees, so it will play AA but it could do it 1000x better if someone made the necessary data.
Also try to make sure in multiplayer games that everyone has XE8 installed, having a copy of NTai from XE7 might bugger up the whole thing. The same for any other skirmish AI, renaming another AI to the same dll name will get spring started but I suspect it issues commands which are accepted from multiple people even though there should only be one instance of NTai