What Script Import Creates—and What It Does Not

Script import is much narrower than “building the project for you.” The current import path creates episodes, scenes, and script items so readable sluglines and in-scene text can enter the project; it does not create shots, take records, shoot days, or camera settings at the same time. A completed import therefore means the script structure has entered the project, not that the on-set record already exists.

Script import creates episodes, scenes, and script items; shots, take records, shoot days, and camera settings are outside this creation path.

Import creates three kinds of script-structure objects

After readable content enters the project, the import path puts the imported scenes into one episode, reusing the lowest-numbered existing episode when the project already has one and creating an episode only when it has none, and creates script items for the in-scene text that is retained. Import also sets a few preset values on the project; that does not expand the set of created objects and should not be conflated with importing unit, director, or director-of-photography presets. This scope corresponds to the script structure itself, not to every on-set object needed for production recording.

What FDX Exchanges—and What It Does Not Carry explains which script information the exchange file can carry; this page only answers what objects that information becomes after import. The appearance of a scene-selection view should not be treated as evidence that later on-set records were also created.

It explicitly does not create four on-set object types

Import does not create shots, take records, shoot days, or camera settings. Those four object types belong to a later on-set recording path and cannot be inferred from one script import; a completed import does not mean shots are already broken down, take records already exist, shoot days are assigned, or camera parameters are established.

Production-personnel presets are also not written by this import path. Unit, director, and director-of-photography values have to be entered separately rather than treated as created merely because similar text may exist somewhere in a script file.

Import completion does not mean the on-set record already exists; shots, takes, shoot days, camera settings, and production-personnel presets must be checked separately from script import.

Two input shapes disappear during import

Paragraphs that appear before the first readable slugline are not attached to any scene, so title-page or opening-style entries in that position are dropped. Import starts collecting later text only after a scene heading has been read.

A scene heading with empty text is another disappearing shape. No scene is created for it, so there is no blank-titled scene waiting to be renamed afterward; a receiver should verify whether the source file contains this shape and whether the imported scene count matches expectations.

When nothing can be read, the scene list never opens

A well-formed script exchange file from which no scene can be read does not open the scene-selection view; SlateX reports the failure instead. What is easy to miss is a partial read: the view opens as usual while the list holds fewer scenes than the file contains, so that step has to be checked.

That is the boundary between “parsing succeeded” and “readable scenes were produced.” A success state means this read did not end in an error; it does not mean selectable scenes necessarily exist, and it does not mean on-set objects were created.

After import, on-set recording is still a separate path

Shots, takes, shoot days, and camera parameters that will be recorded later belong to another workflow, and this page does not expand those steps. The point to keep is narrow: script structure entering the project and on-set records being created are two different events.

The import flow also filters some duplicate-scene cases. The exact scenes filtered depend on the input file. This is a step inside import, not a user-reliable duplicate safeguard. To check whether a scene entered the project as expected, compare the source file with the actual imported scenes rather than treating the filter as a guarantee.

What an Exported FDX Does Not Bring Back covers rewrites that happen after a file has been written out and read back; this page sits one step earlier and only answers what one import creates and what it clearly does not create. Taken together, the two pages still do not replace the receiver’s check of the source file and the imported result.

FAQ

Does script import also create shots and take records?

No. The current import path creates episodes, scenes, and script items, while shots and take records belong to the later on-set recording path.

Are unit, director, and director-of-photography presets imported with the script?

They are not written by this import path. Those production-personnel presets have to be filled separately.

Does a file with no readable slugline always raise an error?

Not necessarily. When no scene can be read the app says so and the table never opens; when only part of the script is read the table opens as usual, so the number of scenes actually created has to be checked.

Can duplicate filtering be treated as a duplicate safeguard?

It should not be described that way. It is filtering inside the import funnel, and the receiver should still check the scenes that actually entered the project.

Axiom One LLC — SlateX