Sharkku

Sure is... Hope they fix it soon.

Yes, Ctrl-Shift-C worked now with your mod installed! Awesome, thanks! You are the man!

Hi! I have an unwanted window in my view that I can't get rid of. I suspect it is the cargo hook view. According to google, it should be turned off with Ctrl-Shift-C, but that doesn't work. It's very annoying and immersion-breaking, since I fly using VR, Rift. DCS ver 2.5.3.23225. Does anyone know how to get rid of it? Am I the only one getting it? It looks like this (circled in red):

The camera window is back. How can I turn it off?? Shift-Ctrl-C doesn't work. Incredibly annoying.

Fixed in latest update!

Seems fixed in latest update!

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.