Thank you for using the mod template! Here are a few tips to help you on your journey:
BepInEx uses semantic versioning, or semver, for the mod's version info. MinVer will automatically version your mod based on the latest git tag, as well as the number of commits made since then.
To create a new git tag, you can either use the git cli, or a git client, such as GitHub Desktop, GitKraken, or the one built into your IDE. For command line use, you can simply type in the following commands in the terminal/shell:
git tag v1.2.3
git push --tags
This creates a new tag, v1.2.3
, at the currently checked-out commit,
and pushes the tag to the git version-control system (vcs).
MinVer will then be able to use this when you build your project to set your mod's version.
Note: You must have a
v
in front of the version number, otherwise MinVer will not recognize it.If you prefer not to have
v1.2.3
and instead1.2.3
, you can remove the<MinVerTagPrefix>v</MinVerTagPrefix>
line in your.csproj
file.
A logger is provided to help with logging to the console.
You can access it by doing Plugin.Logger
in any class outside the Plugin
class.
Please use LogDebug()
whenever possible, as any other log method
will be displayed to the console and potentially cause performance issues for users.
If you chose to do so, make sure you change the following line in the BepInEx.cfg
file to see the Debug messages:
[Logging.Console]
# ... #
## Which log levels to show in the console output.
# Setting type: LogLevel
# Default value: Fatal, Error, Warning, Message, Info
# Acceptable values: None, Fatal, Error, Warning, Message, Info, Debug, All
# Multiple values can be set at the same time by separating them with , (e.g. Debug, Warning)
LogLevels = All
This template uses harmony. For more specifics on how to use it, look at the HarmonyX GitHub wiki and the Harmony docs.
To make a new harmony patch, just use [HarmonyPatch]
before any class you make that has a patch in it.
Then in that class, you can use
[HarmonyPatch(typeof(ClassToPatch), nameof(ClassToPatch.MethodToPatch))]
where ClassToPatch
is the class you're patching (ie TVScript
), and MethodToPatch
is the method you're patching (ie SwitchTVLocalClient
).
Then you can use the appropriate prefix, postfix, transpiler, or finalizer attribute.
While you can use return false;
in a prefix patch,
it is HIGHLY DISCOURAGED as it can AND WILL cause compatibility issues with other mods.
For example, we want to add a patch that will debug log the current players' position.
We have the following postfix patch patching the SwitchTVLocalClient
method
in TVScript
:
using HarmonyLib;
namespace LCCameraPosition.Patches;
[HarmonyPatch(typeof(TVScript))]
public class ExampleTVPatch
{
[HarmonyPatch(nameof(TVScript.SwitchTVLocalClient))]
[HarmonyPrefix]
private static void SwitchTvPrefix(TVScript __instance)
{
/*
* When the method is called, the TV will be turning off when we want to
* turn the lights on and vice-versa. At that time, the TV's tvOn field
* will be the opposite of what it's doing, ie it'll be on when turning off.
* So, we want to set the lights to what the tv's state was
* when this method is called.
*/
StartOfRound.Instance.shipRoomLights.SetShipLightsBoolean(__instance.tvOn);
}
}
In this case we include the type of the class we're patching in the attribute
before our ExampleTVPatch
class,
as our class will only patch the TVScript
class.