haha… that’s been happening a lot lately.
Oh, man!
I upgraded to Windows 7 and tried to install BlurPython again, but this time I’m really having problems getting the dlx load up in Max!
For some reason, it just doesn’t load up at all! Nothing!
I have the correct path to the plugin in the plugin.ini, I have the libs installed in System32 etc… but the plugin doesn’t load up in Max 2009 x64.
Anyone know a reason why this might be? :banghead:
Thanks a lot in advance!
be sure in the root of max
the ini file: installsettings.ini
one of the lastest lines
useUserProfiles=0
if is useUserProfiles=1
you are loading data for a crazy place in your local settings.
that for sure what si not loading.you are using the plugin.ini for the enu folder not the one in max route.
Unfortunately that’s not the problem (see above). I’m not using user profiles and my INIs are loading properly (I load tons of stuff with them).
Just a quick question while i am in the progress of doing the first Python conversions for tools (YAY!). Is the installer problem regarding erasing the Path Variable fixed ? Just wondering as i dont wanna deploy on artists machines and get them all borked
Regards,
Thorsten
Edit: Oh and just stumbled over another question. Are there any plans to maybe use pyside instead of PyQt in the not so near future ? For one it will be lgpl like Qt, it is backed by Nokia itself and will prolly be more pythonic after the first release (wich is supposed to be API compatible with PyQT). With PyQT still beein GPL this seems like a nice option to me!
@ loocas – right now we’re not supporting Vista x64 +, mainly because I dont have access to it to build the writeup on how to install it. The DLLs should work but the installers probably need tweaking and we don’t have any test OS to run it on
@ luigi – thanks for that bit of info – I forgot we do that here already and is the cause of some of the installation headaches
@ thorsten – I don’t have a reproducable case of the path variable being reset – we’ve never run into that on any of my installations…
As for pyside, I’m sure we’ll shift things over to it at some point, we haven’t seen the need to do it yet, but as it matures, it will probably replace PyQt, and we’ll update at that point. Everything I’ve read leads me to believe it should be pretty much as easy as a mass find & replace w/ some minor bug checks
I understand that, but the weird thing is I got it running perfectly fine under Vista x64, however, doing the same steps, I can’t seem to get blurPython running under Windows 7 x64.
I tried to force-load the .dlx in Max and it threw:
Any idea why it might trhow this error? :shrug:
Also, perhaps, providing the dlls etc… without the installers might help some of the more “adventurous” types to try to get it up and running under various OS versions. :lightbulb
Anyways, keep rocking, guys! :buttrock:
Very very cool Eric. Great stuff and am still playing with doing some custom widgets and messing things up…great fun
I’ll just try on a spare box and see if it’ll reset the path there too. Eventually something else caused it…more to come!
Regards,
Thorsten
Eric, if you want to just swap out the 2010 SDK in VS and hit compile for x64, I’m more than happy to test everything for you. I won’t blame you if anything breaks!
Could it be that the Blur DLLs arent loaded (the ones going to the system dirs) ?
I wouldnt know for 7, but has the location for DLLs changed ?
Regards,
Thorsten
Yeah, I think so too, but why shouldn’t they load up in Windows 7, but they did in Windows Vista? W7 is “just” a cosmetic update to Vista (well, that’s an understatement, but still).
Next Guess, Python/Qt not working correctly ?
Hmm. I don’t know. Python and Qt seem to be working just fine from the IDLE/CMD line. :banghead:
This is such a pitty. BlurPython seems to be the perfect answer to all our prayers as to having Python FINALLY implemented in 3ds Max, but on the other hand, since it’s privately developped and not OpenSource, it’s something you can’t rely on in a production environment.
I can’t build my entire pipeline on this as:
-
What if Blur decides not to release new versions anymore?
-
What if Blur will never upgrade to Max v. XYZ that we’re using?
-
What if there’s a bug we can’t workaround that holds us back?
-
What if Blur changes the lic. policy that we won’t be able to follow?
etc… etc…
Don’t get me wrong, this is a HELLUVA awesome job you’ve done, blur guys! And I very, very much appretiate it. But to us outside Blur, it’s “just a toy”, not really a production tool.
Well – the end goal with this is to actually get Autodesk to pick it up and just build it in…we’ll see how well that works out…
As for the error you’re getting, its got nothing to do with Qt or PyQt. The DLLs we install that require the path changes won’t actually be accessed until running the Python scripts from within the scripts in [max]/scripts/python/startup.py
The blurPython26.dlx itself doesn’t have any Qt dependencies, its only linked to the 3dsMax & Python26 Libs
You have to make sure that you have Python26 x64 installed and that the path within your registry properly points to the installation path, I don’t know how windows 7 works and if its changed, but for the others its at HKLM->Software->Python->2.6-> and then click the different variables to make sure your paths are correct. I’ve run into problems having multiple pythons installed with customized path locations where the registry is wrong, but if I run python from its install folder, it works just fine.
All that you really need to run python in max is the blurPython26.dlx itself, you just won’t have any gui support.
To test it, you can strip out all else from the installer – the stuff in [max]/scripts/python/ & [max]/scripts/startup/init_py.ms
Run max, and in the listener just type: python
That should show you a global struct that the DLL registered. But you dont need to mess with the PATH variable, or Qt/PyQt installs to fix the error you’re seeing.
As for open sourcing – its always been our plan to release the source code and support future versions, I still have to clean and document everything, and its still a work in progress.
Now this is great news, Eric! Really, KUDOS for all that!
I hope ADSK will pick it up, it’s becoming a must for 3ds Max TDs nowdays.
As for the Python path. I didn’t know it was looking into the registry for the path actually, I don’t have anything in the REG regarding Python (resp. under the HKLM > Software > …).
Can you, please, show me a screenshot what the reg. key hierarchy should look like? I’ll add it manually, but I don’t know what’s the correct format. I thought that only a PATH variable would be enough though.
Thanks a lot again, much appretiated!