Navigation

    FAForever Forums
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    1. Home
    2. Jip
    Jip

    Jip

    @Jip

    1760
    Reputation
    1899
    Posts
    496
    Profile views
    8
    Followers
    0
    Following
    Joined Last Online
    Website gitlab.com/w.b.wijnia Location Netherlands Age 27

    • Profile
    • More
      • Following
      • Followers
      • Topics
      • Posts
      • Best
      • Groups
    Jip Follow

    Best posts made by Jip

    Game Councilor

    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.

    posted in General Discussion •
    Game version 3741

    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.

    4b109c5c-7378-47d6-b2a3-ba5ec03fa4f8-image.png

    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.

    fd9f5733-a423-4d29-a027-a2d3f22f3f8f-image.png

    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:

    00ec191d-91d6-4b74-8188-3d3889e5e2fc-image.png
    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 🙂 !

    66cc0e35-abf2-4b86-b254-02447cd45acd-image.png
    Current FAF game type, looking at 500 asf: ~150 fps

    cf98f9a0-ce41-45c6-ba67-bcb10e1afd54-image.png
    Current FAF Game type, 500 selected asf: ~100 fps

    92bd0a25-9d1a-4cb8-8a3f-147ea58be17d-image.png
    Current FAF Develop game type, looking at 500 asf: ~250 fps

    69882a09-9e45-4abf-b52e-0fc9e829a867-image.png
    Current FAF Develop game type, selected 500 asf: ~150 fps

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

    posted in General Discussion •
    Patch 3732 - 3735

    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 🙂 .

    5145aaee-2e05-4bb9-887c-8245c4b8e2f1-image.png
    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.

    posted in General Discussion •
    Game patch 3728

    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)
    
    posted in General Discussion •
    Patch 3721 / hotfix 3722 / hotfix 3723 / Patch 3724

    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)
    posted in General Discussion •
    RE: Game Councilor

    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.

    posted in General Discussion •
    RE: Developers Iteration I of 2023

    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

    f3787cae-d488-4666-bd87-d3b226c59470-image.png

    Long John Silver

    4f5ab8ef-e4dd-47b8-94e3-cd28554a266d-image.png

    b1fd76bc-7812-49fe-ac45-98bab33276ef-image.png

    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

    ba35b039-cd3b-43c5-8f7f-1394cb7ca57b-image.png

    Long John Silver

    60aa05b9-0a24-4d27-a37d-88c6967e0c0f-image.png

    bcd20260-3fec-4aea-b0ed-a02fc3f3788a-image.png

    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:

    f8605648-3467-4938-9b38-e4a3e9a444cc-image.png

    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
    bdcf1864-79e4-4011-9dbc-1da63a65096c-image.png

    Divides a selection orthogonally to the line from your mouse position to the center of the selection
    be226567-5f0a-4d0e-a689-c633a831d31b-image.png

    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:

    ad1c2ce5-8b55-44c4-9936-d4c9f542e4ab-image.png

    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.

    posted in General Discussion •
    Questions about performance

    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.

    posted in General Discussion •
    Questions about performance: Cybran build drones

    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:

    bb6c7775-b972-4bf9-a475-4acdfe518b5e-image.png

    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.

    posted in General Discussion •
    Developers Iteration I of 2023

    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:

    a724abb1-a5db-4d84-8734-4fddcbb638ec-image.png

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

    posted in General Discussion •

    Latest posts made by Jip

    RE: BlackOpsFAF-Unleashed only for FAF v20

    They are blueprint changes to individual units.

    posted in Modding & Tools •
    RE: Split matchmaker into mapgen and regular map queues

    @tagada said in Split matchmaker into mapgen and regular map queues:

    There is currently no 3vs3 queue since that format is essentially dead. Nearly nobody plays it and there are no maps for it.
    If it would be just a map problem then the mapgen 3vs3 would solve that. The question is would enough people play it?

    As far as I can recall it was primarily dead because of not having sufficient maps. And we can't answer the last question without trying 🙂

    posted in Suggestions •
    RE: Split matchmaker into mapgen and regular map queues

    Having a 3v3 queue would fill a gap for me, where you end up in a game with no dedicated air player and nobody knows what to expect because the map is (always) generated.

    To have six queues feel a bit much

    posted in Suggestions •
    RE: Split matchmaker into mapgen and regular map queues

    I like the idea of @maudlin27 , reasons being:

    • (1) 6 players are less prone to startup problems (not connecting)
    • (2) 6 players are less prone to connectivity problems in general (lag)
    • (3) 6 players is almost guaranteed that the game can be played from start to finish with no sim slow downs (assuming 600+ units per player means we end up with with about 3600 units, which is far less then what a budget cpu is able to run soon)
    • (4) 6 players is unusual meta wise, and there is likely no dedicated air slot

    It would also prevent us from having six queues, even though you can enter multiple queues.

    posted in Suggestions •
    RE: Issue with t3 air factory roll off time/next build delay

    The intended roll off time is a balance discussion. This particular change was unintended - I'll try and revert it unless the balance team wants me to do something else. @Tagada ?

    posted in Game Issues and Gameplay questions •
    RE: Random UI improvements [UI mod]

    If I am not mistaken they are available on the development branch. Could you check and confirm?

    posted in Modding & Tools •
    RE: Issue with t3 air factory roll off time/next build delay

    I'll look into it.

    posted in Game Issues and Gameplay questions •
    RE: Small text fix

    We fixed the bones, they got messy due to some animation. The transport can carry up to three tech 3 units

    posted in Contribution •
    RE: Can't play Nomad Campain any more

    Share the log - that way we can tell you what happened.

    posted in I need help •
    RE: Is it OK that engi stations can eat experimentals?

    @mach said in Is it OK that engi stations can eat experimentals?:

    experimentals themselves can probably be made unreclaimable like ACUs are (removing RECLAIMABLE category I guess)

    I like this idea - they are experimental and unique after all. They should not be reclaimable. Would also 'fix' the reclaim glitch that prevents the Ythotha from spawning the storm.

    posted in Balance Discussion •