Game councilor: part 1 / 3

Recently Keyser resigned as Game Councilor and last week I was approved by the board to take over. Some of you may know me as a map maker, for making trailers, for trying to improve the performance of the game or adjusting or adding in new features. I will focus my attention on the last two - and I hope we can do this together.

About us: the community

We're a self sustaining community with various contributors as our backbone. There are numerous ways one can contribute: By creating graphics for the news team, by being a personal trainer to help players out, by being a moderator to protect the community from itself - this list continues on and on. I want to take this opportunity to highlight two of them: taking part in productive discussions and testing the game or client.

Discussions

Discussions are a corner point of a thriving community. The development of the game should be no exception for these discussions. A recent example is the adjustment to the mass extractor capping feature that started with a discussion on the forums. This is the type of interaction that we should have with the community. In order to facilitate this further we're expanding our use of our Discord channel:

• A new channel '#game-updates' under 'Technical' where all updates to the develop branch / release branch are posted
• A new channel '#game-features' under 'Technical' where where all updates that can benefit from discussions are posted, including sub threads for each update to discuss the update with the community
• A new channel '#game-general' under 'Technical' where you can talk about (technical) game improvements in general

You will require the @Tester role that you can select in the #role-selection channel in order to respond to and discuss features. The same role will be used to ping when new features arise. The role is shared with client testers and announcements.

I hope with this change we can accommodate a more community-engaged game development, in particular the idea is that:

• The forums can be used to initiate a discussion on features / improvements
• Discord can be used to discuss features / improvements on an informal level with fellow community members and the game developers
• Github can be used to discuss features / improvements on a technical level with fellow game developers
• Zulip can be used to discuss features / improvements on a technical level with fellow developers of other branches, such as the client or server developers

We're going to use next week to set up the Discord channels.

These discussions should involve bug fixes, feature suggestions and performance improvements. Balance discussions have their own councilor and their own forum sections.

Testers

People that test the client or game have a direct impact to the overall experience of the community. Their work is appreciated - I'd like to use this section to highlight @WhenDayBreaks, @Emperor_Penguin, @GenevaConvention , @Tagada, @Snagglefox and everyone else who has discussed issues with me in the past that they experienced with the game.

There is a new patch coming set to release on the 26th of November. You can find the changelog on Github. Meanwhile we're trying to create a stable version of the client with various changes including an auto debugger and improvements to team matchmaking. I am asking everyone reading this to contribute - not by writing code, not by creating graphics and not by making content or managing content.

Instead contribute by giving yourself to the @Tester role on Discord, by installing the pre release / alpha client and by hosting games on the game type FAF Develop. Then report back your findings - even when they are positive and stable. You can do so in #testing-faf and #game-general on Discord respectively.

Final note

The intention was to write more about my ideas as a councilor - but time is short. I'll be writing about other changes that I intent to make in the near future including a mentorship for community members that are willing to learn about and work with the game repository for an extended time. But for now - let us enjoy this game together and report back the bugs.

Upcoming features

Some of the upcoming features, in a new format. The changelog can be difficult to read, over the next few days we'll be posting new features of the game in a friendly format.

1. Tractor beams of the Galactic Colossus

These never really did function! But soon, they will! We're working on it on Github where you can preview the working behavior via the attached video.

2. Tactical missile defenses

They've always felt a bit underwhelming - and that is because they were. They typically overkill their targets, causing them to be unreliable at best. We're working on fixing this on Github, where you can preview the working behavior via the attached video. Finally A tactical missile defense can properly counter a tactical missile launcher that fires at the same rate and takes only one strike to take down.

3. Game results

A brand new implementation on how the game results are being tracked is available on FAF Develop! Now that we have all the files in the repository we can finally properly investigate what is going on. And with that investigation an alternative system of determining the game results has been implemented. This system has already been live for about a week - as the date of merge on the pull request suggests!

I'm quite confident that this:

• Gets rid of the 'draw bug' once and for all
• Reduces the amount of 'unknown results' to practically 0

The previous implementation was a fix over a fix, over a fix, over a ... bug. While they didn't manage to tackle the core issue that showed up all over the base code, and apparently also in the game results computation. As a result, one army was sometimes not considered defeated until the next tick - the source of the draw bug. It is quite technical, I won't dive further and keep it brief.

Note that when you draw you can still lose or gain rating: the idea is that if you draw you should be of equal rating, and therefore the players 'move towards each other' rating-wise.

4. Projectiles that hit but miss

There are a lot of situations where projectiles hit (read: collide) with a unit, but they do not deal damage to that unit. This is a consequence to how the engine works: the collisions are computed at tick n, the consequences of the collisions are computed at tick n + 1. One tick later, the unit may have moved so far away that it can miss area damage, especially when the radius of the area damage is low. The full fix, along with videos can be found on Github.

To describe it visually:

A scout at maximum velocity, red marks the old damage location where as blue marks the new damage location. The collision boxes are also rendered (in blue), clearly showing that the old damage location is no longer in reach of the spy plane

Note that this primary impacts two type of situations:

• Very fast units (> 15 maximum movement speed, usually planes)
• Projectiles with a very small damage radius (< 0.5, the average land units moves at a speed of 5)

5. Range rings and performance

With thanks to @RutreD and @Kionx (who's not on the forums) another engine patch has been made and is available on FAF Develop! This patch improves the performance of range rings, with up to 20% to 50% more frame rate than before when rendering plain vision and range rings!

As an example, while having used the following console commands:

• ShowStats
• sc_VerticalSync 0
• sc_FrameTimeClamp 0

You can reproduce these results yourself - I highly encourage you to do so and report back !

Current FAF game type, looking at 500 asf: ~150 fps

Current FAF Game type, 500 selected asf: ~100 fps

Current FAF Develop game type, looking at 500 asf: ~250 fps

Current FAF Develop game type, selected 500 asf: ~150 fps

6. And a lot more - see the patch notes below!

On April the 22nd the next game patch is coming - and it is an exciting one. There are various significant improvements on the base game and critical bug fixes. You'll be able to stomp again and the game will have proper mod options support. There is improved AI tooling and a quick check for map makers to confirm everything is buildable. On top of that some of the small suggestions have been implemented and more are coming. And above all: on average the game appears to be 10% to 15% more efficient in comparison to the FAF branch. When interacting with shields the game is 600% to 700% more efficient - I dare you to compare the interaction of 5 Janus with 30 Aeon hover shields on the FAF and on the FAF Develop branch . And to finish it all up the aesthetics of the game has been improved in various areas, such as how trees interact with the game.

I'll extent this post with more information in the near future. For now, you can find the changes here on the commit log or read them up in the changelog. The latter has not been updated for two weeks.

I am asking you all to contribute by playing on FAF Develop and reporting back the stability of the branch in this topic. A positive result (in other words: it is stable) is important to report too. Attach the game log (via pastebin.com), the enabled (sim) mods and the replay id of your game when you report back.

Up to this point all my tests with AIs show that it is stable. And they show that the game is significantly faster in general. But they do not have sufficient coverage to confirm that the game type is stable for release. We got roughly a month to confirm that, and I need your help to do that .

An infographic to help you host a game using FAF Develop. Instead of using the FAF game type, select the FAF Develop game type. Note that FAF Beta is for balance changes and is the same as the FAF game type at the moment.

Improved structure terrain interactions (#4584 on Github)

Combined with the knowledge of Balthazar we managed to significantly reduce a common source of confusion and disappointment: bad terrain deformations. As you build structures the terrain was flattened underneath, with a bit of (bad) luck this could create sharp edges in the terrain that end up blocking pathing or projectiles all together.

As a few examples:

Seton's Clutch

Long John Silver

We're all too familiar with them, to the degree that it would even limit the creativity of map authors. Terrain has to be flat, or it will cause bad deformations that result in significantly worse gameplay.

But - no more! With the changes we're making to how structures interact with terrain we no longer create a flat plane that needs to be completely horizontal. Instead, we create a gradient between the four points of the build skirt and slightly orient the structure to match the gradient as required. As a result the number of bad deformations is reduced significantly, to the degree that it is really difficult to create a bad deformation.

As a few examples:

Seton's clutch

Long John Silver

This change is significant - not only does it help you as a player to just enjoy the game. It will also increase the creative possibilities for map authors as terrain no longer necessarily needs to be flat.

Significant performance improvements (#4584 on Github)

We've found one more large performance hiccup and managed to resolve it. The problem and solution is rather technical. Tthroughout the entire game you can expect 10% to 30% more performance on average, depending on what is happening.

I'll try and explain it - I've not found a way to keep it simple. Therefore I'll just write it out and make comparisons where possible.

Table trashing

The first issue was during instantiation of a table with a C reference. Instantiation means the creation (allocation) of something. And the table can reference quite literally anything:

• A damage instance: any damage in general, regardless whether it hits a unit or prop
• A decal: tread marks or the small decals we generate when projectiles hit the ground
• An effect: terrain effects, projectile trail effects, projectile impact effects, build effects - the list goes on
• A blip: the radar blips that are created for units
• A manipulator: these are applied to units for animations, and the sliding of barrels as they fire
• An entity: units, weapons, projectiles, bare entities, props, beams, trails, ...
• ..., the list goes on but we'll stick with these examples

When we create an instance they inherit functionality and data from a Class. This was done via a table called a ClassFactory, which was defined as:

ClassFactory = {
    __call = function(self, ...)
        -- create the new entity with us as its meta table
        local instance = {&1 &0}
        setmetatable(instance, self)

        -- call class initialisation functions, if they exist
        local initfn = self.__init
        if initfn then
            initfn(instance, unpack(arg))
        end
        local postinitfn = self.__post_init
        if postinitfn then
            postinitfn(instance, unpack(arg))
        end

        return instance
    end
}

The problem is at the very start:

    __call = function(self, ...) <-- note the '...'

The argument ... is called a varargs, and the idea is that it allows a function to be more flexible: you can pass any amount of data to the function and the function can then iterate over that data, as the data is stored in a table. The table is created regardless of whether there is any data to pass along. And that is exactly what the issue was: every example we just described does not use this approach to pass data to the instance. Therefore every example described has an overhead of creating a 80 byte table, just to trash it out again!

And the overhead is significant: 80 bytes sounds like nothing. But let us take a single event as an example: when a weapon fires a projectile. At this event the game creates:

• 1x manipulator: A slider to mimic recoil
• 6x effects: two effects for firing the weapon (a flash and smoke for example), two effects for the projectile itself and two impact effects
• 1x projectile
• 1x damage
• 1x decal
• 1x other things

In total, on average:

• 11x varargs table created just to trash it again

For this single event we've trashed up to 880 bytes worth of memory. The average unit fires about 1 projectile per second. That means during a battle a single unit can trash up to almost a kilobyte of memory per second! Multiply that by 200 units for the average battle and we're talking about hundreds of kilobytes of data being generated per second, just to trash it again. To put that into perspective:

• This post is about 5 kilobytes of text, at the moment of writing this sentence. We'd trash the same amount of memory when a Hoplite fires one salvo
• The average JPEG image is about 50 to 500 kilobytes. It is not unreasonable to trash as much memory as the average JPEG image per second during a relatively small battle

We can continue on - but the impact is quite significant when you take into account the garbage collector and how the CPU cache works. For example, we drastically reduce trashing the caches and increase the chance of a cache hit.

For those that like a puzzle: there are a lot of other very common events that no longer create this dummy table. Can you find some based on this information? I'll add them to a list in this post as they are found

Pre allocate tables

The second issue is about how tables grow in memory as more elements as attached to it. We'll take the example of the creation of a projectile again. When a projectile is created, we at least add the following fields to it:

OnCreate = function(self, inWater)
    -- store information to prevent engine calls
    self.Blueprint = EntityGetBlueprint(self)
    self.Army = EntityGetArmy(self)
    self.Launcher = ProjectileGetLauncher(self)
    self.Trash = TrashBag()
end,

Just like lists in C# do, a table in Lua starts with no allocated memory by default. As we add elements to the table (the self instance, in other words: the projectile) the table grows accordingly. This is done by logic similar to the following:

static void resize (lua_State *L, Table *t, int nasize, int nhsize) {
  int i;
  int oldasize = t->sizearray;
  int oldhsize = t->lsizenode;
  Node *nold;
  Node temp[1];
  if (oldhsize)
    nold = t->node;  /* save old hash ... */
  else {  /* old hash is `dummynode' */
    lua_assert(t->node == G(L)->dummynode);
    temp[0] = t->node[0];  /* copy it to `temp' */
    nold = temp;
    setnilvalue(gkey(G(L)->dummynode));  /* restate invariant */
    setnilvalue(gval(G(L)->dummynode));
    lua_assert(G(L)->dummynode->next == NULL);
  }
  if (nasize > oldasize)  /* array part must grow? */
    setarrayvector(L, t, nasize);
  /* create new hash part with appropriate size */
  setnodevector(L, t, nhsize);  
  /* re-insert elements */
  if (nasize < oldasize) {  /* array part must shrink? */
    t->sizearray = nasize;
    /* re-insert elements from vanishing slice */
    for (i=nasize; i<oldasize; i++) {
      if (!ttisnil(&t->array[i]))
        setobjt2t(luaH_setnum(L, t, i+1), &t->array[i]);
    }
    /* shrink array */
    luaM_reallocvector(L, t->array, oldasize, nasize, TObject);
  }
  /* re-insert elements in hash part */
  for (i = twoto(oldhsize) - 1; i >= 0; i--) {
    Node *old = nold+i;
    if (!ttisnil(gval(old)))
      setobjt2t(luaH_set(L, t, gkey(old)), gval(old));
  }
  if (oldhsize)
    luaM_freearray(L, nold, twoto(oldhsize), Node);  /* free old array */
}

That is a lot of code, but more importantly: it allocates new memory, re-inserts the existing elements into the new memory and prepares the old memory for deallocation! That is a relatively expensive operation, but it all depends on how often it is run. To understand that, these are the resize thresholds for the hash-based array:

Resize threshold	Resizes to	Bytes hash part occupies	Total bytes
0 or 1	2	40	80
2	4	80	120
4	8	160	200
8	16	320	360
16	32	640	680
...	...	...	...
n	2 * n	n * 20	n * 20 + 40

That means when we create a projectile we have to resize at least three times! And in practice it is four times, where as the average projectile can take up to 8 hash entries. That causes it to just resize to 16. This is something we can try and optimize in the future too.

Usually in Lua you can not pre-allocate a table. That is not normal syntax. But the GPG devs introduced that syntax in the Moho engine. And using that syntax, we can size the table as it is created. As an example, this is a special class instantiation factory for projectiles:

ProjectileFactory = {
    ---@param self any
    ---@return table
    __call = function (self)
        -- LOG(string.format("%s -> %s", "ProjectileFactory", tostring(self.__name)))
        -- needs a hash part of one for the _c_object field
        local instance = {&15 &0}
        return setmetatable(instance, self)
    end
}

Where the important line is this:

        local instance = {&15 &0}

Which states that we want to pre-allocate the hash part of the table so that it can at least hold up to 15 elements.

This same principle applies to any instance mentioned earlier, where we properly pre-allocate the table for units, shields, weapons, projectiles, damage instances, effects, decals and all the other parts of this game. We now properly pre-allocate them all, drastically reducing the frequency at which the engine ends up calling the resize function.

Control ... (#4587 on Github)

A Discord user asked in the general chat if there is an easy way to split up your selection. The answer is no - but the question is why? Why are there no tools to manage your current selection?

With this patch we're introducing a first batch of hotkeys that you can use to create subgroups of your selection, through which you can navigate. You can find them in the hotkeys menu:

All these hotkeys divide your selection over a series of subgroups. You can then use an additional hotkey (in the screenshot it is Tab) to navigate through your subgroups. We'll take two examples:

Divides a selection by the line through your mouse position and the center of the selection

Divides a selection orthogonally to the line from your mouse position to the center of the selection

These two hotkeys allows you to divide your selection into two subgroups, which you can then quickly navigate between. The command mode (when the cursor changes to issue orders, for example reclaim, ground attack, launch orders ...) are not reset as you navigate between subgroups.

With this patch we at least introduce the following divisions:

• Divide over mouse axis
• Divide over orthogonal mouse axis
• Divide over major axis
• Divide over minor axis
• Divide over tech
• Divide over layer
• Divide over tech, but only include engineers
• Divide over subgroups of size 1
• Divide over subgroups of size 2
• Divide over subgroups of size 4
• Divide over subgroups of size 8
• Divide over subgroups of size 16

We hope this provides you with more control over your selection, and therefore with more control over your army. If you have ideas of other divisions or selection manipulation: feel free to jump into the suggestions channel in Discord and we can discuss them accordingly!

... and Command! (#4577 on Github)

On top of that we are introducing various quality of life features. The first two features we'll reveal are about adding optional side effects when you issue an assist order. Specifically we're talking about these options:

The option Assist to upgrade allows you to immediately queue up the upgrade of a tech 1 mass extractor as you issue the assist order. The option Assist to Unpause allows allows you to unpause extractors and radars as your units start assisting them. The former is useful for quickly queue up (assisted) extractor upgrades. The second makes it easier to focus your build power.

As mentioned by @Brutus5000 on Discord we managed to find one cause of the excessive CPU usage by the ICE adapter when a player leaves. For more technical details:

• https://github.com/FAForever/java-ice-adapter/releases/tag/3.3.9

We do not know why this behavior suddenly started to show. But what I do know is that with thanks to @Ravandel , @Rowey , @Tagada , @Strydxr, @IndexLibrorum and Babel (Discord user) after a few hours across a few days of iterations with Brutus making changes and us testing we managed to find a solution.

We enforced the client to update to 2024.6.1. If you still experience high CPU usage of the ICE adapter then please take the time to do the following steps:

• (0) Make sure that you are indeed running version 2024.6.1 of the client.

• (1) Enable the debug window of the ICE adapter:

• (2) When the problem occurs again:

• • Take a screenshot of what is on the debug window.
• • Take a screenshot of the CPU usage in the task manager.
• • Mention your system specs, specifically the CPU.

• (3) Find the ICE adapter logs:

And then share all of that information in a new forum or Discord topic. That way we have the information we need to better understand the problem.

On the 20th December, the day after the finals of LoTS, the developers patch is due. You can find the most recent patch notes on Github. With thanks to all the people that helped with the patch in some fashion. Whether that is by developing, reviewing or testing by playing on the FAF Develop branch and reporting back.

The milestone on Github is essentially empty. Note that it says 3726 because of two additional hotfixes required for the beta patch. With that over 86 pull requests and / or issues have been tackled - and hopefully with many more to come with future patches.

At this point the FAF Develop branch is stable. Stable means that games play as expected - no crashes that alter gameplay significantly. With one more week to go I am asking you all to help test the developers branch by playing on it. In general there are only benefits: improved features, less bugs and better performance. By hosting on FAF Develop and reporting back either in this topic or in #game-testing on the official discord you can help guarantee it is as stable as possible when we release the patch. For once I'd like to release a patch with no hotfixes after the fact.

For quick-access I copied the patch notes into this post. They are not final - as an example I still need to read through them and fix typo's . You can find the most recent patch notes on Github.

Patch 3730 (23th of December, 2021)
===================================

Games using the featured mod Nomads will break when playing the Aeon 
faction until Nomads has been updated by its maintainer.

### Features
 - (#3627) Whitelist Kyro's lobby
    The file `kyros.nxt` is now white listed. If you intent to
    work on this lobby, please consider working on the lobby
    of the repository instead.

### Bug fixes
 - (#3628) Fix inconsistency with hover queue
 - (#3626) Fix issue with insignificant units and campaign levels
 - (#3625) Force recompilation of shaders due to Nomads shaders
 - (#3624) Fix highlight of selected units to drop in transport
 - (#3624) Fix template menu that allows you to rename / delete templates

### Contributors
 - 4z0t (#3624)
 - Jip (#3627, #3628, #3626, #3625)

Patch 3729 (20th of December, 2021)
===================================

### Features
 - (#3615) Happy Christmas (in advance) ^_^

### Bug fixes
 - (#3618) Fix scale of Seraphim build effects
 - (#3618) Fix issue with disconnection window for auto lobbies (ladder / tmm)
 - (#3618) Revert removed effect template for backwards compatibility with mods
 - (#3620) Add delay to ringing feature to prevent malicious intent
 - (#3621) Fix backwards compatibility with mods

### Contributors
 - 4z0t (#3615)
 - Jip (#3618, #3620, #3621)

Patch 3728 (20th of December, 2021)
============================

### Features
 - (#3484, #3500, #3535, #3600, #3604, #3610, #3611) 
    Allow more structures to be cap-able using a similar mechanic to storages for extractors.
    This changes the ringing behavior to:
    - 2 clicks + shift to mass storage an upgrading t1 extractor
    - 1 click to mass storage a t2 / t3 extractor
    - 3 clicks to shift + mass fab cap an upgrading t2 extractor
    - 2 clicks to shift + mass fab cap a t3 extractor

    - 1 clicks to mass storage a t3 fabricator
    - 1 clicks to pgen an t2 artillery
    - 2 clicks + shift to pgen an upgrading t1 radar
    - 1 clicks to pgen an t2 radar or t3 radar
    - 1 click to wall a t1 pd
   
    General rule of thumb:
    - Typical: click
    - Upgrading: shift + 2 click
    - Dangerous: shift + (regular click count + 1)

    Shift was already part of the feature and is extended to prevent unintended ringing.
    
    Assisting behavior
    - When all engineers are of the same faction, they can all build the same storage. No assisting happening.
    - When you have engineers of two or more factions, one must assist the other as they can't build the same storages.
    - When you have engineers of one faction and units that can't build the storage (kennel drones, ACU) then they must assist an engineer as they can't build the storages themselves.

    This option can be adjusted in options -> gameplay. Search for
    the field 'Automated Structure Encircling'. Options are:
    - Off
    - Only mass storages and extractors
    - Full suite

 - (#3597, #3604, #3605, #3607) Add factory queue on hover
    This allows you to get a quick overview of the factory queue by
    just hovering over the unit. Especially useful for casters as
    you can now view the factory queue without switching to the army
    in question.

    Can be adjusted in the options -> interface. Search for the 
    field 'Show Factory Queue on Hover'. Options are:
    - Off
    - Only on when observing
    - Always

 - (#3531) Add an option to scale down the UI (to 80%) for low resolution monitors
    This doesn't appear to be an issue at first due to the infinite 
    zoom but when the score board takes up 50% of your screen due to a
    1024x720 resolution then it suddenly is.

    Not all of the UI can manage this - please report issues in #game-general
    in the FAF discord when you find them.

 - (#3554) Add quick-swap feature to lobby for the host
    As a host you can quickly swap two players by
    left-clicking on the slot numbers of two players. It
    highlights to teal (light / bright blue color) when
    in swap modus. Click the highlighted slot number to
    cancel.

 - (#3616) Expands the disconnection dialog
    A host can now set a lobby option to change the
    delay required during a disconnection dialog. This defaults
    to the current behavior but can be set to 10 and 
    30 seconds.

    The exit dialog is now on top of the disconnection dialog, 
    instead of the other way around.

 - (#3602) Overhaul of the cheat spawn menu
    Adds a basic prop spawn mode. Units are spawned using the 
    command feedback on the spawn location. If spawning 
    multiple units they spawn in a box formation. Multi column 
    support and customizable in the game options. Dynamic 
    support for custom factions. Adds in a toggle for 
    revealing hidden-from-spawn-menu units

### Stability
 - (#3477) Prevent clearing critical state in AI functions
 - (#3490, #3551) Refactor the init files of the game
    This is an involved change but one that was due. 
    
    The init files can no longer load in content that clash between
    the base game files or between older versions of the same mod.
    This could also occur when the mod was not activated for sound
    and / or movie files.

    The client supports loading content from a separate vault
    location, the init files need to support this functionality
    accordingly. The init files of the game types FAF, FAF Beta
    and FAF Develop support this functionality. Other game types 
    need to be updated accordingly.

    The vault location determined by the client is used to load in
    content (maps / mods). Any other location is no longer read and
    therefore any map / mod in the other locations are not found
    by the game. If after this patch you 'lost' a few of your
    maps and / or mods it means that they were in an old vault 
    location - you'd need to move those manually.

    Adds icon support to FAF Beta.

    Adds the ability to more easily block content that is integrated.

 - (#3527) Integrate the Nvidia Fix mod and block the mod from loading
 - (#3543) Prevent applying bugs to insignificant units, like the Cybran build drone
 - (#3550) Attempt to fix Rhino from missing its target 

### Bug
 - (#3522) Fix upvalue issue of patch 3721
 - (#3486) Fix (mod) units being unbuildable due to error in UI
 - (#3432) Fix overcharge occasionally basing its damage on the previous unit it hit
 - (#3316) Fix experimentals doing death damage upon death during construction
    Monkeylord: only when fully complete as it sits
    Megalith: only when fully complete as it sits
    Colossus: when complete 50% or more
    Ythotha: when complete 50% or more

 - (#3440, #3604) Removes the dummy drone from the unit restriction list
    This drone was often misintepreted as an easy way to unrate a game. In
    contrast to what the name suggests it does have a function: to help gift
    units when a player dies and full share is on. The drone can no longer be
    restricted and instead there is a dedicated lobby option to unrate the
    game.

 - (#3525) Fix the unpathable skirts of the Seraphim Quantum Gateway
 - (#3582) Fix Aeon aim bones being underground when building
    This fixes the famous issue where an unfinished t1 pd 
    attracts a lot of fire, but because its aim bones are still
    underground all the attacking units shoot at the ground. No
    more!

 - (#3581) Fire Beetle properly applies EMP / stun buffs
 - (#3601) Fix Seraphim t3 MAA from zapping through shields
 - (#3599) Fix consumption bug introduced by #3447
 - (#3598) Fix Rhino overshooting its target.
 - (#3598, #3614) Fix errors on gifting when full share is enabled
 - (#3596, #3617) Fix typo that prevents cybran build beams from spawning
 - (#3609) Fix inconsistency with SACU presets that prevent them from having custom strategic icons
 - (#3612) Fix kennels not spawning their drone when you immediately queue up an upgrade

### Other
 - (#3480) Update visuals for the UEF T2 PD and Destroyer
 - (#3523) Switch off debug utilities by default
    This is only useful for developers, but it did cause
    a (slight) drain on resources when it was turned on
    even though you're not looking at the logs. It turns it
    off by default during each startup, you can prevent 
    this as a developer by adding
    `debug = { enable_debug_facilities = true }`
    to your preference file

 - (#3417) Add unit tests for generic utility functions
 - (#3420) Fix small issues for units of the Cybran faction.
 - (#3492) Remove greyness when deviation is high
    In combination with other work, such as combining the number of
    games people played across the board (ladder / tmm / globals)
    it should become easier for people to 'get into' custom games
    without being called a noob beforehand or a smurf afterwards (never
    played custom games, but played a lot of ladder).

 - (#3475) Fix capitalisation consistency
 - (#3443) Allow trashbag to be re-used for effects
 - (#3489) Fix UI description of teleport
 - (#3491) Fix the attack animation of the Monkeylord
 - (#3349) Updates the readme with the most recent dependencies
 - (#3461) Remove game quality computations for games with more than two teams
    The Trueskill system is not designed to compute the quality of a game 
    when more than (or less than) two teams are involved. Hence, the 
    computation is gibberish anyhow.

 - (#3526) Remove the curated maps button until an alternative is available
 - (#3528) Fix T2 seraphim sonar being restricted when t3 base spam is selected
 - (#3533) Change default settings of auto lobby to 1.5K unit cap and full share (used by ladder / team match making)
 - (#3441, #3614) Introduction of insignificant or dummy units
    This introduces a new unit class that can be used to fix
    various bugs and glitches with the game. One such issues
    is the long standing bug with the Aeon build animation where
    the aim bones are underground at the start of construction.
    
    Sadly, this change is quite involved because a lot of the
    functionality expects a full-fledged unit. We've tried to
    catch some of these but there will be more issues that will
    show up, especially with scripted maps.

 - (#3552) Update regular expression of mod version removal
 - (#3558) Restrict t2 artillery orientation to 90 degree angles
 - (#3582) Fixed various issues with the Aeon build animation
    As an example, hover units no longer jump to their hover
    elevation when they're finished. All experimentals have
    unique build animations that fit the style of the faction.

 - (#3586) Force shader re-compilation on development branches
 - (#3583) Update URLs to https instead of http
 - (#3567) Fix graphics of Summit and Fatboy
 - (#3606) Fix (build) icon of Seraphim T3 MAA
 - (#3607) Fix Cybran ACU not having the right amount of build bots when enhanced
 - (#3613) Add a hotkey to select all idle scouts

### Performance
 - (#3417) Add minor performance improvements for generic utility functions
 - (#3447) Removed old AI related code that was being run regardless of whether AIs were in-game
    This change is involved performance-wise but does not impact gameplay.

    As a practical example: chain ten engineers assisting one another and make the
    first engineer assist a factory. With these changes they'll start assisting the
    factory one by one as it takes one tick (simulation tick) to detect the unit
    it is assisting has started working on something.

    The previous behavior would be that all engineers get updated immediately. This
    required it to search for engineers in its surrounding and all those it found
    would need to look up its surroundings too. This can quickly get out of hand.

 - (#3502) Optimize the import function that is used by all files.
 - (#3512) Removes AI threat computations and fixes AI detection
    AI code was being run during every game even when no AI was present in
    said game. After discussing it with the AI devs this pull requests
    completely removes the threat computations.

 - (#3419) Reduce impact on sim of common hover emitter effects
    Effects have an impact on the sim, in particular when they create a 
    particle. Once the particles exist they appear to be free of charge. 
    With this PR we reduced the number of particles created for various 
    units such as the Aeon T1 engineer to bring them into the same cost
    range (sim wise) as the other engineers, without impacting their
    visual appearance too much. Disables the hover effects of these units
    all together when playing on low fidelity.

 - (#3557, #3617) Fix and improve performance on Seraphim build animations
    The old version had complicated logic and various
    computations that were not required. The new version is 
    better for performance and a lot more smooth with regards
    to the build animation.

 - (#3582) Prevent unneccessary allocations during the Aeon build animation
 - (#3587, #3589) Optimize most common called unit functions
 - (#3595, #3590, #3588, #3617) Optimize weapons

### Contributors
 - Askaholic (#3417, #3440)
 - Madmax (#3420, #3419, #3582)
 - Uveso (#3477)
 - Rowey (#3475, #3528, #3533, #3583, #3606)
 - Jip (#3443, #3316, #3491, #3447, #3484, #3492, #3500, 
        #3522, #3512, #3440, #3419, #3525, #3526, #3490,
        #3527, #3531, #3543, #3411, #3551, #3550, #3557
        #3558, #3582, #3581, #3587, #3589, #3601, #3600
        #3599, #3598, #3595, #3590, #3588, #3586, #3567
        #3604, #3607, #3610, #3609, #3611, #3612, #3613
        #3614, #3616, #3617)
 - KionX (#3486, #3489, #3523, #3349)
 - Crotalus (#3432)
 - Benzi-Junior (#3461)
 - Balthazar (#3552, #3602)
 - 4z0t (#3554, #3597, #3605, #3607)
 - Marlo (#3582)
 - Eternal (#3597)
 - Tagada (#3480)

### Reviewers
 - Balthazar (#3484, #3587)
 - Relent0r (#3512)

### Translators
 - Lenkin (#3440)
 - 4z0t (#3597)

Find out about the last bits and twigs for the first development iteration of the game in 2023. Everything in this topic is merged - you can experiment with these changes yourself by playing the FAF Develop game type. You can choose this game type as you host your game:

With that said, let us dive right in the latest developments!

References to all development iterations:

• Development Iteration I (this article)
• Development Iteration II
• Development Iteration III
• Development iteration IV

Game councilor: part 2 / 3

With the patches 3728 / 3729 / 3730 / 3731 behind us I think it is an ideal moment to look back and evaluate. I can't do this alone - I hope to receive your feedback in order to finalize the evaluation. Feel free to add anything in a separate post down below. Remind yourself to be constructive before posting.

Evaluation

A few things I've noted during the first few months of being game councilor.

Communication

Releasing two large updates at once is always a mistake.

As an example, the developers patch was supposed to release on the 26th of November. This was known in advance by two months as I've communicated this on the news, through the introduced dev Discord channels, through the milestones on Github* and anyone that asked me about it.

I found out one week in advance by asking the balance team that they intended to launch on the same day - even though I have been asking for weeks in advance (as early as October) what their launch date was going to be. Petric and I discussed it and they had to release now in order to make it valid for LoTS and I decided to postpone the developers patch to the 20th of December, right after LoTS. Reasoning: launching two major events at once is a mistake because they have not interacted together yet and if something goes wrong you do not know its source. And surely something did go wrong where the adjacency bug allowed for quite novel gameplay.

As another example, the developers patch was supposed to release on the 20th of December. This was known in advance by one month as I've communicated this on the forums, on the news, through the introduced dev Discord channels, through the milestones on Github* and anyone that asked me about it.

Out of nowhere 4v4 TMM was launched the Sunday evening before the patch and here I was thinking: should I launch the developers patch the day after, as I said I would? I decided to go through with it because there are new tournaments taking place early next year such as the Rainbow Cup. I need to make sure that the patch is stable for AIs and if it is not that AI devs would have sufficient time to communicate with us what was going wrong. Alas - things did go wrong as the disconnection window received an update but the default settings of the auto lobby (read: ladder) didn't get the same update. This issue wouldn't be critical as for the 1v1 and 2v2 queue the amount of connectivity issues are limited. But for the novel 4v4 queue connectivity issues are a lot more present and therefore people playing on Monday were experiencing a whole new type of ever-present disconnection window in the left top corner of their screen.

Long story short: communicating what is going to happen is key. It is frustrating for everyone involved when that doesn't happen. I've kept this to the impact on me - but the same applies to the News Team that got flanked by the last news on Sunday evening while the news set to release on Monday was essentially already finished and they were supposed to go on holiday-mode.

• Note that I'm talking about milestone 3726 that was set to the 26th of November, got moved back (to the 20th of december). The name of the milestone didn't change as 3728 (the actual patch) was already taken by another milestone.

Stability of releases

In my opinion there are three type of releases:

• (1) A stable release, no issues and no consecutive hotfixes required
• (2) A release with minor issues, a consecutive hotfix is not immediately required but it is coming
• (3) A release that is clearly broken

For all obvious reasons I aim for (1), but in practice I typically end up like (2). Even big budget companies like Ubisoft with their Game patch 13 for Anno 1800 introduces quite an amount of bugs and end up like (2) instead of (1). In my personal opinion a release like (2) is decent. However, we've also had releases like (3) in the past where the game is immediate and clearly broken - even though the issue may have been reported by a user.

Community interaction

One thing I am happy about is the amount of community interaction with the game repository. In particular having a separate channels and threads in Discord has helped a lot. There has also been more interest for the community in general. As an example, @GAS introduced the hover queue feature useful for casting and @Eternal made the UI for it.

Approach based on evaluation

A few things to change during the last few months as game councilor.

Playtest before release

To prevent a release like (3) I will refuse to release any large code base change that has not at least been played five times by the members of the team responsible. These play tests should be on various (popular) maps, including Dual Gap, Setons, the map generator and two of their own choice. The reason is simple: if something is at odds then players that often play those maps will notice. And since the people responsible for the patch are in-game playing they can immediate ponder on what changes may have done this.

I've been doing this myself for the large 3728 developers patch. As some of you can confirm - some nasty game breaking bugs were found and the wider population never got to know about them. All in all I think the 3728 developers patch was a (2) - one with only minor issues.

Better communication

In the near future I hope to finish the new readme for the game repository that is a bit more up to date. The current readme has not aged properly. As a few examples:

• I'd like to update the content of the current readme with more relevant information
• I'd like to introduce a Russian translation of the readme

I've been informing modders for the past few months to always test on the FAF Develop game type. I am going to re-iterate this in a more wider notion: if you want your mods to remain compatible with FAF then you ought to play them on the FAF Develop game type when we're asking you to do so in the news. There is a role in this for both the maintainers and users of a mod:

• As a maintainer I recommend you to always test on FAF Develop and report back the stability
• As a user, especially when the mod is unmaintained, I recommend you to play on FAF Develop when we ask you through the news and report back the stability

Informing us of the stability is not only relevant when things break. It is also relevant when things appear to be fine. That makes it easier for us to find the cause when things do break one week later. You can inform us on the official Discord server in the #game-bug-reporting channel.

As a quick example, this issue could've been prevented if someone would play BlackOps on FAF Develop when it was in the news. It was an easy fix - just a few lines.

Note that this doesn't mean that I'll suddenly fix your (ui) mods. Things that are broken right now will likely remain broken until the maintainer takes action.

Focus

With all of that said I'd like to look at what we have coming for next year.

Graphics

A 5x5 Evergreen / Tropical themed map

A 10x10 Desert themed map

Together with @CaptainKlutz we're looking into upgrading the graphics of (future) maps. I've been able to adjust the shader and embed additional information. With that we can use more advanced software such as a light mapper and have actual shadows, indirect lighting and direct lighting on our terrain. The results so far as astonishing in my opinion - and we have barely touched the surface. We could introduce biome-specific shaders with biome-specific properties.

I am actively looking for more people to participate on this journey. In particular:

• If you have an interest in PBR
• If you have an interest writing shaders
• If you have an interest in graphics in general

then you are most welcome to help tinker on or implement what the possibilities are.

The current process on this can be found in this pull request.

Documentation and accessibility

As I mentioned before - I hope to improve the documentation about the repository and the game in general (for modders). I hope to revive the climate for modders / contributors to the game repository one step at a time.

Performance

And of course - the sole reason I became Game Councilor: I hope to be able to improve the performance of the game. There are still significant opportunities - it just takes time to implement them all.

I am actively looking for more people to participate on this journey. In particular:

• If you have an interest in coding
• If you have an interest in understanding how code ticks
• If you want to make players feel bad because they have less APM during the late game

then you are most welcome to help tinker on orimplement these type of issues.

Overview

With all of that said - there are exciting times ahead of us. And I hope to share these with you - whether that is through playing the game, discussion issues and / or implementing features or fixes - we'll be doing it together.

Hi everyone. Recently I've taken on the task to optimize the FAF base game repository. Since LOUD shows it is possible - why shouldn't we do that too.

As it stands I've made a profiler to help figure out what functions are called often and how to write code that is more efficient. One approach to this is through benchmarks. See also this folder:

• https://github.com/Garanas/fa/tree/optimize-effects/lua/profiler/benchmarks

All benchmarks (with a similar name) perform the same operations, some faster than others. To give a few examples:

synthetic benchmarks

• table-insert.lua / AddInsertGlobal = 0.046 seconds
• table-insert.lua / AddCountAlt= 0.00219 seconds (the regular approach is 500% - 2000% slower (!))
• table-hash.lua / Hash01 = 0.00488
• table-hash.lua / HashCached01 = 0.00341 (the regular approach is about 10% - 30% slower)
• table-loops.lua / ForGetn = 0.2136
• table-loops.lua / ForPairs = 0.3704 (the regular approach is about 40% - 50% slower)

rewriting of existing functions

• table-hash.lua / HashCross1 = 0.08498
• table-hash.lua / HashCrossCached1 = 0.05175 (the regular approach is 30% - 40% slower)

This shows that it is possible from a theoretical perspective. I've been doing work on optimizing projectiles that you can find here:

• https://github.com/Garanas/fa/commit/2cc658ed293097ac09a3af5a0a8250e63b268d5f

When 400 Zthuee are firing at one location it takes 12 - 15 ms on the base branch, assuming you are completely zoomed out. On the optimized branch it takes 8 - 9 ms. That is a significant difference on its own - and this is just on projectiles. @CheeseBerry can confirm this - on his computer it runs about 18 - 20 ms on the base branch, where as it runs 14 - 15 ms on the optimized branch.

Up to this point I've only optimized while trying to keep the original logic alive. However, there are some things that I feel are not required for the overall game, are expensive, and can not be made cheaper. I'll use this topic to discuss these issues to get a bearing as to whether people think it is worth changing or taking out of the game.

In order to facilitate discussion each problem will have its own topic on the forum. Please remain on topic, whatever you are writing for. As it is easier for me to identify how people feel about certain changes.

And here we are - the patch is live!

The development branch has been tested thoroughly - however, as with any patch - things may leak through. Please post your findings when things break in this topic. Make sure that you include:

• The client log
• The game log
• Exception code (if available)

The changelog as described in this commit

Patch 3721 (19 September, 2021)

Lobby

• Improved visibility of balance patchnotes
• Improved CPU benchmark to take into account RAM
• Removed large map preview when map preview is hidden (map generator)
• Prevented kyros lobby from displaying spawn location when map preview is hidden (map generator)
• Fixed ACU display in large map preview
• Fixed the link for curated map button

Gameplay

• Removed reclaim rate from scoreboard mass income
• Added decals on a lot of projectiles impact and tree falling effect for aesthetics
• Added feature : preselection of mex when selection engineer and hovering the cursor over a mass spot
• Allowed battleship/battlecruiser to render their weapon reload bar
• Speed up Aeon static shields death animation to match other faction
• Added a hotkey for dock
• Made sonars more reliable to hit

Bugs

• Fixed game resulting in draw when it should not
• Fixed units doing some friendlyfire and inaccurate damage
• Fixed Cybran ACU sonar that was working without the torpedo upgrade
• Fixed unit cap display in coop
• Fixed some UI scaling issues
• Fixed game ID displayed in the scoreboard
• Fixed a warning with shield overspill function
• Fixed a bug happening when engies were not able to build
• Fixed some warnings due to lava trees missing textures
• Fixed aoe damage not working properly on build drones
• Fixed hotkey not working with Seraphim SACU in buildmode

Performance

• Optimized Cybran build effects and reduced the number of drones spawned by hives
• Code optimization related to weapons
• Call to faster function
• Improved UEF build beam logic
• Simplified Seraphim flash effect at finished structure
• Simplified UEF static shield build effect
• Optimized math calculations
• Optimized function to generate random numbers
• Optimized logic for structure rotation toward enemies (for point defenses, artillery)
• Optimized HQ logic
• Prefetch data in the lobby to speed up loading screen
• Removed unused code which aimed to rock boats
• Optimized the access to the current layer of a unit
• Optimized trashbag
• Benchmark tool for developers allowing to evaluate code impact on performances

AI

• Fixed a bug preventing AI from firing nukes from Aeon SML
• Fixed AI's ACU upgrade in coop
• Fixed arty range issues with AI
• Removed unused code for AI
• Improved description of AI code
• Fixed AI platoon function
• Fixed AI game result

Other

• Improved and more visible weather
• Added new props for maps
• Display beetle as cloaked for the owner
• Removed duplicates of adjacency visual effects
• Added field engineer icon to Cybran/Seraphim/Aeon, so it display in case they possess one.
• Updated loading tips
• Prevented observers from pinging
• Prevented sending resources to enemies
• Fixed tooltip to support experimental transporter
• Improved code style consistency
• Fixed chrono dampener and RAS description
• Removed Aquatic tag from T3 UEF Mobile Anti Air (MAA)
• Fixed the visual of several Cybran unit's weapon
• Added old patch notes changes until the version 3636
• Test code with FAF Lua language
• Better naming of T3 Mobile Anti Air (MAA) unit folders
• Small refactoring with regard to taunts
• Add textures for map generator

Contributors

• Jip
• Keyser
• Uveso
• speed2
• KionX
• Sheikah
• KeyBlue
• Relent0r
• Dragun
• Askaholic (added after the fact)
• Madmax (added after the fact)
• Tagada
• FemtoZetta
• Azraeelian Angel (added after the fact)
• Rowey
• Azraeelian Angel (added after the fact)
• Divran
• Timocov
• Melanol
• Benzi-Junior
• slinkingant
• WhenDayBreaks (added after the fact)
• Snagglefox (added after the fact)

Patch 3722 (19 September, 2021)

Lobby

• Updated balance patchnotes link

Bugs

• Fixed featured mod not working

Performances

• Optimize default explosion (on accident)

Other

• Support for custom UI icons (see this post)
• Allowed custom vault path

Contributors

• Jip
• KionX
• keyser

Patch 3723 (19 September, 2021)

Bugs

• Fixed some wrecks (colossus / ythotha) not spawning due to a typo

Contributors

• Jip
• keyser

Patch 3724 (04th October, 2021)

Gameplay

• (#3450) An alternative approach to loading in custom strategic icons (see this post)
• (#3458) Fix UEF Triad and UEF Destroyer projectile on impact animation

Bugs

• (#3442) Fix scathis packing animation time
• (#3439) Fix Cybran drone visibility for other players than the owner
• (#3450) Fix UI textures being overridden by mods that are not enabled
• (#3457) Fix Cybran drone being interactable and other small issues (with thanks to Archsimkat)
• (#3453) Fix units being gifted to the same player causing a soft-crash for the shared army mod (co-op campaign)
• (#3468) Revert changes to sending the results of games
• (#3471) Fix overcharge mouse indicator to use the right damage calculations

Stability

• (#3436) Prevent fetching blueprints for potential entities with no blueprints
• (#3449) Fix significant hard-crash potential that patch 3721 introduced (with thanks to all the debugger reports)
• (#3460) Fix potential soft-crash when gifting units upon death (with thanks to FemtoZetta)
• (#3467) Add SCD support for large icon sets (with thanks to Deribus)
• (#3472) Revert changes to some projectiles that caused them to crash for mods (with thanks to DDDX)

Other

• (#3385) Add support for custom game options being set by the server (for 3v3 / 4v4 TMM)

Contributors

• Jip (#3442, #3439, #3449, #3458, #3457, #3460, #3450, #3467, #3468, #3471)
• KionX (#3449)
• Crotalus (#3436)
• Balthazar (#3450)
• speed2 (#3453)
• Askaholic (#3385)
• BlackYps (#3385)
• keyser (#3472)

This is a sub-topic of this topic. Please keep this topic clean and only talk about this one specific issue. Balance will not be changed - it is just an aesthetical change.

This specific topic is about the Cybran build animations. This is by far the most expensive build animation of the game, yet typically the most used one because of Hives. Lets start with some numbers.

The problem

The sim runs at 10 ticks a second, therefore we have 100ms for each tick. Let us compare some engineer numbers when they are building something:

• 150 t1 Aeon engineers: The sim increases with 1 ms. (3.3 -> 4.2)
• 150 t1 UEF engineers: The sim increases with 3 - 4 ms. (2.3 -> 5.8)
• 150 t1 Cybran engineers: The sim increases with 4 ms. (2.0 -> 6.1)
• 150 t1 Seraphim engineers: The sim increases with 2 - 3 ms (3.5 -> 5.0)

That isn't too bad. Lets try with 150 t3 engineers.

• 150 t3 Aeon engineers: The sim increases with 1 ms. (3.4 -> 4.2)
• 150 t3 UEF engineers: The sim increases with 4 - 5 ms (2.2 -> 6.9)
• 150 t3 Cybran engineers: The sim increases with 10 - 11 ms (2.0 -> 12.8)
• 150 t3 Seraphim engineers: the sim increases with 4 - 5 ms (4.0 -> 8.8)

And what about hives / engineering stations.

• 150 t2 Kennel (upgraded): the sim increases with 7 - 9 ms (4.5 -> 12.2)
• 150 t2 Hives (upgraded): the sim increases with 16 - 17 ms (2.2 -> 19.1)

Some notes:

• Seraphim and Aeon engineers are more expensive by default (they start at a higher base value) because they have emitters underneath them. If those are not in vision they do not impact the sim.
• Aeon engineers are cheapest because they always have only 1 beam emitter, regardless of tech.

The reason cybran engineers tend to be more specific is for one, and only one reason: they require a large number of additional (dummy) entities. As an example:

Each hive has drone bots. These are new units made from scratch each time the hive starts building while it doesn't have any drones at all. Each drone requires a random target on the structure it is building to create a beam. Each of these targets are (dummy) entities. Therefore for one hive you need:

• 6 additional (indestructible) units
• 6 additional (dummy) entities

Then we have the effects that the hive uses.

• 6 beams from the drone to their own dummy entity.
• 6 'spark effects' at each dummy entity.
• 6 beams from the hives to the drones.

That means we introduce over 12 new entities (of which 6 are units) and 18 new emitters. As a comparison:

• Aeon introduces one entity and one emitter for each tech.
• Seraphim introduces one entity and 1 - 3 emitters, depending on the tech.

Other Cybran builders can be discussed in a similar manner - resulting in much higher entity and emitter counts than their co-workers.

A solution

The Cybran build effect is unique and I do not intent to take it out entirely as it is part of the game. However, having it in its current state can seriously slow things down especially for slower computers and laptops. (as a comparison: the computer of Cheese runs the sim almost twice as slow as my computer, by default).

What I suggest is the following:

• We limit the number of drones not on build power, but on type. All engineers will only have 1 additional drone, instead of 1 / 2 / 3 depending on the tech. All hives will have up to 1 / 2 / 3 drones, instead of 2 / 4 / 6. Commanders and sub-commanders will have 1 / 2 / 3 drones depending on their enhancements, instead of 5 / 6 when they are fully upgraded.
• We limit the number of unique targets. Instead of having each drone (and the engineer build arms) all have their own unique target, they all share the same target (as the engineers). With that we limit the number of entities (to 1 / builder) and the number of emitters (just 1 sparkle emitter / builder).
• We limit the speed at which drones switch targets. Instead of having them switch target each 0.2 seconds, we lower it to 0.5. All drones switch targets at the same time, instead of each having drone switch targets on their own (this lowers the number of threads required).

All in all - the effect will be the same when you use 10 - 20 engineers or more. But - I expect it to be a lot cheaper when you use 50 - 100 engineers (or hives). My question to you all is - what do you think, and do you think it is worth changing for the more sim speed?

disclaimer: the times are related to the performance of your processor / RAM. You will have different timings, but their differences (in %) will be roughly the same

Clarifications

The Aeon and Seraphim have a higher baseline because they have emitters underneath for a hover effect. This means that the sim has more to do. That is why they start at about 3 ms, while the uef and cybran engineers start at about 2ms.

This topic is solely about the cost of buildings things. Therefore we do not look at the baseline, but at the difference between the baseline (idle engineers) and engineers assisting something.

Identify a Problem

A unit with a jammer produces (radar) blips that are fake. These radar blips can be used to trick enemy weaponry. The radar blips disappear when you have vision over the fake radar blips.

At the moment the radar blips do not automatically respawn when you lose vision over the unit. What a lot of people do not know (including me up to a few weeks ago) is that they do respawn when you manually toggle the jamming ability on / off. They also respawn when you lose / gain power.

This is a manual interaction that is unintuitive as it is impossible for you to know whether the blips are gone or not: they are only visible to your opponents.

Showcase the Problem

The current behavior can be sandboxed using a radar, a few scouts and a few sparkies. You can switch between armies using the cheat menu. Once you've scouted the sparkies the blips disappear and they do not come back. If you disable / enable the jamming device then they are back again.

Find a Solution

We can automatically reset the jammer once the unit is out of vision. This has been suggested seven years ago:

• https://github.com/FAForever/fa/issues/968

I'll make sure that this is done such that it is responsive, but that it doesn't impacting the performance of the game.

Justify the Solution

It automates a behavior that is only possible to do manually, without knowing when you should do it.

With thanks to @phong we managed to play the first representative game on the FAF Develop branch. See also the first post. You can find the replay 19044295 in the vault.

Performance

It clearly shows the performance improvements, where we now have a new record of 1500 units + a battle being processed in 17ms, and 3000 units + a battle being processed in 40 ms.

For those unaware: the game is processed in ticks. Each tick has a 'budget' of 100ms. If we can't meet that budget, the game starts slowing down.

To put that into numbers: my computer has a Ryzen 5 3600. You can buy one of those brand new for 100 to 160 euro CPU. This relatively cheap CPU is now able to process games up to 6K units without any problems, which is where it would start slowing down the game on the current release branch.

1500 units at 17ms / tick

2900 units at 38ms / tick

Terrain deformations

There are no visible terrain deformations, even at places where there used to be factories. I'll post a few screenshots.

Air base at a slight slope

Various units at a slight slope

There used to be a full base here, but there's no trace of it when you look at the terrain

Destroyed air base at a slope, but the terrain is not deformed

Full array of SAMs with no terrain deformations whatsoever

Entire base with air grid build on a slight slope, no issues with terrain

But moreover:

• During play, nobody noticed that structures were slightly tilted
• During play, even I did not notice structures were slightly tilted

And looking at the terrain: there are basically no noticeable deformations even though entire bases got destroyed and rebuild. I'd say this is a grand success. And with a bit more tweaking for individual edge cases (like a radar) we can make it even better.

-- Control groups --

Control groups in Supreme Commander has always been a bit messy, especially when you look at how other strategy games approach it. We're streamlining their behavior, without removing the capability to have the old behavior. You can find the exact details on Github:

• https://github.com/FAForever/fa/pull/4119/files

Deprecated UI mods

The following UI mods are known to collide with these changes, and are therefore deprecated:

• group_split
• Control Group Zoom Mod
• additionalControlGroupStuff

Make a post in this thread if you think some of these features are worth keeping around and we'll discuss whether the UI mod should be re-implemented or that we can integrate the behavior into the game.

Settings

With these changes, there are three places where you can adjust the behavior. Lets go over them one by one.

• Set behavior

Triggers when you try to create a control group with your current selection. The settings allow you to 'steal' units from other control groups, or the old behavior where a unit can be part of multiple control groups

• Factory behavior

Triggers when a factory is assigned to a control group and it starts producing a unit. The settings allow you to create units that are not attached to a control group, or the old behavior where a unit inherits the control group of the factory.

• Double tap behavior

Triggers when you select a control group twice. The settings allow you to choose between a series of behaviors:

• • none: nothing happens, the behavior is disabled
• • translate-zoom: the old behavior, where the camera is translated and zoomed in / out to see the entire control group
• • translate-zoom-if-lower: the old behavior, but it does not zoom in. It only translates the camera and zooms out as required.
• • translate`: the old behavior, but it does not change the zoom at all. It only translates the camera.

These changes give you full control over what some of the UI mods implemented separately.

• Double tap decay

Allows you to define the amount of time (in miliseconds) when something is considered a double tap. Defaults to the old value (which is 2 seconds).

Hotkeys

For completeness sake I'll include all the related hotkeys. Some of these are unchanged from the old behavior.

• ['set_group1'] = '<LOC key_desc_0015>Set Group 1'

Defines the units for control group 1. Steal behavior can be adjusted using the Set behavior in the settings.

• ['group1'] = '<LOC key_desc_0004>Recall Group 1'

Recalls the control group by selecting it.

• ['revert_selection_set'] = 'Restore selection to the one before recalling a control group'

New behavior that allows you to switch back to the previous selection when you previously recalled a control group.

• ['append_group1'] = 'Append control group 1 to current selection'

The old append behavior, where the control group is added to the current selection.

• ['add_selection_to_selection_set1'] = 'Append the current selection to control group 1'

An alternative to the append behavior, that allows you to add the current selection to the control group.

• ['combine_and_select_with_selection_set1'] = 'Combine selection and control group 1 and select the control group'

An alternative to the append behavior that allows you to merge the current selection and the control group and then immediately recalls the control group.

-- Command and cursor interactions --

There are a lot of small improvements we can make to command and cursor interactions. A proof of concept was made by @Strogo in this forum post. We're now integrating the majority of his work, while refactoring how cursor interaction works from the ground up. You can find the exact details on Github:

• https://github.com/FAForever/fa/pull/4124

Deprecated UI mods

The following UI mods are known to collide with these changes, and are therefore deprecated:

• Advanced Camera Stuff (we're integrating the range rings of this mod)
• Random UI Improvements

Make a post in this thread if you think some of these features are worth keeping around and we'll discuss whether the UI mod should be re-implemented or that we can integrate the behavior into the game.

Settings

With these changes additional settings come in to help you customize the behavior to your liking. Lets go over them one by one.

• ignore mode via Ctrl

When enabled and holding (left) control, forces the game to ignore any other command but move and attack move commands. This allows you to run away without accidentally reclaiming. Or make it easier to micro your units without accidentally directly attacking another unit.

• Default selection threshold

The higher the value, the easier it becomes to select and target units or props. The value is in (screen) pixels. This can help you select individual units or props, especially on displays with higher resolutions.

Note that Interaction with units take precedence over props. When multiple entities are in range, the one nearest to the mouse location has precedence.

• Reclaim selection threshold

The same as the previous, but specifically for when you're in reclaim command mode. Makes it less tedious to reclaim by making it more difficult to miss click.

Note that Interaction with units take precedence over props. When multiple entities are in range, the one nearest to the mouse location has precedence.

• Replay selection threshold

The same as the previous, but specifically for when you're watching a replay. Should make it easier to track units while they are on the move.

Behavior changes

Issue tactical / strategical missiles

Tactical and strategical missiles can no longer target specific units or props. Instead, they always ground fire. This guarantees that they target exactly where you click. Prevents the intel bug (of 'dead structures') from causing all sorts of issues, such as your order not going through because the unit is 'dead'.

Other features

Disabled reclaim cursor

At a certain (camera) distance from the terrain you can no longer issue reclaim orders. This is now made visual by adjusting the cursor. This should improve the UX, and prevent issues such as the one described in this forum post.

-- Improved performance of reclaim labels --

The performance of reclaim labels have always been questionable. There have been many attempts at improving their performance - and finally here we are! Reclaim labels no longer have a significant performance hit on your fps. On top of that, reclaim is batched to make it easier to understand the amount of reclaim that is on top of each other. The batching is disabled the moment reclaim commands valid.

• https://github.com/FAForever/fa/pull/4232

Deprecated UI mods

The following UI mods are known to collide with these changes, and are therefore deprecated:

• Advanced Reclaim&Selection Info
• Advanced Reclaim Info
• Better Reclaim View
• disable reclaim UI
• DynamicReclaimGrouping
• EzReclaim
• OnScreenReclaimCounter
• Optimized Reclaim View
• SmartReclaimSupport

Sadly, the list is quite large. The reason for this is that apparently all the UI mods related to reclaim did not adhere to good modding practices. This is partly because the old implementation was indeed difficult to hook. We've taken this into account with the new implementation. We'll be integrating some of the features of these UI mods (such as color-tuning reclaim based on their value), but due to the amount of UI mods we can't integrate everything.

-- Recall --

A new feature that was requested by other contributors to decrease the amount of effort that it takes to close a losing game. You can now recall via the diplomacy menu. A recall is similar to 'conceding' in other games: if you and your allies decide to recall, your team is taken out of the game.

• https://github.com/FAForever/fa/pull/4203

The recall conditions are as follows:

• With a team of 2 or less players: all players need to agree
• With a team of 3 or more players: all but one player needs to agree

-- Observers can see mouse locations --

A new and unique feature to help trainers train and to help casters cast: as an observer you can view the mouse locations of the players that are playing! As a result, it is immediately clear what someone is paying attention.

• https://github.com/FAForever/fa/pull/4188

This feature does not work in replays, and it does not work when you watch a live-replay.

Looking for feedback

We're open to all feedback, but we're specifically looking for feedback on the naming and descriptions. I'm not a English native speaker so they may be a bit wonky. I'm also not able to translate to other supported languages of the game. We're very open to have these translated too.

Find out about the last bits and twigs for the third development iteration of the game! You can experiment with these changes yourself by playing the FAF Develop game type. You can choose this game type as you host your game:

For the complete history on all changes you can read up the Github history:

• Github history on development changes

The third development iteration is planned to be released on the 2nd of September. It will only contain development related changes, such as bug fixes, performance improvements and new game features.

References to all development iterations:

• Development Iteration I
• Development Iteration II
• Development Iteration III (this article)
• Development iteration IV

I'm literally working on fixing this at the moment. Let me explain to you what is happening. These are the target priorities of the Cerberus:

            TargetPriorities = {
                'EXPERIMENTAL',
                'SNIPER',
                'ANTISHIELD',
                'MOBILE TECH3 ARTILLERY',
                'MOBILE TECH2 SILO',
                'STRUCTURE SHIELD',
                'STRUCTURE TECH3 DEFENSE DIRECTFIRE',
                '(STRUCTURE * TECH2 * DEFENSE - ANTIMISSILE)',
                'MOBILE TECH1 ARTILLERY',
                'MOBILE TECH3',
                'MOBILE TECH2',
                'MOBILE TECH1',
                'COMMAND',
                '(ALLUNITS - SPECIALLOWPRI)',
            },

Note how tech 1 artillery is higher than regular tech 1 units. That means that if previously only regular tech 1 was in range, but then suddenly a tech 1 artillery is then it will retarget.

Watch my ACU drop from min 11 onward. You will notice early on the T2PD seemed to be fine. Near 11:40 onwards you notice a few time the PD wiggles between targets (losing firing time) then seems to settle down to normal behavior.

The white line represents your intel range. Anything beyond it are blips, and therefore they have the lowest priority. The tech 1 artillery get into vision one by one, causing the Cerberus to go from a t1 artillery, to a tank, to a t1 artillery, to a tank, as the blips get into vision range. As the majority of tanks are to the west, the Cerberus aims all the way to the west, just to aim somewhere north again as the artillery are identified (they're no longer blips).

Then at 12:10 or so you will see PD randomly stop shooting upwards (at fervors, a good target), rotate 150 degrees down and left to shoot at some aurora, then rotate back up to shoot at the fervors that never left range(while getting crushed by the fervor)

Same situation as before - you simply didn't had the intel on them. Blips have the lowest priority as the game literally doesn't know what they are.

The worse offense was at Min 14:30, the T2 PD just... stop shooting. You see this start when an engi enters range and the PD does not fire. It just continues from there. Fervors enter range, no pew pew. Targets are in radar range, power is on, no pew pew. Fervors start to kill my shit... no pew pew.

Ironically, it is the intel that made them ignore other targets. Weapons have a tracking radius that allows them to prepare for higher value targets. This is useful on mobile units, as you're likely moving towards your target. This is broken on static structures, as the turret can't move.

The green circle is the tracking radius (it is 15% on a Cerberus) and if you look at the priority table then tech 2 mobile silo's (mobile missile launchers) have one of the highest priorities. As such, the turrets prepare to fire onto them but by all means they never get in range.

All of this will be fixed on FAF Develop within a week, and released in roughly two weeks to the main branch.

Identify a problem

Tech 3 air dominates the air scene, especially when a map has a dedicated air slot. For the majority of maps and players it makes the previous air stages completely obsolete due to the oppressive nature of Air Superiority Fighters (ASF).

The issue that I'd like to tackle is that this starts at about minute 10 - 12. And once it starts it is a self-fulfilling prophecy because of how adjacency tears down the costs of producing ASF.

Showcase the problem

Look up any replay, it doesn't really matter what map it is. Once ASF are on the battlefield any previous stage is essentially worthless if your opponent is capable of managing its ASF properly.

Find a solution

My proposition to the situation is to naturally delay the production of tech 3 air units, while at the same time making it more difficult to continuously produce them.

(1) Increase build time of tech 3 air factories

• Tech 3 HQ: from 10400 to 12000
• Tech 3 support: from 3400 to 5000

A natural reduction to slow down the first and subsequent tech 3 air units by forcing the player to produce more build power.

(2) Increase the energy cost of tech 3 air factories

• Tech 3 HQ: from 99400 to 120000
• Tech 3 support: from 40000 to 50000

A natural reduction to slow down the first tech 3 air unit by forcing the air player to produce more initial power.

(3) Decrease efficiency of assisting air factories

Push the build rate of tech 3 air factories from 120 to 150, which is a 25% increase. Accordingly increase the build time of tech 3 (and experimental) air units by 25% too. This discourages assisting air factories, a natural reduction to slow down the first tech 3 air unit and subsequent air units.

(4) Decrease adjacency efficiency of tech 2 and tech 3 power generators

• Tech 2: from 0.125 to 0.1
• Tech 3: from 0.1875 to 0.125

At the moment an air grid decreases the energy costs of an ASF by up to 75% when the air factory is fully capped with tech 3 power generators. That is an absurd amount. With these changes the energy costs of an ASF is reduced by up to 50%.

(5) Increase build time and mass cost while decreasing damage and hit points of SAMs

• Build time: 1195 -> 1300
• Mass cost: 800 -> 950
• Damage: 1200 -> 1000
• Hitpoints: 7000 -> 6000

SAMs are extremely oppressive since we fixed splash damage from 'missing'. And even more so against tech 2 air units as they tend to take out a tech 2 air unit in one salvo. With these changes:

• All tech 2 fighter / bombers can survive 1 salvo by default
• All tech 3 spy planes except for Cybran can survive 1 salvo by default

Justify the solution

With these changes we delay the tech 3 air scene, and by doing so give more room for the tech 1 and tech 2 air scene to thrive. We do so without adjusting the statistics of mobile units, and therefore the balance changes do not impact how a battle situation is perceived by the player. But we do give room for more variance in the type of situations the player can encounter.

You can find out about all the other changes for this development iteration by reviewing the milestone on Github.

# Game version 3751 (25th of February, 2022)

In this first development update of 2023, we introduce three month's work of bugfixes, quality of life changes, and assorted improvements. It is, by far, the most exciting patch we've released so far. While the full changes are detailed below, a quick summary of those changes we think you'll find most important:

- We've changed how structures interact with the terrain. Previously, structures built on uneven ground could create terrain deformations. On some maps, this resulted in changes to the terrain that prevented the player from placing neighboring structures and created pathing issues for units. With this update, buildings deform the terrain less and may be placed at a slight angle. 

- We've introduced a new series of hotkeys that will make it easier to select and micromanage your units. 

- The process of managing your mex upgrades will now be easier than ever thanks to several small features. You can now choose to have mexes automatically queue an upgrade and (un)pause extractors when you order engineers to assist them.

- Several smaller quality of life changes have been made to existing features, such as no more empty reclaim orders and preventing ground attack orders from snapping to props or units. You can read more about all these changes in the 'Features' section.

In future updates, we'll be shifting our focus to improving the AI we ship with FAF. So far, we've been working on a navigational mesh that can help the AI understand any map you throw at it. The task ahead is to extend this with additional features to help the AI understand specifics about a map. You can read what we've achieved this patch in the 'AI' and 'Navigational mesh' sections.

And last, but certainly not least: this patch contains the largest performance improvement to date; the game is on average 10% to 20% faster in comparison to the last developers patch! This is exciting because with this patch the average game no longer slows down. We've been running tests and a CPU as cheap as a Ryzen 3600 can now run up to 6000 units without slowing down. We find this is extremely exciting: the game is nearing the point where you can just enjoy playing the originally intended experience in real-time!

With appreciation towards all the contributors that made this patch possible,

Jip

## Features

- (#4584, #4607, #4615, #4636, #4714, #4724) Improve terrain structure interactions
    Instead of flattening the ground below structures, they now slightly tilt to reduce terrain deformation.

- (#4474) Ground attack now ignores all props/units
    You can now assign a ground attack exactly where you clicked without it accidentally snapping to props or units

- (3e34599) Prevent being able to issue 'empty' reclaim orders
    It is now impossible to create a reclaim order with no prop or unit attached to it

- (#4474) Move command mode no longer creates patrol orders by accident
    When you specifically issue move commands using the hotkey (usually 'm') or by clicking on the move command button it now ignores the 'convert to patrol' functionality

- (3e34599) Remove the use of CTRL to issue commands with formations
    When you hold control units first move towards each other and create a formation before they would go to where you told them to. This is a hidden feature of the engine and often players were not aware. We patched this out because often people use the same key for hotkeys, after which players (usually accidentally) would issue a formation order instead of a regular move or attack move order

- (#4510) Add a game option to set the zoom threshold at which reclaim values are grouped together in the reclaim-overlay

- (#4586) Add game option to tweak the camera shake multiplier
    When set to zero it will entirely remove shaking from the game. Additionally, the default shake multiplier is now set to 0.5 (instead of 1.0)

- (#4577) Add game option to upgrade and pause tech 1 extractors when you issue an assist order
    A small quality of life feature that reduces the use of a few hotkeys

- (#4577, #4620) Add game option to unpause tech 1 extractors as engineers start assisting
    A small quality of life feature that reduces the need to check up on your extractors

- (#4587) Add hotkeys to divide your current selection into subgroups
    There is a separate hotkey to tab through the subgroups. This feature significantly improves your ability to manage and micro larger chunks of units

    As a few examples of divisions:
     - Divide your selection by tech level
     - Divide your selection into groups of 5
     - Divide your selection over those nearest and furthest from your mouse location
     - Divide your selection into two equally sized groups

    For UI mod authors: the changes introduces a framework that allows you to define additional ways to split a selection into subgroups.

- (#4626) Allow mass storages to be built underwater

- (#4490) Add mission briefings to the lobby for all campaigns that ship with Supreme Commander
    When you are in a co-op lobby the patch notes button is replaced with a briefings button. There you can see the briefing of a map. Only original campaign maps support this feature at the moment.

- (#4689, #4690, #4691) Add hotkey that resembles the 'hard move' functionality introduced by Strogo
    For those unware: it allows you to continiously issue move orders without queueing them and without accidentally converting them to patrol orders. This is particularly useful for ASF battles

- (#4095) Adds a partial share game option
    An alternative variant of full share. While structures and engineers are transferred, all other mobile units are lost.

- (#4463) Add a new key binding to select naval units, excluding sonar structures

## AI

This update adresses several long-standing issues that affected the custom AI that FAF introduces. Further developments and improvements of the AI will remain our focus in future updates.

Additionally, we would like to remind people that there are various mods that provide different AI experiences. We can highly recommend you to download them from the vault and give them a spin too.

A short list of AIs we recommend at this point:

- M27: made by Maudlin
- RNGAI, as made by Relent0r
- Sorian Edit, as made by Marlo
- Uveso AI, as made by Uveso
- Dilli Dally, as made by Softles
- Swarm AI, as made by Azraeel

And not to forget the AI that ships with the Total Annihilation mod that is maintained by Dragun.

- (#4413, #4419, #4450)  Tunes the economic assesments of the AI.
    Throughout the game the AI constantly tries to balance his decisions and those decisions depend on various conditions. These conditions can be tweaked and that is exactly what we did here.

- (#4445, #4447, #4455, #4462, #4461, #4460, #4454, #4475, #4505)
    General tuning and bug fixing of the AIs. This involves all sorts of improvements, such as fixing a bug causing the AI to hoard units in their base and improving their use of naval units.

- (#4386) Separately keep track of radar structures for AIs
    These are interesting and often vulnerable targets for the AI. By keeping track of them separately it can interact with them more easily.

    Better guard those radars from now on!

- (#4412) Add logic to prevent prematurely disbanding a platoon
    A platoon is a group of units that is acting according to some logic that describes the behavior of the platoon. When a platoon disbands it returns to base to receive a new order. We fixed platoons disbanding too soon due to a bug.

- (#4682) AI has been upgraded to make better use of experimentals.

- (#4436, #4450) Improve consistency of builders used by the AI
    A builder is not an engineer, but a set of conditions that the AI uses to determine what to build. These conditions depend on the status of the AI (do I need additional factories given my income?) and the status of the enemy (should I produce more interceptors?)

    These are tweakable and that is what we did here.

- (#4525) Allow AIx multipliers that are lower than 1.0
    Some people asked for this feature and here it is - for new players you can lower the multiplier to below 1.0

## Navigational mesh

The navigational mesh is an abstract representation of a map. The AI can use that representation to gain an understanding of what the map 'looks like'. The navigational mesh is generated at the start of the map and works on any map.  

We're looking for people with an interest in computer science to add features to add many other functions that allow the AI to understand. One example of such a feature is the ability to generate expansions markers: points of interest for the AI when it would like to build an expansion. And we'd like to add so much more so much more so that an AI can understand and properly play on any map. The navigational mesh is only use by the AI and only runs when there are AIs in-game.

- (#4432) Add label utilities
    Allows the AI to understand the value of an area, such as a plateau.

- (#4485, #4495) Only load in the navigational mesh as requested
    Entirely skip the generation of the navigational mesh when it is not used. This prevents allocation a few megabytes to store the navigational mesh in memory

- (#4555, #4559, #4561) Improve retrieval of (nearest) leaf for path finding
    This is an improvement to a macro feature (what is the general path from A to B?) and not a micro feature (how should I move this unit?). It is now more consistent, such that if a unit is remotely able to navigate to some place it will always have a label assigned to it.

- (#4569) Add generation of expansion markers
    These markers are generated for each map. The AI can now identify sane expansion locations on any map

## Bug fixes

- (#4483, #4482, #4496, #4499, #4508, #4519, #4546, #4550, #4580, #4599, #4600, #4605, #4606, #4608, #4631, #4638, #4668, #4669, #4671, #4667, #4672, #4678, #4683, #4692, #4727)
    General bug fixes that are too small to mention. These are usually introduced during the development environment and caught during testing.

- (#4438) Fix Seraphim torpedo bomber being able to apply damage twice

- (#4453) Fix the marker manager being unable to detect spawn markers

- (#4481) Fix UI scaling of lobby messages

- (#4488) Fix UI scaling of lobby map preview tooltips

- (#4500) Fix and improve option keys

- (#4588) Fix the charge icon of the loyalist

- (#4593) Fix the Lighting Tank being unable to fire at targets on water

- (#4617) Fix a bug where the construction menu would consistently reset

- (#4622) Fix wrong LODs for Cybran shields

- (#4623) Fix removing restrictions breaking the HQ system
    This was most notable during co-op

- (#4634) Fix the charge animation of the Emissary

- (#4635, #4639) Fix the direction of adjacency beams for factories

- (#4633) Fix various units being refracted when rendered in front of water

- (#4697) Fix a bug where neutral armies could view the entire map

- (#4699, #4715) Fix the jumping and rotating of units as they start being built

- (#4694) Fix offset of LOD1 of the CZAR

- (#4716) Fix a bug with the creation of templates with 1x1 or 3x3 structures
    The old method of creating templates would create gaps, the new implementation allows you to make proper templates with any structure size

- (#4725) Fix a bug where tech 2 and tech 3 Aeon engineers can not move backwards  

- (#4726) Fix a bug where damage indicators linger on and remain visible

- (#4730) Fix a bug where using recall could make your ACU immune to damage

- (55ddea) Fix a bug where pausing a unit would also stop updating the work progression
    Often noticeable when assisting paused structures

## Performance

We've been consistently improving the performance of the game by re-implementing features and in general by reducing the overhead of functionality. This section may not be as interesting for the average reader, but we add it anyway as good performance is an important aspect of the general user experience.

- (#4399) Improve performance of the heap data structure by 60%
    The heap data structure is used during path finding for AIs

- (#4417) Reduce run-time parsing of categories for AIs
    Replaces all string literals with their respective categories

- (#4376) Reduce overhead of the objective arrow
    Reduces memory usage of certain aspects of co-op missions

- (#4421) Lower case all imports of build conditions
    These are imported during run-time as they are processed, by having them as lower case characters we prevent a string operation to turn them into lower case characters during run time

- (#4150, #4444, #4489, #4512, #4512, #4557, #4680, #4681)
    Remove fields on instance tables to reduce memory usage. In Lua the hash part of tables grow by factors  of two. It can be quite beneficial to refactor the code to remove a few fields as it can prevent the average unit to hit the threshold. As an example:

    - (1) A unit with 33 fields in its instance table will have space for up to 63 fields
    - (2) A unit with 30 fields in its instance table will have space for up to 31 fields

    Where the table occupies 64 * 20 = 1280 bytes in the first example and only 32 * 20 = 640 bytes in the second example.

- (#4426, #4483, #4503) Separate AI and player logic
    AI initialisation is now only performed when there is an AI in the game. For a game with no AIs these procedures are skipped which saves several dozens of megabytes worth of memory

- (#4451) Reduce overhead of passing regeneration values to UI
    These values are no longer passed via the sync, but attached to the state of the unit instead

- (#4466, #4492, #4597, 3e34599, 9c9dda3) Reduce traffic between the sim and the UI layers
    Every bit of data we send to the UI is (deep) copied and usually thrown away afterwards. This involves a lot of memory management and that is the most expensive type of logic that a computer can run these days.

- (#4517, #4534, #4532, #4533, #4531, #4528, #4529, #4530, #4582, #4552, #4585, #4549, #4596, #4611)
    Reduce overhead of projectiles and weapons. The primary change is to reduce the amount of table trashing. An example is the use of a table within the scope of a function: it is allocated and then immediately ready to be de-allocated, which is a waste of performance and a hurdle for the garbage collector.

- (#4539, #4540) Reduce overhead of class instantiation
    Reduces the overhead of all instantiations such as the creation of effects, decals, projectiles, internal data structures and more. This is a significant boost to the performance overall

- (#4536, #4556) Reduce memory footprint of navigational mesh by 50% to 95%
    With thanks to #4523 we can now reliably measure the impact of changes, and as a result we managed to increase our awareness of what is expensive.

- (#4640, #4663) Reduce overhead of unit treads
    The new implementation is a lot more memory aware and reduces the amount of table trashing

- (#4657) Reduce overhead of builder conditions of AI

- (#4558) Replace legacy trashbags with the TrashBag class

- (#4576, 4679, #4703, #4711) Reduce overhead of unit intel management
    The new implementation is a lot more memory aware and drastically reduces the memory footprint of the average unit

- (#4675) Dynamically compute LOD thresholds for units
    The larger the unit the longer it remains in view. These values where all over the place. These changes create a consistent experience for players

- (#4686, #4703, #4712) Reduce overhead of passing veterancy state to UI
    The old implementation could cause stutters due to excessive copying of tables when syncing

- (#4686) Fix memory leak with the veterancy system
    The old implementation would keep a reference alive to essentially every unit in the game that ever received or did damage to another unit. This would create a directional graph of references with the ACUs being the spills. As a result there is a significant build up of memory as the game progresses

- (fd41dce) The game can now use up to 4 gigabytes of memory, instead of just 3 gigabytes
    Due to an assembly patch the game can now use an additional gigabyte of memory. In combination with all the other memory improvements mentioned this should prevent all cases of where players run out of memory

## Physics Based Rendering (PBR)

We're slowly but surely preparing the game for a significant visual improvement. This is a long term project that is going to consume hundreds of hours. We're hoping to find additional contributors that have an interesting in creating (and fixing) meshes and textures.

If you have that interest and/or experience and you'd like to help out then you can introduce yourself in the dedicated channels in the official Discord channel!

- (#4247) Introduces shaders for Physics Based Rendering (PBR)
    The shaders are not used yet but the code is ready to run

- (#4443, #4673) Fix existing cube maps and prepare them for PBR
    Adds a blur to the mip maps to mimic roughness of the surface

- (#4456) Re-create the Cybran land factories

- (#4469) Re-create the Cybran naval factories

- (#4501, #4664, #4665) Re-create the Cybran air factories

- (#4501) Re-create the Aeon air factories

- (#4479, #4613) Re-create the Aeon land factories

- (#4521) Re-create the Aeon naval factories

- (#4471) Fix localisation and colors of default fields of combo

## Other

- (#4317, #4476, #4320, #4515, #4502, #4504, #4517, #4547, #4513, #4603, #4322, #4677)
    All the annotation work that has been merged in. We have an extension that allows you (a developer) to gain basic intellisense support in the repository. This has been, and still is a massive improvement to the workflow of those that work on the game (in)directly.

- (#4468) Fix terrain-type depending mesh selection of structures
    This feature is not used, but technically it allows you to change the (textures) of a structure depending on the terrain type it resides on. As an example: a factory on snow would have snow on it

- (#4303, #4604) Add or improve Chinese translation

- (#4487) Improve the test functionality of movies

- (#4523, #4658) Introduce function to determine size of table in memory
    Allows us to estimate the size of a table in memory

- (#4512) Fix firing sequence of the UEF Cruiser
    This is a visual fix and does not impact gameplay.

- (#4538) Reduce code duplication by introducing 'table.random'

- (#4263) Add division icons

- (#4395) Add MIT licenses to various FAF-introduced files

- (#4659) Add a russian translation for the balance patch

- (#4688) Add a code of conduct to the repository

- (#4731) Fix the auto balance button in the lobby being too large

## Mod incompatibility

There appears to be an issue with the UI mod 'Supreme Economy v2.3'. We've notified the maintainer.

## Contributors

- Rowey (#4317, #4320, #4517, #4515, #4517, #4534, #4532, #4533, #4531, #4528, #4529, #4530, #4547, #4582, #4552, #4588, #4549, #4603, #4322, #4627, #4626, #4657, #4731)
- 4z0t (#4376, #4437, #4472, #4484, #4538)
- Relent0r (#4413, #4417, #4412, #4419, #4435, #4436, #4445, #4447, #4450, #4455, #4462, #4461, #4460, #4454, #4475, #4505, #4682)
- BlackYps (#4247, #4443, #4667, #4673)
- Blodir (#4247)
- Zjonn (#4399)
- MadMax (#4443, #4456, #4469, #4486, #4501, #4501, #4521, #4613, #4622, #4664, #4665, #4694)
- Jip (#4247, 4421, 4386, #4453, #4432, #4444, #4451, #4475, #4426, #4466, #4474, #4483, #4485, #4482, #4492, #4496, #4495, #4489, #4503, #4500, #4512, #4523, #4539, #4540, #4546, #4510, #4536, #4555, #4556, #4557, #4559, #4561, #4560, #4580, #4581, #4585, #4590, #4591, #4596, #4597, #4598, #4599, #4600, #4605, #4586, #4606, #4607, #4577, #4611, #4608, #4587, #4611, #4615, #4617, #4612, #4620, #4623, #4631, #4635, #4634, #4633, #4636, #4640, #4658, #4639, #4639, #4663, #4638, #4558, #4576, #4668, #4669, #4672, #4677, #4675, #4679, #4680, #4569, #4681, #4686, #4689, #4688, #4690, #4691, #4692, #4697, #4699, #4711, #4703, #4712, #4714)
 xXEddieXxx (#4438, #4463)
- speed2 (#4448, #4487, #4488, #4508, #4490)
- hdt80bro (#4471, #4476, #4550, #4513, #4395)
- Yuchenjimmy (#4303, #4604)
- Penguin (#4095, #4491)
- Haifron (#4499, #4526, #4519, #4504, #4593)
- Balthazar (#4479, #4716)
- Senex-x (#4659)
- MostLostNoob (#4669)
- maudlin27 (#4671)
- KionX (3e34599, 9c9dda3, fd41dce, 55ddea)
- BlueAmulet (fd41dce)

At last I'd like to thank Phong for consistently hosting games on the FAF Develop game type. I've watched almost all his games to track down bugs that would otherwise go unnoticed. And my thanks to Prohibitorum for proof reading the changelogs.

I look foward to everyone sharing their opinions and perspectives.

I'll share you mine as the lead of the game team that would be responsible of integrating it, only then the balance team comes in and tries to balance it. All of the mentioned issues are those that I collected over the year of people asking me the same question. There are likely a lot more when we would start integrating it.

What would nomads need to be worthy? Some said nomads would never become ranked. As many of us may be aware, most of the FAF userbase plays campaign and solo skirmish.

I've got some numbers for you, these are from 2022 as a whole:

Players per reason why game is unranked (note the AI section)

message	num_unique_players	num_player_games
No results were reported by peers	59,358	933,257
The game has at least one AI	40,380	384,982
An unacceptable mod was used	38,986	844,815
Valid	34,953	2,535,854
Game was too short (probably had a technical fault early on)	34,326	368,491
Too many desyncs	21,657	137,612
The game was FFA	16,757	125,076
An unacceptable map was used	16,349	107,452
Unranked by host	15,282	99,677
Unacceptable unit restrictions were enabled	14,922	154,352
Coop is not ranked	13,122	137,427
The game had unbalanced teams	9,670	38,441
Team were unlocked	8,018	20,851
More than two teams. XvXvX+ games cannot possibly be ranked, for the same reason that FFA cannot	7,757	24,997
Cheats were enabled	7,199	33,099
Difficulty was wrong	6,423	40,789
Only assassination mode is ranked	6,040	13,198
Expansion was disabled	3,612	31,125
Prebuilt units were enabled	3,086	6,334
No rush was enabled	2,771	6,283
Fog of war was disabled	2,090	4,486

Players per game type

name	num_unique_players	num_player_games
FAF	75,094	5,135,790
Coop	27,517	568,697
Nomads	22,100	186,907
FAF Develop	7,770	51,735
Xtreme Wars	7,571	48,641
FAF Beta Balance	6,475	29,067
Phantom-X	3,812	18,151
Murder Party	1,452	2,864
King of the Hill	1,301	3,127
Claustrophobia	1,282	2,548
LABwars	494	1,071

With thanks to @Sheikah for running the data. Given these numbers we should work on:

• The base game
• AI-related functionality
• Co-op

And then Nomads maybe next, depending on how you interpret the data. Luckily we are working on the base game and AI-related content already - soon with the navigational mesh all maps will have a decent marker setup available. At some point this year I'd love to look into co-op too and maybe even produce a few missions of my own.

For those that are unaware: Nomads is ranked, all game types are. Therefore it is just not part of the matchmaker.

Technical issues

Let us start with numbers, and specifically about framerate. I'm not sure why but the game runs poor at best when you have 4 Nomad AIs ditching it out against each other. It has been an issue on Github since June 2020. The framerate would usually be at 200+ it is at around 20 - 40 with Nomads:

Fixing just this issue is likely not trivial and the solution will likely have a large impact on on the visuals of the faction.

A lot of code in Nomads is not written to perform. It is written to function. That is fine, but in order to not lose some of the performance we gained over the last year we'd need to spent just a few months improving the code base before we can even start integrating it.

Sound and visual issues

Then we move on to the general feeling of the faction. All of that is of course subjective, but there are some issues that I'm sure we can all agree to.

• A lot of (sound) effects are not on par with the existing factions
• A lot of units are not on par with the existing factions, take the land factories:

• A lot of naval units feel unfinished. The only unit that feels complete to me is the Frigate. All the other units either lack the 'wow' factor, or are simply not made for the part:

• A lot of units lack LOD1 or further, which is bad for your framerate
• A lot of effects are visible for too long, which is bad for your framerate
• I'd argue that a lot of units lack the baked-in ambient occlusion that some of the base game units have, causing the units to look flat:

Time

Everything takes time. Integrating Nomads properly would quickly take more than a year with the issues mentioned so far. And all of that, instead of:

• General gameplay improvements, like the improved terrain deformations
• Better graphics for the base game, like the pbr project
• General improvements to performance
• Navigational mesh so that AIs can play on any map
• Introduction of new features
• Fixing bugs
• ...

We'd be delaying all of that for a project that is barely touched upon by the community: only 85K games according to the data. In comparison to co-op it is nothing, let alone when you compare it to AI games in general.

But don't get me wrong - I do think the project is epic. Some units and effects are really well made. And that is why it is a featured mod, one that is ranked. That is on-par with any other game mode, such as the FAF game type that everyone plays.