SF2 - Advanced Moddings (DLL Files editing)

[+Eagle114th 1,091]

Welcome to the Strike Fighter 2 (SF2) Advanced Modding thread!

A quick reminder:

We mod ethically, honoring ThirdWire’s life passion in creating SF2. All projects here are strictly freeware, transparent, and require a legit copy of SF2 to use any modified DLL files.  This thread also serve as the modder resource library that can assist us finding what we seek for advanced modding.

Hello everyone! This thread is dedicated to advanced modding, focusing on DLL file editing using tools like Ghidra and other debugging/reverse engineering tools.

We have the rules here:

- All projects must remain freeware. Payware is a hard NO!

- No links or discussion about pirated SF2, period!

- We encourage everyone to share knowledge, collaborate, and keep the community spirit alive!  

We have the great desires to expand the engine beyond the current limitation,  from custom HUDs to radar behaviors, etc...

This post will be updated through time with more information.

Let's have a happy modding!

Edited July 31 by Eagle114th

[+Eagle114th 1,091]

I have spent the week learning how to use Ghidrea, contemplating on how to find the right information, in order, to make sense out of what is shown as disassembled / decompiled functions and variables.

WIth AI help, I am able to come up with an idea:

1) Find the class name that is called by associated functions

2) Find the function with associate strings for possible keywords

As first step of building the modder resource library.

In the link below, you will see vast number of folder with three types of .txt files:

_CLASS_FUNCTION_LIST.txt
_STRING_LIST - 1.txt
_STRING_LIST - 2.txt

And inside each folders, for example: FLIGHT -> AVIONICS 60, you will see the files:

AVIONICS60_CLASS_FUNCTION_LIST.txt
AVIONICS60_STRING_LIST - 1.txt
AVIONICS60_STRING_LIST - 2.txt

These files give modders a big head start by helping pinpoint the location of relevant functions, and that's the step one.

For next steps, it is up to anyone here.  I am here to provide what I can product from the ghidra tools.  I will continue to update the resource library as I grow the understanding of Ghidra tools and codes shown in it.

MODDER RESOURCE LIBRARY v1.1
SF2 -Resource Library v1.1.zip

NOTE about v1.1:  I have added two folders, you will see in each folders:
REFERENCES
RTTI

References are the one that I used pyton script to extract the name of class called by functions, as well the strings from the functions.  RTTI, in other hand, contains the list of class and the assoicated functions, along with the function names restored.  However, please note that, there are two or three of DLL that does not have RTTI, I still ran the script to create the list of class with assoicated functions.

 

Hoowever, I am working an interesting next projects: I just recently realized, after seeing how Ghidra symbolized the native C++ into C Pseudocodes and is working on Name Demangling (Converting C++ mangled symbols back to readable C++ codes).  Here is an example:

?MyFunc@@YAHH@Z -> int MyFunc(int))

For now, here is notes that AI generated with me while studying various codes:

(NOTE: the note below is incomplete.  Will be updated eventualy.)

CODES NAME DEMANGLING NOTES.txt

Cheers!

Edited August 1 by Eagle114th

[+Eagle114th 1,091]

HOLY MOLY!!!

I made another breakthrough as I learn more about the tools with Ghidra, as well creating new script python for output (text files)

What I recently used is known as RTTI, which stands for Run-Time Type Information.  It helps recovering the class names, shows inheritance and virtual function tables (vtables), and making it possible to link function ack to the classes they belong to!

For example, from

Quote

Class: avnHUDTD_RadarClass
  avnHUDTD_RadarClass @ 10005260
  vfunction2 @ 100016a0

Class: avnHUDRadarRangeClass
  avnHUDRadarRangeClass @ 10007cd0
  vfunction4 @ 100016c0

Class: avnHUDRadarTargetTASClass
  avnHUDRadarTargetTASClass @ 10007dd0
  vfunction4 @ 10001720

Class: avnHUDRadarTargetHeadingClass
  avnHUDRadarTargetHeadingClass @ 10007f40
  vfunction4 @ 10001780

Class: avnHUDRadarTargetVcClass
  avnHUDRadarTargetVcClass @ 10007fc0
  vfunction4 @ 100017e0

Class: avnHUDRadarTargetAltClass
  avnHUDRadarTargetAltClass @ 10008040
  vfunction4 @ 10001840
  scalar_deleting_destructor @ 1000af90

Class: avnHUDImageClass
  avnHUDImageClass @ 100019b0
  vfunction2 @ 10001b20
  vfunction4 @ 10001bb0
  vfunction5 @ 10001c40
  vfunction6 @ 10001cb0
  vfunction3 @ 1000ac60

ETC...
ETC...
ETC...

Looks like I will be doing the same for each DLLs and will update the Modder Resource Library.  This is another huge steps, which helps us big times!
 

[+Coupi 4,613]

My friend your work is amazing ! 

The DLLs seem to be the core of SF2.

So how do you plan to use directly them in order to improve the current "July 2013" game version ?  

After these first steps do you plan to create a dedicated team to test them before "produce" them ?

P. 

[+Eagle114th 1,091]

Hello my friend!

Excellent questions, and this is steps I am working on:

1) Finish working on compiling the text files with list of Class and function associated with them.

2) Analyze and make the list of already available codes for full reference of usage for each tyipes of .ini for cockpits and avionics related

3) Start experimenting modifying the DLL files and see if it works on SF2.

I do not have the team.  I hope, eventually someone will start the team.  
 

Eagle114th

[+Eagle114th 1,091]

Hello everyone, the new version of modder resource library v1.1 is uploaded, it is posted on the 2nd post above.
 

Eagle114th

[+GKABS 8,915]

I am really interested to see the outcome of your hard work. I hope it will improve the game. One of the things I would like to see is air refueling.

Keep up the digging. I hope you can find the SF treasure box.

P.S. Two more things to see: a pilot eject with a parachute and if there is a chance to add more animation IDs.

Edited August 1 by GKABS

[Stratos 3,272]

Wondering, how one can edit those files Eagle? We need a hex editor for that?

[buccaneer4499 2]

hmmm, could DLL modding mean that air to air refueling be done? as well as visible pilots walking on the ground and boarding their aircraft?

[+EricJ 4,424]

How about let him figure out the stuff before requesting it? Kinda let him build a team, get the tools and such. I know people are excited and such, but let's not get too excited and see if he can deliver first.

[Wilches 1,176]

My wish list:

1 - Dynamic front line (same as EAW)

2 - On XXX.DATA.INI:

- Airbase=X (choose airbase where your flight start on Single Missions)

- SecondAirbase=X (airbase move according to front line)

-SecondAirbaseDate=XX/XX/XXXX

ThirdAirbase=Y

ThirdAirbaseDate=YY/YY/YYYY

New roles like INTERCEPT BOMBERS, flyable TRANSORT/TRANSFER, return of FAC missions among others.

3 - Making the aircraft turrets attack specific air and ground targets selected by player.

4 - Air refueling

There are much more to be add and correct.

[+FLOGGER23 3,152]

Guys, I know we are all excited for this discovery, but then again, let's wait for @Eagle114th to play, understand completely, and then, I think he will come up with some changes and ideas.

I'd wish for better graphics options and so many more, but for now, i merely will be just watching how this develops, and my fingers are crossed for good, all my good vibes are for him.

And if I can be of help, count me in.

Thanks!

[+Eagle114th 1,091]

Hello everyone!

Sorry for being absence for almost two weeks. It have been quite hectic weeks!  Real life caught me, so I had to put projects down for time  being.  Aat the same time, i needed a short break, a fresh breath and many ideas for bothSF - CAP and Advanced modding (DLL editing).

There is one video that shocked me, let me show you:

X-wing: Tie fighter, got modernized through reverse engineering, which bought improved graphic, VR suports and other amazing feats!

And please note, this sim is from 1993!

This shows me that it is definely possible.   However, what I have realized is that, as stated, by using Ghidra to reverse engineer and looking at the pseudocodes, there is one extra challenges:

As stated, the SF2 engine is natively written in C++, not C.  So therefore,  by editing the C Pseudocodes, we nbeed to carefully codes while remain in the loop of SF2 with the calls and imports, so it will rrun well in SF2.  But atleast, C and C++ are somehwere close toe ach other.

C++ is deviated from C, so we have to use extra C codes that work the same way what C++ codes intended to doin SF2.

Nextw eek I am going back working on SF2 - CAP and further exploring advanced modding.

I will post an additional i nforamtion on what tools I use and how I managed to extract the codes out, so you can view it and edit it as well.  I use the tool known as Ghidra 11.4 and scripts to help me extracting the codes.


Cheers!

[+gerwin 468]

On 13-8-2025 at 4:44 PM, Eagle114th said:

X-wing: Tie fighter, got modernized through reverse engineering, which bought improved graphic, VR suports and other amazing feats!
And please note, this sim is from 1993!

 

Not quite. This is a 1999 engine, AFAIK running as it always was.

https://www.mobygames.com/game/1126/star-wars-x-wing-alliance/

[simonmiller416 2,282]

In my experience, it's still too early to make wishlist yet, we still need to do more research to get familiar with what these things do, and rebuild the foundation one day, which takes time.

Let us look forward to it.

[+Eagle114th 1,091]

Hello everyone!

I am back to working on ghidra and SF2 DLL files digging.  This week I am working on extracting all of available sections (Headers), key values, available values that can be used with it, especially examples how to use it.

I am quite shocked to see this in Avonics60, example:

UPDATE: For now, the list is removed.  There was some mistakes. I am continuing to grow skilsl using AI correclty while extracting huge amounts of codes (over 60K lines of codes from Avionics60.Dll).

I apologize for the mistakes.  Will post more accurate list when I double check them.

However, I do not promise that it do work in SF2, but it is what extracted from avionics60 dll

Therefore, this week, I am going to get busy building the large database of information for each .ini sections (headers), keys (entries), and values that can be used with each keys.  With that, we can experiment if they do work in SF2.

Eagle114th
 

 

Edited Monday at 05:14 AM by Eagle114th

[+Eagle114th 1,091]

Hello everyone!

I figured out what to do now.

I’ve been digging through Avionics60.dll to understand how HUD and avionics are handled before any attempts to modify DLL files. By analyzing the Ghidra dump and .ini files, I created detailed notes on .ini editing for Avionics60.dll, starting with the HUD section.

Here is note for a start:

HUD.txt

This is what I just realized from digging through Avionics60.DLL: 

Keys (Entries) like LCOS and CCIP are tied to the specific ballistic classes (avnHUDLCOSClass, avnHUDCCIPClass), not the generic HUD class, THERFORE is why LCOS and CIPP goes beyond HUD. 

Slowly will go through each DLL and extract what I can find (Sections and Keys), to build a comprehensive .ini editing library for modders here. 

Cheers

[+Eagle114th 1,091]

Hello everyone!

The progress mining through the Avionics60.DLL in the language of C pseudocodes of Ghidra have been full of puzzles and it starts to make sense.

Here is how it work, based on what I understand:

1) INI reads the token: "SymbolType=(NAME)"

2) Engine normalizes the token (treats "AirspeedScale", "airspeedscale", "AIRSPEED_SCALE" as the same entities).

3) Engine looks it up in a registry (Table),  instantiates the matching "avnHUD(NAME)Class".

4) That class owns the **logic + drawing** for the symbol.

The way SF2 handle hte string and names from class is wild!  Here is list, so you can see an example:

This is based on what is found inside the Avionics60 and SF2.exe dump. 

I want to add more informaiton about LCOS and CCIP adn why they don ot stay within the limtation of HUD rendering area (ViewportTopLeft and ViewportBottomRight):

LCOS and CCIP are HUD symbols, BUT they calls the ballistic code within HUD class, resulting in not being fully integrated in HUD codes as another HUD classes do.
 

Another wild bug I also discovered, this is from Avionics60.DLL DUMP FILE:

Quote

fVar26 = FUN_10020f80(local_260,L"AvionicsData",L"TrackMemroyTime",0.0);

This means if anyonoe uses "TrackMemoryTime" instead of TrackMemroyTime, wil not work.  I plan on correcting it by modifying the DLL files via Ghidra and patching the DLL as first step toward modding DLL files after finishing the ini modding information library.

Cheers!

Edited Wednesday at 04:15 AM by Eagle114th

[+pvince 111]

On 27/08/2025 at 6:01 AM, Eagle114th said:

TrackMemroyTime

I would not correct the typos bugs in the dll, because then the old XX.ini, modded but also original ones, will not work. There are other typos like that, but they are known by ini modders:

Type=HUD_MODE_INDIDCATOR (cockpit.ini)
NoJettisionTank=TRUE (data.ini)

and maybe others that do not come to my mind now 

 

Edited Thursday at 06:33 PM by pvince

[+pvince 111]

Wishlist (starting "slowly" ):

- SymbolType=CLOCK_TEXT

- SymbolType=WAYPOINT_TIME_TEXT (time to next waypoint at current speed)

[+Eagle114th 1,091]

Hello everyone!

It have been incredible challenging going through over 60k lines of C-pseudocodes (Decompiled in Ghidra) that follows the logic of C++ (natively written in SF2 DLL files) in Avionics60.DLL file.

The interesting thing is, I have noted how each class of HUD calls another HUD class and/or uses string to handle the key and associated keys for each sections.

Spent days and many hours working on both HUD and RadarDisplay key extraction that can be used in INI files.  I do NOT guarantee that it works, at least it is what is found in the DUMP files.

The AIs have been huge help, cutting down the intense DLL DUMP digging.

Here are HUD and RaadarDisplay (WIP) INI usage guide.  If some codes (INI) does not work, then I apologize. At least I tried!

Here are two Avioincs60 INI information:

HUD.txt

RADARDISPLAY.txt


Eagle114th

Edited 18 hours ago by Eagle114th

[+pvince 111]

Incredible work, amazing, this is much more complete than the databases we had so far based on accumulated experience.

It seems that the outcome has HUD, RADAR, but also COCKPIT functions. For example I have not been able to get "SymbolType=LOW_ALT_INDICATOR" working for the HUD. But the "INDICATOR" part is the clue for me that it is like the cockpit function "Type=LOW_ALT_WARNING_LIGHT" (that works). I am not sure. 

Unfortunately, a function intended for "RADAR" does not work for "HUD" (or COCKPIT, and vice-versa). A great future outcome of the work could be to get a new "HUD" function (for example) derived from an existing "RADAR" or "COCKPIT" function (because in that case the output data is known existing from the simulation engine, so it is "just" to display it).

Some Remarks:

1. "HUD_" in Symbol[XX]=HUD_FUNCTION  and [HUD_FUNCTION] entry is not mandatory, just practical legacy naming convention. Any name would work. Same for Radar_ (and most likely VDI_)
2. SymbolType=ALT_LOW_TEXT is an interesting case (not in your list). It works, the defined text will be displayed, but whatever the altitude is. A bug I guess.
3. BORESIGHT alone not sure, but SymbolType=BORESIGHT_CROSS works
4. SymbolType=CLOSURE_RATE_SCALE not sure but SymbolType=RADAR_CLOSURE_SCALE works
5. SymbolType=DEVIATION -> SymbolType=COURSE_DEVIATION
6. SymbolType=FLIGHTPATH not sure but SymbolType=FLIGHTPATH_MARKER works (I have seen your note on alias in the previous release but not tested)
7. G_INDICATOR not sure for HUD, but SymbolType=CURRENT_G_TEXT works
8. SymbolType=GLIDESLOPE -> SymbolType=ILS_GLIDESLOPE
9. SymbolType=LOW_ALT_INDICATOR does not work (see above)
10. MACH_INDICATOR not sure but SymbolType=MACH_TEXT works
11. MasterArm not sure but SymbolType=MASTER_ARM_TEXT confirmed yes
12. SymbolType=MAX_G_INDICATOR  ->  SymbolType=MAX_G_TEXT works
13. SymbolType=MODE_INDICATOR not sure, and not useful, as any function is called in a known mode so "SymbolType=" makes it (but "Type=HUD_MODE_INDIDCATOR" is valid cockpit function)
14. SymbolType=RADAR_ALT_INDICATOR -> SymbolType=RADAR_ALT_TEXT
15. SymbolType=RADAR_RANGE -> SymbolType=RADAR_RANGE_TEXT
16. SymbolType=RADAR_TARGET_ALT -> SymbolType=RADAR_TARGET_ALT_TEXT
17. SymbolType=RADAR_TARGET_ASPECT -> SymbolType=RADAR_TARGET_ASPECT_TEXT
18. SymbolType=RADAR_TARGET_BEARING  not HUD (tbc) but SymbolType=TARGET_BEARING_TEXT works in radar display
19. SymbolType=RADAR_TARGET_HEADING not HUD (tbc) but SymbolType=TARGET_HEADING_TEXT works in radar display
20. SymbolType=RADAR_TARGET_TAS  -> SymbolType=RADAR_TARGET_TAS_TEXT
21. SymbolType=RADAR_TARGET_VC -> SymbolType=RADAR_TARGET_VC_TEXT
22. SymbolType=SCALE alone I am not sure (what on the scale ?)
23. SymbolType=TARGET_TEXT alone ?
24. SymbolType=WAYPOINT_ID  not ok (checked) -> SymbolType=WAYPOINT_ID_TEXT works
25. SymbolType=WAYPOINT_RANGE not ok (checked) -> SymbolType=WAYPOINT_RANGE_TEXT works
26. SymbolType=WEAPON_COUNT -> SymbolType=WEAPON_COUNT_TEXT

Again, great, very promising ! 

[+Eagle114th 1,091]

@pvince

TRhank you for BIG help testing the funcitonality of the HUD / COCKPIT / RADAR! I will keep posting what I can find from the DUMP files and please feel free to make the chagnes to the files I upload here.

I forgot to add that the HUD.txt I upload is tied to Avionics60.  I have at ehory that Avinoics60 and 70 have a bit different way how HUD works?  When I upload the next files, will make sure to add DLL file name, so we wont' get confused among the files.  There wil be Avionics60 - HUD.txt and Avionics70 - HUD.txt as an example.

By the way, I believe this coudl be huge help:

If we could make the table and put all HUD_Functions names on left section, then add to clumn:  COCKPIT | HUD | RADAR

Then add check or mark which works for either of them.

The more people work with us here, the merrier!  I am now working on Avionicsdata, RWR, TVDisplay and other sections of Avioincs60.DLL before moving on to Avionics70.DLL.

I want to add one more thing, the more we become aware of how SF2 engine works syemtically, the higher chance we can get modifying DLL working in SF2.


Cheers!
 

Edited 4 hours ago by Eagle114th

[+Eagle114th 1,091]

Hello @pvince and everyone,

I have finally got to complete digging the possible sections and keys, along with assoicaated keys from Avionics60.DLL.

WShat is included inthe AVIONICS 60.zip (4 Folders):

RTTI - CLASS + FUNC LIST
RTTI - DUMP
RTTI - STRING LIST
SF2 INI MODDING NOTES

The recent HUD.txt and other .txt posted above are insdie SF2 INI MODDING NOTES too.  however, you will see files:

 

Quote

AVIONICS 60 - AVIONICSDATA.txt
AVIONICS 60 - BlendOp.txt
AVIONICS 60 - HUD.txt
AVIONICS 60 - RADARDISPLAY.txt
AVIONICS 60 - RWR.txt
AVIONICS 60 - TEXTUREDATA.txt
AVIONICS 60 - TVDISPLAYDATA.txt

This time, they are labelled whichi DLL file they are from, to avoid the confusion when dealing with various .txt files.


The next thing I want to note:  AIs, no matter how advacned they are, they are still prone to make mistakes from tim eto time, which can't be helped.  That is why the DUMP file come sin handy, as well RTTI String and class / fucntion list, so you can check it.  And not everything come in string, sometime the class calls another calss for  sections / keys.

Next, about the DUMP, I will retreat it again:  It is in C Pseudocodes, NOT native codes that SF2 is written in.  This C codes is decompiled from Ghidra software and they follow the logic and systems that is natively built using C++.  Basically it's C folloiwng how C++ is used in SF2 engine.

Keep that mind when looking at DUMP file.

Here is the file:

AVIONICS 60.zip

Now I am moving oni to Avionics70.DLL.  


Cheers!