R-27ET fusing issue

[Cmptohocah]

Hello,
my R-27ET seems to need to collide with the target physically before it explodes. In the screenshot you can see that the missile passes the target at a distance of 7 meters and fails to detonate. Anyway have an idea what might be the issue here?
What kind of fuse proximity fuse does the ET use anyway?
Please note that at the time of this near miss, the target was not deploying chaff nor flares.
This just proves my concept: "If you wanna kill something in a FC3 Soviet jet, you gotta go for a guns kill."

 

Personal note: I would actually like to see these kind of random fails happen on regular basis as it looks a bit more realistic, but since AIMs don't miss anything, I would expect my ETs to behave the same.

 

[GGTharos]

IIRC 11m for the R-27s.  I don't know if there's a difference between the new and old fuze (or rahter, is there a new and old fuze?) ... what I mean is:

 

Back in the day, the distance was computed from the pilot's head.   Chizh mentioned the new code checks the entire fuselage.

The R-27s use the old FM.

 

There is a separate declaration for the fuze both in the old and new FMs.

 

... so perhaps there is indeed new fuze code and the R-27 family won't see it until it's moved to the new FM?  But the fuze is definitely there.   You can set it to 50m and watch the fireworks.

 

PS: AIMs miss plenty.  The CM rejection on both Russian and US heaters is set to the same last I checked, save for the 9X which is a monster.   There is also the possibility of the missile having lost power for a long enough shot, but you didn't provide any more details than just that image.

 

Also, if this is a network track, that missile may be further away than is shown.  Likewise, tacview estimates positions between data points, though I don't think this would be an issue here.

Edited December 21, 2020 by GGTharos

[Cmptohocah]

Yes, what I forgot to mention is that this was indeed an online track. I will provide it tomorrow after I trimm it.

Sadly, this lucky person, did fire an AIM-120 seconds after this, but that is besides the point.

[GGTharos]

Ok, but it's your track, right?  In which case the missile it at it's true position vs. if another client had launched it - at that point there's the possibility of desync and you don't need a lot of it.

[Cmptohocah]

On 12/22/2020 at 12:54 AM, GGTharos said:

Ok, but it's your track, right?  In which case the missile it at it's true position vs. if another client had launched it - at that point there's the possibility of desync and you don't need a lot of it.

I've finally trimmed the track. The track was not recorded by me, but the server this happened on.

Engagement is between Su-27 (Nix) and F/A-18C (TANI BG).

r27et-fuse.zip.acmi

On 12/22/2020 at 1:34 AM, Flyingeagle357 said:

I don't understand how multiplayer would give so much challenge to sync a missile and a target when he has dozens of kilometers to calculate and adjust the trajectory, while realistic FPS games like Arma 3 will calculate every single bullets fired on a given server without any issues.

 

Too me it sounds like another non sense excuse. The lag shouldn't benefit the lagger. By default, if the lagger stop sending the required amount of packet, the server should re pop him following a logic trajectory assuming it didn't maneuvered. So the lagger would just "wake up" with a missile in his face, just like it happens on FPS. Lagging on a server won't make you invincible, else all the kids would overload their connection  just to make sure they never get hit.

 

Someone is just to lazy to address the proximity fuse and desync issues.

Yeah, having the possibility of warping around the map is quite an issue in multiplayer setup.

Would be great if the person lagging just continued it's previous trajectory once the connection is interrupted.