FAQ Authors

Well we had the same problem with Github downloads which has a worldwide CDN, so I'm still not sure if CDN can actually fix it.
So apart from just throwing money at some company, how would we measure that we actually improved the situation?

I mean don’t get me wrong, I have zero clue what any of you are talking about on a technical level so I am not trying to say anyone is right or wrong. I just have a problem with it being an open thread on a forum (meant for communication) and then a dude asks a question based on the information provided and gets lambasted with “I’m not gonna respond until I am” and “pls respect the devs.”

If it’s just informing people for tests, you can still so that with a locked thread. If it is open, I honestly don’t see why the dude can’t post what he did. If it’s a shitpost then why bother responding at all, or just respond with however much effort you feel it is worth. No point in the huge dance.

If you’re gonna get mad at a dude being unqualified to give input based on the literal OP and demand he have like 2 years of FAF repo + zulip experience prior to making some criticism maybe don’t make forum threads and keep these updates to zulip where you can get the feedback you want.

Or just lock the thread, because genuinely don’t understand how anything malicious was in that dude’s post.

@dontstealecorock said in Client v1.6.0:

I think u can try better. I dont mind if you will be rude(actually your last post is toxic so whats the difference) There should be a reason for switch to non blocking approach so just write it. Maybe u can share perfomance numbers. How many memory blocking code was consuming per call?

Ok, so here you go:
You take the time to spit out unqualified critics on a topic by reading a short summary of the changes obviously without a) even have the slightest understanding what reactive is about or b) how it affects the client architecture overall. Furthermore if you would have reviewed the changes you would have spotted that this change goes beyond just introducing reactive patterns.

Less memory consumption due to less threads is one of many benefits, but it is not the main driver behind moving to reactive patterns.

I will not argue that in general replacing classic synchronous blocking code with reactive code is increasing the code complexity. I have seen it. I work with it every day. And in some cases it's worth it and in others it's not and I would not introduce it without good arguments.

But that "reactive is complex"-bashing you do here doesn't apply at all, because the client already tries to be asynchronous by applying the crappy Java 8 CompletableFuture logic everywhere it touches API calls. This code was already pretty ugly and complex to understand and using Project Reactor actually can make the code more consistent and easier to read. It also allows additional improvements such as better unit test supports and better handling and mixing of separate async operations than the Java 8 library can.

Furthermore the client by itself is per definition already forced to run stuff in background thread and schedule it elsewhere because it has a GUI with a main thread and we need to be particularly cautious not to ever block this thread. Therefore reactive programming actually is a good match for UI programming which is the reason why web frameworks such as React and Angular was ahead of the Java ecosystem years before (well apart from the fact that JavaScript only allows one thread they needed a better solution).

Looking at actual lobby-server tcp connection: reactive programming here allows us to move away from a constantly polling io thread which eats a lot of CPU waiting (RAM is almost completely irrelevant here). But again this refactoring brought along some other changes and Sheikah can't mention them all along.
We split off the lobby protocol into a dedicated module and wrote it in Kotlin which results in much fewer code. We now have protocol mesage classes with correct null/not-null annotations which makes it easier for future developers to work with it. We tried to decouple the lobby protocol from the client state so we can adapt to protocol changes more easily also enhancing the overall architecture.

Soo essentially we did these changes for different kind of reasons.
You cannot know these reasons. That's completely fine. You can ask for it though and we'd be glad to explain them within our time constraints.
But just picking one argument and bashing on it is just buzzword trolling.

@sheikah said in What should be done to address FAF patch download issues?:

The caching is only useful if you go back and watch old replays. For most players this is never any issue. The download happens when a patch is released and then it is over.

It is a much bigger issue to consume all the memory with the cached files as people may have limited space on their C: drives.

I thought we added a file (size) limit and that it is on by default. We should really do that as it seems stable.

Is it not useful for joining/watching FAFdevelop games and then having to join/watch normal games and then potentially going back to FAFdevelop? I mean it isn’t like tons of FAFdevelop lobbies are up, I guess.

Yes, but it isn’t enabled by default. If this is going to keep being a problem I’m saying you might as well as enable it and if people have a memory problem they can disable it instead. People might grudgingly tolerate the first mega slow download but it consistently happening might just make them decide to stop bothering with the client.

It really isn’t, I could download and play Witcher 3 faster. If I treated FAF like any random game I would have uninstalled it and probably came back somewhere in the next 6 months once the 2nd 30 minute download happened because I’d think this was a constant occurrence.

If it’s going to be like this then you might as well as automatically turn on file caching for players.

@dontstealecorock said in Client v1.6.0:

Sounds like you higly increased code complexity in return for nothing. JVM allocates 1mb per thread. How many parallel blocking request client does? I assume that number is not big. You can even reduce memory per thread using jvm option. 512kb most likely is enough.

I literally cannot answer this seriously without getting sarcastic and rude, so I will not comment on this any further.

There is no way to break it down into files any further, so that would be guesswork.

Yet again waiting 30 minutes is not acceptable? How did I survive the 00s with only ISDN (64kb/s max) and paying per minute? A 5mb patch took 1.5 hours and cost me around 2€.