streakeagle

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.

Absolutely. The Game Loops increasing is a response to low fps, not caused by it. The game won't work right if the game loops too slow. It messes up the flight model and AI. So when the fps gets too low or when there is extra cpu processing power available, the game automatically runs its loops faster.

Game loops do not lower fps, on the contrary, when the fps get low and the cpu is underutilized, the game loops more frequently.

Prior to Wings Over Vietnam, Gephard had released the DRV (Demorcratic Republic of Vietnam) terrain for SFP1. ArmourDave had already released an F-105D for SFP1 was working on releasing a major base... when TK blindsided everyone with the release of Wings Over Vietnam. ArmourDave had invested so much time and effort into making a proper Vietnam expansion for SFP1 that he got very angry at TK for stealing his thunder with this surprise release. ArmourDave, who had done so much for SFP1, completely left the SFP1/WoX community after this happened. WoV's big change beyond the new terrain was adding in carriers and basic carrier operations. But TK's view system with its stock head positions were optimized for allowing the virtual pilot to see the control panel which made carrier landings quite difficult since you couldn't see over the nose with the view position so low if you were on glide slope at the correct AoA and speed. This problem was further complicated by the lack of ILS support for carrier landings. Overall the plane set was outstanding, greatly expanding the number of flyable and AI aircraft compared to SFP1. Besides the F-105, the F-8 was the big win, plus a half finished A-6 could be flown by the player. Unfortunately, like nearly every patch or release in the SFP1/WoV series, the gains were partially canceled out by bugs. The AI pilots went stupid compared to the very lethal SFP1 Service Pack 2a enemy pilots. But the worst problem was issues with the flight engine. Transonic flight behavior was broken bad. So WoV went through some quick patches to get rid of the worst bugs. However, the dumb AI pilots would remain until Wings Over Israel was released years later, a precursor to another surprise release: SF2.

I had none of their games starting with Rise of Flight. But having an Oculus Rift and knowing that BOM/BOS supports VR as well or better than any other flight sim, I bought Deluxe BOM and Deluxe BOS from the website. I almost bought the Steam Version, but only the first game was available as a "Deluxe" package. Up to now, Aces High 3 has been my best VR combat flight sim. But after trying BOM/BOS last night, I would say that BOM/BOS is at least the equal of AH3 in VR implementation and it is a generation or two ahead in graphics. This series is clearly positioning itself to truly replace the original IL-2 series as the dominant WW2 combat flight sim.