Zabuzard

Yeah, also works for me. Looks like user error with your procedure. I would suggest following the procedure described in our manual step by step and if it doesnt work still, you can provide a track file or video or just write down a list of your steps so others can check what you might be missing

You would need to properly put out the fire. I am not aware of a way to trigger this magically. Fire goes out when you repair the aircraft (maybe this can be triggered?) or fly fast enough for some time (practice testing: around 10-15s at 0.8 - 1.0 mach). Depends on a lot of conditions of course. Shutting the engine down will not help a lot because once there is a fire it will burn through the engine and set other parts on fire as well. It does not need the fuel to continue burning. It can help in the early stages of some fires when you only got an OVERHEAT but no FIRE lamp and potentially also only see smoke instead of fire coming out of the engines.

What exactly do you mean by "blocks"? You cant select the weapons anymore or they dont appear visually? If latter, only in the mission editor preview or also in-game? The mission-editor preview is fully ED controlled and hence sometimes differs from what it will actually look like in-game. If it works in-game, it would likely be sth for ED to look into.

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?