The code this was taken from assumes a 'size_t' result,
which isn't the case here.
In practice the bucket distribution wasn't bad,
even so this was a nop so best fix.
Looks like we need to explicitly set i18n language to default value on
some OSs... Unless that 'need to create new translated-name IDs in
versionning code for startup file' situation is really seldom.
Anyway, hopefully that will fix the crash.
This is to solve an issue where a blend file could be compressed
unbeknownst to the artist. This happened in the following situtation:
- Artist edits an uncompressed blend file.
- Some script saves a compressed blendfile to a separate location.
- When the artist saves the file (s)he is editing (File>Save, or Ctrl+S),
it was silently compressed.
Cherry pick from: cd3b313d5f
This is a bug experienced by animators in the Blender Studio that developers
have been trying to fix for a /long/ time.
What happens is that partial file writing extracts the needed datablocks from
the main list of datablocks into a smaller one. Afterwards they are added back
to the main list, but in some cases not exactly in the same order.
There is file path remapping code that depends on the datablocks being in
exactly the same order as before, and when this was not the case filepaths
would get swapped between datablocks
The reason datablocks are not restored in the same order is because the sorting
of datablocks by name is a) case insensitive and b) undefined if there are
multiple datablocks with the same name from different libraries. This should
be made well defined, but the fix in this commit is simpler.
The way animators ran into this bug is that they use the Copy Attributes addon
a lot, which has as the first item in the menu Copy Selection to Buffer. In
some cases this would be clicked accidentally when menu is near the edge of the
window, breaking the library paths which would only be noticed a much later on
file save and reload.
The way this bug was finally tracked down is that it was suspected that the
undo system was the cause, and so Bastien added library validation for undo.
When Hjalti then did undo and noticed the error, he remembered accidentally
clicking Copy Selection to Buffer just before, and we could finally reproduce
the bug.
There are serious suspicions that weird corruptions faced by studio
artists may happen in undo/redo code, so let's see whether that's the
case.
With this, and when --debug-io arg is passed on startup, the whole lib
data are checked at every undo. This makes undo slower (from two to
three times slower), but it could help us spot better what happens...
At least on windows we do not re-run datatoc when the .glsl files change.
To test is simple, just change edit_mesh_overlay_common_lib.glsl
remove lines, write plain text, ..., now rebuild and go in edit mode
with the default cube.
I also had to remove the entry in gpu/CMakeLists.txt for
gpu_shader_material.glsl since this was being tracked directly, as well
as running data_to_c_simple (otherwise CMake raises an error for
duplicated entries).
We probably want to do the same for the other datatoc functions.
Reviewers: LazyDodo, brecht
Differential Revision: https://developer.blender.org/D3803
I think there are two possible ways to fix that.
1. Make the name a required parameter.
2. Provide a default value.
I choosed option 1 in this fix to be consistent with other .new functions.
Also I think `RNA_def_string` instead of `RNA_def_string_file_path` should be used here. Looks like a copy-paste error.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3728
The default compositor node update function sets the need_exec flag on the node
which the Auto Render feature checks, but the custom update function that was
added as part of rB4cf7fc3b3a4d didn't do so.
Therefore, the two custom update functions that were added now also call the
default update function.
