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

Fix assorted json errors #34455

Merged
merged 10 commits into from
Oct 7, 2019

Conversation

jbytheway
Copy link
Contributor

Summary

SUMMARY: Bugfixes "Fix assorted json errors"

Purpose of change

I have written some code to verify that when parsing json files we actually visit every member of every json object. Failing to do so is often a sign of a mistake in the json. For example a typo in a key name, or a misplaced bracket, or a simple misunderstanding of the format.

This happens a lot. See #33144 #33328 #33502 #33613 #33852 for examples of fixes of this type. I'd like to catch them earlier.

Enabling that code surfaced numerous errors in the existing json. I need to fix those errors before I can PR the code that checks for them.

This is the first batch of such fixes, for the dda core game data.

Describe the solution

The vast majority of these changes are to the game data itself. These are:

  • Removing parts that just don't do anything and probably aren't important.
  • Fixing typos and misplacements when I was able to do so.
  • Normalizing the comment format. Now all json 'comments' must have a key starting with //.
  • I added a new item group allclothes_damaged because it was required for many places which were trying to apply damage in a way that doesn't work.
  • Some fields which don't work but contained potentially useful information (like freezing points) I 'commented out' by prefixing them with // rather than just deleting them.

I also tweaked a couple of pieces of code:

  • Expand vehicle part installation requirements to allow for using both using and the 'standard' requirements fields.
  • Improved some error messages regarding json malformedness.

Describe alternatives you've considered

One of the more concerning changes is that a bunch of magen code is using chance in places where that doesn't work. I considered making it work instead of removing it as I have, but I didn't want to get any further sidetracked in this PR which has already taken a couple of weeks. All those changers are packaged up in one commit so it can be easily reverted in the future if anyone ever adds support for chance in these extra mapgen components. I probably should have don the commenting out trick. I can go back and do that if it seems worthwhile.

Additional context

If reviewing these changes I recommend doing so one commit at a time, rather than reading throught the diff in aggregate; it will be easier to see what's going on.

Next step is to look for similar errors in (some of) the core mods, and then push the verification code that checks for these mistakes to prevent them returning.

@KorGgenT KorGgenT added <Bugfix> This is a fix for a bug (or closes open issue) [JSON] Changes (can be) made in JSON labels Oct 4, 2019
"phase": "liquid",
"container": "bottle_glass",
"freezing_point": 25,
"//freezing_point": 25,
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the idea here? Isn't freezing_point a valid node?

Copy link
Contributor Author

@jbytheway jbytheway Oct 5, 2019

Choose a reason for hiding this comment

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

freezing_point is only valid for comestibles. This is an ammo.

@@ -958,7 +955,7 @@
"name": "handful of hickory nuts",
"name_plural": "handfuls of hickory nuts",
"description": "A handful of hard nuts from a hickory tree, still in their shell.",
"spoils_in": "180 days",
"//spoils_in": "180 days",
Copy link
Contributor

Choose a reason for hiding this comment

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

spoils_in should be valid node too.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

spoils_in is only valid for comestibles. This is a generic item.

@snipercup
Copy link
Contributor

I tested your changes and encountered no problems.

  • I could build it with msys2 on windows and there were no unusual errors.

In-game:

  • Browsed trough recipes
  • Browsed trough debug item spawn list
  • visited different locations on the map (cities and specials and fields)
  • Uninstalled and installed a vehicle part

The only errors I got were:

 DEBUG    : invalid furniture id "f_feather_mattress"
 
 FUNCTION : const T& generic_factory<T>::obj(const string_id<T>&) const [with T = furn_t]
 FILE     : src/generic_factory.h
 LINE     : 356



 DEBUG    : Tried to access invalid map position at grid (0,11,0)
 
 FUNCTION : size_t map::get_nonant(const tripoint&) const
 FILE     : src/map.cpp
 LINE     : 8148

But I don't think they are related to your change.

@Night-Pryanik
Copy link
Contributor

Damn, so many errors. So many things worked not the way they should.

@jbytheway
Copy link
Contributor Author

The two cases @ZhilkinSerg highlighted are both examples of item fields which are only valid for some types of item. By default, each item only loads basic info and the details for its slot (in this case, the comestible slot). For some slots it is possible to use them for other item types by explicitly including a sub-member for that slot (e.g. "container_data" for the islot_container). However, that doesn't appear to be possible for islot_comestible.

There were many different comment-ish keys being used: "//", "info",
"note", "comment", "description".  Some had in-game meaning in some
contexts, and some did not.  Try to rationalize them all so that the
"//" prefix is always used for pure-json comments.
This fixes a bunch of places where json was slightly off somehow, either
because some key had a typo in it or some chunk of json was misplaced
somehow.
This removes a bunch of json fields.  All of them do nothing.  And
largely they're just unnecessary.  So I think they can just be
discarded.
These are values that don't do anything, but seemed worth keeping for
posterity in case they might be used for something in the future.
For many pieces of mapgen (NPCs, furniture, etc.) the "chance" field
doesn't work, even though map authors clearly expect it to.  This commit
removes uses of "chance" in unsupported places.

Alternatively, we could add support for it.  That should probably happen
at some point.
A bunch of mapgen was trying to spawn damaged clothing in a manner that
doesn't work.  Rearrange things a bit into a way that might work.
Mapgen in these locations doesn't allow you to specify charges.  Remove
uses that did nothing.
This mission wasn't connected to anything and served no purpose.
There were two ways to specify vehicle part installation requirements.
Either with "using" or with standard requirements ("components",
"qualities", and "tools").  Previously the two were mutually exclusive,
but some parts tried to use both.  There's no reason we should prevent
that, so allow both to be used.
Improve context for consistency check errors in item groups.

Improve errors for undefined item (group) types in mapgen.
@ZhilkinSerg ZhilkinSerg merged commit 0733972 into CleverRaven:master Oct 7, 2019
@jbytheway jbytheway deleted the fix_assorted_json_errors branch October 8, 2019 10:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
<Bugfix> This is a fix for a bug (or closes open issue) [JSON] Changes (can be) made in JSON
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants