Started planning for paints (see desc)

I was going to start working on paints but ended up just doing some planning for the new loading system instead. Building from the ground up with customs in mind this time means they can perform better and have more options.

See the huge comment on RegistrationPaint for details!

build.gradle

@@ -124,8 +124,10 @@ dependencies {
     // If the group id is "net.minecraft" and the artifact id is one of ["client", "server", "joined"],
     // then special handling is done to allow a setup of a vanilla dependency without the use of an external repository.
     minecraft "net.minecraftforge:forge:${minecraft_version}-${forge_version}"
-    compileOnly fg.deobf("com.fureniku.metropolis:Metropolis-Forge-1.20.1:0.1.0")
-    runtimeOnly fg.deobf("com.fureniku.metropolis:Metropolis-Forge-1.20.1:0.1.0")
+    //compileOnly fg.deobf("com.fureniku.metropolis:Metropolis-Forge-1.20.1:0.1.0")
+    //runtimeOnly fg.deobf("com.fureniku.metropolis:Metropolis-Forge-1.20.1:0.1.0")
+    compileOnly fg.deobf("com.fureniku.metropolis:Metropolis:0.1.0")
+    runtimeOnly fg.deobf("com.fureniku.metropolis:Metropolis:0.1.0")
     // Example mod dependency with JEI - using fg.deobf() ensures the dependency is remapped to your development mappings
     // The JEI API is declared for compile time use, while the full JEI artifact is used at runtime
     // compileOnly fg.deobf("mezz.jei:jei-${mc_version}-common-api:${jei_version}")

src/main/java/com/fureniku/roads/blocks/paint/PaintBlockCommonBase.java

@@ -0,0 +1,12 @@
+package com.fureniku.roads.blocks.paint;
+
+import com.fureniku.metropolis.blocks.decorative.MetroBlockDecorativeBase;
+import com.fureniku.metropolis.datagen.TextureSet;
+import net.minecraft.world.phys.shapes.VoxelShape;
+
+public abstract class PaintBlockCommonBase extends MetroBlockDecorativeBase {
+
+    public PaintBlockCommonBase(Properties props, VoxelShape shape, String modelDir, String modelName, String tag, boolean dynamicShape, TextureSet... textures) {
+        super(props, shape, modelDir, modelName, tag, dynamicShape, textures);
+    }
+}

src/main/java/com/fureniku/roads/blocks/paint/PaintBlockConnectingBase.java

@@ -0,0 +1,4 @@
+package com.fureniku.roads.blocks.paint;
+
+public class PaintBlockConnectingBase {
+}

src/main/java/com/fureniku/roads/blocks/paint/PaintBlockRotatableBase.java

@@ -0,0 +1,5 @@
+package com.fureniku.roads.blocks.paint;
+
+// For any standard, rotatable paintblock.
+public class PaintBlockRotatableBase {
+}

src/main/java/com/fureniku/roads/registrations/RegistrationPaint.java

@@ -0,0 +1,80 @@
+package com.fureniku.roads.registrations;
+
+import com.fureniku.metropolis.RegistrationBase;
+import com.fureniku.metropolis.RegistrationGroup;
+import com.fureniku.metropolis.utils.CreativeTabSet;
+import net.minecraft.world.level.block.SoundType;
+import net.minecraft.world.level.block.state.BlockBehaviour;
+import net.minecraftforge.eventbus.api.IEventBus;
+
+import java.util.ArrayList;
+
+public class RegistrationPaint extends RegistrationGroup {
+
+    /* Notes for custom paint 2.0 because the top of a random class is a sensible place to put it and i'll totally remember later.
+
+    Version 1.0 worked but had flaws:
+        - Every pixel of the paint model was individually drawn, meaning potentially 256 calls in the bakery event for a 16x16 paint. Most paints were 32x32, which is 1024.
+        Sides were also drawn on the edges of paints.
+        THATS BAD.
+        - The system didn't support connecting styles, only static icons
+        THATS BORING.
+        - The system only worked with single colours
+        THATS... expected but also boring.
+
+    CUE VERSION 2.0!
+        - Paint files are now going to be made of structure entries. For example a straight line might have just one entry
+        Entries are Vec4's, indicating a start and end position. The straight line entry might be 7,0,9,16 (from X7 Y0 to X9 Y16)
+        Each entry is drawn as a single call now. Each entry is effectively one scaled model. It's basically how the vanilla system would work.
+        ... could I just use the vanilla system? That might actually be much better... My editor would generate vanilla models.
+
+        - We can add support for connecting systems. Connecting paints had two types:
+            - Connect in a direction indiscriminately (center lines)
+            - Connect in a direction but varied depending on the orientation of the target to connect to (side lines)
+        - First is very easy. Editor has a mirrored image, you edit one and the other auto-updates to show how two side-by-side textures might connect. Enable/disable the NESW as preference.
+        - Editor exports the north connection and we rotate as normal.
+        - Second is a bit more complicated. I can do it in code but I'm not sure how to explain in editor to make it idiot proof enough. Might just mark as advanced.
+
+        - Paints only having one colour is boring, but not a limitation.
+        Now that we can redesign from the ground up with support for alternate paint styles in mind, we can also design paints which contain multiple styles.
+        The new element system on the paint gun allows for this. Elements can be flagged using a colour enum. This defaults to "all", but setting anything else will mark that paint as a specific colour.
+        Mutlicolour paints will have their own section of the paint gun, and no longer auto-adapt to every colour. If people want mutliple colours
+        (e.g. this paint can be white/red/yellow but has a blue accent part), they need to create mutliple specific paints.
+        Mutlicolour paints will only load if all listed colours are installed. If it requires a plugin, it won't load and an error in the console (and maybe on login in-game)
+        Cost-wise, the paint will require all listed colours to be available in the paint gun. The costing ratio will be split evenly regardless of the actual distribution.
+
+
+    While we're here... custom paint colours
+        - Paint gun will now support all paint colours. Every colour can implement one specific dye colour, as well as an RGB value.
+        - Paint gun tanks can hold more variants now. The UI buttons change to a dropdown, and you can select any dye that you have available
+        - Every paint colour will have a cost associated for both options. For example, yellow might say 2mb of yellow dye, or 1mb each of green and blue.
+
+
+
+
+
+     */
+
+    private final String PAINT_SINGLE_CENTER_LINE_CONNECTING = "_single_center_line_connecting";
+
+    private BlockBehaviour.Properties _props = BlockBehaviour.Properties.of().strength(1.0f).sound(SoundType.STONE);
+
+    public RegistrationPaint(RegistrationBase registrationBase) {
+        super(registrationBase);
+    }
+
+    @Override
+    public void init(IEventBus iEventBus) {
+
+    }
+
+    @Override
+    public void generateCreativeTabs() {
+
+    }
+
+    @Override
+    public ArrayList<CreativeTabSet> getCreativeTabs() {
+        return null;
+    }
+}