Closed clyfordv closed 1 month ago
... also, with the pitiless attitude of working with code I didn't write, is there a reason not to condense VetDamage (<EntityId, Unit>
) and VetInstigators (<EntityId, damage>
) into <Unit, damage>
, and eliminate a whole table declaration on every unit in the game? (see most recent commit, tested it with the Mavor + Paragon and appears to work correctly)
... also, with the pitiless attitude of working with code I didn't write, is there a reason not to condense VetDamage (
<EntityId, Unit>
) and VetInstigators (<EntityId, damage>
) into<Unit, damage>
, and eliminate a whole table declaration on every unit in the game? (see most recent commit, tested it with the Mavor + Paragon and appears to work correctly)
There certainly is!
When you use a table as a key the memory reference is used as the actual 'key' value. This memory reference is not deterministic and is therefore almost guaranteed to be different among players. As a result iterations on this collection are in a different order for each player. And the moment that happens all bets are off and the game can randomly desync, especially when mods or future contributors may suspect it is safe to use for other purposes.
All in all; no - we can't eliminate the table ðŸ¤
We could maybe however use this:
I'm not sure how efficient that function is, we'd need to benchmark it. But that way we can entirely rely on the VetInstigators
table and get rid of the VetDamage
damage.
Would be nice to annotate what stats units usually have.
Would be nice to annotate what stats units usually have.
How would we annotate that?
The use of GetEntityById
and GetUnitById
appears to be fast - I can do 900 queries in 0.4ms. That's sufficient for this type of task!
@clyfordv can you write a changelog snippet? Make sure to also describe the practical change for the players
Dropping the VetInstigators table introduces the issue where a new unit with a reused ID might get credit for kills by the previous (now dead) unit that had the same entity id. Thoughts?
Dropping the VetInstigators table introduces the issue where a new unit with a reused ID might get credit for kills by the previous (now dead) unit that had the same entity id. Thoughts?
Is there a way to detect how often this occurs? If it barely, if ever happens then I don't see an issue.
Unfortunately, I think it might happen... all the time? Basically, any time:
Which feels like it could be an extremely common (inevitable, really) occurrence.
But is there a way to test and see how often it happens? What if we re-introduce the backup table and see how often they're not the same unit for an AI vs AI game?
With titans, ravagers as a backstop:
So 3-5% is probably a good estimate.
(apropos nothing the dynamics of the waves of bots sloshing back and forth is very interesting)
Relevant code here/"I know how to github":
Okay; that is super interesting. Let's let this sink in and see if we can come up with a solution.
I've given it some thought and to me the only correct solution was the old solution where we use a separate table. Did you manage to come up with something?
I did not, I think it's inescapable, will revert the changes.
@clyfordv can we get this finalised so we can have as a part of the game patch
It's done, just needed to update the changelog.
Previously, all damage taken from any source (including an allied unit or
self
) would be included in the veterancy dispersal calculations. This moves the addition operation toVetDamageTaken
(the denominator inveterancyDispersal
) inside an "IsEnemy" check, which prevents (for example) the Paragon from stealing 10,000 damage of veterancy experience for itself as it dies.Downside is a particular unit may get more credit than it is "rightfully" owed for a unit that was hit by friendly fire--not a big downside, in the scheme of things.