Ironwulf

If you repair the hornet for any reason, the radar altimeter fails, emitting a continuous warning, unless the landing gear are down. Re-repairing does not fix the issue. In the past, initially when I first encountered this issue, shutting the bird down with the radar altimeter off avoided the problem, but seems that doesn't work now. For a while after that, the BIT seemed to function, and that also fixed the problem. I didn't log a fault because I presumed that might be standard behaviour if you left it on when the aircraft was shut down, and the BIT functioned as a reset. But now either method doesn't fix the issue. Also, the SAI doesn't work any more, you cannot cage it or uncage it. You cannot cage it prior to shutdown either to perhaps avoid this issue. This is less of a problem than the radar altimeter, where its kinda handy to have if you need to do some low altitude flying in low light. Lastly the GEN TIE reset doesn't turn off when you close the guard - I believe this has been reported elsewhere however, and I don't think its specifically related to repairs. Track file is here. http://voyager.hi-powered.net/files/dcs/f18issues.trk

Some other issues are with refuelling http://voyager.hi-powered.net/files/dcs/F-14-2.jpg http://voyager.hi-powered.net/files/dcs/F-14-1.jpg This guy really really wanted to get some fuel, but the tanker wasn't having it.... so he tried anyway, apparently http://voyager.hi-powered.net/files/dcs/F-14-3.jpg

Not sure if this is a DCS World thread, or Heatblur, so feel free to move 1. They (most of the time) attempt to climb to a given altitude from one waypoint to another seemingly instantly, pitching up 25 degrees or more with full burner and if they didn't start with enough airspeed they either stall, only to try the same ridiculous pitch angle again, or just fly along nose up with burner on.... usually descending. Even if they do manage to make it up there, they've burned off a HUGE amount of fuel and they are way outside their TOT. This is particularly evident if you task them to take off from land, and end up at 30000ft in a short (but not unrealistic) distance. 2. The AI seems to favour AIM-7 over AIM-54... long range engagement against nice dopey Mig-23s where I specifically have told them (using search and engage group) to use "LR AAM" they will maybe fire off one, then close in on the others at full burner to engage with an AIM7. It would not be uncommon to see them come back with 3 or 4 (out of 4) phoenixes, which is not how I wanted the scenario to pan out. Typically after that first one, they will only fire the Phoenix after they have exhausted their Sparrows. By contrast if I use the old F-14A, its AI will put 2 or 3 in, at least, before going to medium range missiles - which is exactly what I want. They are supposed to be able to engage multiple targets at once with Phoenix, and this is not evident - in the F14B at least- at all. 3. Unrealistic startup time from a ramp start. One minute from air being applied to chocks away and taxi... I cant see a human doing this.

From what I have read the V2 requires the presence of another aircraft to give certain features. This does not... it essentially functions the same as HTS on the F-16.

yeah I know what you're saying, but it would then be yet ANOTHER FLIR for them to do. I figured the laser spotter would help fill the gap a bit, without the huge workload of doing a whole TGP... worst case once LITENING and ATFLIR are done, maybe they can come back to it if they want to do the more classic hardware.

RAZBAM does MiG-27 then? haha :)

Pretty handy as a Laser spotter whilst we await the TGP... Mounts on a fuselage missile station so don't take up a A/G stores location. Partially modelled already on the AI F/A-18C it would seem. Could go the AN/AAS-38 (which it complimented) too, if you wanted to do a set up for earlier period Hornets... but I think that would be a distraction from the other TGP. My argument is the ASQ-173 would allow better location/designation of the drop point for LGBs, in the meantime.

What happens when the radar source is moving - such as an aircraft... it would then be lying to you again. Cant win unless you do some unrealistic tracking of the position without an actual source. For search radars, they sweep at a certain interval, and it is then, when it sweeps over the aircraft, that the RWR will update. When you are locked, and a tracking radar is used, or the radar switches to single target track mode then that's a different story because your RWR should be continuously getting a source signal, but I am pretty sure the RWR doesn't have latency then... again, which is what you would expect. Similarly with LTWS the position will only update when the radar sweeps over it. Sure it could make some guesses on where the aircraft might be based on its last return/track... but that could be problematic close in. If you want less latency , narrow the azimuth, decrease the number of bars. it will update more frequently.

MiG-23s that lock you up on the parking apron from 35000ft and 40-50nm away... a bit ridiculous when they'd struggle to lock anything up at 20nm and 500ft AGL Hawks that will fire missiles at a TU-95 whilst a strike fighter is rolling in for a SEAD strike... Shutting down when ARMs are launched (without needing to make your own triggers)

+1 for me... but also the western counterpart... the F-111F/G

Basically HTS for the F/A-18, very ingeniously integrated into the outboard pylons. Probably best summed up in this article, which is a great read... [TAS is in most detail starting at 'Targetting Recievers for HARM'] http://www.ausairpower.net/API-AGM-88-HARM.html

Here is a short track with the maverick issue I was talking about in the HARM/AAM thread, which has very similar conditions and to me seems related. http://voyager.hi-powered.net/files/dcs/maverickissue.trk If I am uncaged, using the TDC depress, plus axis commands to slew the crosshairs, and hit 'sidewinder select' the maverick seeker head seems to just move randomly off axis and cannot be recovered. Pressing 'cage/uncage' seems to pause it momentarily. The work-around fix seems to be around using WPDSG... it gets the seeker on the waypoint. I can then recage and it seems to be fine. You should be able to see it in the track. This only happens because I happen to have those AAM switches next to the TDC controller I use on my X56 throttles (as the stick has a ministick where that selector would be), so I get that its not likely to happen to many people, as often as it does, to me.

Here is a short track with the maverick issue I was talking about, which has very similar conditions and to me seems related - indeed this is exactly what had happened, when I got the 2nd picture with the mavericks in AAM. You may want to make a separate bug for it. It seems very repeatable. http://voyager.hi-powered.net/files/dcs/maverickissue.trk If I am uncaged, using the TDC depress, plus axis commands to slew the crosshairs, and hit 'sidewinder select' the maverick seeker head seems to just move randomly off axis and cannot be recovered. Pressing 'cage/uncage' seems to pause it momentarily. The work-around fix seems to be around using WPDSG... it gets the seeker on the waypoint. I can then recage and it seems to be fine. You should be able to see it in the track. This only happens because I happen to have those AAM switches next to the TDC controller I use on my X56 throttles (as the stick has a ministick where that selector would be), so I get that its not likely to happen to many people, as often as it does, to me. As someone mentioned TOO, it makes me wonder if this is related as both require the use of an uncage function. That might be a red herring however.

I had it happen again, this time mavericks. I had Mavs on left MFD, using the TDC, accidentally pressed sidewinder AA override mode ("Select Sidewinder" in the controls... And it did as pictured. It also makes the maverick go weird if it is uncaged at the time, with the sensor just tracking all over the place for no reason, and you cannot recage it.... but it can be made to slave to WPDSG So... I have a track file for this... but its over 2 hours long. Is that going to be ok?

Yeah so I found out... only problem might be its going to be huge as I play for hours sometimes... too bad there isn't a track editor (or is there?) I could crop it down a bit. I will put a track file on in the next 24-48 hrs

I am not sure how I did this, and unfortunately it was on an MP server I am not in control of... so I didn't think I could get a track file. What I was trying to do was change AAMs on my HOTAS. From memory I didn't have HARMS up, I was just changing from AMRAAMs to AIM9X, or trying to.... I can only guess I got some sort of SP mode routine (HARM OVERRIDE) by accident... ?

Well from what I read it was initially 2 per AW squadron.Nonetheless, it’s not ATARS that defines it as an AW variant, from what I have read, as there are obviously many more without it, and it requires deletion of the gun. From what I can see ATARS is used as recce/BDA, so it’s not needed in every fighter.

Only 3 aircraft per squadron have ATARS

As fry says... shut up and take my money

FWIW the workaround I did for it was to set a trigger that when they were on the ground, they turned 'invisible' - this let the CAP go about their mission properly.

Was having a similar issue which I reported here https://forums.eagle.ru/showthread.php?t=230172

I think given the more sensitive nature of the capabilities of the superhornet, a D would be more likely than an E or F, and really the 3D model etc wouldn’t change that much cockpit and sensors would be similar if not the same as the C, and it’d tie into the LANTIRN pod that they’ve said they’re going to do (as they are used by night attack hornets)

Obviously this would probably be a fair way down the track, but doesn't hurt to mention it now so it can be kept in mind :) https://en.wikipedia.org/wiki/McDonnell_Douglas_F/A-18_Hornet#C/D

OK, I take that back... the first time I used it, it was worse... but now its working. Bizarre.

Its not fixed for me in the open beta...