Tomsk

So I've been having a go at flying the Mirage but I keep hitting issues with the radar. It keeps getting into a state where it's "stuck" and won't lock onto anything anymore. When it gets into that state neither locking via the radar screen, nor locking with the ACM modes works properly. You can have the enemy sat 100m in front of you with the boresight mode right on them and it won't lock. You can still move the cursor around and change range and so on, but locking won't work. The only way I've found to fix it if this happens is to restart the mission. This seems to be the same issue as reported here: https://www.reddit.com/r/hoggit/comments/dyu4je/mirage_2000c_radar_issues/. I've been able to replicate in both latest open beta and stable. Unfortunately there's no easily reproducible way to replicate the problem: it doesn't always happen. But it does happen enough over the course of flying the plane for a few hours that it's a pretty serious problem, especially since there seems to be no way to recover from it.

So I expect the issues with the radios will be down to Razbam. There used to be a bug in the Mirage with the new VHF radio that you could turn it on before the battery was powered. Probably they tried to fix that but went too far: now you can only turn it on if the engine is running. The issue with the AI no longer being blocked by vehicles is likely a general DCS issue: I doubt it's specific to the Mirage. That said the fact that Baltic Dragon felt that it was necessary to use vehicles to prevent other vehicles moving at certain times is a little indicative: I doubt he'd have done it that way if it could reliably be done another way.

Since some recent patch I no longer get audio from Chevy 1-1 at the start where he says "Chevy 2-1 this is Chevy 1-1, how copy?" and all his other introductory dialogue. The first thing I hear is the player saying "One. This is Two. Lima-Charlie got you five by five". All of this is on the most recent Open Beta: 2.5.6.49314 I've tried turning on all the radios before turning on the battery. I've tried every setting on the radio imaginable. I've been into the mission editor and checked the frequency preset is the same as Chevy 1-1, it is we are both on 249 AM. However, nothing helps: all I get from Chevy 1-1 is silence, I get neither text nor audio. EDIT: I've worked it out. The UHF radio (and possibly also the V/UHF radio) no longer works unless the engine is running. You can hear the audio if you change the mission to start from parking hot. So this is (presumably) a bug in the M-2000C due to recent changes that is breaking the campaign missions. I've raised a separate bug report for this: https://forums.eagle.ru/showthread.php?t=274520 MORE EDIT: So there are other problems. Chevy 1-1 now creeps forward and crashes into the HMMV that is holding him in place, meaning that his plane is damaged and he'll never taxi out of the hangar. I guess the trick of using a vehicle to prevent AI units moving is broken more generally and this probably breaks in the other places in the campaign that use this technique. Basically it's a hot mess.

So the group I fly with have been using and loving it, even in it's rather unfinished state. Right now it is more like an F-16A with a few additional toys (for example DL, HMCS, AIM-120). However, it's already significantly more capable than the Mirage and it works perfectly well as a basic aircraft. The plane is a rocket and personally I like flying it more than the F/A-18, which feels a bit slow and lumbering by comparison. I also prefer the F-16 HOTAS and avionics. Whether it's worth it now is kinda up to you really. It's definitely not finished, but I've been really enjoying it and look forward to learning new features as they come along. That said I'm kinda biased as I've always been a huge F-16 fan, YMMV.

That said if you have the Mirage, and are handy with the mission editor, then it’s not too hard to convert the Mirage campaign to the Viper.

I agree, I don’t actually think it’s “harder” than the Hornet but it definitely is different. I found I just had to practice a little every day until I got a feel for it.

A fairly recent change to DCS is that preset channels, set in the mission editor, are now set explicitly as being either AM or FM. However Jester does not respect this setting and if you ask him to tune the VHF/UHF radio to an AM preset he does not necessarily set AM mode, meaning it doesn't work. Steps to reproduce Download the attached mission Open the mission in the mission editor and click on the parked F-14: note that the VHF/UHF radio preset 1 is set to 245 AM. There is a HMMV also in the mission which is transmitting a message continuously on 245 AM. Fly the mission Connect ground power and air. Ask jester to start and confirm the comms check. Ask jester to tune the VHF/UHF radio to channel 1. Note that you cannot hear the message. Ask jester to use AM modulation. Note that you can now hear the message. This is surely a bug: it should not be necessary to ask for AM modulation explicitly .. the preset is specifically an AM preset, it could only ever work with AM mode. This is extremely confusing for the user: I myself spent more than an hour trying to work out why I wasn't receiving any messages.

Ah you're talking about the Battle of the Philippine Sea .. I mean I personally don't think it's a very interesting battle to simulate. The Japanese were absolutely decimated due to the US's overwhelming advantages by this point in the war: the notorious Great Marianas Turkey Shoot. As I understand it the air part of that battle happened like 600km west of Guam island in open sea ... so not really that near it. Also we don't have the carriers or planes currently to simulate either the US side or the Japanese side. In fact I don't think any of the aircraft we can currently fly in DCS took part. Perhaps I'm exposing my bias as someone who was more interested in A2A combat in WWII than pure A2G. There was plenty of A2G stuff you could simulate no doubt .. you could probably make a mud-moving campaign for the P-47 when that gets released. Hey look free is free .. I'm not complaining, and if people are excited about it that's great. But personally I don't understand the choice.

So .. to my knowledge, and someone please correct me if I'm wrong, the Battle of Guam wasn't really an aerial battle. It was bombed from the air by the US B-24s .. but as far as I know the Japanese fielded no aircraft in that battle at all. Even if they did .. there aren't any Japanese planes in DCS. Nor are there B-24s .. we have the P-51 but I can't find any references that says it fought in the Battle of Guam. It might be possible to use it for Battle of the Philippine Sea .. but AFAIK that happened a fair way away from Guam, like more than 500km to the west .. and we don't have any of the planes for that on either side .. nor WWII carriers. Also IRL it was a notorious roflstomp: the Great Marianas Turkey Shoot. I'm also not sure how you could make a realistic modern scenario out of it. I mean I suppose you could do a modern fantasy "Russia declares war on the US and decides to invade the Marianas Islands" type scenario but it'd be pretty contrived. Honestly .. it's a nice island and the screenshots look great .. but I'm not sure what we're supposed to do with it.

Wow Pikey, thank you for your effort that's hugely helpful of you!! It seems so much of this process is a bit of a "dark art" due to the intricacies of DCS .. thank you for sharing your knowledge :)

Figured out the grouping problem, it's in two parts. First there's the SetDisengageRadius radius problem. That prevents (for some weird reason) groups of units from climbing to the right altitude. The second problem is the wingmen acting weirdly. This, I have found out, is specific to my choice of plane to fly the patrol: the F5 Tiger II. If I use M2000s instead then there is no problem, the wingmen behaves fine. However, for some reason with the F5 the wingmen behaves super weird and can't fly formation with the lead.

Thanks, I think I've figured it out ... this is the script I'm using: local detectionBlueGroup = SET_GROUP:New() detectionBlueGroup:FilterPrefixes({"EWR Blue", "SAM Blue"}) detectionBlueGroup:FilterStart() local detectionBlueArea = DETECTION_AREAS:New(detectionBlueGroup, 20*1000) local blueDispatcher = AI_A2A_DISPATCHER:New(detectionBlueArea) blueDispatcher:SetEngageRadius(100*1000) blueDispatcher:SetDisengageRadius(150*1000) blueDispatcher:SetDefaultLandingAtEngineShutdown() blueDispatcher:SetDefaultTakeoffFromParkingCold() local f5_1st = "1st F5" local capBlue01 = ZONE:New("CAP Blue #001") blueDispatcher:SetSquadron(f5_1st, AIRBASE.PersianGulf.Al_Dhafra_AB, {"1st F5 CAP"}, 20) blueDispatcher:SetSquadronCap(f5_1st, capBlue01, 7000, 8000, 470, 500, 600, 800, "BARO") If I comment out this line so it looks like this: -- blueDispatcher:SetDisengageRadius(150*1000) Then I do not see the "Holding" behaviour. Things patrol as they should. It's a bit weird as there are no "targets" in the mission (only BLUFOR planes). So I'm not sure why it would prevent patrolling .. or prevent pairs of planes from climbing to the right altitude .. but for some reason it does prevent those things.

Thanks for your reply :) I'm aware the AI in DCS is .. special. But the bit that seemed to be MOOSE related that was weird is as soon as it reaches the patrol zone the tactical display says "Holding" and a new CAP flight is immediately spawned as a replacement. Is that intended behaviour? I can't find any documentation of the "Holding" state in the CAP state machine. Also the burning around is one thing, but the bigger issue is the immediately returning to base. They still had tonnes of fuel left (more than 75%) .. so I don't understand why they decided to RTB? I included a link to the mission and script in my post, but I could jump on Discord. Where is the server to be found?

Hi I'm trying to setup a simple CAP patrol using MOOSE but I'm getting weird behaviour. I'm trying to setup a CAP patrol use the A2A_DISPATCHER. At first everthing seems to be working fine: I've setup the Zones, the planes take-off and fly to the patrol zone ... so far so good. However when they reach the zone, on the tactical display it changes from "Patrolling" to "Holding". At this point a replacement CAP flight is spawned. They immediately then burn round in a circle as hard as they can for a few minutes before returning to base. The patrol zone is really big (30nm radius) so they should be able to lazily cruise round it. How can I get the planes to actually just stay on CAP in the zone until they run low on fuel? Setting the SquadronFuelThreshold appears to make absolutely no difference to this behaviour. Setting the patrol speed in SetSquadronCap also does not appear to effect in any way the speed they go at in the "Holding" behaviour. The second problem is grouping. I'd like my CAP flights to consist of pairs of planes because that's more realistic and immersive. However if I do this (using SetSquadronGrouping or SetDefaultGrouping) then the planes won't climb to altitude any more (they stay on the deck) and the wingman dives and climbs on burners like a crazy thing .. as if they had absolutely no idea how to fly formation. I've tried using both MOOSE 2.4.13 and 2.5.0-pre and I get the same behaviour in both. I've uploaded the mission file and the lua script here

Oh does that work? I mean that seems like a fair compromise to me .. if you want to wait for the align then let it align, otherwise just switch it to NAV and off you go.

Please ED, can we have an option to skip this like in the Mirage. Some people enjoy sitting and waiting for the INS to align, and that's all great. However, some people (such as myself) don't enjoy it. We especially don't enjoy it when our VR crashes shortly after take off and we have to do it three times in a row like I just had to ...

So some of us are hoping that it's possible to mod them in. As whilst the USAF/ANG Block 50 does not use the AIM-7, other Viper blocks & operators certainly did and simulating other conflicts can be fun.

Ah right you are I had indeed set the AWACS to 30Hz AM. I'd just put it into the frequency window in the ME, but on closer inspection it does indeed say "AM". I'm not really sure why DCS allows that ..there's probably not a radio in existence that can tune to 30Hz AM as that is an exclusively FM band, but hey ho :) Yes using a SetFrequency task to 30Hz FM, it is indeed possible to contact the AWACS. So it's only the display that is bugged, the actual functionality works fine. It should probably also accept 0-3-0-0-0-ENTR (and variants) as a valid way to enter 30.00 as it is completely unambiguous and so I suspect the real jet would accept it.

Well sort of. You can type 3-0-ENTR into the scratchpad and it'll SAY it's tuned to 30.00 but it's actually not: you can't contact anything on that frequency. In contrast if you type 3-0-ENTR into the preset setting you get 300.00 instead. All in all it's a bit broken.

There appears to be a bug with the VHF radio in the F-16: it does not seem to be possible to tune it to FM frequencies. The AN/ARC-222 VHF radio in the F-16CM Block 50, as I understand it, should be able to tune to: 30.000 to 87.975 MHz FM 108.000 to 151.975 MHz AM (where 108.000 to 115.975 is receive only) This agrees with the F-16C.lua in the CoreMods folder as well as various sources online. However, it does not appear to currently be possible to tune the radio to any of the FM frequencies. First, I set the frequency to 30.00 FM in the Mission Editor as preset 1. This works correctly and is accepted as a valid frequency for that radio: Then I go into the mission and select preset 1 on the VHF radio, this shows incorrectly. It shows 300.00 rather than 030.00. This is wrong for two reasons: firstly it's not what I selected in the ME, secondly it is outside of the valid frequency range for that radio: I tried to contact an AWACS which is listening on frequency 030 using the VHF radio to see if it is just displaying incorrectly. However, this fails, the AWACS does not respond. Next I tried to change the preset to 030.00, this fails as the input is rejected (the display flashes). This is likely incorrect as 030.00 is a valid frequency within the range of the VHF radio. Next I tried to enter 030.00 into the scratchpad for the radio to tune the frequency manually. This is also rejected (flashing). I retried the test with a number of different FM Radio frequencies in the 30.000 to 87.975 range. I got the same result each time. NOTE: I discovered this bug trying to contact a friendly AI A-10 flight whose flight frequency had been set in the FM range.

Yes, good clarification, I would also very strongly suspect that the tadpole shows relative bearing between the ground track (I.e relative to the FPM) and the steerpoint rather than simply where the nose is pointing (I.e. relative to the gun cross). This of course would give wind corrected directions to fly to the steerpoint.

Here's another illustration of the problem: I am keeping the tadpole centred as I turn away from the steerpoint faster and faster: chYbNLgnigY The problem is the tadpole is currently showing how far the steerpoint deviates from the vertical plane of the aircraft. So if the steerpoint is directly underneath the belly of the aircraft it shows as being "centred". As the above video shows, this means you can be going nowhere near the steerpoint and it'll still show as "centered" if you bank the plane steep enough so that the steerpoint is directly underneath the belly of the plane. This error is also what makes it crazy hard to follow the tadpole: in order to turn towards where the tadpole is indicating you have to bank the plane towards the tadpole, but that extra bank means the steerpoint is even less "underneath" the plane's vertical axis .. and so it moves the tadpole further away from you. This isn't right, the tadpole should instead be showing things in terms of headings only. If your heading is directly towards the steerpoint it should be centred, irrespective of bank angle. It should show guidance of where to turn so that your heading will point directly towards the steerpoint. Note that your heading towards the steerpoint does not change just because you bank the aircraft, it only changes if you actually turn and change heading. You can see the contrast with the HUD tapes that were posted earlier in the thread: in real life just banking the plane doesn't move the position of the tadpole. That is because the real life tadpole is showing to what degree your plane's heading is pointing towards steerpoint, which does not change just by banking the plane.

So one thing is that it looks like the canopy is open in that video ..

Agree completely, was exactly the same in the Hornet: people have asked ED many times if they can allow a slider option for those of us that have a slider rather than sprung switch, or indeed if it could just respect the "slider" setting that is already there like the other axes do .. sadly it has never materialized.

Really handy tip for those that don't know it: a quick way to work this out (approximately) is take your distance from the airfield in nm and multiply by 300 to get the altitude you need to be at in order to be on glideslope. The altitude is, of course, QFE which is the setting you get when you call inbound. So at 10nm DME you should be (roughly) 3000ft QFE, at 4nm DME you should roughly be 1200ft QFE. Really helpful if you need to do a non-precision approach (i.e. without ILS). Similar tricks for descending from altitude to the airfield: for a 5 degree descent take your altitude in 1000s of feet and multiply it by 2 to get the nm you should start your descent from. So if you are at 20,000ft start your descent at 40nm for a 5 degree angle. For a 10 degree angle take your altitude in 1000s of feet and that is the distance to start: so at 30,000ft start your descent 30nm out with a 10 degree angle. Most planes struggle to descend at more than 10 degrees without gaining airspeed, even with the airbrake out.