Zabuzard

This is an oversight. Thanks, fixed.

Sorry, cant comment on that

I was replaying track 1. The bandit appears on screen at 21nm, Jester calls him out and moves the cursor over him. At about 17nm you are commanding lock, then unlock, then lock, then unlock, then lock, then unlock. All the way until merge. Jester is spamming commands and voice phrases as you give him new directives. If I click on "Take Control" once the bandit appears on screen and hit Context Action LONG once (hold V for a few milliseconds) and then stop giving Jester commands, he successfully locks the bad guy and keeps the lock as intended. Lock achieved at 19nm.

It seems you are constantly pressing the context actions, way too often. Resulting in commanding Jester to lock, then unlock, then lock, then unlock, ... you send the action about 8 times. He found and called out your bandit at 21nm Then you told him to lock the guy and Jester locked him While he was locking, you told him to unlock him again. So a few seconds later he unlocked him. While he was unlocking, you already commanded him to lock and shortly after to unlock again. And so on. Try to give Jester one command and then wait for its execution If I take control of your replay, command the lock once and shoot as soon as in range, I am able to force your bandit defensive at 20nm and shoot another missile for kill at 7 nm.

Sure

Thanks, the issue is on our list already, cheers

The technical explanation is that there is Jester code that lets him control and tune antenna elevation and cursor position 24/7 every couple of millisecond, so that it will be fast and accurate. While other things, like the range knob, is only set on certain trigger points in Jesters logic, such as when he switches from standard scan to lock, or when he is following a target within autofocus range. And then assumed to not be changed anymore within that period - which is the moment you could mess with the controls (while Jester still assumes what he set is the active setting). And other controls, like the Aspect knob, are only touched when he boots up the radar, and then assumed to be left like that. Which technically allows you to mess with it as-you-like, but can then of course throw off Jester completely if what he thinks is active differs from what is actually set. The aspect knob in particular will soon (next update) also be touched by Jester all the time, making direct manipulation of it not feasible as well - but therefore, Jester Wheel and Context commands will provide a way to perform no-lock shots (see the manual). In general, Jesters code must be able to assume that his pit is under his control only and that any pilot requests come in through a controlled interface, such as the Jester Wheel/commands. Direct manipulations of his controls are technically possible (in particular for power users), but Jester assumes its not and doesnt support it.

Since you have deselected the weapons, you have to wait 3 minutes for them to warm up again (this timer is hardcoded in their circuit) and then hit trigger to activate the camera again. If that also doesnt do the trick, can you please send us a short track file showing the issue? That would be very helpful, thanks.

It has a higher priority, but the issue is very complex to approach from a technical side. Might also need a change or two by ED... Will see

In the debriefing window, there is a "Save Track" button

It is indeed the same issue. The tracks dont fully support HB UI yet. You did the cold start with either mouse-clicking or head-tracking through the Jester Wheel, which is not captured in the track and hence, when you replay your track, your aircraft moves around with dead engines and no power. You either have to use the keyboard-only interactions for the Wheel (CW, CCW, Enter, Exit, ...) or, while replaying the track, mouse-click what you would have clicked during the real play. To understand why you are still moving despite dead engines you have to understand that the track system ignores the simulation for the aircraft position. The aircraft is moved "on rails" to ensure that at least the aircraft position is correct at any point during the replay. Everything else goes according to the simulation though, which is why you then get these weird combinations.

I am sorry if you perceived my message as calling you incompetent, that was definitely not my intention. More that I cant start looking at the code with "okay, Jester becomes saturated with too many targets", cause this is not how it works on the technical side. Jester can handle 2 million targets simultanously without any problem, he is a computer. If you say there is an issue, then there is an issue, I believe you. If you can provide a quick track file, then we can investigate the issue and likely spot the bug very quickly. Without track, if I am trying to replicate what you are describing, chances are quite high the issue might not occur because I probably misinterpret your description or the description perhaps misses a step that you thought is perhaps irrelevant to the bug. For example, perhaps the issue is related to the mission having wind. Or only happens on a certain map, or only around a certain airfield with a certain magnetic deviation. Or because you placed the AWACS with Jammer behavior enabled. Essentially, based on previous experience with bug hunting, going after something like that without track has very low chances of replicating the issue. It also just makes the developers life a bit easier, as we are then able to replay the exact situation after each code-edit to see whether it got fixed. So it would be highly appreciated if you can share one, or perhaps at least your mission file

I have a different, better experience flying this mission. Please send a track our way and we can tell you what you can improve - or possibly spot any bugs with Jester :)

I appreciate your attempt of interpreting what might be happening, but that can't really be the case. Can you share a track or mission so that we can have a quick look and investigate? Cheers

Teaching Jester to work with you manipulating his cockpit simultaneously is extremely difficult and not really something we want to pursue. In general, you are not supoosed to "play WSO from the frontseat". Instead, we want to rather give you commands mimicking what a human pilot would tell the WSO, such as "can you scan a bit higher? I think the bad guy is above us", which btw is already available in some form with the Jester Wheel Scan Elevation commands. I suspect the "need" for more manual control will get less and less the more Jester learns and becomes smarter. Or once we add planned features like pointing the radar at your eyesight/mousecursor, as in "look here". And when Jester also learns to hear AWACS calls.

Sure, Ill put it on the list. Doesnt sound too difficult at first glance :)

Should be this guy here: Alternatively, you can also start the DCS executable with the command --no-launcher.

Thanks for the tracks. This is a bug, I have just fixed it with the help of your tracks For CAGE/Boresight specifically it seems that the "last_seen_timestamp" of the targets werent updated, so he could not properly apply his "priority" selection to tell the targets that are actually on your screen apart from the old targets in his memory from before entering CAGE/Boresight. Leading to the target you just downed being as-recent as the other targets and having a higher priority since it was last seen at like 0.1 NM distance. Workaround until the fix arrives in your version is as you said to exit/reenter cage quickly when you want to change targets in CAGE/Boresight Perhaps also toggling CAA on/off would do the same, thats just two quick presses of the NGS/NWS button on your stick and only takes half a second. I cant really spot the issue in your track file, which is different to the video. In the video it looks like you G-locked Jester with a sudden hard turn and he locked only after the G reduced a bit. In the track I dont really see any actual locks, just Jester attempting to lock but losing the target out of sight in the heavy clutter and hence taking very long to execute the lock and also giving up once. He could have picked a better gain setting to reduce the clutter (which we are working on), but its also just a very unfortunate altitude/distance combination where targets are just naturally all within the ground clutter and altitude line etc. Very difficult to pick something up in that situation. Thanks for the track. Might take me a bit longer to check it while I am trying to get hands on Sinai. (Possibly you could re-do the track on Caucasus or Syria in the meantime?)

AFAIK this is correct behavior. The HUD reticle is limited vertically to move between +14.4 and -225.1 mils. The reason you can select a higher depression than that is that there are also other factors that can displace the reticle vertically in certain delivery and HUD modes. For example, it can be either relative to the fuselage reference line or to the radar boresight line, as well as compensate for INS pitch and/or drift. With a certain mix of those, it is possible that the "default" undepressed position of the reticle is above 0 and then the full range of 245 mil depression can have a visible effect. I'll try to dig out the reference doc, cheers.

Good stuff, thanks for the tracks. Will investigate tomorrow :)

It depends on your selection in the Special Options. Its called the Headtracking Origin and you can select between two types: Center and Dynamic. If you picked Center, you can shift the Center point to your natural head center (important for VR) by using the offset options next to it. Details of how it works in our manual: https://f4.manuals.heatblur.se/dcs/special_options.html#allow-head-tracking

You dont have to learn his job. But then you also have to accept that perhaps it wasnt necessarily Jesters fault that an engagement failed but instead having too high expectations of this radar. It is a bit difficult for me to give you concrete feedback when you just say that he can't lock your bad guys without providing some details, a mission or working track file, while Jester seems to lock bandits well for many other players. What I can tell you from debugging this type of feedback so far is that it is most of the time people not understanding the limitations of this radar good enough, expecting something from Jester that a human WSO couldnt do either (which is fair btw, we are all here to learn and improve). And if it was Jesters fault, it was usually him not having the right gain setting in a situation where the right gain is very tricky - which is being worked on.

You don't and that's also not expected from you.

He doesnt yet hear AWACS calls, but that is being worked on. Try acquiring the head-on lock yourself, you will likely have trouble doing it as well and conclude it is mostly just the radar and not necessarily Jester using it incorrectly. His shortcomings in that regard currently are not experimenting with the gain setting enough, which is also being worked on. You can help us by sending in working tracks of situations where he wasnt able to spot the target, but you were (by operating the radar yourself). Aspect and Vc settings have no influence on the radar, those are manual overrides. What plays a role here, aside from the pilot positioning the aircraft proper, is the correct antenna angle and gain setting. And even then, a head-on small target will be very hard to spot until perhaps 15-20nm out in good conditions. Thats just how this radar works. Please make sure you have a solid understanding of how to operate the radar in order to ensure your Jester complains are valid. If unsure, just hand in tracks :) Cheers

Are you talking about boresight locks or in normal scan? For latter, its almost instant after you command lock (provided he sees the return), you do not have to wait for him to finish his talking. For boresight, he waits until the target is within the 5° cone, else the chances of a bad lock are far too high. This is a frequent mistake I see on human WSOs. Not sure what you mean with the cursor being stuck. As soon as the target is within range, it should start moving on its own. No need to exit/reenter. Otherwise, a working track would be very much appreciated :)