virgo47

Hi, thanks for the update. About the inversion - do you mean that having an inverted value would cost for any other action as well, not only when the slider changes? And if so - only if used or even if added as a feature (minus some if check, perhaps)?

@xoomigo, hello. After some time with L-39, I returned to UH-1H. And the beast has all the volume knobs inverted. My memory is overloaded recently, but I recalled that we talked about it - the need to invert the sliders, so that 0 is max and 65535 is min. Please, is that feature still on your TODO list? Currently, I'm using a nasty ugly trick with inverted colors - but this means I have to slide down for more. EDIT: I'd also have some PP patches for Huey (duplicated "Volume" names from DCS/DCS BIOS are quite confusing), but I'll probably get more, so just let me know when you're about to release and I'll sum it up then. I started the cosmetics contributions to DCS-BIOS - such as Description fixes, e.g. deduplication (adding specificity) or fixes of typos (e.g. Back vs Front for some L-39 elements). This means that when they release a new version and you'll use it, eventually some descriptions will be fixed. To fix it at the source (DCS-BIOS) makes more sense for these things. EDIT2: What DCS BIOS build do you use? Is this the current official repo now? https://github.com/DCS-Skunkworks/dcs-bios

It's better with those things, but it's not "nothing". I never wanted to transform scale and rotate, perhaps because I never expected such thing from the current editor, but many times I wanted to move/clone a few selected units - and use marquee select for that.

Mentioned in another thread, but I'm not sure you're tracking this: When one tries to resize the device, the bar gets resized but the device does not. After that, you can also freely move the bar away. To see the new position and size you have to cycle the view of the device (off/on).

Hi all, I tried NS430 after a long time, in MT the brightness of the scene is not affected anymore, however, the NS430 itself seems very dark: This is in L-39, so it's probably modeled somewhere where the gunsight is. The display is fine, but the rest is mostly this rather flat shades of black. As I turn, I can get it brighter, in some particular directions I can even get it like this: But this is only a very particular angle, most of the time it's significantly darker or plain flat looking. Would it be possible to make it brighter overall or at least not so dark in the extremes?

I fully understand why it can't may be nontrivial really. Just because we see virtually the same set of parameters (sometimes some go away, e.g. between FLAG IS TRUE or TIME SINCE FLAG there is additional time) it doesn't mean the dialogs are designed to share the info, it can even be programmatically a different piece of input (and perhaps if it isn't, that's what caused the problem, just speculating here). Also, if I first chose a wrong action/condition accidentally (non-flag) and then another one with the flag, it would be nice to see the original values - and it works this way in conditions. E.g. after going through a few completely different actions, if I return to FLAG EQUALS FLAG, both flag name inputs are preserved. The UX question then is: If I switch from condition FLAG IS TRUE with 6 to FLAG IS FALSE and change it to 5... what should happen after I change the type to FLAG IS TRUE? Currently, the new 5 stays there, which is probably what we want when working with flags. But if we looked at each set of parameters for each TYPE as a separate subdialog, then seeing 6 would also make sense. Finally, these are not even dialogs, it's just a bunch of inputs, no confirmation, whatever you do is applied. I guess all this affects what is possible and what is difficult to implement in ME. I'll not comment on the architecture of ME.

I guess the undo can be the harder one, but why the "marquee select" does not work is a bit beyond me. I often try to select multiple units only to misclick (which is extremely easy) to lose the whole selection. I wish it was easier to consistently select the units without accidentally deselecting everything.

I like this "bug" a lot when changing conditions... it's a small but nice life-quality feature. Hopefully, they can make it work in actions as well without "messing with other parts".

I use Touch Portal with DSC-COINS plugin as a poor man's control panel. Matric can be used for similar purposes but I don't have experience with that. I like it, it's flexible per plane and gives me more control with visual feedback. Of course it's not VR friendly. Example panel:

I absolutely agree with your last sentence. As for the context switching (I'm a developer too) - it is a thing, no questions about that. But we're not talking a month here, we're talking months, even years. That is beyond the context switching of a developer. This is about the priorities of the company, perhaps they are spread thin, I don't know. I'm not saying they would not like to do it, but they leave many bugs unattended and focus on new stuff instead. There will always be some ratio of bugs vs new features (modules, whatever). The question is how long the bugs are there, how many, etc. As a customer, I don't like the current ratio, but it is what it is.

Welcome to the forums. Please, provide at least a screenshot, what module we're talking about and any other possibly useful info. When the question is very general, nobody can help. (For screenshot, pressing Print Screen should be enough, the file then should appear in your Saved Games/<dcs-directory>/ScreenShots.) Some modules have some binding options missing for some devices - this is super annoying, but fixable - although I totally agree that a new user encountering this is not the best scenario ("look at this mod" or "check this Lua file" should not be the first advice any new user should hear).

That's not the same. That means waiting for ED to refresh the module. There is no incentive for them to refresh older modules based on the demand from users. Currently, they don't even bother to systematically fix the bugs that crop up in some modules from update to update. Also, sadly, BS3 was not trialable, so if one had BS2 and wanted to upgrade to BS3 just to see what was fixed, there was no way to do it. (Granted, the upgrade price was reasonable.)

I can only assume that TM Warthog, being a replica, is also ergonomic - but focused on A-10C. Can you use it for other planes? Sure. Does it have so many buttons as STECS grips? No. I'd say that the main killer feature of this throttle is configurable detents. Nice things are easily adjustable throttle tension (can be done any time you want quickly) and module customization (although you will only do that once). VKB does not seem to like normal switches (there is just one toggle metal switch) and prefers buttons - this shows on the STEM base module. STECS is a universal throttle with unique configurable detents, TDC on the thumb (has its pros and cons, for many mostly cons), many, many buttons/hats/actions, less metal than the competition. It performs great. It's not perfect. Probably none throttle suits all the needs of every person and every plane. Yes, STECS is comfortable. Very comfortable. Even the seemingly overcrowded front of the throttle is easy to use.

I was thinking about "modules" like this. I'd also buy a module called "L-39 bugfixes"... However, ED is not very transparent about what is sold in what quantities at this time, so how would I know whether it even makes sense? Perhaps then something like a donation effort with the goal amount where it would make sense to start something with such dedicated money. Currently, there is no way how one can "vote with their money" on priorities. It's still their business and the topics/options would have to come from their side anyway. As for subscription, I don't agree with it either. But ED must do something about overall quality and care for older modules as well - as we will only get more and more modules and if all of them get worse over time after "finished" it will likely bring some sour feelings. Not to mention many people can be put off by simple things like missing bindings (not actual bindings, but even actions in controls) for some planes/devices, buggy bindings (e.g. toggle is not toggle or bindings doing nothing or other things), buggy training lessons, etc. This all sounds trivial for long-term users and they know how to overcome it - or enjoy the plane otherwise - but I know it can be off-putting. And most of these bugs are pretty cheap. But instead of fixing them in the next version after being reported, they often take well over a year(s). And with fewer people put off by things like that, they could make more money. Speculation perhaps, but quality is important.

I don't own L-39C to test it myself. I know the knowledge can get lost - I'm not sure if the team still has the SMEs that worked on this or, ideally, notes in the code. I nearly asked on Matt Guthmiller's YouTube channel about it, but it felt a bit silly really (what if it broke one of his L-39 for whatever reason). But if you/the team can't get non-contradictory sources, I believe most people would be just as happy if it is fixed in the manual.

@Flappie Just to add one more source, taken from 1991/1992 Flight Manual L-39C Serial No 931529, I've got just some pure-image scan PDF without page indication (p31 in reader): Arguably, it's not totally clear and as a programmer I'd have a few questions about it, just to be sure. (This is a slightly modified L-39C judging from the pictures, e.g. knots instead of km/h speed indicator, but the changes are minimal, no changes in warning/caution lights, and I doubt this affects how this engine-related mechanism works.) Now, again, it can be an error from some other sources, but it really made me thinking what sources were used for the original implementation. Again, the nosewheel and engine shutdown with 730 light is also mentioned, currently not implemented.

That sounds pretty clear then... although so does the engine manual I mentioned, so there seems to be some contradiction on the ground (not in flight). God knows how and why it was implemented originally, whether intentional or not - perhaps there are some comments in the code. In any case, there is a discrepancy between the module behavior and the manual. And the engine does not stop after touchdown with 730 light on.

Perhaps there are some mechanics for the Kola map, no idea. But the list of fixes is really underwhelming.

Did uninstalling some of your mods help? If so, which ones? I encountered this thread when my game regularly crashed on restarting one of the Su-25T Instant Action missions (easy CAS). I'm not sure it's mission-related, but it seems it crashes the game mostly when I ask the mission restart in the outside view (F2 or after I crash and the view is outside already). As for mods: I suspected the Barthek's Caucasus redone mod originally, but uninstalling that one didn't help. I've got a few seriously low-profile mods + DCS-BIOS - and while DCS BIOS does show some errors in the log, it does so consistently (so to say), not only when the DCS crash occurs. As a side note, a crash related to mods... isn't this still kind of a DCS problem that it doesn't catch exceptions (or whatever the equivalent is) at the "extension points" and - if totally unrecoverable - at least clearly logs it that way in the log? Suspicious logs are attached. As a side note 2 - it would help us as well if the log was not polluted by various other warnings and errors, often graphics/shader related... if something is normal, don't report it as warning. And if something is a warning, fix it, or if possible, suggest a remedy, perhaps even in the log. (Sounds overly simple, I know, but as of know, there is no way to tell whether I can do something about a warning or an error.) dcs.log dcs.log.old

Eh? ... Shouldn't this be an English forum?

I don't have a 3D printer (yet) and somehow I manage. The worst part is the resistance... it should be progressively higher away from the center, not like now that it kinda "snaps" and then it moves easily. Yeah, I exaggerate a bit - but really, only a bit. I also use curves for TDC in DCS, but that's another problem, because in DCS you need some minimal value (around 10) to get the TDC moving. So to make it move slowly from the get-go (right after you move it off center) you need to add user curve with a steep step at the start, then a smoother one later, and also probably some saturation as the max speed of TDC is often too fast (at least in FC3). All that said, it's not worse than the TDC on the TWCS... but it's not that much better really. (Index vs thumb issue aside, one can really train it for the thumb.)

I've used it for 7 months and I understand all those points mentioned in the OP. I don't need to mount it, but I also wondered about the screw hole under the USB connector, although you can unplug and plug it... Now the main points: OTS - it's far from perfect, but to my surprise, I got used to the thumb. But I wish it was easier to move from the center and progressively harder towards the ends. This one is kinda harder to start moving and then it goes easily runaway. This is even more so when moving the thumb "sideways" (physically up/down, but logically I map this to side, of course) - because there is even less control in that thumb move. Back and forth (up/down logically) is fine, plenty of control in the muscles. But the move action is way too loose. And with that, I don't even use OTS press to lock, for that I use one of the front triggers, so I don't accidentally move the OTS. And please, VKB, give us some dish shape. This cone is not bad, but it's far from good. Just for fun I tried the rubberized red button from WEAPON SELECT and it was MUCH better. (But of course it doesn't cover the hole and I miss the piece on WEAPON SELECT position.) Detents are great, I use mostly one, but I have one "universal" IDLE+AB combo, still reasonable amount of throttle is left, as I mounted the IDLE as low as possible and also used narrower V detent. I didn't like low (regular) L detent for idle, because it's easy to overcome, and "large" L detent is extremely difficult to overcome in idle configuration, as it goes really against the springed rollers. I'll not try it, but I don't believe it wouldn't break eventually after many cycles. Large V works much better as IDLE for me, and the throttle can start lower than with the L shape. Three detents seem silly to me, not with these quite wide detents (W and L both take 18-19% of the throttle range). I'd welcome some subtle version of W, something that doesn't push the throttle away and the center notch is just a small groove, just to feel it and hold the throttle with minimal force. This would be a great detent that would not have to be configured and great for things like "nominal power". I use DCS curves to set the actual AB position for planes where the physical AB doesn't match the logical one. No problem. You're using even less friction than me. I had problems on the top end, especially the right grip is heavy. I'd also like to use less friction, but it is what it is and this throttle must be pretty tight. Not sure what can be done about it mechanically, perhaps some counterweight, but for that there is no room - otherwise the unit would have to be much higher, I guess. Overall? I also like it. I only talked about the points from OP, so I'll not open "grip encoder-vs-axis" problems and other possible improvements as there are plenty and it would be a different product. We'll see what VKB comes with. I wish they'd give us more grip options in the future (e.g. the right one with OTS on the index finger or the left one with axes options).

I've noticed that some 3rd party dev maps are not available for trial - will this be the case for Kola as well? I guess it's ultimately the decision of the dev, but I don't understand it with terrains in particular, because if one likes the plane, they can enjoy it for 14 days and then exploit this after 6 months again, but with the terrain, if one likes it, it's probably more likely they will not wait 6 months to enjoy it again. Doubly so if they need it for some online play.

Ergonomics is a lot of things. What this throttle does - it does well. I like it under my hand. Everything is easily within reach. But there are some drawbacks - which I'm sure every throttle has - just different ones: Encoders on the left grip are great, but configured as axes they are not adequate substitutes for real axes. Especially the encoder under the ring finger is difficult to operate, some axes (perhaps self-centering?) would work better there. The thumbwheel is precise, but the placement and spiky finish is not the best... rubberized wheel (like on the grip encoders) would be much better. There is no substitute for any rudder axis if you're upgrading from a throttle where you had one. And OTS on the thumb is a thing to consider. I have no problem with the thumb position now, but a better hat/dish would help with the control. Feeling and action (including the press action) could also be better, but I guess these are in the price range (I can't compare). These are all ergonomics things as well... That said, it's a solid product. And what it does, it does really comfortably.

I posted the first two parts of my review trilogy previously, and finally, I got to the last one. This one focuses on detents and various configuration customizations, including quite extensive examples in VKB DevCfg. Let's call it "first impressions after 7 months" in the context of this thread.