ShuRugal

The way force trimming works in DCS (or any sim) is a compromise which doesn't really reflect how it works IRL, unless you have a force-feedback setup. IRL, force trip and autopilot work together to physically move the controls, but only using a tiny amount of force. All the pilot has to do to override it is push slightly harder on the controls. There won't be a moment where the helicopter suddenly "jumps" to the position commanded by the pedals like in DCS. So, real Apache pilots just have to push the pedal where they want it. no "overshooting" caused by the trim logic engaging/disengaging. That is a limitation of the sim. IMO, shooting rockets from a hover is just a waste of rockets in DCS. you CAN do it, but you will always be more precise shooting rockets in a running engagement, because it's easier to make fine adjustments in forward flight than in a hover.

Also worth mentioning that the HI/LO/DIR trajectory settings do nothing in LOBL. if the missile sees a laser, it will always fly its pre-programmed "i see the laser" trajectory, which is distinct from HI/LO/DIR.

PAR would be an excellent addition, considering that the Navy modules don't have any ILS besides ILCS.

If the mission editor did not change anything, all Apaches will have the same laser codes in each code "slot" (A, B, C, D etc.) Additionally, the default code for A is 1688, which is the default laser code in other NATO lasers - all target pods will default to this, as will laser-guided munitions. If the mission designer has changed the laser codes, you and your wingman will need to understand how to edit laser codes and change which code your LRFD is sending, which code your LST is looking for, and which code your missiles are looking for: https://www.digitalcombatsimulator.com/upload/iblock/f6a/wi36xv816rx9p4slj30ac05w5jnj3sqb/DCS AH-64D Early Access Guide EN.pdf Check out pages 425 (Channel sub page), 426 (Code sup page), 427 (FREQ sub page) 463 (laser code and missile channel overview), and 470 (SAL missile setup page) of the current version of the Early Access guide (linked above) for some quick overviews of how to change which laser codes you have set up and are using. If you are not sharing a laser code with your wingman by default, the steps to get onto the same code (or check codes) are as follows: 1: navigate to the FREQ sub-page (WPN -> CODE -> FREQ) 2: select one of the Code slots (they don't need to be the same, but it helps for coordination if they are) 3: assign the value you will use to that code using the keyboard entry unit (example: press 'L' to select code Lima, Keyboard Unit becomes active, type '1788' and press 'enter, value of L changes to 1788) 4: navigate back to the CODE menu and set the LRFD and LST to Code L 5: navigate to the CHAN page (WPN -> CHAN) and add code L to the list of avilable codes on the bottom of the menu 6: Navigate to the SAL settings page (WPN -> MSL) 7: set PRI channel to L after completing these steps, you and your wingman should both be sending laser code 1788 with your LRFD, your LSTs should both be able to find 1788, and your missiles should be looking for 1788. Note again that this is ONLY required if the mission designer changed the default laser codes. If the mission designer did not do this, then every apache defaults to using 1688 on channel A.

To be fair, this one was specifically an over-torque event. there wasn't enough power available to pull out of that dive at the height the pilot held it to. If i recall correctly from when this happened, the pilot and CPG both faced administrative punishment for this one.

in the case of loss of both engines, you have about 1.25 seconds to recognize the problem and get the collective on the floor. if you don't react in that window, the rotor RPM will droop too far to be recovered.

unless, of course, you're doing digital flight simulation where you can't feel the Gs, don't get any control feel in the stick and pedals, and have no peripheral vision to use to monitor the dashboard gauges. At the end of the day, BFM is about energy management, and you can't manage your energy if you don't know what it is. Even the highest fidelity VR setup doesn't give you the tools you need to have the level of awareness a pilot relies on to perform BFM in real life. Some concessions have to be made to how you approach the mission simply due to the fact that the simulation doesn't give you the same tools you get from the real thing.

Can this be clarified in the manual? As written, there is nothing in the manual which contraindicates the supposition that shutting the jet down with a valid alignment would allow aligning with the stored alignment on subsequent start, provided the plane was not moved.

Starting the engines with the pyrotechnic charges seems slow? the spool up rate using the cartridges seems to be about the same as using the air source starter. Considering that the pyro charge only burns for a few seconds, this seems slow? Every real-life pyro start i've seen kicked the engine core up to self-sustaining RPM in just a few seconds. This video of a Canberra doing a dual cartridge start appears to take just 4 seconds from firing the cartridge to the engine being at ground idle. in this video of an F4 cartridge starting, the charge fires at 12 seconds, and by 18 seconds we can hear that the engine is accelerating under its own power, which means it must be at least 35-45% RPM (45% being where the book says the engine is self-sustaining and the air hose can be switched to the other engine). After that point, it takes the normal time from "sustaining" to "idle", but "zero" to "sustaining" is much more rapid than currently in sim. When you think about how a pyro start works, this is the expected behavior. The cartridge cannot sustain the volumetric rate required to turn the air impeller starter for more than a few seconds, so the tradeoff is that it makes the gas flow that it can at absurdly high pressure in order to accelerate the engine to a self-sustaining speed in as few revolutions as possible, so that it gets there before the cartridge stops burning. I'm sure this will be addressed as the module is tuned, it just stood out at me when i was playing with the feature, so i figured i'd comment on it.

lol, you are an AMAZING hypocrite. I refer you to the first point I made in my previous comment, the one you pretended not to read.

congratulations, you have now spawned a sub-thread to complain about one off-topic comment in an otherwise on-topic post which is longer than the actual on-topic thread. Is there some kind of award for that? Also, the person you were complaining about is the original poster on this discussion, some might say that gives him the right to take the discussion wherever he wants, once his main thrust has been satisfied.

That isn't the question which was asked. The GAU-8 has a recoil force of roughly 45 kN when firing at its maximum rate. The TF-34 has a thrust of 40.3 kN. So, the answer to the question asked is "yes", or if we want to be pedantic, "no, it's 4.7 kN GREATER than one engine". What you said was TRUE, firing the gun has no notable effect on airspeed, but this is because the gun is typically fired in short bursts, and the total mass of the aircraft is great enough for a short burst to not make an appreciable change, especially when both engines are producing thrust and/or the aircraft is diving on a target. is is NOT because the gun does not have significant recoil thrust.

Just wanted to chime in with my experience being detected when i feel i shouldn't in the AH-64. For me, the biggest problem is surface radar units like S300 or 2S6 detecting me while i cannot detect them back because there are trees or buildings in the way. The way i've been circumventing this issue has been to use George, who can cheat and see ground radar units using whatever broken mechanic allows them to cheat and see me, but it kinda breaks immersion to be detected through a dense forest or buildings, sometimes even through actual terrain(!), and have to use George to magic-detect the offending unit in return.

It's worth mentioning that Direct/High/Low ONLY applies to LOAL shots. a LOBL shot has its own trajectory which overrides the direct/high/low behavior.

lol, i didn't even notice the age of the thread. For some reason, the forums notification function put this thread in front of me, and i lizard-brain responded without reading date stamps. As far as hardware to run the game.... I was running DCS in VR on a GTX-1070 all the way up until late 2021. I had to tune the hell out of it, but i was getting 40+ FPS reliably in helicopter mode, and 50+ in the mile-high club. Currently running a 3070, eyeballing a 4070 because 8GB of VRAM is starting to be an issue in terms of <profanity> just soaking up RAM for no reason (looking at you, VR Chat)

Using an encoder wheel is definitely another good option for pit builders to make a pull-handle that doesn't require special coding!

This community has had a serious issue with gatekeeping around hardware for as long as I have been a part of it. Really needs an attitude shift. Insisting that people NEED to buy the latest and greatest bleeding-edge kit to get the minimum level of usable performance out of the game is harmful to the community, not helpful. All it succeeds in doing is driving people away who cannot get the top-end hardware.

This would be an excellent addition to the filters - just add a table to the server advertisement which contains the number of slots total and currently open for each module. Then add a component to the client browser to let the user filter both by specific module as well as a filter to hide servers with no open slots the client can use.

If Eagle does not move on this (or does not move quickly) another option for simpit makers is to have the ejection handle not directly connected to a switch, but to a sliding cam with 3 lobes which activate a momentary switch as the cam is pulled past it. Three pulses on the switch, one motion from the user.

I feel like it probably fits within the spirit of some of the other options in the Voice Chat menu (there is, after all, a full Discord-style voice lobby function for people who care to use it), but at the same time i feel like ED may not feel particularly motivated to implement channel splitting, depending on whether or not the base elements required to support it already exist in the VC engine. I'd be all for it if they did, QoL features like this absolutely have a place in a serious sim, even though i wouldn't personally use it. I'm just saying that I feel like this is niche enough that ED might feel it is already adequately covered by having the visual indications of which radio is receiving both in the cockpit and in the VC overlay UI.

I love using the AAR light bars in VR. They provide a nice little groove for aiming my HUD compass tape at. Like a set of pistol sights. Oh, wait, you mean they are supposed to be illuminated???

I've never seen an aircraft com panel with the ability to split radios between ears IRL. I know that Air Traffic Controllers do this so they can work multiple sectors at once, but i've never heard of it in an aircraft. Certainly none of the radios on aircraft modeled in DCS have a balance knob. As far as knowing which radio you're receiving on, most DCS aircraft do have a visual indicator to show when they are receiving so that you can identify what radio a call came over.

https://www.ecfr.gov/current/title-14/chapter-I/subchapter-C/part-43#Appendix-E-to-Part-43 600 feet of error at 10,000 is nearly eight times the acceptable error, as spelled out in the Part 43 maintenance regulations.

stationary drogue connector on the ramp, of course. Just extend the probe, taxi up into it, and start filling!

Had to bump this thread five times over the course of two months before it was acknowledged and reported to the internal team. There is absolutely a need for a more robust bug report ingestion and tracking process. It shouldn't even be possible for a bug report to go completely UNNOTICED for that long.