Handle the case where a user tries to install an asset pack which has been corrupted by macosx

[almatheresa3]

Hi everyone.

I have same troubles with installing system assets in blender.

I have installed the MPFB in blender and it works perfectly fine when i make a human. I have tried to install the "system assets pack". When I try to apply the assets, such as hair, skin, eyes etc. it says that there is no assets installed. Do any of you know what this problem could course? could it be because the asset pack isn’t compatible with the new Mac version or Blender 5.0?
I am looking forward to hear if any of you nows the solution

XO

[joepal1976]

This looks rather strange. With the message about the system assets not being available, the hypothesis that the filter box might have a value seems invalid.

I'd like some more info:

Can you open the "system and resources" panel and take a screenshot of that?

In the "system and resources" -> "directories" panel there is a button for opening "user files". Can you click that and take screenshots of the following directories (if they exist).

• data
• data/packs
• data/eyes

[killmetro]

Same issue

[joepal1976]

I am not going to get any further without more debug info.

[mslisbetha-droid]

Hey @joepal1976 I'm having the same issue. I am using Blender 5.x and MPFB v2.0.14 on macOS.

And since there have been no responses on this I'll supply the information.
I go to System Information (Hopefully in the right spot)
Build Info: 20260225
Blender Version: (5,0,1)
Under Directories: User Files, Library Files, System Data, Log files
Here are the screenshots you may be asking for after clicking User Files

Hopefully this helps.
FYI - The directories under MACOSX appear to be empty, while the ones with the appropriate names have items in them. Hopefully, if you are still responding I get a notification about this.

Thank you for your assistance.

[joepal1976]

This looks very strange. Is this after using the "install from zip" button inside MPFB or did you manually unzip files in the data directory?

In summary, there is a subdirectory level too much here. The "makehuman_system_assets_cc0" directory shouldn't exist at all, Its contents should be one level up and be placed directly under "data".

To fix the problem, you can move the directories manually. But it'd be interesting to understand how this came to be in the first place.

[mslisbetha-droid]

@joepal1976
It's in the zip file that way. I was just working with Claudette (Claude) and she said move the stuff out after loading the zip traditionally, then have at it. But the downside is that in each pack there is a data directory with a Jason file in it, that needs to be moved directly out of it (or does it?), else it might blow up the upper level data directory when drag and dropped. Gotta be careful with that. Could be wrong about this though.

My guess is that the python script responsible for doing the behind the scenes work is not working properly, if there is a script that unpacks the zip file and such.

[joepal1976]

You should not need to do anything manually in the data directory. For most users it does not make sense to even open the data directory.

If claude tells you to drag and drop things, then I'd recommend having claude read up on the docs on the home page before continuing.

[mslisbetha-droid]

@joepal1976 I agree, with you on verifying the information but for some reason MPFB isn't unpacking the information correctly, as evident by the the screenshot and dyadic responses concluding that the subdirectories need to be moved up one.

One of two things; bad packaging, or the plugin isn't processing the asset package properly.

In either case, the workaround is to first import as per the documentation. If that fails, go to the user area and move the contents out of the sub-directory and drop into one folder above. This is the solution that you yourself suggested, and at the same time Claude did as well.

Just to re-test I downloaded another asset pack and it to did the same thing. After moving the sub-directories up one, those items also were properly displayed. Following that, I pulled in a pose pack, installed via the suggested method. sub directory showed up, but the poses did not. Moved the poses and they show up.

Until the issue is resolved, that is someone looks further into this as myself and the OP can't be the only ones experiencing this issue. Again, I am seeing it on Blender 5.0.1 with the 20260225 plugin on a macBook with Apple silicon.

Furthermore, it doesn't explain why the "Load asset from zip" is also creating empty subdirectories under __MACOSX.

[mslisbetha-droid]

@joepal1976

And I found, and I mean Claude found the possible issue.
Found in loadpack.py

Yep, there's the bug plain as day:
pythonwith zipfile.ZipFile(self.filepath, 'r') as zip_ref:
zip_ref.extractall(data_dir)
It's just blindly extracting the zip into data_dir — so whatever folder structure is inside the zip is preserved as-is. Since the zip contains a top-level folder called makehuman_system_assets_cc0/, that's exactly what gets created, nesting everything one level too deep.
The fix would be to extract and then flatten — i.e. detect if the zip has a single top-level folder and if so, move its contents up. But since it's not your code to fix, your manual Finder workaround is the pragmatic solution.

And as you pointed out in an early post, it (make human_system_assets_cc0) shouldn't be there. Now we know why.

[joepal1976]

I still don't understand how this happens. Some 90000 people have installed the systems asset pack by now, without running into this problem. The system asset pack from the home page does not contain the extra directory level you are talking about, I re-downloaded and checked now.

[mslisbetha-droid]

@joepal1976 The behaviour is actually the default on macOS — Safari ships with 'Open safe files after downloading' turned on out of the box, meaning every Mac user who downloads the zip will have it automatically decompressed. Seeing a folder instead of a zip, re-compressing it with Finder is the logical next step — it's what macOS encourages by default, not unusual user behaviour.

The question worth asking isn't why I did it, but how many of your 90,000 installs were Mac users who hit this exact situation, quietly gave up, and never filed a bug report. Silent failures don't show up in install statistics.

The root cause is in loadpack.py — the extractall call blindly preserves whatever folder structure is inside the zip. A simple fix would be to check if the zip contains a single top-level folder that isn't a known asset directory (like clothes, skins, poses etc.) and strip it before extracting, while also skipping __MACOSX entries that Finder injects. That would make the plugin robust against this default macOS behaviour regardless of how the user got their zip file.

Worth noting that the OP @almatheresa3 appears to have been using v2.0.13 while I am on v2.0.14, confirming this is not a version specific issue and has persisted across releases. A nod to @almatheresa3 who originally opened this issue but appears to have dropped off after the initial request for debug info, hopefully a fix to loadpack.py puts this one to bed once and for all.