CCRP release parameters
-
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?
-
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.
FWIW, the jet is continuously calculating a release solution, so once he’s inside of max loft range he’s “a little bit late” ONLY in terms of a maximum distance loft. The bombs will come off sooner (a lower nose high pitch) the closer you get to the target. Afterall, if he simply held down the pickle button and flew straight and level directly over the target the bombs should release at some point in space. That would be a valid test for the OP. Attempt to fly level CCRP deliveries in his Campaign.
As an aside, I suspect it’s just a simism, but in his TE video I heard snakeye at release. Maybe BMS defaults to calling all Mk-82s snakeye upon release?
EDIT: Frederf makes a great post, it’s what I was thinking that guys should experiment with just 30-40 degree pullup.
-
After doing more testing tonight, I think we are the victims of 2 separate bugs.
Bug #1
I believe that the CCRP calculation has the wind direction reversed. In my campaign save file (the one from the video above) I played with invulnerability and unlimited fuel so I could experiment, and discovered that if I attacked from the other direction (with a tailwind) using the same speed and pulled up when the loft cue appeared, the release cue moved smartly down the line and hit the flight path marker no problem. When I did it with a headwind, the release cue moved very slowly down the line and barely touched the flight path marker before moving back upwards. I think it is safe to say that it never reached the centre of the flight path marker, which would be required to trigger a release.
Also, look at this screenshot from testing tonight:
The wind is coming from my right, but the steering line is to the left (downwind) of the target. Surely it should be upwind of the target.
To be sure, I added an 80 knot wind in my test TE (the max it would allow me to add). In the 3D world the DED showed the wind speed varying from about 65 to 75 knots. I noticed that flying on the deck at full mil power (roughly 550 KCAS) with a tailwind, the last flashing circle disappeared at around 5.0 NM from the target. With a headwind, it was around 5.6 NM from the target. This is backwards!! With a headwind you must be closer to the target.
I think that in a campaign if you have a decent headwind and pull up as soon as you see the loft cue, the release cue will not actually make it all the way to the centre of the flight path marker because you pulled up too early.
Another indication that the wind direction is reversed in the calculation … in my TE with the strong winds, when dropping with a headwind the bombs landed very short, but with a tailwind they landed very long … but in both directions they seemed to land in the same spot (based on the black marks on the ground).
(For the devs if you are reading this: I bet CCIP has the same issue)
Bug #2
Thank you whoever pointed out that the SMS shows REL or RDY based on whether the pickle button is pressed. I hadn’t noticed this before. During a couple of tests tonight I looked down and saw RDY even though I still had the pickle button down. I think this may have happened in the campaign video I posted, since I know I had the pickle button down well past the time when the release cue was near the flight path marker.
I did some tests to see how long I could hold the pickle button down before it flipped to RDY. It happened anywhere from 1 to 20 odd seconds. I think 25 was the longest I made it. This is in campaign mode. When I went back to the TE to try this, I made it to 2 minutes before I gave up. In other words, holding the pickle button down is perfect in the TE, and problematic in the campaign.
Pushing the pickle button as close as possible to the release point is good advice, because it seems to be quite unreliable. Based on my testing there is no specific safe time that it can be counted on to trigger a release. I think that for CCRP drops it is wise to have the SMS screen up and glance regularly at the REL/RDY notation to make sure it is registering that the button is still down.
It looks like the logic in the sim is that once the button appears to be released, it won’t register another press until the physical button is released. Can this logic be changed for CCRP mode? I am assuming that the code is polling the state of the buttons every frame. Surely if the button appears to be down and the system is in CCRP mode, then treat it as down.
Anyway, I think I have been bitten by the first bug occasionally in my campaign, (because I have noticed the release cue having a tough time making it to the flight path marker a few times), but a lot by the second bug. All CCRP drops (level or lofting) would be affected by the second bug. Everyone’s system and experience of this would probably be different, but for me only pressing the button a few seconds before release isn’t enough to guarantee a drop, as the status can flip to RDY on my system in as little as a second in campaign mode.
Hopefully someone from the BMS team notices this thread and can check the relevant code.
-
Bug #1 - the wind is coming from your left in that screenshot. You are tracking 025°, with wind coming from 332°. The azimuth cue is biased to the left, into the wind, with the target to the right, downwind of the solution.
Bug #2 is a longstanding issue, which is why BMS wings train to press the pickle a couple seconds before solution, instead of the prototypical pickle to consent, unpickle if situation changes.
As far as the long/short head/tail wind stuff for bug #1, that might merit further investigation IMO.
-
FWIW, I can remember all the way back to the Superpak/FF days as the cue hit the FPM, release the pickle and instantly consent again. Just because of this situation. Don’t know if this is still the same ole gremlin. I’ve just carried it with me through each iteration of F4. Bombs always come off… shrugs. This is for CCRP. With CCIP I’ve never had to re-consent.
-