Thanks for posting the build!

If you want a 32bit version of WED, you can download a build I did.
Just navigate to this link and pick the relevant download.

Good Luck

First, thanks for the confirmation that the source actually builds. 🙂 Generally, I’m happy to take patches (or GIT pull requests) from Linux users who have fixed distro/compiler/whatever related problems but I don’t have the time/resources/expertise to go after those things myself. I do my best to not screw up the kinds of cross-platform fixes people send in.

Re: MeshTool, there is a definite cutoff: MT 2.x will build v9 meshes (which work in v10) and a 3.x stream will build v10 meshes. There is one more patch coming to MT 2.x: RealScenery got me a repro case on a bug I had heard about before (smeared edge textures) and I now have a fix; I’m hoping to get a build of that cut this weekend. (The patch is available in source in the meshtool_200_release branch.)

I don’t know what the timeframe is on MT 3.x for v10 support, but it’s definitely a different major version. MT exposes the DSF-generating GIS algos we use to make the global scenery, and that stuff got heavily worked over for v10.

A Linux user who doesn’t compile from source … Does this mean Linux is now main stream? I didn’t think I would ever live to see the day. (wipes away tears from the eyes)

Anyways all kidding aside, the current source compiles and runs nicely on 32bit Linux (built it on a small atom processor). Just one question, will MeshTool also receive a similar treatment? As I recall the height map in DSF v10 is not stored as a vector but as a raster. Or will the cutoff for V9 mesh generation be the current MeshTool?

I did not promise you a 32-bit build in that comment.

To follow up on the inquiry: I cannot build a 32-bit WED. I do not know if a 32-bit WED can be built for Linux by those with 32-bit distributions. You can download the latest source and try to compile it. I do not have time to work on a port back to 32-bits for WED for Linux.

Yes you understand well (my en is awful) I mean lastest beta. There you promised 32bit version – http:/2012/05/wed-1-2-beta-1-is-here/#comment-5046 . I wait about 1 year for beta2 but still nothing (I have used some older beta).

Wait, do you mean: “when will there be a 32-bit release of WED for Linux?” Is this a serious question??

In the long term that’s what we’ll do for sure.

In the short term it’s a question of the cost of doing multiple releases with multiple betas vs. having ‘optional’ functionality.

I must admit, I need to look over the feature spec more carefully — I thought (from a while back) that there are features in 1.2 that are highly desirable for X-Plane 9 that warranted a cross-sim build.

Edit: actually, I think we need an ‘export target’ no matter what. For example, the set of features you can use and still submit an airport to Robin is much lower than what you can do in custom scenery – we won’t accept custom objects in an airport submission, or third party library parts. So if nothing else, we need the idea of ‘export target’ to do DB submissions.

Add to that that scenery system feautures are sometimes added in point releases, and we’re likely to have multiple v10 export targets, e.g. 10.20, 10.30. At that point, we might as well make v9 an export target and go home happy.

The author can basically answer one question that he or she should really know the answer to: what is the oldest version of x-plane I expect my users to use/want to support.

I believe this idiom can work because it is already used for software and OSes – when you build an app, you pick the OLDEST OS you want to support, and the programming tools yell at you if you use a feature that demands the new OS.

Probably just working on a parallel release of XXX-Plane 😀