pvince Posted August 30 Posted August 30 4 hours ago, Eagle114th said: If we could make the table and put all HUD_Functions names on left section, then add to clumn: COCKPIT | HUD | RADAR I take that 1 Quote
Eagle114th Posted August 30 Author Posted August 30 (edited) 1 hour ago, pvince said: As far as I can say, HUD and RWR entries are the same for Avionics60 and Avionics70. Avionics70 is different for Radar functions only. Maybe less work for the radar difference only. Avionics14A: some differences in radar functions + VDI introduction 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! Edited August 30 by Eagle114th Quote
pvince Posted August 30 Posted August 30 It's not exactly the table you described but it is a first step. All the Avionics and Cockpit functions I know, by alphabetical order. I cannot claim it is exhaustive. Those in red were captured in dll or mods but either they do not work or I have not been able to make them work. Cockpit and Avionics Functions.xlsx 1 Quote
Eagle114th Posted August 31 Author Posted August 31 10 hours ago, pvince said: It's not exactly the table you described but it is a first step. All the Avionics and Cockpit functions I know, by alphabetical order. I cannot claim it is exhaustive. Those in red were captured in dll or mods but either they do not work or I have not been able to make them work. Cockpit and Avionics Functions.xlsx 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! Quote
Eagle114th Posted August 31 Author Posted August 31 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! 2 Quote
pvince Posted August 31 Posted August 31 I tried a few new functions found. For some, so far nok (tried in Avionics70 only): I tried SymbolType=MISSILE_TOF and then tried SymbolType=MISSILE_TOF_TEXT in case of ... but none displayed something I also tried the font overrides: // --- Per-symbol font overrides (optional) --- TextFontName=Arial TextSize=14 TextBold=TRUE TextItalic=FALSE TextUnderline=FALSE TextStrikeOut=FALSE TextShadow=FALSE ShadowColor=0.0,0.0,0.0,1.0 ShadowOffset=1 TextOutline=FALSE OutlineColor=0.0,0.0,0.0,1.0 OutlineSize=1 in a TEXT entry, and also added them in [RadarFont] but also no effect. On the opposite, for "SymbolType=MASTER_ARM_TEXT", I knew the simplified one, but I could test successfully the options "OnText" OffText" and "HideWithGuns=TRUE" that were unknown so far. For those that did not work I can assume they are there as provision, or leftover from the library, but not coded yet, or code removed because unused for optimization. 1 1 Quote
Eagle114th Posted September 17 Author Posted September 17 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 1 2 Quote
Eagle114th Posted September 20 Author Posted September 20 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. Quote SF2 Avionics60 vs Avionics70 vs F-14A vs F-14A IIAF DLL – Practical Diff Guide Purpose: Show only the meaningful differences so modders can set safe overrides fast. # Class Implementation Map Legend: - FULL = fully implemented - LIGHT = Lightly Implemented - PLACEHOLDER = No logic | not working = stub/no effect Note: Some Placeholder still calls other class for images, texts, or other type of class, but still have no local logic. ## 2.1 Radar-related | Class | Avionics60 | Avionics70 | F-14A | F-14A IIAF | | --------------------------------- | ------------- | ------------- | ------------- | ------------- | | RadarASECircleClass | N/A | FULL | FULL | FULL | | RadarAcqSymbolClass | N/A | LIGHT | LIGHT | LIGHT | | RadarAimDotClass | N/A | LIGHT | LIGHT | LIGHT | | RadarAzimuthClass | N/A | LIGHT | LIGHT | LIGHT | | RadarBreakXClass | N/A | LIGHT | LIGHT | LIGHT | | RadarCarrierSymbolClass | N/A | PLACEHOLDER | FULL | FULL | | RadarECMTextClass | N/A | LIGHT | LIGHT | LIGHT | | RadarElementClass | N/A | LIGHT | LIGHT | LIGHT | | RadarElevationClass | N/A | LIGHT | LIGHT | LIGHT | | RadarElevationTextClass | N/A | LIGHT | LIGHT | LIGHT | | RadarGroundSpeedClass | N/A | PLACEHOLDER | FULL | FULL | | RadarHorizonClass | N/A | LIGHT | LIGHT | LIGHT | | RadarImageClass | N/A | FULL | FULL | FULL | | RadarLockedTargetSymbolClass | N/A | LIGHT | LIGHT | LIGHT | | RadarMaxAltClass | N/A | FULL | FULL | FULL | | RadarMinAltClass | N/A | FULL | FULL | FULL | | RadarMissileRMaxClass | N/A | LIGHT | LIGHT | LIGHT | | RadarMissileRMaxTextClass | N/A | LIGHT | LIGHT | LIGHT | | RadarMissileRMinClass | N/A | LIGHT | LIGHT | LIGHT | | RadarMissileShootCueClass | N/A | FULL | FULL | FULL | | RadarMissileTOFClass | N/A | PLACEHOLDER | PLACEHOLDER | PLACEHOLDER | | RadarRangeScaleClass | N/A | LIGHT | LIGHT | LIGHT | | RadarSweepLineClass | N/A | FULL | FULL | FULL | | RadarTASClass | N/A | PLACEHOLDER | FULL | FULL | | RadarTargetAltitudeTextClass | N/A | LIGHT | LIGHT | LIGHT | | RadarTargetAspectTextClass | N/A | FULL | FULL | FULL | | RadarTargetBearingTextClass | N/A | FULL | FULL | FULL | | RadarTargetClosureTextClass | N/A | LIGHT | LIGHT | LIGHT | | RadarTargetHeadingTextClass | N/A | LIGHT | LIGHT | LIGHT | | RadarTargetRangeClass | N/A | LIGHT | LIGHT | LIGHT | | RadarTargetRangeTextClass | N/A | LIGHT | LIGHT | LIGHT | | RadarTargetSymbolClass | N/A | FULL | FULL | FULL | | RadarTargetTASTextClass | N/A | LIGHT | LIGHT | LIGHT | | RadarTargetTextClass | N/A | FULL | FULL | FULL | | RadarTextClass | N/A | LIGHT | LIGHT | LIGHT | | RadarWaypointBearingClass | N/A | PLACEHOLDER | PLACEHOLDER | PLACEHOLDER | | RadarWaypointHeadingClass | N/A | PLACEHOLDER | FULL | FULL | | RadarWaypointRangeClass | N/A | PLACEHOLDER | FULL | FULL | ## HUD-related | Class | Avionics60 | Avionics70 | F-14A | F-14A IIAF | | --------------------------------- | ------------- | ------------- | ------------- | ------------- | | avnHUDASE_HeatClass | FULL | FULL | FULL | FULL | | avnHUDASE_RadarClass | FULL | FULL | FULL | FULL | | avnHUDAirspeedScaleClass | FULL | FULL | FULL | FULL | | avnHUDAirspeedTextClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDAlphaTextClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDAltitudeScaleClass | FULL | FULL | FULL | FULL | | avnHUDAltitudeTextClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDAttitudeBarsClass | FULL | FULL | FULL | FULL | | avnHUDBoresightClass | PLACEHOLDER | PLACEHOLDER | PLACEHOLDER | PLACEHOLDER | | avnHUDBreakXClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDCCIPClass | FULL | FULL | FULL | FULL | | avnHUDClosureRateScaleClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDDeviationClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDElementClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDFlightPathTextClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDFlightpathClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDGIndicatorClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDGlideslopeClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDHeadingScaleClass | FULL | FULL | FULL | FULL | | avnHUDImageClass | FULL | FULL | FULL | FULL | | avnHUDLCOSClass | FULL | FULL | FULL | FULL | | avnHUDLowAltIndicatorClass | PLACEHOLDER | PLACEHOLDER | PLACEHOLDER | PLACEHOLDER | | avnHUDMachIndicatorClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDMasterArmClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDMasterArmTextClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDMaxGIndicatorClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDModeIndicatorClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDRadarAimDotClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDRadarAltIndicatorClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDRadarRangeClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDRadarRangeScaleClass | FULL | FULL | FULL | FULL | | avnHUDRadarRangeScaleTextClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDRadarTargetAltClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDRadarTargetAspectClass | FULL | FULL | FULL | FULL | | avnHUDRadarTargetBearingClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDRadarTargetHeadingClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDRadarTargetTASClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDRadarTargetVcClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDRollIndicatorClass | FULL | FULL | FULL | FULL | | avnHUDScaleClass | FULL | FULL | FULL | FULL | | avnHUDSelectedWeaponTextClass | FULL | FULL | FULL | FULL | | avnHUDSteeringCueClass | FULL | FULL | FULL | FULL | | avnHUDTD_EOClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDTD_HeatClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDTD_LaserClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDTD_RadarClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDTargetTextClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDTextClass | FULL | FULL | FULL | FULL | | avnHUDVerticalVelocityScaleClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDWaypointIDClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDWaypointRangeClass | LIGHT | LIGHT | LIGHT | LIGHT | | avnHUDWeaponCountClass | LIGHT | LIGHT | LIGHT | LIGHT | 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! 3 Quote
pvince Posted September 20 Posted September 20 Very interesting With « placeholder » we have the confirmation of those that do not work. But what is the difference between full and light ? Both work. 1 Quote
Eagle114th Posted September 21 Author Posted September 21 5 hours ago, pvince said: Very interesting With « placeholder » we have the confirmation of those that do not work. But what is the difference between full and light ? Both work. 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 2 1 Quote
pvince Posted September 21 Posted September 21 OK. "LIGHT" and "FULL", is it your assessment, or the IA assessment, or is it in the source ? 1 Quote
Eagle114th Posted October 2 Author Posted October 2 (edited) 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! Edited October 2 by Eagle114th 3 Quote
Eagle114th Posted October 2 Author Posted October 2 On 9/22/2025 at 12:55 AM, pvince said: OK. "LIGHT" and "FULL", is it your assessment, or the IA assessment, or is it in the source ? 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. 1 Quote
Eagle114th Posted October 6 Author Posted October 6 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! 5 Quote
mue Posted Tuesday at 02:10 PM Posted Tuesday at 02:10 PM If you could find more information how exactly stall is modelled in SF2, I would be *very* grateful! How the normal flight envelope is modelled I understand quite well: sf2_fdm_notes.pdf. But the stall regime is still rather unknown to me. BTW, the key 'Qr — Downwash/relief factor used in aero build (vs α)' is also unknown to me. And I couldn't find it in any stock aircraft data inis. What exactly is this downwash/relief factor? 1 Quote
Eagle114th Posted Wednesday at 12:02 PM Author Posted Wednesday at 12:02 PM 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. 21 hours ago, mue said: If you could find more information how exactly stall is modelled in SF2, I would be *very* grateful! How the normal flight envelope is modelled I understand quite well: sf2_fdm_notes.pdf. But the stall regime is still rather unknown to me. BTW, the key 'Qr — Downwash/relief factor used in aero build (vs α)' is also unknown to me. And I couldn't find it in any stock aircraft data inis. What exactly is this downwash/relief factor? 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 6 Quote
pvince Posted Thursday at 05:15 PM Posted Thursday at 05:15 PM (edited) I am not 100% sure but for me the StallXXTableData are not nominal values but relative coefficients to apply to the nominal value. For example for the Stall Lift Table, the coefficient will be 1, multiplied by CLmax=1.45, which gives 1.45 in your example. I say that based on how tables are used in SF2 and actual values in data.ini. To be checked. Edited Thursday at 05:22 PM by pvince Quote
Eagle114th Posted Friday at 01:55 AM Author Posted Friday at 01:55 AM (edited) 9 hours ago, pvince said: I am not 100% sure but for me the StallXXTableData are not nominal values but relative coefficients to apply to the nominal value. For example for the Stall Lift Table, the coefficient will be 1, multiplied by CLmax=1.45, which gives 1.45 in your example. I say that based on how tables are used in SF2 and actual values in data.ini. To be checked. 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 Edited Friday at 02:34 AM by Eagle114th 1 1 Quote
mue Posted Friday at 07:04 AM Posted Friday at 07:04 AM 5 hours ago, Eagle114th said: Once you’re past `AlphaStall`, the game blends to these stall table multipliers. Do you know, how the blending works? Quote
Eagle114th Posted Friday at 09:36 AM Author Posted Friday at 09:36 AM 2 hours ago, mue said: Do you know, how the blending works? 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 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.