WorldEditor 1.5 beta 3 is now available on the WorldEditor download page.
Besides a number of new features, WorldEditor 1.5 has much stricter validation checking; our is to get to a point where, if WED will export it, your scenery pack doesn’t have problems. This has two implications for the beta.
You’re Not Validating My Work!
If you haven’t tried a WED 1.5 beta, you may be surprised by how many validation errors WED finds. In particular, Ted coded a hot zone and runway analyzer that catches mistakes with taxi routes. It turns out that it’s really, really hard to get hot zones perfect by hand; even experienced WED authors who know all of the hot zone rules usually miss a few just due to the shear number of hot zones in a large airport and human error.
We have also seen airports on the gateway where the author clearly did not understand how hot zones were supposed to work at all.
We put the validation in because X-Plane’s ATC absolutely cannot function without properly marked hot zones; they are the only way that the ATC understands how airplanes are operating in the movement area. I think a significant amount of “weird ATC behavior'” will go away as we get better airport data that passes validation, and it will make the remaining real bugs easier to spot.
It’s not fun discovering that you have a big pile of problems to fix in your airport. To that end, we have been working on the docs to make sure that the ATC system is clearly documented, and we are now working on the validation messages themselves to make them more clear. If you find some part of the docs themselves that aren’t clear or have mistakes, please file a bug on the X-Plane Scenery Gateway’s bug reporter.
To be clear: airports already uploaded to the gateway with WED 1.4.1 will remain there, even if they fail validation; we’re not removing airports. But if you want to upload new work once WED 1.5 comes out, you will need to fix existing validation problems.
Who Will Validate the Validator?
The validation code may not actually be correct! People reported a number of high profile validation bugs, and they have been fixed in beta 3. But this doesn’t mean we have found all of the problems.
Please run your airport through beta 3, and if it fails validation, read the docs. If it seems like what you did is valid but WED is saying it is not, please file a WED bug on the X-Plane Airport Gateway’s bug reporter.
When WED 1.5 goes final, it will become the required version to upload airports to the gateway, so we want to be sure that the validation code is enforcing what we want enforced.
Hi,
I have been working on upgrading one of my own local airports (EKAH) to 10.50. And after WED Beta 3 it is actually validating OK. But I seem to see some issues, but I am not sure that it’s me that is the problem or is it X-Plane 10.50 or is it WED.
Issue 1.
Sometimes a AI plane will wander off Taxi Route. It looks funny and it seems that the pilot simply does not know what way to go. But it is not consistent. I have seen a B737 suddenly make a 360 in the middle of the runway or when an aircraft is leaving the gate it seem not to know witch way to turn (but only sometimes). And yes I have the Taxi Routes all the way to and from the gate. As said WED Beta 3 do validate OK. So I have no clue of why this is going wrong.
I actually got all the ATC Flow wind rules working (kind of a victory for me because it is difficult for me to understand fully the ATC Flow).
Issue 2.
I am trying to find the right name for the gates (Ramp Starts). My logical conclusion is to simply call them by the gate number ex. 1, 2 or 3 and so on. But when ATC is telling me (after landing) on witch to park, the yellow ATC line will say (“Callsign” Gate 4 Taxi via…) and so on. But the voice always leave out the number and say (“Callsign” Gate Taxi via…) with no number. But I have no clue what naming roules you expect for Ramp Starts (Gates).
You would probably expect a bug report, but I want to be sure that I understand this correctly before I will call it a bug.
I made a video (https://youtu.be/Hlvhdi_gRT8) that clearly shows some of the issues I here mention. The last 15 minutes is a top view showing AI traffic in the airport. I have added 5 AI planes and all in all it works OK. But sometimes it just gets funny.
The airport is with OrthoPhoto and custom buildings. So it will never get to the Scenery Gateway. But I might strip it from all custom things in the future and make a “clean” version for the gateway.
This was a long one (and sorry for my English). I hope to get to the bottom of this so creating airports would become less time consuming.
Regards Michael
Ohh, I almost forgot…
Sometimes I get the following message:
0:14:26.884 E/SYS: +——————————————————————————-
0:14:26.884 E/SYS: | Don’t send me co-located points!
0:14:26.884 E/SYS: | point=9
0:14:26.884 E/SYS: | lat=56.31
0:14:26.884 E/SYS: | lon=10.63
0:14:26.884 E/SYS: | (fm_update_otto_natc_listen.cpp:97)
0:14:26.884 E/SYS: +——————————————————————————-
I think I understand that there is something wrong with a Taxi Route or point. But I have no clue to how to find witch one.
Do you have some kind of guide line on how to find this problem?
This is a known bug we are looking to fix for 10.51.
Is it all a bug Ben? I just today reported the issue on the Gateway site surrounding missing WAV files and gate names not playing. Plus it appears Tie-Downs noted in WED are being treated as Gates in X-Plane.
Please look at the picture below.
http://xplanetaiwan.blogspot.tw/2016/09/wed-1.html
How do I use WED 1.5 Beta 3 to draw the proper take-off path? Will not let the plane out of the runway
Do not mark the turn-around as being part of the runway – it is not! The turn-around needs to be marked as hot for arrivals/departures for the runway, and the taxiway name can be blank since it is probably unnamed.
Something like this works fine:
http://imgur.com/a/QRCz4
That works! I’d suggest the last straight taxi route segment over the runway stripes be marked as runway and not hot taxiway, but x-plane and WED can tolerate it as it is.
Ok, after seeing this screenshot: on my iMac the ATC lines look thin as ever in my WED1.5b3 version, no wingspan markings or wheel thingies… RWY segments are still red (or white, if I mark the segment ‘runway’), not blue… file a bug, I presume?
Hi Ben
Ok in the guide for ramp starts
http://developer.x-plane.com/?article=guide-to-ramp-starts
You state:
“If you have included more than one airline code in this spot, X-Plane will randomly pick one BEFORE the library is checked. If the airline code X-Plane selected is not found in the user’s library, a random result will be placed instead.”
This will lead people,like me, to believe that users can somehow create their own library of aircraft that could be randomized by WED ramp starts.
If this is true, could the be a little more elaboration on it.
If not, you may want to reword that.
Yes – if a third party library provides aircraft using the path scheme that we expect, we will pick out those aircraft – potentially including airline matches.
Cool
Is this “path scheme” documented anywhere yet?
not yet.
Where can we find the updated manual for making Taxi routes?
http://developer.x-plane.com/?article=atc-taxi-route-authoring
http://developer.x-plane.com/?article=atc-flow-authoring-in-wed
I started testing KSBP and it seems there needs to be a way to override the hot zone. It’s telling me that taxiway A is a hot zone for RWY 7 departures. Even after changing 7 / 25 to one-way (excluding RWY 7)…which may or may not be valid. Either way, it didn’t seem reasonable taxiway A should be a hot zone and thought I would consult first. Does this seem right? Thx. — Greg
http://155.178.201.160/d-tpp/1610/00989AD.PDF
Thanks Ben.
Yyyyyeah..that’s not so good. How many meters is it from the 25 threshold to taxiway A?
Also please file a bug on the gateway bug reporter.
Funny working on KSBP also and ran into the same thing, also taxiway G, gets a hot zone. Made sense for 25 arrivals, kind of, so I guessed 07 departures would be hot zoned also, do not want a tall tail in your face if you do not get up quick.
http://www.airnorthwest.org/TW_Museum/KSBP.png
HI Ben
Looks like about 302 meters
http://www.airnorthwest.org/TW_Museum/Distance.png
Do they land 25 arrivals? 302m isn’t a ton of space.
According to the data they land/depart on both 07/and 25
http://www.airnav.com/airport/KSBP
Left pattern for both and nothing in the notes stating not for use.
The tower is closer than 302 meters, granted it’s off axis from the runway centerline. And then the ramp parking is right there too. So I’m trying to understand is this a WED thing…or is this *really* how it’s done IRL? In the end, I guess I don’t care as far as WED goes but it seemed like a bug, if it’s not, so be it.
There is certainly no indication from the orthophotos that the area off the end of 25 is restricted.
OK, doesn’t seem to be an issue after all. Thx.
i don´t know why but after 1.50 when compile my airport on wed now have low fps, even when use WED 1.4.1r1,, its the same airport, i don’t add nothing new, all is the same, seems like 1.50 use more resources…
WED 1.5.0b3 validates airports with textures (tiles, objects, …) whose size is not a power of 2 (while the log.txt shows a warning for those textures). Is that intended?
Well, we haven’t provided a power-of-2 validator, so … yes.
I guess it is of no concern for Gateway airports.
Right – it does not apply to the gateway, and we had to pick our battles – we didn’t have enough dev time to put every single validation possible into 1.5; we focused on ones that were causing serious problems in real use.
If you are making custom scenery, you should absolutely read _X-Plane’s_ log and make sure there are no problems.
The reason why it’s so important to get validation into WED for the gateway is to _require_ that authors address their errors before sending them on to the repository.
Hi Ben and LR crew,
I’ve updated ISDG’s YMML (and YPAD) using WED 1.5 with full populated Gates, sizes etc. I have a question regarding Land And Hold Short operations (LAHSO), and whether they are supported by the AI.
At Melbourne YMML the longer runway 34 is used during peak periods for landing while the crossing runway 27 is used for take off. If I’ve set the runway taxiroutes up correctly, including the intersecting hotzones (purple), will a FLOW with this setup actually work? In other words, will the code allow both runways to be active if the flow rules say so?
I’m asking because if it isn’t really supported these “peak hour” flows can be removed for simplicity.
Cheers,
Michael
The AI/ATC does not support LAHSO operations yet. It does support non-LAHSO crossing runway operations, so if you enable two crossing runways for simultaneous landings (or landings vs departures) then the aircraft landing on what should be the LAHSO runway will go around if there is a simultaneous landing/departure on the other runway – even if it could have held short. You will get correct departure behavior in that the crossing departure will launch once the arrival is past the crossing point.
If an arrival lands short and has a taxi route off the runway -before- the crossing, I a not sure if the departure rolls immediately (as it should) or when the crossing runway is vacated – the tower ATC might be too conservative in this case.
LAHSO is hard for us because the AI is written to be generic – you can tell X-Plane to fly -any- aircraft you can model (albeit with mixed results) – there is no custom data you have to enter to teach the aI how to fly the plane.
This means the AI kind of flies the planes by the seat of its pants, and can’t -guarantee- a particular landing distance. The overall landing distance estimation is a heuristic Austin came up with, but it is almost certainly too conservative, where-as if you know a lot about a specific aircraft you might know it can hold short if it uses max brakes, reverse thrust, and lands firmly without wasting a lot of runway.
Thanks Ben. That’s what I suspected, and therefore having explicit LAHSO flows, in addition to normal cross-runway flows, is probably overkill.
Is there a trick to getting AI aircraft to spawn on the ramp starts? I get static aircraft to show on them (randomly as expected), but no AI. The AI I have set in my preferences are GA (172, baron, etc) and while the planes show near the airport in-flight, they never spawn like they used to in 10.4x. I set export target to 10.50 for the pack, ramp starts are gate or tie-down, equipment types are props/turboprop/jets, sizes are mostly B, a couple C, ramp op type is GA except for the two gates where they are airline. I tested the airport flow by filing a flight plan and got the yellow arrows properly placed. I noticed under airport there is an option to “upgrade ramps” which seems to do nothing. I attempted to establish the dataref for the debug logging, but it shows nothing useful (in log.txt) regarding why the aircraft are spawned in-flight rather than on the ground.
Have spent a few hours on this and no love. Any clues? Thanks! — Greg
Turn on the art control atc/debug/log_spawn and you can see how the AI is deciding where to put aircraft.
As I said above, I did this and since the debug setting is not persistent, it seems to indicate no additional information. That is, I set it after the AI have been spawned in-flight, never land at the airport and never spawn ON the airport. Is there a global setting for the airport that I missed? Worked before 10.50, no longer works once I use the new WED. Clearly I’m missing something simple. Thx.
Maybe found the answer…says longest runway is not paved. I use transparent runways because I use a custom texture. Any way around that? Thx.
Bug filed for WED.
No work-around right now.
Is there a way to make aircraft to push back?
Hi all,
I am working on a wartime usaaf base X35M. It has 3 runways, the first being 20/02, however the validation check throws it out saying the high end is not within 19 to 36. Any ideas why?
nb I am converting FSX packages so I am only using the smaller demo version (space reasons on my MBP). I have the full monty 10.50 on my Mac Pro’ s.
The runway should be 02/20.