Posts made by Nomander

@Sprouto I randomly found out that Monkeylord's SinkLower causes this, as for GC it doesn't use SinkLower and its target is rather messed up still so I don't know.

@Kilatamoro said in Wish-A-Mod Foundation:

A visible cooldown for Billy nuke on your com. Otherwise you have to look at the in-game timer and remember the cooldown duration.

The ACU model has a small animation for the missile hatch closing depicting the reload time. It's not visible at a distance, but it's good to know about. It also reloads in 30s and rebuilds in ~30s with T3 suite (or 3 T3 engis) so those numbers match up.

@TankenAbard The examples your own post fit the criteria of supporting an army and not replacing it itself, because those effects are way stronger when used by units with good DPS/HP stats compared to the same mass in pure SACUs.

As for replacing the ACU, that's a good thing as it allows using the cool things the ACU has on a large scale across multiple fronts (like 1v1) and without risking ending the game due to a simple shift in mass from the entire map concentrated to snipe the ACU.

You can hack around the issue with projectiles by setting the ACU's hitbox to very small so that it paths around units a bit better, and then creating an entity attached to the commander with a hitbox. Then you can override the new entity's OnCollisionCheck, OnCollisionCheckWeapon, and OnDamage functions with the ACU's versions.

There is an example of creating an entity attached to a unit in the Aeon T2 Torpedo Launcher script. I don't have an example of an entity with a hitbox passing damage to the base unit, although I know it's possible since giving props projectile collision was an experiment we did.

Monkeylord has a target bone on its turret, and as far as I know all surface targeting weapons can target the seabed layer too, so it is not an issue with seabed layer targeting or bones. I thought it was related to LayerChangeOffsetHeight, but changing that doesn't affect the targeting, it only affects how deep in the water the Monkeylord shows up with vision (which would be a good improvement by itself). So it seems to be entirely an engine issue with how weapons target things on the seabed but on the land layer (because if you disable AboveWaterTargetsOnly, then the weapon fires at underwater, seabed-layer targets just fine).

For example, although these two can hit and see each other, they won't do it without an attack command:

Slacking on the job when the commander isn't looking :

Make sure the "Always Show Custom Names" option is enabled in your game settings.

I'm not aware of any little arrow to open the map. Typically you enable the minimap using the map options button in the multifunction bar in the top left:

I've had this issue, there needs to be a minimum time for how long you have to hold left click.

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