People used to complain about material list impossible to purge, without closing/reopening file, before invention of Purge button of Outliner.
Whatever default is imposed, there are always people complaining it.
That is why, it is easier to satisfy most of people, by giving choice to choose a preference.
But the way it currently is already commonly results in data loss. Much more commonly than the case of using someone else’s system with different preference setting.
Even knowing about fake users, it is still very easy to overlook it and forget to press that button.
It can result in time loss. If you lose hours rendering in the wrong color space, for example. But that’s no reason to remove those preferences.
If you’re going to collaborate in a project and use someone else’s system, you have to take some precautions and check if everything is set up correctly, and adapt to the settings used in the project (although this particular setting can be different in different machines for the same project without any issues at all, and I don’t think it’s common for people to switch machines during a project).
Still, having the option would be better than not, in my opinion. But obviously we won’t reach a consensus here, it’s a ten year debate and I just have to accept that it simply won’t change because the only solution that’s within reach is viewed as imperfect, and the ideal solution (replacing the whole system with some mysterious other perfect system) just won’t happen.
The way blender does it currently already results in data loss, by purging data you may have wanted to keep.
I’m not sure what you’re getting at – is it that a checkbox that offers you a preference on preventing that, brings about … more data loss?
He’s saying that we are talking about a topic that deal with loss of data to significant assets. Color space does not delete your material. Standard frame rate does not result in data loss. Audio settings don’t result in immediate data loss, either. All three examples you brought up yourself.
Your examples all did not deal in significant parts for losing work but more “annoying to rework”. A setting as integral as autosave does and is, thus, inherently more urgent and complex and needs better restructuring.
But you didn’t answer the actual reply, which stated that data loss is already the case and a checkbox would only create less data loss. If the checkbox was off, nothing would change, it would be as it is now where data loss can happen any time. Turning the checkbox on would prevent that from happening
And a checkbox that says “mark fake user automatically”, and does this when I make a new material, or animated action, or whatever - also does not result in immediate data loss.
Unlike how things are at present, which IS immediate data loss if you haven’t shielded an unused item and close the file.
Sorry I thought that was so evident that I didn’t care to expand. Possibly this is just my brain convolutions that do this ? Maybe I’m imagining this problem ?
Thank you, so that part seems understood by everyone. This risk exists right now, but only once. The user needs to learn, sometimes the hard way, that they have to prevent garbage collection from running when an ID has no users left. We agree that’s a very imperfect system.
The issue I see with a situation where deciding which IDs are auto-fakeuser’d on creation versus which IDs aren’t, is precisely that this is variable : once committed to muscle memory, and stored in your preferences, you, the individual user, wouldn’t think twice about not clicking “fake user” for your animations because you’d set it before to auto-do that. That’s a critical piece of logic, controlled by something that can vary over installs & workstations, and as such it becomes one more gotcha to be wary of when dealing with multiple installs, troubleshooting your colleague, or even teaching Blender in schools or over the web.
It adds onto a pile of checks, that for the most part are inconsequential -except that one can easily cause loss of data, with all that entails, and emotional distress.
Are you worried about this for yourself, or for other users?
If it’s for yourself, you don’t have to worry because you could just not change the preferences.
If it’s for other users… why? You’re not every user’s caretaker to decide for them.
So… I’m not allowed to have a preference setting, because another user might not be able to handle managing their own settings.
Look, I get that you take this to heart, but I am not attacking you, you can drop the defensiveness. We can simply discuss normally, with arguments and stuff- like I just did, without resorting to strawmen.
I’m not attacking either. Just - you know – summarizing the outcome result.
For me it’s still the undo system randomly taking forever or behaving unpredictably in bigger projects. You can have a decent PC and still end up waiting after a simple action. It’s one of those little workflow killers that feels like it should have been solved years ago.
I thought of this yesterday before falling asleep: it would be good if the Outliner or Asset Browser had a “Material Library” sub mode with special features tailored for local Material management…
Thre’s no need to answer to that. We all know the current state of the system and I wrote pretty much what I would like to happen: Finally a rewrite of Materials as a higher object type.
Also I am totally on Hadriscus’ side that a “save all datablocks” checkmark would be a dangerous quick fix, as well. Would it be somehow better than the status quo? Yes, probably. But thre really are still many scenarios where this can go into a wrong direction and any temporary quick fix has the bad habit of becoming the permanent solution despite many other shortcomings.
Me merely mentioning how crazy it is that materials still get deleted and all the different opinions on what the right way of dealing with it shuold be shows: It’s absolutely not trivial at all. It’s just frustrating that there has been no movement in any fixing of the problem in sight for over four years now. Everybody who works with a software long enough kind of starts losing sight of some of the really crazy problems they simply accepted of working around. Seen these in any 3D software I’ve worked with over the years. This particular one is, to me, just a very frustrating one and I’d take any official solution to it at this point. Especially since BF seems to be okay with implementing groundwork and then iterating over the next few release cycles to fix stuff.
Please list these “many” scenarios. The two you’ve list so far aren’t wrong, they’re following the behavior requested.
What shortcomings?
A quick fix means it’s easy to remove or change in the future once a proper solution is established. Maybe it does become permanent because that’s the most that was needed to solve the majority of the issues.
This is a routine issue with the Blender developers, putting off a major problem for the perfect solution that never comes, instead of at least addressing the problem in a way that gives the most benefit now and then looking for a better one if needed. Sometimes this makes sense for imperfect solutions that are complicated or affect a large portion of the codebase in a way that will affect future development but they do this all the time, in every scenario, simple or complex.
That’s not what was proposed.
But that does not really make sense.
A significant asset would be marked as an asset, anyways, to be visible in asset browser or asset shelf.
There will be several incremental saves of this asset as its own file.
If you set as your preference, to auto-fakeuser datablock ; indeed, that will be your responsibility to preserve significant data, according to you.
Because it is you that will remove this data from its user.
If your colleague considered data was significant, he probably already did several incremental saves of it, marked it as an asset or set a fake user.
So, if it was his job to create that important data, why would you take responsibility to remove it from its user ?
You would not do that without a good reason.
Preserving data from imported file, starting by a quick check, is an habit, you will take whatever is the source. A colleague from team or a bought asset, etc…
When I add one to the scene it luckily comes in as LINKED so I should be able to find out somewhere the path that it is linking to… but I can never remember where… I found it eventually. They should put the path of the source in the tool tip of these menu items. It would save a lot of time and confusion. I’d also like to see author names on node groups. I’ve got several other Array generators from several other people that I still sometimes use over the new Array. All of them are named “Array”.
Funny thing I just actually realized for the first time … for script files it already works that way. Every script gets an auto-fake user and is actually deleted when it’s being X-ed from the text editor with deactivated fake user.
