Noctrach

The blinking happens 8 seconds before Ropt and that in itself isn't anywhere near Rtr. I believe it's defined as the distance that a lofted shot will intercept a head-on target with enough energy to do terminal manoeuvring. Note that this implies something like a high-G jink defence at terminal stage by an otherwise straight-flying target. Any manoeuvres prior to this point, or the target simply turning around and running will drastically lower Pk. In "the other sim" Ropt is something like 85% of the missiles maximum aerodynamic range. In all cases it's still a pretty low Pk shot on any aware, manoeuvring target. Considering the Phoenix can intercept non-manoeuvring targets at well over 70 miles, blinking at 50 miles seems very reasonable. If a launch doesn't activate the countdown on the AWG-9 and/or the missile doesn't track, either something was done to spoil the shot (loss of contact, too far off boresight, etc) or you have a bug you can report.

In principle I like this direction, but isn't it little bit too much wishful thinking? The problems I encounter using Jester revolve squarely around those aspects that you'd normally be talking about with your human RIO: target sorting in complex environments. Hence the focus on two items: Next target functionality Ability to "micro-manage" scan granularity. Imagine the following scenarios: Multiple bogeys but limited, scattered bandits. Multiple bandits of different type (two-ship MiG-31 at 50k for 50 but singleton F-5 at 40k for 30) Two-ship of solo F-14 pilots trying to sort any 2vX encounter. Jester would need a significant level of heuristic decisionmaking to correctly identify what's expected. In these cases there would not even be any other option than going STT and severely diminishing situational awareness. Hence, Next Target would solve all three of these. Managing this through narrowing the scan width and bars would at least help you isolate to make Jester's decision-making significantly less complex (and therefore less error-prone, as well as easier to implement?). I don't see this being fixed any other way, because not even a human RIO would be able to infer what do to in these situations without having a pre-briefed gameplan or some in-flight chatter. Conversely, once a human is briefed on the ROE and threat environment, these scenarios become extremely trivial. While I agree that the RIO drives the intercept and the pilot flies the intercept, Jester cannot be briefed on any situation that slightly deviates from the norm, so he'll need a little help from us.

Yeap, a lot of players also simply don't know how the backseater position works even in basic form. The act of interpreting a readout on the DDD (your main instrument) already contains enough intricacies to dedicate an entire machine learning project to. Capturing this in Jester is entirely unreasonable. At the end of the day, no matter how sophisticated he is, Jester isn't a RIO. He's a smart interface providing us access to a selection of backseat functionality. He's pretty good at that. However, right now he is unnecessarily increasing single pilot workload in combat. While I'd love to add a billion other elements to this enhancement request, the core of it is simply to provide quick access to the tools most critical for target discrimination in combat. In my mind there's only three things important to attain this goal: The ability to designate a TWS track for next launch Maximize control over radar elevation, azimuth and scan volume parameters Do the above with as few interactions as possible Even in this list I only consider TWS designation and antenna elevation to truly be problems that need to be solved for release. Anything else I'd consider a bonus.

"Sorry lads, the airborne invasion of our proud nation will proceed unopposed. We're all grounded due to an unfortunately dense cloud cover this afternoon." "But sir, we have TACAN and perfectly capable radars!" "Don't talk back to me Timmy. You know we only installed those as counterweight."

I recently added a forum suggestion for this as well. Absolutely agree with your suggestion

Is this intended behaviour? As the behaviour as described would be: So this would lead me to believe correct behaviour would be: ACM cover up and PD-STT and angle <15deg: LTE 1s, no loft, active immediately ACM cover up and PD-STT and angle >15deg: LTE 3s, no loft, active immediately I have tested both of these scenarios and neither of these cases are true right now. LTE is never changed in PD-STT. ACM doesn't affect active state Phoenix only goes active in P-STT or BRSIT or launched <10nmi (trigger pressed at 9.9 nmi: active, 10.1 nmi: never active) As a side note: ACM cover up with no track automatically puts missile mode in BRSIT with Phoenix selected. So there's only really 3 scenarios... PSTT, BRSIT and PDSTT with ACM up Also to quote @Naquaii, the following is the actual behaviour in the sim, with the exception of the ACM cover, which currently does not affect the shot

As per title. Putting ACM cover to UP while having a contact on the nose locked in PD-STT: Will not affect LTE (still 3 seconds) Will not set Phoenix active upon launch Interestingly, Phoenixes launched at <10 nmi will guide ARH. Launched beyond that range will guide pure SARH and go stupid when lock is broken. Manually selecting BRSIT works fine, missiles pick up contatcs well over 10 miles.

Scenario: 2-ship of MiG-29s flying steady at 0.6 miles separation AWG-9 resolves both tracks at 40 miles in TWS-A Missiles launched at 30 miles, both tracks solid Light crank towards the trailing MiG (increases separation of contacts), dive to +4 degrees lookup Second MiG increases separation further by doing a light crank away from the formation AWG-9 starts tossing out broken tracks for the separating MiG, track of first MiG remains steady. Missile on separating MiG goes stupid, simultaneously secondary missile pulls to level 1G flights (no longer guiding even if track holds) Both tracks time out without ever sending active signal. Result: Whenever any track breaks, all missiles in the air go stupid and no active guidance signal is ever sent. Reproduction rate: 100% (8 of 8 tests) of scenarios where multiple missiles are fired and one track breaks.

So does this tell you physics is wrong, or that the dive scenario is not equal to the climb scenario Bit of a straw-man obviously, but I urge you to write it out for yourself with all forces involved and see where it gets you. I stand ready to be corrected.

Then all you have to do is somehow prove that thrust-to-weight is decidedly not equal. In a purely ballistic trajectory with negligible difference in drag, mass doesn't contribute to the result, since the following is true according to the laws of energy conservation: Kinetic energy at the start = ½ m*vinitial² Potential energy at the apex = m*g*hapex This leads us to: m*g*hapex = ½ m*vinitial² hapex = m*vinitial² / 2*m*g hapex = vinitial² / 2g since vinitial and g are the same for both aircraft, hapex will be identical. The only difference here is thrust, so you'd need to prove that thrust-to-weight is significantly different based on the thrust-to-drag needed to attain a steady-state formation. As @Katjhelped demonstrate, this means you need to determine the impact of AoA on the thrust setting and energy bleed of both aircraft. This in turn is heavily dependent on the L/D curve. The impact of AoA will be more severe on the heavier aircraft during the turn, but it will also reduce drag more significantly as it approaches 0 in the vertical part of the climb. Applying the KISS principle I would say: "all things considered, thrust/lift/drag will roughly cancel out in linear fashion". Therefore, we can assume thrust required to attain the same starting speed scales roughly linearly with weight. This would mean thrust-to-drag = thrust-to-weight = equal, in which case both aircraft would reach the same altitude. Not entirely true for real life, so therefore the real answer becomes "it depends". Bottom line, you cannot easily simplify this, nor test this by just taking two aircraft at the same speed and pulling vertical.

"It depends" xD But all things combined it'll be about equal unless we go to the extremes.

I wouldn't be surprised if his point is nothing more than "don't pretend you can prove anything based on arbitrary, imperfect scenarios" Personally, I just enjoy physics discussions, since that invariably means learning a thing or two.

Yeah my point was to illustrate that in the end-state the only contributing factor to lift is thrust, i.e. the scenario described goes from being about thrust-to-drag to being about thrust-to-weight. It would be more correct to remove the lift vector and make the drag vector very very tiny, but ehhh I'm not saying drag is greater than lift do I? I'm saying the drag coefficient increases more quickly as a factor of AoA than the lift coefficient. Since increasing AoA is the only way to create more lift with the same wing at the same speed, the heavier aircaft is going to have to exponentially modulate its thrust setting to maintain steady-state formation. I.e. a 20% increase in AoA, will generate a 20% increase in lift, but a greater or smaller than 20% increase in drag, depending on whether we are right or left of L/Dmax Image courtesy of wiki. If we want to be entirely correct then the answer becomes "It depends where we are on the L/D curve".

Yeah very good point. So if the drag coefficient scales non-linearly with the lift coefficient, the answer becomes "it depends on where we are on the drag curve" right? Considering drag curves seem to be pretty exponential, while the lift curve is linear (right up to the stall area) the heavier aircraft might have a significantly higher thrust-to-weight to overcome induced drag. Then again it also bleeds more in the initial pull I still think it'll be about equal Parasitic drag would be equal I think though, since both aircraft are the same shape and velocity.

Force = mass * acceleration You correclty assert that acceleration by gravity is equal, therefore F_gravity = m * g Therefore, if m increases by 20%, F_gravity increases by 20% Meaning the gravity component in th picture I posted is 20% larger, therefore 20% more lift is needed to keep the airplane flying. The rest I have explained in my post

This is the situation: Both aircraft are identical, flying the same altitude and speed, meaning: Coefficient, density and velocity squared is identical for both aircraft Mass is 20% higher on one aircraft 20% mass increase will lead to 20% increase in gravity component, requiring 20% more lift to offset (maintain level flight). Since all components of the lift formula are identical, the only way to increase lift is to increase effective wing area by 20%. The only way to increase wing area by 20% is to increase the AoA on the wing by 20%. This in turn increases the drag of the wing by 20%. Finally, 20% more thrust is needed to offset the drag and reach the same steady-state speed. Therefore: Thrust to weight is identical and both aircraft reach the same altitude. Edit: also this means it very much is applicable to the current situation, thanks @Victory205 for showing us the light Edit: Unless I'm overlooking something super obvious ofc in which case please do show me the light.

Fun question. I'd say these should reach the same altitude because at a steady-state starting point that means their thrust-to-drag is equal, making the comparison a purely ballistic one if thrust is unchanged. There'd be some AoA-related shenanigans involved due to difference in lift force needed, but I have no idea how it'll affect the outcome so I'm gonna assume it evens out somewhere... (more drag in the pull, but bigger reduction as lift vector aligns with thrust... something like that) It's not directly applicable to this situation because while both aircraft begin with the same start, plugging the burners does mean there is a thrust change affecting the outcome. The question would be how significant the thrust difference has to be for it to be measureable in seconds on a hand-flown test scenario.

There's another key difference between the TF30 and F110 that you might be missing. While the installed thrust of the F110 is much higher than the TF30s, the actual thrust in full AB might be lower in certain scenarios. The TF30 fuel feed will just basically give the engine as much mass as it asks for, while the F110 will schedule fuel flow in a way to greatly reduce risk of flameout due to oxygen starvation. This does mean that in certain speed conditions, the F110 will have equal or even less thrust than the TF30. You can notice this best in very slow turn fights and acceleration at supersonic speeds. I wouldn't be entirely surprised if something like this is also affecting your climb test. As you near low-end speeds of your climb profile, the TF30 will continue to push massive amounts of fuel into the AB, while the F110 will have been throttling down fuel flow to prevent engine stall. Repeat this test by just maintaining a certain airspeed and I think the F110 will have the advantage.

Yeah I feel they just straight up broke AI in the last patch, other aircraft are just doing one pass nose-low then straight vertical until they stall out and then they start repeating stall turns. Dogfighting vs AI right now is no fun at all. If you keep 10 knots over the enemy you'll have him on the first pass because of these stupid manoeuvres.

The carrier used for the instant action CASE I recovery has its target waypoint set to 11 knots, leading to a wind-over-deck speed of only 17 knots. I was hoping it would be fixed with the Forrestal release, but the problem seems to still be there

Good call!

Dear Heatblur, While I really enjoy using Jester, I find his A2A interaction rather rough. I'm missing some basic functionality that a RIO would provide, and find that interacting with him takes a lot of time in the heat of battle. This wishlist would add some features to help identify and discriminate targets, as well as reduce the amount of interactions needed to achieve these results. Lock/Designate My first suggestion would be a Designate TWS Target function within the STT menu, allowing use of the AWG-9 Next Target functionality to prevent target reassignment or simply to designate a contact on a cluttered scope. This could have the same submenu as the existing Choose Specific Target STT menu. Secondly, in the STT Lock submenu, I'd like to suggest the addition to cycle MLC on/off and toggle PH-ACT. At 30 miles the 3 degree look-up to disable MLC would require dropping slightly less than 9500 feet, while the range gates on STT allow far wider margins. This would make engagements with the Phoenix in PD-STT much more potent. Scan Elevation The current Scan Up or Down menu is basically unusable, providing only 0, ±16 and ±30 degree elevations, which are far too coarse for any engagement outside of 5 miles. The elevation-at-distance menu is a nice alternative, but it requires 4-5 interactions to achieve result. Using the wisdom of our lord and saviour @Karon over at Fly and Wire I would suggest changing this menu to ±1.6, ±3.2 and ±6.4 degrees elevation. This would provide 5000/10000/20000 feet elevation increments at 30 miles, while having good granularity at longer and shorter range as well. Alternatively 0, ±1, ±2 and ±4 degrees would provide the same increments at 50 miles, at the cost of sub-30 mile engagement potential. 2 and 4 bar settings would allow good overlap between these increments for both options, enabling full use in RWS and TWS modes without risking loss of target. Having these as cumulative would be the icing on the cake. Scan Azimuth This menu is nearly perfect as is, I'd like to propose addition of ±60 azimuth to go along the proposed ELAZ menu. Radar Settings Another menu to keep pretty much as-is. This could have the Radar Silent functionality to make room for the ELAZ menu in my wishlist. ELAZ This is the core of this proposal: A menu to allow the pilot to select between 2, 4 and 8 bars as well as ±10, ±20, ±40 and ±65 degree azimuth settings. These additions would truly unlock the full scope of AWG-9 functionality through Jester, allowing for better sanitization, detection and discrimination of targets in chaotic combat environments. Final words I feel these additions and tweaks would really bring the A2A menu into its own and enable the pilot full control of the F-14 in combat engagements. I'd love to see parts of it end up in the release candidate for the Tomcat. That said, I understand some of these are made from the RIO perspective and will require the pilot to get a slightly increased understanding of the AWG-9 and its workings. So I'd very much like to hear any pilot feedback on my suggestions as well!

I'm also intermittently seeing missiles no longer go active or try to intercept when tracks break. Instead the phoenix will go stupid/ballistic (1.0G level flight) as TWS-M continues to try and keep the centroid on the dead track until it times out.

This I've noticed yeah, you have to really unload to get back on airspeed but if you've settled in a turn it will also hold it quite effortlessly.

It for sure took me some adjustment but I'm positively surprised at how good the changes feel. The "AoA tells" and CASE I handling are lovely right now. Much as I like his company, I politely ask Jester to shut up in BFM, because the buffet gives me all I need. Previously I felt like I was struggling to figure out how it would respond to certain inputs, which lead to a lot of overcorrecting. I feel much less "behind the jet" right now. Seems a bit harder to keep the speed up, especially with bags, but in return there seems to be more precision and I can "feel" when I'm in the right places of the envelope.