The default is NonUFS, which means outside the pak

The rule lives in the staging script, not in engine code. Content/Movies is walked recursively: anything that is not a .uasset or a .umap gets staged, and the engine’s own movies in Engine/Content/Movies go along with the project’s. The staged type is NonUFS in every scenario except when using a file server (CopyBuildToStagingDirectory.Automation.cs:1982-2011). A comment a few dozen lines above leaves no room for interpretation (:1971):

// NonUFS files are never in pak files and should always be remapped

A NonUFS file is one that staging copies into the output directory and that the pak knows nothing about. Hence the loose .mp4 files in the build. Packing them was always possible; nobody ever told staging to put them inside the pak.

The two fields that reverse it

With bSkipMovies on, the script takes a different branch (:2013), where two explicit lists of movie names decide the staged type instead. In the editor they sit under Project Settings → Packaging → Advanced.

The field names hide what they do:

The description for UFSMovies states this explicitly: will still be added to the .pak file (ProjectPackagingSettings.h:513). In DefaultGame.ini it looks like this:

[/Script/UnrealEd.ProjectPackagingSettings]
bSkipMovies=True
+UFSMovies=Intro

Why playback keeps working

A movie inside the pak stops being a file the operating system can see. Only code that reads through IPlatformFile can reach it, and the pak is mounted there as another layer of the virtual file system.

Media Framework reads exactly that way. UFileMediaSource hands the path over as a URL with the file:// scheme (FileMediaSource.cpp:169). WmfMedia, the player enabled by default on Windows, always opens such a URL through IFileManager and then passes the resulting byte stream to Media Foundation (WmfMediaUtils.cpp:1285-1305, :1341). Nothing in that chain needs the file on disk under its own name.

I checked this in my own build: an .mp4 packaged inside the pak through UFSMovies kept playing at runtime through UMediaPlayer with FileMediaSource.

When this matters

With one movie, the benefit is a cleaner build directory: the file stops sitting in plain view, and the output directory holds one archive instead of scattered assets alongside it. With a dozen or more it becomes the difference between a build you can scan at a glance and a file list you have to keep track of every time you distribute the build.

Verify this in a packaged build, not in PIE. In the editor every movie sits on disk, so the staging settings have no effect there at all.

It comes down to how the tooltip generator splits the comment. That behavior affects every BlueprintCallable node, in the engine and in every plugin.

The symptom: nine pins, a two-sentence tooltip

Set Timer by Event is the textbook case. The function comment warns that a time less than or equal to zero clears the timer instead of setting it (Engine/Classes/Kismet/KismetSystemLibrary.h:723):

/**
 * Set a timer to execute delegate. Setting an existing timer will reset that timer with updated parameters.
 * @param Event   Event. Can be a K2 function or a Custom Event.
 * @param Time    How long to wait before executing the delegate, in seconds.
 *                Setting a timer to <= 0 seconds will clear it if it is set.
 * ...
 */

The node tooltip itself reads, in full:

Set a timer to execute delegate. Setting an existing timer will reset that timer with updated parameters.

Target is Kismet System Library

The sentence about <= 0 shows up when you hover the Time pin, and nowhere else:

I wrote up the consequences of this particular case separately in Set Timer by Event with Time = 0.0 never fires. What interests me here is the mechanism, because it affects far more than just this one node.

The cause: Split with nullptr on the right

The node tooltip comes from ObjectTools::GetDefaultTooltipForFunction (Editor/UnrealEd/Private/ObjectTools.cpp:5396), and the whole decision fits in two calls:

// Strip off the doxygen nastiness
static const FString DoxygenParam(TEXT("@param"));
static const FString DoxygenReturn(TEXT("@return"));

Tooltip.Split(DoxygenParam, &Tooltip, nullptr, ESearchCase::IgnoreCase, ESearchDir::FromStart);
Tooltip.Split(DoxygenReturn, &Tooltip, nullptr, ESearchCase::IgnoreCase, ESearchDir::FromStart);

Split with the result written back to LeftString and nullptr in place of RightString truncates the text at the first match. The right-hand side is computed and thrown away. The comment “strip off the doxygen nastiness” describes the intent precisely: the Doxygen tags were treated as noise and removed together with the content they describe.

Everything else follows from that one decision. Parameter descriptions take a separate route to the individual pin tooltips (ObjectTools.cpp:5452), and @see and @note survive the cut and render as See: and Note:, but only when they appear above the first @param.

What to do about it

Reading someone else’s nodes: if a node tooltip looks suspiciously thin for the number of pins, the documentation is most likely on the pins. Hovering a pin takes a second and routinely reveals information that was missing from the node tooltip.

Exposing your own API to Blueprints (which covers every plugin with UFUNCTION(BlueprintCallable)):

When this matters

On a node with two pins, not much. The whole description fits in the opening sentence anyway.

The stakes rise with the number of parameters, and with the number of values that are technically valid but mean something other than what the user assumes: zero for “cancel,” a negative value for “no limit,” an empty name for “use the default.” That kind of knowledge belongs next to the parameter by definition — and the text next to the parameter is exactly what the node tooltip will not show.

There’s one more consequence for plugin authors: a user who falls into that trap despite a correctly written comment will file it as a documentation bug. The comment will be right where it belongs, and the report will still be justified.