Closed leryss closed 3 years ago
This approach will produce inconsistent data for structures that may or may not be empty.
There are some examples in particles.bin. For instance, the probabilityTables
is a list of VfxProbabilityTableData
structures:
"probabilityTables": [
{
"keyTimes": [0.0, 1.0],
"keyValues": [1.0, 0.0]
},
{},
{}
]
With your changes, this would be output as:
"probabilityTables": [
{
"keyTimes": [0.0, 1.0],
"keyValues": [1.0, 0.0]
},
"VfxProbabilityTableData",
"VfxProbabilityTableData",
]
which produces inconsistently typed data.
This is one of many exemples. Some of those structures may be already used/checked by people. Changing the data from a an object to (sometimes) a string would break code that rightfully assume that some field (if set) is an object.
A better approach would be to add a special entry e.g. (__type
) to structures, with the type as value. We would have to warn users that this is not a regular field. (Note that scripts should already not fail on unknown fields since new ones could be added at anytime by Riot). And it would not break scripts that fetch specific fields to extract data.
Moreover this could be useful even for some non-empty structures.
I have modified the code to add "__type" field with the name of the field for all structs
For my application I needed some information about spell data that was missing because it was in a struct that was not being serialized (it was an empty dict in the resulting json). Thing is that the name alone of the unserialized struct can convey enough information about the spell.
Take a look at the following image showcasing the json differences before/after the code I wrote:
As you can see for example mTargetingTypeData tells us what type of spell are we dealing with values can be Cone, Location, Area. Also there is important information that can be extracted from the type of the struct for behaviours.