IronMike

We're aware, thank you! This is a general DCS missile guidance issue though, not phoenix specific.

Small correction, campaign will be for the -B, Reforger Part II, Syria map.

It comes from the test where a phoenix got fired from an F15 iirc at around 50k feet, without a warhead (to see/prove if it can go mach 5 potentially). Would one reduce the weight with the current missile accordingly, and launch it from the same or similar conditions, it would likely achieve that in game as well.

I respect your opinion, I do, but I also have to disagree, and I think that you will likely find that many folks will disagree with you regarding its usefulness. It has its place online as much as offline, as much as in air to air as in air to ground, pitted agains its contemporary cannon fodder, or a much more modern and advanced challenge - it is, in the end, what you make of it. So, if for you it has a seemingly narrow purpose, to best eagles, vipers and hornets day in day out online, all the time, with a nigh 100% success rate, then yes, I guess one could argue that it is useless. But the idea to make it purposefully unrealistic to give it a place - in what exactly? - is not something that is in any way feasible, or acceptable, when doing realistic simulations. Thank you for your kind understanding.

I just tried above 36k again, and indeed, unless one is precisely at null rate, and well below m 0.9, it just pulls straight down. Definitely a bug. Thanks again for all the feedback!

FFB is still an ongoing process and a known issue, our apologies that it drags out.

Check what mach speed you are doing high up. Note that you can be significantly below 450IAS yet doing more than m0.9 high up, at which point alt hold will start failing, oscillating etc. That just in general. It will ofc also not be able to hold beyond a certain AOA, but would need to check at point. Thank you for the track as well. To comment on that a bit: The fail at 37k feet is expected, you are at m.9, which is where its limit is for alt hold, and engage out of a steep climb in terms of FPM, so it oscillates. Likewise the fail at 45k feet seems ok, because you are getting so slow, you can barely keep the aircraft level yourself. So ALT HOLD now has to fight 3 conflicting things, from that particular negative FPM you engaged it: 1. It needs to null the rate, aka climb. 2. It needs to dive to lower the AOA, this in return makes the aircraft gain too much speed (to note that there was no speed management involved in your track), aka exceeds the limit again, which in return increases oscillation 3. And all that while trying to return to the captured altitude. The result is this heavy mess. In other words, you made it maximum hard on the autopilot to succeed, or basically impossible. Which in itself is not a bug. ALT HOLD will disconnect only if stick force is exceeded or 30° pitch is exceeded, so it will keep the phugoid happily ever after if you do not disengage it. When exceed this limit, it should revert to ATT hold, in which case you would still have to save the plane manually from disaster, if that makes sense. However, despite of the expected outcome seen in the track above, there is a bug, where above between 39 to 41k-ish - from personal experience - no matter how well within your limits you are, ALT HOLD engagement will always result in a dive first, and phugoid second, which seems to be wrong. If you manage speed and FPM accordingly, it will work rock solid up until 39-41k-ish feet though. Just tried myself as well to confirm. Flying with ALT HOLD on at 45k also may not have been a thing, but when within limits, the immidiate plunge to negative FPM still should not happen like that. In other words, if you tried to do it correctly, it would not work either now, so definitely a bug, even if not clearly demonstated in the track (I also flew it myself a couple times now to verify). Thank you again for the report!

Thank you, we will take a look!

It depends, I will keep it somewhere around 350 IAS to 450 IAS, so I can transform it quickly into a split-S, etc if necessary. Around 350, increasing through 450 in the reverse is usually quite ok.

Btw everyone, I kept saying "NASA tests" in my previous posts, and @Machalot was kind enough to remind me of not being precise, I of course meant the NASA simulations. Apologies!

Start modest, build as time goes, most of us came into it like that as well. No need for the bestest and greatest right away. Should be decent, should have it work nice on medium to high. Can be a very much cheap entry stick at first. Then you see how you like it, and expand. Thus, building a medium to average gaming PC, that can be expanded upon in the future, is the best way to go for starters. Self-built and thus modular. You may very well not like it, or need to time to grow to like it, etc. and then you can still buy an aficionado joystick and the latest of latest of gaming hardware.. Generally, it uh, ends like that I shall warn you though.

We are still doing it, but we had to put it behind other, currently more pressing tasks. Thank you for your very kind patience and understanding.

Thank you for your very kind words! This is why accuracy is so important to us, no matter if we have to backpaddle, bite our tongue or eat our own heads: these modules do contribute to the history of these aircraft told, even outside of DCS, and thus one has to be responsible in doing everything we can to get it as close as possible. Myths are myths, and I would carefully suggest: no matter these changes, the Tomcat remains a mythical beast, especially when you start creating rather realistic scenarios. Btw, ever thought about trying DCS yourself? Not trying to sell you anything, but it is a) an even deeper look and experience and b) a lot of fun as well. It is quite intimidating at the start, but for someone like yourself, who is into these things already, the learning process should actually be a lot of fun in itself. Just something to consider, it is one of the few things I never regretted to have sunk time into myself, hehe.

We do care if you live or die online, because we want you to have fun. But that still must not influence the realism of the simulation, and making or keeping the missiles unrealistic despite knowing better, is not the way to go about it. The way to go about it, imho, is that we all together learn the strengths and weaknesses of what we get, and figure out how to make it work. The phoenix is inferior to the amraam in many situations, but in some, it is much more powerful and has a much further reach. Figuring that out and flying towards an according setup, is part of the nature of a simulation. I hope that makes sense.

Welcome to the forums @Timo Niemelä - it is great to see that our work sparks interest even outside of DCS. I hope you find what you came looking for. The mach 4.3 is often taken, I would kindly suggest, wrongly, as a normal employment max speed, while it was only demonstrated as capable, not guiding, etc etc. You can see this is demonstrated for the DCS phoenix as well here: The NASA tests show much more close to normal employment conditions, and indicate a top speed of around m3.4-3.5ish. However, without speculating too much on details, indeed an improved guidance will help both the A and the C with terminal energy, etc. But not by that much that it would turn out as a silver bullet. The C being expected to be faster and then turning out to be what it really was, is another story, as with the same impulse and a slightly heavier weight, the logical expectation is to be slightly slower. However this is completely negligable in regards to its true benefit, which is a much improved guidance. I hope that makes sense.

We do have access to real data, and we are not doing this to balance Multiplayer. If I may refer again to @JNelson's post above, you can take a look for yourself just how close the phoenix is to real data. I really cannot stress this enough, how utterly unimportant Mulitplayer balance is to us. It has zero bearing on any of our decisions. Please be so kind and stop insisting on this, it only spreads an entirely wrong rumor. Thank you! Jester's behavior in both cases is a limitation of Jester and a consequence of how he works. If he calls missiles from 60 miles that have no RWR warning or show on the radar, that is a bug though, and I would kindly like to ask you to make a report about it, especially if you have a track that would help. We reworked his missile calling behavior a while ago, but it is very possible that bugs remain, which we have overlooked so far. Any input to help us improve this is much appreciated, thank you!

I understand your frustration and I don't mind the sarcasm. But maybe I can put it a bit into perspective, if you allow: The aerodynamics were correct, the motors were wrong. Now both are correct, and by correct I mean as close as we can get it to reality. That is simply something we all have to deal with. Please understand that we're not making modules to be "competitive online", but to portray them accurately. Just how close it is to reality, you can see a couple posts above, when comparing to irl record of flight and impact times of known tests and the data provided by the NASA tests. Peak mach is around 3.45, but you can get it to around 3.8 under optimum conditions. If you do what NASA did during their tests you can also get the mach 4.3 they showed it is capable of, as a proof of concept, however mind you, not under normal employment conditions. Overall it is within a margin of around 3-4%, which I think many are not aware how insanely close that is in missile simulation. As for online, by that logic no other aircraft than the F16, F15 and F18 would have a place online. Why fly an F1? Or a mirage 2000 even or let alone a MiG21 online then? The expectation that sets up for disappointment by some seems to be that the Tomcat should a priori come out on top over everything else. While in any other older jet the challenge it poses is accepted from the get go. But the issue remains, you are flying an older jet that was not really developed to counter an F-15/6/8 amraam slinging threat (by that I do not mean the still wrongfully spread rumor of it and the phoenix only being meant to shoot down bombers, far from that). And there is a challenge involved, naturally. Whether players consider that kind of challenge fun or off-putting is up to each player themselves, and unfortunately not something we can take into account when trying to improve the simulation. The lofting in most long range shots is as it should be. The issues are in shorter to medium range shots, where it can at times overloft. But we compared lower loft, straight and higher loft shots with the missiles as is, and the higher loft will have it arrive with more energy, and also hitting the marks it should - specifically on long range, but also medium range shots. With the wider arc that it travels, ofc you will overtake your own missile eventually. But you would not do that in BVR, you fire and crank and slow down, burning the cans towards your target - and his missiles - is not really an advisable tactic. There are regimes where the Tomcat holds its place even against more modern bluefor jets, but you need to fly it accordingly and make use of its strengths, just like with other older jets. If you see the challenge in that, it - in my humble opinion - adds fun.

ACLS is still WIP, same as AT. Our apologies that this takes a bit longer, but it is a fairly complicated item.

Dear all, I recently had both the luck and opportunity to sit down with @Enigma89 for an interview. I very much enjoyed being his guest, and would like to express my thanks here again! I found his approach very refreshing and interesting, and while I am sure I talked too much as usual, I hope those of you who are interested, enjoy it, too. This time we talk less about day to day development, roadmaps and updates and more about some of the thought process that stands behind - at least some of - the things we do. We also talk a bit about the history of Multiplayer in DCS in general, the role of Cold War and the Cold War Server in it in particular, and how that affects us as developers. Big thanks again to Enigma and the entire Cold War Server and Community.

In TWS, you can only fire 1 missile per track, the next missile will be for your previous priority target 2, which is now the new priority target one and so on and so forth. If you want to fire more than 1 missile, you have to fire it in PDSTT, either twice in row in PDSTT; or TWS 1 missile, then lock PDSTT and fire another or more.

It's my pleasure, but both of the above questions I honestly cannot answer, because we have no or only partial insight into that part of the guidance. Both your questions would be best directed to ED. Apologies that I cannot help there much, or in other words: both remains to be seen, @okopanja and @cheezit.

That is a question for ED, we are ofc open with our "roadmap" (please dont take this too officially), which is basically what I described above: - check if and what kind of adjustment nozzle exit area needs (potentially in our case we may even leave as is, but yet to be seen.) - continue improving guidance issues as mentioned above - continue improving lofting issues, etc. - move missile to new missile schema. The last three are happening more or less simulatenously, and the guidance and loft improvements will likely continue after transferring it. As ED is of course thinking of the bigger picture and more long term, and thus wants missiles moved to the new schema once they feel it is more complete - which I btw think is a good decision - this can take a bit still. I know it has been long in the making, but I can only imagine with how much complexity they have to deal and how hard a task it must be. In that sense we all just need a bit of patience, long term it will be worth it, if missiles in DCS improve overall, not just the aim54.

Notching is very difficult to substantiate. It is a case by case thing one needs to look at, so if you find odd cases, where you think it should not have been notched, or where we can show that it just gets notched "way too much" or "too easily" (and therein lies the problem, as in defining what "too much" and "too easy" is), it helps to build a case. Personally I have to admit that in my experience, and the cases where I have seen my missiles notched, it did not seem too odd or utterly unrealistic, while ofc missiles do get lost to it, but that is also a bit the point behind it. I would be hard pressed to make a judgement call there in most cases, but 100% sounds definitely wrong.

That's ok, I do not mind, and it may not even be intentional, may be typing on a phone, etc... Let's stay on topic please and all a bit more open minded towards each other. Ha! Sniped me.

There is no need to apologize at all, all good. It definitely is a problem, just as you describe it. It's not at all a real missile phenomenon, it is a bug in the guidance, or maybe a flaw in the logic, or a limitation of the current model, which is partially still unknown to both us and ED. We are currently trinyg to chase this down - if anyone has a short track with it happening, please share! - because it makes the missile do really stupid things, like weaving above a target to match the intercept course, but like, not even pointing down to make the actual lead intercept with just 500 feet left, etc.. These are guidance specific issues, which we cannot fix on our own, but we're working with ED on all of these. We take this matter very seriously (and so does ED), btw, because we think this is one of the last remaining major issues that hampers the phoenix (and missiles in general). Also noteworthy is that due to its long range, the phoenix pronounces such issues much more than other missiles, too. Which makes it double as important to find a way to fix this for the phoenix, because it is much more affected by it than shorter ranged missiles. A very good and recent example for that was the video shared by @Soulres - a shorter ranged missile would have likely ran out of steam before making it around that mountain and a faster missile may have lead more aggressively and crashed into the mountain. This particular issue (flying around a mountain) was believed to be fixed when the "magic INS" bug got fixed couple years ago, but now we know this still exists, too. And this all boils down to these guidance issues that need to be fixed both short term and long term. To be transparent on how that works - strictly speaking guidance related issues now that are generally out of our hands: we collect what we can find on the issue (and have been doing so for a long time ofc), then present the case to ED, upon which they propose a change, implement a fix themselves, or guide us in adjusting certain parameters, and then rinse and repeat. It is a very difficult and unfortunately time consuming process, stemming from the complexity of coding missiles and the unreliable reproducability of these issues: we all have seen them, we know they exist, we even experience them on a regular basis, but they do not happen so consistently that it can be 100% reproduced/debugged by the developers both from us and ED. I am not saying this to excuse the admittedly very slow process btw, just to explain to you how we go about it, so you guys understand what is going on behind closed doors in general. And it is also important to know that ED is very forthcoming and helpful in these matters. It is just a very, very painful process for all parties involved, as in difficult to solve. In that sense we are very grateful for your very kind patience. This particular phenomenon you mention is of course not all that remains to be fixed, but in our opinion it is one of the biggest remaining issues. I also want to add to the lofting debate: while some of the lofts are excessive at short to medium ranges at times, often times they are benefitial as are (provided you do not overpitch and the missile goes to space), and if you compare them with a more shallow or non lofted profile, arrive faster at the target, as if they would when travelling through thicker air for a longer time. Again, this is not to say that there are no issues with loft, there 100% are, and these, too, we are looking to change and improve ofc. Finally the transition to the new missile schema will get rid of some limitations the old missile API poses on guidance, missile logic, etc. and may additionally help to tackle parts of the above mentioned - which remains to be seen if and how much. We are not done with the phoenix, and we will continue improving it and working on the remaining issues.