Cross-Language Mod Development
- Thread starter Hlaaftana
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
YES! It works!
http://i.imgur.com/5lFLeyZ.png http://i.imgur.com/StGmbsc.png
Sorry if my excitement is a bit too much, I just LOVE Groovy now! If anyone wants to use Groovy too, I'll create a GitHub repo.
http://i.imgur.com/5lFLeyZ.png http://i.imgur.com/StGmbsc.png
Sorry if my excitement is a bit too much, I just LOVE Groovy now! If anyone wants to use Groovy too, I'll create a GitHub repo.
Well that's not necessary for that though, but I guess it would make it easier.
A dealbreaker for me is often IDE support - Java tools are very matured by now and not many languages are at that level, especially when trying to interface with Java code ^^
For instance: A Scala case class is much shorter to write than a whole Java class with getters and setters and equals and hashCode... but an IDE can generate all of that for me in a few clicks.
It looks like this either is or will be possible in the future using Perl 5. I haven't looked too in depth about it yet. I have only read what was written on the Perl Blog by one of the developers, because it was in this weeks Perlweekly (#216)
Huh... looks interesting.
Unfortunately I've encountered a large issue. Because of the obfuscation, any references to Minecraft methods will not work outside the dev environment. A fix I thought of for this was creating an API/library written in Java that added new methods for all the Minecraft methods needed. I'll get started on it soon.
Perhaps some advanced addition to ForgeGradle would do it but I'm not really sure.
EDIT: I'm currently creating the API for 1.7.10, Forge version 10.3.4.1448. If anyone requests 1.8, I'll try to do that too.
EDIT: Never mind. That'll take way too long.
Unfortunately I've encountered a large issue. Because of the obfuscation, any references to Minecraft methods will not work outside the dev environment. A fix I thought of for this was creating an API/library written in Java that added new methods for all the Minecraft methods needed. I'll get started on it soon.
Perhaps some advanced addition to ForgeGradle would do it but I'm not really sure.
EDIT: I'm currently creating the API for 1.7.10, Forge version 10.3.4.1448. If anyone requests 1.8, I'll try to do that too.
EDIT: Never mind. That'll take way too long.
Last edited:
Any at all? Does Groovy access all Java fields by reflection?
Anyway that can be a problem indeed for dynamic languages...but it's okay in Clojure. It will avoid reflection and you can tell the compiler to give a warning when it has to use reflection.
(Obviously it still makes the REPL pretty much useless ^^)
Anyway that certainly stinks...Groovy is pretty much out of the picture
Anyway that can be a problem indeed for dynamic languages...but it's okay in Clojure. It will avoid reflection and you can tell the compiler to give a warning when it has to use reflection.
(Obviously it still makes the REPL pretty much useless ^^)
Anyway that certainly stinks...Groovy is pretty much out of the picture
Last edited:
Huh, it does
I'll still try to make Groovy work. Even though my interest in modding has dropped significantly, I wouldn't want to give this up.
It doesn't appear so. While there is a version of the JVM programmed in Go, I don't think it actually works for Go.
Technically, you could say that all jvm languages access all fields/methods by reflections. Since the instruction to access/call a field/method takes a string as parameter and the jvm is the one that looks it up. I've gone around this issue when making the snapshot mod by obfuscating my own class when it loads: https://github.com/hea3ven/Hea3venT...va/com/hea3ven/tweaks/RuntimeObfuscation.java . Still, this method requires you to provide the mappings.
If you are running Forge, then forge automatically modifies all of the minecraft obfuscated classes into the srg names (i.e. func_179540_p). If you manage to rename all your calls to mc code to the srg names and compile that, it should work.
Yeah technically, but ForgeGradle replaces all the references that are done in this way during the build process. That's not possible for reflection, at least not until runtime.
Unfortunately not. The indy version didn't work either.
I'm now trying to include both the forgeSrc and srg jars in the build path, and looks like it's kinda helping. Only disadvantage is we have to use obfuscated code (for vanilla stuff).
EDIT: It works but... damn. All Minecraft fields and methods are obfuscated. I don't think it's possible to work with.
There's a jar somewhere in your Gradle cache that's fully deobfuscated if you need something to build against. But then you'd have to remap the mod to SRG names before it could be used.