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.

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.

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)

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)

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.

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.

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.

Game version 3738 (19th of June, 2022)

The past month has been exciting - there is no other word that we can use.

From a development perspective we're on the verge of being able to provide a modern, interactive development environment to our community. With the work of Eluvatar a Visual Studio Code (VSC) extension is close to release that provides intellisense support for map scripters, mod makers and game developers. And with the work of Ejsstiil the Lua debugger that ships with the game is fully functional again when you work from your development environment. Programmers understand how critical these features are for the development of essentially anything.

And from a user perspective the game has never been more performing. Specifically the infamously slow ASF battles has been tackled. For the majority of matches the game no longer slows down, with the assumption that there is no potato processor participating in the match.

All of that shadows all of the other critical work that has been done the past month with thanks to all the remaining contributors, including SpikeyNoob, Hdt80bro and LilJoe7k4 who made their first contributions to the game repository.

A great deal of appreciation towards everyone that made this patch possible.

I hope you all enjoy the lack of APM during a late Seton's Clutch game,

With kind regards,

Jip

Bug fixes

• (#3896, #3899, #3901) Fix UI elements ignoring the console command UI_ToggleGamePanels

• (#3909) Fix enhancements ETAs leaking to the other screen when using split screen

• (#3876) Sanitize weapon target priorities of Point Defenses
  This fixes the issue that point defenses are not firing while a target is in range

• (#3923, #3924) Fix an economy related glitch that allows you to gain resources free of charge
  For all intends and purposes we will not dive into the details

• (#3946) Fix damage of child projectiles, such as Cybran tactical missiles after they split

• (#3961) Fix issue with the attachment bones of the tech 2 Aeon Transport
  As a consequence the tech 2 Aeon transport can now carry up to 3 tech 3 units, instead of 2

• (#3966) Fix roll off points for various factories
  The roll off points were not properly aligned, as a consequence ships had trouble leaving the dock. This was especially noticeable on the naval factories of the Cybran faction

Features

• (#3887, #3968) Introduce Intellisense support for the FA Visual Studio Code (VSC) extension
  As map scripters, mod makers and game developers we have been living in a cave. But no more - thanks to the work on the extension and the work in this pull request we are slowly introducing annotation across the repository.

  For those with programming experience: it is like the introduction of Typescript, after working for years on ends in Javascript.

  This also works when you have no development environment for the FA repository on your system, see the readme on the Github page of the FA repository for more information.

• (#3938) Revive the FA Lua debugger
  Revives the FA Lua debugger when you are working from your development environment. Allows you to set breakpoints and inspect the stack, locals and globals. Extremely useful when you are debugging your maps, mods and when you're working on game development in general.

  Requires a development environment in order to work. You can set this up in half an hour, see the readme on the Github page of the FA repository for more information.

• (#3883) Introduce a UI to keep track of the mass fabricator behavior
  The UI element is to the right of the economy panel. It can be dragged horizontally by using the middle mouse button.

• (#3889, #3906) Improve in-game chat settings panel
  Fixes various small issues with the chat panel and allows you to view and inspect the changes in the settings live by using the apply button.

• (#3863) Pimp the Aeon Quantum Optics Facility
  The unit was unfinished in every regard - as part of a live programming session we improved the feeling and aesthetics.

• (#3905) Add guidelines for a development environment for FA for Linux-based operating systems
  For more information, see the work instructions of the github page.

• (#3933) Use playable area instead of map size on the default scoreboard

• (#3835) Introduce a builder pattern to create UI elements
  An alternative, more modern approach to creating, positioning and checking of UI elements.

• (#3972) Add the ability to manually recheck weapon targets of the selected units via a hotkey
  As per #3857 the weapons of the majority of units do not recheck their targets. Usually this is not required, but it does cause a big hit on performance. This new hotkey is introduced to allow you to let your units retarget on command for those situations where that is required

  You can find the hotkey by searching for 'recheck' in the hotkeys menu

For map, mod and AI developers

• (#3884) Add support for a unit.IsCivilian flag
  Introduces an easy to use flag to indicate whether a unit belongs to a civilian army

• (#3894) Add support for a unit.ImmuneToStun flag
  Introduces an easy to use flag to make a unit immune to stuns

• (#3894) Add support for a shield.SkipAttachment flag
  Introduces an easy to use flag to allow shields to function when attached

• (#3944) Add support for multiple upgrade animations via the function unit.GetUpgradeAnimation

Performance

• (#3845) Reduce table allocations when defining weapon target priorities

• (#3875, #3945) Reduce memory impact of units, weapons and props

• (#3891, 6fefe78) Sanitize guard scan radius of units
  The guard scan radius is used by units on attack move or patrol to find and engage hostile units in their surrounding. The value was all over the place and could cause serious slowdowns, especially during the late game.

• (#3892, #3903) Sanitize footprints of air units
  All non-experimental air units had a footprint size of 1 - the size of a wall. Because of that there were two issues: due to their proximity it introduced mesh intersections that break the immersion of the game. And due to their density it causes performance issues. From now on all bombers have a footprint size of 4, all gunships have a footprint size of 3 and all interceptors have a footprint size of 2.

• (#3930) Remove dependency on the schook folder
  Improves code maintainability and reduces the amount of hooks that ships with the game.

• (#3857, #3931, #3950) Sanitize weapon parameters
  There are three crucial parameters that determine the behavior and performance of weaponary: the weapon target check interval, the weapon tracking radius and the retargeting behavior of weaponry. The weapon target check interval is now based on the rate of fire of the weapon. The weapon tracking radius is reduced to 7% for non-anti air weaponry units and 15% for anti air weaponry. The retargeting is disabled unless the weapon is considered artillery or anti air.

  This slightly changes the behavior of units, by standardizing their weapon parameters. In return, the game performs a lot better and units respond more consistent based on their weapon statistics.

• (#3949) Reduce impact of props on FPS
  Aligns the rendering distance of props with the base game

• (#3943, #3951) Reduce impact of mesh entities on FPS
  Aligns the rendering of various mesh-based entities with their respective size. As an example, the adjancency node was rendered up to the same distance as that of shields.

• (#3967, #3965) reduce impact of projectiles on FPS
  Sanitizes the LODCutoff of projectiles that have a mesh. The average projectile is emitter based, but some use a mesh. These meshes were visible at extreme ranges, causing them to be rendered even though they were completely hidden behind the strategical overlay of projectiles (dots)

Other changes

• (#3885) Fix argumentations for the Hunter AI

• (#3879) Fix minor issue with lobby

• (#3881) Refactor effect files of the Lighting Tank
  As told to us by Rowey - we'd be lost without him.

• (#3895) Fix minor issues with the initialisation files

• (#3907, #3926) Improve the /nomovie command line switch

• (#3908) Introduce a /nomusic command line switch

• (#3904) Fix game options menu not being scrollable by mousewheel

• (#3913) Fix issues with the .gitignore of the repository

• (#3921) Add tooltip to patchnotes button in the lobby
  The mighty Rowey - at work again.

• (#3882) Fix bone names of the upgraded Hives

• (#3925) Fix the width, padding and layouts of various UI elements

• (#3912, #3724) Add in remaining base game blueprint and script files
  Greatly improves code maintainability of working on the game as a whole.

• (#3947) Fix UEF engineers not applying their water animation

• (#3948) Fix a rare issue where the speed adjustment of (slow) hover units caused an error

• (#3941) Fix categories missmatch for the Atlantis

• (#3969) Fix the Flayer (AA) missiles of the tech 2 UEF Cruiser
  The missiles were using a torpedo mesh, instead of the typical UEF AA Flayer mesh used by sams

Contributors

• LilJoe7k4: (#3845)
• speed2: (#3885)
• 4z0t: (#3879, #3883, #3835)
• Jip: (#3895, #3894, #3884, #3875, #3863, #3891, #3892, #3903, #3923, #3913, #3924, #3857, #3931, #3912, #3724, #3944, #3947, #3946, #3945, #3948, #3950, #3972)
• Ejsstiil: (#3896, #3889, #3899, #3907, #3908, #3909, #3904, #3906, #3901, #3926, #3925, #3937)
• Madmax: (#3863, #3951, #3943, #3961)
• SpikeyNoob: (#3905)
• Tagada: (#3876)
• Rowey: (#3921, #3881, #3882)
• Hdt80bro: (#3933)
• Eluvatar: (#3887, #3968)
• Uveso: (#3941)
• M0rph3us (#3969, #3967, #3965)
• KionX (6fefe78)

Translators

• 4z0t (Russian)
• M0rph3us (French)
• Unknow (French)
• Carchagassky (French)

@jcvjcvjcvjcv Do you happen to still have the logs of the game?

The load / save functionality is not stable at the moment. There has been no progression in finding a solution for that. Is there a reason that you're playing offline? As an example, if you play online then you can share your replay id. That allows us to inspect what is going on.

I was referring to how you're trying to load it in .

The init file can be found on Github, the base game assets that contain Lua files are no longer loaded. See also these lines. That means any changes to those files will not be picked up by the base game, and I suspect that is what you're doing here.

I don't know how your changes are setup, but you can try loading it like how people load Kyro's lobby. You can put the file in the gamedata folder of faforever (usually found at: C:\ProgramData\FAForever\gamedata) and call it like one of these exceptions.

Can you describe what you're trying to do?

A lot of other clients operate in a similar manner - we just copied their behavior.

I'd like to know what replays stutter for you, can you share a replay id?

Yep, that is not exposed.

To try and comply to the feedback I hear in bits and pieces we are reverting the majority of the changes, allowing all direct fire weapons to recheck their targets as usual. That is essentially any weapon with a low arc. See also:

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

With that, this topic can be closed.

Do we really want to keep this behavior?

We're all here to make FAF better, we all have a say in it. If we deem that this is not worth the performance then we (partially) revert these changes again. Which again - is fine by me.

What is weird about it?