DTOS point of impact jumps during high-altitude delivery
-
When delivering bombs in a high-altitude dive in DTOS, the point of impact cursor jumps when designating with TMS up. Attempts to move it back on-target cause it to jump around:
A similar issue seems to occur when using CCCIP-to-CCRP (where you designate a target in CCIP when the actual impact point is below the HUD; apologies if I’m using the wrong terminology). The impact point and the corresponding ASL shift from where the pipper was right before holding the pickle button:
Frames immediately before and after:These issues are easily reproducible on the KTO GP bomb training TE:
-
Hi!
Please reproduce on KTO to report on main Technical room, or post this bug on the appropriate theater room (it could be an elevation issue of the 3rd party theater).
Regards.
-
-
As johku said, the original post reproduces it in KTO, using the GP bomb training TE. Please see the video links at the end of the post:
@mrkline:These issues are easily reproducible on the KTO GP bomb training TE:
-
What happens over the water?
-
The same behavior is observable over the water:
The CCIP impact point jumps on designation, as does the DTOS impact point. When slewing the DTOS impact point, it often jumps once you stop moving it.
EDIT: After trying a few different scenarios, the jumping seems proportional to the wind speed and direction. It’s almost as if there’s some inconsistency as to how wind correction is being applied to the impact point (before vs. after designation in CCIP, and stationary vs. slewing in DTOS), which causes it to skip around. This would also explain why the jumping seems worse at higher altitudes.
-
i have noticed that blks 50/52 is very consistent when in DTOS mode but 40/42 and below are not, can someone confirm?
-
This still occurs in 4.35U1. The designated point (in both DTOS and CCIP post-designate) seems to jump in the same direction as the wind. It also seems to jump by a fixed distance regardless of the ownship altitude, which means the angle of the jump increases as you get closer to the target.
Clips from 4.35U1, with the GP bombs TE:
Point jumping on designate: https://streamable.com/4rdapy
Point “snapping back” against the wind when moved: https://streamable.com/qzbbax -
ground intersection accuracy issue.
The better resolution the terrain will be , the less visible to problem will be
-
Thanks for looking into it Mav-jp.
Could you help us understand the scope of the issue a little bit better? I’m pretty sure we see an identical problem at sea level over flat terrain (it repros in ITO for example). I’m also pretty sure it applies as a function of winds aloft.
High winds aloft -> big jump/offset in the pippers.
No winds aloft -> no jump/offset in the pippers.I can try to repro/confirm these when I get done with work today.
-
I’m guessing you see this behaviour at steep dive angles and wings not level
-
We ran some more experiments, and we’re confident the problem is not related to ground intersection - the exact same problem happens over open ocean. We learned a few other interesting things:
- My original intuition was wrong - the jumping doesn’t seem proportional to wind speed. We see similar jumping behavior with 50 knot winds and 0 knot winds.
- The jumping - both when designating in DTOS with TMS up, and when slewing the TD box after designation - seems proportional to aircraft pitch. The steeper the dive angle, the larger the jump.
- The direction of the jumps is always perpendicular to the pitch ladder, regardless of the plane’s roll. TD movements parallel to the pitch ladder (e.g., up and down when wings are level) are preserved.
A brief demo video: https://streamable.com/xh9ptz
Points 2 and 3 lead us to think the bug might be related to translating the HUD’s coordinate space to the world’s coordinate space - possibly with some asymptotic behavior when the jet is pointed straight down?
-
We ran some more experiments, and we’re confident the problem is not related to ground intersection - the exact same problem happens over open ocean. We learned a few other
thats a ground intersection function issue.
Related to innacruacy in the different transformation in the ground intersection function that uses quaternions extensively.
it does not matter if terrain is flat or not,
it’s relatively well know, and it is very far in the bottom of our priority list (at least mine, dont kow for tumbler )
Edit : unless i fixed it already, but i dont remember well…4.35 is too old already
-
[…] The jumping - both when designating in DTOS with TMS up, and when slewing the TD box after designation - seems proportional to aircraft pitch. The steeper the dive angle, the larger the jump.
[…]As I predicted above
[…]
it’s relatively well know, and it is very far in the bottom of our priority list (at least mine, dont kow for tumbler )
[…]Ran into it for something else, so fixed it.
-
Edit : unless i fixed it already, but i dont remember well…4.35 is too old already
Don’t reference a build that we don’t have. (And probably won’t have for at least a year.) It serves no purpose and is extremely pompous.
-
Don’t reference a build that we don’t have. (And probably won’t have for at least a year.) It serves no purpose and is extremely pompous.
Fact is that everyone - with some knowledge of BMS community - know that current developpement is between 1.5 and 2 years ahead of current public version.
Fact is that this part of code has been modified In The last 2 years because was part of a bigger plan
Fact is that I communicate that I don’t remember if I fixed it or not , good news tumbler fixed it
So one the one hand when we don’t communicate we are tagged as arrogant , and when we communicate now we are Pompeus because we state for a fact that we are developing
Wow man !!!
You wish to have some news about development ?: be ready to discover that we can talk about things you will not see in the next 3 to 4 years
Sorry to be pompous I don’t feel I am
-
Fact is that everyone - with some knowledge of BMS community - know that current developpement is between 1.5 and 2 years ahead of current public version.
Fact is that this part of code has been modified In The last 2 years because was part of a bigger plan
Fact is that I communicate that I don’t remember if I fixed it or not , good news tumbler fixed it
So one the one hand when we don’t communicate we are tagged as arrogant , and when we communicate now we are Pompeus because we state for a fact that we are developing
Wow man !!!
You wish to have some news about development ?: be ready to discover that we can talk about things you will not see in the next 3 to 4 years
Sorry to be pompous I don’t feel I am
You are not, but you Devs have the Right to be as pompous as you like! You do the hard work! You deserve at least that. So …. Be pompous AND proud for the grate job you have been doing! :Yo:
-
You are not, but you Devs have the Right to be as pompous as you like!
That’s a very strange attitude. Treating those around you with patience and charity is important, no matter who you are or what you do.
Just as the devs work very hard to develop BMS, many members of the community spend their precious free time debugging problems, or building free tools. They do this out of a love for the game, and to help make the BMS experience that much better. I would hope there’s some mutual respect between everyone involved.
-
So, this is fixed in an upcoming version of BMS then? We can mark the issue as “Resolved” then… is this likely to be a “future Update” or a “future Version” type fix?
-
Well…
Whether you like it or not, we live in the future within the dev team. Development is about making sure a new code feature is stable and accurate enough for release…
Now, it is impossible to remember every bit of code given that there hundred of thousands lines modified between major versions…
It is what it is…
Hold your comments next time please, it serves no purpose here in the end.
Cheers