For the Editor form, see Package (Form).
Packages are the main way in which you can control an Actor's behavior. Each Package represents a behavior that the Actor will perform under certain conditions.
The Package system consists of a number of components:
- All Actors have a Package Stack, an ordered list of potential behaviors.
- These stacks are composed of Packages, individual behaviors that the Actor can perform.
- Package Templates, in turn, are composed of a structured Tree of Procedures, the atomic actions that make up the behavior.
- Periodically, the game will reevaluate each Actor's Package Stack. The topmost package in the stack whose conditions are satisfied will be run.
For example, say the game updates the AI for Faendal, an Actor in Riverwood, at midnight. It evaluates his Package Stack, checking the conditions on each Package from the top of the stack down. The first one whose conditions are satisfied happens to be [FaendalSleepHome23x5]. This Package is an instance of the [Sleep] Package Template, and specifies a piece of data used by that template (where Faendal should sleep: in his house). The [Sleep] Template, in turn, specifies the atomic actions needed to carry out the behavior, telling the AI that Faendal needs to walk home, lock his door, find a bed, and sleep in it.
The basic concepts of Package System and Package Stack are unchanged from Fallout 3. However, the system has a number of new features, as described below.
Radiant Story Alias Packages
The Radiant Story system makes it possible to add Packages to a Quest Alias, and then apply that Alias (along with those packages) to an Actor (in some cases, potentially to ANY Actor) at runtime. This means that, depending on what Alias an Actor might have attached to him, he may have more packages on his stack than you can see by looking at the Actor's form directly. For more, see Category:Radiant Story.
All Actors can have a Default Package List, a list of Packages that are added to the bottom of the Actor's Package Stack and typically function as 'fallbacks' when none of the Actor's specific packages apply. For more details, see the Package Stack and AI Packages Tab articles.
Interrupt Behavior Override Packages
Some systems, such as Combat, will preempt an Actor's package-driven AI behavior. You can interrupt and override those systems by explicitly specifying a package or list of packages to run instead. For example, you can specify that when a particular NPC enters combat, they will perform some specific behavior (like running over to a lever and pulling it). For more details, see the Interrupt Override Packages and AI Packages Tab articles.
Procedures, the building blocks of Packages, are now exposed in the Editor. Procedures are atomic actions that take inputs or parameters that further define behavior. For example, a Travel procedure takes a piece of data that defines the location to travel to. See Procedures for details.
Procedures in a package are connected together by a procedure tree.
A Procedure Tree is a stack of Branches (or "Nodes") that contain procedures. Because Branches and Procedures can all have Conditions, you can create very complex switches to route AI behavior through. So by looking at a package's procedure tree structure, you can intuit the "thought process" of the actor as he goes about doing what the package asks him.
For example, you could build a package that first tries to "FIND" a chair, and if it finds one, causes the NPC to "SIT" in the chair. If it doesn't find a chair, it can cause the NPC to "WANDER" around instead. This is what the "Sit" package template does.
Because you usually manipulate Procedure Trees while designing new Templates, see Package Templates for more details.
Package Templates are prebuilt Procedure Trees and data inputs, whose data can be changed, but whose structure and logic cannot. The vast majority of the packages in the game are derived from a small handful of Templates.
If desired, you can build a custom package with its own procedure tree and not make that package a Template for reuse. But this is rarely necessary or desirable- if you are going through the trouble of creating new behavior, you might as well make it a Template so you can reuse it later. Since creating a stand-alone package is identical to creating a template, except you don't mark it as a Template, See Package Templates for more info.
This category has the following 2 subcategories, out of 2 total.
Pages in category "Packages"
The following 11 pages are in this category, out of 11 total.