GetSunPosition breaks SunSky blueprint in standalone mode

[ExopackVFX]

As the title implies, I have a SunSky blueprint, modified to include a day/night cycle, as well as a running clock/calendar of the current time and date. The blueprint has worked fine for literally hundreds of update iterations, and through several engine upgrades, including 5.5.

As of late, I have no idea what happened, but I’ve noticed the blueprint stopped working outright. No error in editor at all, it just gets completely ignored when running the game in standalone mode. This is not just about blueprints not working: literally no elements within the actor are even showing. No lights, no moon mesh object, no clouds, no post processing. Nothing.

When running inside the editor, everything works perfectly, but standalone mode refuses to include the blueprint. It’s as if the standalone mode is automatically hiding the actor.

After a good amount of messing around, breaking and rebuilding, I found the culprit: the GetSunPosition node. Its mere presence, connected to any live execution pins causes the issue.
I even tried to connect it by itself on the OnBeginPlay, or Tick. Same result.

I tried several searches, and it seems as though I’m the only one who came across this issue, which usually means I may be looking simply at some odd side-effect, and not necessarily at the root cause.

Does anyone have some idea on what may be going on?

UPDATE:

Just for kicks, i tried to drop the GetSunPosition node into the OnBeginPlay of my third person character blueprint, and it did the exact same thing. Anything connected to the character blueprint was gone in standalone mode. There is definitely something weird happening with the GetSunPosition node that somehow throws a grenade into any blueprint I drop it in.

2nd UPDATE:

In yet another failed attempt, I tried to move some of the functions related to GetSunPosition into the game instance blueprint. This time nothing broke, but the GetSunPosition node disabled the function in which it resides (the one that updates the sun position “UpdateSun”), so now my sun is stationary, while the clock and date seem to work.

[ClockworkOcean]

Do you use a reference to the directional light ( or similar )? You might need to wait a second or so for it to be available.

[Falcon_Firestar]

1. Open Your SunSky Blueprint:

• Navigate to your SunSky blueprint in the Unreal Engine content browser and open it in the Blueprint Editor.

2. Locate the GetSunPosition Node:

• Find where the GetSunPosition node is executed. This is likely connected to the OnBeginPlay event (which runs once when the level starts) or a Tick event (which runs every frame).

• Note the execution pin (white arrow) that triggers GetSunPosition.

3. Insert a Delay Node:

• Add a Delay node from the blueprint utilities (search for “Delay” in the node palette).

• Set the Duration to 1 second.

• Connect the execution pin from OnBeginPlay (or wherever GetSunPosition is triggered) to the input of the Delay node.

4. Reconnect the Logic:

• Connect the Completed output pin of the Delay node to the execution input of the GetSunPosition node.

• Ensure the rest of your logic (e.g., updating the sun’s position) flows from GetSunPosition as before.

• Example structure:

OnBeginPlay -> Delay (1 sec) -> GetSunPosition -> (rest of your logic)

---

Testing the Fix

To verify it works:

1. Run in Standalone Mode:

• Go to the toolbar, select Launch > Standalone Game, and run your project.

• This simulates a built game environment, where the issue originally occurred.

2. Verify the Result:

• Check if the sun position updates correctly (e.g., the day/night cycle works, and the sun moves as expected).

• Confirm that the SunSky actor is no longer ignored or hidden, and the blueprint executes without failing.

---

Why It Works

The issue stems from a timing difference between the editor and standalone mode in Unreal Engine 5.5:

• In the editor, the SunSky system initializes quickly, so GetSunPosition works immediately.

• In standalone mode, the initialization is slightly delayed, and calling GetSunPosition too early causes it to fail, breaking the blueprint.

By adding a 1-second Delay node, you give the SunSky system time to fully initialize before GetSunPosition is called. This ensures the node retrieves valid data, fixing the failure in standalone mode. Hope this helps.

[ExopackVFX]

That’s a good point! Didn’t think of adding a delay. I’ll try that as soon as I’m back into my project.

[ExopackVFX]

While it does make sense, this method didn’t work for me for some reason:

[ExopackVFX]

The directional light is a component of the blueprint in which GetSunPosition resides. The thing that baffles me is that if i drop a brand new SunSky BP into the scene, GetSunPosition works fine in both editor and standalone. Something is somehow interfering with the GetSunPosition node but I’m at a complete loss on what that may be.

[ExopackVFX]

Here’s more weird things: the function isn’t even connected to anything, and yet while the external input exec pin is disconnected, the internal one still appears as though it lets GetSunPosition execute, and break the blueprint. Shouldn’t the function not run if it’s disconnected, or is there some basic principle I’m getting wrong about functions?

Here is the function disconnected:

Here’s the function, still disconnected, but with the internal exec pin connected to the nodes:

Blueprint breaks. No sun, no sky, no moon, no nothing.

I disconnect the internal pin of the already disconnected function:

And i got my sun back, although with none of the features necessary to make my sky work properly, namely celestial body rotation, etc:

[ExopackVFX]

Ok so i seem to have found the issue. It took me a good amount of chasing, but apparently GetSunPosition was in fact a symptom, and not the root cause.
Apparently i had a reference to my sky blueprint in a widget, as well as referenced variables pulled from it. For some reason, GetSunPosition does NOT like that, at all, and will cause any blueprint in which it’s dropped to break, if a reference to its parent blueprint exists in any widget.

Live and learn…

I’ll go ahead and mark this as solved. Thanks everyone!