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
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.
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.
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.
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.
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
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.
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.
: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
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.
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.
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
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
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?
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.
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
62521on April 15, 2019 6:56 PM
Prospero246 Thanks for the compliment. Even tho did not make final cut
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.
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.
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.
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
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.
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
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.
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.
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.
: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.
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.
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.
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.
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.
Prospero246 Thanks for the compliment. Even tho did not make final cut
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.