Feedback Recompile + Enter Play Mode Process

Here is a solution I was able to find for my issue https://assetstore.unity.com/packages/tools/utilities/auto-relaunch-167027

 

Thanks @Allen0012. I grabbed this but I'm having a really hard time trining myself out of stoping playback before I edit scripts

I'd love it if the people at Unity would consider adding this back as a feature though.
Perhaps if you pressed play while compiling, the play button could show a waiting icon or something then play once ready?
Currently it's a really awkward workflow that people have to do continuously throughout a day.

 

@petey I'm glad it worked for you, yeah it takes a bit to get used to it.
I agree, this shouldn't be a very complicated feature to add on the engine/editor source level, it would save a ton of time.

 

Just to chime in, we also used this constantly.

So to be clear, the new "desired behavior' when we make a script change, is to wait 10seconds plus, then press 1 button, and then wait another 10s+ for the exact same task to complete, and then test our game?? Are you actually trolling us right now?

The idea that we would want to setup some automatic play on save is just so far removed from the reality of what a game-maker actually does, I'm really surprised you would suggest this.

 

For my case, it's been 6 minutes after making one line change. :/

 

You should be able to check with the Profiler if it's caused by user-code, 3rd party plugins or Unity.

• Open Profiler "Window > Analytics > Profiler"
  
• Switch the drop-down from "Playmode" to "Editor".
• Change the drop-down from "Timeline" to "Hierarchy" in the bottom panel.
• Hit the "Record" button
• Do whatever takes 6 mins
  
• You should see a gigantic spike in the Profiler and need you need quickly hit the "Record" button to stop the Profiler.
• In the CPU graph select the peak
• In the Hierarchy panel expand the all the nodes with the highest cost

... this should lead you to the cause.

If it's not showing what's causing it, you can enable the "Deep Profile" button and repeat the above steps. Deep Profile is significantly slower, but collects more data.

The Editor Iteration Profiler could also be useful:
https://forum.unity.com/threads/introducing-the-editor-iteration-profiler.908390/

If it's caused by Unity code, please submit a bug-report:
https://unity3d.com/unity/qa/bug-reporting

PS: What Unity version do you use?

 

I'm using 2020.1.0b11.3880 personal. I'll try profiling, thanks!

 

Following up on this I posted a proposal for a new lightweight editor/runner for programmers:
https://forum.unity.com/threads/allow-3rd-party-players-or-make-a-lightweight-editor.1029856/

I share the exact same concerns as you guys. I just want a compile and run button.

 

So i stumbled uppon this thread while also being bugged by this.

For me (and maybe most of the others here) i think a have a fairly good compromise to offer.

There are two things which cost time here:
1: if you are working on code and switch back to unity and you just want to do something in the editor (not starting the app) the auto recompile is very annoying, so i´d like to switch it off.
2: if auto refresh is off and you want to test code during runtime it´s not possible to chain the playbutton AND it happens that you forget to CMD+R and test on old code

My suggestion would be an additional option in the prefs to compile BEFORE entering playmode (in best cases only when code is dirty)

Case 1: there is no recompile offtime
Case 2: there is no way to forget recompile AND its chained (just the other way around)

In case you are working on an editor script, you still can use CMD+R to compile your changes

 

To autoplay after compiling, with a menu item toggling on/off, try this code in an editor folder. (tested on Unity 2019.4). It also enters playmode when Unity loads up, I'm not sure if there's way to prevent that.

Code (CSharp):

1.  
2. using UnityEngine;
3. using UnityEditor;
4.  
5. public class CustomEditorHelper: MonoBehaviour
6. {
7.     const string MenuName_EnterPlaymodeAfterCompile = "Autoplay/Enter Playmode after Compile";
8.  
9.     public static bool EnterPlaymodeAfterCompile
10.     {
11.         get { return EditorPrefs.GetBool( "EnterPlaymodeAfterCompile", false ); }
12.         set { EditorPrefs.SetBool( "EnterPlaymodeAfterCompile", value ); }
13.     }
14.  
15.     [MenuItem( MenuName_EnterPlaymodeAfterCompile )]
16.     static void ToggleEnterPlaymodeAfterCompile()
17.     {
18.         EnterPlaymodeAfterCompile = !EnterPlaymodeAfterCompile;
19.     }
20.  
21.     [MenuItem( MenuName_EnterPlaymodeAfterCompile, true )]
22.     static bool ValidateToggleEnterPlaymodeAfterCompile()
23.     {
24.         UnityEditor.Menu.SetChecked( MenuName_EnterPlaymodeAfterCompile, EnterPlaymodeAfterCompile );
25.         return true;
26.     }
27.  
28.     [UnityEditor.Callbacks.DidReloadScripts]
29.     private static void OnScriptsCompiled()
30.     {
31.         if ( !Application.isPlaying && EnterPlaymodeAfterCompile )
32.         {
33.             EditorApplication.EnterPlaymode();
34.         }
35.     }
36. }
37.  

 

This is still inferior to the old workflow. Sometimes when I switch back to the Unity editor, I want to recompile and then play; sometimes I want to just recompile. I don't know ahead of time which I want, so having a menu item for it doesn't really help.

The way it used to work is that you could hit ctrl+p in the first 500ms or so after switching to the editor, and that would make it enter play mode as soon as it's done compiling. My desired ideal workflow is that you should be able to hit ctrl+p any time before or during compilation, and that makes the editor enter playmode as soon as compilation is finished.

 

This sums up my experience, my sadness, and my wishlist perfectly.

 

I'm running 2019.4.10f1 and even on simple tutorial projects the compilation time after making any .cs file change was driving me crazy.

Turning off Auto Refresh in Preferences -> General has helped me reclaim my sanity.

Though disciplining myself to do CTRL+R in Unity may take some time.

Edit: hitting 'Attach to Unity and Play' doesn't work - I only get latest code changes if I CTRL+R in Unity.

 

Its a feature/bug of Windows. Even though they're just dumb windows, the frame becomes dysfunctional when the program held inside is thinking. Forced alt tabbing should never happen, it should always be a request. The number of times I was forced to alt tab to make a decision on files being saved only to click one at random with my typing, or in the middle of something ripped away is annoying. I say it may be a feature since Microsoft seems to be moving away from freedom of the user, to a more Hal 9000 type of not letting you do stuff like delete files and uninstall stuff, watch registry changes or have logs of files touched, and of course the notorious, "Search for files doesn't always work."

 

I agree!

This used to NEVER happen in 2019 ... something happened in unity's code base or visual studio?

 

As a person who works with Unity every day all day, the sum of my experience using 2020.2 and 2021.x is a product with ever increasing performance regressions (editor workflows) and limited acknowledgement of a problem by Unity staff.

Now that I am waiting 15-25 seconds each time I make a minor script change I am now at wits end. Why isn't an issue like this an "all hands on deck emergency"? Are we so thoroughly beaten down into submission (customers and Unity staff) that these kinds of editor regressions are somehow acceptable?

If the Unity staff is willing, I will gladly meet to show how recent changes to the Editor are destroying daily productivity (https://forum.unity.com/threads/any...pt-assembly-reload-time.1117138/#post-7447712).

 

It's a very good question. It most likely means you've crossed the boundaries of what Unity was designed for at the very beginning. Join the club. I feel your pain, believe me.

It is, indeed, a crazy, infuriating situation. However it's likely only met by studios which use Unity on full-on AA(A) ambitious productions. And that's just not the bulk of their clients at this point (especially with UE5 looming so close).

If it's any consolation, many devs at Unity know of this issue, internally. And they deal with the same pains we are. I know, it's no excuses, but... Well, it is what it is.

 

They claim to dog food Unity for internal projects but then this just raises more questions. 1) how could they allow this kind of deal breaker into the product and 2) why haven't they fixed it since it first appeared in December 2020? Where is the sense of urgency?

I agree that it appears they aren't using Unity in sufficiently complex projects. The roller-ball tutorial works so hey, ship it.

I don't know what the tipping point is. Since it appears to be compilation/app-domain related, here are .cs file and assembly statistics for our affected project.

Code (CSharp):

1. .cs (project)       3,137
2. .cs (compiled)        757
3. .dll (assemblies)       7

I didn't start seeing impactful editor regressions until 2020.2. I upgraded from 2019 (which works fine) to 2020.2, which is abysmally slow. I was subsequently shocked to see the behavior remains in 2021.1. This isn't a scenario where there is a lack of feedback, tickets, or diagnostic logs from end users.

@Seith Would you mind sharing some stats on your project size?

 

Probably because there's a silent majority of us that's not experiencing these kinds of problems at all. We're making major games and iteration times are faster than they were with similarly sized games in Unity 4, 5, 2017, 2018.

Opening a bug report and sending them your entire project is probably the best way to actually get something done.

 

A completely fair assessment if true. Using Unity 2020.2 or 2021.1, what is the largest project you have found success with, measured by number of classes and assemblies? As Seith indicates, there may be a tipping point or threshold for the behavior to manifest.

I would certainly be happy to share. However, there is already an open ticket with a reproduction project. There is a large number of customers discussing the issue in this thread and others. What else does Unity need, and are they communicating with the end users that have voiced concern?

 

Nothing really. They know the pain points, the people working there know the pain points and even want to address them, but for one reason or another these things will never get fixed, at least not in a time frame that will matter to any of us here.

"If only we, the users, could simply show Unity what's wrong, then they would fix everything" is simply a fantasy we keep telling to each other (and that Unity reinforces at every turn because it puts the onus on us, not them, right? That feature doesn't work right? Well it is your fault for not submitting a bug report, shame on you) to keep hope alive and feel like we have some control.

The truth is Unity is too corporate to care and their priorities are elsewhere. I mean certain executives sold their shares in the company already, so whatever, who cares.

They are chasing after other markets, and for the current issues gamedevs are facing, they've probably put all their eggs in the DOTS basket, and most teams are probably asked to work on DOTS stuff (like didn't the new input, which released in a bad state, just in time for a certain event, stop development for a year or so just to make a DOTS prototype or something?), while the current feature set is being worked on only if things get too bad, or if someone famous makes them look bad on Twitter.

And in the meantime, the people who rely on the current working feature-set of Unity, we can all go get F***ed.

 

Final project will probably be just under 100Gb, with roughly 8k .cs scripts. It's an open world structure relying heavily on streaming hundreds of scenes, with dynamic time of day/lighting.

To be fair we know that's not exactly the typical use case Unity is catering to, but we're still fighting each day to make it work. To use the engine as best we can. And we do invest time and energy to give constructive feedback to the Unity team.

It might be fair to say that Unity as a company is currently facing a crisis in terms of vision and direction. Add to that the terrible (but maybe forced) splitting of rendering pipelines, the huge hurdle of trying to give birth to DOTS while risking to alienate a sizeable part of their user base. It's a lot.

Then again maybe we're asking too much of the engine. We're still using Unity because we know it very well, we love it, and we've invested a lot of time and money developing ways to try and bypass its limitations.

So we'll see how the situation evolves in the coming months. If things do not improve considerably in 2021.2 we might have to face some painful decisions.

 

Related thread -- https://forum.unity.com/threads/any...embly-reload-time.1117138/page-2#post-7454570

On Monday I think I am going to try to create a reproduction project tailor made for the issue. I am thinking of writing C# code to generate 10,000 C# scripts. The scripts will exist in the project folder but are otherwise not used. This might show it is compilation or app-domain related.

I'll then benchmark in 2019 LTS, and then 2021.1.18f. Based on ongoing conversations, it seems like this may be a way to clearly demonstrate the issue. If you have ideas and/or suggestions please let me know.

 

My results are here (https://forum.unity.com/threads/any-update-regarding-increased-script-assembly-reload-time.1117138/page-2#post-7461319) and to be honest, I failed. The test was limited to scripts and assemblies, with 10K scripts and modification of one script to create the 15 to 45 second delay. I rarely ran into the 15 to 45 second wait I experience each time in my other project.

 

OK, thanks to the Iteration Profiler (https://github.com/Unity-Technologies/com.unity.editoriterationprofiler), I identified the cause for my game's slow editor iteration performance. I added a carriage return to a single script, brought Unity to the foreground, and then let the profiler record Unity's iteration process. The V2 AssetDatabase is consuming 6.4s seconds in method ImportAndPostprocessOutOfDateAssets. 60% of my editor iteration time, resulting from changing a single script, is caused by the V2 asset database. This is why my previous testing couldn't reproduce the behavior -- it was not accounting for the size of the asset database in a large or (A)AA project.

 

@Seith, @AcidArrow

In the interest of checking if a common thread is the v2 asset database, could you confirm if you are using it for your affected projects? Also, report the size of the asset database in your project?

// size of asset database
Debug.Log(AssetDatabase.GetAllAssetPaths().Length + " Assets");

Here's my timing:
AssetDatabase.V2.ImportAndPostprocessOutOfDateAssets. 22371 Assets, 6488ms

 

Great! We should be able to run some tests in the coming days. Will report here...

 

@lyndon_unity

Ticket
https://issuetracker.unity3d.com/is...57.1707974302.1630328440-511853534.1602175685

Stack Traces

1. Exit Play Mode. No Script Change. Expected Behavior


2. Exit Play Mode. Script Change. Expected Behavior.


3. Exit Play Mode. Script Change. Unexpected Behavior.


There appears to be a few different variations. In the scenario shared above it is seen during ExitPlayMode. However, I believe I have seen it occur when playback is not active, and it feels random or related to editor uptime or number of play/stop iterations.

*Edit. Please note that in all of the above scenarios, the only change was the deliberate addition of a carriage return to a single .CS file.

 

Associated thread: https://forum.unity.com/threads/har...52.1707974302.1630328440-511853534.1602175685

 

@Baste , @Seith , @stonstad

Have anyone with the big complex project tried using Assembly Definitions to improve script recompilation time? I've made experiments with it some time ago but all my projects were relatively small and I haven't seen any perceptive differences. I decided that it doesn't worth the hassle in my case. Now I wonder if it could be of some use for huge projects like yours?

 

It's an optimization problem. Adding additional assembly definitions decreases compile time -- but this benefit is offset by an increase in the number of assemblies reloaded into the app domain for each editor iteration. For many developers the issue is app domain reload time. Ultimately, Unity must work to reclaim performance lost by the architecture and feature changes introduced in Unity 2020/2021.

 

Yes compile time is super fast now in the latest, maybe its worth it to remove all assembly defenitions and see what happens in a project with many of them.

 

Our latest project had some 30+ assemblies in our own codebase. Our current has 4 or 5. We're a lot happier this time around. Reload and compile times are much better.

 

To address the original issue, how about a checkbox on the compile progress dialog that says "Enter playmode on completion", so we just tick that and it enters playmode when it's done?

 

It's way more annoying to click on a checkbox (or any other UI element) than to just press a hotkey (which was the pre-2019.3 workflow). Of course, I'd take a checkbox over the current totally missing functionality.

 

We did invest a lot of time trying to convert our project to use assembly definitions but in the end the benefit was rather minimal. Plus it had rendered coding in the project much less user-friendly. So it did not appear to us at that point that investing more time in this direction was a sound decision.

 

I liked this little mock-up someone made - https://mobile.twitter.com/willgoldstone/status/1352269824467066881
It would be really nice if Unity could fix this, it’s super annoying and just adds a little tedium to your day.

 

Thank you a lot for sharing this, it will save me some time not wasted on non helping feature.

Heh, it was Will Goldstone, and he made the voting if they should implement it or not.

 

Full agreement with OP. Coming from Unity 2017. The new behavior stinks.

 

[DidReloadScripts]
private static void OnScriptsReloaded()
{
EditorApplication.EnterPlaymode();
}

 

Unity 2019.x, 2020.x, 2021.x, 2022.x all were slow on my home Windows PC but worked great on my office Windows PC.

By slow I mean that empty freshly created project with one script in it took 15 second for Unity to process the change to a script ("Hold on" "Reload Scripting Assemblies") and 10 more seconds after pressing Play button to actually enter Play mode.

HERE IS HOW I FIXED THIS ISSUE:

My office Windows PC System Language was to English US and my home PC was set to Ukrainian.
By setting your Windows System language to English US the issue is gone.

Unity team, can you confirm reproducing this bug with any other non-English language setting?