yoshiquest

This issue is rather... complicated, so bear with me. The mod I am writing involves inter-op between Java and Clojure, and utilizes the Clojure compiler. The compiler is itself written in java, meaning that whenever Clojure code is in the compilation phase, a jvm is there. Unfortunately, Clojure has a bad habit (as far as I can tell) of compiling Java classes it references as well ahead of time. This means that I have run into a problem with net.minecraft.init.Blocks, as there is a static block there crashing compilation if it gets loaded before bootstrap is registered. This means that any class referring to Blocks (such as BiomeGenBase as one crucial example), will crash the game when Clojure tries to load it. I was able to get around this for a time by using a bit of reflection to set the variable it was checking (alreadyRegistered in Bootstrap) to true, tricking it into letting my code compile. Unfortunately this failed as soon as I started to use BiomeGenBase directly, as the class is trying to call a method on the result of Blocks, causing a null pointer exception and crash. So I figured I might as well just call register in Bootstrap, in order to get everything while it's compiling. Sadly, this eventually causes a crash as follows: sun.misc.Launcher$AppClassLoader cannot be cast to net.minecraft.launchwrapper.LaunchClassLoader Presumably due to some classes wanting to reference Minecraft's class loader instead of the default class loader that Gradle is building with. TL;DR: I wish to know if there is a way to change the class loader that Gradle builds with to the loader Minecraft wants, as with that I could presumably avoid all of these issues once and for all.

I was afraid of that. Well, might as well get started...

As long as you don't just package things and ship it as your own I am pretty confident you are in the clear here, but don't quote me on that. Check the licenses if you want to be sure. What it basically does is: - Download the Minecraft files. - Decompile them using a custom version of FernFlower. - Deobfuscate the result using the data from MCP. - Apply the forge patches. - Know how to remap between SRG names and MCP names (forge patches are in SRG names but you want MCP names in your workspace). - Reobfuscate your built jar file so it runs in normal minecraft (same as the previous step except mapping MCP to SRG names). I might have missed something here but this is the gist of it. Overall it is pretty complex, since there is a lot to the whole remapping process. Well, ForgeGradle relies on MCP, not the other way around. Not sure what you are trying to ask here, you can read the whole ForgeGradle code on Github Yeah, thanks. As for the third part, I was really thinking about what parts of the compilation process are covered by MCP, rather than being fully implemented in Forge Gradle. I think I get the gist of this though, that second part was very useful. Thanks!

Yeah, I know I'm gonna sound crazy, but this is something I've been meaning to do, and something that needs to be done. As you may already know, I've been developing a mod to provide support for another programming language (Clojure) for Minecraft modding. However, I have repeatedly run into problems, partially stemming from the fact the Gradle plugin for Clojure is sort of... unreliable, as well as the fact that I have little control over how things are compiled, resulting in a ton of bizarre bugs and issues I've frankly gotten tired of solving. So my solution is to reimplement Forge Gradle as a plugin for Leiningen, the main dependency manager for Clojure. It's actually rather easy to use (far easier than Gradle in my opinion), so using it for Java mods wouldn't be out of the question either. However, I simply don't know where to start, so I'd like to ask some questions in order to get my bearings (assuming this is feasible in the first place): 1. Will I run into issues, legal or otherwise, with the people who made the Minecraft Forge Gradle plugin, or Minecraft Forge itself? 2. What exactly does Forge Gradle do? Er, I know this is a vague question, but I'd like to know a bit more about the details of the various stages of compilation if I'm going to do this. 3. What tasks does Forge Gradle hand off to other tools, such as MCP (in other words, what can I NOT worry about)? I know this might seem like reinventing the wheel, but this will go a long way towards creating better support for Clojure in Minecraft, or possibly even a better platform for Java code (Maybe).

Fixed it! Now let me explain what it was. Apparently, Clojure isn't SUPPOSED to load imported classes, and this was fixed in Clojure version 1.7. However, the gradle plugin I was using to compile the Clojure code was using Clojure version 1.6. Luckily for me, there was a not-very-well-documented newer release for that plugin, and upon updating the issue went away. So yeah, that's what it was.

Good question! I have no idea! Again, probably something with the Clojure compiler, might try asking people experienced with Clojure about it. It probably has something to do with how I need to AOT compile things. I've experienced a similar problem in the past, where importing client-side files in a namespace and then would crash on the server side even though the namespace was never used when it was on the server side. Nah, I don't think so. That might sound a bit stubborn to you, but my project is called forge-clj for a reason, with that reason to provide support for Clojure in Minecraft. In other words, Clojure is kinda the entire point of this.

I don't. Actually, I probably should mention that this error is THROWN AT COMPILE TIME (aka when compiling not running). I think it might have to do with how Clojure tends to preload things at compile time. Maybe.

Ok, I began to port my mod to Minecraft 1.8.9, and this happened. I don't think you guys will be able to fix it, but I'll post it anyways. Upon compiling the first time it works just fine, but compiling a second time causes a crash with the following error: I did a little bit of testing, and figured out that this seems to be caused when the compiled Clojure file registry__init.class is present. Upon deleting this specific file, it compiled just fine. After this file was generated and I try to compile again, it crashes again. For those who can actually read byte code, the file in question is downloadable here (I have a feeling this goes down to the bytecode level). This seems to be caused due to me importing the BiomeGenBase class, which contains references to the Blocks class. Upon removing the import, this goes away completely, though I shouldn't have to do this. The Blocks class seems to now include a check to see if Bootstrap registry is complete, that wasn't present in 1.7.10, which will through an error if the Bootstrap class returns false for whether or not it is finished. But for some weird reason, whenever the generated class file is not present it works fine, but whenever the class file is present, this causes it to return false on the check, crashing the program. I have absolutely no idea what is causing that. So there you go. If no one can solve this problem, I'll try to post it on a Clojure board, since it could be a problem with Clojure's compiler as well.

What the title says. Should I update my project (forge-clj) to 1.8.9, or stay on 1.7.10 until I've finished some things? What all changes are involved, how big is the switch, and is 1.8.9 starting to see some common use? I'm just kinda uncertain...

Updated forge-clj to Version 0.5.2. I added the ability to make new biomes, and some support for custom Chunk Providers. Unfortunately, I was unable to get a full chunk provider implementation working, due to slowness and general complexity, so if you want to use that, I recommend you make a Java version and reference it from Clojure. And sorry about this update taking so long, I spent a lot of the time trying and failing to reimplement the terrain generator. It's just too performance intensive for Clojure to really handle. I don't think any of the other updates will take this long... Next up, I'll move on to start implementing custom dimensions. I don't think this will take too long, hopefully.

Thank you. This is EXACTLY what I needed. Might not do it exactly the same way (this is Clojure, not Java, after all), but with this I should be able to test it easily enough. Again, thanks.

Ok, it's been 3 days and no one has answered, AND I've also just finished the implementation of the Chunk Provider, so I guess I'll rephrase my question. I'm wondering if there is possibly a way to replace Minecraft's world generation (perhaps in a different world type) with my Chunk Provider, keeping everything the same except for that. I'm just worried that since this implementation is HUGE (as is the original Minecraft provider), it'll break after I've already completed more advanced things later on, or not be accurate to Minecraft's current generator (which is what I'm trying to reimplement). So, does anyone know how to replace Minecraft's Chunk Provider with my own?

Since I'm having to implement a Chunk Provider in a language other than Java (and a very different one at that), I'm having to rewrite its methods/functions from the ground up. It's going rather slowly, but I'm worried as to how I could test this once I'm done with it. I need to see if the generation provided by this is equal to vanilla, but I don't want to have to implement an entire new dimension to test it. Any ideas as to how I could test it once I (eventually) finish it?

Tutorials are on hiatus for now. Currently looking at implementing world generation, and eventually, custom dimensions.

I have started to create some basic tutorials for using forge-clj. Currently, they only cover from how to set up forge-clj to making your first block, and is a work in progress, but it does exist now. So feel free to go through the tutorial, and make sure I didn't screw up. The link has been added to the first post. More tutorials will be added over the coming days.

Updated forge-clj to Version 0.5.1. I finally got around to adding docstrings to the code, so there is actually SOME documentation out there now for the api. I also added a couple of useful macros, and moved some functions around. Up next is most certainly a tutorial, which I'll be writing soon. I'll post a link and update the main post when I'm done with it.

Updated to Version 0.5.0: Added GUIs and REPL support! If you don't know what the repl is, it stands for Read, Eval, Print, Loop, and lets you run code while the application is running. It's currently only useful for testing, but it's nice that I made it happen! I think I'm going to work on some actual documentation next. It's about time I really told people how to use forge-clj.

Ok nevermind. I was reimplementing the addSlotToContainer method, and forgot to set the slotNumber of the newly-created slot to the size of the list. So it was me derping. Sorry if I wasted your time .

Bumping because I just overhauled my entire gui system, and this is STILL happening. If you need to see a java-ish version of a piece of my code, just ask (I'd rather not convert the entire codebase to that, thanks). But seriously though, I need some help here, because I have no idea what could be causing this to happen.

Added code to my github for those who understand clojure code: forge-clj test-mod Where forge-clj is the api I'm building, and test-mod is the mod with the actual gui code and stuff. This is still a problem, so help would be appreciated.

Updated forge-clj to version 0.4.1. Fixed bugs and stuff. I also spoke at Clojure Conj today about forge-clj, check it out here.

I'm having an issue with my Container class. Every time a slot is clicked, the slot picked is always 0, no matter which one I choose (overrode slotClick to test this). What could be causing this issue? Or, more specifically, what all methods call slotClick, so I can narrow down the problem a bit more? Would post code, but system is written in Clojure and VERY complex. I will say though that the IInventory seems to work just fine, transferStackInSlot is not overridden (though this shouldn't be a problem), canInteractWith always returns true, and the slots I add are still highlighted when hovering over them, and their slots are indeed set properly.

This is interesting! I'll have to take a closer look at this. The main reason I wanted to use Techne was because I thought it was widely used to create models. However, if that isn't the case anymore I'll gladly use this.

I'd like to see the form that Techne models take in order to create a program that converts this data into code for another programming language. Unfortunately, no matter how hard I try, Techne won't run for me, either online (fails spectacularly) or for the client (for client I have a mac, and my windows machine currently doesn't have internet so no luck there either). So, uh, if you've made a Techne file, it'd be nice if you could post a download link for the raw generated .java code, and if you can, the file exported by using .json instead. Even getting one already posted online and doing this is just fine, it's just that I can't seem to do it myself with the equipment I use. Again, it has to be generated by techne, preferably with no changes to the files generated, since I need to know how these files are structured in order to act upon them.

Updated to Version 0.4.0. Added a system to handle models and animation, though it only works on tile entities at the moment, and Techne models are not supported yet. I think I'll end up creating a separate conversion tool to turn the generated java code into a clojure map you can embed into the code. Also added a couple of other minor systems, such as the ability to make a new creative tab for your mod. Finally, one of the biggest changes is that I changed how the mod is organized. It now is consisted of multiple files, and is much easier to read and find each part of the code, in both forge-clj and the test-mod. So if you didn't like reading through my messy code, it's cleaner now. As a side note, I also created a small program for myself that automatically builds and uploads the mod to dropbox, makes the new links, etc. So hopefully I'll be able to update a lot more often than I have been now that the process is easier.