Third party mods are just mods made for other environments (Forge, Sponge, Bukkit, etc.)
Quantum Extensions are extensions to the API and are not restricted to just 3rd party vendor support, though the primary usage will be modloaders for 3rd party vendors. They may, however, be something that makes Quantum more useful, or exposes some part of Vanilla Minecraft.
Good news everyone! I'm in E-Learning at my school, so instead of being done in May, I'll be done before the end of October! That means full-time programming! No road blocks!
Quantum API Beta 1.0
-API - complete*
-Wrapper - almost finished
-need to complete custom model loading
-need to complete obfuscation mappings
-need to complete jCLA (Java Class Assistant)
-need to complete jCDIO-PKZIP (Java Common Data I/O library - Zip archive components)
*not fully tested
Currently, with jCLA, I'm working on a few quirks, and then I have the compiler and decompiler which, contrary to what might be popular belief, will not take long. After that, I'll complete the obfuscation mappings, and then I'll be on my way to finishing the Wrapper.
As you can see, I need to complete custom model loading. That is basically it for Beta 1.0 according to the schedule I posted a while back. You can expect the schedule to be quite consistent with the features presented. I will be presenting things in the order of the schedule so that I can get plenty of feedback. You are mod developers, so by all means, tell me what Quantum lacks and I'll implement it (or you could just submit a PR)!
The first thing I'll need during Beta when implementing Events is a list of all Events that are currently used by developers, and what other Events you, the modding community, need. There'll be no more "coremods" like you made with Forge! From now on, I'm putting in everything you'll need so that you won't need to resort to Forge based on whether or not you need to change minecraft to make your mod work! I'll be setting up a separate forum for feature requests as well for Quantum API.
As mentioned above, there'll be no "coremods", and there'll be no equivalent thereof! Quantum API is meant to do things in a systematic way. As of right now, I have the idea of implementing basic "hook" functionality. Everything must be delegated to Quantum, and that is what makes this API different from Forge. You don't need to make a PR that hooks into Minecraft, you'll only need to write some code in a Runnable, and how mods use that and hook into certain areas of Minecraft systematically while maintaining backwards compatibility with Minecraft across any number of versions will be determined later.
Hooks, however, are the farthest extent that a mod can go, beyond re-implementing a certain Minecraft game element's representative interface, that allows you to "modify" Minecraft through Quantum without writing any hook-implementing code at all. You, like I said, will have functionality as simple as registering a Runnable during initialization of the mod. The only configurable part is where you place the code in the Runnable: the beginning or end of a method.
Your link to the improved post just redirects me to peerprofile.com and requires me to create an account. Also the website shown on the Github repo (here) doesn't work.
I have yet to update the forum post which is why that link isn't updated, any apparently the website (votable.com) doesn't exist, so there is no updated article anymore.
The website I haven't touched since the beginning of this project. I'll get that thing working for beta at some point though.
jCLA’s Compiler is coming along. The easy part, lexical analysis, is done. The longer part, turning a stream of arbitrary tokens into bytecode, is another story which is in progress. Once the compiler is built, the decompiler is simply the inverse process which means I’ll be done with jCLA after the compiler is finished.
Due to some unforeseen events, and because of my current pace, I may not get out of school until the actual deadline which is December 2nd. In the meantime, however, much productivity has been possible, as a result of said events, with jCLA. It is no one’s concern.
I would like to reiterate the purpose and intent of what I am doing exactly. I need jCLA to modify class files at runtime the same way that Javassist does, but without quirks. It is also necessary in order to generate source code for the correct version of Minecraft.
I need jCLA specifically for the purpose of generating source code for Quantum’s Wrapper. Because each version of Minecraft is different in terms of obfuscation, I need mappings for each target version of Minecraft in order to release Quantum for that version of Minecraft. The only way I am able to test Quantum at all right now is because I have MCP’s deobfuscated and decompiled source code for Minecraft. Because of these release complications, I have to make a custom build solution utilizing jCLA that generates Quantum Wrapper source code for the Minecraft version of my choice from the correct obfuscation mappings for that version, and MCP has an online repository of these mappings at http://export.mcpbot.bspk.rs/. I can configure the build solution to run from a CLI that can auto-download the correct mappings for the version of Minecraft I want to build Quantum for, and that generates source code which is then compiled into the JAR file (or JMOD Java 9 module) that I can release to the general public online.
Since my last post, plenty has happened. I won't go into details as that doesn't matter right now, and so far my circumstances have allowed considerable progress towards getting Quantum API released.
I have some design goals that I'd like to add, or rather, one design goal: modifications to the Minecraft base code.
As you might know, from the beginning I planned on making Quantum API something that never allows mods to step on each other even in the midst of conflict. It also got me thinking about how limiting that would be, and all the possibilities I want for mods that I want to make with Quantum. For example, what if I wanted to change Minecraft's build system entirely? That wouldn't be possible with the previous paradigm for Quantum.
In this paradigm, we will have two different kinds of mods: Plugin Mods, and Thematic Mods.
Plugin Mods are mods that modify Minecraft without changing the essence of what Minecraft is. These mods do not change the canon of the game, such as game mechanics like crafting or building.
Thematic Mods are mods that modify Minecraft that change what the essence of Minecraft is. These mods do change the canon of the game, such as game mechanics like crafting or building.
Now, an elaboration. The plugin mods are the most common mods available; most mods don't require fundamentally breaking Minecraft. The distinction here is important because that means that Plugin mods will never conflict with other Plugin mods or Thematic mods, but Thematic mods always have the potential of conflicting with other Plugin mods or Thematic mods.
I still will not allow the ability to modify Minecraft base files directly. Instead, I will create an intermediate representation of Minecraft; a virtual Minecraft Engine that mimics the real Minecraft engine that you can modify or implement as necessary to achieve a desired game-changing experience with Thematic mods. Here, I'll give an example:
I want to make a mod that makes Crafting in Minecraft more realistic. Instead of using items put in a template in a crafting bench to make items, I'm going to modify the existing crafting system to require all your raw materials be put into a slot, and you have to use the correct tools to shape and model the object you are making with your mouse as a cursor. In order to do this, I would simply modify the crafting behavior in the intermediate representation of Minecraft.
When it is time to run the mod, the version of Quantum that the mod is running on will automatically resolve the version-specific discrepancies and insert the code into the Minecraft JAR file for you at runtime. You could also have the option to generate a new Minecraft version with the given modifications to create a dedicated Minecraft JAR file.
The Intermediate Representation
For developers, the Intermediate Representation will be an actual Minecraft Engine API that is very abstract. It will mostly consist of abstract classes such as interfaces (and abstract classes) rather than concrete classes. To modify a part of the Minecraft Engine, you would simply implement the appropriate interface and corresponding method(s).
This IR will expose Minecraft's Engine in a cross-version manner. This preserves the backwards compatibility aspect, as well as makes the systematic modification of Minecraft possible. This will be a large improvement over Forge coremod functionality and directly editing Minecraft class files at runtime.
At runtime, the Quantum Wrapper distribution for the version of Minecraft will have it's own mappings for the IR. As Quantum currently is, Quantum currently has three tiers, beginning from the top: Quantum API <- Quantum Wrapper <- Minecraft. When the IR is introduced, the Wrapper will be discarded and replaced with the IR. I will most likely keep the name of Quantum Wrapper, but will clarify that it is an IR of Minecraft's Engine. It will expose every feature of the Minecraft Engine, including rendering, as well as technical details such as the internal chunk server, so porting Optifine to Quantum (or not, you won't have to since it works with Forge) will now be a possibility, but I wouldn't waste your time with making mods that optimize Minecraft as I will be doing that part myself with the IR. I plan on doing a lot of optimizing with just the basic Quantum environment because there is so much to optimize in Minecraft, and it has so much potential for being faster. Any increased overhead is not a problem because JIT will just inline the method calls that are delegated.
Finally finished with school, I will from now on be working on Quantum API full time until I go to seminary (no idea when that will be).
Im still working on the compiler for JCLA, but it will not take much longer thankfully because my solution is a simple Trie for storing Productions and using that to identify Productions during parsing. (It’s the same structure used for auto-correct on your phone).
These Production objects will then be passed to the compiler for conversion to some form of bytecode, converted to a ClassFile, and from there, it’s up to the programmer to do something with the generated class. You could convert the ClassFile to a ClassDefinition to use metadata about the class, or make a ClassBuilder, modify the class, and make a new ClassFile; write the ClassFile to disk; send the ClassFile remotely; or load it directly into the current JVM instance.
For the 10th time (I know, sorry): the purpose of JCLA is to allow me to create a build solution for Quantum that actually works, and I also need a way to compile arbitrary tokens on the fly to bytecode both at initialization and run-time for QAMCL.
When I used Javassist in the past, it wasn’t consistent for insertion of bytecode by compiling a single line of Java, or even a method body, to bytecode at runtime, and this was a problem. I could have made a big request, and this might be fixed by now, but it’s too late to just abandon JCLA which has become, in my opinion, far better than what is out there in terms of simplicity and versatility.
Been following this project for over a year now. and looking at it occasionally (OG account is saby232323 :p) Excited to see the project is back alive.
Been following this project for over a year now. and looking at it occasionally (OG account is saby232323 :p) Excited to see the project is back alive.
I am very happy to see this project back alive again. I did not expect to see this project still alive even after all these years. I have been watching this project for 3 or so years.
I am very happy to see this project back alive again. I did not expect to see this project still alive even after all these years. I have been watching this project for 3 or so years.
I can assure you, this project will either never complete because I died, or because I became too busy with my business. Other than that, I see no reason to give this up, especially since it is potentially another income stream for me.
By the way, your diagram needs a bit of tweaking:
Quantum Mods | Third Party API mods
----------------------------------------------------
Quantum | Quantum Extensions for 3rd party vendors
----------------------------------------------------
Vanilla Minecraft
Third party mods are just mods made for other environments (Forge, Sponge, Bukkit, etc.)
Quantum Extensions are extensions to the API and are not restricted to just 3rd party vendor support, though the primary usage will be modloaders for 3rd party vendors. They may, however, be something that makes Quantum more useful, or exposes some part of Vanilla Minecraft.
Status Update
Good news everyone! I'm in E-Learning at my school, so instead of being done in May, I'll be done before the end of October! That means full-time programming! No road blocks!
Quantum API Beta 1.0
-API - complete*
-Wrapper - almost finished
-need to complete custom model loading
-need to complete obfuscation mappings
-need to complete jCLA (Java Class Assistant)
-need to complete jCDIO-PKZIP (Java Common Data I/O library - Zip archive components)*not fully tested
Currently, with jCLA, I'm working on a few quirks, and then I have the compiler and decompiler which, contrary to what might be popular belief, will not take long. After that, I'll complete the obfuscation mappings, and then I'll be on my way to finishing the Wrapper.
As you can see, I need to complete custom model loading. That is basically it for Beta 1.0 according to the schedule I posted a while back. You can expect the schedule to be quite consistent with the features presented. I will be presenting things in the order of the schedule so that I can get plenty of feedback. You are mod developers, so by all means, tell me what Quantum lacks and I'll implement it (or you could just submit a PR)!
The first thing I'll need during Beta when implementing Events is a list of all Events that are currently used by developers, and what other Events you, the modding community, need. There'll be no more "coremods" like you made with Forge! From now on, I'm putting in everything you'll need so that you won't need to resort to Forge based on whether or not you need to change minecraft to make your mod work! I'll be setting up a separate forum for feature requests as well for Quantum API.
As mentioned above, there'll be no "coremods", and there'll be no equivalent thereof! Quantum API is meant to do things in a systematic way. As of right now, I have the idea of implementing basic "hook" functionality. Everything must be delegated to Quantum, and that is what makes this API different from Forge. You don't need to make a PR that hooks into Minecraft, you'll only need to write some code in a Runnable, and how mods use that and hook into certain areas of Minecraft systematically while maintaining backwards compatibility with Minecraft across any number of versions will be determined later.
Hooks, however, are the farthest extent that a mod can go, beyond re-implementing a certain Minecraft game element's representative interface, that allows you to "modify" Minecraft through Quantum without writing any hook-implementing code at all. You, like I said, will have functionality as simple as registering a Runnable during initialization of the mod. The only configurable part is where you place the code in the Runnable: the beginning or end of a method.
Until next time!
I have yet to update the forum post which is why that link isn't updated, any apparently the website (votable.com) doesn't exist, so there is no updated article anymore.
The website I haven't touched since the beginning of this project. I'll get that thing working for beta at some point though.
Updates:
jCLA’s Compiler is coming along. The easy part, lexical analysis, is done. The longer part, turning a stream of arbitrary tokens into bytecode, is another story which is in progress. Once the compiler is built, the decompiler is simply the inverse process which means I’ll be done with jCLA after the compiler is finished.
Due to some unforeseen events, and because of my current pace, I may not get out of school until the actual deadline which is December 2nd. In the meantime, however, much productivity has been possible, as a result of said events, with jCLA. It is no one’s concern.
I would like to reiterate the purpose and intent of what I am doing exactly. I need jCLA to modify class files at runtime the same way that Javassist does, but without quirks. It is also necessary in order to generate source code for the correct version of Minecraft.
I need jCLA specifically for the purpose of generating source code for Quantum’s Wrapper. Because each version of Minecraft is different in terms of obfuscation, I need mappings for each target version of Minecraft in order to release Quantum for that version of Minecraft. The only way I am able to test Quantum at all right now is because I have MCP’s deobfuscated and decompiled source code for Minecraft. Because of these release complications, I have to make a custom build solution utilizing jCLA that generates Quantum Wrapper source code for the Minecraft version of my choice from the correct obfuscation mappings for that version, and MCP has an online repository of these mappings at http://export.mcpbot.bspk.rs/. I can configure the build solution to run from a CLI that can auto-download the correct mappings for the version of Minecraft I want to build Quantum for, and that generates source code which is then compiled into the JAR file (or JMOD Java 9 module) that I can release to the general public online.
Since my last post, plenty has happened. I won't go into details as that doesn't matter right now, and so far my circumstances have allowed considerable progress towards getting Quantum API released.
I have some design goals that I'd like to add, or rather, one design goal: modifications to the Minecraft base code.
As you might know, from the beginning I planned on making Quantum API something that never allows mods to step on each other even in the midst of conflict. It also got me thinking about how limiting that would be, and all the possibilities I want for mods that I want to make with Quantum. For example, what if I wanted to change Minecraft's build system entirely? That wouldn't be possible with the previous paradigm for Quantum.
In this paradigm, we will have two different kinds of mods: Plugin Mods, and Thematic Mods.
Plugin Mods are mods that modify Minecraft without changing the essence of what Minecraft is. These mods do not change the canon of the game, such as game mechanics like crafting or building.
Thematic Mods are mods that modify Minecraft that change what the essence of Minecraft is. These mods do change the canon of the game, such as game mechanics like crafting or building.
Now, an elaboration. The plugin mods are the most common mods available; most mods don't require fundamentally breaking Minecraft. The distinction here is important because that means that Plugin mods will never conflict with other Plugin mods or Thematic mods, but Thematic mods always have the potential of conflicting with other Plugin mods or Thematic mods.
I still will not allow the ability to modify Minecraft base files directly. Instead, I will create an intermediate representation of Minecraft; a virtual Minecraft Engine that mimics the real Minecraft engine that you can modify or implement as necessary to achieve a desired game-changing experience with Thematic mods. Here, I'll give an example:
I want to make a mod that makes Crafting in Minecraft more realistic. Instead of using items put in a template in a crafting bench to make items, I'm going to modify the existing crafting system to require all your raw materials be put into a slot, and you have to use the correct tools to shape and model the object you are making with your mouse as a cursor. In order to do this, I would simply modify the crafting behavior in the intermediate representation of Minecraft.
When it is time to run the mod, the version of Quantum that the mod is running on will automatically resolve the version-specific discrepancies and insert the code into the Minecraft JAR file for you at runtime. You could also have the option to generate a new Minecraft version with the given modifications to create a dedicated Minecraft JAR file.
The Intermediate Representation
For developers, the Intermediate Representation will be an actual Minecraft Engine API that is very abstract. It will mostly consist of abstract classes such as interfaces (and abstract classes) rather than concrete classes. To modify a part of the Minecraft Engine, you would simply implement the appropriate interface and corresponding method(s).
This IR will expose Minecraft's Engine in a cross-version manner. This preserves the backwards compatibility aspect, as well as makes the systematic modification of Minecraft possible. This will be a large improvement over Forge coremod functionality and directly editing Minecraft class files at runtime.
At runtime, the Quantum Wrapper distribution for the version of Minecraft will have it's own mappings for the IR. As Quantum currently is, Quantum currently has three tiers, beginning from the top: Quantum API <- Quantum Wrapper <- Minecraft. When the IR is introduced, the Wrapper will be discarded and replaced with the IR. I will most likely keep the name of Quantum Wrapper, but will clarify that it is an IR of Minecraft's Engine. It will expose every feature of the Minecraft Engine, including rendering, as well as technical details such as the internal chunk server, so porting Optifine to Quantum (or not, you won't have to since it works with Forge) will now be a possibility, but I wouldn't waste your time with making mods that optimize Minecraft as I will be doing that part myself with the IR. I plan on doing a lot of optimizing with just the basic Quantum environment because there is so much to optimize in Minecraft, and it has so much potential for being faster. Any increased overhead is not a problem because JIT will just inline the method calls that are delegated.
That's all for now!
Finally finished with school, I will from now on be working on Quantum API full time until I go to seminary (no idea when that will be).
Im still working on the compiler for JCLA, but it will not take much longer thankfully because my solution is a simple Trie for storing Productions and using that to identify Productions during parsing. (It’s the same structure used for auto-correct on your phone).
These Production objects will then be passed to the compiler for conversion to some form of bytecode, converted to a ClassFile, and from there, it’s up to the programmer to do something with the generated class. You could convert the ClassFile to a ClassDefinition to use metadata about the class, or make a ClassBuilder, modify the class, and make a new ClassFile; write the ClassFile to disk; send the ClassFile remotely; or load it directly into the current JVM instance.
For the 10th time (I know, sorry): the purpose of JCLA is to allow me to create a build solution for Quantum that actually works, and I also need a way to compile arbitrary tokens on the fly to bytecode both at initialization and run-time for QAMCL.
When I used Javassist in the past, it wasn’t consistent for insertion of bytecode by compiling a single line of Java, or even a method body, to bytecode at runtime, and this was a problem. I could have made a big request, and this might be fixed by now, but it’s too late to just abandon JCLA which has become, in my opinion, far better than what is out there in terms of simplicity and versatility.
It certainly is more than what I expected, but nonetheless, it is now a quality library for bytecode modification. See https://stackoverflow.com/a/45891652/2950711
In case anyone didn't notice: the project still won't die.
Been following this project for over a year now. and looking at it occasionally (OG account is saby232323 :p) Excited to see the project is back alive.
I share your enthusiasm
I am very happy to see this project back alive again. I did not expect to see this project still alive even after all these years. I have been watching this project for 3 or so years.
I can assure you, this project will either never complete because I died, or because I became too busy with my business. Other than that, I see no reason to give this up, especially since it is potentially another income stream for me.
Hello everyone, please see the update I left in the spoiler. If anyone has questions, my email is [email protected], or you can reply to this thread.