Retnek

Please set (key-combo just examples most probably not use) a) Jester Command: UHF Radio > Freqency Mode > Preset (keyboard=) RShift + RWin + M b) Jester Command: UHF Radio > Channel > Comm > 1 (keyboard=) RCtrl + RWin + 1 c) Jester Command: UHF Radio > Freqency Mode > Manual (keyboard=) RCtrl + RWin + M Do all klicks below from pilots seat with "Toogle Radio Command" = green light off = radio settings under WSO-control klick a) radio at WSO-place is set to "Freqency Mode = Preset" = OK klick c) radio at WSO-place is NOT set to "Freqency Mode = Manual" = BUG klick b) if radio at WSO-place was set to "Freqency Mode = Manual" it will be set into "Freqency Mode = Preset" and "Channel =1". So that overrides the "Manual"-position of the switch and chooses "Preset". But switch at WSO should remain "Manual" until Pilot sets it to "Preset" first = BUG

Thanks for pointing on those mods. I know & use them, but both are a stop-gap solutions 1) it's a mod of core-files and will fail at servers with strict script-enforcement. Not a big problem right now, but ... A modification by the gamma-table alone gets rid of that GREEN. I gladly pay that price on Normandy 2, but it still results in a somewhat strange colour composition. Anyhow, it's my day-by-day option and I'm glad we have it. 2) Barteks Vivid Normandy changed the gamma and according to that a lot of textures. Sadly a core-mod, too, with a much more convincing result imho. Sadly modified textures are excluded on many / most servers. So only single-player only for this mod at the moment. First choice when playing solo-campaigns. But only thanks to fine add-ons by Morpheus Bartek's mod remained usable after the last map-update. Now another change is coming up - good news and very welcome. Now again Bartek and / or Morpheus have to cure that GREEN ... I prefer a permanent solution by Ugra. Looking at that GREEN while developing must hurt them, too.

Thanks for the update, really! But could you please use the chance to naturalise that striking GREEN of the Normandy-map? This flashy 150%-spring neon-green imho kills immersion.

Thanks for the TER-racks and the weapons to realize cold-war Luftwaffe-sorties. Could you please enhance the "F-4F-options" with the SAMP-250KG-high-drag-bombs? Looking for sources (or traces) of the Luftwaffe's-use of Matra-250-kg-bombs one regularly stumbles over the retarded model. From the mid-1970s on Fiat-G91 or F-104G until recent Tornado-sorties. Corresponding threads in scale-model-builders forums, former Luftwaffe-groud-crew reporting and so on - it's the retarded model of the Matra-250-kg-bomb. That model fits best to the BL755, too - specially developed to be dropped as low as possible. (Yes, those balloon-retarded Mk-82 might fit to the job, too. Somehow ... but it's not the same! Not really ... if there's a little time, please)

Here's a small group of haters blowing up up their personal disfavour about a 3D-models presentation. Over month now there's nothing new- just the repetitive pointing on unbelievable disappointing cosmetics. Others told them they're fine with that level of aesthetics. Positions exchanged about a topic of minor importance. Polychop took notice of the displeasure, they will react according to their priorities. That's it, usually. But some guys here feel the need to cultivate an obsession. Seen them starting a comparable flame-war against EA because of the outdated and dishonourable impression of the Huey? THE iconic helo-warbird - it's graphics are imperfect, too! How they endure the worst offence against quality-standards in simulator-business ever? This thread just feeds some trolls who campaign against Polychop over many weeks now.

Nothing new since 5th of June and still on his crusade for the cosmetics, really? At least he made some friends on that journey, too. If the notorious moaners here spent the same time flying the Kiowa than whining in the forums they'll be well below 50 Cent per hour of flight-time. Extremely low operational costs for such an incredibly complex module, right? Polychop, even the most pig-headed critics from time to time point on errors worth your time. Try to see it that way, please. "Son, what's wrong with your present? You got the model-railway you asked for - a platinum-beginners set! Big locomotive, 20 waggons, 30 m of tracks, 10 switches and a dozen buildings - so what?" - "The locomotive is blue, NOT RED!"

Gunny - tanks ahead! Confirmed, Frau Oberleutnant! Six missiles - six kills, right? Absolutely, Frau Oberleutnant! Less then six kills ... means I catch up by foot, Frau Oberleutnant! Good Gunny! (she comes across a bit strict, but brought me home any time) Very well done - never without her, I promise!

"deceiving" because of 3D-cosmetics and textures? Your "critics" lack arguments. Polychop, just go on, please. If the functions and procedures of the Kiowa have been completed, polished and updated twice, you might consider some face-lifting, too.

LOS of sight was given, went in from 20 km out until the downed pilots popped the smoke. No joy with NDB. Interestingly Ciribob in his CSAR-script excluded the fixed freq. (Just pointing on it, I'm a lua-moron) https://github.com/ciribob/DCS-CSAR/blob/master/CSAR.lua (line 1950 ff) Maybe worth another thread, just a draft: why not using SAR-radio analogue to smoke or flares? That's how it worked in real, too. Most of the non-satellite SAR-radios used high VHF (243 Mhz). In contrast to the MF-beacons we use in the CSAR-script now a freq. of 243 Mhz really depends on LOS. Beacon-mode usually was switched on by downed pilots after voice-contact. Just for the final approach of the SAR-aircraft. (for radios see https://www.greenradio.de/sar.htm) So it might be worth to re-design and simplify the CSAR-script for the aspect of radio-handling? Just one freq., it's beacon-mode activated after radio-contact (via F10?) by SAR-aircraft nearby (20 nm or so)? A few years ago I've done some test-missions with the UH-1 and the Mi-8. Both were able to come along with 4 active beacons sending nearby simultaneously. Usually the nearest source was strongest and displayed on the instrument. Would need some further testing now, true. But on the long run it might make life easier. Homing on a VHF-frequency at 243 MHz would limit the CSAR-helos to UH-1 and Mi-8 (Hind maybe?). And it might "spam" all the aircraft-radios listing to that emergency-freq. by default, too. Would be easy to avoid that kind of trouble choosing 222 MHz or even a frequency in the range of the MF-NDB, 666 kHz f.e. 24.06.11 add-on: thx @cfrag for some interesting hours with radio-stuff! 243 MHz is no way to go, no range limitation, would spam radios all over the map. Using the NDB-range offers more chances for mission building - checking Caucasus-map 666 kHz has fixed NDBs nearby. But 777 kHz has no neighbours for +/- 35 kHz. With the Mosquito one needs at least 20 kHz spacing for the radio to separate two NDB somewhat solid. That should do.

Hint / Question: the NDB for CSAR don't seem to work. I receive the airfield-NDB in the HIP without a problem. Original mission-file on a dedicated server except trigger-zone "stopGapConfig" from "onStart = yes" to "no". No add-ons or mods. btw: Is there an option to limit the NDB-frequencies-range to the lower range < 999 kHz to please the Gazelle-pilots (it's ADF is broken anyhow afaik)? And exclude the freq. of the airfield-NDBs, too? Since the NDBs in DCS are a pain in the a.. regularly it's just a nice-to-have.

I see, thx again. I bet you already adapted these lines from your readme.pdf accordingly: "As of version 1.2 of Expansion, this is merely recommended for a better user experience. If SSB is not running on the server, Expansion now supplies its own lightweight mission-based (instead of server-based) SSB-service."

Ok, I see. for me "onStart=no" does the trick and airfield is war-like empty, too. Thanks! Sloppy writing in the first post - just for the records: I checked starting the mission-file in single-player-mode, naturally. Here everything works fine, so it's dedicated-server-only.

Cfrag - I (we?) have a problem starting "Expansion 1.3" on a dedicated DCS-server. There is no "DCS-SimpleSlotBlock" by Ciribob active on that server. Researching the problem DCS-client and DCS-server were set to "plain vanilla" except the persistence settings in "MissionScripting.lua". For my setting given above your "leight-weight-slot-block-solution" results in helos crashing at spawn directly at the platform. Like they are dropped from 1 m height to the ground. Gazelle looses main-rotors-blades, Huey breaks skids, Hip fatally damaged etc. Changed the trigger-zone "stopGapConfig" from "onStart = yes" to "no" cures the problem for me. It SEEMS the leight-weight-simple-block-workaround is not perfect yet. I think I studied your "README or die.pdf" and the forum here thoroughly - it finally resulted in the workaround "onStart=no". But I tend to sloppy reading, could you please check? BTW: For me (with some serious nerdy realism-rivet-counter-affinities) platforms with a dense population of aircraft every 20 m definitely don't look like a front-line-airfield. That's appropriate for a Nevada training range. But front-line-spawns need 100 m spacing minimum or you'll get a serious problem with the stations commander. No serious critics intended, please! It's cosmetics and up to the artist.

Daddy: "Santa Claus did not pass the chimney - presents just one day later!" kids room: "WHAAAAT?"

Stumbled over this topic by chance - just a few years old, not long ago a patient DCS-follower, right? Please check https://vaktelforlag.se/produkt-kategori/english/ The volumes of "Black Cross vs. Red Star" are on hand again! Enhanced editions and new volumes, too! The books are THE standard on that topic and an immersive reading, too. (should end the daylight robbery by second-hand gangsters )

Das - aus berufenem Munde - könnte helfen:

Imho it'll be fine if you offer the choices the pilots had in flight, too. The present solution is definitely better than it has been. That vague option "Function delay mode" just for some types of fuses is quite confusing. Maybe all I need is more distinct presentation of the options and/or another wording - suitable for a non-native speaker.

No photoshop, both screenshots during a single-player-session yesterday, ca. 21:30 GMT. The level of detail is just like the first pictures in this thread from 2020, so it might be old content on that PR-billboard. Anyhow - a good reason to point on the profound need for an analogue Delta-Mirage. The F-1 is marvellous, a true gem. Now the next step to a classic Mirage delta-wing, please ... The upcoming Kfir is a close relative to the Mirage V - the good old war-hero Mirage III would be a proper choice. I personally would love to see the Mirage IV, but she's far away from the mainstream.

Testing some stuff SP in the South Atlantic, I gazed by chance at a billboard - Airport-Road, Port Stanley airfield: HELLO - who's this? Isn't "proximamente" Spanish for "soon"? Just a remnant from the early days of developing the map or is it a hint? I like that kind of humor, btw:

Very nice skins, thank you! A detail: just by habit I placed the files via OvGME in the user-part of DCS (something like "ssd:\users\username\Saved Games\DCS\Liveries\Fw-190D9\...") and it works fine. Later I found your advice to place them into the core-part - like "ssd:\PathToDCScore\Bazar\Liveries\FW-190D9\...". Is there any strong reason to place the skins in the core-area? During the last few years usually we were advised to place add-ons user-owned-part in "saved games" if possible.

It was fixed with DCS 2.8.3.38090 Open Beta, at least for me.

Helpful note - thx! I prepared 3 mods in OvGME with the factors 0.2, 0.4 and 0.6 (line 101 in DCS MT 2.8.3.37854 now) - easy to exchange while testing different planes and light regimes.

Sorry, in contrast to this thread imho the fuses still aren't right. First one is easy. The German fuse 25c had a long "Vz Mode function delay" of fourteen (14) seconds, not 8.5. Since the delay is relevant for attacking in larger formations it should be corrected. Like it was done by the Germans advancing from fuse-model 15 to 25. Please check the documents given here: and here: I learned in mission-editor one should use the "function delay mode" "fixed" to set the fuses, not the "variable" one. So for fuse type "Zünder 25C" in mode "Fixed" there is given this pattern: oV Mode Function Delay (oV = no delay) = 8.5 sec mV Mode Function Delay (mV = with delay) = 8.5 sec Vz Mode Function Delay (Vz = retarded mode) = 8.5 sec Sturz Mode ARM Delay = 80 ms Waagerecht Mode ARM Delay = 80 ms "Function delay" here is the time from impact of the bomb to it's ignition. "Arm delay" is the time the fuse needs after leaving the bomb-rack to change the status from "safe" to "armed". For the fuse-type "Zünder 25C" in mode "Variable" there is given this pattern oV Mode Function Delay (oV = no delay) = 0 sec mV Mode Function Delay (mV = with delay) = 80 ms Vz Mode Function Delay (Vz = retarded mode) = 8.5 sec Sturz Mode ARM Delay = 80 ms Waagerecht Mode ARM Delay = 80 ms Historically correct values for fuse 25 for an (extended) table should be (sources see above and below) oV Mode Function Delay (oV = no delay) = 0 sec mV Mode Function Delay (mV = with delay) = 80 milliseconds Vz Mode Function Delay (Vz = retarded mode) = 14 sec Sturz Mode OV ARM Delay = 3 to 6 sec Sturz Mode MV ARM Delay = 5 to 10 sec Waagerecht OV ARM Delay = 3 to 6 sec Waagerecht MV ARM Delay = 0.7 to 1.6 sec For the time-to-arm this table gives detailed numbers: I know the fuses are still work in progress. Your way displaying the values in a "variable" and a "fixed" mode will add to confusion, too. Whatever I try - I'm not able to find a way to prepare my Anton via the mission editor to drop bombs historically correct using the mainly used fuse-type 25. Add-on 15.03.23: Here's the most detailed documentry about German bomb, fuses etc - always worth a look for British and US-documents and procedures, too. Sorry, in German only and a somewhat strange HTML-setup ... http://michaelhiske.de/ German fuses: http://michaelhiske.de/Wehrmacht/Luftwaffe/Zündervorschriften/StartSeite.htm Zünder 25 f.e. = 152/8 & 152/22 & 152/27

Thanks! Very nice - that's a real improvement for the WW2-scenarios. Here's two pages from the Luftwaffe's service regulation LDv 5-1 from June 1943 - hopefully useful: PS: don't get me wrong - it's already fine as it is! Looking at the videos you already implemented some typical details and differences between Allied and German airfields.