Goggles

It is not fixed. Loaded the most recent version 2.5.6 At night, with 50 meters visibility, while on the runway, you can see the runway lights all the way to the far end, and taxiway lights beyond 50 meters. I suspect that the coder does not understand the concept of visibility. It is not some kind of texture function that is tweaked on video graphics, but a limit on how far you can see. Foggy in a video game is not fog in a flight simulator. If the visibility is 50 meters, then you should not see anything beyond 50 meters, even the lights.... just blackness at night or gray in daytime beyond that setting. So any object beyond the set visibility limit should be inhibited and not be rendered. Here is an example of 200 meters visibility. You do not see anything beyond 200 meters, and certainly not the runway lights at the far end. https://en.wikipedia.org/wiki/Runway_visual_range#/media/File:Lisbon's_Runway_21.jpg

Fog is only wrong concerning the runway lights. Not a problem otherwise.

Make sure you move the 'Thickness' slider just below the fog slider all the way to the right. Unless they just changed it, all my parameters are in meters. So if you actually entered 800 meters, you'll get 2400 feet visibility.

I found a way to get a ceiling below 300m. Start off at one of the coastal airports at sea level (Batumi, Sochi etc), and plan a flight to an airport with higher elevation. IIRC, Tbilisi elevation is 1500 feet ASL. So you want a 200 foot ceiling there, set the clouds at your departure point at 1700 feet, converted =520 meters. You will have a ceiling of 520 meters at the point of departure, and when you get to minimums at destination Tbilisi, you'll pop out of cloud at 200 feet AGL. The C101CC seems to be the only aircraft with an ILS, ADF and radar altimeter together. Anybody use any other A/c with ILS? Would be nice with an aircraft with a bit more pep.

There was a big MiG-21 upgrade program some 10-20 years ago, one programme by Israel Aircraft Industries. Although the airframe dates back to the '60's, it still has formidable Mach 2.2 performace. "With their (India) upgraded Phazotron Kopyo radar—which is capable of simultaneously tracking eight targets—the Indian MiG-21s are able to attack targets beyond visual range with Russian-made Vympel R-77 radar-guided missiles."

The aileron and pitch trims are swapped. When you try to trim for pitch, it trims the roll, and vice versa. Just swap them in adjust controls. The chinese hat trim switch is also incorrect. As it moves laterally, the plane trims in pitch. I've seen this with other planes, so I think it's DCS's sim engine.

Yes, I hope they fix the weather. Presently, clouds cannot be lower than 300 meters. Cloud ceilings should be able to be set a lot lower than that, down to the surface (it becomes fog then). Wars are not only fought in nice weather. Those air forces that can fight in all weather conditions win. Being able to take off and land in shitty weather is part of that. Here's Jimmy Stewart landing a B-47 in very crappy weather, when they were doing GCA's then. Pick it up at 5:00 Also, on-board ILS guidance has been flawed ever since Flanker 2. Actually, the behaviour of the flight director and CDI in ILS mode were quite accurately modeled in Flanker (1). Then they decided to rewrite the whole code.

Here are 4 tracks, 2 day and 2 night; 2 clear and 2 with 50 meters visibility. day_nofog.trk: aircraft at take-off position day, unlimited visibility runway lights visible to the end of runway normal condition day_50mfog.trk aircraft at take-off position day, 50 meters visibility, fog thickness to maximum runway lights visible to the end of runway Runway lights should not be visible past 50 meters. night_nofog.trk aircraft at take-off position night, unlimited visibility Runway lights visible to the end of runway normal condition night_50mfog.trk aircraft at take-off position night, 50 meters visibility, fog thickness to maximum runway lights visible to the end of runway Runway lights should not be visible past 50 meters. (DCS Version 1.5 works correctly.) day_50mfog.trk day_nofog.trk night_50mfog.trk night_nofog.trk

Visibility in fog Nothing new on this matter. Setting fog to 20 meters, you can see the runway lights all the way to the end of the runway. This is incorrect. Lowering visibility (using the fog selection in the weather menu) means you should not be able to see anything beyond that value: no runway lights, no mountains, no buildings, no outlines. DCS 1.5.8 still more realistic than 2.5 wrt visibility. Don't know why they changed it, and why they don't fix such a fundamental feature.

The Mi-8 Trim button doesn't work in DCS 1.5 version anymore. I use the Microsoft Sidewinder Force Feedback stick. You press the button and you hear the click, but it doesn't remove the force feedback; the force on the stick remains, and the centering remains unchanged. It works ok in DCS 2.5. Push the button and force on the stick is removed; let go and the artificial feel is re-centred where the stick is now positioned. Why do I still use 1.5? Visibility modelling sucks in version 2.5. I don't know why they had to re-invent the wheel in 2.5. I like scud running at low level in low visibility. Impossible to do with version 2.5, as you still see a horizon and objects appear at a distance greater than what the visibility is set at. You can't actually program a cloud layer lower than 1000 feet (which is a shame), but DCS 1.5 fog option models scattered low stratus clouds, which kind of gives it a realistic look, having been there in real life. BTW, the force trim works ok on the UH-1H, in both DCS versions 1.5 and 2.5. It replicates what the real Bell 205 felt like, a long time ago.

Weather and visibility was much more realistic in DCS 1.5. The fog is not right in 2.5. With maximum fog, minimum visibility set, you can see the runway lights right to the end and surrounding structures well beyond the set visibility distance. If this were true in real life, there would be no need for Instrument Landing Systems. If the visibility, whether in fog or haze or dust, is set at a given distance, say 1200 feet, then you should not be able to see anything beyond that distance... anything at all, not even runway lights. In 2.5, you can only set reduced visibility if you tick the fog selection. It should be possible to set the visibility above the fog layer. The weather in real life is never always severe clear.

The basic fog/visibility modeling is flawed: With the fog visibility set to near zero, you still see the runway lights all the way to the end of the runway, and you can see the buildings adjacent. In reality, if the visibility is 150 feet, then all you should be able to see is up to 150 feet around you. So that would be the runway itself, and any runway light or object within that distance. The rest of the image should be gray, and at night black. Increasing the brightness of runway lights increases their range in fog, but very marginally. They should be modeling fog like any other cloud: That's because fog is a cloud that's reached the ground. It is also not possible to have low ceilings. It should be possible to have the cloud base as low as one wants, and not at 1000 feet. In the real world, weather is an important factor in combat flight operations. The weather isn't always clear, and the side that can operate in periods of low visibility without crashing has a definite advantage.

Flying over a fog bank, it will appear as a white blanket, if the moon is out. Otherwise, you will see nothing but black below.

IF you can see the ground 50 meters ahead, you will not see the runway lights further than 50 meters, except perhaps for the glow of the next lights, depending on the strength of the lights. A visibility of 50 meters is just that: 50 meters. IF you want to take-off in low visibility, and the visibility is reported to be 150 meters, then you should be able to see the runway lights at 150 meters but not more. In 2.5 with the visibility set at 20 meters, you can see the lights all the way to the very end of the runway, or 3000 meters, which is wrong. In fog with the visibility set at 20 meters, you should also not be able to see any surrounding buildings or terrrain/hills etc. and should not be able to see any other clouds. That's because, you are, in fact, in a cloud, as fog is a cloud that is at ground level, Reduced visibility is screwed up in 2.5: it is amateurish. It is a paradox that the aircraft modelling is spectacularly accurate, yet somehow the weather modelling is arcade like.

In version 2.5, if I set low visibility, such as 20 meters, I can still see the runway lights all the way down the runway, and the surrounding terrain. Thickness is 300 meters. Version 1.5 seems accurate: when you set 20 meters, you see noting. Just grey around you. When you set 300 meters visibility, you see 300 meters down the runway and no surrounding terrain. I think I'll stick to version 1.5 until they correct the problem. That's the more realistic version. Also, none of the airports have approach lights. It would be nice to have those for conducting low visibility approaches. War doesn't always happen in nice weather.

Fair enough, but is what you're reporting as a bug, a bug? I'm saying that your's is a valid observation, but for different causes. The flight model lacks many attributes. How to convince the developers to implement changes without understanding why or where you're coming from?

Applying rudder only on an airplane in forward flight induces a skid, resulting in the upper wing having a greater angle of attack than the inside wing, resulting in a roll. The same would happen with a helicopter in cruise flight. But we're talking about a helicopter in stationary flight, not forward flight. The comparison cannot apply because airplanes are not capable of stationary flight (unless it's its last flight). My quote: "But I would not expect a change in attitude (roll) unless the application of pedal is sudden and violent." Is this in forward flight or stationary flight? What is the reason for this? Any relation to it having a fully rigid rotor system? I'm not denying that cross-coupling exists. Only that the effect of applying moderate pedal is very minimal (not worth the effort of simulating) on roll when in a hover. That being said, applying pedal in a hover changes the sideways force vector on the helicopter, resulting in sideways drift. Correcting that drift requires that the rotor disk be tilted by application of lateral cyclic, resulting is a slight roll. But the application of pedal in this case does not cause roll per se: only the necessary pilot reaction in order to prevent sideways drift. Any instructor would call the session quits over something like that. The dynamics of helicopter flight are complex, with various forces interacting. These vectors have to be broken down into their various components in order to help the programmers with a high fidelity simulation. That's my goal here.

I don't think that the attitude itself would change with application of pedal. What would happen with a change in pedal is a change in the sideways force vector on the helicopter, and that would cause the helicopter to start drifting sideways. Of course, to stop the drift, it would be necessary to tilt the rotor disk in the opposite direction to compensate, if one would want to maintain position in hover and not start drifting, and that would require a small amout of sideways cyclic. So the solution might be to apply an algorithm that applies a lateral force vector on the rotor system, as a function of the amount of fenestron thrust, as determined by pedal position. It is then up to the pilot to apply enough cyclic in order to counteract this drift. Then there is the case that the sideways force vector of the fenestron is lower in height than the counteracting vector of the rotor. But I would not expect a change in attitude (roll) unless the application of pedal is sudden and violent. This would be different to a sudden sideways wind gust that pushes against the airframe and makes it swing like a pendulum.

Please elaborate what should happen with the cyclic when, in a stable hover without wind, a pedal turn is done, and why? What about when turning into or out of a crosswind?

You adjust the throttle in the Huey in case the governor fails and you need to switch it to emergency. Then it flies like a helicopter with no governor, like many piston helicopters. But it is very challenging and a run-on landing is suggested. Otherwise, the twist grip throttle on the collective is rotated full open, and the governor keeps the RPM's at the proper rate. Same with the MI-8. But the issue has nothing to do with the throttle or governor.

"performing the maneuver should cause a rapid increase in headspeed and a drop in engine rpm as the governor tries to compensate. At the moment the rpm needles don't even flinch. " You would split the needles, but you would not see the engine RPM drop in this situation, because the governor keeps the engine RPM steady (the engine is single spool: the turbine is on the same shaft as the compressor; it does not have a free power turbine). Only the rotor RPM would increase. The freewheeling unit uncouples the rotor from the engine drive when torque goes negative. That also permits autorotation.

I was doing some autorotations: With increasing airspeed (after initial pitch down), the rotor RPM is supposed to increase. In the model, it decreases to the point of unflyability. The converse is also the issue: When slowing down, the rotor RPM increases when it should decrease. Rotor RPM should also be affected by G Loading: pulling G's increases the weight on the rotor, thereby increasing RPM. In an autorotation at constant airspeed (120 km/hr), Rotor RPM should increase in a turn as G loads increase. In the model, RPM stays the same. Indeed, in a real helicopter, you may have to pull on collective a little bit in order to prevent over speeding the rotor RPM in a turn. G loading is not modeled in the simulation. The only reason the model increases the rotor RPM in the flare in the autorotation is because the model incorrectly increases rotor RPM because of speed decrease. RPM should increase more dramatically because of G loading in the flare, and should counteract the natural slowing of the rotor because of the decreasing airspeed. That's the basic problem with not getting an increase in rotor RPM during a flare in the model. Rotor dynamics are not correct.

Maybe grunting instead? Could have a female mode too maybe for our lady fliers?

At what point does the heavy breathing start? How many G's?

Nobody here is demanding instant action. But it would be nice to have some issues acknowledged and feedback given from the developers. Hopefully, rational discussion is encouraged and reported to the developers, and that might help them understand, troubleshoot and fix issues, especially complex flight dynamics that do not seem apparent to the uninitiated.