Posts made by maudlin27

v5 changes - these were mostly about the ACU, making it more aggressive and less suicidal

• Fixed various bugs and improved some error handling (see 3.18.4)
  ACU improvements (see 3.19):
• ACU will try to expand to high reclaim or mex locations, while building on mexes it comes across and reclaiming
• ACU will have scout and MAA support
• ACU tries to kite enemies it comes across
• ACU uses manual overcharge to overcharge optimal targets

Also updated the guide slightly to add details of the AI development discord channel in FAF (separate to the main AI development discord), and a couple of common hard crash errors

v4 changes (in reality v2, but when I uploaded the mod on its first release I had to rush out a couple of hotfixes where I'd forgotten to remove debug logic and accidently introduced a bug that affected all games!)

• Fixed various bugs (see 3.14.3)
• Slightly improved pathfinding performance (see 3.15)
• New AI logic which will detect enemy threats and send units to deal with them (see 3.16)
• New AI logic which attempts to maintain intel over the map to stop surprise attacks (see 3.17)

I've also updated the guide to reflect speed2's comments (as well as a couple of other minor points/sections, such as a bit on uploading a mod and some tests that I now run before uploading)

If it can be implemented without changing how high the missiles go then I’d see it as a good change. My main concern (already mentioned above by ofhers) is maps like astro craters where even a slight change in the height of a missile from a cruiser could have a dramatic balance impact (at the moment some but not all missiles can clear the astro cliffs so i expect even a small change could have a large impact in the damage cruisers could do)

I’d suggest highlighting the point about being able to join multiple queues in the news post when its released (and possibly even the game loading tooltips)-I doubt I’m the only one who assumed you could only be in one queue at a time.

@speed2
Don't think I've got that folder with the steam install, I've got the following:
C:\Program Files (x86)\Steam\steamapps\common\Supreme Commander Forged Alliance
(this doesn't have a coderecs folder, and adding one in doesnt resolve the issue)

I've also got the FAF location:
C:\ProgramData\FAForever
same issue as with the steamapps folder

(just in case I also tried the \Documents\My Games\Gas Powered Games\Supreme Commander Forged Alliance folder but no luck).

Is there anywhere else I may have missed for a steam version?

Although I'd hoped I'd got the CDs for both as well, checking I've only got the CD for the original supcom so cant try a fresh install via disc.

@speed2
Thanks, in particular for the debug window - I expect using that would've drastically cut my debugging time! I'll update for your comments in the latest version.

Unfortunately I can't get the debug window to work for me (I just get an error message) and some other people have had the same problem. Asking in the AI discord Jip thought that you need to do an install from the cd version of the game not steam but that you may know the exact procedure?

Error message below in case it helps:

Thanks, I'll reflect the correct case usage of Lua in the next version of the guide (I'll probably update it whenever I release an AI update so the two are in sync)

1. Overview 11
   1.1) AI goals 11
   1.2) Background 12
   1.3) Approach 12
2. Setup and background 13
   2.1) Lua editors 13
   2.1.1) Intellij IDEA 13
   2.2) Other guides which include a section on AI: 13
   2.2.1) General information: 13
   2.2.2) How AI in FAF works 14
   2.2.3) AI markers and how AI uses them: 15
   2.2.4) Hooking (e.g. replacing/appending existing game code) 15
   2.2.5) Creating custom scripts for Sorian AI: 15
   2.2.6) Pathfinding 15
   2.2.7) How platoons work 15
   2.3) Lua coding 16
   2.3.1) How to code in Lua 16
   2.3.2) Stand alone Lua code testing 16
   2.3.3) Lua optimisation 16
   2.3.4) Common causes of errors for non-Lua coders 16
   2.4) Debugging in FAF 17
   2.4.1) Console 17
   2.4.2) Cheats 17
   2.4.3) Log window and error messages 17
   2.4.4) Debug window and shortcuts 17
   2.4.5) Platoon names for debugging 18
   2.4.6) Fast speed 18
   2.4.7) Other shortcuts and game startup options 18
   2.5) AI development discord 19
   2.6) Core FAF Lua files 19
   2.6.1) Accessing core Lua code 19
   2.6.2) Other built in functions 20
   2.6.3) Unit blueprints 20
   2.7) Testing AI against other AI 20
   2.7.1) Simple offline testing 20
   2.7.2) Mass offline AI testing 20
   2.8) Getting started – using a simple AI template as a starting point 21
   2.9) Downloading and setting up MicroAI 21
   2.10) Giving the AI mod your own name 21
   2.11) General - Hooks, and getting the code to recognise if it’s running your AI 22
   2.12) Github 22
   2.12.1) Linking Github with a local repo via creating your own init file 23
   2.12.2) Pro Git ebook 23
   2.12.3) Git commit messages 23
   2.13) Uploading your AI to FAF 23
   2.13.1) Pre-upload checklist 23
   2.13.2) FAF rules on uploading mods 23
   2.13.3) Uploading to FAF 23
3. AI changes 24
   3.1) Build order - Changing the initial build order 24
   3.1.1) Adding/removing buildings 24
   3.1.2) Change build order based on map resource positions 24
   3.1.3) Build order conditions 25
   3.2) Build order – ACU builds without moving at start 25
   3.2.1) BaseTemplate 25
   3.3) Build factory and power to benefit from adjacency 26
   3.3.1) Record all mexes on the map, and reference this information 27
   3.3.2) Determine com start position 27
   3.3.3) Identify mexes near to start 28
   3.3.4) Hook onto the core code relating to building a structure at a location 29
   3.3.5) Call build order from custom aiBrain function, to edit how things are built 29
   3.3.6) Adjust build template based on mex location - conditions 30
   3.3.7) Adjust build template based on mex location – build location adjustment 31
   3.3.8) Build initial PGens by existing factory 31
   3.3.9) Adjacency bonus where ACU is away from start location 33
   3.3.10) Referencing unit blueprints for information such as unit size 35
   3.4) Platoons and sending engineers to reclaim 37
   3.4.1) How platoons work 37
   3.4.2) Send the first engineer on reclaim duty 42
   3.4.3) Determine where to send the engineer to reclaim 44
   3.4.4) Identifying reclaim mass value 44
   3.4.5) Find out if a location is accessible by ground: 44
   3.4.6) Mapping reclaim locations and assigning preferred location to an engineer 46
   3.4.7) Don’t send early reclaiming engi if there’s minimal starting reclaim 46
   3.4.8) Issue new reclaim command if engineer becomes idle 47
   3.4.9) Send more engineers to reclaim later (as lower priority) based on the reclaim currently on the map 47
   3.4.10) Send 5 engineers at the start to reclaim and build mexes 48
   3.4.11) Reclaiming trees when no main mass left 49
   3.5) Building and assisting hydro 49
   3.5.1) Check if hydro near start area and have engineer build hydro 49
   3.5.2) Have ACU assist engineer with hydro 50
   3.5.3) Get ACU to continue build order after hydro complete 51
   3.5.4) Subsequent build order changes 52
   3.6) Attack force composition changes and check of AI performance 52
   3.6.1) Build Moar Tanks 52
   3.7) Pre-v1: AI Progress check 52
   3.7.1) Land factory buildings and other build order refinements 53
   3.8) Raiding AI 55
   3.8.1) Raiding behaviour - overview 55
   3.8.2) Queue up move commands for mexes 55
   3.8.3) Identify mexes to target 56
   3.8.4) Locating mexes near to an existing pathing route 58
   3.8.5) Determine when raiders need new targets 59
   3.8.6) Handling complications (stuck units, move orders built on, platoon units dying) 59
   3.8.7) Change factory rally point so units are assigned orders sooner 61
   3.8.8) Making use of platoon names for debugging 63
   3.8.9) Ensure 1 land scout included in each platoon 64
   3.8.10) Use microbots before switching to tanks 64
   3.8.11) Have scouts stay with the platoon 66
   3.8.12) AI scouting, threat detection, and identifying nearby enemy units 67
   3.8.13) Attack engineers en-route: Overview 69
   3.8.14) Tracking when have reached movement points 69
   3.8.15) Determining the platoon minimum range 70
   3.8.16) Identifying nearby enemy units and assessing their threat 71
   3.8.17) Actions based on enemy threat 73
   3.8.18) Avoid attacking enemy mexes for small platoons 74
   3.8.19) Other issues – cheating, walls and min range 75
   3.8.20) Larger raiding platoons 76
   3.9) Large attack wave 77
   3.9.1) Checking when to form a large attack wave 77
   3.9.2) Generalising raider AI 77
   3.9.3) Creating separate platoon AI for the large attack force 78
   3.9.4) Run nearer to base when outnumbered 78
   3.9.5) Recalling nearby raiders to join attack force 79
   3.9.6) Updating threat assessment for ACU health and upgrades 80
   3.9.7) Don’t chase small numbers of faster units 82
   3.9.8) Switch to hunt and kill enemies once reached destination 83
   3.10) Pre-v1: AI Progress check 83
   3.10.1) Summer duel 84
   3.10.2) Theta passage 84
   3.10.3) New issues 84
   3.11) Platoon AI – Generalised approach and further enhancements 85
   3.11.1) Embracing the table 85
   3.11.2) Moving units when shots blocked by cliffs 88
   3.11.3) Anti-stuttering protection 88
   3.11.4) Large attack AI – Rally point for merged units 88
   3.11.5) Raiders assume small numbers of enemies are engis/scouts 89
   3.11.6) T1 Artillery specifically target structures, and spread-attack units 89
   3.11.7) Keep scouts at back of platoon 90
   3.11.8) Platoons with non-Seraphim T1 artillery and no tanks don’t run unless against slower enemy 91
   3.11.9) Factor in nearby platoons when faced with enemies 91
   3.11.10) More T1 arti in platoons once reached certain level of tanks 92
   3.11.11) Don’t treat AA as a direct fire unit when forming a platoon 92
   3.11.12) Build hydro where it’s far away from base 92
   3.12) Expansion bases 93
   3.12.1) Background – expansions and the main base 93
   3.12.2) Having all units treated as available for platoons 93
   3.13) Upgrade ACU with gun and attack 94
   3.13.1) How to upgrade an ACU 94
   3.13.2) Get enough energy to support guncom 94
   3.13.3) Upgrade ACU’s gun once have enough energy 95
   3.13.4) Attack with ACU once upgrade finished 96
   3.13.5) ACU overcharge 96
   3.14) V1-3 release incl AI progress check 97
   3.14.1) Performance – v1-3 of M27AI 97
   3.14.2) Issues and planned improvements from testing 97
   3.14.3) Debug issues and other bug fixes 98
   3.14.4) Attack lauched as soon as ACU gun ready 103
   3.14.5) Default attack-move direct fire units at enemy (attack-move if platoon scattered) 103
   3.14.6) Limit of 1 microbot per early raider platoon, and tank defenders 104
   3.14.7) Skip move location if are closer to the next move location than the first one 104
   3.14.8) Build more engineers if are close to overflowing mass 105
   3.14.9) Add energy storage requirements to ACU initial land factory build order 106
   3.14.10) ACU and Engineers will move near mex to build 106
   3.14.11) Other minor misc changes 108
   3.15) On demand basic pathfinding 108
   3.15.1) Revised approach 108
   3.15.2) Mex raiding path optimisations 110
   3.15.3) Useful maps for testing map based logic 110
   3.15.4) Move to build structure – check pathing 111
   3.15.5) Platoon Merge location – have it check no pathing issues in nearby segments 111
   3.16) AI Overseer - responding to enemy attacks 111
   3.16.1) Overview 111
   3.16.2) Planned initial logic 111
   3.16.3) Run overseer on AI creation 112
   3.16.4) Assigning units to defender platoons 113
   3.16.5) Recording enemy threats 114
   3.16.6) Sending units to deal with enemy threats 116
   3.16.7) Sorting a multi-dimensional table 116
   3.16.8) Disbanded units return to base 118
   3.16.9) Intercepting platoons should leave at least 1 scout when removing spare units 118
   3.16.10) Don’t remove units when in combat 119
   3.16.11) Platoon and other build conditions 119
   3.16.12) Limit number of mobile AA in an intercepting defending platoon 120
   3.16.13) Remove ACU from defender platoon once the threat is dealt with 120
   3.16.14) Don’t have ACU join a platoon if its upgrading 120
   3.16.15) Disabling sorian base manager distress logic 121
   3.17) AI Overseer – Intel and ACU managers 121
   3.17.1) Intel manager - overview 121
   3.17.2) Planned logic – 1-off 121
   3.17.3) Planned logic – recurring 122
   3.17.4) Scout localised platoon AI 123
   3.17.5) ACU manager 124
   3.18) V4 release (incl AI progress check) 125
   3.18.1) Pre-release testing checklist 126
   3.18.2) AI performance results 126
   3.18.3) Notable issues noted from performance 127
   3.18.4) Resolution of immediate issues/bugs post-release 128
   3.19) ACU –aggression, support and micro enhancements 133
   3.19.1) ACU custom platoon - overview 133
   3.19.2) ACU expansion – choice of location 134
   3.19.3) Platoon completion actions 136
   3.19.4) Expanding more than once 137
   3.19.5) Getting nearby reclaim and/or unclaimed mexes while moving 138
   3.19.6) Assisting hydro construction (reworked) 140
   3.19.7) ACU defender platoon refinements 141
   3.19.8) ACU Scout helper and general scout build order 141
   3.19.9) ACU MAA helper and general behaviour 144
   3.19.10) Air threat assessment and MAA to build (initial) 144
   3.19.11) Large platoon scout and MAA helpers 145
   3.19.12) ACU attacks independently to large attack platoon 145
   3.19.13) ACU Build order tweaks 145
   3.19.14) Aeon ACU gets both gun upgrades 146
   3.19.15) ACU retreat 146
   3.19.16) ACU kiting 146
   3.19.17) Have ACU attack-move if kiting doesn’t return any action 147
   3.19.18) Manual overcharge 147
   3.19.19) Other misc changes/refinements 151
   3.20) V5 release (incl AI progress check) 151
   3.20.1) Pre-release testing checklist 151
   3.20.2) AI performance results 151
4. Future likely planned changes 152
   4.1) AI Overseer – Other changes 152
   4.1.1) Fix AI assisters when ACU goes into water 152
   4.1.2) ACU logic when underwater – reclaiming enemies; moving to nearby land 153
   4.1.3) Update intercept location for defenders 153
   4.1.4) Limit the range of the defender logic 153
   4.1.5) Determine when an enemy threat is killed 153
   4.1.6) T2 range adjustments 153
   4.1.7) Split up a large platoon to chase small units 153
   4.1.8) Attack with all land units once ACU near enemy main base 154
   4.1.9) Point defence included in ACU threat? 154
   4.1.10) Platoon composition manager 154
   4.1.11) Air threat MAA intercept 154
   4.1.12) Performance optimisations 155
   4.1.13) Anti-stuttering logic needed? 155
   4.1.14) Interupted buildings are compelted by assisting engineers 155
   4.1.15) Intel pathing – use land based pathing 155
   4.1.16) Intel pathing – have scouts advance independently if no threats 156
   4.1.17) Initial movement path for defenders based on intel 156
   4.1.18) Platoon completion – next action based on intel coverage 156
   4.1.19) Backup logic for unforeseen errors – idle ACU 156
   4.1.20) Backup logic for unforeseen errors – idle units 157
   4.1.21) Use OnKilled to reduce enemy threat and cancel defender intercepts 157
   4.1.22) Other (TBC) 157
   4.2) More micro improvements and other enhancements 157
   4.2.1) Assist building being constructed instead of building new one 157
   4.2.2) Engineer assist AI will assist factories 157
   4.2.3) ACU and small platoons move if under attack from artillery 157
   4.2.4) ACU/General platoon target prioritisation 158
   4.2.5) Initial raider build order tweaks 158
   4.2.6) Factory builder – instance count bug 158
   4.2.7) Indirect fire units near the ACU when its upgrading? 159
   4.2.8) Attack platoons merge with larger attack platoons they come near 159
   4.2.9) Support platoon units run away from enemies nearest them 159
   4.2.10) T1 Arti composition based on PD 159
   4.2.11) Platoon merge path when attacking? 159
   4.2.12) Aeon T1 tanks kiting 159
   4.2.13) Indirect fire structure targeting 159
   4.2.14) ACU new land factory/adjacency bonus – target nearest mexes first? 160
   4.2.15) Target low health units (small platoon sizes) 160
   4.2.16) Anti-capture protection 160
   4.2.17) Advanced reclaim prioritisation 160
   4.2.18) Air factory adjacency 160
   4.2.19) Engineer management – combine to construct a single building instead of 2 separate ones 160
   4.2.20) Engineers attack-move to nearby enemies 161
   4.2.21) Improved blip threat detection 161
   4.2.22) Protecting engineers 161
   4.2.23) Saving scouts when a platoon is dying 161
   4.2.24) Replace existing construction orders if closer 161
   4.2.25) Factory adjacency location - Build land factories nearer our base if not near base 161
   4.2.26) Integrate IsShotBlocked into wider unit stuck and targeting logic 161
   4.2.27) Advanced Kiting – Com vs Com 161
   4.2.28) Overcharge further refinements 161
   4.3) Resource stall and overflow 162
   4.3.1) Mass stall – pause non-mex production 162
   4.3.2) Energy stall – pause non-PGen production 162
   4.3.3) Mass overflow – upgrade a mex 162
   4.4) T2 upgrades and anti-turtle tactics 162
   4.5) Enhanced pathfinding information – how long to path 162
   4.6) AI scouting, threat detection, and safe paths 163
   4.6.1) General discussion on scouting and threat detection 163
   4.6.2) Naval pathfinding 165
   4.6.3) Determining a safe path for raiders 166
   4.6.4) Engineer mex selection – calculating safe paths 166
   4.6.5) Basic air scouting 166
   4.7) Other enhancements 166
   4.7.1) Fix guide hyperlinks 166
   4.7.2) What to do if early hydro is destroyed 166
   4.7.3) Transports 166
   4.8) Optimisations – base game AI removal 167
   4.8.1) Consumption values 167
   4.9) Lower priority enhancements to earlier code 168
   4.9.1) Enhancements flagged earlier 168
   4.9.2) Per-unit micro to win early exchanges 168
   4.9.3) If control >50% of mexes then consider upgrading to T2 mexes and land 168
   4.9.4) Overseer and full share 168
   4.9.5) Free for all and multiple opponents 168
   4.9.6) Enemy ACU upgrade 169
   4.9.7) Improve intel pathing choice based on enemy threats 169
5. Index of useful functions 169
   5.1) Map, game setup and general aiBrain information 170
   5.1.1) aiBrain - general 170
   5.1.2) AI Brain – Economy 171
   5.1.3) Map Markers and start positions 172
   5.1.4) Map size 172
   5.1.5) Terrain info 173
   5.2) Getting a list of units by category, location, or other method 173
   5.2.1) All units that meet a particular category 173
   5.2.2) Units at/near a location 174
   5.3) Unit information 175
   5.3.1) Units on radar 175
   5.3.2) Blueprints 175
   5.3.3) Unit upgrades 176
   5.3.4) Unit’s ai Brain owner 176
   5.3.5) Whether a blueprint matches category conditions 176
   5.3.6) Location and pathfinding 176
   5.3.7) Unit’s current commands and whether it’s alive 177
   5.4) Unit and platoon commands 177
   5.4.1) Building 177
   5.4.2) Assisting 177
   5.4.3) Reclaim 177
   Note: The core AI functionality appears to run ProcessBuildCommand on a unit given an issuereclaim order (even if that unit is in a custom platoon) and will then disband that platoon (meaning less than 1 second after the reclaim order is given, the unit stops reclaim and is disbanded). 177
   One solution is to add extra code to ProcessBuildCommand to not disband the platoon is the unit is reclaiming. 178
   5.4.4) Factory specific commands 178
   5.4.5) Movement and attack-move 178
   5.4.6) Transport 178
   5.4.7) Combat related 178
   5.4.8) Stopping 179
   5.4.9) Upgrades 179
   5.4.10) Current commands and targets 179
   5.4.11) Unit status 179
   5.4.12) Change a unit’s name 181
   5.5) Platoon additional functions 181
   5.5.1) Units platoon handle 181
   5.5.2) Get AIBrain 181
   5.5.3) Get units in a platoon 181
   5.5.4) Disband 181
   5.5.5) Platoon exists 181
   5.5.6) Platoon position 181
   5.5.7) Get all platoons 181
   5.5.8) Platoon ai plan name 182
   5.5.9) Add units to a platoon 182
   5.5.10) Army pool and removing units from a platoon 182
   5.5.11) Create a platoon 182
   5.5.12) Change or reset an AI plan 182
   5.5.13) Platoon movement formation 182
   5.6) Time and thread related 182
   5.7) Other 183
   5.7.1) Visual changes – Draw Circles and Lines 183
   5.7.2) On Intel Change 184

Following the recent Supreme Computer Cup I was inspired to have a go at developing a basic AI for FAF. As I had zero experience of coding in Lua, I thought at the same time I would write down things as I learnt them to have both a guide for other people interested in getting started in developing an AI, and a dev log for the creation of my AI.

See below for a link to the current AI development guide and devlog:
https://docs.google.com/document/d/1uQlEoN-kti7G2MnhwD60uaaHwVevPNYH/edit?usp=sharing&ouid=100973959280546778272&rtpof=true&sd=true

The current AI has been uploaded as a mod, and the files can also be accessed from the below:
https://drive.google.com/drive/folders/1jnLd67CVIpBB-ulXPlJP_GSS5QPZjK0R?usp=sharing

I've copied the current overview from the guide below:

This document is intended to do 3 things at once (meaning it does none of them very well!):
• Act as a guide to people new to FAF AI development, including collating any other useful resources out there on AI development
• Be a sort of dev log of my thought process and development steps for creating my first FAF AI, with extracts of code thrown in
• Form my main ‘todo’ list for further developments of my AI
If you see any errors, or have any comments or suggestions (in particular any AI developers who read this since you’ll probably know better/easier ways of doing things than the methods I’ve chosen) let me know and I can update the guide where relevant.

If you’re here for useful resources and/or details of how to write AI and don’t care about the dev log aspect then just skip to section 2) Setup and background and section 4) Index of useful functions, and/or browse the index for points that may be of interest.

In terms of the dev log section, if you start seeing lots of yellow highlighting/square brackets you’ve reached the end of the dev log part and the start of my todo list of things I’m planning on working on next.

Latest changes (v5) summary:

v5 changes - these were mostly about the ACU, making it more aggressive and less suicidal

• Fixed various bugs and improved some error handling (see 3.18.4)
  ACU improvements (see 3.19):
• ACU will try to expand to high reclaim or mex locations, while building on mexes it comes across and reclaiming
• ACU will have scout and MAA support
• ACU tries to kite enemies it comes across
• ACU uses manual overcharge to overcharge optimal targets

Good idea. However will the map size be weighted to be similar to normal ladder, or will it be 1/3 5x5 1/3 10x10 1/3 20x20? If possible (if not already done) I'd suggest it mirror the normal map pool weighting for a particular rating bracket.

I've won with sera SACU spam a few times, but that's on astro craters. You have the build power to get AA on the fly, and can take out ground experimentals mass efficiently if your opponent doesn't micro well. However they're slow and hence vulnerable to kiting while your opponent will have plenty of time to get defences if you try and attack with them.

I essentially see them as a 'jack of all trades' type of unit. They give an eco boost, but IIRC it's about half as efficient as a RAS SACU. They've got a good DPS and mass for their cost, but are slow and have a poor range. They can give you AA, but it'll be fixed and can't handle large amounts of air at once.

They're also the only SACU that gets the TML upgrade, although so far my attempts at getting a sneaky snipe with this have failed as you need so many to punch through multiple T3 shields (and if you fail with the first launch the opponent will move their com and get more TMD).

If making such a change I'd suggest still having an e cost so power stalling costs you mass - e.g. this could just be the same as a T2 mass fab (-100 e) so it's far less proportionately while still punishing you for stalling (and meaning that if you mindlessly spam them forever you'll also end up stalling)

I found my biggest improvement (moving from c.400 rank to 800) was primarily from watching replays where i got crushed and figuring out what my opponent did. Playing more games instead wouldn’t have taught me that anywhere near as quickly.

I also found sandboxing initial strategies numerous times to both figure out what works and to memorise it was better than just starting a game and trying to think about it on the spot (as I was frequently finding i would be close to overflowing mass despite trying to build more factories early) - sandboxing and replays helped me realise i was sending my acu to the front too early and that i should get it to build more factories first.

I see this as something that could be useful not just for reclaim but more generally
e.g. instead of needing to select a group of bombers, and then shift-click on every enemy in an area before using spread-attack, you just click the 'attack area' button, click to drag over the area in question, and they will randomly target any enemy in the area (at the time the command is issued, so it's a 1-off order).

Similarly with engineers they would randomly reclaim anything in that area, and keep reclaiming until the area is cleared of reclaim.

Yeah some way of easily telling tree groups would help - I just don't bother and use attack move as I don't have the time to try and figure out what's a tree group and what isn't, but would be nice to have better information on this so if I wanted to I could try and make better use of tree groups without needing to memorise the map in question. I'd probably prefer including the mass and energy values for tree groups (but not individual trees, to avoid too much information on the overlay), or some special icon/other visual indication (that happens when activating the reclaim overlay), over 'zoom out to a particular level and you can see tree groups but not individual trees', although the zoom out option would still be better than nothing.

Tbh in any RTS game I've played, I can breeze through the campaign on hardest difficulty, then try a multiplayer match and get absolutely crushed (and I also expect to be). I don't think FAF is anything different in this regards - there's an established meta (since it's not a brand new game) and that meta is different to how you can win in the campaign.

Challenge maps/improved tutorials would still help, but it requires someone to do it (although improving the tutorials section of the client to include links to the various guides I'd like to think would be an 'easy win').

I'd prefer option 2 or option 3.
I'd also see this as having a benefit from a gameplay perspective (not just a performance perspective) because it always seemed counter-intuitive to me that an ACU which kills an experimental by itself gets only 1 rank of vet, whereas an ACU that kills some T2 tanks that are a fraction of the mass value can get multiple vet ranks easily. That said though, it's also slightly more intuitive that you gain veterancy when a unit dies rather than when you damage it, though I've seen RTS's that take either approach.

However, it would generally make veterancy more powerful, so might need some sort of slight tweak to compensate. E.g. any unit with moderate or better health that would benefit from an earlier vet would get a benefit when attacking a high health unit with a higher mass cost, such that the veterancy bonus or mass requirement might need adjusting.

Having only started following the FAF forums and news the start of this year I'd not come across the PC election before, but one thing that's surprised me is just how long the process has gone on for. To summarise the timings for the PC election that's almost now finished:

• 6 May 21 - election announced, candidates requested
• 30 May - Signups closed (includes 1 week extension to accommodate further debate following disqualification of certain candidates/clarification of conditions to apply)
• 6 June - voting begins
• 6 July - voting ends

So essentially, 3 months taken up with the PC election.

Regardless of whoever wins the current election, I'd suggest shortening this period significantly, as 1/4 of the PC's time will potentially be in 'election mode'.

I'd therefore suggest allowing 3 weeks for candidates, and then 3 weeks for voting, to halve the time involved overall, for next year's election, while still giving enough of a period to allow most people who might be on holiday at some point in that time to be able to stand and/or vote, without having the election go on for so long.

I'd also be curious if anyone has stats on the timeframe of when votes were cast, as I suspect they will be weighted significantly towards the start of the voting period (which would give further support for there not being a need for a whole month to vote). If this isn't the case and votes tend to be evenly spread over the time period (or even weighted more towards the end of the voting period) then it may still be worth retaining 4 weeks for voting.

Could you give a source for 95% of games being on gap? If I was to guess I’d have thought it closer to 20-30%, and thats counting both gap and dual gap, and ignoring 1v1 ladder

After the recent AI tournament I was inspired to have a go at experimenting with AI development to see if I could come up with anything remotely functional, and figured I'd also document some of the steps in doing it to help anyone else who is interested in starting out (assuming I make enough progress for such documentation to be of any use).

Unfortunately I feel I've failed already at a basic first hurdle, and wondered if any of the AI developers might take pity and help me out?

I thought I'd start simple, and just try and adapt an AI's initial build order. I used the MicroAI as a starting point since I understand it's intended for public use for such a purpose:
https://github.com/HardlySoftly/MicroAI

My presumption with how the AI relating to the intial build order worked from looking through the files is as follows:

• AIBaseTemplates\MicroAI.lua lists the various custom builder functions to be used by the AI, including 'MicroAICommanderBuilder'
• AI/AIBuilders/MicroBuilders.lua then sets out what each of these builder functions does. 'MicroAICommanderBuilder' is the top priority, and appears to contain the initial build order in the section beginning BuildStructures = { 'T1LandFactory', 'T1EnergyProduction', 'T1EnergyProduction', .... }

So, as a simple test to check if I was right, I changed it so the first item listed was 'T1EnergyProduction', followed by 'T1AirFactory'. However, on loading up the AI on an (offline) custom game, it would still start by building a T1 land factory.

Other changes I made seemed to have some sort of impact (e.g. to try and change the attacks the AI was sending I started messing around with the "MicroAILandBuilder" part of this file, along with the PlatoonTemplates\MicroAITemplates/lua file, which resulted in the AI massing an army of land scouts to attack with - not quite what I was after but at least a noticeable change! So I don't think the issue is with the changes I'm making failing to be reflected in the mod I then load in the offline FAF skirmish)

Searching for articles that might give some basics of how the AI works I found the below which has a section on AI scripting (in the context of custom missions) and a separate guide which gives an overview/diagram of how the AI works:
https://wiki.faforever.com/index.php?title=Mission_Scripting
https://wiki.faforever.com/index.php?title=AI_Modding
I've also been able to locate the core game files that are part of FAF (i.e. the Lua file within Supreme Commander Forged Alliance\gamedata), but I couldn't find anything else from a skim of these forums and Discord.

Is anyone able to help either with my query, or alternatively if there's any material aimed at beginners getting into FAF AI development that might explain some of the basics?

Edit: Thanks for the help everyone - now resolved the issue

Edit2: See my more recent forum post for a link to the current version of the guide:
https://forum.faforever.com/topic/2373/ai-development-guide-and-m27ai-v1-devlog