Hi all,

I'm the guy that's responsible for FAF replay server, here to talk about stuff. Tl; dr if you have issues watching live replays and want to help out, scroll down to the bottom.

A long time ago there was the original replay server. That thing had a bunch of issues and had to be restarted every once in a while. Some time back I rewrote it and the new version has been running ever since. The replay server does two things: it streams live replays and it saves them to FAF vault. Right now saving replays works perfectly fine, but streaming doesn't quite work.

Many of you know that there's a bug with live replays where if you're behind on replays and the game ends, the replay ends abruptly. I know about this bug, but never managed to fix it. I can't reproduce it myself and I have absolutely no clue what causes the bug. Maybe it has something to do with how Python deals with TCP connections, maybe it's the FA executable acting up, or maybe there is some bug in the server I missed. I don't know. Here's a possible way to fix it.

Not long ago I rewrote the replay server again. This version is IMO simpler, more tidy and it's done in Rust rather than Python, meaning it's faster, multithreaded and easier to maintain. I spent some time polishing it, making tests and so on, the last bit that's left is testing it with a bunch of real games, then deploying it. Now, we held off for a while on that last step. From our (dev) perspective, current server has been working fine, in a sense that replays were saved properly and nothing crashed. Here's where you come in.

• First, I need to hear your opinion on live replays so us devs can gauge how serious of an issue this is.
• Second, I need a bunch of people for a testing session on the test server, maybe a mini-tourney of sorts, with some people playing and other people watching. This way I can verify that the server works fine, and with a little luck the live replay issue will be fixed as well.

I don't have any timeframe for the testing session, but we'll figure something out, maybe on some weekend. Come help out pls!

You'll end up with people flaming about kill stealing and accusing one another of stealing rating.

Jesus Christ people what are you even talking about

I know I don't do much dev work, but please, please listen to my heartfelt plea. I know it's hard to do when we're 100 posts deep into accusation and hurt feelings, but it's just a videogame. There's no reason for any of this drama to exist.

I'm not the kind of person that likes the "toxicity + inclusiveness + CoC" HR nonsense, but maybe we can accept some provisional rules to get this thing under control. I don't want another ZeP episode over nothing.

• Assume good faith, even when first impression tells you not to. We're all adults here, we should assume by default that we're not driven by pettiness, even if we sometimes lash out.
• Get angry in proportion. Being direct and sometimes offensive is fine, if the thing at hand warrants this approach. If something is bullshit about a thing, call it bullshit. If we ban getting angry, people will vent through underhanded office politics bullshit. OTOH no one is obliged to respond to every rant and people who rant all the time start being ignored, so save them for things that really matter.
• When in doubt, deescalate. If things get too heated, deescalate first. Get someone else to arbitrate. If you're a bystander, support the person that chose not to escalate, not in what they're arguing about, but in their stance. An argument is a dollar auction game and beyond some point betting higher should be made not worth it.

Can we all agree to this? I hate to see people who contributed this much more to FAF than me lose it over petty nonsense.

We all think it's hard. If reworking netcode is a piece of cake for you, then do it. You'll be a FAF hero.

Jesus @Askaholic relax. I don't care about complaints or people being annoyed, I just want to get something done.

Following recent balance forum rule changes, I decided to check how often beetles are actually built. So, I did the following:

• I grabbed 2000 replays from id 13370143 downwards, skipping IDs that gave me a 404.
• I ran the replay parser on replays with the following script:

  #!/usr/bin/fish
  for file in scfa/* 
   ./fafreplay commands $file -c IssueCommand 2>/dev/null | grep -q xrl0302
   if [ $status -eq 0 ]
   	echo $file
   end
  end | wc -l
  

  This basically counts the number of replays in which commands were given to a unit type "xrl0302" (or fire beetles).
• Finally, I counted replays in a similar fashion for a bunch of other gimmicky/niche units.

Here are the results:

• Beetles: 18
• Sparkies: 100
• Mercies: 79
• Janus: 187
• Continental: 99
• Spearhead: 42
• Shard: 76

Hey, an announcement. Here's my idea what we will do.

• We meet up on Sunday, June 6, 18:00 UTC. I think it doesn't collide with any events. That's a provisional date, if you have better suggestions please let me know.
• We meet on IRC and Discord. I'll be in Discord's #faf-testing channel. If IRC on the test server works, I'll also be in client chat. Voice chat is an option I guess, I'll be in one of Discord's voice channels. Apparently my mic sounds like a WW2 fighter pilot, but we'll manage
• We login to the test server. This means: log out if you have autologin enabled, select "Test server" in the dropdown menu and use 'foo' as password.
• We organize a few games, some people play, other people watch live replays, no particular format. I hope we can get maybe 4-6 games.
• I check if everything works as it should, you report if the short replay bug is gone. I go back to dev chat with results and we decide if and when we deploy the new server.

Let me know what you think.

This thing is good, it parses tick count real fast, it's thanks to this thing that we get to preview in-game time for replays, you should adore it

@Gatsik I took a look at your commits , and as a long-time Python client maintainer I officially bless them as good.

I've never seen a more wrong opinion about beetles.

A beetle snipe didn't set you back 4k mass when you could load up 4 onto a T1 transport and kill a full HP ACU 5 minutes into the game. You're not getting flak this early unless you're paranoid and immediately rushing T2 or keeping your ACU in your base the whole game. Flak doesn't work 100% of the time either. Mercies are a bit different in that people don't counter them properly, the best counter to mercies is scouting and suiciding in a handful of inties to kill the whole lot in 1 pass before they leave the base. Unlike a tanky transport, there's no defending that.

Unlike nothas, beetle drops can be stealthed and you can drop engies with them to steal the mass. I used to steal T2 and T3 mexes that way, of course it's much harder now with halved reclaim speed. It's also more cost-efficient than nothas assuming old beetle damage and much harder to stop once they land. Just like arty drops really.

Will setting target priority affect AlwaysRecheckTarget? If I'm sending a few tanks to kill engies and an enemy tank gets into range first I'd rather they switched to an engie when possible. Same issue with e.g. killing power in a raid, switching immediately vs. in 10 seconds after killing some tanks makes a difference.

I know, mea culpa. Last server update turned on my rewrite of the replay server and it's not working too well. I'll fix it and in the meantime I'll ask our server guys to revert to the previous version.

Some preliminary tests suggest it might be some invalid unicode fun. There's a clan with a tag J<invalid unicode character>p, can someone from there confirm if they're having trouble with their clanmates' live replays?

Is anyone else getting a "Premature EOF" error from the game when trying to watch live replays? I've been getting this error lately, and as replay server dev I'm curious to know whether it's a more widespread issue.

If we really wanted to, we could add an option e.g. for game host to not save a replay. We'd have to do some coding (switch to new replay server, add rabbitmq to it, add some simple "don't record this replay" logic between lobby server and replay server), but if there is a lot of interest in it, why not.
Metadata is another thing entirely of course.

From what I understood of the explanation, it's possible to handle stalling/not stalling color change in a single loop instance, right? So that we pay a tiny fixed cost for the stalling/not stalling logic, and the rest is handled by some shader magic. All the other logic like building units and such could then be placed in appropriate functions instead of being polled every tick. Then we'd keep the old behaviour without polling everything all the time.

There was some discussion on preserving current behaviour without the performance penalty. Maybe that's the best option?

Is it possible to change light color globally in some way, some shader magic or such? We could then have a single loop that checks stall status. All the factories and such would then only have to change the color when they start/stop producing, which is probably cheap.

We could maybe add some casual matchmaking queues? Something like 2v2 vs. AI or such, restricted to specific rating/number of games?

Or, again, we could just color friends and foes in the games tab. All of the convenience, none of the compulsion.