Rework continuous_aim as a performance tradeoff, not just a spam penalty #6293
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Collaborator
Author
|
This tested well though might need adjustments for actual player perf expectations in heavy multiplayer games. |
efrec
changed the title
added 2 commits
November 24, 2025 18:58
This adds support for give/take/capture and dynamic team maxunits. Non-player teams get a very large reference value for their maxunits, making them less prone to reaimTime penalties and keeping a more smooth difficulty scaling as they produce more units. Player teams scale vs. a reference amount, 2400 (2000 maxunits + 400 default spam rating for padding), so unit control is never noticeably different due to game mode. It also allows spam score to decrease over time, treating this as a performance tradeoff rather than a penalty for making units, and spreads out the reaimTime penalty to all unitdefs on that team, not only the source "spam-prone" unit. Finally, all units are "spammable" to some degree, now, and all values have been adjusted to account for this.
efrec
force-pushed
the
continuous-aim-improvements
branch
from
6e60e00 to
282c7c5
Compare
Collaborator
why? |
Collaborator
Author
|
I want to treat this as a performance tradeoff rather than a penalty for making units. eta: Slightly better PR description. |
efrec
changed the title
sprunk
reviewed
Nov 27, 2025
sprunk
reviewed
Nov 27, 2025
sprunk
reviewed
Nov 27, 2025
Co-authored-by: sprunk <[email protected]>
…c/Beyond-All-Reason into continuous-aim-improvements
This is equally arbitrary and made-up. Just want the PvE horde-mode faction not to lose its edge over players when they give themselves crazy bonuses.
still dancing around the fact that the customparam isn't the "X units made" so I have some sloppy writing unless someone reads the code to figure out what it means
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Work done
current maxunits / default maxunitsThis approach offers a more direct performance tradeoff rather than a continuously increasing penalty for making units. Chiefly, I want to recover my original/faster reaim time whenever units are lost, including given and captured units. Then, I want to support our dynamic maxunits per-team.
Before this change, two teams received the same time penalty even with vastly different unit caps.
After, if e.g. one team has fewer players, each player on that team takes a reduced spam penalty.
The penalty decrease is not in direct proportion to maxunits. It is weighted toward a reference number (whatever the default maxunits is/was for that team). However,
game_dynamic_maxunitsalready does not redistribute 100% of unit cap, but only 25% of it, so this might be decided too defensively.I've run through this with both
givecatand several massive fightertests and found no errors.This is tangentially relevant to #6289 but neither needs to wait on the other.