T1 pgens aren't essential for T2 arty, it's a 4% reload discount which ends up being a 1.19x effectiveness for fully capped arty, coming to a profit of only 62 mass which is a negligible 2.8% of the total 2200 mass cost of the setup (unitdb).
This marginal adjacency is eclipsed by the idea that sparkies shouldn't build any eco structures so that there is no chance of them not being a combat unit.

As Deribus mentioned, I think reducing the size without changing the stats would make it too powerful in firebases, since you can basically stack 4+ instead of 3 shields to defend a T2 PD and they are high HP and low cost compared to UEF/Cybran.

Here's the overlap possible for a PD with the current shields:

I don't think being unable to upgrade the shield is a huge drawback, it just requires you to ctrl-k the shield and reclaim the small wreck before building the very cheap T3 shield. It requires some APM but definitely isn't impossible if you're defending something important that requires your attention with shields.

For the size complaint, I'm not sure what you want to shield. It can shield adjacent structures pretty well. Not entirely but almost everything:

For this pgen specific case I'd rather opt for a tiny increase in shield size instead of making the structure smaller.

I've been testing your size idea with the "Create entities" dialog (its in the hotkeys, you use the hotkey while a unit is selected and you can change its blueprint values. Spawn a new copy of the unit to make sure you get all the changes. Requires cheats):
4x4 size is just way too OP, since you get ~8 overlapping shields instead of 3:

5x5 size is enough to cover a pgen but its still a small shield so its not reaching towards diagonals:

It also still increases the coverage from 3 to 4-6 shields:

Decreasing the size even by 1 seems to bring more problems than solutions.

All in all, I understand why you dislike the shield but I think its strengths in HP and cost make it above average for firebases and protecting most directly adjacent things like T3 shields, pgens, factories, or engineers. The T3 shield is also very strong because it's super cheap and the 2nd most powerful, while giving sufficient radius imo: I've seen Aeon T3 shields easily protect air grids, artillery, or game enders from artillery barrages when a sufficient number are built (and number of shields is the most mass-efficient way of defending, so having a cheap shield helps a huge amount - natural regen is nearly worthless while recharge from 0 is extremely strong).

SMD missing and having to fire a second time is unacceptable. In that game the SMD firing twice actually lost the game.

I have published the SACU Rebalance mod. Afaik there are no bugs and its very playable: the balance is theoretical number crunching with very light T3/T4 land/navy combat testing, and all the game/visual design is implemented at a basic level (so you can look in UI for stats). Please host it/play it/sandbox it.

There's a github page with the working environment and commit history: https://github.com/lL1l1/SACU-Balance-Mod/tree/main

From the github:

FAF SACU Rebalance

This is a mod for Forged Alliance Forever.

Implements changes for the SACU rebalance proposed by balance team: cheaper SACUs, stronger adjacency/gateways, new army support enhancements.
Rambo SACUs are independently reworked with new weapons and upgrades to fill gaps in faction rosters.

General Changes

• Cheaper SACUs: Buildtime and energy costs are significantly reduced across the board.
  • RAS is more energy expensive due to decreased base SACU mass cost. RAS also increases death volatility of SACUs.
  • Weaker base SACUs: Unupgraded SACUs have less HP and/or DPS.
• Stronger gateways: Gateways consume 32-44 mass/s building SACU and have 160 buildpower, while costing 2550 mass, down from 3000.
• Stronger adjacency: Mass fab and pgen adjacency for gateways is un-nerfed and made equivalent to land factory adjacency.
• Engineering upgrade buff: Engineering upgrades are made much cheaper, especially on buildpower and energy, so that they can come close to engineering stations in power.

Faction specific changes (Rambos and support enhancements)

• UEF SACUs are highly armored with good firepower. They have powerful support enhancements and combat enhancements designed to engage T4 units.
  

• Cybran SACUs are lightly armoured and slow, but are highly upgradeable with enhancements designed to engage enemy T3, SACU, naval, or air units.
  

• Aeon SACUs are agile and have a powerful sensor suite (to counter underwater cloak) but are lightly armored. They have cheap combat enhancements designed to engage enemy T3 units.
  Aeon SACU nano is removed since nano does not fit the faction.
  

• Seraphim SACUs are highly armored with increased Regeneration rate but reduced firepower without combat enhancements. They have unique utility/support enhancements and powerful combat enhancements designed to engage enemy T3 units.
  Seraphim SACU shield is removed since personal shields do not fit the faction.
  

Fix here: https://github.com/FAForever/fa/pull/6884

This is a repost of a post made by @Jip on Discord:

It goes without saying that when an ACU is destroyed that it should explode. This discussion is not about the 'typical' way that an ACU ends up exploding. Instead, this discussion about what should happen when a player disconnects. There's some interest of adjusting this behavior, see for example:

• https://feedback.userreport.com/354e2fbd-fdb7-4282-ae57-df75bf625431/#idea/448833

And with thanks to @Nomander we now have a technical solution:

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

We just have to enable it. At the moment it is disabled. We can make the behavior work like any of the other share conditions. And we can also introduce a new behavior: the ACU recalls individually.

The question that remains is how this feature should work in practice. A few relevant facts:

• A) It is difficult, if not impossible to determine whether a player left the game on purpose or because of technical reasons. We'll refer to this as the player 'leaving' regardless of what the cause is.
• B) It is possible to make it configurable, in the same way that the victory conditions and the share conditions are configurable.

And the primary questions for this topic?

• 1. Should we adjust the behavior of the ACU when a player leaves the game?
• 2. Should we make the behavior customizable (through the lobby options)?
• 3. The new (individual) recall behavior, how should that work exactly? Are there conditions, and if so - what are they?

I'd like to add some more details based on what's possible with the current implementation too:

• Aside from recalling the ACU individually, we can share the ACU for a limited time or permanently.
• The share condition for units can be changed based on if a player disconnects, and whatever anti-abuse measures are used (ex: use fullshare for disconnects unless we detect abuse, then use no-share just like for normal deaths).
  • Some ideas for anti-abuse measures are checking current ACU HP, if the ACU was damaged recently, or letting the ACU live (and possibly sharing it) and calling it abuse if it dies too quickly.

Maudlin is correct that assistance costs vary by shield, since it is based off of regen rate, repair cost, and RegenAssistMult.
Documentation on github repo:

--- How much buildpower is required to provide 1x of the shield's regen rate.
--- The cost of assisting a shield is repairCostRate / RegenAssistMult,
--- where repairCostRate is determined by Unit:UpdateConsumptionValues
---@field RegenAssistMult? number

These are the buildpower and mass efficiencies considering that repair cost is 0.75x the unit cost and RegenAssistMult is 60 for all shields.

Considering that defending a T3 Aeon artillery costs at least 165 mass/s, and a Mavor at least 550 mass/s, it is well worth economically to spam out multiple shields (they cost around 3.4k mass each) instead of assisting one, although it is riskier because the enemy can retarget the artillery, let all your shields get up, and then come down all together in the next few artillery shots as the overspill and splash damage take effect. Good for game enders that you need to protect at all costs but also need income to build.

2 Aeon T3 artillery one shot a shield and it is impossible to assist to prevent that currently.

Assisting works at full speed if you're stalling but that's a hard to fix engine bug/performance heavy Lua fix.

[Does assisting] speed up getting a collapsed shield back up?

No it does not. That is determined by the shield recharge time which will be added to the UI soon.

Aeon used to have t2 shields that couldn't be upgraded (unless my memory fails me) but that was patched as a balance decision.

The balance team does approve of letting them be upgradeable but there is simply no animation for doing so.

Good post. If you want you can take a look at/contribute to 4z0t's rings for all mod, it's set up to display range rings on top of units and currently there's no capture preview iirc.

As for interrupt pathfinding, it can get a bit out of the original scope with certain commands (attack move causing long range reclaim, load into transport from long range, capture from long range). We already filter the order to engineers only, but we could go further and filter by command type too, so it only works on what we want for good gameplay. Alternatively we should implement interrupt on assist/capture/auto ranged reclaim into the game going by the (poorly enforced) policy of integrating important mods into the game.

The cost of the TML isn't just 800 mass:

• mass cost: TML (800 mass) + missile (250) + some way to kill tmd, let's say 4 (easily countered) T1 bombers (360) = 1410 mass (unitdb) which affords 5 TMD.
• You need to get an extremely valuable central map position to be able to force out 6 TMD per enemy base. You then have to get T2 engineers to that position. Taking all that time + having to get the engis there (early HQ instead of eco) gets your opponent a T2 mex.
• You also have to build a TML instead of a T2 mex which gives your opponent extra mass to build TMD while you load the TML.

If there are more than 20 desync messages sent from any players: https://github.com/FAForever/server/blob/1b98cdae23350c92fab5203b4e6ac9bf52198e6a/server/games/game.py#L477
So I guess the unpredictability comes from the player count heavily affecting the result. An Astro game will send 6 desync messages every 5 seconds while a Dualgap game sends 12.

supcom campaign branch is enabled when playing campaign on the steam version and it being enabled gets saved to the game prefs for some reason.

He mentioned that it's anything he contributed "after this post", and to "treat it as unsupported and remove it where practical." I don't think he meant anything bad, just asking for people to take care of the maintenance/cleanup.

@Sheppy said:

I feel like too often there is clearly "one best option" in the selection and that takes away choice. I don't know how to best fix that, only thing I can say is that in most other games I think a lot more about my selection.

Some roguelikes bias rolls towards what your "build" is. I think combining that with general purpose upgrades (eco) would make picks more interesting.
You could even track what units the player has built recently to determine the build.

Also printer is 1.5k 4.7k games and plays terribly according to his own replay (that he even thinks matters for the nerfs done) so I shouldn't waste more time here and I wouldn't recommend for anyone else to do so either.

@Printer
Reads like AI stylized your post.

1. not an argument
2. Post replay where transports matter. AoE vs units outside engi clumps, like shields or mex storages, is irrelevant because its unrealistically apm heavy.
3. yes that's the point. Second sentence doesn't make sense.
4. Wrong because it's 3750e/s avg
5. Wrong number. Also not an argument.
6. You need to build power anyway to use the unit, this forces you to do it before it is finished instead of after.

E nerf makes arty a more viable counter without affecting total mass cost.
AoE/retargeting nerfs fix the most annoying/toxic things which were killing fab capped mex, stalled shield arrays, and engi clumps.
All of this was explained in the changelog snippet and you should address those ideas instead of just listing the (wrong) numbers then baselessly saying they're wrong.

@DommyMommyDostya

You still need a really high number of novaxes to one shot shields through assistance with the increased burst DPS.

A setup of 2 Dukes with adjacency has 1960 DPS and deals 15680 dmg + 6 aoe every 8s, while costing 76k * 2 + 3240 * 6 = 171k mass and producing 2500 * 6 - 1400 * 2 = 15k excess energy.
For just that mass you'd have 5.3 novaxes not counting the 20k/s avg. energy drain.
If you count the energy in terms of pgen-storage infinite grid mass cost (best case scenario) then it's 32k + (3240+200*8)/(2500 * (1 + 0.0625 * 16)) 35630 mass total per novax or 4.8 novaxes.
If you subtract the excess energy from the duke cost (lets say you used it in advance for mass fabs) then the cost goes down to 171k - 15k * 324/250 = 152k, which is equivalent to 4.3 novaxes w/ grid pgen energy.

Also not to mention if you add some engineers the novaxes can't actually break through your shields because they still take time to deal damage. Against 7 novaxes (3 arties equivalent) you'd need 9-22 additional engis to survive the burst damage, on top of the 19-24 engis to survive the avg dps.
Meanwhile 3 dukes one shot all shields and you can't stop it, but the avg dps needs 33-42 engis to out-assist (vs 28-46 to survive the novax volley).
Additionally the engi assist costs are up for a balance pass eventually so that it's more fair across factions, since that mechanic has never been touched.

It's definitely possible but it's not easy. The biggest hurdle would be the game's performance stopping you from doing general-purpose machine learning approaches. I think on zulip someone reverse engineered a basic simulation of the game but I'm not knowledgeable on the matter.

There's some work towards build-order infrastructure:
@seraphim-noob has worked on a build order recorder mod ("BO Logger" by Seraphim-Noob). The description says the data is for use in a BO analyzer which I found on his github here: https://github.com/TimMasalme/Bo-Analyzer
@sheppy has a website with build orders in text form manually input from players. https://fa-companion.services.atlantishq.de/maps

In my personal opinion build orders are solvable almost analytically. Your context would be mass costs and mass-seconds (for travel time). The target builds would be a sequential list of builds to achieve at what timing, since splitting focus between 100% the target or eco should always be the fastest way to build something. Once a target is achieved you can add its impact on mass/energy production to your economy's state and continue ecoing to the timing of the next target.

ok, thanks for letting me know.

@Nuggets said:

Everyone is responsible for activating / deactivating their own mods)

Actually we can update the init file in the game repo to mark a mod as deprecated so that the mod doesn't even get loaded into the game. I did this in my PR that implements feedback for the chat rework.
Also any mod author reading should know that the deprecation status is based on version number, so you can update your mod and then people can load it again.

That mod overwrites the entire chat.lua file, so it's unfixable and 4z0t has to rewrite it or game team has to integrate it.