Zeigfreid

The real answer is: use Eclipse! 1.14 forge development setup guide for Eclipse (OSX): git clone https://github.com/<User>/MinecraftForge Forge cd Forge ./gradlew setup eclipse forge:genEclipseRuns open Eclipse File -> Import -> General -> Existing Projects into workspace Run and Done!

I followed these steps, which I found elsewhere on this forum. I am able to make changes, run forge client, and see those changes. I am using IntelliJ IDEA Community 2019.2.4 However, I'm not able to "test with existing mods" as described in the docs for 1.13.x (which I think are the latest docs at the time of this writing). The general idea from the docs and linked video is: 1. import another mod as a module in the project settings 2. add forge main as a module dependency in the new module 3. add the output path of the new module as a "JAR or Directory" runtime dependency in forge main I have tried adding a mod of my own that works, as well as the example mod that comes with the forge mdk. In either case, forge client runs, the minecraft client starts. When I click the mods button from the minecraft title screen, I see only "Minecraft" and "Forge" in the list of mods. (which is troubling because I think I also expect FML). There is an error in the output of running forge client: `Incompatible Java and native library versions detected.` That seems pretty significant, but I'm not sure Here is the output of running forge client: 9:21:24 p.m.: Executing task 'forge_client'... > Task :forge:compileFmllauncherJava UP-TO-DATE > Task :forge:processFmllauncherResources UP-TO-DATE > Task :forge:fmllauncherClasses UP-TO-DATE > Task :forge:compileJava UP-TO-DATE > Task :forge:processResources UP-TO-DATE > Task :forge:classes UP-TO-DATE > Task :forge:downloadMCMeta UP-TO-DATE > Task :forge:downloadAssets > Task :forge:extractNatives UP-TO-DATE > Task :forge:prepareRuns > Task :forge:compileUserdevJava UP-TO-DATE > Task :forge:processUserdevResources UP-TO-DATE > Task :forge:userdevClasses UP-TO-DATE > Task :forge:prepareForge_client > Task :forge:forge_client [21:21:28] [main/INFO]: ModLauncher running: args [--gameDir, ., --launchTarget, fmldevclient, --fml.mcpVersion, 20190829.143755, --fml.mcVersion, 1.14.4, --fml.forgeGroup, net.minecraftforge, --fml.forgeVersion, 28.1.90, --version, MOD_DEV, --assetIndex, 1.14, --assetsDir, /Users/zeigfreid/.gradle/caches/forge_gradle/assets, --username, Dev, --accessToken, ❄❄❄❄❄❄❄❄, --userProperties, {}] [21:21:28] [main/INFO]: ModLauncher 4.1.0+62+5bfa59b starting: java version 1.8.0_131 by Oracle Corporation [21:21:29] [main/INFO]: Added Lets Encrypt root certificates as additional trust [21:21:29] [main/WARN]: Failed to find exploded resource mods.toml in directory [21:21:29] [main/INFO]: Launching target 'fmldevclient' with arguments [--version, MOD_DEV, --gameDir, ., --assetsDir, /Users/zeigfreid/.gradle/caches/forge_gradle/assets, --assetIndex, 1.14, --username, Dev, --accessToken, ❄❄❄❄❄❄❄❄, --userProperties, {}] [21:21:30] [Client thread/INFO]: Setting user: Dev [21:21:34] [Client thread/INFO]: LWJGL Version: 3.2.1 build 12 [21:21:34] [Client thread/INFO]: [org.lwjgl.system.Library:checkHash:467]: [LWJGL] [ERROR] Incompatible Java and native library versions detected. Possible reasons: a) -Djava.library.path is set to a folder containing shared libraries of an older LWJGL version. b) The classpath contains jar files of an older LWJGL version. Possible solutions: a) Make sure to not set -Djava.library.path (it is not needed for developing with LWJGL 3) or make sure the folder it points to contains the shared libraries of the correct LWJGL version. b) Check the classpath and make sure to only have jar files of the same LWJGL version in it. [21:21:34] [Client thread/INFO]: [org.lwjgl.system.Library:checkHash:467]: [LWJGL] [ERROR] Incompatible Java and native library versions detected. Possible reasons: a) -Djava.library.path is set to a folder containing shared libraries of an older LWJGL version. b) The classpath contains jar files of an older LWJGL version. Possible solutions: a) Make sure to not set -Djava.library.path (it is not needed for developing with LWJGL 3) or make sure the folder it points to contains the shared libraries of the correct LWJGL version. b) Check the classpath and make sure to only have jar files of the same LWJGL version in it. [21:21:34] [Client thread/INFO]: [org.lwjgl.system.Library:checkHash:467]: [LWJGL] [ERROR] Incompatible Java and native library versions detected. Possible reasons: a) -Djava.library.path is set to a folder containing shared libraries of an older LWJGL version. b) The classpath contains jar files of an older LWJGL version. Possible solutions: a) Make sure to not set -Djava.library.path (it is not needed for developing with LWJGL 3) or make sure the folder it points to contains the shared libraries of the correct LWJGL version. b) Check the classpath and make sure to only have jar files of the same LWJGL version in it. [21:21:35] [Client thread/INFO]: [org.lwjgl.system.Library:checkHash:467]: [LWJGL] [ERROR] Incompatible Java and native library versions detected. Possible reasons: a) -Djava.library.path is set to a folder containing shared libraries of an older LWJGL version. b) The classpath contains jar files of an older LWJGL version. Possible solutions: a) Make sure to not set -Djava.library.path (it is not needed for developing with LWJGL 3) or make sure the folder it points to contains the shared libraries of the correct LWJGL version. b) Check the classpath and make sure to only have jar files of the same LWJGL version in it. [21:21:35] [modloading-worker-1/INFO]: Forge mod loading, version 28.1.90, for MC 1.14.4 with MCP 20190829.143755 [21:21:35] [modloading-worker-1/INFO]: MinecraftForge v28.1.90 Initialized [21:21:42] [Forge Version Check/INFO]: [forge] Starting version check at https://files.minecraftforge.net/maven/net/minecraftforge/forge/promotions_slim.json [21:21:42] [Forge Version Check/INFO]: [forge] Found status: AHEAD Current: 28.1.90 Target: null [21:21:45] [Client thread/INFO]: OpenAL initialized. [21:21:45] [Client thread/INFO]: Sound engine started [21:21:45] [Client thread/INFO]: Created: 512x512 textures-atlas [21:21:46] [Client thread/INFO]: Created: 256x256 textures/particle-atlas [21:21:46] [Client thread/INFO]: Created: 256x256 textures/painting-atlas [21:21:46] [Client thread/INFO]: Created: 128x128 textures/mob_effect-atlas [21:21:47] [Realms Notification Availability checker #1/INFO]: Could not authorize you against Realms server: Invalid session id [21:21:52] [Thread-1/FATAL]: Forge config just got changed on the file system! [21:22:18] [Client thread/INFO]: Stopping! 9:22:18 p.m.: Task execution finished 'forge_client'. I noticed that in the dependencies list for forge main there are two entries for LWJGL: Gradle: org.lwjgl:lwjgl:3.2.1 Gradle: org.lwjgl:lwjgl:3.2.2 I'm not sure how to follow the suggested actions a) and b) in the above output. I'd really appreciate some guidance! I am adding events to hook into grass spreading, and the change itself is really straightforward. I feel like I could have a PR up soon, but I am not interested in pushing untested code. Thanks!

And the gradle task you need to run is... what exactly? I have this same problem. The Contributing to Forge docs for 1.13.x described a very different environment to the one I cloned. I was able to get as far as being able to make changes, run forge, and see those changes by a process of experimentation. As of this writing I am unable to enable the test mods or run my own mods to test my changes. (I need a buddy)

Hmm if I define separate textures for each facing I am able to get those separate textures to show. For example: { "forge_marker": 1, "defaults": { "textures": { "all": "tutorial:blocks/tatami" }, "uvlock": true, "model": "cube_all", "transform": "forge:default-block" }, "variants": { "normal": [ {} ], "inventory": [ {} ], "axis": { "y": { "textures": { "all": "tutorial:blocks/orecopper" }, "model": "cube_all" }, "z": { "model": "cube_all", "x": 90 }, "x": { "model": "cube_all", "x": 90, "y": 90 } } } } In this case, the orecopper texture shows when I place the block against the y axis. In addition, when I view the debug info with F3 I am able to see that the blocks variant is being chosen correctly. So the correct variant is being chosen based on the property value. It's the rotation that isn't happening. I've double checked my rotation values against the hay_block.json values, and then I also took time to "figure out" an intuition for which rotation corresponds which which action on the block in the world (I was kind of flying blind). If I click against the a block face that lies in a plane normal to the x axis, then I am selecting axis=x. With a bale of hey I see a rotation of the block 90 degrees around the x axis and then 90 degrees around the y axis (which is vertical). I've convinced myself that if the rotations were happening, I would definitely be seeing the orientations that I want to see. That being said: looks like its back to the tutorial mines for me!

I'm going to copy/paste the implementation of `BlockRotatedPillar` and fill it with `println` statements to get a sense of what is and isn't happening.

Ah problem solved! I am now able to view JSON files. The key was I had so far been using an external editor to work with my own JSON files (vscode). An external editor isn't allowed to open files from inside a jar maybe? Anyway, when I set the default open with to eclipse's internal generic text editor I was then able to open hay_bale.json. However, as expected, it is a minecraft blockstate not a forge blockstate... { "variants": { "axis=y": { "model": "hay" }, "axis=z": { "model": "hay", "x": 90 }, "axis=x": { "model": "hay", "x": 90, "y": 90 } } } (but I'm glad to have the correct rotations)

Hmm, Cadiboo it isn't that I am unable to edit JSON files at all (I edited the one above, right?) it's that when I try to open a JSON file in assets.minecraft.blockstates I get an error. I get a similar error if I try to open a png from assets.minecraft.textures.blocks. I think it is because these files are in a jar? It's weird though because I can open a .class file from net.minecraft.client.main so...

Thanks for the lint Cadiboo I did in fact try looking at the `hay_block.json` file in `assets.mincraft.blockstats`, but I received an error "Problems opening editor for hay_block.json: System editor can only open file base resources".

Hmm yeah definitely not working. I changed the json to this: { "forge_marker": 1, "defaults": { "textures": { "all": "tutorial:blocks/tatami" }, "uvlock": true, "model": "cube_all" }, "variants": { "normal": [ {} ], "inventory": [ {} ], "axis": { "x": { "textures": { "all": "tutorial:blocks/orecopper" }, "model": "cube_all", "x": 90, "y": 90 }, "y": { "model": "cube_all" }, "z": { "model": "cube_all", "x": 90 } } } } In the hopes. When I place a block on the x axis I should get an oreCopper, but I don't! So there must be something I'm missing elsewhere. I extend from BayHale and when I use the minecraft blockstates like "axis=x" and "axis=y" in my json I get the default texture, but the texture has "tatami#axis=z" or "tatami#axis=y" written on it, so in that case I know that the rotation is working. When I use the forge blockstates though, I just see the blank texture, or (once I added those `model: cube_all` lines, which I had assumed would be redundant) I get just the default tatami model. So... so something's up. Your `BlockLog` class extends BlockRotatedPillar directly, where as I was extending BlockHay (which is a really simple class that adds very little, and I figure a tatami mat is very close to a bale of hay in principle). Maybe I will try to extend BlockRotatePillar instead. Anyway, I have your repo to dig around in now (thanks) so I'm sure I will be able to figure it out! Thanks!

Thanks! Here's the class, but it is honestly just HayBlock. package net.shadowfacts.tutorial; import net.minecraft.block.BlockHay; import net.minecraft.entity.Entity; import net.minecraft.item.Item; import net.minecraft.util.math.BlockPos; import net.minecraft.world.World; public class BlockTatami extends BlockHay implements ItemModelProvider { public BlockTatami () { super(); setUnlocalizedName("tatami"); setRegistryName("tatami"); } @Override public void registerItemModel(Item item) { TutorialMod.proxy.registerItemRenderer(item, 0, "tatami"); } /* unfortunately, tatami will not save you from a fall */ public void onFallenUpon(World worldIn, BlockPos pos, Entity entityIn, float fallDistance) { // NO-OP } } (oh I just noticed that I missed an @Override ? ) (also, I realize that repeating hard coded strings is a bad idea, I'm just trying to get it working)

I encountered difficulty when trying to make a blockstate for a block with rotation like a log, or a hay bale. I've read this and this, and I know that `hay_bale` has an `axis` property with three values `x`, `y`, and `z`. I haven't been able to make the rotations work (the block shows up as a blank texture in world). If I leave off the `axis` property entirely, the block renders properly (just, without rotation). When I looked around at other mods (botania, harvestcraft) for examples of blocks with rotation, they are using minecraft blockstates (like, `"axis=x": {}`) rather than forge blockstates. I also poked through the blockstates folders of some jabelar's mods, but without knowing exactly what I'm looking for it's like... looking for a needle in a hay stack? My class is very simple and just extends `HayBlock`. My blockstate looks like this: { "forge_marker": 1, "defaults": { "textures": { "all": "tutorial:blocks/tatami" }, "uvlock": true, "model": "cube_all" }, "variants": { "normal": [{ }], "inventory": [{ }], "axis": { "x": { "y": 0 }, "y": { }, "z": { "y": 90 } } } } What is my misconception? Thanks for your advice in advance!

I am actually kind of already porting a mod from 1.10 to 1.12 ^o^// I started working on this tutorial a few days ago, but I had downloaded the latest version of forge (1.12). This resulted in bugs involving the registry changes, which I had to fix, which promoted learning. Even though I now know that an updated version exists I'm going to do the rest of the 1.10 tutorial, porting it to 1.12 as I go. Adversity helps me learn! Anyway, thanks again for your help! I'll be back with less annoying, more practical questions soon.

OK right, if I make a wrapper to isolate my mod code from the forge APIs etc... that would achieve the result I desire. What about things like the formats of the various json files? That's something I would not be able to encapsulate with a wrapper, if the formats have changed I would need to either... generate the json files from some common format, or write everything twice. What would be a good guide to look at for porting from 1.7 to 1.8 ? (just to get a sense of the concerns involved) What I will probably do is just learn 1.12.2, but I thank you, Cadiboo, for your advice! It could mean that, but couldn't it also mean that you/someone just has to write a new wrapper for each supported forge version?

I am learning to make mods. Is it possible to develop a mod that is compatible with 1.7.10, using later versions of forge? I noticed that botania does not hardcode the minecraft version number into its gradle.build file, instead importing it from a config file. I haven't dug around in their git repo, so I'm not sure how this works, or to what end. If so, are there some resources available for modders who are concerned with backwards compatibility? I'm sure someone will ask so I'll just go ahead and explain: I have no particular attachment to any version of minecraft and, as a programmer, I would like to work using the latest versions of the tools available. However, I started wanting to write mods while playing around with Botania and Pam's Harvestcraft in "the 1.7.10 modpack". This is a server that some friends and I are playing on together, and I thought it would be cool to be able to add some simple blocks and items (proper tatami mats, for example). Thank you!