Hiding edited object has never been allowed, no bug here, this is expected behavior.

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.

Our asserts by default do not error, only print the warning, autotest has nothing to do with that… There is a switch to actually abort on failed asserts iirc, could be useful to enable it for testing (can't remember exactly how, build option, envvar, …).

Am not sure what to say here… Yes, file is totally corrupted re libraries, no idea how this happened, and would need precise steps with basic simple files to reproduce such situation to go any further.

Indeed, there’s nothing we can do here, there is no regular FBX material stored in that file. We only have a big blob of binary data that could be pretty much anything, and mysterious material indices, but no material. So afraid we cannot do anything here.

Not strictly speaking a bug, but annoying for docs indeed, will fix.

that’s not what I’d call 'simple file'… :/ Did you try to reproduce the issue with very basic set of files (mere cubes groups...)?

Sounds like someone has been messing with order of datablocks during file save or reload… But as always, need simple .blend file to reproduce and investigate.

yeah, must be new ways of not exposing py-registered classes in bpy.types ;)

Yeah, thanks @Sergey Sharybin (sergey), that was also my understanding of things.

Bah… yet another mismatch between rendering data and regular scene update data, here there are less child particles for rendering (5) than for 3DView (30), so when rendering data update process (re-)allocates memory for 5 children, but then regular scene update, which happens in parallel, tries to use that allocated cache for 30 children, it obviously breaks…

Yes, think we can archive for now.

Funny fact: if you switch source mirrored object to WeightPaint mode, it will work as expected.

That FBX file has two issues from Blender POV: unsupported Normals mapping (by polygons), and invalid material indices. But importer knows how to work around that to some extent.

Note that rB9591b5f6182f is tentative fix (based on @Germano Cavalcante (mano-wii)'s work), if one of you guys could confirm it fixes the issue would be great. ;)

Uh… good point didn’t thought about that kind of concurrency issue :P

This smells like threading issues again, pretty sure running with -t 1 option is enough to get rid of the crash?

Cannot confirm that here on linux64, with a debug build of current master… can you check if you still get crash with the latest build from our buildbot?

Thanks, got the mail now. We'll check on it asap.

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

Set it to 5 digits, like e.g. for location.

Thing is, new code now always show same amount of significant digits - 3 in case of unit display by default. Previous one was showing from 4 to 6, will check on bringing one more, but it really does not makes much sense to show more in units display imho…

Check our reporting rules, one of them is 'one issue per report', and collada and FBX are definitively totally different issues. We cannot manage confusing reports, handling god ones already eats tremendous of time not spent on actually coding new useful stuff for Blender…

Making a report about 'import/export in Blender' is utterly confusing, all exporters handle data in different ways, since not a single file format shares same material capabilities. Please try to be accurate, and talk about a single issue per report.

@Sergey Sharybin (sergey) no idea really why that intersection algo was chosen, would bet it was best available in our code at the time. ;)

Think this fix is simple and safe enough, not ideal to expose that kind of advanced stuff to python, but on the other ends render engines are doing rather advanced stuff, so guess we cannot really avoid it.

Ok… still, don’t think that was a good idea, like, at all… ID types are not virtual stuff like operators or render engines, they are data, stored in Blender file, they are kind of root of everything in Blender, so faking their subclassing in py sounds like a nice can of worms to me… Would have been so much cleaner to have registrable NodeTreeType classes instead! Anyway…

@Sergey Sharybin (sergey) yes, but… wait… since when is it valid to subclass an ID type? Subclassing ID types in Python… who ever allowed such an evil scheme? :((((((

pfff… no actually, you nailed to point @Brecht Van Lommel (brecht)! I probably need to wake up a bit more here :(

Wooo… ugly! :/

Thanks, let's see what our Cycles experts have to say here.

+1 for using lib->id.name instead of lib->name, that was my main concern (due to length) when first read the patch. Can’t see anything else bad here, so patch LGTM.

Yeah, antivirus would be prime suspect here…

Thanks, fix shall also be in 2.79 released today, so we can consider this as fixed I think. :)

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

Am sorry, but we cannot do anything here, blank file is… blank file (filled with only zero bytes). That kind of corruption is most likely an issue at OS level, or something else - but in any case, unless you can provide us a reproducible way to generate such void files from Blender, we cannot do anything.

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

This is actually the same issue as the one I fixed months ago for vertex particles… And same fix applies.

Crash clearly comes from FFMPEG (avcodec is part of this). Blender comes with its own ffmpeg, which seems to be used here, but my bet would be that it somehow interact with libs installed by K-Lite stuff, so would suggest you try to uninstall it (or maybe simply re-install Blender), and see if it fixes things.

Pretty sure this has been fixed already, cannot replicate in current master nor in current 2.79 branch, to which a serious modifiers-related crasher was backported after 2.79 RC2 was published.

@Lukas Stockner (lukasstockner97) I guess you'll know whether this was already fixed or not? If yes, can you please also check commit is in 2.79 branch? Thanks

I think Flip names does what it should do currently - flipping names, not trying to change names to match (and usually fail in all but simplest cases) some mirror pattern.