Two

That was my second try, however the texture I get is very strange and does not include many blocks that are present in the world. The UV of leaves for example points to an empty part of that texture, and I am not sure yet why. It might be an error on my part, but then I figure that at some point the textures are loaded from disk anyway, so why get them via texture buffer? As far as I understand it, there has to be some point where the texture files are actually loaded from disk in the form of a BufferedImage. What I would like to do is to either somehow do the same, or to intercept that either while it is loading or at a later time if that image data is kept in memory afterwards.

One build.gradle coming up:

Thanks, but that's the part I already know. I am looking to access the pixel data from that icon, but I don't know hot to get it.

I am currently trying to write a minimap addon and I am desperately trying to find a method that allows me to get a block's top texture reliably. So far I tried to get the texture directly from the IIcon by casting it to a TextureAtlasSprite if possible, but that is limited to only a few blocks. I also tried to fetch the image directly from the texture that holds the block faces, but that feels very hacky to me and requires exact timing to actually get the block texture properly. Is there a better/reliable way to get the top texture of any block that has one?

If I try to add the very same line as you have, I get the following error: * What went wrong: A problem occurred evaluating root project 'mc-forge-1710-mapwriter'. > Could not find method testCompile() for arguments [junit:junit:4.11] on org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler_Decorated@ff5762d.

I've been trying to get JUnit tests to run with Forge Gradle (1222), but I can't seem to get anything to work, and external resources are not helpful at all. Situation: I have a class that needs testing, so I auto-generated a JUnit 4 test class, which ended up in the test packages folder. Problem: - JUnit jar is not recognized, therefore test classes won't compile. - Adding JUnit dependency manually according to the gradle guide doesn't work even the slightest. How do I add JUnit jars to the test build properly so I can run the test case?

Last time I asked I was told that a Java version update would be possible as long as everyone does it. If that's still true: how about doing a version update once 1.8 is ready? As Java 8 is out for over half a year now, it can be safely assumed that it is mature enough. And with Java 8 we would get many features that would make life as a developer a lot easier. The very useful Lambda operations are just one massive reason to go with Java 8. It not only allows to shorten many constructs, in addition the ability to execute code in parallel on the fly can be a massive speed increase to many mods. Then we have enhanced concurrent operations, additional Math methods that help a lot with bit-wise operations, Optionals to get rid of all those NullPointerExceptions, default methods and function parameters which will make designing APIs a lot easier, and on top of that all features of Java 7. As far as I understand it, all that has to be done would be to change the compile target in Forge and we should be good to go?

Thanks for the answers Lex, I have a feeling that this must be a difficult time for you as you already said: you base your whole income on a very vague future at the moment. Let's hope that Microsoft does not destroy the game as many fear. My estimation is that Microsoft will realize that Minecraft and its very special community is something delicate to deal with, especially since many former Mojang developers will stay to tell them. I assume they will receive some additional senior developers from the MS pool to advance the quality of the game, eventually to a state where one could call it well programmed. I am just not so sure it will still be Java once they are done. Modding is something that drives this game and keeps customers happy, Microsoft would be stupid to throw that away, and I don't think that is going to happen. I could imagine two scenarios: the one that they will develop a modding API on their own (and license it) and the other that they will acquire one. Which one that would be in scenario two is obvious I think. As a business entrepreneur, maybe it might be an idea to talk to them about that scenario while they are still in the decision making process. Because, to be honest, I'd rather like to see a Forge API than any of those Microsoft nightmares.

I updated the initial post to reflect the changes. I still cannot figure out how to run individual tasks in NetBeans, just because the list of tasks is so huge that the window does not display any beyond the 'jar' task. Not sure what to do about this, but then you can always edit the run task to have it execute the proper 'runClient' or 'runServer' task.

Sorry for long time no answer and big thanks for the fix! I just tested the change with the current Forge version (172-10.12.1.1061) and it works. If you just hit the run tasks, it complains because no main class has been set. This is understandable because the script doesn't know if I want to run server or client obviously. It might be a good idea to default the run to runClient, because that is what most people want to run. If I change the built-in run task to run 'runClient' instead, the client launches properly and everything seems to work fine. I got at some point an error about the lwjgl missing, but the second time I run "setupDecompWorkspace" the error was gone. No clue what caused that on my first try.

There are mostly convenience features in J7 that I do not really need to use like binary literals and Strings in switch statements. I wasn't aware that J7 is such a problem on OSX?

Ok now I am confused. First you say there won't be a problem, now you say: don't do it. So... are there any known problems that will occur when I am using J7 as target for my mod while everyone else uses J6?

So basically I should enable --target 1.7 asap, because nothing can go wrong, except for the few players who happen to not have J7 installed?

Just wondering: what would happen if I'd compile my mod targeting Java 7? Beside the obvious that the user needs J7 to run Minecraft, which should be like 98% of all players. Would my mod be able to run alongside other J6 mods? Would it work at all?

https://github.com/MinecraftForge/ForgeGradle/issues/50 Thanks!

I've been trying some more things after a reply from LexManos, and I am pretty sure that the failure to run is a Forge bug. See here: http://www.minecraftforge.net/forum/index.php/topic,15233.msg77271.html

With your hint that the Forge build scripts actually do not define a proper run task, I tried to rule out all IDE problems by disabling the internal tasks and then writing my own run according to the official Gradle documentation: apply plugin: 'java' task(run, dependsOn: 'classes', type: JavaExec) { classpath = sourceSets.main.runtimeClasspath main = 'net.minecraft.launchwrapper.Launch' args '--version 1.6 --tweakClass cpw.mods.fml.common.launcher.FMLTweaker --accessToken FML' jvmArgs '-Xincgc -Xmx1G -Xms1G -Dfml.ignoreInvalidMinecraftCertificates=true' } And again the command-line parameters are ignored and the run fails, because Forge still uses the VanillaTweaker. [14:40:06] [main/INFO]: Loading tweak class name net.minecraft.launchwrapper.VanillaTweaker [14:40:06] [main/INFO]: Using primary tweak class name net.minecraft.launchwrapper.VanillaTweaker [14:40:06] [main/INFO]: Calling tweak class net.minecraft.launchwrapper.VanillaTweaker [14:40:06] [main/ERROR]: Unable to launch java.lang.NoSuchMethodException: net.minecraft.client.Minecraft.main([Ljava.lang.String;) at java.lang.Class.getMethod(Class.java:1665) ~[?:1.7.0_45] at net.minecraft.launchwrapper.Launch.launch(Launch.java:131) [launchwrapper-1.9.jar:?] at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.9.jar:?] I would now consider this a bug.

Because the Gradle-Plugin expects the game to be launched with a Gradle call. Which kind of makes sense, since otherwise I would have to break out of the entire Gradle-concept just to launch the application. This as well renders the concept of an Eclipse support pointless, because Gradle is Gradle and independent from the IDE used if implemented correctly.

I've been trying to setup Forge 1.7.2 Gradle with Netbeans without success so far. You can see the steps I've taken here. The command I added: -Pargs="--tweakClass cpw.mods.fml.common.launcher.FMLTweaker --version 1.6" The main problem is, that even though I have correctly added the command-line parameters for the tweaker class (according to all sources on Gradle that I could find), Forge still uses the vanilla tweaker, and I cannot figure out why. And there is no error message (except for the vanilla error) that would help me on finding the issue. It would be great if anyone could help me on this problem. In addition I think it would be a good idea to add the correct tweaker class parameter to the setupdev task, because every dev will have to set that parameter otherwise by hand. So setting it by default might reduce the amount of 'Gradle doesn't work' topics.

Use the force... eh.. Forge. The extracted ZIP is your working and project directory. But compared to earlier Forge versions, it is now much more tidy, as the Minecraft and Forge code has been moved into a jar by the team.

The Launcher class is hidden in the launchwrapper-1.9.jar. If your IDE can't find that, my guess is that you didn't run "gradlew eclipse" or got errors while doing it.

The difference to Ant for me as a Forge user is that I never had to bother with Ant-XML mess, because it just works. I can't say the same for Gradle.

This was one of my many attempts, but whatever I do, the arguments are always ignored even if definitely present, and I have no clue why. Edit: I changed the tutorial so that it adds the required parameters to the run config. It doesn't fix the problem, however.

You can see a working example in my mod. worldObj.playSoundEffect((double) xCoord + 0.5D, (double) yCoord + 0.5D, (double) zCoord + 0.5D, TwoTility.proxy.SOUND_FLUIDSUCKIN, 0.6F, worldObj.rand.nextFloat() * 0.1F + 0.9F); Where the parameters are: x, y, z, soundName, volume, pitch The point is that you first need to register the sound (as done in my ProxyBase (should actually be done in ProxyClient)): @ForgeSubscribe public void onSoundSetup(final SoundLoadEvent event) { event.manager.addSound(SOUND_FLUIDSUCKIN + ".ogg"); } Where SOUND_FLUIDSUCKIN is: TwoTility.MOD_ID + ":" + "fluidsuckin" And the sound-file is stored in: assets\twotility\sound

I do not have opinions about tools, I use the one that fits best. And if I have to choose between two tools that can both do the same, but the one is fully supported by all major IDEs, I'd choose the supported one, because... It is not about having to edit a text file, it is about what to write into it. With an ant properties file (if done right), there are a few selections to make that most people who are somewhat familiar with programming can understand. With Gradle you cannot simply edit a text file, you need to write code, which means you need to know the programming language, which means you need to look through various Google resources. And if something doesn't work (as with the current Forge setup), you are basically screwed until someone with a lot more knowledge comes around and does the work for you. That's the difference between editing a property file and editing the Ant build-script. There is a good reason why property files have been invented. What's the reason Forge doesn't want to use Ant?