Drunq

@Alvega @ThomseN_inc As requested https://github.com/drunkwinter/MSFS2020.ARPC/releases/tag/v1.2.2-SU14%2B Probably the last release I'll do. As I previously said I don't really recommend using it. Using something like Reshade would be much better suited, especially when/if Biology releases his shader.

@Biology Just saw the work you did on the post-processing in the MSFS forum, and you really did one hell of a good job. This just shows we need better post-processing in MSFS. Image comparisons by FinalLightNL from the MSFS forum:

Yes, I'll make it work when I have some time. However like Biology said It's not recommended, because the values are physically accurate. The post-processing probably needs some tweaks.

The values are stored like this in memory: [0.002291070065, 0.001540360041, 0] I don't know how I got these mixed up. Correct ones: Red: 0.002291070065Green: 0.001540360041Blue: 0.0

Yes, something like that. I searched in the general area where the previous values were. The surrounding pattern of bytes are very similar.

@Biology and anyone wondering what the new scattering/ozone coefficients in SU14-beta are. Red: 0.001540360041 Green: 0.0 Blue: 0.002291070065

No, I meant the original coefficients from the executable (exe) file. Decimals in code or configuration are always expressed with a dot, unless the developer has explicitly added support.

Weird, it should have overwritten the exe.

No, executables are stored in binary, so values are not represented with a comma or dot, just one's and zero's. Everyone should have the same executable, I think he must've applied the hex edit to the exe.

This means that you somehow have a different .exe. Have you modified the executable in some way?

Btw, If you are using Proton/Wine on Linux you can probably still run it: https://cookieplmonster.github.io/setup-instructions/#proton-wine

Not at all! Linux is unfortunately a domain I know very little about, so I may not be of much help in that regard. However, I can provide a brief explanation of how my patch works on a Windows. Essentially, the patch is a .dll file that has been renamed to .asi. This renaming is done so that the asi-loader recognizes it and knows to inject it into the game's process. The specific asi-loader I use is called Ultimate-ASI-Loader, it imitates the behavior of a Windows .dll the game tries to load (dinput8.dll in this case) and also additionally loads any .asi's found in the root directory. It's abusing the fact that Windows first looks for the .dll the game is trying to load in the root folder of the application and in case it doesn't exist, it looks in "C:\Windows\System32" which it then does. Anyway that's how the .asi (.dll) get's loaded into the game's process. Because of that fact, I have read and write access to the game's memory at that point. All I do is search for a specific pattern of bytes I need to modify in the game's memory, which in this case is "C3 64 2A 3A E3 8B F6 3A 07 42 B2 38" (representing 3 floats of 4 bytes each: 0.00065, 0.001881, and 0.000085). Once I locate this byte pattern, I retrieve the memory address pointer, which allows me to make the necessary modifications.

Yes, anything after the `;` character is interpreted as comments and ignored.

Yes, only the .asi has changed.

For all those who just downloaded v1.2.0, please update to v1.2.1. Just noticed there was a performance regression with that update that may cause increase in CPU usage for no good reason 😔.