air-ai started in fron spot (DSDR) while all the other ais staretd in the back of him. later on, the t2 airlab was build on the frontline. multiplayer games airplayer should be always in the back and airlabs in general should be build far away from frontline in a secure place.

• "hover & water" higher probability of hover factory , if map is considered as water. actually it seem that build probabilty stay always the same.

• "task priority support builder" possibility to add via config different task priorities for ressurect kbots, engineers and so on like: [0.7["repair", "build", "reclaim"]], [0.3["reclaim", "repair", "build"]] or similar system.

• "guarded expansion" constructors assigned to build mexes should be (always? => maybe configurable via [0.8]) guarded. the guarding unit (manouver) should be the next unit build after constructer and with one of following roles (skirmish, riot, raider). if there are idling groups of units somewhere they should also stay close to one of the contructors as long as they get assigned to sth else.

• "group arrangement" actually the forces are split into different groups that move seperately. raider, artillery, anti_heavy and skirmisher toghter with assaault and riot i think. actual problem is, that for example artillery and anti_heavy role units are very vulnerable for counter attacks. so these groups must be protected somehow.
  possibilities without order or exclusion of one for each other: 1. those vulnerable groups follow other skirmisher groups. 2. some units with other roles can be assigned to guard, 3. those special units stay close to own defence.

• add "random" to faction selection: not sure if this must be integrated exclusively in the lobby.

• commander task range: make it editable like [[time, range]] => [[0, 500], [120, 200], [600, 1000]... after some consideration i think time might be better than metalincome cause events on the beginning maybe easier to control with time like first incoming scouts or raiders. a event for seeing enemy should stay though

positiv:
(+) overall eco seems better than 0.58.
(+) mex expansion improved to 0.58
(+) i had the impression to see sometimes ai spready units a bit with arm kbots. tanks i didnt see it right now. improved to 0.58 but would like to see still a bit more especailly tanks were i whitnessed still some unit clusters

open issues

1. porc is still lagging behind much.
not mentionable defense in clusters at minute 30 where ai is already on 4-5k energy per second and +150m/s
=> i would wish some control over that via config somehow.

2. builders chasing units for repair
i saw arm vehicle builders (but probably happeing with core too) chasing damaged units from frontline to base to repair them. that can also cause issue nr. 1 - expansion and especially porcing lags behind.

3. Defense behaviour in own territorry
a.)slow skirmisher hunts retreat from front and try to hunt fast raiders.
sometimes big and slow skirmish groups try to hunt fast single raider units in own territory. they go back from frontline und chasing single small units that they will never get. defending single raiders sohuld be done by own fast units. ideal would be a response that produce immediately units that get especially assigned to hunt those intruders. as well as own single units (not complete skirmish groups) in vicinity should be reassigned to hunt down intruders.

b.) ai doesnt understand when base is in danger

c.) enemy raiders dont get attacked on own territory
units produced in lab head directly to front and dont care about intruders. as well as there is no adequate response to enemy raiders on own territory. ideal response against fast units raiding in own territory would be to produce own fast raiders but with a "defend own territory task"

4. eco expansion stop at a certain point
as a fact of BAR mechanics the moment were eco expansion stop is usually the moment u lose the game until the game isnt already decided or something unusual happened. ai is no exception from that rule. unfortunately with current barb eco mechanic happens exactly this in lategame: it comes to an hold

once ai cannot occupie more metal stop sooner or later it stops developing of eco because everything is in balance: buildpower - energy - metal. right now , eco wont be increased further if all mex are build and e is sufficient for buildopwer. converters are not considered atm when ai tries to build the right amout of e, it considers just buildpower via storage % .

If converters will be considered in the future it should not trigger high priority only because converter are not supplied 100% cause otherwise everything else come to on hold (base, porcupine etc.) but only low prio, medium prio if buildpower is bigger than e income and high prio if e storage is below limit. also on nanos there should no limits, they need to increase continously, but i actually dont know if that is the case. furhtermor, nanos should forced only on highest factory of each branch not on t1 anymore if there is already a t2 available. same counts for bots and t2 if there is already the t3.

Here an (maybe simplier to implement) alternative for the eco mechanics to the one above: this one is all based on storage. to make that work, its important to alter the value were converters are switched "off".
actually e stall is triggered with storage <=0.5, but converters go off with e storage around 0.7 or 0.8. that means they dont get into account cause they are switched off before.
SOLUTION: increase priority by 1 level when storage go below a value where converters are still on like 0.75 (so we have to make sure converters get switched off later around 0.65) and increse priority by another level (to high) when storage going under 0.5.

Now we have only to figure out what conditions trigger low priority for e and which condition dont call a e task at all.

actually too much constructors getting lost too easy. the actual unit guard is set on "hold position" and doing nothing until constructor is destroyed. also builders are in the front without any cover and not reacting to close enemys.

solutions:

• configurable guarding in economy.json or inside behaviour.json for each constructortype.

• constructors should react to enemy presence close to it and retreat before it gets attacked.

• contructors should prefer building in areas covered by radar.

• idle units and defending units should wait close to builders and defend it in case it gets attacked.

• lab selection before position detection when building/planning factory (1st factory UnitDef selection, then position logic)
• augmenting terrain types from 2 => 3 (or more). Water, Ambhibic, Land
• switch event per factory - different factories different time/ressources for switch event.
• better factory building logic - how to start on different mapsTerrains with different start positions and how to progress to 2nd 3rd factory and so on. what factories are necessary in certain situation which are not worth to build in other situations?
• integrating uw moho
• integrating water-nanotc in caretaker logic

i thought around how to make Barbarian choosing the right starting factory depending on the Map. Result is a concept where different step are taken to find the right solution for each possible map. some of the steps (or layers) are optional. the concept is also kind of modular which allow to include other layers/modules later on. for now the steps could be following:

1. check for air start override (optional)

2. map terrain check
   for the right strategy it is important to know which type of map the ai is dealing with. for that reason there has to be a check to categorize 4 map types that influence in the next step the build probability of certain start factories. for this its necessaryto know:

• % of land mass
• how hilly is the map. maybe checking % of terrain that cannot be reached by vehicles but only by bots. according to the values map gets categorized as hill, land, mix & water (the values that defines the categorization must be editable in a config file). so example u have:

Hill >80% landmass >20% reachability
Land >80% <20% reachability
Mix >30% <80%
Water <30%

3. metal distribution land / water
   get the metal distribution to know how much metal is under water and reachable only by ships or hovers and how much is on land. that influense the build probability in the next step of the different factories. for example if 70% of the metal is on land the build probability for land factories is multiplied by *(7/10) and water based factories by *(3/10)

4. terrain start probability
   based on step 2 the factories become here a build probability for each terrain or vice versa:
   veh bots air hover ship
   hill 0.5 1 0.5 0 0
   land 1 1 0.5 0 0
   mix 1 1 0.5 1 0
   water 0 0 0 1 1

this should be all defined in a config like "hill": [0.5, 1, 0.5 0, 0]; etc
this value gets multiplied by the value of step 3 to get the final probability for each factory

5. teamsize clamp
   teamsize clamp for air. as a fact that in most cases air is not considered to be a good starting option there should be a clamp for the amount of ais starting air in games that depends on the teamsize. also this value/lline should be in the config
   it could look like this: "teamsizeclamp_air": [0, 0, 1, 1, 1, 1, 1, 1, 2,] which is the max amount of airplayers from teamsize 1-8 and last value for everything above 8.

however, it should be possible to override/write those clamp value in certain situation (like step 1) of commander cannot expand from start position cause he is placed on a hill. or also maybe if the map is very large but amount of metal is low etc. but all this is optional and not necessary for basic functionality

I have collected a few crash logs that all indicate skirmishai as the crash source, if you have some time, would you mind looking into them, @rlcevg ?
infolog_2561.log
infolog_2562.log
infolog_2568.log
infolog_2545.log
infolog_2558.log

D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x000628FD /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/stl_vector.h:95
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x00003AC4 /home/runner/work/spring/spring/spring/AI/Skirmish/BARb/src/circuit/CircuitAI.cpp:772
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x0000B8E0 /home/runner/work/spring/spring/spring/AI/Skirmish/BARb/src/circuit/map/InfluenceMap.cpp:350
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x000014EA /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/basic_string.h:237
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\spring.exe 0x0091132B rts/ExternalAI/SkirmishAIHandler.h:172
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\spring.exe 0x00914D9C rts/ExternalAI/SkirmishAIWrapper.cpp:468
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\spring.exe 0x008EF346 rts/ExternalAI/EngineOutHandler.cpp:578
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\spring.exe 0x005350D5 /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/shared_ptr_base.h:729
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\spring.exe 0x00433965 /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/atomic_base.h:419
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\spring.exe 0x00862FAC rts/System/SpringApp.cpp:767
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\spring.exe 0x008660E0 rts/System/SpringApp.cpp:806
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\spring.exe 0x0084FBEC rts/System/Main.cpp:48
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\spring.exe 0x00F89F29 rts/System/Main.cpp:100
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\spring.exe 0x004013B4 x86_64-w64-mingw32-x86_64-w64-mingw32-crt/./mingw-w64-crt/crt/crtexe.c:341
D:\Games\Beyond-All-Reason\data\engine\105.1.1-653-g954b191 bar\spring.exe 0x004014DB x86_64-w64-mingw32-x86_64-w64-mingw32-crt/./mingw-w64-crt/crt/crtexe.c:197
C:\WINDOWS\SYSTEM32\ntdll.dll 0x00052651 ??:0

issues without specific order:

1. much more & earlier nanos on t2 and t3 needed. maybe its also possible to build a block of nanos before placing t2/t3 close to it.

2. mobils antinukes walking around the frontline and gets killed instantly. => we need kind of attribute that forces units to stay more in the back. furthemore antinukes should move into the config cause they get build without getting mentiones anywhere as far as i can see.

3. more focus on higher tier production. is there a way to do that via config (like distribution of ressources or weights)?

4. last games no air got build in 2v2. air should a more viable option as 2nd factory.

5. com should support always highest tier production instead support t1 til end of game

6. com didnt seem to cloak when under attack

I was testing 5 barbs in FFA on Pentos map as a spectator, and I selected a constructor to try and place a building (testing latest buildability updates, where you can now build into a structure if the yardmaps dont collide)

`translated for copy and paste

C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x0043D785 rts/Game/GameHelper.cpp:1265
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x0043F5A6 /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/stl_algobase.h:204
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x008B5562 rts/ExternalAI/AICallback.cpp:1104
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x008D5256 rts/ExternalAI/SSkirmishAICallbackImpl.cpp:2208
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x0023E4A3 /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/stl_vector.h:1186
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x000B30E7 /home/runner/work/spring/spring/spring/AI/Skirmish/BARb/src/circuit/terrain/TerrainManager.cpp:237
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x000B327C /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/hashtable_policy.h:729
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x00093D6D /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/std_function.h:260
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x0007B630 /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/ext/atomicity.h:53
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x000612EA /home/runner/work/spring/spring/spring/AI/Skirmish/BARb/src/circuit/script/BuilderScript.cpp:35
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x00004A6F /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/basic_string.tcc:219
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x0000B600 /home/runner/work/spring/spring/spring/AI/Skirmish/BARb/src/circuit/map/InfluenceMap.cpp:350
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\AI\Skirmish\BARb\stable\SkirmishAI.dll 0x000014EA /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/basic_string.h:237
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x008EBC0B rts/ExternalAI/SkirmishAIHandler.h:172
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x008F04A5 rts/ExternalAI/SkirmishAIWrapper.cpp:471
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x008C7781 rts/ExternalAI/EngineOutHandler.cpp:130
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x0042D248 /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/stl_vector.h:809
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x00532C33 rts/Net/NetCommands.cpp:568
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x00433C75 /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/atomic_base.h:419
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x0084010C rts/System/SpringApp.cpp:765
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x00843230 rts/System/SpringApp.cpp:804
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x0082CD5C rts/System/Main.cpp:48
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x00F256B9 rts/System/Main.cpp:100
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x004013B4 x86_64-w64-mingw32-x86_64-w64-mingw32-crt/./mingw-w64-crt/crt/crtexe.c:341
C:\Users\Peti\Documents\my games\Spring\engine\spring_bar_.BAR105.105.1.1-472-g5f11001_windows-64-minimal-portable\spring.exe 0x004014DB x86_64-w64-mingw32-x86_64-w64-mingw32-crt/./mingw-w64-crt/crt/crtexe.c:197
C:\Windows\system32\kernel32.dll 0x0001556D ??:0
C:\Windows\SYSTEM32\ntdll.dll 0x0005385D ??:0
`

some feedback based on yesterdays games:

AI too late on t2
ai does very good on t1 but suck from the moment it has to go t2. there it gets surpassed by human. only 2 of 5 ai werer going to t2 in a 40min match on delta siege dry. first one around min 23 when human tries to go around min 10-12 there. they already had all over 20 metal income and lots of metal in storage.

solution:

• lower the trigger for t2 or spread it wider (on the lower end)
• the absolut top would be when it starts a lets say teching phase were it reclaim old lab for getting additioal metal in case it is missing some.

i wonder also if it is possible in multiplayer games to let ai play sometimes with kind of teching ai-player, which maybe reclaim com to level up very early and then force economy and build t2 cons for other players which they use them too build some t2 mexes before they level up. comleting that task it should force economy again before going early to t3

The AI doesn't know how to handle Scavengers.
In the behavior fiel, I only see the Armada and Cortex units definitions so the AI doesn't plan a strategy against the Scavengers (response file) and lose everytime as they doesn't attack the Scavengers bases and specific buildings.

Also Scavengers are using the whole air land sea units while BARbarIAn build only one factory type per AI.

Could you check if you can boost the behavior of the AI against specials ennemies ?

<html><body>
<!--StartFragment-->

module | address | file | line
-- | -- | -- | --
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9  bar\AI\Skirmish\BARb\stable\SkirmishAI.dll | 0x00000000000ea300 | /spring/AI/Skirmish/BARb/src/circuit/unit/FactoryData.cpp | 243
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9  bar\AI\Skirmish\BARb\stable\SkirmishAI.dll | 0x0000000000099d29 | /spring/AI/Skirmish/BARb/src/circuit/task/builder/MexTask.cpp | 174
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9  bar\AI\Skirmish\BARb\stable\SkirmishAI.dll | 0x0000000000018a55 | /mxe/usr/lib/gcc/x86_64-w64-mingw32.static/11.2.0/include/c++/bits/stl_tree.h | 1903
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9  bar\AI\Skirmish\BARb\stable\SkirmishAI.dll | 0x000000000000797c | /mxe/usr/lib/gcc/x86_64-w64-mingw32.static/11.2.0/include/c++/streambuf | 470
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9  bar\AI\Skirmish\BARb\stable\SkirmishAI.dll | 0x000000000000d743 | /spring/AI/Skirmish/BARb/src/circuit/map/InfluenceMap.cpp | 431
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9  bar\AI\Skirmish\BARb\stable\SkirmishAI.dll | 0x00000000000023f7 | /mxe/usr/lib/gcc/x86_64-w64-mingw32.static/11.2.0/include/c++/ext/new_allocator.h | 145
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff739d3e64b | rts/ExternalAI/SkirmishAIHandler.h | 172
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff739d4457d | rts/ExternalAI/SkirmishAIWrapper.cpp | 471
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff739d1987f | rts/ExternalAI/EngineOutHandler.cpp | 113
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff739c44af5 | /mxe/usr/lib/gcc/x86_64-w64-mingw32.static/11.2.0/include/c++/sstream | 1054
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff7397a8e02 | rts/Game/Game.cpp | 468
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff7397c6a72 | rts/Game/LoadScreen.cpp | 138
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff7397c7005 | rts/Game/LoadScreen.cpp | 183
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff7397d1869 | /mxe/usr/lib/gcc/x86_64-w64-mingw32.static/11.2.0/include/c++/bits/basic_string.h | 195
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff7397d2bbd | rts/Game/PreGame.cpp | 200
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff739c6760c | rts/System/SpringApp.cpp | 806
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff739c6b178 | rts/System/SpringApp.cpp | 845
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff739c5234c | rts/System/Main.cpp | 48
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff7397713c1 | /mxe/tmp-gcc-x86_64-w64-mingw32.static/gcc-11.2.0.build_/mingw-w64-v9.0.0/mingw-w64-crt/crt/crtexe.c | 323
D:\Users\RTS\AppData\Local\Programs\Beyond-All-Reason\data\engine\105.1.1-861-ge8bf8a9 bar\spring.exe | 0x00007ff7397714d6 | /mxe/tmp-gcc-x86_64-w64-mingw32.static/gcc-11.2.0.build_/mingw-w64-v9.0.0/mingw-w64-crt/crt/crtexe.c | 178
C:\Windows\SYSTEM32\ntdll.dll | 0x000000000005a2f1 | ?? | 0

Full Infolog: https://server2.beyondallreason.info/teiserver/reports/infolog/833

As talked about for quite some time i made this card so we/Lamer can post updates or things regadering BARbarIAn improvements for eco. (or status updates)

some extended test on different maps - dsdr bigger map with some hilly terrain and 3v3 instead 2v2 revealed some interesting things.

• ai doesnt build antinuke also after it was nuked

• after nuke and with only 120e left one ai didnt build any e for 15 min but instead one adv storage after another cause it was metal overflowing. but in that case and stalling so hard e it must start building e as fast as possible from bottom to top. what it did in the end was trying to build a fusion after 15 min which obviously didnt go well after it has increased metal storage to max (around 40k). thats why i prefer a flexible priority systems that increase priority based on urgency where different triggers alter priority and.

• ai was harrased by bombers but battlefield was to large and mobile aa were everywhere but nothing to protect base structures or clusters. => response for structures and base/cluster buildings not only mobile units => force airlab for airshield with fighters. => awarness off map and fill the gaps on front? => again and again _suffix for units would help. in this case maybe a mobile unit with an _defendbase suffix and attributes that let it defend base making an even distribution on own territory.

• i whitnessed some com stutter like an inability to move on both games i played with 0.62. it last sometimes minutes

• expansion slow on dsd cause less mex densitiy and diversified terrain. partly open partly hilly. not enough drive forward in the expansion. might be good sometimes to let walk ai con in groups of 2 maybe to finish defense earlier after building mex.

• ai nor aware of terrain or poistion of enemy base etc. lots of open gaps, defenses build in the wrong direction (behind wind eg). how can we solve that? is it worth to integrate a 3rd solution for placement of structure among fix x,y or back/front etc.?
  i am thinking about a measurenet from distance to base or median of enemy territor as fix point for positioning.