Okay, I'll bite assuming that the first post was actually written by a person, since the rest of this thread appears to be copy pasted from an LLM verbatim (at least no person I know actually writes that way)... and the github link doesn't actually work?
First of all I would point out that the most realistic way to run OP2 on a Mac is by using Wine, or running Windows in a virtual machine (the latter will have way better performance), assuming this isn't "just for fun" and you just want the game to work on a Mac.
Secondly I would also point out that many folks here (self included) are likely to be pretty skeptical of this approach actually working; there have been many attempts at remakes / sequels over the years here and none have really gotten anywhere. This is definitely not a beginner project and doesn't seem likely to be feasible without some degree of reverse engineering knowledge (or at least software dev experience).
That said, addressing a few other points made in the thread:
There isn't enough real Outpost 2 90s era source lying around to build a serious dataset.
There isn't
any actual OP2 source known to exist, everything that you find is going to be stuff that the community has created via RE over the years. The only exception here are the SIGS headers from the Homeworld 1 source, and parts of a couple of libraries that were also used in Tribes 1 (source for T1 is out there, but OP2's version of said libs is a little different).
So why not rebuild it (or chunks of it) using the same kind of tools and stack they would have used back then?
Not sure I understand this, unless you want to target MacOS classic (i.e. it'd run on 68k / PPC macs and absolutely nothing modern) - the OS environment and programming model is
very different from modern MacOS. Using awful-by-modern-standards tooling from 1996 doesn't seem to make a whole lot of sense unless the goal is to torture oneself, I guess? There are also a lot of strange limitations/unhandled edge cases and "interesting" design choices in OP2s engine that would make very little sense to preserve, some of which may have made sense given the hardware of the day and some of which was clearly half baked to rush the game out the door.
3G-2 - RTTI / vtables
- Done: PE-first RTTI parse (`recover_rtti.py`, `rtti_pe.py`), optional Ghidra apply, `rtti-classes.md` + JSON.
- Expected: 100-300 functions renamed from RTTI alone.
- Actual: Community Tethys VAs already named most stream/GFX vtable slots. RTTI confirms hierarchies and only 6** extra `FUN_*` renames on apply. OP2Shell / op2ext in the OPU tree: no MSVC RTTI anchor found.
This section seems a bit technobabbly to be honest... only a couple parts of the game were compiled with RTTI and there isn't anywhere near hundreds of RTTI descriptors.
Also, FWIW, op2ext is a community developed library that we have source for, so there isn't a whole lot of point in RE'ing it.
HFL-style DAT globals
Huh? HFL as in the community developed mission dev library?
Table: Subsystem heat (row counts, duplicates allowed)
Subsystem Rows
units 794
ui 392
save_load 391
scenario 327
...
There isn't particularly great separation of concerns in the compiled OP2 code. A lot of code is inlined all over the place and there's a lot of code that is difficult to bucket in this manner. The TethysAPI headers are probably the most recent/complete description we have. Not everything is documented yet in these headers though to be fair, we have documented a lot more in private IDA databases that we can't distribute for copyright/legal reasons.
I'm also not sure there would be much value in reverse engineering any of the stuff relating to VOLs, etc. All that has been long-ago reverse engineered and we have reimplementations of the libraries; further, the community update extracts all the files, so there isn't much point in working with VOLs anymore.
As I know I've said in other posts like this in the past, I will be pleasantly surprised if this works but I don't know that an LLM is a great substitute for being able to do a lot of the work yourself.
Recent Posts
