Northstar98

Meh, why not. And while we're at it, it would be nice if it could come to ships as well.

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.

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.

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).

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).

I absolutely love reading these incredible update reports! The A-7E is definitely a module that I'm incredibly excited about!

Well to be honest, some of the affected ships shouldn't be producing smoke anyway, especially stuff that's powered by gas turbines.

+1

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.

Nope.

It's something that's affecting all new models in the new format, under CoreMods\HeavyMetalCore - the B-1B, B-52H, S-3B and S-3B tanker, as well as LPWS are all similarly affected, whereby they appear to be lower quality models than what's shown in promotional material. New models released in the previous .edm format such as the Kh-29L/T, Kh-59M/MK, new BLG-66 etc are unaffected and look to be modelled to perfection (even including animated seeker heads for the Kh-29L/T and -59M). In this case the Big Bird radar has antenna elements that look as though they're just a flat texture, whereas in the 2.9 short cinematic, they appear to be higher-quality or even 3D: 2.9 cinematic: In-game: The shot isn't a perfect recreation and the lighting is obviously totally different, but the Big Bird shown in the 2.9 cinematic clearly has higher-quality elements. The new Tin Shield (on the 40V6M mast), is also quite a bit less detailed than the previous Tin Shield that was released over 2 years ago: Here's a shot of the previously added, trailer-mounted Tin Shield: And here's a shot of the newly added 40V6M mast-mounted Tin Shield: Here's another shot of the previously added Tin Shield: And another of the newly added mast-mounted model: The difference in quality and detail should be obvious: There's no antenna elements on the feed or sidelobe compensator/IFF antenna (the latter appears to be floating in mid-air). There are model holes in the waveguides. The turntable and elements of the turntable are quite a bit lower in detail and quality. There's missing actuators/links. What's weird here is that the models shown in these screenshots should be identical - wouldn't it have made more sense to reuse the previously added, higher-quality model, removing the trailer and then adding it onto the mast? Regarding the other models in the new format, there are other examples too: The B-1B: S-3B: LPWS: The same also applies to the B-52. Now don't get me wrong, I don't these models are bad in any way, in normal gameplay these almost certainly won't be noticeable, but they definitely are lower quality and not as detailed compared to both promotional material and existing assets. Personally, I'm leaning on this being a LOD issue, where it looks like, for whatever reason, the LOD1 model is being used instead of LOD0, but as the new format seems to be a (possibly encrypted) container that the modelviewer can't open (and as there are files needed but cannot be accessed also in the containers, making custom liveries is also impossible). It would be nice to get an acknowledgement of this though, whether this is in-fact an error or whether it's intentional, as the other thread discussing this same issue (although focusing on the B-1B) also doesn't appear to have been acknowledged yet.

Ahh, I see. I was using open image in a new tab rather than opening the link directly as unfortunately, most if not all images from newsletter behave that way.

Can't argue with that

They all look to still be there on my end.

Ah, I see. To tell you the truth I was mostly looking at textures (it's quite difficult to see undulating terrain on a 2D satellite image), but yes - there I am with you. Hopefully Orbx can make the geometry more like the real thing.

In what way? And hard disagree, Rovaniemi (1st screenshot) and Olengorsk/Olenya (2nd screenshot), look very good to my eyes - I think Orbx has captured the look (particularly of Olengorsk/Olenya) very good comparing them with satellite imagery.

They never did IRL, the closest thing is the Batch 3A conversion to 5 Leanders (F57 Andromeda, F75 Charybdis, F60 Jupiter, F58 Hermione and F71 Scylla), completed from the early to mid 1980s, which added GWS 25 Sea Wolf. Yes, though it is wrong Block. Both Condells IRL feature Mk 15 Phalanx Block 0. However, in DCS, they're depicted with Block 1B (and it isn't a trivial difference (see here for a break down), or at least it wouldn't if they were modelled properly). Yes - it never had a CIWS IRL. It doesn't - it's depicted as it was initially - accurate to the Falklands War. In September 1982, after the war, Invincible was retrofitted with 2 Mk 15 Phalanx Block 0 CIWS, which during its 1986-1988 refit, were replaced by 3 Goalkeeper CIWS.

Well, in that case you'd also need a 60s/70s aircraft carrier We have a post SLEP Forrestal (so mid 1980s at the earliest), pre-SLEP it had significantly different weapons and sensors (and how far back you go, the more different they get - no Mk 15 Phalanx, BPDMS instead of NSSMS/IBPDMS, 5"/54 Mk 42 guns). During Vietnam, Forrestal would've had 4 5"/54 Mk 42 guns. The Ticonderoga we have is mid-to-late 2000s at the earliest (Mk 38 Mod 2, Mk 15 Phalanx Block 1B), the Arleigh Burke, at the earliest, ranges from 2007 with DDG 101 to 2018 with DDG 116.

Yeah, would really love if Heatblur's Forrestal got the supercarrier treatment for people who own it.

On the South Atlantic map there is (or perhaps was) a nearly vertical, smooth, uniform, light-grey band where the sea meets land (even from right up close), making the landmass almost look like it's sat on concrete (as you'd expect to see around ports for instance). The sudden, uniform incline, combined with islets that look completely flat and it almost makes them look like they were cut out with a cookie cutter. Of course, real-life shots of the area (Bodø) does show a lighter, rocky band. But it's clearly not uniform and clearly resembles rocks (see this shot of Lille Hjartøya, taken from Bodø, highlights this relatively clearly). However, immediately to the east-south-east of Bodø Air Station, there is an islet (Skanseholmen), visible in the 7th screenshot. In the screenshot, it very much looks like what I described above - looking like it was cut-out with a cookie cutter, looking almost flat with near-vertical, concrete-looking borders. The real thing should like this (more rocky and irregular). Of course, these are still WIP shots and from further away it is a little harder to judge.

In case anyone hasn't seen the post on the official roadmap thread, more WIP screenshots were posted on the Orbx Discord: It looks really good so far - I'm really impressed with what I'm seeing and this will definitely be the main map I use going forward. One thing has got my eye that I don't like though, which is/was also common to the South Atlantic map, if you look where the land meets water, you'll see a sharp, steep, grey incline, which makes it look like all the landmass is sat on a load of concrete and it's particularly noticeable when flying at low altitude. These are all WIP screenshots though, so hopefully Orbx will improve the coastline to make it look more natural (obviously in some areas, such as ports, naval bases and piers it's accurate, but there's plenty of places where it isn't).

Absolutely. System failures are already optional and can be user-configured, the same should be true here. Even ignoring any realism argument, being able to turn off failures is incredibly useful for testing. If you're trying to investigate say, 'x' weapon's kinematics, it's going to be substantially more of a pain if there's some random probability of it just outright failing in the mission. Even more of a pain is if something didn't fail in the mission, but does when replayed in a track.

FWIW, all the modes described for the 5N62 are CW modes. MHI is unmodulated CW, FKM is frequency-modulated CW and there's another one which is phase-modulated CW. All 3 modes can be utilised for missile guidance and they have their respective use-cases (for instances, unmodulated CW offers the best range, but is susceptible to losing track on targets with a low-closure rate and doesn't provide for ranging).

If there's an aircraft landing it comes on. I'm not entirely sure what the threshold is (perhaps when an aircraft commences), but I've definitely seen it come on when aircraft are landing.

Should have at least the E-2 and F, possibly also M. In the pre-order trailer you can see what looks to be a long-nosed Sparrow (such as what's seen on older Sparrows like the E-2) and a shorter-nosed Sparrow as we're used to seeing on the F, M and P.