- String: a string value
- TagName: Path to a specific tag definition (without the group extension)
- DataName: Path to a specific file in the data sub-folder
- Switch: can be a boolean value (true/false) or switch (0/1)
- Directory: Path to a folder in the tags or data sub-folder
Builds a cache file with extra Open Sauce arguments. Output cache file will be in .yelo format instead of .map if use-memory-updates is on.
|mod-name||String||The name of the mod this scenario belongs to. This will also be used when naming the new data-files|
|create-anew||Switch||Should new data-files be created before building the cache?|
|store-resources||Switch||Should the scenario's bitmaps/sounds/locale data be stored in the data-files?|
|use-memory-upgrades||Switch||Does the scenario require Open Sauce's memory upgrades to run? Produces .yelo file instead of .map|
|scenario-name||TagName||Name of the .scenario to use. Just like the stock build-cache-file|
You'll need to turn use-memory-upgrades on if:
- You're using mod-sets to store-resources externally in those data files
- You're using OS-specific script functions or globals
- Your scenario's scripts need more than the standard amount of script limits to compile.
- Your map needs more than the standard amount of tag memory.
- Your map needs more than the standard amount of tag instances.
- Your map uses unit seat extensions (such as boarding)
shader_postprocess_generic tags from HLSL .fx shaders in the data directory
|shader-directory||Directory||Path that contains the shaders to compile|
Replaces the lightmap UVs of a bsp with custom ones loaded from an obj file. The obj file must have lightmaps grouped by object and in ascending order (lightmap_0 to lightmap_n). Best way to ensure this is to export a fresh lightmaps obj using Aether, import it into your modelling program then ONLY edit the UV's to ensure the model matches the bsp.
|structure-bsp||TagName||location of the target bsp, relative to the tags directory|
|obj-file||DataName||location of the source obj, relative to the data directory|
Creates a c++ definition header file mapping out the tag structure of a specified tag. The resulting header file is saved to the working directory of OS_Tool.
|tag-group||String||4 character identifier for the tag type type you want a definition of. E.g., bitm|
|add-boost-asserts||Switch||Controls whether to add
Reads the tag cache and tag instances from a running instance of haloce, displaying the addresses, offsets and values of tag fields for easier reverse engineering. Also has basic memory writing for runtime editing of tag values.
Collates a set of files into a single package that OS can load. Only used for OS features that require data that can't be in a map cache, such as the OS UI and postprocessing shaders.
|source-directory||String||The absolute directory to use as the root of all relative paths.|
|output-directory||String||The directory to save the resulting file to.|
|file-definition-xml||String||Relatice path to the packed file definition xml.|
Removes OpenSauce data from tags that would prevent the stock tools from working. WARNING: DESTRUCTIVE!
|tag-name||String||The tag to purge of OS data.|
|tag-type||String||The type of the tag (file extension).|
|recursive||Boolean||Controls whether to process all of the tags that are referenced by the specified tag|