Scenery Tools Update

22 comments on “Scenery Tools Update”

1. Sure hope there is going to be a fail safe for static planes that will remove them if you pick that ramp start.

   i.e. start x-plane, x-plane puts statics, change ramp start, if x-plane put a plane there it will remove it. Or we are back in the “someone put a static on the ramp start”.

   1. Since Austin is still working on the implementation, I don’t know the definite answer, but my expectation is that when you re-initialize a flight, the static aircraft spawner (and dynamic aircraft spawner) can wait to see where YOU pick and then fill in the blanks – the two spawners need to not step on each other either. (Some time ago, maybe 1035, I set the dynamic spawner to try to keep each dynamic plane away from the others).

      If you maintain a continuous flight without restarting, well, don’t taxi into an occupied ramp position. 🙂

      1. “If you maintain a continuous flight without restarting, well, don’t taxi into an occupied ramp position. :-)”

         Well that goes without saying, as long as ATC does not send you to a spot with a plane in it. Since no way to pick what ramp you want (with ATC) after landing.

2. Ben, I hope this system will examine and honour the equipment type flags on the start points. Otherwise Austin will probably get a whole new bunch of “there are jumbo jets spawning in the GA parking area” type complaints. Having the equipment type honoured on each gate/ramp for AI aircraft spawning would be welcome.
   Cheers,
   Michael

   1. We will be -extending- the data on the parking spots so that we can do a better job of spawning. Details in a future post.

3. Could you place a warning in WED rather than hide the static aircraft?
   I’m thinking of the airports that have statues of aircraft, the static aircraft are the closest approximation.

   1. How to handle “museum” aircraft is still under discussion.

      1. Thanks, there are quite a few “hanger queens” that can be quite iconic among the locals, so I’d hate to lose the ability to place static airplanes. Otherwise, sounds great!

4. excuse me sir,

   but, a while ago, you have mentioned about a possible development of an adequate X-Plane .obj export plugin for 3ds max, has been there any further progress on that matter?

   1. There is already an adequate exporter – the one from step2sky.

      There aren’t any new developments – I’ll post when there are.

5. Any plans for an update to the AC3D plugin Ben?

   Its good to read that the blender plugin is being updated, but the AC3D one is lacking some features, such as the Anim_Loop command, and the X-Plane Properties Window has problems when lots of objects are selected.

   Cheers.

   1. I do not plan to update the AC3D plugin. AC3D lacks native support for the things we need in a 3-modeler for X-Plane.

      1. It does? Please enlighten me!

         It’s done everything i’ve required it to so far, except baking Ambient Occlusion.

         1. Maybe I’ve missed something in a new release but:
            – AC3D doesn’t actually support animation. My plugin tries to hack animation into place via plugin trickery. It’s barely usable. For example, you can’t edit your model unless it’s in its rest pose because the editor itself doesn’t know the crazy animation things the plugin has done.
            – Therefore there’s really no hope of doing skeletal animation, which is how the next-gen OBJ format is going to work. Every real 3-d modeler can do this.
            – AC3D doesn’t let you move a mesh without editing its vertices (or animate this way).
            – As you said, it doesn’t bake.
            – The number and power of modeling features, such as slicing, topology operations, UV unwrapping…it’s not in the same class as serious 3-d modeling programs.

            1. Thanks for the info. I’m still finding it pretty usable, but i wasn’t aware of its shortcomings. Makes sense that you wont be updating the plugin now!

6. Hi Ben,

   Any chance to have a TMS viewer inside WED ? In know these are most of the
   time in transverse Mercator whereas WED is in spherical but on the scale of an
   airport the induced inaccury would not be a real issue.
   As you know many (most) of X-Plane runways are off by a few meters, sometimes
   more, I guess the reason is that not all users are able to provide the right geotiffs
   to WED and work with misplaced photos .

   Another suggestion : you have mentionned many times that WED development was
   difficult and time demanding. JOSM is a highly developed tool that works like a charm and has advanced tagging features (in addition to TMS, WMS capabilities and even
   reprojection of coordinates) . Wouldn’t a unique script to turn OSM files (with appropriate tags defined by you) to dsf (and back) a much easier way to go ?

   (sorry if this has already been discussed before)

   1. Hi Oscar,

      Please file a bug against WED for Mercator projection. If you have a good real-world example where (1) the error of not having a real projection causes an error and (2) the use case is realistic, please attach it so I can see what’s going on.

      Regarding JOSM, I’m not sure what problem you’d be trying to solve – WED and JOSM sort of work in different problem domains.

7. Hi Ben,

   You read it too quickly I am afraid, I said the exact contrary, in particular I do not blame any WED bug but just point the lack of one (important to my mind) feature.

   I repeat :
   (1) WED does not have an automatic TMS viewer capability
   (2) therefore many users end-up stretching their orthophotos “by hand” when building their apt.dat file (of course I know it is not the right way to do it but this
   is just a fact) and THAT leads to wrongly placed runways.
   (3) I mentioned that perhaps you didn’t include such a viewer because that would imply some additional reprojections (which few viewers are able to) but said that EVEN not doing a reprojection wouldn’t be noticable on the scale of an airport (and you ask me to prove the contrary to what I said).

   On the second point: my viewpoint is that WED and JOSM are both tools to encode vector data (one in OSM format, the other in DSF, this a essentially a matter of translation). Since the latter is largely developped and also very good, I suggested the possibility to build upon it rather than building things from scratch (but I admit it is probably too late now).

   1. Ah – my mistake – I totally mis-read this.

      Yes, a TMS server is a possibility. But…where will the tiles come from? File a feature request with a -specific- tile server that we can use within our license that is useful to X-Plane users and I will take a look. (In the past, the only requests I have gotten have been Google and Bing – both license-incompatible.)

      I’m not that excited about WMS…I think the world has basically figured out that serving pre-cut tiles is a much better architecture than having the server do a bunch of poorly scaling server-side image processing every time the client scrolls. 🙂

      Re: JOSM, at this point so many of the high priority feature requests in WED are very X-Plane specific:
      – WYSIWYG Taxi sign editing
      – WYSIWYG facade editing and facade textured previews
      – Output to MeshTool
      – Writing DSF road networks

      1. I hope and WYSIWYG for painted lines (.lin) too!

         1. Somewhere on the road map is to have -every- art asset have some kind of reasonably WYSIWYG (within the limits of 2-d orthographic projection) preview!

8. One can use NoniMapView to download 4096×4096 px tiles including the lat/lon for each of the for tile corners in any zoom level and use a script which positiones the downloaded tiles via manipulating the file earth.wed.xml.
   This is exact.

Comments are closed.