Northstar98

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:

Have to agree - I'd much rather Ugra add the racing pylons to the static objects (though there is one already) and let mission editors decide whether to have them or not. I'd say the same for balloons. The sort of thing I love. I know the Saal site is currently missing, as is the S-125 site adjacent to it. There is a completely fictional tank range nearby though... Though we really need ED to implement that P-37 and PRV-11 that have both been in the files for over 12 years now and to implement the trailer mounted ST-68U as an EWR. But these sites should be in a more-or-less empty state, so we can place functional radars on them (these sites IRL were quite empty, with radars just sat on small artificial hills and concrete pads). From what I've seen so far, many EWR sites currently implemented in Germany feature tall towers with a small radome on top, I'm not entirely sure what it's supposed to be, but it doesn't look anything like the EWRs present in either the Cold War nor modern day (the linked post also shows that this EWR station is in the wrong place). The other, more pressing thing though is by making towers with radomes, Ugra is excluding the possibility to put functional radars there. Ideally they'd include a structure with a flat top and then a radome static object. Allowing them to be used as functional units, while looking the part.

May also explain why the motion disappears when zoomed in - maybe something that works in principle to LODs for 3D model is employed and this cuts down the refresh rate.

Just an addendum, this video was taken from the above track, with RTSS and DCS' own performance statistics enabled. Ive also switched from MSAA to DLAA, all other settings are as they were in this post. The clouds still appear to be exhibiting unexpected motions as I make small, rapid inputs on the stick. The motion is subtle but it's still there (the easiest comparison is probably at around 18-22 seconds in - pay attention to the cloud just in front of the mountain - you can see it moving up and down relative to the mountain). And as you can see - rock steady 60 FPS once actually in-game, frame times too are basically completely stable. The only time they differ is immediately upon entering or exiting the mission.

I don't have an issue with performance - my missions are kept fairly simple. You can see in the first video I have a stable 60 FPS and the frame time graph is essentially flat - it's very stable. And that 60 FPS is capped both in DCS and in the NVIDIA control panel. My monitor is only capable of outputting 75 FPS maximum (though currently set to 60) and that's only at 1080p. So long as I don't have too many VRAM hungry aircraft in view with full-resolution textures, with more difficult weather settings on maps that have problematic performance at low-level (like the South Atlantic) I'm able to run such high settings and rarely encounter any issues with performance. Regardless though, settings changes nothing with regards to cloud motion, the blurring effect present with DLAA smooths it out but it's still there. Even if I reduce the graphics settings all the way down. The new clouds have always exhibited this behaviour.

Here's a track, not from the same video though (tracks don't seem to behave all that well with the Phantom and this followed a dogfight wherein the AI does different things) - default conditions on the Caucasus map, when I look to the right and make small roll inputs more distant clouds can be seen moving up and down relative to the terrain (as if they're moving with me). CloudMotion.trk

Just as an aside to this - if generic templates are to be used, please make it accurate to a real site in Germany. For instance, the S-200 sites currently implemented have a launch battalion too many (no S-200 site in Germany had 3 launch battalions, only 2).

Here's another video showing cloud motion. This time it's a bit more clear. Some points I'd like to raise: The clouds closest to me do not appear to move in the same way, it's only the next and subsequent clouds further out that do. When zoomed in, the motion stops.