Zabuzard

We have seen the report and it was added to the list [emoji106]

Care to elaborate? I am pretty confident that the majority of users would claim the exact opposite to what you just stated. Very unfortunate if you think this way and if you provide some details I would be happy to clarify :) That said, if you want to critize the module perhaps make your own thread instead of going off-topic in OPs thread, cheers.

Yes

The trimming behavior is implemented correct with respect to real life behavior of the aircraft. You gotta do very short taps, it was known to be wonky. The response by aircrew usually was to "just fly the aircraft". That said, there is a Special Setting available to counter this especially for people who have hardware that physically cannot send super short impulses. Like, for some joystick even if u you click something only for a very short amount of time, the actual impulse send by the hardware to the system is much longer. I believe it was this setting: https://f4.manuals.heatblur.se/dcs/special_options.html#stick-neutral-position-smoothing-period (Trimming in the F-4 acts as a modifier of the lever that the bellows use to pull the stick aft as opposing force to the bobweights who push the stick forward, and is hence heavily dynamic and dependent on factors like speed and G)

(the AI, in contrast to the player controlled module, is not slated after the EF and will come whenever its done - it is being worked on)

You might want to checkout: https://github.com/Munkwolf/dcs-community-keybinds If they are present in this mod, it will end up on the F-14 as well as soon as we come around to integrate the mod like we did for the Viggen already, cheers.

When there is some actual big news, we usually share it on all our channels (Discord, this forum, Facebook, Instagram, ...). Those are just general newsletters called "dev-shoutouts" and is mostly intended for people who want to follow HB a bit closer and stay in touch with the devs - which is what Discord is generally used for. Until then everything you may read essentially boils down to "we are working on it, its there when its there".

We currently cant provide ETAs, sorry. But its ofc coming out eventually :)

That negativity wont get you the fix sooner either. The team and ED are working hard on it already. As explained in the other thread on the topic, something ED did in the last update broke it and it seems not so easy to get it back working. Some other aircraft and weapons are apparently affected as well.

Yeah, so the first one is definitely him still being in FOCUS mode. I suppose he did not understand that this particular bandit died. The "bandit is down" callout isnt coming from his radar code but is a visual observation. So his radar logic likely thought that the bandit could still be there, keeping it focused to get it back on screen. You can just get him back to standard scan by using the context actions - autofocus only happens on targets actually on the screen, so he will not focus thin air. The second one, not sure whats going on there specifically. Possibly he did not understand that you left CAGE mode yourself instead of using the context actions. You can enable the Jester Console (RCTRL+L) to get some insights into what he is doing. I would also suggest to hit context action to get him back to standard scan. Note that you can have Jester leave CAGE mode for you by using the Context Action as well - no need to rotate that knob yourself (potentially losing the target visually doing that). If you can reproduce this a track would be great, then we can have a deeper look. Cheers

Just to make sure, while this might be your personal estimation, such a statement has not been made by any official sources. There is no correlation betwen the two modules in any way. I cant speak for ED and their F-35, but the EF releases when its done as simple as that

I can check them tomorrow, thanks. But what you are describing sounds like focus mode and not general target search. You can use context action double click to leave that (and possibly disable autofocus).

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.