OlWilly

From my experience digging through aircraft flight models as well as doing ingame tests, the flight model is indeed the strongest part of the game engine. It is far more complex and detailed if you compare it for example to the primitive avionics capability

So you're saying that as soon as you established free access, people immediately started getting their way to download more stuff... in amounts unacceptable for your hosting capabilities. Also "bandwidth monthly aggregate average is 2.3 to 2.4 TB, peaks are 5TB and higher", really? This means that a lot of people are still interested in the game which is actually surprising. Does ThirdWire knows about this? The writing on the wall is that they really should make SF3, all of this shows that it will sell well

I dug a lot into weapon and avionics parameters and basegame indeed has this issue - I won't say it is biased, more like casualised Default AIM-9M from Israel DLC could easily lock at 20km and then hit without losing much energy. This is ace combat level of "simulation" The energy performance of missiles is likewise all over the place edging on UFO territory I would stress that this is not the engine issue - the engine could model missile performance surprisingly well, I had good results tuning the missiles Unfortunately, without massive rebalancing this is not easily solvable

Since the engine is 32bit it remains bottlenecked by RAM. It works alright with vanilla assets and you can max the setting as much as you want. The more new stuff you add to the mission, the worse it gets. You can take a default map and spam it with F-100s for example, even with dozens of them flying around it will work alright. But once you start adding new high def stuff, the performance drops - you can test it with high def ground vehicle pack or certain aircraft. The more different stuff you add, the worse it gets Old MSFS titles have polygon limiter to prevent modders from overloading the game engine - but here you can take a high def model ripped straight from DCS and the engine will still try to process it

Since autopilot on MiG-21 was still fairly basic, this indicator was used to give pilot visual cues on required intercept course. Works similar to glideslope/course director on landing, you align the movable lines with the cross in the center and it means you go right. On later models like MiG-23 and MiG-25 this was directly linked with autopilot so it could take commands directly from CGI without pilot supervision. Pilot could almost take a nap but he still retained throttle control The vertical aka azimuth line could be made to work within base SF2 avionics - the game supports course indicators. Horizontal aka altitude line unfortunately won't work outside of landing waypoints

No mention of required subscription on the download page. No mention of it on the frontpage. I assume nothing is said about it when registering as well. What's the reason for not putting a banner with big block letters on download or front page saying "Downloads are available only for subscribers?" That other site, a-team or whatever, has the paywall mentioned right on the frontpage in big red letters, you won't miss that Unless you are trying being low-key about it I see no reasons not doing that

SymbolType=TD_RADAR is for target locked in STT SymbolType=TD_HEAT is for target locked by SRM own seeker Usually it's two different symbols so they don't overlap. Also remember that most fighters could slave SRM seeker to a radar I am not sure if you can disable TD_RADAR when SRM is selected since it's two different functions

I've definitely seen that in some of planes I adjusted. Your method is superior, as it allows for finer tuning and better results, but requires matching the armor values for nearly every aircraft individually. You can do things like, for example, having a multi engine bomber and giving its engines better protection from the rear and sides, but worse from the front, encouraging frontal attacks. StructrualFactor is just simpler, you can slap it on every component and get the durability boost

If you compare SF with other sims you may notice that planes explode way too easily. You just look at the plane funny and it's already going down in a ball of flames. In my install I went out to fix this. Generally, every airplane part (fuselage, inner wing, etc) has its own HP bar. Once it's depleted, it's gone. HP pool is determined by the size of the part - obviously, B-52's inner wing would have more HP than F-15's. StructuralFactor statement is a plain multiplier for every such part. At 1.0 it does nothing, leaving HP at 100%, at 2.0 it makes it 200%, etc. So, what I did, I gave every structural part a StructuralFactor=2.0, unless it was already higher. This gave some ruggedness, but planes were still exploding too much. The issue is fuel tanks. They are big, always get hit, and once hit - leakage, fire or explosion proc very easily. This allows stuff like easy kills with just 1-2 cannon hits. I wasn't looking for an elegant solution, and as a dirty crutch just added 35mm of steel armor on every fuel tank (it has no weight so alright). This is not supposed to represent any real-world protection, just to crutch over game's engine mechanics. And it gave good results. Aircraft did not become indestructible, a good missile hit or aimed burst still takes it down. But aircraft (you and AI alike) now can take some non-critical damage, and you may even see damaged planes actually hit the ground. For the first time while playing, I managed to get hit and lose one engine, limping home instead of outright exploding. Another issue is ground vehicles. In vanilla SF, a single 20mm shell destroys any tank from a single hit, from any projection, which is wrong. After experimenting I found that ground vehicles have pitiful HP bars and you need to up them literally by 1000s. For example, I gave T-55 StructuralFactor=4000.0 for hull StructuralFactor=5000.0 for a turret. You would think that this is a lot, but a single Maverick still gets it; if you use cannon, now you have to work for a kill. The downside of this is that you have to apply changes manually to every vehicle you want to have it. I had a lot of available time during night shifts, but it is really a tedious process. But it makes dogfights and ground attacks more involved for sure

If I am not mistaken, SARH missiles don't have a HUD symbol of their own, the target gets the symbol from being locked by radar. I can't remember what symbol it is, most likely [HUD_TD] SymbolType=TD_RADAR

I see a number of typos in cockpit labels on the screenshot. Usually I would offer to help spellchecking them, but no point in it now

The decision to drop Strike Fighters series is actually strange from financial point of view. For post WWII era we have two great study sims - DCS and Falcon BMS. Lots of arcade flight games (not worthy being called sims), like Ace Combat or whatever. But for survey, lighter sims, right in the middle, there is an actual shortage on the market. Notice how Nuclear Option waltzed in and seized a decent following just overnight, and it is still in Early Access. A lot of people enjoy sim mode in War Thunder, but hate the grind, and won't mind an offline or less grindy version/spin-off of it. Strike Fighters 3 would easily get its share of the market, especially if it will have an online mode, but without the grind like in WT

From my understanding, BoresightElevation and BoresightAzimuth define the direction of the beam. In this case, it will be 0 azimuth - straight center, and -2 elevation, meaning that it's angled down -2 degrees from the aircraft's centerline. BoresightBeamAngle should be the width of the cone, imagine it not as a "line" but as a "cone" with apex being placed at emitter and degree being measured from the centerline (or bore in that matter)

.LOD in general is not owned by TW, but this is the "umbrella" format of sorts. Some other games used .LOD too, and guess what, they are incompatible with SF2 Generally, I don't recommend this format for open source game as it is a locked format, with no easy editing. Strike Fighters .LOD models are exclusive for Strike Fighters From what I understand, TW is very touchy on the matter of using their 3D assets, so this is a hard no. This is one of the reasons why they choose .LOD format, so no one could touch their precious 3D models On the other hand, modders created tons of decent and great 3D assets for the game, but here comes the issue. All the mods available here are in .LOD too So, you would need their permission and original 3DSMax/Blender/whatever models which would be hard to get. Many modders are no longer active and many original models are lost to time TLDR - if you manage to contact the modders and convince them to share their original 3DSMax/Blender/whatever models, you are good to go. But if you want to work with SF .LOD format, you're out of luck

From what I understand, those are low level functions that process the raw data generated by the game's engine This data is called by scripts which govern the actual functioning of the game, avionics, flight model, etc. Scripts, in return, are set up by .ini files So we have two levels here, with the higher one being accessible to tuning, but not modding. Thus, we know that the low level is contained in binaries. The scripts themselves, the higher level, I assume hidden in the binaries too Low level itself may seem not that important to modding the engine as it's just a set of tools to get and process raw data. But it could open the way into the actual meat of the code, the scripts, and help understand how they actually work Speaking of which, do we know in what language the game is written? C++ I presume

Some compromises had to be made, but overall function of RP-21 could be modeled just fine. You just need to create proper symbology

Indeed, the game engine was built to deal with a limited number of assets during a single mission. You have like up to 10 types of aircraft, limited number of munitions and very few ground objects all using relatively low res textures and not too crazy on polygon count. Then you load up a heavily modded game with number of objects increased by order of magnitude and all using bigger textures and often high poly. Ground vehicle mods tend to contribute to this problem a lot. A single mission won't generate too much types of the aircraft, but can go crazy with ground units. When I added vehicles from massive WarPac pack the loading times increased a lot ...

AI can't really defend again SARH missiles either. The only thing it could do is to drop chaff, but defensive maneuvers - forget about it. I've read somewhere on this forum that in some previous titles - WOE I think - AI could even notch your missiles; but apparently this was nerfed like many other features to simplify the gameplay

Technicians are preparing the Polish MiG-21PFM for takeoff. The canopy is tilted to the right. The MiG-21PFM was the first version of the fighter to feature two rear-view mirrors in the cockpit. Later they were also used on vehicles of the MiG-21SM family. Only on the MiG-21 MF they were replaced with a TS-27LMSh rear view mirror. The MiG-21PFM was also equipped for the first time with the improved RP-21MA Sapphire radar. Two rear mirrors on the MiG-21PFM canopy. These mirrors were not present on early MiGs. This aircraft is also equipped with a TS-27AMSH rear-view mirror. In addition, this is an early version of the MiG-21PMF, since the aircraft is equipped with a KM-1 ejection seat. https://military.wikireading.ru/33447?ysclid=lzs4o0c1wx378987657 TS-27AMSh is the rearview periscope common for other aircraft too (MiG-23, Su-25, etc) View from Il-76

Speaking of the text on the fuselage, before you release these birds send textures to someone for proofreading, me if no one else around

SF2 engine allows only for unlimited CCIP - meaning that it will show the point of impact no matter the distance to it.Things like limited rangefinding distance or HUD limits are not present in the game. This works both for rockets and bombs. What this means in game that you can simply align your CCIP with target box and fire, distance notwithstanding. Rockets will land close to the target Works only if you had CCIP enabled in avionics.ini

By general rule, aircraft produced/designed in 1940s-1950s had dark gray/blackish color - MiG-15/17/19/early 21s, Tu-95, Tu-16, etc. In mid 1960s the coloring scheme changed for greenish-blueish color with MiGs, Sukhoi went with more blue-gray colors

Countermeasure pods of all kinds work only in player aircraft, both chaff/flares and ECM. I tried few ways around it, for example, enabling an internal CM dispenser but loaded only with 1 chaff/1 flare and then loading external pods with CMs. What AI did with it? It dropped exactly one flare and then just stopped. Same with ECM, I enabled internal ECM with 0.001 strength and then normal external pod. No change - in fact, in player aircraft you can't really activate internal ECM but ignore pods - both will go on; but AI has only internal working. So it's not like AI *chooses* not to use the pods, it simply doesn't register them on. The stuff is messed up on .dll level; I've read about that this bug came in only with NA so someone has to compare pre-NA and current .dll's. The only way around it is to fix the pod external model to aircraft through fakepilot, disable the station taken and enable the function in aircraft .data file. The bad news is that this removes the flexibility from loadout options

In RL, to jam something you need to know at what frequency it operates. After you know the frequency, you put out jamming to block it - and from then on, it's the game of jammer and radar powers. Radars, especially SAM ones, usually have more power than jammers, but the signal power decreases with range - so you have jammer working at a certain distance, but then radar "burns" through it. In Vietnam, the main task for Americans in that regard was to learn the frequency range on which Soviet radars operated. After they found out the frequencies of the first supplied S-75 radars, they issued jammers that blocked these frequencies specifically. Soviets, in respond, supplied radars with changed frequencies. And so on, this is the game one can play for a long time. The response to this was firstly, to enable radars to use several frequency presets, allowing operator to choose the one that wasn't jammed (Kub, for example, already had it, not sure about later S-75s though). Then, later, radars switched to dynamic frequencies, randomly picking and changing them within the operating range. Game doesn't simulate these later developments, all SAM radars have fixed frequencies, so early 1960-s level of tech. You can only specify search, track and guidance frequencies Interestingly, missiles have MinFreq and MaxFreq statements, but those are only for anti-radiation missiles, telling them what radar they could pick

After some testing, I came up with a routine to tune SAMs and SRMs as well. For SAMs, the data you can find online is usually given for a high-altitude target - where the air is thinner and missile could accelerate better, having more range. To get the low-level performance, for simplicity sake, we may assume that it is the half of maximum range (which is often close to reality, check MIM-23 for example) and reduced max speed. And this is all we need. Weight and Diameter as in DATA file. Init speed at zero which would mean launching from a non-moving platform. Next, we will check the missile performance at higher altitude. Again, to keep things simple, let's assume 15k meters - IAS/TAS ratio at 0.6. Here, aim for more range and speed as stated online - because you had to account for missile actually getting there and MRS doesn't do this. Then, check missile performance at lower altitudes, which would be IAS/TAS ratio of 0.8, or around 5k meters. The range should drop approximately in half and max speed below the one stated online. Speed of sound at this altitude is around 1150km/h or 319m/s for the reference. SAMs nearly universally have booster stages, so they had to be enabled in data file for the required performance. ---- For SRMs, the process is a bit different. SRMs follow the same energy rules as all other missiles, but they are in fact limited by their seeker - the max lock-on range, plus heatseekers leading algorithms are inferior to radar seekers, and they don't lead in the most optimal way. Purely ballistically, one could lob AIM-9 at well over 20km with no problems, but you would be unlikely to lock on anything at that range. Thus, as SRMs are designed for maneuver combat at close ranges, we simply pick the lesser energy state of the launch platform. For simplicity, this would be 5k meters (IAS/TAS ratio of 0.8) and Init speed at 1 Mach, or 319m/s. Tune the missile so it would have the speed close to what you can find online, and range somewhat below it. The game doesn't have good algorithms for heatseeker operation, and many vanilla SRMs have crazy lock-on ranges - it was not uncommon to lock and shoot with something like Python-3 or AIM-9M from 20km at target that doesn't even have the afterburners on. In my install I arbitrarily capped all SRM at certain ranges to prevent this.