Just a poke regarding my inquiry above, otherwise we will have to archive this for now.

Yes, this used to work: http://members.iinet.net.au/~ideasman42/random/facemap_28.ogv

Has this worked in previous versions btw.?

Has this worked in previous versions btw.?

The problem is caused with value variable from:

Will dare setting this to High Prio since we are basically shipping a broken template script.

I've updated the release notes now. In order to conveniently convert to/from sRGB we need some API functions, for which I added a patch.

I talked to @Brecht Van Lommel (brecht) and it seems that this is intentional. I think we should mention this in the release notes of whenever we introduced this (with an example of how to convert the values from one to the other?). I couldn't find it in any of the 3.x release notes so far.

This was an intentional design choice. For attributes I wanted to have all color values in the same linear color space in the API and UI, regardless if they are stored as byte or float. That way the values match in color pickers, spreadsheet, shader nodes, geometry nodes.

Setting status to confirmed, but not setting as a bug yet. Waiting for Hans to confirm it.

Why BF Blender 2.90?

The report should contain exact steps to redo the bug (script, blend file etc).

See feedback about switching last_line_inserted to an integer.

Changes based on review feedback:

Not sure if there is still progress?
In any case, I will step back from reviewing, thx anyways.

Indeed the warnings are rather annoying. But I think the real bug is that since 3.0 all the Node Editors show the "Group" tab. I don't think this option should be there. So there is no way to create the new sockets anyways. (what is the point of creating them even?)

According to @Lukas Toenne (lukastoenne) in T90233:
"The warning current value '-1' matches no enum is because when loading the file the script for defining the custom tree hasn't run yet, but the node editor still has the tree loaded. Nothing to worry about."

Thank you for your report. Unfortunately, it does not contain the requested information that we need to investigate the issue. Please read this guide, it may help you write a bug report that allows us to identify the cause of the problem.

import bpy

Yes this has been fixed, closing.

Bug confirmed in Blender 3.01 hash dc2d18018171

Thanks for the report. Marking this as known issue since it depends on the old particle settings which is end of life.

Mantaflow (fluid simulator) has no active developer at the moment. Moving those reports as known issues so at least other users can find their issues already reported.

Same issues here, and searched in google lead to this page.

In T97909#1353217, @Philipp Oeser (lichtwerk) wrote:

Can confirm.
Looks like this was once working in 2.80 (but has stopped working in 2.81)

Could it additionally be related to T93987?
So mute vs enabled?

Can confirm.
Looks like this was once working in 2.80 (but has stopped working in 2.81)

Closing as code_from_builtin has been removed as of rB3e98331a094b0bc7f6bf8d386e610e06bfa4e61b.

The changelog generator needs to be run manually. The main reason this wasn't automated is you need two different versions of generate output, although if we kept the previous releases output in a fixed location we could compare against that which will work as long as the file format doesn't change.

@Campbell Barton (campbellbarton) , @Bastien Montagne (mont29) : do you know if this was done by hand?

These were intentionally removed which should have been noted in the release notes, updated This was an intentional removal, in general Python scripts did not use these events much as they are never sent to modal operators.

This is a limitation of the internal implementation of Image/ImBuf relationships...

With 'USE_INSERTION' you can add new items to the override collection prop, but if you save and reopen the file, the items are not saved.
You can try it with the addon "Selection Sets".

@Julien DUROURE (julien) I'm closing this task, because the command from the original report clearly does not load the supplied .blend file and the default cube does not have an image texture, thus it is not found. Thus, the problem is with the command line parameters, not the script or Blender.

@Campbell Barton (campbellbarton) Since you are closing this instead of improving the "intelligence" of the triangulation could you tell what the intended workaround for this problem is? How could we "guide" the algorithm to achieve the desired result and resolve the disambiguation?

Confirmed, although the exception isn't lost, it just excludes the file & line number.

Great! :)

Thanks, good idea. I did that here: rB891268aa824f0fcaf54f56b3a8640a78282552d8

Can confirm.

Closing this report because this is a case where both results are acceptable as the edges are co-linear once projected into 2D.