I would be happy to give an example of how to transfer the coordinates of a real object, rather than enter them manually.
https://docs.blender.org/api/blender2.8/gpu.html#wireframe-cube-using-index-buffer

Thank you for providing an fix for that issue.

I have updated my Blender to yesterday's version and am unfortunately still having the same crashes.
I also updated my sample code in the first post, seems I deleted too much code when I was simplifying it. I am very sorry for that.
It should work (or rather crash) as intended now. I even added a small panel for convenience's sake.

I cannot reproduce this in the current build. Please check if the issue still exists.
If yes, then please start Blender from the terminal and post the output here.

Ok. Thanks for Your help, and sorry for posting it here.

thanx @Bastien Montagne (mont29) for clearing that up! (sorry for my uneducated fiddeling here...)

Thanks again!

First of all, this is not a bug report at all, and should not be handled here. We have a site for that kind of question: https://devtalk.blender.org/

I can only repeat myself: I am on shaky ground here, if the above file doesnt work for you, I am probably out of ideas...

Sorry, Your blend file was not empty, my mistake. But the error still occurs.

Not sure if this is the recommended way, but picking a region type for your spacetype that doesnt draw panels automatically seems fine, I guess...
So for space TEXT_EDITOR, you could use bl_region_type = 'HEADER', bl_region_type = 'WINDOW'?

This .blend file You attached is (as far as I know) default init blend file, so I can't check what You have changed. Please attach the changed .py file.
I followed Your directions:

• I removed enumerate (It was there for testing purposes anyway), but this did not solve the problem.
• I assume that Your step 2 was passing 'deepcopy(branch['sub_items'])' instead of ''branch['sub_items'] into the recursive function. It did not solve the problem for me (did it for You?). Please remember that (like I wrote in the comments of my py file) calling operator again does not replicate the error: "I have to restart blender to repeat the error". And after that changes error is still there. Also, the problem from Your link is little different from mine, because my problem is with 'current_item' variable (not with ''branch['sub_items']"). I am not passing 'current_item' to the recursive call, and as far as I know my current_tems variables from every scope point to a different object, coz I create it in the scope, not passing it as a parameter.

Regards.

Thanks! layout.popover() seems like exactly what I need.

Can confirm the crash (when accessing/printing the current_item after the recursive call)

?

Oki, closing then

I think this is just a limitation of the menu system. For more custom layouts, use a popover.

Menus are a bit limited in regards to layout.
I dont have an exact list of these limitations (I just remeber I had an issue in D4215 as well).

I think this isn't worth worrying about, we could use from __future__ import print_function all over for our utilities, but in practice we never had people adding back old style print statements.

The future import makes legacy print statements syntax errors even in Python 2 which prevents Python 2 developers from making changes which break Python 3 compatibility.

Committed rB7262ac6202eb9258293473f35a24f375f9d6f635, no need for __future__

That was probably a bit too quick on my side, need to look at that again (on Monday)...

I regret to write: it is not it :(.
I changed init to sub_init and I steel get TypeError: unsubscriptable object.

I couldn't check that the bake result is correct. Yesterday's daily build crashes upon clicking the image dropdown menu in Image editor or UV editor. That's an unrelated issue, and I'll wait a day or two before reporting it.

Cool, it seems to be fixed in current daily builds. I close my bug report as resolved.

RNA_def_property: runtime property identifier "TreeItems.items" - this keyword is reserved by python

@Campbell Barton (campbellbarton) Thank you :), just downloaded the latest 2.80 beta directly from blender.org and so far, all working well. Thanks again. Can't overstate how grateful we are.... and relieved too. :)

Committed basic undo system support in background mode: rB3d16a268ee688da25f72a1adb08fdaab454c344d

Is this still an issue if you use the latest intel drivers?

I'm getting the following assert when changing the properties:
BLI_assert failed: blender/source/blender/depsgraph/intern/depsgraph_query.cc:145, DEG_get_evaluated_scene(), at 'scene_cow != __null && DEG::deg_copy_on_write_is_expanded(&scene_cow->id)'

I also take copies of objects. I then, among other things:

@Jeducious (jameshcrowther), updated P563 although this should be documented.

I maintain an exporter add-on which messes extensively with the scene during export, then uses undo to clean everything up. Now that undo is unavailable in background mode junk objects are leaking out everywhere. I don't think that many users of my addon are running it in background mode...but *I* am for my unit tests, and those directly affect the quality of the addon.

In T60934#614228, @Campbell Barton (campbellbarton) wrote:

Hi @Bastian Neumann (bneu), this is mostly a question of priorities since there are enough high priority undo bugs open which need attention, see: T61045

2.79b also didn't properly initialize undo, eg: wm_files.c

	if (!G.background) {
		BKE_undo_reset();
		BKE_undo_write(C, "original");  /* save current state */
	}

While it didn't crash, it wasn't fully working either.

This is something to look into, if we should have basic memfile undo support in background mode, or add the ability to fully initialize undo.

Some context for how you're using this feature in 2.79 would be helpful.

---

I commented about this on the thread that explained how to use it, but no one ever replied to my comment that it wasn't working.

Could you link to this post?

@Jeducious (jameshcrowther), can you briefly explain what you need undo in background mode for? For memory usage on render nodes being able to save memory is quite important, and now might be a good time to make such a breaking change. However there may be solutions to handle both cases.

Note that there is a replacement for scene_update_post in the form of depsgraph_update_post and the new timer API.

Hi @Bastian Neumann (bneu), this is mostly a question of priorities.

@Philipp Oeser (lichtwerk) still planning to look into this?

Is this still an issue with 2.79?

1. You're correct. I changed it to tuple and no there's no error after that. Thanks for correction. I didn't know ordering issue with sets. New learning today :)

@Jeducious (jameshcrowther), can you briefly explain what you need undo in background mode for? For memory usage on render nodes being able to save memory is quite important, and now might be a good time to make such a breaking change. However there may be solutions to handle both cases.

I found two problems in the code.

Find source code below (video is recorded with following source code only)

I've respectfully request that this bug be fixed so that the undo system will again be usable in background mode allowing the crowdrender addon to function. Crowdrender is one of the most important addons for our company.

hold on, or should we pass the evaluated object here in the first place?

Can you share a small complete example that we can use to reproduce the issue?

Here is registration code (snapshot)

Yes... I registered RenderLayersToInclude before ConfigCreatorOperator

bandaid:

Did you register RenderLayersToInclude before you registered ConfigCreatorOperator?

@Campbell Barton (campbellbarton) I can appreciate the reasoning you gave for not reinstating the undo stack in background mode. However, I respectfully request you reconsider. For one, the change that we're talking about was never mentioned in the API. Yet you mentioned it is an intentional change. That change has now given us a major redesign task to make our addon compatible with 2.80 that we were not expecting and it would be fantastic to have more time to adjust. Given time we can work around.

Raise an error instead of crashing, closing rB1b7c361fbb320744e6b7cc0c03b5f850e8fbfd9e

Not using the undo stack in background mode was an intentional change.

@Brecht Van Lommel (brecht) @Philipp Oeser (lichtwerk) @Campbell Barton (campbellbarton) Thanks guys :)

@Brecht Van Lommel (brecht): Sorry, was blinkered by T60684 all day :/

@Philipp Oeser (lichtwerk), did you find the commit?

That seems fine, I guess we can just link to the OpenGL reference docs for each function.

Hmm, I could do it but it does not feel like it is worth it.
Maybe we should just link to http://docs.gl/ and mention how bgl differs from the C functions.
I guess the main difference is that bgl.Buffer has toused as parameter instead of a pointer.

Maybe it was generated at one point, but I can't find anything about that in git history.

@Brecht Van Lommel (brecht), is doc/python_api/rst/bgl.rst all handwritten, or is it generated?

Can confirm, bisecting...

These functions are no longer available, it is the documentation that needs updating:
https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Python_API/Draw_API

I can't seem to reproduce this issue. Could you see if you still get this with the latest blender beta?
IIRC there has been some fixes to cycles baking.

I agree, we need better docs for this.

Brecht, your suggestion works. Thanks for the input!

Ok but how are Python addon developers supposed to add active tools then?

Well that's good that it's not a bug. This should be mentioned in the Python API section of the release notes. For addon devs like me there is no mention that you need to use the engine to set the frame now instead of the scene. Then I waste you guys' time posting reports on bugs that aren't bugs.

For rendering, use engine.frame_set() instead of scene.frame_set() to change the frame.

Here's a stripped down version of the render plugin. Instead of exporting items it just prints matrix_world

The documentation you've linked works for a "built-in" nodes. Currently python nodes do not support muting. This can be annoying for some usecases, but lack of functionality is not considered a bug and should be handled outside of the bug tracker.

Thanks Philipp. I’ll get a scene and mock-up to you later today

I can confirm that the widget shows up but you can no longer manipulate it if you have the addon enabled on startup.

Just to make this a little simpler for everyone looking at this: