No real reason we keep this only to copying, creating ID outside of
database is handy as well!
Also, add helpers to add/remove an ID from Main, and to set/clear its
'user refcounting' status. Those will be useful in future complex ID
manipulation cases (like static override...).
Not much happy, have to include BKE_curve in BLI_freetypefont to copy
nurbs... Not sure why fonts are in BLI tbh. We are already replicating
quite a bit of nurbs logic there. :(
Those are not actually copying the ID, only its internal subdata (and
other ID-specific handling). Generic processing common to all ID copying
is done by `BKE_id_copy_ex()`!
Makes things much simpler, and more consistent.
Also fix issue with new copying and bloody nodetrees, using same hack as
in original ntree copying code to detect 'root' ntrees that shall never
be put into bmain :(((((((
Note that those are an nightmare to handle correctly, current code is
like a plate of noodle, so... most likeley not fully working, think I'll
have to nuke localize code as well :(
(continuation of previous WIP commit, sorry about that one :/ ).
This commits changes quite a few things, distributing new copying flags
into sub-data copying code (mostly concerns ID refcounting or not).
It also removes ID refcounting handling from Modifiers' copy callback
(this was ugly from the start, proved to be problematic in current
master, and generally bad practice). This is now done by calling code.
Also, it brings back ID refcounting handling to main BKE_library's copy
code, which means in generic ID copying lower-level IDType-specific copy
code should not use it at all. Support at lower-level remains needed
though, unfortunately, to cope with partial copying tools etc.
It tried to assert that
addons/io_blend_utils/blender_bam-unpacked.whl/__init__.py was loaded when
the io_blend_utils module was imported. However, this happens only on
demand, and not directly when importing the add-on.
*Sigh* One more example of why we should keep ID management handling in
as few places as possible! It's impossible to keep more than a few
places in sync regarding which ID pointer is refcounted etc.
Children where always getting at least one segment of fixed length...
Now fully hidden ones (zero length) get no segment at all.
Note that even very short ones keep getting one 'unit' length segment - would
rather avoid changing that at this point, given how complex children
particles 'length' can get with all kind of modifiers... Think we can
live with that for now anyway.
The crash did not happen yet because we always had proper vmemh defined in
the parent scope.
Patch by Ivan Ivanov (aka obiwanus), thanks!
Differential Revision: https://developer.blender.org/D2715
Idea is the same, looks like it will be a tad simpler than with copy
though, since we should not need to change each ID type freeing func, as
ID usercount handling is done in main BKE_library code (would like to do
that for copy as well, but it's not that simple).
