Model Matching: "Airline" and "Livery" fields...?

[Robert Shearman Jr]

Hello Swift team --

 

When logging onto VATSIM using XSquawkBox, there is a drop-down for "Airline" and "Livery". My understanding was that the only two data-points a VATSIM Pilot Client uses to determine how to match someone to an AI model is their Callsign and their Aircraft Type. Are these "Airline" and "Livery" fields even transmitted over FSD, and if so, are any Pilot Clients using them in determining how to represent a player who has those fields set?

 

I asked this in the XSB forum too, but, since the question has bearing on other Pilot Clients, I thought in this case it might be appropriate to cross-post: viewtopic.php?f=109&t=80703

[Andreas Fuchs]

Hi Rob,

 

what you enter in the field "callsign" has no or almost no influence on model-matching. The information about "type of aircraft" and "livery/color" are defined as separate entries within your data-package that you transmit to the VATSIM servers.

 

In swift this information is set in the fields

 

 

"Aircraft" and "Airline". As soon as swift has connected to your flight simulator it tries to determine what "Model" (=aircraft/airline) you are using at this time and should fill in the following fields automatically. If not, you must define "Aircraft" and "Airline" manually.

[Ross Carlson]

what you enter in the field "callsign" has no or almost no influence on model-matching.

 

Here, Andreas is referring to other swift users ... the callsign is definitely used for model matching for vPilot users. In other words, the callsign that you enter determines the airline that other pilots will see you as if those other pilots are using vPilot. The airline and livery values are not used by other pilots that use vPilot. (Not yet ... they may be used in the future.)

[Andreas Fuchs]

Ah, that's why I continue having issues with vPilot users

[Ross Carlson]

Ah, that's why I continue having issues with vPilot users

 

What issues?

[Andreas Fuchs]

Oh, that was a joke!! During Worldflight the 747 of SimfestUK was hovering quite a few feet up in the air, consistently. Were they using vPilot? I do not know.

[Ross Carlson]

Hovering aircraft would not be a problem in the client the hovering pilot is using ... that's a problem with your client and/or a large scenery elevation difference between you and them. That's also not a model matching issue, rather a ground clamping issue.

[Robert Shearman Jr]

Andreas -- how does Swift determine what model to use to represent another player, and how does this differ if (a) they're also using Swift or another client they've set "Airline" and "Livery" codes in, versus (b) they're using vPilot or xPilot which does not include provisions for setting those values (or using XSB but left them blank)?

[Andreas Fuchs]

Hovering aircraft would not be a problem in the client the hovering pilot is using ... that's a problem with your client and/or a large scenery elevation difference between you and them. That's also not a model matching issue, rather a ground clamping issue.

There's the issue: as you know swift does put everyone else to the same elevation as you (the player), but only the SimfestUK guys were hovering in the air. Clearly an issue with the vertical offset of that model and the information.

[Ross Carlson]

Yeah, the simfest guys are a special case because they use a custom system that syncs data between PSX and P3D, and then vPilot sends data from P3D to the network. I know that they have (or had) an issue where they were not setting the "on ground" flag in P3D when the PSX sim was on the ground. Thus, vPilot cannot send the on ground flag to the network. I'm guessing that swift does not invoke its ground clamping until it sees the on ground flag set to true. Do you know if that's the case? If so, that would mean you might also get hovering aircraft when the sending pilot is using a legacy client that does not support the on ground flag. To deal with this in vPilot, I invoke the ground clamping any time I see the aircraft's altitude remaining constant from one update to the next AND the sending client does not support the on ground flag. That way you get ground clamping with all clients regardless of protocol support.

[Andreas Fuchs]

Hi Rob,

Andreas -- how does Swift determine what model to use to represent another player, and how does this differ if (a) they're also using Swift or another client they've set "Airline" and "Livery" codes in, versus (b) they're using vPilot or xPilot which does not include provisions for setting those values (or using XSB but left them blank)?

a) swift to swift we transfer this information with all details. You could even connect as "AAL1234" but define your airline livery to be "AWE", because you just love the livery of US Airways. There's even a further layer of detail and you can transmit information of using a special livery of an airline.

 

b) apparently, as Ross has explained, other programs pull their livery information from the callsign that you use to log in to VATSIM, AAL1234 = AAL. Not much that we can do. Until Ross mentioned it, I thought that as a pilot you also had to define the livery in vPilot and xPilot and not simply enter the callsign that you want to use. I remember from Squawkbox for FS9 and FSX that you had to setup aircraft with their type and livery/special livery. Obviously this function has not made its way into vPilot. And I have never used vPilot because I switched directly from FS9 to X-Plane 11. vPilot is a great program, but I have never been able to use it due to my SIM-software.

[Andreas Fuchs]

Yeah, the simfest guys are a special case because they use a custom system that syncs data between PSX and P3D, and then vPilot sends data from P3D to the network. I know that they have (or had) an issue where they were not setting the "on ground" flag in P3D when the PSX sim was on the ground. Thus, vPilot cannot send the on ground flag to the network. I'm guessing that swift does not invoke its ground clamping until it sees the on ground flag set to true. Do you know if that's the case? If so, that would mean you might also get hovering aircraft when the sending pilot is using a legacy client that does not support the on ground flag. To deal with this in vPilot, I invoke the ground clamping any time I see the aircraft's altitude remaining constant from one update to the next AND the sending client does not support the on ground flag. That way you get ground clamping with all clients regardless of protocol support.

Oh, that's very useful information! Let me ask Klaus and Roland. Thanks a bunch!!

 

How do you determine that a client that does not support the on ground flag?

[Ross Carlson]

Oh, that's very useful information! Let me ask Klaus and Roland. Thanks a bunch!!

 

How do you determine that a client that does not support the on ground flag?

 

Clients advertise their protocol support to each other through protocol messages.

 

Since the legacy clients aren't long for this world, it probably doesn't make sense for the swift devs to bother implementing ground clamping for them. The only reason I did so in vPilot is because I built ground clamping in before the on ground flag was added to the protocol, and before the writing appeared on the wall predicting the impending end of support for legacy clients.

[Andreas Fuchs]

I believe Simfest UK uses vPilot. The question is now why swift won't clamp it to the ground. Must be an issue with the PSX-P3D-combination.

[Ross Carlson]

I believe Simfest UK uses vPilot. The question is now why swift won't clamp it to the ground. Must be an issue with the PSX-P3D-combination.

 

Uhm ... I explained it above.

[Andreas Fuchs]

Yes, but from what the developers explained to me, it should still be at the correct level. Apparently swift recognizes them as "on ground", but the vertical offset is not right. Next time I see them online (on the ground) I will try to get all the data from their plane.

[Ross Carlson]

There is no vertical offset sent over the network, so I'm [Mod - Happy Thoughts]uming that would refer to something that is configured or calculated locally.

[Andreas Fuchs]

Yes, the CSL model set configuration files for X-Plane allow a "vertical offset" to be included. This determines the height of the cockpit view point (or similar) above the ground. Some CSL models are programmed better than others, so some need this offset, many do not. When we see a plane too high/low, we can investigate and then implement this vertical offset.

 

It looks like this in xsb_aircraft.txt

OBJ8_AIRCRAFT A306_AAW
OBJ8 SOLID YES __Bluebell_Airbus/A306/A306_AAW.obj
VERT_OFFSET 4.6
AIRLINE A306 AAW

[Ross Carlson]

So if it was the vertical offset, that doesn't have anything to do with simfest or the client they were using.

[Andreas Fuchs]

Possibly not, but something made the model, that swift chose to display them, float. We need some fine-tuning there, but that can only be done when the source of the issue has been found.

[Ross Carlson]

Of course, which is why I said "if it was the vertical offset" ... "if" being the operative word, there.

[Andreas Fuchs]

Absolutely!

[Robert Shearman Jr]

Andreas -- how does Swift determine what model to use to represent another player, and how does this differ if (a) they're also using Swift or another client they've set "Airline" and "Livery" codes in, versus (b) they're using vPilot or xPilot which does not include provisions for setting those values (or using XSB but left them blank)?

a) swift to swift we transfer this information with all details. You could even connect as "AAL1234" but define your airline livery to be "AWE", because you just love the livery of US Airways. There's even a further layer of detail and you can transmit information of using a special livery of an airline.

 

b) apparently, as Ross has explained, other programs pull their livery information from the callsign that you use to log in to VATSIM, AAL1234 = AAL. Not much that we can do. Until Ross mentioned it, I thought that as a pilot you also had to define the livery in vPilot and xPilot and not simply enter the callsign that you want to use.

Given this knowledge (i.e. that everyone on the network using either vPilot or xPilot DOES NOT set "Airline" nor "Livery" data values), would it be possible for the Swift client to be updated so it could attempt to glean some idea of a user's intended representative model from their callsign in cases where the aforementioned items are null or gibberish?

 

Personally, I prefer to enter data one time -- i.e. if I put "AAL" in my callsign I would find it unnecessarily redundant to have to specify again that I want to appear to others in an American Airlines livery. In other words, I like the way vPilot and xPilot handle that. Of course, everyone else's mileage may vary, and I'm sure there's a decent split on that opinion too...

[Andreas Fuchs]

Under normal circomestances you won't have to enter that data again. If swift recognizes the plane that you are using in your SIM, it will automatically fill in the type and the airline livery. It works for me, consistently. It's there on purpose to force users to ONLY use accurate ICAO codes for aircraft types and airlines. You won't believe how many "LH" instead of "DLH" we see. Or "EASY1234" instead of "EZY1234". We want to stop that and only provide valid data.

[Robert Shearman Jr]

Under normal circomestances you won't have to enter that data again. If swift recognizes the plane that you are using in your SIM, it will automatically fill in the type and the airline livery.

I'm referring to the case where I am using vPilot or xPIlot, and you are using Swift.

 

Will *YOUR* Swift try to recognize that as a B738 logged on as "SWA1234" I should be rendered with a Southwest livery, even though *MY* pilot client (xPilot or vPIlot) didn't allow me to set "Airline" and "Livery" values -- or, I used XSquawkBox but chose to leave those blank?

 

If not, I postulate that it should. But of course that's open for debate.