OlWilly

When SF2 crashes, open the crash event report, expand it and look at the module which caused the crash. This may give some input on what caused the crash. Recently, I had persistent campaign crash in a certain mission, on further examination it was caused by ground_formation.dll or somesuch. So obviously, game didn't like something related to ground unit behavior. The solution is to start the mission and then exist it, failing but skipping it.

While playing around I noticed that missiles (BVRs mostly) behave quite unrealistically. I have a bad habit of flying low and slow, and this is the worst place kinematics wise for BVR combat, yet, I have little problem scoring hits. Granted, AI doesn't know how to defend with maneuver, but it is still wrong. Similarly, when I am on the receiving side, no defensive maneuver seems to help - missile will still get me. The only way is to abuse the game's engine and go below 50 meters when AI loses all means of attacking me - even with guns. Checking out the missile performance shines the light on the problem. First example, R-24R - I launch on pursuit course, while going at 0.7M at target above me and going with the same speed. Missile accelerates to 3.7M on upward swing and even gains velocity during the entire 30 or so km flight path. R-40, while checked in MRS, shows the range of 160km while launched at 2.8M from 15k meters. And the crazier ones, AIM-47 shows the range of above 1200km (!) at the speed of 14M (!) while launched from 15k meters at 3M. Both AIM-47 and R-33 have weird 240 second sustainer times. What this means is that missiles are barely energy limited, and the max effective launch is limited only by the statement in DATA file. Your kinematic performance barely matters. This turned out easy to correct. -------------- The missile performance is governed by few statements in the DATA file. Booster acceleration and booster time govern the max acceleration of missile. Acceleration is measured in Gs which are roughly 35km/h. The time says for how long the booster works. Thus, If we have acceleration at 5 and time at 10, we get 5x10x35 = 1750km/h of default acceleration - with no account of drag and launch platform velocity. Sustainer works by the same logic. Then we have subsonic and supersonic drag which determine mostly how quickly missile runs out of energy. Supersonic drag is the most relevant here of course. The obligatory tool to deal with missiles is MRS: Now, keep in mind that missile performance you find online is usually its best performance - meaning launch from good altitude at a good platform speed. For the sake of simplification, let's assume the altitude as 15k meters. You may tailor it more accurately by ceiling of known aircraft, but I keep it at 15k. The platform speed will be close to max M number of given aircraft or aggregate of various aircraft using a given missile. As an example, I show the process for R-40 missile as it is very dependent on launch platform kinematic state. First we have to set up the launch state. MSR has no altitude setting but it could be st by IAS/TAS ratio. For 15k meters it will be around 0.6. MiG-25 will launch it at 2.8M. The speed of sound at 15k is around 1060km/h. Thus, 2.8x1060=2968km/h. Then we convert it to m/s - the factor for this is 3.6. So, 2968/3.6=~824m/s. We input this into the init speed. Weight and diameter of missile could be picked from DATA file. Thus, 475kg and 0.31m. Now we had to deal with the booster and sustainer. R-40 has no sustainer, so both values at 0. For R-40 we are lucky and we know the default acceleration - around 2.2M and the max speed - around 4.5M. We pick the first value. 2.2Mx1060km/h=2332km/h. Then we divide the given speed at G value - 2332/35=~67. Let's say we give it a 4 second booster - so 67/4=16.75. This way, we have booster acceleration at 16.75 and booster time at 4. We press SIMULATE and get 300km range (statement Length) with max velocity 1455m/s (~4.9M). Speed is almost there, but the range is out of whack. We forgot about the drag. Now, we experimentally adjust the drag to bring missile range close to its real value. For R-40 this should be around 50-60km. Drag has two windows, first is subsonic, second is supersonic. Second is the most important here, keep the first below it. Input 0.6 for subsonic and 1.2 for supersonic. This gives us 56km range and drops velocity to 1353m/s (4.5M). This looks really good. Check out the energy loss curve too. Now we can check how missile will perform at subpar kinematic state of the platform. Set IAS/TAS to 0.95 and init speed to 350 (this is going at 1M at 2k meters). We get pitiful 11km range and 845m/s (2.4M) velocity. This is close to how the missile should perform at such launch parameters. I strongly recommend to extend the duration in DATA file too, make it so missile lives longer --- R-40 was easy as we know both default and max speed, as well as the parameters of launch platform (MiG-25 and MiG-31 behave similarly). What about missile when we know only the max speed? Sparrow for example, it has max speed of 4M. But if we use 4M for booster calculation, we get values far above 4M. Take the max missile speed at retract 70-80% of the optimal speed of launch platform from it. Assume we mind Phantom launching from 2M, so we set up 4M-1.5M=2.5M of default acceleration. Let's make the same tuning for AIM-7M Speed is almost here, but range is not enough. As we know, AIM-7M had sustainer, so we can use it here to extend the range. Sustainer acceleration at 4 and duration at 10. I also drop booster to 17 And once again, subpar kinematic state check: ---- What this does in-game is that your kinematic performance now matters. If you want extended engagement ranges, you had to go higher and faster. And missiles now actually lose energy. I am not sure if missiles in-game lose energy during maneuvering (hard to check since AI doesn't defend) but I hope so. ---- Now, this doesn't quite apply to lofted missiles like AIM-54 since they have very different flight profile, and this MSR has no loft settings. I guess you can set them up to have reduced range and velocity and then check in-game if they perform correct while being lofted. Likewise, I currently don't know how this tool could be used to tune SAMs since their flight profile is radically different.

Ahh, that's cool but I use Mirage Factory 23s... I guess I can loan the decals from this pack and adapt them But regardless, the book has markings for other aircraft too

The book on Soviet paintschemes and markings during Afghan War. Could be useful for skinmakers https://homeread.net/read/kamuflyazh-i-bortovye-emblemy-aviatehniki-sovetskih-vvs-v-viktor-markovskiy?page=2#tx MiG-23 markings for example

Yes Mue's extractor doesn't like scale being any other than 1, so make sure to ctrl-a any object you actually scale. Then it's no problem Secondly, Mue's LOD viewer could be used to show the ingame size of the model When you put the cursor on any part of the model, it shows coordinates - which should be in meters Just make sure that, let's say, the forward most and rear most points of the model sum up to a correct (or so) length

TW extractor should not be even touched when Mue's one exist Search function solves the issue Use * to denote misc entries F-4D*AVIONICS* will return relevant files for all the D versions F-4*AVIONICS* should show all Phantom's avionics files *AVIONICS* should show avionics files for all stock aircraft

I play with red target square only - as a compromise. In real life, your wingmen will help and duly report the targets they spot so other can engage them. No such thing in the game, they just yell about being shot at Real life terrain also has more details which will helps to communicate where the target is. Default SF terrains are fairly barren so even if you spot something, good luck remembering where it was after maneuvering The game engine also has some rendering issues, so objects may simply not render if you are not close enough. Even if you don't want red square, the padlocking should still work

For player, kinda possible. Create a ghost station where you want the flares to be. Creates a lod-less flare dispenser; pair dispenser and the ghost station through specific station code. On loadout screen, load pod into the regular station, then dispenser into the ghost station. Voila, you have both functions. Don't cheat though, don't load dispenser without pod, mkay?

It's simple, you don't. Why do you think US took such heavy casualties from AAA fire? Things like ZU-23 or ZPU-4 could be camouflaged so well that you wouldn't be able to spot them until they fire. And mind you, in real life Vietnam has lush vegetation, meaning that you are looking for a small AAA in the midst of endless bushes and tall grass. Not on a flat texture like in the game. The basic idea was that if one pilot sees something that he thinks is the gun flash of NVA AAA and then dumps there a load of munitions, hoping to hit something. Speaking of SAMs, your best friend here is RWR. The "star" pattern of S-75 deployment was abandoned fairly quickly in favor of more camouflaged approach. Just let them track you, RWR will tell you where to go. AI is not taught to switch off the radars so you can get as precise as you want. You can take the easy way though, find the mod that removes the HUD but leaves red square in place.

Ahh, I misread the schematic. The only way to say for sure would be to see it in the official technical description of the relevant 21 model. Book 3 preferably, this is where it should be Online, I have seen book 3 only for 21UM and it has no mention of these plates

This thing?

Post data file for missile in question

With engine limitations, two things are quite possible: - a playable SAM battery - a playable unarmed ground vehicle In the first case you will sit in one place, use radar to lock targets and shoot missiles at them. In the second case, you will be able to drive around and that's it Not much possibilities otherwise RE: oh, you could also make a SPAAA like Shilka or Avenger, but you will be only the driver with gunnery done by AI

Adapting these models using Blender is quite doable. I can upload this if administration doesn't mind, but better, I would like to ask for little help: - normal map shows in Blender, but is not shown in the game. Have no idea why - no lods for performance optimization - no damage textures - pylons and gunports are terrible (my job). If someone has better French pylons, this would be appreciated If someone can help with advice, this would be good. Or I could pass the entire package for someone to polish it. Flight model, weapons, animations - all alright This Mirage is best used with Mirage F1 cockpit. If the author of F1 cockpit doesn't mind, this Mirage could be uploaded with it

"1976, on the initiative of the head of the Air Force Research Institute, General Gaidaenko, supported by the Deputy Air Force Commander-in-Chief for Armament Mishuk, comparative tests and training combat were carried out between former South Vietnamese F-5E [of earlier series] vs MiG-21bis and MiG-23M fighters. Test pilots N. Stogov, A. Bezhevets, V. Kondaurov participated in the tests. These tests consisted of two parts: an assessment of the aircraft’s general performance and a comparative assessment. Moreover, at the stage of comparative assessment [air combat], each of the pilots took turns in MiG-21bis and MiG-23M and fought against F-5E (and vice versa). The technical staff who prepared the elegant American fighter for flight remembered it for its simplicity and thoughtfulness of design, and ease of access to serviced units. One of the participants in the study of the American aircraft, leading engineer of the Air Force Research Institute Marchenko, noted such an advantage of the fighter as a glare-free instrument panel: high-quality coated instrument glass in any lighting did not create problems for reading information. Air Force Research Institute engineers puzzled over the purpose of the button at the bottom of a deep niche in the cockpit for a long time. As it turned out later, it was intended to remove the weapon lock with the landing gear extended. Soviet test pilots appreciated the comfort of the cockpit, good visibility from it, rational placement of instruments and controls, easy takeoff and excellent maneuverability at high subsonic speeds. F-5E flew in Vladimirovka for about a year until one of the landing gear tires collapsed. After testing at the Air Force Research Institute, the aircraft was transferred to TsAGI for static tests, and many of its components and assemblies ended up in the design bureaus of the aircraft industry, where interesting technical solutions from Northrop were used in the development of domestic aircraft. These tests are recalled very interestingly and in detail by their direct participant, Honored Test Pilot of the USSR, Hero of the Soviet Union, Colonel Kondaurov in his book “A Life-Long Runway.” After a thorough analysis of the materials, the conclusions of F-5E vs MiG-21 tests were as follows: MiG-21bis had better acceleration characteristics and climb rate at speeds of more than 500 km/h – due to higher thrust-to-weight ratio MiG-21bis had better angular speeds of turns at speeds of more than 800 km/h [MiG turned better at higher speeds] At speeds of 750-800 km/h, neither aircraft had any advantages - the fight was on equal terms, but close combat did not happen due to the large turning radii of both fighters At speeds less than 750 km/h the F-5E had the best maneuverability characteristics, and this advantage grew bigger with increasing altitude and decreasing flight speed F-5E had a wider maneuvering area where it was possible to perform steady turns with a radius of less than 1800 meters [speeds at which F-5 could perform tight turns] F-5E had better visibility from the cockpit and a more comfortable cockpit layout F-5E had more ammunition, but a lower total rate of fire of the guns, which allowed to have a longer firing time Kondaurov wrote about the American fighter: “Not inclined to perform vigorous maneuvers in clean wing configuration [wing mechanization not activated], it was transformed when the pilots transferred it to the maneuverable configuration [slats and flaps activated]. From a heavy “hulk” it turned into a swallow.” It was noted that without the use of wing mechanization, the F-5E had no advantage in maneuverability. On F-5E of the first series (one of these aircraft was tested by Soviet pilots), the pilot, using a switch mounted on the throttle stick, could set the slats and flaps to 5 fixed positions. On later series F-5E, the deflection of slats and flaps was made automatic - based on a signal from the altitude and speed sensors. At speed above 0.85 Mach forward slats of F-5 were not active [neither version of MiG-21 had leading edge slats]. Analysis of the tests carried out forced Soviets to reconsider the degree of importance of certain parameters when assessing the maneuverability of an aircraft. Tactical techniques for conducting air combat with F-5E and recommendations for fighter pilots were developed. The general meaning of these recommendations was as follows: to impose a battle on the enemy in conditions where the MiG-21bis had advantages over F-5E, and to evade the battle (or try to get out of it) under unfavorable conditions - make a good use of the advantages in speed and acceleration characteristics of MiG-21. [same vibes to “American pilots encounter A6M in Pacific and learn to not engage into slow turning dogfights, maintain energy instead”] The results of training dogfights with MiG-23M were similar. At higher speeds, the advantage likewise passed to MiG-23M, due to better acceleration characteristics and thrust-to-weight ratio. Based on the test results, work began on introducing leading edge slats on the next modification of MiG-23 [ironically, almost all versions of MiG-23 had forward flaps, but those were used only for take-off/landing. Fully automatic forwards flaps for maneuvering were enabled only on MLD version]. With F-5E's armament [cannons and Sidewinders], the main problem for it was entering the Weapon Employment Zone. At speeds of less than M 0.85, F-5 did well and could tail both MiGs on the second turn. At higher speeds F-5 could no longer do anything. And indeed, at higher speeds MiG-21 and MiG-23 both performed well against F-5. In fact, at these speeds MiG-23M performed the best because it could attack from any vector [MiG-23M had all aspect R-60 missiles and IRST while both MiG-21bis and F-5E had no IRST and assumed to use older “tail-chaser” missiles]. Moreso, MiG-23M was the only fighter of these three capable of BVR combat and could engage F-5 from safe distance. For this reason, BVR combat was not even simulated as F-5 couldn’t really do anything in such scenarios."

So I looked into the VTOL behavior to see what is wrong with it. From my experience (on Hard of course), all stock and modded VTOL aircraft in the game are impossible to hover and thus, you can't take-off or land in trve VTOL mode. When your airspeed is low enough aircraft starts to show stall behavior (default in-game) and is subjected to sudden sideways jerking movements, quickly taking it out of control. This restricts you to using only the STOL take-offs and landings - on take-offs you had to input horizontal acceleration as soon as possible, and on landings you have to maintain minimal airspeed. This is fine, I learned to land Yak-38 on the deck going at 70-100km/h, but having proper VTOL would be good too. Debug mode shows the reason for this - AoA values go all over the place. When you climb vertically, it goes around -90, when you sink - 90. If you sink backwards it shows close to -180, and on backwards climb - close to 180. Technically, this kinda makes sense as it shows the direction of "relative wind". But because the airspeed is well below the stall speed, this shouldn't really matter. Aircraft is not yet producing any lift and it doesn't really have AoA yet to speak of. The game thinks otherwise. It sees AoA value going overboard and freaks out because of it, applying stall and then trying to spin your aircraft. This is the reason for wackiness during hover. To test this, I picked Harrier and plainly deleted all stall and spin related values in its DATA file. No surprise, it started behaving fine in VTOL, I could hover, take-off and land alright. But this is not the solution because: 1 - by deleting all stall and spin entries I just turned Harrier into a complete UFO in the normal mode. Unacceptable 2 - the game still freaks out when I "flip 180". With backwards movement, if I cross the line between positive and negative AoA at 180/-180 - read sink backwards and then apply power and start climbing or vice versa - the game simply flips the aircraft over I've thought about using the usual fake highlift surfaces or editing the tables, but neither solution worked or didn't affect the normal flight. And thus the bad news, I don't think this could be solved using the DATA files alone. The proper solution should be implemented on the game engine level, simply disabling all stall and spin behavior (for example, simply locking AoA to zero) when nozzles are deflected downwards. Since we don't have access to engine's code - alas. And likewise, this problem is legit for modded helicopters too. You can disable all stall and spin values from their FMs, but "flipping the 180" issue will remain. This is really unfortunate because on game engine level this could be solved with just few lines of code. With the simplest approach, the engine has to track only one variable (thrust vectoring input) and after a certain threshold simply lock AoA to zero

Speaking of which, I don't think you need to complicate it that much if you make a simple animation. Making a parent node for control surfaces is usually done when you need to assign a double function to a single node, like elevons (pitch and roll) or rudder-airbrakes (think F-22). A single function node could be animated using only the pivot point. I know that setting a pivot in Blender is not that user friendly as in 3DSMax, but nothing impossible. And also, you don't really need to create the animation for control surfaces. Just set-up a pivot point and then point the according node in DATA file. The movement limits are established there as well, the game's engine will handle the rest

I am not a much 3D guy myself, but if this helps - to export the multi-object model to SF2 engine you need to establish a kind of "master node". Select one object in editor (usually it is fuselage) and make it a parent to all other nodes, so it sits at the top of hierarchy. Not sure about emptys, in any case you can use just a really smol object which would not be seen in the game. I saw this in several working models and did the same recently. This is usually done to enable elevons or drooping ailerons as making them through data file is not always possible because the game engine doesn't allow two functions for a single node

So I wanted to check if F-22 from download section has G limiter - and of course it has. F-22 FM is credited to Baffmeister by the way It uses the very same method of applying downforce, has two stages and looks like this (I swear I wasn't copying it when I was experimenting with mine ): [LS_Pitch_Attenuator] SystemType=HIGHLIFT_DEVICE DeploymentMethod=AUTOMATIC_G_LOADING CLiftdc=0.0 CDdc=0.0 Cmdc=-0.06 AreaRatio=0.0 SmoothDeployment=TRUE Setting[1].Angle=40.0 Setting[1].DeployValue=9.5 Setting[1].RetractValue=4.0 MaxDeflection=40.0 MinDeflection=0.0 ControlRate=16.0 ModelNodeName= [HS_Pitch_Attenuator] SystemType=HIGHLIFT_DEVICE DeploymentMethod=AUTOMATIC_G_LOADING CLiftdc=0.0 CDdc=0.0 Cmdc=-0.20 AreaRatio=0.0 SmoothDeployment=TRUE Setting[1].Angle=40.0 Setting[1].DeployValue=12.5 Setting[1].RetractValue=9.6 MaxDeflection=40.0 MinDeflection=0.0 ControlRate=16.0 ModelNodeName= Major differences are that retract values are much lower and ControlRate is way higher, also downforce is ascending (in my set-up it is descending). In F-22 itself it works like a charm, kicks in instantly and no wobbling at all. But I found it more difficult to adapt it to other planes

I know this, although I don't remember posting anything related to airspeed values. The limiter works with G loading (DeploymentMethod=AUTOMATIC_G_LOADING) and Angle of Attack (DeploymentMethod=AUTOMATIC_ANGLE_OF_ATTACK). I don't think it is related. The worst thing you can get is badly controllable plane, although even this is rare. In my install, I fixed the rudder on all aircraft and it works alright. For rudder drag, first you had to make check the ReverseInput= parameter. It reverses the values, for example, CDdc=-0.1 with ReverseInput=TRUE value is the same as CDdc=0.1 with ReverseInput=FALSE. It is usually TRUE in most aircraft but I found one where it was absent (it's Su-57 from Banidos) Then, if you simply want to fix the drag you just make CDdc negative. If you want to enable sideslip drag, you make the total CDdc of rudder at -0.2. This means CDdc=-0.2 for single rudder aircraft and CDdc=-0.1 in each rudder for twins This is useful if you need to drop the speed to avoid overshooting (AI likes to force overshoot) and you can sideslip for speed or altitude during landing. If I come in too fast I just go hard sideslip and bleed energy until I can deploy flaps and enter glideslope normally. Although of course the testing is needed as FM models differ quite a lot across the board.

So, can we have such things in this game? Yes, we can. I saw the method in F/A-18A I downloaded. It essentially creates a fake highlift surface which is activated under given conditions and prevents you from exceeding the given limit. Only in Hornet this fake surface slices down the total lift force - which works, but is not really optimal. Firstly, if you pull really hard and go at high AoA you will already experience the lift force going down - then this limiter kicks in and the situation can quickly turn into accelerated stall. Secondly, I haven't managed to make it work for stock F-16. The solution is to apply pitch downward force instead of slicing the lift. Much simpler and effective. This is the type of limiter I put into MiG-23MLD. If you try to go above 25AoA it kicks you back five or so degrees. MLD didn't have fly-by-wire and had simple limiter, so this is even close to historical behavior. Moreso, MLD is not particularly twitchy plane so it works fine. [AoA_Limiter] SystemType=HIGHLIFT_DEVICE Cmdc=-0.5 DeploymentMethod=AUTOMATIC_ANGLE_OF_ATTACK Setting[1].Angle=45 Setting[1].DeployValue=25.0 Setting[1].RetractValue=24.9 MaxDeflection=45.0 MinDeflection=0.0 ControlRate=10.0 SmoothDeployment=TRUE But if we try this for more twitchy planes - like F-16 - this creates weird pitch wobbling. Not good, so we have to be more precise. This is the limiter for stock F-16A [G_Limiter] SystemType=HIGHLIFT_DEVICE Cmdc=-0.1 DeploymentMethod=AUTOMATIC_G_LOADING Setting[1].Angle=45 Setting[1].DeployValue=8.0 Setting[1].RetractValue=7.99 MaxDeflection=45.0 MinDeflection=0.0 ControlRate=0.5 SmoothDeployment=TRUE [G_Limiter2] SystemType=HIGHLIFT_DEVICE Cmdc=-0.05 DeploymentMethod=AUTOMATIC_G_LOADING Setting[1].Angle=45 Setting[1].DeployValue=8.5 Setting[1].RetractValue=8.49 MaxDeflection=45.0 MinDeflection=0.0 ControlRate=0.5 SmoothDeployment=TRUE [G_Limiter3] SystemType=HIGHLIFT_DEVICE Cmdc=-0.025 DeploymentMethod=AUTOMATIC_G_LOADING Setting[1].Angle=45 Setting[1].DeployValue=9.0 Setting[1].RetractValue=8.99 MaxDeflection=45.0 MinDeflection=0.0 ControlRate=0.5 SmoothDeployment=TRUE [G_Limiter4] SystemType=HIGHLIFT_DEVICE Cmdc=-0.015 DeploymentMethod=AUTOMATIC_G_LOADING Setting[1].Angle=45 Setting[1].DeployValue=9.5 Setting[1].RetractValue=9.49 MaxDeflection=45.0 MinDeflection=0.0 ControlRate=0.5 SmoothDeployment=TRUE [G_Limiter5] SystemType=HIGHLIFT_DEVICE Cmdc=-0.5 DeploymentMethod=AUTOMATIC_G_LOADING Setting[1].Angle=45 Setting[1].DeployValue=12.0 Setting[1].RetractValue=11.99 MaxDeflection=45.0 MinDeflection=0.0 ControlRate=0.5 SmoothDeployment=TRUE It has 4 (!) main stages which introduce progressive pitch down moment. In effect, no matter how hard you pull, you will keep 9 - 9.5G in continuous turns and wobbling is minimal. The fifth stage is hard cap to prevent going overboard at hard pulls (stock F-16A can easily get instantaneous 20G, crazy). Limiter takes few seconds to kick in but then does it's job. The template is fit for any plane you wish. The first, simpler method could be used for older no fly-by-wire planes, while multi-stage limiter for the ones that have it. Likewise, you can limit negative AoA and G too. Obviously, the values had to be tailored for different planes. You need to check the deploy/retract values to specify the range when limiter kicks in. Then, you had to adjust the downforce Cmdc value. If plane gets too wobbly, it had to be decreased; if the limit is exceeded, increased. In general, you want to keep the wobble minimal, at 2-3deg AoA or 0.2-0.3G units. Usually, the more twitchy is the plane, the bigger Cmdc should be. The values are by no means final. You can stack more stages if you fancy and play around with different values (ControlRate here is the speed at which downforce is applied and removed, I.E - 10 - instantly, 0.1 - very gradually) This is G limiter for Hornet for example: [G_Limiter] SystemType=HIGHLIFT_DEVICE Cmdc=-0.05 DeploymentMethod=AUTOMATIC_G_LOADING Setting[1].Angle=45 Setting[1].DeployValue=8.0 Setting[1].RetractValue=7.99 MaxDeflection=45.0 MinDeflection=0.0 ControlRate=0.5 SmoothDeployment=TRUE [G_Limiter2] SystemType=HIGHLIFT_DEVICE Cmdc=-0.025 DeploymentMethod=AUTOMATIC_G_LOADING Setting[1].Angle=45 Setting[1].DeployValue=8.5 Setting[1].RetractValue=8.49 MaxDeflection=45.0 MinDeflection=0.0 ControlRate=0.5 SmoothDeployment=TRUE [G_Limiter3] SystemType=HIGHLIFT_DEVICE Cmdc=-0.015 DeploymentMethod=AUTOMATIC_G_LOADING Setting[1].Angle=45 Setting[1].DeployValue=9.0 Setting[1].RetractValue=8.99 MaxDeflection=45.0 MinDeflection=0.0 ControlRate=0.5 SmoothDeployment=TRUE [G_Limiter4] SystemType=HIGHLIFT_DEVICE Cmdc=-0.010 DeploymentMethod=AUTOMATIC_G_LOADING Setting[1].Angle=45 Setting[1].DeployValue=9.5 Setting[1].RetractValue=9.49 MaxDeflection=45.0 MinDeflection=0.0 ControlRate=0.5 SmoothDeployment=TRUE This turned out a little bit wobbly, but it keeps Hornet at 7.8-8.2G in continuous turns. Fifth stage is not needed. As you can see, Cmdc values are decreased to reduce wobbling. You may notice that limiter is kicking in at both cases at 8.0G, but Hornet is kept at 8G continuous while F-16A is at 9G. This is the quirk of the method, you had to tailor it for every plane. Attached stock F-16A data file with limiter enabled F-16A_Netz_Data.INI

Control of such aircraft in VTOL mode is taken care by different control inputs. The max control speed for rudder and ailerons in Harrier is 200km/h which means that below this speed they do nothing. The maneuvering below these speeds is governed by engines themselves which is how the game simulates differential thrust I assume. This is the correct approach but the game doesn't really like any aircraft staying in the air at airspeeds close to zero. Every time I tried to make any VTOL to hover it started to show the stall behavior (which is not correct, the lack of lift is compensated by engine thrust) and just fumbled uncontrollably

I don't have much experience with SF1 content, but apparently it uses one big weaponsdata.ini file which stores the data for existing weapons. You have to add new lines to it to activate new stuff. SF2 supports individual data files in folders, so you just put new folders into the general weapons folder

More discoveries! I was playing with rudder drag (CDdc coefficient) to simulate the drag during sideslip. This is really a dirty way of dealing the with issue, but as @mue points out, the game engine simply doesn't calculate the correct force - drag due to beta Cdb. It works as intended, it is possible to increase the drag so you would start to lose speed during any slip. The byproduct is that you would also experience increased drag during coordinated turns when you apply rudder to correct for adverse yaw, but as adverse yaw in SF flightmodels is not really strong, I can live with it. But the interesting part is that the value of CDdc also seems reversed. In all data files I've seen it is set in positive. Makes sense. So, this time I picked Yak-23 as the victim for my tests and started gradually increasing the value. Not only I haven't experienced any drag effect, aircraft actually started to accelerate at full rudder. Then, I went overboard and increased CDdc all the way to 1.0 - and voila, the poor Yak instantly accelerated to supersonic speeds at full rudder. After affixing the value to negative, it started to work as intended. I went back to my control subject, stock F-100A, and effect is similar. Positive drag value decreases drag and negative value increases it. This means that every stock and modded plane actually has a reduction of total drag when giving full rudder. It's just that the values are rather low and barely noticeable.