Jump to content

Whisper

Members
  • Posts

    691
  • Joined

  • Last visited

About Whisper

  • Birthday 02/12/1975

Personal Information

  • Flight Simulators
    DCS / IL2 / MSFS2020

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. There's no lock on target through the periscope, the DCS engine has no way to know what is your target, so I'd guess the "attack my target" can't work with sensor that have no lock on ability
  2. And it's a preview, what did you expect .... Some pple really love complaining
  3. Hu? I wonder what is presented from 2:50 to 7:40 then....
  4. All airports do not have ILS set up in both directions, in DCS. It may well be that Larnaca only has antennas set up for the 04.
  5. AFAIK rockets are not intended to be fired from a hovering position
  6. Because it's inevitable if you model the behaviour like the real life counterpart : pressing trim up release the trim brake on the stick, release the trim re-grips the brake on the stick at the place the stick was when you released. This is the way ED wished to model it, true to IRL behaviour. Since our joysticks cannot stay at the position we commanded but will always return to center, we're stuck with either one the 2 drawbacks you mention. If you want to get rid of it, you need to model trim button behaviour differently from the real thing. I think you propose that when pushing trim up button, we actually indicate to the system that our expected trim position is the stick position when trim is pressed (unlike current behaviour where expected trim position is the position when trim is released), and that the trim button pressed neutralize input, which are given back when we release the trim? That way we could press trim up when in target stick position, place the stick back to center without impact on attitude, and release trim button when our stick is back at center. Is that so, or do you have something else in mind?
  7. It is the same but also kinda different because there's no delay after button release in the Apache, where we have like 0.5s to center back the stick in the other helos.
  8. This looks kinda logical to me. Slave redirects your sensor (TADS) to your acquisition source , unslave gives you back control through the TEDAC . Your acquisition source is the laser seeker, so once the lasing is on, the seeker catches it, and slaving puts your TADS on point So that should work... provided the seeker finds the laser point, IE is looking in the general vincinity of it, that may be your issue Do you also have a 9 line from the JTAC? If so, maybe using a markpoint on coordinates and slaving to it would do the trick Edit : warning, many edits after initial post, I didn't properly read your post in the first place
  9. Exactly this! Add to this the fact that the Apache is FAR more reactive than the other helos and it makes the difference really noticeable, actually, even though it's technically minimal. Working on this delay and if feasible, Apache twitchiness would help far more than a "trim reset" option
  10. To each his own, no pb with that Central trimmer bugs on me (DCS often do not recognise that the stick is back at center, leaving me with a dead stick). I just don't understand the hyperbole behind describing the apache trim as totally alien to the other DCS helicopters. Technically, the diff isn't that much (there's very short delay in Mi8 before the trim kicks in in default mode, and afaik that is all that differs, and yes, I think they could easily put it in the Apache, but I'm no DCS dev, so... ) between the trim implementations. Like you say, add it to the general Apache twitchness and the result can appear violent, and thus I'm not sure how a trimmer reset will solve issues. It's going to be a very violent reset, actually, seeing how reactive the Apache is to input. Wouldn't working on a delay and a more dampened input be better?
  11. It happens all the time if you don't go back to center fast enough. The only difference is the delay you have to do it
  12. Changed to what default behavior? Because the current Apache "INSTANT TRIM (FFB Friendly)" behaves the same as all the other "Default" in the other choppers to me. What exactly makes the Apache ""INSTANT TRIM (FFB Friendly)"" different? I don't see the "it's nothing like trim in other helicopters" part AT ALL on my side. It took me zero second to adapt because it was behaving in the same way (only talking about cyclic trimming, here)
  13. I'm not here to prevent the request, if people feel that's a good addition to them, I've no issue with that. But just a genuine question : what is it helpful for, actually? In fact, what is that "neutral" position? I'd argue there's no such thing, you just need to place your stick in the position needed for your bird to be in the desired attitude, and then you trim, and voila.... Each time I decide to use a "trimmer reset" button, it creates more problem than it solves, personally : either my current trim point is far from the "neutral" position, and the result is a violent change of attitude of the helicopter with potential catastrophic event incoming, or it's so close to the neutral position that an actual light manual re-trim in the desired attitude (because actually, the "neutral" position is never optimal) will achieve better result. Maybe, once on the ground, it's usefull ?
×
×
  • Create New...