SF2 - Advanced Moddings (DLL Files editing)

[pvince]

7 minutes ago, alfa2 said:

Hello, bear in mind that it is almost impossible in reality to get the Mirage F1 in a spin and especially a flat spin. It stalls by just dropping the nose. 

Yes, and it was not the case in our previous releases. We'll be close to that in the next release (F1C-200 update in progress) and following. 

[Crusader]

On 11/2/2025 at 3:50 PM, pvince said:

What could be "MISSILE_INTERLOCK" ? Quickly tested as a lamp in missile operation (lock, min/max range) but never went on.

Used in TW F-4 cockpits
Radar-guided missile selected and radar mode = boresight/ACM results in "Interlock Out" switch indication.
IRL function:
missile can be fired by overriding certain Fire Control System checks (like ASE dot position, closing speed limits etc) which would inhibit the launch
 

[pvince]

For info and feedback on  the work:

- Mass= in the [Pilot] section tested successfully (just tested the total weight indication in debug mode)

I had never seen it in a data.ini before. 
Thanks Eagle !

[Stratos]

Was watching a DCS F-100 video today, player put an aggresive maneuver close to the ground, engine had some compressor stalls but finally didn't died, man that was so cool. Maybe one day we can add such a feaature in SF2 with the help of the AI.

[snowburn]

Any news on this?

I've been thinking about the possibility of building some kind of telemetry/instrumentation tool that could hook into the Aircraft Objects DLL and expose the aircraft's internal flight-model state.
 

If we could get access to the values being used internally by the flight model — things like airspeed, AoA, sideslip, G forces, angular rates, engine output, control inputs, forces and moments, etc. — it might be possible to automate a large part of the process of studying and eventually recreating the flight model.
 

For example, the tool could load a particular aircraft and run a series of controlled tests while changing specific values in its _DATA.ini:

change CLift / CD / Cm-related values

change AoA tables

change Mach scalars

change control-surface effectiveness

change engine parameters

change mass and inertia

change damping/stability parameters
 

Then it could automatically run the aircraft through a predefined set of flight conditions and record the resulting telemetry.

Something along the lines of:

Aircraft_DATA.ini
      ↓
SF2 / Aircraft Objects DLL
      ↓
Instrumentation / Telemetry hook
      ↓
Flight test
      ↓
CSV / binary telemetry
      ↓
Analysis / graphs

The really interesting part would be being able to run the same test repeatedly while changing only one parameter at a time. That would let us build a sort of empirical map of how SF2's flight model actually responds to its INI parameters.

For example, we could start with something very simple:

Spawn an aircraft at a fixed altitude and speed.

Set throttle and control inputs to known values.

Record the aircraft's state over time.

Change only one aerodynamic parameter.

Run the exact same test again.

Compare the two telemetry streams.

From there, we could gradually determine things such as:

CL vs AoA

CD vs AoA

Cm vs AoA

Mach effects

control-surface authority

induced drag

damping

engine thrust vs altitude/Mach

mass and inertia effects

stall and post-stall behaviour

effects of damage and stores on the flight model

Eventually, this could provide enough information to build an independent flight-model implementation rather than simply trying to reproduce the equations from disassembly.

The ideal result would be something like an SF2 flight-test harness:

┌───────────────────────────────┐ 
│      Aircraft DATA.ini        │ 
└───────────────┬───────────────┘ 
                ↓ 
       SF2 Aircraft Object 
                ↓ 
        Flight Model Tick 
                ↓ 
      ┌─────────┴─────────┐ 
      │                   │ 
   Inputs              Outputs 
      │                   │
      └─────────┬─────────┘ 
                ↓ 
            Telemetry 
                ↓ 
          CSV / graphs 
                ↓  
       Flight-model analysis

Once enough of the internal state was understood, the same test suite could then be run against a reimplementation of the flight model and the results compared directly against SF2.

That might actually be a more manageable way of reconstructing the flight model: instead of trying to understand the entire thing from the disassembly at once, we could treat the original SF2 flight model as a black box, instrument it, and progressively turn it into a measurable specification.

Given the recent work on the Aircraft Objects DLL and the discovery of additional INI tokens, classes and functions, I wonder if something along these lines would now be technically feasible.

Even a relatively simple first version that could hook the aircraft object and dump its state once per simulation tick would probably be extremely useful.

[snowburn]

I wonder if it would be legal to create some kind of "DLL patcher" for the original game.

The idea would be to have a standalone executable that takes something like Avionics60.dll (or another SF2 DLL) as input, analyzes/decompiles it, replaces the incorrect or problematic parts, and then generates a new patched DLL.

In other words, rather than modifying the original DLL manually every time, the tool would automate the process of applying known fixes and produce a patched version of the library.

I'm wondering whether something like this would be legally feasible, assuming the tool itself does not distribute any original SF2 code or DLLs, and the user has to provide their own copy of the original library.