@HaraldNielsen can you answer, please? Thanks
Yes more than these 4, and over time we also want to open up for the API for Users can define their own callbacks using the same system
Hi Bdovaz
Did you refer to the Enum question above?
If you look closely, in my message I was replying to a message I posted a few days ago.
But anyway, to sum it up, my question is whether it will be possible to install NuGet packages, use .editorconfig, and generally use the tooling just like in a normal .NET project.
No related announcement at this time. If and when that changes Iâll link it in this thread.
Can someone explain to me, when they mention CoreCLR for the Editor - Does that mean will see large performance improvements to working in the editor in general? Would love a snappier and smoother editor experiance.
You can use GitHub - bdovaz/UnityNuGet: Provides a service to install NuGet packages into a Unity project via the Unity Package Manager ¡ GitHub or GitHub - GlitchEnzo/NuGetForUnity: A NuGet Package Manager for Unity ¡ GitHub . I prefer the former.
Thatâs the long-term goal - and CoreCLR Editor is a necessary milestone to unlock that future - but in 6.8 alpha weâre shooting for performance parity.
Fantastic! I know On my Mac I get some issues, a weird one where that canât be fixed is the âQualityâ Setting tabs in the project settings, scrolling up and down it lags like hell and itâs the only tab to do so, everything else so far so good.
Keen for general performance improvements, didnât relise that CoreCLR would effect the Editor itself so that is awesome.
Iâm very familiar with the UnityNuGet project; Iâm its owner and maintainer since almost the very beginning.
Thatâs why I asked about NuGet support, because once itâs available, UnityNuGet project will be dead and will only be useful for older versions of Unity.
so the long domain reload and recompile loading bars wonât be gone?..
Weâre working towards that outcome, but at the moment we donât want to promise that weâll have completed all the changes there in time for 6.8.
For Unity 6.8 all we are saying you should expect is âperformance parityâ - i.e. it will not be slower than Mono to iterate on your code with CoreCLR - but it may be that we donât get to the big performance wins until 6.9+.
I get it, but I think you should all be prepared for a big group of people whining about âis that it?!â.
On the other hand, letâs not forget how DX12 performance parity with DX11 went (or still ongoing, idk cause I abandoned the idea totally and decided to stick with DX11)
Exactly why weâre trying to set expectations early ![]()
I think some specific performance charts going around with poor interpretation might undermine this effort.
When we can provide data that better represents a real-world project - hopefully pulled from a real-world project - Iâll share.
When the Entities package becomes integrated in the editor, would we still be able to see its code?
Can you jump straight to C#15 support ? Union type please!
The existing functionality will be split between an internal module and a package. The package will be more-or-less as accessible as it is today.
Which set of types and functions go where isnât final, but in general weâre only looking to move whatâs strictly necessary into the internal module (very basic types and their support functions).
how exactly will the whole thing work after the integration? ive seen how dots works but never used it, will the editor ui change? will we need to do anything differently or write diff code?