Yeah would be cool if it just automatically left queue

As you said there is the problem with possible rating manipulation. If you are that many people it's better to host a custom game. It should fill rather quickly when you already start with six people

Formations are definitely slower: [image: 1715316777320-formations.gif]

@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).

yeah battleships outrange t2 arty. So if you lose navy, there is absolutly nothing you can do to stop battleships from pounding you now. Atleast when t2 arty had more range you could shoot back, but you cant even do that now anymore.

@valstrax said in Paragon turn on/off button: I think he means that engineers reclaimed everything under the factory constuction zone quickly without needing to click each individual rocks or to do the slow way of patrol/attack move. Now, placing a factory down erases all "natural" reclaim (aka trees and rocks, wrecks still needs to be reclaimed) It doesn't erase rocks or other relative valuable props. Just individual trees and other props that are worth very little to no resources.

@melanol I don't understand why this is a bad outcome.

@beebob said in RTP Session drops. Potential mitigation.: the vast majority are drops of the UDP/RTP Session to a single or a number of players I think it's not one player dropping all other players, but one player dropping one connection to another player. @beebob said in RTP Session drops. Potential mitigation.: Since we can clearly see a successfully established RTP Session, which fails later on, we can assume that the firewall configuration is ok on all involved sides. That is a fallacy. Just because you were allowed to open connections does not mean, that the firewall doesn't decide to kill it later. Even the firewall configuration could change dynamically somewhere in the internet in between and you wouldn't even notice. (Simple example would be if you are on 4g and you are handed over from one station to the next). When all players are connected, all we know that it works right now. The big differene to telephony or other multimedia streams where ICE is used is: packet loss does not matter. If you switch over to a different connection and dropped a few packets, voice or image get blurry for a few seconds is fine. But in FAF it kills a game. @beebob said in RTP Session drops. Potential mitigation.: The ICE Log and the advanced ICE log only tell me that sessions are dropped. The operating doesn't know why a connection is dropped, thus it can't tell us. Hell, with UDP and TCP you don't even know WHEN exactly the connection dropped. @beebob said in RTP Session drops. Potential mitigation.: the ICE Client seems to utilize the full range of the High-Port spectrum I think we are using 40000-60000. We can reduce this, but what that help? I think the port range is mostly relevant for a system admin on a backend server trying to reduce the amount of open ports. @beebob said in RTP Session drops. Potential mitigation.: The ice advanced log is not detailed enough. Most of the ICE logic is not implemented by us, but by the library called ice4j. It's a blackbox for us. We don't know what it exactly it does and due to connection timeouts etc. it's also impossible to debug. We can't add any logging there. Apart from that feel free to make suggestions what we could log.

@mostlostnoob The previous exploit was based on the fact that Armies 1, 2, etc spawned on markers 1, 2, etc., so you could look at the spawn marker positions from the save file and associate them with an Army, identifying which player got what slot (Armies also contain player name and faction data). This got patched by FAF by scrambling the marker positions upon sim initialization for random spawn settings maps. This scrambling isn't reflected in the save file obviously, so there is no way for the UI to know what players spawned where, only where the spawn points are. The "... (Revealed)" spawn settings work by adding the newly scrambled positions to the Sync table for the UI to access and use to place the visual elements. My version of the reveal positions mod still looks at markers in the save file, but it doesn't show player names if the spawn settings scrambled the spawns.

@stormlantern xD, I rarely play lately and misunderstood the problem (translation issues)

What you're describing are icon mods with a different strategic icon for the TML structures. What's being discussed in this thread is the icon for the actual tactical missile projectile. I assume his point is that putting extra emphasis on the projectiles is consistent with the way a lot of people are already playing As long as it is aesthetically pleasing, I'm in favor of making the missiles more audible and visible

Just send labs or tanks with your engineers. it will slow your expansion but if your opponent rushed labs to snipe your engies and they don't pay off they're not ahead anyways

The ice adapter currently does not work without a game. The whole process is quite complicated, but the start is the following: faf-client launches ice-adapter and tells it to listen on TCP port 12345 ice-adapter opens a socket and waits for someone to connect to TCP port 12345 faf-client launches a game instance game and tells it to connect to TCP port 12345 game instances connect to ice-adapter on TCP port 12345 game instance tells ice-adapter it's UDP port is 23456 Now ice-adapter is ready to relay messages. This is the minimum requirement. For a good test game instance and faf client could be mocked away with simple CLI tools, which is a thing I am currently working on. But the game COULD be responsible for bad networking too... we don't know. Since we do binary patching on the exe lord knows what side effect a single change could have. The overall problem with the network stability is that the whole setup is a moving target. The users network connection change (LAN/WIFI, ISDN/ADSL/VDSL/Fibre/3G/4G/5G) The users OS change (Windows XP->7->10-11 + always patches) The users environment OS changes (firewalls, antivirus, ...) The game is patched. The faf client is patched. The underlying Java runtime is patched. The server is sometimes DDoSed.

They are a separate issue. Same with mods. https://github.com/FAForever/downlords-faf-client/issues/3120 https://github.com/FAForever/downlords-faf-client/issues/3118

@quantumtyphoon By all means report these when you see them! I've handed out several longer term bans for this kind of stuff.

Easiest way to make FTX mad is just to say UEF worst faction