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:
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!