Ranma13

I don't have a definitive answer, but based on my experience, I don't think so. I do know that the batteries never run down. I've sat on the ramp for hours with all the battery-powered systems turned on, and it never dies.

My Ka-50 project is a good place to start off with. I structured it in a way where it should be relatively easy to add new images and controls just by copying and pasting what's already there: https://github.com/danieltian/dcs-stream-deck-ka50/blob/master/index.js

Information about the Ka-50 is spread across a lot of places. Most of it is in bits and pieces on this forum, some of it is in videos, and some is in the manual. There's no definitive source of info on the aircraft, and the manual is often wrong or outdated. One thing I find helpful is to test all your assumptions. For example, you might think that the NAV switch on the right panel powers the PVI-800, so flip it off and see what happens. If the PVI-800 doesn't turn off, find out which switch you need to flip in order to do so. Once you find it, you'll realize that the K-041 power switch also provides power to the PVI-800, and it takes precedence over the NAV switch. From this, we can infer that the NAV switch is either a backup switch, or only used for ground checks. Checking the manual on page 158 seems to suggest the same thing, where it says "This switch governs power and ground checks for the targeting navigation system." A lot of the knowledge I've come by is either through this kind of experimenting, or by wondering what a certain thing actually does, then doing a search for it. I then test the info I find because not everyone is correct is basing it either off assumptions, or is repeating something someone else said. I found the video a while back when I was learning the Ka-50 and I bookmarked it. It's a bit lower on the YouTube searches due to its age, but it's by far the best DCS training video I've watched across all aircraft, likely because it was a commercial product: https://forums.eagle.ru/showthread.php?t=42223 Sadly, it seems like either this was the only video produced, or that nobody bought the DVD. As for your intro, think about what you do when you watch other people's videos. Do you sit through their intro, or do you just skip it? Maybe you'd tolerate a 5-second intro, but I'd imagine that most people will hit the right arrow key a few times once the first 5 seconds has passed. If you're looking for specific pieces of information, do you want to sit around listening to someone ramble on about their life? This video is a great example of how not to start off a video: Do you really care that he hasn't had the time to play a lot because he was moving, and that the sound quality is a bit more echo-y because he hasn't been able to sound dampen things? Or do you only care about what the title states, how to use the Ka-50 as a scout helicopter? In this day and age, if the video hasn't caught your interest based on the title and thumbnail alone, you're already watching something else. Having to continually skip past non-relevant sections is a great way for people to just drop watching the video altogether, because if the first 30 seconds doesn't give you what you want, why should they expect that the next 9:30 will? We give a pass for DCS videos because there just aren't that many out there, but adding needless elements to a video is a great way to turn people of because, as the meme goes, "ain't nobody got time for that".

I think you misunderstand what "viewpoint" means. I don't care how well you get along with VR, because that's your viewpoint and has no relevance to how I get along with VR. Your "counterpoints" are basically saying "I have a different experience than you", which is great, but you also try to dismiss mine because you don't agree.

Most likely yes if you're binding to controls that have a binding in the controls configurator. The official software has support for multiple profiles, folders, and now support for modifier keys on different sides of the keyboard (i.e. LAlt vs RAlt), but there are controls that DCS doesn't support through the controls configurator that are supported in DCS BIOS. DCS BIOS also allows for two-way communication (like changing the image on the Stream Deck when the state of the aircraft changes), whereas the official Stream Deck software can only send keyboard presses. If you only want to emulate a keyboard or button box, then I suspect you'll be perfectly happy with the Stream Deck, but if you want the two-way communication, then you'll need some programming knowledge (at least for now).

To offer a contrasting viewpoint, I have the HTC Vive and TrackIR and I vastly prefer TrackIR for the following reasons: 1. I get motion sickness when I fly in VR for too long. I know about the whole "getting your VR legs" thing, but combined with the other reasons, I don't feel the need to repeatedly punish myself so that one day I might get over it. 2. I have a cockpit with external monitors and several button boxes, all of which are unusable inside VR. I know there's people who can feel their way around, but it's not going to be the same as just looking at something and using it directly, especially when I have a F-16 ICP, A-10 UFC, 2 MFD panels, and an Elgato Stream Deck. 3. The headset gets hot after a while, and it's hard to keep it in the sweet spot. Either I have to pull the head straps tight enough to where they start to squeeze and hurt, or I keep them looser but have to constantly adjust the positioning to stay in the sweet spot. 4. It's impossible to look at reference materials such as tutorials, live maps, airport charts, etc. while in VR, and things like bathroom and water breaks have to be planned out because removing and putting the headset on, getting into the sweet spot, then feeling around for the joystick and throttle, is a whole process that I don't want to repeat too often. 5. The low resolution, even with super-sampling, is not great. MFDs and displays are too blurry to view comfortably unless I lean in, and combined with having to feel around for the MFD buttons means that I often feel like I'm just fumbling around instead of doing what I actually want to do. Ground targets without labels are all but impossible to spot, and air targets all look like black dots until you get really close. 6. The feeling of immersion is great at first, but I find that it quickly wears off and I find that the other things I stated above takes precedence. As someone else said, "VR is great if you're just flying around, but not when you actually want to do something beyond that". I'm sure that there are workarounds and even decent solutions for these points, but taken as a whole, I find that I'd much rather fly in TrackIR and only lose the sense of immersion, vs. VR where I have to deal with all of the downsides.

This is not necessary. The batteries can power the INU, ABRIS, and EKRAN directly without ground power or the AC generators running. Since you need the APU to start the engines, ground power does not affect how quickly you can start both engines. To tell when you can switch from one engine to the other for startup, wait for the START VLV light to go out at around 60% RPM. The only thing that ground power allows you to power up before both engines are started and generating AC power, is the Shkval display, HMS, weapons systems, and UV-26 countermeasures. The Shkval display will need to be adjusted depending on the distance to target, so it's not too important to set it on the ground. Same goes for the HMS depending on how you're using it. The UV-26 can be set within seconds. It doesn't hurt to use ground power, but I find it to be extra steps that aren't necessary and don't really save any time.

The issue is not that you left things out; I can understand not doing all the tests or running through the entire checklist because some things don't matter in the sim. The issue is that some of the things you state are flat-out incorrect. You're not just omitting things for the sake of brevity, you're teaching something that's completely wrong. You also only explain the what, but not the why; if you really want new players to absorb the information, you need to explain why you are doing what you're doing. By contrast, this startup video series explains every step in the startup (including tests) and also why they need to be done. It's over an hour long for all 7 parts, but it's very comprehensive and thorough. I doubt anyone watching it will find it to be a waste of time because, although long, it gets straight to the point, explains why certain things need to be done, and covers nearly everything you'd need to know: If you really want to save time, take my advice from the other thread; cut out your 30-second intro, quit the small talk at the beginning, and speed up the video.

VVI still works without INU alignment, the HUD VVI and VVI gauge both use air pressure to indicate vertical velocity and is not dependent on the INU. Without the INU, ground speed info from the doppler radar won't be displayed in the HUD, but you still get ground speed info on the ABRIS from GLONASS, and IAS from the airspeed gauge. A full alignment before take-off is not really all that necessary unless you're flying at night without night vision and can't see the ground.

In real life, you want to run the tests because they can mean the difference between life and death. In the sim, it hardly matters. Random failures occur so infrequently that when they do happen, you can just restart the mission or deal with it. Almost no missions will add in failures, and if they do, it's almost always some kind of failure training mission. It's up to you if you want to run the tests or not depending on what level of realism you're looking for, but in the years that I've been flying the Ka-50, I've never seen any need to run them. There are also other things that you're supposed to do during the startup that nobody ever does because they have no effect in the sim. For example, you're supposed to wait 1 minute after starting the APU before you start the main engines, which nobody does. You're also supposed to contact ATC to do a hover check before you ask them again for clearance to the runway for a rolling take-off, but most people will just take off immediately from the parking spot. If you follow the startup checklist to the letter, running every test and doing everything you're supposed to in real life, it will easily take 10 minutes assuming you're familiar with the entire process. Conversely, understanding that this is a sim, the limitations of the systems modeling, and your goal (do you want to blow stuff up or sit on the ramp flipping switches?), you can get the helicopter airborne in less than 2 minutes.

Though those are good points to bring up, I personally skip all the BIT tests and other tests because, unlike in real life, we get a perfect helicopter every time in the sim. After doing a startup for the umpteenth time, it gets tiring running a test that you know will succeed 100% of the time.

Some things I'd like to point out: 1. At 1:14, the SA-TFL switch is non-functional in-game. You can flip it up so that it matches all the other radio switches, but it's not strictly necessary. 2. At 2:20, the proper procedure is to only engage the fuel pumps to either engine when you're about to start them. However, it doesn't have any adverse effects in-game if you flip them up beforehand. 3. At 3:18, though it has no adverse effects in-game, the proper procedure is to arm the ejection seat as the last step before taxiing. 4. At 3:52, you need to leave the throttles on idle until both engines are started up and have stabilized. Pushing them up to auto before the engines are started is a safety hazard, as in auto mode the rotors generate enough lift to cause the helicopter to either move or become airborne. 5. At 4:04, the switch is the engine selector switch, of which turbo gear is one of the possible positions. 6. At 4:37, the IFF switch is non-functional, and the NAV switch provides power to the PVI-800 only until the engines have started up and both generators are running, at which time power is delivered by the generators. It's not necessary to flip these switches up, though it doesn't hurt to do so. 7. At 4:43, the left switch is for the INU correction mode. In the forward position, the INU correction is done through the Shkval, and in the rear position, it's done through flying over a known reference point. This switch is only used in conjunction with the INU alignment buttons on the PVI-800. The right switch is for data link power. Neither need to be in the forward position for the PVI-800 to work properly, though the datalink switch should be switched forward for it to work. 8. At 5:00, you actually turned on the altitude hold channel while leaving all the other channels off. Due to a long-standing bug, the lights for the autopilot channels are inverted (dim is on, bright is off). In normal operation, the bank, pitch, and heading channels should always be on. 9. At 7:04, the throttles should only be put into the max position for emergency situations only, for example if one engine goes out and you absolutely need the extra lift. For normal operation, the throttles should only be used in the auto position. 10. At 8:30, the trim reset is a workaround for the majority of joysticks being spring-based and not intended to be used with helicopters. I wrote a very long post here that explains the 3 different trim modes and how they work: 11. At 9:50, the rotation of the helicopter is due to two things: at 5:50 the heading hold channel was not turned on, and because the two rotors generate slightly different amounts of torque. It is not due to centrifugal force. 12. At 12:32, the p indicates that the altitude source is from the radar altimeter. It goes away above 300m because the helicopter will switch to the barometric altimeter. This distinction is important because above 300m when the p goes away, the number will most likely jump to a completely different value, because the altimeter source is changing. 13. At 13:30, the bar and number on the lower right indicates your vertical velocity. The +01 shows that you are rising at 1 meter per second.

Nice video! Here's some feedback for future videos: 1. Skip the 30-second intro, everyone's just going to skip it anyway. If you must have one, follow what the big YouTube channels do and start with something catchy that summarizes the video's contents, then play a short intro that's no more than 5 seconds. I would just cut it out entirely though, as most people find it boring and a waste of time. 2. You should turn up your microphone volume or increase the gain, right now it's too low compared to most other videos and even your intro. 3. For the first 2 minutes, you fall into what I call "shoot the shit" mode. This is fine if you're streaming on Twitch, but for a tutorial video, it's information that's not relevant to what the video is about. Likewise, up until 4:40 or so, you're in "cover my ass" mode where you tell us that the video is not comprehensive, but the vast majority of people innately know that a 30-minute video won't make them an expert. 4. Since the spoken language is English, you should use an English cockpit mod. For someone who's unfamiliar with the aircraft, it's much easier to read English labels while listening to an English speaker. 5. I recommend that you speed up the video in post. Watching it on 1.5x speed sounds perfectly fine, which indicates that you can deliver the same amount of information in a shorter timeframe. 6. The video's title is "Basic Fundamentals", but for the majority of gauges and switches, you only say its name before moving on. I feel that this doesn't really cover the "basic fundamentals", but is rather more of a cockpit overview; useful as a refresher for someone familiar with the aircraft, but not very helpful for someone new, since all they're getting is "this is <insert unfamiliar name here>" over and over.

With regards to FFB inside DCS, it turns out that vJoy can receive FFB commands, and with an appropriate feeder, it's possible to do something when a FFB command is received. It also just so happens that Brunner has an API available for CLS2Sim that allows you to control force feedback with an external application while reading the state of the joystick position. What this means is that it should be possible to write an application that glues vJoy together with CLS2Sim to get force feedback with the Brunner base in DCS (and any other game that supports FFB). I've looked a bit into this and I believe I can write the app, but without a Brunner base, I don't have access to the CLS2Sim software, and even if I did, there's not much point without a base to test against. The challenge is in adapting FFB commands to CLS2Sim commands. FFB commands expects that the joystick understands how to implement the command, so for example the command might be something like "activate a spring force at 88 degrees with 200-level force for 0.5 seconds", and the base is expected to know how to do it. Looking at the CLS2Sim API though, it seems like it only supports simple "activate a force in a certain direction with a certain strength" until it receives a cancel command, though I won't be able to tell for sure until I get a base for myself to try it against. I will likely have to implement all the FFB effect types in a way that will duplicate the same effect in CLS2Sim with its simpler API. With that said, I'm currently trying to drum up enough funds to purchase a base. Keep an eye out for an update from me.

I purchased the FSSB R3 about a year ago, shipped to Hawaii for 51.62 EUR (~$58 USD). This was about 10% of the purchase price, and is reasonable given that it's shipped from Spain via 2-day delivery, and was actually delivered in 2 days.

Nice find, Thermal! This should make it a lot easier to interface with the Stream Deck, be more reliable because it will show up as a plugin instead of having to run a completely separate app, and be more versatile because we can take advantage of the Stream Deck's software features. I'll spend some time looking into porting my DCS BIOS API library over to be a Stream Deck plugin. Edit: Hmm, I spent some time looking at the example projects and the documentation and, like most SDK documentation, I found it very lacking and missing key pieces of info. I'll have to play around with the examples some more, but from what it looks like, I'll need to write an executable that can handle the communication between the Stream Deck and DCS BIOS API, then write the Elgato plugin to run this app and interface with the Elgato hardware. It seems like at this point that the only win is that I don't have to write my own UI, but everything else is the same as the plugins I've already written.

It looks like they're just about ready for pre-orders: http://realsimulator.com/ "Preorders as soon as test users give the GO" "First two units under test by final users"

cichlidfan is incorrect. You cannot export the MFCD's (or any other screen) more than once. If you have two definitions of LEFT_MFCD, the last one will replace any before it because it's a variable/key name. As far as I know, there is no way to export each screen more than once through the MonitorSetup lua scripts. You may be able to do something with the MFCD_init.lua script where it's getting the viewport to display the MFCD's in. The file is located here for the A-10C: C:\Program Files\Eagle Dynamics\DCS World OpenBeta\Mods\aircraft\A-10C\Cockpit\Scripts\MFCD\indicator\MFCD_init.lua But how to do this and whether it will pass IC is something you'll have to discover yourself.

I am extremely interested in how the force trim feels once you get it in, especially since MonsterTech now has a mounting plate for it. Please keep us updated!

If you plan to make a small batch, you really need to own the Crosswind. Trusting someone to provide you accurate measurements and then manufacturing the pedals solely based on those measurements, is going to have a high likelihood of the pedals not being able to fit properly.

The A-10C's TGP works similar to the Shkval. It can either ground stabilize on a certain point on the ground, or it can lock onto a lockable entity and track its movement. The difference is that it doesn't have a range limit like the Shkval does. It just so happens that in-game, things that move are always lockable entities, and things that don't can be handled by the ground stabilize lock. But as far as I know, there aren't any aircraft that can do a true contrast lock in the game, so for example you won't be able to lock an aircraft's shadow on the ground and track its movement because it's not a lockable entity.

Just clear all the bindings in-game for target lock, then re-bind it. Your screenshot is for the default controls, which has nothing to do with what's currently bound (that file doesn't get modified when you bind controls).

That red bar in your binding means that you have a binding conflict. You need to fix that first to get the binding working again.

The lock range is dependent only on the time of day and (possibly) the weather conditions. It does not do real contrast detection like on the real aircraft. At noon in clear weather, it's possible to lock out to 7-8km, but around dawn and dusk, it drops to around 3-4 km. At night you'd be lucky to lock anything up beyond 1-2km, if even that. The Shkval's been this way since the aircraft was released back in 2002, but I suspect that the move to 2.5 reduced the ranges a bit, hence why people are noticing it more nowadays.

The lock range is dependent only on the time of day and (possibly) the weather conditions. It does not do real contrast detection like on the real aircraft. At noon in clear weather, it's possible to lock out to 7-8km, but around dawn and dusk, it drops to around 3-4 km. At night you'd be lucky to lock anything up beyond 1-2km, if even that. The Shkval's been this way since the aircraft was released back in 2002, but I suspect that the move to 2.5 reduced the ranges a bit, hence why people are noticing it more nowadays.