Stickler Posted Monday at 05:51 PM Posted Monday at 05:51 PM Standard RL procedure is to switch fighter radars off prior to commencing AAR. As shown in the attached track, after being commanded to set the radar to standby, Jester will automatically switch the radar back on after AAR is complete. The actual trigger seems to be the closing of the AAR door. This has the unwanted side effect of Jester switching the radar back on when recycling the AAR door after unintentionally having fallen off the boom. I recommend to disable this Jester behaviour. Note that manually setting the radar power switch to standby instead of giving Jester the appropriate command yields the same result. aar_rdr.trk 3
Zabuzard Posted Monday at 06:11 PM Posted Monday at 06:11 PM 18 minutes ago, Stickler said: The actual trigger seems to be the closing of the AAR door. This is WIP. It is because currently this is the best way for him to understand that you are doing AAR. The condition should be refined so it wraps the process better, but its important that its specific enough to not trigger when you are for example just escorting a tanker or waiting for your buddies to be refueled. Not that simple, so the AAR door has been picked as intermediate condition for the time being. 1
Volator Posted Tuesday at 06:00 AM Posted Tuesday at 06:00 AM (edited) Same thing happens after a touch and go. Can't you just tell Jester to leave radar off until further notice after he gets the command "radar off!"? (Same issue applies to countermeasures dispensers btw) Edited Tuesday at 06:49 AM by Volator 1 1./JG71 "Richthofen" - Seven Eleven
Zabuzard Posted Tuesday at 06:08 AM Posted Tuesday at 06:08 AM (edited) Something like that is planned. Its not that trivial though. From a UX perspective it is better to approach this stuff from the use cases and less from a "let me control the switches in the backpit". Some things, like the AAR and landing stuff should be fully automatic by Jester, you should not have to tell him to switch radar off or anything - so the solution for that will consist of improving the automatic behavior. Other than that there will be situations in which you want to shutdown all emitting equipment, i.e. a "go silent" option that does not only turn the radar off but also jammer and similar. The existing option in the wheel just switches the knob, there is no persistence applied to Jester that lets him remember your choice - so he will switch the radar on again whenever his logic decides its time to turn it on again. Making your choice permanent isnt ideal either. 10 minutes later you are jumped by a Mig and complain that Jester isnt smart enough to figure out that its time to put the radar on again without you explicitly telling him. This stuff needs to be approached in a proper and more modern way that resembles the real cockpit interaction between pilot and WSO better than you trying to control both pits at the same time Edited Tuesday at 06:14 AM by Zabuzard 1
Dragon1-1 Posted Wednesday at 09:43 PM Posted Wednesday at 09:43 PM It doesn't change the fact that you can very much tell your WSO "keep the radar off until I tell you otherwise". Do not get hung up on "modern" design so much that you take control away from the player. Jester is not human and never will be, so manual overrides are absolutely needed. No matter how smart you think you can make him, you simply won't be able to make him actually think. Always remember, your code can be buggy, your design philosophy can be wrong, and no developer's intent survives the first contact with the userbase. Even aside from that, there will always be ACs out there (and no doubt have been IRL) who will want to tell their backseater "you're back there to flip switches, not to think". While real examples were probably not the most popular people at the squadron, so to speak, given Jester's limitation as an algorithm, this is a valid way to play that should be accommodated. 2
Recommended Posts