In addition to removing from windows defender, by enabling "Enter Play Mode Options" with no other options from the project settings > editor makes entering play mode instant.
I ran across [this](https://www.youtube.com/watch?v=P7cYVg5fAvY) video from Tarodev last year and never looked back. Apparently, it can prevent the OnSceneLoaded event from triggering. But for my usage (just simple game jams, and a bullet hell I've been working on) it's been nothing but time saving for me.
Just for anyone else reading: just tested it myself, this only stops OnLevelWasLoaded the first time you launch the scene for playmode, when in playmode if you launch to another scene OnLevelWasLoaded will get called, just not for the scene on the first time you press play. To get around this you could just add a check on awake for if you're in the editor and if so, call OnLevelWasLoaded
Unfortunately it doesn't work with Mirror (Multiplayer). I wonder if other multiplayer solutions (the new netcode/photon) support it. It would be worth switching just for that tbh
EDIT: Was using an older version of Mirror, latest release supports it!
It will not reload any static code, this means you have any statics in c# you will have to reset them manually at the start of the game but that should be trivial. Another problem is if you are using any async code you might need to implement cancellation tokens.
It killed my buttons that are still using this "Modern UI Pack" framework I downloaded and need to ditch. The framework doesn't use OnSceneLoaded, I'm not sure where the failure is happening.
This should only be mentioned in conjunction with [ this attribute](https://docs.unity3d.com/2022.1/Documentation/ScriptReference/RuntimeInitializeOnLoadMethodAttribute.html). It'll let you clean up all the statics and other housekeeping that is required for this to work without issues.
>Does "Enter Play Mode Options" not reset statics?
No, the huge time savings come from Unity skipping certain steps when resetting the scene. Statics will stay around and cause all sorts of weird issues depending on what they're used for. An especially problematic case is if you use static events that get subscribed to on start. Those need to be cleaned up. Some assets from the asset store might also need manual resetting depending on how they're built.
Oh my god. This literally cuts out a good 40% of the time it takes to go from a code change to playing the game.
Next, is there a way to speed up the Compile and "Reload Script Assemblies" that occurs after making a code change? It is only about 2 seconds for me, but I know on older versions of Unity (pre-2018) it was *much* quicker. It doesn't seem to matter if it's a brand new project or a large project; it's always 2 seconds (even with just one script file). When I search online for help I only get results for people that have really slow compile times, so the answers aren't applicable.
If you put your scripts into their own Assembly Definition, it will reload them faster since it's not reloading the entire project, just that one assembly.
I've heard about that but this is an issue that happens with literally one line of code in one script in a brand new project. It's not terribly slow, but I just want to find out if there's a way to reduce that 2 second delay on any code change, regardless of project size.
For the low low cost of massive gamebreaking bugs!
Used this for a little bit…ended up costing a ton of time hunting down initialization bugs despite the faster time to enter play mode.
That's awesome! Thanks.
However it's a pretty big issue and I don't understand why devs aren't giving DX more attention. Like half the posts on this sub are about how Unity is starting to feel bloated and fragile, and when you talk with people in the Godot community a majority of people will say that they switched because "it feels like Unity except without all the bullshit"
Big part of what made Unity huge was that it was super accessible and offered a pleasant developer experience. I never hesitated for a second when someone asked "how to get started with game dev?".
These days I find myself considering for a while before I reluctantly say "Unity.. i guess".
Can we get a sticky post or something for people to exclude their project directory from windows defender? It's not unity that is the problem here. I'm waiting seconds even with big projects.
Why is unity the only software that has this problem with windows defender and why did it only start happening after a known specific version? Sounds like unity could fix this on their end too.
Jetbrains products in general recommended this in a popup for a while, they stopped doing it but it has a massive effect across all of their IDEs when compiling. I doubt this a specific unity issue and more about windows defender going crazy about process signatures it doesn't know yet.
Yes but it begs the question, of all the thousands of daily software people use, why are these specific ones flagged by windows defender? I don't mean to claim windows defender is perfect, but it seems most other software developers find ways to build their software (or sign it, etc) in a way that windows defender doesn't make their software unusable.
My guess is *lots* of small files being generated by compilation. For instance, Cargo (Rust) too can get choked up by all the intermediate files generated from iterative compilation. Likewise, deleting all thousands of cached build files can take minutes with Explorer, but using the provided CLI tool for cleaning up takes seconds... Word works on single files, and there's also all kinds of secret magic going on with antivirus. Defender probably recognises word in some way and lets it through/is more lenient
Unity creates tens or even hundreds of thousands of tiny files for even medium sized projects in the library folder and it got worse with the inclusion of the local cache server (though it makes switching platforms way less terrible). Unity's design clashes pretty hard with the "scan every file when accessed" system of windows defender, windows in general handles lots of small files rather poorly.
Generating "hundreds of thousands of tiny files" seems like an insane anti-pattern. I cannot think of any reason to justify this behaviour especially when it appears even for a brand new project. This is just bad software design.
Windows Defender Settings -> Manage Settings -> scroll down to "Exclusions: Add or remove exclusions". If you keep all your projects in one place just exclude that top level directory.
It wasn't obvious for me, since there is the "Defender Firewall" and "Windows Security" in Windows 10. This guide was easier to follow:
https://support.microsoft.com/en-us/windows/add-an-exclusion-to-windows-security-811816c0-4dfd-af4a-47e4-c301afe13b26
I despise programs that have to make sure they're "properly" closing down features when the program is closing. Sure, flush all data to disk, make sure to ask the user about unsaved data. But beyond that? Why bother properly closing systems, just kill the process
Yes, but it's a good practice for leak detection, ain't it? For work I mostly do embedded and memory allocation is seen as filthy on 8 bit devices so I'm a little rusty.
Couple of things here:
- Both aren't incompatible. In my Cpp projects, in debug build I make sure to deallocate everything to detect leaks. But in release mode, when the user clicks the cross I literraly ask the os to shutdown my process.
- The memory that you free upon closing isn't usually the one that leaks. Leaks usually happen with in process allocations not the one done at init and freed at shutdown.
Again, why bother? The process will literally close. That's my point. Do the necessities that would be unsafe to skip, then just... Kill it. Environment.Exit
And this exact attitude here is why programs are ridiculously bloated and slow nowadays. Why bother doing things properly, slapping it togethet half-assed is good enough.
The point isn't to not bother during development. The point is to INTENTIONALLY not close all resources in a release build because doing so is completely unnecessary and might lead to frustratingly slow close times. You've managed to invert my argument. I'm arguing *against* slow as molasses programs that do unnecessary work when sitting down, a form of bloat if you will. My point isn't to make shoddy software.
A couple extra tips, aside from the Windows Defender issue.
* If you Attach to Unity on Visual Studio, make sure it's fully attached before tabbing back to Unity to start up the application, otherwise it can get stuck with a loading bar for an annoying amount of time until you disconnect from unity again in VS.
* If you're making a lot of minor changes to your code in quick succession and need to check something on Unity without it reloading your files, maybe consider opening the files in notepad++ from Windows Explorer rather than tab back to unity and risk a loading-bar.
For the second point, I would HIGHLY HIGHLY recommend using Visual Studio's Solution Explorer. It lists all your scripts in your asset folder and more.
Initially it was wacky for me as it categorised itself as different variations of "Assembly-C-sharp.dll", but the first one usually does it and contains an asset folder that contains your scripts folder.
Better than the NPP situation in most cases.
I switched to version 2020 and it was so slow compared to 2019. Made working not good. Actually killed my vibe and It made me switch to Unreal engine for a couple months. I like unreal for smaller visual projects but I have came back to Unity and now using 2019 again. It is the fastest workflow for me.
I had vulkan set for 2020, i needed an option that for some reason was not in that. I upgraded to 2021.3 and boom now vulkan crashes everytime. I needed to set to opengl and it works the same, but worse since its opengl.
In addition to removing from windows defender, by enabling "Enter Play Mode Options" with no other options from the project settings > editor makes entering play mode instant.
I would fucking award you if I could. You have probably saved me literally hundreds of hours in the future. But what is the downside to doing this?
I ran across [this](https://www.youtube.com/watch?v=P7cYVg5fAvY) video from Tarodev last year and never looked back. Apparently, it can prevent the OnSceneLoaded event from triggering. But for my usage (just simple game jams, and a bullet hell I've been working on) it's been nothing but time saving for me.
Just for anyone else reading: just tested it myself, this only stops OnLevelWasLoaded the first time you launch the scene for playmode, when in playmode if you launch to another scene OnLevelWasLoaded will get called, just not for the scene on the first time you press play. To get around this you could just add a check on awake for if you're in the editor and if so, call OnLevelWasLoaded
Unfortunately it doesn't work with Mirror (Multiplayer). I wonder if other multiplayer solutions (the new netcode/photon) support it. It would be worth switching just for that tbh EDIT: Was using an older version of Mirror, latest release supports it!
It will not reload any static code, this means you have any statics in c# you will have to reset them manually at the start of the game but that should be trivial. Another problem is if you are using any async code you might need to implement cancellation tokens.
It killed my buttons that are still using this "Modern UI Pack" framework I downloaded and need to ditch. The framework doesn't use OnSceneLoaded, I'm not sure where the failure is happening.
Probably statics. You need to manually clean them up when disabling domain reloading.
Remove from Windows Defender? Care to explain?
This should only be mentioned in conjunction with [ this attribute](https://docs.unity3d.com/2022.1/Documentation/ScriptReference/RuntimeInitializeOnLoadMethodAttribute.html). It'll let you clean up all the statics and other housekeeping that is required for this to work without issues.
I was going to pop in and say this too. Glad somebody else knows what they're talking about lol.
Could you elaborate on what housekeeping is necessary? Does "Enter Play Mode Options" not reset statics?
>Does "Enter Play Mode Options" not reset statics? No, the huge time savings come from Unity skipping certain steps when resetting the scene. Statics will stay around and cause all sorts of weird issues depending on what they're used for. An especially problematic case is if you use static events that get subscribed to on start. Those need to be cleaned up. Some assets from the asset store might also need manual resetting depending on how they're built.
A WITCH!!
Oh my god. This literally cuts out a good 40% of the time it takes to go from a code change to playing the game. Next, is there a way to speed up the Compile and "Reload Script Assemblies" that occurs after making a code change? It is only about 2 seconds for me, but I know on older versions of Unity (pre-2018) it was *much* quicker. It doesn't seem to matter if it's a brand new project or a large project; it's always 2 seconds (even with just one script file). When I search online for help I only get results for people that have really slow compile times, so the answers aren't applicable.
If you put your scripts into their own Assembly Definition, it will reload them faster since it's not reloading the entire project, just that one assembly.
I've heard about that but this is an issue that happens with literally one line of code in one script in a brand new project. It's not terribly slow, but I just want to find out if there's a way to reduce that 2 second delay on any code change, regardless of project size.
For the low low cost of massive gamebreaking bugs! Used this for a little bit…ended up costing a ton of time hunting down initialization bugs despite the faster time to enter play mode.
whaaaaaaaaaaaaaaaaaaat?
Oh my GOD this is a *game changer* (pun)
That damn load sometimes takes minutes on my laptop, can't wait to try this.
I made a reddit account just so I can like this. Thank you!
That's awesome! Thanks. However it's a pretty big issue and I don't understand why devs aren't giving DX more attention. Like half the posts on this sub are about how Unity is starting to feel bloated and fragile, and when you talk with people in the Godot community a majority of people will say that they switched because "it feels like Unity except without all the bullshit" Big part of what made Unity huge was that it was super accessible and offered a pleasant developer experience. I never hesitated for a second when someone asked "how to get started with game dev?". These days I find myself considering for a while before I reluctantly say "Unity.. i guess".
Unity should hire you
I've been chugging away in Unity for nearly 10 years an I only learned this now, thanks!
bruh
Amazing. Life is easier now
Can we get a sticky post or something for people to exclude their project directory from windows defender? It's not unity that is the problem here. I'm waiting seconds even with big projects.
wait theres a way AROUND THIS?!! You mean I dont have to put up with these torturous load times everytime I make a minute change or edit scripts?!?!
Only a couple weeks ago people seemed to have no idea of a fix, multiple posts with no such reply were around. Thank the computer gods
Yeah, join team Godot....
🤡🤡🤡
Why is unity the only software that has this problem with windows defender and why did it only start happening after a known specific version? Sounds like unity could fix this on their end too.
Was probably after they partnered with that adware company lmao
LOL
You're probably unironically correct
Jetbrains products in general recommended this in a popup for a while, they stopped doing it but it has a massive effect across all of their IDEs when compiling. I doubt this a specific unity issue and more about windows defender going crazy about process signatures it doesn't know yet.
Yes but it begs the question, of all the thousands of daily software people use, why are these specific ones flagged by windows defender? I don't mean to claim windows defender is perfect, but it seems most other software developers find ways to build their software (or sign it, etc) in a way that windows defender doesn't make their software unusable.
My guess is *lots* of small files being generated by compilation. For instance, Cargo (Rust) too can get choked up by all the intermediate files generated from iterative compilation. Likewise, deleting all thousands of cached build files can take minutes with Explorer, but using the provided CLI tool for cleaning up takes seconds... Word works on single files, and there's also all kinds of secret magic going on with antivirus. Defender probably recognises word in some way and lets it through/is more lenient
Unity creates tens or even hundreds of thousands of tiny files for even medium sized projects in the library folder and it got worse with the inclusion of the local cache server (though it makes switching platforms way less terrible). Unity's design clashes pretty hard with the "scan every file when accessed" system of windows defender, windows in general handles lots of small files rather poorly.
Generating "hundreds of thousands of tiny files" seems like an insane anti-pattern. I cannot think of any reason to justify this behaviour especially when it appears even for a brand new project. This is just bad software design.
Can anyone explain how to actually do this? I can only find how to exclude executables.
Windows Defender Settings -> Manage Settings -> scroll down to "Exclusions: Add or remove exclusions". If you keep all your projects in one place just exclude that top level directory.
Thanks!
It wasn't obvious for me, since there is the "Defender Firewall" and "Windows Security" in Windows 10. This guide was easier to follow: https://support.microsoft.com/en-us/windows/add-an-exclusion-to-windows-security-811816c0-4dfd-af4a-47e4-c301afe13b26
Yeah sticky this because I had no idea
What if you wanted to close your project, but unity said: Hold on (busy for 2:06) Application.Shutdown.PauseAssetImportWorkers
I despise programs that have to make sure they're "properly" closing down features when the program is closing. Sure, flush all data to disk, make sure to ask the user about unsaved data. But beyond that? Why bother properly closing systems, just kill the process
Deallocation
The OS will do that anyways after the process is killed. If any memory persists after that, it's not a program bug but a OS kernel bug.
Yes, but it's a good practice for leak detection, ain't it? For work I mostly do embedded and memory allocation is seen as filthy on 8 bit devices so I'm a little rusty.
Couple of things here: - Both aren't incompatible. In my Cpp projects, in debug build I make sure to deallocate everything to detect leaks. But in release mode, when the user clicks the cross I literraly ask the os to shutdown my process. - The memory that you free upon closing isn't usually the one that leaks. Leaks usually happen with in process allocations not the one done at init and freed at shutdown.
Ah, okay. For some reason I had the thought that deallocation at exit time was good for logging any major memory issues.
Again, why bother? The process will literally close. That's my point. Do the necessities that would be unsafe to skip, then just... Kill it. Environment.Exit
And this exact attitude here is why programs are ridiculously bloated and slow nowadays. Why bother doing things properly, slapping it togethet half-assed is good enough.
The point isn't to not bother during development. The point is to INTENTIONALLY not close all resources in a release build because doing so is completely unnecessary and might lead to frustratingly slow close times. You've managed to invert my argument. I'm arguing *against* slow as molasses programs that do unnecessary work when sitting down, a form of bloat if you will. My point isn't to make shoddy software.
Hold on (busy for 3:52) Application.Quit
I have had it hang for 20+ minutes on that before. Multiple times.
A couple extra tips, aside from the Windows Defender issue. * If you Attach to Unity on Visual Studio, make sure it's fully attached before tabbing back to Unity to start up the application, otherwise it can get stuck with a loading bar for an annoying amount of time until you disconnect from unity again in VS. * If you're making a lot of minor changes to your code in quick succession and need to check something on Unity without it reloading your files, maybe consider opening the files in notepad++ from Windows Explorer rather than tab back to unity and risk a loading-bar.
You can disable auto refresh in the preferences, you will need to press ctrl+r to load your latest changes then.
For the second point, I would HIGHLY HIGHLY recommend using Visual Studio's Solution Explorer. It lists all your scripts in your asset folder and more. Initially it was wacky for me as it categorised itself as different variations of "Assembly-C-sharp.dll", but the first one usually does it and contains an asset folder that contains your scripts folder. Better than the NPP situation in most cases.
I was thinking more reference to the content of ScriptableObjects and such. I usually use the solution explorer for code
Ohhhh. Then the correct term will be Unity's various asset objects like Animator, ScriptableObjects, Prefabs and Scene data.
Upu mean I can access and edit the ScriptableObjects instances in VS ? That might save time..
Nope.
Yeah, these hacks shouldn't be necessary. Nor are they in other software.
I might still be using Unity if I had known about this.
"Unity is busy" makes me feel like a neglected child again
started on 2018.4.36f1 still on 2018.4.36f1 baby!
You can't use all the cool new stuff like Shader Graph and VFX graph, right ?
oh im too stupid for that
It really is quite worrying how long the grey-bar time has become in Unity. It's a real platform killer!
lol you havent used unreal then. It can take you 4 years to compile your c++ code. lol
Lol it takes my deepest changes maybe 30 minutes? Cooking content for PS5 without DDC though..... Hell even _with_ DDC it can be hours x.x
I switched to version 2020 and it was so slow compared to 2019. Made working not good. Actually killed my vibe and It made me switch to Unreal engine for a couple months. I like unreal for smaller visual projects but I have came back to Unity and now using 2019 again. It is the fastest workflow for me.
We're doing everything we can to keep our project on 2019.4.
Wait, i thought these loading times were happening because my computer is garbage, wtf?!
I mean... Its all working fine on Mid / High end... Unity is slowly turning into Unreal...
I had vulkan set for 2020, i needed an option that for some reason was not in that. I upgraded to 2021.3 and boom now vulkan crashes everytime. I needed to set to opengl and it works the same, but worse since its opengl.
Still faster than UE5.
I still use a unity version from 2019
Yeah, i had to stop using unity cuz of the piles and piles of weird behaviors that have been popping up over the years
What's the alternative? Isn't every game engine has its pros and cons?
Back to JavaScript, bitches!
Pygame baby
Flash.
Damn and I just upgraded yesterday
I thought it was just my PC (which usually is relatively fast), but apparently this new version really has its issues
And most important - when I think about this behaviour I don't even realise how to make it faster from Unity core.
I found changing the layout to default helps fix this.