[MoO] Master of Orion 2 unofficial patch

solar_one; thanks for the report. the log error is a good pointer for us to investigate. if you happen to have a savegame of 1 or a few turns before crash, it would be welcome also.

vmxa; thanks for making the connection!
 
Nice mod and thanks, but here is a bug:

strict_combat_sequencing = 1;

If set to 1 during combat there is frequent bug. Not sure exactly how, but it might relate to having ground, base, and ship vs. enemy ships and how it takes turns. Here is the LOG error:

died: invalid cur_ptr 13

This causes a CTD. When I set to 0, it does not CTD.

Thanks!
We have just released hotfix (1.50.3.1) that fixes cur_ptr crashes related to strict_combat_sequencing (1.50.3 bug).
Lemme know if you encounter any more issues.
 
Somebody has left the following feedback on Steam:



Since we are not frequenting Steam (we don't have accounts there) I will reply here in the hopes that this reply will find its way to the poster on Steam:

When high armored ships get shot down & explode by missiles, even if these missiles are coming from seemingly under-powered foes, almost certainly this is caused by EMG missiles. Once missiles with the Emissions Guidance System penetrate shields, all damage is applied to a ships drive, ignoring all armor, causing the ship to explode (described as 'self-destruct' above). Needless to say, such missiles are very dangerous! So always scan your opponents ships to properly assess the threat. Also, putting batles involving EMG missiles on AUTO would indeed make the problem worse because AUTO would move your ships forward, assuming that your ships armor and structure can soak up the missiles damage, which will completely fail for EMG missiles.

Secondly, the rebalances to combat that we have done are all optional and part of the by default enabled 'SET150.CFG'. This means if a player does not like the changes for some reason, he can always return to a full classic combat style by disabling SET150.CFG in ORION2.CFG, or make custom adjustments by disabling specific items in SET150.CFG. All items and their effects in SET150.CFG have been described in detail in our manual.

Lastly, in case there are doubts still about this specific combat, or more in general if anyone experiences 'weird outcomes' of a battle or in any other areas of the game, we are always curious and would like to take a look at a save game.

Rocco.

Thank you very much for this information, I was a little un-nerved when it first happened as I have been playing this game since 94 and this is the first time I have had ships get one shotted by such a weak set of ships, it was pretty embarrassing.

I will take a look at the config files as you suggest.
 
Thank you for the link. I normally dont bother with initiative because it sounded confusing but your video is very clear. I think I will give it a go.
 
We have just released hotfix (1.50.3.1) that fixes cur_ptr crashes related to strict_combat_sequencing (1.50.3 bug).
Lemme know if you encounter any more issues.

Cool...forgot to mention that ship initiative was on when I got the bug. Sorry, no save game, but it happened exactly after the planet took its turn against the Antarans at the end of combat. Thanks for the fix!
 
(*) Everything is better with Outpost ships?

So I guess this is a possible place to report bugs?

- Outpost ship conflicts colonization bug fixed.

Still a bug; if an enemy Outpost ship is present in a system, colonization is not possible.

I've started several games with "starting_OP = 1;", only to figure out that the AI doesn't seem to know what to do with its Outpost ships. But whenever I tried to settle a planet in a system where an enemy Outpost ships was present, I didn't get the option to colonize, until the Outpost Ship was forced to leave by removing the enemy colonies.

I also got a nasty thing yesterday, but didn't bother to save the save. Will try to reproduce later:

When starting a new game, the sixth ship design slot contained an "Outpost ship" design. WTH? The design could be changed (I usually reset all slots to empty Doom Stars on new games), which in turn allowed for construction of a Doom Star in slot 6 from turn 1, without the appropriate tech.

In the same game, I got surprised by a very early GNN message that the Sakkra paid Orion a visit. That was way before the first Antaran attack, so turn < 100. It turned out that they were able to settle on Orion, but didn't got any Xeno techs, so I guess the Guardian didn't spawn on the map or was repulsed by the Sakkra's odor or something like that.
 
So I guess this is a possible place to report bugs?
Yes it is indeed!

Still a bug; if an enemy Outpost ship is present in a system, colonization is not possible. [...] But whenever I tried to settle a planet in a system where an enemy Outpost ships was present, I didn't get the option to colonize, until the Outpost Ship was forced to leave by removing the enemy colonies.
That's not a bug but an actual game rule; it would be unfair to let one party settle (by either outpost or colony ship) while the other one then does not get this opportunity.

I've started several games with "starting_OP = 1;", only to figure out that the AI doesn't seem to know what to do with its Outpost ships.
starting_OP = 1; is just a fun option that we have introduced and it can have its use in multiplayer games and certainly it has its use in the many testgames that we run, but indeed the AI has no clue what to do with OP's as there is no code written to help them out here. Thus, enabling this in SP games gives an unfair start for a player. But hey, not all games need to be 'fair' ... :satan:

I also got a nasty thing yesterday, but didn't bother to save the save. Will try to reproduce later:

When starting a new game, the sixth ship design slot contained an "Outpost ship" design. WTH? The design could be changed (I usually reset all slots to empty Doom Stars on new games), which in turn allowed for construction of a Doom Star in slot 6 from turn 1, without the appropriate tech.

I can only assume you have been playing this in version 1.50.2, because it should have been fixed since version 1.50.3. Lemme know if it's not so.

In the same game, I got surprised by a very early GNN message that the Sakkra paid Orion a visit. That was way before the first Antaran attack, so turn < 100. It turned out that they were able to settle on Orion, but didn't got any Xeno techs, so I guess the Guardian didn't spawn on the map or was repulsed by the Sakkra's odor or something like that.
This sounds weird, could be a problem; especially if you did not start on Advanced Tech start it sounds really to early. Savegame would have been really welcome here...

thanks for the feedback, new civ member ;)
 
Still a bug; if an enemy Outpost ship is present in a system, colonization is not possible. [...] But whenever I tried to settle a planet in a system where an enemy Outpost ships was present, I didn't get the option to colonize, until the Outpost Ship was forced to leave by removing the enemy colonies.

That's not a bug but an actual game rule; it would be unfair to let one party settle (by either outpost or colony ship) while the other one then does not get this opportunity.

A somewhat strange rule. Mexican standoff with civilian ships? :crazyeye: Perhaps a desireable behaviour for multiplayer, but kind of sucky for singleplayer. Caused me to raze an entire AI system only to get rid of that :satan: Outpost ship. A system that I only wanted to settle in the first place for trying to actually prevent genocide of one AI by another. Had to collect those 50 points of score a little bit sooner than planned. :nuke:

Anyways, I'm definitely back to "starting_OP = 0;"!

(And I really wished that for singleplayer, the human player always had initiative in a contested system with more than 2 parties present, especially if it's the last planet of an AI. It's annoying if another AI collects MY trophies!)

Thus, enabling this in SP games gives an unfair start for a player. But hey, not all games need to be 'fair' ... :satan:

Sure as hell not. With the option to freely change initial picks, one of my first endeavours was to try out UniSubLithTol. That was sick!

I can only assume you have been playing this in version 1.50.2, because it should have been fixed since version 1.50.3. Lemme know if it's not so.

No, it was indeed with 1.50.3.2. I had been playing an unhealthy amount of 1.40 games before, then boldly went forth directly to the current 1.50.3.2.

This sounds weird, could be a problem; especially if you did not start on Advanced Tech start it sounds really to early. Savegame would have been really welcome here...

I'm very sorry that I didn't keep the save. Maybe I was a little bit embarrassed for some of the names I had chosen for that game...

The game was Imp/Huge/Organic/8/Average/+Tactical/+Random/+Antarans, but I did change my custom game config several times thereafter.

I did more than a dozen new game starts today, trying to reproduce the bug and matching the original config, but failed to achieve a broken game. :scan: Oh, well...

Is it possible that a RNG might have been seeded with "foul" data from 1.40? That might explain why only my first few games were a bit weird. Seems like wild guessing, but I've noticed that some LBX files actually appear/disappear/change when starting new games or playing (SR_R#_SC.LBX, SR_R#_TR.LBX, SR_R#_SP.LBX, where I guess that # relates to race pic chosen).

thanks for the feedback, new civ member ;)

You're welcome. I'd wanted for several times already to thank you all for your great work, and also wanted to encourage you, Rocco, to do more LP stuff on Youtube, but I'm always very reluctant to join forums and the likes. But now that this obstacle has been taken... :cooool:
 
A somewhat strange rule. Mexican standoff with civilian ships? :crazyeye: Perhaps a desireable behaviour for multiplayer, but kind of sucky for singleplayer. Caused me to raze an entire AI system only to get rid of that :satan: Outpost ship. A system that I only wanted to settle in the first place for trying to actually prevent genocide of one AI by another. Had to collect those 50 points of score a little bit sooner than planned. :nuke:
also, moo2 is a turn based game and is set up in such a way that the game cannot know which player is colonizing a system, as its happening within the turn and not during turn processing, so it could lead to a conflict if both parties actually colonize the same system.

No, it was indeed with 1.50.3.2. I had been playing an unhealthy amount of 1.40 games before, then boldly went forth directly to the current 1.50.3.2. I'm very sorry that I didn't keep the save. Maybe I was a little bit embarrassed for some of the names I had chosen for that game...
Hah, ok :) perhaps next time choose somewhat more bland names in your game, so we will have to pleasure of using it for serious patch work. :p
Anyway, maybe we will find this obscure issue...

The game was Imp/Huge/Organic/8/Average/+Tactical/+Random/+Antarans, but I did change my custom game config several times thereafter. I did more than a dozen new game starts today, trying to reproduce the bug and matching the original config, but failed to achieve a broken game. :scan: Oh, well...
If only you'd know who often i have been doing game restarts... :crazyeye:

Is it possible that a RNG might have been seeded with "foul" data from 1.40? That might explain why only my first few games were a bit weird. Seems like wild guessing, but I've noticed that some LBX files actually appear/disappear/change when starting new games or playing (SR_R#_SC.LBX, SR_R#_TR.LBX, SR_R#_SP.LBX, where I guess that # relates to race pic chosen).
Dunno, only candidate seems to be the MOX file that keeps your personal settings, but it seems unlikely to me. The lbx files you mention are just picture files for the new tech screen for the 13 races (0-C), with 3 variants for scientists (SC), spies (SP) and troops (TR).

You're welcome. I'd wanted for several times already to thank you all for your great work, and also wanted to encourage you, Rocco, to do more LP stuff on Youtube, but I'm always very reluctant to join forums and the likes. But now that this obstacle has been taken... :cooool:
No thanks, we're a group of 3 enthusiasts & just enjoying to enhance the game. Always good to hear there are actually people playing it though!
And I am sure i will do some more moo2 vids in the future. :scan:

edit: with "No thanks" i meant no thanks needed
 
I'm unsure what the "No thanks" was addressed at; I didn't want to cause any misunderstandings, sorry.

Just rest assured that your patch work is highly appreciated, as are your MOO2 videos. :goodjob:

It just hit me that my user name "Tech_150" might be a bit ambiguous in a thread dealing with the 1.50 patch. After all those "good explosions" in your OC2 videos, I was going for "Quantum Detonator", but that seemed a bit unwieldy; hence the smartass abbreviation from the tech table. :crazyeye:
 
thought your user name is quite appropriate!

with 'no thanks' i just meant that thanks are not needed, but i guess my English fell short here to find the correct way of expressing it.

so thanks for saying thanks,,,
 
Is there a way to increase the likelihood of Antaran attacks? Not having them attack sooner, but simply more often, with a fleet composition that still fits the current game turn.

Depending on my played race, I love capturing Antaran ships. In some games, I started to collect them and pair them up with the Avenger at Orion, just to show off. :smug:

Simply decreasing the chance for Quantum Detonator explosions prevents the need for save scumming, but both things feel kind of lame. Compared to 1.40, where I often craved for the next Antaran incursion, already Antarans show up more often, but I'd like to have an option to increase it even further.

Another thing that I'd find very usefull on occasion would be an Auto-Build Blacklist; a list just like BUILD.CFG, but with items that never should be auto-built(*). If the purpose wasn't clear, I'd be happy to elaborate further.

(*) Exemplary Food Replicator rant. Having the maintenance reduced from 10 to 2 was overdue, if one relies on auto-building. I once got so annoyed by those mostly useless things, that I completely removed them from the tech tree. Which in turn left Transporters as a singleton, which in turn prompted me to move some item from the next tier one field down in the tech tree. You get the idea.
 
For the Antarans, use:
ANTARAN_FLEET_RATES Attack_Frequency_Determinant = 200;
The lower you set the number, the more frequent the attacks.

We haven't looked at AUTOBUILD yet...
 
I'll play around a bit with the various ANTARAN_FLEET_RATES items and see how I'll screw up...

We haven't looked at AUTOBUILD yet...

If you ever like to have a look at it, perhaps a combination of BUILD.CFG as source for preferred build order, and BLACKLST.CFG with a list of items that never should be auto-built?

Currently again experiencing the "fun" when conquerred Silicoids build all the food buildings on AUTOBUILD, because the player race isn't lithovore; although the AUTOBUILD-AI is smart enough to not build anti-pollution buildings for them.

If you look at how Gravity Generators are handled, I'm wondering why the devs didn't just do the same thing with the pollution items - only offer them in the list of buildable items if at least one pop guy may need it. I'd also be happy with a (hypothetical) restriction like "lithovores may (should) not farm", so that pure lithovore colonies may never build farming items. That way, one BUILD.CFG would be fitting for all kinds of different player races.

The icing on the cake would be a simple method (EDIT: or automatism) to scrap non-relevant buildings(*), like Gravity Generators after the original pop has been replaced, or Alien Management Centers after conquered pop has been assimilated.

I hope all of this doesn't sound demanding in any way; those are just thoughts that I have again and again when playing the game.

(*)EDIT: Which the game already knows how to do for Pollution Processors or Atmospheric Renewers when Core Waste Dumps are build, for example. You even get a refund...
 
Can't remember if I've seen something like this before:

orion2_000.png


ANTARAN_FLEET_RATES Attack_Frequency_Determinant = 10; may have had something to do with that...
 
Currently again experiencing the "fun" when conquerred Silicoids build all the food buildings on AUTOBUILD, because the player race isn't lithovore; although the AUTOBUILD-AI is smart enough to not build anti-pollution buildings for them.

If you look at how Gravity Generators are handled, I'm wondering why the devs didn't just do the same thing with the pollution items - only offer them in the list of buildable items if at least one pop guy may need it. I'd also be happy with a (hypothetical) restriction like "lithovores may (should) not farm", so that pure lithovore colonies may never build farming items. That way, one BUILD.CFG would be fitting for all kinds of different player races.
Good suggestions. Indeed some efficiencies can be won in buildings and colony management. Not sure we will ever get around to improve such stuff though..

Food is treated as a global item, while pollution is planet based. Autobuild builds a pollution processor if pollution exceeds 10, while for farming there are no local rules. Thus, the game also keeps putting Sili's on farming in mixed societies, when a new pop is created.

ANTARAN_FLEET_RATES Attack_Frequency_Determinant = 10; may have had something to do with that...
Yes, ofc. :) :borg:
 
Good suggestions.

Got another one! I think. The "XXX surrenders to the YYY" event can be a cause of shock for perhaps not millions, but pretty sure for me, and this one currently can't be circumvented by just disabling random events altogether.

If this one could get a config option, or be treated just like a regular random event so that it can be disabled -> :hatsoff: :goodjob:

The current workaround is to reload, and mess around with diplomacy, which most of the time, but not always, seems to re-seed the RNG. For repulsives, this can be done by clicking on "Declare war" and then chickening out.

Not sure we will ever get around to improve such stuff though..

Well, there's always hope, and that's what counts. :yup:

Re: ANTARAN_FLEET_RATES Attack_Frequency_Determinant

This was a bit weird for me. I consecutively lowered this from 200 in many iterations, starting at 100 if I remember correctly. I felt hardly a difference, and was about to give feedback accordingly. Then, in a game after I had lowered it down to 10, all of a sudden I did feel a difference... Which again nurtured my superstition of an externally stored seed for the (or a) RNG.

Sometimes it can become really crazy (see last screenshot), but then again there are still longer periods without any Antaran activity. It's just like they ran out of frigates at some point, and don't feel like sending in cruisers yet.

Balancing these things out if all of a sudden you're given the options to do so can be quite the challenge!
 
Another rant against AI surrendering. In a current game it just happend that the Klackon surrendered to the Sakkra. The Klackons had a score in the History graph that was around twice as much as that of the Sakkra. :crazyeye:

Only this time I'm actually somewhat happy with this turn of events; the Klackons were the only race that my spies had trouble with, and the Sakkra had no new techs for a while...
 
Back
Top Bottom