Northstar98

Definitely agreed, Wittmundhafen at least should be present. If we're going to do road bases they should be real-life ones. There's fairly extensive research material on them, for both the FRG and the GDR, backed up with historical satellite imagery. Though I really worry about cluttering up the map with aerodromes that we can't filter out. The good thing about roadbases though is that if the roads themselves are appropriately made (with the turnaround areas), mission editors are able to add them as is, using the invisible FARP. This can then be used to make a static template which can be reused.

Hi everyone, I've noticed that in some testing scenarios, large-calibre WWII AAA will only track targets without ever actually firing - instead at some point they stop tracking and reset (seen in the. Sometimes, guns will start engaging but will only fire a few rounds before ceasing. Adding the Kommandogerät 40 seems to resolve the issue for German Flak guns and the allied director resolves the issue for QF 3.7". However, the Kommandogerät 40 does not resolve the issue with either the 75 mm Type 88 AA gun, nor the 8 cm/40 3rd Year Type gun. However, the director shouldn't be required for guns to actually start firing (especially if they've detected and are tracking the target) - instead directors should make guns more accurate. The same issue also applies to ships (namely the Essex), which I've reported here, but have yet to make extensive tracks (I've seen it sometimes engage higher altitude targets, but my prevailing experience is that 5"-guns don't engage reliably, nor do the directors track targets reliably). The same issue does not occur with the KS-19, which is perfectly capable of engaging targets without its SON-9 director. 8.8cmFlak37_Engage-ish.trk 75mmType88_Engage-ish.trk 80mm3rdYearType_Engage-ish.trk KS-19_Engage.trk 8cm3rdYearType_NoEngage_3kft.trk 8cmFlak18_Engage_3kft_Kdo.trk 8cmFlak18_NoEngage_3kft.trk 75mmType88_NoEngage_3kft.trk KS-19_Engage_3kft.trk KS-19_Engage.trk

Just as an addendum, behaviour seems really inconsistent and appears to affect nearly all large-calibre WWII AAA I’ve tested (the Samuel Chase seems to be the exception but more testing required), in some form, not just the Essex (though Magnitude 3s assets are affected the most).

How does it do anything of the sort? Just because real-life sites exist, it does not mean mission editors are forced to only put air defences in them. This even represents real life doctrines, where some pre-prepared sites are unoccupied and the system relocates to another site. This is especially true of mobile systems like the SA-4, SA-6 and SA-10. If anything it only enhances mission creation options, because without these sites present, the sites aren't usable, so the only mission you can do is where you have air defences not in their pre-made positions as it's usually the case that the topography is otherwise unsuitable - e.g. Caucasus, South Atlantic, Persian Gulf (at least in some cases). If they are present however, usually the map developer has made them so that they're suitable for placing units on - that way you can still use ahistorical or relocated SAM sites and you can place them in the IRL locations. Well, seeing as many of these sites span >50 years at this point and many are still around decades after being abandoned, in their original configurations, probably fairly easily. But even for the ones that have changed - if we have accurate revetments/berms etc as static objects then you can use the scenery object remove zone to reconfigure SAM sites. So if we had those objects, that would be pretty easy too. Again though, the problem is on maps where SAM sites haven't been made, the terrain is often unsuitable for placing them in their real world locations, so building them yourself (assuming we even have the objects required, which we don't) is somewhat fruitless. However, if the map creator has added SAM sites, they usually make sure the topography is suitable for placing functional units on. Again, there is a trigger that does just that - scenery object destruction. You can substitute "based on satellite imagery" to "in DCS" and still be just as true - because every single map in DCS represents a "snapshot in time" and none of them change based on what year you set. Sinai 1960s vs Sinai 2000s is already an issue on the current map, even if none of the air defence sites were present. Ironically, as I described, there is already a mechanism in place for you to alter, edit or remove these air defence sites, so long as we have static objects to do so (and I don't know why maps don't contribute scenery objects to static objects - yes it's a different format, but surely it's the same original model, just re-exported?) - there isn't a way to edit say, edit the layout of airbases, nor is there any way to remove them (even if you remove all scenery objects, all surfaces will still be present). Just for an easy example, the Falkland Islands in the early 1980s wouldn't have Mount Pleasant on them (which is also in a mid 2000s - early 2020s configuration), Stanley would have a smaller runway, the JCUFI wouldn't be there, the wind turbines wouldn't be there etc. The latter I can't even remove with the scenery object remove tool.

Okay - that's a relief. Although I'm interested in the case where the rangefinder shouldn't be present. Oh well, I guess it doesn't matter much. Cheers Flappie!

Definitely - ideally we'd be able to add sides at will like Command Modern Operations - a civilian "side" though is definitely a requirement for this. As well as tweaks to how units are identified (AI does it magically, as does ED's NCTR implementation, at least in the Hornet - a neutral MiG-21 will remain an unknown, a hostile MiG-21 will be determined as hostile). Jester also does this in the F-4, not only does he often assume non-response always = hostile, in some cases he'll even call out friendlies (even friendlies that are providing positive response) as hostiles.

There's AAA issues across the board it seems - 5"/38 on the Essex similarly has issues. Interestingly enough I did notice Flak 18/36/37/41 also not engaging despite tracking a target, so perhaps this is an ED issue.

Hi everyone, The Mk 49 Mod 0 and Mod 1 guidance sections don't track the 1S31 of the 1S91 SURN [Straight Flush], despite providing tone and ADI steering. The 1S91 is listed as an intended threat in both DCS and IRL and the 1S31 track/fire-control radar is the the one that falls within the frequency range of the Mk 49 Mod 0 and Mk 49 Mod 1 (the other radar being the 1S11 acquisition radar, which currently is set to operate in the C-band). I've tested with guidance sections set to both direct and loft and I've ensured that the 1S91 is actually tracking me. You can see, that in no point during either track does the Shrike track the radar when launched, instead flying more-or-less ballistically throughout. AGM-45A_Mk49_1S31_NoTrack_Loft.trk AGM-45A_Mk49_1S31_NoTrack_Direct.trk

On my end I can reproduce no track warning, but I get launch warnings. 9A310M1_FA-18C_LaunchWarning.trk 9A310M1_F-16CM_LaunchWarning.trk

#1 and #2 turrets look fixed in the F4U release video - that's good to see.. However, unfortunately it looks like the rangefinder has also been removed from the #3 turret, which was correct as-is before.

Oh well, it's great to hear it's been corrected!

Looks like as of DCS 2.9.17.11733, the 9M38M1 no longer employs bank to turn. However, I was mistaken in my original post in that the V-601/5V27 of the S-125M and the V-755/20D of the S-75V rolls when yawing (not quite BTT, but can look somewhat similar). Again, not sure what exactly is correct or not, though it is somewhat odd for a missile of its configuration and type. The V-755/20D is maybe different in that it has liquid propellants, but so does the 5V28 which in DCS, does not bank to turn. V-755_rollwhenyaw.trk 5V27_rollwhenyaw.trk

My list of errors has errors! Apologies, edited.

Hi everyone, The 5" mounts on the Essex appear to track aircraft but, in the majority of tests I've run, only actually engage below 2500 ft. In the tracks below I have a single Ju 88 A-4 at various altitudes that should be well within the engagement envelope of the guns. The only track where the guns engage reliably is the 2.4k ft track. The other thing is the range at which the guns start firing - according to the linked trajectory chart, the upper-limit of the range should be around 15000 yards (~13.7 km) for a target flying at 10,000 ft and around 16000-17000 yards (~14.5-15.5 km) maximum for a target at 2500 ft. In DCS however, the guns first start firing at around 1.5 nautical miles (or about 3000 yards or about 2.8 km) and only get a single salvo off (and even then, not all the mounts engage) before the carrier is overflown. Each gun should be able to fire at a rate of 15-22 rounds per minute (or 30-44 rounds per Mk 32 mount, as used on the Essex). Part of the range issue may be down to the directors (Mk 37 GFCS), whose radar ranges (for the Mark 12) are half of what they should be (they also are defined with the wrong frequency range). In Essex_Class_Carrier_1944.lua, the director's "distanceMax" is set to 25 km. The Mark 12 radar (the rectangular antenna on top of the director, mark 22 is the elliptical antenna beside it) should be able to track bomber-sized targets out to ~41 km [source] Suffice to say, these issues drastically limit the effectiveness of these guns. Essex_5-inch38_Engage_2.4kft.trk Essex_5-inch38_NoEngage_2.5kft.trk Essex_5-inch38_NoEngage_5kft.trk Essex_5-inch38_NoEngage_10kft.trk

Hi everyone, The threat rings associated with the Essex are much smaller than expected. The sensor ring is only 15 km, far below the instrumented ranges of the radars. The SC-2 for instance has a maximum instrumented range of ~120 km [source] and the SK-2 up to 320 - 600 km [source]. The weapons ring is only 4 km, it should be >16 km [source] To fix these issues, change "GT.airWeaponDist" on line 78 to 16000 (on this trajectory chart, the maximum range is ~17000-17300 yards) and change "GT.airFindDist =" to at least 321868.8 (i.e. 200 statute miles).

Pleased to see that the forward 2 turrets have been corrected, though unfortunately, this change seems to have also applied to the 3rd turret, which was correct as-is before - now none of the turrets appear to feature rangefinders:

Have to agree with @Ghostrida9 - the accuracy of airbases is currently my biggest turn off: Many NATO airbases have the wrong types of hardened shelter and the USAFE shelter type (though a very similar type can be seen at some RAFG airbases coming in later phases) that is actually correct is the wrong shape. There's a few threads on these such as here and here. There are QRA facilities used to house alert aircraft that are instead office blocks. Some aerodromes seem to mostly consist of placeholder objects (at least, I hope they're placeholder - the primary example for me is Gütersloh) There are aerodromes that are wildly inaccurate - Bienenfarm being the primary example (which has no paved surfaces at all IRL) - EDIT: Wrong!!! Thanks Bremspropeller. Unfortunately Germany carries on the trend of assigning ammunition warehouses to seemingly random buildings, instead of in actual shelter objects that depict real weapon storage areas. In some cases these are actually modelled in-game, which makes it somewhat confusing as to why they haven't been assigned as ammunition warehouses. The prevalent, dug-up, mud-like texture surrounding many paved surfaces looks inaccurate, to the point that, IMO it almost makes Germany look like a different biome - in the vast majority of cases it's grass right up to paved surfaces.

I've noticed quite a few of these. Here's another 2: -camera -47.619865 0.094396 123.935962 -cameradir 0.783814 -0.324993 -0.529164 -camera -47.501616 0.114918 122.572081 -cameradir -0.938114 -0.345114 0.028957

Well, in the track, the JSOW's path has it directly overfly the target - not compensating for the drift of bomblets at all. Reducing the wind to 10 knots at 33 ft results in a near miss, the track above is with 15 knots.

Hi everyone, It seems the AGM-154A JSOW-A does not account for the drift of its bomblets when correcting for the wind. The weapon seems to correct to fly itself directly over the target, but the bomblets will encounter drift due to the wind as they fall. In order for the bomblets to actually impact the target, the JSOW should fly such that its flightpath is upwind of the target, so the bomblets drift into it. With high-enough crosswinds (the track below is tested with a 15 knot perpendicular crosswind at 33 ft), small-enough targets and high-enough function heights (tested with it set to 1000 ft, with an actual functioning height of ~1340 ft AGL) it can lead to a total miss, doing no damage. With 0 wind however, the same target set-up has all targets destroyed. I am waiting for a 01 GOOD alignment (testing with the F/A-18C). AGM-154A_WindCorrection.trk AGM-154A_NoWind.trk

The exact same issue as a matter of fact Apologies @BIGNEWY @NineLine, this was already noted (the issue has been present since the F-16 received these pages) previously but I searched the wrong subforum (and subsequently posted to it too), though that issue is not reported either. This though should be merged with the linked thread as it describes the exact same bug (though the linked thread doesn't seem to mention the HUD, though it is affected).

All I can say is that with the exact same control bound, using the exact same settings (curve, saturation etc), with the same calibration, this issue is not seen on any other module, or any other page of the F-16 (such as the HSD and the FCR). Here's a video to show what I am seeing (this is after a recent calibration): Note the following: The FCR and HSD pages don't show this issue - the cursor behaves entirely predictably and there are no sudden rapid accelerations - all good. However, the HAD, HARM WPN page and the HUD (here shown in DTOS, but the same applies to say, Maverick in VIS mode or any other mode using the HUD's cursor), show sudden, rapid accelerations when the switch is moved in a circular fashion. When I make just max X or just max Y inputs, the cursor generally moves more slowly and sudden, rapid accelerations are less frequent (though not entirely 0, you can sometimes still see the cursor suddenly start moving very quickly). The bug appears to affect the Y-axis more than it does X. The sudden, rapid acceleration of the cursor occurs when changing direction. Towards the end of the video I show my control bindings, you can see that my control moves as smoothly as I make it move. It properly re-centres to 0 and I can move it to the extremes of either end without any observable jitter. Here's a video showing what happens when I try another module, here I try the A-10s TAD cursor and the HUD cursor - note how there is no sudden rapid accelerations and the cursor behaves completely predictably and is generally very smooth. I also again show my control bindings and test, you can see that the exact same control is bound and (aside from not being inverted) the same exact settings are used: Every other module I've tested (A-10C II, AV-8B, F-4E, F-14A/B, F-15C, F/A-18C, Ka-50, Mirage 2000C, Su-25, -25T, -27S, -33) work as they do as seen in the A-10C video - smooth, predictable motions, with no sudden rapid movement - if I move the control to it's maximum values the speed of the cursor stays clamped. It is only the F-16CM and only for the HUD, HAD page and HARM WPN page that exhibit this issue, other pages (such as the FCR, the HSD, the Maverick WPN page, the TGP page etc show no issues). VKBsim Gunfighter Modern Combat Pro {1C884E80-2E03-11f0-8009-444553540000}.diff.lua VKBsim Gunfighter Modern Combat Pro {1C884E80-2E03-11f0-8009-444553540000}.diff.lua

Hi everyone, Encountered an issue with ATFLIR, when slewing it and releasing the image briefly jitters before stopping where it was released. This behaviour is not seen in LITENING on the Hornet, nor any other targeting pod on any other module I've tested. ATFLIR_jitter.trk LITENING_NoJitter.trk

Hi everyone, Certain pages in the F-16 have the cursor move at inconsistent speed when changing direction, leading to it appearing to jump. It's most commonly seen when going left/right and then adding some up/down. As far as I can tell the following are affected: The HUD (for instance, CCRP, DTOS, Maverick VIS etc). The HAD page (though the cursor does move more smoothly - as if its position is updated at a higher rate compared to every other page. Unsure what the rate should be). The WPN page for HARM. Everything else appears to work as it should and motion is predictable (though the rate at which the position is updated seems to be lower than the HAD page). No other module appears to suffer from the same bug (the A-10C for instance is very smooth and very consistent, with the exact same control on my stick bound), there are also no conflicts in the control set up. F-16_cursor.trk

Just going to leave this here: