-
Notifications
You must be signed in to change notification settings - Fork 19
Papyrus Compiler
The Papyrus Compiler is a command line utility used to compile Script Files.
The program will take source *.psc
files and convert them into executable *.pex
files, a format that Fallout 4 can understand.
During this process it will check your scripts for a wide range of errors, and report them to you.
All Papyrus scripts must be compiled before they can be used in the game.
The Creation Kit uses this utility to compile scripts inside the editor as well.
This utility is included with the Creation Kit and can be found ...\Steam\SteamApps\common\Fallout 4\Papyrus Compiler\PapyrusCompiler.exe
.
The compiler for Fallout 4 is different than the one for Skyrim. You shouldn't have to do anything special to use the new one.
For the most part, Papyrus remains the same between Skyrim and Fallout 4. A script written in Skyrim will be able to be brought over to Fallout 4 with minimal changes, sometimes only needing to be recompiled with the new compiler.
Also note that Skyrim (.pex) files are not compatible with Fallout 4, and vice-versa.
Both games will throw a Game ID number doesn't match
error if you try to load a (.pex) file from the other game.
Just re-compile the file with the right compiler to fix the issue.
You can tell which compiler you are using by the output it gives.
If you see Papyrus Compiler 2.X.X.X for Fallout 4
then you're running the Fallout 4 compiler, and if you don't see that, it's the Skyrim compiler.
There are a few main ways to compile scripts. Inside the Creation Kit, on the command-line, or other external tool.
The traditional way to run the compiler is to have the Creation Kit do the compilation for you through the Creation Kit Papyrus Manager Window.
The Creation Kit uses a project with the equivalent of the following command line to build scripts. See below:
PapyrusCompiler <file> -i="<scripts folder>" -o="Data\Scripts" -f="Institute_Papyrus_Flags.flg"
You can tell the Creation Kit to build in release or release final mode as well via the Creation Kit's preferences page.
Release adds the -r
and -op
flags to the command, and release final uses the release flags plus the -final
option.
The Creation Kit now supports setting what mode the compiler should run in, being debug (the default),
release (optimizations turned on, DebugOnly
functions removed), and release final (Release
+ BetaOnly
functions removed).
There are two new flags that can be applied to functions and scripts - DebugOnly
and BetaOnly
.
These control whether these functions are left in or trimmed out from your script, based on the options given to the compiler.
Script functions in the Debug Script, as well as a few other functions, have been marked as DebugOnly
, which means that the compiler will now remove them from any script when building the release or beta script archive.
This means that all your trace statements will not be visible on a machine running the either script archive.
Scripts you build yourself will not strip these functions, if you're using the default compile options in your editor or the CK.
If you need to get trace statements from someone else's machine who doesn't normally run with loose scripts, you may rename the Fallout4 - Misc - Debug.bsa
file to simply Fallout4 - Misc.bsa
to have the game use the debug scripts.
You'll probably want to rename the existing misc archive as well so you can restore it when you're done.
The BetaOnly
script functions operate in the same way as DebugOnly
, but are only removed from release final archives.
Both the debug and beta archives contain these functions, so if you want to see their output, you'll want to rename one of those so the game loads them.
Again, by default, BetaOnly
functions are included in scripts you compile.
If you want to compile your scripts for release, you can use one of the other compile batch files, add the options to the command line yourself, or change the CK into release mode in the script preferences tab.
Power-users may want to execute the compiler via the command line, batch file, or other external tool.
Run the PapyrusCompiler.exe
inside the "Papyrus Compiler" folder, which can be found in the location where you installed the editor.
Of course, you'll need to specify a series of command line arguments to tell it what to do.
If you run the compiler without any command line parameters, or with erroneous ones, it will spit out a set of help text to remind you what they are.
The very first thing you pass to the compiler is the name of the script (or folder, if you're using the -all
flag) to compile.
You may also pass a Papyrus Project if you specify the (.ppj) extension, for more information, check out the page on Papyrus Projects. Any command line arguments override any project settings.
To build with a project, use the following syntax:
PapyrusCompiler MyProject.ppj [other options]
The extension must be specified (it's how the compiler differentiates between a script and a project). Any command line options passed to the compiler will override the settings in the project.
The common command-line parameters are listed as follows. There are others, but most users will not need them:
-import="<folders>"
-output="<folder>"
-flags="<file>"
-optimize
-release
-final
-all
-quiet
-import="<folder 1>;<folder 2>;<folder 3>"
-i="<folder 1>;<folder 2>"
This command line parameter specifies a list of folders that the compiler will look in for other scripts and the flag file. You'll want to at least point this at the folder that contains all the game's base scripts. Multiple folders are separated by semicolons. If compiling a project, these specify places to look for the project, but the project's own import folders will override this when searching for scripts.
Files in folders listed first override ones in folders listed after.
-output="<folder>"
-o="<folder>"
This parameter specifies the output folder for the compiled files.
You'll almost always want this to be your game's Data/Scripts
folder.
-flags="<file>"
-f="<file>"
This parameter specifies the flag (.flg) file to use for processing Flag Reference in the scripts.
You'll almost always want this to be Institute_Papyrus_Flags.flg
-optimize
-op
This parameter tells the compiler to perform basic optimizations on the script. You will usually want this on for any script you release.
-release
-r
This parameter tells the compiler to remove all DebugOnly
function calls from the script, optimizing it and reducing its size slightly depending on how many you use.
You will usually want this on for any script you release.
-final
This parameter tells the compiler to remove all BetaOnly
function calls from the script, optimizing it and reducing its size slightly (depending on how many you use).
You will usually want this on for any script you release.
-all
-a
Compiles every single script in the specified folder. The folder path replaces the filename as the first argument to the compiler. This is usually faster then compiling each script in the folder independently, as the compiler can re-use data.
-quiet
-q
Forces the compiler to be silent, only printing out any errors encountered.
Usually used with the All
flag to reduce the amount of spam sent to the output.
A Papyrus compiler error is structured as follows:
<file>(<line>:<column>): <error>
Every error line starts with a full path to the file being examined. This is followed by the line and column where the error was detected. Note that this is not necessarily the exact line and character where the mistake is, but it is in the point at which the compiler detected the error. The actual error may be a few characters or even a line or two away.
Note that the compiler tries to recover from each error as it goes by faking a repair (usually by inserting what it expects, or ignoring some piece) and continuing on. This may lead to more errors.
If you're having trouble figuring out what is causing an error that is in the middle of a list of errors, it may simply be a result of the compiler's attempted fix of an error it has previously reported. Try fixing the other errors in the file and compiling again.
Most error messages should be relatively self-explanatory, but some may confuse people. Potentially confusing errors are explained below:
The compiler expected X, but found Y instead. This can usually be the result of a misspelled keyword, or malformed line.
The compiler expected Y, but found X instead. This is usually the the result of a malformed line or misspelled keyword.
The compiler didn't expect X, and so cannot compile the element. Usually the result of a malformed line or missing parts.
The compiler expected a list of things, but got confused when it encountered X. You may be missing a comma somewhere, misspelled something, or have excess text at the end of a line.
This is an internal compiler error that is usually the result of a failed error recovery mechanism. Try fixing any errors reported before this one.
Extension
Features
- Language Definition
- IntelliSense
- Code Navigation
- Refactoring
- Compilation
-
Debugging
- Debug View
- [Debug Console](Debug Console)
- [Assembly View](Assembly View)
Creation Engine
Language
Help