Acceleration chevrons flickering at center

[sedenion]

When the aircraft have a perfect or near pefect balance between acceleration and desceleration, the acceleration chevrons goes creasy and flip above and bellow the FPM at high speed, while it should be aligned to the FPM... It seem something goes wrong when a variable of the acceleration equation is equal or near 0.

 

If necessary i can make a track.

[sedenion]

I update the comment because i really don't understand how and why this effect appear. at one time, i thought that was due to some specific drag at mach 1.0, but in fact this is not specifically at mach 1, but it is well around mach 1.0 (from mach 0.85 to 1.1 it seem)

 

What i observe is the following:

- Depending altitude and payload, near mach 1.0 (mach 0.85 - 1.1) the chevrons sudently shift up or down, like "tac!"... and if we maintain the speed at this kind of limit, the chevrons goes crazy, shifting up and down very rapidly, which appear as flickering.

 

I let you a track, to see the problem... in this track, the problem appear precisely when the aircraft reach mach 1.01 and keeps this precise speed due to altitude and high drag (many payload) which allow to clearly see this flickering.

chevrons flickering.trk

[Davee]

When the aircraft have a perfect or near pefect balance between acceleration and desceleration, the acceleration chevrons goes creasy and flip above and bellow the FPM at high speed, while it should be aligned to the FPM... It seem something goes wrong when a variable of the acceleration equation is equal or near 0.

 

If necessary i can make a track.

 

+1

[OnlyforDCS]

I've got this too. Or something similar. The chevrons go up and down as if the plane is alternatevly accelerating and deccelarating really quickly.

 

Didn't report it because I thought maybe it was intentional, or maybe my throttle is spiking.

[Azrayen]

Interesting. :)

 

Saw your track, sedenion. Will try to reproduce.

 

But not with the exact same conditions, because:

- you shouldn't fly above M 0.95 with bombs

- you shouldn't fly with both 530s and A-to-G weapons at the same time.

 

++

Az'

[gospadin]

I reported this a long time ago, and was told it wasn't going to get fixed because the calculator of the acceleration chevron was correct.

 

"Should" versus "Can" is the kind of thing, IMO, that the original designers would have thought about. Every system would have margin designed into the calculations.

 

7P8wGlWxXEc

[sedenion]

I reported this a long time ago, and was told it wasn't going to get fixed because the calculator of the acceleration chevron was correct.

 

"Should" versus "Can" is the kind of thing, IMO, that the original designers would have thought about. Every system would have margin designed into the calculations.

 

I am not sure i properly undestand what you explain, but i just can't beleive the chevrons does this kind of thing in the real aircraft... The calculation equation is probably correct, but this bug looks like a calculation exception, like a 0 value or vector lenght somewhere that is divided elsewhere which produce non consistant values...

[CptSmiley]

I'll look into this. I've looked into it before but could never find an easy fix, but will take a second shot at it.

 

For full disclosure this is what my findings were originally:

 

If you notice, this problem only occurs when stores are loaded on the aircraft. What is happening is there seems to be some odd transonic drag modeling going on internal to DCS with the weapons on the aircraft we have no control over. What seems to be going on, is that for one frame you get a huge amount of drag output from the stores, this causes an immediate but negligible slow down on the airframe...then because of the immediate slow down the weapon is out of the huge drag spike area so the airframe accelerates into that speed again.

 

This cycle just continuously repeats itself...the changes are so small that it doesn't affect the airframe all that much, except of course the accel vectors you see there. I've tried added some rate limit filtering and it didn't seem to do it quite right (you'd always be stuck with the chevron stuck with postitive or negative accel when you are effectively not accelerating at all.

 

I have some new ideas to try out to attempt to correct this. Stay tuned...

[myHelljumper]

Thanks for letting us know :)

[sedenion]

I'll look into this. I've looked into it before but could never find an easy fix, but will take a second shot at it.

 

For full disclosure this is what my findings were originally:

 

If you notice, this problem only occurs when stores are loaded on the aircraft. What is happening is there seems to be some odd transonic drag modeling going on internal to DCS with the weapons on the aircraft we have no control over. What seems to be going on, is that for one frame you get a huge amount of drag output from the stores, this causes an immediate but negligible slow down on the airframe...then because of the immediate slow down the weapon is out of the huge drag spike area so the airframe accelerates into that speed again.

 

This cycle just continuously repeats itself...the changes are so small that it doesn't affect the airframe all that much, except of course the accel vectors you see there. I've tried added some rate limit filtering and it didn't seem to do it quite right (you'd always be stuck with the chevron stuck with postitive or negative accel when you are effectively not accelerating at all.

 

I have some new ideas to try out to attempt to correct this. Stay tuned...

 

making an average of cumulated drag per frames over time lapse should reduce the problem... if the "odd transonic drag" appear alternatively each frame, this is even simpler, an average over two frames is sufficient...

[gospadin]

I have some new ideas to try out to attempt to correct this. Stay tuned...

 

Thanks, sorry for beating a dead horse...

 

 

:Flush:

[CptSmiley]

All fixed :) should be in next update

[sedenion]

Great ! thanks