Northstar98

Mmm, not to mention some of the errors and issues (albeit most of them minor) on the Forrestal as is: As Viper33 alluded to, the datum lights bloom significantly at a distance. This could be solved if there were different lights for each LOD, such that they better scale. The lights in general don't properly account for LOS and have the similar blooming issue. The landing area lights also abruptly disappear at a certain distance. For the Mk 15 Phalanx CIWS: The barrels are way too long It's silent It's depicted as possibly the wrong block - it's currently depicted as a Block 1 with the larger magazine, but I've only ever found images (including those close to end of Forrestal's service life) showing Block 0 - the difference isn't trivial: 989/990 rounds as opposed to 1550 smaller elevation limits (+80 -10, compared to +80, -20) If this is to be believed, a significantly reduced elevation search capability (0-5°), not that DCS models any of Phalanx's sensors (apart from LPWS) The AN/SPS-48C antenna completely lacks the supporting structure behind it (the ships with the AN/SPS-48E all have this) and shouldn't be solid between the rows of elements (and should have more of a grille look to it - though at some angles it does look solid) The AN/SPS-49(V)5, AN/SPN-43B and Mk 23 TAS have the wrong shape (with the SPN-43B easily being the worst offender), no other ship with an AN/SPS-49 or SPN-43 in DCS has the same issue. The AN/SPS-64(V)9 antenna isn't present. The radars above rotate in the wrong direction (with the exception of the AN/SPN-43B, which nods for some reason, with its IFF antenna rotating independently). The Mk 95 directors don't track targets. We can't remove the static deck equipment. The catapults have inaccuracies. The propellers don't rotate. The elevators are animated, but there's no hangar present.

2-3 minutes is already vastly faster than anything approaching realistic. Arguably slotting into a new aircraft is more realistic than a magical arcade-ish 3 minute repair.

Ai aircraft do indeed follow CASE III recovery procedures, including flying the marshal stack (the holding orbit before commencing an approach). However, they do it automatically - marshal/tower/approach and recovering AI aircraft don't interact with each other. Marshal will increase the altitude, distance and entry time for successive aircraft, at least IIRC.

Eh? There's an inbuilt voice chat system similar to SRS. It isn't a popular as SRS and there are still things SRS does which the native system does not but player radios absolutely have a purpose in multiplayer. Well, yes it does - I've given you the prime example twice now (i.e when you have other aircraft waiting to takeoff, taxiing onto the runway/landing area), in the case of the former, the current ATC system is as good as useless. If you were in the same marshal stack, at the same altitude, that absolutely could result in collision which is why marshal should separate aircraft. Likewise, if you're on final and aircraft are fouling the landing area (either by taxiing onto it, or using the waist catapults), that also increases risk of collisions were it not for a proper ATC system, who should wave you off due to a foul deck. This has been relevant IRL too, and it shows what happens when ATC (or rather everyone in PriFly and the LSOs) isn't performing: I have had a near identical experience as this in single-player, with AI aircraft at land bases - the only reason why I didn't collide is because conditions were such that I could see AI aircraft making incursions onto the runway and I was further away, giving me enough time to go around. This proceeded to happen over and over again however until eventually I just said "sod it" and landed as an aircraft was departing - narrowly avoiding it.

How about this? If this mission was in reduced visibility, the current ATC's complete uselessness would've resulted in a collision with departing aircraft. And this is in a single player mission. Yes - which is a bad thing. As it stands, the current supercarrier system breaks if you so much as bolter, there's no interaction with the AI at all, it uses the wrong callsigns when using the Forrestal and it also doesn't support ziplip operations. The other, F-16-orientated sim, begs to differ. Its ATC system allows for things that are straight up impossible to do in DCS (especially in single player) without causing utter carnage. Like I said before, ATC being fundamentally not worth using beyond turning on lights and receiving a single vector is probably contributing to that being the case. I ignore ATC completely in DCS because it's so limited. In the other sim though, I pay attention to it, because it actually works more like the way it should and I don't encounter the same annoyances using it.

Ever considered that the lack of decent ATC is at least partially the reason why that is? And if so, do you not see how circular that is? ATC isn't worth using and doesn't work properly -> people avoid making bigger missions with more traffic -> little traffic for ATC to manage -> people think ATC isn't worth it -> ATC stays useless -> people avoid making bigger missions with more traffic -> ... Because it certainly is for me. I'd definitely be more interested in making bigger single player missions if the ATC system was worth using. Instead of what it is currently, where creating chaos takes very little effort and airbases feel dead and unimmersive. It doesn't take long in the other sim to see how worthwhile a good ATC system is, even in single player missions. A decent ATC system and an AI that interacts and obeys its instructions (like in the other sim) is definitely useful, even with a small amount of aircraft in a single player mission.

Is it opposite day?

Yep, definitely agreed. For me it's simple - I'm not going to purchase Iraq if this airbase isn't present and the same goes for things like SAM and EWR sites.

No it shouldn't, because that's not what the BRC describes. BRC is the ship's heading, the bearing down the landing area (about 10° left of the BRC) is referred to as final bearing (which is what marshal calls out during a CASE III - i.e. the case where ACLS is applicable). You shouldn't be using BRC with ACLS or with CASE III approaches.

Well, that or I'm just boring Thanks though, I appreciate it!

Yep... Would also be a very useful EWR, fitting on several of our maps (including the Caucasus, Syria and Kola).

I mean, I could get behind a new S-300 version. Though personally I'd go for a domestic S-300PM-1/2 system, I guess it doesn't really matter though, the domestic version is just a bit more applicable to DCS' maps IMO. DCS also doesn't respect the more limited arrangement of the TELs, the 5P85D does not need the 5P85S in order to fire (as if they're all "smart"), nor are the limited cable lengths modelled. We are lacking functionality to even deploy the S-300PS as it would IRL, taking advantage of its self-propelled nature. Though the longer-ranged missiles of the S-300PM-1/PMU-1 and S-300PM-1/PMU-2 wouldn't go amiss. DCS also lacks the ability for missile batteries to operate autonomously from the command and control element, the real thing can do this, but with degraded acquisition capability (particularly against medium/high-altitude targets) Though FWIW: Off topic, but yeah completely agree with everything here. The lack of IADS functionality (or even just AI sharing targets between different groups via appropriate units) means you cannot even deploy an S-300PS as it would be set up IRL (i.e. with a single 5N64S RLO and 5K56S PBU) controlling 2-6 missile batteries as a single regiment/brigade. You have to have the RLO and PBU in the same group, which means you can't relocate them independently (and shoot-and-scoot mechanics are a main feature of the S-300PS, having a rapid stowage/deployment time well within the timeframe of a mission). Well, I guess first we would need a 5S116/17/18-equipped MAZ-7410 tractor and the the 5N64S RLO would need to support being towed around too. The map thing though really irks me though - this is supposed to be a combat flight simulator, air defence sites are directly applicable to what we do here. And yet, they're seemingly an afterthought, if they're a thought at all - only a single map really does them justice (Sinai). We also have an absoluteluy tiny amount of EWRs, despite having an appropriate model for a very prolific one for over a decade now. You mentioned the S-200 having the wrong acquisition radar, which significantly impacts range, the S-75V also has the same issue (though at least the practical implications aren't as severe).

Yeah and the missile battery (minus the Clam Shell) already facilitates shoot and scoot mechanics. But the current lack of IADS functionality means that I cannot relocate the command and control units independently to the missile battery (well, if the Big Bird supported being towed and if we had a 9S17/18 equipped MAZ-7410 tractor for it), as it should IRL.

Hi everyone, A somewhat minor issue, that's trivial to fix - a complete S-300PS missile battery doesn't work without the SAM SA-10 S-300 "Grumble" C2 unit (5K56S PBU). IRL this unit is a regiment/brigade-level command and control unit, used primarily for forwarding targets detected via 5N64S RLO [Big Bird-B] radar to 2-6 missile batteries. The analogue to the Patriot system would be the AN/MSQ-116 ICC, which in DCS (as it should), is not required for a Patriot battery to function. The 5N63S RPN [Flap Lid-B] fire-control radar has a cabin (F2K) mounted on the rear of the vehicle, which provides battery-level command and control (the Patriot analogue would be the AN/MSQ-104 ECS). The missile batteries should be able to perform their own target search, independent of the command unit, using either the 5N66M NVO [Clam Shell] radar (albeit only against terrain-following targets) - which is required against NOE targets anyway, or via the autonomous target search mode of the 5N63S (which is 105° in azimuth by 1° in elevation (though this can be elevated up or down as needed and the radar itself can be rotated through 360°)). The F2K cabin of the 5N63S RPN should then provide all the command and control functions for the battery, including target acquisition via the NVO or the fire-control radar. The 5N64S RLO [Big Bird-B] radar is already not required to have a working S-300PS missile battery (just the acquisition capabilities of the battery will be greatly diminished), the same should be true of the 5K56S PBU (SAM SA-10 S-300 "Grumble" C2). Without the 5N64S radar and/or with only a single missile battery, the 5K56S should be redundant (just as the AN/MSQ-116 ICC is redundant for Patriot without IADS functionality). However, despite this, without the 5K56S PBU in DCS, the missile battery doesn't function - as if the 5K56S is treated as the sole command and control unit, which isn't the case. This means that if the command and control unit is disabled or destroyed, or is in the process of relocating, the missile batteries aren't usable, which also shouldn't be the case - they should still function, albeit with quite degraded acquisition capability. The only difference between the 2 tracks below is that the noPBU track doesn't have the 5K56S unit and the wPBU track does. You can see that the target is not engaged if the PBU isn't present. As above, without the RLO and with only a single missile battery, the 5K56S is redundant - the 5N63S RPN's F2K cabin provides all the necessary command and control functions for the battery, just as the AN/MSQ-104 ECS does for Patriot. To fix this issue, all that needs to be changed is that the "depends_on_unit = { { { "S-300PS 54K6 cp" } } }," needs to be removed on line 23 of S-300PS 5H63C 30H6_tr.lua (for the self-propelled mount) and on line 19 of S-300PS 40B6M tr.lua (for the 40V6M mast-mounted version). In case anyone is wondering what the structure of an S-300PS brigade/regiment looks like, see the spoiler below: S-300PS_missilebatt_test_noPBU.trk S-300PS_missilebatt_test_wPBU.trk

Yeah, IADS is sorely needed - even if it just meant AI groups communicating with each other. Right now, without this functionality, I can't even set up how an S-300PS would normally be deployed IRL, i.e: Have a group consisting of 1 5K56S PBU and 1 5N64S RLO [Big Bird-B] (+ the RLO's 5S17/18-equipped MAZ-7410 tractor), this consistutes the command and control element. This will in turn control: 2-6 missile batteries (2-3 for a regiment, 5-6 for a brigade), each containing: A 5N63S RPN [Flap Lid-B] Up to 4 launcher platoons, each consisting of: 1 5P85S TEL Up to 2 5P85D TELs A 5N66M NVO [Clam Shell] I'd ideally want them in separate groups, because this enables shoot-and-scoot mechanics without the whole regiment/brigade sharing the same waypoints (vastly constricting my options, if not making it outright impossible) and making it easier to separate the missile batteries for triggers. I currently can't do this without having the whole brigade/regiment as one group, which also leads to missiles fired by one battery guided by the radar of another, even if distantly separated and if the firing battery doesn't have line-of-sight to the target. IADS functionality would enable me to set this up properly, while having desireable shoot-and-scoot mechanics. The Patriot suffers from a similar issue and that also already has higher echelon elements (such as the AN/MSQ-116 ICC and the OE-349/MRC AMG). Ideally though IADS functionality should be at the brigade level and should integrate EWRs, interceptors/DCA aircraft and things like SAM sites and have them coordinate with each other. There are also other SAM improvements like no-fire sectors, primary and secondary target lines (for things like Patriot), ARM decoys etc. A "detected in zone by unit" condition would also be fantastic for influencing things like EMCON.

Reproduced all the above issues. There's also another issue when you have a complete battery (8 guns) - 2 of them won't engage. Similar thing for the AZP S-60 when you have a complete battery of 6 guns (only 4 engage).

Hi everyone, Would ED consider adding appropriate marshal callsigns for Heatblur's Forrestal? The appropriate callsigns for them are as follows: CV 59, USS Forrestal: "HANDBOOK" [source] CV 60, USS Saratoga: "FAIR FIELD" [source] CV 61, USS Ranger: "GRAY EAGLE" [source] CV 62, USS Independence: "GUN TRAIN" [source]

And if you play AGM-45A_S-125M_Mk37.trk you'll see the same mission working (if you watch the track then change .trk to .miz you can confirm it's the same mission). So long as the AI can get to a position where they can fire, it works - the track proves it.

The track I posted accompanying it (which is the same mission) shows a Shrike being fired at the P-19 and successfully destroying it, after 1 aircraft crashed and another shot down. The mission and track posted with just the P-19 has it engaged 100% of the time. There's nothing wrong here so long as the AI can get close enough to engage it, though their "tactics" sometimes hinders that.

Yeah, couldn't get the AI to launch the BK90s in that mission - I did try changing the reaction to threat setting, override AI attack avoidance and deleting then re-adding the bombing tasks - all to no avail, the AI simply overfly the target and then they're never in a position to launch. Very strange - I'm able to get the AI to drop BK90s no problem in my own missions (I've got an identical set-up in each, just changing the target and setting the AI to no reaction and immortal when against the SA-3). AI_BK90_Infantry.trk AI_BK90_S-125M.trk

Yes - I agree. That's a mistake on my part - my apologies, I appreciate the correction

Here I've got one where there's just a P-19 with no accompanying S-125. Make sure that: Make sure the P-19 is actually radiating (this is the default behaviour) The Shrike's guidance section needs to be set to Mark 37 - it is the only one that targets the same band as the P-19. Check the AI's reaction to threat and override attack avoidance decisions. Make sure the former isn't set to "allow abort mission" and turn the latter on. Try using perform task -> attack unit/group and search then engage as opposed to just SEAD. The other thing to bear in mind that the AI will only fire the AGM-45A in direct and in a dive, which results in firings only at very close ranges (and the Shrike isn't that long-ranged to begin with) - just about every SAM will outrange the Shrike when fired by the AI. The AI also isn't the best when it comes to attacking SAMs and miss opportunities to turn in and fire when one presents itself - so keep that in mind. But provided the AI can get to a firing position, they will definitely engage the P-19 and the Mark 37 guidance section is definitely capable of tracking it. EDIT: Made the AI actually fight an S-125M site, I used a 4-ship of aircraft and while they took losses (including controlled flight into the water) an aircraft did make a successful engagement against the site's P-19, using an AGM-45. AGM-45A_P-19_test.miz AGM-45A_P-19_Mk37.trk AGM-45A_S-125M_test.miz AGM-45A_S-125M_Mk37.trk

Reproduced. Dear me what a mess. Looking at the tracks, I've got some speculation as to what is happening: The RGM-84D's activation point is far too close - it's enabling before passing friendly vessels, which is why it's hitting the Arleigh Burke. There are a few ways this can be solved, but one of them involves changing the geometry of the formation and the targets: Implement waypoints for the AI Harpoon, allowing us to steer it to avoid friendly/neutral vessels (IIRC the RGM-84D with the AN/SWG-1 can be programmed with up to 3 waypoints, as well as a selectable pop-up or skim attack profile). Change the activation point of the Harpoon, ideally it should depend on the estimated target distance. Change the location of friendly/hostile units such that friendlies aren't in the line of fire/aren't within the RGM-84D's search sector (which for the AGM-84D is defined as ±30° × 40 (or possibly 65) km, the RGM-84D unfortunately appears undefined and generic). As for the La Combattante IIas, they appear to be firing missiles in turns, where the ship is heeling over. Slowing the tracks right down, you can see the missile moving independently to the launcher, sometimes teleporting to a different orientation and/or position. This leads to it clipping or crashing into its own launcher and exploding or flying at too shallow an angle to climb effectively and crashing into the sea. It's almost like the missile knows that it's the wrong missile for the launchers the La Combattante IIa is equipped with and is rebelling in its own ways. LaCombattanteIIa__LaunchFail_SlowMo.trk

The point is that what's being developed (and what's currently in-game with FC3) is not a MiG-29A. It's a misnomer - the MiG-29A is a different, hypothetical concept aircraft that was never built. What we have in-game (and what's being developed) is simply a MiG-29 (be it a 9.12/12A/12B, though the 9.13 is also referred to as just MiG-29). It's like calling an apple an orange and it seems to be a problem DCS uniquely suffers from - like calling the HY-2 a Styx, Silkworm or an SS-N-2 (of which the HY-2 is neither), the Type VIIC U-boat a U-flak, when it absolutely isn't a U-flak or the Chieftain we have a Mk 3, when it isn't a Mk 3. The fix for all of these is a change to a couple of lines in a .lua file each - it should be trivial. Before the .lua lock of 2.7 I would've just done it myself.

Hi everyone, Minor bug, the newly implemented Lie Ying Falcon ("Falcon Assault Gyrocopter") has an incorrect NATO APP-6 symbol. It currently has the symbol for a fixed wing UAV: It should have the icon for rotary wing, attack - as seen with attack helicopters.