Campbell, I believe it is one of these commits that caused the issue (I think the more recent of the two, but can't recall for certain.)

In T47811#445375, @Campbell Barton (campbellbarton) wrote:

@john peterson (bliblubli), this isn't enough info, are you interested to create a task that includes proposed changes? (something like T51219).

Displaying the path automatically in tooltip is not supported yet (it's an old to do, see e.g. T25746). However the properties are accessible:

bpy.context.scene.render.layers[0].cycles.use_denoising

Thanks for the suggestion, but we do not accept feature requests or suggestions on this tracker (use forums or bf-funboard ML for that).

Thanks for the report, but we do not support very limited platforms like raspberry pi at all - those are considered as waaayyyyyy to limited to run a modern Blender.

PointerProperty is not supposed to work in Operator at all (technically, we have no 'runtime' definition for Ppinter RNA property type).

I updated the documentation to describe the reason for this behavior, the numbers must be powers of two:

Thanks for the suggestion but the naming is still being discussed see T43623 so I would rather not make noisy commits until this is finalized on.

Half way there:) Press the continue button and fill up the title and the summary fields and create the differential.
You don't need to assign any developer as reviewer if you are not sure who to add.

Differential at https://developer.blender.org/differential/diff/9010/ please let me know if I should add it somewhere to this task.

For submitting patches to blender please consult this page:
https://wiki.blender.org/index.php/Dev:Doc/Process/Contributing_Code

I already provided a unified diff. Please tell me what more to provide!

Please can you make a differential for this patch?
Add a small description explaining the purpose of the proposed changes. After possible approval / code review it can be included in future versions (2.80 series) since we are really close to 2.79.

@john peterson (bliblubli), this isn't enough info, are you interested to create a task that includes proposed changes? (something like T51219).

As suggested today on IRC, making robust naming conventions for bmesh operators would help new coders to jump in. It will be very helpful for making the nodal everything work faster. At the moment, the use of for example underscores is pretty random. Having easy to search names will give more time for real coding.

The value is used, this is more of a documentation issue, committed edit.

Thanks for your precision

As mentioned above, UI is launched but is not being drawn at the time when your script runs.

Thanks for your answer but, forgetting "--background" option (1st and 2nd "NOT working" cases), why are these commands not being able to a take valid screenshot since the UI is launched and can be modified by my script as you can test if you uncomment corresponding lines (so the OpenGL buffer should be readable as you mentioned, since Blender is not started in background) ?

The warning is caused by script trying to trick the system and override the context, that context is likely in inconsistent state. When running screenshot from the interface you don't need to override any of the contexts.

Actually I don't have tested it, I also don't have experience with the buffer protocol and if there are no other issues with it.
Did you have tested the buffer also with some of the other bgl function calls like glTexImage2D()?
Does slicing the buffer still work?

Thanks for the report, but no bug here, python API is designed to be efficient, not to protect the developer against himself. There are billions of ways of generating a corrupted mesh from python in Blender, it's up to you to do valid things (and you can always also use Mesh.validate() method in case you do not trust your generated geometry for some reasons, e.g. when importing from other formats).

Perhaps the best option is to write an external tool: a very simple stand alone program which can normalize all the weights and save to a clean fbx file. This way we would avoid polluting blender and we would not be limited to python. We could even use the autodesk SDK (need to check their license though).

I don’t say trying to fix those stupid weighting is bad or wrong, I say that doing so by only normalizing on a per-vertex basis is wrong. With your code, a set of weights for three vertices like that ((0.1, 0.5, 0.2), (0.2, 1.6, 0.2), (3.0, 2.4, 0.6)) would be normalized to something like that (if I followed your code correctly): ((0.1, 0.5, 0.2), (0.1, 0.8, 0.1), (0.5, 0.4, 0.1)). On set of weights remain unchanged, while the two others are scaled by different factors - you end up with vgroups totally different from input ones, not only uniformly scaled, which imho is not acceptable in general. That’s why I said 'scale them all by highest weight found', and you are done. If people want to normalize their groups afterwards, they can do it - but it should not be done silently by default, and certainly not while letting some unnormalized.

In D2713#64090, @Bastien Montagne (mont29) wrote:

In D2713#64089, @Paolo Acampora (pkrime) wrote:

Hello mont29, thanks for looking into this

In D2713#64077, @Bastien Montagne (mont29) wrote:

This won’t work that way… Main issue with this patch is that it ignores weights below 1.0 (so they won't be scaled accordingly when bigger ones are).

All weights are scaled in the latest block (line 2189). No need to store weights below 1.0 in the dictionary, as no information is lost when we assign them to the vertex group

Hello mont29, thanks for looking into this