Skip to content
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

Achievement type safety #39777

Merged
merged 5 commits into from
Apr 22, 2020

Conversation

jbytheway
Copy link
Contributor

Summary

SUMMARY: Infrastructure "Achievements have better up-front checking to detect definition errors"

Purpose of change

Make it easier to debug mistakes made in json when defining event stats, transformations, scores, and achievements.

Also, doing this checking up-front means we can more safely ignore issues that arise when processing events, deeming them to be due to changes in event definitions. See the discussion in #39717 for more details.

Describe the solution

Every event_statistic now exposes a type, and every event_transformation exposes a fields which defines the fields it has, together with their types.

For this to be possible, event_field_transformation has also gained a type signature which can be used to derive the associated types.

Use all these types to add a bunch more checks at "Verifying" time when loading game data.

Some other changes that happened which working on this:

  • Clarify a comment in units.h
  • When reading a json field into a cata::optional, the code was previously dropping errors. Now it propagates them correctly.
  • Changed some maps to unordered_maps.

Describe alternatives you've considered

There's more up-front checking that could be done, but this is a good start.

Testing

Tweaking the currently existing definitions and observing that I get useful errors.

For event_statistic, add a type() method.  For event_transformation, add
a fields() method.

Consolidate the type of all these field lookup objects as
std::unordered_map<std::string, cata_variant_type> (previously some
places had used std::map).
We can expect this to happen when loading old saves, so we must expect
it.
Detect various forms of error at verification time.
I didn't think this comment was sufficient to explain the mysterious
"throw" here.
The optional deserialize overload wasn't propagating errors to its
caller properly, leadning to some JSON issues not being reported.
@kevingranade kevingranade merged commit 29b43dc into CleverRaven:master Apr 22, 2020
@jbytheway jbytheway deleted the achievement_type_safety branch April 22, 2020 12:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants