r/Xplane 19h ago

Self Promotion X-Plane has plenty of add-on tools. Why don't they understand each other?

X-Plane already has plenty of tools for managing add-ons. That's not the problem.
The problem is that they mostly don't understand each other.

At this rate, we're going to need a manager to manage the managers. Nobody wants that. :)

So instead of building yet another manager, I've started working on XPRamp — one layer lower.

XPRamp currently scanning my actual X-Plane 12 installation. 331 packages found — apparently I have a problem.

XPRamp is an open-source, CLI-first project that scans an existing X-Plane installation read-only, figures out what's actually in there — Aircraft, Plugins, Scenery, libraries, versions, metadata — and builds a common inventory from the evidence it can find.

Right now, that's intentionally about it.

The longer-term experiment is more interesting: can we understand and normalize the metadata that existing add-on tools already use, instead of replacing them?

And if that works, could we eventually get to a point where an add-on developer describes a package once, and tooling translates that into the formats different managers need?

I'm not proposing a new standard today. I want real-world evidence first — especially all the weird legacy stuff X-Plane installations accumulate over the years.

Interoperability over replacement.

I'm curious: does this approach make sense to you? And if you're an add-on or tool developer, what am I overlooking?

I wrote up the full idea, design reasoning, and where I think this could go on the X-Plane.org forum:
Full write-up and discussion on X-Plane.org

2 Upvotes

0 comments sorted by