jcranky

Not Forge's, but Minecraft's methods and fields are confusing because they are extracted from compiled code - which means that the original method and field names are usually lost. As I understand it, the tools involved in the process do a best effort to extract those names, but that is a quite complex matter.

Use the [ code] tags.

Hi, I was just wondering: how do you guys (specially the ones that read and post a lot) read the forums? From your browser? Perhaps some cool app or something? Something similar to Tapatalk, I guess? Is there any kind of API to access the forum content? []s,

Giving the topic a nicer (more descriptive) name would be helpful as well.

Don't. Conceptual discussions are always fun =)

Well, yes, I can agreed with that. It is different to say that your mod has an API, and that your mod is a library. And that is also why I am calling my thing a library: it is not a mod. It is a set of wrappers and helpers intended to help mod creators.

Everything is exposed anyway, unless we use classloaders tricks. So yes, organization and presentation are important. But technically, its all the same and that's where I'm getting at. So I'll have to remember to have both a developer's and a user's guide. Or on a second thought... installing the library seems to actually be part of the mod installing process. Does this make sense?

That's how I see it, and that's why I was a bit confused with jabelar's first statement.

And how would the modders use that API? Expose where? It is open source already. I'm just not promoting it too much because it is just starting and there are lots to be done still. It should be a library because there won't be any reason to change the code of the library. The internals are likely to get complex and easy to break if you don't know what you are doing. Like forge itself, it should be used, not messed with. Yes, the goal is to be quite comprehensive. I'm writing wrappers and DSLs on top of forge, with Scala.

Yeah.... that's a very complex problem. Handling libraries manually takes us back 15 years ago, before even maven was around... having to manage libraries, and libraries of libraries. Coming to think of it, this can affect the libraries of my library as well. Which means that, to be really safe, it would be better to avoid any external libraries at all... or am I taking this rationale too far?

No, I'm mainly concerned with the library itself, that will not contain any mods. I just want to make using the library as seamless as possible. All sample mods using the library are going to be in a separated project.

A jar with the mod and all its dependencies, so that the player doesn't need to add those manually to the mods folder.

I see. So the deof is for the mod author to compile against my library, but for the client to run that mod, the normal jar will have to be installed in the mods folder. This also means that creating an uber jar is a bit more complex. In that regard, would that be a good idea (the uber jar)?

So, I've been thinking about this a little. To use the published library, I'm having to do compile 'com.easyforger:easyforger-core:0.1-SNAPSHOT:deobf@jar' Point being: I'm having to specify the classifier. Is that what should happen? Also, is the 'normal' (non deofuscated) jar file of any usage in this scenario? thanks!

Why?

It is closing the addRecipe call.

Your code seems fine. The root of your problem is this: Caused by: java.lang.UnsupportedClassVersionError: net/ramenchef/ecologyproject/EcologyProject : Unsupported major.minor version 52.0 Which probably means you are compiling with java 8 and running with java 7, or something like that.

Code please

Is this EcologyProject thingy your mod or some library?

World.playerEntities?

Is it just me or this "I am very good at" is not very compatible with the kind of help being asked? edit: fixed typo

Here is an example for you: player.addPotionEffect(new PotionEffect(Potion.fireResistance.id, 10, 0))

So the main goal is getting the sources jar? I'm already getting that, I thought this was a standard task from gradle, but perhaps that is my publish plugin doing? I don't need sourceJar even here (tasks.build.dependsOn('sourceJar', 'deobfJar')) then? Also, where does the deobf classifier comes from? ForgeGradle plugin?

Draco18s, that is not a concern for me because I want everything. Perhaps that could be a way for you as well. Separate what is not part of the 'exported' lib in its own project. In my case, I'll have three projects: the lib, a tester, and samples. Its a bit more trouble setting up but everything gets nicely organized. The main down side is having to publish the library 'all the time', which is not that hard if you publish to maven local.

Perfect! Worked like a charm, thank you. Now let me just understand what is happening here. I just need the deobfJar task, plus the extra tasks.build.dependsOn definition, right? I see you also defined a sourceJar task. Why? It worked without that for me, but perhaps I'm missing something that I'm just not seeing?