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

+1 on all this thread

"Recompile after finished playing" should be the default option, in my opinion

In 2021.3.11, the code still doesn't refresh when exiting play mode with the option `Preferences -> Asserts Pipeline -> Enabled Outside Playmode`

Since I really need it, I just added this script in an Editor folder:

Code (CSharp):

1. using UnityEditor;
2.  
3. [InitializeOnLoad]
4. public static class MyRefreshEditor
5. {
6.     static MyRefreshEditor()
7.     {
8.         EditorApplication.playModeStateChanged += LogPlayModeState;
9.     }
10.  
11.     private static void LogPlayModeState(PlayModeStateChange state)
12.     {
13.         if (state != PlayModeStateChange.EnteredEditMode) return;
14.         AssetDatabase.Refresh();
15.     }
16. }

It works for me for now...

 

There should be an emergency patch.

Why can't we have an option: DO NOT COMPILE ON CODE CHANGE?

 

Why not have this option: Do not recompile until asset refresh? That's an option all other ides have.

If I save my code while debugging, IT CRASHES MY CODE!!!!!!

Watch this video ON HOW BAD THIS IS!!!!

IT TOOK ME 160 HOURS! YES 16 DAYS OF NON STOP UPGRADING UNITY EDITOR!
THIS IS HOW BAD THIS IS!!!!!!!!!!!!!!!!!!

I even reinstalled windows because I thought I may have had a VIRUS.

I HAD GAME DESIGN DOCUMENT DATA LOSS BECAUSE I FORMATTED THE WRONG DRIVE because of this issue!!!

Now I'm still reinstalling software along side Windows reinstall. SO I lost more than 160 hours upgrading UNITY EDITOR! IT will end up making me lose about 300 hours!!!!

THAT IS HOW BAD THIS BUG IS! DO PEOPLE AT UNITY EVEN UNDERSTAND HOW BAD IT IS FOR THEM TO SHIP UNSTABLE UPDATES? It is LTS, you broke your promises not to remove features from LTS!

We as developers need trust in the company who send upgrades that it will work and not break our builds/systems.
UNITY has lost my trust that I can do incremental upgrades pain free and easily.
This means I will not upgrade my UNITY again unless I am missing features absolutely required for my game.
The reason why is this: If I lose 300 hours just to patch something that should take 20 minutes, and this happens over and over... It's easier to just do the big leaps of upgrading very old and out dated tech when needed.

Unity really really really has no clue about how bad their "KICK IT OUT THE DOOR IF IT WORKS OR NOT,WE'LL PATCH LATER" philosophy wrecks their 10,000ish active devs a day who rely on it being stable every time.

Please emergency patch. I need the feature to be able to debug my code again.

 

PS: DOTS/ECS is good, and I love Unity. I want to praise you guys, not just constantly be complaining at these bugs you put in, seemingly intentionally( You can't 'accidentally remove' an option in a patch right).

What else is good on UNITY:

I love your collision detection.

I love being able to use 3d easy.

I love your asset store.

I love the community support on youtube.

I love Unity devs helping on Discord.

I love Unity devs helping in this channel.

I love how easy it is to do professional UI with now embedded Textmeshpro.

I love how easy UNITY is to use 'when not bugging'.

I like Addressables now that I found work arounds the bugs.

I love that the CEO sees the error of his ways and will aim to make UNity more stable so bugs don't reach us devs.

I love the tools in scene view.

I love that UNITY uses C#, it's better than Java for run speed and specific focused code for gaming.

I love that you can make general purpose games in UNITY and have more creativity than FPS in box editors. Unity is the choice for the most skilled game developers.

There are many other things I love about Unity. If you want me to write it up,I can do more. Do not think that since I blow up because you push a patch that nuked my entire system.... That I do not love Unity. I really do love Unity, please, never ever ever ever again knowingly push a patch that will cause people's editors to crash and burn.

 

Give us this option: DO NOT COMPILE AT ALL ON CODE CHANGE.

TY, every other IDE known to man does this.

Look at my above post for the video of how this bad!

 

Glad to hear this is getting rolled back. Absolutely bizarre that this change went out in the first place.

(Perhaps if you had a team who actually produced large-scale content in the engine and could spot such usability issues? Maybe some sort of demo team? Oh, wait...)

 

One thing I've noticed about "recompile after stop playing" is that it slightly changed from 2020 (or 2019) to 2021. It used to not load anything after changing code. In 2021 it was reloading something with a popup, maybe that's the reason why suddenly it started causing issues.
2021.3.5:

 

It did the exact same thing before, there was just a tiny little progress wheel and message on the status bar instead of a popup window, and apparently a lot of people never saw it, or never noticed that the editor was locked up while it was happening. They seem to have added the popup to make it clearer why the editor isn't responding, but ironically some people may have been happier when they assumed that it just took a really long time to exit playmode.

 

Wrong, I just download 2019 and there isn't any loading at all when changing code while playing.

 

If the Internal Game Production Team hadn't had been dissolved we would have definetly lobbied against this change ahead of time.

 

Sure, glad UT realizes the magnitude of the mistake and is doing a quick U-Turn. But this is a change that practically anyone who has used Unity for production of any product of any meaningful magnitude would call out instantly. That this happened is scary. Decision making this out of touch indicates underlying structural issues of an existential magnitude. If UT wants to still be around 10 years from now, a quick U-turn on a terrible decision isn't sufficient--they also need to fix whatever dysfunction led to such a decision manifesting in the first place.

 

No hotpatch yet??!?!?!?!?!?!?

Unity devs are insane. Just patch the damn thing.

How hard is it to add an option,"NEVER RECOMPILE AUTOMATICALLY!"

I have auto refresh off for a reason. I literally never want it to recompile.

You know how EASY it would be to add this option?

Look for the part the intern screwed up and it recompiles while running and simply don't do a compile. You could fix this in under 3 minutes!

And I'd be more pleased than ever... One less bulls*** compile wait gone.

I don't want new features until this is fixed, I don't want .12. Give us f2 which is EXACTLY f1, but with the option to stop trying to compile because we saved a script while debugging. Strong words are coming out because this should have been hotpatched 5 days ago!

DO NOT ADD NEW FEATURES AND TRY AND BE COOL AND MAKE A .12 before fixing this. Just HOT PATCH. Devs are losing 10,000s of hours of productivity.

Lets do Order of Magnitude calculations. You have scientists working for you right?

I spitball that you'd have about 10,000 average users a day who use it for 3 hours a day.
As they use it, they debug on average probably 10 times an hour. Of those 10 times an hour, they want to save their script every time... But if they do, they crash their build and lose about 2 minutes of work. That would be 20 minutes lost an hour per dev of 10,000 average users over 3 hours or 60 minutes per 10,000 users or lets just say 10,000 hours of development lost a day. By not hotpatching for a week, that's like 70,000 man hours Unity wasted. I personally lost about 400 myself alone, since I thought I had a computer virus, reinstalled windows. I'm not much of an outlier tho, this is wrecking us all hardcore.

Yes, some are mitigating it by trying to remember not to save. But that makes programmer's lives worse because if you actively have to think about stuff in the back of your mind productivity goes down.

Its time the community heats up til they understand they're basically telling us to pound salt by shipping us unstable patches, then refusing to hot patch. This hotpatch should have been out early last week. It is the Unity's community's #1 desire that Unity patches all these easily reproducible bugs before making new features. When I report bugs that I can reproduce 100% of the time, the bug reporting filers just say they're not bugs or other excuse to throw em in the trash. What a cool job that must be to take in feedback to improve your company and just throw it in the trash 'lah de dah, problem solved' The community is here to help Unity get better, but it's like Unity Employees are fighting vs the users like the users are the problem when we're literally telling you how to fix the code.

 

Strong words because mistakes are happening every level of Unity now.

#1: This patch should never have been approved since LTS is not to remove features.
#2: Cost devs close to 100,000 man hours lost from this failing.
#3: No hot patch despite Unity understanding the situation and having an easy fix.
#4: Unity is pushing new features while breaking old code, which as any dev knows is how you get nothing done. You always need to fix your bugs before moving on.

Unity is great, I gave reasons why above. When you gonna give us a hotpatch that could be coded in under 3 minutes and then compiled shipped in hours? For serious... Let me guess why

#5: (guess) Unity does not save old code bases of patches they sent out to revert to, and it's currently in an unstable mess now that can't get kicked out the door easily.

This frustrates us as developers because we're all generally smart as software engineers, and ignorant compounded mistakes like this should never ever ever ever happen. Is this the executives or managers then? Somewhere in Unity there is a breakdown in function. I've seen it in other companies where Yale/Harvard executives want to justify their paycheck by changing stuff that should no be changed and ruining good design/product.

 

Fellow devs, anyone back tracked your project from .11 back to .5? I thought the hotpatch would come, but I'm about ready to move to 2021.3.5 and never upgrade unless I absolutely need a feature unavailable. I don't want to rollback, but Unity is letting their broken editor sit there broke for everyone and not even caring to fix it.

 

Imagine thinking that posting three angry forum posts within the span of half an hour is going to make this happen any faster.

I think you need a break from your computer mate.

 

It does, activity on forums is one of the metrics Unity uses to decide what to prioritize. Even better if you create few threads in different subforums and send few bug reports.

 

Unity staff have already responded to this thread to say they're working on it. It still has to go through all the usual checks and balances that a large software company has to go through.

Smashing one's keyboard in a fit of rage isn't going to make that happen any faster.

 

Not only it will be faster but also will lower the chance of similar bad decisions happening in the future.

 

Over the years I've seen far too many threads where Unity staff acknowledge an issue, say they are looking into it, then years later the thread is bumped up by someone asking when it's coming (because it never did). So I won't chastise angry posters.

 

I'm not angry, I'm disappointed.

The hot patch should take less than 3 minutes to fix + compile time.

Something is very very wrong at Unity, and I think it is executives.

Patch should have been out a week or more ago.

Unity .6,.7,.8,.9,.10 were all broken too.

 

I don't know about you, but I certainly do my best work while being yelled at on the internet. /s

That was sorta part of the point of the Internal Game Production Team that Andy was a part of. Unity has long been criticised for not 'dogfooding' (that is, not actually making full use of the product they're working on), and this sort of change really highlights that. Shipping a real game using the engine, not just a small sample (and especially not a sample that required rewriting half the supposedly-included systems themselves) would have gone a long way to highlighting this sort of usability issue in real, large-scale projects.

Alas, the money people decided otherwise. Merging with a company known for distributing malware was more the sort of thing they had in mind, I suppose.

 

Yup, this man knows how it goes. You get it. The point of pointing out mistakes is for them to fix it. I even tell em how to fix it. The community waited patiently for a hot patch,a hot patch never came, so the community responds,"What gives."

If Unity devs are getting their feelings hurt for not fixing bugs in the easy manner that should take 1-3 minutes, then that's another problem. You should have GREAT feelings if you have a job that pays more than 10$ an hour. You work in game dev! You should all be happy. I'm not here to hurt your feelings. I want you happy and loving too! I'm here to say that you're doing terrible work practices like throwing shoes into the gears, sabotage level of bad work.



TO Reiterate the fix is easy:

1) Take your exact 2021.3.11f1 build that you have archived.

2) Add an option "DO NO COMPILE WHILE EDITOR IS PLAYING"

3) In the place it executes this compile while playing, just skip that.

This hot patch could have been out about an hour + compile time. We're on day 12 of something so incredibly severe that should have been fixed immediately day 1.

You literally can't break anything since 2021.3.11f2 will be exactly the same as 2021.3.11f1, except hot patched.

If UNITY is trying to add new features like this hot patch was a regular patch, well that's another failing.

If UNITY doesn't version control their live builds to have them to compile from, that's another failing.

UNITY is a multibillion dollar company and they're messing things up worse than INDIE devs, there is no defense against this Spiney199, your feelings are not meant to be hurt. We have 10,000 Unity devs suffering under this version of UNITY crashing their builds 300,000 times a day. What about their feelings? You guys don't want to play "the users are the problem" card right now, we're trying to help.

 

Hey man, thank you, that works for me as well. My Unity editor isn't crashing anymore. I'll tell the other concerned forums about it.

 

Found something similar but for

Code (CSharp):

1. [InitializeOnLoad]
2. public static class MyRefreshEditor
3. {
4.     static MyRefreshEditor()
5.     {
6.         EditorApplication.playModeStateChanged += LogPlayModeState;
7.     }
8.     private static void LogPlayModeState(PlayModeStateChange state)
9.     {
10.         if(state == PlayModeStateChange.EnteredPlayMode)
11.             EditorApplication.LockReloadAssemblies();
12.         else if(state == PlayModeStateChange.ExitingPlayMode)
13.             EditorApplication.UnlockReloadAssemblies();
14.     }
15. }

Unfortunately code is still compiled but at least not loaded to Unity in playmode.

 

You struggle with asset refresh issues? No more.

"Say hello to my little friend"

-Slap the above code from Kamyer to stop the debug save crashes.

-Slap code assembled from various sources below in your editor folder to compile only on play issued by f11 or f12-
-You now compile/play/stop with f11 or f12- (I don't know how to hijack the play button)
-You turn asset refresh off-
----What this does is NEVER do a sloppy asset refresh delay again, just do that when you compile...Like every other IDE known to man. This script will save you 20 minutes a day in an 8 hour work day...

Unity should have been doing this since day a decade ago... Not sure why it isn't an option for advanced users... Sure noobs don't know to refresh to populate serialized fields, etc etc. But experienced users refresh for that maybe once every 10 hours since playing refreshes anyway, saving em TONS of development time.

Code (CSharp):

1. using System;
2. using System.IO;
3. using System.Text;
4. //using UnityEngine.SceneManagement;
5. using UnityEngine;
6. using UnityEditor;
7. using UnityEngine.Events;
8. using UnityEngine.Scripting;
9. using UnityEditorInternal;
10. using UnityEditor.Scripting;
11. using UnityEngine.TestTools;
12. using Unity.Profiling;
13. using UnityEditor.Profiling;
14. //using UnityEngine.SceneManagement;
15. using UnityEditor.VersionControl;
16. using UnityEngine.Profiling;
17. using System.Reflection;
18.  
19. public static class GlobalKeyEvents
20. {
21.     // Exposed delegates to hook up your methods to them.
22.     public static event Action<KeyCode, EventModifiers> GlobalKeyDown;
23.     public static event Action<KeyCode, EventModifiers> GlobalKeyUp;
24.     public static event Action AnyShortcutTriggered;
25.  
26.     [InitializeOnLoadMethod]
27.     private static void EditorInit()
28.     {
29.         RegisterToGlobalEventHandler();
30.         RegisterToTriggeredAnyShortcut();
31.     }
32.  
33.     private static bool OnAnyShortcutTriggered()
34.     {
35.         AnyShortcutTriggered?.Invoke();
36.         return true;
37.     }
38.     private static void RegisterToGlobalEventHandler()
39.     {
40.         FieldInfo info = typeof(EditorApplication).GetField("globalEventHandler", BindingFlags.Static | BindingFlags.NonPublic);
41.         EditorApplication.CallbackFunction value = (EditorApplication.CallbackFunction)info.GetValue(null);
42.         value += OnGlobalKeyPressed;
43.         info.SetValue(null, value);
44.     }
45.  
46.     private static void RegisterToTriggeredAnyShortcut()
47.     {
48.         FieldInfo info = typeof(EditorApplication).GetField("doPressedKeysTriggerAnyShortcut", BindingFlags.Static | BindingFlags.NonPublic);
49.         Func<bool> value = (Func<bool>)info.GetValue(null);
50.         value += OnAnyShortcutTriggered;
51.         info.SetValue(null, value);
52.     }
53.     private static void OnGlobalKeyPressed()
54.     {
55.  
56.  
57.  
58.             if (Event.current.type == EventType.KeyDown)
59.         {
60.  
61.             KeyCode key1 = Event.current.keyCode;
62.  
63.  
64.             switch (key1)
65.             {
66.                 case KeyCode.F12:
67.                 case KeyCode.F11:
68.  
69.                     {
70.  
71.                         if (Application.isPlaying)
72.                         {
73.  
74. #if UNITY_EDITOR
75.                             UnityEditor.EditorApplication.isPlaying = false;
76.  
77. #endif
78.  
79.                  
80.                         }
81.                         else
82.                         {
83.                             UnityEditor.AssetDatabase.Refresh();
84.                             UnityEditor.EditorApplication.EnterPlaymode();
85.                         }
86.  
87.  
88.                     }
89.                     break;
90.  
91.             }
92.  
93.  
94.  
95.  
96.  
97.             GlobalKeyDown?.Invoke(Event.current.keyCode, Event.current.modifiers);
98.         }
99.         else if (Event.current.type == EventType.KeyUp)
100.         {
101.             GlobalKeyUp?.Invoke(Event.current.keyCode, Event.current.modifiers);
102.         }
103.     }
104.  
105.     }

 

A bit unrelated but it really shows how broken LTS is.

After updating from 2021.3.5 to 2021.3.11 suddenly mouse delta of new input package stopped working. Turns out it automatically updates it (from 1.3) to 1.4.2.

More bugs related bugs here: https://forum.unity.com/threads/input-system-1-4-1-released.1306062/

These LTS releases are ridiculous lately.

 

Good question.
Thanks @Kamyker this script seems to work for me. Finally.

Remember back in the days before 'Recompile after playmode' was added we also had a script to prevent recompilation. But when unity finally added the feature it was literally the only time I applauded to unity (Disclaimer: I'm not that much of an unity-advocate). Now they removed it again with something 'half baked not working (for me)' and I thought.... ok. That is unity in its purest form

 

Another +1 to getting this reverted, though I see that is already in the works. It's definitely a setting that me and my colleagues all use and find very valuable. Thanks for listening and resolving this quickly!

 

I think I get what you mean now, you're saying that in earlier 2021 releases, before the option was removed, it seemed like it was doing something new when the editor got focus back. I just switched to 2021 at the beginning of Sept, so I never saw that behavior.

An upsetting number of people always seem to be asking why the editor needs to pause at all when recompiling scripts.

 

This new behaviour was bothering me so I wrote an editor script that matches the old behaviour as closely as possible. This also prevents the short import that happens in Unity when code is changed and "Script Changes While Playing" is set to "Recompile After Finished Playing" (as illustrated by @Kamyker in #57).

With this script you can
- Enable/disable (default: disabled) the auto refresh prevention from a menu item (Extra -> Prevent Asset Refresh While Playing). It'll show a check mark next to the option when enabled and your selection persists between editor launches.
- Keep "Asset Pipeline -> Auto Refresh" enabled if you like. Assets will refresh when the editor is not playing

Note: When enabled, this script will override the behaviour selected for "Preferences -> General -> Script Changes While Playing" if you are running a version of editor that still supports that option.

To install
- Place the script in your "Editor" folder
- Go to the menu in your editor and select "Extra -> Prevent Asset Refresh While Playing"

Code (CSharp):

1. using UnityEditor;
2. using UnityEngine;
3.  
4.  
5. /// <summary>
6. /// Prevents the asset database from refreshing while the editor is in play mode.
7. /// This means that any changed assets aren't imported and changed source isn't recompiled.
8. ///
9. /// NOTE: When this is enabled it overrides the behaviour of
10. /// Preferences -> General -> Script Changes While Playing
11. /// (In versions of Unity that include that option)
12. /// </summary>
13. [InitializeOnLoad]
14. public static class PreventAutoRefreshWhilePlaying
15. {
16.     private const string MENU_PATH = "Extra/Prevent Asset Refresh While Playing";
17.     private const string PREFSKEY_IS_ENABLED = MENU_PATH + ":IsEnabled";
18.  
19.     private static bool s_IsAutoRefreshDisabled = false;
20.  
21.     private static bool IsEnabled
22.     {
23.         get => EditorPrefs.GetBool(PREFSKEY_IS_ENABLED);
24.         set => EditorPrefs.SetBool(PREFSKEY_IS_ENABLED, value);
25.     }
26.  
27.     static PreventAutoRefreshWhilePlaying()
28.     {
29.         EditorApplication.playModeStateChanged += EditorApplication_PlayModeStateChanged;
30.     }
31.  
32.     [MenuItem(MENU_PATH)]
33.     private static void ToggleEnabled()
34.     {
35.         IsEnabled = !IsEnabled;
36.  
37.         if (IsEnabled)
38.         {
39.             EditorUtility.DisplayDialog(
40.                 "Note",
41.                 "Enabling this option prevents assets and scripts from reloading while the editor is playing. This overrides the behaviour of \"Preferences -> General -> Script Changes While Playing\".",
42.                 "OK"
43.                 );
44.         }
45.  
46.         bool shouldPreventRefresh = IsEnabled && EditorApplication.isPlaying;
47.         if (shouldPreventRefresh)
48.         {
49.             PreventAutoRefresh();
50.         }
51.         else
52.         {
53.             AllowAutoRefresh();
54.         }
55.     }
56.  
57.     [MenuItem(MENU_PATH, true)]
58.     private static bool ToggleEnabled_Validator()
59.     {
60.         // Make sure the menu is showing the correct checked state
61.         Menu.SetChecked(MENU_PATH, IsEnabled);
62.         return true;
63.     }
64.  
65.     private static void EditorApplication_PlayModeStateChanged(PlayModeStateChange state)
66.     {
67.         if (!IsEnabled)
68.         {
69.             return;
70.         }
71.  
72.         switch (state)
73.         {
74.             case PlayModeStateChange.EnteredPlayMode:
75.                 PreventAutoRefresh();
76.                 break;
77.  
78.             case PlayModeStateChange.EnteredEditMode:
79.                 AllowAutoRefresh();
80.                 break;
81.         }
82.     }
83.  
84.     private static void PreventAutoRefresh()
85.     {
86.         if (!s_IsAutoRefreshDisabled)
87.         {
88.             s_IsAutoRefreshDisabled = true;
89.             AssetDatabase.DisallowAutoRefresh();
90.             Debug.Log("Auto asset refresh disabled.");
91.         }
92.     }
93.  
94.     private static void AllowAutoRefresh()
95.     {
96.         if (s_IsAutoRefreshDisabled)
97.         {
98.             AssetDatabase.AllowAutoRefresh();
99.             s_IsAutoRefreshDisabled = false;
100.             Debug.Log("Auto asset refresh enabled.");
101.  
102.             AssetDatabase.Refresh();
103.         }
104.     }
105. }

 

So it's been 10 days since this message, and since there's been no new 2021 release (either 2021.3.12 or 2021.3.11.f2); I think it's reasonable to ask for an actual, real world ETA on this issue - saying it's "the most important thing" isn't enough information to generate trust at this point.
Thanks in advance.

 

Spiney199, remember when I said it was of CRITIAL IMPORTANCE to fix the bug? Famous Youtubers who love Unity are being frustrated now.

They, like I say that we still love unity despite instability... If a Hotfix was made 14 days ago in 3 hours, these things would not be happening. You are simply not aware of just how bad this is for Unity and this is why I raised alarm days ago so this type of honest evaluations did not come in.

Remember, the users are not the problem, we love Unity and want to help. The problem is that there is a bugged version of editor that's out live. No one should ever leave bugged live vesions of software live, this is why you roll back if you can't hotpatch. I know .5 had the least bugs. Maybe have it be live for new users and .11 only if people want it for their rolled up version. Having bugged software live makes you lose active users, statistically you'll maybe lost a % of your long term users and did not retain new users. Both reverting versions or recompiling a new version should take only moments and much less than an hour. They're standard procedure in most production houses.

We're all very very supportive of Unity. Raising an alarm is what you do when a fire is going on. You do not just sit there and go,"This is fine." We want Unity to succeed so a standard methodology rapid response was/is called for.

 

That's nice honey. Maybe if you colour your text some more it will make me care slightly more than not at all.

Youtubers will find any reason to make a video. It's not exactly revelatory. I wouldn't call 17K subscribers 'famous' either.

This doesn't even pertain to my original response to you, which was calling you somewhat unhinged for your repeated rage-posting.

 

I think the main problem Unity has is simply too many, untested (by community) LTS releases. It's a wrong shipping model.

There should be public preview version of lts release that could be hotfixed daily. After some time when all major bugs are found and fixed it can be finally shipped. Many companies have so called nightly versions of their products. Unity should do the same.

Otherwise what we have now are random LTS releases, not tested by game devs. When you find a game breaking bug it will take Unity another 2-3 lts releases (2 months) to fix it.

 

Red and Null in 2022.2 is becoming my best friend. I hope we can get a fix soon.

 

For some reason, even though it was a high priority critical issue, we still don't have a patch to fix this problem. The word of the Unity developers has become unreliable.

The fact that they removed this feature already indicates how little they use unity (at least on a professional level), and I find it unbelievable that studios and devs had to lose their entire workflow overnight on an LTS release.

 

In Unity 2022.1.13f1, the "Recompile After Finishing Playing" option is listed, but ignored (!). No matter what you set, it will always do like "Stop Playing and Recompile" is defined.

 

Comes down to unity does not make games with their engine. Mentioned many times all over.
And recently has done very little in terms of big name actions to say they are really interested in having users keep making games with unity.

Buying 3d VFX company, simulation, meta verse stuff.
While still having so many packages in preview for core features.

I really wish my job was making demos that only need to work a few time in under very specific cases. Life would be great vs trying to make a real game.

They just need to give out source. At least with UE I could go and attempt to fix it or comment it out until they updated.

 

Does Unity give you biscuits for every smarmy reply you make to frustrated Unity users, sugar?

 

Hey maaan thank youu, any advice about how to use it ?

By the way +1 to this question

 

this works perfect for me thnx good sir +1000 for you

 

I think the biggest issue is the fact that this feature was removed in an LTS release.

https://unity3d.com/unity/qa/lts-releases states:
"These updates will only cover fixes aimed at improving the stability of the product to enable users to ship their projects."


@Kamyker 's post here is the same issue:
https://forum.unity.com/threads/rec...etter-say-removed.1335368/page-2#post-8506265

Why does the LTS version update the Input System package automatically?
Why does this happen with any package in the first place?
Good UX would be a popup asking for permission.

Updating LTS versions should be a no brainer. Something safe to do, without the concern of either breaking the project or introducing new bugs. That's the promise.

As many of us I've worked for years with Unity, and as of now there are only three reasons for me personally to actually update:

1) You absolutely need one of the new features
2) The current version has bugs which break the project or are (very) annoying and introduce pain points for the workflow and those bugs are fixed in a higher LTS version
3) I'm forced due to other influences (publishers, platform SDKs/policies, etc.)

If none of these is true I simply don't update, but I could at least trust in LTS, since LTS is a promise to us. A contract.
Since packages now are automatically updated, I need to scour through the forums and check out if there any problems with the updated package versions.
Because now a new scenario was introduced:

When I am on an LTS version and the current version has a bug, and this bug is super annoying and there is new version with a fix, but this newer version updated also some new packages, but those new package version introduced some new bugs which introduce bugs/faulty behaviour into my game, so I have to balance the pros and cons of this then, too...but this scenario is not too dramatic I guess, since I can update the engine version and downgrade the packages again (at least I think that's possible), but all of this feels so unnecessary convoluted and is just plain bad UX.

LTS was a promise and by breaking this promise we're entering a state of uncertainty. Pls keep that promise up (by not removing features in LTS) and also introduce a better UX for package updates like asking for permission to actually update them.

 

@jrdewsen
it's been nearly 3 WEEKS since this message and no new 2021 version for like, a month.
If not an ETA, can we please get a link to an issue in the Issue Tracker?
I don't want to have to come back here for each new message to check if it's proper info from Unity or rants from understandably frustrated users.

 

I said this above... UNITY LOST THE TRUST of their users. This cannot be over stated. I used to update painfully knowing bugs happen... But now,like you, we learned never to update. If its painful/time consuming/frustrating to do small updates because UNITY does not test properly, then we merely never update until LONG JUMPS later. If small steps are long jumps, then developers know to just wait to do one long jump at a time.

I'm glad I'm not the only advanced software engineer in this forum stating this. Sometimes when you're in a sea of voices of people who don't know anything, experts like yourself and I get drown out.

 

I hear Electronics Arts is hiring for their new game,"Barbie's Dog and Pony Show Simulator"

When I watched The CEO do this interview:

All I could think of is:

Stability is what everyone wants, but he gave you 'You UNITY developers are so great, you're so cool." I do honestly hope he does make things stable with people still requesting of him... But I'm feeling we'll be riding the monorail a bit longer.

 

Unity, can you hurry and fix this please so I don't have to see this guy's posts anymore.

 

this woks, but creates a bit amount of time when exit play mode (even when not compiling anything new) :C

 

Hmm, does it take the same amount of time if you right click on your "Assets" folder and select "Refresh"?
I don't have a large project to test with at the moment but I imagine if your project has many files it may take some time. I don't think there is a way around this but you could comment out the "AssetDatabase.Refresh()" line and just know that you either have to manually refresh or will need to make a change to an asset before your next build....Not a great option.

 

I'll throw in a +1 to this issue. Unless a game has been carefully structured to survive a script reload while running(which is very rare), every developer I've ever worked with *always* sets this to Recompile After Finished Playing. You fix multiple bugs as you playtest and then stop to recompile. It was quite a shock to update to 2021.3.11 to get some unrelated improvements and find this option missing. Please fix asap!

 

A solution that works for me: Rolling back to 2021.3.5f1. I recommend all to do this that experience the inability to debug anymore on more recent corrupted LTS versions.