How does TethysAPI compare to Outpost2DLL/HFL/OP2Helper?

[Vagabond]

I saw the TethysAPI on GitHub recently (https://github.com/OutpostUniverse/TethysAPI) branded as a C++17 re-implementation of the APIs used to create custom missions for Outpost 2. It is currently on version 0.8.2.

How does it compare to using Outpost2DLL / HFL / OP2Helper for mission development? Does it contain all the features of these 3 libraries, or does it just reimplement Outpost2DLL?

And how feature complete is it compared to Outpost2DLL? Have most to all portions been ported or are there still missing chunks?

Are there plans to support C++20, or will it live on C++17 for technical reasons? (I was trying to use a C++ 20 feature recently in a mission and had trouble when enabling it using Outpost2DLL).

Thanks,
~Brett

[Arklon]

You're still alive?!

There's various debugging and reverse engineering efforts ongoing!

At the time we published TethysAPI originally, C++17 was the latest. We started to update it for C++20. C++26 Reflections will likely convince us to update it further, particularly for Python/Lua/C# language bindings.

Right now, we're mostly focused on debug tooling.

[Hooman]

Huh, I wasn't aware there was a C++20 issue with Outpost2DLL. Though it's been awhile since I've used it, and I don't think it's been updated in a long while.

I'm not so familiar with TethysAPI, so I can't really speak to that project.

[Vagabond]

Yeah, I haven't posted in a really long time and don't really drop in on Discord. I am still poking about and we still play about a half dozen times a year.

The area a couple of partially programmed missions that I may finish up at some point. Since they are partially done I'll probably stick with the older Outpost2DLL. Are you recommending new maps be developed using TethysAPI at this point?

~Brett

[Hooman]

I would still be using Outpost2DLL, but I have experience with that one, and I don't exactly have experience with TethysAPI.

I kind of had the sense for a long while that TethysAPI was still a work in progress. I'm not really sure how complete or usable it is. I'm guessing it's probably been usable since the code was released publicly. I'm not aware of any maps using it. Maybe someone can correct me on that.

Long term though, having a solution that doesn't require a compiler to build levels is kind of a must if we want the general population to be able to make new levels. It would be even better if the general population wasn't required to use a programming language, even a scripting one, for new levels.

[Sirbomber]

I've used TethysAPI for a few missions, there's a lot more you can do with it than you can with Outpost2DLL, even with HFL.  There are a few bugs that still need to be worked out, though, but it's largely stable.

[Leviathan]

Great to see you around!

Ive been doing some work on Outpost 2 development over the last year.

We now additionally have TitanAPI and OP2Lua for mission development.

TitanAPI - Clean, modern C++23, type-safe with crash diagnostics mission library.

OP2LuaSDK - Missions in Lua without a compiler, the entire mission is scriptable from a text file.

I've done a lot of work on both and consider them both stable and very usable.

[Arklon]

I would say the older OP2MissionSDK is the most stable option right now for mission development.

Everything else is pretty experimental, at least for developing missions anyway. For mods, TethysAPI is far more powerful than ForcedExports or HFL and is pretty stable for that use case - OPUPatch itself uses it. TethysAPI is able to be used alongside OP2MissionSDK in the same DLL, by design (to make it easier to gradually convert missions over from the old SDK).

[Sirbomber]

I've done a lot of work on both and consider them both stable and very usable.

Not to start something but it seems dishonest to say "you" have been doing a lot of work when TitanAPI was obviously made by taking TethysAPI (without giving any credit to Arklon or even acknowledging that you used it as a base) and feeding it through an LLM.
Regardless of its origins, I like the attempt to add more robust error handling so the game doesn't crash at the drop of a hat, but a quick glance through it reveals some glaring inaccuracies and usability issues that make it ill-suited for non-trivial mission development.