@popsniper

That’s bizarre and I don’t think that’s how steam works

This is not fixed in map gen 1.12.1

I had a similar problem, Windows Defender was an issue in my case

You can't and there is no reason to.

@mostlostnoob thanks 🙂
love the avatar XD
Smug mode 🙂

OP found the login credentials for his older, already verified FAF account, which resolved the issue.

You can't gift units to an AI I'm afraid

@magge said in Why?:

@goodgamepleasety

Maybe the issue is related to the ICE-Adapter high CPU usage bug. In case you or other readers are not following the Discord thread, I will quote the following:

Ravandel said in Discord

An alpha test client has been released with a rolledback ice-adapter version. the devs would like you guys to try it out, and let us know if the problem does not appear at all with this alpha test version.

This in order to figure out if it is caused by "recent" changes in the ice-adapter or by something else. If it does happen with the alpha test version also then those changes can be ruled out.

Note: you can install this alpha version alongside your normal install, and you can play games with other people running the normal client as well.

Link: https://github.com/FAForever/downlords-faf-client/releases/tag/v2024.5.1-alpha-2

I would be grateful if you could test the Alpha 2 client and provide feedback to help narrow down the issue.

I came across this thread in dc yesterday.

Also yesterday I had 2 consecutive client updates, and I'm now using the 2024.5.1 - alpha - 2 version of the client. I will see if I notice any improvements to my situation.

Probably so, but the high CPU load is coming from the FAF client, cause usually I don't have anything else open during game. I also check if my pc is updating or anything like that and it's never the case.

has anyone else faced this problem? is it just me

It might even be relatively easy.

I think there are only two ways how the arrow keys could be hardcoded into the exe:

Using Windows scan codes (raw input):
bd850e39-fed1-4cc4-a260-e413fdde32ef-grafik.png

If the right most hex values were found in the exe in close proximity (0xE04D, ...), they could be exchanged with the corresponding values for WASD (see link).

Using Windows Virtual-Key Codes

1b73a278-1d43-4de2-ae88-ccbba14730b2-grafik.png

So in this case these hex values would be hardcoded in the exe in close proximity (0x25, ...), and again could be exchanged (see link, W=0x57 for example).

So somebody would just have to use a hex editor to search for a set of these, replace them, and check if it works.

@indexlibrorum
no, I didn’t think of such a simple operation. Thanks, this helped

Hey, if you are in the FAF discord, head over to #mapping-general and we'll help you debug it.

But from what I can tell from the error logs it looks like you tried to rename your map improperly. I suspect you renamed the folder of the map, but that's not enough: there are several other locations where you have to rename the file paths.

Renaming maps is best done using the "rename map" function in the editor itself, and not done manually unless you know what you are doing.

504 means you were able to talk to api.faforever.com but it wasn’t able to reach the backend service. So the fact that it started working again after you flushed your firewall rules is just a coincidence.

Just noting that in case someone finds this in the future and thinks that if they get a 504 error they can fix it by flushing firewall rules. You can’t. Just wait a bit and try again or notify the server admins.

Ok, I fixed it by creating a new folder in my Downloads instead of transferring Gas Powered Games to downloads. Thank you for taking the time to help me and have a great rest of your week!

@jip Hello. I encountered the same problem, tell me how to fix it

On a second thought, might also be this assert that fails the first tick:

gpAssert( (_controlfp(0, 0) & _MCW_PC) == _PC_24 );

Since setting the _PC_24 flag does not do anything on ARM, when checking the flags, that will be unchanged. First thought - could we disable one of these asserts with a patch? Or somehow pretend the flags are always set as expected on Apple Silicon with _PC_24 set (or redefine _MCW_PC)?

However, two more interesting bits of information I found, comparing Intel and Apple Silicon, which seems to hint at calculations using binary64 (double) match but binary32 (single float / 32 bit (24 bit precision)) don't match:

https://stackoverflow.com/questions/71441137/np-float32-floating-point-differences-between-intel-macbook-and-m1

https://eclecticlight.co/2021/04/22/can-you-trust-floating-point-arithmetic-on-apple-silicon/

If so, that would mean the proper fix would be to replace all single floats in the game with double floats.