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.

The two threads are different behaviors, they may have the same root cause though. I have to say looking at the new flight model the improvements outweigh any issues, it still needs fixing, because us a**l people will always find something. It's not an easy task developing a fly-by-wire model, that's why it takes years and costs millions in the real world

See this:: Two threads have been merged both relating to FCS behavior, my thread was complaining about uncommanded nose up behavior after a touch-and-go

TO trim button was the first thing I thought of, It didn't work, I still had reduced pitch authority when I encountered the first issue, bearing in mind this was after the onset of the issue in flight with the flaps at half. My suspicion here is that the FCS somehow gets stuck in landing or approach mode and the FCS has an argument with itself when you command pitch down , I've no idea if these FBW modes are modeled in DCS.

OK, I've managed to reproduce similar behavior as the original issue but not exactly the same. You'll see in the track file I'm doing lots of approaches with different parameters and some missed approaches, the last one in the track file is a touch and go which demonstrates the behavior. I don't select gear up and give mill power without touching the stick. As expected I pitch high but I'm unable to recover even with full stick down and trim, selecting gear up seems to re-instate full pitch authority. EDIT: attached the tacview file from the original occurrence, this is all I have from the first time it happened but it demonstrates the issue well, note I was applying full nose down at the end when the roller-coaster was occurring F18_AOA.miz.trk Tacview-20240223-120901-DCS-IA-FA18C-Syria-Free Flight.zip.acmi

Yep, I'll work on reproducing it and remembering to save the track file

I'm not raising a bug yet, I just want to know if anyone else is experiencing unexpected behavior: My first flight using the new flight model was an instant action flight on the Syria map, I flew around for 10 minutes or so testing the AOA capabilities and then decided to dump all stores and do some touch-and-go's at Incirlik. To cut a long story short, the landing was fine as was on AOA during finals and touchdown, the problems started when I selected 1/2 flap, military power and rotated after touchdown. The jet adopted an increasingly nose-high attitude which I was unable to counter with full forward stick and manual nose-down trim. The result was inevitable and the jet departed. Has anyone else seen behavior similar to this? I've been unable to reproduce the behavior in the 2 short flights since and the track file has been overwritten.

So regarding the Deployment Campaign conversion to BS3.. I'm working on the final mission (Mission 12), unfortunately this will require an almost complete re-write! The problem is the mission is based around intercepting a convoy and attacking a rebel base, the newer Caucasus map is now populated by a lot more trees and the convoy route is now completely off-road, coupled with the new weather and enhanced rain effects you can't see s***t and even if you could the enemy is completely obscured by trees! Remove scenery trigger doesn't appear to work for large areas anymore so I need to re-think the whole mission's location and alter the associated triggers. At LEAST a weeks work sorry for the delay

I've nearly finished converting the "Deployment" campaign to BS3. I think it's one of the oldest campaigns so there was quite a lot of work involved and I had to fly through every mission multiple times to fix them. Apart from simply changing the model to BS3 in the ME, I also checked the weapons load-outs, the correct helmet-mounted device (defaulted to NVG normally) Set INU to no alignment needed, removed trees from areas with targets where there were no trees originally, changed some AI load-outs for SEAD where the AI was useless, plus a few more tweaks which make the missions slightly more achievable. I also cut some of the longer mission routes which involved flying for ages and then not having enough fuel. Will upload in hopefully a few days from now. Edit: Finished! Attached zip file, search for user pyates2104 Deployment Campaign for Black Shark 3 (digitalcombatsimulator.com) BS3_Deployment.zip

I'm guessing you mean in-game and not in the mission editor... So the quick answer to this is no not really. The weather and date/time is stored in the mission *.miz file so the only way would be to unpack the mission file after start, edit the values in the lua somehow, save it and then reload the mission, defeats the point somewhat and is ugly.....

I would use the HaptiConnect software from Buttkicker which now works with DCS. The recommended way to use this software is NOT to use the headset splitter and connect the amp directly to your Buttkicker. Normal in-game sounds should then continue to your speakers/headset as normal, the telemetry from DCS aircraft drives the Buttkicker not the sound coming from the game.