RAZBAM_ELMO

Just so there no confusion or thinking this is a Mirage issue, testing this over other airframes like the A10, F18, F-16, JF-17 and Harrier, the behaviour is the same across all the platforms. So that means that it is down to the user to practice and follow bombing tables. If you are curious to know what these may look like then you can have a look at the declassified bombing tables for the F-5 which should give you a rough estimation for what speed, and altitude you should be bombing at.

Yes, however the post you linked was posted before this post and therefore this post became a duplicate which was unessesary

Just an update, the team and CB testers are having difficultly replicating this FM bug as it is a very isolated issue. We are experimenting and exploring options to rectify it.

Perhaps not jumping the gun and assuming were ignoring it first off. Second It has been reported and I simply forgot to adjust the post.

If it is a CTD then we need a .log file as explained in the HOW TO REPORT posts stickied at the top.

trk file showing the issue please.

trk files of the issue please.

YEs this is intended behaviour to reduce engine stress at lower altitudes. For future reference please do not link your trk files out of the forum, insert them into your post. Moving to resolved as intended behaviour

its not bad, it just has a separate purpose. And as stated above this may be implemented as a second gunpod in the future. Moving to resolved as FUTURE IMPLEMENTATION

Moved to resolved as USER ERROR

Draken I am going to need a .trk file from your end please to file this report.

As Ramsay said it is a known bug affecting all modules with ILS. Moving to resolved and tagged as DCS issue

Tracking thankyou.

I'm not sure whether this is intended behaviour but I will check. If it is as intended I'll make sure the manual writer provides a better description in the manual.

A .trk file is most definitely required.

Just to update, i found out not 5 minutes ago that the behaviour experienced will change on the next update so standby for the next drop.

As it has been stated before. The locking logic for the 65F requires the crosshairs to be centered on the center of the #D object you are attempting to lock because the DCS engine does not work on contrast like the real thing, it works on asking the game if its at the center of a target and locks there.

Again, will move this to resolved as it IS AS INTENDED. The dev team have investigated the issue thoroughly and have not been able to find a fault. However if you have a separate issue concerning the slew in TDC and switching ti MAV mode then please make that as a separate post with a trk and we will investigate.

I am by no means dismissing the case nor am I ignoring it. I did ask the SME and am awaiting his response. However at this time with the information available and provided it cannot be considered a major or gamebreaking bug requiring the attention of the dev team, more like a side note to be addressed at a later time. I'm in the process of testing the theory that computing a point of impact in 3D space using a 2D logic in level flight will produce the long misses described using various aircraft from A10s to F18s and F16s. So far its all showing the same results, relative movement of the aircraft on the ground is greater than that in a dive therefore trying to aim at target always produces a miss because the impact point in 2D space is past or beyond the target due to the delay in releasing the munition. This is mater of fact and a CCIP drop with the HUD cannot compensate for the presence of a 3D target. Given the results I've seen, that is what prompted me to move this to resolved and labeling it as user error. During the tests we had individuals use the center of the pipper to get the long shots then compensating on successive runs by aiming in front of the target space which produced wither a hit or within a 5m radius of accuracy depending on individuals. In a dive it was the center and everyone hit within 5m. Sent from my SM-N960F using Tapatalk

Yes this other issue is known already. Moving to resolved, another sneaky update that made its way in

Sorry for getting to this one late, yes known and team has been trying different ways to work around it.

Moving to resolved, was slated for major update but somehow made it into a mini patch.

Previously mentioned bug, has already been reported.

Hi guys, sorry to ask but can you check again and see if this is still present in OB .55960? thanks

All of that is correct and makes perfect sense because of that eg. .5s delay where the relative distance the aircraft travels in the sky compared to if it were diving the distance covered would be shorter. Taking that into account and releasing at an earlier point would logically make sense because its a predicted impact point on a 2D landscape not accounting for a 3D object like a tank par example. How that is hazardous is confusing to me though and would require some explaining because the only difference is that you have to think a bit before your attack run and just note mentally that on a level flight path between 0 and -10 degrees that you release at the top of a pipper and not the center like you would do in a taller, steeper dive. Sent from my SM-N960F using Tapatalk