OBJ8 spec isn’t updated for the manips yet but if you look at the Blender 2.7 GITHub project, there is a working spec.

Looks like we might be missing the datarefs? I’ll investigate.

OK, thanks !
Pascal

Using DSF2Text is _not_ going to disappear.

Just some precisions, I work mostly on texture, not roads or objects. I work with GIS databases and assign arbitrary ter files to the base mesh triangles. I also add overlay triangles where needed. These are the only operations I use, but they require access to the dsf.

Ben, I’m currently working on high quality scenery production, at the scale of a few dsf at time. I’m using techniques I’ve been working on for years. I build my own (valid) dsf from scratch, in text format (not the binary format). If this possibility disappears in the future, I can stop right now all the same and find a new job. Sorry for being slightly dramatic, but I’ve invested a lot of time and money into this project. I can give more details in private.
All the best,
Pascal

Please file a bug and include the full Log.txt; this may be unrelated to your layout. If you validate that there are no colocated points in the ATC layouts it should not be possible to get this message due to your layout. I think there is a fix for a related problem in beta 6, but you’ll need to check the notes once beta 6 comes out.

Well, let me be clear: I am absolutely _not_ proposing that X-Plane become a closed platform!!!!!

As an example of the kind of decision that I have to think about (I’ll write more on this later), there are two ways to support content creation:

1. Publish the file formats and let people make stuff for the product.
2. Publish content creation tools and let people use them.

We do both; if you think of content going through a pipeline, the question is: how much of _LR’s_ pipeline does content have to go through to get into the sim. Right now the answer is “potentially none” – in that you can write your own OBJs by code or even your own DSFs (gasp) because the file formats are published.

The up-side of the open format is that -anything- is possible; this is the most open and most flexible we can be and we are never a bottleneck.

The down-side of the open format is that it allows for a lot of our pipeline to be bypassed, and in that event, validation code may be skipped.

By comparison, for the X-Plane Scenery Gateway, that pipeline is heavily specified – content must come from WED, full stop, and it goes through WED’s validation layer. This means that we have a tool to improve quality: any time something goes wrong, we add validation -in WED- to catch the problem.

We have no such strategy for DSFs – for DSFs we have to catch them in sim, at load time, while the user waits.