MeFisto94

Andraste Modding Framework The Andraste Modding Framework is a generic modding framework, that aims to allow you to modify a wide range of (currently 32bit) applications via both simple file replacements ( mods ) and manipulating it's code via C# ( plugins ) Note: This current release requires you to be tech-savy and is primarly aimed at mod developers and to find problems with the base-framework. It won't provide major features, yet, so don't sweat it, if you can't get it to run. Note: While this is in the TDU2 category, Andraste can also be used for TDU1 and potentially a lot of other games (unless they are 64 bits or have some protective anti cheat system) How to run Andraste Currently, Andraste only comes with a console launcher, so to launch it, you need to execute the Launcher.exe and pass one or two arguments (within ""s, if the path contains spaces): First, the path to the Application you want to run (here, TestDrive.exe for TDU2 or TDU1) and potentially the second, the DLL to inject (currently defaulting to Andraste.Payload.Generic.dll, as there is no published game specific payload available yet). If Andraste is running, it should write logging into the output.log and error.log in the Launcher directory, which is streamed into console window of the launcher. At this point, you can start creating mods that will then be loaded into your game. Currently, since the Launcher has no proper GUI, all mods are always loaded, you can't toggle them, but you can move them out of the mods folder. Converting a Mod into the Andraste Format The Andraste Launcher is searching for mods in the subfolder "mods", so you need to create that folder first. Then, add a subfolder for each of the mods you want to convert. In this case, I've used This Audi R8. You need to find a unique foldername (also called slug), such as "r8-v10-2017". For that folder to be recognized as a mod, it needs to have a mod.json file. You can always see the most recent file format specification in the code on github: https://github.com/AndrasteFramework/Shared/blob/master/ModManagement/Json/ModInformation.cs An example file for the Audi R8 is: { "slug": "r8-v10-2017", "name": "2017 Audi R8", "displayVersion": "1.0.0", "authors": ["Star GT", "Brian Balliu"], "description": "2017 Audi R8 V10 Plus Coupe S Tronic", "configurations": { "default": { "features": { "andraste.builtin.vfs": { "directories": [ "mod-data/" ], "files": {} } } } } } The metadata part should be self explanatory, this information is only used to display mod information to the user (especially later when a proper GUI is there). Then, Andraste supports multiple configurations per mod, you can think of those as the most basic form of settings, e.g. you could have a "high-definition" configuration and a "performance" configuration. Currently, you can only have one configuration, that should be called default, because the user cannot yet decide between multiple configurations. Every configuration is furthermore defined by settings passed to features. A feature can be built in, such as the VFS feature that this example uses, but can also be registered and consumed by a plugin (in later stages of the framework, not yet implemented). This allows you to extend the framework with support plugins, that can be used by other mods (or to allow mods to configure other mods). The built-in VFS Feature VFS means Virtual File System. In this context, that means, the real hard-drive is abstracted away via software. This allows Andraste to redirect every attempt of the game to edit a file (Caution: currently this is not read-only, the game could also overwrite your mod files) into a subdirectory of your mod-directory. The andraste.builtin.vfs feature supports the directories setting (which is the recommended way): Define a directory in which Andraste will look for files. Those files will then be mounted into the game. So in this case, if you had a "a.txt" file inside "mod-data", it would be treated as if "a.txt" would be in the game root folder. This means, for TDU2, you want to have the "Euro" folder directly under the mod-data folder. This leaves our example with a folder structure of mods/r8-v10-2017/mod-data/Euro/.... It also supports the files setting: This is an object from game-relative path to mod path, so { "a.txt": "my-mod-data/b.txt" } would redirect a.txt into b.txt in your mod folder. This is especially relevant, if you want to use the same mod file for multiple game files (e.g. sharing a texture), so you can just point them onto the same file, without having to duplicate them in your mod folder. You can also use this to redirect the game to an invalid file (any path would do, as long as it's not plain invalid), so that the game cannot load the file. If you use "INTENTIONAL" as the mod path, Andraste will NOT emit a warning, which it would do, if you otherwise try to redirect into an invalid file (it could be a typo). If you managed to convert a mod, you can now use (and remove!) these game mods, without changing your unpacked(!) base game (the game needs to be unpacked, because the VFS feature only replaces existing files, it doesn't create packed files yet. While this feature may not be impressive yet (besides removing mods without having to have a backup of your game folder somewhere), there is much more possible with that technique, but that takes manpower and time. Internally, we're currently using the scripting functionality to find out more about the game and progress on different fronts such as multiplayer or asset manager, so definitely stay tuned for further progress, at some point, we will release the TDU2 Modding Framework, that is an additional layer on top of Andraste, providing TDU2 specific features (patching files inside BNKs, running on a packed game, hot reloading, ...) If you need further assistance, don't hesitate to post in the relevant forum thread, here on turboduck or in #tdu-modding on https://discord.tduniverse.org Andraste is a TDUniverse Umbrella Project by MeFisto94 and redd