It doesn't exist. Technically it's possible but unlikely to find someone to do it.

@ZOMEBODY This is not a new issue. The error message pins down the problem exactly.

I highly doubt that zip compression has magically improved recently.

@Xalimur said:

java.lang.RuntimeException: java.io.IOException: Cannot run program "rundll32": CreateProcess error=740, The requested operation requires elevation

You have some weird Windows issue, that the process claims it needs more permissions (admin permissions) to run the windows core dll to open the browser.

There is a potential threat where people upload a malicious zip file that is only a few kb small, but unpacked a few gigabytes. Your file seems to have a similar compressed<->uncompressed ratio, which triggers the error you quoted. This can usually only happen on maps that are basically empty, flat terrain and have no textures. Add some more content to your map and the error should go away.

Dear commanders,

over the years, memory usage of the FAF client was regular subject of complaints. We worked hard to figure memory leaks and reduce memory usage. Our maintainer assumes, that memory issues >1GB are a thing of the past. But I am not convinced yet. Thus, we need more data and feedback.

Therefore I challenge you: Send me your worst RAM usages images from your task managers. Minimum requirement is it's from version >= 2026.4.0

Thank you!

@wilson_ said:

Also it's not that "I need it", I don't have access to the mod client. But I know a couple of folks, who usually come with the pools, have complained about the lack of options in the past.

I was under the assumption you have access. Then just forward my message to the people complaining please.

Raise a feature request in the github repo then and explain what you need. Nothing will be done if a feature request only exists in someone's head...

You want to pitch a successor to Supreme Commander to investors? You don't need our approval, do whatever you want.

Do we need another close source investor backed project like Sanctuary? The genre can benefit, this community probably not so much.

If you are just here to grab free labour to work on your vision, I assume you are in the wrong place. The collaboration with Sanctuary already shattered the remaining faith in community projects where real world money is involved.

Amazing work. I am currently very short on time, but please join our Zulip chat and we can discuss how to integrate your work.

We had somone willing to invest serious amount of money into the rights. Nobody is interested in selling it. And even then most probably the source code is lost, only intellectual property rights remain to be acquired.

Looks like a broken update. Uninstall, remove all remain of faf in c:/program files then reinstall.

Would it surprise you that lots of people use the password for both?

I blogged about that too over for years ago in The complexity of the FAF infrastructure and why throwing money at it doesn't fix shit.

This is a fair question and it deserves an official answer.

Decisions in the context of time

First of all: all decisions made are/were made under the circumstances, context and given knowledge of it's time. The best decision at that time is not necessarily the best decision under different circumstances. That doesn't make the decision wrong, only because the circumstances change over time. However it also doesn't mean that a decision is final forever. It can be reevaluated and changed any time.

Developers, developers, developers!

Tools are only as good as the people using it A project like FAF cannot commit to a technology nobody is capable or willing to work in. This is the fundamental truth of any open source project and it haunted FAF from the very early stages.

The original FAF client and server used Python. While everybody claims Python would be so easy to use, I cannot agree to that in bigger projects, and I can argue about that for hours, but this is not the right place about it.

The amount of time FAF had a dedicated Python-skilled contributor in the last decade is very small. So small in fact, that the Lobby server is unmaintained for a while now and Pull Requests have been piling up and will be probably stuck there until someone with a long-term engagement is showing up.

Nobody in the core contributor team wants to or can do work with the Python codebase today. And it was the exact same situation when we promoted the Java client to the official client. Features or bugs don't really matter, if nobody is touching the code.

You might argue, what is there even to touch, the Python client has stayed the same for years and that is where you are wrong. We had multiple fundamental changes that were necessary, in order to keep FAF maintainable or (especially looking at the DDoS situation) alive.

Some examples are:

• Moving from an unmaintained php based map/mod vault (which wasn't even in version control) to a proper REST API approach
• Moving from the odd binary patching logic sending files over raw TCP to a simple HTTP patcher (to shutdown another Python server component that was rotting along)
• Changing the replay format from ZIP to ZStd back when the server disk was running full
• Changing the OAuth login provider (due to security requirements in our backend)
• Basically all the DDoS related changes (websocket connections for lobby protocol, websocket for chat, hmac protected urls ...)

All these things work now in the Python client. But they didn't from the start. The were fixed with a certain delay.

And this is the core point: We, as the core contributor team, must be able to make necessary core changes anytime when there is an urgent need. This wasn't the case back then and it still is not today. I know multiple people who are able to patch some immediate things into the Java client if needed, in worst case I can do it myself. But I only know one persistent developer working on the Python client and he has never shown interest to become part of the core team.

And I get it. The Python client has 1 dedicated developer. He can do whatever he wants. There is only a small userbase, there is no pitchfork mob waiting if something goes wrong. There is no overhead of reviewing pull requests and helping onboarding people who vanish very fast. It is a very efficient development process. But I believe it would not scale, if you promote the Python client back to official and tell other developers to put stuff in there.

The incubator advantage

There is a very funny thing I noticed in several projects now. If you build an alternative tool, you are fast, visionary, you iterate a lot, you break a lot, and you innovate a lot. This allows creating a good project. This is startup feeling. But as soon as you roll it out to the masses and people rely on it, the effect stops. Suddenly the project becomes conservative, people don't want to break anything for your user base. You try to do more testing, but there aren't much testers. Things slow down, you are suddenly no longer a startup, you are an enterprise now...
Until someone else comes and builds an alternative tool...

We try our best

The FAF client used to be much more active than it is now. I didn't expect it back then, but development has significantly slowed down indeed. We have lost many core contributors over the years and they were not filled up with new people. My general feeling is: the remaining people, myself included, are just tired and put in the least amount of work to keep FAF running.

We try to involve other clients in changes. We share upcoming changes, provide documentation. We talk to people, when they approach us. We are answering questions. We do everything we can think of help people keeping alive the Python client or building a new one. So that you or anybody else can still use it. If the Python client works better for you, that is great. Feel free to use it, we're not sabotaging it. The only thing we ask for not to bother us, if something is broken there because we made changes in our system.

Also, it's not just Python, there also was the interesting approach for C# with the Ethereal client, but it seems to have died down.

Conclusion

I would still argue that the choice to make the Java client the official one was the right choice at the time. And I think the reasons from back then are still valid today. So right now I see no reason, or not even the possibility to make a different decision. But this is a community project, and should the situation change, we might need to reconsider.

VPNs use one ip address for many many users. Most rate limiting techniques assumes one ip = one user. So the overall Github usage of all VPN users can cause the rate limit to trigger.

I found a tool called Porting Kit that I use to run Civilization 4 inside Steam. That might help you getting the game running, but I doubt it works in combination with the FAF client, network play is probably impossible.

Is this from a local replay or a reist from the vault?

Where do you receive the error? Client? (Which client, which version)? Website? Somewhere else?

Should be fixed now.

Every central server we set up will be immediate subject to DDoS just like our turn servers.