Skip to content

Conversation

Basilisk3
Copy link
Collaborator

@Basilisk3 Basilisk3 commented Oct 11, 2025

Description of the proposed changes

Some naval units have guard scan radii that are lower than their primary weapon range. This causes them to move closer to their targets than necessary when attack moving. For the units listed below, the issue originates here, where the cap is set too low for high-ranged weapons. This PR fixes the issue by treating naval units as if they were one tech level higher when applying guard scan radius caps. This ensures their guard scan radius scales more appropriately with their long-range weapons.

Checklist

@Basilisk3 Basilisk3 requested review from Rhaelya and lL1l1 October 11, 2025 11:03
@Basilisk3 Basilisk3 added area: balance related to units balance, but not as a suggestion area: unit-blueprint related to issues in unit blueprints (*_unit.bp) area: balance idea related to suggestions for unit balance labels Oct 11, 2025
@lL1l1
Copy link
Contributor

lL1l1 commented Oct 12, 2025

The destroyers having too low of a guard scan radius was unexpected; it shows that this issue is prevalent across most naval units, so I think a good solution would be to increase the tech tier of naval units by 1 in the guard scan radius limits. That would fit all the changed units except the Summit which would have 160 radius instead of 165.

Copy link
Contributor

@lL1l1 lL1l1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The blueprint processor changes look good to me. Keeping the Summit's custom radius makes sense. Only the snippet needs to be updated now.

@Garanas
Copy link
Member

Garanas commented Oct 13, 2025

Urg, there's quite some scope creep happening here. What started with talking about the Torrent, then some tech 3 units and now all of the naval units. Please be extremely careful. This value can seriously tank the simulation, especially late game. It can be the difference between a game that runs smooth and a game that's slowing down.

With these changes you are changing intentionally chosen values that favor performance over gameplay elements. I finally found the original pull request. These changes originate from: #3891. There's some additional information there.

Please make a list of all the actual changes that are made, similar to a list that I also made here: #3891 (comment) and #3891 (comment). It becomes a lot easier to oversee the changes this way.

edit: I also think that the changelog snippet should mention that this is a trade off between performance and gameplay elements, where the changes now favor gameplay elements over performance. This way if players perceive slower games then they'll know something has changed that can be related to it.

@Basilisk3
Copy link
Collaborator Author

Basilisk3 commented Oct 13, 2025

The Summit and the Torrent are not included here because their blueprints were adjusted.

Galaxy Class (urs0302) benefits from new cap: old GSR = 120, new GSR = 140
Silencer (uas0304) benefits from new cap: old GSR = 120, new GSR = 160
Ace (ues0304) benefits from new cap: old GSR = 120, new GSR = 160
Omen Class (uas0302) benefits from new cap: old GSR = 120, new GSR = 121
Iavish (xss0303) benefits from new cap: old GSR = 120, new GSR = 160
Plan B (urs0304) benefits from new cap: old GSR = 120, new GSR = 160
Hauthuum (xss0302) benefits from new cap: old GSR = 120, new GSR = 140
Ithalua (xss0202) benefits from new cap: old GSR = 80, new GSR = 120
Governor Class (ues0202) benefits from new cap: old GSR = 80, new GSR = 120
Shard (uas0102) benefits from new cap: old GSR = 40, new GSR = 52
Siren Class (urs0202) benefits from new cap: old GSR = 80, new GSR = 88
Salem Class (urs0201) benefits from new cap: old GSR = 80, new GSR = 93

This also shows why nobody ever attack-moves missile‑based cruisers. Their current GSR is shorter than the range of the Salem's main cannon, which makes attack-moving them not just practically useless but also detrimental in many, if not all, cases. Players may not explicitly realize this, but I suspect they have subconsciously learned to avoid it over time. As for new players, they will simply lose their missile-based cruisers because attack-move behaves unintuitively for these units. I do believe this is the kind of experience we want to create.

I will take some time to reflect on whether taking the performance hit is worth it. I don’t think we need to change every unit listed below. I will update the changelog snippet once we have reached a consensus.

@Garanas
Copy link
Member

Garanas commented Oct 14, 2025

Their current GSR is shorter than the range of the Salem's main cannon, which makes attack-moving them not just practically useless but also detrimental in many, if not all, cases. Players may not explicitly realize this, but I suspect they have subconsciously learned to avoid it over time.

I'm not sure if I think you can make this statement. If it really was this detrimental then why did nobody bat an eye about it when the changes were made a few years ago?

I personally do not use attack move for these large distances. It's unpredictable in general, even if you change the distance that they keep from their target. For example: it stops for the first target it sees. Even when that is a tech 1 scout. Or an air unit that it ends up following.

I'm personally not a huge fan of these changes. It's the difference between having a few units in the guard scan radius and a lot of them. It undo's some of the work that I did to make sure the game runs smooth.

I also forgot until now that we made binary changes to when the guard scan triggers. Unfortunately, they're not as documented:

You can read about the conversation here on Zulip:

if I recall correct then in the Steam version the guard scan radius would always scan. Regardless of the type of order. With these binary changes they would only scan when the order would use the output. The scan output is only used by an attack move and patrol order. That means when you do tests units should be either patrolling or attack moving. Or you won't see the difference.

@Basilisk3
Copy link
Collaborator Author

If it really was this detrimental then why did nobody bat an eye about it when the changes were made a few years ago?

There can be a lot of explanations for this, one of which I outlined above. I can recall several a similar cases where a feature was broken for years without anyone realizing. It is not something we can know for sure, so we probably shouldn't spend too much time debating it anyway.

I personally do not use attack move for these large distances.

Attack-move is widely used for long-range engagements, especially in large fights involving battleships. This is because attack-moving helps prevent some of the worst micro mistakes.

It's unpredictable in general, even if you change the distance that they keep from their target. For example: it stops for the first target it sees. Even when that is a tech 1 scout. Or an air unit that it ends up following.

I disagree with calling attack move unpredictable because it stops at the first unit it encounters. This behavior matches the order's description, and it would likely feel more unintuitive (and potentially imbalanced) if it ignored some units but not others.

Overall, if attack-move causes missile-based cruisers (150 range) to move directly into the enemy fleet to attack, then the feature is broken for these units in my opinion. I doubt this is the behavior anyone expects, since the vast majority of units behave differently. To make sure I'm not out of touch here, I made a post in the change-discussion channel on Discord.

@lL1l1
Copy link
Contributor

lL1l1 commented Oct 15, 2025

I'm personally not a huge fan of these changes. It's the difference between having a few units in the guard scan radius and a lot of them. It undo's some of the work that I did to make sure the game runs smooth.

Navy is typically a tech tier higher in cost, so I would say it is very fair to apply 1 tech higher radii since there will be less units scanning, and (for the usual navy vs navy case) less units to be scanned.
Navy also occupies more space with their long range weapons, high speed, and large footprints.

@Garanas
Copy link
Member

Garanas commented Oct 16, 2025

🤷 , if you feel comfortable making these changes then you're free to approve it. I would discourage scope creeping it further though. Don't look for problems in this area unless they are reported. It's a trade off between the performance and gameplay, especially on lower end hardware or laptop CPUs.

@@ -0,0 +1 @@
- (#6939) Increase the `GuardScanRadius` cap of naval units. This prevents them from moving closer to their targets than necessary when using attack-move. For example, attack-moving a Summit (UEF Battleship) will now allow it to use its full range more effectively.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added the performance impact Jip mentioned and I clarified exactly which units are affected.

Suggested change
- (#6939) Increase the `GuardScanRadius` cap of naval units. This prevents them from moving closer to their targets than necessary when using attack-move. For example, attack-moving a Summit (UEF Battleship) will now allow it to use its full range more effectively.
- (#6939) Increase the `GuardScanRadius` cap of naval units. This prevents them from moving closer to their targets than necessary when using attack-move, although it does increase their performance impact.
The units affected include battleships (especially the UEF battleship), strategic missile submarines, missile cruisers, the Cybran destroyer, the Cybran cruiser, and the Aeon Shard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: balance idea related to suggestions for unit balance area: balance related to units balance, but not as a suggestion area: unit-blueprint related to issues in unit blueprints (*_unit.bp)

Projects

Status: To Discuss

Development

Successfully merging this pull request may close these issues.

3 participants