Righteous26

This was the initial post. He said the crash happens when he orders his wingmen to attack. He is well past the takeoff point by this time. Perhaps you should pay more attention to the OP and not your unfounded assumptions. This has nothing to do with airfield size or aircraft selection. He made that clear. That's why I suggested taking the CAP chance out to see what happens.

I looked at several benchmarks for both chips and they were 10% different when performing timed tasks. I have also noted that SF2 does not take advantage of the advanced chips. Increasing power does not seem to help here as the OP has an i7 and is still experiencing this problem. The campaign manager also determines missions using the war goals listed near the top of the _data file. You should check that out. It's not just the chance given to the squadron. In this case they are all 90 anyway so any mission type should have the same chance. As you are defensive at the start of the campaign you will be on defensive missions like defensive CAS and CAP. You should start that campaign with a defensive CAS mission if you play as Mercenary and change no other options. I started it ten times yesterday and a defensive CAS mission to Najafi or Mosak came up every time. A CAP mission came up second as I intentionally failed the first mission. I was then able to replicate the problem. It happened twice. The first time was when a MiG-21 fired an AA-2D at a friendly and the second was when I fired an AIM-9N at a MiG-23BN coming off its attack run on some friendly tanks. The game just crashes to the desktop. Setting the CAP mission chance for [AIRUNIT008] to 0 in the _data file may help this. The CAP missions should not come up anymore. You still have not spelled Occam correctly. It's Occam, Ockham or Ocham. A razor is a small blade that is used for precise cuts. Given the intent of Occam's Razor is to be as precise as possible with as little effort as possible a razor is more appropriate.

Is the CAP mission the first or second mission you flew? If it is the second, were you successful on the first?

It's called Occam's Razor. I said the processing difference does not matter for SF2 as it can't take advantage of it. Besides a lot of benchmarks put i5 and i7 performance at about a 10% difference even when performing timed tasks.

I doubt SF2 spends much processing time in the space between an i5 and an i7. It's not designed to use either chip to its maximum performance. Hence, you won't see an increase in performance. SF2 is not a high end game requiring that sort of horsepower. Please note I claimed it happens only rarely and I can't replicate the issue even now.

Not at all. I have all settings maxed out and it has not happened for months. It is rare, but I can see that the CPU bogs down in certain instances because the game is slowing down and it's not just the graphics. The engine is having problems keeping up with everything. It sorts itself out most of the time but it has crashed sometimes as well. I moved it to an SSD and that seemed to help. My CPU is an i5 8700 at 2.8GHz with 16GB RAM and the video card is an RTX 3060 with 8GB VRAM. The SF2 textures and shaders aren't taxing either of these cards. Hence, it's not a graphics issue.

Strange, I run it on Windows 10 x64 and I have had what he describes happen. The CPU clearly bogs down if too many entities are active and the game will crash. I have plenty of RAM, VRAM and no corrupted files. Some of these campaigns are clearly more than the game was designed to handle.

It depends on what it has to load. There could be more units in that campaign. That means more in the air at one time.

The base game does not appear to be written for modern multicore processors. When you merge and order your wingmen to engage the computer does the same with nearby enemies. This increase in loading on the CPU can cause a crash. SF2 likely can not use the full power of your CPU. I have had similar problems. You may try moving the game to an SSD or a drive connected to your motherboard if it is on a USB drive. The increased data transfer rates may help.

To amplify this I have taken all the AAMs I use in the game and consolidated them with the best models and textures I could find. I also adjusted the data files to change the ranges to better match the available data. Several of the weapons available here seem to be above the maximum resolution and number of vertices the game engine can handle so you are not likely to improve much.

Yes, you can add things like this on the flight line and move the equipment between aircraft. In the US Navy they have aircraft called "strike birds" that are in such bad shape by the end of a cruise that they take functional parts from these aircraft for use on aircraft that can be made mission capable. The US Army does the same thing and calls it "controlled exchange" or "CAN" in the maintenance records. You absolutely can move sensors, armament, computers, MPDs, ASE, engines, wire bundles and just about any black box or electronic device to another aircraft. It may be frowned upon officially, but the units do it to meet mission especially when they are at the end of a deployment and parts are in short supply. You must record it in the maintenance logs of all affected aircraft however, as the parts are often serial numbered and accounted for by SN and aircraft tail number. If a squadron is going to war then they will likely get the best kit available even if it means taking it from another unit. Further, the units leaving theater leave some equipment behind so there is a supply of spares in theater.

It would be reasonable to assume that any aircraft in SF2 would have the countermeasures installed as all the aircraft simulated are in an operational theater with an active war ongoing. The US military will swap mission essential equipment from vehicles leaving a theater to those entering it and will prioritize units going to a theater over those not scheduled for deployment.

Just because the item does not appear in the manual until a given date does not mean that it was not in use earlier. If you note page 8-4 reads "Change 4" at the bottom and page 8-5 reads "Change 7" next to the page numbers. These pages were added to the manual at different times after 1975 and then released as one comprehensive package in 1979. Unfortunately, any interim changes in panel position, if any, are lost. The installation of the control panels was likely an ad hoc affair if a unit did not get the technical support representatives from the equipment manufacturer and there was no USAF guidance for where the panels should be placed. Hence, there may have been several configurations depending on when the panels were installed. Further, some units would receive the equipment for installation on the flight line and others would have it installed during depot level maintenance or overhaul. The manual reflects the official requirements for the placement of the panels as of its publication. It is likely not the only configuration that was approved or used as these change over time.

Here is a campaign movement file I made for the TexasASC terrain. The attached picture shows the routes. The units appear to be moving properly between the nodes. However, the frontline trace becomes a mess after the first day or so and loops back on itself. TexasASCCampaign.txt

Is there a campaign movement file for the Texas ASC terrain set?

Check the attachment type in the MiG data files. It should look something like this. Ensure it reads AttachmentType=WP,SOVIET. If you intend to use Chinese weapons then you must add ,CHINA to that line as well. [RightOuterWingStation] SystemType=WEAPON_STATION StationID=2 StationGroupID=1 StationType=EXTERNAL AttachmentPosition=2.68,-1.49,-0.42 AttachmentAngles=0.0,0.0,0.0 LoadLimit=500.0 LengthLimit=3.5 AllowedWeaponClass=BOMB,RCKT,RP,IRM,FT AttachmentType=WP,SOVIET ModelNodeName=WingPylon_Outer_R PylonMass=60 PylonDragArea=0.02 LaunchRailNodeName=MissileRail_Outer_R LaunchRailHeight=0.10 LaunchRailMass=25 FuelTankName=Tank490_MiG21

Check each file in the list when Windows prompts you to replace files. It is very easy to overwrite things you want to keep. I keep the weapons I want to use most in separate folders and copy them last. I also remove redundant weapons.

The order of operations matters. As an example the weapons in NATO fighters may override the Weapons Pack. Check the weapon ini files and ensure the correct LODs are referenced as a weapon may load without a 3D model but the airplane still has the weapon available.

It sounds as though one part of the install was installed under the "install for all users" option that windows has and that some of the file structure was installed under the "install for a specific user" option. Did you create a new user after installing SF2? It might help to run everything from the run as administrator option you can select from the right click menu.

Did you run the new executable you created before creating or editing an ini file for it? You must run the new copy of the game first and adjust the settings to your liking. The executable will make the ini file when it runs.

The missiles in SF2 tend to be over modeled as compared to other simulations. BMS Falcon comes to mind as hitting a fighter at 20 miles is effectively impossible with an AIM-120C-5. I reduced the impulse of all AHMs to reduce their effective ranges and the AIM-120C-5 can still reach 30 miles with enough energy for an intercept.

If the enemy fighter is an Su-35S you will get outranged because his radar will burn through your jamming before you can burn through his and fire. These reduced firing ranges also put both combatants well within the no escape envelopes of each other's missiles so the player can't just turn and run away at full afterburner. Players must then defeat the missile with chaff as the ECM is of no value against a missile and a kinematic or seeker track rate defeat is unlikely. The Su-35S radar data is obviously lifted directly from Russian promotional materials and is suspect to be fair. I have adjusted all the range, impulse and drag values for the AAMs in my copy of the game and limited their useful ranges to the range at which their velocity drops below Mach 1 based on the Missile Range Simulator projections as the missile likely has little energy left for an interception at this point.

This is a major problem for the active homing missiles (guidance type 13). The AA-9B is particularly problematic in this case as the seeker range is set to 120000. There is no such thing as an active homing missile with a seeker range of 120000 meters. You can fix this by going to the data file and changing one line. Set SeekerRange=120000.000000 To SeekerRange=20000.000000 This will prevent the computer from firing at you until it can get an accurate range on you with its radar or it closes to within 20000 meters. This will force it to respect the same constraints the player must follow. You can also reduce the firing range by changing this line. MaxLaunchRange=120000.000000 Note that changing this line will also prevent the player from firing the missile at a longer range regardless of other factors. I recommend against changing the SeekerRange value for semi-active homing missiles (guidance type 12) as the computer must first lock you up before firing regardless of the range of the seeker so there is no point in reducing that number. Also, the missile seekers do not appear to be affected by aircraft RCS. I have had MiG-31s fire at my stealth aircraft from the maximum missile range without ever seeing me on radar. This stopped when I adjusted the seeker range.

It could be a negative habit transfer from the simulator. The missile may work just a little differently there and it could throw the pilots off the first time they fire a live missile.

Look at the Nations.ini file in the Flight folder and find the Russian Federation. Check the start and end dates and make sure they cover the period you want.