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: icekiss
« on: Yesterday at 06:34:42 AM »

Error popup, often several times at once, occurs every few 5-day increments.  It was originally #2661, now #2662.

2. 5. 1 Function #2662: Could not load file or assembly 'System. Data. Entity. Design, Version=4. 0. 0. 0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.

Started happening after, I *think*, making several ground forces with "Construct Org".

No mods, running 2. 5. 1 in aurora4x-docker.

I am getting the same error (#2661 and #2662, same PublicKeyToken). Happens sporadically, then multiple times. I have not constructed any ground forces yet, nor done anything else obvious to trigger it. My assumption: An NPR wants to access records that do not exist (Although I have not left SOL yet. I am playing with default settings - do NPRs get generated before leaving SOL?).

I am launching with AuroraPatch.exe, using DeepBlueTheme, no mods otherwise.
Game is running on Linux, via Steam/Proton.
Posted by: skoormit
« on: Yesterday at 04:24:12 AM »

In the FCT_Fleet table, the AssignedPopulationID and OrbitBodyID columns will acquire the corresponding ids of the last executed movement order, even if that order used a distance offset.

In my game, I gave a fleet an order to move within 1mkm of one of my colonies.
The fleet completed that order, and received no further orders.
I later noticed that these two columns were populated with the corresponding IDs.
(The fleet has never actually been in orbit of this population/body.)

I then gave the fleet a move order to a JP, and removed the order after a 5-sec increment.
This caused those columns to both reset to 0.

I'm not sure if these two columns are ever used by the game, but I rely on those columns for various database queries to determine which fleets are where.
Posted by: Froggiest1982
« on: July 15, 2025, 07:10:29 PM »

I guess since we just talked about it here: https://aurora2.pentarch.org/index.php?topic=11545.msg173967#msg173967
I may highlight this bug as it may have slipped through the cracks.

In short, you cannot load Decoys into magazines from ship design window and need a workaround to load the template.

Once the template is on, everything works fine so the issue must be at a magazine level.

It may be entirely possible this was fixed during any of the playthrough that is leading to release.
Posted by: Unclemestor
« on: July 15, 2025, 10:57:34 AM »

I have been able to do this in the past without issues. Out of curiosity what is the reload time on your buoy launcher? If you use 30% size with a large buoy and low reload tech it might not finish reloading before reaching the POI.

This was a great suggestion and point, and an aspect I did not initially test.  I was originally using 30% launchers in my game.  So I created a scenario where I had both a "fast" launcher with a 45 sec reload, and a slow launcher, with a 3600 second reload

Both exhibited the same behavior, even when point to point transfer was hours > than the reload speed. 

Example test:  "Fast" [45 sec] reload buoy ship, Launch Ready Ordnance order at Sol Comet Wolf-Harrington [Current location] -> Temp Waypoint in between -> Enke - travel time required 11.3 hours total.  Waypoint is roughly halfway between.  Skip 1-day increment results in a 11:30 timeskip, Wolf-Harrington has a buoy, the temp waypoint is gone with no buoy, and the ship is awaiting new orders at a buoyless Enke.  Only the first buoy drops.

tldr; I can replicate this issue with a brand new aurora install, with a 45-sec reload launcher that should be ready during that time frame.
Posted by: nuclearslurpee
« on: July 14, 2025, 06:24:06 PM »

2.5.1 Issue - Launch Ready Ordnance order only happens once per increment

Expected result - Launch Ready Ordnance order takes effect as many times as was ordered and completed per increment

Impact:
With a suitably fast engine, and JPs close enough together, this issue causes me to have to babysit my buoy dropping ships to ensure I am skipping time slow enough for each buoy to drop successfully.

Steps to reproduce:
In Missile Designer, create an engineless buoy
Create a ship, engine, launcher, FC, and magazine capable of supporting & launching the buoy
Build the ship
Assign the launcher and buoy to the appropriate FC
Identify a system with points of interest close enough for your ship to reach them all within a 5 day increment -- or alternatively create waypoints close enough together to reach all within a 5 day increment
Set ship orders to Launch Ready Ordnance at all locations
Pass time for 5 days

Expected result
Buoy dropped at each POI reached during that increment

Actual Result
First buoy dropped, others skipped that were reached during that increment


Note:  Same issue occurs if using fleet order "Move to location" followed by "Launch Ready Ordnance", tested in case that was part of the problem.  The temp waypoints I used in my test all disappeared, so I feel somewhat confident in thinking that the destinations were actually reached by my ship, just nothing [other than the first buoy] was dropped.

I have been able to do this in the past without issues. Out of curiosity what is the reload time on your buoy launcher? If you use 30% size with a large buoy and low reload tech it might not finish reloading before reaching the POI.
Posted by: Unclemestor
« on: July 14, 2025, 01:14:12 PM »

2.5.1 Issue - Launch Ready Ordnance order only happens once per increment

Expected result - Launch Ready Ordnance order takes effect as many times as was ordered and completed per increment

Impact:
With a suitably fast engine, and JPs close enough together, this issue causes me to have to babysit my buoy dropping ships to ensure I am skipping time slow enough for each buoy to drop successfully.

Steps to reproduce:
In Missile Designer, create an engineless buoy
Create a ship, engine, launcher, FC, and magazine capable of supporting & launching the buoy
Build the ship
Assign the launcher and buoy to the appropriate FC
Identify a system with points of interest close enough for your ship to reach them all within a 5 day increment -- or alternatively create waypoints close enough together to reach all within a 5 day increment
Set ship orders to Launch Ready Ordnance at all locations
Pass time for 5 days

Expected result
Buoy dropped at each POI reached during that increment

Actual Result
First buoy dropped, others skipped that were reached during that increment


Note:  Same issue occurs if using fleet order "Move to location" followed by "Launch Ready Ordnance", tested in case that was part of the problem.  The temp waypoints I used in my test all disappeared, so I feel somewhat confident in thinking that the destinations were actually reached by my ship, just nothing [other than the first buoy] was dropped.
Posted by: nuclearslurpee
« on: July 12, 2025, 02:37:21 PM »

Engine Power per MSP appears cut off (concatenated/rounded down/floored) at 2 decimal places.

To check my own math:
Ion engines have 0.625 EP/MSP
Speed is Engine Size * Boost Multiplier * Engine Power per Hull Size / Total Size * 1000
1 HS = 20 MSP, .625 * 20 = 12.5. So if we have a size 1 engine and a size 12.5 missile everything should simplify down to 1 * 1 * (12.5/12.5) * 1000 = 1,000km/s

However as shown in the attached image the speed is calculated as if I had an EP/MSP of .62.

It is not the Engine Power per MSP that is truncated, but rather the total Engine Power of the engine which is truncated. This is visible in the screenshot as the listed Engine Power under the engine type is 0.62. You can observe this for many other combinations of engine tech and engine size, including tech levels with nice round-number values of the engine power tech.

This is a consequence of the use of C# Decimal types throughout the Aurora code. Many places in the game feature Weird Aurora Rounding™ (WAR) because of this.
Posted by: RocketPapaya
« on: July 12, 2025, 02:01:51 PM »

Engine Power per MSP appears cut off (concatenated/rounded down/floored) at 2 decimal places.

To check my own math:
Ion engines have 0.625 EP/MSP
Speed is Engine Size * Boost Multiplier * Engine Power per Hull Size / Total Size * 1000
1 HS = 20 MSP, .625 * 20 = 12.5. So if we have a size 1 engine and a size 12.5 missile everything should simplify down to 1 * 1 * (12.5/12.5) * 1000 = 1,000km/s

However as shown in the attached image the speed is calculated as if I had an EP/MSP of .62.
Posted by: Walter
« on: July 10, 2025, 03:00:26 PM »

Not really sure whether this is a bug or whether this works as intended:

When I acquire the 1000th research facility or more, I am greeted with the message:

"2.5.1 Function #616: Input string was not in a correct format."

when I try to click a researcher to assign them to a project.
I have to acknowledge that by clicking "Ok" and can then proceed as usual.

Once I scrap enough research facilities to go down to 999 the nagging stops.


Edit: On further tinkering it turns out hat his only happens when you have more than 999 research facilities on the same system body.


I did encounter this when SMing in facilities via "Edit installation", but it also happens when legitimately building the 1000th research facility (after SMing in 999 facilities... ahem).

Of course this is a real minor issue, I just thought I'd let you know.

My installation of 2.5.1 is completely Vanilla, I do run it on a Linux system via Wine, which itself runs via Lutris.
Posted by: Nostramo
« on: July 07, 2025, 03:24:27 AM »

In my game, there was a multifactional war between different NPRs that all had the same homeworld (Earth), and I got a couple of error popups, and was wondering what they mean, and if anything I did with SM mode made things worse, so that I would know not to do those things again.

For a while, I got errors for functions #103 and #111, but these went away eventually. These popped up at seemingly random times, whenever I pressed the buttons to advance time. I couldn't figure out a pattern to what was happening.

Lately, I have an error for function #117, which seems to occur at the end of each construction cycle.

iirc, they all just say the same error message: "Object reference not set to an instance of an object".

Hello, were you able to fix these errors? I have the same error for function #117  :(
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 »

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.