Leaderboard

BlockStateProvider is the correct way to generate blockstate and model files. There's an example in Forge's GitHub repository here, and in my mod here.

Yeah, it may useful for accept water in nether

Oh , ok , you are right I miss that piece of code in the BucketItem: if (worldIn.dimension.doesWaterVaporize() && this.containedBlock.isIn(FluidTags.WATER)) But he can add an event like : PlayerInteractEvent.RightClickBlock just for the nether dimension to place a water source and stop the actual water from the bucket to be placed , if i'm correct ! Yeh , you are right , i dont give him the correct classes to look! My bad, sorry !

Jesus H Christ. What is so hard about finding the latest.log and copying all of it? Are you even reading my posts? If it doesn't fit, use fucking pastebin.

Because lava isn't biome tinted?

For simple blocks, it can be a single method call that generates both the blockstates file and the block model. If you have a lot of similar blocks, you can use loops or helper methods to save having to write out the JSON by hand (or having to write your own JSON generation code). The fluent-style builder classes make it very simple to use. The IDE can auto-complete all the methods and fields for you, so you don't have to manually type out block, property and value names.

Mojang added data generators (or stopped stripping them from the built JAR) in 1.14. Model generation was added in October last year by this PR. The code is still in the mod JAR after it's built, but it doesn't run at all during normal gameplay; there's a separate main class (net.minecraft.data.Main) that runs data generators.

On your github this is in your debug-1.log.gz file. This class I assume is the class for hm:chairsy does not have the facing property in it. And is causing this exception. Maybe fixing this will fix your error as it is the last thing in your debug-1.log.gz file.

If you refresh the project in eclipse it should find external changes. Again though, no way for us to know without seeing your project layout for ourselves

What diesieben said as well as if you want to automate this process you are going to have to write your own piece of code that generates those files. Which isn't that hard. You can take a look at this. I made this a while ago I don't recall if it still generates a proper blockstate, it probably doesn't, but the code should help you on your way.

Hi In addition to what Draco said: I think the difference arises when more than one mod is installed. Each mod gets its own MOD bus to deal with its own lifecycle events during startup+initialisation All mods share the same FORGE bus for gameplay events I guess the reason is to better control the order that the events are called in for different mods. No idea why that would be important. -TGG

Hi Look at mbe10 in this example project, this is the resource structure you need to follow. https://github.com/TheGreyGhost/MinecraftByExample/tree/master At Ugdhar said, often the console log will give you an good clue (typically "file not found: xxxx" which tells you exactly where forge expected to find your file -TGG

Post logs, and either share your codebase in a github repository, or I guess show a screenshot of your project layout in the IDE. This should provide enough info to figure out what's going on.

Update Regarding LTS System: Please read The Big Forge Update Earlier this year, 1.13 was announced and the snapshots started coming out, the update was relatively small, but enough to be a hurdle for mod developers. This combined with 1.12 stabilizing, and a few fundamental Java changes that broke modding in general, made the Forge team decide to use this opportunity and work on cleaning the years of technical debt that Forge had accrued. During this time, it was discovered that a lot of things needed updating. In fact, well, everything did. And so, it was done, a full rewrite of practically everything Forge related. This took a long time, longer than originally anticipated. But what’s the outcome of this you might ask? A lot. cpw’s mod launching system (ModLauncher) allows for parallel mod loading and support for more modern Java versions. (Considering the original was written to target Java 6). The Forge installer now runs tasks at install time once, rather than doing it every time you run the game. These alone provide dramatic reduction in launch times. ForgeGradle, the “devkit” for creating mods, has been rewritten and is faster at, well, everything. It also integrates much better with IDEs. What does that mean, you ask? Simple. Mods are nicer to make. (Also 100% less setupDecompWorkspace.) MCPConfig allows for much easier MCP updates, and is public source too, so people can see exactly what's going on between updates. In short: There was a lot of work to do. And now that it's done, future updates will be much, much smoother. 1.14 and 1.15 The 1.14 release came around, just in time for the rewrite to be finished, so it was time to get the ball rolling again. The bulk of the restructure work was done through 1.13's life, so all that remained was actually seeing how it was to update all of it, and it went pretty well. A lot of improved systems exist now that make developing for these modern versions far easier and just better in general. The 1.15 release was relatively simple, even if Mojang decided to restructure everything and make changes to how the rendering works. (Taking some of our systems in the process, don't worry, this is a good thing.) 1.15's rendering changes were mostly a refactor, and we expect 1.16 to be a large update to rendering. This plus 1.14 seeing growth is why we chose 1.14 to be a candidate for LTS. (More on that further down.) Hopefully this kind of restructure from them is a rare thing in the future, but we welcome the change, since it often brings improvement. Although the rendering changes may pose a tough hurdle for some, the update for most should be relatively straight-forward. Forge support and LTS Forge's support for Minecraft versions will try to follow a predictable cycle, assuming Mojang also follows a predictable cycle. We will always actively target the latest Minecraft version, as ever. We will now also deem a previous major Minecraft version as "LTS" (Long Term Support). The LTS version will receive support for modders and players alike, however all new features must target the latest version first, and then may be backported. An LTS version differs slightly from the latest version, in that any new features you may want to add to it, must target the latest version, only once it has been merged in, can it be backported. (The exception to this is if the feature is non-applicable to the latest version.) The Forge Team will also mostly be focusing on the latest. This is so the community has time to stabilize a bit and gives modpack developers some time to create something special. But still have Forge running full steam ahead. Late last year (Happy 2020!) a vote was held privately with many developers of various Minecraft projects to determine which version will be LTS: Should 1.12 remain LTS or should 1.14? A vast majority chose 1.14, and so, from now on we are dropping 1.12 from support, and 1.14 is now LTS. What does this mean? 1.15 is latest. It will get full support. 1.14 is LTS. It will also get support, and new features, but new features must be made for 1.15 first. 1.12 is no longer supported on this forum, no new features, and no more bugfixes. All other versions are not supported. This means if you come to us for help with those, we will ask you to update. This includes crashes/bugs. To keep with Mojang's history of releases, we expect 1.14 to stay LTS for 12-18 months, giving plenty of time for modders and pack developers alike. However, this may change depending on what surprises Mojang has in store for us. Finally… Thank you. Thank you to all the modders/developers, all the players, and especially to all the contributors. The Minecraft modding community would not be what it is without you. You are responsible for the striving ecosystem we have today. We hope this new year brings you all you desire, and we look forward to seeing what you create. And now time for some shameless plugging, if you like Forge, please consider supporting us. http://www.patreon.com/lexmanos - The Forge Team.

I want to not render certain blocks inside certain chunks. I want there to be no texture in the place of the block... something like XRay... and 1 more question... What happened to RenderWorldEvent? I don't seem to be able to find it

Hmm. I hadn't looked at that event for a while but you're right, it is not in 1.12.1 and looking at the events in minecraft forge client events referenced library doesn't show anything that looks like a replacement to me.

This is not what you want to do. This is a much more complicated and horrible way to do what you want to do. Just make the model/blockstate files.

I don't know.