Offline
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.
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.
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:
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.
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...
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.
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.
Sounds like the update didn't replace all files. An unpleasant but common issue with our installer.
Uninstall. Manual delete all remaining files in C:\Program Files\FAF Client, then reinstall.
@HitiX We already did that for half a day. It broke the last bit of connectivity we had ...
As far as we know players ips get only exposed when joining lobbies.
Apart from that I can't get into detail of our detection patterns.
WebRTC relay servers are basically providing the same protection as a VPN for our use case. However we have technical software issues forcing all clients to pass through to relay server. The attempt to do so made connections overall worse and we have no clue why.
FAF will never raise relevant amounts money via crowdfunding, the community is way to small. Star Citizen makes money out of big promises for something people can't get anywhere else.
Deinstall and make sure to delete the folder in c:\program files\faf client
The program data folder is not the one causing problems.