scoobie

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

@Zabuzard - yes, what you're saying makes sense, but we're talking about the very first second of the mission. Incidentally, there are two things here. The first one, which is the trouble, is the lack of the Jester menu in the front seat. It used to work no problem, now it doesn't. To correct for that, I just re-launch the same mission - that solves the issue. KrisJ instead hops into the rear seat, invokes the Jester menu from there (which allegedly works - haven't tried myself yet), then closes it, then he jumps back to the pilot's seat, and now the Jester menu works. The second issue, which is not a problem for me, just a strange phenomenon I've noticed, is that on the second mission launch the Jester immediately asks for alignment type, he doesn't do that on the initial mission start. Again - what I'm doing: 1. Launch DCS 2. Lanuch Phantom mission. Observe you can't get Jester menu to show up, at least from the pilot's seat (I use joystick and mouse bindings for that - neither work). The Jester will NOT ask you for alignment type just yet (seems correct). He would ask that later, but not at the very mission start, with no power yet. 3. Exit the mission. 4. Launch the same mission again. Jester now behaves differently - he IMMEDIATELY asks for alignment type, at the first millisecond of the mission. The mission barely loads and you immediately hear that audio amp noise from him, the "talking circle" pops up and you have to answer him. No power attached yet, not a single switch flicked yet. This is just an observation, it doesn't bother me that he asks. On a bright side - the Jester menu now works, so I can ask the crew chief for GPU power etc. It's as if a "part" of the Phantom survives the mission exit, at least briefly (a process/thread or something doesn't get killed, maybe?), I have no idea how it all works.

Hm... after the latest update, I'm having a similar thing. I haven't checked if Jester menu is available from the rear seat, though. Launch DCS, launch a mission with the Phantom. No Jester menu. No bindings work - neither mouse, nor joystick. Now the trick: exit the mission and launch it again - Jester menu is now available. Also, interestingly, on the second mission launch, Jester immediately asks me for the type of INS alignment I want. She's still cold and dark, no action taken on my part yet and this small "talking circle" pops up with "What alignment do you want?" (or whatever he's saying). No idea what's going on. Maybe it's something on my end, though the Jester menu used to work normally some time/update(s) ago.

Count me in! Yes, date/time on my PC is sync'ed through NTP and correct. As it has been for about forever. My only guilt was I updated DCS and bang - could no longer go offline immediatetaly after this update. For me it was the version where the "DCS Launcher" was first released, but I might have overlooked a version prior to it, I'm not sure, hence I don't know which update exactly introduced this bug. Is this even tracked, investigated or whatever? Date/time is NOT a problem here.

While the flashlight does work, it's also true that "plafond lights" (IIRC that's how Russians call them) were nerfed in the Hip a few years ago. They don't illuminate anything except for their immediate surrounding on the ceiling. Prior to that they had been very bright. You know - FLOOD light is supposed to flood the office (with light). It works in Huey, for example, yellow or green, both colors do the job.

Hi, I've updated DCS to 2.9.6.57650 today and I'm getting error 500, but not when trying to log-in/authorize (this works), but when I'm trying to switch to offline mode. I don't get it. I am in online mode, I click that antenna button on main DCS screen to switch to offilne mode and... error 500, "Can't enter offline mode". When I repeat this, I get 401 error instead. Any further attempts give 401, the error 500 only appears on the first attempt. I tried it with this new "Launcher" thing enabled and disabled - no change. Time & date in Windows set correctly. Any idea what could be wrong? Online mode is a bit of a no-go for me - my internet provider has become sloppy recently, so thanks to offline mode I don't need to worry about it (except for DCS updates, but they only take 10-15 minutes, once in a while).

Great idea! Yes, I KNOW it can help, because I tried something similar and it helped me. Unfortunately I have no idea how to achieve this the way you suggest - as a kind of an overlay on the screen. If you have a Stream Deck, you can arrange a sort of poor man's slip ball on it. Description below. If not - maybe someone more knowledgeable can come up with a recipe for a screen overlay for slip. I'd like to have such a contraption myself. If not - I understand that this is a wish list topic, it's just such topics have a tendency to grow bigger and bigger. And then bigger some more

Yeah, I know, early on I had my DCS on the HDD and yes - that was a VERY bad idea Then I bought an SSD (SATA) and magic happened. But now this SSD (1 TB) is gradually getting full. I mean it's about 65-70% full, but you need some free space on SSD for wear leveling, it's not too smart to stuff it to the brim, that's why I started thinking about moving selected parts of DCS back to the old HDD (in anticipation of new maps and modules). Thanks for the clue - keep the maps on SSD. Will do!

Speaking of which... I'm thinking of splitting the DCS installation across 2 physical drives by means of symbolic links, but here's the trouble - my "spare" drive is an HDD, not exactly a speed demon. I'm worried about the potential impact on performance. Which directories should be my first choice for moving onto the slower drive? Terrains, aircraft modules, missions/campaigns, or... what? I don't know how hard DCS is sucking data from particular folders when I'm flying Does anybody have experience in this?

Since you want a short answer (and it's difficult to give one): it's a mixed bag, some controls will work fine, some only if you modify Lua, others just won't. As for the Viper, I don't fly it, like at all, maybe 6 hours total. I don't fly Hornet much, either (maybe a 100 hours) and it's a mixed bag. Never tried zoom. As for CRS/HDG - this plane has those toggle switches for that and they're actually "tuned" exactly for 1° (single "tap" on the switch), which is absolutely unique in DCS, so they should work the same with a rotary. One notch on the rotary should be exactly 1° of a CRS/HDG change. Sounds great, but this also means you'll probably have to make 180 "notches" to set the reciprocal heading. I'm not sure, but the rotaries on SD+ have about 12 detents per turn, something in this range. So, if 12 is the correct number, 180/12 = 15 full turns with a rotary! You're not gonna like it, and the rotary isn't, either. Maybe you can write a separate pair of "fast" commands, which would turn the CRS/HDG by 10°, but that's very doubtful (it's a complex, "variable speed" command). This will work, however, in the Tomcat! I have it arranged like that (Lua modification) - 2 speeds, slow and fast, you alternate between the two with a push on the rotary ("Dial Stack" in SD software). Tune CRS/HDG fast/coarse (approximately 10° increments), push, now fine tune. Works quite well, but "fine speed" isn't tuned precisely to 1°. In reality, you'd have to go through all such controls one by one and see which work well out of the box, which need some Lua tinkering (but it's doable), and which work bad, are hardcoded, and you're toast. With every module you'll get a mixture of all these 3 cases. That's why it's very hard to give you a single "go for it" or "save yourself the pain" answer. Mixed bag, all across the board. Still, I think that if (and only if) you have a SD XL already, buying a SD+ (or better yet - TWO of them) is a good option. It's just it won't be all roses. Let's say 30-40% roses, 60-70% weeds. It has nothing to do with SD+, but with the mercy of the particular module's authors. In my experience it's somewhat limited You know... the principle of clickable cockpits in DCS is a bit insidious. It's not (always) merely a control method option, i.e. clicking things with a mouse. Sometimes it's the ONLY method, because the commands for joystick or similar controls have been neglected and are difficult to use (too fast), or virtually impossible to use (too coarse for rotaries or way too fast for "normal" buttons). Or completely missing, which is also a popular design principle.

TRK = track file. Fly your mission where you present the problem, it's best to make it as short as you can (longer track files tend/tended to get corrupt), then quit the mission and in the debriefing window you have this row of buttons, at the bottom. One of them reads "SAVE TRACK" or something like this - click it, give the file some name, save. It's not a bad idea to then check if your track file works on your PC (it may NOT). On the main screen in DCS I think it's called "REPLAY" (or similar). Click it, load the saved track file and watch if it plays OK, i.e. if what you see in the replay is actually what happened in the mission. If it is, attach the file here, so fausete can grab the file and investigate.

I never auto-start-stop, so I don't know about this one, but I can confirm the second issue! It's not only about BE, I've had it happen in CE, too. It certainly bit me with SAMP 250 HD bombs (retarded). Not entirely sure if it happens to ALL weapons (I think it might not be the case, but I don't want to muddy the waters here). Regardless - 250 kg chute bombs for sure get glued to pylons once "rearmed" in flight, with Unlimited Weapons on. You may say it's not so much a big deal, but OTOH Unlimited Weapons is a great feature when you're practising (or just enjoying) weapon employment in a new aircraft, especially more manual ways of weapon employment, as is the case with all A/G weapons in F1 BE/CE/EE. And which is sweet and cool

Sorry for the strange title. Tested in CE, but probably it's the same in EE and BE, too. Settings as in the screenshot: "BOTH" and "PRGM". Slap the release button - the program set on that fancy panel behind the seat gets started. So far so good. Now, BEFORE the program completes, try "re-slapping" the button, numerous times if you like. Each slap (the program is still running) will release chaff - cool, but WILL NOT release a flare - not cool. In other words, for the time it takes to execute CM program, manual release of flares is disabled. Chaff work OK. I may be doing something wrong (but what?) or otherwise that doesn't seem right. It may get you killed, I doubt the real device really worked like that. When I need another flare, I need it badly. Since I knew something wasn't right, later I set a very specific program to test it easily - another screenshot. One chaff/flare, 8 seconds of delay, another chaff/flare.