Northstar98

Just eye candy unless you add/replace them with functional units.

Personally, I think the better solution would be peer counterpart and contemporary aircraft, to Soviet aircraft that can actually be developed. So 80s F-15A/C, F-16A Block 10/15 or C Block 25/30, and F/A-18A. The REDFOR aircraft still wouldn't have precision strike capability (only dedicated aircraft like the Su-25 have that). In that case I would absolutely support a full-fidelity MiG-27 or Su-25 or even a Su-17/22M3/M4.

Hi everyone, The MIM-23 missile is currently named MIM-23K. This is incorrect for the battery components and the general capabilities of the system. The MIM-23K belongs to the I-HAWK PIP Phase III, which uses the AN/MPQ-62 ICWAR (not the 55) and the AN/MPQ-61 IHIPIR (which not only can track targets in angle completely passively, but can also illuminate multiple targets simultaneously at low altitude). The AN/MPQ-50 IPAR is retained (though given the limited TBM capability of the MIM-23K, the AN/TPS-59 can be used). To compound things however, the AN/MPQ-46 IHIPIR in DCS has the model of a HEOS-equipped AN/MPQ-57 from the I-HAWK PIP Phase II. If you wanted to keep the AN/MPQ-46 designation, the missile should be renamed MIM-23B and HEOS on the AN/MPQ-46 model should be deleted. If the HEOS-equipped AN/MPQ-57 model is to be kept, then the IHIPIR should be renamed AN/MPQ-57 (HEOS) and the missile renamed to MIM-23C or MIM-23D. The AN/MPQ-50 IPAR and AN/MPQ-55 ICWAR are both accurate for both PIP Phase I and Phase II systems. If it was ever implemented, all 3 would use the same IROR (AN/MPQ-51)

Is there a track file? I've found that with Attack Unit/Group, the AI may drop the task if the radar cannot be engaged the moment the task is called. I've found that Search then Engage will only have whatever group fire as many HARMs as there are threat radars.

Hi everyone, I've discovered an inconsistency with AI-fired AGM-84Ds. When "Attack Group" is used, the missiles always only strike the group leader, ignoring any other ships (even if those other ships have larger radar cross sections and are directly in the path of the missile - in the attack group track, you can see missiles overfly larger escorting ships on their way to the group lead). Even with a far tighter formation, the missiles only track the group lead, ignoring any other ships. This they do, even if other ships are obscuring the group lead. As if the missile magically knows where the group lead is and its seeker isn't being modeled. However, when "Search then Engage Group" is used, the missiles more randomly target ships in the formation, leading to every vessel being hit at least once (with the escort ships, which are both larger and closer to the missile's flight path) having more missiles target them. This is more expected behavior of the Harpoon and seems to better replicate the Harpoon's seeker. The bug here is that missiles fired by the AI using "Attack Group" should behave like they do when fired in "Search then Engage". For anyone wondering why I wouldn't just use Search then Engage every time. Well, search then engage requires the firing unit to detect the target themselves, which the low-flying aircraft will only do at fairly close distances. By using Attack Group, I can replicate pre-planned targets (where the Harpoon is fired at a pre-planned waypoint) - allowing the launching platform to remain in EMCON and/or replicate targets transmitted to shooters by other AI aircraft. AGM-84D_AttackGroup.trk AGM-84D_AttackGroup_TightForm.trk AGM-84D_SearchThenEngage.trk

Hi everyone, Pretty simple one - the YJ-83K (as fired by the JF-17 and H-6J) do not produce any sound for their sustainer stage - only wind noise can be heard. The same bug does not affect the surface-launched YJ-83. YJ-83K_no_sustainer_sound.trk

This looks corrected to me.

Not having an issue on the latest patch - tested with GBU-10, -12 and -24. Make sure the laser code matches between pod and bomb and make sure the code is actually entered into the Pave Spike.

Just as a tack on from this one: specifically Type 22 Batch 1 (w/ Type 910 Sea Wolf directors, not the later Type 911) as seen here and Type 42 Batch 1, with the Type 965P DOuble Bedstead, not the later Type 1022 (as seen on the current Invinicble, where it's accurate). See here for an example.

Only if this would entail removing the scenery object airliners that are already there. Simply taking the model and converting it to .edm format so it can be used as a static object doesn't necessarily entail doing that.

Could not agree more.

Yeah, but if you want to put anything else where they are, you're in for a fun time of trying to precisely tailor the object remove zone so that it only removes what you want to remove and doesn't remove things you don't want removed, if this is even possible (and there are cases where it isn't). It doesn't just go for airliners either, though they are the easy example to point towards as they take up what could've been a usable parking space.

Yeah, ythis is exactly my problem with having these kind of objects as scenery objects. Personally, I'd much rather maps embrace more of a sandbox ideology - let me decide what goes where, rather than making the choice for me and then doing so in a way where it's difficult to impossible to do anything else. It is far easier to add a static object and use that as decoration, than to delete a scenery object, especially when it often results in collateral damage as seen above.

Yes, this is a problem when developing an aircraft that was only recently declared fully operational. It's part of the reason why I think that the F-35 is a poor choice for DCS. However, developing a pre-IOC aircraft would really solidify that the F-35 is a poor-choice in DCS for me - on top of everything else (like the lack of relevant peer threats, low fidelity sensor modelling, lacklustre EW etc). And to be honest, the only thing 3F materially improves when it comes to DCS-relevant aerial warfare is external carriage of 2 AIM-9X. Most of the changes relevant for DCS would concern AG armament.

No it isn't. I want an operational variant, of which Block 3F is the first. If I wanted "the most powerful version" I would've said block 4+ It's give me a MiG-23MLA, not a pre-production MiG-23. Give me a 9.12 MiG-29, not a 9.11 MiG-29A.

Yep, they would be far more useful as functional units than just decorative, scenery objects. Though we really need a separate civilian faction.

Yeah, would really be nice (though might be something more for the general wishlist), alongside a different icon for heliports and for fixed wing aircraft with systems that list aerodromes to ignore heliports.

Absolutely agreed.

@Ghostrida9 Looks excellent - far more accurate than what's currently there. I wonder if there's any way to actually place the ammunition warehouses for this airbase where they should be? I saw a screenshot showing them in seemingly random places - like 2 objects near the apron in the north-west of the airbase.

It wasn't the only obvious invasion route, the other is the North German Plain, which is not only flatter, but also includes several strategic areas - like control of the coastline and ports (important for Reforger). https://en.wikipedia.org/wiki/Seven_Days_to_the_River_Rhine

DCS really needs to have a separate icon for helipads and for them to be filtered out for fixed-wing aircraft that list them.

Same goes for H GDR 21 - see here for 1985 satellite imagery. It should just be a forest. Meanwhile military installations (including, one with a helipad) in the vicinity aren't present, ironically replaced by trees: FuTK-332 (1), which actually had a grass helipad, isn't present (note the adjacent SA-3 site (2)): Another military site in the vicinity that isn't present is the SA-3 at Damgarten itself (1), there's also an EWR site (2), see here for an image showing the 2 very clearly.

@EvilBert VR what website?

It is, however we're getting the Ukrainian T-64BV Model 2017 (though externally it's pretty similar). So not quite, but should more-or-less work as a stand in.

Echoing my thoughts on other threads - the radome should be a static object, not a scenery object, so we can place functional radars in the right locations. If it's a scenery object, we won't be able to use the site as a functional EWR site.