KlarSnow

It is very easy to recreate this behavior, just hold the stick back and as you get slow step on the rudder in either direction as demonstrated here. The "turn rate" is just heading change, IE the nose swinging around, it is not the flight path turn rate until the nose has stabilized and it is fully loaded up again. 19.4 Dps turn rate, 1.1G, at 231.0 Km/h CAS 17.5 Dps turn rate, 1.4G, at 256.1 Km/h CAS 17.7 Dps turn rate, 1.4G, at 263.2 Km/h Cas also note the stick was held back the entire time, the AOA pegged, and my aircraft increased airspeed as I descended. Tacview-20220818-173925-DCS.zip.acmi

Which is entirely related to the nose position of the missile swapping from one side to the other, please, this is all just the “turn rate” in tacview being tied to nose position, not actual turn rate. Any time there is a transient and a mismatch as the nose is moving there will be a high transient “turn rate”. This is not the same as the actual flight path turn rate. Which appears to match the steady state turn rate and turn radius the entire time. again nothing appears remotely wrong here. Y’all seem to be latched on to the high “turn rate” which is more accurately described as nose position. Actual turn rate of the flight path once it stabilizes the AOA is exactly in line with what is possible. The only way what is shown happening is not possible is if the control surfaces have no authority to affect the nose of the aircraft/missile. you can replicate this exact behavior with any aircraft.

The point you indicate here is when the flight path and nose of the missile goes from above the horizon to below the horizon. Why would it not accelerate as gravity is no longer slowing it down but increasing its speed. the AOA dip immediately after (red line) when it changes direction is also commensurate with a 10 knot speed increase. like to be clear you are talking about a small 10-20 knot increase in airspeed as the missile goes from pitched up to pitched down. That is very much not unreasonable, nor does it defy physics.

The acceleration occurs when the missiles flight path goes from above the horizon to below the horizon,and when it briefly unloads AOA during the nose swap, what exactly is wrong there. And as to the turn the only thing I have concluded is tacview is assessing turn rate based on change in nose position.

A stalled aircraft can definitely change its flight path, you can demonstrate this with any aircraft in DCS, pull the nose up to max AOA and then as it buffets and stalls kick the rudder in one direction or the other, or unload the stick letting the nose fall back through vertical, in this instance it appears like the missile went from fully loaded in one direction to fully loaded in the other, I see zero issues with this. There is an AOA dip right as the missile is changing direction, with the nose below the horizon, so this also contributes to the small acceleration you see there. The force is coming from gravity, again a rock thrown through the air is stalled, does it accelerate? In addition as to it making a 110 degree turn, the missile is dead (battery death) approximately 5 seconds after it swaps its nose from one side to the other, it then falls with its controls in their final position, continuing to turn (at a 2-3 degree per second rate) as it falls to the ground. Again this is all expected based on what is happening here. Look at the turn radius, not rate. Looking at your tacview, it appears the rate you are observing is solely related to how tacview interprets turn rate, as nose movement of the aircraft, not how quickly it is moving along its flight path. The turn radius and airspeed shown in the tacview match the max performance you calculated, which also matches the actual flight path of the missile. if it was actually turning at 13-18 degrees per second turn rate, there would be a 500M turn radius and a much tighter circle instead of the giant barely moving curve presented. I see absolutely nothing wrong here.

Ok on reviewing that I really don't see anything untoward, the missile basically swaps its nose from max AOA to the right to max AOA to the left, the actual flight path does not change. It is still stalled and the turn rate you are seeing is just the nose moving. As to the acceleration, its falling downhill. Stabilized in a stall at max AOA, it will pick up speed as it falls so again I dont really see any issue here. Like you still can point the nose of an aircraft post stall with control surface movements, that's all that's happening here, it has a very high nose movement rate for a second as it swaps from one side to the other, but it is stalled so the actual flight path barely moves.

I would really compare the turn rate to the assessed turn radius, because those are tied to the speed. 13 degrees per second turn rate vs a 2km turn radius at 360 km/hr don’t match up for an actually turning object. The turn radius if it was actually turning 13 degrees per second at that speed should be something in the vicinity of 4-500 meters, not 2000. A 2km turn radius at that speed matches a 2.8 degree turn rate. I feel like you are looking at a transient rotation of the missile here. The same btw applies to all three of the snippets you presented. The Turn radius matches a 2-3 degree turn rate for that airspeed. The turn rate seems to match nothing. the turn radius is a much better representation of The actual flight path of the object than the turn rate. As to the airspeed increase. A pitch angle would help here. The missile could be pointed straight down at max AOA in which case gravity will make it accelerate.

It is stalling at this point, so its AOA is going to be pegged, as to the turn rate, is the missile rotating, or is its flight path actually moving, these are two different things, in a stalled state of flight the missile isn't actually changing its flight path its just rotating as it falls. This is also why it accelerates, it's falling. Essentially you are saying that an aircraft spinning with a 50 degree per second or faster spin rate is unrealistic because of how much G they are pulling. They are still pulling 1 G, but tacview doesn't show lateral G (yaw) at all, and that can be very disconnected from flight performance. Like just to be clear, based on the airspeeds you have presented this is a missile that has missed its target and is falling at terminal velocity (360Km/hr), completely stalled (max AOA 25 degrees pegged) and apparently autorotating at some rate. This doesn't appear to be remotely affecting guided performance or its ability to hit the target. like look at the turn radius vs the turn rate. This looks much more like an autorotating stalled ballistically falling missile than anything else. IE it's not a factor to anything. Do you have the entire tacview of this missiles flight, because based on the parameters shown this is my conclusion, not anything untoward in the missile dynamics or flight model. If you had the entire tacview of the missile and its flyout instead of just the snippets that would help illuminate what is actually going on.

The SA-2 radar has no idea what the AGL under the target or intercept point is. That is the entire point of using the LOS to the target as the boundary. if I keep my intercept no lower than where I see the target now, unless terrain gets between me and the target then the missile cannot hit the ground. and in this case it really doesn’t matter if the missile is doing the guiding. In the SA-2’s case the guidance commands are sent from the radar to the missile, the guideline missile doesn’t guide itself, but this simple line of sight based adjustment still works if the missile is doing it all on its own. All you need to do is pre launch tell the missile you are going into a low altitude environment, (whatever you define that as) or the missile tells itself when it crosses a specific altitude to swap. I do not know if any specific air to air missiles that use this specific technique, but I do know that the AIM-7E and F had altitude bands that were passed pre-launch based on the targets altitude in order to set control gains. Whether or not the AIM-7E/F had this type of technique to help with low altitude targets I don’t know, but the pieces are all there and it’s not a difficult problem to solve especially with computers.

Example from SAMSIM's documentation on the SA-2 Target height less than 5Km (15-16,000 feet), at least this variant of the SA-2 uses exactly the method of guidance I am talking about to avoid the ground. That's a pretty big buffer and would also solve the issue immediately.

Yes I am aware, that does not change any of the validity of it. The vast majority of terrain in the world is within a few thousand feet of sea level, and if you are ducking into a valley there isn't much a guidance algorithm can do to avoid a ridge. However that's not what we are talking about. We are talking about a target at low altitude, in clear line of sight of the missile diving at the ground to push the intercept under the terrain. That happens most often relatively close to sea level. So having something like when below 5000 ft AGL barometric, activate this logic, would solve 90% of these issues. Missiles have to have some SA as to the density altitude they are flying into because it can change how they actuate their fins, so it is a part of their logic to change gains based on shoot up, vs shoot down. No it would not solve this issue 100% of the time, but you need some pretty advanced stuff to solve this problem 100% of the time. And again nothing is going to help the missile avoid a ridgeline its target dives behind, however over relatively flat even terrain this would prevent the majority of the exploits that occur in DCS. (how much of each map has terrain that isnt mountainous, and is above my example altitude of 5,000 feet MSL) The only one that gets remotely close is the Nevada map in some parts. And even then, most of it is below 4000 ft MSL. As to requiring a radar altimeter, if the missile has an active radar of its own it will recieve a strong altitude line through its sidelobes, any MPRF or HPRF radar will have that, and especially as it gets closer (within a mile or two) it should be fairly easy to track the range to it. This would be a direct measurement of AGL.

Could be either, the missile could have a "low altitude flag" that gets tripped at launch based on targets or shooters altitude. Or It could have some way of knowing its altitude roughly, if not accurately, even just barometrically. Or if its an active missile it could measure the altitude return once its active and have a very accurate altitude. Or if it has an INS/a 3d Coordinate and vector of the target it could switch the logic on itself based on the targets maneuvers and position. Lots of options based on how specifically a missile works. Could also just trigger this logic in the "terminal phase" instead of from launch, again based on any or none of the above factors.

If below a certain altitude point no lower than the target until a certain line of sight rate is reached. So if in a low altitude environment, use pure pursuit in the vertical until the line of sight rate hits a point that requires switching back to lead.

I'm aware of the differences between the missiles in real life, I'm specifically talking about in game. Does the AIM-7E have the worse motor? Or is it just an AIM-7F renamed with worse CCM rejection values.

Strike eagles don't have OBOGS, they have MSOGS, different system. The strike eagle issue which was a few years back was due to a spate of faulty valves in the regulators, MSOGS worked and works fine. The solution to all of these problems btw is to do what aviators have pretty much always done, drop your mask and breathe normally as long as the cabin altitude isn't too high. The issue where someone suffocated was a familiarization flight, so somebody in a jet who was not familiar with the mask, helmet and regulator.

The issue here is that metal objects do not heat up and cool down at the same rate as surrounding terrain/ambient air. On a sunny day a metal object like a tank will warm up very quickly and even when off will be hotter than the dirt. The ground will take a long while to warm up and will almost never get as hot as the tank. This will vary depending on the type of terrain. A desert for example will heat up quicker than a grass field for example, but still the metal object will normally heat up much quicker than the surrounding terrain and thus should be visible. The reverse happens after the sun goes down, the metal tank does not retain heat as well as the ground does and so will cool off quicker while the ground retains its heat. This is where thermal crossover occurs, as manmade metal objects or buildings cool off from their elevated temperatures throughout the day and match for a while the surrounding terrain temperature providing no contrast, however this is a transitory state usually lasting less than an hour and then the vehicle or building will be cooler than the surrounding terrain. This holds true all night until sunrise, when the object will heat up through the ambient terrain temperature and again lack contrast until it is hotter than the surrounding terrain. This is all without the vehicle engine or any other factor heating or cooling the vehicle.

Apologies I did not see that your response @BIGNEWYwas to another post that got deleted.

I'm sorry but his response was a deflection and has very little to do with what we have been discussing. Nowhere in this entire discussion was the total Pk of the Amraam in DCS brought up, nor is it really relevant. We have discussed the design philosophy and decisions that seem to be going into the new missile API and the frustrations that are inherent to the percieved modeling. We have also discussed specifics about how the seeker is being modeled and tried to determine what assumptions and possibilities could go into it. Nowhere in there was the missiles Pk or relation to the real world brought up. I'm sorry but that is obvious deflectionary tactics and is not addressing what we are discussing.

The radar has a monopulse seeker, it should be resolving the target and any return in angles, otherwise it would not be able to tell two targets in its field of view from each other. I don't know what kind of angle resolution you have it capable of but the target should not be competing with the entire field of view of clutter in front of it, just what is directly along its line of sight. It can see and measure the angles to all of the large clutter returns using the monopulse seeker so should be able to ignore it by simply not looking there unless the target begins to overlap it in clutter. Yes by your calculations the radar has a 15 degree beamwidth but once it has found the target, its effective beamwidth (what it is considering for tracking purposes) should be incredibly small. Some very basic googling on monopulse multi target resolution is showing roughly 3 degrees, so even if that's a horrible estimate, once it has found the target, it can now disregard ( and should disregard) all returns that are outside of a very tight window around the target. Reducing the clutter that is directly competing with the target to just what is in that narrow field of regard. if the seeker cannot resolve angular resolution then it would have zero capability to tell one aircraft from another if both are in the field of view, or which is closest to the cue the INS is providing when it goes active. Yes it is sorting by range and velocity, but it also should be able to sort by angles as well. The Main lobe clutter is not going to be spread out evenly across the field of view of the seeker and if it can see where the target is via angles it can also see where the largest MLC returns are by angles and ignore them, reducing the total clutter that is competing with the target to just what is in the direct line of sight that it can resolve.

And how much of that Pk is due to short range terminal notches or kinematically dragging and defeating the missile. You should be aware that these are two very different things. I sincerely doubt improving the missiles capabilities in this regard will change the Pk all that much. All it will do is remove the ability to completely negate missiles up until extreme short range. And move the gameplay into kinematic defeat and away from sensor defeat. Players will still kinematically defeat the missiles they will just pay for trying something as high risk as pushing inside where they can kinematically defeat it.

The other concern is that you are putting all of this effort into constantly adding features that make the missile the same or worse than it was previously. We currently have so many filters that every missile has to get through to make it to the target. Random chaff rolls, notching, support from the radar, whatever effects jamming have, finally terminal glint effects. And this is all assuming the supporting radar doesn't bite off on a missile that was launched by yourself or the target on the way and completely defeat your own shot. When are you going to add features that make missiles more effective, because right now it seems you have worked for years to make them exactly the same or less effective. Someone could have left the game in 2019 and come back and found the EXACT same mechanics at play as they have been for the past twenty years. This makes me question what the point of all of this in depth modeling is if ED can't make a decision on changing any mechanics and are just modeling the same mechanics "more realistically".

Maestro, If you had said this at the beginning instead of correct as is. I think this would have alleviated a lot of the concerns. This entire thread was instigated by you dismissing that complaint as realistic and not acknowledging that there was any further work that needed to be done. Maybe be honest with the flaws and what needs to be done with your modelling as this goes forward instead of every single question is correct as is. Maybe Correct as implemented, but improvements are coming would be a better way to answer that. As for the rest. You are correct on much of the theory. However you are consistently making assumptions that lead to these results regarding the seeker. And ignoring anything that could potentially make these issues better. An MPRF Monopulse seeker should have a notch in the 10's of knots, not 100's. Especially once it has found and is tracking the target. Angle gating is something I think you should look into, because yeah if it has a 15 degree beamwidth all of that clutter can get illuminated, doesn't mean it cant digitally cut what its looking at down to only a couple of degrees once it has the target acquired. As a monopulse seeker that should be inconsequential. It should be able to as well as measuring range and velocity, measure angle of return, and can then use that to filter out much of this 15 degree beamwidth noise. once it has an angle and range track on the target, Why is it still competing with the entire 15 degree beamwidth of clutter, once it knows where the target is all returns that are not in that tiny window and angle should be disregarded. Yes there will still be MLC in that window due to aliasing, and yes its not a completely clean picture, but you are treating it like no matter what the target is always competing with the 15 degree beamwidth of clutter, and that is not at all a requirement. It should be completely able to gate that down to a couple of degrees around the target, and then the tiny range gate around the target, and finally the velocity. None of this would remove the notch, but it would make it much much smaller than you have currently implemented it. Again the issue here isn't really the modelling. The issue is where this years long process is going and what the end result will look like. You cannot have it both ways. You cannot claim to be making the missile "realistic" and maintain the current gameplay mechanics that have been essentially the same for the past 20 years. If you are making the system more realistic then you are going to at some point have to deal with that.

To any ED Flight model peoples. I will put a track up tomorrow if needed, I believe your pitch CAS implementation in the F-15C is incorrect and is making the aircraft harder to control than it should be at low speeds and high AOA. The Stick should get heavier (require more aft movement) to generate higher AOA as you get slower with the pitch CAS on currently you have the opposite. With Pitch CAS on the stabs are fully dug in at half stick travel as the jet decelerates below 250 knots. This results in a loss of pitch control authority and results in the jet pitching up heavily uncommanded as you slow down with a frozen stick. The jet is easier to control in the high AOA regime below 250 knots (25-30 and above AOA) with the pitch CAS off than with the pitch CAS on. This is incorrect. You should not be able to sustain greater than 35 AOA without holding the stick fully aft. If you slow the jet in game below 250 knots with the stick half aft the AOA will increase until you are stalled and pegged at nearly 40 AOA without moving the stick. This is commensurate with an uncommanded increase in the stabilators that is putting them at or near the full pitch up limit. This is in effect reducing the effective movement of the stick by half or more. This makes it very very difficult to maintain or sustain any AOA between 25 and a full stall, and makes unloading from a fully loaded maneuver require you to nearly center the stick since the stabs are barely moving as you move the stick. I am happy to take this to a PM to discuss this further and why specifically this is wrong. I do not think a track will help since I believe the issue is a confusion about how the pitch CAS system works, and thus how it is implemented. This is from Eagle Talk, a magazine published in 1974 about the incoming F-15 Eagle. Can be found online easily. This is opposite how Pitch CAS currently works in the game. Here is further on in Eagle Talk Vol 1 where it talks about high AOA characteristics and stalls, the key thing here is it says stalls are stabilized at full aft stick both CAS ON and CAS OFF, This is not how it works in DCS currently, you can be fully stalled at half aft stick with the CAS ON here is a quote from the Preliminary F-15A-1 from 1975, this line or something similar to it is in section 6 of every single F-15-1 This is saying that with CAS on or off, the nose should get heavier as you increase AOA regardless of speed, this is what the CAS washout means, the CAS is providing extra authority for stick movement, so it washes out as you slow down so that the stick is heavier as you slow down. This is explained better in newer -1's that are just after rule 1.16 but are available on the internet, including an F-15A-1 from 1986 that is easily found but I will not link here. Currently the FC3 F-15C works exactly the opposite to this with CAS on, as you slow down the Nose gets lighter and you barely need half aft stick to hold a stabilized stall. here is ED's line about the pitch CAS on the F-15C modules store page, This is directly contradictory to what is said above. The damper is also washed out in authority, and the stick gets heavier which increases your pitch control precision at higher angles of attack. I added a track of the incorrect behavior, I limited my stick saturation so that I could not unintentionally pull more than half aft stick, and did a max AB turn with the stick at half aft. With the pitch CAS on the aircraft immediately pitches all the way up to 40 plus units of AOA and continues to stall. With the Pitch CAS off It stabilizes at roughly 35 units of AOA and does not stall. After a couple of turns demonstrating this I did a turn where I turn the pitch CAS on and off in the turn and you can see the jet swap between dug in and not as the Pitch CAS goes on and off. Again the Pitch CAS on should be washing out its inputs as we increase AOA, not increasing them. F15CPitchCasBug.trk

@cofcorpsequestion for you or anyone on the ED team. How is pitch CAS and the stick force sensor implemented? Where in the travel of the stick is the stick force sensor being applied? I may have a bug report related to how AOA and this system works. I believe it is related to where in the travel of the controls the stick force sensor is having pressure put on it, assuming you are modelling it as a discrete part of the input. Just trying to ascertain how this is implemented before I post a bug report.

While I hope this will help, I am afraid that it may exacerbate the disconnect between what players are expecting to see and what your (ED's) intent is. Adding one line features in change logs that affect (or don't affect) the entire gameplay system without any real in-depth explanation of what exactly is going on really does not help. This is a community that thrives on documentation. So please document changes and updates in how these mechanics work. What exactly type of radar is missile X using, what's its detection range, what techniques are you using to mitigate problem X problem Y, what is its notch size..... etc..... all of these parameters need to be clarified so they don't have to be parsed from random threads and general user knowledge in these forums. And it needs to be updated as things change. If we know what you are trying to do from the outset and what assumptions you are using for each change, that at least lets us know with every update what the working as intended state is. "added range gates" or "fixed range gates" tells us absolutely nothing when you go out and the exact same behavior as before the patch is still there. I understand that ya'll probly don't like having every single update constantly scrutinized like this, exposing each change in detail will at least give everyone a common ground to start with, and if you updated us on the progress of things, more frequently that would immediately cage expectations or at least give everyone an understanding of what is going on. Yes this will probably also lead to a lot of concern and feedback about decisions and design assumptions, that already happens, but right now we have no idea if any of it is as intended or a bug, and most of the time concerns that things aren't working correctly or that theories are being applied wrong are just dismissed out of hand with a Correct as is. You cannot properly test if something is working correctly if you do not know how it is designed to work. All you have to go on is why does my missile miss so much in these situations. You might understand why this is all very frustrating and does not lead to a lot of trust between you (ED) and the community when it comes to this stuff. A roadmap (much like you have implemented for the F-16 and the hornet) for how the missile API is developing would probly be super helpful, list all of the features you are implementing or are intending to eventually implement, and then prior to each update explain in full what that feature does in a tagged form that can easily be linked to and read. That way everyone knows how exactly to determine if its a bug or a not implemented feature. Let me put it in a way that hopefully makes this painfully obvious, right now only ED knows how the missile and its seeker and guidance and all of this actually works, and what is planned. By putting it on the open beta without explicitly having all of that available, you are enabling so many spurious bug reports that do not know how or why things are working that is increasing your workload and leading to all of these off the rails conversations about intent. Tell us how it works and what is intended with each update, tell us what we should be looking for to see if things are implemented correctly or not. Obscuring these details are making ours and your lives in this harder. You will absolutely get questioned if you put up a feature change that's intent does not seem to match how the community thinks it should work, but at least we know what is correct as is.