To buttress this, I’d rather go without a Dictionary serializer than give up the serializaition callbacks and Odin. I’ve gotten by just fine for the last fifteen years without native dictionary support but one of the first big editor tools I had to make for myself was a generalized inspector handler for arbitrary objects. Odin was the replacement for that and frankly, I never want to go back to the monstrosity that I’d used before.
Being able to handle serialization manually at the right time is far more valuable than being able to handle a dictionary with any key type, much less a dictionary with just a few. It’s in fact, what most of us USE to handle dictionaries.
Any plans to support hotreloading? Being able to make a game and test changes without turning off playmode is basically the dream goal.
I know this is not an easy task, but wondering if it is ever considered / is it even possible technically with unity.
There are some plugins that “hack” methods around it and they kinda work, just being supported officially would be much better.
Just to add +1 to what @PanthenEye said: We also rely a lot on [SerializeReference] and ISerializationCallbackReceiver interface and it would be catastrophic if the replacement doesn’t cover all cases.
The serialization of SerializeReference fields in particular have gone under a lot of formats, but I like it a lot the current implementation, where all “rid” values are at the root level. It’s simple and works.
Can we hope to see full support for nullables with CoreCLR, with nullable aware Unity APIs?
Actually could we have a way to enable nullables everywhere in a project even before nullables?
Currently, we can use a .csc files for compiler support, but VS still doesn’t recognize it.
What do you mean by ‘full support’? As far as I know, they work just fine already in Unity.
As for API awareness, I wouldn’t expect that to be likely. ECS For All is their new initiative for the backend of the engine and nullables kinda go against the grain of that.
Nullables enabled in csproj file. So as we go from asmdef to csproj you will have full support in IDE
to make it work with VS you need to add csproj post processor to add <_Nullable>enable</_Nullable> string
ECS is only backend and low level. On high level they very handy.
Nullables in C# is exactly solution for this issue. Because it make all C# reftype that is nullable by default - to be NON NULLABLE And to make them nullable you need express this explicitly.
With Nullables enabled most of your code become NON nullable
But it is not enough by itself because it is nullable warnings. to make them errors you need to make all warnings to be errors or only warnings relates to nullables.
I go second route with all my packages. it is again setup in csc.rsp
Also Nullables in not runtime guarantee, they are complier analytics so they dont eliminate
entire “The Billion Dollar Mistake” but big part of it
The normal Lifecycle Callbacks needs to be setup before the static constructor is called, and because of that can’t depend on the static constructor to first run to subscribe to the events.
But AutoStaticsCleanup we do exactly what you propose, and use Source Generators for it so you can see it:
public partial class StaticGenericType<T>
{
[AutoStaticsCleanup]
public static int Counter = 0;
}
Generator:
partial class StaticGenericType<T>
{
[System.Runtime.CompilerServices.CompilerGenerated]
class UnityEngine_PlayModeScopeAutoCleanup_Both_AutoCleanupType: UnityEngine.PlayModeScopeAutoCleanup
{
public override void Cleanup()
{
Counter = 0;
}
public UnityEngine_PlayModeScopeAutoCleanup_Both_AutoCleanupType() : base () {}
}
[System.Runtime.CompilerServices.CompilerGenerated]
static readonly UnityEngine_PlayModeScopeAutoCleanup_Both_AutoCleanupType _UnityEngine_PlayModeScopeAutoCleanup_Both_AutoCleanupType = new();
}
Nicely spotted, we also found this internally and the mismatch of the order in the Player.
We have changed the behavior so OnEnteringPlayMode happens early, and its the same as in the Player’s initialization, so one of next alphas will contain this fix
We are a restricted to what callbacks we can get from the platform, so OnExitingPlayMode will have the same problems as OnApplicationQuit when the app is moved to the background.
Also curious if there’ll be matching attributes for entering/exiting edit mode.
Currently EditorApplication.playModeStateChanged gives us an attribute with four options. The specific timing of exiting edit mode -> enter play mode -> exiting play mode -> entering edit mode can be pretty useful in certain cases.
Personally I would’ve preferred a single attribute with a flags enum parameter to let us opt into any of the four timings (and allow the method to also take said attribute as a parameter as well). Feels leaner to me. Though I can understand not wanting to include potentially editor-only parameters to something in the runtime namespace.
(And I’ve also already made my preferred solution for myself in any case)
We considered the enum, but instead of having a enum that just grows of the “state”, like what happened with the RuntimeInitializeOnLoad, we wanted to be specific in the attribute of what is happening and order. So you can map it to a enum based on these callbacks if that is best for you.
And to make them nullable you need express this explicitly.
