OlWilly

So, with the valuable input from Mue, the updated instructions on rudder related fixes in data.ini (preserve the original file though). Each problem now has two solutions for your choosing Rudder roll Pick up the aircraft of your choosing. Give right rudder. Aircraft should gently roll to the right. If this doesn't happen: Easy way Find rudder in control surfaces section (two of them for twin tail aircraft). Find Cldc coefficient and put it to negative (add minus sign before the value) Example: before Cldc=0.0008, after Cldc=-0.0008 More correct way Find Clb coefficient in wing sections (left wing, right wing, left outer wing, etc). It should be in negative. Increase the absolute value in each of them until aircraft behaves correctly. The increase should be the same for left/right sections, I.E. if you increase the left for 0.05, the right should get the same increase. If this doesn't help or causes weird behavior, decrease Cldc in rudder. Example: before Clb=-0.0182, after Clb=-0.0232 for both [RightWing] and [LeftWing] Slip Pick up the aircraft of your choosing. Give right rudder and left stick to keep the wings level. Aircraft should slowly change the heading clockwise. If this doesn't happen: Easy way Find rudder in control surfaces section (two of them for twin tail aircraft). Find Cydc coefficient and put it to negative (add minus sign before the value) Example: before Cydc=0.1130, after Cydc=-0.1130 More correct way Find Cyb coefficient in fuselage and tail related sections. It should be in negative. Increase the absolute value in each of them until aircraft behaves correctly. If this doesn't help or causes weird behavior, decrease Cydc in rudder. Example: before Cyb=-0.5053, after Cyb=-0.5553 for [VertTail] Excessive swaying on yaw axis Pick up the aircraft of your choosing. Start giving full right and left rudder in quick succession. If aircraft wiggles like mad: Easy way Find EmptyInertia= line. Set the third value to 1-2 times the EmptyMass of the aircraft. Example: before EmptyInertia=68970.9,20295.1,65332.2, after EmptyInertia=68970.9,20295.1,8000.0 More correct way Find EmptyInertia= line. Gradually decrease the third value until the behavior becomes acceptable After all changes Test the aircraft before and after changes. Set up a simple 1vs1 cannon only dogfight mission, then a simple but cannon only interception mission vs level bombers (Il-28, Canberra, etc), and, finally, do some aerobatics (knife edge, hammerhead, barrel roll with rudder, etc)

Ahh, I get you. Well, firstly, as we don't have access to source code, I can't really say what the game does when we switch it to easy. And secondly, I consider the main problem to be mostly solved. Now we have even two methods of dealing with it and with applied changes the rudder does behave like it should. Coefficients could be tweaked around, but this is another story for another day. Now they do Gunfighting is easier and you can do some tricks with it Now "Knife Edge" is possible Hammerhead too

Yes! But you see, the function of horizontal stab directly depends on the relation between CoL and CoG. If CoL is right below the CoG, stab should be a symmetric airfoil and not produce any lift for level flight. If CoL is in front of CoG, stab should produce the downforce aka negative lift. And if CoL is behind the CoG, stab should produce lift. But what I say is that Strike Fighters game engine does not take this into account. You can move CGPosition= wherever you want without changing a single parameter in horizontal stab, and aircraft will fly just fine. F-100 is and old aircraft, CoG is definitely in front of CoL and this means that horizontal stab is rigged for downforce. You move CGPosition two meters behind (I just did). What should happen? It should pitch up uncontrollably immediately as it gets fast enough. But this doesn't happen. It flies absolutely fine. Now let's look at F-16. We know that it has CoG behind the CoL, so horizontal stab produces lift. But I don't see any fundamental differences between stab parameters of F-100 and F-16. In fact, I just copied stab data from F-16 to F-100. It should pitch down instantly, but it doesn't. The game simply doesn't care. It doesn't calculate these forces deep enough. Yes, it works. In fact, we can just purge Cydc and Cldc from the rudder and work with wings, fuselage and tail instead. But effect is the same. I think the game treats these values as the same (Clb = Cldc and Cyb = Cydc). We can either increase Clb and Cyb values or simply put Cldc and Cydc into negative as "force multipliers". The latter is simply easier

Could be, but I really don't see the point in flying on Easy or Normal Flight settings. Even Hard is very forgivable compared to other sims or real life I wouldn't say so. The game was originally geared to jet gunfighter era, so you have stock planes that did (or were meant to do) a lot of gunfighting, like various MiGs, Super Sabres, Crusaders, French fighters, even Phantoms... But gunfighting without proper rudder is a torture. You need rudder to gently slip your aircraft left or right without banking to keep the sights where you need them to be. I can't say that I am particularly good virtual fighter pilot, but I know how to shoot. But in Strike Fighters, this turned out to be a real embarrassment for me. Even if target flying straight and I have all the time in the world to line up a shot - I still miss. The worst part was when I tailed enemy fighter for 20 (!) minutes, solid on his tail and still couldn't land a good shot. Yes, SF AI likes to jink very actively, but it does it in very predictable manner: up - down, left - right, force overshoot... I know that the problem isn't me because I never had such problems in Il-2 or Lock On or DCS... After fixing the rudder, gunnery became way more pleasant as aircraft does what I expect it to do and now I can enjoy some good jet dogfights

I concur. We apply right rudder. Vertical stab starts producing lift which pushes the tail to the left. But as aircraft "pivots" around its CoG the nose is getting pushed to the right! This is the yaw - Cndc. The CoG is the "pivot point" of any such movement. Notice that when you use elevators, the entire aircraft doesn't go up or down - it affects only the pitch, so you have tail going down but nose going up. This is very similar, only on different axis. The rolling moment is generated by different airflow over both wings. With right yaw, the right wing generates less lift, left wing generates more lift and you get the right hand roll - Cldc. And lastly, the yaw causes relative wind to hit the side of the aircraft, which turns it right and generates a substantial amount of drag - Cydc . This is why sideslip is often used to lose the energy quickly. Images attached. ------------------------ But if you still don't agree. Fire up any other flight simulator. DCS, Lock On, any of Il-2s, MSFS, X-plane, Flightgear, Falcon... Or hop in a real aircraft if you are lucky. Give hard right rudder. What do you see? The plane is yawing and rolling to the right. Apply left stick to keep the wings level. What do you see again? The plane is slowly turning to the right and bleeds energy quickly. Now do the same in any stock planes in Strike Fighters. They may rudder roll correctly (depends on the plane), but they won't slip turn at all. Then apply the changes I described - Cydc, Cldc and Cndc in rudder all negative. And you will see that the plane starts behaving correctly. Rudder turning can be used to turn the aircraft without banking - but it is inferior to banking turn because turnrate is much lower and drag increase is profound (also major risk of getting into a spin) But it is mandatory during air combat when you need to keep sights on the target without banking. I don't really have to touch other coefficients because the changes I described already do the job. The one issue I discovered though - the sideslip doesn't cause any additional drag at all. Even at hard sideslip the plane doesn't lose energy at all, you can even go supersonic. Do you think this could be fixed? I thought about increasing drag of the rudder as a crutch but this simply feels wrong.

For the clarity, let's establish what is a rudder and how it works. Vertical stabilizer is essentially a symmetric airfoil - it doesn't produce lift at zero AoA, aka aircraft flying straight. But as we deflect the rudder, the lift is starting to get produced. Imagine that vertical stab is a vertical wing, and rudder is a flap - this is easier to understand. Now, let's say we give right rudder. Vertical stab starts creating lift which pushes the tail to the left. Aircraft "pivots" around its center of gravity, so nose gets pushed to the right. Voila, we achieved a yaw, now longitudinal axis of our aircraft is misaligned to the vector of speed. This is called the yaw angle. This creates two effects. As we now flying "sideways", the airflow over right and left wings is different, and they create different amounts of lift. In our case, right wing creates less lift, left wing more, and aircraft rolls to the right. This is rudder roll. Then, the relative wind hits the side of our aircraft, in our case the left side. This pushes the aircraft to the right, making it slowly turn right. This is rudder turn. All of these effects happen on the same side - I.E., as we give right rudder, we get right yaw, right roll and right turn. For aircraft with unorthodox control surfaces like spoilers on B-2 or fully moving vertical stabs on YF-23 the effects are the same. After checking more rudder settings on modded and stock planes I found that most of them are messed up. I am not talking the tune-up of coefficients themselves, they simply have the wrong signs. With the default settings, rudder yaws aircraft correctly, but tries to roll and turn it in the opposite side. This is weird and wrong. After looking on the forum, I found this thread from 2009 with the guy complaining about the same thing: https://combatace.com/forums/topic/60218-question-about-flight-model-sideway-g-force/ So the issue is really old, and I can't think of how to explain it. I can't believe that this is an oversight, in so many planes and over multiple games and expansions packs and patches... Likewise, I don't think that the devs didn't understand how this works. The coefficients are in place after all. So the only answer is that this was done deliberately for some reason

I fly around with no external indication at all, so to find my way around I have to use NAV equipment; in case of older planes this is navigational marker on radiocompass. Oftentimes, instead of correct bearing it chooses to show me the butt for some reason. This is the case, for example, for F-106 pit and others based on it After looking into the matter the culprit is found. Originally, it looks like this: [CourseArrow] Type=COURSE_ARROW NodeName=HSIcenter MovementType=ROTATION_Z ValueUnit=DEG Set[01].Position=00.0 Set[01].Value=0.0 Set[02].Position=360.0 Set[02].Value=360.0 [CourseCounter] Type=COURSE_ARROW CounterNodeFormat=course_dig%d MovementType=ANALOG_COUNTER ValueUnit=DEG While it should be: [CourseArrow] Type=BEARING_MARKER NodeName=HSIcenter MovementType=ROTATION_Z ValueUnit=DEG Set[01].Position=00.0 Set[01].Value=0.0 Set[02].Position=360.0 Set[02].Value=360.0 [CourseCounter] Type=BEARING_MARKER CounterNodeFormat=course_dig%d MovementType=ANALOG_COUNTER ValueUnit=DEG After looking into the pits made by Stary, the following is found too: [CourseArrow] Type=BEARING_MARKER //Type=COURSE_ARROW NodeName=course_arrow MovementType=ROTATION_Y ValueUnit=DEG Set[01].Position=00.0 Set[01].Value=0.0 Set[02].Position=360.0 Set[02].Value=360.0 [BearingMarker] Type=MAGNETIC_COMPASS //Type=BEARING_MARKER NodeName=bearing_marker MovementType=ROTATION_Y ValueUnit=DEG Set[01].Position=00.0 Set[01].Value=0.0 Set[02].Position=360.0 Set[02].Value=360.0 So apparently, CourseArrow became BEARING_MARKER while BearingMarker is now just MAGNETIC_COMPASS. Not sure when it happened, between SF1 and SF2 (never played SF1 for that matter), or later during updates... In case if you encounter the same problem and want it gone, find the node which is ought to show you the correct course and define it as BEARING_MARKER. Works for analog counters as well

Sadly, the implementation of ARMs in Strike Fighters is just bad. The only thing you can do with them is to loft them in LOAL mode, that's all. Thus, the only viable tactic is... To know the effective range of your missile at the given altitude and airspeed. Let's say we have Shrike and go low, this should be around 10-15NM. Then, you had to get the azimuth and range on the radar you want to attack, from RWR for example or from pre-flight. When the range is met - when you are closer than 15NM from the target, lob your missiles towards it and hope that they will lock, immediately turn away. Other modes of use are simply not modeled. For example, Shrike could lock before the launch, it was similar to Sparrow in floodlight mode, Shrike's seeker could lock emitters in the narrow cone in front - giving the pilot a tone when lock was obtained. Ho HUD, no dedicated display was needed - just turn on the target emitter and wait for a tone. Later ARMs displayed spotted emitters to the pilot either on display or on a HUD, letting the pilot to select them for attack. ARMs with more range were often paired with detecting equipment, which likewise spotted the emitters and displayed them to pilot. Missile will go most of the way on INS and switch to seeker when close to the target

Strike Fighters game engine does really have a problem with drawing distant objects, which is the most noticeable with stock assets. I assume the game was developed with having "markers on" in mind, so this wasn't considered as a some kind of problem. The solution is to have at least target markers on, otherwise, suffer from planes going invisible In my set-up, I have all indication disabled except for red box on selected target

Yes, it is a picture from Polish training dogfight, made by MiG-21bis One of a dozen photographs taken during a simulated dogfight during the visit of four Dutch F-16s (323 Squadron) to Zegrze Pomerania in 1999. The hit was made by the pilot, captain. Andrzej Kilar. The photograph was analyzed and processed by a senior staff member Wieslaw Sieradski - head of OKL. The photographs captured the beautiful sequences of the aiming, the hit itself, and the takeoff. The pilots were present together during the analysis of the materials. The photo above was given to the Dutch pilot as a reminder of the event

I fully agree with Eagle's sentiment. SF2 has a great potential, there are so many mods for it, so many stuff... Yet, the quality of simulation is simply depressing. Yes, semi-casual sims are a thing but simulation of many aspects in SF2 is way too simplified. There is, of course, neither the need neither the capabilities to make SF2 into a hardcore sim like DCS or BMS. What should be the level of simulation to strive for, in my opinion, is Lock On Flaming Cliffs 2. Lock On is a casual sim too, and it is as old as SF. Likewise, you start the plane with one - two buttons max, but the simulation of the main systems is simply better. Just download Lock On 2 and play around with it if you haven't already, it is quite easy to get into yet is more pleasant if you care about how the stuff actually works.

More stuff for MiG-21 This scale right below the gunsight is actually a radar range indicator. Lowest part shows the distance to the ground in ground attack mode (not applicable in SF2), the one above it shows distance to aerial target in air-to-air mode. Very useful thing, allows you to know the range for sure and pick the best time for a launch To enable, replace original AgujaBB entry by this: [AgujaBB] Type=RADAR_TARGET_RANGE NodeName=AgujaBB MovementType=ROTATION_Z ValueUnit=METERS Scale=1 Set[01].Position=-20.0 Set[01].Value=1000.0 Set[02].Position=20.0 Set[02].Value=9000.0 Sadly, this scale is properly animated only in these MiG-21 pits. In his works, Stary just put it as a solid texture with arrow being painted on it 3km:

I noticed that MiG-21MF pit has working Bereza RWR. It bleeps and lights do show the angle of incoming radiation MiG-23 pit has Bereza too, and it looks like a same 3D model, but currently lights don't work. It bleeps, but no lights Another thing, 21 pit has "droptanks empty" indicator light. Very useful. 23 pit doesn't Thus, how exactly I can edit 23 pit to add this? I understand that I had to modify 3d model of the pit, add hooks and respective light textures, then add them in cockpit.ini having 21 pit as an example. What software is best to use here?

View File Su-35S cockpit by Insky, light update A light overhaul of old Su-35S cockpit by Insky. Sadly, it is of lower fidelity than Su-27SKM cockpit from YeYeYe which is often used for modern Su-27 derivatives, but it follows the general layout of Su-35S cockpit and is worth a try. Updated textures, sorted out various indication and HUD, some other small fixes. It is tailored for Su-35S by GKAB, but could be adapted for any other aircraft. Caution: there is no "launch authorized" indication on the HUD, not possible to add it with resources I have - it will be displayed on the radar. Real Su-35 pipes both radar and RWR information straight to the HUD, which is not possible to recreate in SF2 engine - so we have what we have. To install, delete original files in Su-35 folder and put new ones inside Submitter OlWilly Submitted 09/06/2023 Category Jet Cockpits  

Size for MiG-21MF is different: SearchPosition=0.6 TrackPosition=0.6 LockPosition=0.6 SearchSize=0.9 TrackSize=0.9 LockSize=0.9 Although I removed additional lights, leaving only four (as it should be). Comes with adapted texture Instrumentos05.tga Same set-up for Su-15 pit, and changed texture instruments.TGA

Only if it happens, eye candy will be improved, but functionality will get closer to ace combat series Not sure if anyone wants it

Missile approach warning is a standard since original Su-27

Well, took me a while to figure it out properly The set-up has two nodes. Outer node is basically for decoration (or, so to say, to imitate the actual SPO-10), in Stary's cockpits it's usually called "RWR_front". This node calls TGA texture, and it is in TGA format to allow transparency. The holes are placed where the lights should be. Better seen on a screenshot in the post from May. The actual RWR node is the hidden node inside (here, called simply "RWR"). It calls BMP or JPG texture, and it should look the same as the outer texture. All of this is already done in the cockpit model, no changes to textures are necessary so I just explain how it works. Thus, in cockpit ini: [RWR] Type=RWR NodeName=RWR In avionics ini: [RWR] Type=3_RING AirSearchTexture=cockpit\rwrGreen.tga AirTrackTexture=cockpit\rwrYellow.tga AirLockTexture=cockpit\rwrRed.tga GroundSearchTexture=cockpit\rwrGreen.tga GroundTrackTexture=cockpit\rwrYellow.tga GroundLockTexture=cockpit\rwrRed.tga SearchPosition=0.60 TrackPosition=0.60 LockPosition=0.60 SearchSize=0.7 TrackSize=0.7 LockSize=0.7 SearchFlash=FALSE TrackFlash=TRUE TrackFlashRate=0.5 LockFlash=TRUE LockFlashRate=0.1 ShowSearchRadar=FALSE TrackSound=MiGRWRS.wav LockSound=MiGRWRL.wav This way, the RWR node works just as a regular 3_ring RWR, showing the general direction of the radiation. The goal is to find proper position so the light will align with aforementioned holes and will be seen outside. Position=0.60 works fine Then, the size should be adjusted so the lights are big enough to be seen from outside - if you make them too small you won't see anything most of the time. Size=0.7 works fine I did increase the number of transparent holes on TGA texture from 4 to 8 for testing, but it is not necessary - the actual SPO-10 had only four (this is where Stary pit is correct and MiG-21 version is not.), so I returned them back. As a bit of trivia, the actual SPO-10 worked in a way that: - the lights show you the direction of radiation, white color only - the frequency of beeping tells you how close the threat is (faster beeping - closer threat) - continuous beeping means you are locked - not sure for what purpose the red lights are, either range or launch warning Most of this is not possible inside the game's engine, so we multicolored RWR would be good enough. TLDR - just check the correct paths and names for all textures, Position=0.60 and Size=0.7

AFAIK, "detection" section of each DATA.ini file has something about visual radius and deadzones. It's in the beginning of the file

I finally made it work

I occasionally ran out of fuel and either glide back to the nearest airfield or land right on some field. Game doesn't simulate bumpy ground regardless, so should be a loss or crash-land. Crash landings are not simulated too, right? You just explode Never seen AI running out of fuel though

Why not? GNSS really changed a lot. Back then accuracy sucked because of imprecise INS navigation and limited radar ground lock capabilities on such missiles (missiles like Kh-22 are notorious for having a massive CEP) With GNSS, 25m CEP at any ranges is just easy

Shaheds could definitely hit their targets. Reni port: …faceofwar/32682 SBU headquarters: …faceofwar/31977 Ammo depot: …faceofwar/32548 And so on. And they are fairly hard to intercept while being dirt cheap. Although those are Russian Geran-2 drones which are derived from Shahed-136 but have some local changes. I think Saudis should start getting nervous right now. If Iran gives enough Shaheds to Yemenis, they could literally cripple Saudi oil production and ruin their economy. Imagine Abqaiq–Khurais strike but on country wide scale

New cruise missile from Iran -