Okay, it's now just "x doesn't know y????" Over and over again. I think the initial proposal has been adequately discussed. Locked

@blade_walker That I have no issues with. Not sure how hard it would be to implement though. Probably pretty hard. And doesnt seem likely to get used a lot by players tbh.

@arma473 said in Engies Clean/Reclaim Mod: @jip How much would it cost to pay someone to figure out which bits to flip in the engine file to fix this nonsense forever? As much as it would cost to convince the balance team of it, and then a little extra

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.

seems like a lot of steps for a few lines that may be on screen for ten seconds, I play in windowed mode so I could just copy, minimize, paste in a second, and enjoy the salt in all languages, I have tried the phone thing but like phong says its not the easiest toption.

Sure, you can dive into that. I don't have a source on how the trueskill mechanism works though. Maybe someone else can point you to that. Regardless, I doubt that the issues you raise warrant any major changes to the system. It's such a niche case in which it hampers player enjoyment. To make the leaderboards more complex to cover that, doesn't seem proportionate to me.

hold the top 16 rated players at gunpoint and force them to play a massive tournament

@caliber agree

Can we not have a news post with the changes in the faf client? That would be helpfull too

No

Correct when the use custom style is ticked the end user is assuming all responsibility for the map generation and any "smart" behavior is turned off. So anything not explicitly specified is chosen at random from all the options.

@evildrew said in FAF(default) mode alternative: You can believe me when I say I have done a big effort to learn as much as I did already and I believe my accomplishments speak for themselves on this matter. You are here complaining cus u don't want to make your mod correctly then u go on about how your accomplishments speak for themselves?! Write your mod the way it is meant to be written then you can close this post and let your accomplishments speak for themselves.

I started my FAF career as a -700 after a half dozen games. It was pretty scary but didn't take long to turn it around. I would argue that people who quit FAF after losing their first half dozen or so games didn't really have their heart in it and were going to quit whether their rank said -700 or 300 after such a stretch.

@brutus5000 said in Removal of the Blinking lights: Can you tell us a little more how the new implementation avoids the performance issues of the original one? Great question! In general I don't think / am able to observe a significant performance issue with the previous or the current implementation when I reviewed it last month. In comparison to other changes such as #4539 or #3857 or the fact that a single formation (every order that involves some form of movement (!)) happily allocates 4kb of memory and can take several milliseconds to complete. I made a mistake by removing the blinking lights and by re-introducing it I'm rectifying the mistake . In general the current implementation follows a few principles: (1) No unnecessary memory allocations. Especially the type of 'use and forget' is exceptionally painful for performance. Not only is memory allocation on the heap slow in general, it also unnecessarily flushes the CPU cache. (2) No unnecessary table access. Everything in Lua that involves : or . is not as 'cheap' as it is in compiled languages and involves a hash operation in combination with following a pointer into (random) memory. This expensive! And it compounds since our Lua is interpret and not compiled. As a quick example #5524 increases the performance of the score graph at the end of the game by several factors and the primary reason for this was to cache table accesses. And unrelated to performance: (3) All logic is now isolated to components. One component for the brain. One component for units. This makes it easier to maintain and understand. I hope that answers your question

I'd like the fatboy be given the ability to go into turret mode, + shield radius/points but make it immobile.

at least for the moment where the league placements are only rarely displaying. Which I have to ask, if the new system isn't functional yet, why has it already supplanted the old system ? Are there cases where divisions of players don't show up even though they should? To my knowledge the system is fully functional. It can be that people don't have a placement yet because the current season started only recently.

@cocainediesel said in TML height needs to be lowered: Additionally, there's carveouts (see MaxHeightDiff in weapon blueprint) for weapons to have cylindrical rather than spherical ranges, so it was meant to happen in some cases. I don't know why that comment on the blueprint value is that way (gotta ask Hdt80bro) but the blueprint editor's comment for MaxHeightDiff says The maximum height diff range for the weapon. Keep in mind weapons are now cylinder in nature. and there is 0 history of talk about weapons having a spherical range as far as I know, so the blueprint annotation must be incorrect.