Data Pack Creation: Difference between revisions
(Created page with "To submit a module to Gamemode 4, it must follow some specific standards. The following instructions will guide you through creating and submitting a module to Gamemode 4. Sub...") |
(Add double warning) |
||
(3 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{{Old}}{{Warning|This page should not be used to create a datapack. More up to date information is available on our GitHub|image=Stophand.png}} | |||
To submit a module to Gamemode 4, it must follow some specific standards. The following instructions will guide you through creating and submitting a module to Gamemode 4. Submitting a module can be done through GitHub. | To submit a module to Gamemode 4, it must follow some specific standards. The following instructions will guide you through creating and submitting a module to Gamemode 4. Submitting a module can be done through GitHub. | ||
Line 27: | Line 29: | ||
=== Naming and formatting standards === | === Naming and formatting standards === | ||
Please be sure to match the formatting for Gamemode 4 modules to ensure readability and consistency. | Please be sure to match the formatting for Gamemode 4 modules to ensure readability and consistency. | ||
* Names should be as clear and relevant as possible to avoid confusion or two modules sharing the same name by mistake. | |||
* Any name, scoreboard name or tag should be formatted as <code>lowercase_with_underscores</code> | * Any name, scoreboard name or tag should be formatted as <code>lowercase_with_underscores</code> | ||
* Scoreboards and tags should begin with the <code>gm4_</code> prefix. | * Scoreboards and tags should begin with the <code>gm4_</code> prefix. | ||
* fake players used to store numbers for scoreboard operations should be named as a "#" followed by that number e.g. <code>scoreboard players set #100 gm4_some_scoreboard 100</code> | * fake players used to store numbers for scoreboard operations should be named as a "#" followed by that number e.g. <code>scoreboard players set #100 gm4_some_scoreboard 100</code> | ||
* fake players that aren't constants should be prefixed by "$" and be in <code>snake_case</code>, e.g. <code>$has_soul_fire_heatsource</code> | |||
* Entities that aren't visible to the player (markers) should have custom names beginning with <code>gm4_</code> if this does not interfere with functionality. | * Entities that aren't visible to the player (markers) should have custom names beginning with <code>gm4_</code> if this does not interfere with functionality. | ||
* Lore on items should have the first word capitalized and no fullstop at the end of the sentence if there is only one sentence. Other punctuation (?!) can be added. Descriptions should be <code>"color":"gray","italic":false</code> whilst flavor text or commands (such as "Throw to use") should be <code>"color":"dark_gray","italic":true</code>. | |||
* Lore on items should have the first word capitalized and no fullstop at the end of the sentence if there is only one sentence. Other punctuation (?!) can be added. | * Names on items should follow Minecraft's rarity colorscheme and should be <code>"italic":false</code>. | ||
* | |||
* | ==== Comments ==== | ||
* Any function except those included with the template file should start with a header comment that consists of: | |||
# Plays a particle animation upon Zauber Cauldron creation | |||
# @s = player holding enchanted book | |||
# at @s align xyz | |||
# run from zauber_cauldrons:cauldron/create | |||
* Executor information may be written in mcfunction format (e.g. <code># @s = @e[type=mooshroom,limit=1,dx=0]</code>) or in human-readable format (e.g. <code># @s = Mooshroom within same blockspace, limit=1</code>). Complicated selectors should be written in a human-readable format. | |||
* Location information should include the full location -- including any <code>align</code> or <code>positioned</code> arguments -- or be written in human-readable format if the location is especially complicated. | |||
* Call information can reference | |||
** a single function, if the function is run by <code>/function ...</code>: <code># run from zauber_cauldrons:cauldron/create</code>. | |||
** a folder, if multiple functions call this function using <code>/function</code>: <code># run from functions in gm4_pig_tractors:till/blocks/</code>. | |||
** a function from where it was scheduled: <code># scheduled by zauber_cauldrons:cauldron/create</code>. | |||
** a combination of these, in which multiple lines would be used. | |||
* (Optional) A human-readable description of the function, e.g. <code># Plays a particle animation upon Zauber Cauldron creation</code>. | |||
=== Sending us your module code === | === Sending us your module code === |
Latest revision as of 20:39, 12 February 2023
This article needs to be updated.January 2024) ( |
This page should not be used to create a datapack. More up to date information is available on our GitHub |
To submit a module to Gamemode 4, it must follow some specific standards. The following instructions will guide you through creating and submitting a module to Gamemode 4. Submitting a module can be done through GitHub.
The following information is taken from the Gamemode 4 Dev GitHub page
Adding a GM4 Module that isn't in the repo yet
- Create a fork of
GM4_Datapacks
using the Fork button in the top-right of the repo. You will then have a personal copy of the repo ready for your changes. - Make a copy of the
GM4_template_pack
folder and rename it to the name of the module you are writing code for. - Each module you create should be made under a separate branch so that modules can be submitted, approved and tested individually.
Inside the gm4_template_pack
folder is code that matches the Gamemode 4 module standard including a copy of the current clocking system. Rename the _pack.mcmeta
file to pack.mcmeta
. The contents of the file can remain unchanged.
There are several placeholder values in both file names and the files themselves.
MODULE_ID
within this folder should be replaced with the module name in an underscored format such asbat_grenades
orenderman_support_class
. This should contain only lowercase characters and underscores and should match the module name on the website if the module already exists.MODULE_NAME
should be replaced with a display name for the module as this is visible to players such asBat Grenades
orEnderman Support Class
. This should match the name on the website if the module already exists.
Folders
Within the data
folder there are three folders for the different namespaces this module will use. If the module is an extension, you will need an additional module for the base module. Because we merge modules with a copy of the base clock certain folders and files should not be included once the module is submitted but are included in the template so you can test your module.
/minecraft/
This folder simply contains code that lets Minecraft run the Gamemode 4 clocking system. Nothing in this folder needs to be changed.
/gm4/
This folder contains a copy of the Gamemode 4 clocking system and small changes need to be made (see placeholder values above). Be sure not to miss any of these placeholders! Do not change anything else in these files. If the module does not contain advancements then the file under gm4/advancements
should be deleted. Otherwise the advancement details should be updated. The root.json
file should not be deleted or changed.
/template/
This folder should be renamed to MODULE_ID
. All your module code should be within this folder or within sub-folders. Place your main commands in the main.mcfunction
file and any commands that should run every tick (avoid this if possible) into pulse_check.mcfunction
.
Naming and formatting standards
Please be sure to match the formatting for Gamemode 4 modules to ensure readability and consistency.
- Names should be as clear and relevant as possible to avoid confusion or two modules sharing the same name by mistake.
- Any name, scoreboard name or tag should be formatted as
lowercase_with_underscores
- Scoreboards and tags should begin with the
gm4_
prefix. - fake players used to store numbers for scoreboard operations should be named as a "#" followed by that number e.g.
scoreboard players set #100 gm4_some_scoreboard 100
- fake players that aren't constants should be prefixed by "$" and be in
snake_case
, e.g.$has_soul_fire_heatsource
- Entities that aren't visible to the player (markers) should have custom names beginning with
gm4_
if this does not interfere with functionality. - Lore on items should have the first word capitalized and no fullstop at the end of the sentence if there is only one sentence. Other punctuation (?!) can be added. Descriptions should be
"color":"gray","italic":false
whilst flavor text or commands (such as "Throw to use") should be"color":"dark_gray","italic":true
. - Names on items should follow Minecraft's rarity colorscheme and should be
"italic":false
.
Comments
- Any function except those included with the template file should start with a header comment that consists of:
# Plays a particle animation upon Zauber Cauldron creation # @s = player holding enchanted book # at @s align xyz # run from zauber_cauldrons:cauldron/create
- Executor information may be written in mcfunction format (e.g.
# @s = @e[type=mooshroom,limit=1,dx=0]
) or in human-readable format (e.g.# @s = Mooshroom within same blockspace, limit=1
). Complicated selectors should be written in a human-readable format. - Location information should include the full location -- including any
align
orpositioned
arguments -- or be written in human-readable format if the location is especially complicated. - Call information can reference
- a single function, if the function is run by
/function ...
:# run from zauber_cauldrons:cauldron/create
. - a folder, if multiple functions call this function using
/function
:# run from functions in gm4_pig_tractors:till/blocks/
. - a function from where it was scheduled:
# scheduled by zauber_cauldrons:cauldron/create
. - a combination of these, in which multiple lines would be used.
- a single function, if the function is run by
- (Optional) A human-readable description of the function, e.g.
# Plays a particle animation upon Zauber Cauldron creation
.
Sending us your module code
To send us your finished module for testing and approval, simply submit a pull request and leave a comment if you have additional notes. Make sure to delete files related to the base clocking system. Specifically make sure:
- Delete the load.json and tick.json files from minecraft/tags/functions/
- Delete functions from the gm4 namespace. Advancements and load/tick tags should be left in there though.
- Make sure that
#$moduleUpdateList
is on the last line containing text of your module'sinit.mcfunction
Updating a module on the repo
If you've spotted a bug in a module or have a performance improvement you wish to make, create a branch of the repo similar to the process outlined in the section above and make your changes. Once you have edited the module files, create a pull request and leave a detailed note on why you have made your changes.