Thanks for taking a look, I'll download the beta.

In "other applications", i.e. in a file browser, with situation as presented, a selection would've been made from the bottom torus to the top. Instead, current outliner breaks existing selection and makes a new one. It may well be working as designed, but then that means there's something wrong with the design.

@Isaac Laclede (Nebelkatze) either contact Asus support or alternatively you can find instructions online to bypass the warning and manually update your drivers. Obviously this is at your own risk but I have done this with a friend's computer and they haven't had any issues.

Closing, see D5463: Handling Numpad keys dependent on Num Lock state.

@Philipp Oeser (lichtwerk) Honestly, I didn't looked on why crash happens, knowing that use-case is not supported.

I can confirm.
It seems that the redo of operators within macros only works for operators that have an exec function.
MESH_OT_rip only has invoke, and it is ignored in the redo.

Ok, but don't dig this one up pls :)

This report was closed, because changing default blend mode pretty much resolved performance difference in context of this report.

How developers can reproduce your problem and solve it if you forgot to upload a simplest possible .blend file to reproduce this problem, just as you forgot to fill relevant data as request in bug template?

@Stanislav Blinov (radcapricorn) I replied on that other task, but I think the problem mentioned in T70852: 2.81 Outliner: using active object as anchor for shift-selection is fragile as it may become hidden in outliner is the same here. Again, I don't think this is a bug, but I'm curious what @William Reynish (billreynish) and @Dalai Felinto (dfelinto) think about this.

This is not a bug. If the light is active, then hidden from the outliner by filtering out light objects, then there is no active object in the outliner. Therefore, trying to do a range select is impossible. In your example, both Torus.001 and Torus are selected, but making a code decision to decide which to begin the range select from would be arbitrary. That is why I decided to only do range select if an active element exists.

In the same vein, using extend selection:
In outliner, click on Camera, ctrl+click on Cube, ctrl+click on Cube again. In 3D viewport, the Cube is still active. In outliner, it isn't. And again, attempting to shift+select from that destroys selection and resets active object.

I can repo in yesterdays build but this seems resolved in master (probably by rB0500dcd711d1)

Good News!

Good News!

looks like this has been reported before, see T70848: Masks of the movie clip editor are empty, will merge these reports...

If it helps:

Since rBd025119aeb12: Fix T69352: Audio strips don't update when changing `frame_start`, we are asserting here

It also crash when expanding the polygon data in the "Data Api" of the mesh "Cube.033" inside the the "murs" collection

I have done what you said and 3 times repeated the procedure that has lead to a crash most of the time. This time it worked perfectly without a crash. I did it on version 2.82. I will try on 2.81 as well and will let you know if it still crashes.

You can change your name on this site by clicking on your name at the top->Profile->Manage->Edit Profile. This should link you directly to your profile edit page: https://developer.blender.org/people/editprofile/125688/ (which I obviously can't access, so I can only hope this link works.)

Thanks, but I can't update the driver. I get the information:

Oops, Sorry about this. I got confused.
Reposting under another report.

@Jerome Scholler (jscholler) : cant see anything relating sound in your crash report...
Sure this is the right one? Sure this is the right report?

The render segfault should be fixed already, see rB7df7a8f3f1bb

@"Jacques Lucke (JacquesLucke)"

@Nathan Craddock (Zachman) see also T70852.

What would be the impact of renaming it in the future?