Jump to content

medx421

Members
  • Posts

    518
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by medx421

  1. 7 minutes ago, Nick Cooper said:

    Hello.

    Evidently that would work.

    I think Ken has already said that he does not modify default files.

    That does not leave that option open to him.

    The option remains open to anyone willing to go down that path for themselves.

    Okay, partially fair, but at @Ken Hall's discretion, he could make a compatibility version with the BVU identifier if he chose.  The consumer base and need supports it.

  2. To Scott's point though, the Aerodata or aero.sors modified default APX17190.bgl would reflect BVU instead of 61B, so modifying the product .bgl to KBVU should exclude the modified default.  That's how I fixed the SCA airport issue.  Changing the ICAO isn't difficult.  It's changing the elevation adjustment.bgl, if it exists, that is a bit more challenging.

  3. 15 minutes ago, jfwharton said:

    I do have one question, however, regarding updating the navaids in P3D/FSX.  Why should updating the navaids affect the field elevations?  I would think that all that would change would be the navaid frequencies, headings (for ILS approaches) and stuff like that.  Nothing that would affect the elevation of the airfield.

    What it does, in this case, is makes FSX/P3D display 2 different airports at the same place.  As the 2 fields are designed differently, and with separate elevation data, it throws a real wrench in the mix.  If you want to see other examples of affected fields, go to any of the below providing you have NCA or CRM also:

     

    KDIJ - Driggs-Reed Memorial - Formerly U59

    KGOO - Nevada County - Formerly O17

    KMPI - Mariposa-Yosemite - Formerly O68

    KJAQ - Westover Amador County - Formerly O70

    • Like 1
  4. 40 minutes ago, Ken Hall said:

    Just woke up and saw this, we were forced to go with 61b as p3d recognises it as that, like Nick said if p3d v5 changes the name to KVBU   then some renaming will be needed for V5 files.

     

    So this is what I stumbled on with SCA and having the aero.sors update as well.  I managed to fix the issue for the SCA field, but had to do some ADE and XML work to do so.  I made those available to the community.

     

    That said, I am going to be in the camp with a base dataset having the field as KBVU.  I don't plan on updating to v5 right away regardless of if it has 61B or BVU in the default dataset, so I'd like to get a fix regardless.  I imagine, if I have to do it myself, it will be the same ADE and XML work required for at least one of the BGL's for this product.  I am however, hoping a fix is coming for those of us who do have updated data, but aren't eager to make the migration to v5.  This was to be a day one purchase for me, but I know (as I had a feeling) that it was going to have a conflict.  Again, I am not going to have any meaningful time to sit down with it though for a day or two.  @kmelz I understand your rule out technique.  I am in the same camp you are.  The fix is to either find a default, unmodified APX17190 as you are searching for, leave it disabled (not ideal), or have the Boulder City bgl's corrected to reflect BVU instead of 61B.  If I make headway on it before it gets addressed here, I'll post a follow up.  Keep this thread bookmarked though, because this is going to be a popular support topic :-)

     

    • Like 1
  5. 8 minutes ago, Nick Cooper said:

    That aside, P3D v5 might well change things a great deal.

     

    I don't know.  If v5 updates the ICAO's to current, then Boulder City is going to be BVU by default which is the crux of this issue.  I plan on buying this product, but am a day or so out before I can get to sit down at my computer.  If it's still problematic, I'll try and help with a fix, as I have some experience with this thorn.

    • Like 1
  6. 2 hours ago, Nick Cooper said:

    The presence of an added elevation for KBVU is still my main suspect.

    An airport named 61B could not exclude it, either in the default version or in the addon version.

     

    I was hoping this wasn't going to be the case, but had a feeling it was going to be.  We had a good discussion about this awhile back.  Have a feeling this is going to be a frequent support issue for this product.  I'm actually surprised this product didn't get the BVU designation.

×
×
  • Create New...