

MBot
Members-
Posts
3938 -
Joined
-
Last visited
-
Days Won
19
Content Type
Profiles
Forums
Events
Everything posted by MBot
-
That sounds a little disappointing, as I think the SA-7 is a huge hole in DCS' lineup of air defense systems. For example, between 1970 and 1983, the Soviet Union exported 15'000 (!) SA-7/Strela-2 missiles to Syria. Just let that number sink in for a moment... ED's perception that no one would want to use not-the-latest weapons for historical scenarios offers some insight into their thinking.
-
I was wondering about this as well. Is this a new functionality where a deception jammer can break a lock? Or was the video simply deliberately set up with threat beyond the good old noise-jamming burn-through range? In this case we would simply see a loop of lock->noise jammer->lock lost->no noise jammer->lock->noise jammer etc., which would mean that jammers remain pointless as burn-through range is almost always bigger than engagement range (perhaps there are some minor exceptions).
-
You want to be as high and fast as possible. What I do is a Zone 5 climb to 37'000 ft at M0.9, then dive to about 30'000 ft to accelerate to M1.2 as quickly as possible, then smoothly climb and accelerate further. You want to have the radar about 5° high, so I order Jester to scan at 70'000 ft at 75 NM. Let him have the radar in TWS-Auto and as soon as the radar gets the missiles it follows them in elevation. You should detect the targets at about 70 NM. Shoot as soon as you get solid tracks (the farther out you fire the better).
-
That would be great!
-
I think the HB's selection of quick missions is missing one of the Tomcat's and the Phoenix' signature job, that of destroying anti-ship cruise missiles. I therefore went ahead and created these two small and simple quick missions, featuring a deck launched intercept against incoming ASM, either low flying SS-N-12 Sandbox or high flying AS-4 Kitchen. F-14A_QuickMission_Vampires_AS-4.miz F-14A_QuickMission_Vampires_SS-N-12.miz For the AS-4 mission I reduced the loadout to just 4 Phoenix and nothing else, as the F-14A cannot currently haul more to the speeds and altitude necessary to make the intercept work. I don't know if this still is supposed to change in the future or not. If so it might be possible to add additional Phoenix. The Phoenix performance against the AS-4 is a bit hit and miss at the moment and results can greatly vary. This used to work a lot better at some time in the past and I am also not sure if this is related to current Phoenix issues and is supposed to improve in the future. Can you defend your battle group? Have fun.
-
I can also confirm the temperature spike at 1.1M, 30'000 ft. Caucasus map, 12°C at sea level. I can't consistently reproduce yet, but happened multiple times after a carrier launch, climb to 37'000 at M0.9 and pushover to accelerate through the trans-sonic zone. At about M1.1 the temperature spikes and depending on how fast you accelerate, the engines blow or return to normal at M1.2. Thanks for the trans-sonic drag fix. Does this conclude drag fixes, or is the AIM-54 ordinance drag something that will still be adjusted?
-
Today's hotfix solves this.
-
Thank you, with your mission I could reproduce the problem and find the bug. The missile misses if there are two aircraft in the target group. If you reduce the target group to only one aircraft, the missile tracks and hits.
-
I can't reproduce this. AIM-7MH shots from <5 NM from the rear hemisphere with P-STT (PD-STT doesn't work under these circumstance) against a non-maneuvering Il-76 with no chaff are guaranteed hits for me. Can you set up a sample mission with the parameters where this happens for others to check? Tail-on launch from 5 NM with AIM-7MH. Missile lofts (shouldn't loft be prohibited with a pulse lock?). Missile connects to a kill. 90° aspect shot with AIM-7MH from about 3 NM.
-
Yes I can confirm, this is a bug.
-
I had a look at this as well. Target is a non-maneuvering Il-76 set to no reaction and no chaff, flying at 20'000 ft. Target aspect is 155° to give the missile some work with a little crossing angle. Shot AIM-7MH in PD-STT. Missile hits when shot at 25 NM and misses when shot at 27 NM or beyond. Here is one of the 27 NM launches that misses: Setup at launch. Note missile speed 523 KTAS and 0.9 G. Note missile speed 521 KTAS and 1.0 G. What I noted with the 25 NM shot that hit is that the missile remained at 0.9 G to impact. It seems that when the missile speed drops to about 520 KTAS, the missile stops guiding and goes ballistic at 1 G, passing behind the target. Whether that is realistic or if the missile should be able to continue guiding at this speed I cannot judge. I don't know the exact specs the AIM-7MH should have, but considering the setup (medium altitude, subsonic launch, subsonic target, crossing angle) a 25 NM range against a non-maneuvering target sounds plausible. I have also shot the AIM-7F and AIM-7M against the same target, but since they do not loft they run out of speed way earlier and have no hope to connect beyond 15 NM. Again I don't know if that is realistic, but considering the setup (medium altitude, subsonic launch, subsonic target, crossing angle) it at least seems plausible. I haven't checked against maneuvering targets and just wanted to check the theoretic performance against non-maneuvering which the quoted post suggest are wrong, which I cannot confirm.
-
*Forum just ate all the text I wrote and only posted pictures, will try again*
-
Like I said above, over water at 20'000 ft and 30 NM, being slightly below the bandit the switch works, being slightly above the bandit the switch fails and the lock is lost. In the mission I provided this is 100% reproduceable. So considering that you are saying it should work, this is definitely a bug.
-
Well I just now ran a number of tests, about 15 different attempts. Over water at 20'000 ft against a MiG-23 coming straight at me. Ordered Jester to switch from PDSTT to PSTT at ranges between 35 NM to 10 NM. Every single attempt when being higher than the target (even just 1'000 ft) resulted in a lost lock. When I was just a couple hundred ft below the bandit the switches were successful (provided it was the first attempt, as described above). Jester attempting to switch automatically at around 10 NM while supporting a Sparrow against a lower target resulted in a immediate lost lock (cause was not a notch). Mission is attached if you want to check it out. PDSTT_to_PSTT.miz
-
I just figured this out as well. Had Jester lock a target with PDSTT in a look-down situation. Then ordered him to switch to PSTT, which he complied with and the lock was lost during the attempt (due to the look-down situation, which is to be expected). Had him lock the target with PDSTT again, then ordered to go PSTT again. Jester acknowledges but does not actually switch the mode. Going back into the RIO pit confirms the lock remains in PDSTT. Also when approaching 10 NM and Jester automatically announces that we will switch to PSTT, the lock remains PDSTT. Another issue with Jester's automatic PDSTT->PSTT transition (when he actually does it) is that he seems to attempt it regardless of the target's elevation. If in a look-down situation his switch attempt at 10 NM will default to a lost lock, which is a very critical timing and especially annoying if you already have a Sparrow in flight. Having realized this now, I have disabled Jester's automatic switching. I think it would make sense for Jester to not attempt to switch in a look-down situation or while supporting a SARH missile. As a side question, how is PAL able to lock targets at up to 15 NM in a look-down situation? I think I understand the physics why you cannot initiate a PSTT in look-down, so how can the pulse mode PAL do it?
-
IF Heatblur indeed were to make the Phantom, then the naval variant would be a lot more likely because of its similarity with the F-14. RIO instead of WSO (no dual flight controls) for which they could simply copy Jester and an early analogue PD radar which they already did for the Tomcat.
-
For completeness, here is the comparison of level acceleration at 30'000 ft between clean F-14A and F-14B: Mach 0.9: 0:00 - 0:00 Mach 1.0: 0:26 - 0:15 Mach 1.1: 1:00 - 0:29 Mach 1.2: 1:26 - 0:42 Mach 1.3: 1:46 - 0:55 Mach 1.4: 2:02 - 1:07 Mach 1.5: 2:15 - 1:19 Mach 1.6 2:29 - 1:32 Mach 1.7: 2:44 - 1:49 Mach 1.8: 3:04 - 2:13 Mach 1.9: 3:31 - 3:41 (B topspeed) Mach 2.0: 4:34 - X (A topspeed) The A still looks very sluggish in the trans-sonic area. Is the difference to the B really supposed to be this large? Shouldn't thrust of the TF30 catch up at this point?
-
This is just a very quick and dirty test. Spawn at Mach 0.9 at 30'000 ft and measure time to accelerate in level flight. First column loadout 4-4-0, second column loadout 2-2-2, third column louadout 2-2-4. Spawn at full fuel, no fuel tanks. Mach 0.9: 0:00 - 0:00 - 0:00 Mach 1.0: 0:38 - 0:43 - 0:58 Mach 1.1: 1:57 - 2:34 - 10:01 Mach 1.2: 2:59 - 4:03 - 12:19 Mach 1.3: 3:40 - 4:55 - X (2-2-4 out of fuel) Mach 1.4: 4:06 - 5:26 Mach 1.5: 4:29 - 5:52 Mach 1.6: 4:52 - 6:19 Mach 1.7: 5:20 - 6:52 Mach 1.8: 6:14 - 8:28 (2-2-2 topspeed) Mach 1.84: ~8:00 (4-4-0 topspeed) Now I am no expert and don't have the manual, but 4 minutes to move 2 Phoenix from Mach 0.9 to Mach 1.2 sounds excessive. Also it has been my understanding that somewhere around Mach 1, the TF30 is about as powerful as the F110. So I wonder why supersonic performance of the A is so much worse than the B.
-
Yes, that is a bummer. From having the Phantom in development to "on hold" to "probably done by someone else" is a major downturn. But perhaps this will open the door for Heatblur doing it as a naval variant with Jester as RIO, which would make a ton of sense.
-
Here are some of my first quick impressions on the FM changes. The F-14A turn rate feels better. I have been flying the dogfight quickmission against the Israeli F-15C a lot and it is now noticeable easier to out-turn. Trans-sonic performance is still bloody awful. This is very disappointing. Fuelflow and power settings for the F-14A in the pattern and the groove are now higher and feel a lot more reasonable. 4000 PPH seems to be the baseline power setting for on-speed in the downwind. With the higher power, managing AOA and the ball in the groove became a lot more easier again. Over the past month I had considerable trouble with flying good approaches, which I felt was because of the unusually low fuel flow. Now I just flew a couple of very nice approaches with rock solid AOA and a fine ball control. The Tomcat feels great in the groove again and I am very pleased with it.
-
I am sure this will make a lot of people happy, this is clearly one of the remaining "big ones" of 90s sim fame. Personally I feel pretty indifferent about it, another flying computer. I had hopes that it would at least have been a steam gauges AH-64A.
-
There you have it, Apache was obvious all along.
-
Trans-sonic performance of the F-14A still seems to be the same. Armed, the jet struggles to go supersonic in level flight. I thought that has been fixed. Very disappointing to have to see this for another month. Very well put. Are you suggesting that this is the behaviour we should expect from the F-14A?
-
Yes, generally if you want to keep altitude you would need forward stick with more power (accelerate). If you want to keep speed, you would need back stick with more power (climb). Now since the last patch with the Tomcat, to keep speed you need a little forward stick with more power. The cause is probably because the low sitting engines push the nose up. This reversal of power-AOA interaction is something I need to get used to again in the groove.
-
I think with the last patch, staying on-speed in the groove became a lot more difficult. With the aircraft trimmed for on-speed in level flight, reducing power to descend will decrease the AOA. This caught me of guard, as generally a reduction of power will go in-hand with forward stick and applying power with back stick. This seems to be new behaviour since the latest patch, as before I think decreasing power would increase AOA, requiring forward stick to correct. Now it is the opposite way around. I guess is related to the following adjustment. Is a thrust axis below the center of drag the reason for this behaviour in the Tomcat?