Yeti42

There going to ask you to upload a track file and possibly logs, just saying

I Had this problem. Windows is not correctly saving the display settings and monitor positions. In my case the MFD's were all landscape instead of portrait. I fixed it by searching for the monitor configurations in the registry and removing all the incorrect ones. You can also use a free screen/monitor config app, sorry forgot what it's called, I'm away from my gaming PC.

My first thought on hearing this was "Oh dear" ED has been saying for years that they could not create modules for newer aircraft as they system information was still classified. This apparently, is now not an issue. What I suspect we will end up with is an approximation of an F35 based on limited public domain information and anecdotal evidence, it will be no more than a community mod. The reason I play DCS is for realism in the knowledge that that aircraft have been modeled in a highly accurate way, once you start fudging modules together based on projected increased sales, you are on a rocky road to something akin to War Thunder, which don't get me wrong, has it's place and is probably fun to play, but not a flight simulator modeled to the level we have become accustomed to in DCS.

Would be good to know what the feature complete target actually is... I can only see the early access/initial release feature list.

Reset the whole thing and restarted, works now, no idea what the route cause was but hey, if it's not broke don't fix it

Hi Guys, I've just taken delivery of a VRSimSolutions V3 MIP F18 Add-On compatible with top gun package panel. I've followed the instruction for the DCS BIOS install and setup the panel but still can't seem to communicate with DCS. The multiple COM ports cmd has been setup, but when I execute it I see no activity or communication with the panels or DCS, I've even backed up the export lua file and am just using the one line from the DCS BIOS setup instructions, nothing works, any ideas? BTW the panels are showing up in DCS controllers and switches and buttons are mappable but obviously none of the warning lights etc can be configured this way, DCS BIOS is needed for that... I don't want to delete the whole setup and upload my own sketch (Arduino Leonardo Boards) as the panel is meant to come pre-programmed with everything working...

There are a few posts about creating SPI's and markpoints with the pod and the accuracy of the points when used for GPS guided weapons. I'm aware of the limitations and the principle of INS stored points and how they are affected by slant, effectively creating a point past the target if the slant from the Aircraft to the Target is large. Back in the day when the A10C came out, it was standard practice to manually lase when creating a markpoint so the point was more accurate and was actually on the target due to laser ranging, this generally worked if you were within 20 miles and within laser range. I'm wondering if the principle still applies to the F18 Lightning II targeting pod? I can see no mention of lasing to increase accuracy when points are created in any guide or the manual... Is this supposed to happen automatically? Is it the same code as the A10C? Any info on how this is actually implemented and how it works in the real aircraft would be appreciated.

Are there any plans to implement realistic effects for a cartridge start? This video of a real life start, compared to the start we see in DCS is a lot more dramatic! we like drama

Yep, that has happened, and heads rolled, doesn't mean it's right or that it shouldn't of happened and was avoidable. Tenure in a job doesn't necessarily mean you're good at it....

I disagree with you disagreeing. I'm an ex aircraft engineer, a pilot and an ex programmer, I've been working in the software industry for over 25 years at all levels. It's very rare any company I've worked for has had to delay a release on THE DAY OF release. The only way this happens is if you don't allow enough time for testing and final build checks, assuming you won't find any problems and not having any contingency time to fix them. This is a simple project management failure, for any serious software vendor this would be a PR disaster. If it was two weeks ago and they found a problem with the RC build that was very difficult to fix or had a huge risk then it's kind of excusable to delay a release, but not one day before.

The recompilation errors are normal if your shaders directory has been cleaned out, as is the "situation should not occur" error, a lot of people clean this directory out when applying a new version. I don't run on steam, which could actually be your problem... It could also be this:

Yes, I can't get it to work ether

I honestly think there is no harm in making an easy option for inflight refueling, as long as mission editors are able to enforce the option not to on servers. I doubt any major servers would allow it anyway. I struggled with it to start with and eventually confronted my daemons, it took about 2 weeks and 5 hours practice to get there, not unreasonable I thought. For me, making it easy rather defeats the point, but I can understand people not wanting to deal with it on a mission.

Just because the lines are commented out doesn't mean someone is working on it... what it means is someone realized it was incomplete "at some time" and wanted to put a placeholder in. Those comments could have been there for a while... we really have no idea if it's being worked on just saying.

RAG was never intended for non emergency landings. For off field landings on roads etc. it was also deemed impractical as this increased the equipment needed and the footprint. I worked on Jaguar GR1's and Tornado's during the cold war and was involved in various trials involving off field distributed operations, none of the off field sites were equipped with arrester gear, this also goes for any other aircraft I was aware of. It would be great to have this feature for runways, especially given the advances that are coming with system modelling on the F4 and similar aircraft. Hydraulic failures were one of the major causes for mishaps when I was an engineer, these type of failures invariably involved the use of the RAG system and were fairly common.