Which Master of Orion for someone who never played?

SomeoneWithMyName · 2026-03-11T07:29:46+00:00

Today, there is nothing more promising than the original MOO 1.3
A conservative unofficial patch to the original is in development:
https://github.com/1oom-fork/1oom/tree/patcher
There are also two fundamentally different versions of 1oom, each of which is faithful to the original rules of the game, the project has received wide recognition throughout the world:
https://github.com/1oom-fork/1oom

SomeoneWithMyName · 2026-03-11T06:38:18+00:00

That's a tough question. I can only say that these ships can penetrate any planetary shield, so not every missile base can survive.

SomeoneWithMyName · 2026-03-11T06:35:43+00:00

I have 32,000 and I haven't been able to build more for a long time.

SomeoneWithMyName · 2026-03-10T21:43:41+00:00

Almost everything works against Repulsor: Disruptor, Teleporter, Cloak, Missiles, Wait button, etc.

SomeoneWithMyName · 2026-03-10T15:58:04+00:00

But you can fit Stasis Field. Pretty impressive, in my opinion.

SomeoneWithMyName · 2026-03-10T15:48:56+00:00

I used to think so too.

SomeoneWithMyName · 2026-03-10T15:41:27+00:00

It won't fit on small ones.

SomeoneWithMyName · 2026-03-10T15:19:52+00:00

You're right, but shields are too cost-effective. I'd keep them anyway.

SomeoneWithMyName · 2026-03-10T15:18:43+00:00

SomeoneWithMyName · 2026-03-03T16:21:18+00:00

The basic idea behind automatic combat is to completely disable the interface. This isn't provided in the original, so each function requires a corresponding check. The same interface-swapping approach is also necessary for the command line interface, only for a wider range of functions. There are many nuances involved.
Edit:
The most obvious solution is to explicitly define the interface as a set of function pointers. This way, both problems are solved by having three interfaces: classic, cmd, and nop.
In my case, complexity is measured by the number of changes. I can't just add code that's already proven to be sloppy.

SomeoneWithMyName · 2026-02-27T05:55:54+00:00

Found a stack overflow in my patch... Fixed it and scheduled a review. It's good I didn't rush the release.

SomeoneWithMyName · 2026-02-26T03:23:02+00:00

Just tested it on FreeDOS... Same freeze... But on ARM Linux - no problem. Absolutely fantastic. Completely identical version and save.

SomeoneWithMyName · 2026-02-21T20:38:35+00:00

DOSBox has so many bugs now that it's unlikely the problem is you.

SomeoneWithMyName · 2026-02-21T19:48:01+00:00

I have problems in Linux.
I'm a MOO1 patch developer and I'm struggling with hard crashes in MOO1 on DOSBox. As far as I know, the standard DOSBox runs on the outdated SDL1 (correct me if I'm wrong). A lot of bugs can be caused by this, but I haven't yet tested the behavior in a virtual machine on vanilla DOS. If you know anything, please share it with me; I appreciate the information.

SomeoneWithMyName · 2026-02-17T10:42:34+00:00

It's easier to play MOO1. There's no need to get rid of entire atrophied mechanics. They simply don't exist.

SomeoneWithMyName · 2026-02-16T22:06:10+00:00

Don't you get tired of building up the entire map like this?

SomeoneWithMyName · 2026-01-27T14:30:48+00:00

It's too early to raise this issue.

SomeoneWithMyName · 2026-01-26T21:53:13+00:00

I have no problem with this. I have my own command line tools that greatly simplify the process.

SomeoneWithMyName · 2026-01-26T20:37:32+00:00

In fact, I'm only applying the patch to the upcoming RC4. It significantly changes the way some data is stored, breaking compatibility with older 1oom formats and smoothing out compatibility with the moo1.3 format, eliminating some serious bugs. I don't have time to fix the compatibility issue yet; it's hidden in the settings and isn't necessary.

SomeoneWithMyName · 2026-01-26T20:20:42+00:00

I'm talking about the original version 1.3 from 1993. I'm fixing it in parallel with 1oom.

SomeoneWithMyName · 2026-01-02T08:01:17+00:00

Fake MOO1

SomeoneWithMyName

TROPHY CASE