Big LASTE IFFCC Bug

ED,

I found out that the IFFCC, LASTE and NAV do not compute the wind correctly. I have attached two screenshots where this is clear.

Second screenshot: No wind computing, both CCIP and GUNS reticles are centered in the HUD and the ADI bar is asking me to intercept the flight plan path. All of this is CORRECT.

First screenshot: Wind FROM the north at 40 knots entered in LASTE. CCIP reticle is moved to the left incorrectly like it thinks the wind comes FROM the south, GUNS reticle is moved to the right (this is CORRECT), ADI bar is moved to the center like it thinks that the wind is also coming FROM the south.

It is clear IMO that the wind calculations are wrong and that they are not consistent to the weapon. Guns are ok, CCIP is wrong and NAV is wrong. Who knows what could happen with CCRP.

Also when you enter the wind data into the LASTE it overrides the real wind data that the GPS collects. For example in the steerpoint page the wind data is replaced with the LASTE wind you entered NO MATTER THE ALTITUD YOU ARE IN.

Hope you find this useful for future fixing. I'm open to be proven wrong, actually I'd love to since this is a super major let down.

Thanks for all the work ED, everything is amazing.

Interesting , will test this.

Although as I understood ,many ppl have confirmed that wind correction is working correctly . As per example: the virtual gunsmoke competition and its contestants(http://forums.eagle.ru/showthread.php?t=144821)

People just use things without knowing what they do.

Please note that CCIP pipper is indicating solution for rockets, while Gun cross does the same for guns. Different weapons with different ballistics. Also I don't understand why, if both cases have same WIND LASTE inputs, IFFCC provides differents solutions, albeit real wind is different for both. I would expect same solution in both cases.

Regards!

A thing flying in the air is a thing flying in the air, doesnt matter if it's a duck, a bullet, a rocket or a witch, they are all affected by the wind in the same direction. There is no explanation for why a rocket will land to the right and a bullet to the left. It's a bug, a major one I'd say.

A thing flying in...

Nothing to see here :music_whistling:. Misread the original post.:pilotfly:

They will be affected in the same direction.

Yes. Do you realize that they will be affected in the SAME DIRECTION, right?

Missed that part, my bad. Try to calm down a little in the future.

A thing flying in the air is a thing flying in the air, doesnt matter if it's a duck, a bullet, a rocket or a witch, they are all affected by the wind in the same direction. There is no explanation for why a rocket will land to the right and a bullet to the left. It's a bug, a major one I'd say.

Exactly, and because that I don't understand why your VVI and pitch ladder are perfectly centered in the HUD when lateral wind is present. Were you using your rudder?

Regards!

No, there was no wind present, just entered into LASTE. When there is actuall wind present the errors of this bug are even worse. But for the purpose of presenting this bug to the devs I did it this way.

Thanks

Hrm ... what about the weather vane effect of rockets in cross wind?

Hrm ... what about the weather vane effect of rockets in cross wind?

Hi Flag,

That's interesting to consider. However given the nature of that phenomenon I dont think it will make that a rocket lands on the opposite direction of a crosswind, it just tends to yaw for a moment.

As the bug is presented, please take a look at how the solutions behave when wind is entered into the computer. The computer basically says that if the wind is coming from your left then the rocket will land even more to the left of the "no wind" trajectory. That's wrong for me.

I tested it with MKs and the error is the same, in fact with MKs the error is more inconsistent as the reticle goes in the wrong direction depending on the layer (WTH?).

I've been testing this also and I can attest that something fishy is going on.

First of all: Not all IFFCC calculations are wrong according to my test but Piston is correct; something is wrong.

GUNS, CCIP (bombing) works correctly with wind correction in both 0 wind ME and with 40knots crosswinds. However, the RKT wind correction is definitely weird(=wrong). I havent yet tested CCRP mode

a vid demonstrating the same effect seen in Pistons screenshots:

although suddenly and occasionally while playing around the RKT cue would appear to work fine :doh:

The second vid was recorded with strong wind from 353 while flying a course of ~270

Attached are two tracks with the sudden correct behaviour, both tracks are horrendously long and tidious to watch. The sudden "correct" behaviour occurs at around 05:30 minute mark in both trk:s, then the rest of it is me trying to replicate and then correct the bug. :D

RKTCorrectbehavioursuddenly.trk

RKTCorrectbehavioursuddenly2.trk

I've been testing this also and I can attest that something fishy is going on.

 

First of all: Not all IFFCC calculations are wrong according to my test but Piston is correct; something is wrong.

 

GUNS, CCIP (bombing) works correctly with wind correction in both 0 wind ME and with 40knots crosswinds. However, the RKT wind correction is definitely weird(=wrong). I havent yet tested CCRP mode

 

 

a vid demonstrating the same effect seen in Pistons screenshots:

 

 

although suddenly and occasionally while playing around the RKT cue would appear to work fine :doh:

 

 

The second vid was recorded with strong wind from 353 while flying a course of ~270

 

Attached are two tracks with the sudden correct behaviour, both tracks are horrendously long and tidious to watch. The sudden "correct" behaviour occurs at around 05:30 minute mark in both trk:s, then the rest of it is me trying to replicate and unreplicate the bug. :D

Nice to see some backup :D

I noticed that CCIP Bombing works fine sometimes, but depending on the layer entered it works like the rocket (wrong).

I've tested different (some ridiculous) hypotheses in an effort to pinpoint what suddenly corrects the behavior and then suddenly causes it to go awry but It seems completely random in preliminary testing. The only consistency that I found, is that the state(correct-to-incorrect) changes only when new LASTE correction values (regardless of how many) are entered.

Nice to see some backup :D

 

 

I noticed that CCIP Bombing works fine sometimes, but depending on the layer entered it works like the rocket (wrong).

You have a keen eye for details , whats not to backup :thumbup:,

I haven't been able to cause the CCIP Bombing reticule to show wrong corrections. I do admit that I haven't tested it as extensively as the gun and RKT. Do you happen to have or .trk files so I could meddle with that too?

You have a keen eye for details , whats not to backup :thumbup:,

 

I haven't been able to cause the CCIP Bombing reticule to show wrong corrections. I do admit that I haven't tested it as extensively as the gun and RKT. Do you happen to have or .trk files so I could meddle with that too?

I dont unfortunately, but I think it is enough that we all agree that there is a bug so the ED team is able to go for a fix.

It is important that ED see an agreement on a bug thread.

Great find Piston. I will test on my end and confirm. Might want to post details in your #1 post on your version of DCSW.

I dont unfortunately, but I think it is enough that we all agree that there is a bug so the ED team is able to go for a fix.

 

It is important that ED see an agreement on a bug thread.

Ofc, but the chances of anything being done about a bug increase drastically if we can tell :"when you do X, you see Y" accompanied with hard evidence (.trk, screenshot, vid etc).

I personally wouldn't want ED diverting any resource/debuggers/coders from their F/A-18,carrier ops, NTTR and DSCW2.0 teams to go on and trying to debug a huge amount of code lines (IFFCC, LASTE , CDU, winds, etc) without a solid description of the bug and what systems it afflicts and when.

.

just my 2 cents

Ofc, but the chances of anything being done about a bug increase drastically if we can tell :"when you do X, you see Y" accompanied with hard evidence (.trk, screenshot, vid etc).

 

I personally wouldn't want ED diverting any resource/debuggers/coders from their F/A-18,carrier ops, NTTR and DSCW2.0 teams to go on and trying to debug a huge amount of code lines (IFFCC, LASTE , CDU, winds, etc) without a solid description of the bug and what systems it afflicts and when.

.

just my 2 cents

IMHO I whink that if we dont complicate this then the evidence I posted is enough to declare it a bug. I know there will be mixed opinions and it's ok, but without complicating it, we are good to declare this a bug and go for a fix. I'd love to have this working right in the A-10C, but I understand priorities.

Thanks all for posting.

IMHO I whink that if we dont complicate this then the evidence I posted is enough to declare it a bug. I know there will be mixed opinions and it's ok, but without complicating it, we are good to declare this a bug and go for a fix. I'd love to have this working right in the A-10C, but I understand priorities.

 

 

Thanks all for posting.

Absolutely fine with me although I have a sweet spot for accurate definition and description of an issue and subseqent evidence/proof of mentioned issue .

Anywaysn - good job spotting this inconsistent behaviour :thumbup:

P.s. if/when anyone sees this issue with CCIP bombing reticule , pls save a.trk a share it.

A thing flying in the air is a thing flying in the air, doesnt matter if it's a duck, a bullet, a rocket or a witch, they are all affected by the wind in the same direction. There is no explanation for why a rocket will land to the right and a bullet to the left. It's a bug, a major one I'd say.

However, A duck, Bullet and Rocket will not be affected the same. In the same way by the same wind. Time of flight, ballistics etc will affect the impact point and aiming. Even the gun ammunition is affected differently. (Which is why we have 2 dots in the Gun Pipper)

This is a possible explanation for why the aimpoint moves despite all other conditions being the same. I'm looking in the Dash 1 for better info on LATSE system.

I'd love to see something from ED on this thread, at least an acknowledgement of the issue :(

Cant believe that this happens after so many years out of beta. But I know it must be really complicated to be on top of everything on such a complete simulation.

Cheers.

However, A duck, Bullet and Rocket will not be affected the same. In the same way by the same wind. Time of flight, ballistics etc will affect the impact point and aiming. Even the gun ammunition is affected differently. (Which is why we have 2 dots in the Gun Pipper)

 

This is a possible explanation for why the aimpoint moves despite all other conditions being the same. I'm looking in the Dash 1 for better info on LATSE system.

Please read the whole post, I already replied to Snoopy about the same comment......

Please read the whole post, I already replied to Snoopy about the same comment......

Well... I didn't have time to "read the whole post" at work. That being said...yes things flying through the air will be affected in the same direction...the ballistics dictate exactly how much they will be affected and more importantly how much the aiming will be affected. I also question inputting a wind component with no actual wind present. If LATSE pulls information from other avionic components your testing might be flawed.

Congratulations, you found a bug. Maybe. Now send it to Ed with tracks and see what they say.