NoJoe

Looks like it might just be a bug in the Rne range indication. If the bandit's nose is about 30 degrees to my right, the Rne range indication increases out to around 14 or 15 miles, compared to about 7 miles if the bandit is head-on to me. It might be as simple as some confusion in the code between Navy and Air Force notations for bandit aspect that is messing up the math. In Navy planes a bandit that is facing straight at you is considered to be at 180 degrees aspect. But in Air Force planes it's considered 0 degrees. Or the other way... I forget. But the point is that they're opposite. Maybe the Rne code is expecting Air Force notation in the math. I'm attaching a short track that shows this. We start head-on at 40,000 feet and Mach 1. Then he turns off to my right. As he turns, the Rne range indication actually increases as he turns rather than decreasing as would be expected. Hornet Rne Test.trk

I've noticed a similar thing. But sometimes when I launch multiple AIM-120s in TWS, some of them change azimuth on the radar display to match their target, and some remain straight ahead per the screenshot above. Not sure why or how to reliably reproduce it though.

Have you posted this in the Bug Reports section? It would probably get more traction over there.

Awesome, thanks NineLine!

It almost looks to me that the "LOST" indication pops up any time the DLZ max range decreases below the bandit's current range. For example, while engaging a two-ship flight that is in trail (so one plane is a couple miles behind the other). I fire on the lead plane when it is in range. So far so good. But as soon as I press the pinky button to swap to the trail plane (which is outside the max range cue) I get the "LOST" indication. Not sure if that's right. It "seems" like the "LOST" cue should only pop up if the max range changes for the current missile in flight (as a result of the bandit's maneuvering; my maneuvering cannot have an effect on my missile once it's already in the air). But then again I don't have any source for the correct behavior, so I don't know for sure. Something for the devs to check?

I'm not sure if this is a bug, or just me doing it wrong.. But I keep getting the "LOST" indication flashing on my HUD shortly after shooting an AMRAAM and cranking. DCS version 2.5.6, and I've already run a repair after updating just in case. I've made a simple 1v1 mission in the Nevada map of me vs a single MiG-29. In the attached track I fly right at him with him bugged in TWS. I fire when in range, then as soon as I crank to the side (keeping him within the radar gimbal limits) The time-to-active indication gets replaced with a flashing "LOST" indication. Why is this? From what I can tell, that indication means that the L&S track file has been, well, lost? I'm struggling to figure out why that's happening in this situation. The L&S symbology remains visible on the radar DDI, and the HUD target box stays there too. In other words it doesn't seem like I've lost the L&S trackfile. Thanks in advance for taking a look at this! [EDIT] What in the smurf... Now that I watch the track reply, it's not showing "LOST" anymore. It shows the steady countdown to ACT, then TTG as expected. And it shows my first missile hitting (when I recorded this, my first missed and I went in for a second shot). I'm very confused. [EDIT2] Since the track seems to play out differently every time I watch it, I'm also attaching the mission file. Steps to reproduce: 1. Launch mission. 2. Switch radar to TWS using OSB 3. Switch TWS to Auto with OSB 4. Increase radar display range to 40 miles with OSB 5. Select AIM-120C 6. Fly straight at the MiG 7. Once in range, fire and crank to the side about 45 degrees Actual result: "LOST" indication pops up once the target is about 20 degrees to the side. Target remains bugged and visible on radar screen this whole time. Expected (?) result: "ACT" countdown remains visible while the L&S track is present. Hornet TWS LOST.trk Hornet TWS LOST Test.miz

In that case it's because the radar signal doesn't change. Instead, the AMRAAMs use a datalink for mid-course guidance until they get close enough to turn on their onboard radar.

Finally, the day has come that we get to fly our glorious AT-802U! ... I can dream, can't I? :D

I have noticed this too in a mission (Hornet over PG, based on Mbot's dynamic campaign, I believe it was) whose date was set to the late 90s or early 2000s. After I opened the mission in the mission editor, changed the date to 2019, and re-saved it, the issue was gone. I'm not sure if it was the act of simply re-saving the mission, or if changing the date was the fix. Not sure if that's related, but worth checking.

I'm still seeing a difference after the latest beta. The DDI radar display shows the target inside the top of the range bracket, while the HUD shows it still outside the max aero diamond.

Awesome, this looks like a fun map! I like how different the tropical water / coral / flora look, compared to the Caucasus map. It's good to have variety.

The joke I've heard is that if you need to maneuver to defeat AAA in the real A-10, just let go of the stick for a few seconds. :D Apparently the real one was a bit of a handful too. I believe this was mentioned in William Smallwood's book "Flying the A-10 in the Gulf War", but it might have been a different source.

I also have no problems reading the new HUD, both with and without TrackIR. You can simply adjust and save your default viewpoint position as desired, and it's good to go. Default keys to use to adjust your viewpoint: Hold RCtrl and RShift, then use the numpad keys to move the view around. / and * move forward and back. To save the view hold RAlt and press the numpad 0. That should save this as the new default view, which should take effect the next time you load the plane. Easy!

Yes, I've been hoping the same, for the same reason. I have very fond memories of flying around Hawaii in Graphisim's Hornet 1.1.1. And maybe shooting down the DC-10s that are flying around... :music_whistling:

Cool, sounds good. And it looks like this has been listed as reported already, here: https://forums.eagle.ru/showthread.php?t=247108 I'll take a look and see if I can find anything in the sim's Lua files that might point to what's wrong. I'll reply to that thread with details if I find anything more.

A better way to test this might be to load just a single AIM-9X onto station 2 or 8 (with no other ordnance on the aircraft). I just tried this, and the plane immediately starts rolling toward the missile when the flight loads (as expected). However the roll is much stronger with the AIM-9X than with the AIM-9M, as you reported, Lester. The weights appear to be correctly listed as 736 and 745 pounds, but the AIM-9X definitely causes a faster roll for some reason. Just to check, you've reported this as a bug in the Bug Reporting section, right?

Thanks! I was wondering this myself.

Commercial pilot here, formerly flew cargo. I have around 2,100 hours total time, but I'm working in aviation-related software now. It's a better schedule and commute. ;)

I'm seeing the same thing, and I think what's happening is that the release cue might be using the navigation waypoint's altitude to calculate the release point of the bomb. I was flying to waypoint #3 which was defined to be 20,000 feet, and the DUD cue kept appearing while I was flying at 20,000. Once I climbed up to about 22,500 the DUD cue went away, but the Auto release point was very very late; I was basically on top of the target so the bomb went very far past. I've been trying to reproduce it, but it seems inconsistent. Sometimes when I turn away from the target I'll suddenly get the DUD cue again, then it goes away once I'm inbound. I'll keep at it to see if I can find a better repro. Seems like it works more often when starting the mission in the air, and the issue happens more often when doing a cold start. But I'm pretty sure part of the issue is that the release cue is using the navigation waypoint's altitude to calculate when to drop the bomb. [EDIT] Yeah, I can reliably reproduce it when I start from cold and dark. The bomb release altitude seems to inherit the altitude of the current nav waypoint at the time the targeting pod was turned on (or when the initialization timer ended, I'm not sure). First I tried setting the waypoint to 20,000 feet in the mission editor, and that seemed to be what the release cue was using. Then I tried it again with the waypoint at 15,000 feet, and the release cue used that. A workaround seems to be to press the up or down arrows on the HSI to select a different waypoint. Then the release cue will use the correct altitude from the designated targeting pod point.

Hey Nooch, could you edit your post to remove the spoiler in the quote? I came across this thread after Hog_No32's post had been edited to remove the spoiler, but I can still see it in the quote in your post. Thanks! :thumbup:

I would LOVE a Hawaii map, like in Graphsim's old Hornet games. Just sayin'.

[EDIT] Oh geez never mind, I was being dumb. I couldn't get my own JTACs set up correctly because I was setting the callsign, frequency, etc. in the Triggered actions section, rather than the advanced waypoint actions section. [facepalm] (see attached screenshot) Once I set them up correctly it all works, and it's great. Thanks for the example missions! These laser Mavericks are fun.

In real-world (civil) aviation I always used 3nm for every 1,000 feet I had to descend. So if I've got 10,000 feet to lose, I'd start the descent 30nm out (at a rate-of-descent equal to groundspeed x 5, incidentally). Good rules of thumb. But of course that was in aircraft that are WAAAAY less maneuverable than a Hornet. ;) And it was rare to get a single descent all the way down anyway; ATC almost always had a step or two in there. This is a great discussion! I'll have to give some of these numbers a try in the Hornet over the weekend. EDIT to add: The CNATRA P-819 "Advanced NFO Strike Procedures" document says: One technique is to multiply the altitude to lose in thousands of feet by two, then ad 10 NM." For example: if you have 10,000 feet to lose, start the descent 20 nm + 10 nm = 30 nm out. This document is written for the T-45 Goshawk, but still probably applies to the Hornet. And this way you have an actual Navy rule of thumb to use. ;) Link to the CNATRA publications, for those who haven't seen these yet (TONS of awesome information and procedures!) : https://www.cnatra.navy.mil/pubs-pat-pubs.asp

This is a really cool idea, but I'm having some issues with the debriefing. It seems the actual events in the mission have no bearing whatsoever on whether each unit gets counted as killed or not. During the mission I lost only 1 jet and destroyed all but one of the enemy jets, but after saving the debriefing the campaign engine listed all of my jets as destroyed, and about half of the enemy as destroyed. The base no longer shows the jets as being there, so it really does consider them dead. Is it supposed to tally one-to-one with the actual events while flying, or is it just a numbers game?

Hmm, not in my experience. The airplane seems to trim itself just fine when the flaps are in AUTO. Hands-off the stick at 250 knots and 550 knots both give me zero pitch rate, without touching the trim. I do notice that as I accelerate (especially from a slow speed), the nose pitches up a bit on its own. Maybe that's what you're seeing? But simply holding some forward pressure until about 300 knots works fine. The plane will trim itself out.