Can something please be done about Unity’s silly “hey, you just created an empty script, let me quickly recompile and reload everything, why would I wait for you to actually edit that script and put something in there?” behaviour?
You really start to notice it when you create a bunch of simple classes in quick succession.
Yes, sure, I can go into the editor config and completely disable reloading, but that’s not what I want, either (and disabling and re-enabling it all the time costs even more time). Is there maybe a way to delay this nonsense? Something like: “hey, if I just created a new script and then opened it up in the editor, maybe just maybe you could wait a few seconds because almost certainly I didn’t create that script just to sit there but I’m actually working on it?”
But it’s not even the problem here. The problem is that Unity triggers a reload as soon as you add a .cs file. Even if that file is empty.
All I want is a “create new script and open it for editing, and wait with the f&&%! reload until I’ve saved the first time.” behaviour. Because 99% of the time, when someone creates a new script, they intend to put something into that script, right?
I mean adding a new script is adding a new class, which requires a domain reload.
Adding a script without causing a reload would require adding it without causing an asset database refresh, or adding it not via Unity. You can probably just do this via your code editor.
It’s just that the current behaviour causes it to reload multiple times. First when the script is created, then when it is edited and saved.
The most common use case, however, is that a newly created script will be immediately edited, so Unity could well delay the reload for a bit.
Especially when writing a bunch of small scripts, reloading quickly becomes half of the time it all takes. The workflow becomes: create script- wait for Unity to reload - edit three lines - save - wait for Unity to reload - repeat.
Yes, that might be a problem not everyone has. My code editor is ScriptInspector, so I do my editing inside the Unity Editor. Which is a ton more convenient than an external editor.
But even ignoring that, there are plenty of assets out there where you create scripts through a wizard or menu entry and then customize them.
I’ve been dealing with this issue for years now and it’s so frustrating.
There are plugins available to help mitigate these issues, I feel Unity should provide them free / heavily subsidised until they release their own solution:
No, they shouldn’t. It would be absolutely senseless to do something like that. You’ re mildly inconvenienced now so you should get a free asset? What?
It isn’t a minor issue at all. It’s an issue unity introduced in their engine years ago and haven’t fixed. If you read the forums you’ll see a lot of people are frustrated by it even to the point of using other engines.
The issue causes delays and distractions. The issue is a big problem, just read the case study of the studio that created the plugin. And all the people buying it. Then look back at when the initial threads about the issue were first created.
In regards to free… Unity has acquired many plugins over the years, integrated them and offered them free. TextMeshPro, ProBuilder, Bolt (now visual scripting). I’m also happy with discounted.
In a time where unity is trying to gain favor with developers after a number of missteps, it would go along way to acknowledging the issue they’ve created.
Anyway, if it doesn’t affect you I’m glad. But it affects a lot of others and has done for years. It’s more the point that if a 3rd party can create a fix, it would of been nice for unity to acknowledge and provide some respite whilst they fix it in the long term.
FYI, I’m in a position to spend the money on the plugin (and have), others, especially indies and those in developing countries may not be able to.
I like unity and I only mention this as it would be a big help to the community and the company.
It wasn’t really ‘introduced’. They had a choice of back ends to take and they took the one that made sense at the time (mono). Only through the power of hindsight can we see that it was the wrong choice.
Now to fix it they have had to unwind about a decade of technical debt that is built on this back end. They’ve been aware of it for a long time, and have been working to fix it for equally as long.
We’ll get the CoreCLR version of Unity when it’s ready. For the time being the idea of Unity acquiring a plugin that is more of a hack than a fix is a really bad idea, especially as it can introduce as many issues as it solves.
It is a minor issue and there are ways to mitigate its impact if you bother to adjust your workflow even a little bit. Don’t try and make this a “think of the developers in low income conditions” thing.
Not sure why you’re so angry about it? As I said, if it’s not affecting you that’s great. Doesn’t mean it isn’t affecting others.
Trying to adjust a project and implement workarounds is non trivial. And yes, I’ve done all the ASMdef techniques, the disable domain reloading, disabling anti virus etc etc. None of it works as well or as fast as the plugins custom complier method.
When you use TextMeshPro in your project, that plugin was made because of limitations in unity original text engine. They bought it and made it free to the benefit of all.
I know about the CoreCLR move, it’s been on the books for years. From my understanding, the slower recompiling wasn’t because of mono, it was because they rewrote stuff in c#, package manager etc. (I mean I understand mono has the limitations but it wasn’t as bad until they made some changes).
You’ll hear from us who remember earlier editor versions that were very quick to compile and iterate.
This plugin actually has a custom compiler built in to quickly compile and patch just the specific code change made. Until they get to the CoreCLR it’s handy to have this tool even with its caveats.
My main point is that to all the many people it’s affected, (for years), it would be a nice solution until they update to coreCLR.
At the end of the day I just want to develop games and have the tools work quickly .
They bought TMPro and implemented it, yeah. They are creating their own solution to these problems and implementing those. What you are asking is that they buy something and make it free while they implement a feature that will deprecate the thing they bought in the first place.
Except these are all simple things to learn, especially if you’re already in a position where you’re making a game, something that is already complex. Especially if your game has enough scripts that this sort of thing has become a “significant problem.”
Like I said, agree to disagree. It’s a problem that affects people, including the company that made the plugin with 40 approx employees apparently. Check their site to see the savings they make each month per employee with the plugin.
They are not the only company that’s made a plugin, there’s also one that’s been made free an open source but not as good.
The play mode options etc with “disable domain reloading” etc was implemented because of this issue by unity as a workaround with its own caveats.
I’m not suggesting they change their road map or integrate the plugin officially either. Just suggesting free or discount as an acknowledgement to this long running issue.
Anyway, once again if it doesn’t affect you then it’s all good. For others it is a big problem because even a small amount of complie delay interrupts developer flow. Every language and ide tries to make compiling faster with hot reload etc (look at all the tools for react that do just this, for free).
If these free options do such a good job, just use them instead instead of saying Unity should buy somebody out just to deprecate that solution within a year.
Again, I’m not sure why you’re so passionate about this, if the issue doesn’t affect you.
That doesn’t mean it doesn’t affect a lot of other people for many years:
This plugin offers a good solution until they can fix it. I merely suggested as an act of good faith they could permanently discount it or make it free.
This could also take the pressure off them a bit as less complaints from users.
I will say that I’m glad to not have to think about this slow compilation issue anymore and can concentrate on actually making games!
Again, why should they do this when they are rolling out an entirely different solution within the year, there are free options that already exist, and there are internal solutions that mitigate this?