Interesting - I'll have to check if we even use SinkLower in our units.

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.

@PViddy The problem can never be solved with a SQL join. What happens in the API is this: perform the join, then filter. So first you join a game and get a result like: game player rating 1 A 1900 1 B 1900 1 C 1900 1 D 2100 2 A 1900 2 B 1900 2 C 1900 2 D 1800 3 A 2200 3 B 2100 3 C 2200 3 D 2000 And now you filter rating>=2000 on all records of that table. So the result would be this: game player rating 1 D 2100 3 A 2200 3 B 2100 3 C 2200 3 D 2000 It's easy to find a game where on participant matches a criterium. But there is no row-based filter in SQL that could require all players to be >=2k. For that you need either SQL subselects (which is not supported by our API logic for technical reasons) or we calculate somehting like min/max/mean rating during fetching the game in the API. The latter is generally possible, but not so simple with our API logic, because a game participant has potentially multiple leaderboards, so it need to return these KPIs per leaderboard (even though in practice each game right now has only one leaderboard).

500ms is still a reasonable minimum delay for FAF since the playerbase is scattered around the planet with the worst PCs and connections possible. Time spent on computation should be virtually nothing compared to the delays introduced by networking. In a 60fps game you only get 16ms to compute everything and render a frame, and 60fps is starting to be considered substandard now.

The reason it didn't work in your test game is because your mass bar was full when you tried to attack move reclaim the bottom right. And engies won't reclaim on attack move or patrol when the mass bar is too full