IronMike

See my post above. Loft is provided in these examples because it is a blinking jammer, so the awg9 has momentarily range info, and performs a normal shot. The track is then extrapolated, while the missile guides HOJ on target but still lofts. This happens also if you say fire in TWS, and then the target turns on the jammer in DCS. But because there are no blinking jammers in DCS, a shot on an already jamming target will be HOJ from the get go, and not loft. Which is why both above examples don't really apply to DCS.

PDSTT or PSTT the jammer, it will go to STT-JAT automatically, fire. That's it.

Actually it doesn't. Neither the example posted by @FWind nor the one by @DSplayer applies to the kind of jamming modelled in DCS. As is, it will fire HOJ and not loft. However with a blinking jammer, the AWG-9 will have momentarily range information at time of launch, and thus the missile would loft normally (irl). That is the problem with just dropping some schematic or picture out of context, without leaving a line with it, or understanding its context. It can be highly misleading, if not providing more circumstantial knowledge. @DSplayer you can replicate the shot. Simply have the jammer off at time of launch and then with a weapon in zone trigger turn it on immediately when the AIM54 is in flight (but it is possible that when going HOJ it will go to straight guidance in DCS, would need to be tested. In this case it shouldn't, but that is not in our hands). The best replication of the shot is thus to do it with the jammer off. Either way, both examples are irrelevant and kinda useless for DCS.

Again, it is the wrong way around of going about it. If someone claims it should be different, they need to justify their claim by backing it up with data that can be acted upon. We have enough insight that justifies the AWG-9 not having a longer burnthrough range. And it is not just some random model. If ppl think this should be different, it's not about proving us wrong, but presenting knowledge that supports their wish. The kind of knowledge that allows us to say a) it is factual and b) it is data that we can actually act upon and implement. Chances are, that with years of work and research gone into this, under the meticulous eyes of folks who work with such radars in real life on a day to day basis, and us not finding anything that suggests differently, it is because there likely is nothing that would suggest differently. If anyone chooses not to trust us on that, so be it, but unless someone presents anything better than the mere thought of "because the radar is stronger the burnthrough range should be further", we won't change it. That different jammers should have different burnthrough ranges is a whole other issue, but again, that is not on us to model, and as said, should the goalposts be moved on that, we will follow along. Until then, it will stay as is. The rest, what can I say? If you use it only for BFM and joyriding, then jamming certainly does not affect you. So stepping away from DCS because of this discovery, makes no sense to me. I can only tell you from flying with the exact same jamming model for the past nigh 20 years - that it is ok enough to provide a tactical element that is both fun to use to your advantage when jamming yourself and being jammed, both singleplayer and online. At the same time, most folks will never know how realistic jamming really is, as it is one of the most classified and closely guarded secrets in the military world, and while we all can know enough to wish for a bit more playful, or slightly more evolved, I should say, implementation of it, acting as if the discrepancy between an expectation based on no true knowledge about it and any kind of implementation of it, is the real let down in flight simming, to me, I am sorry, sounds a bit far fetched. Jamming will likely never be fully realistic in any consumer sim, for good reasons. Could or should it be better? Sure. But no matter how it is, it is far from being the one thing that makes or breaks this video game, even if its denominating genre is being a combat flight simulator. I would also like to kindly suggest that any further discussion about the principal implementation of EW stuff in DCS is better directed to ED, and does not really fit in either this topic or our subforum. Thank you.

Absence of evidence is just absence of evidence. Else that is like saying "there is no proof that it does not exist" - something which you can hear quite often in history channel mockumentaries, which is also where this kind of stuff belongs - into the realm of amusing thoughts. We also deal less in "evidence" or "concepts of ideas" but facts and data we can act upon. So far, simply nothing suggests that the AWG-9 would provide a greater burn through range to our best knowledge, and from my best knowledge from speaking to folks who know a hell lot more on that than me, is that more powerful radar =/ bigger burnthrough range per se. The decision to implement jamming along the path ED has laid out by the general representation of jamming in DCS is also not a question of balance. It is a matter of fairness. It would be simply unfair, if the Tomcat remained unjammable. And the fairest way to implement it, is to implement it by incorporating the current model of EW within the possibilities and capabilities of the AWG-9, as realistically as possible. The AWG-9 in return provides a toolset to deal with jammers, which do not force you into some kind of WVR Arena at all. You can take as long a HOJ shot as you like, and even within burnthrough, you remain well outside 10nm. Never has ED approached us and said "hey guys, but remember to force everyone into WVR", nor did we ever consider "balance" when implementing jamming as we did. If at some point ED decides to expand the current EW model in DCS, we will move along the goalposts ED sets out for it. Simple as that. But until then, you neither suffer a particular disadvantage or advantage in regards to jamming compared to any other module in DCS. In fact I would suggest that in the Tomcat you enjoy the slight advantage even of being able to use triangulation, which no other module in DCS currently can.

The set commands are very straight forward to use, even for newcomers. But if you want some additional guidance, check out this great tutorial by @Reflected

Unfortunately not for the time being. We tried, but without IK it is nigh impossible to get it to look as we'd like, however this is something we will continue to keep on our radar and improve over time as possible. We had a great many things in mind, including hand signals, but all that will have to wait for now unfortunately. Thank you for your kind understanding.

Due to how jamming is in DCS, the standard burnthrough ranges are featured, and vary with the type of aircraft that is jamming only.

You can always contact @graywo1fg - but please keep in mind that his services are not free of course.

Ah, I see. Thank you! Then yes, to put it more accurately: please try again once the patch goes live. Thanks!

Unfortunately not, we will publish it as soon as it is done for download though as we did with part one, I need a bit more time with it. Thank you for your kind patience.

Please try after today's patch is live again.

There is nothing to fix. ED would have to change how actives work in DCS. It works for the A as intended and only affects the C though. It is also a bit over-rated in DCS, and a DCS-ism due to the lack of possibilities to model certain things in missiles. To not get into too much detail, irl it is not meant as a sneaky mode, but reflects when the missile is likely to detect a target on its own. If misjudged, active guidance may be inhibited, for example if using large on a fighter sized target (or normal or small on a bomber sized target). But this is something we most likely will never see in DCS, it is far beyond the scope of what a consumer sim should and can offer.

Nope. Although someone in the test team reported they might still do that when grossly manually overlofted, but that was general missiles, not aim54 specific. But the fix for the looping stuff remains in place. The "reverted" refers to lofting.

Today: Reverted AIM-54 loft to state before looping hotfix to revert exceptionally poor performance.

Please think of it as an alternative history, which it is (no desert storm etc). AMRAAM, F18C, A10C, the Viper block 50 (which will be featured in reforger part 2) all got introduced between 1987 and 1989 in this reality. This is not accurate, but allows to circumvent some of the gaps the AI, dated AI models etc else provide (or shall I say not provide) for the missions. Once we have the A6 AI and early A we can lean more on historic accuracy in the PG campaign, which will be much more true to life.

SET COMMAND WITH VALUE 10009 <value> value = 1 disables Jester LANTIRN auto designate value = 0 enables Jester LANTIRN auto designate (default) SET COMMAND WITH VALUE 10010 <value> value = 1 silences Jester value = 0 Jester will talk again (default) SET COMMAND WITH VALUE 100011 <value> value = 1 disables Jester value = 0 reactivates Jester (default) SET COMMAND WITH VALUE 10012 <value> This is a special command with which you can force Jester to track a specific target using unit name. Since SET COMMAND can only accept numerical values >= -1 and <= 1, we use the following rule: value = 0.01 will track unit named LantirnTarget01 value = 0.02 will track unit named LantirnTarget02 ... value = 0.99 will track unit named LantirnTarget99 value = 1.00 will track unit named LantirnTarget100 value = 0 will resume Jester state to normal operations SET COMMAND WITH VALUE 10013 <value> Another special command but this time Jester will track zones. value = 0.01 will track zone named LantirnZone01 value = 0.02 will track zone named LantirnZone02 ... value = 0.99 will track zone named LantirnZone99 value = 1.00 will track zone named LantirnZone100 value = 0 will resume Jester state to normal operations Commands 10012 and 10013 are exclusive - when Jester is tracking a unit using command 10012, activating command 10013 will force jester to stop tracking that unit and start tracking a zone, and vice versa. Using value = 0 in either of the two will stop tracking both units and zones. 10014: Jester will designate manually what is under the lantirn cross. 10015: - tune AN/ARC-182 to a selected channel. As the value pass: 0.XX where XX is the two-digit channel number 10016 - tune TACAN channel. The value should be constructed using the following guide: s0.XXXY, where s is an optional - sign - use negative values for A/A and positive for T/R XXX is the three-digit channel number (remember about the leading zeroes for channels lower than 100) Y is 0 for using X-mode, and 1 for using Y-mode. so: 0.0630 is channel 63X, T/R -0.0081 is channel 8Y, A/A 10017: DEST knob 0.1 - WP1 0.2 - WP2 0.3 - WP3 0.4 - FP 0.5 - IP 0.6 - ST 0.7 - HB 0.8 - MAN 10018: select waypoint to enter coords from a trigger zone (this command does no action in the cockpit) 0.1 - WP1 0.2 - WP2 0.3 - WP3 0.4 - FP 0.5 - IP 0.6 - ST 0.7 - HB 0.8 - MAN 10019: enter coords from trigger zone for the waypoint selected with 10018 (if no selected, WP1) 0.01 - WaypointZone01 0.02 - WaypointZone02 ... 0.99 - WaypointZone99 10020: WCS switch 0.1 - OFF 0.2 - STBY 0.3 - ON 0.0 - return to automatic 10021: run RWR BIT 10022: TID range knob 0.1 - 25 NM 0.2 - 50 NM 0.3 - 100 NM 0.4 - 200 NM 0.5 - 400 NM 0.0 - return to automatic 10023: Jester Eject 10024: STT target: 0.00 - Stop force STT track 0.01 - AirTarget01 0.02 - AirTarget02 ... 0.99 - AirTarget99 10025: break lock 10026: weapon station state 0.xy x - station number (1-8) y - state: 0 down (safe), 1 up (selected) 10027: weapon wheel option: 0.10 - MK-81H 0.11 - MK-81L 0.12 - MK-82H 0.13 - MK-82L 0.14 - MK-83H 0.15 - MK-83L 0.16 - MK-84 0.17 - LAU-10 0.19 - CBU-59A 0.20 - CBU-59B 0.21 - CBU-59C 0.22 - MK-20A 0.23 - MK-20B 0.24 - MK-20C 0.25 - MK-45 0.26 - GBU-10 0.27 - GBU-12 0.28 - GBU-16 0.29 - GBU-24 0.30 - BDU-33 0.31 - TALD 0.32 - SUU-25 10028: ATTK MODE knob: 0.0 - CMPTR TGT 0.1 - CMPTR IP 0.2 - CMPTR PLT 0.3 - MAN 10029: DLVY MODE switches 0.xy x: 0 - STP, 1 - RPL y: 0 - SGL, 1 - PRS 10030: DLVY INTERVAL 0.xy x: first roller y: second roller 10031: DLVY QTY 0.xy x - first roller y - second roller 10032: MSL Launch 10033: Radar azimuth -1 to 1 10034: Radar elevation -1 to 1

The issue is simply how tracks work in DCS. They are not really meant as a replay function - even if used as such. They record all inputs, and then play them back, which helps tracking down bugs. Now, naturally we would like to have them fixed, but multicrew and the Jester menu make it virtually impossible as is, hence the suggestion further above to record server side tracks, by for example hosting a dedicated server for yourself. It's not really a discrepancy, unfortunately, it is an improbability at best and an impossibility at worst with the current state of affairs, and thus it is highly unlikely that we will dedicate ressources to fixing it, until (and if) the way tracks work is changed (I don't think there is any intention for that atm), or a true replay function gets added to DCS. Please do not get me wrong, it is as disappointing for us as it is for you, but currently there is not really anything we can do about it. Server tracks are your best bet (and work fine), and also for short tracks it helps to hit ATT Hold within 10 seconds of mission start (which avoids input desync) and not using the Jester menu, though I can see that this is not very useful for general purposes. Our apologies.

It was also intended that ground controllers or JTACs could steer the plane on a ground attack run via datalink. Which ofc also never happened.

Additionally you can ask Jester, your RIO, to tune TAC assets or ATC frequencies from a list and he will do it for you.

Lots of speculation here guys. We've always followed a marketing approach that fits the module, its development, the community and us. In short: when the time is right, or when you guys are too clever to keep it from you haha (like with the a6, etc.).

I think he means the alert state of units, which can be set between green, red and auto.

Thank you for asking, it is going well so far. More news will follow a bit later this year, hehe.

Hmmm, it is possible that repair might break that, since the jet moves, even if only up and down. TBF it is a fairly edge-case scenario to use it in DCS anyway, few would do a full align before shutting down, only to then spool up again etc etc, especially when a new spawned jet is set to use AHS and so on. I'll see what @Naquaii thinks, and maybe we can investigate it further at some point, generally ofc it should work as advertised. Also not sure how much wheelchocks would affect it, etc.

Is that directly after mission start? IIRC targets need some time to warm up and there are other such issues with the new FLIR. It's best to make a short track and report it to ED, as these FLIR issues are out of our hands unfortunately.