Cratthorax

Thank you, found it, but according to the description it's somewhat risky to use? That's partially because of the sentence "no automatic backup", and my layman Java skills, which restrict me from even understanding how, and specially WHERE to install it? Is this supposed to go in the build.gradle? And if so, where exactly? "...add them to the remapping tasks" I don't understand what he means by remapping tasks? In the minecraft, or in the dependencies section? I assume in the dependencies section where it says... "minecraft 'net.minecraftforge:forge:1.16.4-35.1.4'" ...? Thanks for your repeated time and patience btw.

Yes, Sir. Things not working makes one blind of hair tearing rage. Hence why I overlooked the fact, I hadn't imported the EventSubscriber to the main file. Can one not just import the old version to the new project without fing up? Doing it file by file is quite tedious.

Found the solution. It appears the registration method has changed. I was registering the Data Gen Main File, in my Mods Main File before. Now you add the EventBusSubscriber directly to your Data Generator main file like this: @Mod.EventBusSubscriber(modid = MatLibMain.MODID, bus = Mod.EventBusSubscriber.Bus.MOD) public final class DataGenMain { private DataGenMain() {} @SubscribeEvent public static void gatherData(GatherDataEvent event) { DataGenerator gen = event.getGenerator(); ExistingFileHelper existingFileHelper = event.getExistingFileHelper(); DataGenBTP blockTags = new DataGenBTP(gen, existingFileHelper); gen.addProvider(blockTags); gen.addProvider(new DataGenITP(gen, blockTags, existingFileHelper)); gen.addProvider(new DataGenFTP(gen, existingFileHelper)); gen.addProvider(new DataGenLT(gen)); } } Edit: correction. In 1.16.4 there wasn't even a EventSubscriber needed. It did that automatically for you.

Good day, updating went pretty straight forward, due to the fact that most code lines in .classes were to be found almost exactly in the same spot as in 1.16.4. However, I do have one issue left, and I'm right now tearing my hair out in order to figure how to solve it. Trying to run my Data Generator Configuration in Eclipse, does execute like it is supposed to, but only it will always return 0 data files provided when the config run is done. I scanned the log for errors, and differences to the way I did it in 1.16.4, but I made absolutely sure(for the last fing 4 hours) everything is just fine an dandy with my run config. I do notice two differences though, and I'm afraid it comes down to those two things why it simply doesn't forward the data generation. Unfortunately I don't know how to change specially number 1. 1. in my run data configuration, under "Environment", in 1.16.4 there are no entry's for "assetDirectory" and "assetIndex", while in 1.16.5 they do exist, as well as for the "normal" run configuration(the game, not the data generation config). They do ALSO not exist for my second mod's Data Generation run config. See this screenshot: Notice when trying to remove the asset entry's from the newer run config, it will simply crash. 2. in my 1.16.5 build.gradle, under "buildscript", just in the beginning, the entry "jcenter()" is missing. I hope someone can help me here. Thanks.

Currently moving on to 1.16.5, mass immigrating my blocks first. I just wanted to verify changes: 1. create changed to of (properties) 2. hardnessAndResistance changed to strength (properties) 3. doesNotBlockMovement and notSolid unified into noCollission (properties) 4. tickRandomly now randomTicks (properties) 5. isValidPosition now canSurvive (method or function?) 6. hasEnoughSolidSide now canSupportCenter (return type function?) 7. isReplaceable now canBeReplaced (function) 8. isRemote now isClientSide (function) 9. getPosX to getX (function) A special note on 8. isClientSide will be called exactly like before, so I need to return it the same way? Aka isRemote = isClientSide, or !isRemote = !isClientSide, or has the logic been switched here? Edit: on a side not, why are all the function names changed, if they do imply the same context?(at least for me). I mean, I understand that getX, is less code than getPosX, but what's the difference in saying, for example, tickRandomly vs randomTicks? canSupportCenter is even more confusing than hasEnoughSolidSide.

Please elaborate. I feel like there is a function that will prevent unwanted keypress repeats? I found traces, but none of them were working. It's hard to tell if there are no annotations.

With a tick of 20 this finally did the trick. I might add a config option, because different users have different computers, and the tick rate might not be the same for all of them. if(guiScreen != null) { guiTick = 20; return; } else { if(guiTick > 0) { --guiTick; } } if(guiTick != 0) return;

I did. It's even worth since it would execute the keypress numerous times. Also, in an older thread you recommended against using it, and instead use either the tick, or the GUI key event. I guess it's a special case, since I basically just try to replace the ESC key function with a custom keybind. The problem here is, stupid Mojang has given all possible keys options to rebind, and address them in java with, for example, minecraft.gameSettings.keyBindUseItem.getKey(). But the ESC menu key is addressed in java code with its keybind number(256). This also creates the issue of the Recipe Book crashing the game, when I try to execute ESC key on my custom key, since the Minecraft.class, respectively the KeyBindListener.class, would only monitor for this explicit keycode, and not its game setting equivalent. Maybe you Forge guys can give that ESC key proper game setting options?

I spare you the whole class since it is huge...but I'll give you those two events. The tick is a private static int.

Because the ClientTick listens for my custom menu enter/exit keypress only outside GUIs, and the other event does inside GUIs. The problem is, the tick is quicker than the GUI key event, and will respond to my if instanceof Screen == null, BEFORE it is properly exited in the GUI key event. I'm fiddling around with a counter. Makes it easy inside the tick event. I'd start it once I press my custom key in the GUI key event, and then inside the tick I will ask him to not execute my menu open condition, if the counter is over a certain threshold. But damn, is my computer quick...:D...needs some fine tuning.: ... if(guiScreen != null) { ++guiTick; return; } else { if(guiTick >= 10) { --guiTick; } else { guiTick = 0; } } if(guiTick != 0) return; ... inside the GUI key event it's set to 10

How is respawn Client based? It's called ClientWorld, because I created it 4 weeks ago, when I still confused up isRemote. I posted the method.

Is there any way to delay the tick of ClientTickEvent? Because it ultimately f's with my KeyboardKeyPressedEvent, and I have found no way how to make them not to react to each other.

Yes, it does. That's because you'd need the iWorld which implements the BiomeReader, so I can define the spawn point anywhere, not just near my campfire. It's just a convenience option. It also makes sure that always a ServerWorld is returned, because iWorld can only be Server, right?

You are...🙃 No seriously. Anything is cryptic if you don't comprehend.

I stand corrected. It works in all GUI instances, except those that are utilizing the recipeBookGui. I've spend whole yesterday to create a way to close any of those GUI's with my keypress without crashing. But it can't be done. I ended up doing this: if(guiScreen instanceof InventoryScreen || guiScreen instanceof CraftingScreen || guiScreen instanceof AbstractFurnaceScreen) { KeyBinding.onTick(Minecraft.getInstance().gameSettings.keyBindInventory.getKey()); return; } So it would execute the init() process which resulted in resetting the affected GUI, and allow for closing it with the regular inventory keyBind. Hacky but working.