v2.5.1 Bugs Thread

[buczbucz]

Distance from A (Scorpii) to B (Caledonia) is different than from B to A on Galactic Map.

Is there more than one route between them?

Yeah.

Here's a bigger map:

[Steve Walmsley (OP)]

Distance from A (Scorpii) to B (Caledonia) is different than from B to A on Galactic Map.

Is there more than one route between them?

Yeah.

Here's a bigger map:

Thanks. Its not a bug. The pathfinding algorithm ends when it finds the fewest number of transits. It is using different 5-transit routes between the two systems. if you want to prioritise one route, you can restrict a jump point and the distance check won't use it.

[skoormit]

...The pathfinding algorithm ends when it finds the fewest number of transits....

What are the chances that could be changed to find the shortest route by actual distance rather than number of hops?

[Steve Walmsley (OP)]

...The pathfinding algorithm ends when it finds the fewest number of transits....

What are the chances that could be changed to find the shortest route by actual distance rather than number of hops?

It's possible, but it's a lot of work. The current system is good enough in 95% of cases and is easily worked around when it doesn't, so there isn't the pressure to build a perfect system - especially with the chance of introducing new bugs. Currently, I just generate an expanding search, record each system the first time I reach it and then eliminate that system from the search. To check every route, I need to find the distance to each system by any route possible, which is an exponential task, as I can't eliminate any systems from the search as I progress.

EDIT - I managed to find a way to do it

Instead of eliminating each system after use, I ignore it (and any systems beyond it) when it is found for the second (or third) time, unless the distance is shorter than any previous time I found it, in which case it is added back into the expanding search. That allows for the speed benefit of eliminating systems, but allows for the option to find them again by a shorter route with more transits. This is only for checking distance, not auto-route. That is a larger problem.

[skoormit]

...Instead of eliminating each system after use, I ignore it (and any systems beyond it) when it is found for the second (or third) time, unless the distance is shorter than any previous time I found it, in which case it is added back into the expanding search. That allows for the speed benefit of eliminating systems, but allows for the option to find them again by a shorter route with more transits. This is only for checking distance, not auto-route. That is a larger problem.

What if you considered the Jump Points to be the nodes, rather than the systems?
Distance between opposite ends of a jump point is 0.
Seems like you could then do a breadth-first search, and force the path to alternate intrasystem movement with JP transits. That way you eliminate all but straight paths between transiting jump points, and you eliminate the silly case of transiting a JP and immediately transiting back.

For pathfinding, the start and end nodes are the current and target destinations.
For system distance checking, the start and end nodes are the centers of the start and end systems.

[randakar]

That's a classic programming challenge, really.

I think considering jump and Lagrange points nodes in the search graph is a good idea. Breadth first, based on distance from your starting point.

The problem you may end up with is situations where you find previously visited nodes but because you search breath first based on distance it will always be either a node at the end of the graph, in which case you overwrite the distance value, or closer to your starting point in which case you eliminate the current path as an option instead.

You will also want to cache routes between jump points to make this thing fast.

[Steve Walmsley (OP)]

I already consider the jump points. Each system is treated as a set of jump point nodes with zero distance to their counterparts in the next system and a matrix of distances between each other, plus each JP has a distance to the centre for the final leg. My explanation above was the simplified version. When I say ignore, or eliminate a system, I mean all the JP nodes in that system.

[randakar]

Pure graph theory wise though, systems aren't really relevant in the sense that they're arbitrary groupings of nodes.

It's quite possible for jump points to be arranged in such a way that two different routes to the same destination don't share jump points while still crossing the same system.

Of course I don't know the exact algorithm, and its been a while since I employed pathfinding algorithms in code. But it's fun stuff to consider. so apologies if I keep stating the obvious

[skoormit]

It's quite possible for jump points to be arranged in such a way that two different routes to the same destination don't share jump points while still crossing the same system.

It's even possible for the shortest path from system A to system B to involve transiting across system C more than once.
A-C-D-E-C-B, for example, if there are very short routes in system C from JP A to D and from JP E to B, and also the route is very short in system D from JP C to E and in system E from D to C, while the alternative path in C from JP A to B is longer than all of those combined.

[Steve Walmsley (OP)]

Yes, both of the above cases are already handled.

[Exultant]

Summary: Turret design parameters not matching with stated changes from VB6 --> C#. CIWS calculations not in line with other components.

The function number: N/A
The complete error text: N/A
The window affected: Component Design
What you were doing at the time: Designing components to reverse engineer cost and crew calculations
Conventional or TN start :TN
Random or Real Stars: Real
Is your decimal separator a comma, No.
Is the bug is easy to reproduce, intermittent or a one-off: Easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: Game Start.

In building a spreadsheet to run calculations for PD designs to take into account the PD changes, I encountered a few things that don't seem to be working as intended.

In the C# 1.0 changes, you mentioned that crew reduction was doubled for turret designs compared to VB6:

A minor update. The benefits of multiple energy weapons in turrets have been doubled. A twin turret now has a 20% reduction in crew vs two solo weapons and has a 10% reduction in gear size. A quad turret has a 40% reduction in crew vs four solo weapons and has a 20% reduction in gear size.

Gear reduction is working as stated, but crew reduction is still at VB6 levels.

How to reproduce:

a 10cm single turret laser has a crew of 9 (unchanged from a base weapon). Expectation then is that a twin turret has a crew of 14.4 (so 14 or 15 depending on rounding rules), but design screen is giving me a value of 16, which is ~10%

A triple turret is expected to be 30% through implication, giving us a 30% reduction on 3x9, or 18.9. The design screen is telling me 23, which is ~15% reduction.

A quad turret is expected to therefore have a crew 40% smaller than 4x9, so 21.6. The design screen is giving me 29, which is ~20% reduction.

CIWS Design

Not sure whether this is a bug, or just undocumented calculations, but I am also having trouble reproducing the math for crewing a CIWS. I know it's five separate parts (gun, turret, fire controls, sensors, ECCM) and I can accurately model cost of the individual parts, but I cannot piece together how much each contributes to overall crew. Changing the Turret Tracking Tech (10%) tech level used is also modifying crew required, which is not matching with how turrets work (more gear % adds to size, but not crew required).

The best thing I can approximate here after testing many different settings is that crew for a CIWS =roundup(HS) regardless of individual parts.

Expected behavior: Crew = (2 * 50% Gauss Gun Crew *(1 - Turret Crew Reduction% (20%))) + (BFC Crew) + (Active Sensor Crew). Turret gear size should not affect crew.

I'm content if this is working as intended to simplify the calculations, I am simply seeking clarity on this one.

[Jovus]

The Ground Forces Unit Series screen shows obsolete units as part of the available units to put in a series. I wouldn't call this a bug, exactly, but it impinges strongly on a certain use case: oops, I set something wrong (like noncombat on a unit that should see combat), let me just obsolete it and give the new one the same name as the old.

What I would like to see is a checkbox or button like elsewhere that toggles whether obsolete units are shown both in the units already assigned to series and those available to be assigned.

[nuclearslurpee]

The Ground Forces Unit Series screen shows obsolete units as part of the available units to put in a series. I wouldn't call this a bug, exactly, but it impinges strongly on a certain use case: oops, I set something wrong (like noncombat on a unit that should see combat), let me just obsolete it and give the new one the same name as the old.

What I would like to see is a checkbox or button like elsewhere that toggles whether obsolete units are shown both in the units already assigned to series and those available to be assigned.

This is not a bug, since part of the purpose of the Unit Series tab is to see which units can be replaced by which other units.

[Andrew]

The Ground Forces Unit Series screen shows obsolete units as part of the available units to put in a series. I wouldn't call this a bug, exactly, but it impinges strongly on a certain use case: oops, I set something wrong (like noncombat on a unit that should see combat), let me just obsolete it and give the new one the same name as the old.

What I would like to see is a checkbox or button like elsewhere that toggles whether obsolete units are shown both in the units already assigned to series and those available to be assigned.

This is not a bug, since part of the purpose of the Unit Series tab is to see which units can be replaced by which other units.

True but it would be nice to have a way of removing a unit , for instance when I accidentally design a unit called Divisional HQ but fail to put an HQ component in it , or after designing some none combat units my Heavy tank design is accidentally set as none combatant.  So a way of deleting some incorrectly designed unit would be nice

[nuclearslurpee]

The Ground Forces Unit Series screen shows obsolete units as part of the available units to put in a series. I wouldn't call this a bug, exactly, but it impinges strongly on a certain use case: oops, I set something wrong (like noncombat on a unit that should see combat), let me just obsolete it and give the new one the same name as the old.

What I would like to see is a checkbox or button like elsewhere that toggles whether obsolete units are shown both in the units already assigned to series and those available to be assigned.

This is not a bug, since part of the purpose of the Unit Series tab is to see which units can be replaced by which other units.

True but it would be nice to have a way of removing a unit , for instance when I accidentally design a unit called Divisional HQ but fail to put an HQ component in it , or after designing some none combat units my Heavy tank design is accidentally set as none combatant.  So a way of deleting some incorrectly designed unit would be nice

I usually delete such mistakes in the research tab. Don't remember if you need SM to do this or not.