Q: What variants will the Heatblur F-4 Phantom include?
A: The first release will be DCS: F-4E, the iconic land based variant of the Phantom. We will be launching two variants of the -E; a “classic era” F-4E (blocks 36-45 with updates retrofitted in 1974 and before, including new slats, DSCG and AGM-65) as well as an upgraded (DMAS) version of the aircraft in one package.

Q: Will there be a Navy F-4?
A: Yes! Our Phantom journey only begins with the -E. However, owing to the complexity of the work and investment of time and effort, it will not be included in the DCS: F-4E product. We’re instead choosing to focus on providing the most content rich F-4E we possibly can, and then set our sights on further telling the legendary story of the F-4.

Welcome to an episode focused on navigating the F-4E Phantom! It's far more complex than you may think; and navigating correctly will be a true challenge. Make sure to read the Navigation sections in the online manual for more information:
https://f4.manual...rview.html

As we continue to push on all fronts in the runup to release, we'll be sharing more frequent small snippets of work and technologies created for the F-4E and future aircraft. This time around lets talk a little about JESTER;

Jester APQ-120 Vision Algorithm
A really challenging part of building JESTER for the Phantom, has been the way that he uses and interfaces with the radar. The APQ-120 is an old, pulse only radar, and utilizing it in a complicated environment is a true challenge as you have to, well, interpret the smudges.

We wanted JESTER to be as authentic in this respect as possible, and just as we have a vision algorithm for jester's eyeballs for anything going on outside of the cockpit, so too do we wish to simulate how he sees and interprets the radar screen.

Using convolutions of the radar scope, we've come up with a way to fairly accurately and authentically recreate what a real WSO could understand from a given radar image. Jester will not "cheat" and see contacts through clutter or other radar returns, but rather, will interpret the radar screen using a mathematical model.
We've tried to tune this as accurately to what a real human would be able to see as possible. Here's a few images of the radar and what JESTER sees as valid contacts:

Jester Swimlanes - Or Hands, Eyeballs and Voice
We've also just in the last couple of days introduced more advancements to JESTER. We had hoped we could get away with a single action-queue for JESTER for all things related to his actions: i.e. speaking, flipping switches or looking somewhere. Unfortunately, we noticed a "slowdown" in JESTER once all of his functionality started slotting into place, necessitating the need of adding what can be dubbed as "Swimlanes".

Swimlanes are a sort of coroutine/multitasking system, split across the natural elements of a human: Hands, eyes, and voice. Each can independently execute tasks, like a real human. I.e., look at something, say something, or manipulate sometihng. This way we have naturally split JESTER's ability to do things in a more natural way, and thus not inhibiting cockpit manipulation while speaking, and vice versa.

In addition, we've also introduced a barrier system to complement the swimlanes.
This acts like sort of a synchronization point which can synchronize two or more swimlanes where necessary. Very useful in a situation JESTER should specifically execute actions in a specific order, even if that sense or appendage is otherwise free. Think for example of a situation where JESTER flips a switch and then confirms that he has flipped it.

With the swimlanes in place, we've now unblocked the task blocking and queuing issues we've been running into, yielding a more natural and responsive JESTER. 🙂

Check out the simple and quick diagram below; and also an example of how the swimlanes are used in the API: