Renko

Sorry, let me rephrase that because I don't think I explained myself very well. I reported 2 things regarding DTOS. - 1) Is the discrepancy of behaviour when you use TMS button. You would expect same TMS Up behaviour when you use the HMCS to do a MarkPoint, and when you use it to designate for DTOS. Not 100% sure as i said, i bet your SMEs could tell you. Its just a minor thing i noticed while testing the other one, you can disregard this discrepancy if you want. - 2) The erratic behaviour when using DTOS mode on the HUD, and use TMS. This one is the one that bring my attention and i wanted to point out before. I made a new track with only this to be more clear on the issue. Sorry i know its hard to follow without knowing my inputs of TMS, i wish we had something for the tracks that display that, so please bear with me. First of all i'm not saying that DTOS logic or TMS is wrong. For DTOS on the HUD: - Fly the FPM with the TD Box to the Tgt, or Slew the TD box to the Tgt - Then TMS Up to ground stabilise Seems that something wrong is happening in DTOS mode using the TMS Up. As demostrated in the track, and easy to reproduce do this. If you go to DTOS HUD >> Slew TD Box (without designate first with the FPM) >> TMS Up >> then after that each time you press TMS Up it jumps, the FPM wont designate it. It jumps with some erratic behaviour, because after hitting TMP up it doesnt go to the FPM. That will make sense. But instead it jumps In this track for clarity: - First i put in the Active Pause. I designate slewing the TD Box to one point, but if i correct it and press TMS up it goes back to the previous designate. Which is weird. It should either just stabilise the new point or designate a new point marked by the FPM. - Then after Active pause is off, you can see the FPM designating the new tgt. Thats perfectly fine, if we asume correct the logic of TMS Up DTOS in the HMCS. - After i climb to gain some altitude it happens again. I slew the TD box and then you will se the box jumping around, but the FPM is not designating it. Its seems that something in the low part of the HUD is doing it. For some reason, I see this tagged as 'Check Procedures'. However, as you can see, I am not challenging the procedure and I did nothing wrong. Best regards! DTOS_TMS_up_Issue_HUD.trk

Currently the aimpoint for a multiple bomb drop with separation is not the center, as it should be. In CCIP the cross points to the first bomb impact. And in AUTO too. I added two track showing this. In the CCIP one you can see that even after i enter distance for the interval, the cross doesnt move to accomodate for that and point at the center of the predicted drop. Here are two other threads where ED officials confirms multiple times that the Center should be the Aimpoint Best regards! F18_AUTO_Aimpoint_Issue.trk F18_CCIP_Aimpoint_Issue.trk

I think there is an incorrect behaviour in the Chinook. When you do slingload the radar altimeter remains stable showing the rope lenght to the cargo. I think this is correct in other smaller helos, but incorrect in the Chinook. First of all the Chinook has its RadAlt sensors in the nose pointing forward (emitter and receptor) long way from the center hook. This helicopter is 30 meters long. null Then you have for the center hook a trapdoor for the crewchief, and there is a RadAlt gauge too. Just saw a video from the Spain Army with a F model, saying the crewchief uses that during night ops to help guide the pilot. And If you see the D model operators manual you will find this phrase a couple of times: "When external cargo is carried, the radar altimeter may occasionally indicate the distance between the bottom of the helicopter and the load." It says may occasionally , not continuously. null Since I don't think it's planned to model the occasional interference of a sling load with the sensors, I think it makes sense to correct the current logic. An let the sensors work even with slingloading. This would allow the sensors to work properly. Best regards! Chinook_Cargo_RAlt_Issue.trk

If you enter DTOS mode, the logic is that TMS Up is to ground stabilise. That works. BUT if while i'm ground stabilised i press again TMS Up it seems that it updates the position, and the TD Box moves position. I think that should not happen. In the track i added first i use the HMCS, and each time you see the TD Box jump is when i press TMS Up. It seems to follow the Aiming Cross. I dont think that should happen because the TD Box should not move, just update the coordinates. For example to create a MARK point TMS up is to update the coordinates. If i ground stabilise and move away the Helmet Aiming Cross and press TMS Up, the TD Box will not move to the new Aiming Position. Wouldn't it make sense for the logic to be the same for both situations? Not 100% sure on this one. But then in the track when i use DTOS with the HUD. After ground stabilised the TD Box, you will see the box jump and jump each time i press TMS Up. I dont think each time i press TMS Up it should jump, and this time there is no aim cross. Just the HUD. Best regards! DTOS_TMS_up_Issue.trk

The HOT3, which is launched from the Gazelle, is displaying some erratic behaviour. If you use the cockpit sights to aim above the horizon, it malfunctions. However, if you aim below the horizon, it will reach its target. However, if you initially aim below the horizon but then correct to a trajectory that is above the horizon from your point of view, it will malfunction. The last one in the series launched in the track goes upwards. I suspect this is the issue. The sight is not guiding the missile. The sight gets map coordinates and the missile goes there. So, when the sight points above the horizon, it won't have any coordinates to give to the missile. Consequently, the missile malfunctions. The tracks I added demonstrate all this. Regards! Gaz_HOT3_Issue.trk

I first noticed this behaviour some time ago. I considered reporting it in the hope that it would be resolved. It's very noticeable. Try using a Gazelle, since it uses the HOT3, and see if you can replicate the issue. You will see it dropping too much, which should not happen. For example, in the track, you can see the missile dropping by around 20 feet. That's twice the Gazelle's height. Here is some real-life footage that can easily be found on the internet, which proves that the HOT3 goes straight. It wouldn't make sense if it dropped, since it's a munition used by ground units. Imagine if it dropped 20 feet. By the way, in the launch sequence you will notice that the HOT3 is not rotating as it leaves the tube in DCS; it takes too long to start doing that. You can clearly see this rotating motion from the tube in the slow-motion footage from the video. (Curiously the inside of the tube in DCS is like a rifled barrel. So it should rotate like a bullet does) There are many examples on the video, i'll mark a few and let the devs see for themselves. - 02:22 >> you can see the launch sequence and how its rotating - 02:55 >> slowmo launch sequence, followed by how it doesnt drop height after launch - 03:15 >> slowmo launch clearly see how it rotates, followed by another example of that - 04:52 >> briefly seeing the flight trayectory, and its not dropping like in DCS - 05:01 >> again seeing how it doesnt drop, this time from the cockpit - 05:05 >> a few more shoots - 10:38 >> a Bo105 demostrating the flight trayectory, and then a Gazelle I'm not saying it shouldn't drop a bit, but I think the video demonstrates that what we currently have in DCS is wrong. In the video, you can see that the flight trajectory is almost flat. I added this track in DCS for comparison. (As a side note, the first HOT3 launch goes bonkers because of another unresolved issue with the HOT3 that I report here) Regards! HOT3_Issue.trk

Can this be labelled and investigated, please? I think it has been proven that there is something there. I fear that if not, this report will be forgotten.

Cheers!

It looks like this hasn't been reported yet. It has not been tagged as a bug or investigated. If someone in Ugra wants to take a look at this bug, this is still a thing in the current DCS version: DCS 2.9.21.16552 null

@OnReTech I fail to see this question answered in your FAQ, and i think it should be included. What period is this map based on?

I fail to see this question answered in FAQ, and i think it should be included What period is this map based on?

It is a bug. I just tested a vertical angle drop, very near to 90º falling down and it opens at the correct HoB. For some reason the CBU-87 work with HoB, but the CBU-99 with the FMU-140 works with Slant Range This should be corrected Edit: i forgot to add the track CBU_Height_Issue_1500_90degrees.trk

Well i think you are into something. Maybe thats the issue there I think what you said is possible to be how in DCS the FMU-140 calculates HoB (Height of Burst), it uses the SlantRange. But i dont think that is correct, if it does that its an error. First of all, if we compare to other cluster bombs like the CBU-87. That has the FZU-39/B that works with setting a HoB too. If you use it on DCS set at 1500, it releases at 1500ft AGL. (if you have the F16, I added a track i did that day to see if there was any difference with the CBU87 Radar Fuze) And i dont think the FM-140 is different. As you can see cleary here it has in the picture a setting for HoB. So i dont think that works with SlantRange, but as any other fuze with Height https://cat-uxo.com/explosive-hazards/fuzes/fmu-140-fuze But thank you, because i think you pointed the devs where the issue could be. VIPER_CBU_Height_Issue_1500_centerHit.trk

In the Fuze menu there is a Text Error that mislead the user. There is a timer setting called Airburst Delay but it should be Arming Timer The former is incorrect because is not a time delay after the canister opens. Is a Arming Delay, as in any other bomb, after the bombe leaves the pylon Should be easy and quick to change, as is only text BTW Airburst Altitude should be changed too. Altitude is MSL, but Height is AGL. And that difference can be huge in aviation. In the FUZE-39/B manual this is called HoB (Height Of Burst), as in other CBU with similar sensors, not Altitude Of Burst. Regards!

I think the issue comes from the explosions effects discrepancy I noticed this a while ago and today during test to report it i noticed something. Even if i changed the Airburst Height at which the submunitions released, the effect remained the same. The visual effect of it i mean. If you slow down the replay you can see the submunitions diferent dispersions, but the visual effect will mislead the user. I think it will worth to update the visuals to match the dispersion. That will help the user to see what the settings and how he deployed it really does. null