Author Topic: v2.5.1 Bugs Thread  (Read 154637 times)

0 Members and 25 Guests are viewing this topic.

Offline skoormit

  • Vice Admiral
  • **********
  • Posts: 1029
  • Thanked: 442 times
Re: v2.5.1 Bugs Thread
« Reply #450 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.
« Last Edit: June 27, 2025, 05:25:06 AM by skoormit »
 
The following users thanked this post: Laurence, Droll, BAGrimm, GrandNord, Ghostly, EclipsedStar

Offline GrandNord

  • Chief Petty Officer
  • ***
  • G
  • Posts: 36
  • Thanked: 24 times
Re: v2.5.1 Bugs Thread
« Reply #451 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.
 

Offline Unclemestor

  • Able Ordinary Rate
  • U
  • Posts: 1
  • Thanked: 1 times
Re: v2.5.1 Bugs Thread
« Reply #452 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]).
 
The following users thanked this post: skoormit

Offline skoormit

  • Vice Admiral
  • **********
  • Posts: 1029
  • Thanked: 442 times
Re: v2.5.1 Bugs Thread
« Reply #453 on: Yesterday at 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.



« Last Edit: Yesterday at 06:24:40 PM by skoormit »