Prepping addons for 2.8

Thanks Brecht :slight_smile: Appreciate the post. Ok, I do use it, our addon depends on it in the following manner.

Crowdrender is our addon. It is a data distribution platform for making network rendering more interactive. In order to assure that the data in the scene is identical on each node, we make sure that the setting for scripts/drivers being executed is matched on all the computers that are active in the user’s session. We currently use bpy.app.autoexec_fail to tell what choice the user has made as to whether they want their scripts and drivers to evaluate.

With the flag removed, we can no longer introspect this choice from the user and we’d have to likely always enable scripts/drivers for nodes running the user session. This is not ideal as often this will cause the nodes to return a rendered image that looks very different.

So I hope you can return bpy.app.autoexec_fail, or at least provide a method through which we can inspect if the user has chosen to evaluate scripts/drivers in the blend session on their local machine (i.e. where the blender ui is run, the other nodes run blender in background mode).

We currently have about 3000 user accounts, and its growing so we’re hoping we can keep bpy.app.autoexec_fail or find a workaround in 2.8. We’re already getting requests for us to release our 2.8 compatible version of the addon which we’ve demo’d, but we’ve held off due to changes like this which break compatibility until we find a workaround.

Thanks again Brecht!

Hi @brecht hoope you are well man :slight_smile: Also hoping that before the beta is released next week, the bpy.app.autoexec_fail could be added back in?

Also today found that C.user_preferences.inputs.select_mouse has gone, this wasn’t mentioned anywhere in https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Python_API.

So, has the select_mouse attribute been deprecated or just moved? Also can you advise if there is any other page out there on the web where I could read on the changes that are breaking our addon? So far none of the things that have affected us were on the site mentioned above until after we’d fixed the problem, except of course in the case of bpy.app.autoexec_fail!

Thanks!

I’ve restored bpy.app.autoexec_fail. Note that if some scripts did not execute and it has a visible effect on the render, then the render is almost certainly wrong. It’s unlikely for users to have scripts in the file that they intentionally do not run.

I can imagine this being used to validate if a file can be rendered without scripts, if there are workers that do not allow running arbitrary scripts for security reasons.

1 Like

The release notes and API docs are the only information:
https://docs.blender.org/api/blender2.8/

The release notes mention the most common updates needed for addons, but listing everything would make them extremely long.

For left/right click select, each key configuration now has its own set of preferences (wm.keyconfigs.active.preferences). This may include left/right click select, or not.

3 Likes

@brecht Awweeeesssoommme! Thank you so much :smiley: I can’t begin to describe our relief! I’ll take a look at the new keyconfigs pretty sure we can repair that problem in a snap if the property has migrated there.

1 Like

Brecht, a suggestion for the new Python annotations for bpy properties…

I’ve been porting appleseed over to 2.8 One of the things we do is dynamically create our nodes at startup. So we create variables by using ‘type’ and ‘setattr’. I’m getting a number of “class X contains properties that should be an annotation!” warnings for the node socket classes at startup but everything appears to load properly. Is there a way that the name of the property that is triggering this warning can be printed? That way I can tell if it’s a legitimate issue or a bug.

FYI the node also contains some straight Python variables (i.e. not bpy.props) but the warnings still appear even when these are changed to annotations as well.

Hi @brecht and @ideasman42 firstly congrats on the beta being out :), we’ve been running our addon with the beta today and its working well, at least on windows :D.

I just wanted to know, from here, will there be more python api changes? If there will be, will the beta change daily, or will the changes be bundled into patch updates?

This would be helpful to know since we’ve held off releasing the 2.8 compatible version of the addon due to the daily builds for 2.8 changing a lot. If the beta will change daily, thats fine, we’ll probably hold off still until the full release next year, but if it is going to be stable, that would be awesome to know about!

Thanks!

James

It’s all explained here:

2 Likes

It looks like the API features for custom transform orientations have changed. If anyone has info to share about this, it would be appreciated. Trying to fix this currently:

custom_orientation = mathutils.Matrix(
[
[vcross[0], vnorm[0], vdest[0]],
[vcross[1], vnorm[1], vdest[1]],
[vcross[2], vnorm[2], vdest[2]]
]
)
bpy.ops.transform.create_orientation(
name=‘MAPlus’,
use=active_item.apl_use_custom_orientation,
overwrite=True
)
bpy.context.scene.orientations[‘MAPlus’].matrix = (
custom_orientation
)

Also, trying to troubleshoot this issue with bl_idname renaming, it seems to adhere to the new prefix/suffix rules, not sure yet what the issue is:

RuntimeError: Error: Registering operator class: ‘ChangeTypeBaseClass’, invalid bl_idname ‘MAPLUS_OT_changetypebaseclass’, at position 0

Update: Just got a NEW error message for bl_idname issue, are dots still required? I don’t remember seeing this in the API change notes:

RuntimeError: Error: Registering operator class: ‘ChangeTypeBaseClass’, invalid bl_idname ‘changetypebaseclass’, must contain 1 ‘.’ character

I believe there was an old requirement that bl_idname values should have at least 1 dot. This is no longer the case, correct? I am currently tentatively assuming that this is a bug with the bl_idname validation/checking…

I posted about this on SE here:

I’ve found this small thing here:
https://wiki.blender.org/wiki/Dev:2.8/Source/LayersCollections/API-Changes

-context.scene.objects
+context.render_layer.objects

It should be view_layer instead of render_layer.

Currently, it works until a new keymap is created and active… Is it safe to use
wm.keyconfigs[0]
to fix it, instead of
wm.keyconfigs.active.preferences
that is broken since new keymaps have no “select_mouse” property?
Will the “select_mouse” property always be on the first keyconfig?

Thanks.

This is what bundled add-ons do:

keyconfig = wm.keyconfigs.active
select = getattr(keyconfig.preferences, "select_mouse", "LEFT")

Accessing wm.keyconfigs[0] does not make much sense since its preferences have no effect if another configuration is active.

Thanks but there’s an issue, or maybe it’s just me?

wm = bpy.context.window_manager
keyconfig = wm.keyconfigs.active
select = getattr(keyconfig.preferences, "select_mouse", "LEFT")
print(select)

Returns ‘RIGHT’ when using the default keyconfig and select set to right.
But, it returns ‘LEFT’ when using a new/imported keyconfig, while select is still set to right.

Actually it does, only the default keyconfig has the mouse input parameter. Switching to other configs remove the mouse parameter from display, and still use the default one.

I’m quite sure it does not have an effect. If you use a custom key configuration, the left/right choice will be baked into it.

Then why does is print “LEFT” when it’s actually set to right? Please see the message above.
Sorry if I’m missing something but this is a bit unclear… Currently I don’t see any way to access the actual value when using custom key configs.

For whatever it is worth, I would like to mention an add-on, which will detect syntax and functions which needs to be updated: https://github.com/tin2tin/Update_Check_2.80

3 Likes