Downlord's FAF Client

[Downlord]

Some will love it, some may hate it. No matter what people think, I will continue making it.

More information: http://faforever.github.io/downlords-faf-client/

Constructive comments and support is welcome!

[quark036]

So would the chat and hosting be separate from the current lobby? I appreciate the work you've done but that seems like it would start to split the community apart, depending on which lobby they like.

[Downlord]

It uses the same IRC channel an integrates with the normal FAF server, so no, it won't seperate the community at all (see the screenshots)

[Ionic]

To confirm, this will be browser based? We don't need another standalone program.

[nine2]

Ok I love your enthusiasm and ideas ... but I really think you should work with the actual FAF developers and replace the actual FAF client. They would welcome you! On the other hand you can go rogue and do some random work and ... well I think it would be much better if you worked with the devs. There are other projects and considerations for the client that you may not be aware of (eg: security rework) and it just makes total sense for you to become one of the people working on this.

and please for the love of god allow me to search replays by two usernames, not just one

[Sheeo]

Hey Downlord,

We've talked about this on IRC before. I apreciate your work, it looks nice!

Some thoughts:

- While I agree the client can use some work, I'm not sure what you mean with "the design is flawed.". If you mean Python and or QT is a bad choice for implementation, then I disagree
- Until we have a stable server interface (It's subject to change a lot over the coming months), I don't think having a client fork is viable at all -- it will need to keep up to date with the interface while it is being developed, alongside the mainline client
- Having a large dependency like the JRE/JVM is a bad idea for a client this small in my opinion, and it would discourage me personally from using such a client


The "unexpected miracle" you're talking about on your sales page is a simple matter of people joining the project and helping out with developing the client, rather than spending time reimplementing it in language X and platform Y, because that's what they're familiar with.

As you know, you're very welcome to help us out with iteratively improving the client. We're not open to an official rewrite, however -- if that was our policy, we wouldn't get anywhere.

EDIT:

I'll add that you don't need to become a skilled Python developer to contribute to the client. While there are some hurdles in some cases with Python/QT interop, overall this project doesn't require that much knowledge of Python.

Should you decide to help us out with the official client instead, I'm glad to provide help with Python/QT (I'm no expert myself though).

[Downlord]

In favor of keeping discussions efficient, I try to keep my answers short. Not meant to be rude!

To confirm, this will be browser based? We don't need another standalone program.

No it's standalone. It's not "another" but a replacement. dstojkov is already working on something web-based, even I'm not exactly sure what his goal is.

I really think you should work with the actual FAF developers and replace the actual FAF client. They would welcome you!

They are not open to a replacement (see post from Sheeo above).

[...] It just makes total sense for you to become one of the people working on this.

Well, as explained, I'm not supporting Python.

and please for the love of god allow me to search replays by two usernames, not just one

I surely will.

I apreciate your work, it looks nice!

Thank you!

I'm not sure what you mean with "the design is flawed"

Well, I admit that it's not too shabby. But here are some examples:

• The repetitive and scattered write-to-server code that should be encapsulated, making it possible to mock it in order to test without an actual server
• The half-native-half-webview that distributes the UI code to client- and server-side and different programming languages
• The html-within-python-code (even the server sends HTML, like in error messages) which violates MVC
• The hard-coded message strings which prevents localization
• The hard-coded technical values like host/port which, again, prevents clean testing
• The 2000 lines _clientwindow.py which clearly lacks separation of concern

Not to mention some of the client/server communication aspects, which can't be solved in the client alone however.

Until we have a stable server interface (It's subject to change a lot over the coming months), I don't think having a client fork is viable at all -- it will need to keep up to date with the interface while it is being developed, alongside the mainline client

Go ahead! My implementation is ready for such changes (the current client is not)

Having a large dependency like the JRE/JVM is a bad idea for a client this small in my opinion, and it would discourage me personally from using such a client

The current client weights 42.5MiB packed and 111MiB unpacked.
My client (currently!) weights 15MiB (packed) or 20MiB (unpacked), 5-8MiB just because of that FAF uid.dll. If the user has no JRE installed, which they usually have, I'll have to embed one which adds 50MiB (packed) or 137MiB (unpacked) - no user action required. But that uid.dll again is a pain because it requires a 32-Bit JRE. I don't see why this should discourage anyone nowadays.

The "unexpected miracle" you're talking about on your sales page is a simple matter of people joining the project and helping out with developing the client, rather than spending time reimplementing it in language X and platform Y, because that's what they're familiar with.

I get your point and I absolutely agree. But that "simple matter" just isn't reality; we don't get people with enough skill, time and will to do it. Now we can either keep sitting on our shards and wait forever for someone to come and fix it, or we replace it along with the promise of a single person (very convincing, isn't it ) that the new thing won't turn into shards anytime soon.

We're not open to an official rewrite, however -- if that was our policy, we wouldn't get anywhere.

From a political perspective I absolutely agree with that policy and I'm fine with it. Ironically however, this is pretty much how FAF got born back in GPG days (except it wasn't open source) - and we all know the results

[Sheeo]

I'm not sure what you mean with "the design is flawed"

Well, I admit that it's not too shabby. But here are some examples:

• The repetitive and scattered write-to-server code that should be encapsulated, making it possible to mock it in order to test without an actual server
• The half-native-half-webview that distributes the UI code to client- and server-side and different programming languages
• The html-within-python-code (even the server sends HTML, like in error messages) which violates MVC
• The hard-coded message strings which prevents localization
• The hard-coded technical values like host/port which, again, prevents clean testing
• The 2000 lines _clientwindow.py which clearly lacks separation of concern

Not to mention some of the client/server communication aspects, which can't be solved in the client alone however.

I agree with these concerns as technical problems, but I don't think choosing Java as a platform, or rewriting the entire client, makes up for solving them directly.

Until we have a stable server interface (It's subject to change a lot over the coming months), I don't think having a client fork is viable at all -- it will need to keep up to date with the interface while it is being developed, alongside the mainline client

Go ahead! My implementation is ready for such changes (the current client is not)

This isn't meant offensively, but of course your client is ready for such changes -- it doesn't have a complete implementation for the current interface to change

Having a large dependency like the JRE/JVM is a bad idea for a client this small in my opinion, and it would discourage me personally from using such a client

The current client weights 42.5MiB packed and 111MiB unpacked.
My client (currently!) weights 15MiB (packed) or 20MiB (unpacked), 5-8MiB just because of that FAF uid.dll. If the user has no JRE installed, which they usually have, I'll have to embed one which adds 50MiB (packed) or 137MiB (unpacked) - no user action required. But that uid.dll again is a pain because it requires a 32-Bit JRE. I don't see why this should discourage anyone nowadays.

Indeed, this is more of a personal preference on my part.

The "unexpected miracle" you're talking about on your sales page is a simple matter of people joining the project and helping out with developing the client, rather than spending time reimplementing it in language X and platform Y, because that's what they're familiar with.

I get your point and I absolutely agree. But that "simple matter" just isn't reality; we don't get people with enough skill, time and will to do it. Now we can either keep sitting on our shards and wait forever for someone to come and fix it, or we replace it along with the promise of a single person (very convincing, isn't it ) that the new thing won't turn into shards anytime soon.

I do believe it is. Currently the client isn't a priority, because the server and game code has been in much more need of improvement than the client.

You can say many things about the client and what you listed is valid, but it at least fulfills the most important virtue of code: It works.

We're not open to an official rewrite, however -- if that was our policy, we wouldn't get anywhere.

From a political perspective I absolutely agree with that policy and I'm fine with it. Ironically however, this is pretty much how FAF got born back in GPG days (except it wasn't open source) - and we all know the results

I don't think that's a comparable situation.

Anyway; I'm not against competition, but for the purposes of clarity I would like to ask you not to call your client "FAF v2" or to use the FAF logo as prominently--it's misleading since this isn't the entire community backing it, and donations towards your client do not go to the official FAF project.

[Col_Walter_Kurtz]

I do feel that the FAF lobby looks outdated and is bugged. I'm not concerned about my own user experience, I'm not that arrogant, but I do worry about the impression new users get from the current client. If we want to attract new users and keep the playerbase healthy I think it is hugely important to make FAF as smooth and modern as possible.

So best of luck! Is there anything we can use and test before giving donations?

[nine2]

will the new project be open source? will sheeo have the ability to maintain and publish updates to it?