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.

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.

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.

I already worked this out, among other options, see: https://github.com/FAForever/fa/pull/5971
In summary it adds 2 new lobby settings: disconnection share conditions and disconnection ACU share conditions.

• Disconnection share sets the share condition for a player after they disconnect. I would expect it to be the same as the share condition or fullshare, but all the other share conditions are available too.
  • To prevent abuse, when the disconnect share condition is applied depends on how the ACU is shared in Assassination.
    In non-assassination, it defaults to fullshare because I find it very unlikely that people can disconnect to avoid death in other victory conditions.
• ACU sharing determines what happens to an ACU after the player disconnects:
  • Explode: Like normal, the ACU explodes 10 seconds after the player disconnects.
    • It is an instantaneous condition, so if the ACU took damage in the last 2 minutes (to prevent abuse) the disconnect share condition is not applied (no abusing disconnect to fullshare a base in a normally noshare game).
  • Recall: Similar to Explode with the 2 minute timer, but the ACU recalls and doesn't damage anything.
  • Delayed Recall: Disconnected ACUs are shared to allies for 2 minutes or until 5 minutes pass in the game. The DC share condition is applied when the ACU recalls or dies.
    This is the competitive option in my opinion, which gives some time to stabilize and use the ACU, but limits the use time since there were concerns about having two ACUs being OP.
  • Permanent share: Disconnected ACUs are shared to allies permanently, and the DC share condition is applied when the ACU dies. This is prone to double gun ACU abuse or just easily saving the ACU for way later tele/com bomb, but it is the option that maintains the current game state the best, so if people don't find multi-ACU oppressive they can use this option.

Vault has v1.0 because v1.1 was removed for some reason, but you can still download it from the original forum post: https://forums.faforever.com/viewtopic.php?f=41&t=17047

I like @Deribus's solution of vet also giving HP proportional to the personal shield HP.

It's a simple, mildly consistent solution that avoids the issues of how to deal with shield recharge/shield regen and you can even ignore (S)ACU shield upgrades since they don't come with the unit by default and are already balanced with vet HP.

@cocainediesel
Teleport would be an overpowered preset due to very high total adjacency discounts.

Adjustable selection priority is a feature allowed by the implementation, since I don't know of any way to adjust engine selection priority outside blueprints.

I think custom presets are not necessary if the upgrades are all made useful and the presets available become best options for a specific purpose.

I wrote a reply last week and a fix PR but forgot to post lol:

I didn't see arty in that replay, but I found it in #23022644. Unfortunately it is desynced so idk if the replay shows the truth of what happened.

For those who didn't watch the replay it's dualgap and a player built arty up on the cliff next to the bases and the arty can't shoot because the muzzle velocity characteristics don't give a possible firing solution, as you can see in the screenshot there are very few possible firing locations:

What is the point of removing gateway assistance?
It's not like rushing any type of SACU is a giant issue like nukes:

• The counter is way easier to build in the form of PD or a T4 or T3 units you already have. On the other hand, SMD is going to take 2.5 minutes to load with assistance, and you can't do anything about it.
• SACU is way less impactful, you don't instantly lose your entire base once an SACU starts attacking if you were unprepared. You also don't lose economically if your opponent makes RAS SACU, you can beat them with mass fabs.
• SACU is way easier to scout because they have to walk to the front where there are less sams blocking spy planes.

Buffing combat SACU cost relative to RAS SACU can be done easily by shifting the costs from the base SACU to the RAS upgrade.

For underwater reclaim, I don't see why it's so unbalanced (especially as to make gateways unassistable), every faction has access to SACUs and should use them underwater when engis can't get to the front and there is lots of reclaim in a dead zone because of shifting frontlines. It creates new decisions around when to build SACU, how to kill the SACU with subs/torps, how to keep them safe, possibilities of building stuff with the SACU, and so on.
UEF SACU will be hurt by the base bp nerf in this rework because of random naval AA killing the engineering drones though.

Personally contextual keybinds would be great, you could rebind most of your order keys to build units when only factories are selected.

To make future integration easier you can look at the repository code at https://github.com/FAForever/fa and check out the code style of the recently changed files (some things like UI are very old and unchanged).

When a unit dies, the selection updates, which might trigger a selection deprioritizer mod.

@SMITHERS said in Map Gen reclaim numbers:

Nothing in the screen would give any indication that B would have an order of magnitude more reclaim than A, and that B and C would be close.

After the last server update I noticed that mapgen was generating orange dots in the preview for reclaim, so you can easily see if you got a high reclaim/boulder field prop generator.
For example this is a high reclaim density boulder field map from a random lobby:

Your low reclaim map is this:

Your high reclaim maps are this:

Fair enough for the last one, the basic prop generator definitely didn't generate enough dots to describe the 141k reclaim of high mass crystals around every cliff. It only marked the 75 and 150 mass rocks on the map, and ignored the 40-50 mass small crystals. Maybe its just a bad interaction between the basic prop gen and the crystalline biome.

Ctrl+right click to order a formation move was removed, so I don't know how you can be accidentally doing it.

@Defiant Yes you do avoid splash damaging multiple shields, but smaller shields also have less HP so they often lose most or all of their HP to overspill before the large shield actually goes down. Shields of the same tier but different factions don't have such an HP difference but they also can't easily cover each other fully. And in general, overspill just makes stacking many shields rather inefficient.

Still, this is the kind of the best way to get lazy shield micro, and it's a decent last barrier of protection in case your T3 goes down but the arty shell hits a T2 shield (especially Seraphim T2).

If overspill is removed, like with the nuclear repulsor shields mod, then hiding shields behind eachother by height becomes very powerful, and takes up less space than spacing out equal size shields. Such a technique is especially potent in that mod since it has absolutely huge shields.

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.

Eco Compendium by Cheeseberry

I don't think T2 fabs are far more efficient:

• For eco efficiency: T2 mass fabs have the same efficiency as T3 fab grids unless they're placed without shields adjacent to T3 pgens, a template which is very vulnerable to random bombers/arty/novax/tele and not dense at all.
• For space efficiency, T3 fabs win by a long shot (1.77x denser, and cleaner templates with pgen adjacency). This also means they are way easier to shield, with high HP on top of that.
• For adjacency efficiency, T3 fabs are great next to 2xT3 factories and T2 fabs are great on mex, with roughly equal payback time efficiency. T2 fabs on mex are more common because it's a lower investment cost and factories fit for t3 fab adjacency are rarer than mex with storage.

The differences in payback time are in a matter of seconds so I don't think there is a clear winner for which is better to eco with since the remaining differences are about T3 fab durability vs T2 fab low cost/unit (easier to build a small amount of and start paying back a little quicker).

For the other non-eco points:

• I don't think there is a big "consistency" issue with T2 fabs being T2. Lower tech units/structures are often cheaper and more efficient but less dense, and that doesn't mean they become completely obsolete when higher tech appears. Some examples: T1/T2 PD, T2 shields, T1 arty, T1 air scouts, T1 engineers, navy, T1 bombers, T2 gunships, mex upgrades, T3 units (compared to T4s), flak. T2 fabs fit into this pattern just fine.
• Making T2 fabs obsolete would be lame and taking out a dimension in how people can eco. Plain downgrade in gameplay.

You posted the ICE adapter and client logs, which aren't the game logs. The game logs are titled something like game_23325000.log, where the number is the replay ID. So you need to post the log from the game where the freeze occurred.
If the freeze can be replicated you can start a sandbox game by yourself and cheat in some engineers/hives to get a log.

It can also be useful to enable the FAF debugger in the client settings to get more details about what is crashing.

Maybe it's caused by your CryptoPro program, I see the dll is being used and something similar to these debug messages only appear in Google search results from the website cryptopro.ru.

Debug messages:
<capi20>Thread:function text xcode(dcode) (file:line)level: 0x1

<capi20>Thread:function text xcode(dcode) (file:line)level: 0x1

<capi20>Thread:function text xcode(dcode) (file:line)level: 0x1

<cspi>Thread:function text xcode(dcode) (file:line)level: 0x1

<cspi>Thread:function text xcode(dcode) (file:line)level: 0x1

<cspi>Thread:function text xcode(dcode) (file:line)level: 0x1

<support>Thread:function text xcode(dcode) (file:line)level: 0x1

<support>Thread:function text xcode(dcode) (file:line)level: 0x1

<support>Thread:function text xcode(dcode) (file:line)level: 0x1

Can you post the client log? It might show a reason why you can't generate/save the map.

Do you have a replay?