The first one to check with when external Add-ons don‘t work is the manufacturer. Did you get in touch with the CrowdRender team already?

@Antonio Vazquez (antoniov) Just seen from a user perspective, maybe it‘s not even needed to have the option Link To Object available for Grease Pencil objects. It makes a lot of sense for mesh objects, as it allows instances to receive different materials, but for Grease Pencil strokes this might be overkill. What do you think? Should Grease Pencil simply ignore that setting in the User Preferences?

Is there any way to remove / deactivate a default keymap item via Python? I've asked this question in two places, once here https://blender.stackexchange.com/questions/110742/how-can-i-modify-the-default-blender-keymap-within-my-add-on-module-registration and once here: https://devtalk.blender.org/t/how-to-modify-the-default-keymap-at-add-on-registration-time/983

side note: same behavior in current 2.8 builds

moved RNA functions outside of loop, please check

Part of this Task T54643

Many users are concerned about the ability to switch between what we at the moment know as layers - in the future collections - in the viewport using hotkeys. At the moment, you can use 1, 2, 3, Alt+1, Alt+2, etc to quickly show and hide layers. Do you think it would be possible to implement something flexible into your design approach? When I look at your mock-up, it makes me think if it was possible to simply assign a hotkey to them, defined by the user. That way, you would not need to hard-code stuff in, instead you put the responsibility to assign the desired key-stroke to the users.

It must be buried somewhere in the code that handles the material link type (i.e. if it is set to 'OBJECT' or 'DATA'). In the given file, the material link is set to 'OBJECT'. If you set the link to 'DATA' on all cube instances, the slot can be removed without a crash. I have done that material link change in the file provided here:

Please note that this isn't a bug in Blender. Animation Nodes have been redesigned recently to use a specific version of Cython. The reason was the massive speedups you were able to get with this. But as a result, AN is now dependent on a specific Python version (which is why you get that error). At the same time, the current development version of Blender has been upgraded to use Python 3.6, while the stable 2.79 still uses 3.5. Recompiling AN yourself using Python 3.6 *should* fix the issue for you, alternatively I believe that Blender can also be forced to use good old Python 3.5. Both is IMHO out of scope of the Blender bug tracker.

@Sergey Sharybin (sergey) Ups, thanks for clarification. Guess this can be closed then as invalid.

I've tested this with a Blender version from the 18th of September, unfortunately didn't work for me. Same as Jan stated, if I copy my template the the AppData/Roaming location it works, but from my custom locations, neither user nor system template folders work. We're using the portable versions of Blender, and redirect unified settings to a server location so everyone shares the same install.

@Brendon Murphy (meta-androcto) Indeed this has been silently fixed somewhen, that's good news! Not sure when it has been adressed, but no crashes any longer

@Thomas Beck (plasmasolutions) I Just checked out the master Branch and patched it with the current version of this patch here (and a few others in addition, like the SurfaceFollow Modifier one). But I haven't changed any ifndef defines due to the total lack of C++ experience. I was only dealing with Python and C# so far.

FYI: Currently the patch fails to apply in three modules (tried applying in blender-v2.78b-release branch on commit c727bc7):

I meant this guide: http://www.gizmoplex.com/wordpress/compile-blender-as-python-module/

Just verified the suggestions. Using the raw Pyhton console made no difference, import errors would remain the same. But following the guide here **http://www.gizmoplex.com/wordpress/compile-blender-as-python-module/** (especially the part of copying the needed libs over to the Python35 directory) made it work. Can now successfully use the bpy build!

Thanks for your feedback,I will try your suggestions next Monday when I am back in the office.

@Bastien Montagne (mont29) HEAD BUMP You can close the report I guess. For one, the crash doesn't appear in newer Python versions, but further more my date format was nonsense. The formatter should have been:

@Vuk Gardašević (lijenstina) I've tested a version which I compiled on the 23rd of November (reports as 2.78.4), it crashes, but with some more latency. Testing VS2015 build, downloaded right now: WORKS! no crashes there!

Wasn't able to reply before as client projects kept me busy, sorry for the inconvenience.

would propose the following fixes:

Hi Sergey,

Maybe even skip the "named", as afaik unnamed objects don't exist in Blender. Otherwise people might ask how to name them...

@Julian Eisel (Severin) I tried to apply this as a patch today, but it failed for me (didn't find the lines to change). To I need to target a specific commit to make it work?

applying the patch currently fails, the kernel_types.h.rej file says:

accidentally created ot twice, please delete this one

Hi Bastien,

found this dirty hacky workaround here:

I'm working on a script that will add some additional input sockets to a node group based on output socket names from another node (input image) in the Compositor. This is the script so far:

strage quirks... man I sometimes hate my keyboard...

forgot to mention I am using the x64 Builds on two different machines, same behavior

I am having the same issue too. We made a lot of use in a recent project of the file output node and rendered the passes to OpenEXR MultiLayer. Not every output file crashed however, it was very hard to reproduce the error. However we were still able to do the compositing without problems by using Blender version 2.72 for Comp. That one never crashed.

same thing here, just one more thing: after confirming the "App has crashed" Windows Dialog, another line is added in the CMD Output:

The weird thing is that this only seems to affect the 64bit versions of Blender. I tested with 32bit Builds on the very same machine under the very same environment and it didn't crash. So even the nvidia driver is identical.

Hi Thomas,