scoobie

Ooh! Good catch! I haven't read the manual (not that it's too long to read), been too busy making myself comfortable in the cockpit (control bindings) etc., bought the module just a few days ago. Speaking of this manual frequency feature... I guess some multiplayer server owners will ask for a realism option to have the land bases removed from this nav radio (as in other birds you don't have such "cheat" for navigation), but I don't do MP. For single player it's a nice-to-have feature, I guess - if you don't like it, find it lame or immersion-breaking, just don't use it, fair enough. Magnitute (who are since Corsair called "LEATHORNUCKS", haha) - they do like to tinker with radios (I mean first they did those "DIY" NDB beacons for MiG-21, now this.) Oh, and thank you for the "tree" - smart little thing, I'll try it, it's my chance... one in a million, I'll give it a go.

I haven't figured it out, but there's definitely something to it. I've been struggling to get the system to work and it may have something to do with particular frequency you set - probably it is about whether this frequency is already "occupied" by some other station/transmitter on the map or not. If it is occupied by anything else (a "clash of frequencies", so to speak), then - perhaps - the NAV radio somehow "fails safe" to (always) the VHF transmitter on the map with the lowest frequency? Or something like this? It happens to be Anapa in Caucasus (121 MHz in VHF band). I don't claim it's a bug, but it makes you scratch your head especially because you can communicate with the Essex via comms radio on this "wrong" frequency no problem (at least I could!). Confusing. @buur - please do me and yourself a favor and try... I think I've set 118 MHz (if not, it was 119 MHz - either of the two). So, on Caucasus map: - set Essex frequency to 118 MHz, set the unit's name to something strange/unique (e.g. "ESX" or "XXX") so that you can be sure you're hearing your Essex, - set comms radio preset 1 to 118 MHz (top bunch of presets in ME), - set "nav" radio preset 1 to 118 MHz (bottom bunch of presets in ME). And check if it works. It worked for me. --- Earlier, when I set 124 MHz (which is Krymsk), I was getting... I think it was "MNM" (which makes no sense, so maybe it was "ANA"?, my brain is all rust, A is dot-dash, M is dash-dash, I can't remember what I was hearing) and the "bearing Morse code"... I think it was letter "H", 4 dots (rusty brain again) - it didn't change when I was circling around the Essex (sailing near Sukhumi-Babushara I think), so I knew I was receiving a different transmitter, not Essex. Then - out of despair - I tried 124.5 MHz. I don't even know if it's a "legal" channel on VHF, but the result was exactly the same as with 124 MHz. Interestingly, I could communicate with the carrier over comms radio (COMMS, not NAV) - both for 124 MHz and 124.5 MHz - Mother was responding no problem, stating her weather etc. Last piece of the puzzle is the Youtube video I watched where the guy set 124 MHz (that's why I set 124 MHz, too) - I thought it should work, but didn't. Maybe the guy just set ANY frequency for the sake of the video and didn't check if it works or maybe... it worked for him before the patch and not for me after the patch? No idea. Anyway, setting a "vacant" frequency (with no decimals, round megahertz) seems to make the thing work alright.

Look for CMS Hat functions in the manual. There are multiple options at your disposal - start/stop selected program, one chaff, one flare, 6 chaff, 6 flares (off the top of my head). Once you know which of these you want - look for them in the Control Options in DCS.

This happens in multiple ED modules already, I haven't compiled a list, but definitely in: Mosquito's T.1154 transmitter knobs, Spitfire's P.8 compass "lid" (or "setter ring") etc. To define it, an "auto-accellerating control" is a pair of key/button assignments concocted to drive (increase/decrease, turn left/right etc.) a particular knob/lever in a cockpit, in such a way that when you press and hold the key/button, the knob will first rotate slowly BUT it will speed up rotating over time. It will - let's call it so - "auto-accellerate". This comes in handy when the "travel range" of the knob is big and at the same time you need precision when setting the knob to a particular position. Frequency knobs (yellow, red, blue) on T.1154 in the Mossie are a great example. Auto-accellerating controls used to work fine in ED modules (e.g. trim knobs on P-51, they're OK). The key for correct operation is that whenever the control is in the "accellerated" state already (you've been holding a key/button long enough), RELEASING the key/button should immediately cancel accelleration. And that's actually how it used to work long ago in those few ED modules where it was implemented, maybe it was P-51 only, I don't know. It was done right in DCS. At one point in time someone came and messed it up, then his botched code was copied to other modules. Now accelleration is only cancelled by TIMEOUT. Also, accelleration may be incited by only briefly tapping a key/button, or even, funnily enough, by tapping both opposite-action keys/buttons (increase-decrease-increase-decrese). For example, you can "accellerate" the Spit's P.8 compass by tapping left/right (CCW/CW) bindings for this compass "setter ring" on top of the unit. (I imagine it may be some kind of expotential filter, but sorry - it has to RESET on button release). As a result, it is very hard (very slow) to set - for example - a particular frequency on the T.1154 transmitter in the Mossie - try if you don't believe me, but make sure you wait until it auto-accellerates first. If you have to do it a lot, it's real PITA, you say and your kids are listening and learn unneccessary words

Wow, thank you, guys! Silver, TheOne! I was just about to sit down and prepare the required evidence for Silver and there you have it - offline.bin. Never heard of it before. The trick did work, thanks again

Hi folks! Been away for a short while, this morning I updated DCS to 2.9.14.8222, then clicked "offline mode" as I always do and left home. 12 hours later I realized I might need to reinstall old Black Shark 2, clicked "online mode" and - to my surprise - I can't. Screenshot attached. Anybody else? I don't know what error 0 is. Yes, system time on my PC is synchronized to NTP and correct.

It's not a bug, but perhaps a bit of an unfortunate design decision. All audio volume pots in the cockpit (and some other knobs) can be LMB-clicked and turned. Normal thing. The exception is the 4 knobs on the CSC panel which can also be pulled to mute a particular radio. To change volume on CSC: VOL - LMB 1 - RMB 2 - RMB 3 - RMB 5 - RMB NAV A - LMB NAV B - LMB (unused, I think) I think it would be better if all of them were LMB-clicked to turn and those 4 which can be also pulled - be pulled with RMB. I think 83% of the people will keep mixing it up, 69% of the time. I promise to mess it up 93% of time!

Awesome, thank you! We will

I think I put my finger on it. Kinkku is a smart guy, he really is! Instead of being "like animal" and manually write thousand of lines with all those control binding commands, he creates them somehow on the fly (I didn't delve into details, because I don't really care - I just want my KW to be nice to me) and he then just defines them in a shorter, consise manner. This way he can't make a mistake in one particular control command (they're created automatically - all are good or all are bad) and he saves himself dozens of hours of work. THAT. IS. SMART! Anyway, for a reason unknown to me he put "pressed" instead of "down" into his automatic binding-command-creating functions, and "pressed" does auto-repeat. Maybe there's some kind of idea behind it, or it's just a mistake, I don't know. So, an example - what cured my ACK/REC switch - picture attached. EDIT: Correction - there's something more with the ACK/REC. ACK works, REC doesn't. The switch moves correctly, but REC does nothing (it works with the mouse, still). So it's just a general hint on what's going on if you have "holding" or "rattling" switches (when bound to joystick commands). EDIT 2: Correction to correction: "REC" position has a separate bug and it's fixed internally already. null Now, bear in mind that: 1. I imagine he will fix it himself, so there's probably no need to tinker with those files unless you are impatient. 2. Every "type" of control has a separate function - the one I'm showing here is just for 3-way "all spring-loaded" toggle switch (i.e. one where both extreme positions spring back to the middle position). 3. If you dare to do such change(s) ALL your bindings for the same type of control - maybe just one switch, or maybe 8 of them - will evaporate and you'll have to bind them all again. @Kinkkujuustovoileipä - would you mind? Picture below. "pressed" is evil in stateful commands. Also those "else" commands aren't what they should - I'm judging by analogy to other modules. They should go "value_up" and "value_down", not "pressed". I think "pressed" is for things that don't have "their own drive" in C++, i.e. pressed injects a new press command every split second so you can "move just a little bit/increment" a control, e.g. a trim hat, NVG brightness up/down or something. Other than that - they're all "value_up" and "value_down" for "else" commands, or they are only "value_down" for "stateful commands", i.e. "set the in-cockpit control to an explicit position when he taps this button and that's it. That is my understanding (though I reserve my human right to be just dumb ). PS. I will investigate "going to sleep" later.

Thanks a lot, Max! You know... I've been living in the misbelief that "going to sleep" is a universal DCS feature in "else" commands (e.g. "Flaps UP else MVR" - this kind of thing). Even the very term "going to sleep" was coined by LeCuvier, I just stole it from him. Such bindings would always "go to sleep" (under specific conditions, as in my previous post - it's just one example how to achieve "the sleep"). Later, when ED came up with the "JOY_BTN<number>_OFF" feature in control bindings, I quickly rebound all my modules to "stateful commands" and all problems disappeared. True stateful commands never go to sleep. However, in KW some of them do go to sleep, which means they just aren't what they claim to be, only their names in "Control Options" suggest so. They must have been programmed... somehow different. Of course "rattling" and "holding" switches are separate issues from my perspective, but maybe these are just another manifestation of that somehow-different programming? I don't know.

What the heck... I wish I knew what it's all about. "Going to sleep" has been reported by numerous people (e.g. LeCuvier). Can it be the case that it happens to SOME people and not for everyone? I thought it was everyone. If not... why? What's so special about my PC? And some other folks', apparently, but not all of them. But to be clear - have you done it as in the picture (it will probably get pasted at the bottom of my post)? Now the procedure (don't use the mouse, of course): Pilot switches down to SAFE. Switch seats. Copilot switches up to STBY. And... does the switch go up to the middle position in the cockpit for you? null Axes! I use that embarrasing mouse nipple on the TM Warthog throttle. Hmm... I can't SEE it, either, but I can HEAR it. It's only the sound. Can you hear the rattle if you flick the swich up or down and hold it? It's best to check when she's cold & dark.

Hi, folks! Sorry for being clearly disoriented, but I bought KW the other day and... it rocks, but... I heard Polychop was (or is?) to do the "overhaul" of the control binding system. Now, are we after this overhaul already or still ahead of it? My worry is that, regardless of all the bug reports about particular controls, the whole "ideology" for bindings is... not bugged, that would be a wrong word, it is "mistaken". So, in KW the stateful commands rewrite the control state every "control update interval", if that makes sense. For example, bind anti-coll light to a latching toggle switch (JOY_BTN_X for "On", JOY_BTN_X_OFF for "Off" - stateful commands). On the TM Warthog throttle there are many of them, for example speed brakes switch forward. Now, when you flick the switch to turn the ANTI-COLL on, in the module the switch is being repeatedly switched to "ON" 20 or so times per second. In this situation, try to flick the switch with the mouse - the switch will flick to OFF for a split second and immediately return to ON, because the state of your joystick button is continually rewritten into the KIOWA's cockpit. This causes multiple problems. Some switches even "rattle" (ANTI-COLL doesn't), for example this ACK/REC switch. People report that recalling caution/advisory somehow doesn't work (and "it's a bug"), but it's the problem with the switch, not the internal logic of the module. ACK/REC works when flicked with the mouse. If you put the switch to ACK or REC by means of a joystick binding, it gets artificially pressed those 20 times a second or so. This switch does "rattle", the flicking sound begins to play, the switch gets retriggered by the code and the sound is cut and played again from the beginning - hence the "rattle". There are multiple rattling switches (e.g. gun switch once moved through SAFE-ARM-SAFE sequence - it then starts rattling in the SAFE position). Also, the switches "go to sleep", which they shouldn't with "stateful commands". I don't know why. Bind Master Arm (again - stateful commands, separate for "OFF", "STBY", and "ARM"). It's a 3-way latching switch. On TM Warthog you may use autopilot mode switch on the throttle's base. Important part is that middle position should be "physical button(s) off" position. Now, sit in the pilot's seat. Switch the Master Arm to OFF (lowest position, joystick button so-and-so is ON). Now hop in the copilot's seat and flick the switch to the middle STBY position (joystick button so-and-so in the OFF position) - the Master Arm switch in the cockpit won't move. Same with Laser Arm. Stateful commands should be immune to "going to sleep", but they aren't. I've got nearly all DCS modules and NONE works like this. Stateful commands should work "once per hardware control's state change". Like an "event". The events are "he just flicked it from off to on", and "he just flicked it from on to off" - only these "events" should cause the commands to actually flick the position of a switch in the cockpit. Between such events nothing should happen, the code should "run idle", shouldn't touch "arg" value for this particular switch in 3D model. So, there's something very low-level, fundamental, "mistaken" in Kiowa's controls. Hence the honest question - is the control binding overhaul still to happen (which will probably fix it) or it has happened already and now Polychop folks think KW needs only a few last touches, bug fixes to particular controls? In the latter case it's... it's not good, it's all wrong now and it... will stay like this? Other than that, KW is sooo nice and I'm happy to have it. Also, if we're talking about controls in particular, I'm probably the biggest fan of the "inheritence" system in controls that Kinkku came up with! It's awesome! For example, you may use the same controls for OSB buttons ("bezel buttons"?) for both pilot and copilot. If you're in the pilot's seat - these controls will drive pilot's MDF buttons. Jump to copilot's seat - now they're training copilot's MFD (just bind the same controls for both positions). There are so many new possibilites thanks to that system. I've used some in the Gazelle, now it's even more handy in the KW. === Oh, and one tip if I may. Some of you reported that slewing MMS sometimes stutters. If you're a sly dog (like myself) and have bound the MMS laser to a latching switch on your HOTAS (so you don't have to squeeze a pushbutton to 10 seconds) - this is definitely the reason. There may be other reasons, IDK, but this is one reason for sure. Turn off the laser and you can slew MMS smoothly again! Noticed that yesterday.

In DCS v2.9.10.3948 (Dec 4th) the radio channel up/down keybinds both working as "up" still seems to be a thing, at least on my PC.

The TACAN mode knob got bugged as described in this thread, but what you're talking about is unrelated. Overall I quite like how these self-accellerating controls are programmed in F1 (there are more of them than those you mention), but I'd agree their "initial speed" is a bit too high, i.e. when you just briefly tap a button/key. Maybe with the keyboard they would feel fine/ish, but I'm using spring-loaded toggle switches and these are a bit slower to work with than keyboard, so yeah - setting precisely 11 miles of offset or an exact course of 347 is somewhat hard, I agree. As for the solution, I haven't tried myself, I'm not bothered with it too much. I suspect that tinkering with Lua files may not work in this case because these are accellerating controls. This accelleration must be done in code, maybe C++ code, in which case it's hard-coded for us, the users. If that's the case the controls probably treat "value_down" in default.lua as strict binary input, zero/non-zero for off/on, respectively, so any attemps to tune value_down probably won't change anything. EDIT: Wait, I was talking about F1-CE (I fly mostly this version), I think you might have had F1-EE in mind - it has this "IDN" instrument different, with this little bearing/offset switch turned left or right, not a "real knob" as in the CE version, correct? If so - yes, if I recall correctly it's very fast, pretty hard to use with precision.

OK, I solved the problem for myself. In my case the reason for this behaviour was launching a Phantom mission with Engine Master Switches both set (a priori) to ON/forward position. This somehow messes up Jester logic in a funny way (different effects on the very first mission launch compared to any consecutive launch).