Mod Creation/Essentials: Difference between revisions

Before you begin writing code, it's a good idea to start by defining some metadata in the manifest.json file. A complete manifest.json might look like the following:

   "namespace": "helloWorld",

   "icon": "assets/icon.png",

   "setup": "src/setup.mjs",

   "load": ["assets/style.css"]

==== namespace?: string ====

The namespace can only contain alphanumeric characters and underscores and cannot start with the word "melvor".

|-

| <code>helloWorld</code> || ✔️

Let's start with what a module that's defined as your mod's <code>"setup"</code> entry-point should look like:

export function setup(ctx) {

   console.log('Hello World!');

We export a function named <code>setup</code> here because that is what the Mod Manager looks for when loading a <code>"setup"</code> module. Without one, an error would be thrown when loading this mod. This <code>setup</code> function is called and receives the mod's context object as soon as the mod is loaded, which happens just before the character select screen is visible. Therefore, this mod would write 'Hello World!' to the console at that time.

If we define a helper module helper.mjs:

export function greet(name) {

   console.log(`Hello, ${name}!`);

We can then use code we export in our setup function:

export async function setup({ loadModule }) {

   const { greet } = await loadModule('helper.mjs');

   greet('Melvor'); // > Hello, Melvor!

If you need to access the context object from your helper module, there are two approaches:

1. Pass the context object from the setup function to the loaded module:

export function init(ctx) {

   // Perform actions using the context object here...

   const configService = await ctx.loadModule('configService.mjs');

   configService.init(ctx);

2. Use the <code>getContext</code> method on the global <code>mod</code> object:

const ctx = mod.getContext(import.meta);

export function init() {

   // Perform actions using the context object here...

==== Using Scripts ====

Loading a script through the context object is very similar to loading a module but you will not receive back a value.

   // Make sure you await the call to loadScript if your code beyond relies on it

   await loadScript('hello-melvor-script.js');

   // But don't bother awaiting it if it's not time-sensitive

   loadScript('some-independent-script.js');

From inside your script, you can still access the context object:

   // Use the context object here

Note that the mod.register method will only work on scripts injected through either loadScript or the "load" property of the manifest.

=== Load (Import) a Module ===

export function greet(name) {

   console.log(`Hello, ${name}!`);

}

export async function setup({ loadModule }) {

   const myModule = await loadModule('my-module.mjs');

   myModule.greet('Melvor'); // Hello, Melvor!

   console.log(myModule.importantData.reverse().join('')); // hello there

=== Load (Inject) a Script ===

export await function setup({ loadScript }) {

   // Wait for script to run

   // Or not

   loadScript('my-independent-script.js');

=== Load (Inject) HTML Templates ===

export function setup({ loadTemplates }) {

   loadTemplates('my-templates.html');

=== Load (Inject) a Stylesheet ===

export function setup({ loadStylesheet }) {

   loadStylesheet('my-styles.css');

=== Load Data from JSON ===

{

   "coolThings": [

     "rocks"

   ]

export async function setup({ loadData }) {

   const data = await loadData('my-data.json');

   console.log(data.coolThings[0]); // ['rocks']  

=== Images, Sounds, and Anything Else ===

export function setup({ getResourceUrl }) {

   const url = getResourceUrl('sea-shanty-2.ogg');

   song.loop = true;

   song.play();

== Game Lifecycle Hooks ==

All of the game's lifecycle hooks are available through your mod's context object and accept a callback function as a sole parameter. This callback function can be synchronous or asynchronous and will be executed at the specified time and receive your mod's context object as a parameter.

export function setup({ onModsLoaded, onCharacterLoaded, onInterfaceReady }) {

   onModsLoaded(ctx => {

     // Build or modify in-game UI elements

   });

== Adding and Modifying Game Objects ==

To begin with this approach, your JSON files should all be constructed with:

   "$schema": "https://melvoridle.com/assets/schema/gameData.json",

   "data": {

   }

If you're using a text editor that supports it, you should now get autocomplete and type checking on the fields you create.

Here is an example of defining an item:

   "$schema": "https://melvoridle.com/assets/schema/gameData.json",

   "data": {

     }]

   }

You would then register your game data using one of the following methods:

{

   "namespace": "helloWorld",

   "load": ["path-to-your-data.json"]

''or''

export async function setup({ gameData }) {

   await gameData.addPackage('path-to-your-data.json');

=== Building a Data Package at Runtime ===

The entry-point for using this approach looks like this:

export function setup({ gameData }) {

   gameData.buildPackage((p) => {

     // use the `p` object to add game objects

   }).add();

Following the same example above of adding an item:

export function setup({ gameData }) {

   gameData.buildPackage((p) => {

     });

   }).add();

Your game data should already be registered from the <code>.add()</code> method being called on your built package.

Settings are divided (in code and visually) into sections. Get or create a section using the <code>section(name)</code> method on the <code>settings</code> object. The value passed in for the <code>name</code> parameter is used as a header for the section, so this should be human-readable. These sections are displayed in the order that they are created.

export function setup({ settings }) {

   // Creates a section labeled "General"

   // Future calls to that section will not create a new "General" section, but instead return the already existing one

   settings.section('General');

The object returned from using <code>section()</code> can then be used for adding settings to that section. Refer to the next section for settings configurations.

export function setup({ settings }) {

   const generalSettings = settings.section('General');

     hint: '1 through 10'

   }]);

You can then <code>get</code> or <code>set</code> the value of any defined setting by its <code>name</code> property.

const { settings } = mod.getContext(import.meta);

const generalSettings = settings.section('General');

generalSettings.set('pick-a-number', 1);

=== Setting Types ===

Each of the customizable (categories, items, subitems) pieces are generally interacted with the same way.

const attack = sidebar.category('Combat').item('Attack'); // Get the Attack item within Combat or create one if it doesn't exist

In addition, these can be called with a configuration object as a second parameter to create or update the existing piece with the new configuration.

   before: 'Attack', // Move the Slayer item above Attack

   ignoreToggle: true // Keep Slayer visible when its category has been hidden

The full definition of each sidebar piece's configuration object can be found in the [[Mod Creation/Sidebar API Reference]] guide.

If you need to retrieve all existing categories, items, or subitems, use their respective methods:

sidebar.category('Combat').items(); // returns an array of all Combat items

Removing categories, items, and subitems is also possible:

sidebar.removeCategory('Combat'); // Alternative (this avoids creating a Combat category if it didn't already exist)

sidebar.removeAllCategories(); // Remove all categories, but why?

// Same kind of structure for items and subitems:

sidebar.category('Modding').item('Mod Manager').remove();

== Creating Reusable HTML Components ==

If you have the following HTML file:

<template id="counter-component">

   <span class="text-light">{{ count }}</span>

   <button class="btn btn-secondary" @click="inc">+</button>

You would import the template in one of the following two ways:

{

   "load": "templates.html"

''or''

export function setup({ loadTemplates }) {

   loadTemplates('templates.html');

=== Defining a Component ===

Using the [https://github.com/vuejs/petite-vue#components PetiteVue documentation on components], you should define each component as a function. This component should define its template selector using the <code>$template</code> property, and then any additional properties or methods that the rendered component will use. For example:

   return {

     $template: '#counter-component',

     }

   };

=== Creating a Component Within the UI ===

Now that your template is loaded and you have a component defined, you can use the helper function <code>ui.create</code> to create an instance of the component within the UI.

== Storing Data ==

There are two options for storing data for your mod that isn't already saved as part of the game or settings: data saved with a character or data saved to the player's account. For most cases, however, character storage should be the preferred location and account storage used sparingly. Both of these stores are available through your mod's context object, as <code>characterStorage</code> and <code>accountStorage</code>, respectively. Aside from where the data is ultimately saved, character and account storage have identical methods and behaviors. Character storage is not available until after a character has been loaded (<code>onCharacterLoaded</code> lifecycle hook).

export function setup({ characterStorage }) {

   // This would all function identically with accountStorage, but also be available across characters

   characterStorage.clear(); // Removes all currently stored items

=== Limitations ===

A common modding scenario is to want to override/modify an in-game method or perform an action before or after it has completed. Your mod's context object contains a patch property that can be used for this these cases. Patches can only be applied to methods that exist on a JavaScript class (<code>Player</code>, <code>Enemy</code>, <code>CombatManager</code>, <code>Woodcutting</code>, etc.). To start, define the class and method that you want to patch:

export function setup({ patch }) {

   const xpPatch = patch(Skill, 'addXP');

From there you can use that patch to perform any of the following actions.

Use the <code>before</code> method on the patch object to execute code immediately before the patched method. In addition, the callback hook will receive the arguments that were used to call the patched method as parameters, and can optionally modify them by returning the new arguments as an array.

export function setup({ patch }) {

   patch(Skill, 'addXP').before((amount, masteryAction) => {

     return [amount * 2, masteryAction]; // Double all XP gains

   });

=== Do Something After ===

Use the <code>after</code> method on the patch object to execute code immediately after the patched method. In addition, the callback hook will receive the value returned from the patched method along with the arguments used to call it as parameters. Optionally, an after hook can choose to override the returned value by returning a value itself. '''''Only''' a return value of <code>undefined</code> will be ignored.''

export function setup({ patch }) {

   patch(Player, 'rollToHit').after((willHit) => {

     return true;

   });

=== Replace the Method Entirely ===

The <code>replace</code> method on the patch object will override the patched method's body, but before and after hooks will still be executed. The replacement method will receive the current method implementation (the one being replaced) along with the arguments used to call it as parameters. The return value of the replacement method will be the return value of the method call, subject to any changes made in an after hook.

export function setup({ patch }) {

   patch(Skill, 'addXP').replace(function(o, amount, masteryAction) {

     // Double any mining XP

     // Grant all other XP as normal

     return o(amount, masteryAction);

   });

It's important to note that the using the replace method replaces the '''current''' method implementation. This means that multiple replacements on the same patched method will be executed in reverse order than they were declared:

export function setup({ patch, onInterfaceReady }) {

   const xpPatch = patch(Skill, 'addXP');

   console.log('XP replace B');

   return o(amount, masteryAction);

== Exposing APIs ==

If your mod serves as a tool for other mods to integrate with, exposing APIs through the context object using <code>ctx.api</code> is the recommended approach. This is especially useful when paired with a mod developed using modules. The <code>api</code> method accepts an object and will expose any properties on that object to the global <code>mod</code> object within the <code>api['your-mods-namespace']</code> property. You can call the <code>api</code> method multiple times to append more APIs.

{

   "namespace": "helloWorld",

   "setup": "setup.mjs"

export function setup({ api }) {

   api({

     greet: name => console.log(`Hello, ${name!}`);

   });

Other mods would then be able to interact with your API:

== The Dev Context ==

To make it easier to test code before committing to uploading a mod, there is a 'dev' mod context that you can access to try out any of the context object's methods that don't require additional resources, i.e. you can't use <code>loadModule</code>. To access this context, you can use the following in your browser console:

''This method/context '''should not''' be used from within a mod.''

* [[Mod Creation/Sidebar API Reference]]

{{ModGuideNav}}