Everything that VOXATC uses is derived from FSX scenery files. All it does is convert and add various BGL files to its internal database. I'll stick with the theory that there is something amiss with the stock airports in that region of the US as the error is reproducible.

One other last option would be to fly the same flight plan IFR and see what happens. The comm handoffs may be somewhat different and yield a clue, although at this point I've chalked this up to a bug.

Edited July 12, 20187 yr by jabloomf1230

Well, IFR flight is OK, I mean it doesn't crash and executes handoff where it is supposed to do so. The last handoff is made to the destination UNICOM as if it was an approach frequency and provides standard approach options (by pressing 0). Of course trying these options has no effect on UNICOM controller but it doesn't crash the process. You just have to do the standard non towered procedures (without any help from the prompter as we already know).

BTW I've noted that handoff from the last center to E45'(virtual) approach is done at the same place where VFR flight crashes. I'm gonna add a real approach frequency on E45 and see what happens.

Ok, here is a part of the story...

In real life Oakland center 121.25 provides aproach/departure services to E45.
In FSX, (default bgl) E45 owns a center frequency (Oakland center 126.85) which seems confusing the Sim. I turned it into an approach type frequency (Note I've also changed frequency to the real one: 121.25).
It doesn't crash anymore in VFR at now !
But it also means that other airfields of this area must be fitted with an aproach/dept frequency in order to avoid VoxATC crashing (maybe excepted those with no CTAF. I've not tested yet).
Unfortunaley once under the approach service' control you can't access to any requests such as emergency or position/bearing. Handoff to approach is made 40nm from your destination so you must pray not to get any problems all along this distance...

In a previous discussion that Rob Ainscough and I were having on an unrelated topic, we talked about how there was a certain amount of "puzzle solving" to flightsims. It shouldn't be that way but sometimes  you can shine a light into the black box.

Unfortunately as instructive as it could be puzzle solving doesn't fix bugs... it just gives you a clue to bypass them. And at the end when you add up the whole time you spent for so few it's just frightening.
Gardening is a more reliable hobby...😏

But if I understand you correctly, the error is in the stock scenery and hence is only a "bug" in VOXATC in the sense that VOXATC doesn't compensate for malformed scenery files.

The sim's default ATC is so "stupid" that it ignores such problems. If one looks back over the threads in this subforum, the vast majority of so-called VOXATC "bugs" are actually the result of either malformed airports or inconsistencies in the sim's configuration files.

I agree that it should be easier for the casual user to correct these problems, but when one considers that VOXATC has replaced two key sim features, ATC and AI traffic, it's not surprising that problems arise.

I've investigated further since my last post. E45 is an atypical example. As I mentionned before Oakland center is also providing an approach service to this airfield. This dual function unsurprisingly is not understood by FSX/VoxATC. This issue wouldn't be a big deal but it highlights something really messy with VoxATC. Centers handoff management doesn't work properly (in not-expert mode at least) as long as the arrival airport is not fitted of approach frequencies. And most of small airfields have no departure/arrival service.

In another vein, this also partially explains the bug of handoff from center to arrival airfields when the latter is equiped with unicom frequency only . If you want to get the right text on prompter you must disable/enable VoxATC before enterring the destination airfield area (5nm) you'll then be asked for an intial contact to the current center and so the procedure will be correct until the end of flight.

I'm back from the West Coast and I can also confirm this misbehavior at E45, even with fsaerodata. Jose from fsaerodata is following this thread and he may have some future insights on how to fix the issue. I have personally never seen this error before and I have been using VOXATC back to version 6 and with FSX, FSX-SE, P3d3 and P3d4, although I only have used VOXATC 7.41 with P3d4. The error is specific to certain uncontrolled  airports that have mismatches between the Center frequencies contained in bvcf.bgl and the airport BGL file.

If one looks up the official FAA entry for E45:

https://nfdc.faa.gov/nfdcApps/services/ajv5/airportDisplay.jsp?airportId=E45

It states:

Quote

• APCH/DEP SVC PROVIDED BY OAKLAND ARTCC ON FREQS 121.25/327.0 (ANGELS CAMP RCAG).

In the stock bgl file, the airport does not have an approach or departure frequency but rather an independent Center frequency, even though it is not a true Center frequency. The FAA says that the ARTCC provides these services. By adding 121.25 as an approach and departure frequency,  as JetBlack suggested above, everything more or less works okay, since the conflict is eliminated. Having a Center frequency included in the airport BGL file looks like a fudge that MS used to allow the correct behavior with the default ATC. Unfortunately, VOXATC looks at a center frequency as just that, not as departure and approach frequencies. Since it now sees two conflicting Center frequencies, the whole Center sector boundary algorithm goes in a ditch.

Edited July 17, 20187 yr by jabloomf1230