Supcom/Moho engine rewrite

Downlord

This is fantastic! When I heard about recent AI reverse engineering progress, I instantly thought of Moho. So happy that someone is already doing it!

GaryTheGoat

This is great!, I was hoping someone would take on this challenge you get my vote and support! keep going!.

Brutus5000

Well I ususally say pics or didn't happen. But in this case I'd rather say code or didn't happen

Darien_

@Brutus5000 said:

Well I ususally say pics or didn't happen. But in this case I'd rather say code or didn't happen

This. Please share the code!

wilson_

Did I just read that we could potentially get rid of p2p?

lan94

Great Work! I was happy to play it easily on my Mac mini. Very impressive what has been done so far. I came along with these bugs so far:

The integrated mod "x2" which doubles the incoming resources seems not working, as the resources staying normal even when this mod is activated
Sometimes units are built and they are invisible. This happens when you select e.g. factory to build 10 technicans or other units, then the first unit is normal as expected, but every further unit is invisible. Often these units staying stacked in the model of the factory. I didnt tested all factories, but when building multiple T3 battleships, they are not invisible, but e.g. on air factory i got this error with multiple units.
When Cybran T4 Soul Ripper is in attack range of an enemy unit, it prioritizes the attack more than moving commands by me. It is then hardly control-able. Often it is attacking the enemy until it is dead, and then i can control it again.
Is the damage of the T3 Anti-Air-Sam-Cannon normal? When 5 SAMs attacking 1 T3-Gunboat and they needed 30 seconds to finish it, the damage seems kinda small.
Air-Transporter dont seem to be able to transport units? Units can be selected to support the transporter, but i cant get them into the transporter.
When air troops are dying, they are crashing into the ground, and sometimes their object is still clickable, showing 0 lifepoints.

CDRMV

Truly very impressive.
It’s genuinely fascinating to see what this community can achieve through a great deal of ambition and experimentation.
I’m excited to see what this project will bring about in the future.
Keep Up the great Work.

SlightlyGrilled

The Binaries

Mac
https://upload.disroot.org/r/XHFvbT4s#ZaPwUTGTjpmK0IlKXyW8N1f8c9Qu5JgVboD8USbDzxk=
Windows
https://upload.disroot.org/r/M0EnT4kb#Ws6EFNfzgC0s/xGGYsIdzgoQNjfmCodVQ6fozlJDfjQ=
Linux
https://upload.disroot.org/r/tuUFTLuT#27oozpFjzTrcIzBS1lY/AeicAgDbtqv5ns460MpwebQ=

Picture in picture

This is a cool new feature, I was mainly thinking of casters for this.
Now on major events, such as your team building an experimental, or an acu dying, you get a picture popup that you can click on to view the location. it also supports modding, so modders can make new events, I've included an example mod that tells you when your acu is below 10% hp. (I'll make a follow up post about this, as I'm not sure i like the api...)
of course this is all toggleable in the settings, and I'm super open to feedback.

Timeline on replay

Another really cool feature, that was mainly me thinking about casters again. I've added a timeline view, that lets you move to any part in the game, it also highlights key events. Such as (ACU death, Exp built).
Allows you to zoom to selected events, and will shift the camera to just before.
It does support rewind, but at the moment it restarts the game and fast forwards, in the future we could save out keyframes, but i want to avoid game serialisation until later as its a source of endless bugs

I have more ideas for this one, but just wanted to get something basic in for now.

like above this is a setting as well, it can be on either main or second screen, or just turned off.
You can see a video here, although the ai playing makes the scrubbing a bit slow
https://youtu.be/aOz7DxAPm28

Split screen! and Dual screen!

This was a fair amount of work, and I'm sure will need more testing. It will work on different refresh rate screens with each screen running at its max speed. You can now in the settings set which display is main and secondary screen.
If any one has a 240hz-480hz I'd love to know if it can go that fast

Mod support!

I haven't tested with blackops, but certainly the inbuilt x2 resources now work

Lua documention!

This one is also really nice.

thanks to rust macros, the apis from the engine to the lua, are now auto generated, and output both to luau type file and a emmy lua file that faf uses, I love this sort of feature, it should help things stay in sync, and of course helps me compare my api to fafs
here's an examples of it on the rust side, then the luau and the emmy lua output

this rust adds the ChangeMaxRadius method to the weapon class, that comment is auto put in to the lua docs too

    lua_method!(lua, moho::Weapon,
        /// Sets the weapon's maximum range (world units) and refreshes the unit's attack range.
        ChangeMaxRadius = |lua, (this, r): (Obj<moho::Weapon>, f64)| {
            with_state(lua, &this, |w| w.max_radius = crate::engine::sim::math::from_lua(r))?;
            refresh_attack_range(lua, handle(&this)?.unit);
            Ok(())
        }
    )?;

Then the generated luau types (a snippet of them)

declare extern type Weapon with
    --- A weapon dies with its unit.
    function BeenDestroyed(self): boolean
    --- True if the weapon is enabled and its fire clock has run out.
    function CanFire(self): boolean
    --- Overrides the weapon's damage.
    function ChangeDamage(self, damage: number): ()
    --- Sets how far (degrees) the turret may be off target and still fire.
    function ChangeFiringTolerance(self, t: number): ()
    --- Sets the weapon's maximum range (world units) and refreshes the unit's attack range.
    function ChangeMaxRadius(self, r: number): ()

the emmylua type

--- Sets the weapon's maximum range (world units) and refreshes the unit's attack range.
---@param r number
function weapon_methods:ChangeMaxRadius(r) end

while I'm sure this is far from perfect, it's just a fantastic example of little things that really can help a project stay manageable, in another time/life, this would have all been manual work of someone.

Merge order lines for units sharing a first waypoint.

No more 10k lines over the map causing massive lag

Perf

(I always strive for faster, not only does it mean higher end pcs will run it faster, but it unlocks lower end devices, which is just as important)

Faster startups for lua transformaions

in order to support fafs old lua under a new lua vm, I have to translate the lua.
some things can be done very fast and quickly using find and replace, others require full parsing of the lua scripts which is really slow, I now do a quick check before fully parsing a file to see if the find and replace route works

scripts/translate all FAF .lua (2,798 files, total cpu time over all cores) 538 ms -> 129 ms
scripts/translate Unit.lua 12.1 ms -> 6.65 ms
Headless startup, user CPU 3.62 s -> 2.68 s
Script prewarm wall time (16 cores) 289 ms -> 196 ms

Better thread pool allocation

I've then rejigged the thread pools for the engine, taking in to account low core machines, this has helped the startup time on low core machines. (its a small amount, but poco a poco
This is limiting the cores to 4
Headless time to game start 2.23 s -> 2.12 s
Script prewarm 726 ms 624 ms

Texture loading

Texture loading, textures are now all streamed as efficiently as possible to the gpu, minimising copies, and shifted off the main render thread to worker threads
Render thread upload models ~675 ms -> ~60 ms
Worst frame in upload models 13–21 ms -> ~1 ms

total texture load time (this is limited to 4 cores)
1,465ms -> 658ms

Terrain loading

we now load terrain much faster, and also much less work is done on the render thread
and when map elevation is changes such as placing a building.

81km map (again on a simulated 4core machine)
map textures uploaded (time from launch) 8.4–11.8 s -> 1.4–1.8 s
terrain change, render thread 23–38 ms -> 0.17–0.64 ms (worker: 4–8 ms)

Bugs and features

killed units now stop showing their stragic icons and are no longer selectable
lods are now based on the distance to the plane of the camera, instead of the camera location, so no more circles of trees
all of fafs graphics settings are now supported (with bumps to shadow mapping as I now support 2k shadow maps instead of 1k)
we have edge of map mesh now!
paused builder updates progress and finishes when assisted
reclaim progress bar now
units move clear of a build site before construction starts
build range needs only touch the target's build skirt
units being built in a factory are no longer selectable
box selection leaves out engineers when other units are in the box
Novax satellite beam reaches the ground, satellite holds its height as well, instead of bobbing up and down
- part of this fixed area damage, which i think effected other units as well
preferences are saved, and FAF's preferences are now imported on first launch
reclaim labels show (Alt-R)
interface settings now work
Half-built Fatboy - engineer assist offers repair, not the transport cursor
factory assist takes the queue and destination of the factory it assists
fixed no borderless windows on windows (how truly awful I let this even pass... serves me right for mainly testing on windows)
fixed bombers not dropping their bombs
fixed auto attack on idle, e.g. bombers moving around in their range to hit things

SlightlyGrilled

@Brutus5000

I 100% want to make this open source, no worries, I just want a bit more time, as I'm well aware that open sourcing it will open the floor gates. I would also be interested in how this can be transferred over to the faf team as well. I do believe this has real merit to replace the base engine. it already demonstrates a large amount of the game working, and absolutely has the nuts and bolts to go all the way.

@wilson_

So it doesn't get rid of p2p, but I think/hope that it handles it more gracefully than base supcom, the faf team just need to host an iroh relay server, which from my understanding doesn't need to be beefy at all.

Also along with the game being many times faster than the base game, should stop that horrible lag.

and the dynamic input latency.

@lan94

Thank you very much for play testing! I believe I have fixed all but number 2, although air transports are not perfect
4. I tired to reproduce, but i have fixed some issues with weapons so maybe this has been fixed along the way before i got to your report

again thank you very much for the feedback.

@giebmasse
Also thank you for testing very much appreciated

@cdrmv @garythegoat @downlord @saver @j_w_w @snoog @xanoxis @randomko @limez3_ @nomads @lycanrising
Thank you for your nice words

@arkenflame @darien_
Yes I do plan to make it open source, I just want it to bake in the oven a little bit longer as im sure you can imagine.

InfimeCmdr

This post is deleted!

mirddes

this is incredible!

zwierzak

Very cool!
Looking forward to try this at some point (without having to trust a random binary downloaded from the internet).

rigomate

This is really amazing! Keep up the good work.

FunkOff

This could be the greatest thing to happen to FA since FAF

Brutus5000

@SlightlyGrilled said:

I 100% want to make this open source, no worries, I just want a bit more time, as I'm well aware that open sourcing it will open the floor gates. I would also be interested in how this can be transferred over to the faf team as well. I do believe this has real merit to replace the base engine. it already demonstrates a large amount of the game working, and absolutely has the nuts and bolts to go all the way.

You can transfer the repository to the FAForever project and still remain the repo admin. It could also be a private repository if you are worried about cheats etc.

I suggest you contact us in our https://faforever.zulipchat.com, so we can discuss options.

Cascade

Awesome! Some strong competition for another TA spinoff that shall not be named

SlightlyGrilled

So in this update I really wanted to dial in and spend time on the air behaviour, while still some work is needed, air now behaves much closer to the base game.

You can see below in this video, planes being generally more plane like
https://youtu.be/I4bx095DNqY

Please try out it out and let me know, it's really helpful to get feedback

Windows:
https://upload.disroot.org/r/FcnpXWYB#rq9t4XIPLv/UEhmeibcj0RKEuuvEJq6AZxfQ2f7AWN0=
Mac:
https://upload.disroot.org/r/bz30tWao#83WfQdi7ZiIGjZVe2njAUsuOqNU7b+63eICnlmf75CQ=
Linux
https://upload.disroot.org/r/rar4HZ26#kyjbGpbvSeB7HqYhrphLzJ9JjFJ1epcbDYo6xM3VIkY=

Weapons

Weapons should now behave far more true to the real game.

Engine <-> Lua api

I think I have also come up to parity with the base game on the engine <-> lua api bridge.
This means the engine is much much more closely aligned on how the game should function.
This was massively helped by the lua type documentation generation I talked about in the previous post.

Perf

With that 10k v 10k air battle, I noticed crazy lag when actually selecting units, this was a combo of the selection logic and also drawing the selection box, waypoints and rings.

Now through some nifty gpu acceleration, range rings are reduced and culled to only the meaningful ones on the gpu, from 10's of milliseconds now down to sub 1ms.

Faelnirv

The multiplayer interface does not show anything.
The campain does not work.
But the skirmish against bots does work.

Below are the game logs;
[game.log](Invalid MIME type)

Faelnirv

Faelnirv said:

nvalid MIME type)

game.txt

MayeulC

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.