Zabuzard

Thanks for your investigations and tracks The Aspect Switch is only relevant if you launch Sparrows without a radar lock. Jester learns in the upcoming update how to do that. He will offer the use of (regular) BORESIGHT mode and will offer changing the target aspect for a no-lock shot via the Context Commands (also in CAGE/BORESIGHT mode). The manual has details on this already https://f4.manuals.heatblur.se/jester/combat/radar.html#dogfight

I cant comment on it, sorry. You will get news when there is news. Cheers

So first of, thank you for the tracks! What I am seeing on my screen looks all normal and correct to me. I will go through all the tracks and explain whats going on. If something different happened to you when you played it, we have to investigate why (perhaps you have the radar performance special options enabled?). In case my description lines up with your experience, I suspect the issue might just be misunderstanding of how to control Jester, i.e. when to use which Context Command. For that, I would suggest having a quick read of: https://f4.manuals.heatblur.se/jester/combat/overview.html https://f4.manuals.heatblur.se/jester/combat/radar.html And practice until it clicks Here we go. Track 1: * Jester detects both bad guys at 21nm by himself, which is very reasonable for this radar and a small fighter aircraft coming at nose-aspect * at 10nm and 4nm you command Jester to switch the targets (SHORT press), you are not commanding him to lock (LONG press) Track 2: * This time you approach them with a slight angle, RCS increases and Jester can spot them at 25nm already and would be ready for a lock * Jester is ready for a lock the entire time but you never give him the command. Track 3: * Again, approach from the side yields higher RCS, spotting and ready for lock at 25nm * You are flying pretty much at the sideways limit of the radar though, so he loses sight at 20nm * Then you are turning into them and they appear back on the screen at 17nm * at 4nm (very late) you are giving the command to lock * at 3nm Jester obtained a solid lock * with the bandit at 1nm you are entering a hard turn with the target on the gimbal limit while it is deploying chaff. that broke the radar lock and Jester returns to scan mode * you command him now to LOCK the target he just lost out of sight, so he is waiting a few seconds for it to re-appear on screen, which it never does * instead, you probably intended to command him to lock the other guy, i.e. first tell Jester to switch targets (SHORT), then lock (LONG). Watch where his cursor is to tell who you are commanding to lock, it is still on where he lost the previous guy, not the other guy * Also, at ranges below 5nm you should consider switching to CAGE/BORESIGHT mode instead to enable Jester to "lock the target on your nose" instead, much easier to use in a Dogfight. Track 4: * Similar attack profile, targets spotted at 23nm * Command to lock at 4nm, at the same time you are executing a hard maneuver, so Jester fails to lead the target correctly with the cursor (as the proper position would be outside of screen bounds), you moved the target out of screen, Jester lost it and gave up on the lock attempt Track 5: * targets spotted and ready to lock at 23nm * no lock command or anything given, you guys merge and overshoot while Jester was ready to lock the entire time

Really odd. Was it also circling for the WSO, or just on your Pilot Screen? Was the WSO having really bad FPS perhaps? With a human WSO, these things are all computed on the WSOs machine and then synced to the Pilot for his display. If Jester can not run his routine fast enough then such overshooting could occur. We are talking about slide-show FPS here though, not just 30 FPS.

Yeah agreed. There is a section that explains Jester features: https://f4.manuals.heatblur.se/jester/combat/overview.html But overall the manual lacks "tutorials" and generally some "hands on" guides. As in, not just explaining what each switch does, but also explaining how that should be used all together. The manual isnt really an ideal place to teach these things and we hope to cover those aspects better with in-game trainings and YT videos and then perhaps embed/link that in the manual. That said, if someone submits a PR to the (open source) manual that adds a written "guide", would definitely appreciate and merge it

I am not sure I follow. The option to force-activate Jester while a human WSO is in the plane is meant to be used for WSOs to sit by and watch while Jester does the job. You are not supposed to control the WSO pit actively while Jester is turned on. Deactivate him if you want to control the backpit directly

(duplicate thread, see the other one)

Ive checked the update logs, the bugfix is in the upcoming update. Currently you need the left engine running for the door to work :)

Are you possibly on an older version? There was a bug with the hydraulics that got fixed. Perhaps its also not in the current version yet, I have to doublecheck. (If your version still has the bug, then you simply need to ensure your left engine is running, as well as having power on the aircraft).

Thats actually fairly "normal" behavior when replaying tracks, since DCS constantly teleports your plane back to the exact position it had during the real session. So you see how the simulation moves the aircraft to a slightly different position than what it was originally, which is then getting "corrected back", causing the jitter. Happens especially whenever you update DCS and replay old tracks, but can also happen directly after recording in some situations. This can essentially be seen on pretty much all aircraft in the game.

There is a plan to port the Tomcat manual to the format used by the Phantom, so that it can also be embedded in-game when we backport the new UI system. That would then likely also include the dark mode. Cant comment on when yet though. For surfing the manual in a browser, you might be interested in addons like Dark Reader which can turn any website into a dark-mode site dynamically

I see, that explains the usage of the Context Command Kinda odd, but that might also be good news then. I am replaying the track on the latest developer version, so possibly whatever was the issue might be gone with the next update then. I dont recall anyone touching anything in that direction, but you never know

Do you happen to have "random failures" activated in your mission? If you have, depending on what you checked, something like that can happen after a certain time without any other influence (thats how DCSs random failure system works). Other than that, it must have been collision-based. So combat damage or collision with something. There is also G-based stuff, but that would read "Stress Damage", not specifically "Hit Damage", as you mentioned. Similar for wear/tear and other stuff, its not "Hit Damage". That said, its also possible that you "collided" with an explosion caused by your engines, in case they caught fire for too long and you did not put it out. Depends on the order of events, I would say. Explosion after catching fire usually occurs somewhere between one and ten minutes, depending on a lot of factors. Engine Fire would be hit-based as well though (or "random failures" or "bird strike" DCS options) (while wear/tear can lower thresholds).

That would need DCS built-in engine support first and to not look bad also needs Inverse Kinematics first :0

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.