We have just released hotfix (1.50.3.1) that fixes cur_ptr crashes related to strict_combat_sequencing (1.50.3 bug).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!
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.
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.
- Outpost ship conflicts colonization bug fixed.
Yes it is indeed!So I guess this is a possible place to report bugs?
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.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.
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' ...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.
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.
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...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.
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.
Thus, enabling this in SP games gives an unfair start for a player. But hey, not all games need to be 'fair' ...![]()
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.
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![]()
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.A somewhat strange rule. Mexican standoff with civilian ships?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
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.
![]()
Hah, okNo, 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...
If only you'd know who often i have been doing game restarts...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.Oh, well...
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).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).
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!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...![]()
We haven't looked at AUTOBUILD yet...
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..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.
Yes, ofc.ANTARAN_FLEET_RATES Attack_Frequency_Determinant = 10; may have had something to do with that...
Good suggestions.
Not sure we will ever get around to improve such stuff though..