CCRP release parameters
-
Slight hijack - but is there a quick ‘realistic’ way of switching between CCIP and CCRP? E.g. on the HOTAS?
I see guys doing it in youtube but assume they’ve mapped it as a shortcut… The only way I know of switching between the two is via the MDF buttons.
Thanks
-
I created a simple Tactical Engagement with a single F16 and a few steer points, loaded with 12 MK82LDGP bombs and a centreline tank. I have been using this the last 2 days to experiment with CCRP mode, since I am having the same issue in my campaign (bombs not coming off the plane). I set the bombs to 1 Pair/RP 1 so that they release 2 at a time to keep the plane symmetrical, just like I was doing in my campaign, for a total of 6 bomb runs each time I run the TE. I was just aiming at random steerpoints and dropping, mostly (not always) from low level, and mostly (not always) trying to loft when the first cue happens. The steer points were not aligned with any target, the test was just to see if the bombs would release. I have run this TE at least 20 times over the last few days, 6 bomb drops each time.
I have experimented with:
- Different Rel Angle settings (seems to affect when you see the release cue, but no affect on whether the bombs would release)
- Ramp start where I must enable master arm vs Runway start where master arm is already enabled (no difference)
- Level VS loft bombing at different angles (both work)
- Pulling up immediately after the circle flashes vs waiting for different times (it only affects the angle I get to before the bombs release … earlier pullup = steeper angle)
- Different speeds (only affects how early the flashing circle happens, faster = sooner)
- Overspeeding the aircraft (I went as high as 600 knots briefly a few times, but the bombs still worked)
- Over G the aircraft … as high as 6.0 a few times but they still worked.
- Different pages visible on the MFDs, just in case there is some weird bug there
- Holding pickle button down up to 30 seconds before release vs 1 second before release
- Probably other factors that I have forgotten now
The result after more than 100 CCRP releases was that the bombs came off the plane cleanly every single time.
Next I went back to my campaign, and the very first mission the bombs failed to release from the plane in CCRP mode (lofting). I did absolutely nothing different to any of the tests in my TE … same weapon type, same settings, same cockpit setup, same parameters. I switched to CCIP mode and the bombs released first try, so the bombs weren’t over speed/over G, and I had no faults on the jet.
So my question is, why does CCRP work perfectly every single time in a test TE, but fail to release regularly during a campaign? The biggest difference between the two on my machine is the frame rate. I got roughly 100 FPS in the TE, and usually around 50 - 60 fps in the campaign. Is this a factor? Is there a way to cap my frame rate in the TE to see if it then has the same issue?
-
I should add that CCRP doesn’t always fail to release bombs in my campaign … it seems to fail about 25% of the time.
-
Slight hijack - but is there a quick ‘realistic’ way of switching between CCIP and CCRP? E.g. on the HOTAS?
I see guys doing it in youtube but assume they’ve mapped it as a shortcut… The only way I know of switching between the two is via the MDF buttons.
Thanks
Tofu, use MISS STEP button
-
I finally worked out how to capture video. I caught a video of CCRP failing to release bombs in a campaign. This is 2.57 of the Korea 1989 theatre:
The jet has 6 MK82s, 4 AIM9, 2 tanks and an EGM pod. It is set to drop bombs in pairs, and the Rel Angle is the default 45 degrees.
From watching the video it looks like I started the pullup in full afterburner at around 5 miles from the target, and was travelling 520 - 525 knots. I also held the pickle button right as I started the pullup.
I tried to recreate these in a simple TE, and bombs released with no issues:
I only uploaded this recording but I tried it several times and bombs never failed to release. I re-flew the campaign mission (I had discarded it) and bombs failed to drop again.
The two videos aren’t exactly the same, but they are close enough that I cannot work out why bombs drop in one case and not the other. In both cases, the drop cue thingy hits the flight path marker. I also tried in both environments a couple of times and got the same results.
-
When did you press the pickle on the first video?
-
In the first video, you pull up a little bit late and it looks like the release cue never actually reaches the FPM, thus not completing the solution. Pull up 4-5G as soon as the reticle stops flashing.
-
In the first video, you pull up a little bit late and it looks like the release cue never actually reaches the FPM, thus not completing the solution. Pull up 4-5G as soon as the reticle stops flashing.
It also seems to me that the pull up was too late and shallow, moreover you were probably also too slow, so the CCRP didn’t reach a solution (your bombs would fall short). You probably should have accelerated sooner with so much ordnance you are quite draggy and low level lofts are problematic without good starting energy.
-
In the first video, you initiate a release command (pickle)at 0:28 seconds and terminate it at 0:32 before you reach the release queue.
You can tell by the weapons REL /RDY status on your SMS page.
Pay attention to weapons status. Also take in the advice given -
In the first video, you pull up a little bit late and it looks like the release cue never actually reaches the FPM, thus not completing the solution. Pull up 4-5G as soon as the reticle stops flashing.
It also seems to me that the pull up was too late and shallow, moreover you were probably also too slow, so the CCRP didn’t reach a solution (your bombs would fall short). You probably should have accelerated sooner with so much ordnance you are quite draggy and low level lofts are problematic without good starting energy.
In the first video, you initiate a release command (pickle)at 0:28 seconds and terminate it at 0:32 before you reach the release queue.
You can tell by the weapons REL /RDY status on your SMS page.
Pay attention to weapons status. Also take in the advice givenWhile these are all valid points, I think it kind of misses the true point. You’re diagnosing a specific instance of video, but he stated that not only did he experience the same issue multiple times on multiple flights in a campaign environment, but he has no issue in the TE…ever. The bigger picture with a little extrapolating thought process indicates that it’s not a procedural issue if he can successfully complete the task every time in one setting, yet not in another. To say it’s procedural at this point would infer that strictly by chance, he messed up the procedures every time they didn’t drop while flying in a campaign setting, and got the procedure correct every time while flying in a TE. Given that he has stated he has run the tests on both TE and campaign several times, with several attempts per test, and the results are always the same (Given the ~25% fail rate in the campaign) the statistical odds of that specific scenario occurring (Scenario being that he consistently ONLY messes up in campaign and NEVER messes up in TE) are less than being struck by lightning several times in your life and winning the PowerBall. If the test results were “It happens much more often in campaign than TE”, then your argument would hold much more weight. But, given that he has not been able to reproduce it even one time in TE, despite actively trying to reproduce it, indicates it is not a procedural issue.
As always, just my personal opinion…
-
That’s why I ask about when he press the pickle button. Again, I think it was pressed way to early. In campaign, with some stutter, the press can be unlatch if pressed to early. That why the rule of “2sec before the drop” still applied.
-
As always, just my personal opinion…
I would wonder though if his TE shares the same atmospheric parameters as the campaign. I see fair weather in campaign, but sunny in TE. By default, fair has a greater wind speed than sunny. Indeed, in his Campaign video, he is looking at an almost 13 knot headwind. Unfortunately there is no wind data on the DED in the TE. The wind alone can alter release parameters.
Flying tighter parameters would allow this to be overcome. Flying exact like for like (as much as possible) needs to be done before “campaign screwed” can even be considered. IMHO
-
Thank you for all the replies! I will be trying out everything suggested for sure.
Pushing the pickle only 2 seconds before the drop is an interesting suggestion. I did not realise that it could be unlatched if the game stutters. I am not aware of stuttering instances during the tests, but my campaign frame rate is definitely much lower than in a TE.
For the comment about pulling up earlier so the bombs don’t fall short … wouldn’t the opposite be true? That is, the later you pull up, the closer you will be to the target?
The weather/headwind comment is not something that I had factored in. I have generated weather for the campaign, but whatever the default it for the TE. Do the CCRP indications on the HUD take headwinds into account? I wonder whether I should be checking whether I have a headwind before each release. I will try some experiments tonight. I am guessing that in a headwind you should pull up later, and with a tailwind you can pull up earlier, correct?
Thank you again for all the input, it is truly appreciated!
-
I’m not necessarily saying it’s an issue of campaign screwed. But there are notable differences in how the engine processes information in the campaign vs a TE.
Someone in another thread discussing FPS shows a clear difference in the amount of data being processed in a campaign environment vs a TE–observable by a considerable drop in FPS during a campaign vs a TE which the OP also noted earlier in this thread–so it is very likely there is something going on in the campaign engine that is causing the release command to be obscured or skipped. The FPS drops 30-50% for a lot of people in a campaign vs a TE from what I have seen/read on the forums. With that in mind a few questions come to mind that could have an impact on this discussion:
How tight is the window in the code to check for drop profile parameters being met?
How is the test structured?
How is it told to “reset”?There is a window for dropping, and it is quite small, so the difference in 20-30 FPS can make a huge difference depending on just how small that window is. Since I am almost positive position is calculated based on DELTA TIME from last frame, that means it is quite possible the window is so small that the drop in FPS is causing the aircraft to fly through the drop window before the position calculations occur on the next game loop cycle.
The logic behind it being that the CCRP is accurate to a couple feet in game right? 350kts is ~180m/s. So at 60fps you are moving ~3m or 10ft per frame. If the release window is smaller than 10ft then there is a very likely chance you will miss that window. The closer to 0 that window gets, the higher the chance of missing it. I have no way to tell, but I would guess it’s a 2m window–which is about ~66% of 10ft so the math is pretty close to the error rate the OP is experiencing give or take a little for varying FPS, small margin of randomness for the position between frames, and ± 10-15 kts airspeed.
EDIT: I re-read the flight characteristics of the OPs test and he is flying considerably faster than 350kts. However, the theory still holds weight–faster speeds mean more distance moved in an elapsed frame, but the window is likely bigger than 2m or it would be a much higher error rate.
-
For the comment about pulling up earlier so the bombs don’t fall short … wouldn’t the opposite be true? That is, the later you pull up, the closer you will be to the target?
The weather/headwind comment is not something that I had factored in. I have generated weather for the campaign, but whatever the default it for the TE. Do the CCRP indications on the HUD take headwinds into account? I wonder whether I should be checking whether I have a headwind before each release. I will try some experiments tonight. I am guessing that in a headwind you should pull up later, and with a tailwind you can pull up earlier, correct?
Thank you again for all the input, it is truly appreciated!
No, you should strive to pull up when the computer tells you. The reticle is solid for two seconds - this is yours “heads-up” that within two seconds you are going to have to pull.When it flashes you should begin your pull, smoothly, and aim to be pulling 4-5G by the time it stops flashing and disappears. Don’t worry about headwinds and tailwinds, the computer does all that for you. Hitting the parameters is your only concern.
Be sure to let us know how you go tonight
-
I’m not necessarily saying it’s an issue of campaign screwed. But there are notable differences in how the engine processes information in the campaign vs a TE.
Sorry, it was a kinda tongue-in-cheek comment.
A lot of your post makes sense - definitely one for the coders to answer conclusively. Anyone would be speculating, but I appreciate what you are saying. :thumbs-up:
-
While these are all valid points, I think it kind of misses the true point. You’re diagnosing a specific instance of video, but he stated that not only did he experience the same issue multiple times on multiple flights in a campaign environment, but he has no issue in the TE…ever.
Not missing the point at all. Maybe I phrased it incorrectly as I do seem to suggest that it is a definite procedural issue.
Let me try again.
In the campaign video, the weapon release command is terminated before the solution cue hits the FPM.
He should observe if that behaviour is repeated. -
My point about missing the point though, was that obviously he has been successful in both the TE environment AND the campaign environment most of the time–which infers he can successfully perform the task on a consistent basis. That being said, you can safely assume he is performing the procedure correctly even in the occurrences where the stores fail to release. Even if that specific instance in that specific video could be attributed to operator error, it is somewhat of a moot point (In my opinion) because it is highly unlikely that the same operator repeatedly made the same error, using the same “personal procedure”, but ONLY in the campaign environment. It’s just a lot of coincidence all having to line up that by chance he never made the same error while in the TE environment, despite making multiple attempts and actively trying to recreate the issue. Statistically not impossible, just highly unlikely.
Furthermore, plenty of other people, myself included, have experienced the same issue. I always hold the pickle all the way through. In 650+ views of this topic nobody has stated they experience the same effect during a TE, but I know from personal experience plenty of people during MP campaigns experience it regularly. The odds against it being something this person specifically did are just really really low.
-
I dose not change the point that the release command is terminated. The question is why. If he and repro, this behaviour,we have a starting point.
-
Different Rel Angle settings
All the REL ANG setting does is change the loft HUD cues. The actual CCRP release math is unaffected. If you were to fly the exact same physical trajectory the REL ANG setting wouldn’t change anything. However if you’re flying the symbols then different REL ANG values will prompt your maneuver at a different time with obvious consequences.
No, you should strive to pull up when the computer tells you.
Sadly if lofts are done by the book and symbols, the maneuver will be too early kinematically. It’s a fault of BMS and requires a compensation by the user.
The assumptions are MIL selected (who wants to make a hot target for an IR SAM?), 4G in 2s (good tip to think of G coming on by the end of flash), and held through release. The bomb is supposed to come off while the G meter says ~4 and the nose is rating quite fast. The post-release recovery is to continue the pitch rate and slice back nose low.
This thing where BMS pilots do a hard pull up to a set angle and then unloaded to climb in a straight line to release is not how it’s done. On YouTube at least 90% of examples get it wrong. These 2 videos are better in that the plane isn’t unloaded to 1G or less but it certainly isn’t a constant 4. Had the WR button been held when the TTRN said 0:00 it probably would have come off. Notice how the time to loft shows 0:00 and the pilot waits 3-5 seconds? That’s a fudge factor. BMS just needs a bigger fudge factor. If he would have initiated his pull up at exactly 0:00 (as you’re supposed to) the first time he would blow through 45° with no release every time because the symbols activate too early.
I found that if you substitute a different REL ANG (<45) you can get the timers and symbols to indicate appropriately for an angle larger than the one you entered. E.g. if you put in REL ANG 15 you might get a release at 22 and if you put in 22 you might get a release at 40. With some trial and error you could develop a rule of thumb. I can say that don’t chase the last 5 degrees or so and consider a release at 40 to be absolutely as good as one at 45. The difference in ballistic range between those two angles is negligible. Since LAT is primarily to minimize time exposed and altitude gained losing 500’ of standoff is no concern. Getting releases in the 40-45 range is all risk and no reward. I would say 35-40 is the sweet spot.
You should find the CCRP much more eager to release at loft angles <40 degrees and with a constant and relatively high load factor throughout the maneuver provided the maneuver was started close enough to the target.
I feel a little betrayed that lofting delivery was never mentioned in post #1. Lofting is a specific case that has a history of problems in BMS. Is this also happening with level releases?