Jump to content

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


Recommended Posts

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

Cheers,

-R.

fvJfs7z.png

Link to post
Share on other sites

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

 

image.png

 

"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.

Link to post
Share on other sites
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.)

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy

Senior Controller, Boston Virtual ARTCC

Link to post
Share on other sites

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.

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy

Senior Controller, Boston Virtual ARTCC

Link to post
Share on other sites

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)?

Cheers,

-R.

fvJfs7z.png

Link to post
Share on other sites
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.

Link to post
Share on other sites

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.

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy

Senior Controller, Boston Virtual ARTCC

Link to post
Share on other sites

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.

Link to post
Share on other sites
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?

Link to post
Share on other sites
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.

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy

Senior Controller, Boston Virtual ARTCC

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites
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...

Cheers,

-R.

fvJfs7z.png

Link to post
Share on other sites

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.

Link to post
Share on other sites
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.

Cheers,

-R.

fvJfs7z.png

Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...