Rangoon

Thanks, Reaper6. So what still seems odd is that it is so consistently a value that is two-thirds of the actual value (what the tower states). Why two-thirds? I've had missions where it was 9/6, 6/4, and 2/1 which I assume to be rounded from 1.33ish. It's not a conversion, since none of the sensible conversions to/from meters/second jive (mph, knots, kph, etc.). I mean if the wind just always happens to coincidentally pick up by 50% every time I get into the cockpit, then so be it. But it seems unlikely. Curious.

Can some please explain how this functions in the DCS Black Shark? I have tried various positions and haven't noticed a difference on any indications in the cockpit. Where should I look to see this functionality demonstrated? For example, it doesn't seem to change anything on the HSI regardless of auto/manual mode. Something in the Abris?

The DCS World manual states that this is the likelihood of a bird strike (not actual birds in 3D), but states that 100% would mean "real-world" likelihood. The slider shows no units, and goes to 1000. Is this a percentage? Does this mean that at 1000 there is a 10-times-greater-than-in-reality chance to have a bird strike at low level? Or does 1000 (full right) indicate 100%

This seems pretty consistent so far across multiple missions. For example, the mission "Courrier" briefing reports wind at 8m/s, while the tower reports 9m/s. The PVI reports 6m/s. I don't mind the briefing being different, as conditions change. I don't even mind the PVI being different from the tower except that it always seems to be at the same ratio. The PVI seems to always (other than rounding) display about two-thirds what the tower says. Both are using meters-per-second units. PVI wind is input by ground crew before the mission? Or where does it come from? And why is it always off by the same ratio from actual conditions (assuming tower is reporting actual conditions)?

No doubt, using a checklist would have prevented this, just as in reality. Of course, just as in reality, you get into a flow and change how (or whether) you use checklists. I hadn't flown the Ka-50 in a few days, and my flow had degraded *just* enough for me to make a stupid mistake. IRL, if it's been a while, or if I'm feeling "off" that day, I do go back to using checklists. Might as well carry that wisdom into the sim. Of course with something as complex as the Ka-50, maybe I should make a habit of always using it...but there again begins the cycle. "Oh, I know what to do...this checklist just slows me down..." And certainly using checklists can even create problems. But not likely in this case. And once again, kudos on your kneeboard checklist mod!

I do, I do!!! :clap: Seriously, I do. Thank you for this! I think what we need now are "tabs" for the kneeboard. So many pages. Would be great to have the ability to assign tabs and have a key for next/previous tab (sectional, approach plates/airport diagrams, checklists).

Edit: might as well delete. Ever since the last update, I am stupid. Hopefully the next update will fix that. :smartass: I failed to turn on my intercom switch :doh: thus could see everything happening but couldn't hear it. That makes a lot of sense, now doesn't it? DCS, I love you, for real. :thumbup:

This couldn't have anything to do with the installation method, could it? I upgraded from BS1 (digital download) to BS2 (through DCS interface I believe). But I'm on the very latest version overall (updated again last night, in fact, I believe - small glimmer of hope - but same deal).

I have to agree.

So, to be clear, your Huey trimmer works the same was as your Ka-50 trimmer? And I assume this is without central trimmer mode on? I have tried both aircraft with and without central trimmer mode on, and have confirmed that the behavior is not related to that mode being on or not, but rather with the sequence of events. When I press the trimmer key (t) or HOTAS button (keypress call of t), the trimmer acts as though it's looking for the pilot to recenter controls (the cyclic position diamond hangs for 0.5 seconds, or if central trimmer mode is on it locks the inputs until you are centered). If I *do* recenter at that point, and release the trimmer, the force trim does correctly record the release position, not the press position (of course the idea is most often not to force trim to center, so that behavior already doesn't make sense). Now it *is* correctly recording the position of the cyclic upon release of the trimmer button, however it has already moved past it's 0.5-second pause time, so upon release, anywhere other than center, the input is then doubled in both axes, so immediately jumps. The 3D cockpit cyclic jumps, as does the diamond. It's only correct then once you move the HOTAS cyclic to center, which cannot happen instantaneously, hence the Ka-50 behavior in DCS of the 0.5s delay or central trimmer mode. Is that how your Huey behaves? I would expect, and it should logically be (right?) that the button is pressed, the contols are positioned, and the button is released. Upon release, the position is recorded as the new "center/neutral" and then you have the 0.5 seconds to return to center (or the with central trimmer mode on it locks the control inputs as they were until you do return to center). In the real UH-1H, the button is depressed, the forces acting on the cyclic are relaxed, wherever the cyclic happens to be at button release is where the force trim tries to keep the cyclic. So in the DCS Huey, it should be: press trimmer move cyclic release trimmer return HOTAS cyclic to center sim cyclic is not offset by that trim position from center, while the HOTAS cyclic is in neutral HOTAS cyclic input from neutral is now added to the sim cyclic (after the 0.5s delay or neutral HOTAS cyclic) The point about relaxing the force trim pressure while the button is pressed is only hypothetical unless you're using a FFB stick, which I am not. Once trimmed, you move the (non-FFB) HOTAS cyclic just as freely as before, but now it's adding input to the sim cyclic's trimmed position, so pressing the button doesn't release any forces because they are undetectable in this sim/scenario without FFB. And as you'd expect, the cyclic diamond doesn't move when the button is pressed. It does, however, hang for 0.5 seconds waiting for a centering of the HOTAS cyclic, which it shouldn't. It should do that *after* the button is released. Right? And this is what yours is doing? I have tried deleting the UH-1H input bindings folder, I have set, unset, reset, unset, and reset again all of the autopilot and trim related options for the Huey. What mine is doing defies logic, defies the manual, defies reality, and seemingly defies other users' experiences.

Works for me as well.

My previous post was incorrect. It still is not working correctly for me. I thought I had tried it with just the keyboard command, not HOTAS, but either didn't or didn't notice it wasn't working correctly. I tried with my HOTAS, which I had forgotten that this morning before I left for work I had adjusted it to be *on release* rather than press. So it was a work-around I was seeing, not the proper DCS implementation. I tried again with the keyboard ("t") as well as HOTAS on press, both yielding the same behavior. No, not for me. Here is how it goes for me: - Centering force set at initial point - push force trim button - the cyclic position gets paused for 0.5 seconds while the trim is updated - cyclic force trim is updated and added to actual control/HOTAS input - release button - nothing changes on button release (all changes/updates/effects take place on button press immediately) So this is distinctly different from how yours is behaving. I want what you have!! :) Good idea, and indeed I have. The behavior is the same except for what happens at the cyclic pause stage (on button press, not button release). With central trimmer mode on, the whole things freezes there until the cyclic is centered (as to be expected, and like with Ka-50). Without, there is a 0.5 second pause (like with Ka-50) and then immediately combines the HOTAS input with the offset force-trim position (like with Ka-50). The problem of course being that this should all take place on release of the "t" key or the trimmer button, not on press. Good idea. I tried this, but no change. I also have the latest update (from a couple days ago). Why is my particular Huey behaving differently from all of yours? Is this some kind of practical joke from ED? Hahahahaha very funny!!! :megalol: Now please let me have the normal Huey back :) :joystick:

EDIT/delete

Thanks for the ideas. I will try them this afternoon.

Not sure if it changed. Maybe mine is not working correctly? My force trim engages immediately upon button press, not on button release. Ka-50 works on button release for me.

On page 43 of the DCS Huey manual, it correctly describes the behavior of the force trim button, being that it reduces the force to zero while "pressing and holding the force trim push-button switch on the cyclic..." At least in the UH-1 Victor model which is the UH-1H outfitted for HEMS, that is the behavior of the button, plus the fact that when you release the button the force trim actuators are re-centered to that new position. So you press, hold, release. The hold zeroes out the force while depressed, and the release sets the new position. In this sense, it's very much like the DCS implemenation of the Ka-50 trimmer. I'm just curious why the same wasn't done for the Huey? It's easy enough to assign the HOTAS command to activate on *release* of the button, rather than on the *press*, but if one were to use a FFB stick then you would also presumably want to feel the forces zero out while holding it. And if the manual states is correctly, and the Ka-50 is implemented (presumably) correctly, why not the DCS Huey? I know, it's a small thing. But someone took the time to write that statement into the manual, and it reflects reality. To me, it also feels better to hold the button while everything gets dialed in, and the release to set, rather than hovering over the button, dialing in, then pressing to set. And any decent HOTAS software can accomplish this as a work-around, but why not code it this way from the beginning?

I have been spending some time in the Huey as well lately, and I notice they already have such a system in place for the "autopilot" in that module. It shows white indicators for where the copilot is placing the controls in addition to the usual indicators for your own inputs. Of course, in the case of the Huey, the pilot controls are disabled though still show (HOTAS, not aircraft controls) position, while the copilot controls override. In the Ka-50, the white indicators would just trail or lead the pilot controls within that 20% authority. I think that would be really insightful. And if the system is already coded for the Huey... (I won't say it).

Ding ding ding ding ding. Well if nothing else, that was easy enough and is working like a charm. Maybe no one at Mozdok will notice I'm not Russian. They armed and fueled me just fine. Wonder where they got the M134s... Good thing I took a few years of Russian in high school.

I tried the mission which Lino_Germany so kindly supplied in this thread but the fuel truck just drives into my tailboom and breaks important parts of the aircraft. Am I blind or is there really no cold-start practice mission that comes with the Huey module? If not, I suppose I will tinker with the fuel truck's waypoints. I just haven't spent any time with the editor and merely wish to practice the Huey startup in a scenario like what the Ka-50 has. I tried making my own mission, but admittedly gave up pretty quickly and came here to look for something. Maybe I could just edit the Ka-50 mission to be a Huey instead...hmmmm....

That does sound sensible, and in line with the DCS mantra of integrity in modeling what can be known. But they are also both crew of two. The Ka-50 would become basically legacy, and will have been the only single-pilot attack helicopter in the series. I think it's a fascinating platform considering how unique it is, and it seems like it will over time be antiquated in terms of the sim, unless it is "updated" to being combat-modern *for its era*. Obviously DCS is tackling multilple eras, so the idea of an antiquated platform doesn't really apply, but the Black Shark is sort of stuck in a kind of limbo being a prototype. I can't argue with the logic of letting it just be what it is, but I also see huge potential in taking this unique aircraft further. Not that it matters what I want.

I agree that it sure appears to be a bug. It's distracting/disorienting going back to NAV and having your map left in North Up from the ERBL submode, then having to cycle through four pages or whatever getting it sorted. I wonder, if it *is* a feature, if they found it disorienting to the pilot to go digging in the ERBL mode and then have the orientation flip around again while trying to put these new discoveries into action on the Nav page. But I doubt it.

Thanks for the reply. I think the system is clear now. And in fact, after rethinking it, today I decided to try without the "CENTRAL POSITION TRIMMER MODE" and as of now I like it better without it. Since I can zero my controls with the button, I don't have a problem with the timing, and there have been a few "mis-clicks" on my part here and there where my trim press was prematurely released, resulting in a frantic couple of button presses on my HOTAS script to get it right again. Without centering force, it can sometimes be a bit challenging finding the precise neutral point on the cyclic, which is what the sim is looking for to give me back control. When all is fine, there is no panic, but in the wrong situaiton I've gotten confused under stress and had some near misses. Now I just zero out if the trim was done right, and if not, at least I'm still on the controls. I do hope CH is secretly working on new controllers, especially a FFB setup (all controls, even collective). What a joy that would be (no pun intended). In general, I hope FFB makes a comeback. It was a real thing in the past. Seems like lately there is a renewed interest? And new products.

:cry: But DCS has evolved so much since the very beginning, too. They could revitalize the Black Shark relatively easily as time goes on and may find it worth the effort to put a new coat of paint on the old bird. To make use of the new features, etc., down the road. They could, right? Right? Please tell me they could. Please. I won't waste any time arguing for why/how it makes sense as I'm sure it's already been done to death. My life may come to a complete standstill once an Apache module is released, but until then, and even after I suspect, the Black Shark is an immensely important part of what DCS is (and the original aircraft). The Black Shark is one of very few peaks in PC simming.

I have generally felt this way, too. It's one thing to strive for 100% authenticity (which already isn't the case), and another to find a compromise between verifiable knowledge and responsible speculation if it's done with a high degree of integrity. I think a little *educated* and careful guesswork from the experts within ED (and partners) would be welcome by some (many?). Especially when it comes to modeling things that do exist and are neither cutting edge nor future tech. FLIR has been around. Radar has been around (I'm not suggesting radar be added to the Black Shark...but, Longbow?). These systems have broadly known capabilities and limitations, though a specific model of FLIR of course may not be precisely known. Just as the manual so appropriately labels things as not implemented ("No function."), so could it label things as "speculative" and give brief details/arguments of the grounds for its modeling. Perhaps there could be "variants" of each aircraft which include speculative systems, such that a server could limit their use. As DCS expands as a combat sim, I think there is a lot of value in this. If this means that ED is "going casual" then I'm pretty sure none of us want it. But to hold the spirit of the "study sim" at the forefront during efforts like this could result in some even more realistic combat environments, as whitehot alludes to. ED is modeling a prototype, as Flagrum points out. But what sense is that in the long run? Why not model the Black Shark in its full glory, having been put into full military production? That seems like a short leap to make, and in the right hands for such treatment.

I can imagine it sounds crazy, and it's a little difficult to describe. I use CH controls because I really like the powerful software and scripting capabilities, plus everything is integrated (FighterStick, ProThrottle with FrankenPotato mod, ProPedals, MFP). I don't like springs, though, so I took them out of the Fighterstick and ProPedals and replaced them with weak rubber bands. If CH made a FFB stick and pedals (heck, and throttle) that worked with their Control Manager software and all devices together like this, I would have that. But they don't. So no springs, but also no force feedback. So the stick feels very much like what I'm used to in real helicopters, except there is no feedback of course - what matters to me is that the sensitivity and the precision are right. I just need to cope with the fact that the stick won't return itself to center, nor will it hold itself in place like a FFB stick. So I have a script/button system where I can just tell it to either hold its last position while I let go of the stick, or go to center. Then when I'm back ready to manipulate it, I tell it so. It's a very elegant and nice system, for me. Got rid of my springs for much higher precision and subtlety (like a helicopter should feel), but kept my favorite controllers/software. So for me to trim the Black Shark, I press/hold trim, position control inputs, release trim, and immediately zero my controllers (cyclic and pedals) with the press of a button. I can then either re-enable if I need to input right away, or I just let go and the controls are at neutral and the DCS BS2 trim system is happy. Then, when I want to hand fly, I just center my controllers and press a button - I'm back in action. I never had to deal with physically centering within 0.5 seconds. In fact, I use the option to wait for a center input before allowing further inputs (CENTRAL POSITION TRIMMER MODE), so that part isn't important. That mode keeps everything nice and clean, and the process is easy (the scripting part was not! :wallbash: ;) ) I have time in all the Robinsons, Bell 206 Long Ranger, OH-6 Cayuse, and Brantly B-2B. Not a lot of airframes, by any means, and no Black Shark time, but these aircraft all felt far more similar to each other than different. So I'm assuming the Black Shark is a subtle machine with finesse in the controls. As such I like this setup, but it's still no FFB, unfortunately. Some day. It's a matter of priorities and I'm happy with this compromise. That mod isn't right for my setup. I like having the trim system the way it is. I always center my pedals (just like I do my cyclic) before I start hand/feet-flying again. It's just a habit. So I don't have problems with the pedals like what the mod tries to solve. Seems like a cool solution, though, for those who do! :)