Hi,

I’d like to explain a problem I’ve been struggling with for several days regarding Aerosoft LEMD Madrid and the Ortho4XP patch, in the hope of either getting a practical solution or at least some guidance from Aerosoft.

My setup

·       X‑Plane 12 on a MacBook Pro with Apple Silicon.

·       Map Enhancement (XPME) for streamed orthophotos.

·       SimHeaven X‑World overlays.

·       Aerosoft LEMD Madrid X‑Plane 12 scenery:

o   Aerosoft - LEMD Madrid - 1 - Airport

o   Aerosoft - LEMD Madrid - 2 - Mesh

What works / what doesn’t

1.      If I use Aerosoft’s mesh (entry “2 – Mesh”), the airport looks good but the mesh/orthos for the wider Madrid region are effectively overridden. I lose my Map Enhancement Pro and/or SpainUHD scenery around the airport and the surrounding area looks wrong or flattened.

2.      If I disable Aerosoft’s mesh and keep:

o   XPME Europe overlays above,

o   SimHeaven overlays above those,

o   Aerosoft LEMD “1 – Airport” at the top,

3.      then:

o   The terrain and imagery around Madrid look good (XPME + SimHeaven work together).

o   But some terminals at LEMD (notably T1 and T4) have wrong elevation relative to the mesh: apron areas have bumps/steps, and parts of the terminals don’t sit perfectly on the ground. T4S looks fine, but T1/T4 are clearly misaligned.

My understanding is that this terminal elevation mismatch is exactly what the Ortho4XP patch is supposed to solve: it adjusts the airport mesh so the buildings sit correctly on a custom tile, instead of requiring Aerosoft’s own mesh to dominate the entire area.

The problem with the Ortho4XP patch

The documentation for Aerosoft LEMD provides an Ortho4XP patch and a TIF DEM, and explains how to:

·       Put the patch in Patches/+40-010/+40-004/.

·       Set the TIF as custom_dem.

·       Build tile +40‑004 with Ortho4XP.

·       Use the resulting zOrtho4XP_+40-004 tile under the airport.

In theory this is a good solution. In practice, on my Apple Silicon Mac, I have not been able to get Ortho4XP into a reliably working state for this tile:

·       My existing Ortho4XP install repeatedly fails with:

o   DEM not being created (tile.dem is None) and crashes like AttributeError: 'NoneType' object has no attribute 'alt_vec'.

o   OSM “server busy / rejected” issues when trying to build vector data for the tile.

·       Attempts to reinstall Ortho4XP and set up a new Python environment hit limits because:

o   I’m on a pre‑release macOS version, where package managers and GDAL/Proj setups are less stable.

o   Versioned Homebrew packages like python@3.10 are not available on my machine.

·       I’m not comfortable doing deep manual debugging or custom Python builds just to get one tile working; I’m a simmer, not a developer.

So I’m stuck in a situation where:

·       The patch depends on a tool (Ortho4XP) that I cannot realistically get working on my current Apple Silicon/macOS setup.

·       The patch itself doesn’t include a ready-made tile or mesh; it only modifies a tile I’d have to generate with Ortho4XP.

·       The product is advertised as premium scenery, but the recommended solution for users with Ortho4XP/Map Enhancement/SpainUHD relies on technical steps that are well beyond what many non‑technical users can reasonably do—especially on Apple Silicon.

What I’ve tried and confirmed

·       I have XPME working correctly as a fallback:

o   XPME overlays and SimHeaven above.

o   Aerosoft LEMD airport on top.

·       With Aerosoft mesh disabled:

o   Madrid region looks good.

o   Only the terminal elevations (T1/T4) are wrong.

·       I’ve tried multiple imagery sources (BI, ARC, GO2) and different thread settings in Ortho4XP; the DEM/alt_vec crash persists even before imagery becomes a factor.

·       I’ve spent hours following various Ortho4XP guides; none have led to a working tile for +40‑004 on this machine.

What I’m asking from Aerosoft

1.      Is there any possibility that Aerosoft could provide:

o   A pre‑built, Ortho4XP‑compatible tile for +40‑004 with the patch already applied (or at least a ready mesh/DSF) for LEMD?

o   Or an alternative patch / mesh package that:

§  Fixes T1/T4 elevations,

§  Does not flatten or override the whole Madrid region,

§  Does not require users to successfully run Ortho4XP?

2.      If not, would Aerosoft consider:

o   Updating the documentation to make clearer that the patch assumes a fully working Ortho4XP environment on the user’s system (which many Apple Silicon users do not have).

o   Providing guidance or minimum system requirements for the patch (e.g. “tested on Windows only”, or “Ortho4XP recommended but not supported on macOS Apple Silicon”).

3.      As a last resort, given the hours I’ve spent trying to make the patch work and the technical barriers on my platform, is there any possibility of:

o   An alternative solution (e.g. a small adjustment to the Aerosoft mesh so it coexists better with third‑party meshes), or

o   A refund or store credit, if the advertised compatibility with Ortho4XP‑style setups isn’t practically achievable on my system?

I’m not asking Aerosoft to support Ortho4XP itself—that’s a third‑party tool—but the current situation is that the LEMD patch is effectively unusable for me, and the supplied mesh either breaks the surrounding scenery or requires me to give up Map Enhancement and SpainUHD.

Any suggestions, clarifications, or alternative files from Aerosoft would be very much appreciated. I’d like to keep using LEMD Madrid with my usual orthophoto (Map Enhancement Pro) and mesh setup without having to be a Python/Ortho4XP expert.

Thank you for your time and for any help you can offer.

J.

Ok. I made some progress. I was able to build the +40-004 Madrid tile with Ortho4XP. The provided patch was in theory in the patches folder of the Ortho4XP app. The Ortho4XP log says that it patched several airports and helipads in the area. However, I still get floating buildings and some partially below ground terminals. As if the patch was not applied, or is not in the correct place. On the scenery_packs.ini, as suggested by AI, because I dont know anything about this, the LEMD airport mesh is at the bottom and disabled, is this correct? In the end, where should the patch be, which is the correct order? Any help would be greatly appreciated.

I thank you in advance for your trouble. J.

Back here again,

Setup

• X‑Plane 12 on macOS

• Ortho4XP 1.40.

• Tile: +40-004 (Madrid area – LEMD is inside that tile).

• Patch: Patches/+40-004/LEMD.patch.osm.

• Custom DEM: Elevation_data/+40-004/+40-004.tif.

• OSM data is in OSM_data/+40-010/+40-004/...osm.bz2 (airports, roads, coastline, water).

Ortho4XP finds and uses all of this correctly: the log shows the airports, roads, water, and “Loading altitudes from DEM file,” then builds the mesh and masks without errors.

What works

• Step 1 (vector data) completes normally.

• Step 2 (mesh) completes; Data+40-004.mesh is created.

• Step 2.5 (masks) completes.

• Step 3 downloads and converts all orthophotos, and reports:

  • *Download of textures completed.

  • *DDS conversion of textures completed.

  • *Encoding of the DSF file (with final node counts).

So Ortho4XP is clearly doing the full build.

What doesn’t work

At the very end of Step 3, every run ends with:

text

*Activating DSF file. ERROR : could not rename DSF file, tile is not actived.

After that:

• In the resulting zOrtho4XP_+40-004 folder, I see all the Data/mesh/terrain/textures files.

• But under Earth nav data/ there is no +40-004 folder and no +40-004.dsf.

• Sometimes there is an empty +40-010 folder, but no DSF inside.

Because the DSF never gets written/renamed into Earth nav data/+40-004/+40-004.dsf, X‑Plane 12 never loads the tile: even with all other sceneries disabled and zOrtho4XP_+40-004 alone in scenery_packs.ini, I still see default XP12 autogen, not photo ground.

What I’ve already tried

• Deleting the zOrtho4XP_+40-004 folder and erasing cached data (OSM, masks, JPEGs, whole tile) in Ortho4XP, then rebuilding.

• Changing the Base Folder (including building into a temporary Custom Scenery folder on the internal drive, then copying the tile).

• Verifying that paths for custom_dem and custom_overlay_src are correct and writable.

• Ensuring no old copies of the tile are still referenced in scenery_packs.ini.

In all cases, the build ends with the same message:

text

*Activating DSF file. ERROR : could not rename DSF file, tile is not actived.

and no DSF appears under Earth nav data.

---

Questions

1. Has anyone seen this specific “could not rename DSF file, tile is not actived” behaviour with Ortho4XP 1.40 on macOS, and found a practical fix?

2. Is there anything in the official LEMD patch workflow (or XP12 vs XP11 differences) that could influence where/how the DSF is written?

3. Would you recommend a particular Ortho4XP build or version for XP12 + LEMD to avoid this DSF activation issue?

I’m comfortable reinstalling Ortho4XP if needed; I mainly want to check whether this is a known quirk with the current 1.40 build, or if I’ve overlooked something obvious in the directory structure or patch setup.

Thanks in advance for any pointers—happy to share more log snippets or screenshots if that helps.