Jump to content

Northstar98

Members
  • Posts

    8293
  • Joined

  • Last visited

  • Days Won

    21

Everything posted by Northstar98

  1. Wanted to bump this, there's no reason why the 1600 ft/500 m wind speed and direction should be coupled in this way, it leads to excessively high wind speeds and it doesn't take long in something like Windy to see that it doesn't match with what's expected IRL. For instance, at the time of writing (14/11/2023 @ ~14:00Z), Windy is reporting that the surface wind speed over Andersen AFB on Guam is 18 knots and the wind speed at 2000 ft/600 m (closest I could get to 1600 ft/500 m with Windy) is 26 knots. In DCS, if I try setting the 33 ft wind speed to 18 knots, it forces me to have 39 knots at 1600 ft/500 m (or, in other words, 50% larger that what it should be). For comparison the highest Windy is showing is 32 knots at 45,000 ft/13,500 m.
  2. +1, though personally I'd go one step further and go for just being able to make your own presets. But if not, more presets would definitely be welcome.
  3. With you, apologies for the confusion.
  4. Yeah +1, would be quite useful.
  5. Just had a look and yes, you're absolutely correct - corrected. Toilet2000 is correct, in the diagrams for Dive Toss, Dive Laydown and Laydown in 1F-4E-34-1-1 (c. 1979, r. 1986), it states that the target is momentarily tracked visually. The radar is slaved to the optical sight's LOS in order to compute slant range. A ground return only needs to be locked in radar/non-visual offset bombing (where the target is located at a known position relative to an identification point, for a radar identification point, the radar is locked onto said point, the WSO puts the radar into freeze and presses the target insert button, the aircraft then provides steering information to put it over the target).
  6. Hi everyone, Minor issue - the repeater lights for the AoA indexer on the S-3B (both versions) seems to have incorrect logic. The logic should be: Green: AoA too high (slow) Green + Amber: AoA slightly too high (slightly slow) Amber: On-speed AoA Red + Amber: AoA slightly too low (slightly fast) Red: AoA too low (fast) I'm not sure what range of AoAs are appropriate for each light, but currently, the amber light never seems to illuminate, but both red and green lights illuminate simultaneously. The lights also don't seem to be properly driven by AoA; I've observed that the green light will come on at a lower AoA than the red light (which is the opposite of what should happen) and that different lights also overlap the same range of AoAs: AoA: 9.2° - Green + Red: AoA: 10.1° - Red: AoA 9.2° - Green: Note: Red light on at a higher AoA than the green light - it should be the other way around. Red and green light instead of an amber light. Different lights/sets of lights come on for the same AoA/range of AoAs. Another thing that should be mentioned is that the lights are incredibly dim during the day and that the lights should come on as soon as the aircraft is in a landing configuration, but only come on until later in the approach: During the day - lights barely visible, it would be easy to mistake the lights as being off were it not for the reflection on the underside of the nose: Quite difficult to see (a daylight shot wouldn't be useful as I can only really tell if the green light is on and I could easily mistake any other light for being off when it’s actually on) but this S-3B is indeed in landing configuration for landing on a carrier during a CASE III recovery (hook down, flaps full, gear down), but the AoA repeater lights are off - they only come on until later in the approach: S-3B_AoA_lights_CASE_III.trk S-3B_AoA_lights_CASE_I.trk
  7. Apart from Googling, it doesn't seem so - the Encyclopedia seems to mostly have it covered, though sometimes it switches between the IEEE designation (such as for the AN/MPQ-50 PAR and AN/MPQ-64F1) and the (new) NATO designation. The screenshot in the newsletter is using the NATO system Anyway here's a list of land-based systems, though the vast majority aren't going to be all that applicable to the Shrike (which mainly targets the E, F and I bands - I'll boldface radars the Shrike is mostly intended for, though the AGM-45A/B-10 supposedly has a more broadband seeker able to target various radars): 1L13 Nebo-SV [Box Spring]: NATO A-band, IEEE: VHF-band. 2K12M3 Kub-M3 [SA-6B Gainful]: 1S91M3 [Straight Flush]: 1S11 (acquisition): NATO C-band, IEEE UHF-band 1S13 (track/fire-control): NATO: I-band, IEEE: X-band 2K22 Tunguska (2S6) [SA-19 Grison]: 1RL144 [Hot Shot]: acquisition: NATO E/F-band, IEEE: S-band. 1RL144 [Hot Shot]: track/fire-control: NATO I-band, IEEE: X-band. 55G6 Nebo [Tall Rack]: NATO A-band, IEEE VHF-band. 9K33M2 Osa-AK [SA-8B Gecko Mod 0] [Land Roll]: Acquisition: NATO H-band, IEEE C-band Track/Fire Control: NATO J-band, IEEE Ku-band. 9K37M1 Buk-M1 [SA-11 Gadfly]: 9S18M1 [Snow Drift]: NATO H/I-band, IEEE C/X-band. 9S35M1 [Fire Dome]: NATO H/I-band, IEEE C/X-band. 9K330 Tor [SA-15A Gauntlet]: [Scrum Half]: Acquisition: NATO E/F-band, IEEE S-band Track/Fire-Control: NATO G/H-band, IEEE: C/X-band. 9S80M1 Sborka (PPRU-M1 Ovod-M1) [Dog Ear]: NATO G-band, IEEE: S-band. AN/FPS-117: NATO D-band, IEEE L-band. FlaRakRad Roland 2: Domino 3D (Track/Fire-control): NATO J-band, IEEE Ku-band. MPDR-16 (Acquisition): NATO D-band, IEEE S-band. Flakpanzer Gepard: MPDR-12 (Acquisition): NATO: E-band, IEEE: S-band. Track/Fire-control: NATO: J-band, IEEE: Ku-band. HQ-7B (FM-90) [CSA-7 Sino-Crotale]: Acquisition: ??? Fire-control: NATO J-band, IEEE Ku-band. MIM-23B I-HAWK PIP Phase 1: AN/MPQ-46 HPIR: NATO H/I-band, IEEE: X-band. AN/MPQ-50 IPAR: NATO C-band, IEEE: L-band. AN/MPQ-55 ICWAR: NATO J-band, IEEE: Ku-band. MIM-104C Patriot PAC-2: AN/MPQ-53 RS: NATO G/H-band, IEEE C/X-band. NASAMS II: AN/MPQ-64F1 Sentinel: NATO H/I-band, IEEE X-band. Rapier/Rapier FSA: Dagger (acquisition): NATO J-band, IEEE Ku-band. DN 181 Blindfire FSA: NATO F-band, IEEE S-band. S-75M/V1 Volkhov [SA-2D/E Guideline/Guideline Mod 3] SNR-75M3 [Fan Song-E]: NATO G-band, IEEE C-band. RD-75 Amazonka: ??? S-125M Neva-M [SA-3B Goa]: P-19 Dunay [Flat Face-B]: NATO C-band, IEEE UHF-band. SNR-125M [Low Blow]: NATO I-band, IEEE X-band. S-200M/VE Vega [SA-5B Gammon]: 5N62V [Square Pair]: NATO H-band, IEEE C-band. S-300PS [SA-10B Grumble]: 5N59S/36D6/ST-68U [Tin Shield-B]: NATO E/F-band, IEEE S-band. 5N63S [Flap Lid-B]: NATO I/J-band, IEEE X/Ku-band. 5N64S [Big Bird-B]: NATO E/F-band, IEEE S-band. 5N66M [Clam Shell]: NATO I-band, IEEE X-band. SON-9 [Fire Can]: NATO E-band, IEEE S-band. ZSU-23-4 RPK-2 Tobol (1RL33) [Gun Dish]: NATO J-band, IEEE Ku-band. If we ever get the P-37 implemented as a functional unit (also a primary target for the Shrike), that'll be a NATO E/F-band, IEEE S-band radar. Note that in many cases (Scrum Half, Straight Flush, Land Roll, Domino 3D/MPDR-16 etc), DCS treats the 2 radars as 1 system, not sure if that'll change, but I've listed everything here for completeness. As for naval radars, I'm not sure it's worth listing them all (though I'll probably do it anyway if I get around to it); a decent amount of them are completely undefined, use the definition from a land-based radar or from another different radar. For instance: the AN/SPY-1A (Ticonderoga), AN/SPY-1D(V) (Arleigh Burke) and Mk 92 CAS (Oliver Hazard Perry), all use the definition from the AN/MPQ-53 from the Patriot; the 4R33 Baza [Pop Group] uses the defintion from the Land Roll; the 3R95 Podkat [Cross Swords] from the Scrum Half. One fire-control radar I can name that isn't reused from something else though is the Mk 95 illuminators, used for NSSMS/IBPDMS (MRS-3 and Type 909 on the Leanders and Invincible respectively also uses this definition), this is a NATO I-band, IEEE X-band radar.
  8. You can get a glimpse of it in the pre-order trailer - there appears to be a long-nosed one and a short-nosed one.
  9. This feature looks to be using the fusing window, which is configurable from the rearming/refueling window during missions. Having it be able to be set in the mission editor would still be useful though, for instance when air-starting. EDIT: BIGNEWY confirmed on hoggit that this will indeed be the case, so you'll be able to set it either in the mission editor or during a mission from the rearming and refueling menu.
  10. Really happy with the higher fidelity and more realistic approach to the Shrike’s seekers
  11. Yes, there are several automatic bomb delivery modes, the 3 main ones are Dive Toss, Dive Laydown and Laydown. The modes are more involved than what we’re used to in 4th generation aircraft - as Smyth said the WSO needs to designate a point on the ground using the radar EDIT: actually this is mistaken (toilet2000 is correct) - the radar is used to compute slant range, but in the -34 for the F-4E, the radar is aimed with the optical sight (and all diagrams state that the target is momentarily tracked visually, the bomb button is then pressed and held and the required manoeuvre performed, the bombs then release automatically as set. However the WSO also needs to input the drag coefficient of the bomb into the WRCS and for releasing multiple weapons a release advance (and not just quantity and interval). The release advance can be used to begin releasing bombs before the calculated release point, allowing you to specify exactly where each bomb in a ripple lands. EDIT: In offset bombing using a radar identification point (RIP), that's when the WSO needs to lock a ground target.
  12. I have plenty of storage. Why should I fill it up with stuff I don't need? Oh really Sharpe, is it? I take it you think the module manager is curtailing and complicating the development of the game, effectively asking ED and other developers to stop making modules, maps and campaigns? Oh so you're actually in favour of this, then? And are just arguing against it, for, reasons?
  13. Do you know how much it costs to delete files you don't need? Absolutely, freaking, this.
  14. Welp, that's 2 shots, let's see how long you keep this up.
  15. Oh yes! You're absolutely right! It definitely isn't flat.
  16. Meh, why not. And while we're at it, it would be nice if it could come to ships as well.
  17. Exactly - don't get me wrong there's plenty of additional liveries I would want to install, should they be developed (such as Tomcat liveries appropriate for the Saratoga, Ranger and Independence, more liveries for the S-3B and B-52H, just to name a few examples). But there's also others I don't use and don't see a need for. I've also made small fixes to some of the description.lua for some liveries, those fixes will get overwritten or the liveries will get duplicated each time I run a repair. It doesn't take a lot of time to copy over the fixed files, but it's time that certainly adds up and it's time I wouldn't need to spend if there was a livery manager - I would only need to do it the once. Whichever way you slice it, the current system caters for one group of people, a livery manager would cater for everybody.
  18. And if it was an opt-out system (which I'd argue to be preferable), users wouldn't be forced to download extra liveries at all - they would need to do precisely nothing and they'd have all the liveries available, completely unchanged from how it works now. That way the only people who would be "forced" to do anything at all, are those wishing to opt-out of whatever liveries.
  19. Oh yes and don't get me wrong - you can find images (although sometimes not many) of gas turbine ships producing smoke (usually whispy, cloud-like stuff)but presumably this depends on throttle setting, ambient conditions and as you described, when starting. Of course none of that is accounted for in DCS - I just wanted to point out that probably 99% of the time a decent amount of ships in DCS should either be producing 0 or only a very small amount of smoke (even for oil fired ships).
  20. If there was a livery manager, that allowed you to select which liveries you have installed, that would be perfect. Even if it was just a blacklist in a configuration file to prevent them from being redownloaded every time an update or repair is run, would be perfectly sufficient. The aformentioned repair and updater utilities already have a way of determining which liveries are and are not installed, as well as those that have been modified, so as to redownload only those either not present or modified - so all the underlying functionality is already present in a fully working state - all that's needed is a way to control which livery files to exclude. Personally though, I think by default, it should install everything, as it does now, so that only those wishing to remove liveries would ever need to touch anything. For everybody else, they wouldn't need to do anything. And before somebody inevitably brings it up, storage space being plentiful and cheap doesn't justify why people should fill them up with files they don't necessarily need, want or use. For a fun game I suggest taking a shot everytime somebody brings that point up. I have plenty of storage space available - why does that mean I should fill it up with unnecessary files I don't need or want? And also before somebody brings it up, no, this request absolutely would not mean that livery development would need to stop or that livery development would be hindered - not in the slightest. That's non-sequitur nonsense and I've no idea where it came from. If the module manager as it currently exists doesn't prevent or hinder new module, terrain, or campaign development, then something like this wouldn't do the same for liveries either. The only other argument is that liveries might sometimes be something you want to have enforced, for instance, to prevent cheating - that's absolutely something I can agree with and in such a case, there's good news! Like the repair and updater utilities, there's another system designed specifically for this purpose - the integrity checker. I would be absolutely fine if liveries were something the integrity checker checks for, at the discretion of the server owner (for instance a checkbox for either enforce stock liveries or enforce host liveries).
  21. I absolutely love reading these incredible update reports! The A-7E is definitely a module that I'm incredibly excited about!
  22. Well to be honest, some of the affected ships shouldn't be producing smoke anyway, especially stuff that's powered by gas turbines.
  23. Wanted to bump this request, they're both very prolific radars that would fit on many of our current and upcoming maps (Caucasus, Sinai, Syria and the Kola map). Especially the P-35/-35M/-37, which is still used by Syria and Russia (and can still be seen at EWR sites in Egypt, as recently as 2014, so well within the era of the majority of our modules), at locations our maps cover/will cover. The models for these 2 (and the DRL-7 ASR) are perfectly adequate enough as is, all the P-37 would need is the mound it's on deleted. Past that, all that's needed is a .lua definition for them and there's plenty of sufficient information online for what DCS requires. We only have 3 other Eastern EWRs and 2 of them are decades old models dating back from Flanker 2.0 and the other one can only be used as an acquisition radar. What's even better is that the P-35/-35M/37 would be a much more appropriate acquisition radar for the SA-5 than either the P-19 or the 5N59S.
×
×
  • Create New...