Northstar98

What does SA-2 on its own refer to in the table? The Shrike's Mk 25 being the only one that works against SA-2 (TR) (i.e. the Fan Song E) makes sense, but the Mk 22-Mk 24 doesn't because the Fan Song we have in DCS is the Fan Song E, which operates in the G band. Fan Songs that operate in the E/F band are the Fan Song A, B and F. Speaking of which, it might be useful to have a threat guide in the manual for the radars in DCS, including their frequency and band where known. A list of what frequencies that correspond to what bands can be found here (you're after the new nomenclature). Though, I guess it also depends on how well DCS models it. The other thing is that some radar systems in DCS are actually a combination of radars which may operate on different bands (Straight Flush, Land Roll, Scrum Half and Hot Shot being primary examples). Also, some radar systems comprise of multiple radars, such as the 1S91 [Straight Flush], whose 1S11 acquisition radar operates in the C band, but its 1S31 tracking/illumination radar operates in the I band. Meaning that the Mk 49 and Mk 49 Mod 1 would only work against the Straight Flush in its track/illuminate mode. The Mk 37 might work (purely looking at the band) In any case, I'll list Eastern Bloc radars below and I'll bold what guidance section is appropriate, based on the frequency, which I'll write in bold. At the moment, for the table in the fusing GUI. 1S91 [Straight Flush] is the acquisition, target tracking and illumination radar for the 2K12 Kub [SA-6 Gainful] 1S11 acquisition radar operates in the C band. Mk 37 EDIT: This one actually has contradictory information, while this says C band, this says G band. If it's the former, the Mk 37 is accurate, if it's the latter the Mk 22, Mk 25, Mk 50 is accurate. Neither cite anything though and there's a non-zero chance the former could be mixing nomenclature (the C band in old nomenclature is G band in the new one). 1S31 track/fire-control radar operates in the I band. Mk 36, Mk 49 As above, while this says I band, this says H band if the latter is correct, it means the Mk 49 (either mod) or the Mk 50 is accurate. SON-9 [Fire Can] is a fire-control radar for AZP S-60 and KS-19 AAA batteries. It operates between 2.7 and 2.86 GHz (E band) Mk 23, Mk 24 SNR-75 [Fan Song] is the fire-control radar for the SA-2. In DCS we have the Fan Song E, which operates in the G band, at around 5 GHz. Mk 22, Mk 25, Mk 50 (Edit 3 - this appears to be the case in DCS). SNR-125 [Low Blow] is the fire-control radar for the SA-3. This operates at around 9 GHz, in the I band. Mk 36, Mk 49 The P-15 Danube [Flat Face A] is an acquisition radar mostly associated with the SA-3 (though is also used as a general purpose search radar, particularly for the Army), in DCS we have the updated P-19 [Flat Face B], which operates in the C band, at 0.83 - 0.88 GHz. Mk 37 The P-35 [Bar Lock] is primarily an EWR/GCI radar, which operates in the E/F band. Unfortunately, it doesn't exist in DCS (though given how prolific and how well it fits in with our maps and aircraft and the fact we have an appropriate model for it, it really should). Mk 23, Mk 24, Mk 50 As for other Eastern Bloc SAMs and radars: 2K22 Tunguska (2S6) [SA-19 Grison]: 1RL144 [Hot Shot]: Acquisition radar operates in the E/F band. Mk 23, Mk 24, Mk 50 Track/Fire-control radar operates in the I/J band. Mk 36, Mk 49 - Note, wiki (citing C:MO) describes this as a J band system, which would put it beyond any of the shrike guidance sections. 9K33 Osa [SA-8 Gecko] - Land Roll (unknown native deignation) Acquisition radar operates at about 7.5 GHz, which is in the H band. Mk 36, Mk 49, Mk 50 Track/Fire-control radar operates at 15 GHz, which is in the J band. None of the Shrike guidance sections can target this. 9K35M3 Strela-10M3 [SA-13 Gopher] This one is quite difficult as some sources refer to its radar as Hat Box or 9S86 [Snap Shot]. The latter allegedly operates in the mmW range which is in the K to O bands (30 - 300 GHz), which is beyond what any of the guidance sections can target. 9K37M1 Buk-M1 [SA-11 Gadfly] 9S18M1 [Snow Drift] SR operates in the F band. Mk 23, Mk 24, Mk 50 9S35 [Fire Dome] tracking/illumination radar operates in the I/J band. Mk 36, Mk 49 9K330 Tor [SA-15 Gauntlet] - Scrum Half (unknown native designation): Acquisition radar operates in the E/F band. Mk 23, Mk 24 Engagement radar operates in the G band. Mk 22, Mk 25, Mk 50 S-200V Vega [SA-5B Gammon] 5N62V [Square Pair] FCR operates at 6.6 GHz, in the H band. Mk 49, Mk 50 At the moment the P-19 and 5N59S are used in DCS (though neither are accurate). The actual acquisition radar used for the S-200 is the 5N84A (P-14F) Oborona-14 [Tall King C], which operates in the A band, below the range of the Shrike. S-300PS [SA-10B Grumble]: 5N59S [Tin Shield B] SR operates in the E/F band (2.85 - 3.2 GHz). Mk 23, Mk 24, Mk 50 5N63S [Flap Lid B] FCR operates in the I/J band. Mk 36, Mk 49 5N64S [Big Bird B] SR operates in the E band. Mk 23, Mk 24, Mk 50 5N66M [Clam Shell] SR - this one has contradictory information, this says it operates in the I band but this says it operates in the E/F band. Mk 36, Mk 49 for the I band, Mk 23, Mk 24, Mk 50 for the E/F band. EDIT: Forgot the ZSU-23-4, its RPK-2 (1RL33) [Gun Dish] operates at around 15 GHz, in the J band. This is above all of the Shrike's guidance sections - none of them should be able to target it. I also forgot the 1L13 and 55G6, but both operate well below any of the Shrike's guidance sections can target (A/B band). EDIT 2: I also forgot the 9S80M1 (PPRU-M1) [Dog Ear] - sorry everyone. That radar is commonly associated with shorter-ranged army systems like the SA-8, -9, -13, -15 and -19 and operates in the H/I band. Mk 36, Mk 49, Mk 50 I haven't extensively tested this however and I am just going by radar band. For later systems (e.g SA-1x, I would assume the later seekers would be better equipped for them, but I'm not sure when which was introduced). EDIT 3: You can check the exact frequency that our radars are defined with, by checking the .lua definition for the unit, which can be found here - if you Ctrl+F for "Frequencies" it should take you to the appropriate line, note that the values appear to be in Hz. As an example, here's the .lua for the SNR-75V of the S-75V, on line 81 you can see the frequencies defined range from 4.91×109 - 5.09×109 Hz (i.e. 4910 - 5090 MHz or 4.91 - 5.09 GHz), which is indeed in the G band as it should be and matches this). See this table for a list of what frequencies correspond to what bands (you're looking for new nomenclature). Note that some units appear to have this undefined, the 9K35M3 Strela-10M3 [SA-13 Gopher] is one such example, some ships also don't have this defined (though some do).

It's single-digit seconds for sure. But some figure is already used in DCS. Yeah, definitely and I believe this is already the case in DCS (though as said previously, it treats them as illuminating at launch, which is not how SM-2s work, nor should be possible owing to the limited number of SPG-62s). As for how targets are prioritised? Again, I don't know. DCS should be able to calculate an approximate time to impact, I'm not sure how rapidly AN/SPG-62s can be slewed and directed onto a different target, but I'm guessing fairly quick (let's call it ~30°/s) so we should be able to figure out how many missiles can be in the air while having enough separation for the AN/SPG-62s. I realise this is guesswork and that, for good reason, is frowned upon here, but right now, this guesswork would be closer to reality than what's currently present. A best-guess for improving the fidelity is better than leaving it basic.

In that case - yes, definitely reasonable.

Are you talking about some way of enforcing livery installation in multiplayer? Because I recognise that under certain circumstances, it might be useful to enforce liveries be installed/unmodified. In that case, I would certainly be open to having them be something the integrity checker checks for, at the discretion of the server owner or mission designer.

I wasn't being sarcastic - I genuinely do appreciate you sharing an opinion without being obstructionist for the sake of being one - the rolling eyes face wasn't intended for you. I appreciate that this is probably something only the minority cares about, that's perfectly fine.

For GP bombs: DSU-33 for airburst (currently wouldn't recommend as there's no fragmentation model). Everything else for impact or delayed impact. Delayed impact is better for when bomb penetration is required. Long delays are useful for area denial. For CBUs: setting shorter function/airburst delays (and dropping from higher altitudes) and setting faster spin rates causes the bomblets to be more widely dispersed (and potentially less accurate). Conversely, setting longer function/airburst delays (and dropping from lower altitudes) and setting slower spin rates causes the bomblets to be more tightly dispersed.

I am fine with making edits and adjustments myself. It doesn't take much time to make them the once. But, because there isn't a livery manager, any edits get overwritten, so they need to be done over and over again. So the time adds up and adds up. If there was a livery manager, not only could I choose what I install, but it would also mean that any fixes I decide to make only need to be made once. I don't think I can make it any clearer than that. Let's see if an analogy will help you out (probably not because you won't read it). Let's pretend for a minute that DCS, when an update or a repair is run, resets your controls and settings back to their defaults. You probably don't have a problem with setting your controls up and setting your settings how you desire, but you probably would if DCS kept resetting them back to their defaults each time it was updated and repaired. This is, at a fundamental level, is no different whatsoever. Imagine then that you ask for a way to make your changes to the controls and settings permanent and to not to be reset each time and I come along and tell you "If you have the time to post here, you have the time to adjust the files to your liking." That's absolutely fine - you're perfectly entitled to not care about things that I do. I recognise that this issue is quite minor and niche in the grand scheme of things, but that isn't an argument against it's inclusion. I definitely appreciate you not arguing against it though, for seemingly no reason whatsoever. Well, I'm fine with default behaviour being as it is now - i.e. install everything. Then if users wish to opt out for whatever reason, they can do so. Well, the only thing I'll say here is it should be up to the user what's more important to them. Being able to manage their liveries how they like or having greater immersion in campaigns/multiplayer etc. It's fundamentally no different to people who run mods that fail the integrity checker - they need to decide what's more important to them - playing with mods, or playing on servers where the integrity checker is enabled.

Wrong. Problem not solved:

To really hammer this home - it should be noted that regardless of which variant is chones, or if it's some combination merged into one vessel, this exact problem would apply just the same and there's no way around it, apart from choosing not to implement ships where data isn't available. To an extent, certain things can (and will need to be) abstracted (especially as these are AI units we're talking about). We don't know for instance what the rate-of-fire of the Mk 41 is when firing SAMs, how many the Aegis system (and its various mods) can support in their mid-course phase or when exactly command + inertial guidance switches over to SARH, a guess (which for the first one, has already happened) would be far better than the current behaviour (which treats SM-2s like SM-1s - i.e. SARH, illuminating at launch, not flying optimised trajectories like the 5V55R and being PN from launch). We do know that the SM-2s these ships have available are inertial w/ a command uplink in the midcourse phase and then switches over to SARH in the terminal phase (and we do know how many targets can have CWI directed at them at any one time, as this is determined by how many AN/SPG-62s a ship has) and that the M-5 also has a secondary IRH mode. A guess of say, 6-12 seconds before impact, switch over to SARH. That would be far better already than the current system.

???

There are some modules that only represent a small amount of install size/storage space (some are even smaller than liveries), yet there's a manager for those. Same for the campaigns, they're also small, representing a tiny fraction of the install size, yet there's a manager for those as well. No it isn't, because as established, this exists for modules and campaigns. Some of the former are even smaller than liveries and the latter is also only a small amount of space too. Clearly how large the files are has no bearing whatsoever on whether or not a manager should exist for them. Rendering this fact completely irrelevant. It also isn't relevant, because even if I have storage space (and I do), why should I store files I don't need, want or use? That can be deleted without consequence? Storage space also isn't the only possible reason either - like I said, I make fixes to the description.luas for liveries. So it's doubly irrelevant. The fact that someone like me, who has lots of storage space is advocating for a manager, should tell you just how irrelevant the storage space argument is. It's puzzling how you don't see that. I take it you didn't read the part where I said that this isn't solely about storage space? I take it it's not the only thing you didn't read. And true to form, completely failing to answer why I should store files I don't want to store, don't need to store, don't use and won't face any consequences if they're removed. So I'll ask again, why should I store files I don't want, need or use, that can be deleted with no consequence to myself?

Ah! My apologies. Should probably have checked that first.

I would definitely appreciate a livery manager to manage all of the liveries. It would be, in principle, identical to the module manager. The repair and update utilities are already able to scan for and exclusively download those that are either absent or modified, so the underlying functionality is already present. I'm already able to delete liveries without issue, so that's not a problem - really it's more about being able to blacklist certain liveries from being redownloaded (hell, I'd be happy if it was a blacklist in a configuration file). And no, before anybody chimes in about how liveries only represent a small amount of install size of storage space, that's completely irrelevant. Firstly, nobody can add $2 or whatever's worth of storage space, they can only free up space by deleting unwanted, unneeded and/or unused files. Secondly, why should users store files that they potentially don't use, don't need and don't want, even if they have lots of storage space (I still have over 400 GBs on a 1 TB drive that's solely dedicated to DCS World). Thirdly, how come we can manage whether or not 3rd party campaigns are installed, which also only represents a small amount of storage space and the total install size? It's not even solely about storage space either - I've made fixes to some aircraft such that their liveries are sorted by country (an easy example is the MiG-21bis - I don't see why when I select USSR, the first livery that shows up is for Afghanistan and why I should have to scroll through a list that's nearly 10 times longer than it needs to be, just to find the half dozen or-so liveries that are actually appropriate for the USSR). While definitely less of an issue, I'm also not a fan of inconsistency, so I make my own edits to the names and orders as I see fit. While it would be better if liveries were sorted as standard, I'm okay with making the edits myself. The problem is that they'll all be undone when an update or repair is done (so what I've done is copied them over to my user area, so I can just drag and drop them back in and delete the duplicates - though the updater/repair will also create a backup folder which contain any modified files/folders), while that doesn't take much time to do, it is something I have to do each and every time an update/repair is run and it's time that adds up. I'd definitely appreciate having a livery manager so that I only need to make edits once. Personally though, should a livery manager be implemented (or livery managing functionality to the module manager be added), its default behaviour should be to do what happens now - i.e. all official liveries are downloaded and installed, such that only those wanting to change which liveries are installed need touch anything. If this is going to be problematic in multiplayer, then official liveries could be something the integrity checker checks for, at the discretion of mission editors. As MAXsenna alluded to, there was a larger thread on the topic, which can be found here, feel free to chime in there (though I assume this will get merged there).

I might be misremembering, I have seen drop footage which appears to show the weapon making a roll but they're quite brief, which makes it difficult to determine. The Paveway III definitely does as per that video. The Paveway II is also supposed to use bang-bang guidance, I know it once did in DCS, but that seems to have changed and it now appears to use proportional control.

What about the relevant Soviet forces circa 1988 that are actually stationed in the region? VMF (Navy): Northern Fleet V-PVO (Air Defence Forces): 21st Air Defence Corps 57th Independent Radio Technical Unit (subordinated to the 3rd Independent Missile Attack Early Warning Army) VVS: 88th Fighter-Bomber Aviation Regiment 258th Independent Helicopter Squadron* 227th Independent Helicopter Squadron for Electronic Warfare SV (Ground Forces): 6th Combined Arms Army, which also includes the 6th Missile Brigade and the 271st Guards Anti-Aircraft Missile Brigade (there's also the 7th Anti-Aircaft Missile Brigade, but not circa 1988) RVSN (Strategic Rocket Forces): 24th Missile Regiment *This is subordinated to the Army We only have the Kirov (but this is the TARKR Pr. 1142.2 Pyotr Velikey), we're missing the Pr. 1142 Kirov (i.e. the original) which has a significantly different air defence systems (SA-N-4 instead of SA-N-9, AK-630 instead of CADS-N-1). Otherwise we don't have any of them (the only ones that are close are the Krivak II and Grisha V).

With the start cart, would it be possible to add this as a static object? I'm obviously not expecting functionality, but it would be nice in order to populate airfields, particularly with AI Phantoms.

Just for reference, on lines 445 and 625 of CoreMods\aircraft\F-4E\Entry\F-4E.lua, if "GBU-24" is replaced with "34759BBC-AF1E-4AEE-A581-498FF7A6EBCE", the GBU-24B/B gets replaced with the GBU-24A/B as is correct for our F-4E. I'm not sure if that remains so when dropped (while I own the Phantom module, I can't test it) if anyone wants to test it, I've attached a corrected F-4E.lua. Back up the one you have first though, before replacing it with this one (all I've done is changed the 2 CLSID entries as above and added a comment to identify them as being for the GBU-24). As above, the relevant path is [your main DCS World installation, usually inside Program Files\Eagle Dynamics\DCS World] then CoreMods\aircraft\F-4E\Entry F-4E.lua

And we know what kind of systems the Arleigh Burke has, especially those relevant to DCS. We don't know all the relevant capabilities, but DCS is too simplistic for them to be relevant. There's certainly nothing classified about the fact that from DDG 84 onwards, they only have the rear Phalanx at most (though some started out with none), RIM-162A ESSM has been in full operational capability since 2004, the RIM-174A ERAM achieved IOC in 2013 and went into full-rate production in 2015 and the RGM-109E TACTOM Block IV was introduced in 2006. Meanwhile, the absolute earliest the earliest Arleigh Burke livery in DCS is from 2007 and the earliest the latest Arleigh Burke livery we have is from 2018. There's certainly nothing classified about how the Oliver Hazard Perry needs the STIR if it's to have Mk 13 Mod 4 GMLS and there's plenty of photos showing that if one's gone, the other is gone. There's also nothing classified about the fact that the SM-2MR isn't SARH, illuminating at launch - that's how SM-1MRs behave and that it's instead inertially guided with a command uplink (at least with Aegis) with SARH guidance only occuring in the terminal stage. While we don't know the exact rate-of-fire or how many missiles Aegis supports in the mid-course phase or when the changeover point from mid-course to terminal illumination is, that applies to the ships as they already are, regardless of whether they're a mashup of different variants or not. It would apply regardless of what variant(s) they choose, as it's an integral part of that class of ship that cannot be worked around short of choosing a different class altogether. Even taking a best-guess would be more more realistic than what we have now (it would certainly be higher fidelity at the very least). It does vary with mission requirements, but this knowledge isn't required for DCS as the Mk 41 VLS is modular and should allow players to configure them as required. And being able to set what the load should be is the whole point of this thread. Even if I accept it to be true, the conclusion would be "don't do such modern vessels" rather than "do modern vessels but make them a hybrid" - all those Arleigh Burke variants that our one is a mashup of still have similar combat systems and similar radars. The problem is equally true for the hybrid, making a hybrid does exactly nothing to rectify or workaround this issue. All you've done is just make it even less coherent than it could've been. As for things like DDG 51 Flight III, DDG 1000 and interior layouts, neither is really all that relevant for DCS. We don't have a Flight III, we're supposed to have a Flight IIA and we don't have a DDG 1000. Interior layouts you can make a case for with the damage model, but the damage model right now is so beyond simplified that even a purely generic and abstracted internal layout would be an improvement by orders of magnitude (and really, that's all that's really necessary). Definitely agree there, though I'd say this is the wrong way to go about solving this probably specifically (we really need the release quantity settings to work properly and a way of configuring what weapons and how many they should use against what targets, when firing at targets of opportunity and in self-defence (the WRA settings in C:MO is essentially a perfect example of how to go about this).

Maybe, but personally it's probably a lack of research - we have ships with the wrong guns, ships that fire the wrong missiles, ships that have the wrong radars and even a vessel that has the wrong name. Not at all, nothing about this is classified in the slightest. You just have to do the research (and there's plenty enough online for it). For example on the OHP: https://www.navysite.de/ffg/ffg7class.htm or paying a visit to seaforces.org and looking at the photos and the dates. For another example, let's take a look at the Arleigh Burke: it has the 2 CIWS from the first 4 Flight IIAs with the 5"/62 Mk 45 Mod 4 (DDGs 81-84), yet it has the funnel design from DDG 89 onwards, liveries comprising the last 12 Flight IIAs, all 3 restarts and the first technology insertion but has the missile availability from 1990s - early 2000s Flight Is and IIs, which don't have hangars and have Harpoon.

Well, when you consider that ED's OHP is a hybrid of an early and mid 2000s version (Mk 15 Phalanx Block 1B, Mk 234 Nulka, Mk 13 Mod 4 GMLS but no STIR (which, for the latter 2, the absence/presence of one should entail the absence/presence of the other as the STIR is what provides illumination for the SM-1MR). In that case, the RIM-66E-6 SM-1MR Block VIB (which is from the mid 1990s), the RGM-84D Harpoon Block IC or RGM-84G Harpoon Block ID and the Mk 46 Mod 5A(SW) torpedo. But even then, DCS doesn't have the fidelity or modelling for their to really be much of a difference between variants, especially when it comes to AI AShMs and ASW torpedoes are non-functional.

As killjoy73au said, the overall idea is to have the P-37 and PRV-11 (but especially the -37) present as a core game unit, using the existing model (which, despite its age is fairly high-quality, though I'd probably get rid of the green mound it sits on). It's also one of the radars the Shrike targets and I'm not sure if the mod has the bands set up.

Yep, definitely. Personally, I'm inclined to prioritise updating existing assets before adding completely new ones and the priority should probably be aircraft > weapons > ships (particularly because the lower quality ones are very low quality) > ground vehicles. I wouldn't be surprised if some were even older than that, i.e. Flanker 2.5-era. Well, unfortunately we know very little about that one, there hasn't been any update on it in the 8 months or so since it was first announced. It was also supposed to go beyond being a simple asset pack - what the actually means we don't know (will we get proper buddy refuelling store functionality for the AI? Will the B-1B, B-52H and S-3B get all of their missing/incorrect weapons implemented/replaced?).

That probably explains the rolling to try and stabilise the missile in-flight. AFAIK the Paveway II is supposed to do exactly the same thing (but doesn't appear to do so in DCS). The Paveway III is also supposed to roll (though in this video, the rolling appears to briefly stop when the bomb is attempting to climb) but AFAIK that uses proportional/PID control as opposed to bang-bang, with proportional navigation (though again, it doesn't roll in DCS).

Yeah B/B is the Navy version, so only having the Navy coatings available for that makes sense. The actual problem here is that the Phantom has the wrong version of GBU-24. It should have the A/B, but instead has the Navy B/B. The A/B does already exist in DCS World and is available for RAZBAM's F-15E and the F-16CM, so hopefully this should be a fairly trivial fix.

This a general DCS AI problem - they're only set up for countermeasures that are carried internally (i.e. not something that's added in the loadout). It's not just the F-4E, the AJS 37, the MiG-21bis and the Tornado (though with the AJS 37 and the Tornado it is possible to set the countermeasures to 0 to prevent the AI having countermeasures without the appropriate payload). AI versions of the Mirage F1 that rely on Phimat for countermeasures don't have anything whatsoever - a consequence of DCS' AI not support countermeasure dispensers as pods. Every aircraft that uses a pod or something you have to equip in the loadout in order to have countermeasures (such as the Phantom) is similarly affected, though with those you can set the numbers to 0 to prevent the AI from having countermeasures.