Zabuzard

Jester Wheel, Crew Contract, Silence or something like that

Ah, you mean the in-cockpit labeling of the switches/knobs. Fair, I misunderstood you.

Could you point those out so that we (or the community, since the manual is open-source) can fix it? Thanks.

The Crew Chief talks to you through headphones connected in-parallel to the WSO audio channel. Meaning that your plane must have power, your intercom must be activated, the WSO must be on hot-mic and shut up to not block the channel. Otherwise no one will be able to hear the Crew Chief talking. When that is the case, the Crew Chief will instead communicate through Hand Signals to you (which you cant see because there is no representation of the guy walking around (yet)). You also notice that by the name of the Crew Chief menu in the Jester Wheel, which says "Crew Chief (Hand Signals)".

The alignment part has a bug that was fixed for the next update. Id suggest to recheck when it drops, cheers.

It isnt more effective. Its ultimately a personal preference. Roll STAB fights your roll input to some degree with opposite artificial input in order to cancel out unwanted roll and stabilize the plane. This can feel like something is getting in your way when you want full and direct control. Overall its fairly minor though and its authority is quite small. Some prefer it on, some off. Both choices are fine :)

Are you running DCS on a SSD? These spikes are usually caused by heavily increased IO traffic due to the map-data calls made by the DCS engine to answer the radar rays. There isnt too much we can do on our side to get rid of the issue, but we are planning to shift the moment to shortly after takeoff by delaying Jester turning on the radar, so that the timing isnt that critical anymore.

Yeah, everyone has until the fix is shipped with the next update

I dont recall what exactly he says without checking in-game right now, but what he says is taken exactly from our real-life F-4E WSOs. Super exact and precise brevity wasnt that common at that time in these situations yet. (Not that I want to get into this discussion now, perhaps a topic for a different thread if you want to challenge that claim )

Checked the track, can confirm no vertical lines for me. So yeah, you are running into that one bug regarding the lines. The locks you got are bad locks because your positioning is less than ideal for this radar. It is easy to notice by the steering dot moving like crazy and the VC readout jumping around. You are in a co-alt to slight look-down attitude and go for a direct head-on with a Mig-21 that has a very small RCS from that angle and the distance to the Migs is similar to the distance to a lot of ground in front of you, giving you a lot of clutter. When you spot a bad lock and cant change your positioning, make sure to tell Jester to retry the lock (context action LONG twice). After one or two retries you might get a solid lock. Although at that point you are probably already merged. Either case, I do not see anything Jester could have done better here over a human WSO. Besides identifying the sidelobe locks and retrying on his own instead of waiting for your command to do so (which is in development). Lock quality is pilot duty, the WSO just has to put the cursor over the return and hit trigger.

This is the moment you disconnected at 6min into the track: The second disconnect happened at 6:39 into the track and while the lights are all green, the operator disconnected you because you were charging the boom too fast. Like, your approach rate was too high for the boom operator to keep up. The third disconnect at 6:56 has red lamp again, too high up: Next disconnect at 7:36 was falling off the boom, also red light: Disconnect at 8:21 had green lights but you fell off the boom too fast for the operator to keep up. Ill stop here, cause I think I get the point. First of all, thanks for the track! I guess we can ignore the disconnects where the lamps were red, those should be clear. For the other cases, what I think happens is that your movement is too fast for the DCS operator to keep up with. If you think this is unrealistic you have to forward this to ED, as the boom movement and the disconnects are totally out of our control. Watching the track I kinda understand what you mean when you think Jester reports nonsense. For this you have to understand that Jester refers to the ideal spot to be in. That is, the center position where you have the most room for error to all sides. He doesnt just want to give you a donut on the boom, but also navigate you to that perfect spot. So its possible that he might tell you to move down and forward even though your boom is perhaps already charged to its max because you are currently way too high. So moving down would relax that and then you would have to move forward again for the sweetspot etc.

Actually, Jester sends an appropriate instruction within milliseconds. The "delay" you feel is due to the length of the sentence itself. Like, lets say he decides to say "Move 5 feet forward". When he starts speaking this, your position is incorrect by exactly 5 feet. But by the time he finished speaking the full sentence you might have drifted elsewhere already, since the sentence takes about 3 seconds to say. There isnt too much we can do about this, you would have a similar experience with a real human. Something we are looking into is to evaluate individual parts of the sentence at runtime. Meaning that for example the number "5" here could change up until the moment he said "Move" instead of being determined before having said "Move". So that would give the number another 0.5s extra accuracy. The "problem" feels more real for people who are not used to AAR yet. If you ask one of the SMEs they tend to fly so precise (because that is what they did/do for years profesionally) that what Jester says is still super accurate by the time he finished talking.

Ah okay, then you are running into a rare but known bug. Cheers

Could it be that you perhaps accidentally hit the disconnect button on the stick or cycle the aar door? ive seen people who bound that somewhere and forgot. As far as Boom movements go, we dont control any of that ourselves. So if there's a bug, it would likely be a topic for ED. Cheers

Ill have a look at ur track on Monday :) The effect seen in ur video is that of a jamming target. Something or someone must be jamming - or its a bug. Probably easy to tell with the track, so thanks for that [emoji106]

It looks like ur getting jammed. This is a fairly early radar and jamming kicks it hard. There isnt too much a WSO can do in this situation. The locks are clearly bad locks. Which Jester will also realize by himself in a future update.

Unless you see it mentioned in the changelog it hasnt been fixed yet

Yes, afaik it got fixed today. Gotta wait for the next update

Has been fixed yesterday for the next patch :) In the meantime, move the instrument backlighting brightness knob up.

Thanks for the video! It looks like your LASER READY button was already pushed in and you just clicked it again so it was disabled, immediately failing the BIT with a MALF indication. During the test, the LASER READY lamp itself will not be lit, in case you were looking for that (since the circuit for that is still guarded by the nosewheel being out). Also, you need to make sure to wait until the pod arrived at the special test position, indicated by the GO light. Enabling the video feed and the pilot checking the AZ-EL indicator for the red flag can also help with that part. Ive recorded it quickly for reference:

A 1nm deviation after 4min of flight, potentially with some maneuvring, seems generally uncommon but still within limits. Is it sth that happens again if you retry the mission?

Yeah. Also cant view it unfortunately. The Phantom, if aligned fully, has a general drift characteristic of 3nm CEP/h. Not sure how long you have been flying already when you reached that point or if you perhaps pulled some hard turns and Gs which would increase the drift etc, but its very possible that this is just within limits and normal behavior. Also sth you might want to check are your sliders for Aircraft Condition and Wear/Tear in the Mission Editor. Make sure that every flight plan includes NAV FIX points.

It is implemented. All Pave Spike BITs are. Details here: https://f4.manuals.heatblur.se/systems/weapon_systems/pave_spike/other.html#bit-3 That said, BIT 3 specifically was bugged and fixed at 5th July. Which was delivery with a DCS update on the 9th August. Make sure you have unstowed the pod, entered a valid laser code (and hit the NO-GO button-lamp to "enter" the code - make sure NO-GO does not remain lit). Then make sure you push the LASER READY button in. Once you are done with the preperation you can enter BIT 3 and start the procedure.

Could you elaborate on what exactly you are referring to, I dont full, follow. I can assure you that we are not ignoring anything, whether we comment on it or not. We read the forum and other places. The stick topic itself spans across multiple threads and gr0ver has given some insights in other threads here and there already as well.

The update didn't touch anything on this. If you genuinely think you found a bug or run into a situation you think Jester should have behaved better, please send us a (working) track so we can improve it. The radar is complex, old and the pilot also plays a huge role in it. It is hard to say without seeing whats going on if a human WSO would have performed better than Jester. Cheers