Jump to content

You're browsing the 2004-2023 VATSIM Forums archive. All content is preserved in a read-only fashion.
For the latest forum posts, please visit https://forum.vatsim.net.

Need to find something? Use the Google search below.

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


Robert Shearman Jr
 Share

Recommended Posts

Robert Shearman Jr
Posted
Posted

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 comment
Share on other sites

Andreas Fuchs
Posted
Posted

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 comment
Share on other sites

Ross Carlson
Posted
Posted
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 comment
Share on other sites

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

 

What issues?

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

Senior Controller, Boston Virtual ARTCC

Link to comment
Share on other sites

Andreas Fuchs
Posted
Posted

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.

Link to comment
Share on other sites

Ross Carlson
Posted
Posted

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 comment
Share on other sites

Robert Shearman Jr
Posted
Posted

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 comment
Share on other sites

Andreas Fuchs
Posted
Posted
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 comment
Share on other sites

Ross Carlson
Posted
Posted

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 comment
Share on other sites

Andreas Fuchs
Posted
Posted

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 comment
Share on other sites

Andreas Fuchs
Posted
Posted
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 comment
Share on other sites

Ross Carlson
Posted
Posted
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 comment
Share on other sites

Ross Carlson
Posted
Posted
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.

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

Senior Controller, Boston Virtual ARTCC

Link to comment
Share on other sites

Andreas Fuchs
Posted
Posted

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 comment
Share on other sites

Ross Carlson
Posted
Posted

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.

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

Senior Controller, Boston Virtual ARTCC

Link to comment
Share on other sites

Andreas Fuchs
Posted
Posted

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 comment
Share on other sites

Ross Carlson
Posted
Posted

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

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

Senior Controller, Boston Virtual ARTCC

Link to comment
Share on other sites

Andreas Fuchs
Posted
Posted

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.

Link to comment
Share on other sites

Ross Carlson
Posted
Posted

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

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

Senior Controller, Boston Virtual ARTCC

Link to comment
Share on other sites

Robert Shearman Jr
Posted
Posted
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 comment
Share on other sites

Andreas Fuchs
Posted
Posted

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 comment
Share on other sites

Robert Shearman Jr
Posted
Posted
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 comment
Share on other sites

 Share