Recompile + Enter Play Mode Process

Unity Engine
,
1

Hi Unity devs, ( @alexeyzakharov @Justinasg )

Since I moved from 2019.1.5 my workflow has really taken a hit, due to something that might sound insignificant to you but that’s had a non-negligible impact for me (projects like Ghost of a Tale tend to be rather large).

The issue in the 2019.3 beta10 is that as soon as I modify a script and then go back to the editor for a recompile, the editor becomes completely frozen (unresponsive) right away. In 2019.1 there was a two seconds window during which the recompile process started but you could still click on the play button. So in effect you were able to daisy-chain recompilation + enter play mode in one single click.

But now with the editor getting frozen right away I have to wait for 15s for the recompile process to finish in order to be able to then click on the play button and wait another 10s before entering play mode. That is super disruptive (as of course happens hundreds of times per day).

Is there a chance you guys could have a look into this please?

9 Likes
2

I think this might because of the asset import changes that happened in 2019.3 and that the import and compilation of a script happens earlier than before and when you switch to the editor, we are already reloading the assemblies and this process locks the editor.

I would say that the previous behavior was not intended and I don’t think we will bring it back.

I would recommend that you instead implement this behavior yourself and automate it.

You should be able to do this by 1) hooking into when compilation finishes.

  1. And then set EditorApplication.isPlaying to true in that callback to enter play mode afterwards.

You could implement this as optional behavior by using a checked menu item that you can toggle on or off.

1 Like
3

@lukaszunity How about Unity finally implements a responsive UI, so our entire editor is not frozen when it’s doing some background tasks :slight_smile: ? Proper approach to those use cases would be to display a tooltip “compiling…” while still allowing us to use the editor using the old compiled sources and refresh it when it’s done.

Take a look at VS 2019, it launches much faster those days, while finalizing some background tasks as you start working with the solution.

This way Seith could still click Play button even while compilation is in progress and it will wait untill the process is done before triggering play mode.

14 Likes
4

When assemblies are reloaded, we actually unload ALL C# code, even the editor UI code and there is a point in time where no C# code is loaded. We then load the new C# assemblies and restore all their state and invoke all the MonoBehaviour.Awake, InitializeOnLoad, etc. callbacks. So there has to be some blocking operation to be able to reload code due how Unity is designed around the main thread.

If you are experiencing long reload times, I recommend using the Profiler and enabling Editor profiling and then look through the data after are the assembly reload and find the very long frame and drill down into the profiling data. We often see long reload times because projects contain C# or third party code/plugins that spends a long time initializing after reload.

5

Being able to tab back to the editor and press play before compilation was finished is one of the few things that makes programming for Unity at all bearable. Whenever there’s a pause that’s longer than 5+, it’s very easy to get distracted and check email or forums or whatever, so the 5+ second pause becomes a 5 minute one. This change makes it so that we have two of those 5+ second delays instead of one. Every_single_time we make a code change.

If you break this, you’ve made a net negative impact on editor usability in the 2019 cycle. So please don’t.

You’re creating all of these features around entering play mode and whatnot that’s supposed to improve the experience, but then you just keep making it worse by breaking stuff like this.

It feels like understanding the usability of the editor isn’t a priority at all for you, and that’s really frustrating.

13 Likes
6

I think this is a fair point. I’m just saying that this behavior wasn’t intended and I’m not saying that the new behavior is better, but that we probably won’t bring back unintended behavior.

I think we should rather add explicit support for this workflow, maybe with an option like “Enter play mode after successful compile”, so you only get 1 assembly reload instead of 2.

Let me know what your thoughts are on explicitly supporting this in the editor in way that would be better than just delaying asset import and script compilation “for a bit”. :slight_smile:

9 Likes
7

for me it is an improvement. in the old version, I either:

  • pressed play while compiling, not get feedback, press play again, then when domain reloaded it immediately exited play mode
  • or if Unity managed to enter play mode and then reload the assembly, I needed to stop and then re-enter play mode because either our code or some 3rd party plugin I have breaks (because of singleton abuse and init non serializable state in Awake())

now at least Unity is already reloading when I focus.
an improvement could be to make the play button still responsive even when reloading (write that part of UI in c+?)
(ideally I’d like partial reload of only the recompiled assemblies and dependencies, but that is on Mono to support first)

or: add ability to only load some of the assemblies for a given editor session (like on-demand import of assets)

8

That wouldn’t help much, as it’s horrible for editing editor scripts. I don’t want to enter play mode when I just made an edit to a ScriptableObject’s Editor, or something like that. I don’t usually work exclusively with editor scripts or exclusively with gameplay scripts. Instead, I work with both in tandem, so I generally want to enter playmode after switching to Unity about every other time.

There’s essentially two things I want to be preserved:

  • I should be able to alt+tab to the editor, and have it recompile, reload assemblies, and enter play mode as soon as possible. This is ideal when editing gameplay scripts.
    I should be able to alt+tab to the editor, and have it recompile, reload assemblies, and not enter playmode. This is ideal when editing editor scripts.

The current (old) implementation manages to do both fine, because there’s a window after I alt+tab where I can press ctrl+p to activate the play mode button, which is blocked from entering play mode until recompilation and assembly reload is finished. That that wasn’t intended doesn’t mean that it’s not good.

The community has been asking you to get the main Unity Editor window and the play button off the main thread since forever, though that’s usually asked for so there’s a way to break out of infinite loops without killing the editor. This might be the time to actually do that.

5 Likes
9

I agree that this is a frustrating change. I don’t want to auto-play every time I tab back in. Maybe have the blocking “compiling scripts” pop-up include a Steam-style “play when done” button that we can click, as a way to emulate the old behavior of being able to click Play during those couple of seconds before the whole editor hangs?

1 Like
10

What about background importing on another tread?
So the editor does not get blocked during import.

11

One workaround might be to use Visual Studio’s “Attach to unity and play” debug configuration:
5180540--514364--upload_2019-11-16_0-30-57.png

It’s not ideal to enter debug mode, but at least until there’s a better solution you can enter play mode right after compiling

12

Where is Attach to unity and play located?

13

The only way I see to get rid of the long pause in the recompilation is to get rid of AppDomain Reload completely.
A single line of change in the source code in a tiny assembly will trigger AppDomain Reload and it will completely reload all the assemblies. Pretty crazy, right?
There is no way to get around in the current system.
The good news is that .Net Core can manage assemblies in finer granularity and it can just reload only the changed assemblies. Imagine less than a second compilation including reloading.

We should push Unity to move to .Net Core as soon as possible. That’s when we can call it Unity updated for the 21st century.

4 Likes
14

There was a prototype to port Unity to .NET Core, but only a prototype: Porting the Unity Engine to .NET CoreCLR | xoofx

It should be possible, but the efforts aren’t to be taken lightly.

I would love to see assembly load context in Unity. It really would end all this AppDomain reload insanity.
But again, porting something this old and large isn’t cheap.
I’m not sure we’ll ever see it land.

1 Like
15

It’s in this drop down menu:
5180909--514409--upload_2019-11-16_3-31-33.png

I’m using Visual Studio 2019 with the Unity plugin.

1 Like
16

Not to put too fine a point on it, but why does unity sit in the background doing nothing when you save changes to the code, and then grab the interface away from you the moment you alt-tab back? That’s almost willfully rude.

4 Likes
17

With Visual Studio 2019, by default it actually compiles as soon as you hit save… and I absolutely can’t stand it. It was constantly spinning up compilation and recompilation and re-recompilation while I was trying to get work done in VS, so I disabled it. Not to mention Unity occasionally crashing out from under me while I was making changes to script files in VS.

2 Likes
18

I did a quick debug session of the new asset import code and I can now confirm that we block the main thread after importing a script and wait script compilation to finish in the same frame because “Auto Refresh” is hard coded to be a synchronous import. This explains why you do not have the window of time to enter play mode, because there are no editor updates/redraw frames between import and reloading assemblies.

I also tested it with “Auto Refresh” disabled in preferences and then using Cmd+R/Ctrl+R to refresh manually and it looks like we do perform an asynchronous import in that case, e.g. the old behavior. And it appears that the workflow with entering play mode before script compilation finishes works with a manual refresh. It would be great if the people who are experiencing this issue could confirm this.

Based upon the feedback in this thread, I would consider the synchronous import with “Auto Refresh” enabled a bug and regression and I would encourage you to report a bug on it and then vote on the issue in the public issue tracker once it has been proceed by QA. The more votes an issue gets, the more visibility it will get internally :slight_smile:

I have raised your this issue with the asset pipeline team internally and asked them respond to this thread as soon as possible.

I have also let UX know of this workflow and asked them have a look at a better workflow for this that isn’t based upon timing and how fast scripts compile. Because we could in theory compile scripts faster in the future and we would be back to the same issue again where isn’t enough time to click the play mode button.

One suggestion I have besides disabling “Auto Refresh”, is that we in Preferences have we the **“**Script Changes While Playing” option and we could add a new mode called something like "Stop Playing And Recompile, start playing". Which would exit play mode, recompile scripts and enter play mode again (if you have 0 compile errors) when a script changes. This would allow you to control the behavior by keeping the editor in play mode when you want to iterate on game code and being outside of play mode when you want to iterate on editor code. The downside is that it wouldn’t work if you have compile errors after giving the editor focus. Let me know what you think :slight_smile:

14 Likes
19

It sounds like a good short-term workaround for me. I had actually implemented this myself in older Unity versions :slight_smile:

3 Likes
20

Alright. I’m warning you, this is going to be a rant. And an open letter to the developers of Unity.

That thing I brought up in the opening post is merely a symptom.

The problem is that almost none of you guys are working on very large AA or AAA games using your own engine (Unity). That is the crux of the issue.

And I’m not talking about making impressive demos, which are basically cinematic sequences destined to prove to the world that Unity can do amazing graphics. You know what? You’ve already proven this a couple of years ago.

What you have NOT yet proven, however, is that Unity is designed for top-notch development of rather large and demanding games (and yes I’m including Ghost of a Tale in this).

What you’re missing is the deep seamless experience that a game is expected to be nowadays. It’s not just about the visuals (I can’t believe I’m saying that) on a 50m by 50m with baked static effects that can have no real application in an actual interactive production where the camera could be anywhere at any time.

If you guys had to live through the actual realities that teams like ours are living through on a daily basis you would go “wait that’s crazy we should address that”. We have to wait almost thirty seconds every time we need to make a small code change and test it in-game. Now multiply this by a hundred times or more during the day.

The Unreal Engine can enter game mode almost instantly. But you know what it doesn’t have? The elegance and ease of use of Unity. The Unreal Engine is a work horse that’s designed from the ground up to be a powerful game engine. Unity is much more user-friendly but it’s also trying to be many things to many people.

When you guys make demos on stages around the world or show off the engine to students, the issues of inefficiency and time-wasting are never broached because on such a small level they almost don’t register. But do you want Unity to keep being considered an entry-level engine in the game industry because of this? By all means if you’re satisfied with that state of things then fine, I’m the fool for not understanding that sooner.

I want to keep using Unity. But you guys need to take the needs of producing larger games into account. All of your users will eventually benefit from it.

Now Lukasz, I thank you for your reply. But there should not have to be a “voting” on that issue. This is not a matter of opinion and even less a popularity contest. Please, do bring this up to your management and hopefully they’ll realize a fundamental shift in priorities needs to happen at some point.

43 Likes