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.

Well, it imports the BiomeReader, which is needed to check for spawnpoints. Oh, you mean why I do something that already exists? Because I would often get confused on what .isRemote() is actually doing, because there isn't a simple explanation like f.e.: !isRemote = "you're not on a server" isRemote = "you are on a Server" As far as I understand it, and I prolly understand it wrong, isRemote is just used to "divide" addressing Server/Client, but it doesn't clearly tell you if you ARE actually on a server, which already you've stated in another thread, you always are(on a server, even in singleplayer). Hence why I found this utility function on Stackoverflow by someone who was just as confused as I am about the topic. I guess I already have seen how that has changed for 1.17 and onwards, because the method has changed to .isClient(). Might be wrong though, and is just a custom utility method as well. Github states otherwise. Just as well as "world" changed to "level"? Which is not really better, because a world is a world, not a level???

I exported all my custom Event helper functions into a .class named EventUtility. Things got quite messy inside my EventHandlers.

I do feel a bit stupid now. Sometimes you don't see the forest of many trees. I basically just told it to return where the sun doesn't shine, if it's an instance of ServerWorld. I also found a less complicated function inside ServerWorld, which asks for position and angle only. However, reminding me of instanceof, I utilized the right search logic in ServerWorld, without that hint I'd never uncovered my finds. So thanks a bunch D7. Final code for now:

Feel my pain: Or in other words, the spawn set function applied when trying to sleep asks for a ServerPlayer Entity, but the PlayerInteractEvent.RightClickBlock Event doesn't have it. Any Ideas? I just want to make my campfire a respawn point. If all fails I might just use a OnPlayerRespawn Event, if it exists, and teleport the player to a custom set position near the campfire.

I keep that in mind and //commented if I ever need it on any of my custom keybinds. But a simple exit function doesn't really need that. I would still love it more to just mimic the ESC key pressed when hitting my custom button, because I could evade all sorts of bugs I don't even know coming yet. Messing with all of the GUI instances can be a messy f. That's specially true for any Screen that has has the Recipe Book GUI imported.

Works like a charm in every thinkable GUI instance... @SubscribeEvent public static void guiScreenKeyEvent(GuiScreenEvent.KeyboardKeyPressedEvent.Pre event) { if(event.getKeyCode() == RelEqtMain.EXITMENU.getKey().getKeyCode()) { Minecraft.getInstance().displayGuiScreen((Screen)null); } }

Yeah, good Morning, feels like waging the war against Java code, to end all wars. This time around the battlefield is custom keypress, and closing the various instances of all menus. The reason? Because I'm an arrow key player, that has to reach all across the keyboard in order to close menus, which can't be closed with the inventory key, or will never close if the recipe GUI is opened. I pretty much tried all available solutions, including using dedicated KeyPressEvents (vanilla and Forge variants), and made sure to not reach across logical sides aka dividing all necessary functions into client and server events. I also made sure to have the events registered on the proper Bus, but for the life of me couldn't figure out why Minecraft.getInstance().displayGuiScreen((Screen)null); does not close all menus. I had at one point the idea it happens because some GUIS do not respond to client ticks, but figured that can't be true, because it would do so in the Main Minecraft .class's I did found traces in MC .class various GUI functions, as well as in the IngameMenuScreen .class, but either it is hardcoded to not allow using a single key to close all of the menus(which ESC actually does), I am to stupid stupid to figue how it does it, or the ESC function is so deeply nested and addressed by various instances, that I simply cant't be allowed to put them all into one keypress function. I'm using the client tick event as recommended on the Mod bus(not Forge bus) like this: Any help would be extremely appreciated. Or at least a hint on why it actually does not address any single GUI instance, with a custom keypress, while it does so in the original game. You can figure this out inside the KeyboardListener.class: I should note that I actually managed to open any of the GUI screens on custom keypress, but how does the game figure out if it is inside any of the various GUI Screen instances, and should close any of them with pressing ESC? Edit: I figure mimic an ESC keypress would be an even easier solution. Can you do this on custom keypress?

The final solution was to learn how to register and use a loot serializer, like this: ...and then extend on LootModifier like this: The registration happens on the Mod bus(not Forge bus), in your main class's RegistryEvents. I still can't get over the inconvenience, how cryptic the Forge Docs uses to be though.

Good Morning, I tried overriding one of the vanilla rock blocks according to instructions in this old thread, but failed for the same reason the org TM did, even though I got a tiny bit farther than he did. I can remove the original block entirely from world spawn, and replace it with custom version, which I want to prevent due to following up workload(adapting recipes etc. to custom block). What I tried solving the issue/actually making replacing(partially) work: 1. I had to use the original Forge variant of registering the block in main class, like that: which actually did use the custom granite block as replacer(not exactly illustrated in the old thread), but didn't consider it on world feature generation... 2. I then believed it was due to not using correct path variables for assets texture/models/blockstates etc., so I created missing asset packets for both, vanilla asset path, and my mod path. This also did not fix the issue with creating holes filled up with Items.AIR on world feature generation. 3. I then tried to remove the vanilla granite block during feature generation, and reimported it after with my replacement set up, during feature generation as well(according to @Luis_ST advice). But the holes were still there, only this time I got my replaced granite block spawned as well. What do I want to achieve(asking myself and you in hope maybe there's a better solution)? Mojang found it a good idea, to give one of the hardest rock materials on this planet, the .harvestLevel(soft as a pillow), so I can harvest it with a wooden pickaxes(which technically is even worth, but doesn't matter since wooden "pickaxe" tools do not exist in my mod). I really just want to compare harvestLevel of any of my tools, against the harvestLevel of the targetBlock, so I can automatically disallow harvesting it, if the tool doesn't match the harvestLevel(which for whatever reason does not work as intended in 1.16.5 Minecraft). Edit: and before you shout "doPlayerHarvestCheck". Yes, I do that! Edit2: Also, why are there Manga Comic Girls, on the right upper corner of my Monitor, stating how can it be that big?(whatever "it" is?)

Oh, so load from/into memory? Like this is adding a new "serializer" to the "acceptedItems" aka -> 0_0, 0_1, 0_2 etc.???, if the length is 1? If not, it will create a new array which will serialize like 0, 1, 2, 3? I really still don't understand what I'm talking about.