Editor: Domain reload and / or scene reload

• Editor: Domain reload and / or scene reload could be disabled when entering play mode to allow faster iteration times in the editor.
  
  This is amazing, instant play without any lag, thanks for including this!
  
  First test are really promising, there were sometimes missing references, but that was a problem with a script that I purchased. Enabling domain reload fixed that for now, but I will investigate it more.
  

 

Is this enabled by default? If not, how do you turn it on? It sounds amazing!

Edit: Figured it out. Edit->Project Settings->Editor->Enter Play Mode Settings.

So far it's feeling like magic!

Does anyone know what the drawbacks are of it? Is there a way to manually trigger domain reload and is that even necessary?

 

That makes me want to write a script that resets all static variables on entering play mode.

 

Get rid of your static variables.

 

Would it be an idea to make one extra option ?
Domain reload with only re-JIT

I don't know what impact re-JIT has on a large project with many scripts?

I say this because I have some projects with many scripts that I purchased on the asset store and I can't remove all the static variables from those assets because I simply would not know how.

This way there is perhaps still some time saving while not trowing up errors for static variables.
Might be interesting to explore

 

Small Feedback: We saved around 17 seconds. Went from 23 seconds of intial loading screen to 6 seconds. Full launch halfed due to this. Thanks!!!

 

This is very cool!
There seems to be a bug with shuriken though. Particle systems don't start playing when switching to play mode unless you start them in the editor by hitting the "play" button in the "particle effect" scene gui.

 

Just when I thought I could settle down with 2018.3 new prefabs, 2019.1 has timeline signals I need to make my UI.
Then when I think I could settle down with 2019.1, then this killer feature came.

Mine went from 11s to 0.5s. This is unreal. Thanks a lot for this feature!
I might as well print out the release note and frame it.

 

no this is Unity

 

Thank you

 

Hi, I have a few questions:
- is there a reload when you stop in editor ?
- is there any impact on scriptable objects or other things you would live edit on play and then press stop (same question but before pressing play)

 

I starting a new project from scratch using Unity 2019.3.0a5 (due to this feature) for a week now (in my limited spare time) And i have to say I never want to go back to older versions.
Even do some Packages like 2D Animation and Vector Graphics are not working (yet)
The only thing i want back is the time i wasted before this feature existed! ;-)
I suspect do due to the static 'limitation's that many current editor related assets will break. (or at least act strange at times)
Luckily I only use one asset so far and that gives me no problems.

The play button turned into a Harry Potter button. Touching it feels like magic!

 

I'm really happy but at the same time really mad.
They should've done it a long time ago and we would have saved countless hours.
It's too bad that they just realize and they better be sorry but at the same time, I'm really happy we can have a better future. It a funny feeling.

It's better late than never but it will take a while before we all adopt it. If one asset you are using causing a problem, you cannot use Instant Play, and it will be very disappointing.
Therefore, I wanted to have them to make the Instant Play available as soon as possible (for 2019.2 ??) so that Asset developers have time to make it compatible but then, it looks like we will have to wait until 2019.3 releases (Most of the asset developers will not touch beta product after being burned by beta so many times)
Unity has broken so many promises delivering stuff late and why they can't they deliver something earlier than scheduled just for once? It's an optional feature and it won't hurt anyone.

Well, if they can't deliver it earlier, the only thing I ask is to make sure it's easy/rock-solid to integrate once 2019.3 release so that asset developers will easily optin and as fast as possible. Since we know it's possible to support Instant Play, I cannot wait any longer. Waiting for 2019.3 and beyond is just too painful.

Thanks.

ps. I wanted to test this on my project but the stupid missing UI assembly is stopping me from it. Don't they do any sort of compatibility testings before they do something? Sigh...

 

@alexeyzakharov for a large AAA project that takes ~10 to 20 minutes to first enter play mode (reproducible on multiple employee machines), is there a general % of time reduction expected?

and are there other editor performance improvements Unity is working on?

 

It would be good if there was a button near the play mode settings you could press that would point out which code is likely to have these drawbacks. It may take time for Unity to develop, but would save on a huge amount of tech support and devs pulling their hair out.

 

You're doing something wrong if entering play mode takes over 10mins. Try to have as empty scenes as possible and load your stuff in code, for exmaple using async loading.

 

Sorry for resurrecting this, but would it make sense to invoke a domain reload when you *exit* playmode rather than on enter perhaps? Using the API above. I think that's what a previous comment was alluding to.

 

I think the documentation is missing some vital info. One major difference with Domain Reload Disabled is that ScriptableObjects don't get reloaded on entering Play. This means that any runtime data that was expected to be re-created in OnEnable will remain and become outdated. I think this needs to be mentioned in the docs.

On this note, does anyone know the most efficient way to re-load ScriptableObjects manually in the editor?

 

This is definitely true and made me a little crazy trying to find what was happening.
The docs don't mention it at all and they really should.
I was lulled into the false sense of security that domain reloading only affected static stuff.
But for scriptable objects, even NON-serialized, NON-static fields remain with their old values.
Don't have a good way to deal with it either, just have to manually reset them before using it anywhere.

 

Is there a way to detect this in code?

If not: why not? This change literally breaks projects.

I'm currently updating some old codebases (with complicated use of statics) and the one thing I can say for sure is "no-one should enable this setting, it will definitely corrupt your project" -- but I don't see a way to do that with the current API/docs?