norman99

Second question. Where would the BLUEFOR airbases be in a 1991 or 2003 scenario? Seems to me this is tailor made for an 80s Iran v Iraq scenario. Nothing wrong with that, especially given the F4 in development. Unfortunately it's not really suitable for 90s & 00s scenarios that a lot of F-15E/16/18 customers have been longing for. Here's hoping it gets expanded in the future.

If this is correct, that’s disappointing. No carrier ops at all for Hornet and Tomcat fans.

Currently, the AI priority for carrier ops is to prioritise recovering aircraft over launching aircraft. This is both incorrect (for cyclic ops), and leads to all sorts of issues on the deck. For instance, due to the deck containing many departing aircraft, an aircraft just landed may get stuck taxiing, fouling the landing area, and then everything gets frozen forever. Remaining aircraft don’t land, and nothing launches. If the priority was given to the launching aircraft, it would be both more realistic, and prevent some of these deck issues. When an AI aircraft arrives overhead for recovery, the AI ATC should check to see if there are any active aircraft on the deck about to launch. (Make the use of “request launch” command mandatory for player aircraft to help facilitate this). If there are any active aircraft on deck, the recovering aircraft waits for these aircraft to launch before being issued the “signal charlie”, and commencing recovery. This has the added advantage of clearing the deck of departing aircraft, providing more room for those about to land. Similarly, when an aircraft on the carrier becomes active for departure (or a player requests launch), it should check to see if any aircraft have already been given the “signal charlie”. If so, they wait till that aircraft has landed before moving, then they launch. If no aircraft are in the process of landing, departing aircraft have priority. Any subsequent arriving aircraft are required to wait until all departing aircraft have launched before they can commence recovery.

Honestly, the sheepskin compresses and flattens rather quickly, years on, there's not much difference to a cotton/synthetic cover, except it catches and hides more crumbs/filth.

If you’re looking for the NAV FLIR/HUD imagery shown above, you can stop now. It’s a function of the AN/AAR-50 Thermal Imaging Navigation Set (TINS), which was removed from service prior to the 2005ish era Hornet being modelled in DCS. Originally, when the ATFLIR replaced the NITEHAWK as the Hornet’s targeting pod, the NAV FLIR function was intended to be integrated as well, and in fact it is present on some cheek mounting station fairings, as you can see below. (it’s the small circle at the front of the fairing.) My understanding is that whilst present, with the advent of NVGs, the need for a dedicated NAV FLIR quickly reduced, and the wiring/avionics integration was never completed. Unfortunately for DCS users, this means no HUD/NAV FLIR for the Hornet.

Absolutely agree. I’d really like to see this system completed correctly in DCS. (Technically we’d also need the P-14 correlation compensator and the Parol-4 IFF radar.) It’d be perfect for the Syria map. Maybe we could crowdfund the purchase of the SA-5 models from TurboSquid, and add them to DCS ourselves? https://www.turbosquid.com/3d-models/max-sa-5-battalion-missile/513949

I first posted this in the Hornet sub, but the thread was closed due to it being classified as a map issue, not a Hornet issue, so I'm reposting it here. I'm noticing vastly different images when using the ground radar, especially EXP3, depending on which map my mission takes place. Specifically, for the Marianas the radar shows buildings and other items, but the ground features such as runways, taxiways (no roads) are very soft/blurry, and nowhere near the same definition as the Persian Gulf or the Caucuses. Compare this to the A/G radar return in the Caucuses, which produces a much sharper image of the ground details.

I first posted this in the Hornet sub, but the thread was closed due to it being classified as a map issue, not a Hornet issue, so I'm reposting it here. I'm noticing vastly different images when using the ground radar, especially EXP3, depending on which map my mission takes place. For the Persian Gulf specifically, the A/G radar displays very sharp ground features, runways, taxiways, (no roads) etc, but absolutely no buildings or other physical features. This is in contrast to the Caucuses map, which displays all features correctly. As you can see, no buildings or roads are visible on the radar, even though there are plenty in the area.

I wasn’t aware of that. (It’s been in my document library for a while, so I have no idea where I got it from). Still, I wouldn’t have thought just proving a rough timeframe for the approval of TOO delivery’s shouldn’t be too sensitive. I’m interested in creating accurate era specific missions, so just wanted to know if and when TOO was made available to Hornets, and when they were limited to PP missions only.

I'm not sure if the is a "feature", a bug, a map issue, or even limited to just the Hornet, so I'll post it here. I'm noticing vastly different images when using the ground radar, especially EXP3, depending on which map my mission takes place. In short: The Caucuses map displays what I expect, a rather sharp image, with easily distinguishable features, such as runway/taxiway/ramps (no roads), buildings etc. The Persian Gulf displays very sharp ground features, runways, taxiways, (no roads) etc, but absolutely no buildings or other physical features. The Marianas shows buildings and other items, but the ground features such as runways, taxiways (again, no roads) are very soft/blurry, and nowhere near the same definition as the other two maps. Has anyone else noticed this? Do we know what the cause is? I have added pictures below to illustrate. All images taken at 20K, ~18nm & ~45-50° off the nose. (F10 map included for comparison.)

The documents I have which detail JDAM systems and delivery methods, specifically state that TOO mode, whilst fully operational in the Hornet, was not authorised, and hence PP mode was used exclusively. This was due to "current state of F/A-18C/D tactical airborne sensors is such that coordinate accuracy (TLE) exceeds the minimum requirement for GPS guidance. This renders F/A-18C/D aircraft sensors unusable for JDAM employment either in real-time or as a second-party targeting source." These manuals are from 2001/2002, so may be out of date. My question for whoever may know is, was TOO delivery mode ever authorised in the legacy C/D Hornets? If so, would anyone know a rough time period for its approval? Lastly, just out of curiosity, what changes would have to be made to allow Hornet sensors to provide coordinates that meet JDAM accuracy requirements?

New Hornet callsigns, such as Roman are not working, calls made by the pilot and received from AWACS use a number instead. e.g. "1211", instead of "Roman 11". I've repaired my installation and nothing changes. null Callsign Bug.trk

Looks ok to me.

I’m interested in creating some late 80s/early 90s missions for the Hornet, simulating early Nitehawk pod operations. Is it possible to have an AI aircraft, specially an A-6 mod, laze fixed targets for Hornets to drop GBUs on? Would selecting the FAC(A) role for the A-6 suffice? In this scenario, would the FAC(A) provide a nineline report in the same way a JTAC does? I was hoping to avoid this, as it wouldn’t be realistic for a pre-briefed strike. Any ideas or tips would be greatly appreciated.

If it’s anything like the Hornet UFC, then no. The DED is not an additional monitor, like the MFDs are, and therefore will require some sort of software interface between DCS and the ICP.

I didn't know that, thanks. (An ALR-67 trackfile.......wishful thinking in DCS )

What do you mean by this? Aren’t they just pre programmed, based on the latest threat intel? i.e. they could, and sometimes are, completely wrong.

Sorry if this seems like I'm beating a dead horse, but I am genuinely interested in the progress of this. Again, the Jan 8 2021 newsletter states both: DCS: Supercarrier Most of our effort on the Supercarrier has been focused on creating the 3D environments for the Ready Room, Air Boss Station (PriFly), and the hangar deck. Other tasks for 2021 include plane directors to marshal aircraft to the catapults and off the landing area, the “burble”, deck crew light wands for night operations, unique radio channels for different controllers, and manual LSO control. And also: Air Traffic Control (ATC) Over the past year, our primary ATC focus has been on the Supercarrier. Now that the Supercarrier ATC system is nearing completion, we will next move on to airfield ATC radio communications. Given the scope of DCS World, this is not a simple task, and it will require three separate ATC systems: Western Modern Day, Eastern Modern Day, and World War II. Because this effort will require a large amount of new radio voice overs, we will also take this opportunity to update the radio communications for other entities like flight members, other flights, AWACS, tankers, etc (Newsletter can be found here: https://www.digitalcombatsimulator.com/en/news/newsletters/d5bb893019c9a8c047d07a678b211c55/) Again, I'm not here to bash DCS or ED, and I will gladly acknowledge both the SuperCarrier features that have subsequently been implemented (night wands, burble, CASE III), as well as the enormous task that is re-writing the entire DCS ATC system. However, as a passionate SuperCarrier customer, the stalled progress of the comms/ATC leaves me scratching my head. 3 years ago, it appeared we were so close to some significant improvements, specifically the introduction of unique controllers, (Red Crown, Marshall, Approach, Tower, LSO etc) all on their own frequency, with pilot interaction required to change to/from each. Unfortunately, since then, nothing has changed. We still have the simple, unrealistic single frequency, and automated "scripted" actions poorly simulating a small fraction of the actual ATC units, such as the current "switch tower" comm sequence. If ED had already spent a year "focusing on SuperCarrier ATC" as specifically stated, and if it was "near completion", why hasn't there been any change in the subsequent 3 years? With all due respect, what exactly was actually getting worked on?

@Miguel21 Did yesterday's update just reverse this fix/change? Which version of the scriptsmod should be used now? From the changelog: Revert previous changes for getCategroy() function (subclasses is returning their own category). Now function for subclasses returning first is Object.getCategory() and second is their own category. Also added a new function getCategoryEx which returns the subclasses own category.

That made me laugh. Funnily enough, here in SE Asia, Thursday is the 21st as well!

Any update on whether this works with 2.9?

Exactly. The University research papers that are often mentioned, are 100% public domain, unclassified sources. To say otherwise is disingenuous.

Now we have to set the temp to 20⁰C for unguided bombs delivery symbology to be realistically acurate ? I genuinely hope you're kidding. Someone already suggested changing POS/AINS to POS/GPS, now this? When do we stop accepting a band-aid, on top of a band-aid, on top of a band-aid?

Boring, the F-16 is boring! . It's literally a one trick pony. Go Fast! In any sort of realistic engagement, good situational awareness & tactics beats bad SA/tactics but 'Go Fast' every time. Apart from SEAD with the HTS, there's nothing the Viper can do that the Hornet can't do better, and many things the Viper can't do at all.

Hi guys. I've been playing Hornets over the PG and really enjoying it, however I don't understand what's happening with the carrier in regards to turning into the wind. I've configure manual activation, min wind over deck of 27kts, and the max carrier speed of 30kts (all in m/s, maybe this has changed?). Upon selection, carrier seems to turn into the wind correctly, or maintains present heading if the wind is nill. The problem is it maintains its cruise speed of ~14kts, rather than increasing speed to generate 27kts over the deck. I know the original script is from MBot, but has anyone else experienced this, and is there a fix?