Currently files are decompiled based solely on what's available in the asset.
A more correct approach would be to dump all the available info from every package and export it into a kms header file to be used when decompiling.
The existing decompilation logic should rely solely on the type info for this to work.

• Refactor the decompiler to use the symbols generated by the analysis step rather than using the asset directly
• Implement tooling to dump a library file containing all known imported/exported blueprint symbols using code injection
• Fallback tooling for when code injection is not available (based on blueprints only)
• Refactor the analysis step to use a dumped library file and skip unnecessary inference.
• Refactor the output the imports differently when using a library file

Currently need to use ZenTools to convert IO store packages into regular packages.
Might be worth looking into supporting IO store packages natively, at least for reading.
Alternatively, we could use CUE4Parse to load the package, and simply output a regular package when compiling using UAssetAPI.

Remove the need of these constructed types by detecting the type (class, struct, interface, array) in the analyser and adjusting the generated code accordingly.

• Add an integration test where blueprints from various games with different unreal engine versions are decompiled & recompiled, where success is based on equality of the newly generated code
• Add a compiler testing suite where all the compiler language features are tested
• Add a compiler testing suite where different kinds of errors are tested, including:
  • Syntax errors (reporting should be helpful to the end-user)
  • Semantic errors (wrong types, invalid context for an expression, unknown attribute, etc.)

Decompiler

• Support 'New' FFieldPath property of KismetPropertyPointer
• Support loading properties from StructExport.LoadedProperties instead of child exports

Compiler

• Populate 'New' FFieldPath property of KismetPropertyPointer
• Populate StructExport.LoadedProperties when compiling

Currently the support for custom objects is limited.

• Create a list of types that have to be supported (to further specify the following tasks as some have been completed partially)
• Custom variable support
• Custom function support
• Custom property support
• Custom class support
• Custom import support

Currently changes to existing asset imports/exports other than script bytecode are ignored.