Recent Posts

1

Outpost 2 Programming & Development / Re: Want Outpost 2 on my Mac

« Last post by jonathangoorin on Today at 02:18:45 AM »

Hey neo_drol, that's really cool! Sounds like we're doing the same thing. Let's touch base and see where we can cooperate I'm on Discord as oxymoxy.

2

Outpost 2 Programming & Development / Re: Using C++20 for mission development

« Last post by Arklon on October 11, 2026, 11:26:21 PM »

Vagabond, I am happy you are still alive!

We ran into similar issues with PyOP2 while backporting it to WinXP. We were able to get C++20 to work, surprisingly.

Regarding /permissive- , in MSVC C++20 there were a couple major changes.

For OP2 missions, the most annoying thing was non const correctness in the OP2 SDK, like

Code: [Select]

class BuildingGroup { void Setup(LOCATION& mine, LOCATION& smelter, MAP_RECT& smelterArea) }

In a lot of mission code, people would write

Code: [Select]

Setup({32, 32}, {64, 64}, ...)

That's not allowed in nonpermissive mode anymore, since "mine"/"smelter"/etc are non-const reference params. Unfortunately due to export name mangling, you can't just change the SDK header defs to add "const" or else Windows import symbol names can break. That's partly why I started making TethysAPI.

There were also major changes to how the C preprocessor works in MSVC nonpermissive mode, but I don't think that affected OP2 missions much.

If you have build error logs, we'd be happy to look through them!

3

Outpost 2 Programming & Development / Using C++20 for mission development

« Last post by Vagabond on October 11, 2026, 06:13:54 PM »

I spent some time debugging why when setting Outpost2DLL to C++20, my missions were not compiling. In the process, I discovered the following.

In MSVC's flavor of C++, there is a compiler flag named permissive. By default, prior to MSVC's implementation of C++20, it was set to be 'more permissive' which allowed several non-standards compliant behavior to compile. In particular, it allows temporary binding to non-constant references being passed into functions (Which I do all the time since it is convenient when scripting even if not compliant C++).

I had known for a while that MSVC was more permissive than other compilers, which can be nice in reducing the barrier to learning the basics, but super annoying when it doesn't compile in other environments. I didn't realize it was controllable by a flag.

Since the permissive flag is set by default prior to MSVC C++20, you unset it by adding `/permissive-`. I was considering recommending generally setting it for our utility projects that get cross-compiled such as OP2Utility. However, since MSVC's version of C++20 doesn't set it by default, it will sort itself out naturally when projects are updated. Just be ready to correct some compiler errors when updating projects to C++20 that are not compiled using alternate compilers. OP2Utility is likely compliant, since it has a Linux automated build, it was just annoying to rework the code post push to GitHub.

I would like to update Outpost2DLL, OP2Helper, HFL, and the Level Template to all use by C++20 if there are no concerns from the community. The downside is if anyone with an existing mission updates to the latest copy post update, they may have to correct some compiler errors. They are not overly helpful to human reading, but an LLM/harness will understand what is going on quickly. The errors I encountered were fairly trivial to correct with low risk of adding a bug once I recognized what was going on.

Another option would be to set `/permissive` when updating to C++20 which would allow the non-standard behavior to persist. While missions are typically compiled for Windows, I would tend to prefer the 'pain' upfront to keep the C++ code written closer to universal.

A third option could be to just update to C++17 for now.

I'll wait a couple of days before changing anything to see if anyone has concerns/thoughts.

Also, in this post: https://forum.outpost2.net/index.php?topic=6456.msg89813, I mentioned Outpost2DLL was not compliant with C++20. This is wrong, I just assumed it wasn't compliant based on the stack of warnings that popped immediately when switching instead of digging into the details... apologies. Hooman even called me out, and I waited a month to investigate... 

4

Outpost 2 Programming & Development / Re: Want Outpost 2 on my Mac - learning the hard way with AI

« Last post by neo_drol on October 09, 2026, 07:27:49 AM »

Interesting thread. I've been working on something similar on the side for about two weeks, using AI usage I have left over after my job. The goal is a native Apple Silicon build of OP2 (no Wine, no emulation), rebuilt function by function from the retail EXE.

For testing, the original EXE and mission DLLs run in an emulator (Unicorn) on the Mac. Every rebuilt piece has to produce exactly the same memory state as the original code from the same starting point, first as single functions and now whole chunks of mission setup.

I'll share some progress when I have something that actually plays.

Big thanks for the TethysAPI headers and the years of forum posts. They're the starting point for almost all the names.

5

OutpostHD / Re: Introducing myself.

« Last post by Hooman on October 07, 2026, 06:48:21 AM »

Also, welcome to larrydgraysdz. Where are my manners.

Though I get the sense maybe we didn't do the best job of making this new person feel welcome.

6

OutpostHD / Re: Introducing myself.

« Last post by Arklon on October 07, 2026, 03:41:38 AM »

Welcome larrydgraysdz!

leeor, Hooman, maybe it is time to write some sort of AI coding expectations for contributors. It is difficult since the technology is new & changing so quickly. I would agree with understanding the code being submitted. I use AI frequently in my workflow now and would have used the tool for assisting in contributions to OPHD before reading this post.

If the stance is to refuse to allow AI to touch OPHD source code, that should probably be explicitly stated before anyone puts time into a PR to be rejected on developer principles instead of content...

Tough subject.

~Brett

You're still alive!

7

OutpostHD / Re: Introducing myself.

« Last post by Hooman on October 06, 2026, 06:58:54 AM »

I don't know that I would go so far as to say no AI code.

I think my concern is more about quality. If something is vibe coded, then presumably it's never even been looked at, so is highly likely to have quality issues. There's also the potential for AI slop, which maybe has been looked at, but no real effort was put into producing good code, merely code that seems to work.

AI tools enable low effort submissions. It then takes effort on our end to review those submissions. I want to avoid a scenario where we end up spending substantially more time reviewing code than the submitter spent producing it. If code is bad and needs to be rejected, it may end up being a net negative contribution since time spent reviewing it was not spent doing something else productive.

AI tools also enable submissions from people who maybe don't have the skills to review the code themselves, or assess it's quality. This might still have uses for prototyping a feature to help with design, though maybe the prototype code is throw away.

AI tools might also be used to do well understood changes in a more automated way. Maybe a refactor requires search and replace like edits with some slight adjustment that's not easy to express directly with search and replace. Such a use would be more like a refactoring tool built into some IDEs. I'm not concerned about someone having typed the changes themselves. I'm more concerned that they understand and have reviewed the changes.

I don't wish to discourage people from tinkering, or learning, or sharing prototype ideas. If AI tools help people with that, than have at it. It's more that if people are submitting something for direct inclusion, I would want them to understand it, and stand by it. In a way, I feel like code being submitted should be something they could have written themselves, possibly after doing some research.

That and I would like my time respected. I'm quite willing to spend time with people who want to learn, and have put in some effort themselves. I don't necessarily want to spend a lot of time on contributions that someone put little to no effort into, and has little interest in learning from or improving.

Anyway, I hope that clarifies my stance a little bit. Maybe Leeor has a different take.

I suspect Leeor might also be concerned about copyright issues, and AI tools being trained on and basically ripping off other people's work. That's something I would probably be more conscious of for game assets.

8

Outpost 2 Programming & Development / Re: Updating the OP2MissionSDK and LevelTemplate for VS2026

« Last post by Vagabond on October 05, 2026, 09:18:12 PM »

It wasn't much work, just updating libraries and toolsets.

Just realized I forgot to bump the solutions themselves to defaults to VS2026... Will push shortly.

9

OutpostHD / Re: Introducing myself.

« Last post by Vagabond on October 05, 2026, 09:13:04 PM »

Welcome larrydgraysdz!

leeor, Hooman, maybe it is time to write some sort of AI coding expectations for contributors. It is difficult since the technology is new & changing so quickly. I would agree with understanding the code being submitted. I use AI frequently in my workflow now and would have used the tool for assisting in contributions to OPHD before reading this post.

If the stance is to refuse to allow AI to touch OPHD source code, that should probably be explicitly stated before anyone puts time into a PR to be rejected on developer principles instead of content...

Tough subject.

~Brett

10

OutpostHD / Re: Introducing myself.

« Last post by Hooman on October 04, 2026, 05:28:30 AM »

Reading the first post I found myself thinking Leeor is not going to be a fan of AI generated content. Not too surprised by his response.

For code changes, I would be uncomfortable with vibe coded submission. I have a very strong preference for small change sets that are easy to understand and review. That tends to exclude a lot of vibe coded output. A lot of AI generated code can be overly verbose, sometimes unnecessarily complicated, and of highly variable quality. Combine that with how quickly AI tools can produce a large quantity of code, and it creates a situation where proper review can become very difficult. I'm generally of the opinion that code submissions should be well understood by the person submitting them, and should be readily understood by a reviewer. Mostly I want conditions where review is easy and quality can be maintained.

To be clear, my objection here isn't really about using AI tools for a research and learning phase, or a prototype phase. My concerns are more about quality and understandability when it comes time to present and review code.

There was someone who vibe coded some prototype UI upgrades. I would say that effort was appreciated. People did go over the visual changes to comment on them, and note which changes would be good improvements to make.

Those vibe coded UI upgrades were never formally submitted for inclusion. The person who made the UI changes left a link to his fork for anyone curious, though there was never a detailed review, nor was a PR opened for the changes. The focus was more on the general ideas for UI updates being presented, rather than on the code.

Given your stated background, I'm guessing you'd be more interested in code submissions. We do certainly like quality code submissions, and are generally happy to work with people that want to give it a try, or learn something new.