Posts made by Nomander

There's a few console commands that adjust the pathfinding budget starting with path_, maybe those have an effect.

For FAF the file blueprints-ai.lua already calculates threat levels from unit stats, you'd want to overwrite the function SetThreatValuesOfUnit in there to properly replace the threat level calculation. This also means you don't have to worry about mod load order since that threat calculation is done in PostModBlueprints.

There are MANY combinations and control values that can impact the actual DPS calculation - it goes far beyond the 'RateOfFire' blueprint value, which many consider to be the 'be all and end all' of DPS calculations. It is not - and anyone who has done sufficient weapon 'rigging' can tell you the many pitfalls, in the blueprint values, that can lead to an erroneous DPS value.

@Sprouto There's a rather comprehensive DPS calculation in FAF's unitviewdetail.lua, I think it's only missing fire rate when it is limited by energy requirements or animation speed, and if I remember correctly some rounding for some stat should be floored instead, but it's still quite complete. I should really put that calculation in a library.

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

@crustaceanMODE
Recall should be fixed after the recent patch 3815.

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.

Shield	AssistRegen/BP	AssistRegen/Mass
Sera T3	2.80	6.06
UEF T3	2.18	4.40
Aeon T3	2.50	5.69
Cybran ED5	2.33	5.19
Cybran T3 ED4	2.17	4.13
Cybran ED3	1.87	4.35
Cybran ED2	1.47	3.29
Cybran T2 ED1	0.75	4.38
Sera T2	2.55	6.07
UEF T2	2.00	5.11
Aeon T2	2.30	6.07

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?

Yeah 3.75 works easily but the tricky part is that if the offset is too much then units will target the underwater unit thinking it is on land, while its hitbox is covered by water (dbg c in console to see collision boxes). I think they start ignoring that unit after they hit the water too.

The "ACU Self Destruct Confirm" mod by @HollowSubmarine could be a starting point/inspiration.

You can also interrupt pathfinding with engis on attack move (or SACU/ACU on patrol iirc) and they will lock on to and reclaim a single target using fac attack move range, which can be useful for this scenario.

The LayerChangeOffsetHeight in the unit blueprints offsets the depth at which the unit is considered underwater relative to the root bone, maybe its value is not ideal for all units.

The OnDamage error spam is from the "No Friendly Fire" mod. There is a fixed version by CatmanFS "No Friendly Fire + fix for log spam".

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: