Ross Carlson

The devs will be fixing the standalone client (and the new xpilot client) so that it works the same way as vPilot for PTT device detection. The Warthog (and the Rhino) has a different issue where sometimes it is constantly sending button presses, and this makes it so that you can't choose the button that you want for PTT because it always immediately detects the button that the driver is constantly pressing automatically. I will be releasing a fix for this in the next vPilot version. (Both the normal and the AFV versions.)

No, it does not. I plan to bring that feature back at some point to allow testing of custom rule sets and to help people find corrupt models that cause the sim to crash.

Yeah, sounds good.

Evan, I found that BE60 is already in the similar type code list for BE58. Did you run into a situation where vPilot would not use a BE58 model when a BE60 was encountered?

Gotcha ... so you're using model matching rules to create type-specific default models. Makes sense. I personally hate to see the wrong airline livery shown on an aircraft, so I prefer to just see a plain white model, so that it's obvious that it's a mismatch. One reason for this is because if ground control tells me to follow the Air France triple 7, and I see a United triple 7, I'm going to keep looking for the Air France. Ideally we'd have a plain white model for each aircraft type, but that just isn't the case, so I default to the A320 or the CRJ. It works the same for helis as it does for fixed wing. The model matching database that vPilot downloads from the server contains a list of similar aircraft types. (This was in a text file in V1.) vPilot makes use of the similar types as described in this section of the docs: http://vpilot.metacraft.com/Documentation2.aspx#model-matching-rules The last few paragraphs there describe the multiple passes vPilot makes through the rules, first starting with the actual filed type code, then if no matches are found, it makes another pass checking for matches using similar type codes. I will add BE60 as a similar code to the BE58. For the reason I mentioned above, I don't want to add automatic matching rules that would result in a UAL B772 being used for an AFR B772. That's really something the individual user should decide on, so a custom vmr file is certainly appropriate there. I was mainly wondering if you had identified some WoAI models that vPilot didn't know about and was thus not making use of via automatic matching. Doesn't sound like that's the case.

Evan, vPilot should recognize most (if not all) of the WoAI models automatically. If there are some that it is not recognizing, please let me know and I'll add them to vPilot's model database. After that, there should be no need for a custom vmr file for the WoAI models. (Obviously there may still be a need for a BVA vmr file if we make use of models and/or rules that are BVA-specific and not of any value to the general vPilot user base.)

Active CAP member here, too.

Wow ... sudden indeed. He was plugged in and controlling with us just two evenings ago. I will remember DA as one of those guys that said a lot with few words. He was one of the quieter members of the gang here, but when he spoke, his words were usually laced with wit and humor. Mike, we hope your permanent leave of absence will be a restful one.

It hasn't happened very many times for me either, since I have almost always given the type of approach to expect, so when I say that "more often than not" they will ask what type of approach, I am working from a very small sample set. :) Definitely a good case for gently nudging pilots toward being in the habit of fetching the ATIS prior to calling approach. I'd say that over my last few controlling sessions on approach, maybe a third of the pilots checked in with the ATIS. So there's lots of room for improvement, and like you said, anything we can do to encourage getting the ATIS is going to help everyone in the long run. As a pilot, it's sometimes hard to get the voice ATIS before checking in on approach during a busy event, especially if you get handed off to approach late and you need to get instructions from approach ASAP. In those cases I've resorted to just double-clicking the ATIS entry in the vPilot controller list and reading the text version. :) On a related trivial note, if I remember correctly, Squawkbox automatically displays the controller's text ATIS as soon as you switch to their frequency. I've thought about adding such a feature to vPilot, but that won't help now that more and more towers are providing a voice ATIS on a separate frequency. Maybe I could have it look at your flight plan and check if there is an _ATIS controller online matching your arrival airfield, and auto-fetch the text version when you get within a certain distance. :)

The problem with that is that it doesn't tell the pilot right up front what type of approach to expect. In my experience, more often than not, if you say the runway without saying the type of approach, the pilot will come right back and say "uh, Boston approach, is this going to be an ILS or visual approach?" So I always tell them what type of approach to expect in the same breath as when I assign the runway, if they don't state the ATIS code. Perhaps when pilots check in without the ATIS, I'll leave the type of approach out of the transmission, and if they ask, I'll say "advise when you have ATIS kilo." ;D

BN, if you had a pilot check in without the ATIS, and you were running visuals, what would you do? (Given that you are assuming they would expect the ILS.) I would probably just modify it as such: American 332, descend via the ROBUC1 arrival, runway 22L visual approach, Boston altimeter xx.xx. But I was looking for an official vZBW policy for the phraseology on this, if there is one ... if not, no big deal, we can each handle it our own way.

Thanks DB ... a question: These phraseology examples do not tell the pilot what type of approach to expect. What is the recommended phraseology for doing that? This is assuming the pilot does not check in with the current ATIS. I suppose we don't have a real world A90 example to follow here because presumably most real world pilots check in with the ATIS and thus they know what type of approach to expect.

Excellent choice ... congrats BU and thank you, DO. (Those are just some words on a web page ... we'll have to give a proper thank you at the TP.)

Wait, you mean they actually completed something ahead of schedule?

The RW server is hosted on a different machine (one of Dave Pascoe's servers) so it won't be affected. The TS server will be moving, but I should be able to copy all the configs over so it should be a transparent change. There might be a few minutes of downtime as the new IP propagates, though. It'll likely be fairly late at night so I doubt anyone will be on TS.

More than once on VATSIM I've seen it first hand where a foreign pilot didn't understand what I meant when I said "position and hold." He read it back as "Roger, hold position." No idea if the same thing happens in the real world, but I wouldn't be surprised. And since there's no other common phraseology I'm aware of that a pilot (regardless of native language) might confuse with "line up and wait", I think it's a good change.

Also known as "position and hold it." ;)

I was thinking of suggesting exactly what EE suggested in the other thread. Allow radar controllers, workload permitting, to issue all applicable runway crossing clearances as part of the initial taxi instruction. That way pilots get their explicit crossing instructions, and the radar controller doesn't have to keep track of where every taxiing aircraft is. Worst case scenario: "Delta 123, runway 27, taxi via Bravo Charlie Delta, cross runways 4L and 4R, hold short runway 33L."

I may be missing a key piece of understanding here, but aren't we creating the potential for confusing our pilots due to the fact that we're only going to issue explicit crossing instructions for every runway on a workload-permitting basis? I mean, if we want to educate pilots that they are expected to hold short of every runway and wait for explicit crossing instructions, won't that cause problems during the times when we're (for example) working CTR and we're too busy to issue all the crossing instructions? Could we end up with a pilot sitting there at the hold short point for 4L on his way to 27, wondering why we're not giving him a crossing instruction? Obviously the pilot can just call up and say "permission to cross 4L?" but then we're not saving any workload. It seems like this is something we either have to do all the time or not at all. Or am I missing something? (Maybe I'm just making a mountain out of a mole hill.)

Does this mean we are relying on pilots to know that they cannot cross a runway without an explicit instruction to do so?

If you take the 7110 change verbatim, that would not be allowed: But I'm with Dan on this one ... this would get crazy on VATSIM for combined positions. Maybe we could have this new rule be in effect only if TWR and/or GND are online? In other words, APP and CTR can do it the way we always have?

Does the point of transfer of control from ground to tower for outbound taxiing aircraft still occur at the first *active* runway? In other words, can ground issue the runway crossing instruction for *inactive* runways?

And if you aren't doing a global search/replace, don't forget to change the voice channel name as well.

Yes, that would be best. ;)