Yes. But it is possible that it will not be available for beta as quickly as the Mac/Win versions. I am actually not sure about the build status of the Linux version – if there are still problems getting all of the libraries to work on all Linux platforms, I will not delay Mac/Win beta for Linux.

Of course, it is open source, so if you want a Linux build you can have it -before- everyone else by cloning the GIT repo and compiling it yourself.

The main problem is that the packaging of libcurl is different on different distros, so it’s not trivial to build a single version of WED that works on all versions of Linux.

Right – I did round-trip testing with the Gateway text format and numeric output stabilized after one round trip. This is definitely not the case with binary DSF.

No – for 1.4 I think we may (for the first time) have real release notes but they are not compiled yet. The source tree is public so you can browse the GIT commits, but they’re not really a feature list.

@snagar, The lossy that Ben mentions for apt.dat and WED’s XML files are not like the lossy you get with importing DSFs. If you always use the original WED XML to produce the DSF, the DSF will not lose anything. However, if you import a DSF into WED, then export (make a new DSF), the new DSF will have lost information compared to the original DSF. “bit-rot” only occurs in the second scenario, which is why the gateway does NOT use this.

Is there a change log somewhere? Can’t tell from Mantis what’s in & what’s out.

Hi,

I’m sorry, but I still don’t get it. What did I miss here:
1. DSF is not an exchange format.
2. WED’s DSF import and export features are inappropriate for a work-flow that involves repeated (or indefinite repeated) import/export cycles.
3. The gateway is -not- based on DSF exchange.

Therefore:
– it is critical that we provide BOTH sides of direct data exchange with the gateway (without .dsf files) to make gateway _editing_ safe.
– this is what we are doing in 1.4.

Are you just saying that we really need to ship 1.4 with direct gateway import to call the gateway “complete”? Or are you suggesting that WED really needs a DSF-based exchange work-flow?

So my word picking was not the best, I should have written that the feature is bogus in away since, and I quote:

— Start Quote —-
small rounding errors (“bit rot”) will creep into our 3-d, and features that were perfectly aligned might not be well aligned after 4 or 5 edits.
— End Quote —-

As much as I love WED, this limitation needs to be considered before multi exporting and importing scenery.

Suggested workaround:
Can it be that when we want to export a custom scenery, WED will pick the original DSF and then “add” the 3D objects to it, from the WED definition file, that way WED file will hold the modified locations of 3D objects in space and the DSF will be built a new every time and not on the previous customized DSF (if possible)

No.

will it be possible to use WED in ‘full 3d’ mode just as we use the Overlay Editor with having 3d/perspective view of the 3d objects we place?