Zabuzard

What I drew on the pic are +-10°. As explained, Jester operates more in the range of +-3 to 4°. So something like:

Right, that is mostly because an elevation angle of 3° already changes the covered altitude by 10k ft (at a distance of 30 NM). So you cover the entire relevant airspace by moving the angle around below 10° already, while the grid on the side goes up to 60° in both directions. So relevant angle changes will be very small on the scale only: Jesters uninformed general scan pattern moves in a sophisticated way between -10k ft, -2k ft, 0 ft, +2k ft and +10k ft relative altitude (for a distance of 30nm). So you will get angle changes of around 4° in both directions maximum. To focus on a specific altitude, you can use the Jester Wheel.

Do you possibly have a track that reproduces the issue when replayed? AI behavior is totally up to ED, we do not control it. Ideally you post it somewhere on their forum section. A track would help them a lot

Yes, this is expected behavior given his current implementation. You need to disable him first if you want to mess with that stuff in particular (Wheel > Presence > Disable, can also be bound to a key directly). Once the vision for Jester fully unfolds and everything is in place, these things should not be a problem anymore Are you sure about the elevation though? In all user supplied tracks ive seen on the topic so far, the elevation was usually good and did cover the airspace with the bandit in (he runs a sophisticated default scan pattern that touches pretty much the entire airspace ahead). The problem leading to not spotting the bandit on the screen is usually the gain, not the elevation. Either case, as a default uninformed scan behavior I think its quite good already. It just lacks, as explained earlier, an extra mode where he actively tries to uncover a target in a known area.

Jester is WIP and will of course be improved over time still. It is not intended for your as pilot to babysit him though. On a technical level, adding the possibility to micromanage him is as difficult as just teaching him to be a better WSO, so we prefer doing that instead. On the note of nutation/MAP mode, Jester is currently doing what the real WSOs did in the Phantom. Nutation and other modes did not work well on this old radar, they did not use it. Some excerpts: > Forget 2 bar nutating feedhorn - search in MAP-B 1 bar, which cuts beam down to 3.7 degrees or so. Then when you get a contact, you adjust the elevation to give the best hit. > RDR uses a nutating feed horn that gives a bigger radar beam but it's less strong. > We hated 2-bar. As a WSO I'm running the elevation all the time, and don't want it jumping down when I want to go up! > -34 recommends using MAP-B for search due to better target discrimination and less wear on the nutating feed horn. > The best radar setting for air to air contacts is MAP - B. That has a tight 1 bar non-nutating scan that is better at discriminating targets from clutter. From my experience with Jester, he is pretty good at managing the antenna elevation already. It is the gain, as you also pointed out, that needs improvement. But finding the right gain requires multiple attempts, waiting multiple radar sweeps each time. If Jester would do that constantly, his general search pattern would be way too long/slow to be useful. Instead, Jester needs an extra phase after "general search" where he will actively try to find a bandit in a known area. In such a phase he could then also spend more time playing with the gain. But therefore, as first step Jester needs to learn more about possible target locations. That is, he for example needs to understand AWACs calls, RWR contacts, mission specific data etc so he knows by himself where targets are. On top, we will add a dynamic way for the player to point somewhere "find target here" (for example pointing on your radar screen or outside the canopy into the air). With that stuff added, Jester can then switch from a general non-informed scan (which he is doing currently) to a more active informed target-uncover phase in which he plays the gain up and down. Once that stuff is added, the experience should be a lot better. In the meantime you can theoretically bind a few switches from the WSO seat as pilot and try messing around with Jesters pit. Some things he will tolerate, others he will reset every now and then. But he probably wont understand whats happening and you could potentially confuse him a lot. Alternatively, turn him off, then obtain a lock yourself and then turn Jester on again - he was coded to understand this scenario and roll with the player-obtained-lock during his absence.

Correct, it has not been implemented yet. Cheers

Thanks for the engagement, suggesting ways to approach it. Dont worry though, the team will have a look and get the experience back to what it is supposed to be [emoji846] The track is helpful, now its time to wait for a dev to fix it [emoji106]

It wont stay hidden. The central place will be the repo. Hopefully soon, fingers crossed.

Could you possibly supply a short track that reproduces the issue for you? That would be a great help, thanks :)

AI wingmen or player? If latter, are their own lights visible for them locally? And I guess yours arent visible for them then? Or do you mean pilot to wso, like visible to pilot but not to wso?

This is a known and already reported issue. The team is investigating already, cheers. Afaik they do lock though, just no tone.

Important updates are usually cross-posted on all official HB channels (this forum, Discord, Facebook, Instagram, ...). Discord is best for when you want to connect with the Devs or the community fast and quick. Most of us have it open on the second monitor or on the phone the entire day and can react immediately. While the forum is more something like "checking your mails" once a day or so. There was no extra communication for this patch because what has been stated before still holds. If you do not see a changelog from HB, it means there is nothing from HB. That of course does not mean things are standing still, quite the contrary actually. There are some bigger changes that require a more extensive testing phase and that has not finished yet. In the meantime the team is of course pushing out more and more changes

What the others said is correct. Unfortunately, the in-game experience with what the tanker tells you is misleading. After an accidental disconnect the tanker is not allowed to connect to you before you cycled your door (restarts the AAR system). This is mandatory to do in The F-4 (IRL as well, ofc) before it can receive fuel again. The tanker in DCS doesnt yet understand this special situation and will gladly put the boom in again - just to immediately receive a message from our code that he must not do this. The tankers reaction to that code-wise currently seems to be to disconnect and conclude you are fully refueled and happy. ED is aware and looking for a solution to improve the user experience.

I believe what they wanted to say is that for a non-expert its generally better UX to have the aircraft shown as primary text and the radar name as secondary info than the other way around. Looking at it less from a challenge/practice perspective and more from a usability POV :)

Yes, it is modelled. The electric system is simulated down to volts, watts and individual wires. This is also why Jester specifically waits and asks if you are done with moving the generator switches around before he starts the INS alignment. A more indepth look (but still an approximation) will be available with the next Phantom build that features the EFB (more specifically its Electrics page) - details in the manual. Cheers

The recent update broke something on DCS engine side. This is a known (and already reported) issue, the team is investigating. Cheers

That is correct though. Btw, make sure to eliminate paralax by putting your head above it in the right angle and distance. The paralax on this one is kinda big bc the screen is quite deep in behind the glass actually. Like an entire arm length deep.

(Careful with active pause. In many cases people use it in a way that gives totally incorrect results because the aircraft isnt unloaded first. The pipper needs to be stabilized naturally on the target, no G load or heavy stick movement, else the AoA is all over during active pause.)

Thanks for the details. Try with the aircraft weight set to 0. Afaik in Laydown the sight is horizon stabilized (by the INS) and hence the AoA correction isnt needed. This is an already reported oversight, cheers.

Usually when that happens people either do something wrong (see the manual for details on the checks) or for example dont actually neutralize their input fully (sometimes hardware also keeps sending small inputs, mini deadzones help here).

(Note that the site has to actively have their radar pointed at you. Just a bit off, tracking someone else or interrupting the radar, switching to visual tracking or other techniques and your missile wont see it anymore)

This topic is in progress. There is another thread somewhere here with details on it and the WIP state including instructions to get it working in that WIP state. Cheers /topic/349847-exporting-screens/#entry5668772

We typically write in the thread and callback when something got fixed

Hey there. The F-4E includes the DSCG variant and the DMAS variant (which is to follow still). Generally HB plans to work on a Naval F4 in the future as well. Its not more than a thought at the current stage though, which version is also undecided. Details in the FAQ, cheers.

Yeah, thanks. Great. It was more a general comment. People often dont know that they can test tracks and then send something in that doesnt work when replayed ingame.