Fix (unreported) usercount of linked IDs becoming garbage after undo/redo.
Not re-reading linked data-blocks in undo/redo case also means that we do not touch to their usercounts. Even worse, lib_link process in readfile will increase those (for cases where local data uses linked one). Whole data management code is now heavily relying on valid consistent refcount of all IDs, so we cannot allow that anymore. Simple solution here could have been to then not increase that one for linked IDs in `newlibadr_us()`, but unfortunately that would not be totally bullet-proof, as some local users of linked data may be added or removed by an undo step... So I cannot think of any other solution than the ugly brute force one, i.e. going over the whole Main database and recompute linked IDs users count... Should not be a big issue performance wise though, this is fairly cheap process.
This commit is contained in:
parent
3600e94eba
commit
3a702ec028
|
@ -8790,6 +8790,15 @@ BlendFileData *blo_read_file_internal(FileData *fd, const char *filepath)
|
|||
|
||||
BKE_main_id_tag_all(bfd->main, LIB_TAG_NEW, false);
|
||||
|
||||
if (fd->memfile != NULL) {
|
||||
/* In undo/redo case, we do a whole lot of magic tricks to avoid having to re-read linked datablocks from
|
||||
* libraries (since those are not supposed to change).
|
||||
* Unfortunately, that means that we do not reset their user count, however we do increase that one when
|
||||
* doing lib_link on local IDs using linked ones.
|
||||
* There is no real way to predict amount of changes here, so we have to fully redo refcounting . */
|
||||
BLE_main_id_refcount_recompute(bfd->main, true);
|
||||
}
|
||||
|
||||
lib_verify_nodetree(bfd->main, true);
|
||||
fix_relpaths_library(fd->relabase, bfd->main); /* make all relative paths, relative to the open blend file */
|
||||
|
||||
|
|
Loading…
Reference in New Issue