Noctrach

Yeah I understand its not meant to be perfectly reliable. Getting fake tracks is something I actually really enjoy. Having no means of resolving even very simple track conflicts just makes the entire mode seem kinda pointless except for in hyper-specific scenarios. It would imply the F-14/Phoenix weapons platform was in fact a very long-range SARH missile in the majority of fighter-to-fighter scenarios, because in real life the weapon could not go active on a lost track. I worry in its current state that when the missile API gets updated, not a single phoenix will manage to make it more than 10 miles before losing track and going stupid. The reason they hit now is because they use old AMRAAM INS guidance, they won't do that anymore. It's effectively impossible to maintain a track for anything that's not flying straight and level at high altitude. Minor course changes already throw off the AWG-9's trackhold to quite extreme levels. I've never seen the AWG-9 actually resolve a track by itself, which makes me question if that functionality is even in at this point. Hence my question being aimed at development status and/or intended behaviour.

@Harlikwin take your poorly informed anti-phoenix brigade to another thread, this one is about TWS track resolution specifically. @rest A lot of you make good points and excellent contributions, but I'd like to ask you to separate Jester related issues and the issues for which I've raised this thread. My POV as a RIO is that Phoenixes do guide and track despite track loss due to the INS issues present in the sim. So multiplayer "effectiveness" of the missile system is not particularly affected when fired at a valid track. Rather, the track resolution of the AWG-9 is so poor that TWS-A will frequently be dragged to extreme and undesirable angles during guidance, leading to it breaking/losing tracks on possible follow-up shots. Firing on invalid track makes a phoenix go dumb, so this issue particularly limits the use of TWS for multi-target engagement. Not so much TWS/Phoenix engagement per se.

I have no doubt TWS would generate false tracks for pretty much any radar between the 70s and 90s but I'm sceptical if the resolution was truly this poor for the AWG-9. One would think when generating 3-4 tracks within the scan volume where you were previously tracking only 1, it would be reasonably easy to create some logic to resolve this to the only track that actually has a return, even with 70s computing. Especially if that one return has a surprising tendency to be just like the one you were tracking before, but on a slightly different speed and heading. :P I would expect there to be a significant difference between false tracks popping up while just in scan mode (random radar reflections) and false track generation just breaking the actual missile guidance.

Cut the snark, what Dragon 1-1 means has nothing to do with input latency. If you compare the F-16s FLCS response with that of the Hornet or that of the non-FBW modules, your control inputs result in motion at an order of magnitude faster in the latter. The Viper's roll axis is particularly affected by this. "The other sim" doesn't have it to nearly this extent, which one is correct is not for me to guess, but there's definitely a difference. With the Warthog stick it isnt as noticeable because the spring forces are so heavy by default. Using a lighter stick you can throw it all the way to the side and back to centre before the Viper's FLCS starts moving. Try something like this in the F/A-18 or the Tomcat and you will get complaints from the passengers that the luggage has exited the overhead compartiments at breakneck speeds. If this is a real feature of the bird, it's a real feature of the bird. If it's there because of some weird input profile exclusively suited for force-sensing sticks, it's a poor example of forgetting 99% of your userbase. Setting negative curves seems fine to reduce the effect but results in extreme non-linear responses to input which is not great for formation flying and refueling. Either case, it's definitely there and unique to the F-16 in DCS.

To what level is the current state of the AWG-9 final? I'm noticing TWS-A mode being extremely unreliable for missile shots, particularly on servers that suffer from a bit of latency. Missiles shot on contacts that aren't flying pretty much straight and level at high altitude are essentially wasted, since it takes almost nothing for the radar to lose track and generate false contacts. Slight turning of a target seems to split off tracks that will go in wildly different directions than the original one, leading to the guidance never resolving even momentary loss of return. Using SYM DELETE on these false tracks as they appear seems to only confuse the radar even more, forcing TWS-A to start tracking... essentially nothing. This frequently drags the centroid to a position where it has quite a high chance of wasting any other missile shots that were in flight as well, before kinda getting stuck until I force it back into PD-SRCH or similar. I saw a bug thread on a similar issue but it doesn't appear to have had any activity for a good couple months now. I'm wondering if the current implementation is still suffering from some bugs and weirdness, or if this is how the actual device is supposed to behave, in which case I'll have to learn to work around it (i.e. only ever use TWS on fighters at relative co-altitude)

What's the point in calling it a study sim if there's no documentation to study and the entire thing is based on SME input :/ a single SME at that. No disrespect intended but even though his credentials are great and these are undoubtedly very passionate devs... Pretty sure if I talk to 10 different pilots I get 10 different opinions aside from the fact that their jet is the best one out there. Weird to me how so many endless discussions are fought on these forums on these kinds of topics, but no worries, if we like the jet it's fine whichever way it's modeled.

Hey Sport, While I don't know whether there is actually some problems with the new guidance, the clip posted above is unfortunately not a great example to make. The parameters of this shot would be extremely challenging for a missile. While this is "only" a 5 mile shot. You are firing at a target that is beaming you, meaning the missile will have to do some fierce turning to lead for a proper intercept trajectory. It also means your missile will be flying a pursuit on a cold target by the time it's halfway through the intercept. This is for all intents and purposes a cold-aspect shot with negative closure (target is significantly faster than you) What's more, looking at the altitude and closure, your target is flying well in excess of mach 1.4 at 36,700 feet. While firing from a low-energy state of 0.65 mach at 11,500 feet. Your missile is at a huge kinetic disadvantage to overcome, all on a 4 second rocket booster. Essentially you are requiring the missile to climb 24,000 feet (4 miles) straight up before chasing down a cold aspect target. Due to the angles and speeds involved, the effective length of your missile's flight path is going to exceed 10 miles. That is if it somehow manages to maintain >1.5 mach for the entire duration of flight. This is an almost impossible shot. In this case it's more an issue that your instruments showed you false information, than there being a problem with the missile. Frankly speaking, I think this is the case with a lot of these reports. Focusing purely on the Rne your avionics give you is a really poor way of estimating the shot Pk in DCS. As it is very often misleading or outright false.

Exactly, you're never getting rid of lag entirely, but you can compensate to the point that it won't be noticeable. Shooters are impacted far more by this than simulations and they manage this with good result.

Frankly I don't understand why people would think this is a problem... DCS does exactly this on the client side right now. There is literally no difference in doing this on the side of the server. Actually, there is a difference: Instead of two different results across two different clients, there is now a single unified result. Bam, no more desync. You will always have some discrepancy due to lag, but the discrepancy is identical when it's client-client or server-client. In fact, server-client is usually the shorter route of the two. Lag compensation.. as long as there's no dropped packets and you have a steady connection, it's not really a problem. 200 milliseconds is about 12 frames, you're not even gonna notice that discrepancy. Your RWR lag is an order of magnitude worse. Physics predictions are pretty doable even at well beyond the speed of sound, but it starts depending largely on server tickrate, which in turn affects hardware requirements. In fact, right now it depends on client hardware to do the same thing. If my client is running at 30 fps, my physics calculations are taking 33 ms to finish on top of your 200 millisecond lag. The evidence to this is in DCS right now for all to see... in online dogfights bullets will pass far behind an enemy jet and still tear off wings. AAA games have been doing far more complicated things for decades. People just took that for granted because nobody pretended it couldn't be done. ---------------------------- P.S. Another non-argument. The amount of people playing shooter games far eclipses the amount of people playing flightsims. There's hacking and cheating in DCS all the same. In fact, about half a year back there was someone killing people on a server by simply connecting and executing scripts. There's just not much of a practical advantage to be gained outside of getting 30 people mildly upset for 10 minutes. There's enough advantage to be gained by simply exploiting inherent bugs (Hornet spark plugs anyone?).

The real solution as Coxy mentioned is a complete overhaul of the network code. This is just another case in which flightsims lag behind the rest of the games industry by a good amount of time. Shooter games figured out the benefits of a server-authoritative networking structure more than a decade ago. In such a setup, all gameplay-critical calculations (like missile intercepts, snapshots, hit confirmations, etc.) are done by the server. This would eliminate the kind of issues we're having with desync. All missile traffic would be server-sided and clients only get positional updates, resulting in one single unified result. It also greatly reduces the possibility of malicious client activity, since they are not an authoritative source. Example: in an architecture like DCS's a malicious client would technically be able kill you without even firing a missile, just by spoofing the "missile hits target is dead" message sent to the server. In a server-authoritative setup, the client would request missile fire. If the server deems this a valid request, it will handle the launch and intercept (positional updates to clients) and dispatches the "missile hit or missed" to all clients. Downsides to this are obviously that you offload a large amount of work to the server and that latency to server will skew the visual result on the local client (although lag compensation algorithms exist in every FPS game that all but eliminate this aspect). Key problem is that it'd require a complete overhaul of the 90s engine extravaganza we have now.

Nope, unmodified warthog basically fresh out of the box. My thoughts exactly, the initial 30-40% of movement only show minimal change, with a sudden aggressive increase in response after that. As someone who flies everything at 0/0 curvature, it feels dreadfully unresponsive.

So I hate to say this but the F-16 is the only module I've ever felt I'd have wanted a refund on simply due to the way it responds to user input compared to all the other modules in the DCS library. I've tried every imaginable tweak to curvature or saturation, but it still feels as if tiny inputs are barely registered, needing huge sweeping motions on my warthog for even the smallest in-flight adjustments. It feels as if there's a delay between what I do and the interpretation of the jet unlike any other module I've flown (which is basically all of them). There has been mention that this is due to the module trying to replicate a force-sensing device, but I doubt more than 1% of players has one of those. I'd really love to see an optional input curve better suited for desktop joysticks, as I genuinely struggle to enjoy flying this module.

Primarily I'd have some doubts about its consistency between modules. Some seem to fly more accurately to expectations with pylons attached, some of them need to be flown clean. The hornet comes to mind which, when flown clean in the first couple of months post release, bordered on supercruising and earned quite a few raised eyebrows in BFM. These days the difference isn't all that big. But then the Viper from the initial release point seems to perform pretty accurately without pylons, but seems to incur too much drag with pylons attached, leading to comments about an apparent lack of engine power and turn rate. The difference here is very noticeable. Of course it could be like this in the real jet, but I'm curious how this is modeled.

There's been a lot of recent debate on turn rates for the F-16. Now I've personally been noticing rates being pretty much where I'd expect them considering the documentation. (Pilot G tolerance notwithstanding obviously) However, this only applies to a Viper without pylons, with them attached the bleed rates seem quite outrageous. How are aircraft generally tuned FM-wise and how WIP is pylon drag?

I think what irks me quite a bit is that there's a pretense that this is a test that has to be done under very specific conditions. What we're testing is nothing but the aircraft response to the maximum digital input value DCS can register with any controller. This has nothing to do with the type of controller used, as we are simply pulling to the limit of what DCS allows us to feed it as an input value. When at this limit the G-onset rate of the DCS F-16 noticeably slows down as the aircraft hits 8G, resulting in a very slow G increase between 8.0 and 9.0G. Other sources (HUD tapes, the other sim, graphs shown in this thread) don't seem to corroborate this behaviour. This behaviour almost exactly matches Nineline's personal findings as shown below: Again, this test is simply based on the maximum possible input value in DCS. Hardware has nothing to do with this. I am only considering the green and blue lines. Nineline's result corresponds with my own in the sim when yanking the stick fully aft at speeds well over the minimum required to hit 9G (above 0.9M to make sure we stay well within the 9G band on the EM graph all the time while loading up). The difference isn't big, but causes a noticeable delay between 8.5 and 9.0G compared to expected results. So @Nineline to be extremely specific for me personally: I do not consider G-onset rate as a whole too slow by any significant margin. I do not consider turn rate/ITR to be off by any significant margin. I do not consider controllers to be a contributing factor for this test as it is simply based on the maximum allowed input value in DCS. What I would like verified is the following: The G-onset rate noticeably slows down in the DCS F-16 between 8.0 and 9.0G specifically. This is not corroborated by HUD tapes or public data. Is this verified as correct behaviour? If so, would it be possible to get an explanation why the DCS F-16CM Block 50 differs so much from other data as brought forth by users in this thread?

@Nineline however despite everything, doesn't the combination of evidence from both ED and other users lead to the conclusions that: a) As per your own test, the G-onset at higher speeds is slower than the one in the real Viper (greater than 10% margin) b) As per user tests (need verification) the speed at which the DCS Viper attains 9G is higher than the real deal? (greater than 10% margin) Taking into account EM graphs are interpolated data. That seems significant. G-loc should imo not be considered "cheating" for these tests as it does not impact the control response in sim at all. It merely impacts the visuals and/or complete lack of control in case of blackout/redout. So if anything a G-loc free test would give a better representation of the in-sim FM response as it is not prematurely terminated due to pilot loc? (Less variables in testing) Controls wise: wouldn't any FLCS just take the relative position of commanded input to the minimum and maximum possible commanded inputs and split the difference? I.e. regardless of exact input device, 60% commanded input results in the same FLCS response? Are you saying a force-sensing stick will create a noticeably different experience and FLCS response in DCS than a regular joystick? edit: What you are saying about controls sounds illogical to me, any flight control system in a real jet has a minimum and maximum deflection. This can very easily be linked to the minimum and maximum outputs of any controller, as we're just talking a min/max digital output value, an incredibly easy abstraction to make. What you cannot simulate are stick forces in response to pressure differentials on the control surfaces, or vibrations and butt-sensor telemetry. This is what makes real flying different and why any pilot (including Mover) initially struggle to adjust to sims. They are missing a ton of senses they would have in the real jet. However, this has nothing to do with stick deflection vs aircraft response. I'm not sure what you are trying to convey here. Is the FLCS response non-linear?

If you delve in deeper you will also notice that different radar modes have different detection ranges and range resolutions. Where TWS will have great difficulty separating close targets, RWS will do this much further out, surpassed again by PD-SEARCH. You will also need to combine your DDD with your TID results to get the full picture. As near_blind says, you're looking at late 60s computational power here. Separating and filtering the DDD information into separate tracks with closure vectors is a lot of processing. Your single track on the TID might correlate to a double return on the DDD. That same DDD result will show two hits on the TID in RWS. The resolution is still there, but how you use your available processing power decides the TID result. The core message here is: Don't see the TID (or front seat repeater) as your radar picture. The reason there's a RIO in the back is that you need ALL displays for the full picture.

Great news, thanks! :)

The amount of armchair experts on this forum trying to hide their ineptitude at BFM behind half-baked, pseudo-intellectual bitching is crazy. No. If they bumped the turnrate down 2 degrees a second to give you that desired +1.5 second on the turn circle the jet would still be perfectly fine and would still beat you in a fight. Especially if the pilot doesn't mind breaking it. If you're complaining about these kinds margins you should be complaining for every jet on every DCS forum, since this is well below the average error. You should then follow this up by accepting your BFM gameplan is trash because you haven't gotten beyond nose-to-tail, pull and hold. Play the damn game. Learn, improve, overcome.

Chart is correct insofar that the lines are 2, 3, 5 and 7.5G People shouldn't expect aircraft to match all charts perfectly though, all DCS FMs are off by a couple %, better or worse depending on altitude and config. This is not real life but merely a very close approximation. Simply the fact that stores drag is generally wrong in DCS means that any charts that are not made with a clean aircraft should be taken with a massive pinch of salt as it is something none of the developers have complete control over. As examples: Hornet turns a bit faster than what's been gleaned from RL charts, Viper turns a lot slower due to some FLCS issues, F-5 is close in some regimes and much too draggy in others. Some aircraft are really close with pylons but completely silly without. Etc. etc. If you're losing fights on 1 deg/s, the problem is your gameplan, not the FM.

Practice the sight picture, no matter your altitude or approach heading, if you manage to get the sight picture right your dive angle will be good. Then it's a matter of getting the speed and release right. But really, sight picture is most important. Use tacview to compare the results between each bombing run and go from there. For me, raising the seat fully and putting the target between the mirror and canopy bow usually gives me close to a 20 degree dive. Leaning left and putting the target on the canopy bow makes 30. Release slightly before your target altitude as the altimeter has a couple hundred feet of lag. I primarily use the patterns as described in the manual. 20 degree - start 5000 AGL, release 1500 AGL, depression 80 30 degree - start 6000 AGL, release 2000 AGL, depression 79 entry at 350 KIAS, exit 400 KIAS As with any manual bombing run: More bombs better. It's okay to ripple 4-5 bombs to take out a single tank. I can drop a pair of Mk-82s on target on a good day without wind, but if there's any other factors involved it becomes a bit of a crapshoot :P anywhere within 150 feet is a very good release and would take out anything with light or no armour.

Solid :thumbup: thanks for the reply Good to hear I'm not just messing something up massively

Good news C: Awesome! I was not aware of this.

Pulling the trigger 0.5 after the wings appear makes the problem slightly worse, which kinda makes sense considering they have slightly less time to "fall". RocketsLongAfterWings.trk RocketsLongAfterWings2.trk RocketsLongAfterWingsNTTR.trk RocketsLongAfterWingsNTTR2.trk

Another victim of the DCS 2.5.6 o̶v̶e̶r̶e̶x̶p̶o̶s̶u̶r̶e̶ ̶e̶x̶e̶r̶c̶i̶s̶e̶ lighting overhaul. The radar in this otherwise beautifully lit pit has become extremely difficult to read, as there's a baked green reflection covering everything. Result on lowest (top) and default(bottom) radar brightness settings: