Giskvoosk

A couple suggestions on Swedish Delivery: 1. Add a certain time buffer between the removal of all SA-2 threat and the bomber spawn. It makes more sense if the escort flight could clear the path in advance, instead of scrambling at Vody in the meantime bombers are already directly overhead at 36k 2. Further tuning of AI bomber flights: forbid bomb jettison on B-52 / change reaction to threats /speed up to M0.8+ ... 3. Add dedicated air-to-air Viggen slots to unlock as bomber escort, preferably with some advanced weaponry. For one it fits more the story telling. Also at height F-5 is underperformed, and underarmed against intercepting MiG-21bis by a wide margin. Specially headon with R3R brings guaranteed loss to bomber flights. The airframe performance deficit contribute to the awkward situation where F-5s could not force its skillful red opponents into defensive. Thoroughly enjoyed the last two runs with the remake of the mission! In the first run I got the vague hint about the Swedish part in the mission. But not till I wiped out the target SAMs with F-5 did it occurred to me that the title suggested the Viggens were the ones to carry out the mission. Or at least my callsign made up for that Thanks for the effort. I would like to know the feedback from the other side as well, thanks in advance. IKEA 24-7

Zero anti-aliasing setups do attenuate the problem but its not solved, both cases significant enough to tell still. I invite you to take another look at the f-16 livery again, at 100% zoom. if you still insist there's no profound problem with the stock one, I'd thank you for sharing your opinion then.

Upon removal of mipmaps, the base color has also been tuned to a higher contrast, which could be attributed to improved readability. Two variable here, can't tell which one is the key factor unless we set a control group. In terms of aliasing artifact, no offence to the author, it's been made worse.

Just read the main post. Certain cockpit textures are not embedded with mipmaps. And I've highlighted the sectors that are affected. Yeah I'm aware of its definition, but mipmaps are really needed in DCS. It's not that I'm nitpicking or something, you take a look. Screenshots are taken in Modelviewer, unscaled. MSAA set to x4. Exhibit A: Notice the altimeter windows, and the labels, and the markers on heading/course adjustment knobs. When leaning back in the seat there're indeed some undesired view effects you talked about. The bottom ones are from my fixes. Exhibit B: Not huey-related but just to demonstrate what artifact could be caused by lack of mipmaps in the DCS. Take the example of a stock F-16 livery, 152nd_Fighter_Squadron. The majority part of the textures has no mipmaps at all. The aliasing artifact is quite distinctive.

I've already modded mine to add full mipmaps as a workaround to get rid of the jagged line artifact. For the reference incockpit-wise I'm using the highest possible graphic setup barring SSAA and the aliasing is beyond mildly annoying when .dds is lacking mipmaps. Dunno what does it have to do with low res cockpit...? Or maybe .dds textures are rendered differently on other settings

Have just been from Two Towns. Situation report: you cannot hill start nor hill climb in track vehicles, namely M60s, BMP and Shilka. T-55 can but still missing engine sound. Also cant speak about units outside the mission. CA currently is screwed up beyond repair, you can't really soften the tone. By "hill" i mean at the elevation angle shown below, M60 cant climb up from standing still.

If i may chime in, from my earlier mission planning I've been searching for ideal EWR deployment for the Blue. The one presented in the game play was actually tested then discarded. My conclusion is to place the radar down here for the optimal coverage. Shame Huey pilots all been busy transporting equipment to the two airbases. images shared from early mission planning

Just read through the post. Rossmum what a mad lad he was in that mission Good job commanding the Redfor both yesterday and the previous weekend! From the opposing side I've been enjoying every minute of the missions.

Well the arabic force is fighting against rivals of IDF's caliber, the Red should expect israeli to conduct a strategic strike on the nuke crates when the photos of the target area are obtained. I always speak highly of our virtual IDF brothers in terms of strategic ISR. Prior to the first campaign, a 1:1 chemical-complex mock-up including the 3 identified nuclear weapon crates was built based off the photogenic intelligence. No less than 50 sorties were conducted should the nukes be eliminated in the first blow, which was expected to be within the first 15 minutes of the mission, turned out to be 22 minutes due to several human error from the sole striker F-5. By the way, a fail-safe plan was also discussed in case the nuke was delivered to Tha'lah. Here I can share some early mission planning first scripted on 2nd March, now that the campaign is over: Strike Package A demo: ideal Blue EWR coverage & SAM ambush demo: But why prioritize the denial of the third Red objective? The reason being deducted from available intel the Blue is at a disadvantage strategically: A) Judging from the wargame simulated by our virtual IDF (again, prior to the first campaign), the aggression of the Hinds from either sides of the Bekaa Valley (both Naqoura and another FARP) can be hardly deterred effectively, not to mention the aggressing ground force and the presence of MiGs. The Red was expected to have a upper hand over 2 bases in the valley in about 30~50 minutes earliest, however in the actual gameplay Mike Delta managed to stop that from happening despite the clear lack of F-5 CAP over the valley in the first hour of the first campaign. B) The terrain masking provided by the mother nature greatly shorten the alert time against the nuke-striking MiG, should the MiG stay undetected by blue EWR until the final 25 mile sprint to Haifa industrial complex; furthermore a relatively low chance SAM interception is excepted even after it reaches west of Sea of Galilee. Later was verified via the mission file of the first campaign, Hawk site could neither managed to intercept nor even react to MiG-21 flying M1.1 NOE all the way towards the target, suffice to say it was one way ticket to Haifa . On the other hand to effectively execute ground attack on 4 Red observatories, the Blue need to establish regional air superiority unfortunately that was not the case in the second campaign or the later half of the first one. The whole point of blinding the Red radar coverage is to conduct better fighter sweep in the AO for the ground pounders. For me as a striker/cap type of F-5 pylote there's absolutely no point of continuing the attack on observatories knowing the constant presence of 2 or more MiG over the Valley or near the Sea of Galilee, and the risk is too high to be justified. Nothing intended to "annoy" anyway although it might be perceived as such. There were way too much for the blue to handle, so desperate time desperate measure. Hope you could understand. Hope to see the mission modified in a better form in regular rotation on the server. IKEA 24-7

Sorry i'm a bit lost here, neither did i pay enough attention in the intense gameplay. So there would spawn a 4th crate (or more?) if the Blue managed to destroy 3 crates which was suggested in the mission briefing?

There was another? One in the wood was destroy in the first 10 minutes. Then the other two crates between two 57mm were destroyed in subsequent raids and BDA confirmed it. Unless there was a forth crate, or possibly desync, maybe?

As suggested in the title I've noticed the lack of mipmaps in the following cockpit textures which graphic-wise results in jagged edge. Except for UH1_scales_c.dds that has erroneous ones, the rest have no mipmap embedded at all. affected files: affected sectors: stock textures (notice the jagged edge): affected sectors visualized with magenta overlay: after my quick fix: P.S. I have no idea if anyone else has had brought up this persistent problem since the files are last modified in 2018. The mipmaps issue should cause people to have trouble reading some stuffs in the cockpit. Apart from the interior, some external skin namely the Hellenic AF ones also lack mipmaps, but to be honest the Greek skins across all modules have such problem more or less. Anyway lets focus on the issue here hope we can address this bug in this decade.

Thanks Mate That's very promising for sure, have your word. Also thanks for the feedback!

As title suggests its pitch black in this area, either improperly baked or overlooked. As a result the radiator is shadowed in most cases unless headed directly towards light sources. Quick adjustment can be made to give it a facelift in the said area as shown below, but i suggest the art team regen the AO map to make a proper correction.

Bump Although on the receiving end it never occurred to me .50s are even slightly underpowered, i'd love to see a historically accurate loadout

Well done all contenders!

86th FS, 79th FG, "The Trojan Warhorse" v1.1 (current version) (2021/03/17) https://www.digitalcombatsimulator.com/en/files/3315377/ @BoNidle Took me past 4 days to rush through my version and never realized we were on collision course all the time Gotta admit you sir did an impressive work! --------------------------------------------------------------------------------------------------------------------- v1.1 (current version) (2021/03/17) Added new incockpit kneeboard texture to match the one on the external model; re-adjusted mipmaps for 4k textures; no further change in other 8K texture files V1.0 initial release

509th FS, 405th FG, "Chief Ski-U-Mah" v1.5 (current version) (2021/03/17) https://www.digitalcombatsimulator.com/en/files/3315096/ changelog: v1.5 (current version) (2021/03/17) Added new incockpit kneeboard texture to match the one on the external model; re-adjusted mipmaps for 4k textures; no further change in other 8K texture files v1.4 Fixed ingame display names; adapted new method for downscaling, used to be too sharp at distance; no further change in 8K texture files v1.3 teeny tiny fixes upon previous version v1.2 teeny tiny fixes in P47D_Fuz_Rear(early)_normal.dds and P47D_Fuz_Rear(early)_roughmet.dds v1.1 US roundel added to the intercooler interior (thanks to Art-J for pointing out), with ambient occlusion channel adjusted for said area; folder/entry title fixed V1.0 initial release

Greeting gents, im currently working Jug's livery and i came across a technically issue. As we know the Jug comes with 2 types of 3D models that can be distinguished from the dorsal fin, which isnt featured on early D30 variant. As a result the two 3D models mount different textures. Heres the situation, the bort number layer across the tail sector picks up only one set of those textures, and is NOT compatible with the other variant. They can be mounted correctly, but only one or the other: My question is, is there a way to differentiate what textures are to attach, in the description.lua? for instance if {a/c type is early D30} then livery[#livery + 1] = xxx end So far i have given a try of variables like submodel or ShapeName etc. still wont work in this case Any of you livery makers have idea how to get it done? Any help is appreciated