Dev

Developer Manual

After adding the mod, nothing will happen automatically.

The mod supports only one feedback backend by default: GitHub Issues. It requires prior configuration, but it’s not difficult.

GitHub Issues is universal (though a bit less convenient in China). Most people are familiar with it, so I won’t go into too much detail.

One note: when pushing to GitHub Issues the title is temporarily formatted in a fixed way — rating + player name + first 30 characters of the body — so it’s easy for people to find and check the repo for replies.

Private repositories, of course, are unaffected by this.

You may choose to use one backend or both. If you use both simultaneously you’ll need to use KJS events — don’t worry, it’s not hard.

GitHub Issues

First, create a Personal Access Token.

https://github.com/settings/personal-access-tokens/new

You can set Expiration to “No expiration”.

Fill Token name and Description however you like, and make sure to select the repository you want to use — seriously, select the repository you want.

Enable the Issues scope and then Generate token.

What you’ll need are the Access Token and the repository name.

Global Configuration

Open the game folder /config/GeneralFeedback and create an example.json file.

For GitHub Issues:

{
  "id": "default",
  "title": "Title of the feedback UI, e.g. XXX Modpack",
  "placeholder": "This is the placeholder!",
  "token": "the token you just generated",
  "url": "https://api.github.com/repos/Mafuyu404/GeneralFeedback/issues"
}

Change the url to reflect your actual GitHub username and repository.

When id is default, that configuration becomes the global configuration. By default, players can open the feedback screen via buttons in the Survival inventory, the pause menu, and the death menu.

title and placeholder both support translation keys using Component.translatable.

After filling the config, use /reload to reload.

This usually completes the setup; if you need further customization, read on.

Local Configuration

You can create multiple feedback tables to collect different types of feedback.

Maybe you don’t like the default buttons and want the feedback UI to pop up at a different moment.

Or you’re a mod author and want to collect feedback specifically for your mod — in that case we recommend packaging it as a JarJar.

If you’re not familiar with JarJar, add the following snippet to the dependencies section in build.gradle:

jarJar("curse.maven:generalfeedback-xxxxxx:xxxxxxx"){
    jarJar.ranged(it, '[0.0.0,100.0.0)')
}

Then create multiple JSON configurations and call them at the appropriate times.

GF$FeedbackUtils.openFeedbackScreenOf(id);

id is the id field from a JSON config — calling this method opens the corresponding feedback UI quickly.

Submit Event

// client_scripts
FeedbackEvents.onSubmit(event => {
    let form = event.getForm();
    form.feedback = Client.player.mainHandItem.id + form.feedback;
    event.setForm(form);
});

This event lets you modify the form just before it is sent. In the example above, the player’s main-hand item ID is prepended to the feedback text.

You can use KJS to attach any information you want, such as the modpack version or the player’s progress.

If you don’t want to use Vika and have another service or your own endpoint, you can write something like:

// client_scripts
FeedbackEvents.onSubmit(event => {
    let HttpUtils = Java.loadClass("com.sighs.generalfeedback.utils.HttpUtils");
    HttpUtils.fetch();
    event.setCanceled(true);
});

HttpUtils is somewhat sensitive and therefore not wrapped in KJS compatibility — you’ll need to load it yourself.

If you need this, I’ll assume you know how to call the API; follow ProbeJS’s completions to implement fetch.

Custom Posting

There isn’t much else to say:

GF$FeedbackUtils.post(entry, form); // automatically decides between Vika or GitHub Issues
GF$FeedbackUtils.addVikaRecord(entry, form);
GF$FeedbackUtils.createGitHubIssue(entry, form);

Call these methods whenever you want to post feedback.