Zabuzard

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

correct

no update

He starts the warmup phase, not the actual alignment. This is the correct procedure.

Yes to all you said. With our condition/wear/tear system you have to get away from an on/off thinking. Your hydraulic system consists of like 100 components and all of them have properties that are influenced up and down. There is no "now the system works, now it doesn't". The result is a highly dynamic composition of everything together. I would also take battle damage aside as extra topic, as this can fail things as well. Sometimes as on/off, sometimes as 0-100%. It is extra, next to the other systems. Battle damage can also apply to all components in the entire aircraft based on their location. The failure list in the ME (and what random failures applies to) is a handcrafted list of manual failures that we put in "on top" of the condition/wear/tear and combat damage systems.

The random failure option covers the failures listed in the Mission Editor only. It is an ED system that we do not control. We can add new entries to the list of failures but thats it. The aircraft itself, with its condition/wear/tear system has way more "failures" than just those, although I wouldn't really call those failures. It also wouldn't be meaningful to add them all to this list, as its around 3000 individual things that all influence each other. And its not just on/off, but varying between ranges of values. The condition/wear/tear system isn't compatible with the ED failure system. Not only technically, but also UI-wise. It wouldnt be meaningful. Instead, you control that aspect with the condition/wear/tear sliders in your Mission Editor and with how you fly in-game. There will likely be more detailed options inthe future when we come to making it persistent for campaigns and similar.

Tracks dont work with the HB UI yet (unless all interactions are done only through keyboard commands). So a video would be needed here, unless you also give us a screenshot of what to enter into the bombing table for ur track to work while it replays :)

Im occasionally hearing similar stuff but no one got it on a proper working track yet sadly. We haven't been able to find the source after a few blind investigations.