Yaga

In 2.9.4.53549, the changelog lists this for the F-16C: Fixed: Multiplayer datalink share of detected air targets. As far as I can tell, prior to this patch datalink sharing and adding/removing flight members' STNs worked fine in MP. Now it seems to not work at all. Neither preset flights from the ME or flights created in the DED from the cockpit work at all (members don't turn blue or even become PPLI, members don't share targets). Could we get some more detail about what changed in this update? Is there a different procedure or intended behavior now? Do we need to update our mission files with something? Or ??? This is only an issue with clients in MP and AI behave fine as group members. Any guidance would be appreciated. Maybe I'm doing something wrong. Thanks,

Interesting info! I wonder if this is why it always wants to roll left.

Can confirm. Surely this is unintended behavior. However, if you want to use these modes without bringing A2G weapons, loading and unloading A2G weapons works to unlock the A2G sensor modes iirc.

Thanks so much for looking into this and passing this along. Are there any updates in their investigation occuring internally? Were you (or they) able to reproduce the reported behavior in the .trk created per your request? Please let us know if you need any additional tracks to document this occurrence in game. I might have one or two or several.

TGT SEP functioning the way you are describing makes very little sense for exactly the reason you list: you can't separate outward for the vast majority of symbols that will be displayed. Especially when you consider that the primary use case is separating multiple search symbols on the same bearing. Interestingly, what you describe is not separation "in a radial fashion", as you put it. Radial separation is defined as: "Given some central reference point A, the radial separation between locations X and Y is the number of degrees (or radians, if you prefer) in the angle XAY". TGT SEP behaving in this way makes it a lot more useful because it breaks out symbols on the same bearing. I'm curious now if the reference material being used said "radial" and that word was misunderstood somehow.

Does the 3 pos ap pitch switch ingame remain in the up (alt) position after you click it, or is it returning to the center position? As long as it isn't snapping back to center, you should be in pitch alt hold. I suspect a binding issue, likely between the specific binding entry you're using in DCS and the way your physical controller is handling button outputs. Also, a dead zone of 9 is massive and you shouldn't need anywhere near that much to compensate for a controller issue. Sent from my Pixel 3a using Tapatalk

Hi there, Have you had a chance to review the track you requested in order to verify that the FCR acquisition cursor will indeed move while on the ground? Thanks so much. Sent from my Pixel 3a using Tapatalk

They're ground unit returns. Also, they still show if you turn the radar to quiet or silent.

No update.. Is the current scoring logic in MP intentional? Is this the complete and final state for this game mechanic?

Navigate to: C:\Program Files\Eagle Dynamics\DCS World OpenBeta\Mods\aircraft\F-16C\Input\F-16C\joystick With Notepad++ or similar, open: default.lua Once open, paste each line of code from my post above into the lua file. It should be evident where it goes because it should look similar to the control entries that are already there. Like this (line 1011): Make sure you place it above the }} seen here in 1023. We are creating a keycommand, not an axiscommand. Then, you just bind it in game to a joystick button like normal. If we look at the lua entries we've just created, we can see that these bindings will be called ROLL TRIM RESET and ANT ELEV Level in the F-16C bindings menu and will appear in the bindings subgroups for Throttle Grip, HOTAS, and YAGA MOD. Unless you enable this lua via OVGME or another mods manager, this file will be overwritten every time you update or repair DCS and will revert. Does this help?

Roll trim reset for Joystick default.lua: { down = control_commands.RollTrim, cockpit_device_id = devices.CONTROL_INTERFACE, value_down = 0.0, name = _('ROLL TRIM RESET'), category = {_('YAGA MOD'), _('Throttle Grip'), _('HOTAS')}}, --MODDED Unrelated, but here's another useful 'reset' for anyone that doesn't have a linear wheel for the radar: { down = hotas_commands.THROTTLE_ANT_ELEV_AXIS, cockpit_device_id = devices.HOTAS, value_down = 0.001, name = _('ANT ELEV Level'), category = {_('YAGA MOD'), _('Throttle Grip'), _('HOTAS')}}, --MODDED

Agreed. The logic used to be pretty solid and fool-proof. If you unslotted anywhere other than at an airbase or farp, on the ground and stationary, you were scored a death. If something did damage to you prior, then that was credited for causing the death. Not sure why this changed all of a sudden, but at this point it was years ago that it stopped working and really should be adjusted to score reliably again. Seems like it's an easy change to make, if the willingness to make the change exists.

Also seems like there's an over-willingness by the fire control computer to corelate the new brick into the location of an old track. This makes it very easy to be looking in the wrong place, because the FCR gives you every indication that it is the correct location, falsely. Each patch feels like a slightly fresh variation on how the FCR track management/handling logic/whatever is strange, illogical, and utterly unhelpful for achieving the task at hand. But it always centers around old tracks ageing out, track donation, and the rules used for correlating tracks.

Yep, I'm totally off here. You should be able to store the alignment through power off as long as you do a full alignment prior to shutting down, and this is indeed nonfunctional in the sim.

To confirm, currently it is not intended to be able to resolve angle on a jamming target outside of burn through range?

That's not how stored hdg alignment functions. It will only work in the parking spot you spawn into initially. If you need to redo your alignment after moving, you will have to do a full alignment. If you turn the INS to OFF, you will have to realign before setting it to NAV.

I agree word for word. Hoping the eventual radar white paper outlines the calculations being applied, the rational behind choosing them, and some evidence that the method applied produces results that agree with available data. Bonus points awarded if it goes as far as evaluating areas where there is discrepancy with RL data and potential ways to reduce it as development continues. Great. Thank you!

You're asking for evidence of what exactly? The team needs confirmation that rotorcraft have unique radar signature characteristics compared to fixed wing aircraft? We can definitely find such validation, but we could probably just show them a picture of each type of aircraft and have the same effect. If we do go and confirm that yes, there are unique attributes to Helicopter RCS in the real world, then what? It isn't relevant at all within DCS. That data doesn't exist to drive any simulated outcomes. The functions that would conceivably carry and use this data don't exist either. Just like the RCS characteristics attributable to pylons and stores in the real world, they don't factor in. This has.. some effect on accuracy across all the results it generates. Here's two works proposing methods for modeling helicopter radar signatures accurately, validated against real world measurements. Radar signature characteristics, unique to helicopters, are briefly covered in both: https://www.researchgate.net/publication/350770098_Modelling_the_radar_signature_of_rotorcraft https://www.researchgate.net/publication/336073108_Parametric_modelling_of_the_radar_signature_of_helicopters This aren't usable methods here, I don't think. But it is the requested evidence showing that helicopters are not airplanes. I suppose that's something.

I get that "easy to pick up" is unquantifiable, but this is a pretty simple assertion and it's strange that you'd dismiss it, in its entirety, so quickly. It's also hard to source something proving that the radar "works" or "doesn't work". DCS isn't an EM simulator and no one needs it to be one. I understand the desire to create accurate organic outcomes and I do think conceptually this is a good ideal. However... It has to work well. Simulated outcomes are great since you can't script an outcome for every situation conceivable. But if the system in place doesn't even generate reliable outcomes for situations that are common enough to be scripted, then you really haven't made any improvement at all. In fact, maybe the ecosystem has become so convoluted at this point with its myriad of coefs and formulated relationships that it can't even be adjusted easily anymore. When I use the radar in the F-18 or the F-16, I find it to be an absolute unmitigated nightmare of inconsistent and unreliable results, capabilities, and behaviors. In fact, the topic of detection ability only scratches the surface of the enormity of all the problems with processing logic, the general avionics presentation, workflow and just about every other area one must tediously slog through and overcome in order to use the radar as a radar. So when someone asserts something should be "easy to detect", it's hard to know where to even begin when the entire sum of environmental and systems modeling is working against them in nonsensical and illogical ways. Generally speaking, and almost certainly for our purposes, Fire control radars work. Modern weapons track. If they didn't, we'd develop ones that did. In fact, that's exactly what occurred over the last 60 or so years. If the deep simulation approach is to be continued, then you can't cut corners. Abstracting relationships at any level is ultimately abstraction, and any of that begs the question "after all this, aren't we still just scripting the outcome with so many extra steps?" Here's some citations for some research regarding helicopters and signal processing. The amount of existing material on the subject and related subjects is quite extensive, so there's plenty to read. I trust, given the scope of the project, that you have access to an academic DB that will have these journals: Thank you,

No, there's definitely something weird going on. I also use the FSSB and absolutely know the unstable wobble you're describing. Also seems to happen during AAR on occasion. In the comment above, it's suggested to correct with pitch rate trim. That's a bit odd and seems like a symptom that something else isn't quite right. . Reduction above 10deg AoA might be too aggressive. The opposite might be true under 10deg AoA. This could make your nose feel heavy at 11deg AoA and light at 9deg AoA with extremely unstable response to input as it transitions between. It does feel a lot like a feedback loop. An induced oscillation from a far too negative curve. As far as FSSB settings, I found that reducing the max pitch force helped a bit.

Looking forward to it!

From what I've been able to reproduce, this is the issue exactly. If anyone on the server uses the unavailable range, it interferes with Link 16. Interestingly, it also appears that it effects both teams. If anyone, on either team is using the unavailable range, everyone within line of sight to that player experiences Link 16 interference, even if they are on the other team. This is likely why the original poster reported that during a match, everyone on the server reported the problem after takeoff. We experienced an identical situation during a match recently, and while nobody on our team had set an a2a tacan, the opposing team did have an A2A tacan set in the unavailable range. Edit: to clarify, A/A channels (1-36, 64-99) cause Link 16 and PPLI interference. T/R channels seem to have no effect.

<64>YAGA F-16C

You might be pleased to know that this completely solved my disconnect issue. It even seems like the game runs more smoothly in MP now. :thumbup: Thank you!!!!!!!!!

I own the very same nefarious router! I will set QoS on and give it another run.