streakeagle

This is a matter of personal taste. The best thing to buy is all of them. That guarantees as much compatibility as possible with all of the SF2 mods. However, I understand the cost is prohibitive for an older game like this, especially for someone on a tight budget. SF2 North Atlantic was the final game release. It is pretty cool, but has a very limited flyable plane set compared to older games. If you love the F-14 and the idea of recreating the Red Storm Rising battle around Keflavik, Iceland, this is the game for you. SF2 Europe is probably the most popular and the most compatible with mods. The plane set is outstanding and with a single large addon, the final revision of NATO Fighters, it is absolutely the biggest and best of all versions. But I am a historical re-creation nut. I don't want to make up new or alternate history like SF2 NA and SF2 E, I like to recreate history as is possible with SF2 Vietnam and SF2 Israel. It is a tossup as to which I prefer more. SF2 Vietnam has all of my favorite aircraft and includes carrier operations. SF 2 Israel has a much better looking stock terrain and includes more modern fighters like the F-15 and F-16 as well as Mirages and even old WW2 aircraft like the P-51D Mustang. Mods can make the SF2 Vietnam terrain look as well or better than SF2 Israel. The original SF2 release that updated the original SFP1 with its fictional terrain and history has its own unique values: a pretty good plane set and a mercenary campaign that provided unique gameplay not possible with any of the other historical/hypothetical games. If I could buy only one game, it would probably be SF2 Vietnam because of my love of all the aircraft used by both sides as well as the history of this war. SF2 Israel would be my 2nd choice. SF2 Europe my 3rd choice. SF2 NA my 4th choice. And finally, for its mercenary campaign system, plain vanilla SF2.

There is an Osprey book on the F-15 in Israeli service. It covers a lot of the fights in detail along with pilot comments. The gun was used a lot more often on the F-15 than is otherwise apparent, especially prior to 1982. They went out of there way to use the AIM-7 since that is the primary weapon of the F-15, but the AIM-7F didn't do much better than the AIM-7E2 (which was actually pretty good as far as AIM-7s go). You can also look at the F-14 engagements with Libya. They use the AIM-7 as much as possible but ultimately end up using AIM-9s. I am a huge AIM-7 fan and the AIM-7M finally achieved a useful PK, but the AIM-7 never achieved the reliability of the AIM-9. More complexity = less reliability. The USAF F-4s assigned to CAP in 1972 did fairly well with the AIM-7, but that was out of necessity due to the ineffectiveness of AIM-4s and AIM-9E/J missiles. Combat Tree helped them attempt BVR shots which were the ideal situation. The AIM-7E2 also performed much better than earlier AIM-7s in a short range dogfight/tail chase situation with shorter minimum range, higher allowed launch g, and more maneuverability. The AIM-7F was supposed to be far superior to the AIM-7E, but apparently its seeker was inferior to the British Skyflash. Rather than buy the British weapons (which had the older inferior AIM-7E platform), the AIM-7M had a seeker comparable to the Skyflash and the engine/performance of the AIM-7F. An AIM-7 with an AMRAAM equivalent seeker would have been great, but with funding going down after the collapse of the USSR, all further AIM-7 development was canceled in favor of the lighter AMRAAM, which could be carried by just about any aircraft that could carry the AIM-9.

As for the value of the gun, just read about Israeli experience with the F-15 in combat. They still used the guns quite a bit despite the advances provided by the AIM-7F and Shafrir missiles. They don't have any good things to say about the AIM-7. They love having the gun when all else has failed. The F-4 was originally designed to have guns (4x20mm in the belly IIRC). It was a mistake to delete them. If you think the chin mount is bad for a gun/radar installation, just look that the F/A-18 Hornet for a worse idea. If an opponent has stealth/ECM comparable to the USA, guns may yet prove to be the key to success in air-to-air combat.

The AWG-10 evolved into a great radar but it fell far short of the brochure data as released with the F-4J. A slatted F-4S with the AWG-10B was an awesome machine only lacking a gun. But look at where the F-4E was at during the same time frame. The APQ-120 evolved in parallel with the AWG-10... digital improvements increased reliability and capability across the board. But look at what the F-4E gained in its multi-role ground attack capability as well as the frameless front canopy that was deployed in limited numbers. I would have been happy to be a pilot of either one, but I think I would have preferred the F-4E unless I specifically was tasked with fleet defense over water, in which case the F-4S/AWG-10 was just short of the F-14/AWG-9 capability. But the F-4E was better at dogfighting and far better at ground attack.

I have been waiting a long time for DCS 2.5 to become the standard release branch. With development ceased on all other branches, I finally committed to the DCS 2.5 beta. I finally have access to the NTTR terrain. Flying out of Nellis over Nevada reminds me of when I got my first Windows PC in August of 2000 and Jane's USAF immediately became my primary sim because it was the best option for flying F-4 Phantoms against MiG-21s at that time. Having played Jane's Fighters Anthology on my work laptop, the graphics in USAF absolutely amazed me. In particular, the Las Vegas terrain looked great. There was a training mission called "Step Down" that taught you to fly low under radar (<300 feet) while navigating to waypoints. I flew it many times. I have briefly looked at the scripting for Jane's USAF missions and it seems to me that the DCS mission editor can replicate most if not all USAF missions. If the voice files can be accessed and converted, the experience would be almost identical beyond the updated graphics engine and differences in the flyable plane set. The problem is that it takes patience to extract the necessary information from the USAF missions and insert it into the DCS World mission editor by hand. I installed Jane's USAF and patched it up to support Windows 7 64-bit. The annoying flight models with stability issues are even more annoying on a modern PC with the patch installed. The inability to map more than one usb controller is almost as annoying. But the Las Vegas terrain still looks surprisingly good after all these years aside from the static low-resolution water. You can really appreciate the jump in technology when you compare USAF's early 3d cockpits with typical DCS World aircraft, but you can also appreciate that the foundations for the current level of graphics/realism were established with Jane's USAF.

If you find a photo showing the rear cockpit with an APX-80 control unit, then you probably have the information you seek. But that should be in every F-4 with IFF rather than just the Combat Tree equipped planes, per the above conversation.

First, I don't think it was ever declassified. So, you probably won't find any detailed descriptions or photos. But then there was this conversation in a forum: http://www.arcforums.com/forums/air/index.php?/topic/199958-looking-for-photos-of-a-combat-tree-f-4-phantom/

The problem with a small interval is correctly filling out the data without errors. It is tedious to fair in all the points compared to the 0.4 Mach interval. But the gains in accuracy in areas of steep transitions is critical. All aircraft have a critical Mach number where the wave drag spike's up. When you are talking transonic/marginally supersonic aircraft, accurately modeling wave drag is critical to accurate performance above Mach 0.75. For aircraft like the MiG-15 and F-86, it will define their top speed. The F-86 has a higher number and is therefore more controllable at speeds the MiG-15 can barely attain and able to attain speeds the MiG-15 cannot. The problems caused by this region are the reason for coke-bottle (area-ruled) fuselages. The specific excess power needed to go supersonic doesn't exist if the aircraft isn't designed to minimize transonic drag and provide decent control/stabilization in that speed range. As for building EM diagrams, my old tool, AIDE, would plot height-mach sustained and instantaneous g curves and easily could have been modified to show specific excess power curves. You just had to weight while it searched for the data minimum and maximum data points over the Mach range for a given altitude and over the complete altitude range. The math isn't really hard, just time a consuming re-iterative process. The first problem is to build a data structure that can be loaded with every possible value in the data ini files, then you have to read in the data ini file and parse it to populate the data structure, then you choose the table/parameters you seek, then the program performs the calculations to balance thrust, drag, lift equations based on the provided parameters, then a plot of the data is displayed. The problem starts with the number of variations that have to be handled when parsing the ini file into a useful data structure. The re-iterative calculations that produced useful performance charts could cause a memory leak, an infinite loop, or just outright CTD or BSOD, so it was important to carefully test and error-trap each subroutine that performed any data object creation/destruction and/or complex calculations. I used to have the time an patience to develop such a tool. Now, I don't want to perform any work, I just want to enjoy the end result and better people than me are providing great flight models for me to enjoy in both DCS World and FSX/P3d. I am far less critical/demanding than I once was because of how well I understand the limitations involved in trying to produce a truly accurate flight model on a PC. I don't expect anything close to perfection, not even a true "1%" error margin. But I have zero tolerance for oversimplification such as the original LOMAC/Flaming Cliffs flight models that made Strike Fighters look like a real NASA engineering program.

I looked at JSBSim when I was evaluating Flight Gear flight models. I think you will find that the numbers will not directly translate between the two flight engines. TK uses extensive tables so that you can plot correct, empirical data. So, if you have a NASA wind tunnel study or better yet a collection of curves/data points from live flight testing, you can usually tweak TK's flight models to match those results. If I recall correctly, JSBSim was much simpler. You start with a core set of numbers and the flight engine estimates all of the other values at various machs/altitudes. I don't recall how JSBSim handles transonic/supersonic mach numbers, but I don't recall being impressed. TK's flight models suffer first and foremost a problem with resolution. The original SFP1 flight models were tabulated in increments of 0.4 Mach. In general, this was adequate from Mach 0.4 to 0.8 and Mach 1.2+ where the curves are fairly linear and flat. If you fed the tables the correct numbers, you could get magical "1%" accurate flight models that seem to be the "gold" standard for flight sims. But a lot of things change quickly at very specific Mach numbers over the Mach 0.8 to 1.2 range. To model transonic fighters like the MiG-15, MiG-17, and F-86 accurately, the interval needs to be Mach 0.05. Even Mach 2 fighters like the F-4, MiG-21, and F-105 benefit from high resolution intervals over the transonic range. If TK's flight models could have been so much more accurate if they had supported varying the resolution as needed instead of a fixed interval between all data points. It is a pain in the butt to develop flight models with the original Mach 0.4 interval, and insufferable to use an interval like Mach 0.1 or smaller. The other problem with TK's flight models is that they can't show interference, such as between the wing and tail. The effectiveness of the tail can be greatly effected at higher AoA by the wing's airflow. The table for the horizontal tail (elevator, stabilator, etc.) is pretty straight forward based on the Mach and/or angle of attack. But the wing can cause the tail to see different speeds and/or angles than the air which originally hit the wing. So you have to choose between tailoring the tail control tables to normal flight conditions such as level flight or to reflect high AoA conditions. The F-100, F-101, F-104, and F-4 are all subject to problems based on this. In my F-4B flight model, I simply ignored the interference effects which combined with the Mach 0.4 table intervals left it quite inaccurate over the transonic range, but still did great at Mach <= 0.8 and ok at Mach >= 1.2.

There are some holes in the flight engine, but overall the SF2 flight engine can produce outstanding results if it is fed accurate data. I was able to get SFP1 to get very close to hitting the numbers for the F-4B over the entire altitude and speed range covered by the charts in the flight manual.

The best way to assess flight models is to know the math behind the flight engine and build a tool that reads the FM ini file and then generates the performance charts you are interested in evaluating. A long-long time ago, before I had a son, I created such a tool for SFP1. It was primitive and used brute force solutions that would light up your cpu for a while, but it worked. At one point, I needed to incorporate some changes to reflect what TK had added in a patch, and a nasty bug appeared in my code that I could never fix. I wanted to build a new tool from scratch that would support SF2, but I doubt I will ever have the time/motivation to do so. The next best thing is to build a spread sheet that allows you to manually solve the same equations my tool solved. It just takes time to build the initial spreadsheet, then go through the iterations of changing the speed (in mach) and/or other related parameters to find the solution to the problem. The only other solution is to fly in debug mode with a zero burn rate for fuel so that the weight doesn't change while you are flying and observing measured parameters.

I bought an MSI GTX 1080 for $470 from NewEgg last spring and want to get another one so my son's PC can run an Oculus Rift. I was astounded to find my exact card going for around $1,200. Maybe I should sell my card and give up gaming for a while, then buy 2 when the prices come back down... if they ever do. This must be heaven for nVidia and AMD since all of their cards with good bitcoin performance have sold out like crazy. I wish a thousand deaths to the digital currency market so that I can afford to keep building decent flight sim PCs.

As a dedicated air-to-air fan, I would have preferred the JA-37. But the AJS-37 has unique advanced systems that are interesting to figure out and employ. While it can be employed as a fighter, it has only a very basic radar search, no tracking, no BVR missiles, just AIM-9s and the option to use gunpods. To truly enjoy this aircraft, you have to fly it on strike or anti-ship sorties. Low altitude passes can be used to accurately lay down retarded bombs. Rockets are very accurate, too. The Mavericks and antiship missiles are fairly easy to employ and have a great chance of hitting if aimed properly before firing. It is absolutely amazing to have a sim where you can fire and control a command guidance air-to-surface missile. The training, instant action, and regular missions give you plenty of opportunities to try all of these systems out. I like it so much that I may buy the AJS-37 Red Flag campaign.

These websites provide perspective on what it takes to avoid an "egg": http://www.krepelka.com/fsweb/learningcenter/advancedflyingskills/aerobatics.htm http://www.chegg.com/homework-help/questions-and-answers/illustration-shows-airplane-loop-fairly-low-speed-son-pilot-air-force-loops-500-mph-jet-pr-q10996085 http://www.planeandpilotmag.com/article/loop/#.WmgD6lUrJhE http://www.hooked-on-rc-airplanes.com/aerobatic-maneuvers.html

Imagine that air is a fluid like water. Now imagine that in water, your radius of turn is determined by the position of your rudder regardless of speed. If gravity didn't interfere, you held the stick back at a fixed angle, and you didn't stall before making it past the top of the loop, you would in theory make a perfect circle in spite of the speed changes. In reality, air is a little more "slippery" than water and a lot more than a car turning a circle with a fixed steering wheel position, but the principles is essentially the same. Somewhere online there must be a video of a stunt plane performing a perfect circular loop with both an outside view and a cockpit view so you can see how the pilot moves the controls to hold the circle. Before high thrust:weight ratio fighters, you simply dived to build up enough speed to hold the circle before stalling. You will find that competition pilots use a combination of a visual reference and seat of the pants feeling to maintain a constant force/perfect circle. It does take practice to very the stick pressure at the right rate to hold the circle.

It is possible to see the g load at the top of the screen via the debug mode. I don't know what is/isn't possible with modding the normal on screen data since I rarely used it and never modded it.

Was the original question how to turn using a g-meter? Traditionally when using the word "turn", this implies a flat turn. So more important than the g meter is the rate of climb indicator. For a given speed and g-indication, you have to maintain a certain bank as described above. But you don't need a g-meter at all to perform a level turn. Bank as desired and pull back on the stick just enough to hold the rate of climb to zero. As long as the rate of climb is zero and the angle of bank is constant, the indicated g must remain constant as determined by the angle of bank as discussed above. This has a nice graph of bank vs g load: http://avstop.com/AC/FlightTraingHandbook/loadfactorsinsteepturns.html

This pdf has an excellent section describing radial g and shows the vector geometry that takes into account lift and gravity to determine the resulting radial g: http://www.flightlab.net/Flightlab.net/Download_Course_Notes_files/8_Maneuvering.pdf In a flat circle, the radial g is parallel to the ground, and therefore perpendicular to gravity. So you wouldn't think gravity would have anything to do with radial g, but it does! Since the aircraft has to maintain 1 g parallel to gravity to keep the circle flat (no altitude change), the aircraft must bank at a certain angle to split its lift vector between holding altitude and providing radial g. This presents a problem when analyzing aircraft performance: If someone says an aircraft can sustain a 9g turn, is it 9gs of force on the wing or 9gs of radial g? Generally, when they say a 9g turn, I would expect that to be indicated g, so the actual turn is the radial g of a triangle using the Pythagorean theorem (c^2 = a^2 + b^2) where the indicated g is the long side of the triangle. So for level turns, the actual radial g used to determine the turn radius and turn rate (deg/sec) is: square root ( (indicated g)^2 - gravity (1g) ). For 9g, the radial g is: (9^2 - 1^2)^0.5 = (81 - 1)^0.5 = 8.94. If we choose (or observe) the indicated g and we know the turn is flat, there is a unique angle of bank that satisfies this condition that can be solved for using trigonometry. The trivial solution is at 1g, your bank must be zero degrees to fly level, so your radial g is 0 giving you a turn rate of 0 and an infinite turn radius. At the same time, it is impossible to fly a level turn at 90 degrees of bank because 100% of the lift vector is going into the turn leaving no lift to provide 1g to maintain altitude. But for 9g, the angle of bank = arcos (1g/9g) = 83.6 degrees, which is pretty darn close to 90 degrees when you are in the cockpit.

I don't understand the original question of "how do you turn on the g-meter". In the sim, it is always on. In real life, it will be one of the loads on a circuit breaker switch. The accelerometer always shows you the actual load on the aircraft, so in level flight you will see 1 g. But the 1 g of lift is canceled out by the 1 g of the earth, so you fly level instead of pitching up in a 1 g loop. So if you pull 2 g per the meter, you will start pitching up in a 1 g loop, but as you approach 90 degrees, gravity is aligned with the drag vector and perpendicular to the lift vector. At that point you will be pitching in a 2 g loop if you can still maintain 2 g while climbing vertically. At the top of the loop, if your meter still indicates 2 g, gravity will now add performance, pulling you into a 3 g loop. The 2 g you see through the entire loop is what is indicated on your instrument. Its purpose is to show the load on the wings so that you don't break them. Radial g is the actual acceleration parallel to the lift vector that acts on the radius of the turn or loop. You must use trigonometry to solve determine the radial g taking into account the angle between the lift vector and the pull of gravity. Radial g determines the actual radius of the turn. So, holding constant indicated g through a loop produces the egg in the diagram. You need to hold constant radial g to make a true circle.

The input and output forum and its home cockpit sub forums are the places you want to be: https://forums.eagle.ru/forumdisplay.php?f=96

To the best of my knowledge, DCS does not inherently recognize any USB gauges. What DCS does do is allow exporting of its parameters so that they can be accessed by other devices including software supporting gauges. To get precise and accurate information on how to integrate external systems with DCS, you need to see the appropriate forum on Eagle Dynamics' home page. There are some serious experts with home cockpit building that can answer just about any question you may have.