Skip to content
openmw-config
api

Directories

data= directories, and the single-valued resources=, user-data= and data-local=.

Directory settings are DirectorySettings: parsed() is the resolved path, original() the text as written. A path you add or set is read like a value in a file: tokens resolve, and a relative path is anchored to the user’s config directory. Paths you look up or remove are compared as given.

Data directories#

fn data_directories_iter(&self) -> impl Iterator<Item = &DirectorySetting>

The data directories in load order, which is VFS priority order: later directories override earlier ones. Includes the entries loading adds: resources/vfs first when resources= is set, data-local last when that is. Nothing checks that the directories exist.

fn has_data_dir(&self, file_name: &str) -> bool

Whether a data directory resolves to file_name. / and \ in the query both match the platform’s separator. The query is not resolved: pass an absolute path.

fn add_data_directory(&mut self, dir: &Path)

Appends a data directory, attributed to the user’s config. Does not check for duplicates.

fn remove_data_directory(&mut self, data_dir: &PathBuf)

Removes every data directory whose resolved path equals data_dir, or whose text as written equals it. Removing a parent’s makes the user’s config replace the list with replace=data when saved, copying the remaining parent directories into it, relative ones as their resolved paths.

fn set_data_directories(&mut self, dirs: Option<Vec<PathBuf>>)

Removes every data= entry and adds dirs in order, attributed to the user’s config, behind replace=data when a parent had contributed. None leaves none. The resources/vfs and data-local directories stay first and last: they follow their own settings, not data= lines.

resources=, user-data= and data-local=#

Each holds one directory: the engine’s resources, the user data root, and the highest-priority data directory. The getter returns the last definition in the chain.

fn resources(&self) -> Option<&DirectorySetting>
fn userdata(&self) -> Option<&DirectorySetting>
fn data_local(&self) -> Option<&DirectorySetting>

The config key is user-data; ?userdata? is only a token, and there is no userdata= key.

Setting a path#

fn set_resources_path(&mut self, path: impl AsRef<Path>)
fn set_user_data_path(&mut self, path: impl AsRef<Path>)
fn set_data_local_path(&mut self, path: impl AsRef<Path>)

Sets the value in the user’s config: replaces the user’s definition in place when it is the last one, and otherwise adds one, which comes last and wins. A parent’s definition stays, so clearing the user’s value afterwards brings the parent’s back, as a reload would.

Clearing#

fn clear_resources(&mut self)
fn clear_user_data(&mut self)
fn clear_data_local(&mut self)

Removes the last definition. When a parent config defined the setting as well, its value is the one in effect afterwards. When the last definition is a parent’s, only saving that parent’s file with save_subconfig makes the removal last: a user config cannot unset a value its parent sets.

Setting a DirectorySetting#

fn set_resources(&mut self, new: Option<DirectorySetting>)
fn set_userdata(&mut self, new: Option<DirectorySetting>)
fn set_data_local(&mut self, new: Option<DirectorySetting>)

The general form of the two above: Some replaces the last definition when it belongs to the same file as the new one, and otherwise adds the new one after it; None removes the last definition. The setting keeps the source you gave it in DirectorySetting::new, and saving writes it to that file.

Changing resources= or data-local= changes the data directories they add, as a reload would: resources/vfs first and data-local last, or neither once the setting is gone.