[3.10.2,3.10.3] VRCSceneTemplateInitializer does not create sample scene if UDON preprocessor symbol is defined at first launch since VRCSDK 3.10.2. | Voters

[3.10.2,3.10.3] VRCSceneTemplateInitializer does not create sample scene if UDON preprocessor symbol is defined at first launch since VRCSDK 3.10.2.

anatawa12

VRCSceneTemplateInitializer

does not create the default sample scene when the

UDON

preprocessor symbol is already defined on the first launch.

Steps to reproduce

Prepare a VRChat Worlds template with the
UDON
preprocessor symbol already defined.

The original report used a project template generated by ALCOM 1.1.5 or earlier. (We added a workaround in 1.1.6.)

However, the issue can also be reproduced by modifying a VCC template to include the

UDON

preprocessor symbol in

ProjectSettings.asset

For reference, ALCOM's Worlds template included the

UDON

preprocessor symbol to reduce the initial Unity launch time by avoiding recompilation of most assemblies.

Launch Unity.
VRCSceneTemplateInitializer
should create the default scene, but it does not.

Cause of the bug

This bug is triggered by the combination of the following conditions:

UdonSharpDataLocator
does not exist in the project. This causes
Assets/UdonSharp/UtilityScripts
to be generated during the first assembly load.
The
UDON
preprocessor symbol is already defined before the first compilation. This causes
[InitializeOnLoad]
in
VRCSceneTemplateInitializer
to run during the first assembly load.

The sequence of events is as follows:

Unity compiles scripts normally.
Unity calls the static constructor of
VRCSceneTemplateInitializer
because of
[InitializeOnLoad]
.

VRCSceneTemplateInitializer

checks

SessionState.GetBool(HasRunStateKey, false)

, which is

false

, so it sets

HasRunStateKey

true

and registers an

EditorApplication.delayCall

to generate

VRCDefaultWorldScene

Unity calls some
[InitializeOnLoad]
methods from UdonSharp, and UdonSharp generates
Assets/UdonSharp/UtilityScripts
.
Unity recompiles
Assembly-CSharp
and reloads the domain.

Note that the registered

delayCall

is never executed before this reload.

Unity calls the static constructor of
VRCSceneTemplateInitializer
again because of
[InitializeOnLoad]
.

This time,

SessionState.GetBool(HasRunStateKey, false)

returns

true

, so nothing happens.

As a result, the logic that generates

VRCDefaultWorldScene

is never executed.

(The order of steps 2 and 3 may differ, but the result is the same.)

For comparison, the following sequence does

not

cause the bug when the

UDON

symbol is not initially defined:

Unity compiles scripts normally, but the
VRC.SDK3.Editor
assembly containing
VRCSceneTemplateInitializer
is not compiled because of
"defineConstraints": ["UDON"]
.
Unity calls some
[InitializeOnLoad]
methods from UdonSharp, and UdonSharp generates
Assets/UdonSharp/UtilityScripts
.
EnvConfig.cs
checks for
VRC.Udon.UdonBehaviour
and adds the
UDON
preprocessor symbol.
Unity recompiles all assemblies and reloads the domain.
Unity calls the static constructor of
VRCSceneTemplateInitializer
because of
[InitializeOnLoad]
.

SessionState.GetBool(HasRunStateKey, false)

returns

false

, so it sets

HasRunStateKey

true

and registers an

EditorApplication.delayCall

that generates

VRCDefaultWorldScene

Unity executes the
EditorApplication.delayCall
, and
VRCDefaultWorldScene
is generated correctly.

Suggested fix

The issue is that

HasRunStateKey

is set to

true

before the

EditorApplication.delayCall

is actually executed.

I believe moving the

HasRunStateKey

assignment into the

EditorApplication.delayCall

lambda would fix the issue.

5 days ago

anatawa12

As mentioned above, although the original report used an ALCOM-generated template, this issue is reproducible with custom VCC templates, so the issue itself is not specific to ALCOM.

Also, I have already implemented a workaround/fix on the ALCOM side for the next release.

venn02_ヴェン

anatawa12
If that's the case, I think all we need to do is output the VCC logs, and ALCOM can handle the fix from their end.
We mustn't forget that ALCOM is, after all, an unofficial tool.

天白ゆうか

anatawa12
You did what you were supposed to do this time.
However, in the future, before officially requesting a fix in a place like this, you should investigate and fix the cause of any future problems yourself.
Don't make a mistake; your Alcom is third-party software, not an official product, so you should not ask VCC to fix any problems it causes.

Val_eins

Why aren't you using VCC?

天白ゆうか

VCC is performing tasks that are not normally done, so why are you asking them to officially fix it? If you are an Alcom engineer, shouldn't you be able to fix Alcom yourself to prevent this bug from occurring?

If you can't do that, then I think Alcom should be taken private immediately, before more people have their important projects ruined because of bugs like this.

Sayamame

天白ゆうか 
As mentioned in the Canny text, this issue can be reproduced in VCC environment using the custom template feature.
ALCOM is only the thing that led the author to discover this fact.
The fact that a bug exists in the SDK and the fact that ALCOM encountered this by behaving differently from VCC are separate issues, so I think they should be addressed individually.
That said, regardless of whether or not this bug should be reported, it’s ultimately up to the VRChat team to decide how much priority to give to fixing it, I think.

天白ゆうか

Sayamame
If the issue is reproducible in VCC, the correct approach is to write here that this bug occurred when performing this action in VCC, without mentioning Alcom at all.
The way the person who wrote this problem describes it as:
A bug caused by using Alcom to perform an action in VCC that wouldn't normally occur.
If that's unclear, let me give you an example using a game.
The wording here is like intentionally causing behavior that wouldn't normally occur in a game by using a mod, and then claiming it's a bug.
In this case, a simple statement like, "When I performed this action in vanilla, this bug occurred," would suffice.
In other words, as I wrote at the beginning of this sentence, you just need to write, "A malfunction occurred in VCC due to a specific procedure."
That's all you need to write.
This place is for reporting officially supported software, and is absolutely NOT a place to report bugs using third-party software.
Please don't misunderstand this and write here.
If you also use VRChat, you should understand this. You wouldn't want to waste the official effort on a problem that the official team shouldn't be dealing with.

Sayamame

天白ゆうか 
When reporting bugs, it’s often helpful to include details about how we encountered the issue. In fact, on the page linked from the Canny submission page, the VRChat team advises users to include "Steps to reproduce (how did you encounter the bug?)".
In this case, the issue was simply first encountered when using ALCOM, so I think mentioning it is reasonable.
If you think ALCOM is equivalent or similar to a mod or a modified client, I would say it is materially different. The client, VCC, and SDK have not been modified.
To put it another way, it’s similar to encountering a bug in VRC or the SDK while using specific assets such as shaders or avatars; it is up to the VRChat team to decide whether to address this on the VRC / SDK side, not us.

Val_eins

Sayamame　I’ll say this again and again: ALCOM is an unofficial tool, and this statement seems designed solely to get the developers to investigate it. To me, what you’re doing is no different from someone who installs an unofficial mod for a single-player game and then just complains that the game won’t run anymore.

天白ゆうか

Sayamame
Ah... you really lack reading comprehension, don't you?
When I gave you an example of a mod, you only focused on that and completely ignored the rest of the text.
It seems I need to explain things more simply and clearly.
Alcom is unofficial, VCC is official; you mustn't confuse the two.
I'll say it again: this is a place to report bugs and other issues that have occurred in the official software.
Let me reiterate: This is a place to report bugs and other issues that occur in the official software.
Therefore, everything you've written about Alcom is unnecessary and not needed.
You should simply describe what needs to be fixed using only VCC's operation, without including Alcom.
Oh, I intended to write something simple, but it ended up being quite long... Is that okay? Have you understood everything up to this point?

venn02_ヴェン

If the issue can only be reproduced by performing an operation in VCC that you wouldn't normally do, isn't that a bug specific to ALCOM?