Blender 2.54 Beta, Windows 7, 64-bit.
Downloaded Blender 2.54 beta from the link:
http://mirror.cs.umn.edu/blender.org/release//Blender2.54beta/blender-2.54-beta-windows32.exe
Error message, running as unprivileged user:
found bundled python: C:\PROGRA~2\BLENDE~1\Blender\2.54\python
bpy: couldnt find 'scripts/modules', blender probably wont start.
ImportError: No module named bpy_types
ImportError: No module named bpy_types
pyrna_srna_ExternalType: failed to find 'bpy_types' module
...
(thousands of lines of similar messages)
What seems to be happening is that Blender, run as an ordinary user, is trying to use files only accessible to a privileged user.
At least one problem is that the installed shortcut for launching Blender
has
"Start in: C:\Users\user\AppData\Local\Temp"
"user", on Windows 7, is the default privileged user, and I'm not running as that. That directory is inaccessible to ordinary users. That should probably be "%USER%" (the current user), not "user" (the privileged user).
That fix isn't enough to fix the problem. But there are probably more problems like that in the install.
Uninstalling and re-installing does not help, but the uninstaller doesn't completely remove Blender 2.54, anyway.
(This may be a duplicate bug, but until someone fixes the "Search temporary disabled..." problem with the tracker web site, I can't tell.)
John Nagle
Description
Event Timeline
See also issue #24454, which seems to be roughly the same problem, but with the Linux install.
#24454 "blender-2.55 doesn't display it's menu bar" (not very descriptive title) I filed for linux blender may or may not be parallel with this bug. I've been aware of blender failing to display menus since early in the 2.50 development and I've worked around it with a wrapper script that copied .blender from /usr/share/blender (the equivalent to the admin windows location but I'm sure that windows installers can write to users directories, I lost interest during xp but this is so in vista.
IMHO blender itself should take care of it's user owned configuration files which is the norm. Linux installers can only write root owned things.
I was told that blender should run on linux with no user owned directories and I'm busy debugging the linux problem, which seems build related via the devel email list.
Although the "no menu display" problem is the result in both bugs, the solutions are quite different.
Looking at our installer code it's clear we don't have code in there to do multi-user installations. Reference: http://nsis.sourceforge.net/Docs/MultiUser/Readme.html
Moving to our todo page in wiki: http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Install-OS#Installation
Incorrectly closed with claim that this is not a "bug".
Status: Developer in denial.
If the Blender installer is run as an ordinary user on Windows 7, it requests administrator privileges. It then installs Blender for Administrator use ONLY. It does NOT do a single-user install as the requested user.
The Windows installer can be set up for a "Standard" (unprivileged) install, but that's not what's being done here. To do that, it's necessary to install as "MULTIUSER_INSTALLMODE_DEFAULT_CURRENTUSER". That won't pop up a request for administrator privileges.
Note that this problem has been discovered over at Blender Artists: "http://blenderartists.org/forum/archive/index.php/t-181068.html". You can read about the problems someone had setting up Blender for 300 students at a school.
(Of course, for each user who reported a problem, there are typically ten who just decided Blender was broken and gave up.)
Hi John,
Nathan is not denying the problem, he correctly identified it and marked it on our wiki as something to resolve.
We only keep bug reports open here for issues in our code that don't work as the developer (or design) intended it.
There are plenty of cases when Blender doesn't work as expected by users, that's not for our bug tracker to collect, we put this well organized in wiki for the entire team to work on.
This is moved to the todo list, as it is something that wasn't even implemented yet. I understand that it causes trouble, and that is also the reason it was moved to the _todo list_ and _not rejected_.
I'm aware there are issues with the installer, and as per note on release page, I prefer people to use the zip distribution, as that will work just anywhere it gets extracted, and has the least amount of fuss (even for school administrators, I'd imagine - disclaimer: subjective opinion).
Anyway, until I learn NSIS properly, or some NSIS guru can provide a good patch for our installer, this will be on the todo list. I've tried making changes, and most of the machines I've tested on the installer works, but apparently there are many more scenarios that I have not foreseen and cannot test myself.
If you have good skills with NSIS, I'd love to see our installer improved through patches by you.