Introduction

Supersymmetry is a Minecraft modpack for 1.12 (SUSY modern coming next Sunday™) based around GregTech. But if you're here reading this, you probably already know that.

Project Structure

This section contains a high-level overview of the different components of the Supersymmetry modpack.

Github Repositories

Supersymmetry

This is the main repository for the modpack! It contains configuration files for the modpack. This is where you'd contribute to the questbook, update recipes, add mods, etc.

SuSy-Core

This repository contains the principal Java code for the modpack. It also contains all of the assets of the modpack. We use RetroFuturaGradle for the compilation.

Supercritical

This repository has our custom nuclear energy implementation. It contains nuclear-relevant recipes, items, multiblocks, and textures.

Contributing

Git for Dummies

Git is a very commonly used version control software whose version structure is represented in terms of sequences of changes, where each change is called a "commit", and sequences of commits can be worked on in parallel.

A sequence of commits is called a "branch". Generally, the branch called "main" is the base branch that all other branches are based on, to some degree. The separate branches permit developers to create their own changes without having to handle changes made by other developers all the time. However, a branch can serve the role of specifying release type, though that's not the case in Supersymmetry.

Because these updates have to be shared online, a space such as GitHub is used to store the data, and this means that the Git repository that you have locally is not the same as the main branch.

The commits made locally also need to be made manually. In fact, local changes can either be ready for committing (staged/in the index) or not ready for committing (in the working directory).

To move all changes to the index, git add . is essential (if you're not using an IDE). Then, git commit -m <description> can be used, converting the staged changes into a commit.

While working on a branch, you may want to integrate new features added to the main branch. Doing this requires using the command git pull, which will merge the two branches, which just leads to a new commit on your branch. Usually, Git can handle merging automatically, but when the new features from the main branch do not line up cleanly with the changes you've made, a merge conflict results. Refer to this link on StackOverflow for a better idea of how this can be done.

When you're ready to integrate their changes into the main branch, you can create a pull request that allows everyone to verify its correctness before merging any new features from the main branch into it, however is necessary.

Guides

Writing Quests

Quests are provided through Better Questing Unofficial.

To create a quest, one uses /bq_admin edit to toggle editing mode, and then one can freely edit the quests from there. Anyone working with this MUST, MUST run /bq_admin default save to record the quest data to the files. Don't do yourself dirty. There are a few things to know when editing quests:

The language files for our quests are stored in config/betterquesting/resources/supersymmetry/lang.

BQ(U)Tweaker allows images and links to be embedded into quests.

To add links, use this format: {Embed}TypeLink;<WebsiteLink>;<DisplayWidth>;<DisplayHeight>;<ButtonText>{Embed} As for images, use this: TypeImage;<ResourceLocation>;<DisplayWidth>;<DisplayHeight>;<ImageWidth>;<ImageHeight>{Embed}

Also, to edit quest lines and quests, look in the lower left-hand part of the chapter-viewing interface:

Writing Recipes

Recipes are written in GroovyScript. Here's an example:

MIXER.recipeBuilder()
        .fluidInputs(fluid('fermented_biomass') * 1000)
        .inputs(ore('nutrientPhosphorous'))
        .outputs(metaitem('fertilizer') * 5)
        .EUt(30)
        .duration(100)
        .buildAndRegister()

MIXER is a RecipeMap that is generated as such:

MIXER = recipemap('mixer')

To create a recipe, one has to call the recipeBuilder method first, which allows developers to add the properties of the recipe. The recipe is registered with the buildAndRegister recipe.

Conveniently, the voltage requirement of the recipe is determined by the EUt method.

Materials

Items that exist as a variant of a material are specified by the ore function with a string argument consisting of an ore prefix and a material, such as nutrientPhosphorous, foilPlastic, dustSilver, etc.

Material definitions and initializations can be found in groovy/material, and importantly, most of them contain sub-materials. SuSyMaterials.groovy defines all materials defined by the modpack and calls their initialization functions. Within FirstDegreeMaterials.groovy, the high-purity elements and materials that depend only on elements are initialized. SecondDegreeMaterials.groovy contains materials that depend on materials within FirstDegreeMaterials.groovy, and so on to avoid nasty errors. Materials of unknown or complex composition are initialized in UnknownCompositionMaterials.groovy. Sometimes, one needs to initialize materials in Susy-Core.

Metaitems

Metaitems can be thought of as individual item variants with unlocalized names and numerical IDs, meaning that one does have to be careful when merging. They are set up in SusyMetaItems.java, along with their tooltips and stack size.

Creating Multiblocks

A multiblock is implemented as a MetaTileEntity (GregTech's buffed tile entities). Therefore, all multiblocks have a controller block. However, we do not suggest that you use a MetaTileEntity superclass for most multiblocks. Usually, a RecipeMapMultiblockController or a MultiblockWithDisplayBase is what you want as the superclass.

When using a RecipeMapMultiblockController, you must create a field of SusyRecipeMaps and initialize it with a name to begin registering recipes in GroovyScript. The initialization is used to set up the GUI and the associated sounds. This is convenient, because appropriate recipe logic can be set up immediately based on the type argument.

For a MultiblockWithDisplayBase, the recipe system and GUI are customizable to a greater extent, but you will have to create them yourself.

Here is an example implementation of createStructurePattern for a launch pad.

Multiblock Parts