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.
This is rewrite of the current map import/export.
The basic idea is that the map importer will import empty objects that will contain information about a certain map section entry. So for inst's in ipls, we will have an empty that will point to an ide file and contain any information that is required. There will be an empty associated with the ide file which will contain information that is stored in the ide file and which will point to the actual dff file. Using collection instancing, this relationship can be shown as a rendered map in Blender.
This empty system will make it easier to export and import ide/ipl files since all the information is stored already in the empties and all the exporter has to do is collect the empties and convert it into the relevant format.
Regarding the code implementation, I have written a system to define map section entry data types using Python dataclasses and automatically generate the Blender GUI code for that. This will allow quick prototyping and make it easier to implement support for more sections faster without having to define each field in 5 different places. These data types can have formats associated with them that will describe how they can be read from different file types. So far there are two of these file types,
MapBinarySectionFormat
andMapTextSectionFormat
which corresponds to the SA binary ipls and the normal ide/ipl formats. It is possible to override the readers and writers by creating a new class that inherits from these two classes and it will automatically be used while importing the relevant map file.In addition, there's also a placeholder map section that will simply store any data that the parser couldn't read. So sections for which we haven't added support will be exported as-is and make it easier to make simple map edits without breaking everything.
In future, more file types can be defined such as MTA's map files, Lua/CLEO scripts, etc.
TODO List: