"Enter Play Mode Options" unchecked causes Avatar Optimizer component to be deleted too early when entering Play Mode

[hai-vr]

I'm taking a shot in the dark here, I'm not sure whose responsibility it is to provide a fix, or whether it is in scope.

I normally use projects with the "Editor > Enter Play Mode Options" option ON, with Reload Domain and Reload Scene unchecked. Last week I accidentally left this option OFF in order to test a release, and this caused a change in behaviour that I had only noticed today.

I'll turn that option back ON but I'm documenting the difference in behaviour here:

---

When "Enter Play Mode Options" is unchecked, the Avatar Optimizer component is deleted too early when entering Play Mode, so it cannot be processed by the Avatar Optimizer pre-processor callback.

Steps:

• Av3 Emulator is already active in the scene.
• The avatar has d4rkAvatarOptimizer, and d4rkAvatarOptimizer is configured to execute in Play Mode.
• The setting "Editor > Enter Play Mode Options" is checked OFF,
• I enter Play mode.

Observed:

• NDMF will immediately process the avatar,
• The d4rkAvatarOptimizer component gets deleted, presumably because it is IEditorOnly,
• The d4rkAvatarOptimizer avatar pre-processor (AvatarBuildHook : IVRCSDKPreprocessAvatarCallback) will run, but not find d4rkAvatarOptimizer component, so it doesn't do anything
• PreventStripTagObjects then executes.

Expected:

• NDMF will immediately process the avatar,
• The d4rkAvatarOptimizer avatar pre-processor (AvatarBuildHook : IVRCSDKPreprocessAvatarCallback) should run.

Expected is the current behavior when "Editor > Enter Play Mode Options" option is ON, but it also is the behavior for when the avatar is being built normally for upload.

---

My suspicion is that when "Editor > Enter Play Mode Options" is checked OFF, RemoveAvatarEditorOnly may not be removed fast enough by PreventStripTagObjects upon entering Play Mode as it is a delayed call; whereas when "Editor > Enter Play Mode Options" is checked ON, that pre-processor is removed before even entering Play Mode.

As a reminder, Avatar Optimizer doesn't have a dependency on NDMF (it is not a Plugin), but it has a conditional compilation that checks if nadena.dev.modular-avatar is installed which alters the callback order from -1025 to -15.

[bdunderscore]

Hmm. I could try patching this out using Harmony, but I've heard rumor that this behavior might be changing in the SDK soon...ish, and so I'm a bit reluctant to be making changes here for the benefit of a third-party optimizer...

I could maybe pull the order of the NDMF optimize pass back to leave room for d4rk to slot in between the two?

[bdunderscore]

Note that we currently use DelayCall because the list we're manipulating is initialized in VRCBuildPipelineCallbacks.Initialize, which is an [InitializeOnLoadMethod]. As such, invocation timing is undefined between our initializer and VRCSDK's.