gulredrel

Valid point. Or maybe it's the autopilot from Airplane filled with Helium. (I know, just for fun, even this would add weight)

Okay, thanks. In flight it's working. Haven't found a similar figure in the Huey manual. So I guess it's just the way it is.

Hello, I've created a mission on cyprus and put the Mi-8 on Pinarbashi airfield. One unit is located at Lakatamia transmitting on 42 MHz FM. R-828 radio preset set accordingly I'm not able to receive the signal. A different unit transmitting on 32 MHz at Pinarbashi or a third on Nikosia Airport can be received with the R-828 radio and can also be used as radio navigation aid. All are sending with 100W (don't know, if this really makes a difference). Having the same setup but with an UH-1, I can receive the Lakatamia signal being on the ground at Pinarbashi. Is the range for the R-828 receiver limited compared to the FM radio in the UH-1? MIssion files can be found attached. Thanks Jens UH-1H_Pinarbashi_Cyprus.miz Mi-8_Pinarbashi_Cyprus.miz

If it's single player could you please try with zero wind speed settings? All of my flights with no wind were without damage during taxi. See also the other taxi explosion thread.

That would really be useful, yes. So no more guessing on user's end. Was lately gunning an IL-76 and needed to aim far in front of the radar dot.

Hello, noticed the following and was able to reproduce it. See tracks attached. DEFA Pods will fire while selecting them without pulling the trigger, when bomb fuze switch was set before. Steps to reproduce: - set keybinds for bomb fuze switch, pylon select, master arm - plane air start or ground start armed with DEFA gun pods, burst cutout set to on with 0.5s - master arm on via key press - bomb fuze switch nose/tail - select gun pod pylon -> selected gun pod will fire a burst without pulling the trigger Thanks Jens 20230105_03_MB-339_Defa_fire_with_pylon_select.trk 20230105_02_MB-339_Defa_fire_with_pylon_select.trk 20230105_01_MB-339_Defa_fire_with_pylon_select.trk

Updated AI models, they have been shown in some dev reports, as well as the new AI S3 Viking model.

Exactly my question.

Hello, I've assigned two keyboard buttons to the U+V pushbutton - PUSH and U pushbutton - PUSH commands to switch between V/UHF (green) and UHF (red )radio. Being in the cockpit. the behavior of the key command is not the same as clicking the corresponding knobs with the mouse. With a click, the knobs stay in pressed and illuminate green or red. Using the keyboard commands, the knobs only stay pushed down and illuminated as long as you keep the key pressed. Letting the key go and the knobs pop out and are no longer lit up. See also track file with my actions. Regards Jens 20230103_Mirage_F1_U_and_V_and_U_pushbutton.trk

What map were you flying at? Nevada or South Atlantic, maybe? Noticed the western coordinates not being displayed some while ago. At least it was only a display problem. You could use western coordinates as described here with previous patches. Currently the faulty RNAV is map independent:

Thanks for reporting. I was wondering last time flying a certain radial abd coming in different than in a different aircraft doing the same. It was a different map so declination was smaller value.

Have you been long enough below 250kts? Looks to me like alternator problems because of insufficient cooling. See manual for details or this thread

Just a heads up from my side. I've taxied and flown from different airfields. Always zero wind at ground level and did not had the behavior described above. Syria map Ramat David, with the elevation changes while crossing the runways and taxiway intersections. Wujah al Hajar with the sloped runway. Pinarbasi, Kings Field and Akrotiri on Cyprus. Kobuleti in Caucasus. Would like to check some crosswind flights but currently I'm afraid of encountering the g-spikes on the ground again.

Cyprus

I don't think that spark plug fouling, magneto problems or rpm governor faults are simulated or randomly configured. So doing no runup will not prevent you from flying. For being a training plane, it would be really nice to have some real world cylinder head and oil temp simulation. I can't imagine, that the plane going 64 % rpm with 230 km/h needs full open oil shutter to keep the oil temp within limit with OAT 20°C. I watched some cockpit videos where OAT definitely was not around freezing and oil temp was about 50°C when they did some aerobatics at 70 % or 82 % rpm.

I did the runup prior to take off. It is highly dependent on OAT. I also did a cold start and warmed up intil 40°C oil prior to runup check. Never tried hot ramp start. Don't know oil temp at hot start.

Hi @Flappie, oil temp stuck is fixed in OB, but I guess there need to be some tweaks to oil temp behavior. My mission was set to 19°C OAT at Beslan, see track file attached. On the ground with oil and cooling shutters open I could maintain temps. Took off with all wide open and than reduced RPM to 70% RPM so max. continuous, I think. Trying to shut the oil cooler I got immediate rise in oil temp. Given, that there are some liters within the oil system circulating through engine and oil cooler, I can't imagine, there is such a quick rise in temp directly when shutting the oil cooler. Even reducing to 64% RPM I had to have the oil cooler relatively wide open to get cooling at 240 km/h. Or is the cooling system so bad in warmer climate, that you need to have the shutters wide open? When time permits, I'll try with less OAT to see, If I can keep temps down in lower cruise power settings when oil cooler is closed. Edit: @Flappie just a thought, maybe you can talk to the devs. The manual states oil INLET temp (I guess measured before entering the engine?). In the other warbirds, it's not inlet temp, so the normal oil temps are significantly higher. Maybe it's just a wrong value on the gauge and that's why it is always so high? Regards Jens Yak-52_oil_temp.trk

Just to clearify, it's an air and oil cooled engine. So no water temp. Triple gauge top is oil temp, the single gauge is cylinder head temp.

Hello, with the last open beta the RNAV Navigation bearing indication is totally wrong. Was completely lost in Syria map yesterday with my mission editor flight plan. Tried alignment with typing in initial coordinates as well auto alignment which should use GPS. Present position shows strange values afterwards, but this should be a known issue. At this time at the beginning of November, Waypoint heading information was correct. It was only a problem with the presentation of present position on the CDU discplay. Now with current OB DCS/2.8.1.34667 WP navigation using CDU is completely usesless. The bearing indication is totally wrong. Distance looks okay. I created a simple test mission air start flight plan with known WP over TACANs in Caucasus. WP1 is over Kobuleti RNAV to WP1 shows bearing of 352, switching NAV source to Kobuleti TACAN 67X shows bearing 110, which is correct with the map WP2 is over Batumi Same here, RNAV bearing is 047 but TACAN 16X is located bearing 166. Distances are the same for TACAN and RNAV waypoints, so whatever is wrong is bearing indication and display on the CDU. I'm a bit concerned here. Normally I'm waiting for stable release version, but was very interested in this aircraft so I bought it on day one. Especially te CDU integration with own data card file support is a nice addition. I've now discovered quite a few bugs. Dev reports were great so I was hoping to get enjoyable hours in this bird but instead invested quite a few hours in finding quirks or trying to find if it was my fault before writing reports. I know it's open beta, but it's a bit... I would have rather enjoyed just flying in my spare time. Nevertheless, looking forward when things get polished. Thanks Jens MB-339_20221223_RNAV_wrong_direction.trk

I have flown several sorties today, same mission as above, but with zero winds. There was no problem. @Bigskill Do you know, what the wind conditions where during your MP flights?

Hello, is it me or the lighting conditions? With the latest OB 2.8.1.34437, the ejection seat safety pin looks really dark. Front seat rear seat It was the factory paint scheme in Caucasus map. Date and time in screenshot status bar, mission attached. track is quite big, but unnecessary for verification I think. Thanks Jens MB-339_Kobuleti_target_practice_no_wind.miz

Hello again, today, 3 attempts, same mission. On all three attempts I encountered the g-spikes while taxiing in the first part of the taxiway but at different places. Tracks 01 without blacking out, track 02 with shortly blacking out. In track 03 the blackout lasted very long and I switched to external view. The front of the aircraft was jittering up and down like crazy as well as the AoA value below -100 and well above +100. I noticed the massive AoA values in the status bar. Just an assumption. Could the problem be related to wind conditions, especially wind from the rear that in some circumstances this has a weird effect on taxi behavior?! Wind related front gear movements where a problem in F1 early beta too, I believe. In yesterday's damage screenshot, the AoA value is even higher. Thanks Jens MB-339_20221219_03_g_spike_taxi.trk MB-339_20221219_02_g_spike_taxi.trk MB-339_20221219_01_g_spike_taxi.trk

That's exactly the problem. It's the same mission. One time the problem occured, the second time there was no problem. Couldn't find a way to reproduce it permanently. The mission attached was used for the tracks above. I always start at ramp position 19(?, see mission for details). Startup, taxi to RW 07. In the first track above, I got the g-spike short after I started taxiing being on the main taxiway. No problems on the rest of the taxiway. After landing on RW 07 I taxied back to the same ramp position via the way behind the ground equipment. Turning to the parking spot, as can be seen in the screenshot above, I experienced the massive g-spike and damage to the aircraft. On the second attempt. nothing happened, using the identical taxi path. MB-339_Kobuleti_target_practice.miz