Sharkku

The sling load camera window, or cargo hook view, or whatever it is called, appears even if it shouldn't. I have no cargo hooked or present. Flying in VR on latest 2.5 beta, free flight Persian Gulf map, "instant action"-flight.

Yeah, I think it's the cargo hook view as well. If anyone knows what to do to disable it, please chime in!

I haven't been flying for a few updates, and now when I jumped into the Huey I have an unwanted top/down view in a window in the top/right corner of my eye. I'm using VR. How can I get rid of this annoying window? Anyone know?

This is in the wrong section, not a bug. Belongs in Peter Pilots. Another hint: You can also try flying very low while decelerating. This gives you the benefit of ground effect which eases the loss of translational lift. It's also good practice to decelerate at a constant altitude.

@MemphisBelle: You can follow the Hinds from a higher altitude. The max distance requirement is only calculated laterally. Makes flying over that hill much easier. Still not easy, but easier.

How is this related to the Huey?

If you exceed the maximum values for EGT, the engine is damaged. Damage is accrued, and eventually it will catch fire and fail. I'm not familiar with game mode, as I always fly in sim mode. I imagine that pulling too much on the collective would put excessive strain on the engine in game mode as well. By the way, I see no attachments to your post.

I suggest the logic for stick and cyclic input should work like this: A value for the amount of movement should be determined for all axis combined, stick and collective. Pilot and co-pilot each have their own value. If the value is above a low threshold, then that person is considered active. If both are active, then the inputs should be averaged. If one person is moving his controls less, the average should shift weight towards the one moving more. If one stops movement below the threshold, the control should go to the other, smoothed over 1-2 seconds or less. When i talk about amount of movement, I don't mean amount of static deflection, but actual movement, the derivative. With this logic, both pilots can fight each other, the result being no input, or each can take over when the other stops moving the stick. Pilots will have to communicate who has the control, and transitions should be smooth. The threshold serves to eliminate axis jitter causing an inactive stick to be determined active. Thoughts?

That would depend on the impact angle and the properties of the ground being hit. At a shallow enough angle, a high percentage would bounce. At least my bullets did whe I was shooting tracers with a machine gun on the range, back in my navy days.

Oh, I'm sorry if I stepped on a sore toe. My apologies. As for the "show us how quickly I can do it myself", that's just asinine. I don't have insight or knowledge about the specific code of DCS. I don't work for DCS, and I'm not a programmer. Of course I couldn't do it quicker than someone working for ED. I do, however, possess a sense of logic and reasoning, and I have a basic understanding of programming. But if you are not saying that it's not doable, then the statement above about lame excuses does not apply to you, logically. Then again, if you are saying that you won't do it because it's too hard, that's a lame excuse. I have complete sympathy for it being hard and taking time. And I am grateful for the effort being put into the module.

Of course it's not possible to sync two different hardware switches in two different real world locations with each other. You can work around it though, so that your hardware switch will not affect the virtual switch until you have put it in the same position as the virtual switch. It's going to be a little more inconvenient, yes, but there is really no way around it, short of both pilots having controllers with server motors that move the switches of the other player's controller. An alternative is to only interact with the virtual cockpit with the mouse or a hand controller in VR. Then it just becomes a question of whose hand will take precedence if both players try to manipulate the same switch at once. It's definitely doable, to make a cockpit with shared controls. Anyone saying otherwise is just making up lame excuses because it's harder to do than two separate cockpits or set of controls.

Nice video! Is this in stock missions? Never saw it before.

Looks like it! I didn't know this either! But the wipers seem to have no effect on it? That just looks strange...

Travel time: Preferably not too long. 5-10 minutes maybe, depending on how much there is to do underway. Mission type: I like search and destroy. But the most fun missions I have flown have been combinations of different tasks. Difficulty: I like a challenge! Nothing is more satisfying than accomplishing something difficult, something you know not just anybody can do. Then again, as you say, I don't like an unfair challenge. Careful planning and practice and skill should pay off. Map: don't own Persian gulf. Will buy at a decent sale price.

Well, I have a hard time believing that this behaviour was chosen as a shortcut to save developing time. What parameter is the "autopilot" using for keeping the heading? And why is it slowly turning? Is it using the course gyro, and following the gyro drift? Understandable then, but then it's working as a real autopilot would, and not a simplified aid when doing other tasks, and your argument falls. Why not take the helicopters absolute heading in the game world as reference then? I'm sure that number would be extractable from the inner workings of the sim, and would result in a virtual co-pilot that can actually fly, keeping the nose pointed in one direction. And it would actually be more realistic.

This is a little disappointing, to be honest. Not very realistic to not be able to manipulate certain switches, just because they are assigned to your co-pilot for instance. I understand it's easier to program this way, but it shouldn't be impossible to let both pilots be able to manipulate all switches. Sure, there will be conflicts, and the position of your switches on your hotas will not match the in-game switch position, but so what. Well, maybe it's because they are trying to solve these issues it's taking so long.

@Holton181 Why are you arguing in defense of this behaviour? It's a completely retarded behaviour, and I'm sure not intended when developed. Asking for the autopilot to work correctly is not a "feature request". That's just silly. @Chic No, it's not due to modeled drift. That would only cause the longitudinal axis of the aircraft to not coincide with the heading. What we are talking about is a slow turn, the nose turning to point another way.

Yeah, I'm sure he's not activating the orbit mode. I know what he's talking about, I have this issue as well. It's only really apparent when using high levels of time compression, since it's a very very slow tendency to turn. But I agree with him, it's rather annoying, since the only time I really ever use the "co-pilot" is when I want to fly a long boring straight leg and speed up the time. And then it's veering off course.

@Sukebe: To be fair, Joshticoun0 said "the majority is done". Not all of it. And check your use of it's instead of its. "It's" is a contraction of "it is", and "its" is a pronoun signifying possession, which is what you meant to say here.

Ah, gotcha.

@PeaceSells: Nope, the forward slant would not be able to compensate for the pitch-up tendency at higher forward speeds by itself. It's there for the reason Chic mentions, to keep the ride more comfortable for the pilot and passengers. In normal cruise you need a forwards propelling force, that in a helicopter comes from angling the thrust vector of the main rotor forwards. Compensating for the pitch-up tendency is accomplished by cyclic trim and tail elevator angle.

Those of you explaining this with the rotor disc being slanted forward, you have not thought it through completely. It is true that the slanted disc requires you to apply aft stick when taking off, but that's just for the initial small pitch up required until the rotor disc is horizontal. After that, when you are in the air in a stable hover, what's important is the balance of forces, not the angle between the disc and some arbitrary "level" plane of the helicopter body. What matters then is the horizontal distance between the force vector of the rotor and the center of gravity of the heli, as well as trim and mechanical properties of the cyclic system. That's what's really causing the need for aft cyclic in a stable hover.

I think you mean site=sight, and radical=reticle?

Just curious: What do you mean by ideal position? Do you mean idle position? And what is nitrogen free flight? And you can very rarely use full collective without overstressing the engine, causing an overtemp and subsequent engine fire.

I have a TM Warthog HOTAS myself. If you lift the throttle handle in the idle position, you can pull it even lower, past a physical detent. This sends a "button press" action to the computer. Should be possible to bind that to page up/page down?