I have a small issue that slowly starts getting irritating. Here, a project window:
If I will select a file in the project window, something like a material, then decide to go to a different folder by selecting a folder from the left side of the panel, then I will just switch folders. Everything works as expected. But If I will try to do the same (clicking a folder) on the right side of the panel, then my material will get unselected.
Here’s a colossal pain in the [REDACTED] point:
The UIToolkit is just far enough along that I was able to make a pretty nice interface that works pretty well.
The XR Interaction toolkit is just far enough along that it works pretty well.
But it doesn’t work with UIToolkit!!!
I hate being sold on getting just enough rope to hang myself with these new systems.
Look, a large part of game dev is about getting multiple subsystems to play nice with each other. I mean, just look at what the Asset Store is all about! If Unity’s going to make a couple of new subsystems and advocate for their use, they have to make these subsystems work together (XR + UI) before they can say they’re complete and production-ready.
I don’t want to have to keep having to kludge together temporary fixes or dig into their source and duplicate efforts that they’ll later be rendering obsolete when the Unity devs finish what they started. It takes me ages! I suck at it! I don’t even get paid to do it! It’s an inexcusable cost! C’MON!
Sigh.
All right. As a dev I understand that these things can’t be rushed. But damn it, the marketing and documentation teams need to stop baiting me with sweet little half-truths about how wonderful their new stuff is when the tried, tested and true legacy systems would have worked fine. My project would be a lot further ahead if you didn’t keep sticking twigs into the front spokes of my development cycle.
PS: Please stop calling everything that works: “Deprecated”.
This right here is one of Unity’s biggest offenses. As someone who started using unity about 4 years ago, it took me 2 or 3 years to finally realize that taking that bait is going to always burn my productivity. And the worst part is that I know that I’ll probably fall for it again at some point because they make the shiny sound so sweet.
I’ll just drop this one here.
Here’s another one: when you search for a line in the console and click it to highlight it, when I dismiss the search, please keep that particular line highlighted and make the console window scroll to show it. Finding the line is only half the battle–most of the time, I need to see it in context to really understand what’s happening in the code. I shouldn’t have to go back and dig through manually to find it again just so I can see it with the surrounding console lines.
When you lose 2+ hours because, for some reason, you updated a script which has nothing to do with the entire project, but the editor needs to scan through every texture, asset, and atom in the project. No cancel, you’re just along for the ride as your day of gamedev is crushed in the palm of the editors hands. To further torture, the bar starts off at 99% and stays there because the editor has no concept of how many assets there are or it does and it just wants to grind up the little ashes of hope you have and steps on them.
Update - It ran for 9+ hours then the editor crashed
Meanwhile, the team who wrote the Editor code for scanning every asset because they never heard of hashed data deduplication, background or farmed processing threads, or packaging jobs with recovery snapshots.
Whenever i make the tiniest change on my very simple game (unity 2021.1.24):
I have like two hours to spare every night on my game but half of it is waiting for unity.
Adding a simple log takes 4 minutes. Scripting is unbearable now, it wasn’t like this before.
Welcome to the post 2018.3 Unity with the new and improved project workflow.
Open the profiler, set it to “Editor” (instead of “Runtime”), enable “Deep Profile”, then change a script.
Most likely this isn’t actual compile time because I have a 60GB Project with thousands of lines of code, a few dozen assets, many containing scripts and the actual compile time is 4 seconds while recompile time was over one minute and is now at ~30 seconds. I am not using any ASMDEFs at all … because they only help with compile time.
What’s actually happening is that all [InitializeOnLoad] and [InitializeOnLoadMethod] attributes are executed, this causes some Assets to scan through all assets to find their Database, it causes the NewInputSystem to recreate some files (which takes a lot of time),
Also all existing scripts are trashed and recreated = DomainReloading,
Which in turn causes all TextMeshPro, ProBuilder and all Mesh-Creating-Components to recreate their mesh and trash the old one,
As well as all (or just some?) Scriptable-Object OnEnable() calls.
So the bigger the scene and the more scenes you have opened and the more dynamic meshes they contain, the longer you will have to wait for recompile because all of the above leads to MASSIVE garbage allocations - which costs time to clean up, as well as time to de-serialize all required data to restore the values.
(Editor Windows are Scriptable-Objects too, they are re-created on re-compile, and for some reason, rendering the scene takes ~15 seconds after a recompile, which I still don’t understand because the same scene can then be rendered in 1/60 seconds = 0.16ms I think)
I was able to cut recompile-time in half and further improve it over time by removing almost all [InitializeOnLoad] and [InitializeOnLoadMethod] Attributes, changing OnEnable() methods in my ScriptableObjects, disabling Gaia and other assets with an #if DEFINE and usually not having all our big scenes open when working on scrips but instead using my test-scene which contains just what I need and nothing more, also I changed EditorWindows to initialize in OnBecameVisible(), so it won’t get triggered on recompile if the Window is just a Tab and not fully visible.
(PS: Also I had massive stalls up to 4 minutes when duplicating assets and doing simple stuff, deleting the libary fixed this issue.)
That is so true. I spend so much time taking care of not accidentally deselecting the material by clicking a folder.
If I click the folder, it shows the name of the folder in the Inspector. This is soooo stupid, it just does not make sense and forces me to locate the material again. I could click the “Lock” key icon to lock the material, but that takes too much time.
If simply a click on a folder would not change the Inspector, then all would be good!
Here is a sample:
Makes absolutely no sense to display the name of the folder and polluting the Inspector and thus removing other valuable information.
You can make custom inspectors for folders. It takes a bit of hacking and reflection, but you can set it up such that selecting an inspector shows a simplified inspector for the things inside the folder.
For example, we made a game with a ton of “Item” and whatnot scriptable objects, and instead of having to go into the folder and edit them there, we selected the folder they were in, and got a nice scrollable, searchable list of simplified editors for all the items in the folder.
So that’s a nice reason for the feature to exist, but yeah, by default it’s really annoying that folders get selected as the information isn’t useful.
A potential solution is to open the material with the property editor. You can write an [OnOpenAsset] that does that automatically when you double-click the asset, if hitting the “p” key is too annoying
But, yeah, I literally thought I was stupid for not seeing that. Turns out, it is only available if there is an instance of the prefab in the scene. Probably why i missed it so many times, that and “context” only kind of makes sense… …I think “prefab view” would be a more sensible label.
Also, ping exists, but is still a giant hassle and hardly worth it in many cases. ID still like to have a “ping in heirarchy” and “ping in project” option, but most of all, and Id like for it ALWAYS to only be one right click away.
Also, If I did not mention it aleady, it would be Really nice if there was a way to find all the objects in hierarchy with a component, or more specifically script. Same with in the project. (again, an option, ping in Heirarchy, ping in project, explode the trees to show them all if necessary) I delete scripts often, and I just want to keep it clean, especially since with auto-refresh off having a deleted script can cause a compile lock, where it will not refresh until you hunt down the script and remove it from everything it was attached to. It’s a PITA now, and that’s when I only have scripts attached to a couple object… …this feature would also be very helpful, when say changing a public field, and then having to find every item with that script and changing what is assigned to that field.
…or maybe just an option when deleting the script, to also remove it from any and all objects at the same time.
To find all instances of a script in the scene, you can search with t:ScriptName. So, for example, t:BoxCollider finds all box colliders in the scene. Also works for your own scripts.
An alternative is the (experimental) dependency finder , which can find dependencies all over the project.
Can we have an option to disable the play button until the editor actually started playing?
I lost count of how much time I lost waiting for the editor to start playing and stop by itself because I accidentally clicked the play button two times.
And it was working fine in 2017, 2018 or so…
in recent versions, maybe 2019 and later that always happens…
I contacted the QA team about the scrollbar bug. Apparently it’s been flagged since 2019.4… If we don’t vote on it, I guess it’ll never get addressed.
<— That bug
Anyways who knows if voting even helps… but vote away if you’d like the UX team to maybe, possibly fix this.
Here’s another pain point: you can’t keep two different instances of the Project pane open to different folders without accessing an obscure “Lock” option buried in a right-click menu. By default, the moment you click on an asset in one Project pane the other Project pane refreshes to mirror the other regardless of what it was displaying a moment prior. This completely defeats the purpose of allowing the user to have multiple Project panes open; each Project pane should be locked to its own display by default.
Actually there is a lock icon in the top right that does the same as the menu option.
Though I do agree some what that maybe each project window should be locked by default.
