Eagle114th

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

Hello everyone! The new version of SF - CAP v0.05 is finally released! UPDATE: Thank you CombatAce Admin / Mods! The files are ready for download now. So much work poured into this version, including the changes to all aircraft's following INI changes: - gun range (Minimum, Maximum, and Default) - DetectSystem, so it actually reference to the avionics.ini - Added many of aircraft avionics overhaul NOTE: In Optical folder, you will see VIEW - CAMERA SYSTEM, it includes more dynamic head movement in flight. It is still in beta stage, there is plan to improve it further. By the way, the Mirage series is the most complicated projects I have ever done up to date. This is where I dive deep into the rabbit hole and realized that various Mirage have different radars and avionics configurations. Good example is Egyptian Mirage 5SDE and Libyan Mirage 5DE, both have same airframe with different radar and optical sight / HUD. I am so relieved to be able to bring this new version out. The feedback is always appreciated, because they are helpful for me to improve the projects. For now, I want to put this project on temporary hold for now, I want to focus on digging through the SF2 dll files, so I can build the huge INI modding information library for all of us to use. You can see the projects in this link: https://combatace.com/forums/topic/100023-sf2-advanced-moddings-dll-files-editing/?page=2&tab=comments#comment-822140 When I decide to take a break from this project, will come back to work on this one, then back and fort between both SF - CAP and SF2 advanced modding projects. Thank you for enjoying the mods! Cheers

Hello everyone! After finishing workingon UAE and Zaire Mirage 5s / 50s series, I just realized that there are even more unique Mirage series that is locally modified based on Mirage airframe. For example, South African Cheetah C / D / E, as well the IAI Finger and IAI Dagger. Started working on South African and Ecuador Cheetah series. Here are screenshot of Cheetah E: NOTE: Cheetah C and D uses IAI Kfir C.2 cockpit and RWR while Cheetah E have modified F-15 cockpit and IAI Kfir C.7 HUD as placeholder that seem close to Cheetah E cockpit. Due to the limited information, this is based on mix of researches and an educated guess that makes sense. I am working on Argentina IAI Finger and Dagger, then I think I will finally complete the ultimate Mirage IIIs / 5s /50s series, including Nesher and Kfir. I aim to work on every mirage based aircraft, used by all nations, because of the love for the aircraft. Any aircraft that exists from any nations, deserves to be flyable in SF2! Cheers!

Hello everyone! Yesterday and today was a very productive day with Peru and Venezuela Mirage 5s and 50s. I have manged to finish working on the Peruvian Mirage 5P and 5P4, as well Venezuelan Mirage 5DV / 5V / 50DV / 50EV. The Mirage 50EV was lot of work, especially new textures for air to ground mode for Cyrano IV3M. Here is screenshot of Mirage 50EV cockpit with air to ground mode (the air to air mode can be seen from Egyptian Mirage 5SDE and Cyrano IV (Early) in previous posts, along with fixed weapon loads, so it allows Mirage 50EV to carry laser pod for LGB too. Eagle114th

Hello everyone! I have been working lot on the Pakistan Mirage IIIs and Mirage 5s. I just realized that I forgot to work on Pakistan Mirage IIIEP, Mirage IIIO (ROSE and ROSE I), and Mirage IIIRP. they are now completed. Since I could not find details on the HUD as well the Grifo-3M, I did my best with both. It is the radar used by Mirage IIIO ROSE and ROSE I upgrades. Here are screenshot of Mirage IIIO ROSE: Mirage IIIO ROSE I: Radar view for both ROSE and ROSE I (Grifo-3M Radar): HUD View: Next, finally got to finish working on Mirage 5AP, 5AP2, 5AP3, as well Mirage 5EF. What I found out is that Mirage 5AP is basically Mirage 5 with range finder, while 5AP2 uses Cyrano IV radar, and 5Ap3 uses Agave radar. They all have each of these radar implemented. And for Mirage 5EF, this is new to me. What I found out is that Mirage 5EF is Mirage 5F being upgraded through ROSE II (or III?) with the capability of using FLIR for air to ground attack. In Mirage 5EF, I am using the same cockpit as used in A-4M Skyhawk with TV capable, as well having RWR, ECM, and chaff/flare included. Did some basic .ini editing so Mirage 5EF can carry laser pod and LGB. Please note, this is simple editing, so consider it as 'quick fix' until someone can take over and do more detailed overhaul. Here is screenshot of Mirage 5EF cockpits: Cheers!

Hello everyone! The work on Gabon Mirage 5G (PAULOPANZ) and Mirage 5G-2 (DENISSOLIVEIRA) are now completed with corrected starting / end years, fixed the "Stock fixed fuel tanks", and implemented the CSF Type 97K optical sight. By removing the stock fuel tanks, the add-on Mirage 5G and 5G-2 now can have properly working fuel tanks: Working on next nations' Mirage 5s / 50s. Cheers!

Hello everyone! I am currently working on Gabon, Pakistan, Peru, UAE, Venezuela, and Zaire Mirage 5 / 50 series. The LIBYA Mirage 5s are now completed after finishng working on Egyptian Mirage 5 series. Here are screenshot of the Mirage 5Ds, 5DDs, 5DEs, and 5DRs (both thirdwire, Wrench / TMF, and Paulopanz packs) Mirage 5Ds / 5DDs cockpit Mirage 5DEs (TMF) cockpit Mirage 5DR (Uses TMF's Mirage 5DE, and the RWR part is removed) Right now I am focused on finishing this as soon as possible, so I can finally release this next version of SF2 - CAP, then I can go back working on digging through SF2 DLL files for INI information library (Modder Resource Library). Cheers!

Hello everyone! I have extracted all of the Radar(NAME)Class which is used as SymbolType for the Avionics70.DLL based radar. Here is the list of Radar(NAME)Class and UPPER_SNAKE names for SymbolType. SF2_Symbol_Assoicated_Key_list.txt Finally, here is RadarData (with DisplayData* and SymbolType included) containing the sections, keys, and associated keys. I hope it have correct data. If any of codes does not work, please let me know and I'll take look at it. AVIONICS 70 - RADARDATA.txt Cheers!

Thank you for the file, the SymbolType=<NAME>, the NAME part is huge help! And with the list you sent me, I can look into what isn't working too. I am almost done with Avioincs70.DLL's RadarData section as well the SymbolType keys with detailed information, Will post here soon. Cheers!

That is noted, I will still peek through Avionics70 and other Avionics DLL. Maybe it will surprise us if there are some difference wihtin the same name of the functions. By the way, you gave me an idea that saves me a lot of time. Instead of building new notes, I will use an existing Avionics60 text files like HUD.txt and other txt files, then rename it as AVIONICS70 version. I will use it as I go through Avionics70.DLL dump file. That way, if there is any difference, even by a little, it wil be updated in that txt file. Cheers!