Recent Posts

Pages: [1] 2 3 ... 10
1
I spent time updating the OP2MissionSDK and Level Template on GitHub. These are the traditional C++ libraries for creating a mission. Of note, there is a newer C++ API known as TethysAPI that may be used in lieu of OP2MissionSDK or complement it. TethysAPI may be found here: https://github.com/OutpostUniverse/TethysAPI

The OP2MissionSDK may be found here: https://github.com/OutpostUniverse/OP2MissionSDK
The Level Template may be found here: https://github.com/OutpostUniverse/LevelTemplate

If you are new to making missions, Sirbomber has an excellent tutorial series that may be found in the forums.

I bumped the version to 5.0.0 with the below changes. The biggest reason for this release was to make everything work 'out of the box' with a stock Visual Studio 2026 install. Some other minor changes are included.

There are other ways to create custom missions for Outpost 2, but I think this SDK remains the most flexible, but with the downside of requiring learning C++ if you are not already familiar with the language.

Also, I added a reference in the readme to TethysAPI in case someone wants to check it out, but stopped short of adding it as a Git submodule.



Version 5.0.0
Version 5.0.0 updates OP2MissionSDK to default to Visual Studio 2026 and its toolset (v145). A new feature in HFL and some minor documentation corrections are included. Automated server builds were updated to use GitHub actions instead of appveyor. A breaking change occurred in OP2Helper correcting the name of an enum ID.

Outpost2DLL
  • Update to Visual Studio 2026 build tools (v145)
  • Automated build switched from appveyor to GitHub actions
  • Minor updates to source code documentation

OP2Helper
  • Update to Visual Studio 2026 build tools (v145)
  • Automated build switched from appveyor to GitHub actions
  • Correct EnumTechID enum identifier spelling of defensive (Breaking Change to API)
  • Correct common metals evacuation victory message text
  • Create helper functions to ease creation of map beacons (common ore, rare ore, fumaroles, and magma vents)
  • Minor updates to source code documentation

HFL
  • Add DoCargoRoute routine
  • Update to Visual Studio 2026 build tools (v145)
  • Minor updates to source code documentation
2
Hello everyone. I recently updated Yukon Trail to be 5 player. It can be found here: https://github.com/Brett208/OP2MissionYukonTrail/releases/tag/Ver1.1.0

We had a 5th player join our games recently, so wanted the ability to play this mission with them. In the 5 player variant, some additional mining beacons are added to form another viable base for the 5th player. The difficulty and objectives scale linearly up with the added player. A few minor bugs were corrected as well.

We tend to have the new players use high resources, the veterans use low, and the casual players use medium. This makes the mission scale pretty well and remain challenging for each player. If one of the players gets wiped out early, it can become brutal trying to win since the AI doesn't let up for the lost player.

Anyhow, readme is below and feedback is welcome.



Version 1.1.0
A 5 player cooperative, land rush, resource race. Requires Outpost 2 to play. Difficulty scales, so it should play well with 2, 3, 4, or 5 players.

Winning conditions:

  • Stage 20,000 * player count common metal in trucks at northern waypoint
  • Stage 10,000 * player count rare metal in trucks at northern waypoint

Change Log

Version 1.1.0

  • feat: Support a 5th player
  • feat: prevent AI from researching tiger speed modification (better chance of outrunning AI if game is close)
  • fix: prevent AI tech branching from inadvertently closing some tech options
  • fix: correct vortex endpoints (was setting incorrect y position)
  • fix: prevent 3 bar rare from sometimes being too close to a cliff to build a mine

Difficulty:
The mission is designed for play with morale unsteady and no initial tanks. If normal is too difficult, try adding initial tanks and maybe steady morale.

  • Normal: High Resources
  • Hard: Medium Resources
  • Difficult: Low Resources

To Install
Unzip contents and place in directory Outpost 2/OPU/maps/Yukon Trail. The PDB file is only used in debugging and does not need to be included unless debugging the mission.

Features:

  • Semi-randomized enemy tech tree research
  • Randomized enemy squad objectives and start locations
  • Enemy EMP missiles when they reach it in their tech tree research
  • Smart disaster mode where colony killing disasters will not occur around your main base and no disasters will occur until your base is established
  • Semi-Randomized ore locations
3
Forgive me for being skeptical. Speaking of LLM 'agents' as if they're people, thinking, reasoning or being able to 'come to a conclusion' is off-putting to a whole new level of ick for me. I'm not one to immediately dismiss something because LLM's are involved but, as Blackbox has stated, I'm seeing a lot of copy/paste directly from LLM output and it's... yeah, ick factor really is the best way to describe it.   :-\

EDIT:
So I realize where the ick is coming from. This thread is reminding me a great deal of this one: https://forum.outpost2.net/index.php/topic,5020.0.html. Specifically the second line of this message: https://forum.outpost2.net/index.php/topic,5020.msg76495.html#msg76495

Not saying this is a case of more of the same but, yeah, there's a reason I'm skeptical. -_-
4
OutpostHD / Re: Introducing myself.
« Last post by leeor_net on September 14, 2026, 10:48:06 AM »
Hello and welcome!

Thanks for your interest! As a note, I really hate generative AI and refuse to allow it to touch any of the code and for sure will not allow any art assets (including sounds/music) into the project.

That stated, I've looked around on OpenGameArt.com for awhile and have some tracks other than Mars that I want to include in the game (the planet select screen is an example). I haven't added them yet as it's been a low priority and I wanted to avoid increasing the download size until it's closer to ready for real play time.

For the AI voices, I was planning on hiring local students to record voice lines for the AI using a recording studio available at the local community liberal arts college. It's a moderate fee, something I can afford but I don't have the script yet since the game isn't really finished. When I have a good idea of what lines the AI voices should be saying I'll be having real people voicing the AI lines. Side note -- in the beginning of the project circa 2016 I had some computer generated ai voices and they really sucked so I removed them because they weren't helpful and the rate of change was so high that I opted to wait until I had a better idea of what was actually needed for voice lines. :D
5
OutpostHD / Introducing myself.
« Last post by larrydgraysdz on September 14, 2026, 01:13:34 AM »
I'm a developer that has been working with coding since mid 1980's. I have both Outpost and Outpost II on DVD somewhere in storage. I spent many hours late 90's and early 2000 playing these.  I found this turn based game and installed it. I like it and want to help out. So, I know C, I know Java extremely well and I know Claude Code fairly well. I think I can help. I love the turn-based genre games too. I've cloned the code, compiled it and run it. I have started a fork repo at github.com/larrydgray

My first thought when playing it was, "sound!"

Sourcing space-ambient music without licensing headaches

OpenGameArt.org ? filter by "Ambient"/"Space", most tracks are CC0 or CC-BY, made specifically for games like this.
Kevin MacLeod (incompetech.com) ? huge catalog, CC-BY (just needs attribution in your credits, which this repo already has a spot for).
Sonniss GDC bundles (sonniss.com/gameaudiogdc) ? free, no-attribution-needed SFX/music packs released for GDC each year, heavily used in indie/fan games.
freesound.org ? best for one-shot SFX (mining, construction, alerts) rather than full ambient tracks; check each file's specific CC license (varies per upload).

I am thinking Mars maybe fading in and out. Maybe timed with certain events or just randomly sometimes. But adding a few others that theme well.

And definitely female AI voice. Kokoro-82M is what Claude recommended. Why it fits best here: both the engine and all 54 voice presets are Apache-2.0 licensed ? one license covers everything, so there's no per-voice license auditing needed before you commit generated files into a BSD-3 repo. It's tiny (82M params, runs fine on CPU, no GPU needed) and currently rates highest quality (MOS 4.2) among lightweight local TTS models, with several American/British female presets (af_heart, af_bella, bf_emma, etc.) that would suit a game advisor/CMO voice.

And some beginning prioritized UI sound effects and event sound effects.

Let me know your thoughts. thanks.


6
Hey all -

So as I started out with the LLM-decompile idea, I thought it would give me a better starting point. But at some point while working with the agents we came to the conclusion that the gain we could get from that path would be marginal - and that is after an optimistic estimate. So I figured we better start the reconstruct now. For after all that is the main goal, right? To reconstruct it - to get back that lost code. At least that was the dream I set out to accomplish.

Small side note - I did not forget the decompile LLM. I still plan to investigate that branch. The idea of a decompilation engine for old games still sounds very exciting to me. But I need to think about it more. We are not only talking about pretty C or C++ out of a decompiler; we are talking about decompiling whole proper game systems. That is different stuff. I even thought maybe diffusion models somehow - but those are just thoughts in the wind, you know.

So we had this decompile stack: the Ghidra pseudo-code, the asm, and of course the community notes and the Olly and all. And I have to say I am very thankful and grateful for the work you guys did. It is short of a miracle to have such a map, and it is a clear sign of love and devotion. As they say - I stand on the shoulders of giants.

So we (and by we I mean me and my agents) took this decomp stack from the original PE and started to refine it function by function, cross-referencing it with the community knowledge. We called it "hanged code" (don't ask why). And once we hanged all the known addresses from the PE and the DLL, we started to rewrite.

The idea is that the hanged code is this huge blob of reworked pseudo-code. It is much closer to source, but it is still a heap of just functions - it is no game by any means. So the idea is to chunk it up with some sort of heuristic of which game system it is, and module by module rewrite it proper.

In order to actually know that the rewrite adheres to the original, we introduced the idea of streams. A stream is like a value over time - like a movie or video stream - where we record the commands given to the original Outpost PE, and we record the memory values over game ticks. We then use that as a baseline and compare it with the stream from the reconstruct. If they match, we can say with some amount of certainty that the reconstructed module is like the original - at least in a behaviour sense.

We also developed a harness for both the original and reconstruct: boot it up, issue commands, create units as needed - integration tests like in any other game.

In the beginning we wrote just simple "unit test" like scenarios: create unit -> order it -> see it arrives, or do whatever it was ordered. But as we recreate more and more modules, the plan is to create longer and more sophisticated test scenarios and run them through (at x40 speed or even more).

For now the repo is a mess, and there is a lot of old code from the dataset creation and LLM training tests and the QEMU Win2k box I used to cross-compile. So I would like to streamline it first - keep only the reconstruct and the harness stuff around it.

Once I do that and finish at least a first pass, I plan to open it to the public. You would still need your own vols / original assets to play; I am not shipping those. Off-day project, so figure a couple more weeks.

Questions welcome.
7
Outpost 2 Programming & Development / Re: Mine Yield Formula
« Last post by TechCor on August 17, 2026, 06:00:59 PM »
I should have shown the updated formula.

If rare is common divided by 2, then the first block could look like this:

Code: [Select]
InitialYield = InitialYield% * 10
PeakYield = PeakYield% * 10
MinYield = MinYield% * 10

This eliminates the ?MaxYield? constants. You just divide by 2 at some point if type is rare.

The notable part is that you have to multiple by 10 or the output numbers are too small. The MINES.TXT is out of 100, not 1000. You didn?t say where that 10x multiplier is coming from. That multiplier could happen later. That would make sense since it would be fewer operations.

From my original post, skip the first block and use the mines.txt values directly in the second block.
Then, replace the third block with:

Code: [Select]
Yield = Yield + Yield * Bonus% / 100
Yield *= 10
if (type == MineType.Rare) Yield /= 2

I haven?t verified truncation is not a problem with it at the end like this.
8
If you make the repo public, and give credit where it's due, we'd probably be willing to share more information with you! :)
9
Hey all - still here. Sorry for the quiet stretch.

@Arklon I spent years making mobile games, in big studios and small ones, including some back-office work. Then I moved into DevOps. These days I build AI platforms for gaming companies. It is basically those two jobs in one.

@BlackBox the thread title is misleading. I know Outpost can run on a Mac, and I am glad that works for people. That was never the point. For years I have wanted to take this game apart and turn the executable back into something like source. It stayed a fantasy. The new AI tools made it feel like I could finally try.

So that is the project. I wanted a machine I could feed Outpost2.exe, plus whatever we already know about it, and see how much readable code comes back out.

To train and test that machine I needed a fair test. There is no original Outpost 2 source, so I could not grade against the real game. I took other old C code from the same era (Quake 2, QuakeWorld, Enemy Nations, and a few Outpost mission SDK sources we already had), compiled it with the same kind of old Microsoft compiler, ran it through Ghidra, and compared the decompiled C to the source I started with. If a model can turn that Ghidra mess back into the original function, maybe it can help on Outpost later.

The compiler had to be the real old one: Visual C++ 4.2. I first tried Windows NT. That guest was too old. Telnet barely answered, I could not get a stable connection, and I could not copy files with robocopy. I looked for the newest Windows that still ran this compiler and was actually usable. That was Windows 2000.

I tried SSH into the guest. That SSH is from when the protocol was still young, and it was too buggy to trust. I did not want to write my own file-copy tool, so I did it the boring way: a shared folder (Samba), robocopy to move the work, and telnet to kick the compile. I wrapped the whole thing so I can talk to a compiler box and a decompiler box as one lab. Docker Compose runs those boxes plus a small workshop screen, and Metaflow lines up the jobs. I used to build toolchains in containers at work, so this part was a lot of fun. Opening those Win2k windows again, icons and sounds included, was unexpectedly emotional. A lot of teenage memories. I even put a VNC window on the virtual machine so I could sit inside it. Far too slow to play the game. Fast enough to compile, which is all I needed.

I ran a few models on a sample of those test functions: Ghidra by itself, Gemini, Qwen, and LLM4Decompile. I was not trying to publish a leaderboard. I just wanted to know if the idea pointed anywhere.

I had really hoped LLM4Decompile would be the one. I even thought about teaching it this compiler with a small extra training pass. That was a bust. The model is from 2024, so less surprising in hindsight. I have not given up on training something later. It is just too much time and effort right now. Gemini is much faster, so that is what I am using.

Right now I am doing a first pass with no extra training. Gemini gets the community notes, the Ghidra output, and I compile whatever it writes, just to see how far that gets on its own. I have started doing that on the real Outpost2.exe as well: take a function, write C++ that matches the names the community already has, and see if a modern compiler will accept it. That is not the game coming back. It is a baseline. Can an agent infer anything sane from what we already have, and does it even compile.

Later I still want a better model (I am looking at Qwen 3.5 9B, or a larger one if I can get a larger GPU), more training data, and a richer pack for each function: the Ghidra C, the assembly, the Olly notes, the call graph, the types, and which compiler built it. That comes after I know what this Gemini pass is actually worth.

Big thanks to Leviathan. He shared his knowledge base with me, and I am building the recompilation work on top of that.

I am not doing this alone. A bunch of agents do most of the work. I steer them.

The repo is still private.

Cheers
Jonathan
10
Awesome, thanks that worked. And it is probably a better solution than what I had been trying.

~Brett
Pages: [1] 2 3 ... 10