Sequencer’s actor visibility tracks do not work in a packaged game if the target actors are in a different sub-level than the Level Sequence actor itself. Everything works correctly in a Play-In-Editor session.
Repro
Create a Blank Blueprint project
Drop a few Cube actors into the level
Save the level as LevelSub
Create a new level from the Empty Level template, save it as LevelMain, then set it as the startup map in Project Settings
Continue working with LevelMain
Add LevelSub as a sub-level and enable both Initially Loaded and Initially Visible for it
Set LevelMain (the Persistent Level) as the current level for editing
Create a Level Sequence asset, drop it into the level (make sure it goes to LevelMain), then enable Auto Play for it
Open the Level Sequence in the Sequencer
Add the Cubes to the sequence, remove their Transform track, then add Visibility tracks for them
Add some visibility change events
Play In Editor: everything works
Package for Windows 64-bit, then test: visibility tracks have no effect
I set up everything that you said to do, but it still seems to work in 4.14.1. Do you have a project that would reproduce this that you can send me? (Note: I’d need the unpackaged project so I can see what I might be doing differently)
So…I don’t really know how to explain it, but the levels you’ve created have fallen into a kind of limbo. In the project that you sent me, the SubLevel is set to the Blueprint Streaming method. This SHOULDN’T load the level unless you trigger it to, which you aren’t…yet it still loads. So I switched it to Always Loaded, like you said in your steps, and now it works. However, when I switch back to the Blueprint Streaming Method, the level no longer loads (as expected).
I don’t know how your project fell into this weird state of appearing Always Loaded, but set to Blueprint and just happens to manifest a weird sequencer issue. It’s like your project, in its vanilla state, is doing this:
Loading the Main Level
Attempting to Play the Sequence (no actors to manipulate)
Loading the Sub Level (when it shouldn’t be)
Either way, the two methods for this should be Always Loaded Streaming Method with Auto-Play on the Sequence OR Blueprint Streaming Method while loading the level manually and THEN triggering the sequence manually.
About the limbo state: so now I’m confused. Are you sure of this? The checkboxes Initially Loaded and Initially Visible are available in the level details panel only if the level is set to Blueprint Streaming; they disappear from the panel if the level is set to Always Loaded (UE 4.14.2). To me, it has appeared that their only role can be to define the state into which a Blueprint Streaming level is initialized in the beginning, before any BP commands are applied to it: whether to have it initially loaded/unloaded and visible/hidden.
If a Blueprint Streaming level needs to be loaded and set to be visible via Blueprints even if the Initially Loaded and Initially Visible checkboxes are checked, then what role is left to these checkboxes? Maybe I am not seeing something obvious here?
(by the way, the repro steps have a step for selecting Initially Loaded, not Always Loaded)
Level is Always Loaded, seq is Auto-Play: seems to work indeed
Level is Always Loaded, seq is played via BP: also works
Level is Blueprint Streaming & Initially Loaded & Initially Visible, seq is Auto-Play: does not work (this was the original issue)
Level is Blueprint Streaming & Initially Loaded & Initially Visible, seq is played via BP at Begin Play: does not work
Level is Blueprint Streaming & Initially Loaded & Initially Visible, seq is played via BP at Begin Play after a delay (I used 2s): does work
(all cases tested after packaging; in PIE, it always works)
So yes, you seem to be correct: the issue seems to occur due to the target actors not yet existing if the sequence is started instantly after the persistent level has been loaded and started (for example, via the persistent level’s BeginPlay).
The root cause is then this, I suppose: the Initially Loaded option operates asynchronously? That is, the persisent level is started before all of it’s Initially Loaded sublevels have actually completed loading?
Somehow this feels flaky to me: if we have a checkbox for a level being Initially Loaded, then one should be able to count on the level to actually be “initially loaded”. At least to me, that reads to be before the moment when the persistent level’s BeginPlay fires (and maybe also before any persistent level’s auto-plays fire).
Also, this manifests only after packaging and appears to be non-deterministic: in a realistically complex setup, you might accidentally have barely sufficient delays during testing, then have occasional failures for end users?
In our project, we probably can’t change our LevelSub equivalents to Always Loaded. What seems to work with a Blueprint Streaming level is to forget Initially Loaded and Initially Visible, but instead do this in BP:
Begin Play > Load Stream Level( level = LevelSub, set visible = true ) > seq.Play()
This seems to work even with the Should Block on Load checkbox unchecked: the Completed pin fires only once the level is loaded, I assume, whether or not the Should Block checkbox is checked.
Suggestion: Add an option to Initially Block Until Loaded, next to the Initially Loaded option?
First, this makes it clear that the default behavior of Initially Loaded is to just trigger an asynchronous load and that the level won’t be there yet when the game / persistent level starts.
Second, it gives a clean solution for those cases where several Blueprint Streaming sub-levels need to be already loaded before the actual game logic starts.
I’ve entered UE-40868. You can track the report’s status as the issue is reviewed by our development staff. Please be aware that this issue may not be prioritized or fixed soon.