You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
52 lines
28 KiB
52 lines
28 KiB
{
|
|
"api/index.html": {
|
|
"href": "api/index.html",
|
|
"title": "BSIPA API Documentation",
|
|
"keywords": "BSIPA API Documentation Welcome to the full class documentation! To see guides, head over to the Articles tab . Select a namespace and a class on the left to get started."
|
|
},
|
|
"articles/command-line.html": {
|
|
"href": "articles/command-line.html",
|
|
"title": "The Command Line",
|
|
"keywords": "The Command Line BSIPA has 2 command lines: the installer, and the game. Their documentation is below. The Installer ( IPA.exe ) The Game The installer has quite a few options, which are documented inline with the -h or --help flag. This is what it currently looks like: usage: IPA.exe [FLAGS] [ARGUMENTS] flags: -h, --help prints this message -v, --version prints the version that will be installed and is currently installed -w, --waitfor=PID waits for the specified PID to exit -f, --force forces the operation to go through -r, --revert reverts the IPA installation -n, --nowait doesn't wait for user input after the operation -s, --start=ARGUMENTS uses the specified arguments to start the game after the patch/unpatch -l, --launch uses positional parameters as arguments to start the game after patch/unpatch -R, --no-revert prevents a normal installation from first reverting The game also gets quite a few command line options, though there isn't anything as convenient as a help page for them. Here's a quick list of what they are and what they do. --verbose Makes a console appear with log information at startup. --debug Enables the loading of debug information in Mono. The debugging information must be in the portable PDB format, in the same location as the DLL that it's for. This option also forces BSIPA to show all debug messages in the console, as well as where they were called. This overrides the config settings Debug.ShowDebug and Debug.ShowCallSource . --trace Enables trace level messages. By default, they do not ever enter the message queue, and thus cost almost nothing. When this or the config option is used, they are added and logged with the same rules as Debug messages. This overrides the config setting Debug.ShowTrace . --mono-debug Enables the built-in Mono soft debugger engine. By default, it acts as a client, and requires that there be a soft debugger server running on port 10000 on localhost . Implies --debug . --server Does nothing on its own. When paired with --mono-debug , this option makes the Mono soft debugger act in server mode. It begins listening on port 10000 on any address, and will pause startup (with no window) until a debugger is connected. I recommend using SDB, but that is a command line debugger and a lot of people don't care for those. --no-yeet Disables mod yeeting. By default, whenever BSIPA detects that the game is now running a newer version than previous runs, it will move all mods to another folder and not load them. (They still get checked for updates though.) When this is enabled, that behaviour is disabled. Overrides the config setting YeetMods . --condense-logs Reduces the number of log files BSIPA will output for a given session. By default, BSIPA will create a subfolder in the Logs folder for each mod sublog, as well as each mod. This disables that behaviour, and restricts it to only create a global log and mod logs. Overrides the config setting Debug.CondenseModLogs . --plugin-logs Causes each plugins' log messages to be written to files in their own folder for ease of debugging. This was the default through 4.1.6, however is now disabled by default. Overrides the config setting Debug.CreateModLogs ."
|
|
},
|
|
"articles/contributing.html": {
|
|
"href": "articles/contributing.html",
|
|
"title": "Contributing",
|
|
"keywords": "Contributing Prerequisites Microsoft Visual Studio 2019 or later (2017 may work, no guarantees) Tools for C/C++ (MSVC) v141 .NET 4.6.1 SDK and .NET 4.7.2 SDK Beat Saber (if developing for .NET 4.5+) Muse Dash (if developing for .NET 3.5) Building Clone with git clone https://github.com/beat-saber-modding-group/BeatSaber-IPA-Reloaded.git --recursive Create a file, bsinstalldir.txt in the solution root. Do NOT create this in Visual Studio; VS adds a BOM at the begginning of the file that the tools used cannot read. It should contain the path to your Beat Saber installation, using forward slashes with a trailing slash. e.g. C:/Program Files (x86)/Steam/steamapps/common/Beat Saber/ If you intend to be doing .NET 3.5 centric development, you must put your Muse Dash installation folder in a file named mdinstalldir.txt that is otherwise identical to bsinstalldir.txt . Open BSIPA.sln in Visual Studio. Choose the configuration that you intend to target during development. Rebuild all. When you make a change somewhere in BSIPA itself, right click on BSIPA-Meta and click Build or Rebuild . This sets up the output in path/to/solution/BSIPA-Meta/bin/<Configuration> to be what should be copied to the game directory. When making a change to Mod List, you only need to build Mod List itself. Install by copying everything in path/to/solution/BSIPA-ModList/bin/<Configuration> to your game directory. When building a Debug build, all referenced assemblies from Beat Saber will be copied from the install directory provided in bsinstalldir.txt into Refs/ . Any new references should reference the copy in there. When building for Release, it just uses the files already in Refs/ ."
|
|
},
|
|
"articles/dev-resources/description.html": {
|
|
"href": "articles/dev-resources/description.html",
|
|
"title": "Demo Plugin",
|
|
"keywords": "Demo Plugin A little demo for the BSIPA modding introduction. WE CAN USE MARKDOWN!!!"
|
|
},
|
|
"articles/index.html": {
|
|
"href": "articles/index.html",
|
|
"title": "Getting Started",
|
|
"keywords": "Getting Started Starting out is quite simple. Just follow one of the following guides: Installing BSIPA Making your own mod Or, if you want to contribute, see Contributing ."
|
|
},
|
|
"articles/start-dev.html": {
|
|
"href": "articles/start-dev.html",
|
|
"title": "Making your own mod",
|
|
"keywords": "Making a mod Overview What follows is a very barebones, and frankly not very useful plugin class, even as a starting point, but it should be enough to give a decent idea of how to do quick upgrades of existing mods for those who want to. using System; using IPA; using IPA.Logging; namespace Demo { [Plugin(RuntimeOptions.SingleStartInit)] internal class Plugin { public static Logger log { get; private set; } [Init] public Plugin(Logger logger) { log = logger; log.Debug(\"Basic plugin running!\"); // setup that does not require game code // this is only called once ever, so do once-ever initialization } [OnStart] public void OnStart() { // setup that requires game code } [OnExit] public void OnExit() { // teardown } } } There are basically 4 major concepts here: <xref:IPA.Logging.Logger>, the logging system. <xref:IPA.PluginAttribute>, which declares that this class is a plugin and how it should behave. <xref:IPA.InitAttribute>, which declares the constructor (and optionally other methods) as being used for initialization. The lifecycle event attributes <xref:IPA.OnStartAttribute> and <xref:IPA.OnExitAttribute>. I reccommend you read the docs for each of those to get an idea for what they do. It is worth noting that this example is of a mod that cannot be enabled and disabled at runtime, as marked by RuntimeOptions.SingleStartInit . What can be changed Before we go adding more functionality, its worth mentioning that that is not the only way to have a plugin set up. For starters, we can add another method marked [Init] , and it will be called after the constructor, with the same injected parameters, if those are applicable. [Init] public void Init(Logger logger) { // logger will be the same instance as log currently is } If you only had a method marked [Init] , and no constructors marked [Init] , then the plugin type must expose a public default constructor. If multiple constructors are marked [Init] , only the one with the most parameters will be called. You may also mark as many methods as you wish with [Init] and all of them will be called, in no well-defined order on initialization. The same is true for [OnStart] and [OnExit] , respectively. From Scratch If you are starting from scratch, you will need one other thing to get your plugin up and running: a manifest. A basic manifest for that might look a little like this: { \"author\": \"ExampleMan\", \"description\": [ \"A demo plugin written for the BSIPA basic tutorial.\" ], \"gameVersion\": \"1.6.0\", \"id\": null, \"name\": \"Demo Plugin\", \"version\": \"0.0.1\", \"links\": { \"project-source\": \"https://github.com/exampleman/demo-plugin/\", \"donate\": \"https://ko-fi.com/exampleman\" }, } There is a lot going on there, but most of it should be decently obvious. Among the things that aren't immediately obvious, are id : This represents a unique identifier for the mod, for use by package managers such as BeatMods. It may be null if the mod chooses not to support those. features : Don't worry about this for now, this is a not-very-simple thing that will be touched on later. In addition, there are a few gatchas with it: description : This can be either a string or an array representing different lines. Markdown formatting is permitted. gameVersion : This should match exactly with the application version of the game being targeted. While this is not enforced by BSIPA, mod repositories like BeatMods may require it match, and it is good practice regardless. version : This must be a valid SemVer version number for your mod. In order for your plugin to load, the manifest must be embedded into the plugin DLL as an embedded resource. This can be set in the Visual Studio file properties panel under Build Action , or in the .csproj like so: <ItemGroup> <EmbeddedResource Include=\"manifest.json\" /> </ItemGroup> At this point, if the main plugin source file and the manifest are in the same source location, and the plugin class is using the project's default namespace, the plugin will load just fine. However, this is somewhat difficult both to explain and verify, so I recommend you use the the misc.plugin-hint field in your manifest. It can be used like so: \"misc\": { \"plugin-hint\": \"Demo.Plugin\" } With this, you can set plugin-hint to the full typename of your plugin type, and it will correctly load. This is a hint though, and will also try it as a namespace if it fails to find the plugin type. If that fails, it will then fall back to using the manifest's embedded namespace. A less painful description If you want to have a relatively long or well-formatted description for your mod, it may start to become painful to embed it in a list of JSON strings in the manifest. Luckily, there is a way to handle this. The first step is to create another embedded file, but this time it should be a Markdown file, perhaps description.md . It may contain something like this: # Demo Plugin A little demo for the BSIPA modding introduction. --- WE CAN USE MARKDOWN!!! Then, in your manifest description, have the first line be something look like this, but replacing Demo.description.md with the fully namespaced name of the resource: \"#![Demo.description.md]\", Now, when loaded into memory, if anything reads your description metadata, they get the content of that file instead of the content of the manifest key. Configuring your plugin Something that many plugins want and need is configuration. Fortunately, BSIPA provides a fairly powerful configuration system out of the box. To start using it, first create a config class of some kind. Lets take a look at a fairly simple example of this: namespace Demo { public class PluginConfig { public static PluginConfig Instance { get; set; } public int IntValue { get; set; } = 42; public float FloatValue { get; set; } = 3.14159f; } } Notice how the class is both marked public and is not marked sealed . For the moment, both of these are necessary. Also notice that all of the members are properties. While this doesn't change much now, it will be significant in the near future. Now, how do we get this object off of disk? Simple. Back in your plugin class, change your [Init] constructor to look like this: [Init] public Plugin(Logger logger, Config conf) { log = logger; PluginConfig.Instance = conf.Generated<PluginConfig>(); log.Debug(\"Config loaded\"); // setup that does not require game code } For this to compile, though, we will need to add a few using s: using IPA.Config; using IPA.Config.Stores; With just this, you have your config automatically loading from disk! It's even reloaded when it gets changed mid-game! You can now access it from anywhere by simply accessing PluginConfig.Instance . Make sure you don't accidentally reassign this though, as then you will loose your only interaction with the user's preferences. By default, it will be named the same as is in your plugin's manifest's name field, and will use the built-in json provider. This means that the file that will be loaded from will be UserData/Demo Plugin.json for our demo plugin. You can, however, control both of those by applying attributes to the <xref:IPA.Config.Config> parameter, namely <xref:IPA.Config.Config.NameAttribute> to control the name, and <xref:IPA.Config.Config.PreferAttribute> to control the type. If the type preferences aren't registered though, it will just fall back to JSON. The config's behaviour can be found either later here, or in the remarks section of <xref:IPA.Config.Stores.GeneratedStore.Generated``1(IPA.Config.Config,System.Boolean)>. At this point, your main plugin file should look something like this: using System; using IPA; using IPA.Logging; using IPA.Config; using IPA.Config.Stores; namespace Demo { [Plugin(RuntimeOptions.SingleStartInit)] internal class Plugin { public static Logger log { get; private set; } [Init] public Plugin(Logger logger, Config conf) { log = logger; PluginConfig.Instance = conf.Generated<PluginConfig>(); log.Debug(\"Config loaded\"); // setup that does not require game code } [OnStart] public void OnStart() { // setup that requires game code } [OnExit] public void OnExit() { // teardown } } } But what about more complex types than just int and float ? What if you want sub-objects? Those are supported natively, and so are very easy to set up. We just add this to the config class: public class SubThingsObject { public double DoubleValue { get; set; } = 2.718281828459045; } public SubThingsObject SubThings { get; set; } = new SubThingsObject(); Now this object will be automatically read from disk too. But there is one caveat to this: because SubThingsObject is a reference type, SubThings can be null . This is often undesireable. The obvious solution may be to simply change it to a struct , but that is both not supported and potentially undesirable for other reasons we'll get to later. Instead, you can use <xref:IPA.Config.Stores.Attributes.NonNullableAttribute>. Change the definition of SubThings to this: [NonNullable] public SubThingsObject SubThings { get; set; } = new SubThingsObject(); And add this to the using s: using IPA.Config.Stores.Attributes; This attribute tells the serializer that null is an invalid value for the config object. This does, however, require that you take extra care ensure that it never becomes null in code, as that will break the serializer. What about collection types? Well, you can use those too, but you have to use something new: a converter. You may be familiar with them if you have used something like the popular Newtonsoft.Json library before. In BSIPA, they lie in the <xref:IPA.Config.Stores.Converters> namespace. All converters either implement <xref:IPA.Config.Stores.IValueConverter> or derive from <xref:IPA.Config.Stores.ValueConverter`1>. You will mostly use them with an <xref:IPA.Config.Stores.Attributes.UseConverterAttribute>. To use them, we'll want to import them: using System.Collections.Generic; using IPA.Config.Stores; using IPA.Config.Stores.Converters; Then add a field, for example a list field: [UseConverter(typeof(ListConverter<string>))] public List<string> ListValue { get; set; } = new List<string>(); This uses a converter that is provided with BSIPA for List<T> s specifically. It converts the list to an ordered array, which is then written to disk as a JSON array. We could also potentially want use something like a HashSet<T> . Lets start by looking at the definition for such a member, then deciphering what exactly it means: [UseConverter(typeof(CollectionConverter<string, HashSet<string>>))] public HashSet<string> SetValue { get; set; } = new HashSet<string>(); The converter we're using here is <xref:IPA.Config.Stores.Converters.CollectionConverter`2>, a base type for converters of all kinds of collections. In fact, the <xref:IPA.Config.Stores.Converters.ListConverter`1> is derived from this, and uses it for most of its implementation. If a type implements ICollection<T> , <xref:IPA.Config.Stores.Converters.CollectionConverter`2> can convert it. It, like most other BSIPA provided aggregate converters, provides a type argument overload <xref:IPA.Config.Stores.Converters.CollectionConverter`3> to compose other converters with it to handle unusual element types. Now after all that, your plugin class has not changed, and your config class should look something like this: using System.Collections.Generic; using IPA.Config.Stores; using IPA.Config.Stores.Attributes; using IPA.Config.Stores.Converters; namespace Demo { public class PluginConfig { public static PluginConfig Instance { get; set; } public class SubThingsObject { public double DoubleValue { get; set; } = 2.718281828459045; } public int IntValue { get; set; } = 42; public float FloatValue { get; set; } = 3.14159f; [NonNullable] public SubThingsObject SubThings { get; set; } = new SubThingsObject(); [UseConverter(typeof(ListConverter<string>))] public List<string> ListValue { get; set; } = new List<string>(); [UseConverter(typeof(CollectionConverter<string, HashSet<string>>))] public HashSet<string> SetValue { get; set; } = new HashSet<string>(); } } I mentioned earlier that your config file will be automatically reloaded -- but isn't that a bad thing? Doesn't that mean that the config could change under your feet without you having a way to tell? Not so- I just haven't introduced the mechanism. Define a public or protected virtual method named OnReload : public virtual void OnReload() { // this is called whenever the config file is reloaded from disk // use it to tell all of your systems that something has changed // this is called off of the main thread, and is not safe to interact // with Unity in } This method will be called whenever BSIPA reloads your config from disk. When it is called, the object will already have been populated. Use it to notify all of your systems that configuration has changed. Now, we know how to read from disk, and how to use unusual types, but how do we write it back to disk? This config system is based on automatic saving (though we haven't quite gotten to the automatic part), and so the config is written to disk whenever the system recognizes that something has changed. To tell is as much, define a public or protected virtual method named Changed : public virtual void Changed() { // this is called whenever one of the virtual properties is changed // can be called to signal that the content has been changed } This method can be called to tell BSIPA that this config object has changed. Later, when we enable automated change tracking, this will also be called when one of the config's members changes. You can use this body to validate something or, for example, write a timestamp for last change. I just mentioned automated change tracking -- lets add that now. To do this, just make all of the properties virtual, like so: public class SubThingsObject { public virtual double DoubleValue { get; set; } = 2.718281828459045; } public virtual int IntValue { get; set; } = 42; public virtual float FloatValue { get; set; } = 3.14159f; [NonNullable] public virtual SubThingsObject SubThings { get; set; } = new SubThingsObject(); [UseConverter(typeof(ListConverter<string>))] public virtual List<string> ListValue { get; set; } = new List<string>(); [UseConverter(typeof(CollectionConverter<string, HashSet<string>>))] public virtual HashSet<string> SetValue { get; set; } = new HashSet<string>(); Now, whenever you assign to any of those properties, your Changed method will be called, and the config object will be marked as changed and will be written to disk. Unfortunately, any properties that can be modified while only using the property getter do not trigger this, and so if you change any collections for example, you will have to manually call Changed . After doing all this, your config class should look something like this: using System.Collections.Generic; using IPA.Config.Stores; using IPA.Config.Stores.Attributes; using IPA.Config.Stores.Converters; namespace Demo { public class PluginConfig { public static PluginConfig Instance { get; set; } public class SubThingsObject { public virtual double DoubleValue { get; set; } = 2.718281828459045; } public virtual int IntValue { get; set; } = 42; public virtual float FloatValue { get; set; } = 3.14159f; [NonNullable] public virtual SubThingsObject SubThings { get; set; } = new SubThingsObject(); [UseConverter(typeof(ListConverter<string>))] public virtual List<string> ListValue { get; set; } = new List<string>(); [UseConverter(typeof(CollectionConverter<string, HashSet<string>>))] public virtual HashSet<string> SetValue { get; set; } = new HashSet<string>(); public virtual void Changed() { // this is called whenever one of the virtual properties is changed // can be called to signal that the content has been changed } public virtual void OnReload() { // this is called whenever the config file is reloaded from disk // use it to tell all of your systems that something has changed // this is called off of the main thread, and is not safe to interact // with Unity in } } } There is one more major problem with this though: the main class is still public. Most configs shouldn't be. Lets make it internal. So we make it internal: internal class PluginConfig But to make it actually work, we add this outside the namespace declaration: using System.Runtime.CompilerServices; [assembly: InternalsVisibleTo(GeneratedStore.AssemblyVisibilityTarget)] And now our full file looks like this: using System.Collections.Generic; using System.Runtime.CompilerServices; using IPA.Config.Stores; using IPA.Config.Stores.Attributes; using IPA.Config.Stores.Converters; [assembly: InternalsVisibleTo(GeneratedStore.AssemblyVisibilityTarget)] namespace Demo { internal class PluginConfig { public static PluginConfig Instance { get; set; } public class SubThingsObject { public virtual double DoubleValue { get; set; } = 2.718281828459045; } public virtual int IntValue { get; set; } = 42; public virtual float FloatValue { get; set; } = 3.14159f; [NonNullable] public virtual SubThingsObject SubThings { get; set; } = new SubThingsObject(); [UseConverter(typeof(ListConverter<string>))] public virtual List<string> ListValue { get; set; } = new List<string>(); [UseConverter(typeof(CollectionConverter<string, HashSet<string>>))] public virtual HashSet<string> SetValue { get; set; } = new HashSet<string>(); public virtual void Changed() { // this is called whenever one of the virtual properties is changed // can be called to signal that the content has been changed } public virtual void OnReload() { // this is called whenever the config file is reloaded from disk // use it to tell all of your systems that something has changed // this is called off of the main thread, and is not safe to interact // with Unity in } } }"
|
|
},
|
|
"articles/start-user.html": {
|
|
"href": "articles/start-user.html",
|
|
"title": "Installing BSIPA",
|
|
"keywords": "Installing BSIPA Note This guide assumes that you are starting completely fresh. Grab a release from the GitHub Releases page . Make sure to download one of the BSIPA-*.zip s, as ModList.zip contains the Beat Saber mod for showing your mods in-game, not the loader itself. Note The specific ZIP you need to download varies on the game you will be patching. For example, if you are patching Beat Saber, you will need the file BSIPA-x64-Net4.zip . This is because Beat Saber is a 64 bit game running .NET 4. If you are patching Muse Dash, however, you nee the file BSIPA-x86-Net3.zip . Tip There are a few tricks for figuring out which file you need. If the game has a folder called MonoBleedingEdge in the install directory, then you need one of the Net4 builds. To determine which build to use, right click on the game executable, go to the Compatability tab, check the Run this program in compatability mode for checkbox, and look and see if the dropdown has any Windows XP emulation options. If it does, the application is 32 bit, and you need to get one of the x86 builds. Otherwise, get one of the x64 builds. Make sure to uncheck that checkbox before leaving the menu. Extract the zip into your game installation directory. There should now be a folder named IPA and a file named IPA.exe in the same folder as the game executable. For example, if you are installing BSIPA in Beat Saber, it might look like this after extraction: Run IPA.exe by double clicking it. A console window should pop up, and eventually, a gold message asking you to press a key will appear. Here is an example of a successful installation: Note In some cases, this may fail, something like this: In these cases, try dragging the game executable over IPA.exe . After installing, your game directory should look something like this: Note At this point it is recommended to run the game once before continuing, to ensure that things are installed correctly. The first run should create a UserData folder with Beat Saber IPA.json and Disabled Mods.json , as well as a Logs folder with several subfolders with their own files. If these are created, then the installation was very likely successful. Tip If you are not installing BSIPA on Beat Saber, you probably want to go to the config at UserData/Beat Saber IPA.json and set both of the following to false : { ... \"Updates\": { \"AutoUpdate\": false, \"AutoCheckUpdates\": false }, ... } Tip Depending on the game, you may have to set the config member GameAssemblies to the names of the assemblies that the game uses for BSIPA to virtualize them properly. For Beat Saber distrobutions, this will be set according to the version that it was built for by default. Otherwise, it will contain just Assembly-CSharp.dll since most games use that default. From here, just place all of your plugins in the Plugins folder, and you're all set! Many plugins will come in a zip such that the root of the zip represents the game install directory, so all you may have to do is extract the plugin into the game installation folder. Note For some reason, by default, Wine does not load DLLs in quite the same way that Windows does, causing issues with the injection. To make the injection work with Wine, winhttp has to have a DLL override set to native,builtin . This can be set either through Protontricks, or with the following .reg file. REGEDIT4 [HKEY_CURRENT_USER\\Software\\Wine\\DllOverrides] \"winhttp\"=\"native,builtin\" For Steam there's a per-game Wine prefix under compatdata . In this case SteamLibrary/steamapps/compatdata/620980/pfx/user.reg . Changes to this file will likely be ovewritten when the game updates or if local files are validated through Steam. Thats really all you have to do! The installation should persist across game updates for as long as winhttp.dll is present in the game directory, though your plugins will be moved to a different folder when it does update so things don't break horribly. Uninstalling Uninstalling is fairly simple, and can be done one of two ways: Drag the game executable over IPA.exe while holding Alt . Open a command prompt or Powershell terminal and run .\\IPA.exe -rn . (see The Command Line for what those options mean)"
|
|
},
|
|
"index.html": {
|
|
"href": "index.html",
|
|
"title": "BSIPA - Home",
|
|
"keywords": "BSIPA - The Unity mod injector for the new age (pending confirmation). Assuming, that is, that Unity 2017 is \"new age\". How To Install See Installing How To Uninstall See Uninstalling Arguments See The Command Line . How To Develop See Developing for more information. How To Keep The Game Patched BSIPA will automatically repatch the game when it updates, as long as winhttp.dll is present in the install directory."
|
|
},
|
|
"other_api/config/schema.html": {
|
|
"href": "other_api/config/schema.html",
|
|
"title": "Configuration File Schema",
|
|
"keywords": "Configuration File Schema <!-- Can not find reference _schema.json -->"
|
|
},
|
|
"other_api/index.html": {
|
|
"href": "other_api/index.html",
|
|
"title": "",
|
|
"keywords": ""
|
|
}
|
|
}
|