Discussion “Recompile After Finished Playing” option is missing (or better say removed)

Hi,
I switched from Unity3d 2019.4 to 2021.3.9f and found that the "Recompile after finished playing" feature has been removed from the editor.



Without this "Compile after playing" feature our iteration times will increase by a lot. It was one of the *best* features added in the past and decreased our iteration times big times! I assumed this to be a bug and searched for it and then found the issue in the bug tracker:

Link

Now maybe I didn't get it, but the recommended "solution" is not working the same as before, so I wonder if someone can explain to me how I can get the old behaviour again?

"This features has been depricated due to it not working as intented. It has been replaced with a new auto refresh feature in `Preferences -> Asserts Pipeline -> Enabled Outside Playmode`" When activating the "Enabled outside playmode", my scripts aren't compiled at all anymore.

I later found this entry by @castor76 which makes way more sense:

"... what we really want is to have option to have "only" scripts to be auto refreshed outside playmode, but not the all other assets..."

Yes, that would make sense. If I change a script, I want to recompile. If I change a 2 gig Photoshop file, I may not want to reimport it immediately.

Unfortunately I can't figure out how to add a poll here as I'm interested if we're the only ones who miss the feature.


Thanks for feedback,
Patrick

 

Hey.
While implementing and testing, we start the Playmode, test features,... During that, we adjust several times our scripts, debug outputs, calculations on the fly. With "Recompile after finish playing" that was no problem, as the changes would take effect after we ended the Playmode.

Now with that gone, if I change my code and go back to the Playmode, the Editor will recompile and kick all static references (e.g. singletons) and continues playing in a different state than before. That means I have to stop the editor (throws null refs anyway now) and can't continue with my test session.

It's about script changes, either from my custom DLL I import and scripts direct in the Unity project. Graphics are not an issue for us in that regard.

If this *should* work, as mentioned in the first issue tracker description, I have not gotten it to work like that.

Thx for the help!

 

Yes. The recompilation (at least in the past is still the case) removed static variables (for example singletons) assignments. It's quite easy to reproduce:

I attached 2 scripts, create a scene like this:



Attach scripts accordingly.

Run playmode and change the

Debug.Log

message, so when coming back, the Compiler will run, remove your static instance reference and you'll get only Null Refs in the log anymore from the

MyUpdate

Update 

method.

For us it's quite normal to change the code at some points, test even further (especially when you have a very complicated test case and you don't want to interrupt 'cause you found a typo in a debug message) and when the test is complete, you stop and then compilation takes place.

Hope this makes sense?

 

Ok, thanks, I'll give it another try. When I used that option, I always had to trigger compilation manually then (reimport on one of the script files), there was no automatic **script** update and recompilation, like it was before, where compilation was happening when I left the play mode.

 

Ok, I gave it another try and it's not working.

What "EnabledOutsidePlaymode" simply does is ignoring my changes of my scripts, I do during playmode. I have to recompile manually.

@jdrewsen Did you get the same behaviour as before, when applying these adjustments to the editor?

 

Another pretty annoying thing: the "Script Changes while Playing" setting is across all editors. So, everytime I open my 2021.3.9f1 project and switch back to my former projects, I have to change the setting again to "Recompile after finished playing".

 

Yes, that triggers the recompile as well then. Same when I manually recompile.

 

So from my experience in 2021.3.10f1 the recompilation on these settings triggers when some scripts change, but only if the changes were made while not in play mode. Changes in play mode are ignored (as they should) but also not recompiled after play mode has finished. If you then make more changes while not in play mode everything recompiles again.

Furthermore, changing the Auto Refresh setting only seems to apply after restarting Unity, which should be shown as an info when changing that setting, similar to how it is on other settings

 

And another bug, if you have made changes to the script while in play mode, and then (still in play mode) delete an asset (possibly also when doing other asset operations), the scripts are reloaded and thus, stuff breaks because of the reasons stated above.

 

I came looking for others experiencing this issue and just wanted to add a +1 to the original post.

The new auto-refresh option is OK, but still not ideal. There are times when I would want to reimport assets (such as art/audio) but NOT recompile code changes, and may need to reimport one but not the other. In fact, I never want to recompile code during play mode. My personal workflow is to always restart play mode after recompile.

For what it's worth, if we have to direct this choice through the new Auto Refresh option then my ideal solution would be to have the existing auto-refresh option for assets, and then have an additional option for code changes.

Something like:

• Auto Refresh (same as current dropdown option)
• Prevent Recompile During Play Mode (TRUE/FALSE)

But to be honest, I'd much rather have just kept the original "Script Changes While Playing" option determine this because it's worked that way as long as I can recall and it lead to much confusion when it quietly changed.

 

I just noticed this and posted on Twitter, and saw this thread after a search there: https://twitter.com/mwegner/status/1575940849795334144

Please, please return this feature. I don't understand why it would be removed at all.

Furthermore, I don't understand which projects are even capable of surviving a recompile while in play mode. I've asked around over the years, and I've never found a single project that is compatible with it, let alone uses it as a fixture of their workflow. Is this for some non-game use (configurable customizer or something)?

I've been using Unity since the 1.x days, and past a very early prototype project with maybe a scene or two, something breaks during a hot recompile. I get that it's a complex feature, but don't remove an actually-useful feature because it makes that complexity worse.

The options we have now are:

• Stop playing anyway, because there's a 0% chance anything will survive recompile and keep working
• Stop

Or, change a global option to stop importing any new assets without a manual refresh? Ugh

I haven't posted here since 2018, but I bothered to post this. I just thought it's been buggy, since I lose an editor session a couple times a day due to this, but I finally checked settings today. Absolutely maddening to hear that it was both deliberate and being defended

 

Just want to +1 the original post because this is extremely important and really degrades the development process.

Its quite common for me to make code changes while testing, and to want to continue testing. Say for example I am testing a gameplay sequence which takes 30+ minutes and find a small issue. Currently I would just make that code change, and continue testing. Its not acceptable to me to have to restart testing.

Disabling auto-refresh is not a solution, because for every single asset except code, I always want these to update. I regularly make changes to textures, shaders, audio and models while testing, and having to manually refresh now is just silly.

To +1 Matthews comment, I have also never seen a non-trivial project which could survive hot recompiles.

 

Why on Earth did Unity remove that feature? I often make several changes while in play mode so they get all batched for a single recompile the next time I stop and re-enter play mode.

It's also super useful being able to make changes to things like shaders and textures during play mode and see the changes in the context of the game, so losing that ability just to keep Unity from blowing into a million NREs due to a mid-playmode domain reload clearing all statics and stopping all coroutine/async operations is not ideal at all.

If only there were people inside Unity that actually used Unity for making games those sort of usability blunders wouldn't happen as often as they do.

And since 2021 has gone LTS and with 2022 nearing LTS status, if the feature comes back it will likely only happen in 2023, meaning two entire LTS cycles having to manually refresh assets to recompile our scripts.

This reminds me of when Unity decided to remove Mono support for consoles during most of the 2018 cycle, but only shipped IL2CPP script debugging in unity 2019. Meaning the only way to debug anything on consoles in Unity 2018 was printing to the log output and guessing where exceptions were thrown from since there are no C# line numbers in IL2CPP (that's supposed to be coming in 2023 or something).

 

This is absolutely a minefield for my current long load/iteration time project. If I accidently save literally ever in scripts I can easily lose half an hour of test setup. On the fly script reload is such a tiny niche. We've been using Unity for 13 years and have never once decided the risk/reward on implementing it and then maintaining it (which is a ton of work because bugs can be hugely subtle) on multi year development cycles was ever worth it.

 

You need the restraint of an hermit monk to maintain a complex project compatible with play mode compile.

Your entire game state must be compatible with Unity's serialization. This means anything that isn't serializable needs to be replaced by serializable alternatives, or go through complex teardown/setup procedures whenever a recompilation happens. Forgetting anything can introduce subtle bugs that will be hell to debug, like a variable being reset or a coroutine not being restarted.

Also, Unity serialization is not free. The more serializable fields you have in your scene, the longer it takes to load, both in editor and at runtime.

Heck I'm not even sure Unity's own packages like Addressables, Input, and even the SRPs are compatible with it.

 

I just wanted to +1 the sentiment of keeping the original behaviour.

Changing things while the game is running is a cornerstone of rapid iteration. And code has the slowest turnaround of any content type, as such needs faster iteration.

Game engines with scripting languages allow users to change code while the game is running, have that code compile (or fail gracefully) and in both cases the execution of the game resumes without breakages. This workflow allows you to tackle problems in place and fearless of risking breakages.

Unity’s model has always fallen short of this.

As such, the edit after play workflow enabled the next best thing. Make the change when and where you observe the problem, often fixes in a feature you spot on route to testing something else (not the one you are working on) and move forward assured that your flow of testing isn’t interrupted.

You still have to wait for confirmation that the code you added compiles after play mode. Temporally detached from your fix AND wait for a full play mode cycle to get the game into a state where you can test it. This is already orders of magnitude slower that a scripting language’s workflow.

Remember it can be time consuming to get the game into the state where a given feature kicks in, that’s why you don’t want to interrupt execution.

You also don’t want to feel afraid of changing things at runtime. And you also don’t want additional cognitive load to recompile manually after play mode. You are probably already really focussed and might need to remember changes you want to carry over to edit time.

 

Same here, I want the ability to Reimport Assets (art) while playing, but only Recompile code after Stop playing.
Isn't that how it was working before? How was that not working as intended?

 

+1 from me as well. It's a super common workflow to
- run your game
- adjust assets on the fly (should reimport either automatically or with Ctrl +R)
- make various changes and fixes to scripts (should neither reimport automatically nor with Ctrl + R).

The distinction is simple:
- things that can be hot reloaded should be able to hot reload (textures, meshes, ...)
- things that can't be hot reloaded should not be reloaded (scripts)

Please bring that option back. Otherwise you force people into constant fear of "misclicks" - "oh no, I accidentally saved the script file I was editing, now I'm in for 5 minutes of wait time to get back to that state". Nobody wants that.

 

Baffling decision. +1ing everyone else asking for this to be reversed.

Please stop making big editor workflow decisions like this without consulting people who actually build games and projects with Unity.

 

Oooof, please revert this. I can't make my fingers not hit ctrl+s when editing scripts, and I definitely do not want Unity to abort play mode just because I happened to save a script - nor do I want it to recompile, because as good as I am with Unity's serialization, it's almost impossible to get a project to survive recompilation in play mode. Asset reimport is not the same as script recompilation, don't conflate them, and ESPECIALLY don't remove options that are global to all editors in a machine, breaking every other installation of Unity

 

+1 from me as well, I often fix several bugs at once in one session by playing, swapping to code and fixing, then continue playing and repeat.

 

+1 here as well, it’s very common to need the original workflow, with a distinction between things that are more reliably be reloaded (ie, textures) and things that aren’t (ie, scripts). Why was this changed?

 

+1

I just can't understand how decisions like this are made.
Did the people that made this change ever work on a real unity project?

Also, please give us the option to reload shaders (along with textures, etc), while only recompiling csharp scripts after play mode ends.

 

Please bring this back asap.

How can such a huge change to the workflow be made within the LTS cycle? I always tell people to use the latest 3.x version, but it seems that's not good advice.

 

That's a really good point about LTS. Removing features in LTS kinda breaks the contract.

 

+1 Please bring this back. Doesn't everyone use this setting?

This is going to trip me up every 20 minutes while testing and will cause so much productivity loss. I'm used to changing code (and hitting save) many times during one playtest session.

The problem with switching to (global??) manual compilation is I'll forget to hit compile every so often then waste ages trying to debug why my change isn't working. The automatic recompile after stop was important.

I can eventually get used to a new workflow, sure, but I didn't consent that with a minor version update.

 

+1

Please, please, please revert.

I remember this feature when it was added made so many devs happy---I remember showing a few friends this "Recompile after finished playing" feature, and their eyes lighting up. Every single dev uses this setting. Every single script absolutely explodes with errors without this setting.

The other two options are completely broken non-options for every single unity game in development.

Absolutely baffling to remove it.

I'm pretty ...flabbergasted---like, so many bugs are Won't Fix, "because it's an LTS release", but it's alright to outright remove a feature to destroy every programmers workflow?

I'm sorry we are all pretty negative on Unity lately.
I know I am incredibly guilty of it. We all love the engine--and this text box is all we have.

 

Removing this option feels like Unity developers don't actually work on any real Unity projects. There are no projects at any meaningful scale where hot-recompile works, and they should stop pretending it's a feature.

 

Since we're going into Monday, I'm just going to drop a +1 here and respectfully ask if we can get an update from anyone at Unity about this?

Are you talking about it internally? Are you considering reverting? Is a revert already in progress? If no, how many like and retweets do we need to get to bring back Fan Favorite Useful Feature? Is there a BTS×Recompile After Playing crossover in the works? Just some comments on what we can expect, if anything.

 

Removing this was a very bad idea and shows again that Unity doesn't really use their engine for real development.
The proposed fix with disabling auto refresh is much more complicated than the previous setting, and requires you to change 2 things to get the correct behavior. This is unacceptable as this is the only sane default.

 

+1 for requesting this feature back

Desired behaviour:
Assets other than scripts should automatically reimport in play mode, due to this not being destructive. Should be an option for changed scripts to only be reimported upon exiting playmode

Shaders however, should be automatically reimported like other assets, as the fast iteration is very useful here and the vast majority of data is persisted

 

OKAY! NOW I KNOW WHY I HAVE NEW BUGS IN MY SYSTEM! Whew, well I wish someone told me this before I reinstalled windows and lost a bunch of design documents(my bad).

Thanks guys, this is terrible!

Every IDE known to man will play and be happy when you change "scripts" and save.
Unity just... crashes.


We need an option: Do literally NOTHING when I change scripts.

I understand the idea for noobies and ninjas to want to change stuff while in game, but us old heads who have a work flow progress of ensuring stability want literally NOTHING changed during the debug.

Think about the time saved not forcing a compile mid debug session.

I'm trying the best I can to be level headed about this, but you guys are doing change for the sake of change and it is screwing us developers up. Literally no IDE in the history of mankind FORCES you to recompile mid debug. I see how it could be a neet feature for my niche needs. I could see how it would be neet to noobs and new programmers with deep nested code to analyze...

But seriously guys, seriously... There's a reason we have done things a way this long and it isn't always good to change stuff that worked. We need need an option to: DO NOT COMPILE AT ALL while program is running.

The car analogy is having your ChimChim steer while you jump on the roof with of the Mach-5 with a lug wrench and work on the engine mid drive. Yeah, some people may be Speed from Speed Racer, but most of us like to park our cars to work on them in a garage.

I'm not dissing the new options. I'm dissing the removal of normal and sane ways of doing things.

I'd say make the default option to not compile at all... This took me by surprise. I thought Unity was just bugging when it was bugging in many other ways. This is part of the reason I had to keep reinstalling Unity for 10 hours a day 16 days straight. It had many many many bugs. I have a stable editor now, but seriously, please throwing stumbling blocks in front of your devs. I know you just want to code a bit, publish what you got done and then go out to some sushi bars and chill, but really, test your code thoroughly before you publish. Do not eliminate options. Don't just kick stuff out the door and rush home to watch some anime. Make sure the code is stable, works and doesn't wreck your users lives. I'd imagine there's 10s of thousands of Unity developers relying on your product to be stable, think of us before you kick unstable product out the door. We'd rather have less updates that are stable, then lots of flashy unstable updates.

,Jim

 

100%, I've been saying this for months now. It's why the CEO is in the hot seat. And as he panics he pushes more and more nonsense updates when all he has to do is chill, and tell his employees, send updates much less often, and with thorough testing. We already like Unity, new flashy stuff doesn't get our blood pumpin. But we can get heated when what we rely on breaks over and over to unstable patches.

My post on my game dev site: Unity Has Too Many Bugs right now: https://www.starfightergeneral.com/2022/10/unity-has-too-many-bugs-right-now/

We want less new flashy changes, more really deliberate testing of use cases. Heck, fire your patches by me, I could help you with UI/stability and general work flow discipline and principles.

 

+1
I need the old feature. I don’t need the new feature.

 

People are getting hundreds of error messages spammed at them and they think it's their code, or Unity update not working. This is major.

 

Here's the workflow that I (and probably many indie/solo devs) used constantly:

1. Playtest the project in the editor with some specific goal.
2. Notice a tiny bug or misconfiguration.
3. Switch over to scripting, make the correction, and save the script (just in case). Leave myself a comment if I'm feeling especially organized.
4. Switch back to the editor and continue playtesting, without a deserialize crashing everything.
5. Notice a visual asset that looks wrong, and tweak it in Photoshop, Shader Graph, etc, with instant feedback.
5. On exiting playmode, the scripts are conveniently reloaded automatically.

I can see the benefits of setting up hot-reload, but it just seems like a lot of (previously) unessesary work for small or medium-sized projects, and it's not practical for rapid prototypes that don't have any kind of persistence yet.

 

Thanks for the update! I appreciate you. Please do update us as things progress.

 

You mentioned you opened a bug, could we get a link to the corresponding issue in Unity Issue Tracker? That way we can get a sense of its priority and progress. Thanks.

 

Great, thanks so much for the update @jdrewsen. Really happy to hear that this is being treated with urgency.

 

Is Unity even using Unity? Serious question...

"Recompile After Finished Playing" is the option almost all project I've worked on used.

 

Agreed.

That is great to hear and feel like best practice.