| Energy Name | Abbreviation | Original Mod | Version |
|---|---|---|---|
| Anima | AM | Anima-Mundi | 1.11.2 |
| Blutricity | BE (NO) | Redpower | 1.6.4 |
| Charge | RP (NO)/Fz? | Factorization | 1.7.10 |
| Crystal Flux | CF | Actually Additions | 1.12 |
| This has been copied from the original DropBox file which can be found here: https://www.dropbox.com/s/hejjfkpyohs9zmn/Why%20MCreator%20sucks.txt?dl=0 | |
| This file is written by the MinecraftForums user jcm2606. I welcome anyone to link to this file whenever they respond to an MCreator thread, as I will be doing. | |
| Okay, so if you're reading this, you've either decided to use MCreator, support it or are uneducated as to why MCreator sucks. Or are just curious as to what I wrote for it. Either way. So, why did I write an entire text file? Because I cannot be bothered writing the reasons why you should not use MCreator over and over. This also goes for other generators that make modding as simple as a "click a button" process. | |
| Just a rundown of what I'm going to be talking about (partly for me writing this): | |
| - Limitations on what you can do | |
| - Over-simplifies code | |
| - Allows for crappy, generic mods |
| { | |
| "parameters": { "name": <time_value>, ... }, | |
| "clips": { "name": <clip>, ... }, | |
| "states": [ "name", ... ], | |
| "transitions": { "name_from": "name_to", ... }, | |
| "start_state": "name" | |
| } | |
| <time_value> ::= | |
| <number> // result = number; Constant value. |
| import java.io.FileDescriptor; | |
| import java.io.FileOutputStream; | |
| import java.io.IOException; | |
| import java.io.OutputStream; | |
| import java.io.PrintStream; | |
| public class HelloWorld{ | |
| private static HelloWorld instance; | |
| public static void main(String[] args){ | |
| instantiateHelloWorldMainClassAndRun(); |
This gist intends on clearing up some of the misinformation surrounding signed chat/the reporting feature Mojang has added to Minecraft 1.19.1. Here you can find both technical information as well as a general explanation of how these work.
After joining a server, clients now send a profile key used for verifying a message's authenticity. This key and thus the whole signing process is optional, but by default, servers enforce secure profiles for clients to send chat messages. Whenever the player sends a chat message and has a key associated, the message will be signed using their own private key, which the server then verifies using the public key sent after join. Assuming signature, timestamp, and message contents line up, the message goes through.
On the other end, clients can also require all broadcasted player messages to be signed, disregarding the ones without sender verified signatures.
| _hashCode java/lang/Object.hashCode()I | |
| _getClass java/lang/Object.getClass()Ljava/lang/Class; | |
| _clone java/lang/Object.clone()Ljava/lang/Object; | |
| _dabs java/lang/Math.abs(D)D | |
| _dsin java/lang/Math.sin(D)D | |
| _dcos java/lang/Math.cos(D)D | |
| _dtan java/lang/Math.tan(D)D | |
| _datan2 java/lang/Math.atan2(DD)D | |
| _dsqrt java/lang/Math.sqrt(D)D | |
| _dlog java/lang/Math.log(D)D |
See https://github.com/comp500/fabric-serverside-mods for the latest mod list!
| /* This first part adds Seared Stone as a material. Toolparts and tool graphics are created automatically by color */ | |
| NBTTagCompound tag = new NBTTagCompound(); | |
| tag.setInteger("Id", 50); // Unique material ID. Reseved IDs: 0-40 Tinker, 41-45 Iguana Tinker Tweaks, 100-200 ExtraTiC | |
| tag.setString("Name", "Seared Stone"); // Unique material name | |
| tag.setInteger("HarvestLevel", 3); // diamond level | |
| tag.setInteger("Durability", 100); | |
| tag.setInteger("MiningSpeed", 100); | |
| tag.setInteger("Attack", 0); // optional | |
| tag.setFloat("HandleModifier", 0.1f); | |
| tag.setInteger("Reinforced", 0); // optional |
net.minecraftforge.fml.common.IWorldGenerator->net.minecraft.world.gen.feature.Feature- No longer needed. I think it should be removed by forge, as it has been superseded by vanilla functionality. See below.
net.minecraft.world.gen.feature.WorldGenerator->net.minecraft.world.gen.feature.Feature- This would also be the most common replacement of Forge's
IWorldGenerator. This should be the solution for anything smaller than a chunk. - Except the 8 blocks offset. This is not a thing anymore. Population now works just like any normal person would expect.
- Position of features is controlled by instances of
net.minecraft.world.gen.placement.BasePlacementinstead of by the feature itself.
- This would also be the most common replacement of Forge's
net.minecraft.world.gen.MapGenBase->net.minecraft.world.gen.carver.IWorldCarver- This is now finally exposed to mods in a useful way. As it was mostly hidden from modders before, not eveyone may know what it is, so it will be explained later. Generates caves a
In this document, I use strings in the format "foo:bar" to represent ResourceLocations with domain foo and path bar. I also use [square brackets] for placeholders.
On startup and whenever the resources are reloaded (in ModelLoader#setupModelRegistry), Minecraft iterates through every registered Block (in ModelLoader#loadBlocks) and asks its custom IStateMapper (or DefaultStateMapper if none has been registered) to create a mapping between every valid IBlockState of the Block and the ModelResourceLocation for that state (with the domain and path pointing to a blockstates file and the variant to a variant within that file). It then attempts to load these models.
DefaultStateMapper looks for the blockstates file with the Block's registry name (i.e. assets/[modid]/blockstates/[name].json) and serialises each property and value of the IBlockState to create the variant name that the model is loaded from (e.g. "enabled=true,type=foobar"