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

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

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.

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.

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.

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.

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.

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.

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.