Mac compatibility

[lcy0x1]

Minecraft Version

1.16.5

Forge Version

32.2.20

Mantle Version

1.6.147

Tinkers' Construct Version

3.3.0.308

Describe your issue

The notorious mac file .DS_Store ruins ModifierModelManager at line 133. It could be fixed by putting this line in the try-catch block. Crash report:

[02Jan2022 22:19:22.327] [Render thread/FATAL] [net.minecraft.client.Minecraft/]: Reported exception thrown!
net.minecraft.crash.ReportedException: Rendering overlay
Caused by: net.minecraft.util.ResourceLocationException: Non [a-z0-9_.-] character in namespace of location: .DS_Store:models/tconstruct_modifiers.json
    at net.minecraft.util.ResourceLocation.<init>(ResourceLocation.java:31) ~[?:?]
    at net.minecraft.util.ResourceLocation.<init>(ResourceLocation.java:42) ~[?:?]
    at slimeknights.tconstruct.library.client.modifiers.ModifierModelManager.lambda$onReloadSafe$0(ModifierModelManager.java:133) ~[tconstruct:1.16.5-3.3.0.308]
    at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267) ~[?:1.8.0_301]
    at java.util.Iterator.forEachRemaining(Iterator.java:116) ~[?:1.8.0_301]
    at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) ~[?:1.8.0_301]
    at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) ~[?:1.8.0_301]
    at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) ~[?:1.8.0_301]
    at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) ~[?:1.8.0_301]
    at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_301]
    at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) ~[?:1.8.0_301]
    at slimeknights.tconstruct.library.client.modifiers.ModifierModelManager.onReloadSafe(ModifierModelManager.java:145) ~[tconstruct:1.16.5-3.3.0.308]
    at slimeknights.tconstruct.library.data.IEarlySafeManagerReloadListener.lambda$reload$0(IEarlySafeManagerReloadListener.java:19) ~[tconstruct:1.16.5-3.3.0.308]
    at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640) ~[?:1.8.0_301]
    at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1632) ~[?:1.8.0_301]
    at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) ~[?:1.8.0_301]
    at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1067) ~[?:1.8.0_301]
    at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1703) ~[?:1.8.0_301]
    at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:172) ~[?:1.8.0_301]

Crash Report

No response

Reproduced with only Tinkers' Construct?

No

Other mods required

Create Above and Beyond Modpack v1.3

Confirm the following

• [X] Confirm you have checked the roadmap, what's new, and the FAQ for your issue
• [X] Confirm you have searched the tracker to see if your issue already exists
• [X] Confirm you are not using performance enhancers, such as optifine

[KnightMiner]

Honestly, I would advise keeping .DS_STORE out of your resource packs as it will likely break other things in the future. I'll look into a sanity check for namespaces in the future, but this is low priority as its misusing resource pack namespaces.

Also, Other mods required is not a spot for your to put your modpack. Its a spot for your to write the 1-5 mods required to cause this bug to happen. In this case, find whatever resource pack/mod is causing this as they also have a bug on their end to fix.

[lcy0x1]

It will be generated every time I open the resource pack folder and there is no way to remove it (deleting it also require me to open the folder). That's why I call it notorious.

[KnightMiner]

This crash is caused by .DS_STORE showing in the list of a resource pack's namespaces. Which means its only a problem in a specific resource pack, e.g. resourcepacks/<My Pack>/assets/.DS_STORE. If all your resource packs are zip files, there shouldn't be an issue.

Alternatively, maybe one of your mods zipped .DS_STORE into their build data. Could also be a global resource pack loader mod as those often use folder packs.

[wompking]

If I'm working on a resource pack while using TC — let's say, while developing a resource pack for a modpack (which I am doing) — then this problem will happen frequently, since it's extremely inefficient to rezip the resource pack with every change.

In which case: no, it isn't misusing resource pack namespaces, it's a Mac compatibility issue.

[lcy0x1]

I think I have found a workaround: Even though .DS_Store is not visible in any means, and cannot be deleted through normal ways, I can open the entire game folder tin VSCode and use VSCode to delete all .DS_Store it finds.

[wompking]

I am personally just going to set up a Bash script to delete all .DS_Store files before I run the modpack. It would still be very nice to not have to deal with this, though.

[KnightMiner]

Was fixed awhile back in 91a7a29, which goes back to 1.18.1. Not sure if this will ever be fixed for 1.16, but will leave it open for now.