Post reply

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

shortcuts: hit alt+s to submit/post or alt+p to preview

Please read the rules before you post!


Topic Summary

Posted by: Unclemestor
« on: July 01, 2025, 11:36:28 AM »

v2.5.1 Issue:  Combat drop medals ID 34, 36 Auto Assignment not working
Assumption: 5 combat drop medals 35, 37 also not working [More difficult to test I think]

Prerequisites:
[not required, but shows nothing user related should be impacting this test]
Create brand new aurora folder
Extract Aurora1130Full into folder
Extract Aurora250 into aurora folder, overwriting db and exe
Extract Aurora251 into aurora folder, overwriting exe
Default game loaded by ... default

Steps to reproduce:
Enable SM mode

Open up Commanders, enable Automated Assignments

System Generation and Display -> Select Mars -> Modify Body to habitable
(ex: .1 oxygen, .35 aestusium, 0 co2)

Still in System Generation and Display -> Create Race on Mars, leave left all settings as defaults

Save example game
Exit Aurora
Re-start Aurora

[You could create the New Race GU here, but I did it later.  Swap back to the Terran Federation "main" species here]
Turn back on SM Mode

Time skip 5 days (Maybe not be necessary, but I don't know if this is required to ensure the new species is working)

Open up Alien intelligence, set as hostile

Instant research Ground Combat - Troop Transport Drop Bay - Standard
Instant research power & propulsion -
 - Pressurized Water reactor
 - Pebble Bed Reactor
 - Gaseous Fission Reactor
 - Nuclear Thermal Engine
 - Nuclear Pulse Engine
 - Nuclear Gas Core Engine (Could go fewer techs but up to you)
Instant research Construction/Production - Shipbuilding rate fully
Instant research Energy Weapons
 - Visible Light
 - Near Ultraviolet
 - Ultraviolet
 - Far Ultraviolet These EW techs aren't necessary, and they are the wrong ones to increase Racial Weapon Strength anyway!

Create Project for Engine - Nuclear Gas Core EP125 (50% power, 25HS)
Instant the Project so it is available immediately

Go to Ground Forces -> Unit Class Design
instant design Unit Class VEH - CAPx2
instant design LVH HQ10, noncombat
[Note, any unit should do, but I'm trying to make something "real"]

Create formation template: 236x VEH - CAPx2, 1x LVH 10k HQ
Change created Formation Template Rank to lowest possible (Major, assuming default game)
Put the ~10k template in an Organization, and instant org 10 on Earth

Class Design - Create Drop Ship design
2 Troop Transport Drop Bays - VL
some number of engines to move it

Medal Management - Create medals for automated assignment for
-Participate in Combat Drop - Formation
-Participate in Combat Drop - Transport

Economics -> Shipyard ->
Use free retool biggest commercial shipyard (Santone Dockyard if on default game)
Build 2 of the new ship designs, pass time until Mid Feb

After ships built:
Validate commanders are assigned to ground units and ships, assign manually if not.

Switch to the New Species
Instant Create Unit Class Design PWL Infantry to get shot
Instant Create Unit Class LVH HQ10, noncombat (because even sacrificial lambs deserve a HQ)
Create Formation of 3312x PWL Infantry, 1x HQ
Put the ~10k template in an Organization, and instant org 5 on Mars
Switch back to the Terran Federation Race

Open Naval Organization, select fleet with Dropships
Create colony on Mars
Select earth, load up all 10 Formations
Select Mars, Orbital Drop all ground units

Advance time until drop and invasion is complete.

tldr; steps for repro
Create medals for Orbital Drop, create race in-system, give them some GU, Orbital Drop invade them

Expected Result:
Medals for Orbital Drop - Formation and Orbital Drop - Transport are awarded appropriately

Actual Result:
No Medals for Orbital Drop - Formation and Orbital Drop - Transport are awarded for naval commanders or ground commanders.

Even doubling the invasion forces to clear the surrender requirements doesn't result in anything.
Posted by: skoormit
« on: June 29, 2025, 04:53:00 PM »

This one is a doo-hoo-hoozy.

TL;DR: In extreme cases, fleets that want to launch AMMs but have no more in stock will spam enough game log messages to crash the game.

Details:

On two separate occasions, I launched about 34 salvos of 5 missiles each, targeting a waypoint at a planet with a hostile fleet.
These salvos were launched 5 minutes apart.
Both times, in a short time after the first salvos arrived on target, the game crashed with an out-of-memory error.

I have been attacking this fleet periodically for many, many years.
The fleet used to fire a large number (many thousands) of AMMs at my incoming missiles.
But eventually they ran out of AMMs to launch.
Now, for every increment while a salvo of mine is visible to them, this fleet is generating thousands of game log entries of the form:
Quote
Ship so-and-so cannot lauch [SIC] a such-and-such as no missiles of the required type are available in the ship's magazines.

This most recent time, I saved the game immediately prior to the first salvo arriving on target.
In the last increment of that save, the hostile fleet generated 16,324 such entries.
In that save, FCT_GameLog contains 1,272,442 records.
Of those, 1,268,840 are these "cannot lauch" entries.

Side discussion:
You might wonder why am I launching this way.
I have eliminated the fleet's PD capabilities and I have soaked all of their AMMs.
The missiles I am launching now have the Retargeting capability, an onboard sensor, and are very slow.
Each increment, some small percentage of the remaining missiles will hit whatever ship is the current target.
If those hits are enough to kill the target, the remaining missiles pick another target.
Rinse, repeat. In theory, a large salvo of these will just keep attacking until the entire fleet is gone.
In practice, there's one problem: sometimes the hits in a given increment do not kill the target, but instead destroy all of the engines and/or missile jammers.
As a result, the remaining missiles now have a 100% chance to hit, and so, in the following increment, they all hit.
End of entire salvo.
To mitigate these overkill losses, I launch very small salvos, spaced many minutes apart.
Each salvo should get all of its hits in before the next salvo arrives.
So my maximum losses from any given overkill event is (usually) a single salvo.

The upshot of this is that, after each salvo arrives, the game runs 5-second increments until all missiles in that salvo have hit.
This takes 10, 20, sometimes 30 increments for a salvo.
And because the hostile fleet is trying to launch AMMs every single increment, and is logging a message for every single missile that they are unable to launch an AMM for, well, we get this super bloated game log that crashes the game.

How to fix?
Might be easy...maybe instead of writing the event each time a ship wants to launch missiles but is out of them, you only write it the first time. This means keeping up with which fleets have written such a message this increment.
Or maybe each fleet gets a counter that is reset to 0 at the start of each increment, and you increase it by one instead of writing this message.
Then at the end of the increment you write one such message per ship with a non-zero counter, and append "x[N]" to the message, where N is the value of the counter. Then reset the counters back to zero.



Posted by: Unclemestor
« on: June 28, 2025, 04:36:37 PM »

v2.5.1 Issue: Ground Commander Occupation Bonus is applied twice
Expected Result: Commander Occupation Bonus is applied once

Prerequisites:
[not required, but shows nothing user related should be impacting this test]
Create brand new aurora folder
Extract Aurora1130Full into folder
Extract Aurora250 into aurora folder, overwriting db and exe
Extract Aurora251 into aurora folder, overwriting exe
Default game loaded by ... default

Steps to reproduce:
Enable SM mode
instant design Unit Class PWL Infantry
instant design LVH HQ10, noncombat
[Note, any unit should do, but I'm trying to make something "real"]

Create formation template: 3312x PWL Infantry, 1x LVH 10k HQ
Put the ~10k template in an Organization, and instant org it on Earth

Expected Police Strength (No commander) using the formula (SQRT(Size) * Units * Morale) / 10000:
Units | Morale | Size | Unmodifed Police
3312100357.37
1100620.08
Actual police strength 57 == success


Now, Assign any commander with OCC bonus to the unit
Example: 30% OCC Bonus commander [COL Lorenzo Verma]

Expected Modified Police Strength (30% OCC Commander) using the formula ((SQRT(Size) * Units * Morale) / 10000) * (1 + OCC)
[Note: this is an assumption of how the formula should work but I didn't actually see it explicitly stated that this is how the Ground Commander Occupy stat is applied.]
Units | Morale | Size | Unmodifed Police | OCC Bonus | OCC Modified Police
3312100357.3730%74.58
1100620.0830%0.10
Actual police strength is shown as 97 == fail

But if you take the expected result, and multiply it by 1.3 again, you get 97.084.

Assigning different OCC strength commanders displays consistent results to indicate that the OCC bonus is applied multiplicatively twice, so instead of [Base Police Strength] * (1+ [OCC]), it appears to be [Base Police Strength] * (1+[OCC]) * (1+[OCC]).
Posted by: GrandNord
« on: June 26, 2025, 04:01:18 PM »

Wow, thank you very much for this workaround. That definitely changes things. I'll try this for the next version of my long range torpedo.
Posted by: skoormit
« on: June 26, 2025, 11:21:48 AM »

Quote from: Ghostly on June 26, 2025, 09:11:34 AM
In regards to waypoint-fired missiles, the only way (that I'm aware of after extensive testing) to make them work is to calculate an intercept manually, place a waypoint there and fire the missiles at it, then use the currently broken Move Waypoint command to reposition the waypoint after the missiles approach whatever you want to hit close enough for their on-board sensors to detect it, but before they reach the waypoint itself. Doing so makes the missiles lose the waypoint as a target and target enemy ship contacts instead.

You can do this without resorting to moving waypoints.
You just need to add an engineless stage in the middle of your missile.

From back to front:
Stage 1: Just an engine and fuel and one (or more) of Stage 2, with a release range of zero.
Stage 2: No engine. Has an active sensor. Carries 1 or more of Stage 3, with a release range less than sensor range and less than the stage3 missile's fuel range. You want your release range to be well within both of those ranges (sensor and stage3 fuel) if you might be attacking ships that are running away.
Stage 3: Carries the warhead. Ideally moves fast, does lots of damage, etc. Does not need a sensor, but you might want one (see below).

Calculate and fire upon your intercept waypoint as usual.
When stage1 reaches the waypoint, it releases stage2.
Stage2 inherits the same waypoint as its target, and since it is already there and it has no engine, it immediately becomes a mine.
If you calculated your waypoint position accurately, the mine will immediately (in the same increment) detect the bad guys and release stage 3 upon them.

If your stage 3 does not have a sensor, then all of them released at the same time will target the same ship.
If stage 3 does have a sensor (and can detect the hostile ships), you may qualify for random targeting. Other conditions apply.
Posted by: Ghostly
« on: June 26, 2025, 09:11:34 AM »

Quote from: GrandNord on June 26, 2025, 07:55:11 AM
What I tried to do is put down a waypoint and then fire the missiles at the waypoint (I tried keeping or deleting the waypoint afterward but it didn't change the result).

What I think should have happened is that, when the enemy ship entered the sparation range (I can confirm it was both in sensor and separation range), the second stage should have separated and attacked the target ship but instead it just continued on toward the original waypoint (even when it was removed), then the second stage separated at 2mkm from the waypoint and attacked it. I tried with the enemy ship both in range and out of range of the séparation range and sensor from the waypoint.

In regards to waypoint-fired missiles, the only way (that I'm aware of after extensive testing) to make them work is to calculate an intercept manually, place a waypoint there and fire the missiles at it, then use the currently broken Move Waypoint command to reposition the waypoint after the missiles approach whatever you want to hit close enough for their on-board sensors to detect it, but before they reach the waypoint itself. Doing so makes the missiles lose the waypoint as a target and target enemy ship contacts instead. Also, missiles will acquire new targets with their sensors when their old ones are destroyed without the need for a Retargeting module. It looks like so:

https://imgur.com/gallery/aurora-4x-waypoint-fired-missiles-ejezAyC
https://imgur.com/gallery/aurora-4x-waypoint-fired-missiles-against-many-targets-3iE5LMK

I would also love to get clarification from Steve on this, as this tactic is fairly janky to execute and Waypoint movement is getting fixed in 2.6.0, which might make missile retargeting impossible. That would be a shame, but on the other hand, this is a very powerful tactic that the AI can neither use nor really retaliate against. But on the other hand, are such missiles all that different from missile fighters? I guess having the AI send scouts in the direction a missile (or a fighter) came from c could be a start.

Quote from: GrandNord on June 26, 2025, 07:55:11 AM
At another point, when testing mines I had the following problem: an enemy ship came into sensor range but did not come into séparation range and from that point on the mine stage perpetually locked on the ship (even when putside sensor range or destroyed) and did not aquire any other target. So it became unusable.

If the enemy ship entered séparation range then the mines worked properly (even if the stack of mines all targeted the same ship).

What I think is happening is that the missile (or mine) is aquiring the first available target possible (the initial target waypoint or the first détecter enemy ship) and this target seems to be inherited by the second stage in the case of the missile. From this point on, they will keep the target and will never aquire another one and never wipe the old target, even if it is destroyed or removed.

Mines do indeed stay locked onto the first contact they encounter, even if it never comes within separation range. I'm pretty sure destroying the original target does clear their contact lock and allows them to seek new targets, deleting your race's contact for that ship in the DB should also work. Deleting the ship in the Intelligence window in-game, regrettably, does nothing, as the lost contact for the ship still exists. Also hoping for this to get fixed.
Posted by: GrandNord
« on: June 26, 2025, 07:55:11 AM »

I did a quick check but I'm not sure if this has been mentionned or not for 2.5.1 yet. It's concerning two-stage missiles (both mines and two stage missiles with engines).

I've been trying stealth ships again to harass a nearby NPR and I've been confronted to a problem: my two-stage missiles don't work properly if I don't send them with an active sensor lock at the time of the launch.

The missiles I launched were a size 20 missile (total size) with a size 12 second stage. Launched at 50mkm, both stages with 3mkm range, résolution 100 active sensors and the second stage with 2.5mkm range and 2mkm séparation range.

What I tried to do is put down a waypoint and then fire the missiles at the waypoint (I tried keeping or deleting the waypoint afterward but it didn't change the result).

What I think should have happened is that, when the enemy ship entered the sparation range (I can confirm it was both in sensor and separation range), the second stage should have separated and attacked the target ship but instead it just continued on toward the original waypoint (even when it was removed), then the second stage separated at 2mkm from the waypoint and attacked it. I tried with the enemy ship both in range and out of range of the séparation range and sensor from the waypoint.

At another point, when testing mines I had the following problem: an enemy ship came into sensor range but did not come into séparation range and from that point on the mine stage perpetually locked on the ship (even when putside sensor range or destroyed) and did not aquire any other target. So it became unusable.

If the enemy ship entered séparation range then the mines worked properly (even if the stack of mines all targeted the same ship).

What I think is happening is that the missile (or mine) is aquiring the first available target possible (the initial target waypoint or the first détecter enemy ship) and this target seems to be inherited by the second stage in the case of the missile. From this point on, they will keep the target and will never aquire another one and never wipe the old target, even if it is destroyed or removed.

I couldn't do anything about the mine but for the missile my "fix" is to send a sensor probe to get active lock of the enemy ship before launching the missile.

I don't know if the same problem is présent for missiles with thermal sensors, I will try to test it.
Posted by: nuclearslurpee
« on: June 20, 2025, 07:34:37 AM »

Quote from: gingerbread on June 20, 2025, 04:39:05 AM
Playing with the Limited Research Admin box unchecked.

The set up is OK, all scientists have research & research admin in multiples of 5, % for research and no. facilities for RA.

Promotion does increase research by 5%, but RA increase can be as low as +1 facility -  is it possible that the code intended for limited box checked is also used, unintentionally, when the box is unchecked, for RA?

This is normal and happened even before limited admin was a thing.
Posted by: gingerbread
« on: June 20, 2025, 04:39:05 AM »

Playing with the Limited Research Admin box unchecked.

The set up is OK, all scientists have research & research admin in multiples of 5, % for research and no. facilities for RA.

Promotion does increase research by 5%, but RA increase can be as low as +1 facility -  is it possible that the code intended for limited box checked is also used, unintentionally, when the box is unchecked, for RA?

SJW: Working as intended. Under limited admin, increase is +1 or +2.
Posted by: smoelf
« on: June 07, 2025, 10:13:58 AM »

I recently had a successful espionage event, telling me that two human factions were allied, although they are most definitely set mutually to neutral. Is the espionage-event possibly set to register diplomatic rating instead of treaty level?

Pics attached.
Posted by: Aloriel
« on: June 04, 2025, 01:14:39 PM »

Just had an issue where neutrals were attacked by my minefield (probably starting the Earth-Minbari War).

The situation was this:
A Minbari Survey Ship jumped into Sol through a gate that I had mined (stats for mines below). 4 hours later, which was probably the minimum increment due to me hitting 5 days, my mines went off and hit the survey ship. The Minbari were marked as neutral, and continue to be marked as such.

Since they're marked neutral, I shouldn't be able to fire at them at all. Normal weapons can't be fired at them. Auto-targeting missiles apparently can target neutrals.

Mine outer body (some stats are slightly different due to upgraded tech):
Code: [Select]
Missile Size: 16.64 MSP  (41.600 Tons)     Warhead: 0    Radiation Damage: 0
Speed: 0 km/s     Fuel: 500     1st Stage Flight Time: 1 seconds    1st Stage Range: 0k km
2nd Stage Flight Time: 13 minutes    2nd Stage Range: 7.65m km
Active Sensor Strength: 0.8   EM Sensitivity Modifier: 8
Resolution: 100    Maximum Range vs 5000 ton object (or larger): 6,624,929 km
Cost Per Missile: 7.33     Development Cost: 428
Second Stage: Mk I Mine Warhead x1
Second Stage Separation Range: 4,000,000 km
Chance to Hit: 1k km/s 0%   3k km/s 0%   5k km/s 0%   10k km/s 0%

Materials Required
Tritanium  1.5
Boronide  2.655
Uridium  1.3
Gallicite  1.875
Fuel:  500
Warhead (some stats are slightly different due to upgraded tech):
Code: [Select]
Missile Size: 14.84 MSP  (37.100 Tons)     Warhead: 12    Radiation Damage: 12
Speed: 20,216 km/s     Fuel: 500     Flight Time: 14 minutes     Range: 16.57m km
Active Sensor Strength: 0.8   EM Sensitivity Modifier: 8
Resolution: 100    Maximum Range vs 5000 ton object (or larger): 6,624,929 km
Cost Per Missile: 11.78     Development Cost: 542
Chance to Hit: 1k km/s 202.2%   3k km/s 67.4%   5k km/s 40.4%   10k km/s 20.2%

Materials Required
Tritanium  3
Boronide  4.23
Uridium  0.8
Gallicite  3.75
Fuel:  500
Also, I noticed that even though I zero out fuel on the buoy, it still adds 500 fuel to the device.
Posted by: Louella
« on: May 30, 2025, 12:26:39 PM »

Quote from: Steve Walmsley on May 27, 2025, 04:17:51 PM
Quote from: Louella on May 27, 2025, 02:42:43 PM
In the course of the multifactional war, Earth got hit by missiles several times, and a lot of installations were destroyed, and several populations on Earth and in Sol changed hands, some several times. There were several battles between CMC garrisons as well. Some of the NPRs have been effectively defeated, with no remaining populated colonies, or ordnance.

Sounds like a fun game though!

Yeah ! It is the continuation of the "War of the Worlds" setup that I have been playing. It was all going rather well, until several Earth powers established large populations outside of Sol, and someone refused to recognise someone else's claim on a system. With a complex system of alliances between the different powers, it ended up with at least 3 different mutually-hostile factions at the height of the conflict, which lasted about 6 months, and pushed Earth to the edge of requiring infrastructure to cope with the radioactive fallout.

I'm not sure if e.g. the USA bombarding Brazil from space, putting radioactive dust into the atmosphere of Earth was the cause of France starting a war on the USA, or if there was also a dispute over sovereignty in Luhman 16, but it probably didn't help matters.
Posted by: skoormit
« on: May 28, 2025, 12:33:18 PM »

Mass Driver not respecting reserve levels for mined minerals.

I have a CMC colony from which I am purchasing minerals.
I changed the mineral reserve levels on this colony to non-zero for three minerals.
Two of those minerals (DUR and MER) are being mined on the body.
The other mineral (BOR) is not.

I manually added 100t of BOR via SM-mode.

I expected the stockpile levels of DUR and MER to increase as time passes and mining progresses, until the stockpile levels reach the reserve levels, at which point excess amount would be sent away via the mass driver.

Instead, the stockpile levels of DUR and MER remain at zero, and the mined amount is apparently sent away with the outbound mass driver packets.

(The stockpile level of BOR remains at 100, as expected.)


Image attached.
Posted by: Steve Walmsley
« on: May 27, 2025, 04:17:51 PM »

Quote from: Louella on May 27, 2025, 02:42:43 PM
Quote from: Steve Walmsley on May 27, 2025, 02:47:25 AM
103 is AI checking fuel, 111 is AI checking for damage, 117 is AI ground force training.
They all run during every construction phase, and sometimes more often, so it must be a very rare bug.
What did you do with SM mode?

Well, the only things I can remember doing with SM mode before all this stuff started happening, was that I adjusted the orbits and environments of some planets in systems where I discovered a couple of new alien races, so that the planets would be suitable for them to colonise. Also used SM mode while designing a few ship classes that I transferred to some of the NPRs, to intervene in their wars.

In the course of the multifactional war, Earth got hit by missiles several times, and a lot of installations were destroyed, and several populations on Earth and in Sol changed hands, some several times. There were several battles between CMC garrisons as well. Some of the NPRs have been effectively defeated, with no remaining populated colonies, or ordnance.

It's probably the transferred ships. NPRs ships are created using the automated design code, which makes sure they are setup in a way the NPRs can handle. If you design a ship and transfer it, the AI will make an attempt to classify it and use it in that role, but it isn't guaranteed. It's best not to transfer ships to an AI race unless they are relatively simple.

Sounds like a fun game though!
Posted by: Louella
« on: May 27, 2025, 02:42:43 PM »

Quote from: Steve Walmsley on May 27, 2025, 02:47:25 AM
103 is AI checking fuel, 111 is AI checking for damage, 117 is AI ground force training.
They all run during every construction phase, and sometimes more often, so it must be a very rare bug.
What did you do with SM mode?

Well, the only things I can remember doing with SM mode before all this stuff started happening, was that I adjusted the orbits and environments of some planets in systems where I discovered a couple of new alien races, so that the planets would be suitable for them to colonise. Also used SM mode while designing a few ship classes that I transferred to some of the NPRs, to intervene in their wars.

In the course of the multifactional war, Earth got hit by missiles several times, and a lot of installations were destroyed, and several populations on Earth and in Sol changed hands, some several times. There were several battles between CMC garrisons as well. Some of the NPRs have been effectively defeated, with no remaining populated colonies, or ordnance.