Thank you very much for this quality work, and the pulic open source release!
I have been watching that other rewrite, but the source code isn't public yet. It is also true that LLMs have made decompilation efforts much more tractable than in the past, and we are seeing these projects proliferate, so in my opinion it is a good thing to make an early release to avoid duplicating effort.

This looks feature-complete, though. Which brings me to my main question: I have a bit of trouble understanding how much of a 100% faithful reimplementation this is. Given that your compiler is VS 2022, and looking at the libraries used, this does not look like a byte-compatible decompilation (where even the final binary checksum would match). Admittedly, this would be a very high bar to achieve.

And I see that you have included a few fixes already, so:

• how do you decide on what to keep close to the original vs what to change?
• Do you have a roadmap or guidelines for what kind of changes would be accepted?
  • lua engine modernization
  • network stack modernization
  • platform ports (Linux, mac, gcc/clang)
  • UI improvements: multiple viewports/windows, shortcuts, menu/artwork changes, etc
  • Gameplay interaction changes: unit orders, etc (I quite like PA's drag-circle to build metal extractors, for instance)

There is probably room for multiple similar projects, though, and if you go for a more faithful approach while the other project is more open to changes, that is perfectly fine by me too
We will probably see multiple forks and total conversion, with source code access, I imagine that you have fully anticipated this!

Hi, thank you for working on this
You may have seen my answer on HN.

I tried this on Linux, it seems to be working fairly well. I haven't launched it for long.

This is a quick list of the issues I found, I have to go to bed, so I can't test more thoroughly right now:

• Bugs:
  • (fixed with caveats) (prerelease fixed but broke vsync) (edit, new): The main window stops rendering when the secondary window is obscured. I would expect only the secondary window to stop rendering.
  • (fixed in prerelease, broken lua not ignored) One of my friends (on windows) had an empty window after clicking "Multiplayer LAN"
  • (fixed in prerelease) I am on sway (Wayland), the join code was not copied to the clipboard. Pasting works fine.
  • (kinda fixed, crash on game start, to debug) I had a crash when joining another game, it should at least be an in-game message if the map is missing (ideally transmit it, of course):

    2026-10-24T23:06:42.394883Z ERROR rts_core_engine: engine start failed: runtime error: scenario /maps/sentina iii.v0001/sentina iii_scenario.lua is not in the VFS: pass a VFS path like /maps/<folder>/<name>_scenario.lua (vault maps need --vault <dir>)

  • (fixed in prerelease) No stats for unit-related data such as units built, killed etc.
  • production numbers kept blinking when changing quickly, which is annoyingly attentions grabbing
  • (fixed in prerelease) (unsure, TBC) it seems to me that the window content (ground textures, etc) was being stretched when I full screened the window (using a DE shortcut). I didn't double check, but it looked like the window aspect ratio affected the textures' aspect ratio.) Looks like the window aspect ratio affects the FOV. This may be a deliberate choice to accomodate for wide screens, I am not sure it is intended to be noticeable for around 40 px more at 1080p.
    
    
• Nitpicks / suggestions:
  • (invalid) * (edit2) please print the port number next to the connect string, as it is hard to identify when set to auto (I believe it could also be added to the string) Dev reply: port number does not matter with a connection code.
  • (workaround in prerelease) "Exit to windows" is not appropriate in the menu when not running on windows
  • status bar info (ticks/s mostly I think) keeps shifting the pause button left/right, I think some values could use fixed-width printing (padding left with spaces
  • (fixed) You could have a look at the following script to locate the SC:FA folder, it worked well for me (flatpak Steam, library in a secondary disk). It also puts faf data in $HOME/.faforever (xdg dirs would be better)
  • Multi-monitor works well (even detected my monitors on Wayland), but:
    • (fixed) Why not allow windowed mode on the secondary display?
    • Is it really necessary to restart the game when changing video options?
    • It was not clear to me what the other options did.
    • To simplify usage, would it be possible to add a button to open a new window? This would open a floating window (PiP), with controls to detach it from the game window, pin, resize it, tile, etc. Honestly I would just replace the minimap with this and offer additional controls
    • It may be interesting to have a different unit selection per-screen, with the HUD interface, etc: one screen focused on your base, the other on the battlefield

New batch of issues (edit 3):

• (fixed in prerelease) Slow FPS on the "edit restrictions" screen, when hovering over the table (GPU time shoots up, maybe some memoization or pre-computing would help?)
• (fixed in prerelease) Unable to drag waypoints in a patrol itinerary (triggers selection area instead)
• Units are trying to follow patrol paths too closely: they will stop at waypoints (visible on the satellite), or slow down and bunch up to turn.
• (fixed in prerelease) The T4 aeon artillery (salvation) seems to point its cannon opposite to the firing direction
• (fixed in prerelease) Submarines do not seem to submerge
• (fixed in prerelease) The cheat menu can only spawn naval units over land
• ETAs displayed on buildings are sometimes wrong (and different constructors can report different ETAs, they get drawn on top on another when multiple engineers are selected). Running out of power when constructing triggered it for me.
• (fixed in release) No construction queue for ACU upgrades or mobile factories
• No drag-and-drop to reorder queues (this may be a nitpick/nice-to-have)
• (fixed in release) CPU times goes from ~2ms to ~4ms when moving the mouse around (on empty terrain)
• (partially fixed in release) I think that obscuring the window drops the FPS to 0 (reported above with secondary window), which... Pauses the simulation? To confirm, but I am not sure this is intended. Possibly the cause of high CPU time on my second screenshot.

We'll try to run an actual multiplayer game soon to check this out.

Looking forward to the source code release
I am also curious what you think of this other reverse-engineering effort. Probably worth contrasting findings.

Thank you for your answers.

Goal and idea of the project is to have byte-to-byte replay and simulation parity, including visuals - which is fully achieved today for whatever I did tested myself.

I did see several mentions of MSVC in the repository readme, so I was a bit worried there, but it is good that the project can already be compiled with clang.

Everything is kept to original, nothing changed for sim or rendering that changes visual look from the original.

Gotcha. It should be possible to put test assets in the original, take a screen capture, and replay with the test assets in the CI to catch visual bugs, like what emulators do, if you really want to ensure 1:1 fidelity.

If you mean to the repo - I will accept changes that fixes bugs that doesn't affect simulation or any other PRs that fixes things I did missed to repeat original game behavior.

I really meant your repository. There are so many improvements I could think of, more or less user-visible. I listed some, but less-visible improvements could include multi-monitor improvements, steam input integration to make it easier to play on Steam Deck, Discord/Steam rich presence integration, better integration with FAF (integrated lobby, control it via IPC to avoid restarting the game, etc).

Testing Linux build also one of the TODOs, since compiler are clang it's possible but will require x87 math adjustments for the platform.

Yeaaah... I imagine that the game relies on system libraries? Probably not on the windows ucrt "universal c runtime" otherwise we would have seen desyncs on wine, but x87 definitely need some focus. It should be possible to load windows libraries (extracted from MSVC redist) with a small shim (or compiler options) to adjust the calling convention. That would not be my prefered approach though, as it makes it more complicated to support non-x86 platforms (arm) with native code. The other option is to link another controlled FP library, which behaves the same across platforms. This would break replays (the old library can still be embedded to read them on Windows, but new replays would be generated with the new one, unless additional trickery is performed). But you probably thought about all this already.

Something else came to my mind: It should even be possible to compile this to webassembly, and, with a few changes, have a replay player in the browser. The hard part is that assets are copyrighted and distributed with the game, but at least event (commander destruction, experimental unit built, game stats) can be extracted, and maybe a strategic view/minimap provided with custom assets? I am fairly new to FAF (not to supcom, but these decomp projects attracted me to FAF), but I imagine that the community would value that?

@Saver this should probably be written in a document somewhere, but:

1. Grab the latest release from the GitHub releases page
   a. The most recent one should be on top (biggest version number)
   b. look at "assets" at the bottom. You may need to expand the list.
   c. Grab the one for the correct platform (windows x64, Macos, etc)
2. Extract it somewhere
3. Launch the executable, it should auto detect the original game and FAF locations if they are installed (if auto detection fails, they can be specified manually, but it's a tad more complex).
4. Bonus: a game.log file is created next to it. Upload it of you encounter any issues.

@Saver this should probably be written in a document somewhere, but:

1. Grab the latest release from the GitHub releases page
   a. The most recent one should be on top (biggest version number)
   b. look at "assets" at the bottom. You may need to expand the list.
   c. Grab the one for the correct platform (windows x64, Macos, etc)
2. Extract it somewhere
3. Launch the executable, it should auto detect the original game and FAF locations if they are installed (if auto detection fails, they can be specified manually, but it's a tad more complex).
4. Bonus: a game.log file is created next to it. Upload it of you encounter any issues.

https://forum.faforever.com/topic/10502/projects-i-found-that-are-redoing-supreme-commander-forged-alliance

If you are into VR, There is nothing technically preventing a VR mode for the rewrites: have the battlefield at your feet, or feel tiny next to a (very low poly and low res textures) commander.

@warrenkc said:

https://github.com/Draiget/faf-re

The forum topic is https://forum.faforever.com/topic/10497/sc-fa-moho-engine-sources/

Thank you for your answers.

Goal and idea of the project is to have byte-to-byte replay and simulation parity, including visuals - which is fully achieved today for whatever I did tested myself.

I did see several mentions of MSVC in the repository readme, so I was a bit worried there, but it is good that the project can already be compiled with clang.

Everything is kept to original, nothing changed for sim or rendering that changes visual look from the original.

Gotcha. It should be possible to put test assets in the original, take a screen capture, and replay with the test assets in the CI to catch visual bugs, like what emulators do, if you really want to ensure 1:1 fidelity.

If you mean to the repo - I will accept changes that fixes bugs that doesn't affect simulation or any other PRs that fixes things I did missed to repeat original game behavior.

I really meant your repository. There are so many improvements I could think of, more or less user-visible. I listed some, but less-visible improvements could include multi-monitor improvements, steam input integration to make it easier to play on Steam Deck, Discord/Steam rich presence integration, better integration with FAF (integrated lobby, control it via IPC to avoid restarting the game, etc).

Testing Linux build also one of the TODOs, since compiler are clang it's possible but will require x87 math adjustments for the platform.

Yeaaah... I imagine that the game relies on system libraries? Probably not on the windows ucrt "universal c runtime" otherwise we would have seen desyncs on wine, but x87 definitely need some focus. It should be possible to load windows libraries (extracted from MSVC redist) with a small shim (or compiler options) to adjust the calling convention. That would not be my prefered approach though, as it makes it more complicated to support non-x86 platforms (arm) with native code. The other option is to link another controlled FP library, which behaves the same across platforms. This would break replays (the old library can still be embedded to read them on Windows, but new replays would be generated with the new one, unless additional trickery is performed). But you probably thought about all this already.

Something else came to my mind: It should even be possible to compile this to webassembly, and, with a few changes, have a replay player in the browser. The hard part is that assets are copyrighted and distributed with the game, but at least event (commander destruction, experimental unit built, game stats) can be extracted, and maybe a strategic view/minimap provided with custom assets? I am fairly new to FAF (not to supcom, but these decomp projects attracted me to FAF), but I imagine that the community would value that?

Thank you very much for this quality work, and the pulic open source release!
I have been watching that other rewrite, but the source code isn't public yet. It is also true that LLMs have made decompilation efforts much more tractable than in the past, and we are seeing these projects proliferate, so in my opinion it is a good thing to make an early release to avoid duplicating effort.

This looks feature-complete, though. Which brings me to my main question: I have a bit of trouble understanding how much of a 100% faithful reimplementation this is. Given that your compiler is VS 2022, and looking at the libraries used, this does not look like a byte-compatible decompilation (where even the final binary checksum would match). Admittedly, this would be a very high bar to achieve.

And I see that you have included a few fixes already, so:

• how do you decide on what to keep close to the original vs what to change?
• Do you have a roadmap or guidelines for what kind of changes would be accepted?
  • lua engine modernization
  • network stack modernization
  • platform ports (Linux, mac, gcc/clang)
  • UI improvements: multiple viewports/windows, shortcuts, menu/artwork changes, etc
  • Gameplay interaction changes: unit orders, etc (I quite like PA's drag-circle to build metal extractors, for instance)

There is probably room for multiple similar projects, though, and if you go for a more faithful approach while the other project is more open to changes, that is perfectly fine by me too
We will probably see multiple forks and total conversion, with source code access, I imagine that you have fully anticipated this!

Hi, thank you for working on this
You may have seen my answer on HN.

I tried this on Linux, it seems to be working fairly well. I haven't launched it for long.

This is a quick list of the issues I found, I have to go to bed, so I can't test more thoroughly right now:

• Bugs:
  • (fixed with caveats) (prerelease fixed but broke vsync) (edit, new): The main window stops rendering when the secondary window is obscured. I would expect only the secondary window to stop rendering.
  • (fixed in prerelease, broken lua not ignored) One of my friends (on windows) had an empty window after clicking "Multiplayer LAN"
  • (fixed in prerelease) I am on sway (Wayland), the join code was not copied to the clipboard. Pasting works fine.
  • (kinda fixed, crash on game start, to debug) I had a crash when joining another game, it should at least be an in-game message if the map is missing (ideally transmit it, of course):

    2026-10-24T23:06:42.394883Z ERROR rts_core_engine: engine start failed: runtime error: scenario /maps/sentina iii.v0001/sentina iii_scenario.lua is not in the VFS: pass a VFS path like /maps/<folder>/<name>_scenario.lua (vault maps need --vault <dir>)

  • (fixed in prerelease) No stats for unit-related data such as units built, killed etc.
  • production numbers kept blinking when changing quickly, which is annoyingly attentions grabbing
  • (fixed in prerelease) (unsure, TBC) it seems to me that the window content (ground textures, etc) was being stretched when I full screened the window (using a DE shortcut). I didn't double check, but it looked like the window aspect ratio affected the textures' aspect ratio.) Looks like the window aspect ratio affects the FOV. This may be a deliberate choice to accomodate for wide screens, I am not sure it is intended to be noticeable for around 40 px more at 1080p.
    
    
• Nitpicks / suggestions:
  • (invalid) * (edit2) please print the port number next to the connect string, as it is hard to identify when set to auto (I believe it could also be added to the string) Dev reply: port number does not matter with a connection code.
  • (workaround in prerelease) "Exit to windows" is not appropriate in the menu when not running on windows
  • status bar info (ticks/s mostly I think) keeps shifting the pause button left/right, I think some values could use fixed-width printing (padding left with spaces
  • (fixed) You could have a look at the following script to locate the SC:FA folder, it worked well for me (flatpak Steam, library in a secondary disk). It also puts faf data in $HOME/.faforever (xdg dirs would be better)
  • Multi-monitor works well (even detected my monitors on Wayland), but:
    • (fixed) Why not allow windowed mode on the secondary display?
    • Is it really necessary to restart the game when changing video options?
    • It was not clear to me what the other options did.
    • To simplify usage, would it be possible to add a button to open a new window? This would open a floating window (PiP), with controls to detach it from the game window, pin, resize it, tile, etc. Honestly I would just replace the minimap with this and offer additional controls
    • It may be interesting to have a different unit selection per-screen, with the HUD interface, etc: one screen focused on your base, the other on the battlefield

New batch of issues (edit 3):

• (fixed in prerelease) Slow FPS on the "edit restrictions" screen, when hovering over the table (GPU time shoots up, maybe some memoization or pre-computing would help?)
• (fixed in prerelease) Unable to drag waypoints in a patrol itinerary (triggers selection area instead)
• Units are trying to follow patrol paths too closely: they will stop at waypoints (visible on the satellite), or slow down and bunch up to turn.
• (fixed in prerelease) The T4 aeon artillery (salvation) seems to point its cannon opposite to the firing direction
• (fixed in prerelease) Submarines do not seem to submerge
• (fixed in prerelease) The cheat menu can only spawn naval units over land
• ETAs displayed on buildings are sometimes wrong (and different constructors can report different ETAs, they get drawn on top on another when multiple engineers are selected). Running out of power when constructing triggered it for me.
• (fixed in release) No construction queue for ACU upgrades or mobile factories
• No drag-and-drop to reorder queues (this may be a nitpick/nice-to-have)
• (fixed in release) CPU times goes from ~2ms to ~4ms when moving the mouse around (on empty terrain)
• (partially fixed in release) I think that obscuring the window drops the FPS to 0 (reported above with secondary window), which... Pauses the simulation? To confirm, but I am not sure this is intended. Possibly the cause of high CPU time on my second screenshot.

We'll try to run an actual multiplayer game soon to check this out.

Looking forward to the source code release
I am also curious what you think of this other reverse-engineering effort. Probably worth contrasting findings.