Eagle114th

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!