Eagle114th

Hello everyone! It have been tricky work solving the bugs that aused some of messy output, like __s, __f__f, etc... It is now fixed, so there should be proper output for tokens / strings from Enum tables. I have completed the work on all DLLs in FLIGHT folder. I am half way done with CORE folder, still have another 2 folders to go through (MENU and OBJECTS). I would like to share the completed FLIGHT, while waiting for another folders. FLIGHT.zip I would like feedback on this project too, please. Cheers

Hello everyone! I have been hard at work on Ghidra and script, as well improving the workflowa of not just mining through DLL, also to improve every ways I can do with techniques to extract Enum / tables and number values hidden in the various hexadecimal in DLL files. I also have been working on figuring out how to automate the progress, got about 90 percent workflow automated while the rest requires AI assistant. For example, after using RTTI technique to restore the original classes / functions names as possible, it is often that about 25 to 40 percent of classes / functions, while the rest is shown as FUN_(Hex number) as generic , unknown function names. To solve this the quick way, I had AI parsing through the whole dump codes, and determine the possible closest name they could have been, based on teh contests of the codes it had. I do not have the time to further research how to restore the function names, it could take much longer time. So by using this method, it helps both human and AI to go through the dump for any information. However, the dump files, this time, now have decoded Enum / table and numeric values, as well separated file that have the list of them. For example, for Avioinics60 and 70, this is where the tokens were hidden in. Here is samples of Avionics60 and 70. NOTE: Go to "DUMP FILES' in both Avionics 60 and Avionics 70, and you will see the following files: (FILE REMOVED, I will post the full version in 2nd post) - DUMP_CLASS_FUNC_FULL CODES.txt - DUMP_CLASS_FUNC_FULL CODES - EXTENDED.txt - SF2_ENUM_TABLE_DAT_NUM_LIST - CMODDER.txt CLASS_FUNC_FULL CODES are for people to look through the dump. CLASS_FUNC_FULL CODES. - EXTENDED, in other hand, are designed for AI to parse through with more details. SF2_ENUM_TABLE_DAT_NUM_LIST - CMODDER have a full list of decoded Enum / table and numeric values (_DAT numbers). I am currently re-working on all DLLs to have up to date DUMP files, as well the list of decoded Enum / tables and numeric values. These two weeks of hard work paid off, and as stated, with semi-automate workflow, I am happy with the progress. It appear that, the more I work with this project, the more I learn how to extract the information and making the dump much more readable compared to before. Eagle114th

Excellent, this means I have successfuly extracted the token correctly! I am contiuning to do mybest. Cheers!

Hello everyone, this is quite wild found, I ama not even sure if all is actualy implemented or is placeholder.. Here is "TYPE" tokens: By the way, I am just so surprised to see these tokens like: Oh boy, for now i am putting INI guidance library on hold. I am still researching and figuring out how to restore the 'undefined' classes / funcitons / methods, variables, and values back to the decompiled codes, so it have defined codes like before it was compiled. At least I am able to decode the stored tokens and numberid values in the hexadecimals address. Eagle114th

Hello everyone! I made another discovdered, after realizing that _DAT_ (Hexadecimal numbers) also contains the hidden values (numbers) What I learned is that the enum / tables contins the tokens of text while _DAT_ hold sthe numberic values. NOTE: Tere is list of numberic values (You'llsee ???, they are for now.) Here is the file: SF2_ALL_DAT_FLOATS_v1.txt This notes is WIP, but check what I have so far: SF2_TOKENS_Enums_Allowed_Values.txt Check the ArmorMaterial Enum,it explains the protection system for each armor types. Eagle114th

Hello everyone, I have made aa major breakthrough reaching the core of the DLL; When I started with the dump, I was able to extract the "STRING", but the values (Example. INI Speed), esum, tables, and other aspect of the codes remains hidden in the hexadecimal address. For example, the token for the cockpit (TYPE), DefaultArmorType= TOKEN, and other token, I could NOT find them besides "STIRNG". I was puzzled for a while, as I was working through the dump file , generating the INI guidance library, as well the manuals for modders. Then by 'accident', the AI revealed to me that they were able to find token within the hexadecimals through wcscmp / strcmp / switches and showed me some steps how it worked. That is when I get lightbulb moment, realized I should be tracking further where the token could be. That is where i spent hours working on scripts of Ghidra to extract most, if not all the esum, as well other types of the tables, then I was shocked by the result: Not only I get massive list of the decoded tokens, I also extracted the Key, sections, etc.. that is beyond the "STRING". This is where I realized how this work; When compiling the codes (Source codes), all codes always get compiled into memory of the files it is compiled in, which contains the locations as well the codes it was entered as (INI NAME, Function name, tokens, etc...) into hexadecimal address. The only thing that remains preserved is "STRING". So therefore, when decompiling the codes, we see unnamed values, functions, methods, even classes. By using RTTI techniques, I am able to restore lot of unnamed classes / functions, methods, and values, but not all of them. Now that I realize, all of hidden names of everything resides inside the hexadecimals. Here is massive list of the names / tokens found and decoded from the hexadecimal address. Keep in mind, this is chaos for now, because it is extracted based on function it is tied to. I am currently cleaning it up and extract ing the relevant tokens / strings for INI modding guidance library and manuals. (Aircraft Objects DLL) SF2_ENUM_MINER_MAX.txt Cheers

Hello everyone! SF2 INI Modding Guidance Library v1.0.1 is now released, it cana be found in my 2nd post from the first page as usual. (LINK: https://combatace.com/forums/topic/100023-sf2-advanced-moddings-dll-files-editing/#findComment-821849 ) Cheers!

Hello everyone! I am still workin gon the 3 manuals (Aircraftdata related) which is nearly completed: Structural & Damage model - Effects & Lights - Ordinances As soon I complete it, I plan working on AIRCRAFTOBJECT.INI found in Aircraft Objects DLL too. After that, I am looking into both flight engine.ini and mission / campaign ini to extract more information for INI modding guidance. Cheers!

@Stary Thank you for the link, I will check it out and i tlooks interesting!

Hello AcariaPlainum, That is good question. This have been on my heads for a while. I wanted to study adn learn how the radar works and how SF2 models it. This is on my 'to do list'. For now I do not exaclty understand how SF2 models radar in Avioincs 60 and 70 yet. Eagle114th

Hello everyone! I am very happy that i am finally able to release SF2 INI Modding Guidance Library v1.0. The flight model mini books, plus the pocket course is now completed. I am currently working on the next aspect of aircraft data.ini editing: - Structural & Damage Model - Ordinances (Guns, Turret guns, weapons, fuel tanks, ECM, etc..) - Effects & Lights I would like feedback on the flight model manuals please. The file can be found on my 2nd post in this thread, here is the link: https://combatace.com/forums/topic/100023-sf2-advanced-moddings-dll-files-editing/#findComment-821849 Look for SF2 INI Modding Guidance Library v1.0 NOTE: I just realized I forgot to clean 'left over' files. Ther are WIP folders. I realied it's okay to leave it there for now. WHen they are compelted, the next version will have compelted Structural & Damage Model, Effects & Lights, and Ordinances manual. Cheers!

I would like to share what I discoverd about how the fligh tmodel works in SF2. this is from the flight model manual I am working on, the introduction section: Eagle114th

Hello @Stary I am very pleasantly surprised to see you here! I am big fan fo your cockpit mods! I would like to ask you to check the mod I worked lot on, related to avionics and cockpit upgrade mod, here is the link: https://combatace.com/files/file/18363-sf2-avionics-community-pack-sf2-acp-beta/ And about the DLL files and ini files; That is noted. I have the plans to go through the viewlist and other ini files. Right now I am digging through the very complicated huge DLL file, known as Aircraft Objects DLL. I am almost done creating the very detailed manuals related to flight model, structural & Damage model, Effects & Light, and Ordinances (weapons + guns + ECM). When I finish working with Aircraft Objects DLL, will move on to the DLL related to what you requested. By the way, I will send you PM soon. Eagle114th

Hello @mue and @pvince Wanted to give you a head up that the ful document on the aero keys, including the stalls are now released in my post above. Thought it might provide to be helpful for fligh tmodel tweakings. Cheers!

Hello0 everyone! I have spent over a week working on this files and I just finished the hardest part, the pocket course. From now on, the rest of Aircraft data.INI and guidance will be done by this week hopefully. I would like to share and get feedback on the pocket course please. The purpose of the pocket course is to make it streamlined, easyto read and digest when learning how to work with the aero keys, the backbone of the flight models. Here are two files: FLIGHT MODEL - AERODYNAMIC REFERENCE KEYS.txt FLIGHT MODEL - AERODYNAMIC KEYS (POCKET COURSE).txt Eagle114th

Hello everyone! I have been working A LOT on what is known as "pocket course" for coefficient as part of the flight model guidance / information library big project. Here is what I have found while digging through Aircraft Objects Dll file: ============================================== AERODYNAMIC KEYS — GROUPED LIST (SF2 BUILD) ============================================== -------- (legend: -------- FLIGHT DYNAMICS PARAMETERS α = AoA (angle of attack, deg): Angle between wing chord and relative wind. β = sideslip (deg): Angle of sideways slide relative to flight path. p = roll-rate (rad/s): Rate of rotation around longitudinal axis. q = pitch-rate (rad/s): Rate of rotation around lateral axis. r = yaw-rate (rad/s): Rate of rotation around vertical axis. S = wing area (m²): Reference surface area for lift/drag calculations. c̄ = MAC (mean aerodynamic chord, m): Average wing chord length. AERODYNAMIC COEFFICIENTS (Force and Moment Multipliers) CL = lift coefficient: Total lift force multiplier (e.g., A-10’s CL rises in turns). CD = drag coefficient: Total drag force multiplier (e.g., F-100’s CD spikes with spoilers). Cm = pitching moment coefficient: Torque rotating nose up/down (e.g., F-4’s Cm balances pitch). Cl = rolling moment coefficient: Torque rotating wings left/right (e.g., F-104’s Cl drives fast rolls). Cn = yawing moment coefficient: Torque rotating nose left/right (e.g., MiG-15’s Cn fights fishtailing). Cy = sideforce coefficient: Lateral force pushing plane sideways (e.g., A-10’s Cy stabilizes slips). SUBSCRIPT MODIFIERS (Coefficient Conditions) a = vs. AoA (α): Effect tied to angle of attack (e.g., CLa for lift slope). 0 = at zero AoA: Baseline effect at α=0° (e.g., CL0 for camber lift). dc = delta control: Change per degree of control surface deflection (e.g., Cldc for aileron roll). b = vs. sideslip (β): Effect from sideslip angle (e.g., Cnb for yaw stability). p = vs. roll-rate (p): Effect from roll rate (e.g., Clp for roll damping). q = vs. pitch-rate (q): Effect from pitch rate (e.g., Cmq for pitch damping). r = vs. yaw-rate (r): Effect from yaw rate (e.g., Cnr for yaw damping). α̇ = vs. AoA-rate: Effect from rate of AoA change (e.g., Cmad for pitch damping). ----------------------------------------------------------------------------------------- READ CONDITIONS • Set HasAeroCoefficients=TRUE in the component. • For wings/tails, usually also set LiftSurface=TRUE. ------------------------------- BASE COEFFICIENTS (LIFT / DRAG) ------------------------------- CLa — Lift-curve slope (dCL/dα): how fast CL rises with α CL0 — Baseline lift at α=0° (camber/trim bias) CD0 — Zero-lift (parasite) drag baseline CDL — Induced/α-related drag (drag from making lift) ------------------------------ LONGITUDINAL (PITCH) STABILITY ------------------------------ Cm0 — Baseline pitching moment (nose-up/down bias) Cmq — Pitch-rate damping (moment vs q) Cmad — Pitch moment vs AoA-rate (α̇) ----------------------------- LATERAL STABILITY (ROLL AXIS) ----------------------------- Clb — Roll moment vs β (dihedral effect) Clp — Roll-rate damping (moment vs p) Clr — Roll moment from yaw-rate r (roll–yaw coupling) | Cross-Coupling -------------------------------- DIRECTIONAL STABILITY (YAW AXIS) -------------------------------- Cnb — Yaw moment vs β (weathercock stability) Cnr — Yaw-rate damping (moment vs r) Cnp — Yaw moment from roll-rate p (adverse yaw) | Cross-Coupling ----------------------------------------------- SIDE FORCE COEFFICIENTS (FUSELAGE / TALL EFFECTS) ----------------------------------------------- Cyb — Sideforce vs β (sideslip) | Fuselage + Vertical Tail Cyp — Sideforce from roll-rate p (cross-coupling) Cyr — Sideforce from yaw-rate r (cross-coupling) ------------------------------------------------------------ CONTROL SURFACE COEFFICIENTS (DELTAS) — from TControlSurface ------------------------------------------------------------ (Defines the CHANGE in a coefficient per degree of surface deflection) CDdc — Drag change per degree. CLiftdc — Lift change per degree. Cmdc — Pitching moment change per degree. Cydc — Sideforce change per degree. Cldc — Rolling moment change per degree. Cndc — Yawing moment change per degree. --------------------------- GEOMETRY / REFERENCE POINTS --------------------------- Xac — Aerodynamic-center X-location (can be tabled vs Mach). Qr — Downwash / relief factor (vs α). ----------------------------- STALL / ENVELOPE BEHAVIOR ----------------------------- CheckStall — Enable stall modeling for this surface. AlphaStall — AoA (deg) where stall onset begins. AlphaMax — Max AoA clamp (deg) AlphaDepart — AoA (deg) where departure / spin may begin CLmax — Max lift coefficient before stall limits apply. StallMoment — Extra pitching moment in stall StallDrag — Extra drag multiplier in stall StallHysteresi — AoA gap between stall entry / exit ========================================= ALLOWED AERO TABLE KEYS (THIS DLL BUILD) ========================================= [Mach-based tables] — scale vs Mach number • CD0MachTable — scales CD0 (parasite drag) with Mach • CL0MachTable — scales CL0 (zero-AoA lift) with Mach • CLaMachTable — scales CLa (lift slope) with Mach • CmqMachTable — scales Cmq (pitch-rate damping) with Mach • XacMachTable — **shifts** Xac (position) with Mach ← not a multiplier (XacMachTable Note: This is a position shift, not a multiplier) [Alpha-based tables - for Base Coefficients] • CDLAlphaTable — scales CDL (induced/α-drag) with α • Cm0AlphaTable — scales Cm0 (baseline pitch moment) with α • ClbAlphaTable — scales Clb (roll vs β) with α • ClpAlphaTable — scales Clp (roll-rate damping) with α • ClrAlphaTable — scales Clr (roll from r) with α • CnbAlphaTable — scales Cnb (yaw vs β) with α • CnpAlphaTable — scales Cnp (yaw from p) with α • CnrAlphaTable — scales Cnr (yaw-rate damping) with α • QrAlphaTable — scales Qr (downwash/relief) with α [Alpha-based tables — Control Surface Deltas] • CmdcAlphaTable — scales Cmdc (pitch delta) with α • CldcAlphaTable — scales Cldc (roll delta) with α • CndcAlphaTable — scales Cndc (yaw delta) with α • CLiftdcAlphaTable — scales `CLiftdc` (lift delta) with α [Control Effectiveness Tables - for TControlSurface] • ControlIASTable — scales overall effectiveness vs Indicated Airspeed • ControlMachTable — scales overall effectiveness vs Mach number ---------------- STALL-REGION FX ---------------- DownwashAlphaTable — Downwash effect vs α for downstream surfaces. StallLiftTable — Detailed CL shaping deep into stall StallDragTable — Detailed CD rise deep into stall StallXacShiftTable — Xac shift vs α in stall And here is sample of the pocket course: ==================================================================== -------------------------------------------------------------------- ------------------ BASE COEFFICIENTS (LIFT / DRAG) ----------------- -------------------------------------------------------------------- ==================================================================== ------------------------------------------------------------------- CLa — Lift-curve slope (dCL / dα): how fast CL rises with α | Float ------------------------------------------------------------------- • Desc: > This is the primary lift-generating power of an aerodynamic surface. > It defines how quickly the Coefficient of Lift (CL) increases as the AoA (α) increases. • Real-World Examples & Analogy: > Wings types situations: - Straight wing (e.g., A-10): Stable lift buildup, lower CLa for steady flight. – Swept / Delta (e.g., F-100, Mirage): CL can rise quickly at low – mid α; if CLmax is similar, you reach CLmax at a lower α, so stall occurs at a lower AoA. Actual stall still depends on CLmax and (stall) tables. > Like wing horsepower: high-performance glider (high CLa) soars easily; flat board (low CLa) barely lifts. • Behavior: > Higher CLa = more lift per α degree, agile turns / climb > Lower CLa = stable but less responsive. > Value Effects: - Positive: Boosts lift, improves maneuvers (normal for wings). - Zero: No lift from α, plane unflyable. - Negative: Downforce, reverses pitch, unstable. • Limits / Tuning: > 0.09–0.11 → Agile fighters (e.g., F-16, tight turns). > 0.05–0.08 → Stable bombers / trainers (e.g., A-10, low stall speed). > 0.0 → No lift, avoid for flying surfaces. • Components: > Primary: [Wing], [HorizontalTail] (main lift surfaces). > Secondary: [Fuselage] (body lift in fighters like F-16). > Usually 0.0: [VertTail] (no lift design). • Interactions: > The total lift force is scaled by the ReferenceArea from [AircraftData]. > The CLa slope is effective only until the AoA reaches AlphaStall, at which point the lift is limited by CLmax. > Ties to CDL (more lift = more induced drag). • Situation Example: > F-100 struggles in turns: Increase CLa to 0.09 on [Wings] for better lift / maneuverability - NOTE: It is critical to understand the difference between these terms. > CL is the current Coefficient of Lift, which changes constantly in flight. > CLa is the slope or "power" that determines how fast CL changes with AoA. > CLmax is the maximum possible value for CL. A stall occurs when the current CL reaches CLmax. > A slope (CLa) cannot "meet" a maximum value (CLmax). ──────────────────────────────────────────────────────────────────── ------------------------------------------------------ CL0 — Baseline lift at α=0° (camber/trim bias) | Float ------------------------------------------------------ • Desc: > Lift (CL) at zero α, from airfoil camber (curved shape). • Real-World Examples & Analogy: > Cambered vs. symmetric airfoil: - Cambered wing (e.g., F-4): Positive CL0, built-in lift, nose-down Cm0. - Symmetric wing (e.g., F-16 aerobatic): Zero CL0, no bias, good for inverted flight. > Analogy: - Curved wing shape (camber) speeds air over top for low pressure "suck," creating lift like air pushing a sail—flat symmetric airfoil needs α for lift. • Behavior: > Positive CL0: Natural lift at level flight, easier cruise (cambered wings). > Zero CL0: No lift without α, symmetric, no bias (aerobatics). > Negative CL0: Downforce, nose-down bias (stabilizers). • Limits / Tuning: > 0.10–0.15 → Cambered fighters (e.g., F-4, cruise lift). > 0.0 → Symmetric aerobatics (e.g., F-16, inverted flight). > Negative → Downforce tails (e.g., -0.05, stabilizes pitch). • Components: > Primary: [Wing] (cambered lift). > Secondary: [HorizontalTail] (incidence angle). > Usually 0.0: [VertTail], [Fuselage] (symmetric). • Interactions: > Ties to Cm0 (positive CL0 = negative Cm0 nose-down) - Affects trim speed • Situation Example: > You're modeling a WWII fighter that feels "dead" and requires constant back-pressure on the stick to stay level. By giving its wings a small positive CL0 (e.g., 0.12), you simulate the lift from its cambered airfoil, making it fly more naturally at cruise speeds. • Note: > This key models the effect of the airfoil's shape. > Lift generated from the wing's mounting angle on the fuselage (angle of incidence) is handled separately by the geometry of the 3D model. ──────────────────────────────────────────────────────────────────── ``` ------------------------------------------------ CD0 — Zero-lift (parasite) drag baseline | Float ------------------------------------------------ • Desc: > Constant drag from a component’s shape, size, and surface roughness, even when no lift is made. > All parts (wings, fuselage, tail) add to total drag, no matter AoA. • Real-World Examples & Analogy: > Sleek vs. blunt fuselage: - Sleek (e.g., F-104): Low CD0, high speed. - Blunt (e.g., A-10): Higher CD0, rugged but draggy. > Analogy: Brick (high CD0, blunt resistance) vs. sports car (low CD0, streamlined flow). • Behavior: > Baseline drag grows with V²; sums from all parts. > Value Effects: - Positive: Increases resistance, lowers speed (normal for all parts). - Zero: No drag, unrealistic (avoid). • Limits / Tuning: > 0.01–0.02 → Sleek fighters (e.g., F-104, high speed). > 0.03–0.05 → Rugged attackers (e.g., A-10, more drag). > High (0.06+) → Gear/stores, slows plane. • Components: > Primary: [Fuselage], [Wing] (main drag sources). > Secondary: [Tail], [Pylon] (add-ons like gear). • Interactions: > This is the baseline drag to which CDL (induced drag) is added to get the component's total drag. > Its effect is modified at high speeds by the CD0MachTable. • Situation Example: > Plane can't reach top speed: Lower CD0 0.02 on [Fuselage]/[Wings] for less drag. • Note: > This represents the drag of the "clean" component. > Drag from deflected control surfaces, deployed landing gear, and external weapons is calculated separately and added on top of this. ──────────────────────────────────────────────────────────────────── ------------------------------------------------------------ CDL — Induced/α-related drag (drag from making lift) | Float ------------------------------------------------------------ • Desc: > Drag from generating lift, caused by wingtip vortices as AoA or flaps increase. > Extra lift (e.g., flaps for takeoff/landing) adds more drag (CDL). • Real-World Examples & Analogy: > Low vs. high aspect ratio (AR) wings: - Aspect ratio (AR) affects efficiency: • High AR (long, narrow wings like A-10 attacker) cuts induced drag (low CDL) for better glide and sustained maneuvers. • Low AR (short, stubby wings like F-104 fighter) boosts maneuverability but adds drag (high CDL), causing quick energy loss in turns. > Analogy: Hand out car window angled for lift—extra push-back (CDL) vs. flat (CD0). • Behavior: > Low at zero α (cruise) > high at high α (turns / landings) > flaps boost lift and CDL. > Value Effects: - Positive: Increases with CL², bleeds speed in maneuvers (normal for lifting surfaces). - Zero: No induced drag, unrealistic for wings. • Limits / Tuning: > 0.05–0.1 → Short-wing fighters (e.g., F-100, high bleed in turns). > 0.02–0.04 → Long-wing attackers (e.g., A-10, better retention). > High (0.1+) → Delta wings, quick slowdown. • Components: > Primary: [Wing], [HorizontalTail]: This "drag from making lift" is primarily generated by your main lifting surfaces. > Secondary: [Fuselage]: Only if it's also configured to produce body lift (CLa greater than 0). • Interactions: > ~ CL² / (π AR e); scaled by CDLAlphaTable; flaps add via CDdc / CLiftdc. • Situation Example: > Your modern fighter jet loses too much speed in a sustained, high-G turn. > To improve its sustained turn performance, you would lower the CDL value on its wing components. • Note: > This key is crucial for defining an aircraft's "instantaneous" vs. "sustained" turn performance. > An aircraft with high lift (CLa) but also high induced drag (CDL) might have a great instantaneous turn, but its poor energy retention will result in a bad sustained turn. The purpose of this is to make it easy to read and digest the information about each aero keys, so it is easy to conceptually grasp how they affect the aircraft physic (Flight model). With that, I hope it will enable modder to confidently and comfortable to tweak the flight models for aircraft in SF2. I have gone through various revisit, starting over until I got this 'streamlined' flows of going through the aero keys and information. I still have lot to do, and it is progressing well! Cheers!

Hello Mue, Good question, and according to the dump files: The blending refer to how the game smoothly transitions from the normal flight model to the stall flight model. When AoA (α) crosses AlphaStall, the sim begins fading in the stall effects. It comes down to the shaape of the fade from the staallt able near Alphastall. Example: > If your first stall-table point at α=AlphaStall is 1.00, and the next few are 0.95 → 0.85 → 0.70, the lift loss will feel smooth. > If you jump straight to 0.50, it will feel abrupt. Eagle114th

Hello pvince! That is a good question, and you are right. From my analysis, the standard tables like `CLaMachTable` act as multipliers on the base coefficient. What I've realized when working with the aerodynamic keys is that the system is quite layered. Coefficients (`CLa`, `CL0`, `CD0`, etc.) are dimensionless values that feed the core force equations: `L = 0.5 ρ V² S CL` `D = 0.5 ρ V² S CD` Standard Tables (`…MachTable`, `…AlphaTable`) are indeed multipliers that scale those base coefficients (e.g., 1.00 = no change; 0.90 = -10%; 1.10 = +10%). The stall tables, on the other hand, are a special case, just as you suspected. Based on the dump codes of the `AircraftObject.dll`: `StallXacShiftTable` is the main exception: it is additive, adding a position shift in meters to the aerodynamic center (`Xac`), not a multiplier. `StallLiftTable` and `StallDragTable` act as multipliers. `CLmax` still matters as it caps the peak pre-stall lift. Once you’re past `AlphaStall`, the game blends to these stall table multipliers. Here is a tiny example of a typical pattern: ; --- Stall Table Examples --- ; At AlphaStall (16°), start at 1.00 (100% of CLmax), then taper lift down StallLiftTableData= 1.00, 0.85, 0.70, 0.60 ; Ramp drag up strongly in a deep stall (multiplying against pre-stall drag) StallDragTableData= 1.20, 1.60, 2.20, 3.00 ; Move the aerodynamic center rearward (in meters) as AoA increases StallXacShiftTableData= 0.00, -0.05, -0.10 This system allows modders to precisely define the complex and often non-linear Eagle114th

Hello everyone! Just a head up, the list of aero keys are growing with additional keys I find from the Aircraft Objects DLL. As I have thought so, the flight model is actually far more advanced than I realize. I am so darn impressed and I still don't understand how TK do not use full of it. Therefore, I have an interesting theory: TK, deep there in his heart, he want advanced mid-fidelity simulation, but he fears that it might not attract enough audience for his marketing. Therefore, he implements the helper to turn SF series into lite sim. IF he did not want mid-fidelity (semi-complex), he would not have implemented these very advanced flight model features. It's coded in there. Not only components have aero keys, the control surface also have it. And the air brake, slats, flaps, and other system's geometry shapes are also taken into accounts how it affect flight characteristic. Hello Mue! That is great questions, from what I have discovered and understand and created the documents on it for you: The stall behavior in SF2 is not something that you just simply turn on / off. The stall behavior is influenced by a group of aero keys in the `[Component]` sections. Here are the groups of keys related to stalls: --------------------- A) Entering the Stall --------------------- Three keys work together to initiate the stall: 1) CheckStall=TRUE: This is the master switch that enables stall physics for a component (like a wing). If it's `FALSE`, the component will not stall. 2) AlphaStall: This is the Angle of Attack (in degrees) where the stall begins. When the component's AoA approaches this value, the game starts to blend in the stall effects. 3) CLmax: This is the maximum Coefficient of Lift the wing can produce. When the wing's AoA exceeds `AlphaStall`, its ability to generate lift drops off from this peak value, causing the aircraft to lose altitude and control. --------------------------------------- B) Post-Stall Behavior (The Deep Stall) --------------------------------------- When an aircraft stalls, this next set of keys takes over to define its behavior. This is where you can set if the stall is gentle and recoverable or violent and dangerous. 1) StallMoment: This is the most vital key for post-stall behavior. It applies an additional pitching moment *only when the wing is stalled*. A negative (nose-down) value will force the nose down, helping the pilot recover. A zero or positive (nose-up) value is dangerous and can cause the nose to pitch *further up* into an unrecoverable "deep stall" or a flat spin. 2) StallDrag: This key adds a large amount of extra drag when the wing is stalled, realistically causing the aircraft to decelerate rapidly. 3) AlphaDepart: This is the AoA at which the aircraft may "depart" from controlled flight entirely, often leading to a spin. 4) AlphaMax: This is a hard limit or 'clamp' on the maximum Angle of Attack the component can reach. It prevents the aircraft from pitching up indefinitely into an extreme post-stall condition, effectively setting a ceiling on the stall's severity. 5) StallHysteresis: This makes the stall 'sticky,' meaning the Angle of Attack must be reduced to a lower value than the initial stall angle in order to recover. For example, if `AlphaStall=16` and `StallHysteresis=2.0`, the wing won't un-stall until the AoA drops below 14 degrees (16 - 2). This simulates the difficulty of re-attaching airflow to a stalled wing. ------------------------------------- C) Advanced Stall Tuning (The Tables) ------------------------------------- For even more precise control over post-stall behavior, the flight model uses these tables: * `StallLiftTable`: This table gives you fine-grained control over how much lift the wing loses deep into the stall. Instead of a simple on/off effect, you can create a curve that defines the lift coefficient at various high angles of attack (e.g., 20, 25, 30 degrees), modeling the post-stall behavior in detail. * `StallDragTable`: Similar to `StallLiftTable`, this allows you to define a precise curve for how drag increases in the post-stall regime. You can model a massive, sharp increase in drag or a more gradual one. * `StallXacShiftTable`: This is an expert-level key. It models how the wing's Center of Lift (`Xac`) shifts as the wing stalls. This shift has a powerful effect on the `StallMoment` and can be used to fine-tune the pitching behavior (e.g., a sharp nose-down pitch) during a stall. * `DownwashAlphaTable`: This table defines how the downwash from a forward wing affects the airflow hitting a surface behind it (like the tail). It's crucial for modeling how tail effectiveness changes at high angles of attack, which is a key part of realistic stall and spin behavior. Here are ini usage example for stalls ; --- Stall Characteristics --- CheckStall=TRUE AlphaStall=16.0 AlphaMax=25.0 AlphaDepart=30.0 CLmax=1.45 StallMoment=-0.005 StallDrag=0.010 StallHysteresis=1.5 // --- Example 2: StallLiftTable --- // This table defines the lift coefficient in the deep-stall regime, after // the initial stall point (`AlphaStall`) has been passed. // // It provides a more detailed curve than the simple `CLmax` value. // StallLiftTableNumData=4 StallLiftTableStartX=16.0 // Starts where AlphaStall begins StallLiftTableDeltaX=4.0 StallLiftTableData=1.45, 1.20, 0.90, 0.75 // Lift decreases as AoA increases past stall // This translates to: // At 16 deg AoA (AlphaStall), CL is 1.45 (CLmax). // At 20 deg AoA, CL drops to 1.20. // At 24 deg AoA, CL drops to 0.90. // At 28 deg AoA, CL drops to 0.75. //------------------------------------------------------------------ // --- Example 3: StallDragTable --- // This table defines how the drag coefficient increases dramatically // in the post-stall regime. // StallDragTableNumData=4 StallDragTableStartX=16.0 StallDragTableDeltaX=4.0 StallDragTableData=0.15, 0.35, 0.60, 0.90 // Drag increases rapidly as AoA increases // This translates to: // At 16 deg AoA, post-stall drag coeff is 0.15. // At 20 deg AoA, it jumps to 0.35. // At 24 deg AoA, it jumps to 0.60. // At 28 deg AoA, it jumps to 0.90. //------------------------------------------------------------------ // --- Example 4: StallXacShiftTable --- // This is an expert-level table that models the shift of the wing's // aerodynamic center (Xac) during a stall. A rearward shift // can cause a strong, uncommanded nose-up pitching moment (StallMoment). // StallXacShiftTableNumData=3 StallXacShiftTableStartX=16.0 StallXacShiftTableDeltaX=5.0 StallXacShiftTableData=0.0, -0.1, -0.15 // Xac moves rearward (negative) // This translates to: // At 16 deg AoA, the Xac shift is 0.0. // At 21 deg AoA, the Xac has shifted rearward by 0.1 meters. // At 26 deg AoA, the Xac has shifted rearward by 0.15 meters. ``` ------------------------- Qr Coefficient (Downwash) ------------------------- The `Qr key is an advanced aerodynamic coefficient related to downwash. What is Downwash? When a wing generates lift, it deflects the air downwards behind it. This downward-moving air is called downwash. This is critical because it changes the angle at which the air hits any surface located behind the wing, such as the horizontal tail. How Qr Works The `Qr` coefficient on a forward component (like a main wing) models the strength of this downwash effect. The game uses this value to modify the local Angle of Attack experienced by components located behind it. Why it matters: The downwash from the main wing reduces the effective Angle of Attack on the horizontal tail. This has a significant impact on longitudinal stability and elevator effectiveness. Without modeling downwash, the tail would be too powerful, and the aircraft's pitch stability would be unrealistic. How it's used: The `Qr` key is often used with the `DownwashAlphaTable, which allows a modder to define how the strength of the downwash changes at different angles of attack. This is a high-fidelity feature that allows for very accurate stability modeling. Allowed Value: > A `Float`. It's typically a small positive number, often less than 1.0. Default Value: > If the key is not present in the `[Component]` section, the game engine defaults to a value of 0.0, meaning the component produces no downwash effect. Interactions: `Qr` works directly with the `4 keys of DownwashAlphaTables`. DownwashAlphaTableNumData DownwashAlphaTableDeltaX DownwashAlphaTableStartX DownwashAlphaTableData // --- Example 1: DownwashAlphaTable --- // This example would be on a [MainWing] component. It models how the // downwash effect increases as the wing's Angle of Attack (AoA) increases, // which affects the horizontal tail's effectiveness. // // Base downwash strength is set by the "Qr" key on this same component. // DownwashAlphaTableNumData=4 DownwashAlphaTableStartX=0.0 DownwashAlphaTableDeltaX=5.0 DownwashAlphaTableData=0.1, 0.4, 0.8, 1.0 // This translates to: // At 0 deg AoA, downwash strength is at 10% of its base value. // At 5 deg AoA, downwash is at 40%. // At 10 deg AoA, downwash is at 80%. // At 15 deg AoA, downwash is at 100%. The final downwash strength is a product of the `Qr` value and the multiplier from the table at the current Angle of Attack. NOTE: - It should only be applied to forward, lift-generating surfaces like the main wings or canards. - If your aircraft feels too stable in pitch or the elevator feels weak, it might be because the downwash effect is too strong. Reducing the `Qr` value on the main wing will increase the tail's effectiveness. - Conversely, if the aircraft is unstable and "porpoises" (pitches up and down), increasing the `Qr` value will create more downwash, which increases stability by making the tail less effective. - Start with a small value (e.g., `Qr=0.1` or `Qr=0.2`) and adjust in small increments while testing flight behavior at different speeds and angles of attack. Eagle114th

Hello everyone! It have been incredible journey digging through Aircraft Objects where the core of flight model, AI, and INI handling related to aircraft is stored in. The such dump files are so complicated as stated, that there are endless of codes to go through. So I developed the new ways to dig and extract the complete list of associated keys for each sections in cockpit.ini and aircraft data .ini, as well looking through flight model and AI. This time, with AI, as described the "Tree" Method and "Fishing Method", I used hybrid of both which works so well! First, I set the fishing method to find the 'root' function, and the 'big fish" using ini several keys, which led me to the class that is connected to the list keys for specific section. Then I had AI to switch to 'tree' method, to go from that class, and parse through it from 'root" to all interconnected branches. Upon discovering the flight model, it surprised me. What confused me is that I used to think that SF2 is 'lite' in an aspect of flight model, which is actually the opposite. The flight model, in fact is so complicated and advanced, with helper on top of it, making it seem like 'lite' flight model. But please remember, I could be incorrect, it is based on what I understand as I go through the fligh model section from aircraft data.ini: [Advanced flight model] -> Helper (Making FM simple) -> SF2 gameplay. And how flight model is set, in these steps: ==================================================================== ---------------------------- CHECK LIST ---------------------------- ==================================================================== STEP 1 - FOUNDATION (TRUE DATA) — [AircraftData] - Sets the “real” geometry and mass: • ReferenceArea, ReferenceSpan, ReferenceChord • EmptyMass, EmptyInertia (Ix, Iy, Iz) • CGPosition, CockpitCGOffset • Units (UseMetricUnit) • Component[001..N] list (what sections to load) - Think: “size + weight + balance.” These numbers are the base the sim trusts. STEP 2 — STRUCTURE & AERO (per component) - Sections: [Fuselage], [LeftWing], [RightWing], [VerticalTail], [HorizontalTail], … - Class: TComponent - What they add: • Lift/drag/coefficient data (CLa, CD0), stall flags (CheckStall, AlphaStall, CLmax) • Optional body aero (Cyb, Cnb), visuals (vortex), structure factors - Think: “how the airframe actually makes CL/CD around the base geometry.” STEP 3 — CONTROL SURFACES (deflection + tables) - Sections: [Aileron], [Elevator], [Rudder] (SystemType=CONTROL_SURFACE) - What they add: • Min/MaxDeflection, ControlRate, lockouts • AoA/IAS/Mach tables that change CL/CD with deflection - Think: “how stick/rudder changes forces with angle, speed, and Mach.” STEP 4 — HIGH-LIFT DEVICES (flaps/slats) - Section: [Flaps]/[Slats] (SystemType=HIGHLIFT_DEVICE) - What they add: • Deployment rules, DeltaStallAlpha, AreaRatio, Setting[x].Angle • Extra lift (and usually extra drag) when deployed - Think: “low-speed help for takeoff/landing; modifies CL/CD when active.” STEP 5 — PROPULSION - Section: [EngineX] (JET_ENGINE / PROP_ENGINE / ROCKET_ENGINE) - What they add: • Thrust magnitude/response, positions, and directions (vectoring/prop effects) - Optional VTOL: add Reaction Control blocks (RCS) for hover jets - Think: “push the airplane; where and how the force is applied.” STEP 6 — AIRBRAKE / GEAR / HOOK / CHUTE - Add or remove drag/forces when deployed; affect ground handling and approach behavior. - Think: “situational force/drag changes.” STEP 7 — FLIGHTCONTROL (envelope + dampers) - Section: [FlightControl] - What it adds: • Speeds (stall/cruise/climb/corner/landing), MaxSpeedSL, MaxG, MachLimit/MachLimitDry • Dampers: PitchDamper, RollDamper, YawDamper, SideslipDamper, DamperLimit - Think: “stability and limits on top of the physics.” -------------------------------------------------------------------- RUNTIME MODIFIERS (always active while flying) - Fuel burn and external stores: • Change mass, CGPosition, and inertia live (especially roll inertia) • Add drag from stores and gear states - Atmosphere: • Air density falls with altitude → both lift and drag fall HOW THEY COMBINE (one-screen view) - Lift = 0.5 × density × speed² × ReferenceArea × CL_effective - Drag = 0.5 × density × speed² × ReferenceArea × CD_effective - Thrust = from engine(s) at ThrustPosition with ThrustAngles - Rotation: • angular_accel ≈ control_moment ÷ EmptyInertia_axis • decay of rate ≈ damper × current_rate (capped by DamperLimit) WORKFLOW 1) Fill [AircraftData] with real numbers (area/span/chord, mass, inertia, CG). 2) Define TComponent surfaces (CLa, CD0, stall set). 3) Add engines; place thrust vectors; add RCS if VTOL. 4) Add control surfaces (deflection + AoA/IAS/Mach tables). 5) Add high-lift devices; then airbrake and gear. 6) Tune [FlightControl] dampers and envelope. 7) Test with fuel/stores variations. RULE OF THUMB - Foundation keys (AircraftData) = “truth.” Keep them realistic. - Other sections = “fine-tune and add detail” on top of that truth. I am currently working on a pocket flight model manual / modding guidance for modder, including the detailed explanation how each Aero key works and how they affect aircraft. A quick reference that will make it easy for us to grasp them conceptually. Now is perfect time for me to learn too. So I am learning a lot as I go along on this project! However, as you can see, from the checklist above (part of manual guidance), steps 1 is where the data is input and is left alone, no changing them. To change / tune the 'feeling" / characteristic of aircraft, step 2 is where it is. Here is list of aero keys that is available: =============================== AERODYNAMIC KEYS — GROUPED LIST =============================== (legend: α=AoA/angle of attack, β=sideslip, p=roll-rate, q=pitch-rate, r=yaw-rate, S=wing area, c̄=MAC/mean aerodynamic chord) READ CONDITIONS • Set HasAeroCoefficients=TRUE in the component. • For wings/tails, usually also set LiftSurface=TRUE. --------------------------------- BASE COEFFICIENTS (LIFT / DRAG) --------------------------------- CLa — Lift-curve slope (dCL/dα): how fast CL rises with α. CL0 — Baseline lift at α=0° (camber/trim bias). CD0 — Zero-lift (parasite) drag baseline. CDL — Induced/α-related drag (drag from making lift). -------------------------------------- LONGITUDINAL (PITCH) COEFFICIENTS -------------------------------------- Cm0 — Baseline pitching moment (nose-up/down bias). Cmq — Pitch-rate damping (moment vs q). Cmad — Pitch moment vs AoA-rate (α̇) (if present). ----------------------------------------------- LATERAL / DIRECTIONAL (SIDE / ROLL / YAW) ----------------------------------------------- Cyb — Sideforce vs β (sideslip). Cyp — Sideforce from roll-rate p (cross-coupling). Cyr — Sideforce from yaw-rate r (cross-coupling). Clb — Roll moment vs β (dihedral effect). Clp — Roll-rate damping (moment vs p). Clr — Roll moment from yaw-rate r (roll–yaw coupling). Cnb — Yaw moment vs β (weathercock stability). Cnp — Yaw moment from roll-rate p (coupling). Cnr — Yaw-rate damping (moment vs r). --------------------------- GEOMETRY / REFERENCE POINTS --------------------------- Xac — Aerodynamic-center X-location (can be tabled vs Mach). Qr — Downwash/relief factor used in aero build (vs α) (if present). ----------------------------- STALL / ENVELOPE BEHAVIOR ----------------------------- CheckStall — Enable stall modeling for this surface. AlphaStall — AoA (deg) where stall onset begins. AlphaMax — Max AoA clamp (deg) (if present). AlphaDepart — AoA (deg) where departure/spin may begin (if present). CLmax — Max lift coefficient before stall limits apply. StallMoment — Extra pitching moment in stall (if present). StallDrag — Extra drag multiplier in stall (if present). StallHysteresis — AoA gap between stall entry/exit (harder to recover) (if present). ========================================= ALLOWED AERO TABLE KEYS (THIS DLL BUILD) ========================================= (Only these names are read. Others are ignored. Tables multiply the base coeff; 1.0 = no change.) [Mach-based tables] — scale vs Mach number • CD0MachTable — scales CD0 (parasite drag) with Mach • CL0MachTable — scales CL0 (zero-AoA lift) with Mach • CLaMachTable — scales CLa (lift slope) with Mach • CmqMachTable — scales Cmq (pitch-rate damping) with Mach • XacMachTable — shifts Xac (aero center X) with Mach [Alpha-based tables] — scale vs AoA α (degrees) • CDLAlphaTable — scales CDL (induced/α-drag) with α • Cm0AlphaTable — scales Cm0 (baseline pitch moment) with α • ClbAlphaTable — scales Clb (roll vs β) with α • ClpAlphaTable — scales Clp (roll-rate damping) with α • ClrAlphaTable — scales Clr (roll from r) with α • CnbAlphaTable — scales Cnb (yaw vs β) with α • CnpAlphaTable — scales Cnp (yaw from p) with α • CnrAlphaTable — scales Cnr (yaw-rate damping) with α • QrAlphaTable — scales Qr (downwash/relief) with α RULES FOR TABLES • Exact key names only (case/spelling matter). • Missing table ⇒ engine uses 1.0 (no scaling) for that coeff. • Define inside the specific component (e.g., [LeftWing]). ---------------- STALL-REGION FX ---------------- DownwashAlphaTable — Downwash effect vs α for downstream surfaces. StallLiftTable — Detailed CL shaping deep into stall (if present). StallDragTable — Detailed CD rise deep into stall (if present). StallXacShiftTable — Xac shift vs α in stall (if present). ================ TINY EXAMPLES ================ ; Mach-based scaling (CLa weaker near transonic) [LeftWing] HasAeroCoefficients=TRUE LiftSurface=TRUE CLa=0.095 CLaMachTable= 0.0,1.00, 0.80,0.98, 1.00,0.90, 1.20,0.85 ; AoA-based drag rise near stall [LeftWing] CD0=0.005 CDLAlphaTable= 0,1.00, 10,1.10, 14,1.30, 16,1.60, 18,2.20 //================================================================== // --- Aerodynamic Key Examples for a [Component] Section --- //================================================================== // NOTE: These keys are only read if HasAeroCoefficients=TRUE // --- Base Aerodynamic Coefficients --- // These define the fundamental aerodynamic personality of the component. // The values below are typical for a fighter's main wing. // CLa=0.0950 CL0=0.0 CD0=0.0050 CDL=0.0001 Cm0=-0.0250 Cmq=-0.2800 Cmad=-0.0001 Cyb=0.0 Cyp=0.0 Cyr=0.0 Clb=-0.0500 Clp=-0.4500 Clr=0.0 Cnb=0.0 Cnp=0.0 Cnr=0.0 Xac=0.25 Qr=0.0 //------------------------------------------------------------------ // --- Stall Characteristics --- // These define how the component behaves at high angles of attack. // CheckStall=TRUE AlphaStall=16.0 AlphaMax=25.0 AlphaDepart=30.0 CLmax=1.45 StallMoment=-0.005 StallDrag=0.010 StallHysteresis=1.5 //------------------------------------------------------------------ // --- Aerodynamic Tables (Example 1: CLa vs. Mach) --- // This example shows how the Lift Curve Slope (CLa) changes with Mach number. // Notice the drop in the transonic region (around Mach 1.0). // CLaMachTableNumData=5 CLaMachTableDeltaX=0.5 CLaMachTableStartX=0.0 CLaMachTableData=0.095,0.105,0.080,0.060,0.050 //------------------------------------------------------------------ // --- Aerodynamic Tables (Example 2: Cnb vs. Alpha) --- // This example would be for a [VertTail] component. It shows how yaw // stability (Cnb) decreases at a high Angle of Attack (Alpha). // CnbAlphaTableNumData=4 CnbAlphaTableDeltaX=10.0 CnbAlphaTableStartX=0.0 CnbAlphaTableData=-0.120,-0.115,-0.090,-0.050 //------------------------------------------------------------------ // --- Aerodynamic Tables (Stall & Downwash) --- // This example shows a detailed lift curve in a deep stall. // StallLiftTableNumData=3 StallLiftTableDeltaX=5.0 StallLiftTableStartX=25.0 StallLiftTableData=1.20,0.95,0.80 // This defines the downwash from a wing. DownwashAlphaTableNumData=3 DownwashAlphaTableDeltaX=10.0 DownwashAlphaTableStartX=0.0 DownwashAlphaTableData=0.0,0.2,0.3 This led me to have this theory: If the helpers is disabled, we could get to experience the raw advanced flight model. By the way, when both updated cockpit.ini and aircraft data.ini are also completed, it will be released along with the flight model manual / modding guidance. Cheers!

It is based on both of our assessment from what we found in the source (dump file). How we figure the "LIGHT' vs "FULL"? If the class have little implement or lightly coded to do the simple tasks, then it is LIGHT. If the class does more than a few tasks, does lot of tasks, even with few codes, it is 'FULL". However, LIGHT and FULL still means the features works in SF2.

Hello everyone! Sorry for short posts, busy day lately. I have extra time to explains about this project in details: Last week and this week have been steer learning curves for me when it comes to learning how the classes / functions are set in both Avioincs and Aircraft Object DLL files. Both have different ways of how classes are set and what they do with SF2 engine. At the same time, I realized how AI works to the core and how I can use AI the right way. Previously, when using AI, i was still learning how to use it. What I realized: AI is not AGI yet, therefore does not think like we do. Rather, AI follows the patterns of human interactions and is the group of programs that is on the rail of pre-defined instruction. It does not yet teach itself, nor dynamically expand itself into critical thinking or creatively seeking solutions upon the requests. So it means, if you only give simple instruction that is vague, AI will 'guess' itself what to do to find the answer for you. it guess itself based on the scope of the request. So therefore, the more you engineer the prompt with rules, the scope of the tasks, and input the details for instruction, the more likely AI will yield the result that is relevant to what you seek for. Fortunate for me, Ai is 'smart' enough to be able to help me with prompt engineering while assisting me with analyzing how the Avionics and Aircraft Object DLL are set. How I managed to extract the information and learn in this steps with AI effectively and efficiently: 1) Lead up the dump file 2) Upload the dump file to AI and have AI 3) go through the dump, studying how classes are set, and have AI explaining the big picture of the dump situation 4) Develop the prompt with AI to perform the tasks based on what I need 5) while getting result from AI, with the given source where they get it from, I check it with AI, to verify it. However, there are challenge: Besides engineering the prompt, there is also limitation to AI's memories (token). Various AI have their own token limitation. At once when AI exceed the token limitation, the memories run out of space. When that happen, AI forgets the prompt instruction, pushes out the oldest conversation, to make room for newest one, causing AI to give me incorrect information. That means, when I verify with AI, and realize AI start to make mistakes more often, that is when I start new chat, to have a fresh start, then use prompt and re-teach AI to do the task exactly what I need. ----------------------------------------------------------------- Next thing i want to talk about is how did I manage to extract the sections / sub sections / keys / associated key for each ini files from Avionics and Aircraft Object dll files? As noted, Avionics and Aircraft Object works so different ways. Let's picture the tree, there are Root / Trunk, main branches, and many branches / leaves that branches from the main branches. Three parts: Root, main branches, interconnected branches In Avionics Dll file, there are one main root class, then branches of the classes (radar related, HUD related, etc...). And for each classes (roots), there are branches (associated functions), and interconnected functions (many branches) that is connected to the associated functions as well. So I had AI analyzing Avionics by going through one class a time with me, parsing / tracing from root (class a time), going through each associated and interconnected branches for data for ini modding information. ON the other hand, with Aircraft Object dll, oh boy, it is steer chaos, there isn't one root classes, rather many roots classes, connecting everywhere. It's like working with thousands of wires and you try to locate the 'root' wire forking into various wires that also forks even more wires for the right group of wires, from 'root' wire. This DLL handles many files, from cockpit ini, to aircraft data ini to other type of files. there are massive lists of strings used for ini files. Often I see the same strings but different function for different files. so I try to find out which type of ini files they are for. So therefore, I developed new methods of how to find specific root function and associated / interconnected functions in relative to the typie of ini files. I call it "Fishing method" For example: in SF2 modding, you would have aircraft.ini, and in that file, there are CockpitDataFile=", so I looked up for the function that handle "CockpitDataFile", and that function is root function. Then I have pre-made cockpit.ini, example: F-4B_COCKPIT.INI, and that is my 'bait" to catch bigger fish. How this work? NOTE: Each cockpit.ini for each aircraft does not use full list of keys for each sections, rather they use specific keys that is relevant to each aircraft, yet I want to find the full list of keys for each sections right? So to catch the whole list, I use already known working key as bait. Example: [CockpitData] Directory=cockpit HUDMode=CAGED,AA,AG RippleQuantity=1,2,18 RippleInterval=60,100,140 I hunted the functions that handles the string of CockpitData and HUDMode, which gave me functions that do handle them. This gives me full list of the available key! HOWEVER, there is another challenge: Sometime there are multi-function that shares the same strings, but again with the root function, and with AI codes analyzer assistant, we are able to parse between the root function and the 'branch' function to see if they are actually connected to root function. Any functions that is not connected to it, trim it off and only keeping one that is connected to root function. And from there, Ai can also parse between root and branch, as well toward other interconnected functions. And next, it get even more complicated! Sometime the key could not be found in the string, for example: Cm0MachTableNumData This such string does not example in Aircraft Objects dll. BUT if you divide them into this: Cm0 MachTable NumData, which gives us: Cm0 MachTable NumData These three strings does exist in dump though! Turns out there are also cases when some keys in ini is from combined of the strings. And there is another thing I found out: "%sThrottle", %s means any strings attached to "Throttle" So if you look for IdleThrottle, you wont' find it, But you will find %sThrottle. It tells you that SF2 uses %s for various other string for ini files. The cockpit ini modding information is completed. The Aircraft data ini is work in progress which is taking times, due to the nature of the complexity of the dll file. And as stated, how i use AI to work with em as team, and with the specific designed prompt, I am able to extract the information, while verifying it with AI, to ensure the accurate information. This is not 100 percent fool proof that gives us 100 percent accurate information, but it does save us tons of time. If there were no AI, it would have taken us years upon years to go through the decompiled codes. With AI, it reduced my time from years to days. And with the help of the community, we can find out what works and does not work. By the way, please throw out the old files I shared, they are outdated. here is the latest files with more accurate data. Please check them out! SF2 DLL - INI INFO.zip Cheers!

Good morning! Great questions, I will explain more: - PLACEHOLDER = no local logic. It’s basically a stub (often just ctor + empty vfunc). It “exists” but doesn’t do work by itself. - LIGHT = works, but only a little local logic. Usually small checks / assignments / formatting, then delegates to a base class to draw / do the rest. - FULL = works with substantial local logic. Manages its own state / resources, calculations, multiple code paths, and doesn’t just rely on the base. In short: - PLACEHOLDER → doesn’t really do anything locally. - LIGHT → does a little (minimal logic). - FULL → does a lot (rich logic). Both LIGHT and FULL Classes works in SF2, however the tag informs us how deep the implementation is under the hood. Eagle114th

Hello everyone It have been unique intense research and digging through Avionics60, Avionics70, F-14A Avionics, and F-14A IIAF Avionics By comparing the radar and HUD related calsses, I made the mapped list of which classes taht works and does not work. Here is the MIcrosoft Word and .txt )For anyone who want ot use eiter type of files UPDATE: It wont' let me upload the files for now. So instead, I am copying and pasting the list. I am currenlty re-working on the Radar and HUD classes keys and assoicated key, to ensure it have accurate information based on Avionics60 / Avionics70, F-14A Avionics, and F-14A IIAF Avionics DLL dump files. Cheers!

Hello everyone! After releasing SF - ACP beta v0.05 https://combatace.com/files/file/18363-sf2-avionics-community-pack-sf2-acp-beta/ I am now focused on this projects. Recenlty, through the day, with help of AI, digged through the Avionics60 and 70 for more information on TVDisplayData, especially the BlendOp, StageColorOp, and StageAlphaOp. The detailed document on them is created and what I learned is that Avionics60 and 70 have different ways of handling the BlendOps. Based on the dump file of Avionics60, for BlendOp, it only have BLEND_SRC_ALPHA, BLEND_ONE, and BLEND_ZERO. And it does NOT expose big per-stage enums like AVIONICS70.DLL, therefore no StageColorOp and StageAlphaOp. However, please note, I can be wrong on this, it is just based on my current understanding from dump files. However, Avionics70, in the other hand, hve vast range keys for BlendOps, as well have the usage of StageColorOp and StageAlphaOp. Here are two files: Updated Avionics60 with the updated files, and Avionics70 AVIONICS 60.zip AVIONICS 70.zip And you will find AVIONICS 60 - BlendOp.txt and AVIONICS 70 - HUD.txt interesting. And if there is any information that appear ot be incorrect, please let me know. I will fix it. Cheers