Plants vs. Zombies: Replanted - v1.0.3
    Preparing search index...

    Interface IGame

    interface for game extensions

    IGame

    interface IGame {
        compatible?: { [key: string]: boolean };
        contributed?: string;
        defaultPrimary?: boolean;
        deploymentGate?: () => Bluebird<void>;
        detach?: boolean;
        details?: { [key: string]: any };
        directoryCleaning?: DirectoryCleaningMode;
        environment?: { [key: string]: string };
        exclusive?: boolean;
        executable: (discoveredPath?: string) => string;
        extensionPath?: string;
        final?: boolean;
        getGameVersion?: (gamePath: string, exePath: string) => PromiseLike<string>;
        getInstalledVersion?: (discovery: IDiscoveryResult) => Bluebird<string>;
        getModPaths?: (gamePath: string) => { [typeId: string]: string };
        id: string;
        logo?: string;
        mergeArchive?: (filePath: string) => boolean;
        mergeMods: boolean | ((mod: IMod) => string);
        modTypes?: IModType[];
        name: string;
        onStart?: "hide" | "hide_recover" | "close";
        overrides?: string[];
        parameters?: string[];
        queryArgs?: { [storeId: string]: IStoreQuery[] };
        queryModPath: (gamePath: string) => string;
        queryPath?: () => string | Bluebird<string | IGameStoreEntry>;
        relative?: boolean;
        requiredFiles: string[];
        requiresCleanup?: boolean;
        requiresLauncher?: (
            gamePath: string,
            store?: string,
        ) => Bluebird<{ addInfo?: any; launcher: string }>;
        setup?: (discovery: IDiscoveryResult) => Bluebird<void>;
        shell?: boolean;
        shortName?: string;
        supportedTools?: ITool[];
        version?: string;
    }

    Hierarchy (View Summary)

    Index

    Properties

    compatible?: { [key: string]: boolean }

    declares this game compatible or incompatible with a certain feature. If not specified, a sensible default will be assumed for each game. So for example if you know the game won't support symbolic links but Vortex offers it by default, you can set "{ compatible: { symlinks: false } }" so Vortex won't offer the feature. You will have to investigate or ask for the possible ids though. Since we will be introducing new "gates" over time and so may extensions, it's not practical (at least at this time) to maintain a list.

    contributed?: string

    set to name of the contributor that added support for this game. For officialy supported games this is undefined

    defaultPrimary?: boolean

    if this tool is installed, use it as the primary tool (unless the user has manually set a primary of course) If multiple tools with this flag are installed it's effectively random which one gets picked, we make no promises on any kind of consistency

    deploymentGate?: () => Bluebird<void>

    if set this function is always called before automatic deployment and it will be delayed until the promise resolves. This can be used if the deployment process is very slow and/or involves user interaction (e.g. through will-deploy/did-deploy event handlers) to prevent managament becoming impractical due to automated deployment constantly requiring attention.

    Once the promise resolves the mods as enabled at that time will be deployed, so for example if the user enabled a mod while this promise is pending, that mod will be deployed.

    detach?: boolean

    if set to true the process tool will be launched detached, that is: not part of Vortex's process hierarchy

    details?: { [key: string]: any }

    additional details about the game that may be used by extensions. Some extensions may work better/offer more features if certain details are provided but they are all optional. Extensions should do their best to work without these details, even if it takes more work (during development and potentially at runtime)

    directoryCleaning?: DirectoryCleaningMode

    decides how Vortex decides which empty directories to clean. With 'tag' (default) we put a dummy file into each directory created by Vortex and only those get removed during purge (or after deployment if requiresCleanup is enabled) With 'all' Vortex will simply clean up all empty directories, whether Vortex created them or not. In some (unusual) cases this may break mods

    environment?: { [key: string]: string }

    variables to add to the environment when starting this exe. These are in addition to (and replacing) existing variables that would be passed automatically.

    exclusive?: boolean

    if true, running this tool will block any other applications be run from vortex until it's done. Defaults to false

    executable: (discoveredPath?: string) => string

    return the path of the tool executable relative to the tool base path, i.e. binaries/UT3.exe or TESV.exe This is a function so that you can return different things based on the operating system for example but be aware that it will be evaluated at application start and only once, so the return value can not depend on things that change at runtime.

    Optional: Game extensions are free to ignore the parameter and they have to work if the parameter is undefined. executable will be called with the parameter set at the time the game is discovered. If there are multiple versions of the game with different executables, it can return the correct executable based on the variant installed. This is a synchronous function so game extensions will probably want to use something like fs.statSync to text for file existance

    extensionPath?: string

    path to the game extension and assets included with it. This is automatically set on loading the extension and and pre-set value is ignored

    IGame

    final?: boolean

    set to true if support for this game has been fully tested

    getGameVersion?: (gamePath: string, exePath: string) => PromiseLike<string>

    intended to be used by game extensions to provide custom functionality to resolve a game's version when the game executable's version attribute is incorrect, which is often the case with games that are still in early access - an example of this is Blade and Sorcery which uses a different versioning system internally.

    Type Declaration

      • (gamePath: string, exePath: string): PromiseLike<string>
      • Parameters

        • gamePath: string

          path where the game is installed

        • exePath: string

          relative (to gamePath) path to the discovered exe

        Returns PromiseLike<string>

        the game's version

    IGame

    getInstalledVersion?: (discovery: IDiscoveryResult) => Bluebird<string>

    use this to determine the version of this game installed on the system

    Do not implement this in your game extension, the function is added by vortex itself

    getModPaths?: (gamePath: string) => { [typeId: string]: string }

    returns all directories where mods for this game may be stored as a dictionary of type to (absolute) path.

    Do not implement this in your game extension, the function is added by vortex itself

    Type Declaration

      • (gamePath: string): { [typeId: string]: string }
      • Parameters

        • gamePath: string

          path where the game is installed

        Returns { [typeId: string]: string }

    IGame

    id: string

    internal name of the tool

    logo?: string

    path to the image that is to be used as the logo for this tool. Please note: The logo should be easily recognizable and distinguishable from other tools. For game logos consider this:

    • it is especially important to consider distinguishability between different games of the same series.
    • Preferably the logo should not contain the game name because Vortex will display the name as text near the logo. This way the name can be localised.
    • Background should be transparent. The logo will be resized preserving aspect ratio, the canvas has a 3:4 (portrait) ratio.
    mergeArchive?: (filePath: string) => boolean

    determines if a file is to be merged with others with the same path, instead of the highest-priority one being used. This only works if support for repackaging the file type is available

    mergeMods: boolean | ((mod: IMod) => string)

    whether to merge mods in the destination directory or put each mod into a separate dir. Example: say queryModPath returns 'c:/awesomegame/mods' and you install a mod named 'crazymod' that contains one file named 'crazytexture.dds'. If mergeMods is true then the file will be placed as c:/awesomegame/mods/crazytexture.dds. If mergeMods is false then it will be c:/awesomegame/mods/crazymod/crazytexture.dds.

    Note: For many games the mods are already packaged in such a way that the mod has an additional subdirectory. In games where this is the standard, mergeMods should be true, otherwise Vortex would be introducing one more directory level. Note: This should be considered together with "stop folder" handling: If the installer has stop folders set up for a game it will attempt to eliminate "unnecessary" sub directories from the mod package. TODO The name "mergeMods" is horrible since we also talk about "merging" in the context of combining individual files (archives) during mod deployment which is independent of this

    modTypes?: IModType[]

    returns the mod type extensions applicable to this game (all mod types except the default

    Do not implement this in your game extension, this is added by vortex

    IGame

    name: string

    human readable name used in presentation to the user

    onStart?: "hide" | "hide_recover" | "close"

    what to do with Vortex when starting the tool. Default is to do nothing. 'hide' will minimize Vortex and 'close' will make Vortex quit as soon as the tool is started.

    overrides?: string[]

    list of game ids. If one of the games listed here is discovered in the same location as this extension they get disabled. This allows third-party extensions or total conversions to take precedence over the original they're replacing

    parameters?: string[]

    list of parameters to pass to the tool

    ITool

    queryArgs?: { [storeId: string]: IStoreQuery[] }

    use instead of queryPath for simpler specification of search arguments

    queryModPath: (gamePath: string) => string

    determine the default directory where mods for this game should be stored.

    If this returns a relative path then the path is treated as relative to the game installation directory. Simply return a dot ( () => '.' ) if mods are installed directly into the game directory

    Type Declaration

      • (gamePath: string): string
      • Parameters

        • gamePath: string

          path where the game is installed

        Returns string

    IGame

    queryPath?: () => string | Bluebird<string | IGameStoreEntry>

    determine installation path of this tool/game This function should return quickly and, if it returns a value, it should definitively be the valid tool/game path. Usually this function will query the path from the registry or from steam. This function may return a promise and it should do that if it's doing I/O

    This may be left undefined but then the location for the tool/game can only be set manually

    relative?: boolean

    if true, the tool is expected to be installed relative to the game directory. Otherwise the tool will be detected anywhere on the disk.

    requiredFiles: string[]

    list of files that have to exist in the directory of this tool. This is used by the discovery to identify the tool/game. Vortex will only accept a directory as the tool directory if all these files exist. Please make sure the files listed here uniquely identify the tool, something like 'rpg_rt.exe' would not suffice (rpg_rt.exe is the binary name of a game engine and appears in many games).

    Please specify as few files as possible, the more files specified here the slower the discovery will be.

    Each file can be specified as a relative path (i.e. binaries/UT3.exe), the path is then assumed to be relative to the base directory of the application. It's important this is the case so that Vortex can correctly identify the base directory.

    You can actually use a directory name for this as well.

    Prefer to NOT use executables because those will differ between operating systems so if the tool/game is multi-platform better use a data file.

    requiresCleanup?: boolean

    if true, empty directories are cleaned up during deployment. Right now this defaults to false if mergeMods is true, this defaults to true if mergeMods is false or a function. The reason being that otherwise we would be leaving empty directories every time a mod gets disabled or the deployment name changes. Users can also manually force the cleanup for all games.

    requiresLauncher?: (
        gamePath: string,
        store?: string,
    ) => Bluebird<{ addInfo?: any; launcher: string }>

    Determine whether the game needs to be executed via a launcher, like Steam or EpicGamesLauncher

    If this returns a value, Vortex will use appropriate code for that launcher "launcher" in the returned object is the id of the store to use to launch the game, whether addInfo is required and what it needs to contain depends on the store. For steam you can leave addInfo undefined, for the epic game store it has to be a string with the application id (same id used to discover the game)

    For the windows store it has to be an object with this structure: { appId: , parameters: [ { appExecName: }, ], } The starter id can be found by looking at the appxmanifest.xml file found in the game directory. Look for the Id attribute in the tag. If there are multiple tags, pick the one you actually want Vortex to start.

    Type Declaration

      • (
            gamePath: string,
            store?: string,
        ): Bluebird<{ addInfo?: any; launcher: string }>
      • Parameters

        • gamePath: string

          path where the game is installed.

        • Optionalstore: string

          id of the store the game was detected through

        Returns Bluebird<{ addInfo?: any; launcher: string }>

    setup?: (discovery: IDiscoveryResult) => Bluebird<void>

    Optional setup function. If this game requires some form of setup before it can be modded (like creating a directory, changing a registry key, ...) do it here. It will be called every time before the game mode is activated.

    shell?: boolean

    if true, the tool will be run inside a shell

    shortName?: string

    short/abbreviated variant of the name, still intended for presentation to the user this is used when available space is limited. Try to keep it below 8 characters (there is no fixed limit but layout may break if this is too long) If none is set, falls back to name

    supportedTools?: ITool[]

    list of tools that support this game

    IGame

    version?: string

    contains the version of the game extension