Need API for Manual Initialization of PrimeTweenManager

[JohnBaracuda]

Hi, I am porting my game from DOTween to PrimeTween and encountered an initialization issue. My game uses a custom installer system that runs during [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]. This ensures all global settings and managers are set up before any Awake() methods are called, allowing me to basically start from any scene without without any issues.

However, PrimeTweenManager also initializes during [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)] which causes a problem because it always runs after my installer. As a result, any UI isntances with Tweens that I spawn or calls to PrimeTweenConfig trigger the error:
"Please don't call PrimeTween's API in Edit mode"

To work around this, I manually invoke the beforeSceneLoad() method from my installation method via reflection:

foreach (var type in typeof(PrimeTweenConfig).Assembly.GetTypes()) {
    if (type.Name == "PrimeTweenManager") {
        Debug.Log("Found PrimeTweenManager, initializing manually!");
        var method = type.GetMethod("beforeSceneLoad", BindingFlags.Static | BindingFlags.NonPublic);
        method!.Invoke(null, null);
    }
}

This solution is obviously fragile and will break anyway in builds because the Assert in PrimeTweenManager.beforeSceneLoad() will be stripped, leading to duplicate managers.

So here is my suggestion to fix this:
• Expose an API to manually initialize the PrimeTweenManager.
• Add a public Initialize() method that can be called early.
• Use a static _isInitialized flag to prevent duplicate initialization.
• Reset _isInitialized during [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.SubsystemRegistration)] to ensure proper domain reload behavior.

Or you can add lazy initialization, which initializes the entire system as soon as the instance is accessed. In the editor, you can use Application.isPlaying to check if the play mode or edit mode is currently active. The message "Please don't call PrimeTween's API in Edit mode" is incorrect because it isn't actually checking if we are in edit mode; rather, it's checking if the Instance of the PrimeTweenManager is null.

This would allow users to control initialization order while maintaining the existing automatic setup as a fallback.

[KyryloKuzyk]

Hey @JohnBaracuda, thank you for the great suggestion!
Before jumping ahead and implementing this feature, may I ask more questions?

1. Would it be possible for you to change your initialization script to use `RuntimeInitializeLoadType.AfterSceneLoad?
2. Why do you create UI tweens inside the BeforeSceneLoad? I would assume that inside the BeforeSceneLoad callback, the scene is not yet completely loaded, so starting animations might cause problems.

The thing is, I never designed PrimeTweenManager to be null at runtime, hence the error wording that mentions Edit mode. Also, doing lazy initialization on the first call will lead to huge initialization spikes, so I create PrimeTweenManager and allocate all the necessary memory at the earliest possible moment.

[JohnBaracuda]

Hi @KyryloKuzyk, thank you for considering this.
My game architecture requires initialization during BeforeSceneLoad to ensure all persistent systems (including certain UI elements) are fully operational before any Awake() methods execute. Moving this to AfterSceneLoad would disrupt core functionality for several important reasons.

Multiple scene objects depend on managers and UI systems being immediately available, with many components injecting these references during their Awake() calls. This initialization approach is fundamental to my scene-independent workflow because it guarantees all core systems are ready regardless of which scene I start from. Additionally, since I manually instantiate all critical systems (global settings, managers, etc.) during BeforeSceneLoad, I maintain complete control over the initialization sequence and avoid any race conditions.

I do use a Bootstrap scene for builds, which I've now realized would allow PrimeTween to work perfectly fine in builds. However, my current setup provides significant advantages for development, which is where I would need the manual Initialization API.

To directly address your questions:

I cannot move to AfterSceneLoad because my architecture relies on systems being fully initialized before any scene objects attempt to access them in Awake().
The UI tweens during BeforeSceneLoad are for persistent UI elements (like loading screens and settings menus) that exist outside the scene hierarchy. These aren't scene animations but rather core UI components that must be available immediately.
If you'd like more details or insight about how this all works I'd be happy to share more with you.

[JohnBaracuda]

HI @KyryloKuzyk I wanted to check in and see if there are any updates on this and if this is still being considered. Also, let me know if you need any additional information :)

[KyryloKuzyk]

@JohnBaracuda I'm loaded with other work right now, but I'll definitely answer this thread once I have any progress or any questions :)

[KyryloKuzyk]

@JohnBaracuda I added an experimental PrimeTweenConfig.ManualInitialize() method in version 1.3.1. Please update and tell me if this works for you.

To enable experimental features, please add the PRIME_TWEEN_EXPERIMENTAL define to the 'Project Settings / Player / Other Settings / Scripting Define Symbols'.

[JohnBaracuda]

Hi @KyryloKuzyk, this works, thank you!

I noticed one small thing: PrimeTweenConfig.ManualInitialize() throws an error if PrimeTweenManager.HasInstance is true. It works fine for me right now, but since I am not sure if the order of RuntimeInitializeLoadType.BeforeSceneLoad callbacks is guaranteed, I'm slightly worried this might randomly break later if the execution order changes.

Would it make sense to either remove that error check (since calling it after initialization seems harmless), or expose HasInstance publicly so we can check if initialization is needed first? Alternatively the method could just return a bool to indicate whether initialization happened.

Either way, really appreciate you adding this :)

[KyryloKuzyk]

The order of RuntimeInitializeLoadType is defined, and it's unlikely Unity will introduce such a breaking change.
https://gist.github.com/hybridherbst/36ae70b6520981c8edc7b478423fae5e

Also, PrimeTween doesn't throw an exception in the case of HasInstrance, but just logs an error, which will not break your project even if the order of RuntimeInitializeLoadType changes.