Deficiencies in aircraft tracking with wind

[tedrek]

This is a continuation from comments on #289 and briefly summarizes the content.

The specific issues are pilots when navigating to fixes point the aircraft directly at the fix rather then compensating for any crosswind and when landing aircraft don't specifically compensate for crosswind to remain on centerline.

Proposed solutions for fixes are: a) Ignore wind motion for aircraft in fix mode b) Improve aircraft navigation to maintain a constant track in fix mode

B is strongly preferable to A, although depending on avionics in an aircraft not all aircraft may be capable of crabbing during fix tracking. This suggests implementing equipment suffixes/capabilities. Equipment suffixes would mean some aircraft shouldn't be able to navigate to certains fixes because of their type.

Implementation of crabbing means the radar vector/tail should be the aircraft's track, not it's heading as is currently done.

[zlsa]

I believe there's already an ILS capable flag in each aircraft, but it's possibly inaccurate since it's not used yet. (It would have been used in the future in case of poor visibility, i.e. fog, rain, etc.)

[tedrek]

As a note, aircraft currently differentiate between heading and fix modes and correctly implement flying a given heading.

I really don't like making aircraft ignore the effect of wind when in fix or landing modes. It would mean two aircraft flying identical tracks into a wind with identical assigned speeds would be flying different ground speeds (potentially large differences).

Implementing equipment suffixes would be possible, but none of the existing fixes are categorized in any way. To me that means the most reasonable suffix to consider is simply a 'not capable of navigating to any fix'. Trying to differentiate further would require revisiting every single fix in every single airport and would probably affect 1 in 200 flights at best, it doesn't seem like a good use of effort to me. Most aircraft are jetliners in most airports at this time. If fix types are implemented and most airports are updated then equipment suffixes would be worth re-visiting for this topic.

I think the best solution is to just implement crabbing in fix mode as it correctly covers 99% of the cases and the other 1%. For landing, it should be relatively easy to implement crabbing at the same time and again it will cover 99% of the cases.

[erikquinn]

Agreed on the topic of the suffixes. Actually implementing legit crabbing is not really necessary though, now that I think about it. After all, the orientation of the leader lines of a radar target have no respect to where the aircraft is facing, but just where it's projected to be at the next update. Thus, even if an aircraft WAS crabbing, and hard, we would never see it in reality. So really, the most correct fix is probably to remove the wind's positional effect on aircraft when in fix/rwy mode. See below:

---

At the bottom is the relevant section from aircraft.js... might it be as simple as adding an "if not in runway or nav mode" before the following line (from near the bottom of the large section)?

  this.position = vsum(this.position, vector);

  v       v       v       v       v       v

  if(!(this.mode == "fix" || this.mode == "rwy")) this.position = vsum(this.position, vector);

That would leave the calls to scale groundspeed effectively, but just allow the aircraft to track direct to the fix without getting pushed off course. Looks to me like it would work, but it seems almost too simple... haha

  if (prop.game.option.get('simplifySpeeds') == 'no') {
    // Calculate the true air speed as indicated airspeed * 1.6% per 1000'
    scaleSpeed *= 1 + (this.altitude * 0.000016);

    // Calculate movement including wind assuming wind speed
    // increases 2% per 1000'
    var wind = airport_get().wind;
    var vector;
    if (this.isLanded()) {
      vector = vscale([sin(angle), cos(angle)], scaleSpeed);
    }
    else {
      vector = vsum(vscale([sin(wind.angle + Math.PI), cos(wind.angle + Math.PI)],
                           wind.speed * 0.000514444 * game_delta()),
                    vscale([sin(angle), cos(angle)], scaleSpeed));
    }
    this.ds = vlen(vector);
    this.groundSpeed = this.ds / 0.000514444 / game_delta();
    this.position = vsum(this.position, vector);
  }
  else {
    this.ds = scaleSpeed;
    this.groundSpeed = this.speed;
    this.position = vsum(this.position, vscale([sin(angle), cos(angle)], scaleSpeed));
  }

[tedrek]

@erikquinn, it is too simple. Trying to ignore the wind when in fix or rwy mode leaves the bizarre behavior where two aircraft can be flying the same track and assigned speed but have different ground speeds.

But rather than implementing true crabbing, the aircraft could just subtract the required vector when in fix/rwy mode.

[Maverick283]

@tedrek Can you give an example of two aircrafts with same fix assigned etc where this effect would occur? I don't understand what would make them fly different ground speeds if the wind would affect the speed but not the track...

[erikquinn]

@Maverick283 Yeah, he's right actually... it's a bit of a paradox:

In the sim, the aircraft's actual movement is not based on its groundspeed. You'd think by allowing the code to still affect the groundspeed, it would still move at the correct pace, but the groundspeed is just calculated FROM the position. If the position is unaffected by the wind, the airplane will move regardless of wind, therefore having groundspeed that doesn't take into account any wind effects.

With my suggestion of 86-ing the positional effects, and leaving the groundspeed effects in play would only affect the groundspeed that is displayed in the callsign, but not the groundspeed at which that the aircraft will actually move.

Example of two a/c flying formation, wingtip to wingtip, with 20kt tailwind:

• Airplane A on 090 heading, 10k ft, @250kt IAS [will move at 290+20=310kt GS]
• AIrplane B on 090 track to next fix, 10k ft, @250kt IAS [will move at 290kt GS]

Airplane A gets wind effects. Airplane B doesn't. Both A and B will display 310kts groundspeed. But, only A is actually having his position move the extra distance each update.

[Maverick283]

Ahh I see thanks! I'll have to get to know the code better... But it appears to me as there is a mistake in the logic then, probably because wind wasn't taken into account at the stage or writing...

[tedrek]

@maverick283, it sounds to me like you are thinking of the wind as affecting an aircraft's speed and affecting it's track separately. That is not the case (and is harder to simulate).

The basic simulation of movement can be thought of as moving the aircraft straight forward a distance based on it's airspeed, then it is moved straight downwind based on the wind speed. As you can see when the wind is at an angle to the aircraft's heading it will move the aircraft both 'forward/back' and 'sideways' at the same time from the aircraft's perspective.

Ignoring the 'positional' effect of the wind loses both the sideways and the forward/back motion.

If we just ignore the 'sideways' portion of the wind, then there is still a speed issue. Consider a wind from the north blowing south and an aircraft which is wanting to fly due east. In heading mode the aircraft would need to fly a heading of something like 85 to have a track of 90. In simulation terms this means the aircraft is first moved north and east and then moved back a little south meaning the aircraft will move a little slower to the east than an aircraft which is flying a heading of 90. In fix mode the aircraft would move due east and therefore a little bit further then the first one, however the wind wouldn't move it that bit south resulting in the aircraft having a higher ground speed.

[Maverick283]

@tedrek yeah I understand, and it would indeed be weird if forward motion and sideways motion would be calculated sepereately, yet what i find weird is that the speed results from the changing position instead of being calculated. What I mean by "ignoring the wind" is getting a triangular function going that would only take the vector parallel to the track of the aircraft so that only the head-/tailwind component is having a effect on the aircraft.

Of course you could also simulate a pilot that does the work for you... The more I think about it the more it seems like both ways would conclude in the same amount of work and would use the same amount of computing power.

[tedrek]

Well, it would be accurate to say the ground vector is calculated directly. It just happens to be done in cartesian coordinates instead of polar and the units are in km/tick instead of knots. It also happens to be a vector which can easily be used to update the position of the aircraft.