FAQ Authors group

Brutus5000

Sorry. This browser-check is nothing that we enforce, it's just some rule our web-render library does this. I can't easily swap it out now.
I know there was a clunky error on manually going via link, but I think I fixed. Maybe it's still broke , I need to check

Brutus5000

The FAF client should show you the link and the login code while it is waiting for you to login. You should be able to copy this into a different browser.
But yes, the permanent Discord spam from taken over browser shows that you are indeed a danger for society with a 2024 browser

Brutus5000

@Dim-A-miD said:

once the client update is complete, of course?

?? Which update are you referring too?

Also there will be most likely no new tier levels or units being added to the base game - ever. We want to preserve our game. Mods allow to do all that. But they are independent from the core development.

Brutus5000

@blackyps Would any of these desync issues appear in a replay out did it only happen in live games? Can we build a CI-pipeline on old repos? @draiget does this for the reverse engineering development somehow.

We now have desync tracking in the lobby server, so this could be used as alarm tracking after patches. But that would basically require more releases / smaller changes per patch.

BlackYps

Let's start with the good news first: Due to relentless work by Nomander, supported through testing by JaggedAppliance, they managed to pinpoint the cause of the desync issues that plagued FAF recently. As I suspected, it was an engine patch, which brings me to the main topic I want to talk about: How do we deal with engine patches?

We are in a peculiar position, because the people doing engine patches and opening Pull Requests for them are frustrated that getting them actually deployed in the game takes so long. On the other hand, these changes are extremely hard to review, because they look like this:
´´´
0x007A7858:
jmp asm__ShouldAddUnit
nop

0x007EF12B:
push esp
mov ecx, esi
call RenderRange__Moho__UserUnit__UserUnit
nop

0x005BF011:
mov ecx, edi
mov edx, eax
call Hooked_SyncVisionRange
jmp 0x005BF02C
´´´
Good luck checking the code for logical errors. And as we can see with the latest debacle, an engine patch can work on the surface. When you test it, it does what it is supposed to do, but it can bite us later when random desyncs pop up because the patch also can corrupt memory under special conditions.
So for me as a team lead, merging in a barely tested engine patch feels like chugging an improvised bomb into my basement for storage. Probably nothing bad happens, but it definitely doesn't feel comfortable.

Recently we got a lot more engine patches by new contributors, which is nice in principle, but it makes the problem even bigger, because with the old contributors I at least know that they have some experience. With the new guys it could be some AI-assisted reverse engineering which can be a good or a bad thing, but I can't tell at all how diligenty they worked on that.

And the thing that annoys me the most is that I as a team lead am supposed to provide a good contribution environment, where people don't feel bogged down by bureaucracy and long approval processes. But if things go south, and nobody knows where the mysterious bugs that have appeared originated from, then I feel like all eyes go to the team lead to fix it. And frankly, I would rather stop storing IEDs in my basement than constantly rebuild the room. In this case, thankfully Nomander took the initiative, but he is also the Balance Team Lead since recently, so once again it is a team lead investing time cleaning up the mess other people made.

I personally think that it is not a good look on FAForever as a whole, if the gaming experience is tainted by random desyncs and crashes. And I think we need to change something about how we apporach this whole engine patch topic. I realize that the position of "just stop it entirely" is too extreme, but just carring on is also unbearable. God, this whole thing makes me angry, not at anyone in particular, but at this whole situation. We can do better than this. We need to do better.

I am looking forward to constructive suggestions.

Brutus5000

We had rented a global 3rd party TURN relay service. It got maliciously abused and we had to disable. The costs went from 100$ to 600$ per month.

Brutus5000

Since you referenced my pull request: it was never done to be able to actually play with it. I just need it to run the client and test FAF things while I mostly use a macbook

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.

Brutus5000

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

Brutus5000

Does your engine run the lua code for the game patch?

FAQ Authors

Posts

Member List