don't click here

Microsoft Flight Simulator 2004 & FSX: Hacking User-Defined Weather and Working Around Restrictions

Discussion in 'Technical Discussion' started by Travelsonic, Aug 27, 2020.

  1. Travelsonic

    Travelsonic

    Member
    827
    20
    18
    The purpose of this thread is to attempt to chronicle my efforts to hack Microsoft Flight Simulator 2004 and Flight Simulator X, mainly to increase the amount of custom weather options that one is capable of doing under the "User Defined Weather" settings.

    Even though Microsoft Flight Simulator [2020] is out now, I feel like this would be fun to do, and that anyone still sticking to these versions for whatever reason would benefit.

    User-Defined Weather Restrictions:
    These are the current restrictions observed (or at the least, the ones that piss me off the most haha):

    [WORK IN PROGRESS, INCOMPLETE LISTING]

    User-Defined Weather: General Restrictions
    • The number of layers you can add, whether for clouds, wind, temperature/pressure, or visibility, is capped to 20 layers.
    • The maximum altitude one can place these layers at, or manually enter into the relevant text box, is 99,999 feet - this is irrespective of if you are in Flight Simulator 2004, where the maximum flying altitude is capped at 100,00 feet, or in Flight Simulator X, where the maximum flying altitude is capped at 100,000,000 feet. you can, however, drag the top of the layer so its altitude is at 100,000 feet, or hit the up arrow next to the altitude textbox
    Wind Restrictions:
    • Sustained wind speeds are capped at 200 knots.
    • Wind speed gusts are capped at 220 knots.
    Temperature/Pressure:
    • Temperature value range is restricted to -139 <= X <= 167 (°F)
    • Dew point value range is restricted to -139 <= X <= 167 (°F)
    • Pressure value range is restricted to 25.0 <= X <= 35.0 (in inches of mercury)
    Working Around Restrictions:
    First thing to know is that many of these restrictions are actually enforced in FSUI.DLL.

    Layer Cap:
    The number of layers is a signed 32 bit value that is, obviously, added to or subtracted from when you add or remove a layer.

    When you go to add a layer, a compare is done against the value and 0x14:
    cmp dword ptr [esi+00000484], 14 ; Compare the dereferenced value against 0x14, or 20 decimal.
    jnl 20837F9B ; If the value is not lower than 20, then a layer is not added.


    At first, my thought was to simply change the value being compared against (0x14). Raising the value to 0x7F allowed me to raise the cap a good bit (going from 20 to 127 layers):
    [​IMG]
    Wind layer menu with 127 layers added.

    If I were to click OK, and then go back to edit more, all 127 layers would be saved, and load fine in the editor, but I thought I could do better. Problem is, the instruction was such that I couldn't make the constant being used in the comparison greater than 1 byte without some hassle.

    Then I thought ... what if I just NOP'd out the comparison all together?

    It seemed to do the trick in terms of allowing far more layers.
    [​IMG]
    Wind layer menu with 500 layers added.

    Problem is, what happens if someone SOMEHOW managed to cause an arithmetic overflow (especially once altitude caps are broken)? Would the game crash, would it not? I don't know yet, but will get around to that problem eventually.





    Manually Enterable Values: Wind Speed, Wind Gusts, Temperature, Pressure, Etc
    This is the part that is currently giving me the biggest thorn in my ass. Specifically, where these values are validated, and errors thrown if the values are out of range (for example going < 25.0 or > 35.0 for pressure, entering wind gusts > 220kts, etc).

    OK, so I learned about the existence of Spy++ which comes with Microsoft Visual Studio, and holy crap has it been a game changer. ​
     
    Last edited: Aug 28, 2020