Cratthorax

Build on Eclipse 2021-03 (4.19.0), with Java 8(JavaSE- 1.8 System Library)...bad for you and me, I can't remember if it was provided by default, or if I had to download it. That's another hurdle I guess. If all fails, and it likely will, use an .exe named jarfix.exe(Google?). Setting up Java 8 is a pita if you're just an intern as I am. You'll have to fiddle around with the windows registry, or so. However, the actual Forge MDK instruction: 1. make new folder as you please 2. copy and extract you Forge mdk source(which you've downloaded from here. The recommended(not latest), which is 1.16.4 - 35.1.4, not 35.1.37) 3. remove any files and folder, from what you've(hopefully correctly) extracted, except: build.gradle, gradlew, gradlew.bat, and the gradle folder 4. open cmd window(windows->search->cmd-click black window icon), navigate to your newly build mod folder(changing harddrives D:, changing folders cd yourFolderName) 5. execute gradlew.bat(in cmd, NOT Eclipse!), like so: "gradlew genEclipseRuns" 5a. wait for it to start doing its thing in the cmd window, and only proceed AFTER it has finished its job 5b. in fact you do not want to mess around with or start your Eclipse IDE at all, to this point! Just don't! 6. now start Eclipse and import a new gradle project, like so: File->Import->Gradle\Existing Gradle Project->Next->Browse to your newly created Mod folder and select it->Finish 7. It should(I'm saying should because you never know, since there are 3 different instructions on the Forge Wiki, Minecraft Wiki, and a Forge forum thread) now work like supposed to Do instructions really defer? Yes they do. There are small details different from any new version, and the Forge Wiki instructions for 1.16.x totally misses the point, were you're supposed to either import an existing gradle project(that you've just created with the gradlew task genEclipseRun), OR build a new project which needs major edits in order to work properly. Funny enough, the Github ReadMe has that info, but this is never mentioned in any of the multiple threads, that will only link you to the Forge Wiki for 1.16.x(which is not 1.16.4 obviously). Only God knows why you get mocked for not having that omnipotent insight. You also figure at one point, that Eclipse doesn't seem to be the familiar Forge Family IDE, even though the Wiki recommends it. Why you make teh thread for tis!? Because forum searches usually suck Elephant's marble, and Google does not. This thread is primarily done to have a future reference for myself, to have a clear, and infallible instruction, whenever I'd return to modding, or make a new project in Eclipse, for 1.16.4. There's no guarantee this is going to work for any version prior or after 1.16.4. Wall of text! WTF!? Yeah, it's called venting steam. I'm pretty annoyed right now, because that's the third time I'm tearing my hair out for following instructions, AND not getting $%&§ done. It's going to end here. Unless I forgot I've made this thread...:)

How does iterating over massive amounts of code, in comparison to a one time, client side, boolean check, make modding efforts more "beauty"? The config file will be created as usual, in your scope of "beauties" with regular code, anyways. So how does it matter if I write to this already existing file clientside? You did not provide a more professionell solution, nor did you share your massive inside into Java/Minecraft coding, to why this is so risky, what I'm doing. I really fail to see the lesson if you just connect it to saying how ugly things are, and rebuke me for hacking the grace of Forge methods. Which I probably don't even know they exist, given there are so many ways to skin the cat.

Well, the system put in place asks me to build configs code for more than 70 blocks, and at least the double amount of itemBlocks spawned on BiomeGeneration as EntityDrops. I simply don't do that. That would sum up for more than 70% of my already existing code. I initialize the method on FMLClientSetupEvent, check if a file is present, and if present, it doesn't do anything. I suppose users installing new mods on their servers will at least start them once, to create config files if present? At least that's what I'd do. I checked this on LAN game, and it is working flawlessly, at least the last 4 hours with multiple bug track points in. I'll come back complaining about the wheel if something dramatically is happening...:)

And I don't know how to loop through ItemTags. Unfortunately a List.array would only work for strings. DF!

I'm sure I can do more. And I'm sure I didn't expressed myself comprehensible enough, for you to provide information, that you have already provided in the past...:D Just make sure it happens way preInit: private static void initDefault() { @SuppressWarnings("resource") File configPath = new File(Minecraft.getInstance().gameDir + "/config", "matlib-common.toml"); InputStream inputStream = MatLibMain.class.getResourceAsStream("/assets/matlib/matlib-common.toml"); try { Files.asByteSink(configPath).writeFrom(inputStream); inputStream.close(); } catch (IOException e) { e.printStackTrace(); } }

Can I even nest a for loop into the .smeltingRecipe() method?

Sure I can, but the default value is this, I'm just trying to save time:

Some of the recipe methods, like .smeltingRecipe(), won't compile without casting an IItemProvider argument in front of ItemTags.WOOL. Let me see if it does what's proposed.

So I got my "modname-common.toml" file created, and know how to populate the file with variables. The problem is, I've got a lot of them...really a lot. I'd need about 4 times as much code if I'd try to pre populate by default, so I'm looking for a way to just easily provide a preset config file, and copy it to the config folder. Can someone tell me if that is even possible?

Utilizing tags it needs an IItemProvider?

Good morning, so I'm currently in the process of converting my recipes to DataGeneration(1.7.x to 1.16.x). In the past I would simply copypasta groups of code blocks, primarily due to laziness and lack of time. I want to change that, and if it's just to render my code a little bit more professionell. I remember in the past you could "group up" item types by calling their material, but no matter how much I'm trying to convert this method, and browsing the Forge/MC Snapshot files, I don't think this method is available any more(correct me if I'm wrong). So, in code, here's what I mean: Material, ItemType, or an ItemArray, what would you recommend? I'd need that info to actually browse the correct files.

Blocks.AIR?

W10 Pro. Android 11 on my S20+(or is it 12 already?). My two other computers are running on W10 home, all behind G-Data security suite, and a Fritz. I'm supposed to use Linux, no? I hate making things compatible, and Linux has limited access to some games I love, so...Mac is even worth I guess? I'm buying servers btw. It's not I couldn't set one up for Linux, but I lack the skills in online security, and I'm paranoid. So not a good combo I guess?

Yeah, the whole registry process can be quite confusing and daunting for how MC is working nowadays, but once you get the grasp of it, it actually saves a whole lot of effort, and quantity of code. I'd spend 3 days+ to actually figure I had to apply the getter(.get())[<-- is this even named getter?], to any of the .class references, because stupid Eclipse refused to de-obfuscate the source of problems. It was just making stupid a** auto fix suggestions, that didn't help at all. Google found the answer quite often though. And don't even get me started when I was trying to implement the Oil to world generation. I was literally tearing my hair out for days. But don't give up. We're not the only ones dealing with the reinvention of MC code wheel. I mean I get it. There's always room for improvements. But a wheel is just a wheel, right?

Because I was used to doing it like that in the past. Also, a block is very sparse in code quantity. Also, also, I would use the blocks to check against blocks of same type at lower levels, to mark as an indicator to what can be found digging deeper into the ground. Doing that with anything but the same object type is just unnecessarily bloating code. However, I had to use creative ways to get something working. What I did was rendering my block and its voxel shape invisible, make it nonsolid and notBlockMovement, then apply the randomTick() method, and using this: worldIn.destroyBlock(pos, true);...which basically drops the item after the blocks gets randomly destroyed. The good thing about that is, with the new DataPack function, I can do all that stuff with a single block object, and then just use instances of other block registers and their properties. I can also customize the loot tables for any of them, but don't need an actual block.class for any of them. Given how I have more then 60 ore blocks in my old mod, that is a really great thing about newer MC versions. The final solution was actually found in vanilla Block.AIR, after messing around with various methods, none of them doing what was easily done in the past MC versions with onBlockAdded(), and dropBlockAsItem(). I'll just leave the block code, and register code here for reference, which should give you a picture of the many things I was trying without success:

The bucket item should be pretty straight forward and is handled in a general purpose registry file. I basically just copied the vanilla water bucket registry, and changed to what I needed. The fluid block and registry however gave me some headache. You prolly want to adapt to changes in 1.17+, but most of the code should be working out of the box. Fluid block:

Good evening, I'm using a NoFeature generator to spawn block types of ores, that resemble deposits at lower layers. Right now they look the same as the ore blocks some levels lower, but I actually want them to exist as items on the surface. In the past I was utilizing onBlockAdded(), and dropBlockAsItem() directly inside my blocks to do exactly that, but this does no longer seem to be an option, because any of the block methods, that handle "BlockAdded" logic can't be used during world generation, when starting a new game. Which is unfortunate to say the least. The problem I'm facing right now: dropping an item from block after it is placed in the world, without player interaction, doesn't seem to be an option either or I just fail to find it. At least none of the block or item .classes contain anything useful. Can someone direct me where to look, please?

Oups, sorry, solved. Obviously I'm supposed to provide an object of type item, and not type block.

Good morning, I'm trying to implement ShapedRecipes into my mod via DataGeneration. I'm using vanilla MC code as template, and I'm able to create a single recipe, but the code will fail if I try to build multiple recipes in the same method. Which is a bit confusing, since I pretty much do it exactly as the vanilla code. The code:

Yeah, I'm already running on DataGeneration. I just wanted to clear out more workload, if I could prevent it. Thanks for the info guys. Well appreciated.

Hello, is the Ore Dictionary still in use? There doesn't seem to be an article for version 1.17 MC and beyond? Also, if it is still in use, how many mods make use of it? I'm asking because I had it implemented for my 1.5.2-1.7 versions of Material Evolution. But I feel like it's wasted energy to implement it again for 1.16.4, if it is not used anyways?

It does with minor changes. I've tested myself. You'll figure.

That's interesting you say that. So basically the RegistryObject can be whatever it wants, but the new BlockCrudeOil is the one addressing the object.class? This might be very well the reason why I can't get my custom oil tags working. I'd still have to "hack" the minecraft.water tag in order to give proper physics etc. to my custom fluid. I've found some leftover traces from you, over here. But it wasn't a priority on my list, so after some struggle and fail I just moved on to more important topics. I shall test this tag thingy again with my newly gained kiddy skills...:)

WorldGen you ask? I'd have examples for Decorations, BiomeHandlers, and Features as well. You can refer to post 3 in this thread for some input.

Good evening, a bit more progress and inherited info. I finally managed to understand why I couldn't perfectly connect my registry's to the object.class. You guys were right all the way. It was all about basic understanding of Java, and to correctly use fields, constants, properties etc. It's just one of 6 code languages I'm script kiddying, so bare with me. It also made sense to understand, that my Fluid.class(not FluidBlock.class) was, from its logic, actually a "register".class just as my main register .class, and I could basically just have used all my fluid.class code inside the general registry as well. So it seems important you also give perfect label/naming/package structure to your mod, though I know from scripting with Papyrus, it isn't the worst thing to multithread. However, the FluidRegistry.class has the FluidBlock.class registered like that now: