Posts made by Nomander

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:

Ravager friendly fire got removed so that they can be used as teledef like every other PD.

Chicken storm got fixed again to be able to hit friendlies, it's just that the storm's weapon is unable to track allies so it does way less damage since it misses a lot.

@Jip Since the manual obs kicking can break for random players as @CaipirinhaPilot pointed out (I also had it happen myself once) and that button goes straight to CLobby:EjectPeer it must be something wrong with the ICE adapter, LUA (lobbyComm.PeerDisconnected), or the engine, but I don't know how to debug that.

@CaipirinhaPilot I haven't noticed the debugger having a performance impact in real games. As for logs, I always play with the debugger and normal game logs are 200-300 KB while long games full of errors in the log are 500-1000 KB. The debugger only traces errors and provides info about what functions errored and what was passed into the functions. Along with that extra info, it can be useful since it can write errors that instantly crash the game that the normal logging doesn't write.

Can you provide the replay of the game where T2 arty doesn't work? Nevermind you posted it here: https://forum.faforever.com/topic/8003/bug-report-t2-stationary-arty-bugged-2-factions-aeon-and-uef-doesn-t-aim-nor-fire

This is about 0-75 ASF where micro is still possible without overkilling everything (stop command after that).
Btw landed ASF are a brutal opponent since they will always get behind you flying into them, so you could sandbox vs that. Sera/Aeon > UEF >> Cyb in terms of ASF DPS quality (Cyb can easily overkill due to low muzzle velocity, UEF can overkill due to firing 2 shots). If you can win with cyb vs landed sera 100v100 head-on its probably extremely good micro.
TL;DR: shift-g your asf to a move order nearby and behind them a bit before your cloud touches the enemy's.

Turnrate and speed try not to overshoot the target by slowing down when approaching the target. So to maximize turn rate you need to keep the move order behind the ASF and reduce your speed by placing the move order close to the ASF (but not too close, they do not start a turn within 5 distance of the waypoint). Keeping your speed low allows you to turn in a smaller radius because turn rate is constant.

Normally when you right click the game issues a formation to units, which means your move waypoints are actually spread out over the entire formation instead of onto one point (do the 3 console commands dbg navw dbg navp dbg navs to see navigation info). To get more control over your ASF you can shift-g every move order so that the waypoints go onto one point like you want them to.
The "every single move command" part is easy because you only need 2-3 move commands to do a 360 degree turn, since there isn't a very high max turn rate or high damping on the turn rate.
ASF formations were changed to be more spread out 2 years ago so you can't get the ultra tight formations like in ZLO's video. Shift-g makes tighter groups than what's in the video (because it has no formation).
Watch out for cruisers/flak/sams when you do that of course.
Imo shift-g makes ASF clouds survive better vs enemy ASF micro'd or even stopped, but nobody tested this idea.

Getting good turns is about timing (0.5 s command delay + turn time) and clumping ASF so they actually obey you. Basically want to get the turn finished right when the enemy ASF pass by you, so you start the turn a bit before the clouds touch in my experience.

Clicking in front of the enemy ASF is wrong, it doesn't maximize your turn rate or minimize speed. Your move orders are just a tool to get your ASF to move in the correct position and orientation, they don't guarantee a good result if clicked on top of the enemy (it just doesn't make sense).

I mentioned ASF don't turn within 5 range of their waypoint, which can explain why large formations suck to move but also allows for a cool trick where you just hover ASF and get 500 DPS shooting at enemy gunships/T4s/strats.

Game won't start despite HQ spawn being set in replay #22959277, seems to be a map issue.
Error running lua script: ...er\mods\ai wave survival\hook\lua\ai\aibehaviors.lua(19115): attempt to call method `GetArmyIndex' (a nil value) stack traceback: ...er\mods\ai wave survival\hook\lua\ai\aibehaviors.lua(19115): in function `GetAIOrHumanEnemyBrain' ...er\mods\ai wave survival\hook\lua\ai\aibehaviors.lua(19354): in function <...er\mods\ai wave survival\hook\lua\ai\aibehaviors.lua:19324>

Also it's frustrating to lose to SMD having issues with nukes:

• would be nice to have front-targeted nukes fire first so front SMD can kill front nukes instead of rear-targeted nukes.
• change the SMD projectile to bypass terrain and have better turning so that it is more consistent.
• Maybe create some new weapon code to improve SMD targeting so they don't lock up the target for so long. There is already some code to do that in the FAF repo applied to TMD so I'd start there (DisableWhileReloading bp field).