We do not handle user support on this tracker, only bug reports. User forums like blenderartists.org or blender.stackexchange.com should be used for that matter.

This is also triggering when you try to link some datablock! very bad handling, fix is incoming.

Can you try to launch blender *from* cmd commandline window? That way, console will remain open after the crash and you'll get full error report.

Thanks for the report, but unfortunately supporting advanced scripts like those is currently not a high priority on our list, since it would require a rather huge effort to integrate relevant tools/libraries in Blender... A patch would always be welcome of course. ;)
As a workaround, typing in a real text editor and then copy-pasting into Blender should give valid results (i.e. keep the result of the complex matching operations).

Just did quick check on the library management/DNA side of things.

LGTM

Hey,
so group objects are not reordered on read file, but according to Dr @Sergey Sharybin (sergey) bloody depsgraph can reorder them at some point. This is sort of can of worms, and probably not worth spending too much time on it since it will be fixed in 2.8 by CoW (i.e. depsgraph will no longer ever touch to actual DNA data).

OK, second issue is caused by addition of check for too small normal vectors (which typically indicate degenerated cases, and are hence 'reset' to default vertex normal). Think 1e-4f is a bit of an aggressive threshold actually, reducing it to more common 1e-6 value seems to fix reported issue and should probably still be OK. Will commit the change (rB2da3949e26f), thanks again for the feedback.

Thanks for the feedback, fixed the first issue already (easy stupid one, rB3b01edd52e8e).

Your MO (or PO) file must be broken somehow, you have to check on messages from gettext tools when you build it. But am afraid we cannot help further here, that is not a blender bug.

@Philipp Oeser (lichtwerk) said everything, this is obviously not a bug, FBX cannot handle all possible kind of broken cases... Also, please note that this tracker is not a supporting tool for users, you should check that kind of issues on user forums first to ensure whether this is actual bug or not. ;)

This is something that should be done by the addon's author (@Campbell Barton (campbellbarton) ;) ). Not a bug at all though, mere TODO, but will let him handle the report fro; here.

Please do not reopen three years old reports, and do proper report, with *simple and easy* reproducible case, not full complete production file.

Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.
Videos and/or links to external sites etc. are not acceptable as bug report (they can be provided as additional information only).

Issue is not actually with exporters at all, that file will break pretty much any python code accessing the faulty ID name (first one is a material here, which has invalid utf8 byte in its name).

In D3113#73998, @Campbell Barton (campbellbarton) wrote:

In D3113#73997, @Bastien Montagne (mont29) wrote:

Only did a quick skim on the patch, it’s a bit too big for detailed review. Overall I like a lot the new system, much cleaner and generic than the old one too.

I wonder, in the xxx_undosys_step_decode() functions you often switch to Edit mode, and then take edit object from undostep… Are we sure current edit object will always be the same as undostep one?

If the undo system is working, yes. But agree this is a weak point especially if users are switching workspaces/view layers in 2.8x, its possible screen data causes different objects to be active when the undo step decode runs.

This relates to a TODO (after merge): "ideally we would use lower level functions to create necessary data".

What should be happening is a lower level function should create edit-mesh data from the object stored in the undo step (we will need this for multi-object edit anyway).

OTOH, Hjalti has been using this patch since yesterday and not reported any issues.

Only did a quick skim on the patch, it’s a bit too big for detailed review. Overall I like a lot the new system, much cleaner and generic than the old one too.

Yes, agree that CoW should make that kind of issue history, so let’s wait and hope for the Mighty CoW! :)

@Sergey Sharybin (sergey) It’s hard to be sure of anything, especially since I cannot reproduce the issue anymore currently. But, reading ASAN report from initial post:

@Dalai Felinto (dfelinto) I will do that yes (though I could not reproduce crash with current blender2.8 anymore… go figure).