Cake

Also, did you shutdown prior to the repair? Some repairs won’t get done unless you shutdown engines first.... not sure all the rules, they seem to be different for different airplanes...

I’d like to see the 430 in the F5. Be nice to have some additional navigation capability for flights taking place after 1998.

First time I’ve seen slower than 45 fps continuously was late in a MP session today with 342. Strange thing was, I closed teamspeak and it went back to normal

I went through the provided training missions and found the same short result as you with bombs, but the rockets seemed spot on for me.

Great info.... thanks So, in the pattern you are flying airspeed? Can you say more about what you do when you bolter? Is it always thrust levers full forward, and then ?

Custard Layer :) To answer your question in it’s simple form, less dense air will result in a lower differential pressure between the pitot tube and the static ports (and hence lower IAS) for the same true airspeed as pressure altitude increases. Some things on airspeed you might want to know,based on your question. Thanks Ironhand :) The definitions I use are: TAS is the actual speed at which the airplane moves through the airmass that surrounds it. IAS is the speed observed on the air speed indicator. Just to be clear..... The airspeed indicator utilizes the difference between pressure measured at the pitot tube and the static port(s) to measure airspeed. This airspeed indicator is designed around a sea level standard atmosphere. The airspeed indicator is subject to instrument and position errors. If you could correct for these errors you’d have CAS, which stands for CALIBRATED airspeed. Another way to define TAS is as CAS corrected for nonstandard temperature and pressure. So as you go higher and the air is less dense, you will actually have a higher TAS than CAS, which IAS tries to display. CAS = TAS at sea level in a standard atmosphere. Just to complicate things, in high speed airplanes, you also correct CAS for adiabatic compression flow. So when you get high and fast, air is compressed at the pitot tube giving false readings. If you correct CAS for this compressibility then you get EAS, which is called equivalent airspeed. If you really want to get deeper into this kind of thing get yourself a copy of “Aerodynamics for Naval Aviators”

I’ll second that you make sure assistance is zero. For the life of me I couldn’t take off in the Mustang with the default assistance set at full. It wasn’t until I read somewhere this was an issue that I could get the mustang to do what I wanted it to..... not that it isn’t still pretty ugly :)

This has been the best thread I've read on here for sometime. Lots of good input from all sorts of experts. One of the best things I learned on this subject was from a test pilot who had experience in a couple hundred aircraft types (mostly military) in over 50 years of flying. His way of teaching was basically like this: ATTITUDE + POWER + CONFIGURATION = PERFORMANCE So, for most flying, pitch attitude would be measured in degrees, while power could be measured in different units based on the type of engine. Piston powered engines would be either RPM (fixed pitch prop), MP (constant speed prop), or % power. Turboprops might be measured in TQ. Jets might be measured by EPR, N1, etc. Configuration would refer to the position of the secondary flight controls, landing gear, etc. The idea is that for each segment of flight (climb, cruise climb, cruise, cruise decent, initial level approach, final precision and non precision approach, MDA level off, and missed approach) there is a specific pitch attitude, power, and configuration that should be known to the pilot as a starting point. So, I've heard people arguing about whether they should add back pressure or release it when going around or going missed. This shouldn't be the focus. The focus should be to initially set the attitude, power, and configuration of the airplane to what the pilot knows in advance will approximate the desired perfomance (using the specific procedure in the flight manual), and then make adjustment to these settings based on the actual performance as measured by looking outside and/or scanning the flight instruments. So, while it is generally true in a 172 that forward stick pressure may be required initially on the go around or missed, what is important is A+P+C. Imagine the airplane is grossly out of trim on approach and was being flown with excessive backward stick pressure, or something else is wrong? Is it still correct to push forward? What matters is the correct attitude power and configuration. If you have a TOGA button, you press it and pitch to the command bars. Push forward, pull back, whatever is necessary. APC=P is among the first things I'd teach to an instrument student. I'd have them make a table for each flight segment. We'd fill out the parts we could using the handbook and then figure out the rest using their own airplanes. Over the years I've found it useful to create a APC=P cheat sheet for the different airplanes I fly. Looking forward to making one for the Hornet, and considering that I'll be using AoA instead of degrees for pitch. It strikes me that airspeed hasn't been mentioned much in this discussion, but there must be a range from maximum carrier landing weight on down, given the specific angle of attack is a constant (correct assumption?). Would it follow the convention Vcarrier landing = Vcarrier landing @ max weight * SQRT (current landing weight / max landing weight). Just curious if the math from AfNA holds up. Is this something the crew has to figure out to set up the arresting cables? Obviously, if the aircraft is heavier, it must in fact also be flying at a higher speed for the same glide path at the same angle of attack. Seems like huge potential differences in kinetic energy for a heavy Hornet vs a light one.

I think DCS needs to rethink how they display other aircraft at distance. This should not be determined by the resolution of the monitor or VR device, but rather by what would be detectable by a typical human fighter pilot eye. For me, the Rift gives a compelling experience and I have found things like low level, refueling and formation flying to be much improved through VR. On the other hand, the distance at which airplane can be visually acquired is way too low. I know IRL, with less than fighter pilot eyesight I can spot an F15 at 8-9 miles, and of course this depends upon its orientation from my perspective. With the Rift, it isn't even close to IRL. This is with pretty optimized settings on a 1080ti. I have heard many simmers say they love VR, but it’s just not competitive with monitors for spotting aircraft and results in a huge competitive disadvantage. Aside from VR, there shouldn’t be andvantage given to someone with a 4K monitor over 1080p..... at least there was a good solution for this way back in Falcon 4.0... so it would seem it is possible for ED to come out with a solution that makes visual acquisition of aircraft occur at same distances regardless of the display device, so that simmers with 1080p vs 4K or VR with various hardware (not everyone has 1080+ hardware for VR) are on a level playing field. I’m not big on zooming. Maybe inside the cockpit to read a small gauge or indicator, but zooming outside ruins the experience. I’d favor a solution where you can put something near the center of your vision and the sim would provide some details on it through some type of triggerable dynamic label based on what you should be able to tell from that distance had you not been limited by your display device.

So, with 2.5 we’re still in the dark ages on this subject. ATIS or AWOS/ASOS as appropriate. yes we still need this and it should clearly represent the region. The elements included in the ATIS obviously depend on condition, but some things currently in the sim are just wrong. For example, in Nevada, ATIS would give wind speed in magnetic heading and knots NOT m/s. Altimeter should be given in QNH, NOT QFE. Seems to me that a simple start would be to use the correct units for the region. The old suggestions in this thread are great. Obviously you could tune the frequency and listen before calling ground. I think a good option would even with the menu system would be to. Check in with ground. Even using the menu, a check in with ground could automatically read your flight number, type, location, ATIS letter, etc. Ground could then issue you taxi instructions, and then you could choose to accept them.... in which case they would read it back, or add to your request, an alternate runway, progressive, cancel taxi, etc. Ground will hand you off to tower as appropriate, or you can contact them, and indicate your readiness to depart. Tower should either tell you to hold short, line up and wait, or give you a takeoff clearance. Same idea landing clearances. They’d give you a clearance and you could accept or make a request. Requests could include, a specific runway, a specific pattern (e.g., request tactical 360 overhead), emergency priority, etc. Some logic for organizing approaching aircraft would be great. Controllers would be familiar with all of these aircraft types and should be able to assign vectors and speeds for separation. This has so much potential.

Agreed. Normally, its much easier at night to spot an ac with nav and anti-collision than during the day. Here, you can see an airplane’s shape during late twilight before it’s lights. Should probably be able to see the lights first. Overall, the distance at which lights on all objects can be seen needs major attention. I think depending on the type of light, you hould be able to see, say an aircraft landing light, at distances far beyond where you could spot the entire aircraft during the day. For a stobe, maybe an individual strobing white pixel should appear before the corresponding red or green nav light, and certainly the white on an airport beacon should be visible a little before its corresponding green. Please give this some love.

Checked this. No rotating beacon for example at Anapa. No runway edge lights. Taxi lights are illuminated, but can only be seen from very short distances, like when you are below a few hundred feat when landing. Even when they can be seen they are unrealistically dim.

It’s really a shame, with such a small community relative to other peripherals, the prices are high anyway, so a little more for quality components is important. I’m sure many of these devices are sold based on recommendations in places like here.... so selling junk is a bad idea for a company in this market.

On another note, I think we are quickly approaching the point where 500gb is a minimum SSD size for single drive systems and 1Tb will be recommended build for the future, particularly if the terrain upgrades start rolling in and you want to run things other than DCS. I’d rather be in a situation where I CAN update video rather than NEED to update the SSD. I know this pushes the price a little, but I really liked the early pcpartpicker recomendation by Gladman otherwise: https://ca.pcpartpicker.com/list/NvW2QV

Yes, thanks. This is exactly my point. Not a problem below the flight levels using QNH, but QFE is a problem, and I'm sure that's why they don't do it in the states. Another example of two nearby airports is Boise (KBOI) and McCall ID (KMYL). It's just a short 80 nm hop between Boise (2871.4 ft. / 875.2 m) and MCall (5024.2 ft. / 1531 m). Salt Lake City Center handles MYL and BOI, but BOI is also handled by Big Sky Approach. Using QNH, the setting betwwen the two will most likely differ, but not usually enough to cause a problem Let's say we use QFE. If two jets are flying between the two airports in opposite directions they are likely less than 10 minutes apart. Say the aircraft leaving BOI is using BOI QFE and indicating 10,000 ft. Assuming ISA, true altitude would be about 12,900 ft. An aircraft leaving MYL using QFE and indicating 8,000 ft would be at approximately the same true altitude. See the problem? Also, MSA is probably something like 11,000ft MSL in between them. Talk about confusing. Now imagine a lost comms situation, aircraft to aircraft communication, or inexperienced pilots using the wrong settings for an approach, or a diversion after a missed approach. I think the QFE system is WAY less safe. I understand it is used in places, but just to have the field indicate zero????? As far as DCS is concerned, I think we should be getting the way it is done in the local we are flying. I also think think there should be options to: Respond to the radio checkin with (a) the altimeter given or (b) a QNH request if appropriate. Furthermore, I think the act of responding through the DCS comms menu should also set the aircraft altimeter(s) accordingly.

Thanks for that... So, when you say ATC, are you talking the tower, approach, or what? Just curious because if you have two airfields at different elevation nearby, and aircraft all using QFE going into each are talking to the same controller, this could be a great source of confusion and could lead to worse. If we’re just talking about traffic for one airport, fine, but otherwise it’s a bad idea all around. It’s also confusing to think some airplanes will be using QNH and others QFE. More potential for misunderstandings.

Ive never seen QFE used in North America. When you get the altitude using F10, what is it, true, indicated, pressure, or denisty altitude? Without ever paying attention, I was kind of thinking it must be true altitude. If this is the case, referencing it to set the altimeter is a bad idea at altitude, because it is not safe to assume standard temperature and you will get errors magnified down low where accuracy is even more critical. Using normal settings on the altimeter, if it’s colder than standard, pressure levels are more tightly packed, so your true altitude will be less than indicated altitude. This is why approaches sometimes require cold weather correction. I’m with you on most of this, and Especially on your recomendation not to use QFE. My preference would be to stick with the western convention for local altimeter and pressure altitude afte climbing above the transition level.

Awesome!!!!

Cool. Thanks.

I had already searched all one-hundred and eighty-five pages of that thread for “ovgme” before posing this question and there was not a single mention. I’m new to mods, so forgive my ignorance, but I was advised that all mods should be installed with a module manager so the install can be restored back and forth to “stock” before updating. Really, it isn’t clear if that is even technically a mod to me..... that’s why I am asking. If it doesn’t install with a mod manager that would be good to know, because obviously it would be simple enough to follow the directions in the thread, so a little more guidance would be appreciated. Thanks.

Should SimpleRadioStandalone be installed like a MOD using OVGME? I've found the guidance for a normal installation, but can't find any info on this...

Well, not necessarily assuming this, but I would assume there should be some logic as to how aircraft spawn on the ship, move to the catapults, and what happens after you land and need to park, for both player controlled and AI aircraft. I guess it makes sense this should apply to any aircraft type that could operate from the carriers.

While the full fidelity models are great, I think there is still a case for doing more FC level airplanes with advanced flight models if the right data are available. Many of the full fidelity tasks are unrealistically cumbersome in a clickable cockpit (e.g. tuning radios, which is super easy in a real airplane but a PITA with a mouse) so sometimes the FC planes are just fun to jump into. I’m also of the opinion that any additional aircraft we can get into the sim, whether it be a fighter, bomber, attack, transport, civilian aircraft, whatever is a good thing, provided it is done to a certain standard. It can be up to the mission designers which ac to put in missions and servers. On a related note, the lack of new AI only aircraft is a little disappointing. Frankly, coming foreword two decades from the original Su27 software, it’s a shame that more of the world’s aircraft haven’t been included.

Haha, oops. That’s what I get for not doing a thorough instrument, I mean thread, scan.

My ASUS Z170 Premium shares the m.2 slot with SATA ports ( I’m on the road, so I can’t look up the actual info ), so when I first tried to install my 960EVO it wasn’t recognized. I moved my existing 840 SATA drive to one of the non conflicting ports, the 960evo was recognized. I’m thinking if you have a SATA drive plugged into those specific ports, you need to move it to remove the conflict with your new m.2 drive. Could that be the problem for you?