norman99

When descending using the FPAS calculated optimum descent, the end point is calculated correctly when a waypoint is the reference, but incorrectly when a TACAN is the reference. As it displays the distance a descent should be commenced for your given altitude, if you keep the FPAs calculated number and your actual distance the same, you can fly and monitor the descent all the way down. When using a waypoint, this works well, as shown below. @30nm @20nm @9nm @2nm (slight error is due to getting a little low compared with the profile) When using a TACAN as the reference, the descent is not calculated correctly. As you can see below. @30nm @20nm @10nm @5nm @2nm @1nm As you can see, the TACAN reference leaves you about 5,000ft too high. To illustrate more clearly, this is the two descent profiles compared: Distance - Waypoint Alt - TACAN ALT 30nm ~30K ~33.5K 20nm ~20K ~23.5K 10nm ~10K ~14.7K 5nm ~5k ~10K 2nm ~1.5k ~7K Secondly, the standard descent profile is, use idle power and descend at cruise Mach until 250kts, than 250kts onwards. ie M0.83-->250kts. This roughly correlates into a 2-to-1 descent profile for every 1,000ft, give or take 5nm. Eg, 20,000ft requires ~40nm to descend, 30,000ft 60nm etc. As you can see, this is almost double the distance calculated by FPAS when referencing a waypoint, and even more incorrect when referencing a TACAN. I believe that FPAS descent figures are incorrect, and result in an overly steep descent. They also calculate the wrong final altitude when referencing a TACAN.

Is the GBU-24 considered “complete” now? After some trials, it seems to be tracking the laser correctly (which was a previous bug), but I’m not impressed with it’s low altitude range. Even when lofting, running in at +550kts with a 3-4g pull-up to ~30° It only has a range of a couple miles. I’d expect much further easily +5nm. Is it still WIP? Also, slightly off topic, how should the aircraft manoeuvre to maintain TGP LOS after release, without presenting a nice easy target? Currently I break right (Hornet with TGP on left chin station) 45° off run in heading, and 5° nose low. This just maintains the laser designation, although I do feel extremely exposed descending slowly at around 2,000ft agl. Any tips?

Yeah, the Hornet radar is very sketchy at the moment. Things like poor/incorrect STT range, completely unrealistic interpretation of look down that significantly nurfs detection range, and more, all need some serious improvement. And this is without even considering MSI and the work needed to improve this capability.

That’s a great explanation @Beamscanner, thanks for taking the time taken to write it.

Happens from time to time. On another note, if you disconnect early by accident, there’s no need to make any radio calls, just reconnect again. As long as the hose remains out, no additional actions are required.

In the cockpit, this doesn’t exist. Time is displayed as local or Zulu only. Liberation waypoint TOTs really should be to changed to one of the two above formats. Of the two, zulu is the most useful as is the only format accepted for input into the Hornet for TOT indications.

This has probably been requested many times before, but we really need the ability to message a single unit via script in DCS. Currently we have message to group, menu to group, picture to group, sound to group, but nothing to a unit. There’s many, many scripts that could use this instead of the current group method, Moose AirBoss is just one example. In multiplayer it only works correctly with each client in a separate group. Unfortunately for the Hornet, that means choosing between AirBoss functionality, or enhanced lead/wingman datalink (A, B, C, D) which is based on flight groups, rather than set in cockpit via MIDS.

Personally, it felt like it was related to the carrier changing heading. For the 10-20 seconds before I launched, once the carrier was tracking straight, it was smooth.

@nighthawk2174 I agree. My understanding is that for all intensive purposes, they should have the same range. Especially because to first detect a contact, you have to start in a scan mode, and hence you can then STT the contact immediately. My example of STT having a greater range is more based on the theory, and a specific case of obtaining an STT and then the contact range subsequently increasing.

@BIGNEWY Can you please investigate this further . The logic behind reducing STT range compared to the detection range when in a scan mode, doesn’t correspond with any normal radar theory. It doesn’t make sense that I can track a contact in RWS/TWS, (including the ability to designate L&S and employ weapons,) whilst spreading the radar scan out across a large piece of sky, yet once the radar is focused onto one specific point, I can no longer track the same contact. Theoretically, STT should yield longer tracking ranges than scan modes for this exact reason, not shorter. If a STT’d contact turns cold and range subsequently starts increasing, it should be possible to maintain the STT lock beyond the RWS/TWS detection ranges, again, as all of the available radar energy is being used to track the contact. This issue, combined with the below bug that clears the trackfile memory completely if the STT is dropped, makes STT almost impossible to use. I know this is marked ‘correct as is’ but surely this warrants some further investigation?

Even in a combat theatre such as Iraq, Afghanistan, Syria etc?

For civil aviation you are correct. Transition level/altitude is where you set 29.92/1013. For combat operations in theatre, this is not the case. Use the altimeter setting provided in the brief. You’re no exactly going to be changing your altimeter halfway through a surface attack, as you dive through 10k. Whether a single altimeter setting is applied theatre wide depends on the situation, geographic area, current weather etc. Sometimes the theatre may be split into 2 or 3 different areas if it’s more appropriate. As long as everyone in the briefed area is on the same setting, altitude separation can be assured. As an example, the NTTR exclusively uses Nellis QNH at all levels. Local QNH would only be used for takeoff/landing and possibly low level CAS type operations where JTACs can provide the QNH. But that’s digressing… There is definitely a bug with the warning as air pressure is irrelevant, it’s internal fuel tank pressure that the warning is referencing. Note this isn’t fuel pressure, but the pressure of the air that is fed into the fuel tank from the engine bleed air, as the fuel quantity reduces. This pressurised air is what helps maintain fuel pressure regardless of the attitude flown or the Gs pulled.

Yes, this includes turning the HMD off.

There’s also a certain SuperHornet available for a particular civil flight sim that has a more complete MSI simulation than what ED currently delivers. After 8 years, ITAR hasn’t seemed to cause them to many problems….

My understanding is you can designate an off board track from the ATTK RDR, AZ/EL or SA page, as L&S (and possibly DT2?) but still require an onboard radar track to launch an AIM120. One of the benefits of this is that TWS AUTO will center the radar scan on the off board L&S, so your time to acquire a radar track should be minimised. I’m pretty sure launching weapons entirely at off board tracks only is F35 level stuff.

When I first started to really learn AAR (granted that was in BMS) the number one thing that helped me was turning the HUD off. It sounds counter intuitive, but I was subconsciously chasing the vv, airspeed and altitude numbers in the HUD, rather than looking outside. With the HUD off, it forces you to start visually identifying trends, forwards/backwards, up/down etc, and then anticipating them. You start getting ahead of the aircraft rather than simply reacting.

Bankler’s, numbers are good. You don’t want to be exactly on the GS at the 90, you need to be above it, otherwise you’re actually low. At the 90 you still have about 0.6nm cross track to fly before intercepting the final bearing, hence your actual track miles to fly will be further then if you flew directly to the ramp from the 90, which is what the GS needle is effectively referencing. If you’re always on the GS at the 90, what you’ll probably find is you are likely flying slightly low and level or a shallow descending base turn, rather than a continuous descent into the grove.

Is this server still working correctly? I cannot see the AirBoss menu in the F10 menu.

Please also apply the same logic to the ATFLIR offset cross slew, which currently requires TDC depress & slew simultaneously to work.

Move the EXP polygon with the TDC (without depressing it), depress TDC to select the new EXP level. Very straight forward, and already implemented for the MAV. As mentioned above, just because you don’t have a problem, doesn’t mean others don’t either. I don’t have a button available for TDC depress on my stick, but do have a perfect one on my throttle, in the thumb position. The problem is, my TDC hat is also in the thumb position, hence I can’t use both at the same time. Many popular controls have a similar setup. Honestly, if this issue doesn’t bother you, I’m not quite sure why you’re even here making an argument against those who do find this an issue.

In a typical DCS server where everyone just charges head first into a fight, yes, getting a missile off at 40K & M1.6 will normally beat someone trying to do the same at 30K & M1.0. But in the real world, self preservation is the priority, so defensive manoeuvring after launch/pitbull is the norm. This will almost always lead to trashed initial shots, and reattacks at progressively shorter ranges. This is where the superior SA provided by the Hornet avionics gives it a substantial advantage. For example, with correctly functioning MSI, in a Hornet you can designate the datalink return 20nm at you 6 o’clock as the L&S target. TWS AUTO will center the scan volume on this target, or attempt to if outside the radar coverage. Once designated, a break into the target to get it just into the radar scan (which TWS AUTO will have set perfectly), one sweep to get a radar track, immediate FOX 3, and another break to turn cold again. All this can happen to quickly for the bandit to respond, and without any button pressing from the turn in. When both aircraft are down at 20K and below M1.0 on the first or second reattack, (which is where BVR fights are likely to end up if both sides fly realistically), this ability gives the Hornet a huge advantage. It enables valid hi Pk shots whilst keeping the aircraft safe and out of the bandits WEZ. Of course if we never get a complete MSI simulation, this won’t be possible, but. The Viper avionics simply don’t have this level of integration with other onboard and off board sensors so in BVR, it’s a bit of a one trick pony. Granted, for typical DCS servers, this trick is usually sufficient.

Hi All, What is the best method to delay a new CAP from spawning after the previous CAP has been destroyed? We have a training mission with 2 CAPs, and would like a 20 min delay after they have been destroyed, to allow for strike aircraft to proceed to the target without further hindrance, as this provides great training. Currently if we use CAP Time Interval, and set it to ~20 min, it doesn't really work, as the previous check may have happened 15min before the CAP flight was destroyed, therefore spawning a replacement 5 min later. Is there a better solution? Even if we spawn the aircraft immediately, but then hold them on the ground for a set period of time, that would work. Is this possible?

Honestly, the “ITAR” defence is starting to loosing some of its credibility. For the first 3 plus years of Hornet development, this term was almost never mentioned at all. Now it seems it’s the go to response for every question about incomplete or yet to be implemented features. Don’t get me wrong, I do understand that there are most definitely things that cannot be done, because the data required isn’t public. The problem is it’s also starting to sound like a convenient ’out’ for features that are just to hard or resource intensive to develop. Especially for a module ED seem to want to move on from. Personally, I think any further Hornet develop will just be the minimum ED believe they can get away with to get it out of EA, without a mass uproar amongst the community. It would be great however, if ED could prove me wrong, and outline what their vision of a feature complete Hornet looks like, no matter how long it would take to complete. Unfortunately it seems ED have shifted away from the more open communications they had a year or two ago, which the vast majority of users appreciated, so now we’re just left to wait and see.

Exactly. Surely if you can detect a target accurately whilst still scanning a relatively large area, then it should absolutely be possible to track this same target once the radar scan is focused entirely on one point?

Devs, please, can this be looked into? There are a huge number of users that don’t have a depressable TDC, and so this behaviour is extremely problematic. Sorry, but “Correct As Is” simply doses not hold up, given ED has implemented the feature for MAVs as a user convenience. Why not extend it to radar and targeting pod functionality too? @NineLine can this be considered?