mehvahdjukaar's refactors by quat1024 · Pull Request #65 · VazkiiMods/Zeta

quat1024 · 2025-03-29T14:35:17Z

Just opening so i can look on github

quat1024

Neat

quat1024 · 2025-03-29T14:40:07Z

src/main/java/org/violetmoon/zetaimplforge/registry/ForgeZetaRegistry.java

-				ResourceLocation name = internalNames.get(entry);
-                z.log.debug("Registering to {} - {}", registryRes, name);
-				event.register(keyGeneric, e-> e.register(name, entry));
+    //TODO: nuke


This exists so things like the slab block can set their ID to a variant of the full block's ID

quat1024 · 2025-03-29T14:43:43Z

src/main/java/org/violetmoon/zeta/block/IZetaBlock.java

+            return 0;
+
+        //TODO 1.20: weird
+		//TODO: wtf is this??


Jank to set block flammability based on the "material" after 1.20 deleted all the materials. Plugs into IForgeBlock#getFlammability

ah so its an automatic flammability guesser

quat1024 · 2025-03-29T14:50:09Z

src/main/java/org/violetmoon/zeta/block/ZetaDoorBlock.java

+		Zeta zeta = module.zeta();
+		zeta.renderLayerRegistry.put(this, RenderLayerRegistry.Layer.CUTOUT);
+		zeta.registry.registerBlock(this, regname, true);
+		zeta.creativeTabs.addToCreativeTab(CreativeModeTabs.BUILDING_BLOCKS, this);
+		zeta.creativeTabs.addToCreativeTab(CreativeModeTabs.REDSTONE_BLOCKS, this);


This standardization is a much-needed change 👍

I wonder if they should be located from getters on ZRegister instead of grabbing them from Zeta... that way you could just pass ZRegister into the block constructor itself, and then I don't think these registries would have to be public on Zeta. Would require a million changes in quark though so this is a good compromise

yeah I thought about this. Making those changes would mean going into a direction where it would make sense to keep all registration stuff private and only acessible via ZRegister event (just like it usually is on forge). That could avoid some mistakes and be cleaner API but at the cost of needing bigger refactors.
In other words if that was to happen the access to the Zeta object would be relegated to read-only information and the actual registraction part would always have to be done via the ZRegister event

quat1024 · 2025-03-29T14:51:03Z

src/main/java/org/violetmoon/zeta/multiloader/Env.java


 import java.util.function.Supplier;

+//TODO: merge into ZetaSide


Wait lol what's this class doing here in the first place

Looks like it's just used to create Quark's sided proxy lol?? Will nuke the one (1) usage quark-side and then you can nuke this

VazkiiMods/Quark@43450a7 alright yeet it

Nice! Sure feels nice removing stuff

quat1024 · 2025-03-29T14:56:49Z

src/main/java/org/violetmoon/zeta/block/IZetaBlock.java

-    	return b;
+    default Block getBlock() {
+        return (Block) this;
    }


(meant to comment on the removal of setCreativeTab but github fucked up)

Deleting this will require a lot of changes in Quark, the method was put in this interface as a "builder" (ex https://github.com/VazkiiMods/Quark/blob/772bdfac2cd290d3c1d3c66a79e3790e99de1271/src/main/java/org/violetmoon/quark/addons/oddities/module/BackpackModule.java#L109 )

Ah i see. Reason I didnt like it and didnt like the condition one is because of access. In theory any mod could get a zeta block and assing a new tab and such.
Obviously not much of an issue if only quark uses zeta but some of these changes were made to provide a cleaner API, in a way that would make the mod a solid choices for other possible mods that might want to develop a module driven mod.

One possible solution i could think of would be to make zBlocks accept a tab and condition object or maybe a general ZProperties object that takes care of the configuration

A more advanced block properties would be really great

so could be a new prop object or a vanilla prop wrapper. imo a dedicated one would be clearer and less invasive

tho tbh not quite sure as adding a prop object to blocks constructor wouldnt be something that the interface could enforce...

still given all of those are created in the zeta event it wuld be just one extra line before it that manualy specifics the tab... i dont think that would make it any less convenient really

to add to this, this would actually be a good argument for giving ZRegister to the QuarkBlock class. now IT could indedd do the automatic stuff like adding to the tab and what not when also given a tab in its constructor

quat1024 · 2025-03-29T15:00:16Z

src/main/java/org/violetmoon/zeta/client/config/screen/ZetaConfigHomeScreen.java

Is this diff just imports/whitespace/formatting stuff

quat1024 · 2025-03-29T15:03:51Z

src/main/java/org/violetmoon/zeta/config/ConfigManager.java

+    //whats this for?
+    public void addOnReloadListener(String id, Consumer<IZetaConfigInternals> consumer) {


I think it was for the "hide removed items from JEI" option? Safe to delete, no usages in Quark atm

MehVahdJukaar added 3 commits March 16, 2025 22:52

probably just whitespaces

5b159e4

mega refactors

131f15b

reg event stuff

495897d

quat1024 commented Mar 29, 2025

View reviewed changes


		import java.util.function.Supplier;

		//TODO: merge into ZetaSide

		//whats this for?
		public void addOnReloadListener(String id, Consumer<IZetaConfigInternals> consumer) {

Conversation

quat1024 commented Mar 29, 2025

Uh oh!

quat1024 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

quat1024 Mar 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

quat1024 Mar 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

quat1024 Mar 29, 2025 •

edited

Loading

quat1024 Mar 29, 2025 •

edited

Loading