More fixes for mod-compatibility #7
Conversation
This commit makes sure that we *only* remove the version specification from the dependency string, whereas previously anything beyond the first space was removed. This caused problems for mods that use spaces in their name
|
Unzipped mods not working isn't intentional so much as I never got around to making it work, on account of never actually needing it. It probably should be implemented, but it does not need to happen here. The relative filename thing does seem like a hack, but it can always be replaced later, and should not negatively impact any case in which it is not needed. Off the top of my head, a less hackish solution may be to record the directories of the files being imported into a stack, and to check the top of that stack when finding the next file. (If I remember how this code works correctly, |
|
Yup, that sounds like a better solution. I'll look into it. |
Serpent is available globally inside Factorio.
Factorio provides a C++ implemented function table_size() that calculates the total size (array *and* dictionary part) of any table. This was introduced in version 0.15.24: https://forums.factorio.com/50323
Factorio allows requiring files relative to the file doing the require call.
For example given the scenario
modname_1.2.3/
`-- prototypes
|-- a.lua
`-- b.lua
both of the following require() calls are a valid way
to require file b from file a:
a) require("prototypes.b")
b) require("b")
This behaviour is different from default Lua, where require-calls must be
absolute to the base folder and where only case a) is valid.
This commit stores each file's directory in a stack as they are executed
and then tries to require the file both relative to the top of the
stacktrace and absolute to the root folder of the zip archive.
In doing so they are more clearly marked as such and there is no confusion on what their purpose is.
RustyBlade64
force-pushed
the
mod-compat-fixes
branch
from
d618b6b to
83d7c54
Compare
|
Finally found some time for this PR again. As you suggested, the relative require logic now records the required files in a stack and uses it to determine where to load the file from. I have also updated the |
| } | ||
| if (version.major == 0 and version.minor >= 17) or version.major >= 1 then | ||
| -- read extranous byte present since 0.17 | ||
| readAll(f, 1) |
There was a problem hiding this comment.
I don't know what this byte is used for, but I will try to find out. For what the calculator needs, it seems to be irrelevant though.
There was a problem hiding this comment.
Got confirmation from Bilka that this byte indeed has no meaning, see the updated documentation on the wiki.
These are all the issues I found in the Seablock modpack. Together with KirkMcDonald/factorio-tools#5 the at least data dumper pipeline now generates a seemingly correct looking JSON for Seablock.
Details for the non-obvious things are in each commits message. The commits are in the order the problems occurred/were masking each other.
Mod without dependency field: e.g. KS Power
Mod names with spaces: e.g. A Sea Block Config and Nuclear Fuel
File relative requires are happening e.g. in Angel's Refining
Regarding Serpent and
table_size(), I don't know anymore where exactly they were used, but it's a pretty straightforward addition I guess.The changes to the
require()logic are clearly a hack. Using the call stack is the best idea I could come up with though. If you see a better way, please let me know. If if stays like this I'll do some refactoring to get rid of the code duplication currently in that commit.Also: Is it intentional/known that loading unzipped mods is currently not working? It's just one line missing here, so I thought it might have happened by accident. If that's the case then I still need to adjust the require logic for the non-zipped case as well.
More special
require()logic is coming for 0.17 as well btw, see #6.