FileNotFoundException when detecting the modpack display name
shuni64 opened this issue · 6 comments
Describe the bug
Itlt fails to detect the modpack display name when using PolyMC on Linux, logging a warning and printing a FileNotFoundException each time. The FileNotFoundException is not visible in the debug.log.
To Reproduce
Steps to reproduce the behavior:
- Make a vanilla instance on PolyMC
- Install Forge and itlt
- Launch the instance
Expected behavior
The modpack name gets detected properly. When failing to detect the display name exceptions should be logged to debug.log instead of the console.
Environment details
Please fill in what you know, skip any parts you don't know.
- Operating system (e.g. Windows 10): NixOS Unstable
- Java (e.g. AdoptOpenJDK 8 HotSpot): OpenJDK 17.0.1
- Mod version (e.g. 1.16.5-2.0.0): 1.18.x-2.1.0
- Minecraft version (e.g. 1.16.5): 1.18.2
Logs and additional context
debug.log
Console log
Thanks for your report. I'm having some trouble reproducing this - the modpack name gets detected and used in PolyMC both on first launch (where no config exists yet) and on subsequent launches (where the config generated from the first run is used).
I'm using PolyMC version 1.3.1 on Windows with the same MC and mod version as you.
Could you share your itlt config file please? Is it fixed for you now in the latest stable PolyMC release?
Still happens with PolyMC 1.3.1, same exception as before. The itlt-client.toml should be the default one.
I think this could be happening because of platform-specific behavior of Path.resolve (not resolving through itlt-1.18-2.1.0.jar on Linux because it's not actually a directory). Using Path.resolveSibling instead might be worth a try.
Yeah, using Path.resolveSibling and adjusting the path fixes it on my end.
Should I make a pull request or do you want to reproduce the issue yourself first?
I was thinking about reverting it to this again:
final String instanceCfg = itltJarPath.getParent().getParent().getParent().resolve("instance.cfg").toString();From this:
Is there any difference to replacing resolve() with resolveSibling() or same outcome as above?
resolveSibling() by default calls getParent() internally, so it should be the same as reverting it unless one of the calls to getParent() returns null somehow.