scoobie

I don't know if it's normal for Black Shark or not, I'm sort of new to it. Both screenshots are from the same situation. External view shows windshield shot multiple times, then from the inside it's unscratched. EDIT: Also, the damaged nose was visibile from the cockpit (when I moved my head in TrackIR forward and up), perhaps it's only the glass that doesn't have "damage model" from the cockpit view.

I'm sold on BS3 and this is really strange, because BS2 was the only chopper I virtually never flew (35 hours or so and that's it). In BS 3 many sounds are better - an extremely important thing to me! In BS2 when the rotors were spooling down, the sound was "slowing down", so was getting darker and darker, my ears were bleeding hearing it. Now it's gone Also I think there's something new and "richer" about engine spool down (maybe spool up as well), I'll need to concentrate more on sounds yet, so far I've been too busy learning new systems (and some old systems I never cared to learn properly in BS2). The 3D model is fantastic. While it's not as important to me as the cockpit (the latter had been improved some time prior to BS3), it does make my jaw drop. Also 3D damage model looks great, at least judging after 1 or 2 days of getting beaten in BS3. The MWS makes a world of difference! That's truly a bomb in BS3. For me that is. Flares will either fool a heat seeker or not, they're not magic, don't go reckless, but at least now Betty/Natasha will yell at you, so, for example, you can drop the collective and hopefully hide behind a building or trees. Yesterday I was so vigorous with it that I tapped with the belly on the ground and damaged Shkval and laser, but I didn't get the missile in the face (I think it was some kind of wire-guided ATGM). Went back to the airfield for repair and then back to the A.O. to finish the bad guys who shot at me. Satisfaction 100% In BS2 you would peacefully die from MANPADS or other non-laser-guided things on a regular basis - if only the bad dude fired it from a rear hemisphere. Or from wherever when you were head-down staring at your Shkval. No warning, another happy day at work and BANG - you're dead. The SAI (standby ADI) goes bonkers, just as in BS2. INU aligment is being disputed, maybe there's something off about it, maybe not, IDK. Regardless, I assume you will now have a reason to learn "reference points" in PVI-800 and do Shkval-guided or "overfly" fixes during a long sortie. Great! To me BS3 seems a very solid offer in the Helo Department and - for whatever it's worth - I'm saying it as an ex "non-fan" of BS2! Call me a convert

Flappie, maaaan! Thank you! Case solved! Watch your head - a crate of beer is flying in your direction It wasn't exactly about this folder, I didn't even remember it was there, but you immediately pointed me in the right direction. The folder is part of the German ATC mod I installed from "User Files". That's not a problem. In order for the mod to work also the file <DCS Install Dir>\Scripts\Speech\_index.lua was modified. That's still not the problem. The problem is that after each DCS update (and there have been 58 of them or so), I had to click "discard changes" for this file in Git, each time thinking to myself "yeah, yeah, that's my German ATC there, I want it, don't touch it"... but THIS TIME, with the release of Black Shark 3, this file was actively modified by ED and I... didn't notice it! Just clicked "discard changes" as usual. So, I destroyed the neccessary "speech" changes without even noticing it! And I did it again today after running the repair ( no comment...) Natasha is not "sound" per se (that's why sounds still worked), she's "speech" because depending on language settings either her or Betty is talking. That's why only this didn't work! In my defence, I've been struggling with a cold or whatever this is, don't feel too good, so my brain's probably on holiday somewhere, but... I'm getting better, I think I'll go for a walk, I feel happy, I feel happy (0:53):

Changed various sliders and checkboxes in Audio menu (mostly for kicks as there was nothing suspicious there). Ran repair. Changed "Avionics Language" option from "native" to "English". Then restored native. Changed "Special", cockpit from "default" to "English". Then restored default. Deleted fxo and metashaders2. Ran cleanup (no interesting findings). All the other modules work. Sounds work in all, including BS3, but in its case with the exception of voice messages. I'm at a loss. Attached dcs.log. There are some kind of errors and warnings there, but they also pop up when I start BS2, so I don't know where to look. dcs.log

Silly girl... she's not even real! Oh, whatever, I'll try and see what I've messed up. The trouble is that I can't hear voice messages even in a hot start Instant Mission, so... I think... it's not about wrong start-up procedure, must be something different.

It's hard not to agree with you, guys Such a pretty panel... On top of that... those "default.lua" files could be generated automatically. ED are not far from there (especially them, 3rd parties vary in this regard). In clickabledata.lua they already have the whole "zoo" of cockpit control classes, 2-way toggle switches, 3-way toggle switches, various "levers" etc. All they need is to enrich them, so each gets a human-friendly name (e.g. "Gear Lever" instead of LEVER_0136 - abstract example), introduce meaningful position names (e.g. {'CHECK', 'EDIT', 'OPER'} for PVI-800 mode knob) or "link" such names from the "library" of generic names (e.g. {'OFF', 'ON'}, {'SAFE', 'ARM'}, {'OPEN', 'CLOSE'}). Now, if the nature of these controls was defined, keybind commands could be generated automatically. And no - not ALL possible commands in the Galaxy, just a sober subset of them. We'd still need the possibility to add our own, because some people have really convoluted sim-pits, button boxes or whatever, so ED cannot cater for all such contraptions. Examples below. Not code, just an idea. Very raw idea, not a ready-to-use solution (obviously). I can see already that some details below are silly, but it doesn't matter - the idea is shown. Examples look like functions, but they would have to be "mixed in" to what is already there in clickabledata.lua, not as separate entities. So, if a particular switch is defined in clickabledata.lua, it could be enriched with definitions similar to what looks below like a function (I don't have DCS here, so I can't throw code off the top of my head, can't remember how exactly things look like in clickabledata files). Holy Directions are always these: out-in/released-pressed/bottom-up/aft-fore/left-right/CW-CCW; unjustified violation is a bug. Behaviour definition: following holy directions, a position with an underscore is spring-loaded to postion "pointed with" the underscore, e.g. {ON, _ON} - the right one springs back to the left one. Something of this sort. (There must be some way of telling the code that a position is spring loaded, for example to tell between a push button and a latching 2-way toggle switch - they need different sets of keybindings). No default positions or behaviours (from "the library") are given below - for illustration. Examples in English only. Translations of switch labels only where multilingual cockpits are planned or already exist (below it is assumed translations are neccessary). k041_reset_btn = cpit_ctrl("_('K-041 Reset Button')", "_('K-041 Weapon Control Panel')", {ON, _ON}, {"_('RELEASE')", "_('PUSH')"}) generated commands for default.lua (just one): 'K-041 Reset Button PUSH' Why only one? Because the "behaviour" says the control has only two positions, one of which is spring loaded - this is either a push button or a toggle switch of OFF-(ON) type (effectively the same as a push button). 2-way latching toggle switch, : master_arm_switch = cpit_ctrl("_('Master Arm Switch')", "_('Instrument Panel')", {ON, ON} , {"_('SAFE')", "_('ARM')"}) generated commands: 'Master Arm Switch SAFE' ("stateful" command, e.g. for an ON-ON switch) 'Master Arm Switch ARM' (a/a) 'Master Arm Switch Toggle' ("relative" command for an OFF-(ON) switch, i.e. a pushbutton, e.g. a keyboard key) 'Master Arm Switch ARM else SAFE' ("spring-loaded command" for an OFF-ON switch) How do we know we need these 4 commands? The control has 2 latching positions. Somebody may want to use a single button/key for it ("Toggle"), somebody else preferes seperate keys (e.g. "M" and "RShift-M") for either position. Someone else has a ON-ON switch, so he also may use the "stateful" commands for each position, explicitely. And someone else has a typical OFF-ON switch (TM Warthog throttle base or whatever), so he nees "spring-loaded command". Now a real plane example - 3-way latching toggle switch. A-10C, LASTE LAAP Mode Switch: autopilot_mode_switch = cpit_ctrl("_('Autopilot Mode')", "_('LASTE Panel')", {ON, ON, ON}, {"_('ALT')", "_('ALT/HDG')", "_('PATH')"}) Middle position is assumed common for a set of two "spring-loaded commands" - this is for typical 3-way ON-OFF-ON toggles in joysticks. Switches which have more than 3 positions don't generate "spring-loaded commands" at all (they only get "stateful" commands for each position plus those "relative" ones - next/previous and toggle). generated commands: 'Autopilot Mode ALT' (stateful command) 'Autopilot Mode ALT/HDG' (stateful command) 'Autopilot Mode PATH' (stateful command) 'Autopilot Mode ALT else ALT/HDG' (spring-loaded command) 'Autopilot Mode PATH else ALT/HDG' (spring-loaded command) 'Autopilot Mode Next' (relative command, only goes up/right/fore/CW, never "rolls over", i.e. goes ALT -> ALT/HDG -> PATH and gets stuck there) 'Autopilot Mode Previous' (a/a, opposite direction, so "gets stuck" at ALT position) 'Autopilot Mode Toggle' (relative command, goes "CW" around all positions, does "roll over", i.e. ALT -> ALT/HDG -> PATH -> ALT -> etc.) These control keybind files shouldn't really be written by a human, EXCEPT where it is absolutely neccessary, which would be perhaps 5% of such files, the rest can be automatic. Automatic means there will be keybind commands generated for EVERYTHING defined in the cockpit. Same goes to axes, they seem even simpler than switches. You define everything in an appropriate file (perhaps clickabledata.lua or another) in a fashion similar to shown above. Then you run a generator, which spits out auto_keybinds.lua. Then you manually write a "master" default.lua file, you include auto_keybinds.lua there ("dofile" or however it's done, I don't know Lua) and you add the neccessary manual (hand-written) commands to the default.lua. If any!

The file would be: <DCS Install Dir>\Mods\aircraft\Ka-50_3\Input\ka-50_3\joystick\default.lua You need to find this "axisCommands = {" in your file and inject things I outlined with those "scoobie begin/end" comment lines. People say you must use "Notepad++" editor for that, I'm not sure why but apparently some folks are using some editor(s) or other software that messes up Lua files. How - I don't know. You also need to have some means of preserving your modifications - each DCS update will overwrite your changes, so you need a mod manager or another solution. Alternatively, there is a mod which lets you keep your own binding commands in <Saved games>, so updates won't harm them... it's just I can never remember how the mod is called. There's an extensive tutorial on the subject made by LeCuvier here:

I can't get Natasha to say anything in BS3. In BS2 she's there and talks, I've just checked. Any ideas what this may be about? Is she offended or what? Do you get her to say anything?

Agree and I've got a joke, too... This is because the cockpits are CLICKABLE. The trick is that not only CAN you click them, you also HAVE to click them Haa haa... absolutely hillarious. Now, seriously speaking, lots of people have basic HOTAS set. May be of stellar quality, but basic - stick and throttle and that's it (well, that's why it's called HOTAS). So people do use mice, for the lack of other equpiment. I don't like using a mouse. Low or average quality potentiometers aren't expensive, jellybean electronics, Leo Bodnar's boards probably aren't too expensive, either. You may also buy one of those "control panels" with knobs and stuff from Virpil or other people, no problem. So, really... I don't see why you HAVE to abuse the mouse to deal with knobs in an simulated aircraft in 2023 ("have to" is different from "choose to"), when at the same time people buy joysticks for hundreds of bucks. Turning hardware knobs just works and feels great (I've got 7 of them), whereas doing it with a mouse is like... OK, no poetic parallels, it's just worse, WAY worse. Sadly, there's an unfortunate coincidence which may make some of one's own binding result in various "artifacts" when you turn a particular axis to absolute minimum. This is because most axes in 3D models go (move) from value 0 to 1, not from -1 to 1 (which control bindings window assumes). When you create your own binding (in the way depicted in the post above), you need to "Axis Tune", click "slider" and "user curve" and the curve goes 50..100 in increments of 5. So far so good. Unfortunately, the Axis Tune window does a trick - even if you start with the value of 50, the axis starts with the minimum value (like 0%, but technically it's -1). There is no real reason for it, but it does that. I don't know if you can do anything to rectify it. SO... when you turn your axis to minimum, it goes to minimum... which is -1 for the cockpit control (knob, rheostat, whatever), which means the cockpit control is set to a value to which it wasn't designed to be set to at all. And sometimes you get unexpected results. For example - the gunsight in the Hind (screenshot attached). It's not very nice

Awesome! Thank you! No problem with the delay. I've progressed further in the campaign and thanks to this new "campaign GUI" you can refly any previous mission, so I'll do this once the mission makes it to an OB update How do you, people, find sales figures? While "Museum Relic" is hands down fantastic fun (IMO), it's also the ONLY campaign for MiG-15, so it's automatically the best selling campaign for it. Best, worst, average, median, all at once. Although I fully agree - if Apache left his airliners alone for a few days, he might find time to make some new campaigns as cool as this one Just a selfish point of view, no offence

The axes shown in the box below aren't available in BS3 out of the box, sadly. You need to put them in Lua files yourself (and then apply "user curve" 50, 55, 60, ..., 95, 100 on each). axisCommands = { -- scoobie begin: -- taken from https://forums.eagle.ru/showthread.php?t=258812&page=2 {action = 3001, cockpit_device_id = 7, filter = {saturationX = 1, saturationY = 0.5, deadzone = 0, invert = true, slider = true, curvature = {0}}, name = _('HUD Brightness Knob')}, {action = 3002, cockpit_device_id = 8, name = _('IT-23 TV Brightness Axis')}, {action = 3003, cockpit_device_id = 8, name = _('IT-23 TV Contrast Axis')}, {action = 3008, cockpit_device_id = 9, name = _('ABRIS Brightness Axis')}, {action = 3001, cockpit_device_id = 23, name = _('Helmet device Brightness Axis')}, {action = 3006, cockpit_device_id = 46, name = _('ADF Volume Axis')}, {action = 3002, cockpit_device_id = 49, name = _('R-828 (VHF-1) Radio Volume Axis')}, -- my own: {action = 3006, cockpit_device_id = 51, name = _('Lighting auxiliary panel brightness knob')}, {action = 3008, cockpit_device_id = 51, name = _('Lighting night vision cockpit brightness knob')}, {action = 3002, cockpit_device_id = 51, name = _('Lighting cockpit panel brightness knob')}, {action = 3004, cockpit_device_id = 51, name = _('Lighting HSI and ADI brightness knob')}, -- scoobie end.

FYI, you may punch through this mission with "immortal" option turned on. That's ugly, sure, but at least it worked. As for what's going on, I might have noticed something new - I would... almost swear I've never heard this line outlined in red: It's there in "MESSAGES HISTORY", but I really can't recall hearing it or reading it on the screen (I have subtitles on), ever. Anyway, this means that Su-17 is perhaps scripted to attack targets right next to the river, the only problem is... they kill him Another try, same result: My DCS is v2.8.0.33006

This one's tricky! For reference: I have a non-extended TM Warthog joystick with main spring ripped out (only 4 small springs remain there). Yes, lowering saturation (saturation Y) makes AAR easier ONCE you can AAR. At least for me, at least in A-10C. Converesly, lowering saturation makes AAR harder if you still can't AAR and you're all over the place behind that tanker. When I was learning (A-10C) I tried curves, saturation, this and that, and it didn't help at all. Not a tiniest bit, really. Then I learnt how to AAR (boy did it hurt for an old-ish fart like me!) and only some time later I thought "hm... what if I lower saturation NOW?". I did. It helped. Joystick is less sensitive, but you (having learnt to AAR) are making only small errors, which require only small corrections and lowered saturation is no longer a problem. If you can't AAR, you're making BIG errors, which require BIG corrections and if your stick doesn't let you make them, you just flyyy awaaayyy. It makes learning harder, not easier, the plane is sluggish, won't move if you want it to. My own experience, YMMV. Now, I use Joystick Gremlin either way, for lots of things, so I use JG also for this. I tap "~" key on the keyboard and the response from my joystick, before it even "enters" DCS, gets cut by approximately 3 times. So if I deflect the stick to the limit, DCS only sees 1/3 of full deflection, OK? That's for the Hawg only. It's a huge lot, probably too much, but I don't care, it no longer matters. Once she's full, I tap "~" again and I regain 100% response from the joystick again. Easy. For some other planes I don't use this trick at all, because I don't think I need it. Hornet is best example, she's polite. In Tomcat, I think I have like 2/3 of full response (not 1/3 as in the Hawg), but I'm not sure if I like it. I may get rid of it altogether, I'll see. IIRC the Viper doesn't need such tricks, either, as it has a "built-in Joystick Gremlin", the stick becomes less responsive on its own when you AAR. The Scooter - no need, no tricks (correction: I think I have roll axis "tuned", toned down, in DCS as she rolls like crazy out of the box, therefore I don't need any additional tricks outside of DCS). I don't fly other AAR-capable planes, so I can't tell. On the other hand, if someone refuses to use such switchable joystick response patent, then I think AAR is not really worth it to scr*w your joystick response just for AAR. Especially in aircraft where you sometimes (or often) dogfight etc. So, throwing in a lot of FIXED curves (effective all the time) just for the occasional AAR seems a bad trade-off to me, let alone lowering Saturation Y.

Hm... that may actually be the same thing. In your case he attacked (as I understand) the right target first, but only one of them, and then got "distracted" and flew to attack wrong targets elsewhere. In my case he started with attacking a wrong target - a random Abrams, before we got near Hill 39. Apparently there was a bunch of angry men with Stingers there, so they sent him one in the face. Anyway, he seems to be attacking whoever he likes.... I mean whoever he DISlikes instead of following his orders.

Su-17 may be aborting the mission because of battle damage. In my case he gets killed quickly, before he clears my target from AAA, so I get killed quickly afterwards, too Tried twice, same story (debriefing screen for Su-17 attached). I don't know if it matters, but IIRC the Abrams he attacked (first entry in the debriefing) was located just behind the river and surely not within our assigned target box further away, next to Hill 39. There have been numerous improvements to AI recently, maybe that includes ground units and they've got better? I don't know. null

Can confirm both points. I wasn't lucky enough to finish the mission, I must have missed a trigger or something. Spoilers ahead...

(deleted my post - no longer neccessay)

(Updated the recipe.) I attached a track file below to show what's going on. I didn't expect it to work, but it does! I believe you may use this patent for SOME other controls in various DCS modules, it's just I've only tried so far with the MiG-15's ARK-5 tuning crank - this one works. The problem: You bound 2 buttons or keys to make ARK-5 tuning crank rotate CW and CCW, but they turn the crank just too fast, you can hardly tune it precisely - you tap briefly and DANG! it turned too much clockwise, so you tap counter-clockwise... DANG! moved too far CCW. Quite annoying. You can only tune precisely with the mouse, but (let's say) you prefer your button box or keyboard keys for tuning the ARK-5. The solution. Step 1: Make a pair of additional "slow" commands for the tuning crank (leave the original commands as they are, you still need them!). Put these into the apropriate control bindings Lua file (depending on the controller and/or keyboard): {pressed = ARC_5_commands.CMD_ARC_5_TUNE_FREQUENCY_EXT, cockpit_device_id = devices.ARC_5, value_pressed = -0.15, name = _('ARK-5 Tuning Crank, CCW, slow'), category = _('ARK-5 Radio Compass')}, {pressed = ARC_5_commands.CMD_ARC_5_TUNE_FREQUENCY_EXT, cockpit_device_id = devices.ARC_5, value_pressed = 0.15, name = _('ARK-5 Tuning Crank, CW, slow'), category = _('ARK-5 Radio Compass')}, You may now bind these slow commands to another pair of buttons or keys OR you may instead bind both slow and fast command for each direction to the same button/key! This way one button/key will turn the crank first slow, then fast clockwise, and another one first slow then fast counter-clockwise. For this you need external software like Joystick Gremlin or similar. Read Step 2. Step 2: Here's Joystick Gremlin screenshot and control bindings in DCS. What it does is this: if you press and hold Button 21 for 1 second, Joystick Gremlin will press Button 21 on the Virtual Joystick (vJoy Device). Pretty simple. The binding for "Short Press" is only neccessary to circumvent a quirk in JG. Now you bind "slow" command to the button on a physical controller (for me it's Button 21 on "BU0836-LC" device). Then you bind normal (fast) command to this virtual button. (Of course "Button 21" is my example, for you it may be a different button or key on a different controller/joystick or keyboard.) It so happens that if two bindings try to act on the same cockpit control, the button/key activated later prevails. I attached short track to show you what I'm talking about. You have to take my word - each time you see the crank turning I tapped or pressed and held a SINGLE button on my button box for clockwise direction and another one for counter-clockwise direction. Only two physical buttons to turn the crank in 2 different speeds Important! Like I said, this can be potentially used for various cockpit controls in DCS modules, but the "Step 1" is where a particular control in a particular module, especially 3rd party module, may fail. Even if you add the slow commands, the specific control won't move slower (or won't move at all etc.). If this happens, I don't think there's anything you can do about it. 2-speed tuning crank.trk

I'm not sure what you mean. They're just throwing each basic colour (values 0..255) onto its appropriate byte in a number (B lowest, G next, R highest), like this (apostrophes separate bytes for clarity, each character is a bit): RRRRRRRR'GGGGGGGG'BBBBBBBB However... this is not a normal language, but this Lua thing, so the little code can as well launch a space probe to the orbit or do laundry for aunt Helen, no one knows

My tentative profile for AJS37 Viggen. Faaa(aaa)aar from perfect, but I don't think anybody else has posted their profile for the Viggy so far. The profile is UNFINISHED, in two ways: 1. The Viggen is unfinished, further work is neccessary on Heatblur's part (control assignments). 2. I don't intend to have all or 90% of module's controls on Stream Deck (SD), in any module. This is because I prefer to interact with those beautiful cockpits instead of a black plastic box (which SD is). So, for example, I never put "BATT ON" or other things non-essential during normal flight on SD. Also, I make heavy use of HOTAS and my button box, so I just don't need SD for as many things as other folks may. This is an "unrealistic mode" profile, meaning it doesn't try to look like Viggen's cockpit. Most icons are drawn, not "photographed" in the cockpit. It's because of a few reasons. You are encouraged to tweak the profile to your heart's content. Please use it merely as a foundation for your own profile - perfect for you. PREREQUISITES 1. Stream Deck XL 2. Invaluable Stream Deck DCS plugin from Charlie T., I'm using version 1.0.4. Link: https://github.com/enertial/streamdeck-dcs-interface 3. Lua export script attached to this post. Put it INSIDE this folder: <Your Saved Games folder>\DCS\Scripts\DCS-ExportScript\ExportsModules\ 4. The very Stream Deck profile, obviously. Attached to this post. BRIEF OVERVIEW OF FEATURES IS IN THE SPOILER BOX BELOW null null AJS37.lua AJS37 Viggen.streamDeckProfile

Are you talking Mirage F1 or in general? I know some aircraft have a single "A/A" position on the TACAN knob. In their case I'm not sure how their on-board TACAN set should work. Some other planes, though, may have two positions: "A/A REC" and "A/A T/R". Screenshots attached. It's from A-10A, but the same TACAN set is on A-10C (AN/ARN-118(V)). To my understanding, a year or so ago ALL planes in DCS lost the capability of working in this "A/A T/R" mode, though maybe Mirage F1 never had ranging in "A/A" position? I mean IRL. I don't know. nullnull

I don't know about F1, but that's definitely true - multiple aircraft were/are affected, probably all of them. The workaround was/is to use T/R instead of A/A (no idea if this is going to work in F1).

There's one thing to emphasise, IMHO one we tend to overlook. When DCS was Black Shark, there could be bugs only in Black Shark and the core game. Now they have something like 30-40 modules (counting ED/Belsimtek only), each can get broken in one way or another by an update to the core game, plus the very core game has been getting bigger and bigger for 15 years. That's nuts An ocean of code, graphics, sounds, manuals, and what-not. And ED haven't grown bigger in terms of staff number by 30-40 times. Maybe 2-3 times, IDK exactly.

For the reason unknown to me, recently we've had a few internet "discos" where I live. No internet, a couple of times a week, for a few hours. As a result I switched to run DCS offline routinely. Whenever there's a DCS update, I go online, install, and go offline immediately afterwards. Thanks to that the "window of opportunity" for the internet provider to scr*w my DCS is smaller

Yes, I make my own missions to practice new things, too, but Fangs has a good point here. There ARE training missions (for some modules) which let you skip a portion of text/voiceovers and these missions, at least some of them, are nice enough to inform/warn you about it up-front: "you can skip if you like, but first time don't skip". Such missions are more practical, because quite often you learn switch-o-logy, "ideology" (of a given system etc.) fast, but then there's something more difficult you want to practice over and over again. Instead, each time you have to listen through the long introduction, how advanced this aircraft is etc., only to get to the interesting part (for you) 5 minutes later. On top of that, I imagine that for the creator(s) of such training missions it is equally easy/difficult to prepare the mission in either of the two "styles" ("can/cannot skip" styles), so if that's true... why not do it in a more pracital way?