Code contributions

As of May 2025, Create: Astral's code structure has been entirely moved around and reorganised (refer to #526), so it may look a bit different if you've contributed code or resources before.

Here's the run-down:

• All asset and resource files can be found in /kubejs/assets/.
• All data-driven recipe files are now handled by KubeJS and can be found in /kubejs/server_scripts/recipes.

  There is an exception to the above, being certain override recipes that are needed to be defined by datapack to prevent crashes caused by REI, which can be found in /kubejs/data/farmersdelight/recipes/cutting/. These recipes would benefit from being removed from datapack while still preventing the crash, so that's a little task if anybody is up for it.

• All other data-driven (datapack) JSON files (except for recipe files, as stated in the last bullet point) can be found in /kubejs/data/. This includes item and block tags, which are no longer handled by JavaScript.
• All KubeJS startup scripts are now organised to be more intuitively arranged in /kubejs/startup_scripts/ - not much has changed here otherwise.

For everything else, the place they're stored hasn't changed and should be rather intuitive for both first-time and long-time contributors.

You can refer to the KubeJS README for more information on what each folder in /kubejs/ does.

If you're new to datapacks, resources, and KubeJS, then take a look at their respective wikis for more information on how to utilise them. Astral has been organised in such a way to aid in readability and accessibility, so you may be able to pick up some skills from just reading through code.

• KubeJS Wiki for 1.18.2
• Minecraft Wiki article on Data Packs
• Minecraft Wiki article on Resource Packs

Code style

This repository has a general code style that is encouraged for the sake of consistency and human-readability. You can find more information on the Code style page.

Housekeeping

In order to keep Astral tidy and to avoid it looking like it did before the May 2025 cleanup, please try to keep to the standards. You can refer to the following subcategories, depending on your situation:

Recipe contributions

For recipe contributions, please organise them in /kubejs/server_scripts/recipes/ by their crafting type rather than collecting all your contributions in one place. This makes it much easier to find all the added recipes.

• For example, if I have a recipe for the Industrial Sawmill from Tech Reborn, I will add it to the already-existing file - /kubejs/server_scripts/recipes/techreborn/industrial_sawmill.js.
• If I have a recipe for a crafting type that does not yet exist, I will make a new file using the following directory template:

  /kubejs/server_scripts/recipes/{mod namespace}/{crafting type}.js

Please also don't make recipes in the /kubejs/data/ folder as it makes it more difficult to find if recipes are spread across both KubeJS and datapacks.

If you wish to replace an existing data-driven recipe, remove the recipe in /kubejs/server_scripts/recipes/removals.js using its ID. For example, If I want to replace the default recipe of tconstruct:smeltery/melting/glass/block, I will add a line in the array of the main helper function of the removals.js file that reads like this:

{id: "tconstruct:smeltery/melting/glass/block"},

Always check if a recipe has been removed before removing it again. You can search in most IDEs using ctrl + F or cmd + F. For more information on using the event.remove() recipe callback, here is the KubeJS wiki article on recipe events.

To find the ID of a recipe, copy its mod file from your launcher's modpack instance to another folder (such as your Documents), rename the .jar extension to .zip, and unarchive it. Within it will be a /data/{mod name}/recipes folder containing all the recipes. The ID of the recipe will be the namespace of the mod, followed by the part of the file directory that comes after /data/{mod name}/recipes/. For example, the recipe with ID tconstruct:smeltery/melting/glass/block will have its file located at /data/tconstruct/recipes/smeltery/melting/glass/block.json

Feel completely free to use helper functions to add recipes en-masse, as long as you make sure it's sensibly organised. For reference, most existing recipe scripts already have arrays that define recipes in this way to make an easy-to-read format.

Adding or modifying tags

Registering or modifying tags (such as #minecraft:logs or #create:wrench_pickup) is to be done via datapack and not KubeJS, even if you need to use helper functions. We understand this may be inconvenient, but it allows us to have a much more easily navigable tags library for reference purposes.

All other code contributions

Generally just try your best to be tidy and organised, the folders in place exist to aid with this purpose. If you can't find a place for your contributions, please make a place for it that feels appropriate :)

Internationalisation and localisation support

If you are contributing something that involves /kubejs/startup_scripts/, or you're making something that displays something in-game as readable text, then this section is applicable to you.

Internationalisation (also known as i18n for short) is a system that uses language keys to allow for translation of the game to any language without requiring an entirely new modpack for each supported language. The term for providing support for a specific language using the already-established i18n foundation is called localisation.

As you can imagine this is very important for accessibility for players around the world, so this repository requires that as much as possible is done to support the i18n effort.

Enabling internationalisation in your contributions

Here's an example of changing the added tooltip and some other text to a language key. For adding a new item/block/fluid, the naming of the key in the language file needs to follow these rules.

To name keys in the lang file correctly, you need to use the prefix (item/block/fluid) + the namespace of mod (such as kubejs,create_astral) + the ID of item/block/fluid. For values, it's the displayed name instead of translation keys. Here is an example:

{
  "item.createastral.crushed_raw_desh": "Crushed Raw Desh",
  "block.kubejs.fragile_sheet_block": "Fragile Sheet Block",
  "fluid.kubejs.molten_calorite": "Calorite"
}

For other texts in JavaScript, you should use text components. Here is an example.

Here are the files where language keys are assigned a translated text value:

• Main lang file for most assets
• Lang file for custom create ponder guides
• Lang file for custom menu texts

You MUST assign a text value for lang keys in the en_us local file before any other language. The en_us file is used as a fallback if a translation doesn't exist for a given language.