Rbrown222 reported issue XSG-2033: Bezier follow up on October 12, 2016 6:40 PM
Closed

As I mentioned the Bezier element does not work properly. In particular, new Bezier nodes cannot be made.
In reviewing Bezier nodes placed by 1.4 and 1.5beta, these do work appropriately in 1.5
So obviously, the code recognizes Bezier node s place in earlier versions of WED but not in current version.
A sample of the Bezier function using older WED

  • Jennifer Roberts October 13, 2016 8:49 AM

    Please see bug WED-559 Closed .

    We have had multiple people report this problem and all reports are consolidated on that one bug report.

    We have also had no luck finding consistently reproducible steps. It seems if WED is quit and restarted the issue goes away. If you can find steps that cause it to always happen, please comment on WED-559 Closed and I'll look into it further.

Rbrown222 reported issue XSG-2034: Found possible fix WED-559 on October 13, 2016 9:45 AM
Closed

In trial and error found that 1. drawing a line with nodes and completing, none of the nodes could be converted to Bezier.

2. That creating Bezier on the fly so to speak was successful

Will try testing now creating real structure. Will keep you advised

Rbrown222 reported issue XSG-2035: Video of problem on October 13, 2016 11:31 AM
Closed

Live from Down Town Winnipeg!
With the first line being drawn nodes are made and in obvious cases converted to Bezier nodes on the fly. Subsequently, the video shows how they can be readjusted.
This readjustment post line drawing is also seen on Bezuier nodes previously drawn with an earlier WED (either 1.4 or 1.5 beta)
The secondline is drawn without introducing intermediate nodes. When the node is introduced it can function by allowing the line angularity to be changed BUT when an attempt is made to convert to Bezier node, only the arrows go round and round without influencing the parent line

An otherer feature or lack there of. In the previous versions, one could go back and change ANY node into bezier. This is the optimum, allowing for rough insertions to be refined after.

  • Jennifer Roberts October 13, 2016 2:45 PM

    Hi Rbrown222,
    Can you please keep all your comments to one bug report? Having it split with each update and comment on different reports, on different bug bases (some WED, some XSG) is making it very difficult to keep track of your issue.

Rbrown222 reported issue XSG-2036: Bezier works with taxiway on October 13, 2016 12:29 PM
Closed

Just created new "taxiway". Bezier node assignment and function normal

  • Jennifer Roberts October 13, 2016 2:45 PM

    Hi Rbrown222,
    Can you please keep all your comments to one bug report? Having it split with each update and comment on different reports, on different bug bases (some WED, some XSG) is making it very difficult to keep track of your issue.

Rbrown222 reported issue XSG-2037: WED-559 on October 13, 2016 12:54 PM
Closed

Polygon. You can see from the video, polygon formed. To get the top left corner to convert took 4

{option}

+CLICK+CLICK. As you can see each time I the added a node adjacent to the bezier node, the node was a Bezier node. Once past the right upper corner, only plain node.
Down the left side, option + click caused Bezier nodes.
This is weird to say the least but nice to know taxiways work without problem, lines have major problems and polygons weird results

  • Jennifer Roberts October 13, 2016 2:45 PM

    Hi Rbrown222,
    Can you please keep all your comments to one bug report? Having it split with each update and comment on different reports, on different bug bases (some WED, some XSG) is making it very difficult to keep track of your issue.

  • An unknown user October 26, 2016 1:51 PM


    IMO the video shows WED behaving as intended. If a segment with a bezier node on either end is split, the inserted node needs to be a bezier node, to preserve that segments shape. Only if the nodes to both ends are non-bezier, (i.e. the segment is a straight line) a plain node will be inserted.
    This behavior is unchanged since WED 1.2, although the ability to initiate the split via mouse click was expanded in WED 1.5.

Rbrown222 reported issue XSG-2040: Follow up WED 559 on October 16, 2016 9:59 AM
Closed

:ine work. two videos showing problem. The first placement of reference nodes on crossing line, the placement of line from A to B. Then placing a Bezier node in center of line. NOT
The second video starts the same but in this instance the bezier node is placed in the middle of the line before completing the line.
On reviewing that line the bezier poibt is obvious and a little bit functional. In previous ver of WED, the individual control arrows could be varied ti length to custom fit the line. Here they stay the same but functioning.
Where are the old Bezier point and their versatility

  • numberonesuperguy October 17, 2016 5:13 PM


    @Rbrown222
    If I understand correctly, I saw the same problem on my Mac with v1.5r3
    The new beta, WED 1.5.1r1 has fixed it for me.

Rbrown222 reported issue XSG-2140: Hold for runway change on November 17, 2016 6:22 AM
Closed

I am constantly ( 80% ) betting Hold for runway change. I have almost completed this scenery package and in testing phase. But being bothered by this command. Occasionally clearance will come through after 10 to 15 minutes but most times not.
While this feature can be a real life experience, changes in wind direction are not that radical or prolonged, even taking into consideration traffic on final.
In the sim world, it is a pain in the posterior.
How can that feature be turned off? It is not like this is a new problem as there are notes in the forum dating back to 2012 at least.
Really would like a solution.

  • Jan Vogel February 23, 2021 4:53 PM

    This is a problem with Xplanes ATC, not the scenery. Small updates have been made to ATC logic over the last years, but no significant advances. Since this problem is not isolated to a specific airport or even scenery in general and well known… I suggest to close this report.

An unknown user reported issue XSG-2169: Verification Errors in reference to scenery pack 44930 on November 26, 2016 5:00 PM
Closed

I wanted to extend the taxiway into the water just north of the sealane but there are numerous errors with taxi routes and without them cleared I can not even save my addition for amphibious craft as export scenery pack

  • Jan Vogel February 23, 2021 5:58 PM

    Several updates to this airport since then - this report can be closed.

An unknown user reported issue XSG-2175: Multiple Taxi route Verific... in reference to scenery pack 44930 on November 29, 2016 2:10 PM
Closed

This file was opened in WED to extend the paved taxiway into the water by the sealane as exists in reality, but before beginning the open file presented multiple Taxi Route errors

  • John Rogers November 30, 2016 1:24 AM


    I am able to download the current approved version and it has no error messages when I validate it. I can make the requested changes on my end. Are you talking about extending the pavement or just the taxi route?

  • FlynBrian December 1, 2016 9:14 PM


    Just the pavement to the south side of the road descends into the water

  • Jan Vogel February 23, 2021 5:58 PM

    Several updates to this airport since then - this report can be closed.

pk4367 reported issue XSG-4361: "Facade Clock wise" Error in reference to scenery pack 56754 on January 9, 2018 7:48 PM
Closed

When I try to open this airport in WED 1.6.1 and Validate, I get an error "Polygon Facade is wound clockwise. Reverse selected polygon to fix this" error and I can't export the pack.

  • Julian Lockwood January 10, 2018 11:41 AM

    Suggest:

    View | Zoom Selection (to locate polygon)
    Delete and re-create polygon.

  • John Rogers January 12, 2018 12:45 PM


    Is this the version of the airport that you downloaded only or have you made modifications to the airport? I just did a test download and export of the scenery and had no problems.

Rbrown222 commented in reference to scenery pack 62521 on April 15, 2019 6:56 PM

Prospero246 Thanks for the compliment. Even tho did not make final cut

GregBC reported issue XSG-16009: ATC flow and taxiways in reference to scenery pack 105104 on February 25, 2025 4:51 AM
Closed

CYVR typical operations are as follows:
no winds: Arrivals 26R, Dep 26L
East winds: Arrivals 08L, Dep 08R
West winds: Arrivals 26R, Dep 26L
Heavy, jets, turboprops all as above.
Smaller prop planes will arrive/depart on 26L/08R
13 is only used for arrivals during strong to very strong ESE to S winds. In this case 08L is used for departures to avoid crossing routes.
31 is basically never used at all for arrivals or departures.
Taxiways a bit off as observed by AI aircraft movements, especially on N runway for exiting runway. Also, AI heavy aircraft crossed 08R on taxiway H, then all the way along south taxiway to depart 08R in east wind. That never happens.

  • Robert Grant February 26, 2025 6:47 PM


    I have submitted an update for approval for your concerns above. Im not sure if it will address them all however I have given it some attention. When I did the last update I basically steered clear of any AI stuff - taxi and vehicle routes as I was mainly interested in the aprons and runways.
    The taxiways are correctly shown. Not sure what the issue is with the AI aircraft but we cant draw bent taxi and vehicle routes so XPlane and the AI might not quite get it 100% right.
    While you have local knowledge of the airport , trying to put in "what does happen" and "what never happens" can be tricky so I guess its a best fit scenario.
    I've worked in aviation since I was 21 (52years) and 2 words I say to people you should never use in aviation are "should" and "never".
    I've also realigned the runway thresholds for 08R and 26L. Not sure how they sneaked through last time but the displaced thresholds are now correctly depicted.
    Hope you enjoy the update.

  • GregBC February 27, 2025 8:26 PM


    That's great. Thank you so much Robert. And I take your point about wording.

    I could have worded things better in my post. I do know someone who has worked ATC at this airport and would still say the same about runway 31. It is so rarely used that for the sake of x-plane, safe to say it is 'never' used. This is partly due to the way winds work and that we don't get intense N winds (due to valley alignment and mountains) and strong surface NW winds in region become more ENE at airport.
    Reality is hard to code into airport flow rules, but in general all arrivals on N runway and all departures on S runway is how CYVR works day in day out. Of course the smaller commuter aircraft using the south terminal will request (and receive) arrivals on the S runway when things aren't too busy, to avoid a long taxi. I guess you could code things as 'props' use the S runway 08R/26L for both arrivals and departures and this would be good representation of reality in x-plane.
    More details on the AI thing - what I observed was heavy AI aircraft (B737, A330) landing on N runway, but coming to a full stop in runway, then turning 180, and taxing back to a previously passed taxiway to exit the runway. In real life that would never happen - no idea if that is just AI bug or something to do with the airport coding, or both. I know very little about AI aircraft in xplane.

  • Robert Grant February 27, 2025 10:03 PM


    Tanks Greg for the feedback and that makes it a little clearer regarding the taxi issue. So with the 180 which runway specifically 08L or 26R? I'll take another look if it doesnt work out. Just add to thsi bug report if it still doesnt work and I'll take another look.

You must be logged in to participate in the discussion