darkman222

I have already made several threads. The issue I run in all the time is in this thread: DXDiag from today, with the issue happening all over again is posted in the thread. I am contributing a lot, and not just complaining. And I take a lot of time to illustrate it with a video and track. I am just curious on how many ED test PCs issues are spotted of a planned OB release, but pushed out to the public anyway. ED always seems to be suprised about how many people are having issues, compared to their inhouse testing.

DXDiag DCS Log from todays session. See the video in first post. Same issue all the time. DxDiagDCS29 20231216.txt dcs.log

DCS was playing back fine with 2.8. Now with the issues of 2.9 there are all those threads popping up how to optimize Windows, what to disable or enable now. Maybe even suggesting that my CPU magically starts overheating, the exact moment I updated to 2.9. What a coincidence. The percentage of time making DCS playable again after an update is higher than actually playing it. Please give me one of that magic inhouse DCS testers PCs that always seem to have no issues before a new update is published. I'll pay any price for that PC. Sorry for this not helpful post. Just needed to say that. Edit: BTW all my settings are set to LOW, there is no more headroom to play with. And I have tried all the major things suggested. If not right from the start, DCS will turn into a stutterfest for sure after a certain amount of play time.

Go to the post of ams999 27th October. He has a single player track file that shows the issue offline too. Might not be playing back any more though, DCS OB version is higher now. I play MP only, but I can only tell its not on your end. ED has to fix it.

I watched the new Wags F16 update video. Although I would not expect him to mention that issue in a video, the next update seems around the corner. Fingers crossed that it will adress the issue. But for now. Nope. No news, keep on interpolating between the pipper jumps in your mind... and pray its not getting worse with the next update lol.

I once ( 2015) stubled up that text on the internet. Seems like in hindsight it was our beloved C.W aka Mover who wrote it: http://fightersweep.com/1494/hornet-vs-viper-part-one/ http://fightersweep.com/1539/hornet-vs-viper-part-two/ http://fightersweep.com/1904/hornet-vs-viper-part-three/ http://fightersweep.com/2378/hornet-vs-viper-part-four/ In DCS the F18 is less demanding, more forgiving. Even the over all size of the letters in the cockpit and the MFDs are bigger and better readable which is a statement how it was designed.

The F16 is the best jet to learn proper BFM and the worst jet for quick success. If you dont absoultely know what youre doing against an F18 or M2K youll lose. 2 circle fights are more demanding. Things might change with the revised G effects, so the F16 can stay in the best performance evelope. We'll see, but again, of course only if you know what you're doing. F18 dudes use exploits with the paddle. Maybe they'll get stuck ailerons in the future according to Wags. And the M2K has been revamped, has a nuclear power plant or maybe less drag. Don't know what they changed, you cant run it out of energy with an F16 any more. Not even on the deck. Maybe try to practice against another F16 first, so you can compare your skill and BFM understanding. Try dissimilar opponents later.

I bet an AI cant fly a highly complex FM like for example the one of an F14. There will be a lot of "counter computation" for FM. I guess its not that easy. These expectations are way too high. But still it is very unsatisfying if the AI can cheat and you cant.

Not really sure about the fuel flow as indication when AB starts. At least the nozzle does not move any more when going over the 75% percent which could be a sign that AB engages. It seems like there is more signs that AB engages over 75% than that its not engaging. Unless someone has better information, I assume that the 75% position is the correct AB position but the flame animation starts at 82%. Which cold be a bug or maybe it really is burning without a visible flame in that lower setting.

Well first of all, thanks for the detailed post. I used the same method with the spreadsheet mentioned above for all my aircraft in DCS. Which are quite a lot. But the main question seems to be adressed here: What youre saying is that you believe in 75% as the point where the AB engages although the visual representation is at 82% thrust set by hardware. That means that you determine the AB position by checking the fuel flow but not the visual representation of the AB flames. If you say the fuel flow spikes above 75% then the control indicator is correct but the visual representation of the AB in the F18 is broken. I dont believe that if the AB engages at 75% will become only visible from the outside at above 82% ? The only possible answer is that it possibly burns without a visible flame up to 82% throttle position which I think is not plausible.

I am recently configuring my physical afterburner detent and I double check between external view and the controls indicator (RCTL +Enter) and realized that although I am right above the threshold for afterburner according to the contols indicator the after burner seem to engage with a much higher throttle setting. Significantly above the AB threshold but no AB engaged The depicted throttle setting is the threshold where it engages. In percentages speaking. The shown threshold in the controls indicator is at exactly 75% like in the F16. But in the F18 it engages with 82 %. For illustration an example from the F16 Afterburner already slightly lit Is the controls indicator wrong or am I missing something? The controls indicator is showing the position the AB engages correctly in all the other modules (F14, F15 SE...)

Not sure where your question is pointing at? The radar does not distinguish between friend or foe. These two radar contacs are currently jamming, no matter what coalition theyre on. At the moment they are just radar returns whithout a radar track file being created yes. If you'll IFF them you'll find out if they are hostile or not.

I did not want to go into that again, but to make it really obvious and to add what Silver said. Community testing is important and valuable. I get that. But VOIP is not like a new module (whithout a competitor) that gets developed while people are adapting to it. We already have SRS, which I hate and find less immersive compared to what VOIP in that early stage already offers. But please, in the next published iteration, make sure that all the community feedback is adressed. Otherwise it will be abandoned and overlooked by server owners soon. And all the effort ED has put into it will be wasted and end on a dead track for such a promising thing.

You can use modifiers to double or triple the amount of buttons. So use one button to set your comms buttons to VOIP. Another one for Comms menu. Or even a third one to do nothing, so you can use them with SRS without transmitting on VOIP or opening up the comms menu.

... is exactly what I was trying to say. I really hate SRS but its working.

Please ED @BIGNEWY. Dont lose the quick completion of voice chat out of focus. I know there are a lot of other issues currently. But I am so looking forward to abandon SRS as an extra layer of error in a mission. Voice chat should not have been released before it was stable and at least comparable in features to SRS. The danger is , that people who tested it right now, realize that its not reliable and wont test it again, when its claimed to be complete. Of course if it is reliable and stable, I am just looking forward to have some audible feedback if someone steps on another persons comms and many people will want to change the balance of the channels between the left and right ear. I know, possibly unrealistic but incredibly helpful to determine from which channel the transmission is coming from. Really those three things are needed for me to be ready to uninstall SRS. Edit: Not sure about how squawk is being handled with LOTATC without SRS though...

Great. Now we have the specifications. Get them from Bogey Dope and post them or PM them to ED.

When I got mine in October the NLR implementation was awful. SimShaker works just fine since then.

Thank you for posting this. I observed this oscillation behavior, with a possible deep stall, since the 2.9 update with the new G onset modelling. I did not have the time to reproduce it yet. But the oscillations can also happen on very low altitude with a very low fuel state. Below 1.500 lbs I remember.

I think gauges are a thing thats detemined by the resolution of the headset. But the shimmering is due to bad textures, of whatever reason. I have the Varjo Aero and the Pimax Crystal. Shimmering on the dashboard and the rudder pedals in both VR headsets.

It does not have a self protection system against stupid pilots. And thats maybe the reason why there is no evidence or data about gear failure due to pilot error. Why would someone test that and what would this data be useful for? But because nobody tried in in the real world does not mean gear overspeed does not exist. I remember a youtube show ( might be a guest of Movers channel) of a F14 pilot who forgot to raise the gear when taking off from a runway instead of the carrier. So he did not have it in his muscle memory. He oversped the gear. In this case there is proof and data about this incident, which is fortunate for the modelling of the DCS F14. Luckily it did not happen in the real world for an F16...yet.

Following this logic means, as long as there is no evidence it is considered plausible and realistic that while the gear door will get damaged, the gear itself is seen as indestructible in the ED universe until someone digs out a paper proving the opposite? Dropping the gear at mach 1.2 without consequences is realistic? Isnt the logic sufficient that external stores like bombs will be damaged going supersonic the gear also must be damaged when employed (at least going supersonic, talking about an obvious situation here for illustrational purpose)?!

Grab a cup of tea, or beer preferably and go through this thread. It will answer most of your questions:

It is pretty much playable in VR though. Of course your head is sometimes stuck in certain parts of the vehicle geometry, which is due to the unrestricted head movement in VR compared to 2D. The only thing that prevents it from VR being useable is that the pipper is just bound to the head movement instead of showing the calculated aiming lead like in 2D. "Locking targets" works good, showing a target designator box around. I dont quite get it as this effort has been done, why the gun pipper is the only thing thats not working correctly. Otherwise it would be just fine for VR use. Feels like "almost there" to me.

Quick heads up on the state of the issue. With the new update DCS 2.9.1.48111 Open Beta either with or without MT.lua the issue persists. In the previous OB the MT.lua file even produced worse results. Now it does not matter any more. Looks like our issue here is just the little brother of the issue other people have with massive CPU spikes all the time.