WorldEditor 1.5 beta 4 is available for download. The only major change here is that we seriously backed off the requirement to have hot zones off of the approach and departure ends of runways; this requirement is now only 100m.
I believe that with beta 4, our validation requirements are now correct; please attempt to validate your WED airport in beta 4 and file a bug ASAP if you find a problem. Otherwise, our plan is to make WED 1.5 beta 4 the required version for Gateway upload.
The only other remaining task to finalize WED 1.5 beta 4 is for Ted, Jennifer and Julian to go through the 75+ (really!) validation messages and review them for clarity and helpfulness. If WED tells you it can’t upload your airport, you deserve to know why!
Ben,
The validation is OK, but I think that cannot include all possible situations.
For example, in Manchester airport, aircrafts backtrack RWY23L down to 05R approach end, into a U-turn taxiway, to lineup and depart RWY05R. The view in WED: http://imgur.com/a/g7lmI
Trying to export I get validation errors that the taxiway’s hot zones should be marked also as o5R arrivals. As you might see, this taxiway never intended to be used for 05R arrivals, since normally aircrafts will touch down further down the runway.
At the end, probably will not be a problem to mark it for both runways, departures and arrivals, but restricts, in a sense, the fully customization.
What I would like to have is an option, when the airport is not for the gateway, and since that flag have been already set, to get the validation dialogue (help catches errors), and ask me if I want to continue exporting, acknowledging the above. After all as a developer of a payware airport, I have the responsibility to fix if something is wrong.
And another thing, a bit irrelevant. Can we have, for the next X-Plane version, special airport meshes?
Your message implies that you do not understand what hot zones are for. You wrote:
“As you might see, this taxiway never intended to be used for 05R arrivals, since normally aircrafts will touch down further down the runway.”
Right – but it doesn’t matter.
Hot zones are _not_ about whether a taxiway is used to facilitate an operation. A 05R arrival hot zone does not mean “This is where you go after ladning 05R”.
A hot zone tells tower to keep track of aircraft in this area during an operation, e.g. “if someone is landing 05R, make sure no one is on this place, otherwise send them around.”
So..you might never use the turn-around for 05R arrivals, but IF there was an aircraft on those red zones, you better believe the tower has to issue a go-around.
So – mark those taxiways has hot for 05R and everything will be fine – you will not get strange ATC behavior. ATC won’t route 05 arrivals to this taxiway, but -if- the user decides to depart 05 and use the turn-around without talking to ATC while the AI is landing 05, the AI will go around as expected.
There -might- be some validations for which we could demote them to ‘warnings’, but honestly, there aren’t going to be many, and the ones you really care about really matter.
In particular, if the hot zones are not built around the runway, the internal logic of X-Plane’s ATC _cannot function_. This is why we had Ted spend so much effort validating the taxi routes. Over and over we saw crazy behavior in the ATC system and it was because the hot zones didn’t meet the invariants the system requires. If there is no (at least small) buffer of hot zones around a runway, ATC will not operate.
So in this case, I cannot relax the requirement – you need to either use the hot zones, or let x-plane generate a (terrible) taxi route diagram all by itself – and if X-Plane generates it, it will have hot zones in those places! 🙂 As a payware developer, it’s great if you fix the errors x-plane detects, but we put hot zone validation into WED because X-Plane doesn’t have the facilities to do in-simulator validation of hot zones and report them in a clean manner. In pretty much every case where WED and x-plane validate the same thing, WED’s reporting will be much more useful. The validations are meant to get you to a truly bug free scenery pack _faster_.
Finally, re mesh editing: we intend to do this someday but it isn’t going to happen soon – it requires new fundamental facilities in the rendering engine to edit the mesh that we don’t have right now. The big problem is that if the mesh is low triangle count, we need to rebuild the fundamental triangle structure of the mesh to get to high polygon count to express your mesh correctly – not trivial for a TIN-based mesh.
Thanks for the explanation; probably I was misleaded by the message:
“Taxi route W is too close to runway 23L and now must be marked active for runway 23L departures”
Also in the properties panel, Departures and Arrivals fields look more like taxi route usage (this taxi route should be used for XX departure), rather than is about the hot zone.
So, I thought as being an active route for taxi if you want a 23L departure, and not only about the hot zone.
May be, if it is possible, the text “Hot Zone” to be added to dialogues/properties, will make things a bit more clear.
Re-re mesh editing: The problem for my side (developer) is not if the mesh is low in triangles. I will add the required resolution where needed. The problem is right now that I have to include the whole tile, which might include another airport, which developer might edit his mesh too. Also any orthophotos packs (.ter based) will not work for that tile.
My proposal is if it possible (and sorry for my ignorance how this might happened), to have around the airports (for example a circle 5Nm radius from airport’s reference point?) as an airport mesh, that can be edited, without affecting the rest of the tile. I could elaborate more, if you like, by email.
Hi Ilias,
Like I said, the problem is in our engine. If you give us a nice high res triangle mesh, we have to merge the two meshes – merging two TINs is non-trivial and we don’t have code that does that.
HI there
Firstly I cant find the place to file a bug for WED
When importing Ortho , Overlay the picture are only white in WED
Regards
Lawrence
file a bug.
File WED bugs on the Gateway bug reporter:
https://gateway.x-plane.com/bugs
Use the Scenery Tools tab.
I don’t can to recreate this case by using WED 1.5b4. More to say, even importing an orthophoto file 1020×1024 .png was successful, and then, after appearing an overlay image,I have had export scenery pack and with my pleasure can see the new .dds and .pol files. Note, a .dds file is 1024×1024. So, until today WED 1.50b4 on my Ubuntu 16.04 has working fine. Thanks.
Great fix here, Ben. TYVM !!
WED-641: Fixed selected color on runway taxi-route segments when ATC tab is not being used.
Hi Ben
One thing that would be awesome is that when a validation error occurs, it shows which part of the scenery it is. The error is found at a certain place anyway – please can it be highlighted for “debugging”.
It is a nightmare to find/guess where the problem is.
Right now for each validation, an object involved is selected. Use the zoom-selected command to go see it!
We do have plans for a better validation error display, but this is not going to go into 1.5.
Great stuff – I needed that fix!
Just realised WED now selects the problem ATC routes that it’s unhappy with. With ‘zoom to selected’ shortcut, that’s saved ages of guesswork, wish I’d seen it sooner.
The problem with 2 bug trackers is… which one should I post this?
My airport validates fine, but flying around and even just watching 10 AI planes occasionally (once every 5mins?) stops the sim and brings up a full screen dialogue – ‘Don’t send me colocated points: point: ppp, lat: yyy long: xxx’.
A comment on error messages: One verification message told me that one runway had an erroneous name (’02G/20G’). If you could write error messages that give examples of correct values, not just say ‘its wrong, try again’ that would be great.
Colocated points will be fixed in 10.51. Generally, file x-plane bugs in the x-plane bug reporter and WED bugs in the scenery bug reporter. But we’ll move them if it turns out the bug is in the wrong place.
Question: when setting taxi way size, the docs say the X-plane will allow that size and one smaller, i.e. if taxi way size is “C”, aircraft of size “C” and “B” can use it. Is this accurate, and if so, why not let any size smaller use the taxi way, i.e. if taxi way size is “C”, aircraft of C,B, and A can all use taxiway… I think this more accurately describes real life practice, especially Charlie airports…
Thanks, having fun with latest beta !
Terry
This might be a doc bug. “The size and one smaller” applies to RAMP positions – that way we don’t park a Cessna 172 at a class E spot for a 747. For taxiways, it’s the size and ALL smaller.
If the docs got that backward, send me an exact link and we’ll fix it.
In this doc:
ATC Taxi Route Authoring.html
this line:
Size
The size field limits traffic to aircraft small enough to fit on that taxi route. X-Plane will allow traffic of the size specified and one size lower–i.e., set this field to “B” to allow aircraft identified as size B and A to use that taxi route.
Guide for Ramp Starts.html is correct.
Thanks !
Terry
Thanks – we’ll fix it.
Thanks for a great product Ben and team.
I have already filed a bug report for this but was curious about the rationale.
When validating a non-towered airport I was instructed to delete all ATC frequencies. Is this due to the state of the ATC system? If a non-towered airport is within radio range of ATC, clearance delivery should be available. Yes?
Cheers
This is a design limitation of X-PLane. X-plane can’t model clearance delivery services _except_ in the case of a towered airport. This includes relays and picking up clearance by phone and being given a departure window.
Someday X-plane will allow IFR departure from untowered airports, and then we can start to allow this kind of thing; until then all you can do is take off and pick up a popup clearance.
Ben a question, how I can define an airport as “runways follows contours terrain” or not?
thanks
The check box is on the airport in WED.