virgo47

The training mission description shows CCRP: But the mission itself is all about CCIP, e.g.: This should be easy to fix in the mission description.

They recently (not sure when, some time between 2.7 and 2.8) changed the mission... slightly for the better. The first group is now 5xM113 instead of a single quite difficult and fire returning vehicle (in addition to a lot of side-wind)... and the second group are 3 HEMTT which are easier to dispatch with the pods. (Green smoke is missing though, but not a problem.) I'd say this is better than before... wasn't there one Abrams in the old days? Definitely something crazy for the pods. M113 are still tough targets for the pods though. BTW: Perhaps I'm stupidly hard-headed or what... but I'd say this is the most played mission for me. I don't recommend that to anyone.

There is also one important distinction between 4x and BSE (which is actually VSE or "vsjo"). BSE still works only for 4 pods, but it also zeroes any gunpod elevation. This is mentioned in the training mission for pods - but it does not explicitly mention that "all" is not gunpods+internal gun. BTW: I'm not sure what I'm doing wrong, I tried many times, but the results are often anything but "a rain of 23mm rounds can be quite deadly". Pods seem to be extremely weak against anything except unarmoured targets. There is no comparison to the internal gun which is many times stronger.

Hi guys! Modifiers seem to be dead-easy, but there is a bit of depth in them, especially when used for axes. And they can be renamed, which is super cool for a couple of situations. So here is my take on the topic:

Yup, modifiers are plane-specific, you can have the same button as a modifier in one plane and not in another. You can even have two different physical buttons as the same modifier (when you specify its name) in two different modules. When you define the modifier there is a warning that the button is used, but you can go on - which is actually good. You'll just see all the wrong bindings with red exclamation marks. I've just created a video about modifiers, btw... there are some interesting applications, especially with axes and when you play with the logical names of the modifiers:

Do you use that modifier as "modifier" or is it a "switch"? I've never had such an issue with a modifier, but I can imagine it with the "switch" (which I totally ignored until today).

I totally missed this thread but not the issue itself. I didn't know it was a new problem because I had wrong default fov in some planes long before this, so I didn't bother. After some experiments I too discovered that there is a workaround. After using any snapview the zoom normal works again! So now I just calmly press snapview 5 and zoom normal - which I have next to each other - and go on. But it is an embarassing bug indeed. BTW I use 2560x1440p common resolution.

I don't know how it is modelled in the game, but compared to the picture the braking effect really looks much weaker. For Su-25(T) there is also no wheel brake axis, so we can't squeeze it fast, it takes more than 1s to even get to the full pressure. (At least from the cockpit instruments, which - strangely - are not even consistent in Su-25T and Su-25. It looks like Su-25T has the hydro and brake pressure swapped, but I'm only guessing that the red area is for the hydraulic pressure gauge and not for the brake gauge.) Is there any public info about the brake deceleration of Su-25/T available? With just a rough measurement, it takes over 9s to stop Su-25 from 50 km/h, which is terrible, but how real it is I have no idea.

I guess encoders on Orion work on the same principle - did you compare how quickly you can set the course knob with the encoder compared to a button inc/dec press? For me the upgrade from TWCS is incredible. TWCS main throttle pot needed to be sprayed regularly and still started to produce noise after a few days. The TDC ministick had totally noisy Y axis (going down on its own), etc. The long-term STECS quality is to be seen, of course, but I believe in VKB and the much higher price tag. Technically, I have 5 good axes on STECS (2-throttles, thumb wheel, x/y thumbstick), while TWCS had 5 as well (-one throttle axis, but +1 paddle axis), so if I don't count the dual throttle (which is excellent) I actually lost one great spring axis I used as zoom and with a modifier as a brake. But I don't regret it, because I have a lot of new buttons - and I use modifier+ministick as a brake. So yeah, compared to Orion, you will miss many more axes. And if you compare it with something like Eagle grips, there is no comparison in this department. Going from Orion, it's probably not such a significant upgrade and it is much more questionable. Even if the throttle and detent system is of better quality - which I can't compare, but the detent system is indeed genius.

During this training mission, I was previously informed I could use Num+ keys OR the throttle axis to increase the throttle. I hardly know where the keys for the throttle actually are - I'm always using the axis. And then I get to the RWY centerline and I'm informed about the RPM 70% test. I check everything and lower the RPM and... nothing happens. If I press Num- at this moment, nothing happens either, I have to get the RPM a bit higher, then press Num- for the mission to progress. The event should not be bound to using the keys only, especially after I had the freedom of choice previously (which was the right thing, of course).

I understand your point and it occurred to me as well - but I disagree. In many training missions it works as it should - if you should lift the gear, it works whether I use the flip switch or a button. The fact that the voiceover only mentions the basic option is fine. Of course it cannot reflect custom bindings either. That's also fine. But when I use Gear Up instead of Gear Up/Down and it doesn't progress... that's strange. Also - you may start with Su-25T when you already have a HOTAS and your preferred bindings. This applies to any plane, I hardly ever use Gear Up/Down shortcut anymore and often manage to rebind many keys to my "standard" even before I start the training mission. That said - if it's officially closed as "not a bug", I'll accept it, even when I don't agree with it. I just felt like reporting it.

I haven't really tried that, but I have it rebound already anyway - so I may not want to press it. But I bound the action to some obscure key which worked and went on. So I guess it's more about the action, not the key in this case. But that still doesn't fix the mission properly.

Yes, unless you choose a different directory for the save - which is possible. It is just the default offered directory. Just try it yourself: And then you see: This is otherwise not used by DCS at all. The configs managed by the game are all under Config/Input folder: This also includes your modifier setup for the plane, which is not otherwise savable. So, manually, you "back up" to InputUserProfiles, but it is all under Saved Games/<dcs-folder>, and you may wish to back it up somewhere else.

In the first Su-25T training mission when I take off and use Landing Gear Up binding (e.g. on HOTAS) Matt gets stuck on the instruction that I need to press G. I don't mind the specificity of the message, but I used Landing Gear Up action instead of Landing Gear Up/Down - which I had to rebind again to let Matt go on with his instructions. I believe this should be some easy fix in the mission, to check for the state of the gear instead of the binding - no need to redo any voiceover.

On L-39 there is a twist on the throttle grip that controls "target distance" for the sight. I use the ring-finger encoder configured as axis for that. I still have to make like 4 moves to go all the distance (and it is still not fluent, of course) - but for that it's usable. I don't need it that fast nor that precise. Although on TWCS you could have that. So I live with that. I'll also try it for radar elevation in more modern planes, I guess it will be acceptable. The encoder under the ring finger is also easy to mess with, so I'd not risk binding it to anything I can't change accidentally. Target distance or slight change in radar elevation is not a problem, so I guess it will work for that. BTW: If you want to use the encoder for anything axis-like, you better configure it as axis, because using an encoder for increase/decrease actions is even slower than using a key/button you can press and hold.

Yup, I know about that one. But the axis has big steps for each click. There is nothing in between. It's not a deal-breaker, but it's annoying. Encoder is very poor substitute for an axis. I didn't know how poor, but it was worse than I expected. For some axes (where not enough resolution or fluency is OK) it's usable, but for many it is a big compromise. In the end I decided to control my zoom with buttons - I use MB2 hat forward/backwards + press for zoom reset. I wish I could do it with an axis, but I'm over it at this moment. I still miss at least some axes for other things (L-39 can use more axes, so can warbirds), but I already understand I can't expect this from the throttle. Otherwise the throttle is very good.

I have Gladiator joystick and use the encoder as an encoder. Is your zoom fluent as a real axis? How do you do it? Mine encoder 'axis' has distinct steps. I don't want that.

That means you did not save the profile explicitly - those are your saves, not game's saves. You have to click on the device dropdown menu at the top and by default this is the selected folder. It's your backups, but still stored under Saved Games folder. But not to be confused with automatically managed input config of the game (Config/Input), separate directory is used.

OK, I've got mine for two days. It's a great piece of gear. I love the detent system and overall feel. However, one of my fears came true and so far I can't get to a satisfactory solution. I love the encoders on the STEM module, they are useful and I'll use them as encoders. But so far, I hate the encoders on the grip. They are no substitute for a real axis. True, they can be configured as an "axis" and move it relatively, which seems fine, but their step is way too big - ~15°. This is fine for encoders, but not as a minimal step for an axis. You can have either a fast and imprecise axis, or a slow axis that is hardly usable. Do you have the throttle and prefer the encoders? How do you use them? For what function in what planes? Do you use them as encoders or mapped as an axis? I know we're talking "money" here, but I wish any of the triggers had a spring-loaded axis (e.g. for eastern-style brakes if you don't have a stick with it) and there was a spring-loaded self-centering axis and another normal rotary axis instead of those two encoders. Encoders can't even work as push-and-hold for some action. The rest of the throttle is great. I like the Standard version, good size, not that much bigger than my old TWCS, and actually narrower. Great upgrade with tons of new possibilities. But I'm not sure when (and IF) I overcome those encoders on the left grip. Not a good substitute for an axis, and I have no use for encoders there. So far all the uses I came up with would be better served even with self-centering two-way switch/hat.

I'll gladly contribute this kind of changes when the time comes. I know that after PP change I have to regenerate the plugin, that's not the problem. (I do this after upgrades as I enable EU speed in common data. No problem.) How about those inverted sliders? Is there some kind of way to do something like (65535-<valueFromBios>)*-1 in the PP file for that =ctrl(...)?

I don't think there is, it seems that the previous plane goes offline when you actually start another plane (change slot and click Fly). That's how the events are delivered.

Hi @xoomigo , another question popped up during my stab at UH-1H panel. I'm adding volume mapping for radios and I've got a couple of problems. I know you're generating PP files somehow and the problems are probably on the DCS-BIOS side (if not DCS itself), but PP file is the place where I can fix it: Many names are quite terrible, short, non-specific. E.g. "Power" is actually VHF COMM Power, but that's difficult to guess. And there are two "Volume"s and two more "Volume Control (step...)" for various volume knobs. It seems that the PP order is preserved, so eventually I can map it all somehow. But adding insult to the injury the volumes for the radio are INVERTED! Max is 0 and vice versa. Can I somehow redefine the =ctrl(...) expression to invert it? I can be creative with inverted colors and have slider going from top to bottom, but that sucks. There are also minor offences like Dome light saying that 0 is WHITE when in fact it's GREEN. But this is no problem at all, I can just add a comment to the button and march on. Compared to inverted sliders this doesn't bother me at all. But it all brings the question. Do you regenerate those PP files every time, or do you manage them separately and only merge in changes from DCS-BIOS? Would it be possible to fix it on your end or should I manage my own patches for PP files - for times of DCS-COINS upgrade.

Guys, what is that COMM TEST button on VHF radio supposed to do anyway? I press it when out of tune - nothing, in tune - nothing. Manual - nothing (except there is a binding for it). I can use that radio to contact the tower, so I guess I here something through it. But what does the TEST button do?

I'm mapping these volume knobs to sliders in Touch Portal via DCS-COINS and DCS-BIOS - and I noticed that they are inverted (0 = max value and vice versa). Is this somehow related or is it just DCS-BIOS issue? Originally I thought it is, but seeing things working "inverted" here, I rather ask before bothering those guys. I also noticed that many right/left clicking in 3-state switches is exactly opposite to "ED standard" (e.g. L-39) where right click goes up and left click goes down - but that is probably a completely different story.

On the collective, search light hat is configured so that EXT is up/fwd and RETR is down/back. I set my hat the same way. But when I actually press EXT binding, the hat in the cockpit tilts AWAY from the EXT description (down). I don't know what the real movement of the hat is, but isn't this a bug? For L/R it acts as expected - the hat tilts toward the used direction. Is this inversion in real UH-1H as well? This looks more like a cockpit bug. Actual function is fine, EXT extends the search light in the exterior.