-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add stats tracker #33782
Merged
Merged
Add stats tracker #33782
Conversation
This file contains 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
ZhilkinSerg
added
[C++]
Changes (can be) made in C++. Previously named `Code`
Code: Infrastructure / Style / Static Analysis
Code internal infrastructure and style
Code: Tests
Measurement, self-control, statistics, balancing.
labels
Sep 3, 2019
range_hash is a hash for using e.g. containers as keys in unordered_maps. auto_hash is a hash function that chooses automatically between std::hash and cata::tuple_hash depending on the hashed type.
This is a typedef for the map type used to store the event data. Adding it because the underlying type seems likely to change in the future.
This sums the value of a particular field in events satisfying a criterion.
Previously each player object contained some lifetime_stats about tiles moved, etc. Replace all that with the newly added stats_tracker functionality. One side-effect is that muscle-powered bionics now recharge at random intervals, rather than regularly, but should have the same average charge rates.
This is supposed to be in the standard library in C++14 but gcc 5.3 lacks it.
jbytheway
force-pushed
the
stats_tracker
branch
from
September 4, 2019 01:27
0e7a193
to
89b61f1
Compare
misterprimus
pushed a commit
to misterprimus/Cataclysm-DDA
that referenced
this pull request
Sep 21, 2019
* Added auto_hash and range_hash range_hash is a hash for using e.g. containers as keys in unordered_maps. auto_hash is a hash function that chooses automatically between std::hash and cata::tuple_hash depending on the hashed type. * Add event::data_type This is a typedef for the map type used to store the event data. Adding it because the underlying type seems likely to change in the future. * Add a simple stats_tracker that counts events * Add stats_tracker to game * Serialize stats_tracker * Add hp_part case for cata_variant * Add (and use) a character_takes_damage event * Add stats_tracker::total This sums the value of a particular field in events satisfying a criterion. * Replace lifetime_stats with stats_tracker Previously each player object contained some lifetime_stats about tiles moved, etc. Replace all that with the newly added stats_tracker functionality. One side-effect is that muscle-powered bionics now recharge at random intervals, rather than regularly, but should have the same average charge rates. * Some comments to help explain stats_tracker * Add std::hash specialization for event_type This is supposed to be in the standard library in C++14 but gcc 5.3 lacks it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
[C++]
Changes (can be) made in C++. Previously named `Code`
Code: Infrastructure / Style / Static Analysis
Code internal infrastructure and style
Code: Tests
Measurement, self-control, statistics, balancing.
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.
Summary
SUMMARY: Infrastructure "Add new object to track event statistics for use in calculating scores"
Purpose of change
The next step towards #4173 (scores and achievements).
Replace the existing
stats
class (used forplayer::lifetime_stats
) with a more generic solution.Describe the solution
Add a new
stats_tracker
class which counts all events sent to the event bus.Add new
event
types for the events needed to compute the stats fromlifetime_stats
.So far it has some simple APIs to count events and compute the sum of values from events. This is used to compute the values previously stored in
player::lifetime_stats
.The
lifetime_stats
was also used for the torsion ratchet CBM and related CBMs. I switched them to use randomized updates at the same average frequency (I think this is more correct anyway; I think there were corner cases where you could cause the power to increase every turn).Describe alternatives you've considered
More features will be needed to make this sufficiently functional for achievements, because we can't afford to do an O(n) recomputation every time an event occurs. I have plans to add "live-updated" statistics that can track various specific values of interest with O(1) updates.
But for the lifetime stats (and for scores in general), this is good enough.
I think the "number of moves" statistic is dubious. I'm not sure exactly what sorts of moves it's counting. But it should be the same as it used to be, in any case. If we want to make it more correct, that can go in a separate PR.
This is now more general than
kills_tracker
, so we could probably retirekills_tracker
, but I don't plan to do that. It's convenient to have all that code and it's associated GUI in one place.The "damage taken" and "damage healed" stats don't seem hugely interesting to me, so I considered just removing them, but I didn't want to lose functionality (and I can imagine some fun achievements involving them).
Additional context
There are potential memory and save file size concerns with tracking all these stats as I am. So far I think the events that are present shouldn't explode too badly (we have one count for each distinct set of parameter values for every event type). If it starts to be a problem we could blacklist certain events or fields from the
stats_tracker
.Uses the new features added in #33742.
The
hp_part
case I added tocata_variant
isn't actually used in the final version, but having it doesn't hurt.