450Devil

While I understand that the Optical Sight was a fixed feature in the Mossie - at least in the versions equipped with guns/cannon, it would be good to be able to remove it similar to how we can remove the Color TV Sensor in the F14's HUD. Although this may impact immersion it would help by making the VSI etc easily visible to the pilot position.

I have searched the forum and been unable to find any mention of this issue. The issue is that the Directional Indicator moves when RPM is increased and decreased - as if the electrical system is supplying more or less power to the DI depending on engine RPM. This makes it difficult to maintain a flight path when the DI is effected by changes in engine RPM. Attached are five photos showing the DI a. Before Startup - Engine Off b. At Startup c. At 1000 RPM d. At 1500 RPM e. At 900 RPM This was on the South Atlantic map with the Mosquito parked on the Rio Grande apron. I tested the Spitfire, P51 and P47 but these aircraft's DI did not move with either increase or decrease in engine RPM.

Further to my earlier post - have now experienced the partial black screen when flying the A-4 over the Falklands at low level.

Setting up to sortie from Rio Gallegos airport using the Community A-4 and RAZBAM M-2000 and both aircraft show a black screen when I lower the canopy. Screenshots attached. By moving the pilot head position (cockpit camera) forwards the black section disappears. Moving head position backwards again shows the black section. Tested same aircraft at all the other South Atlantic airports and it is only Rio Gallegos where this defect occurs.

It seems the pre-sets are all placeholders at this time. For example, the ARC-164 pre-sets in game at different from the ARC-164 pre-sets in the ME and changing the pre-sets in the ME has no effect on the in-game pre-sets. There is also no ARC-220 HF radio listed in the ME even though the aircraft carries one with ten pre-set channels. Hopefully the ability to set pre-sets in the ME and to have such operate in the aircraft in-game will come along soon as this increases the immersion when flying in MP.

Having looked through all the current suggestions in this Wish List thread I note that a couple almost touch on this matter but do not go as far as I would wish. It would be helpful (and I suspect closer to real life) for an Apace pilot and Gunner to consider what are the likely targets and threats they will encounter on a sortie. Doing so they would probably agree a priority list that should be targeted as the sortie progresses. This could be simulated in SP by the pilot setting George some targeting parameters such as Threat or Target Type and Distance out from the aircraft. For example, priority targeting parameters could be Priority 1 SAM Priority 2 AAA Priority 3 Enemy MBT within 10 Kilometers (or perhaps from 5 to 10 Kilometers from the aircraft's current position). George could then take these parameters into account when directed by the Pilot to Slave the Sight. The great thing about George is that it allows a player to fight the Apache without a human CPG. The limitation with George is that the AI is currently very limited in its ability to substitute for a human player in the front seat. While I have no idea how a priority list could be programmed into the game; perhaps the front end implementation / setting could be through the kneeboard in a similar way that chaff / flare settings are managed for some of the other modules. Anyhow, Ed please keep up the good work.

Strange - but after posting the report above and going back into the MP game - all was OK.

Just tried to fly a MP mission on a mate's server. Trouble was the inside of the cockpit was as clear as it would be in daylight despite the mission being set at night. Meant it was impossible to use the IHADSS / FLIR as the reflected lighting inside the cockpit bled out the IHADSS image. Ran into a hill. Not sure what the problem is as earlier today a few of us flew a night mission on my MP server and all was well with the lighting. Screenshot of inside of cockpit attached. The flood lights were off. However there was a full moon (but the mission earlier today also had a full moon and the cockpit lighting in that mission was OK) Also, I noticed once I had the aircraft started and my main MFDs seemed OK that looking over my instrument panel to the CPG's MFDs that all his MFDs were dead.

Once again the Apache and the Syria map results in game freeze and CTD. Here is the log etc files if anyone is interested. dcs.log-20220507-051111.zip

I removed the UH-60s from the mission. I then removed all user mods from my DCS Openbeta and closed down the game and ran repair. I then booted up the game; went into the mission and still experienced a massive fps drop after about 6 or 7 minutes flying. Attached are the log and track files. Hope this helps Cheers dcs.log DCS-SimpleRadioStandalone.log DCS-SRS-GameGUI.log DCS-SRS-InGameRadio.log debrief.log LastMissionTrack.trk

Sorry about that. I have reproduced the issue this morning. Attached are the log and track files. If you are wondering why I seem to be regularly glancing up to the top left corner of the screen it is because I was looking at the FPS counter which doesn't seem to be captured by the track file. LastMissionTrack.trk dcs.log dcs.log.old DCS-SimpleRadioStandalone.log DCS-SRS-GameGUI.log DCS-SRS-InGameRadio.log debrief.log

As it was an offline mission there was no track file in C:\users\Saved Games\......... etc However I checked the hidden files in C:\users\.......\AppData\local\Temp\DCS.openbeta and found the attached track file. Its details suggest it is the right track - hope so as otherwise I will need to redo tomorrow. Interestingly, the file size shows 3,018 KB but it comes out at 2.95 MB when I uploaded it to this page. _LastMissionTrack.trk

Situation: Single player flying the Apache on the Syria map (in the vicinity of Raqqa). After about six minutes flying my frame rates decrease to a level that makes the game unplayable. Computer setup: 11 Gen Intel)R) Core(TM) i9-11900K @ 3.50GHz / 64.0 GB RAM / MSI RTX 3090 24G / 49 inch Samsung Neo G9 Odyssey QLED monitor / TM HOTAS and Joystick / Cougar MFDs / MS Sidewinder Steering wheel / Razer Ouroborus gaming mouse / Saitek Pro Rudder Pedals / Logitech G15 Keyboard / Logitech G35 Headset My keyboard has inbuilt CPU and RAM monitors - during the flight the CPU did not go above 10 percent or the RAM above 45 percent. Attached are my log files. Neither SRS or in-game radio were active - do not know why these files were generated by the game. I have not experienced this issue with any other module. Yesterday to test the issue I set up a simple ME mission using the Caucasus map. I experienced no problems even though each time I flew the Caucasus mission I increased the mission complexity by adding (1) AI units (2) Moving AI units (3) Trigger Zones (4) Shelling Zones (5) Smoke effects (6) George AI (7) George via Voice Attack (3) Discord I also tested a simple 20 minute flight in the Apache in all the other maps and experienced no issues. I did not increase the complexity in the other maps. Any suggestions for rectifying this matter will be greatly appreciated. dcs.log DCS-SimpleRadioStandalone.log DCS-SRS-GameGUI.log DCS-SRS-InGameRadio.log debrief.log

A friend of mine recently installed DCS Scratch Pad (https://github.com/rkusa/dcs-scratchpad) and he was telling me that this allowed him to capture coordinates directly from the F10 map that are then shown in the Scratch Pad. Not wishing to take anything away from the work done by the Scratch Pad developer, it would be a real plus if a similar facility could be built into the Notes page of the Viacom Kneeboard. Just a suggestion.

I see from the forum that this bug has been raised previously over several years but it remains unresolved so I do not feel that I am doing the wrong thing by highlighting it again. I bound the RWR Power button to a button on one of my MFDs and while the panel powers up when my MFD button is pressed and held, the panel turns off as soon as I release the MFD button. I note that this topis was closed off by NineLine last year but the problem remains and from what i read in an earlier post the fix appears fairly simple for the Devs to implement. please can someone look into providing a fix with the next DCS OpenBeta patch.

Carrier comms are currently limited to one frequency (albeit that the actual frequencies can be set in the ME). It would be useful and more realistic if carrier ATC had two available frequencies - one set in the VHF band and one set in the UHF band. This would both reflect the multiple frequencies available at airfields and allow more aircraft to communicate with carriers. For example, most mission makers using USN carriers leave the carrier ATC frequency at the default VHF frequency. This is fine for any F-14s or F-18s but denies A-4s the capacity to talk to the carrier ACT as the A-4 is limited to one UHF radio.

Love the preset video settings and really appreciate the ability to create and save custom settings. Only addition I would like is to be able to give the custom settings a unique name when saving the setting. For example, if I find a particular setting arrangement works well when playing MP then it would be helpful to be able to rename Custom1 to MP when I save that setting.

As the Mossies top two roles were high altitude and low altitude day / night penetration of enemy territory, an accurate altimeter was a requirement. The altimeter in this module is neither accurate nor consistent. To test this I suggest you set up a simple mission in the ME with a player Mossie @ 220 knots and ME standard altitude (6562 feet). On spawning in go to Active Pause and outside view and not the altitude. Then go back into the aircraft and adjust the altimeter to the real altitude. Then resume flight and descend the aircraft to 1000 feet on the altimeter. Go back to Active Pause and outside view and note the shown altitude which will be much less than 1000 feet. Not only does an inaccurate altimeter make it difficult to fly at a selected altitude but it also makes it very hard to low level bomb as there is a real danger of the aircraft sustaining blast damage due to the aircraft being lower than the indicated altitude on the altimeter.

The current operation of the undercarriage indication lights seems somewhat at odds with the Air Ministry's Mosquito Flight Operating Manual. The two red lights should extinguish once the undercarriage is up and locked. Except when the throttles are set at less than one quarter open. Also the undercarriage warning horn should only operate when the undercarriage is locked down AND the throttles are less than a quarter open. At the moment the warning horn operates at about boost 5 which is about a quarter open when RPM is set to 3000 as at 3000 RPM you can advance the throttles to about 20 lbs boost. However at lower RPM settings the amount of boost available reduces with lower RPM settings. For example, at 2850 RPM the boost available is only about 18 lbs. Therefore one quarter throttle at one quarter throttle the boost would be 4.5 lbs. Etc, etc for lower RPM settings. Unless the trigger for the undercarriage warning horn is built in to the throttle quadrant, then the crew would be constantly annoyed when operating at low RPMs such as when conserving fuel on a long distance flight.

By making the lua changes as advised by Scoobie above, I can now trim the Mosquito to fly level hands off. Down side is that I had to redo the lua changes after the latest update as it reset the files to the default. After several trials I have found -0.5 and 0.5 works best for me.

The easy way to check runway orientation is to use the distance / direction tool in the ME. Just run it along the edge of the runway and it will show the orientation.

Yesterday myself and three mates ran an Op Jericho mission using the Channel map on a private MP server. We were all flying Mossies and over the course of the mission some of us were shot down / crashed. To keep everyone in game as long as possible, whenever one player was taken out they then spawned in to a Navigator position in the remaining aircraft. Some anomalies in the displayed flight instruments then showed up between what the player flying the aircraft and the player occupying the Navigator position observed. For example, at one time I (as pilot) observed our altitude as 500 feet AGL while simultaneously my Navigator was see our altitude as 1500 feet AGL. Another example is that my fuel gauges showed three quarters full but my Navigator saw them as almost empty. Similar differences were observed in the other flight instruments. For information, two of us are in Australia and two were in Canada. The private server was in Canada. Seems that multi-crewing the Mossie causes some bugs to appear. That said, it is a great module - thank you.

RAF Manston's runway orientation is marked as 112/292. This is incorrect. The actual orientation on the map is 102/282 Also the runway markings on a number of RAF Biggin Hill's runways are also 10 degrees out.

As someone who is regularly shot down when flying in a Warbird, it seems unrealistic that the parachute immediately deploys when I bail out. Pity that automatic deployment of the parachute cannot be disabled. It would be more realistic for the pilot to have to deploy their parachute after free falling for some distance. The rate of decent in game in a parachute appears to be about 280 meters per minute which is reasonably accurate given a mass of 80 kilograms and a canopy area of about 80 square meters. The same pilot free falling will decent at about 1800 meters per minute as their canopy area is about a meter square. An in-game pilot bailing out at high altitude (say 8000 meters as happened on my last sortie) would expire due to oxygen starvation if their rate of decent was only 280 meters per minute. Just my view on a way to improve DCS Warbirds experience.

I have been trying to design a mission which simulates AI interceptors taking off with their air-to-air radars in silent mode. The intend is to simulate GCI control of the AI interceptors until they are within a set range of the intruder aircraft they are being directed to intercept. The current options (waypoint actions) for turning off and on the AI interceptors' radar are very clumsy and often do not work. It would be an improvement if there were simple actions - such as "Set radar to silent"; "Set radar to search mode" and "Set radar to attack mode" that could be selected for particular waypoints or set a actions that occur when the AI enter a trigger zone.