Zabuzard

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.

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?)