Northstar98

The problem there might be that it impose ground clearance problems if placed on an adapter. Again, it's not a configuration listed in either of the -1s I have (unlike the AN/ALQ-71/72/87/101, which is explicitly mentioned as being able to be mixed, the 119, 131 and 184 are only listed by themselves). That doesn't necessarily mean it's not a possible configuration, it just means that it's a configuration that isn't explicitly mentioned.

Doesn't look like the combination is listed in the stores limitation chart, I'm not sure on the dimensions but it looks like their could be a potential clearance issue (ALQ-87/101 are both thinner and not as tall).

Please be careful with this table though - I’ve largely only matched seeker and radar bands generally, I cannot vouch for what seekers are actually compatible with what radar. Seekers may only cover certain parts of bands which might differ from certain radars. Unfortunately the specific range of frequencies a particular radar operates at isn’t always available and sometimes even what band a radar operates at isn’t all that precise. Sometimes information is contradictory (and I’ve just realised I haven’t updated the forum post in accordance to a similar one I made on hoggit, so that needs fixing). There’s also the possibility that some radars aren’t fully or properly configured (especially for systems that are composed of multiple radars combined into one vehicle). Though if anyone finds that a particular seeker doesn’t work despite being indicated in the above list, I’m more than happy to make corrections.

No you aren't and no I haven't. Nowhere have I said that this is a problem that isn't really a problem. Once again, dishonestly misrepresenting what I've said for only God knows how many times. Well right back at you! You don't even care about this, yet here you are. Again, which wouldn't have happened: I'm only left to conclude that all I've actually been doing for days is feeding a gish galloping troll. I'm absolutely beyond tired of having everything I say dishonestly twisted by you seemingly just so you can keep baiting a response from me over and over again and that's even when you acknowledge anything that was said at all. I haven't added anyone to my ignore list up to now, but I'm not going to engage with trolls any more.

Why shouldn't it be up to me to determine what liveries I have installed?

Perhaps if you'd stop dishonestly misrepresenting what they say, maybe you'd find it less fascinating? Posts that wouldn't exist, if people would stop misrepresenting what was said, so they can argue against something that they, by their own admission, don't care about, for seemingly no reason whatsoever. See also: Brandolini's law. There you go again...

So how exactly is it a non-analogy then? That was the key part of the analogy. Your responses either appear to demonstrate either a miscomprehension of the analogy or appear to be at odds with each other. But as I've said several times now, it's time that unnecesarily adds up with subsequent updates. You would have a point here if I only had to do this the once, but I don't, so you don't. It takes me very little time to bind my HOTAS and set my settings up, but if I had to do it over and over again, when I should only need to do it the once, then that would be a problem and that's exactly what the problem is here. That's rather ironic - you're spending quite an amount of time pointlessly arguing against it seemingly purely for the sake of it, despite the fact that you don't actually care about it. What gives? If it presented no problem to anyone, then why do we have multiple threads asking for such a thing? Just because it isn't a problem for you doesn't mean it's not a problem (even if it's only a small one) to anyone else. And don't need to store and come at little to no consequence to me if I don't store them. Only it demonstrably isn't the nature of software, as again, similar managers exist in DCS for items that also represent a small part of the total install size, that fundamentally have the exact functionality requested. So that's just false. As for "life isn't fair" - it's a fundamentally useless point which could apply to everything. You could stand in the way of any kind of progress or improvement with that attitude.

You see, you say that, but several times now (and indeed even now), you're still arguing against points I've already addressed or are misrepresenting what I said, so I don't believe you. It's completely fine to not agree with it - there's no problem there whatsoever. What is a problem though is making irrelevant points that have already been addressed and arguing against a misrepresention. If you were reading what I said, I doubt you would've typed this: See, if you actually read what I said, it means you would've got the fact that it's not having to do it the once that's the problem - it's having to do it over and over again, meaning the time adds up and adds up. I'll quote myself again: So let me get this straight: You think having to do something that doesn't take a massive amount of time to do once, but is something you have to do repeatedly, when you should only have to do it the once, bears no resemblance whatsoever and is completely incomparable to having to do something that doesn't take a massive amount of time to do once, but is something you have to do repeatedly, when you should only need to do it the once? Have I got that right? I'm not surprised that you can't imagine that. You don't even seem to understand what the argument for it even is, you're either not reading it or you're misrepresenting it. Also, what argument against it? You've so far told me something completely and demonstrably irrelevant and a non-sequitur, you've now just told me that you think this is minor? None of those are arguments against it. Hell, I even agree that this is minor, certainly in comparison to things like working on the AI, or the damage modelling, or clouds blocking LOS, data cartridge functionality and dozens and dozens of other major, gameplay-impacting updates. But I'm capable of advocating (even strongly advocating) for things that are both major and minor.

Yeah, but that can be generalised and abstracted, especially because we only really need to track critical compartments for damage modelling and hull compartments for sinking. And usually things like engine spaces are directly below funnels. But this applies regardless of whether we have a hyrid of multiple variants combined into one, or a specific variant. The hybrid still has the Aegis system and the Mk 99 fire-control system. So all you're doing by making a hybrid is making them less coherent than they should be (the hybrid certainly isn't broadening capabilities - if anything it's doing the opposite, because it's armed like ships at least around a decade older).

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.