Rifter

Elevators are working again - nice!

Seems to be fixed now - did some test flights and the flight ball behaviour was as expected.

If you mastered the other helicopters in DCS it won’t take you long to transition to the Apache. The AH-64 is a quite heavy helicopter. Moments of inertia around the three axes are significant. It’s far beyond what I would call an agile helicopter. The mistake I made at the beginning was to assume the Apache being an highly agile machine and was constantly overreacting on the controls whenever the helicopter made a movement around the the axes. Finally I realised that the AH-64 is quite lethargic and does everything in slow motion (compared for example to the Huey or the Gazelle). So in hover I startet to react intentionally slowly and allowed the Apache to get into bigger movements I actually wanted to have. That taught me to adapt my inputs step by step to what is really needed (speed and amount of input on the controls). And the Apache really doesn’t need a lot of input. Flying the Huey never gets boring because there is always something to do on the controls. The AH-64 might be the quintessence of a helicopter gunship. But when you finally got the hang of it this thing it feels tamely and the actual flying job is rather unexciting. I finally came to the conclusion that the AH-64 is flight control wise the most good-natured helicopter in DCS. Only the UH-60L mod is even more placid on the controls. Which is good at the end because you don’t want to spend your precious brain capacities for keeping the Apache under control in flight - you need most of your biological cpu power for managing your situational awareness, your sight and weapon systems. By the way: Despite your assumption the Apache does have flight assistance in shape of it’s flight augmentation system. Switch it off and you will see and feel the difference.

I have two MS FFB2 sticks. One in original configuration and one heavily modified with extension and resistor mod and a B8-grip. For both there is no imprecision at any position when making micro movements on the stick while force trim off. Feels like a good non-FFB joystick with removed springs. It does have some friction to it though, meaning that it stays in position even when I let go. Using force trim arrests the stick precisely at the desired trim position without any deadzone or unpleasant breakout force when moving out of trim position.

I read this some time ago and was therefor excited to find your mission. It’s a cool setting beyond the typical ‘fight tanks and troops’ scenarios. Like it! Had some trouble though in single player with the little preparation time for startup and entering the coordinates and com frequencies. The UH-60s left their waiting point and were way ahead when I was ready - as rcjonessnp175 also mentioned.

I’ve tested my Warthog throttle and my Virpil CM3 throttle as collective inputs. On both I defined the analog thumbstick as cursor controller. Switching between the two MPDs by moving the cursor to the edge and then ‘pushing it over’ to the other MPD only works on the Warthog (but not reliable). Doesn’t work at all on the CM3. When I define a deadzone on both axes of around 25% it works like a charm. It’s seems that switching between the MPDs works properly when there is only a pure X-direction (horizontal direction) on the analog stick without any Y-component when moving the stick. A deadzone to rule out the undesirable Y-component on the stick seems to solve it. Using hat switches as cursor controller works without any problems by the way. Anyone else observed that behaviour?

I am so sorry for any misunderstanding. Our community here of course is multi-cultural and using text alone is not always the best way of transporting a portion of sarcasm. I hoped for the today’s date being hint enough… So now without any confusing humour: In the past every helicopter mission or campaign I played which included AI-driven AH-64s, created a sigh of ‘will we ever be able to fly them ourselves’ on my side. And now after 2 weeks I still catch my self being like a child and switching and toggling my way through the menus of the MPDs enjoying the pure fact that we have this thing now. For my first self-build mission I included a sound sample from the movie Firebirds with the immortal words of Tommy Lee Jones: ‘Put your hands here, here and there, put your feet, here, here, here and here and do not step here or there.’ - couldn’t stop my broad grin for the rest of the mission.

For me the Apache module is totally broken. This is not what I expected for an early access. After a thorough analysis of the bugs&problems section and the rest of the forum content I have to certify: No thread or complaints about a questionable flight model No dramatic size, scale or modelling issues No complaints about unsatisfying extent of early access content within the module Further more In-game adaptation of monocle and sights gets absurd high approval from community No complaints about any in game access barriers regarding the complex systems And finally (most alarming!) The module creates a suspicious pull effect on fixed wing guys suddenly discovering their love for helicopters It has to be pointed out that the fact that some pilots experience FPS problems, is no compensation for the mentioned list of shortcomings. What’s going on here? Come on Eagle Dynamics! Either you fix this module instantly, or… …I will go to the extreme and consider the Apache as a new milestone in the history of ED and I will feel as a valued customer. Sorry, but sometimes the truth has to be told.

As mentioned from a couple of people here, I also had some ‘wobble’ moments when picking up the Apache into a hover in my first attempts. But the AH-64 is indeed a very stable helicopter. The mistake a made is that I instantly tried to react to the helicopter movements on the cyclic and the pedals as I was used to from the other helicopters. That quickly brought me into pilot induced oscillations because I started to fight the flight augumentation system. Then I realised that the apache does not just tilt or roll away aggressively when not instantly countered on the controls but instead leaves the pilot plenty of time to observe the movement and then to calmly react on the controls without haste. Flight control wise the AH-64 is the most relaxing helicopter experience within DCS for me. Wags was right - it nearly feels like cheating or a… …video game?

Wags clearly uses the Controls Indicator to return his trim to default position in his latest video. I don’t want to have that indicator in my VR experience - I would really prefer a trim reset functionality. I’m using a FFB-stick by the way and I loved the ‘bug’ in the initial version of the Hind where you could reset the trim by double clicking on the trim button. For non-FFB-sticks a trim reset is even more desirable. Trim reset in a simulated helicopter is one of those things which should not be strictly inspired by the real thing. It’s more about the best utilisation of the equipment we all have at hand.

Hey - this was exactly my plan too. Let’s do a multiplayer session and flip and mash and switch things in both cockpits at the same time! Perhaps we should also play some heavy metal as background music and accompany our work with some headbanging while we totally screw up the chopper.

Ok - whatever was planned on ED-side or 3rd-party-side for a future UH-60 module: They are left in the dust for now. I wish them good luck in catching up with Kinkkujuustovoileipä and his crew.

It totally depends on what kind of resistancy the rotorblades meet with. When the blades of the Red Bull Cobra hit the concrete roof of an airport fuel station in Salzburg back in 2017 the helicopter was practically destroyed. The blades came to an instant stop and the Cobra was virtually torn appart. The transmission box was ripped out of the helicopter and flew in a high arc through the air and as a consequence of that even the tail rotor was ripped off together with the tail boom fin. If only the tips of the blade touch something the rotor head and drive system might survive.

Ok – now I understood. Was slow on the uptake here, my bad. So the focal length is hardcoded in DSC and we can’t change it and it’s not even consistent throughout the modules (the latter makes me facepalm). What you describe is funnily enough exactly what people often bothers when using VR headsets in the industry. When VR is used in architecture or car design people often complain about the virtual representation of objects not being to scale although the associated CAD data usually is correct.

I was not aware of the fact that there is a focal length of in-game camera in VR as an additional factor besides the “world scaling” or what you correctly describe as left and right camera. Or are you refering to 2D visualization? How do module creators bring that to use? Do they apply a distortion to the geometry itself to create the focal length effect? Or is there an additional setting of that parallel to the known "Force IPD Distance" and why are we not allowed to change that setting ourselves in the options? All examples of cockpits being “off” in VR I know of are due to geometrically wrong modelling. For example a couple of enthusiast made modules estimate the overall cockpit height wrong (measured from floor pan to upper edge of instrument panel). Examples are the Alfa Jet or the F-104 where you can see in VR that there is not enough room for the pilot legs. The UH-60 is correctly dimensioned with respect to the fuselage but the cluster consisting of instrument panel, center console and seats is scaled too big which can be judged by looking at the remaining space between the instrument panel and the side of the fuselage or simply the width of the seats in relation to the rest of the helicopter. Nothing of that could be corrected by focal length or world scale because it is simply modelled wrong in size and therefore the relation to the surrounding geometry will never match. When the whole cockpit is wrong in scale than at least "Force IPD Distance" can help.

Are you sure? On my side it scales everything including the map objects. Perhaps not obvious to everyone when in cockpit, but when using outside camera options clearly perceptible. Seems consistent to me since "Force IPD Distance" is nothing else than a misleading term for "world scale factor". As long as the different cockpits are scaled correctly the relation to each other (eg. Mig-15 to F-86) should be correct.

I spent some time of my working life on the analysis of aircraft fatigue and the prediction of the service life of military jets by determining so called load collectives based on flight recorder data. The main reason why g-loads on military jets are observed so accurately is to ensure the life span of the birds as specified by the manufacture. Critical structural damage on a healthy military jet up to the point of falling apart due to a single over-g event is not a thing. Don’t know of any evidence for that. Not in training and not in war time fighting-for-your-life events. For instance the F-15C of the Air National Guard which broke into pieces in 2007 was over 25 years old and had a severe fatigue problem because of wrong dimensioned structural parts within the fuselage. Saw a lot of over-g damage on for example F-4s (some of them had 12g incidents according to the flight recorder data) - saw broken avionics, broken panels, jammed control surfaces, popped rivets, bent bulkheads and even a jet engine ripped out of one of it’s mountings. But all of that was repairable. Core problem and pain in all cases was reduction of valuable airframe life time. Gradual damage in DCS during a dogfight due to over-g instead of ripped of wings? Why not, would love to see that. Although I don’t see a big difference between an engaged DCS acrobat pilot pulling 15 g and losing his guns or vital avionics or losing one of his wings. Both puts him out of business. Ripped off wings in DCS is a pure placeholder effect to mask the fact that the devs don’t have detailed information about the realistic damage a specific plane takes during massive over-g. Discussions like these are placeholders too. People pretend to be interested in nonlinear structural mechanics (realistic damage modelling) and cerebral hypoxia (pilot G-LOC) but in the end it’s just about exploiting the last tiny bits of the aircrafts abilities to the absolute maximum.

No. Rather your control surfaces will come off whilst your “egregious” trial to get rid of your wings. Damage always occurs along a chain - weakest parts come first. The structure around the area which attaches the wing to the fuselage is usually the strongest due being the area with the highest loads induced. Worst case over-g scenarios in reality are severe reductions of the airframe life time (less flight hours possible until end of service) or g-limitations for rest of lifetime or donation to the airplane mechanics school or just scraping the whole damn thing.

In the Huey the ball is broken. This is old. It makes me chuckle when folks around here try to justify the behaviour of the ball as something that might be correct by pulling out “scientific” explanations or asking about fuel or payload or specific models. And it makes me sad to read that Flappie want’s some video proofs. This was addressed long ago. There is no need of a proof anyway. Fly the Huey without any wind, comply with the ball, and see how prominent it crabs. No helicopter on earth in coordinated flight goes into such a pronounced crab flight when in a simple ordinary standard run-of-the-mill cookie-cutter level flight without any other external influence. The only answer from ED I would accept in this particular case is: Devs have no time at the moment to look after legacy moduls. Everything else I consider as a diversionary tactic to keep the community busy gathering proofs or hoping they will jump to another topic after they have discussed themselves to death.

Probably the best enthusiast made helicopter mod for DCS so far. That flight model really shines, as well as the cockpit and the modelled systems. Very impressive! However, in VR (as so often with enthusiast created mods) the cockpit scale is off. Feels like being overall around 25% too big. The collective dimensions seem fine though, but the B8 grip is a monster with a diameter of 2 inch and seems double of the size of the real one. I will have to eat tons of fast-food to build up enough body volume for those 30 inch wide seats! On pancake everything looks fine - so the majority will not have any issues with cockpit scale I guess.

For some reason ED has an inhibition to touch the old Belsimtek helicopter moduls (geometry and texture wise). Several graphics/lightning issues are pending for years now. At some point I developed the delusional idea that ED has suffered from a data loss in the past and is not able to access their original 3dsmax data anymore and is therefore stuck with the old .edm files and is forced to solve all graphics issues as laborious workarounds in the core program.

It's basically the same issue as with the shiny Huey fuselage textures: Removing certain materials from the file cockpit_mi-8mt.edm.json partially solves the reflections. Example: Shiny floor can be solved by deleting the marked file entry: Shiny appearance of pedals and other parts cannot be solved by editing the file though.

Nice compilation of the F-18 mods from Chiller and josh-109 without losing the original F-18C. The F-18D doesn’t rest correctly on it’s wheels and on the super carrier the holdback bar will not be attached correctly. Catapult start is possible though a bit bumpy. As AI planes definitely an enrichment for mission building. The flyables with the known quirks and limitations.

D'accord! Personally I would love to have more transparency here from ED how they model structural failure and which specific factors they consider for the different planes. Especially how they take into account the changing weight of an aircraft or how they deal with asymmetrical loads or which kind of compromise was necessary for them in case of insufficient information about the aircraft. I remember that the F-4 had a limit of 7.33 G for a symmetrical load case with full internal fuel tanks which went up to around 8.5 G (I don’t remember the exact number) when half of the fuel was burned. A viable modelling of the F-4 with regards to structural limits without telling us how it is done, would probably create a lot of threads here claiming there is an erratic behaviour for the structural limit… …intransparency creates controversy.

Somehow I don’t understand this whole discussion. My very first job in my career as graduated engineer was the analysis of fatigue and service life of military jets (at that time Phantom, Alpha Jet, Tornado and MiG-29). Structural failures of a military jet due to a single over stressing event is a kind of non-issue. Snapping wings is a thing in the world of gliders or in general aviation or for the old warbirds. I’m not even aware of such a case for military jets but I don’t have a complete overview here. Structural failures of military jets are due to fatigue and not because of a single over stress event. In case of a massive over stress of a jet as a singular event I would expect intense plastic deformations in the regions of highest loads rather than an instant desintegration effect. Having said that it seems that those who criticise the DCS damage model of various aircrafts are somehow right. The question here is: Does it make any difference? The aircraft would no longer be able to fulfill its mission in either case. An aircraft bent like a banana or an aircraft which falls apart - as a pilot you are out if business in both cases. Since there is no fatigue and no advanced damage model in DCS (for example plastic deformations which result in severe changes of flight behaviour), why on earth would one demand realistic structural failures for a single over stress event? Apart from this, no real world fighter pilot can take advantage of the ‘absolute’ structural limit for a once in a lifetime event of his bird because the aircraft has already seen a lot of G loads during its service and is therefor pre-damaged anyway. The approach of DCS is (and should be) to limit and penalize absurd high G pulling manoeuvres as a single event. Ripping of wings might not be the most realistic effect in all cases - but it serves the purpose.