Nealius

The only wobbliness I've noticed in the Hornet is the nose having some weird adverse yaw tendencies and lateral oscilations when making hard maneuvers, that other jets like the Viper and even Tomcat don't.

Essentially, any effort by the users to discuss or fix any potential or perceived issues is absolutely pointless because it can be waived away with "our data is better but we won't let you see it." All we can do is pray that the developers, whoever they may be, are acting in good faith with accurate interpretations of that data. Not very comforting. And to be clear, I'm not directing this specifically at HB, I'm commenting on this from a wider DCS ecosystem perspective. ED devs have many times been caught using inaccurate data or inaccurate interpretations of data and given us the same "our data is better" reasoning until years later someone finally finds counterevidence that ED will take a look at and fix. Or never fix at all.

In VR, the head position seems to be different between JHMCS and HGU-55. E.g. with JHMCS it isn't very difficult to see and access exterior lighting panel, however with HGU-55 the viewpoint has been shifted such that the exterior lighting panel cannot be seen or accessed from any angle whatsoever.

At least the FLOLS. It's usable in the day but crap at night.

Yeah I don't know why I couldn't get the shot. The TWS auto track looked good. Maybe I pressed the MSL Prep button too close to the engagement time.

Still having issues, only with Kola map. Posted in the ORBX bug tracker and ignored. If I use the F10 map then exit the mission back to the editor, black screen. If I edit a mission then exit the editor, black screen. If I edit a mission, then load another Kola mission, load halts at terrain init. During these hangs DCS is still responding, as I can alt-tab to try and close the window, and the "are you sure you want to exit" dialogue appears. Task manager shows DCS using 40-50% CPU, 60% RAM, 20% or less of GPU, and 0% disk during these episodes. Logs still appear the same as above, with "resize main window" loops. Again, this only happens in Kola. This does not happen with any other terrains. dcs.log

So 40nm and over are better? I tried a shot at 45nm but the missile refused to launch until I got to 34nm.

It's more effective than standard fuses on infantry and soft targets like logistics trucks.

I’m curious if anyone has experienced severe INS and CCIP degradation on pre-GPS era missions. With mission date 2024 my INS is solid as is CCIP bombing, however running the same mission with date set 1993 my INS is off by about 17nm and CCIP bombing throws bombs hundreds of meters long.

It was usable at night the last time I used Forrestal some months ago.

Works for the MiG-21 that includes Arabic numbers as possible combinations. Placement and format (3-digit vs. 2-digit on the flaps, for example) is most likely the major issue, as the indidival fonts and styles (e.g. italics) can be placed in the livery file like they already are for other modules.

It depends. As clearly evidenced by known documentation about doctrine regarding the Kola region. Being hundreds of miles off shore instead of within the natural protections of the Vestfjord would leave them more vulnerable to a Soviet threat.

F6 view showed it still tracking from the drone's rear aspect during the turn, so it wasn't notched. It had no energy to intercept, but the nose was still keeping up with the target's azimuth.

I haven't noticed this either with the LANTIRN. I'm usually able to trim her for hands-off orbits in the CASE I marshal. Granted I am holding a bit of rudder to maintain that so perhaps there's some Dutch roll aiding the trim in that situation. The only payload I find difficult to trim--and handle in general--is TARPS.

Drone in racetrack orbit, set to ignore all threats. It was non-maneuvering in the straight leg when I took the shot. While the missile was airborne, the drone happened to hit its turning leg, which I don't count as defensive maneuvering because it was a 1G airliner turn, not a high-G defensive maneuver.

So it's fair to say that its use is wholly dependent upon the CVW, with no universal "truth," as it were.

Well, clearly the pod was used as shown here in 1997 during OSW with TARPS on a combat mission. This reddit comment by someone supposedly with first-hand experience mentions the pods had configurable modules to jam a wide array of threats, and that it was transferred to red air roles for simulation because it wasn't as effective as more specialised jammers. This website lists 18(?) different configurations. The idea that it was only used to counter F-4 and F-14 radars seems suspect, given the contrary evidence.

Just yesterday I made a 34nm shot from 31k on a non-maneuving F-4, head on, at 22k. My shot was kinematically defeated by a lazy 1G 180-degree turn at around 15-17nm. I guess I accidentally discovered its MAR?

Concur. Hard to notice on the low-vis schemes but on the hi-vis schemes you can tell the rudder and engine nacelles maintain the default gray.

Just tested by copying/pasting. It does work!

Ball is unusable at night. The amount of bloom is so excessive that it's a massive cyan blob that's impossible to read.

It seems to be locked in "Aircraft.edce" in the same folder as the textures zip, so not only will we have to wait for Bignewy or someone to give us a working description.lua, livery creators will no longer be able to test their work in the ModelViewer because the edm file is encrypted.

Still no cockpit illumination.

How does one blank out areas of an existing livery to add new numbers/letters. E.g. blanking out the tail codes so I can put new tail codes over it? I've tried the smudge tool but that destroys the rivets/texture details. I've tried "stamping" with areas copy-pasted from empty areas of the file, but those don't blend very well.

I can't even find the default S-3 liveries folder any more. It's no longer in the Bazaar folder, and doing an Explorer search of the entire DCS root results in zero results except for a zip file in "HeavyMetalCore" that doesn't even have a description.lua. That said, I tried using "KS_3A" instead and they still didn't work.