Jump to content

Brin Brody

  • Content Count

  • Joined

  • Last visited

Posts posted by Brin Brody


    1 hour ago, Sean Harrison said:

    Would I not ask to cancel IFR before accepting a visual approach? 

    Opening disclaimer: This is written for FAA-land.

    You absolutely could do this if your company policies allow it, but that's not always the case.  Some real world company OPSPECs prevent crews from cancelling in the air, so they'll take a visual approach (under IFR) to the ground.  I'd guess that some of the more "realistic" virtual airlines might have something similar built into their policies.

    There are also plenty situations in which it makes very little sense to cancel. For example, if I'm arriving into a Class B primary field (not necessarily a satellite, though this could be applicable there too), I have no reason to cancel my IFR clearance just to turn around and get clearance into the airspace as a VFR aircraft.  It adds to my workload, and to that of the controllers, for no reason. (and, perish the thought, if I encounter IMC before reaching my destination, I've not left myself a legal way out of the situation)

    As always: If you're not sure, ask!

  2. Hello, all:

    vZJX ARTCC (VATUSA) has had a consistent issue with FS2020 pilots using vPilot wherein they are unable to connect to the primary CTR frequency (135.925). vPilot seems to interpret 135.925 as 135.924, making it so that pilots are not reaching us when they need to.  As far as we're aware, we're the only U.S. facility to report the problem. We've been made aware that it is due to a SimConnect issue, but are still hoping there is some kind of resolution on VATSIM's side. 

    Short of updating our primary frequency - again (this change was made only about two or three weeks before the FS2020 release) - are there any suggestions as to how we might solve this problem?

    As a quick note: We are aware that having pilots use the .com1 command to access the frequency does solve the problem, but we've found it to be impractical to provide that instruction to every FS2020 pilot, especially during busy periods such as events.

  3. Hi there...


    Been using STARs to work a Tower position, and though it's not built for it, it works pretty well.


    Oh it's built for it alright.


    Looks like it! Appeared to be very TRACON based (as expected) after a first look. Didn’t expect nearly as much TWR support.



  4. Hi there...


    Been using STARs to work a Tower position, and though it's not built for it, it works pretty well. The only issue I'm seeing is the flight strips. It might be an issue I've created on my own, due to lack of knowledge, but I've been unable to use strips that aren't pushed from another controller. When pushed from another controller, either below, or above, they put themselves nicely in the bay.


    However, when working top down, flight strips need to be automatically generated. This is supposedly possible using the separators, and defining parameters for each... I've configured them properly, I believe but have not been receiving auto-generated strips.


    For example, the Departures separator has the departure field properly set up but never brings in new departures. Similarly, arrivals do not appear under the Arrivals separator, which is also properly configured.


    User error, or is this broken somehow?

  5. When I did my testing yesterday, I was disconnected every time. In almost all of the cases, it was within one second. I didn't keep records, but I think in one or two cases it may have taken up to 4 or 5 seconds before the disconnect happened.


    Personally it happened every time... I had people reporting that it was working for them every once in a while though. Hence "sporadic".


    They might've just been using the old sector file?

  6. I don't see how a sector file could cause disconnects. You say it's sporadic, so I'm guessing it's something else.


    That was my thought too. However, it happens ONLY with the new sector file, and not with any of the old ones. The rest of our staff couldn't find any good reason, as sector files don't influence connections.


    There's been no reliable way to reproduce the problem past trying to connect using that sector file.


    Did you see anything abnormal in the file itself?

  7. Hi,


    I recently put together and released a new sector file updated to AIRAC 1709 for the Anchorage ARTCC. The creation is fine, and it loads into VRC fine, with all diagrams showing up properly. However, when a user attempts to connect to the network with the new sector file loaded, it connects them, and then instantly disconnects them. If they revert to a previous version of the sector file, it works fine. This problem is sporadic, and VRC will sometimes connect to the network without any issue.


    Is there something wrong with the sector file that would be causing this problem? Download a copy here. Thanks for the help.

  8. Found the fix for Windows10:

    Need to download copies of mswinsck.ocx, msflxgrd.ocx & comdlg32.ocx.

    Put a copy of each in the file location \Windows\syswow64 and also put a copy in the folder where TRWTrainer resides.

    open a cmd window as administrator.

    Type: cd \windows\syswow64

    Type: regsvr32 filename.ocx

    where filename = each of the above files, one at a time.


    Chuck Messina

    CID 1303148

    ZOB - DATM


    Thank you, Messina! Was able to only copy mswinsck.ocx into syswow64, but register all three successfully. Much appreciated.

  9. Hello,


    I am working on a service that requires either a METAR or TAF in raw format for any airport in the United States, in JSON format, preferably. Thus far, I've only found XML and CSV versions, and would be willing to use them, if necessary. Does anyone here have any knowledge as to the location of any files that may include these things? Thanks in advance...

  10. If we could introduce a way to teach pilots hold properly using a lack of technology

    I don't see how flying a hold is different than any other skill needed to fly on VATSIM. Either they learn it on their own or they use the training available from ATOs.

    Flying it manually is ok, unless a. it's very long or b. you require the hold to fix a problem you need to focus on.


    Not everyone uses training from an ATO, due to our lack of requirement for pilot certifications prior to flight on the network. So, I get people who tell me "unable" to going direct to a fix when filed IFR... There are some things that are hard to do without some better technology.

  11. I think pilots are getting more and more use to holds. That is definitely a great thing to see. Three of the last six FNOs required holds of at least ten minutes.


    Hold are a useful thing to have, when the airspace is way over-saturated, but I find that when I put a pilot in a hold, they tend to disconnect, because of (I [Mod - Happy Thoughts]ume) one of two reasons:


    1. They don't want to wait.

    2. They don't know how to fly a hold using their GPS systems, and therefore don't.


    In both cases, it's simpler for them to just log off, and fly the rest of it offline. I myself, until recently, identified with the second of the two... Those using default FSX aircraft with no addons are at a serious detriment in this case. If we could introduce a way to teach pilots hold properly using a lack of technology, or give them a freeware FMC that can hold properly, it might work better. This obviously goes beyond a few guys chatting on the forums, though.


    And, of course, we can't keep pilots from being impatient. Just my scoop on things.


    Great work Aaron, Kaylan. Hope to see you soon.

  • Create New...