Scripts are running before rendering-related properties have been initialized properly in Play Solo

EmeraldSlash · August 31, 2022, 1:29am

Reproduction Steps

Studio Version: 0.541.205.5410438
OS: Windows 10 Pro
CPU: AMD Ryzen 5
GPU: NVIDIA GeForce RTX 2070

In an empty place file, create a new LocalScript in StarterPlayerScripts with the following code:

local s = Instance.new("ScreenGui")
s.IgnoreGuiInset = true
s.Parent = game.Players.LocalPlayer.PlayerGui

print("vs:", workspace.CurrentCamera.ViewportSize)
print("sg:", s.AbsoluteSize)
print("vr:", game:GetService("VRService").VREnabled)
print("---")
task.wait(2)
print("vs:", workspace.CurrentCamera.ViewportSize)
print("sg:", s.AbsoluteSize)
print("vr:", game:GetService("VRService").VREnabled)

Then test this in Studio Play solo. Try this with and without VR.

Also let:

SVS = studio viewport size
VVS = VR viewport size – which is usually (960, 720) I think

Expected Behavior

The output should without VR should have been:

vs: SVS
sg: SVS
vr: false
---
vs: SVS
sg: SVS
vr: false

and the output with VR should have been:

vs: VVS
sg: VVS
vr: true
---
vs: VVS
sg: VVS
vr: true

Actual Behavior
Without VR, the output you should get is:

vs: 1, 1
sg: SVS
vr: false
---
vs: SVS
sg: SVS
vr: false

This means the Camera’s ViewportSize was at (1, 1) when the script ran, then later was updated to the correct value.

With VR, the output should get is:

vs: 1, 1
sg: SVS
vr: false
---
vs: VVS
sg: VVS
vr: true

This means initially the Camera ViewportSize was at (1, 1), the ScreenGui’s AbsoluteSize was using the studio viewport size, and VR was thought to not be enabled. However, the engine shortly figures out (in the next frame or two) the correct values for these properties.

When doing the test in VR you may also note an error in the output from the PlayerModule:

I think there are two places in the PlayerModule which assume that VREnabled will always be true, hence when this bug occurs the PlayerModule throws errors.

I’m not sure if Camera.ViewportSize being (1, 1) on start is a bug, but I did get errors in my own code from it and those errors were not appearing prior to this update, so I assume that is unintended. Also, the fact of the ScreenGui’s AbsoluteSize property working differently than Camera.ViewportSize may imply a bug as well.

Workaround

Being careful with Camera.ViewportSize.
Listening to property changes of VRService.VREnabled, instead of checking it once at startup.
Applying the above to a forked version of the PlayerModule

Issue Area: Studio
Issue Type: Display
Impact: Moderate
Frequency: Constantly
Date First Experienced: 2022-08-30 00:08:00 (+12:00)

ShoomamaAtlantis · August 31, 2022, 3:48am

I’ve been having this same problem occasionally. It occurs randomly on my end which makes it a strange bug. One workaround I found was to just use a local server test session with 1 player instead of play solo, as this still worked properly. Hopefully this gets fixed soon.

Club_Moo · September 9, 2022, 2:23am

Yes, it’s good to monitor AbsoluteSize changes, etc.

However, I’m curious–Are you testing with Workspace.SignalBehavior set as Deferred?
And if so, do you see a different behavior if you set it back to Immediate?

EmeraldSlash · September 9, 2022, 8:28pm

Workspace.SignalBehavior does not appear to affect anything for me.

Club_Moo · September 10, 2022, 12:45am

So your tests above behaved the same either way? I asked because Deferred can start scripts
before the script’s Parent is set, etc.

EmeraldSlash · September 10, 2022, 9:26pm

The tests all behaved the same.

Also, have you actually confirmed that scripts will run before their parent is set? That seems like a very significant game-breaking change. I tried creating Scripts and LocalScripts in various places with the code print(script.Parent) with Deferred signal behaviour and did not notice any issues.

Club_Moo · September 10, 2022, 11:32pm

Yes, it breaks many scripts–Mostly ones written by Roblox. Last time I checked recently this was still happening, to my surprise, as I figured it would have been fixed already. (nil script.Parent on a running script.) Did you try it at the top of your scripts? Edit: And in the Workspace?

EmeraldSlash · September 10, 2022, 11:51pm

The entire source for the scripts was print(script.Parent). I tried it in StarterPlayerScripts, ServerScriptService, ReplicatedFirst, and Workspace. I haven’t had any issues with Roblox’s scripts.

Are these scripts being cloned during runtime or something? Although doing something like

task.wait(2)
game.Workspace.Script:Clone().Parent = workspace

doesn’t make a difference for me either.

Club_Moo · September 10, 2022, 11:58pm

Interesting. I wonder if it’s a symptom of Studio being bogged-down on my end. (Wouldn’t think it could fail that way, but maybe.) I’ll take another look and see if other parameters could possibly be in the mix.

Edit: I had some old Tool-related scripts from Roblox that behaved differently in Deferred mode which
caused some scripts to be “deparented”. @EmeraldSlash Thanks for the double-check.
Interestingly, even though the behavior changed with Deferred mode, it was not related to Signals.

thirdtakeonit · September 12, 2022, 2:39pm

Thanks for the report! We’ll look into it.

TheNexusAvenger · September 22, 2022, 2:44am

This bug seems to have made it to the client. When I was testing in VR (Steam VR using Valve Index, Windows 11), I noticed Nexus VR Character Model was not initializing. VREnabled is sometimes appearing as false on start, and then true after waiting for a second.

JoyfulFlowerMary · September 30, 2022, 6:15pm

That could be a possibility; I’ve noticed that when I would test my game in VR (like @TheNexusAvenger, using his (great) module), if I clicked the “play” button in the top-left corner, the game would somehow start in VR but without Nexus VR Character Model. (Also, my game’s loading screen would have a background, which is normally hidden from VR players, indicating VREnabled was somehow false.)

(That loading screen looked like this.)

If I waited until all textures loaded, then Nexus VR would initialize and everything would work properly.

EmeraldSlash · October 1, 2022, 12:25am

Your problem will be because the Nexus VR code (and your loading screen code) code start running and check VRService.VREnabled when it still has the incorrect value. By the time textures have loaded VRService.VREnabled will be correct.

You can probably temporarily fix this in a hacky way by just waiting a few frames before checking VRService.VREnabled in both the NexusVR code and your own code.