FileNotFoundException when detecting the modpack display name

[shuni64]

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:

1. Make a vanilla instance on PolyMC
2. Install Forge and itlt
3. 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

[PaintNinja]

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?

[shuni64]

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.

[shuni64]

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?

[PaintNinja]

I was thinking about reverting it to this again:

final String instanceCfg = itltJarPath.getParent().getParent().getParent().resolve("instance.cfg").toString();

From this: https://github.com/zlepper/itlt/blob/bf61c87d03af795d72012fbf5acc32bde4fd3e40/src/main/java/dk/zlepper/itlt/client/launchers/MultiMC.java#L20

Is there any difference to replacing resolve() with resolveSibling() or same outcome as above?

[shuni64]

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.

[PaintNinja]

Thanks. I'll revert it back to the old getParent() code then as it would need less NPE handling.