Minecraft Forums

Quote from jcm2606»

Might want to wait until you actually have the API working with Forge mods before saying that, just sayin'. (Unless the API already works with Forge mods, but I don't think it does)

No, it doesn't, but thanks to the latest response from Spartan322, it will be one of the first things I do.

Quote from Spartan322»

Technically, extending forge is completely legal and legitimate, so there should be no reason not to start off with supporting Forge mods, now if you want to actually support them through the wrappers, that's a completely different story. Though, as I've said, I would like a mod system where consistency isn't an issue the modder has on the top of the already infinite amount of priorities.

I'll be implementing my own version of Forge API that just wraps my API. The methods in the API will be modified to point to my APIs methods.

One of the things I'd like to suggest to add to the Mixin system, in which I'm pouring some research into the JVM, is the concept of Overwrite Method Mixin Extend/Super system, which would allow you to inject the original method into the function at run-time, in these cases, it would be easier to prevent breaking when switching to new versions. The only issue I can see with this is that mixin's override the bytecode at run-time, so retrieval and injection of this (probably through ASM) would need to be done before the bytecode interpreter starts and has to hold it until the original injection is finished. This might take me a few weeks to even start working on, after I get finished a mod I'm currently working on, but I might try implementing this if you are fine with it.

Another good idea to investigate is this guy's APIs or a concept of them

Now that I think about it, a Mixin system would be better for Quantum API extensions and mixed mods, and for Minecraft injection. I think I've also decided that mods should not be able to change how minecraft works, only extensions. This will eliminate variability between mods since they'll only worry about the API.

I've also decided that extensions will only be allowed to create mixins and classes that add content or implementation to minecraft. If I were to make minecraft more OOP by creating interfaces for crucial parts of minecraft (such as rendering, worlds, settings, etc.), instead of injecting modifications, you can write your own implementations! This would be a very large refactoring of minecraft though, and I worry how long that would take at startup. The best I can do is create a concurrent injector to halve the time it takes or more depending on how many cores a system has to work with. Luckily, I can implement the interfaces and just add those to the classpath, then change every method in minecraft as needed.

hey, Spartan322, would you like to join the team? Also, if you are going to implement anything for the API, use what the API uses. Use javassist instead of ASM. It's much more lightweight and easier to use.

How would this appeal to minecraft server software that it can be the replacement for Bukkit? Implementing Quantum API will be harder then let's say Bukkit, TridentSDK, or Sponge API. Although, this would be good for the client-side community; I don't think this will a sufficient replacement against Bukkit. Here are some advantages and disadvantages I see in this API for server-side software:

Advantages:

• Backwards compatibility with a older implementation of the API.
• More functionality by wrapping all of Minecraft.

Disadvantages:

• Extremely harder to create implementations than Bukkit, TridentSDK, or etc.
• Possibly may not be thread-safe in multi-threaded server software.

I wouldn't mind joining the team, but I'd like to try and get a gradle versions up before any other work I'd be doing (which I'll work on after Christmas probably). Also It would be nice if mods could change Minecraft behavior more responsibly, you can't really block people from changing it, but you can try to make it less wild and more responsible. I have a few ideas on this, I'll test out a few ideas for Mixins after I get a Gradle implementation finished.

Also, how do you plan on handling Minecraft patching? (It be more efficient to do it like Forge, and in the end, people would be able to see the changes we made much easier)

You know, if this becomes a big thing, someday we will all look back at the first few pages of comments on this thread and laugh.

EDIT: This was really off-topic, if you didn't like this comment please go ahead and ignore it.

Quote from Swatcommader6»

How would this appeal to minecraft server software that it can be the replacement for Bukkit? Implementing Quantum API will be harder then let's say Bukkit, TridentSDK, or Sponge API. Although, this would be good for the client-side community; I don't think this will a sufficient replacement against Bukkit. Here are some advantages and disadvantages I see in this API for server-side software:

Advantages:

• Backwards compatibility with a older implementation of the API.
• More functionality by wrapping all of Minecraft.

Disadvantages:

1. Extremely harder to create implementations than Bukkit, TridentSDK, or etc.
2. Possibly may not be thread-safe in multi-threaded server software.

Because of the way I choose to implement Quantum API , it is actually very easy to create implementations. I use wrapper objects as synthetic accessors to minecraft objects, so that if an implementation changes, I can implement it in the wrapper and everything will work again.

you know there will be a server side implementation right? I wouldn't implement something to make it not suitable for threading. It's in my mind and I will make all of my API thread-safe, but right now it isn't much of a concern.

Quote from Spartan322»

I wouldn't mind joining the team, but I'd like to try and get a gradle versions up before any other work I'd be doing (which I'll work on after Christmas probably). Also It would be nice if mods could change Minecraft behavior more responsibly, you can't really block people from changing it, but you can try to make it less wild and more responsible. I have a few ideas on this, I'll test out a few ideas for Mixins after I get a Gradle implementation finished.

Also, how do you plan on handling Minecraft patching? (It be more efficient to do it like Forge, and in the end, people would be able to see the changes we made much easier)

Great, you're on the team. Welcome!

I'll give you your first task, but you should join wuantumapi.slack.com so we can communicate in the team. Your first task will be gradle.

yes, I realize sadly that mods will have to change minecraft code sometimes to make it work for their mod. My problem is "how do you merge two methods?" Well first of all it's really easy if you lay it out in steps:

1. If return object parameters not changed, optimize the code and insert it in lexicographical order.
2. Else , get the lines of code for each parameter and put in List.
3. For each element in list, create a single variable for both methods to manipulate, and pass that variable as one of the parameters to the return object.
4. continue in this manner recursively with each method of the same type until they all manipulate only one variable at a time instead of their own local variable.

Example:

MyObject fooMethodChanger1() {

//common code

MyObject bar1;

doSomething(bar1.foo);

doSomethingElse(bar1.foobar);

//end common

// changed

customDo1(bar1.baz);

return new MyObject(bar1.foo, bar1.foobar, bar1.baz);

}

MyObject fooMethodChanger2() {

//common code

MyObject bar1;

doSomething(bar1.foo);

doSomethingElse(bar1.foobar);

//end common

// changed

customDo2(bar1.baz);

return new MyObject(bar1.foo, bar1.foobar, bar1.baz);

}

MyObject resolvedFooMethod() {

//common code

MyObject bar1;

doSomething(bar1.foo);

doSomethingElse(bar1.foobar);

//end common

// changed

Object argBaz = bar1.baz;

customDo1(argBaz);

customDo2(argBaz);

return new MyObject(bar1.foo, bar1.foobar, argBaz);

}

Hopefully this example cleared up my patching idea. Applying the patched methods is a matter of creating a list of CtClasses, names of methods to change, and then replace the changed methods in the CtClass.

Quote from ElitaTrademark»

You know, if this becomes a big thing, someday we will all look back at the first few pages of comments on this thread and laugh.

EDIT: This was really off-topic, if you didn't like this comment please go ahead and ignore it

Don't forget the 50% mark on the poll up there XD

I would be sure Mixins could handle 99% of cases like that (and in fact solve over 80% of that problem anyway). But what I mean with patches is do you want to patch minceraft like Forge does (use java.patch files and such). I can't access the slack, you need to invite me by email (you also put a 'w' instead of a 'q' for the domain of the slack)

Quote from Spartan322»

I would be sure Mixins could handle 99% of cases like that (and in fact solve over 80% of that problem anyway). But what I mean with patches is do you want to patch minceraft like Forge does (use java.patch files and such). I can't access the slack, you need to invite me by email (you also put a 'w' instead of a 'q' for the domain of the slack)

For patches, I don't want to use *.java.patch files. I was thinking a more generic approach, possibly allowing applicability outside of quantum regarding patches. I would prefer to make a DSL for patching things into and out of Java. With it, you wouldn't necessarily have to specify Java code or Java source code to patch into a system. You could code a class representation and compile it to bytecode, then inject it either permanently or at runtime. Of course, the ability to convert Java source to the DSL would be a feature. A Gradle interface would also be great, that way you can use this with gradle as a task to apply at build time.

Oh btw I invited you to quantumapi.slack.com, check your email. I'll be adding you to quantum_dev.

Well, if we don't want to replace the minecraft jar file (cause that is the only reason not to use java patch files) then how do we report the change files at compile time (cause an IDE like eclipse can only see compile-time stuff, modifying in runtime is going to trick the mod dev and might even blow his code up)? We need to come up with a way to inject a modified mc jar for development while keeping it completely ambiguous to the real jar when installed (i have idea on how, but it can easily break and burn, it would not be very safe)

Sent a pull request dealing with annotations (meta) and a concurrency handler.

Just thought I'd let you know, since I'm counting myself as part of the team, (I'm the sign guy who spins the sign out side, but more like this ) I'd send a guy your way, he's been programming physics, multiworlds, vehicles, and aerodynamics, into minecraft for a few months now. If he's up to it, he could be a big help to your team, he's a bit of a java god if you ask me. And to all those who keep saying things like, Good luck, I know you're going to fail but good luck! Oh ye of little faith, have you not seen the works of the small devs? Are not many of great wonders? Have many not prospered? I tell you today, if a man is wanting to make a new api, and he does so with his whole heart, and with his whole strength, and puts his mind to it, he will do just so.

What we really need are devs who know Gradle and people who can follow contribution guidelines, and hopefully documents their code. If he knows the JVM really well, then he'd be a great help too

Just committed everything I did this month to GitHub.

give me your email to add you to quantumapi.slack.com spynathan.

And after a few days, I'm officially out of this project because "encapsulation" is an excuse to prevent true modding. Goodbye.

Quote from Spartan322»

And after a few days, I'm officially out of this project because "encapsulation" is an excuse to prevent true modding. Goodbye.

Oook?

Quote from link_the_programmer»

Just committed everything I did this month to GitHub.

give me your email to add you to quantumapi.slack.com spynathan.

I sent it in a pm.

Quote from Spartan322»

And after a few days, I'm officially out of this project because "encapsulation" is an excuse to prevent true modding. Goodbye.

Encapsulation does not prevent "true modding" or coding, it simplifies and enhances it. You still act like encapsulation limits the programmer's ability and adds bloat to the program. What encapsulation really is is OOP and makes it easier to extend the capabilities of a program by letting you yourself define the object, and then the API doesn't worry about which object implementation is passed to it by the modder.

Quote from spynathan»

I sent it in a pm.

Alrighty.

A Second Project

I just want to add, I'm working on a different side project as well, which will not affect development of this API. In fact, it will enhance it, as it will most likely be used in the Quantum API to replace the corresponding minecraft system (GUIs). It uses some of Apache Commons and will use Guava as well, and will be GWT compatible.

The GUI project I'm working on is simply called jGUI, not to be confused with jGui. It provides an easy solution to create, show, and draw, to a display (window). Everything uses the Display interface and you can easily choose a Display implementation to use with the Displays class. Currently, I only support GLFWDisplay s, AWT- and SwingDisplay implementations will come later.

Each display is capable of drawing an Image object, whether it be 2D or 3D. It is up to the display implementation to provide a compatible image implementation as well.

More information to come.

Update

As for Quantum API, I've been working on getting mod loading working, as well as how mods can modify minecraft. I've decided that modders will use Javassist themselves to modify a CtClass implementations at startup. This is done through a special interface that you implement to modify the class, and then the mod loader takes a List of these interfaces and iterates over them for each type of class (which is done by putting the interfaces in UniversalAgents and iterating over the UniversalAgents). Currently working on adding the mod running functionality by calling a method in QuantumAPI (which used to be RuntimeInfo) that starts each QuantumMod object.

After I get this functionality working, I will test everything I currently have in the API, and then continue developing the API .