norman99

I’ve noticed extremely long refuel rates (as in 100lbs per 30-60 secs) on the right hose only, using the KC-135. The lights on the refuelling hose pod are also not working on the right side, so maybe this is an indication of a general bug with this side? The left hose always seems to refuel at a normal rate. I also noted some abnormal behaviour after disconnecting. This was all present pre v2.7 so it may or may not be the same issue you are experiencing.

In one word, Yes.

So far this is the only way to make it possible, and truthfully, I don’t see that changing. This method has it’s issues if considered for a persistent public server (blocking CATs & fouled landing deck etc), but for single mission oriented private/squad servers, you could literally spawn 30+ aircraft with no problems at all.

When it comes to storage, always buy more than you need. There’s nothing worse than getting a small drive to ‘save some money’ only to need another 12 months later. These days 500Gb is simply no where near enough. My laptop already had 256Gb & 1Tb drives, but they were getting full, so I bit the bullet and bought a 2TB Samsung Evo last year (I’m lucky it has space for 3 drives). Best decision I could make.

And most commercial/airline pilots too. No more paper charts or approaches plates in cockpits of any sorts these days, just a few iPads.

I'm curious where you got this information from.... The Navy simply being unaware of a basic feature of there own jet is something I struggle to believe.

Just to rule out the obvious, make sure you have tuned the correct radio frequency of the carrier. Even if you select the carrier in the comms menu, if you are still tuned to a ground tower frequency, that's who you will be calling. Otherwise, I'm not to sure. I've never experienced this myself.

The simple answer is "because that's all the real aircraft can do". Remember, ED are not designing a new navigation system themselves, they're simply recreating the systems of a real aircraft. I'm not sure of the Hornet specifics, but most aircraft have systems that are designed to intercept a course with a set/max intercept angle. Something in the 30°-60° range would be normal. Distance doesn't usually enter the equation. If it's vitally important to be on track for a set distance, than simply create an additional waypoint where needed.

This might be a slight tangent, but are military aircraft, and fighters in particular, required to meet similar balanced field performance requirements as civil aircraft when getting certified? (ie the ability to both continue airborne, and stop on the remaining runway, with an engine failure at V1)

I'm guessing landing performance simply wasn't a concerning factor in the F/A-18s design, as it would either be operating from the carrier, or on shore from 5-10,000ft+ runways. NAS Lemore,the home base for all pacific fleet navy squadrons has 2 x 13,500ft runways, basically just for hornets. Also remember, civilian aircraft have wing spoilers to immediately dump the remaining lift from the wings, significantly increasing the weight on wheels and breaking effectiveness. Not to mention thrust reverse. The hornet obviously has neither, so it's braking performance is understandably average. P.S. Out of curiosity, which civil aircraft are you talking about (A320, B737)?

Thanks, exactly what I was looking for. I'll add my thoughts to that discussion.

Great discussion. My hunch is that DCS has basically been "fudging" correct altimetry for some time. Seems the underlying code all uses "DCS true" altitude, and only in some specific cases, such as player/client aircraft altimeters, does it appear as though any additional pressure correction is able to be applied. I guess 10+ years ago, when the entire ecosystem was no where near as complex or realistic as it is now, this wasn't really noticeable. Unfortunately with the plethora of additional data sources and emphasis on realism that DCS has today, it is starting to become a notable issue. All aircraft. Including AI, should have the ability to correct their altimeter for changes in pressure, and all systems that use altitude as an input such as radar, datalink etc, should be using this corrected figure. Unfortunately, I picture this as a hugely complex issue to solve though and almost certainly exists well beyond the F/A-18 alone.. The weather system, AI logic, and individual avionics of almost every aircraft in the game would need to be updated. Not to mention procedures and education on altimeter SOPs. A lot of people incorrectly apply civil procedures to a military/combat operations, when it simply doesn't make any sense to use a transition layer in a combat environment. It’s not like I’m going to change my altimeter as I dive from 20k to 10k whilst dropping Mk83s. It's normally keep simple with one (or two if there’s a significant difference) theater wide QNHs. This is sufficient to provide air to air separation as everyone is on the same setting. Almost all combat aircraft have a rad alt, so terrain separation can be ensured that way, even if the theater QNH is slightly different to the the actual, current location pressure. As an example, the entire NTTR uses Nellis QNH, at al altitudes. Local QNH around the airfield/carrier is the only other setting you need. As I sad, this is a tough one for ED. There is most likely so much code, both new and old built on top of the original "true alt' concept, that it would be a massive task to change this effectively.

I have a question regarding the A/A radar modes of the Hornet. Are the altitudes given, (both TDC scan range, & contact alt) referencing the current aircraft's altimeter setting? For instance, I have a mission in Nevada with custom weather. QNH on the ground at Nellis is 30.15. Unfortunately as the AI doesn't adjust their altimeter's for pressure changes, (they fly an "absolute true" altitude so to speak), the tanker in the mission that should be at 20,000ft, is actually flying at 19,000ft indicated altitude. When locked with the radar however, it indicates an altitude of 20,000, despite my aircraft's altimeter being corrected for the QNH, and indicating 19,000ft. Is this correct? Are the altitudes on the radar "magically" correct, regardless of air pressure (ie, it uses the same "absolute true" altitude that AI use?) How does the real radar function? Does it receive "corrected" (ie adjusted by the altimeter setting) altitude from the aircraft's altimeter?

Strangely enough, my number one wish with a future DCS 3.0 is that they actually charge me for it! Not a subscription, just a one off $50-80 purchase. The problem with the DCS economic model at the moment is all the outdated areas that desperately need attention, such as AI, ATC, comms weather, mission planning, etc etc, are part of the “free” DCS world, and hence provide limited to zero return on investment. Whilst improvements are on the way in all these areas, the reason some take decades to become reality is simply because resources need to go to revenue generating modules first. Personally, I’d love to see a 2-5 year release cycle for the base DCS, charging me once each time. If the majority of users upgrade with each new version, it would instantly become their biggest earner, and therefore rightfully receive the appropriate resources required to continually enhance the core sim at a much faster pace.

Maybe the aircraft hasn't met the ID criteria to be classified as a bandit yet. Did you try the "engage bogey" command instead?

Looks like @Harker beat me to it re uploading a track. Thanks mate.

Sorry I couldn’t supply one this time but it’s 100% repeatable, so I’ll set one up shortly.

Also, unfortunately the way the MIDS system works (or at least, is currently modelled, which is apparently correct), even using the UFC D/L button to turn off datalink doesn’t really work, as it’s tied to the TACN as well. Basically both need to be off to disable DL.

Not sure if this is how it's meant to operate or a bug, but I have experienced the following behavior. If the current time is prior to midnight zulu, (such as 23:50:00z), and you set a time on target for a future waypoint that is beyond midnight zulu (such as 00:05:00z), it requires the time to be incorrectly entered as 24:05:00z for the system to give correct speed indications. However, once the actual time passes 00:00:00z, this become invalid, and no longer provides correct speed indications. The time on target then needs to be changes from 24:05:00 to 00:05:00 to work correctly. NATOPS paragraph 24.2.5.3 states valid TOT inputs as 00:00:00 to 23:59:59, so my guess is this is a bug simply due to the calculations not continuing smoothly through midnight zulu. It therefore thinks 00:05:00 is actually in the past up until 23:59:59, hence the need to use 24:05:00 instead, until the actual time has passed midnight. A lot of number in my explanation, but I hope that makes sense.

Nice ! Unless flying as a single, you can simulate the correct procedures quite well. 1. First get your flight in a close group & echelon left formation, and call inbound to the tanker. 2. Then approach the right basket and set up in pre-contact position. Do not make a ready pre-contact call to the tanker yet. 3. Now importantly, give wingman 2 only, the "go to tanker command". He'll be behind the left basket already, and hook up almost immediately. 4. After calling wingman 2, make your ready pre-contact call to the tanker (no need to wait for 2 to actually hook up, he's already assigned the left basket on you call to him). Connect yourself and start taking fuel. 5. Give a "go to tanker" to the flight as a whole to send 3 & 4 into the tanker queue. I think you can do this before you hook up, but it has to be after your pre-contact call (which reserves the right basket for yourself). I usually just wait till I'm taking fuel anyway to ensure 3 or 4 doesn't get inpatient and try and steel my hose. 6. Lastly, whilst both yourself and number 2 are taking fuel, give an echelon right formation command to your flight. This will make them form up on your starboard side after refueling. One word of caution, aircraft disconnecting and returning to formation, the AI can do all sorts of weird and unpredictable maneuvers, often leading to mid-air collisions. The best position to avoid this is slightly high and forward, almost abeam the tankers tail. This will ensure they reform by moving aft and beneath you.

Correct. Right side for number 1. even if joining up with the tanker as a single ship only. NATO Allied Air-to-Air Refueling Procedures Manual is available online from a number of sources. Just search for ATP-3.3.4.2

Just have to pick up on one small point here. This is absolutely not the correct way to configure an airliner for any landing, let alone a CAT III approach. CAT III can be a zero visibility landing, depending on operator/equipment, so logically leaving final flap selection until 'assured of landing' is impossible. All aircraft/operators have stabilised approach criteria, usually meaning landing config, speed & checklists complete by a certain point. In IMC, this is commonly 1,000ft agl. If you are not fully configured, or haven't completed the landing checklist by this point, a missed approach is mandatory. Obviously this is all for civilian LVO (low visibility operations), and as mentioned above, completely different to US Navy CASE III recovery procedures.

Even if we did get the NiteHawk, which version should it be? The original, no target designator/ranger/LST? The A model, which added self designation, or the B, which added LST? If it's either of the first two, you'd really need the ASQ-173 LST pod modeled as well. There's probably just as many different opinions on this as there are the current pods.

Ahh, that explains it. Thanks. Still, it’s a shame it couldn’t be released as a static model first, until the relevant tech allows for more. Combined with some nice placeable berms/revetment models (desperately needed in my opinion), you’d really be able to fill out a fixed SAM site nicely with this.

One of my interests is recreating realistic SAM sites, and in my browsing I stumbled across some photos of a DCS SA-2 missile transporter model. This was from an Aprill 2018 newsletter. https://www.digitalcombatsimulator.com/en/newsletters/newsletter20042018-db94994c1740e9d799ea62b7f07e4d1a.html I went looking for the model, initially in the mission editor, and then just digging around the DCS files, but couldn't find it. Seems it never made it to release. My question is why? Obviously someone put a lot of time and effort into the model, as it looks fantastic, and it seems sad for that to go to waste. Being a simple transporter, I don't imaging there's really any additional functionality required of it either. (I'm thinking as a static/AI only model, not any Combined Arms functionality.) Obviously not a high priority in any way shape or form, but the images made me curious non the less.