People keep asking for an ETA for Team Matchmaking, and until now our response has always been "we don't know." Well, I'm happy to say that I believe enough progress has been made to release an initial version in the near future!

My plan as of writing this is to have a working TMM "beta" version released to the FAF community by the end of the year. That is, if everything goes well, you should be able to play 2v2 matchmaker games with your friends in late December or early January.

WARNING: Do not expect everything to work perfectly! If you've been around for a while, you will be familiar with the usual chaos that ensues after a server update or game patch, and I expect this to be no different. While I hope it won't be the case, I will not be at all surprised if everything burns to the ground and we have to shut it off shortly after release in order to resolve critical issues.

That being said, here are some things you should know in the unlikely event of a successful deployment:

• There will only be 2v2 and 1v1 matchmakers (currently known as ladder).
• The ladder tab will be replaced by a more general matchmaker tab, in which you can join any active queue.
• There will be a party system. Players that queue together in a party are guaranteed to be on the same team.
• You can queue by yourself, and a team will be found for you.
• You can join multiple queues at the same time.
• The new matchmaker queue will have its own rating. This new rating will be based on your global rating, but it will assume higher uncertainty. This rating might not be displayed in game, or might be displayed incorrectly. You should not expect to know exactly what your rating is for this initial TMM release.
• We are NOT deleting your global rating. Custom games will continue to function exactly as they do now (provided there are no bugs).

If you are so anxious about playing TMM that you can't wait until the end of December, there will be a few opportunities to help with pre-release testing which I will announce in the FAF Discord (invite link in the client and on faforever.com). Just make sure you're subscribed to the Tester role by writing !subscribe Tester in the #bot-commands channel and you will receive a ping from me personally when we need you.

About a month ago I posted about our plans to release the Team Matchmaker towards the end of December or early January. I wanted to follow up on that post to say that we are still on schedule with that timeline.

At the end of this week, we will be entering an "opt-in beta" phase of the matchmaker release. This means sometime around the 25th of December we will make another forum post with a download link to a special version of the FAF client that you can use to start playing TMM. The matchmaker will remain in this "opt-in" state for an as yet undefined amount of time until we have had a chance to evaluate the matchmaker's performance and squash any remaining critical bugs.

The more people opt-in, the shorter the wait times will be, so please help me spread the news!

The matchmaker is now playable on FAF using the client build linked here, but before you download it please read over these important notes:

• If you do not see the 2v2 queue, restart your client. This is a known bug.
• To prevent game setup from timing out, make sure to install all maps in the map pool prior to queuing. For now this needs to be done manually.

Now that you have read the important notes above, you can download the client installer from here:
https://github.com/FAForever/downlords-faf-client/releases/tag/v1.4.0-RC2

After some 2 odd years of working on the team matchmaker I'm really happy to see it released to the community in a mostly playable capacity. Of course there is still a way to go until it becomes stable enough to be merged into the official client branch, but we are making progress.

The main feature that Team Matchmaking adds is a 2v2 queue which works similar to the current ladder queue. You can join this queue by yourself and be matched with a teammate automatically, or you can use the new party system to queue together with a teammate of your choosing. The 2v2 queue uses its own rating which is completely separate from global and ladder 1v1 ratings, however this third rating is currently only visible in the replay vault. Your 2v2 rating will be initialized based on your global rating (trueskill mean remains the same but deviation is increased) so it's likely that you will match with people who have similar global rating as you.

As I said in my previous post, for the time being the matchmaker will only be available by downloading the pre-release version of the client linked above. If you have any feedback or find any bugs, you can leave your reports in discord (#faf-testing), the forum, or GitHub.

There are a few known bugs that you may want to be aware of (please don't make bug reports for these).

• Sometimes queues randomly don't show up.
• Accepting an invite after the party owner has already started a queue will cause the party to become locked until that person leaves again (the owner can't kick them, and cannot leave the queue).
• There is no way to prevent people from sending you party invites (other than foeing them individually).

Special thanks to everyone who has volunteered their time and effort to make Team Matchmaking happen!
@biass
@BlackYps
@Brutus5000
@FtXCommando
@Geosearchef
@umbrasolis

And shout out to our amazing testers who helped us find countless bugs already!

Happy FAFfing and happy holidays!

Update: We will need to do a second test! Same time next week, details at the bottom of this post have been updated.

It's about that time! TMM for larger teams is nearing completion and we need your help playtesting it.

When we started work on the team matchmaker we decided to only worry about 2v2 so we could focus our efforts on getting all of the logistical things working first and then expand our algorithm later to handle larger teams. @BlackYps has been doing exactly that over the last few months, and now we are reaching the point where we think it is almost ready. But, we need A LOT of people to help us test it. At least 6 for 3v3, 8 for 4v4, etc (yes, its hard for us to get this many testers together).

So hop into the #role-selection channel on the FAF discord and react with the emoji to get reminders about the testing session. I will send out a reminder ping at the end of the week.

When: Sunday, June 27th @ 18:00 UTC
Where: FAF Discord in the #faf-testing channel
What: We will be queuing for games in our test environment. Your rating will not be affected.

Past test:

• Sunday, June 20th @ 18:00 UTC Completed

For the web app written by @PattogoTehen see https://fafafaf.github.io

Intro

Some time ago I started working on a replay parser library for FAF/SCFA replays, and now it's gotten to the point where I think it deserves a forum post.

This project started as my own rewrite of a Parser library written by @dragonite and quickly evolved to include a more versatile replay inspection tool. I think this tool can be useful for many people in the FAF community who want to understand the replay format and what information is/isn't available in a replay. I hope that by sharing it, we can figure out the last few unknowns about the replay format, and that people will be empowered to explore new ways of extracting useful data from FAF replays. I have been impressed by the work that @teolicy has done on this front so far (hopefully he will make a post about his work soon).

So what the heck does this tool do? Read on to find out...

Command Line Interface

The tool currently has 3 functions:

1. Unpack compressed fafreplay files into scfareplay files.
2. Show basic info about the replay. Mostly constrained to the replay header.
3. Show the replay command stream.

Unpack

I expect this to be the most widely useful feature of the tool, as a lot of other software that can parse replays only knows about the scfareplay format. The tool can handle the newest version of the fafreplay format as of release 0.5.0. Unpacking is very simple:

$ fafreplay unpack 9000556.fafreplay
Extracting...
Done
Writing 9000556.scfareplay
Wrote 12314246 bytes

Note that you do not need to unpack replays before using them with the other features of this tool. Files ending in .fafreplay will be converted in memory automatically.

Info

The info subcommand displays the sort of stuff you would expect to see for instance on the vault page. Stuff like the name of the map, the name of the players and what mods were used. It can also be configured to go into more detail with certain flags enabled.

$ fafreplay info 14210327.fafreplay 
processing replay: 14210327.fafreplay

14210327.fafreplay
Supreme Commander v1.50.3719 Replay v1.9

Operation Trident (00:25:40)
    Operation Trident

Mods
    Resource Rich v1

Team 1
    Civilians (AI) UEF
    Melanol (0) Cybran

With additional info enabled:

$ fafreplay info --mods --options 14210327.fafreplay
processing replay: 14210327.fafreplay

14210327.fafreplay
Supreme Commander v1.50.3719 Replay v1.9

Operation Trident (00:25:40)
    Operation Trident

Options
    Victory: sandbox
    Unit Cap: 1000
    Share: FullShare
    CheatsEnabled: false

Mods
    Resource Rich v1
        Increases resource production. (X2)
        Author: Gas Powered Games
        Copyright: Copyright � 2006, Gas Powered Games
        UID: 74A9EAB2-E851-11DB-A1F1-F2C755D89593
        URL: http://www.gaspoweredgames.com
        Location: /mods/resourcerich

Team 1
    Civilians (AI) UEF
    Melanol (0) Cybran

Note that this subcommand doesn't show every bit of information available in the replay header. It aims to provide more of a summary of the most relevant information.

Command stream

Here is where things get really interesting, although it requires a lot more work to extract useful information. The commands subcommand lets you explore the meat of the replay file.

By default only a small subset of commands are parsed as these are the most useful:

$ fafreplay commands 9000556.scfareplay --limit 10
processing replay: 9000556.scfareplay
Supreme Commander v1.50.3701 Replay v1.9

├── SetCommandSource { id: 0 }
├── VerifyChecksum { digest: a8377a57463c1191e0ae3447028f6d02, tick: 0 }
├── Advance { ticks: 1 }
├── Advance { ticks: 1 }
├── Advance { ticks: 1 }
├── Advance { ticks: 1 }
├── Advance { ticks: 1 }
├── Advance { ticks: 1 }
├── Advance { ticks: 1 }
├── Advance { ticks: 1 }

Total commands parsed: 10

However, you can select exactly the command types you are interested in with the --commands flag. For a list of all available commands run:

$ fafreplay commands --help

There are also a few options for printing additional information such as the offset of the command in the file (useful when paired with a hex editor) and the in game time at which the command happened.

For example to select only two specific commands and print additional info:

$ fafreplay commands 9000556.scfareplay --time --offset --commands IssueCommand ProcessInfoPair --limit 1000
processing replay: 9000556.scfareplay
Supreme Commander v1.50.3701 Replay v1.9

Time option used without including Advance commands, Advance will be parsed implicitly

0x000042c0 00:00:00 ├── ProcessInfoPair { unit: 0, arg1: "CustomName", arg2: "king_shrike" }
0x0000cc6a 00:00:06 ├── ProcessInfoPair { unit: 1, arg1: "SetFireState", arg2: "HoldGround" }
0x0000cc89 00:00:06 ├── ProcessInfoPair { unit: 0, arg1: "SetFireState", arg2: "HoldGround" }
0x0005e804 00:00:47 ├── IssueCommand(GameCommand { entity_ids: [0], id: 0, coordinated_attack_cmd_id: -1, type: BuildMobile, arg2: -1, target: Position { x: 667.5, y: 18.679688, z: 357.5 }, arg3: 0, formation: None, blueprint: "urb1103", arg4: 0, arg5: 1, arg6: 1, upgrades: Nil, clear_queue: None })
0x00062acb 00:00:49 ├── ProcessInfoPair { unit: 2, arg1: "SetFireState", arg2: "HoldGround" }

Total commands parsed: 1000

Keep in mind that determining the in game time requires parsing Advance commands and using the time option will force these to be included (but not displayed).

Some commands will have a number of fields called arg1, arg2, arg3, etc. This usually means I haven't figured out what they do or don't know a better name for them.

If anyone finds a replay containing a SetCommandCells command please send it my way as thus far I have been unable to locate any occurrences of this command.

Installation

I have compiled some binaries for Linux and Windows and hosted them on my server. If you don't feel comfortable downloading random exe's from the internet you can install pretty easily from source.

There are also Linux binaries built on each tagged release, but they are a little hard to track down in GitLab CI. Version 0.5.1 for Linux can be downloaded here.

From Source

The parser is written in Rust so you will need to use cargo to compile it. If you have cargo installed, you can run:

$ cargo install --git https://gitlab.com/Askaholic/faf-replay-parser.git --features=cli

You can also install the latest version published on crates.io with

$ cargo install faf-replay-parser --features=cli

but it may be less up to date than installing directly from git. I would recommend starting with the first command, and if something turns out to be broken, try the second command.

Note that you need to make sure that the ~/.cargo/bin directory is in your path to be able to run the tool once it's compiled.

Python Bindings

The parser is available as a python package for convenience. The bindings are written in Rust using pyo3.

Here's an example of using the bindings, copied over from the README with comments removed for brevety:

from datetime import timedelta
from fafreplay import Parser, commands

parser = Parser(
    commands=[
        commands.Advance,           # For the tick counter
        commands.VerifyChecksum,    # For desync detection
    ],
    save_commands=False,
)

with open("12345.scfareplay", "rb") as f:
    data = f.read()

replay = parser.parse(data)

print("Game time:", timedelta(milliseconds=replay["body"]["sim"]["tick"]*100))
if replay["body"]["sim"]["desync_ticks"]:
    print("Replay desynced!")

Note that the bindings themselves don't currently provide a function for converting from the fafreplay format to the scfareplay format because I didn't want to redistribute the needed dependencies. However, you can achieve this with the following bit of code (shoutout to @teolicy for porting this over from my Rust code):

import base64
import json
import zlib
import zstd


with open("somefile.fafreplay", "rb") as f:
    header = json.loads(f.readline().decode())
    buf = f.read()
    version = header.get("version", 1)

    if version == 1:
        decoded = base64.decodebytes(buf)
        decoded = decoded[4:]  # skip the decoded size
        extracted = zlib.decompress(decoded)
    elif version == 2:
        extracted = zstd.decompress(buf)

For more information see the project page at https://pypi.org/project/faf-replay-parser/.

Installation

Thanks to cibuildwheel and the fact that GitHub Actions can run Linux, Windows, and even MacOS instances, binary wheels for the latest version (0.5.1.post0) are available on pretty much all major platforms, and all cpython versions from 3.6 to 3.9, as well as pypy 3.6 and 3.7. Install with pip:

$ pip install faf-replay-parser

A source distribution is also available in case you are running something really exotic (or old). You will need to have rustc installed to build the package.

Rust Crate

This is actually the OG project, but it gets mentioned last because I'm guessing the overlap between people who are interested in extracting information from SCFA replays, and people who would rather do so in Rust than Python is quite small. If you happen to be such a person, let me buy you a beer sometime. Also check out this project's crates.io page for documentation.

Final Thoughts

I would be interested to hear what cool things people find in their replays, especially if they are things that seem to cause any errors with the parser. If you run into a panic (other than Broken pipe), let me know how you caused it.

I would also be curious about which commands people can find in their replays, as there are some commands which should theoretically exist, but I haven't found in any replays that I've parsed. There are also some arguments/bytes which seem to always be the same for a given command.

Furthermore, I wonder if the replay format for Forged Alliance is similar to that of the original SupCom, and if anyone has any vanilla SupCom replays that they could throw at the parser.

Of course I would also be open to some suggestions for improving the parser, ALTHOUGH please only make suggestions once you have a good grasp of the replay format. There is a lot of information that we all wish we could read straight from the replay file, but is actually impossible to obtain without fully simulating the game (which this tool cannot do because I have not re-implemented SupCom).

Project Links

Binary and Rust crate: https://gitlab.com/Askaholic/faf-replay-parser
Python Bindings: https://github.com/Askaholic/faf-replay-parser-python

One thing I want to say is that I think the candidates are severely over estimating the influence that the PC has over development. The dev team are all volunteers, we will work on the things that are fun/interesting for us and some PC coming in and telling people they need to rewrite xzy system "because I said so" is simply not going to happen.

The PC may request/suggest certain features from time to time (as may anyone) but there is no guarantee that it will be fulfilled.

@emperor_penguin said in New Player Councilor Discussion + Removal Announcements:

Emperor_Penguin’s Player Councilor Application
I have already talked with developers and have a feasible vision for TMM

Who exactly are these people? Because I certainly was not included in any such discussion and it would be me who is in the position of having to implement a large part of your idea, or ultimately, spend a lot of time reviewing and maintaining the code.

I would also not consider this:

lots of user-choice

to imply this:

Massively improve the TMM experience

The point of matchmakers is not to give people every possible option they might want (that's the point of custom games), it's actually to reduce barrier to entry by making many of the choices for them. Especially when you want to focus on the new player experience and new player retention, you want to make getting into a game as intuitive as possible. It's much better for that to be 1-click "Play Now" and have few choices over what the game settings are than to have 10-clicks for "Maybe play a game at some point if enough other people click the same stuff as you".

I am more inclined to agree with FTX on this issue. Letting the players decide everything is a fallacy in video games. If you always do what the majority of players says they want you end up with a hunk of junk, because the problem is, often times people don't actually know what they want (they think they know, but they don't). It is up to the PC to figure out what players want even though they don't know they want it, and then give it to them.

Finally, many further improvements to the matchmaker will be coming (eventually) regardless of who the PC is, because in fact, the driving force behind its development is --surprise-- the developers, not the PC. I'm honestly a little surprised that overhauling TMM (which we just recently built in the first place) is such a major part of so many candidates' platforms, since those promises are things that will almost certainly not be fulfilled.

@nine2 said in Calling for nine2 to resign as Promotions Councillor:

Basically everyone I talk to personally is fed up with attitude in FAF.

This may be a result of biased sampling. Like, of course you won’t hear from the people who are not fed up, because they aren’t fed up. Naturally the only opinion you hear will be from the people who are fed up.

Also there is the echo chamber effect of being more likely to surround yourself with people who share a similar view to you because naturally they make you more comfortable. That doesn’t mean they are the majority.

@swkoll sorry but your questions are off topic. This thread is for personal jabs only.

While the server was down anyways we took the opportunity to deploy the latest lobby release https://github.com/FAForever/server/releases/tag/v1.8.0. I've copied the release notes here for your convenience:

Summary

With this release we are finally making some progress towards upgrading our login flow by supporting token login in addition to the old style of password login. As an end user, you won't notice a whole lot. Future client versions will give you the option of logging in with the new method which is more secure, as it will use temporary tokens instead of directly sending your password to the lobby server (you still need to enter your password into the client though so it can fetch a token from the API).

In addition we've fixed a few bugs, done some internal cleanup, and added support for more integration with other FAF services which will eventually (TM) be relevant for Galactic War. Here are the noteworthy highlights

Other Noteworthy Changes

• Foes can no longer join your games
• Matchmaker games that fail to start will be properly cleaned up. This should also fix the game count on the website being way too high.
• Added a time delta to the queue pop timer message. Future client versions may use this to present more accurate queue times even when the system time is wrong.

Pull Requests

• Feature/#440 hydra token login (#784) [by @Sheikah]
• Add timeout to base game class (#798) [by @Sheikah]
• Use maxminddb directly instead of geoip2 (#792)
• Issue/#790 Nightly test deadline (#794)
• Issue/#778 Fix for foes in command_game_join (#793) [by @SpikeyNoob]
• Feature/#747 save additional metadata in game results (#782) [by eoinnoble]
• Issue/#771 send broadcast info to rabbitmq (#779)
• Remove metaclass for service creation (#785)
• Issue/#769 nightly test run (#781)
• Issue/#482 improve documentation (#753)
• Issue/#655 add rabbitmq to github actions (#775)
• Update dependencies (#774)
• Fix control server integration tests (#770)
• Issue/#560 Fix co-op leaderboard IntegrityError (#767) [by eoinnoble]
• Remove references to equilibrium #744 (#764) [by IanNaughton]
• Feature/#699 Add queue_pop_time_delta to MatchmakerQueue representation [by eoinnoble]

This will become irrelevant with the division system as the divisions reset after a certain amount of time.

Need to update the title to $735.04

I don’t think the game results are actually saved in the replay, so even if we had a bunch of replays where the bug occurred it wouldn’t help us. It’s also not that hard to reproduce the bugs with the game results. I have a pretty good understanding of what happens, but not why since that’s buried in the depths of the exe. I also wasn’t able to figure out a fool proof way of patching over it in the lua which is why there are certain edge cases like the draw bug that still happen.

It can also be done on demand with the OG web based parser https://fafafaf.github.io/. So for moderation purposes there isn’t a need to extract everything ahead of time. That would mostly be a ton of data that nobody looks at.

There are actually 2 different headers. The one added by FAF that you see there, and the original one included in the replay data. The original gpg header will have pretty much all metadata that you could want about the replay including game options, players, mods, etc. To get it though you’ll have to use a parser that knows the binary format of the header. I’ve written one and made a post about it here: https://forum.faforever.com/topic/1551/faf-scfa-replay-parser-library but there are a number of different implementations out there in a variety of languages.

Am I gonna have to copy/paste a link to Brutus’ post on the subject for you Thomas?

The scenario is like this:

• you ctrl-k your ACU, it explodes
• the explosion damage kills your opponents ACU

Expected game outcome: DRAW
Actual game outcome due to bug: VICTORY for the player who ctrl-k’d

This has nothing to do with game mechanics. It is about a bug in the engine which causes this to be incorrectly reported as a win for you. If we could, we would just fix the bug so the scenario would be rated correctly, but we can’t, mostly because we don’t have the source code and it’s very difficult to debug without that. Thus the only option is to use moderation to prevent people from abusing this to intentionally inflate their rating.

So if you are in the situation where you are about to draw your opponent anyways, you should not be ctrl-k’ing your ACU in order to abuse the bug and get yourself a false win.

You might be able to use the chat colors to help yourself remember. But it’s more of a hack than a solution. I think nicknames and additional notes would be nice. The question is, do we need that to persist across computers (in the server database) or can it be on a per client level (nicks/notes not synced between computers).

@keyser said in Make the "Draw Bug" a Bannable Offense:

the fix got reverted, because it made more games unrated

Well there wasn’t really a fix. The “fix” was to revert the fixes for the games being unrated, therefore making them unrated again .

Need to include the most important message: "e pls"