Spacehamster

You have a really loose grip on physics. If I release at 900 the bombs have only a tiny amount of relative speed compared to the plane, means any bomb touching the plane (which again would not have happened for the aerodynamically impossible zero G spike that happened after release) would only very gently touch it, like a feather. And on top of that, the wings are made to withstand several G so they do not get torn off in high G maneuvers. And as I said several times, the moment of release has 0.1 G, then shortly after that a -0.9G spike happens which is due to lazy script coding on the developer's side that does not account for the gravitational situation at this point. If i pull positive G and release 3 tons of bombs, which accounts for roughly 25% of the plane's current mass, then it would reinforce the positive G, and not cause a negative G spike, because my positive G pulling now got a lot easier because of 3 tons of mass having detached from the plane.

Yes. Does it work for you?

The radar won't switch on for me. I have: -waited 5 minutes in stand-by mode. -performed self-test in standby mode, which completed. Something bugged or am I overlooking something?

Selective perception. Bombs released at unconvenient dive angles probably slid along the pylons a million times. Instead of damaging the plane. Of course that does not get to youtube. And it does not explain the magic floating bombs passing through the plane. If there was working collision, the bomb would very likely not have exploded, and sure as hell not 10m in front of the cockpit. And if I pull the tiniest bit of POSITIVE G then the vector of the bombs will be away from the plane, because 0.1 + means the plane's trajectory is changing and pointing away from the bomb vector after release, because the only thing acting on the bombs are inertia and gravity and air resistance. Collision bugs causing freaky behaviour like that is not pilot's error. So blaming that on pilot's error is very irritating to players who take time to provide evidence of these bugs.

Having the option to change the instrument-displayed units between imperial and metric is lame. Unless the real aircraft has that option it should not be a possibilty. It's as lame as being able to make eastern and western weapons interchangable.

It's great that someone finally acknowledges what the actual problem is. The bombs fail to collide with the pylon when it matters, then proceed to magically pass through the plane and then 10m away from it magically have their fuzes go off. And then that is presented as a realistic consequence of "pilot's error" for a very steep diving angle. Even if I actually had pulled negative G (which I did not), then the bombs would have pressed against the pylons or bump against them gently and that would send them off in a vector that would make it impossible for them to collide with the plane.

You cherrypicked a moment after or before release. Because I was very careful to not pull negative G on release. And in the exact release moment (when I pressed) it was +0.1.

Just going to re-quote myself. Because you people show a lack of understanding of physics and vector math and reading comprehension. They could not have continued on a magic path of 53 because then they would have to pass through my plane, which is physically impossible. But they did that. Stop blaming the physics bugging out two-fold on players. Attitudes like this delay fixes for bugs for months becuase every bug report has to get through this wall of "pilot's error", even in the face of hard proof which I presented in the video and replay and in the quote at the beginning of this post.

That slope was done declining as you can clearly see my G was 0.1 + on release. Can you not ignore the mounting evidence? Also the pich instrument does in fact lie. It might have been misaligned on take-off. But the external camera G display does not lie.

It is not. I waited until the negative G passed, then pressed the release, and upon release, there was a sudden negative G generated by the bomb release. Also let's not forget the bombs failing to follow their own inertia and gravity and floating comfortably through the plane before exploding. That sudden negative G spike is not pilot's error. And even if it were, the bombs would press against the mounts before eventually sliding off, and not float through the plane. That is a bug. I was at +0.1 G, but after the release the game decided to create a negative G spike of 0.9. https://youtu.be/daIpfLo99dY As you can see the negative G only happened after bomb release and is not pilot induced. Which was the first bug, because a sudden loss of big heavy objects below my wing should have induced a positive G because it would point the plane's nose up. Not the opposite direction. And the second problem is the bombs getting magical instant drag + them passing through the plane before exploding 10m away from the plane without even touching it

Also I will upload a video that will show it is a bug, and that at the moment of release and afterwards the G was exactly 0.0 and above, not negative -0.3

Watch the replay and observe the bombs turning into weightless cardboard boxes that float through the plane before detonating. Bug.

Look at the attached image. It is several screenshots in sequence. The plane explodes shortly after the last. All of this happens in less than two seconds. The bombs instantly float through the plane and explode after passing through it. Physics says the bombs have the same acceleration vector as the plane on release, and they get pulled away from the planes vector a bit because of gravity. It is a bug. And not some aerodynamic unfortunate G-force.

Thanks that worked.

I went for a divebombing attack at 40 degrees and after release the bombs passed through my plane and exploded. 1. They should have the same speed as my plane on release. And they should follow a trajectory that would make a collision impossible. 2. On the replay you can see the bombs slowing down a lot after release and hovering through my plane before exploding. The plane was an F5 divebombing_crash.trk

I think the trimmer is broken. I have set the trimmer mode to "Joystick without Springs and FFB". The helicopter starts pre-trimmed about 20% down and right. And it will not respond to trimming commands. It does make the trimming click sound but it will not set the trim to the new position. Also trim-reset won't work. And yes, I know I have to let go of the stick to allow the trimmer to set itself to the new position because I am using a stick without FFB. All of this worked until recently. Using the "default" option in trimmer mode does accept trim commands but with the problem of the stick getting offset (because that is the mode for ffb sticks) I have posted the exact same post in the Mi8 bug section because it appears to be the same bug causing it for the Huey.

I have noticed that most onboard systems on the Mi8 only work once the engines are running. Is there a way to get these things running before the engines are on? By using external power? And if so, what switches would I have to use for that?

No, I double checked. The first 2 options will cause the trim to creep. The 3rd (no FFB) will simply not trim. It makes the clicking sound, but the new trim position is never acknowledged. This is a bug.

Buy an Intel CPU. I replaced my system, similar AMD like you have, with an i7 + 16gb ram and a 1060 card. It went from 20fps to 70-150fps, under the most crowded conditions in multiplayer (20 players on the same airfield).

The frequency band display won't rotate to indicate the selected band after using the frequency band selector switch. DCS 1.5 current version

I assumed it is a bug because the RI65 warning system kept warning of it.

I was able to start the helicopter after forgetting switching on the fuel pumps. It was fully running and only the female announcer voice told me that the pumps were off.

I think the trimmer is broken. I think the trimmer is broken. I have set the trimmer mode to "Joystick without Springs and FFB". The helicopter starts pre-trimmed about 20% down and right. And it will not respond to trimming commands. It does make the trimming click sound but it will not set the trim to the new position. Also trim-reset won't work. And yes, I know I have to let go of the stick to allow the trimmer to set itself to the new position because I am using a stick without FFB. All of this worked until recently. Using the "default" option in trimmer mode does accept trim commands but with the problem of the stick getting offset (because that is the mode for ffb sticks)

I think the trimmer is broken. I think the trimmer is broken. I have set the trimmer mode to "Joystick without Springs and FFB". The helicopter starts pre-trimmed about 20% down and right. And it will not respond to trimming commands. It does make the trimming click sound but it will not set the trim to the new position. Also trim-reset won't work. And yes, I know I have to let go of the stick to allow the trimmer to set itself to the new position because I am using a stick without FFB. All of this worked until recently. Using the "default" option in trimmer mode does accept trim commands but with the problem of the stick getting offset (because that is the mode for ffb sticks)

I always want to fly it with the most realistic options. So if the real helicopter has no rudder trim I keep that off