So, interesting approach to solving backwards compatibility on account of obfuscation changes, but this doesn't solve the entire problem. You've accounted for changes to obfuscation, which is fine, but you've merely moved the problem of code changes up the pipe and haven't actually fixed it.
From what I understand you plan on creating a system where to access Minecraft's objects, you go through your own objects which basically means only your API / MPI deals with changes to obfuscation, the actual mods using it aren't affected. Unlike Forge where it acts as framing around Minecraft's source code to allow mods to work with it better without actually directly working with it (Forge handles the things that would normally require base edits through hooks and such), you've actually made an entire new project which acts as an interfacing container surrounding Minecraft; instead of mods working with both your API / MPI and the source code of the game, mods just use your API / MPI to access the source code meaning they've been protected from changes to the code (somewhat, as I'm about to get into). While this (may or may not) solves the problem of obfuscation, what about if Mojang changes some of the code? For instance, think of if your API was functional during 1.7.10 then had to update to 1.8.
Your API basically exposes the rendering methods and code in Minecraft for mods to use, but it doesn't abstract it enough for backwards compatibility to work perfectly. You've basically just drilled a hole through a piece of metal and called it an interface. Any changes to the rendering code would mean you would have to rewrite how your API deals with rendering, which means mods would also have to change to follow suit, ultimately meaning 1.8 mods will not work for 1.7.10 because of the fact that the two use completely different techniques and functions for rendering; you've (maybe) solved obfuscation, but have just moved the problem of changes to the code up the pipe to the same spot Forge is at, even though Forge absorbs the bulk of the damage, mods still get a fairly substantial blast on account of the changes to the way Forge works with rendering, your API is in exactly the same place.
I'm intrigued and interested to see how your idea for tackling obfuscation works, though it appears as if you've pretty much just added padding for mods, you still internally have to deal with obfuscation changes (think of it like this, to my understanding your API works like this: mod -> BlockWrapper -> internal block object mapping to Minecraft's -> Block (Minecraft), if Block is obfuscated as axy under 1.7.10 and hgy under 1.8, you still have to reobfuscate your API to match but it means mods won't deal with it because your API acts as padding absorbing the damage). However you haven't sold me on the idea of fully perfect backwards compatibility, because you've only solved one problem out of two.
You've basically summed up what half of my API does: make an abstraction layer to account for obfuscation.
The other half you missed, you basically summed up as saying what my API will not do.
There are very fundamental things you have to do for certain things to do what they do. For instance, your problem you presented me with: a complete refactoring of the rendering system in minecraft.
What is the most basic thing you need to render an OpenGl standardized model? ...? ... ok I'll tell you. It's really easy. Get a load of this: rasterize the points onto a 2D plane and apply that wire mesh with texture(s). If for some reason the rendering system were to change to, oh I don't know, the world would be refactored to use only a single 3D plane to represent the World and the actual 3D screen location, rather than two 3D planes, one as perhaps a "box" that extends infinitely* in the z axis and one plane to represent the actual World. Say I have a previous method of render(Model, x1, y1, z1, x2, y2, z2) where the first coordinates represent the World location, and that changes to render(Model, x, y, z), but my abstracted method is render(ModelWrapper, x1, y1, z1, x2, y2, z2), I would change the contents of that method to render(modelWrapper, x1, y1, z1) and I would add a method called render(ModelWrapper, x, y, z) and deprecate the other method.
Just because you change an equation fundamentally to do the same thing it did before (just in a hopefully better way) doesn't mean you can't make the old one compatible with the new because you rearranged your variables, or compressed the function, etc.
Hmm, this is strange, the thread text is being sent in English but is being rendered as Greek (as in, the html doc and the clipboard reports it as English, but its rendered otherwise, btw only the first post, I've checked other threads, though not the stylesheet, very odd)
Edit: 3 days later, problem hasn't changed
Interesting, I'll just copy and paste everything as plain text into a document. I believe the problem is I set the font to "symbol" and I liked how smooth the text looks compared to others, so I'll probably change it to Times New Roman and see what happens.
I didn't understand half of what you said in your post, but I love it! So to see what exactly you mean in simpleton language, lets say I'm playing 1.8, and I want the portal gun mod. But it's not updated for 1.8 yet. So theoretically, I put this fancy API on here and it'll update the mod to 1.8?
Maybe you should also put in a basic overview of what this does in English for us non-devs.
Theoretically, yes you could, when I get Forge mods actually loading, and when I get legacy Forge compatibility and make it an actual thing.
Formatting still broken, but the post is much more clean so it'll be easier to know what is what and where. Changed to "helvetica" font family. It would appear this is a site glitch? and might I add it seems like every word I type is lagging because it's putting in bbcode for the document in the background on the fly? I shouldn't be getting this problem... really...
You've basically summed up what half of my API does: make an abstraction layer to account for obfuscation.
The other half you missed, you basically summed up as saying what my API will not do.
There are very fundamental things you have to do for certain things to do what they do. For instance, your problem you presented me with: a complete refactoring of the rendering system in minecraft.
What is the most basic thing you need to render an OpenGl standardized model? ...? ... ok I'll tell you. It's really easy. Get a load of this: rasterize the points onto a 2D plane and apply that wire mesh with texture(s). If for some reason the rendering system were to change to, oh I don't know, the world would be refactored to use only a single 3D plane to represent the World and the actual 3D screen location, rather than two 3D planes, one as perhaps a "box" that extends infinitely* in the z axis and one plane to represent the actual World. Say I have a previous method of render(Model, x1, y1, z1, x2, y2, z2) where the first coordinates represent the World location, and that changes to render(Model, x, y, z), but my abstracted method is render(ModelWrapper, x1, y1, z1, x2, y2, z2), I would change the contents of that method to render(modelWrapper, x1, y1, z1) and I would add a method called render(ModelWrapper, x, y, z) and deprecate the other method.
Just because you change an equation fundamentally to do the same thing it did before (just in a hopefully better way) doesn't mean you can't make the old one compatible with the new because you rearranged your variables, or compressed the function, etc.
Except that's not what Mojang has done for redoing rendering. Prior to 1.8 you used to have IItemRenderer and ISimpleBlockRenderingHandler (ISBRH I believe was part of Forge, IItemRenderer may have been part of Forge too) and you could write some OpenGL code to render the model like how you described, instead using the old model system (where models were collections of cuboids). 1.8 changed this to instead make models use JSON files which eliminates dynamic rendering (having code render and piece together the model versus storing variants of a model, for a pipe for instance), which killed IItemRenderer and ISimpleBlockRenderingHandler. Buildcraft used code to condense pipes down to be as efficient as possible at the time; when you call the render method in the model class you would pass some values through and based on those values individual model components would or would not be rendered, everything was handled in-code, versus with the JSON system where there is literally no way to even port models over because there would be too many model variants for the system to handle (apparently there's a maximum of 65536 total models that can be registered, Buildcraft requires at least a hundred thousand considering factoring in pipe type, side connections, pipe wire x3 (red, green and blue pipe wire), facades for every registered block, pipe gates, etc, every single one of these has to be considered, and every variant has to be written in it's own unique JSON file, there's not enough "slots" to even fit a portion of the models required for Buildcraft, the alpha had to "hack" the old method back in).
If your mod is for 1.7.10, won't work, no matter if technically speaking both 1.7.10 and 1.8 do the same thing at the end of the day. Your 1.7.10 mod works completely differently to how 1.8 works; it'd be like saying that you can translate an Arabic essay to English perfectly because at the end of the day all languages do is convey meaning. Not possible. 1.7.10 works one way, 1.8 works another, you can't have a mod work for both 1.7.10 and 1.8 unless you abstract it to the point of having the API deal with this internally and mods use your own unique method of dealing with rendering, which your API does not do.
Mojang didn't rearrange variables or compress functions, they deleted the old code and rewrote new code that works entirely differently. No way to maintain compatibility across both with the way your API works currently.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
Except that's not what Mojang has done for redoing rendering. Prior to 1.8 you used to have IItemRenderer and ISimpleBlockRenderingHandler (ISBRH I believe was part of Forge, IItemRenderer may have been part of Forge too) and you could write some OpenGL code to render the model like how you described, instead using the old model system (where models were collections of cuboids). 1.8 changed this to instead make models use JSON files which eliminates dynamic rendering (having code render and piece together the model versus storing variants of a model, for a pipe for instance), which killed IItemRenderer and ISimpleBlockRenderingHandler. Buildcraft used code to condense pipes down to be as efficient as possible at the time; when you call the render method in the model class you would pass some values through and based on those values individual model components would or would not be rendered, everything was handled in-code, versus with the JSON system where there is literally no way to even port models over because there would be too many model variants for the system to handle (apparently there's a maximum of 65536 total models that can be registered, Buildcraft requires at least a hundred thousand considering factoring in pipe type, side connections, pipe wire x3 (red, green and blue pipe wire), facades for every registered block, pipe gates, etc, every single one of these has to be considered, and every variant has to be written in it's own unique JSON file, there's not enough "slots" to even fit a portion of the models required for Buildcraft, the alpha had to "hack" the old method back in).
If your mod is for 1.7.10, won't work, no matter if technically speaking both 1.7.10 and 1.8 do the same thing at the end of the day. Your 1.7.10 mod works completely differently to how 1.8 works; it'd be like saying that you can translate an Arabic essay to English perfectly because at the end of the day all languages do is convey meaning. Not possible. 1.7.10 works one way, 1.8 works another, you can't have a mod work for both 1.7.10 and 1.8 unless you abstract it to the point of having the API deal with this internally and mods use your own unique method of dealing with rendering, which your API does not do.
Mojang didn't rearrange variables or compress functions, they deleted the old code and rewrote new code that works entirely differently. No way to maintain compatibility across both with the way your API works currently.
Oh so that's the major change eh? is it really that hard to make a simple converter for this? A way to recursively send all your objects through a converter that generates JSON files? This is besides the point, but just saying.
You act like my API is very limited. You do realize I am the sole creator of this API, and I can do whatever I want with it? Making an abstract layer means defining, internally, a stable backend to make the frontend work, especially in this case. The goal isn't to solve obfuscation, it's to solve backwards compatibility; you are thinking too narrowly in terms of backwards compatibility.
For the modeling problem presented with the change from 1.7.10 to 1.8, the obvious fix is provided by a backend that of course abstracts it, the old modeling system from the new. From the way you described the new rendering system, this actually is a very big improvement and will make abstraction easy because now the whole system uses a common rendering system instead of defining your model to be rendered a certain way. The backend (defined in the Wrapper classes) would abstract these two rendering systems by using the new system to define the old one. You say ISimpleBlockRenderingHandler and IItemRenderer have all but disappeared, but it's quite the opposite: They've been combined into one seemless step! Look at it the way I see things: 1.8 "defines" a single "ISimpleBlockRenderingHandler" and "IItemRenderer" for all rendering operations. If you have defined your own ISimpleBlockRenderingHandlers and IItemRenderers, then could I not turn that into a BakedModel since they use the same information in code and in JSON? I think this to be true.
(I decided to go on greyminecraftcoder.blogspot.com.au to actually learn how the minecraft rendering system works between 1.7 and 1.8. I might go back on there when I need help with other stuff, and I'll be around on #minecraftforge on freenode)
jcm, instead of posting hate on this (I understand you are trying to help him a bit, but it stopped being constructive ages ago) how about you let him focus on the project. If it's wrong, it's wrong. If it's right, it's right. You can't always know the exact outcome until you try it. Yes, this is coding, but 1 line of code or thing that you overlooked could completely fix any issues. Not likely, but it's possible. Just give it time.
A better question is why even follow half the things Mojang is doing? A good question is why even bother with the json system as it currently is, which btw, doesn't let you create dynamic models, nor can it be used to build dynamic models off of, which ruins a like of 1.8 dynamic stuff (which we hack anyway). Why not improve Mojang's system? What I've use to question (silently) with everyone in the community is "Why the hell do we need to follow all of Mojang's standards for modding, I mean follow some of them for consistent interfaces, but why, for example, must we actually use, care, or follow the json system, which is incomplete, broken, and utterly unwanted. Why use something so broken? Why not wait for it to be complete first?"
Do you get my idea? Why do we need to follow a system which has not yet proven to work, to which its not only horrible, but brings about the exact opposite of its intended purpose?
Like seriously, why should we create mods and APIs based on horrible practices that were set by the original developers? The item, block, entity, and json model systems are all horrible, and break because they were rushed without prior thought.
Rollback Post to RevisionRollBack
I may be crazy, or maybe you're the crazy one, time will spill it soon enough click us, or we die
jcm, instead of posting hate on this (I understand you are trying to help him a bit, but it stopped being constructive ages ago) how about you let him focus on the project. If it's wrong, it's wrong. If it's right, it's right. You can't always know the exact outcome until you try it. Yes, this is coding, but 1 line of code or thing that you overlooked could completely fix any issues. Not likely, but it's possible. Just give it time.
I'm not posting hate on this, I'm trying to get link_the_programmer to see that their suggestion won't do anything to solve backwards compatibility. They suggested a method of abstracting the 1.8 rendering changes, but none of that is present in the OP.
They've come up with an idea that allows mods to not care about obfuscation, but haven't thought about how to isolate mods and protect them from any and all code changes Mojang presents. I know the outcome of this because I've read the OP, all the OP states is "here's a way to solve backwards compatibility by working around obfuscation". Obfuscation is the first step, the next step still has to be done and I see no information on that whatsoever for globally working on it. This won't solve backwards compatibility in it's current state, which the OP says it will just by fixing obfuscation changes. I'm not hating on the idea, if it works, fantastic! A backwards-compatible API! But that's the thing, it doesn't work, it won't work until link_the_programmer works out a way to protect every single mod using the API from any changes to the code Mojang makes. Whether it be to the Block class, Item class, Entity class, World class, rendering, chunk loading and chunk management, tile entities, particles, whatever, any code changes Mojang makes this API has to handle before it happens to be classed as a true backwards-compatible API. It doesn't handle it? Mods will break. And in it's current state, the API does not do this.
Oh so that's the major change eh? is it really that hard to make a simple converter for this? A way to recursively send all your objects through a converter that generates JSON files? This is besides the point, but just saying.
You act like my API is very limited. You do realize I am the sole creator of this API, and I can do whatever I want with it? Making an abstract layer means defining, internally, a stable backend to make the frontend work, especially in this case. The goal isn't to solve obfuscation, it's to solve backwards compatibility; you are thinking too narrowly in terms of backwards compatibility.
For the modeling problem presented with the change from 1.7.10 to 1.8, the obvious fix is provided by a backend that of course abstracts it, the old modeling system from the new. From the way you described the new rendering system, this actually is a very big improvement and will make abstraction easy because now the whole system uses a common rendering system instead of defining your model to be rendered a certain way. The backend (defined in the Wrapper classes) would abstract these two rendering systems by using the new system to define the old one. You say ",courier,monospace">ISimpleBlockRenderingHandler and IItemRenderer have all but disappeared, but it's quite the opposite: They've been combined into one seemless step! Look at it the way I see things: 1.8 "defines" a single "",courier,monospace">ISimpleBlockRenderingHandler" and "",courier,monospace">IItemRenderer" for all rendering operations. If you have defined your own ",courier,monospace">ISimpleBlockRenderingHandlers and ",courier,monospace">IItemRenderers, then could I not turn that into a BakedModel since they use the same information in code and in JSON? I think this to be true.
",courier,monospace">",courier,monospace">(I decided to go on greyminecraftcoder.blogspot.com.au to actually learn how the minecraft rendering system works between 1.7 and 1.8. I might go back on there when I need help with other stuff, and I'll be around on #minecraftforge on freenode)
You don't seem to understand my point. I'm not saying backwards compatibility between 1.7 and 1.8 isn't possible. It's possible, all you need to do is abstract things enough that mods don't have to use the system Mojang provides and instead uses your own system and then you deal with everything internally; your API is the only thing hit by the update, mods are not. What I'm saying is your current idea doesn't solve backwards compatibility. All you're doing is mitigating damage caused by obfuscation changes, you're currently doing nothing to solve changes to code; you've solved one step in a two-step equation, now you need to solve the other step.
Until you solve the other step for everything that Mojang can change, which is a lot, this isn't backwards compatible. Mods will still break because they're still using code provided by Mojang through your own classes, until you introduce a method of abstracting the rest of the code so mods for your API don't interact with Minecraft's code, this is not backwards compatible.
A better question is why even follow half the things Mojang is doing? A good question is why even bother with the json system as it currently is, which btw, doesn't let you create dynamic models, nor can it be used to build dynamic models off of, which ruins a like of 1.8 dynamic stuff (which we hack anyway). Why not improve Mojang's system? What I've use to question (silently) with everyone in the community is "Why the hell do we need to follow all of Mojang's standards for modding, I mean follow some of them for consistent interfaces, but why, for example, must we actually use, care, or follow the json system, which is incomplete, broken, and utterly unwanted. Why use something so broken? Why not wait for it to be complete first?"
Do you get my idea? Why do we need to follow a system which has not yet proven to work, to which its not only horrible, but brings about the exact opposite of its intended purpose?
Like seriously, why should we create mods and APIs based on horrible practices that were set by the original developers? The item, block, entity, and json model systems are all horrible, and break because they were rushed without prior thought.
Primarily because the community is so divided about what to do about this. Some mods literally cannot update to 1.8 or above because of the limitations it imposes with the JSON model system. Others are updating just fine. Some modders are hacking in older solutions using ASM. Others are just sticking to it. Some are working around the problem and using TESR's which (to my knowledge) still use the system they used in 1.7.10, but excessive use of tile entities can get taxing.
Someone asked Lex to reimplement the old system and hack around the new one to provide dynamic rendering functionality without forcing the use of TESR's (TileEntitySpecialRenderer's), Lex said no, he would rather just stick to the system Mojang implements. Whereas other modders are just fed up with it and hacked the old system back in. The community is divided on what they should do so one solution cannot be thought up to please the masses.
I'm not posting hate on this, I'm trying to get link_the_programmer to see that their suggestion won't do anything to solve backwards compatibility. They suggested a method of abstracting the 1.8 rendering changes, but none of that is present in the OP.
They've come up with an idea that allows mods to not care about obfuscation, but haven't thought about how to isolate mods and protect them from any and all code changes Mojang presents. I know the outcome of this because I've read the OP, all the OP states is "here's a way to solve backwards compatibility by working around obfuscation". Obfuscation is the first step, the next step still has to be done and I see no information on that whatsoever for globally working on it. This won't solve backwards compatibility in it's current state, which the OP says it will just by fixing obfuscation changes. I'm not hating on the idea, if it works, fantastic! A backwards-compatible API! But that's the thing, it doesn't work, it won't work until link_the_programmer works out a way to protect every single mod using the API from any changes to the code Mojang makes. Whether it be to the Block class, Item class, Entity class, World class, rendering, chunk loading and chunk management, tile entities, particles, whatever, any code changes Mojang makes this API has to handle before it happens to be classed as a true backwards-compatible API. It doesn't handle it? Mods will break. And in it's current state, the API does not do this.
You don't seem to understand my point. I'm not saying backwards compatibility between 1.7 and 1.8 isn't possible. It's possible, all you need to do is abstract things enough that mods don't have to use the system Mojang provides and instead uses your own system and then you deal with everything internally; your API is the only thing hit by the update, mods are not. What I'm saying is your current idea doesn't solve backwards compatibility. All you're doing is mitigating damage caused by obfuscation changes, you're currently doing nothing to solve changes to code; you've solved one step in a two-step equation, now you need to solve the other step.
Until you solve the other step for everything that Mojang can change, which is a lot, this isn't backwards compatible. Mods will still break because they're still using code provided by Mojang through your own classes, until you introduce a method of abstracting the rest of the code so mods for your API don't interact with Minecraft's code, this is not backwards compatible.
Primarily because the community is so divided about what to do about this. Some mods literally cannot update to 1.8 or above because of the limitations it imposes with the JSON model system. Others are updating just fine. Some modders are hacking in older solutions using ASM. Others are just sticking to it. Some are working around the problem and using TESR's which (to my knowledge) still use the system they used in 1.7.10, but excessive use of tile entities can get taxing.
Someone asked Lex to reimplement the old system and hack around the new one to provide dynamic rendering functionality without forcing the use of TESR's (TileEntitySpecialRenderer's), Lex said no, he would rather just stick to the system Mojang implements. Whereas other modders are just fed up with it and hacked the old system back in. The community is divided on what they should do so one solution cannot be thought up to please the masses.
"Until you solve the other step for everything that Mojang can change, which is a lot, this isn't backwards compatible."
I've already stated how I solve this problem: I change how the API works internally to be compatible with Minecraft code. I know what it takes to make something like this backwards compatible because it's very obvious to me. I'm not worried about obfuscation at all because MCP does that for me. What I do "worry" about is refactoring in Minecraft by Mojang. Any major change in the minecraft source code, I have to still compensate in my API to make the old method(s) for the previous version still compatible with the new version.
"Whether it be to the Block class, Item class, Entity class, World class, rendering, chunk loading and chunk management, tile entities, particles, whatever, any code changes Mojang makes this API has to handle before it happens to be classed as a true backwards-compatible API."
Over time, I will be making Minecraft more efficient, by providing my own obviously superior (and anyone else's) implementations of these things. Chunks? I'll make them cubic. Chunk Management? I'll put that in a separate thread to improve latency. Blocks? Static classes instead of Singletons. Entites? Same as blocks, and improve the Entity/World interaction system. World? I would improve ticking and client-to-server response times. Particles? They could easily be optimized. Explosions? I'll make those lagless. Everything else? Depends on what it is, otherwise, I'll worry about it later. Sorry if I sound rather naive and arrogant, but the optimization potential for minecraft is pretty obvious.
"Until you solve the other step for everything that Mojang can change, which is a lot, this isn't backwards compatible."
I've already stated how I solve this problem: I change how the API works internally to be compatible with Minecraft code. I know what it takes to make something like this backwards compatible because it's very obvious to me. I'm not worried about obfuscation at all because MCP does that for me. What I do "worry" about is refactoring in Minecraft by Mojang. Any major change in the minecraft source code, I have to still compensate in my API to make the old method(s) for the previous version still compatible with the new version. You didn't, all you've said is you'll be wrapping Minecraft objects with your own so mods only interact with your's to access Minecraft's, meaning your API is the only thing that is affected by changes to obfuscation. You only explained obfuscation, you never said a single thing about changes to code.
"Whether it be to the Block class, Item class, Entity class, World class, rendering, chunk loading and chunk management, tile entities, particles, whatever, any code changes Mojang makes this API has to handle before it happens to be classed as a true backwards-compatible API."
Over time, I will be making Minecraft more efficient, by providing my own obviously superior (and anyone else's) implementations of these things. Chunks? I'll make them cubic. Chunk Management? I'll put that in a separate thread to improve latency. Blocks? Static classes instead of Singletons. Entites? Same as blocks, and improve the Entity/World interaction system. World? I would improve ticking and client-to-server response times. Particles? They could easily be optimized. Explosions? I'll make those lagless. Everything else? Depends on what it is, otherwise, I'll worry about it later. Sorry if I sound rather naive and arrogant, but the optimization potential for minecraft is pretty obvious.
Except a lot of that is something an API shouldn't do. And some opportunities are frankly not possible. There's a reason why explosions lag; Mojang uses ray-tracing to track what blocks an explosion should or should not break to keep explosion damage dynamic. Chunk management is technically already threaded considering each dimension runs in it's own thread from 1.8 onwards. Singletons would arguably be the better method of dealing with blocks considering you're not creating many instances of a single block for every block of it's type in the world. Client-to-server response times can't just be improved just by saying it. Particles have been optimised already (from memory they did in one of the snapshots).
There's a reason why Forge denies changes that Mojang should really do, the point of an API is not to optimise the game for Mojang, optimising the game for Mojang is just wasting time and bulking up your own API. It's not Forge's job to swap chunks over to be cubic in nature or move chunk management over to be threaded, those are simply too big a task for an API to do. If there's small optimisations you can do; replacing a couple lines of messy code with cleaner, better code, you can fix it up with an API and Forge has been doing that since the start, but big tasks that require rewriting how the game works, it's not a task for an API to undertake.
You still seem to be missing the point. I've already explained it, so to save wasting space and time I won't write another block of text explaining it in depth, all I'll say is this; it doesn't matter if you want to fix later, it's not making the situation any better, in order for this to be a true backwards-compatible API you need to abstract every single thing mods work with and provide your own means of modding the game without referencing Minecraft's own code. Good luck writing wrapper classes for every single class mods interact with to actually modify the game, because that's what you're up against. All it takes is a single change to how blocks are registered or the setBlock() method and every single mod that uses it is broken.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
Hmm...I might need to agree with JCM, ideas like that are a little more than an API might be doing. On the bright side, if it's not an API it's a pretty innovative cross between an API and a modpack...hmm...sounds pretty interesting, actually. "The Quantum Machine: The future is here! New 'Super-Thingamajig'". I would totally get that. It's got the mod loading power of Forge, the compatibility power of Nova (I have no idea what Nova is I'm assuming since you said it does all the things that you hope Quantum does, that includes such compatibility stuff), and the optimizations of Optifine. Pretty neat! Would be awesome to see if that's possible!
Except a lot of that is something an API shouldn't do. And some opportunities are frankly not possible. There's a reason why explosions lag; Mojang uses ray-tracing to track what blocks an explosion should or should not break to keep explosion damage dynamic. Chunk management is technically already threaded considering each dimension runs in it's own thread from 1.8 onwards. Singletons would arguably be the better method of dealing with blocks considering you're not creating many instances of a single block for every block of it's type in the world. Client-to-server response times can't just be improved just by saying it. Particles have been optimised already (from memory they did in one of the snapshots).
There's a reason why Forge denies changes that Mojang should really do, the point of an API is not to optimise the game for Mojang, optimising the game for Mojang is just wasting time and bulking up your own API. It's not Forge's job to swap chunks over to be cubic in nature or move chunk management over to be threaded, those are simply too big a task for an API to do. If there's small optimisations you can do; replacing a couple lines of messy code with cleaner, better code, you can fix it up with an API and Forge has been doing that since the start, but big tasks that require rewriting how the game works, it's not a task for an API to undertake.
You still seem to be missing the point. I've already explained it, so to save wasting space and time I won't write another block of text explaining it in depth, all I'll say is this; it doesn't matter if you want to fix later, it's not making the situation any better, in order for this to be a true backwards-compatible API you need to abstract every single thing mods work with and provide your own means of modding the game without referencing Minecraft's own code. Good luck writing wrapper classes for every single class mods interact with to actually modify the game, because that's what you're up against. All it takes is a single change to how blocks are registered or the setBlock() method and every single mod that uses it is broken.
1)who cares about memory!? We care about latency! Memory comes next in optimization if at all!
a. Explosions shouldn't have to lag, nor use ray-tracing to track blocks to break for dynamic damage. All you need is a radius for which blocks are affected, get the blocks in the affected radius, and use a function of the distance from explosion epicenter to calculate damage done to the blocks. If more TNT increases the damage of the explosion, have the radius increase by getting the distance of the other TNT from the current TNT and add that onto the radius of the current TNT if the other TNT is at or in the radius of the current TNT.
2) Those optimizations will be loaded as (a) mod(s). Might I add you can enable and disable mods with this API.
a. Chunks are cubic by nature, but are treated as 2D chunks (16 cubic chunks stacked on top of each other to make one square chunk for a max height of 255). Making Chunks cubic wouldn't change anything except improve chunk processing because it's not processing 16 cubic chunks per square chunk.
b. Putting chunks in another Thread would greatly improve latency because the most obvious bottleneck in the whole game is the harddrive for writing chunks all the time, and chunk generation. Instead of generating 1 chunk per tick, you can have an arbitrary number of chunks load unconstrained by ticks in it's own thread on Thread.MIN_PRIORITY at it's own pace without affecting the game loop directly.
c. There's a difference between changing how the game works and refactoring the implementation to do produce the same output, but more efficiently.
3) Never has there ever been a case in which a change in 1.8.1 changed the same version 1.8.1. One major change in 1.8.1 results in 1.8.2, at which point I update my API to compensate for the change that may be getBlock() or how minecraft registers blocks. I don't mind doing that every time there is an update, no matter how big, and I don't mind Wrapping every necessary class (models, entities, BlockEntity [known canonically as TileEntity, but proof in the source of the file in an error string shows this to be the correct name], items,and world), because everything else I can control internally without wrapper classes and only exposing the methods by wrapping them (The JIT will optimize the wrapped methods by inlining the minecraft methods within the wrapped methods, so the performance will improve in terms of nanoseconds and might free up a millisecond or less). EDIT: Let me clarify for JIT optimization: the method called inside the wrapped method; instead of your mod calling the wrapped method, the JIT will optimize your mod to call the method inside the wrapped method is what I mean to say.
I will conclude with: the OP says "Article WIP", meaning everything I've mentioned thus far I haven't gotten to putting in the OP because it's formatting's broken for some reason...
1)who cares about memory!? We care about latency! Memory comes next in optimization if at all! Because after you know it the game takes gigabytes of memory upon launch then sits at 2-3GB while playing. Versus the if even 512MB of memory vanilla uses. I've proven that vanilla Minecraft can run perfectly fine with 512MB of memory. Thinking memory isn't important is just begging for trouble, if you don't think memory is important to care about you need to rethink about everything to do with computing.
a. Explosions shouldn't have to lag, nor use ray-tracing to track blocks to break for dynamic damage. All you need is a radius for which blocks are affected, get the blocks in the affected radius, and use a function of the distance from explosion epicenter to calculate damage done to the blocks. If more TNT increases the damage of the explosion, have the radius increase by getting the distance of the other TNT from the current TNT and add that onto the radius of the current TNT if the other TNT is at or in the radius of the current TNT. Except how do you know what blocks to break versus what blocks not to break aside from using a pre-generated image as a driver for the damage "map"? The ray-tracing is used to provide the random destruction of blocks, instead of an explosion killing every block in range using the power as the radius for the look-up sphere, it spawns n rays where n is a number determined by the power and throws them out in random directions from the origin. Noise generation can get sketchy as you could destroy blocks which weren't accessible to the explosion (blocks behind obsidian, hence the obsidian protecting them) so noise generation is out, plus noise isn't exactly quick to generate either for a quality noise sample.
2) Those optimizations will be loaded as (a) mod(s). Might I add you can enable and disable mods with this API.
a. Chunks are cubic by nature, but are treated as 2D chunks (16 cubic chunks stacked on top of each other to make one square chunk for a max height of 255). Making Chunks cubic wouldn't change anything except improve chunk processing because it's not processing 16 cubic chunks per square chunk. I thought chunks were cubic, however didn't want to say anything just in case I was wrong.
b. Putting chunks in another Thread would greatly improve latency because the most obvious bottleneck in the whole game is the harddrive for writing chunks all the time, and chunk generation. Instead of generating 1 chunk per tick, you can have an arbitrary number of chunks load unconstrained by ticks in it's own thread on Thread.MIN_PRIORITY at it's own pace without affecting the game loop directly. I wouldn't call this the most obvious bottleneck, I'd just call the most obvious bottleneck poor code and lack of decisions that would put the game in a better situation for what it is now. Like, hell, the lighting system in the game is basically a hack on top of a hack and could be optimised a ton. At least they've moved forward with models and provided a semi-decent model format, not calling the JSON system a decent model format of course.
c. There's a difference between changing how the game works and refactoring the implementation to do produce the same output, but more efficiently. Refactoring the implementation affects and breaks any code that used the old implementation, especially when the way the implementation worked changes. That's what I've been saying all along. Just because 1.7.10 and 1.8 both render blocks doesn't mean mods will deal with it fine because they both result in the exact same outcome. It doesn't work that way. If method "render()" is removed in 1.8 and a mod for 1.7.10 still uses the "render()" method, Java goes "uh oh, render() doesn't exist!", mod crashes the game because it's referencing a method that is non-existent, ergo the update broke the mod. Ultimately, no backwards compatibility. There's a reason why Google Translate and the majority of other translation services introduce subtle and trivial mistakes when translating between languages; even though language is just a means to communicate a meaning between entities, just like a programming language or a function, it doesn't mean one implementation is immediately and perfectly compatible with another. This is what I've been trying to say all along and have been saying all along.
3) Never has there ever been a case in which a change in 1.8.1 changed the same version 1.8.1. One major change in 1.8.1 results in 1.8.2, at which point I update my API to compensate for the change that may be getBlock() or how minecraft registers blocks. I don't mind doing that every time there is an update, no matter how big, and I don't mind Wrapping every necessary class (models, entities, BlockEntity [known canonically as TileEntity, but proof in the source of the file in an error string shows this to be the correct name], items,and world), because everything else I can control internally without wrapper classes and only exposing the methods by wrapping them (The JIT will optimize the wrapped methods by inlining the minecraft methods within the wrapped methods, so the performance will improve in terms of nanoseconds and might free up a millisecond or less). When did I say that a change in 1.8.1 is released as 1.8.1? And I've been saying that that's what you have to do all along.
I will conclude with: the OP says "Article WIP", meaning everything I've mentioned thus far I haven't gotten to putting in the OP because it's formatting's broken for some reason...
Responses in bold.
I will conclude with this: this entire time I've been arguing that in the current state your API does not provide backwards compatibility. I never said it never will because that's impossible, if you abstract something enough to isolate an entity in it's own system nothing externally can affect it so long as the system remains stable, in English, if you abstract an interface so much that whatever's using it doesn't once interact with whatever's behind it (in this case, the interface being your API and the thing behind it being the code of the game), that thing using it won't be affected by changes to whatever's behind the interface so long as the interface itself doesn't change.
If the modding interface doesn't change, the mod doesn't care about any changes to the internal code and hence will remain compatible. It's its own system and is not affected by anything else but what goes on in its own system. This is what I've been saying all along, backwards compatibility is possible if you abstract things enough to isolate the mod. If you practically reinvent a way a mod does something and just wire that way up to how Minecraft deals with it. It has been suggested countless times that Forge do this and the reply that the suggester receive is: no, Forge won't become it's own entity, it merely acts as a frame around the code of the game, it's not a separate pipe you interact with the game through. Your API may differ, you could design it like this and it could work, up to how you do it.
Could. And this is where I think we all misunderstood what I was saying. Back to the original point that started this, the OP only tells half the story. Now that I know you plan on doing what I've been saying all along, things have changed in terms of if backwards compatibility is possible.
In the OP you only describe a way of maintaining backwards compatibility through mitigating the damage caused by obfuscation, where you full intent is to use that system you described in the OP to both mitigate obfuscation damage and build a layer of abstraction; you just missed that last part. In the current state of the OP, your API doesn't support backwards compatibility. In the state of what you want to do it does. Do you see what I'm saying now?
To end this entire debate, I'll say this. You should maybe look at rewriting the post to convey your ideas entirely. Maybe before even writing it, open up a text document on your computer and dump everything you have planned for this in there to plan out what the post will look like before you begin writing it. As I said, you've only told half the story when the other half is so very crucial to what you want to achieve, people coming here and looking at the OP aren't getting the full picture, and that's what I've been saying.
As a tip for the formatting, how exactly is it breaking? Maybe use the preview function to work out what it will look like then tweak to avoid problems, I've noticed the editor can be a little wonky when editing an already posted comment, so it's better to catch a mistake through the preview function. If need be, start an entire new post, probably better to start afresh if you'd rather not have this in the comments.
I look forward to the progress you make, backwards compatibility for mods is something that may change the game, heck if you pull this off and maintain compatibility with Forge (I'm a bit iffy on this one) Quantum may end up becoming a de facto API alongside Forge. Good luck.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
I will conclude with this: this entire time I've been arguing that in the current state your API does not provide backwards compatibility. I never said it never will because that's impossible, if you abstract something enough to isolate an entity in it's own system nothing externally can affect it so long as the system remains stable, in English, if you abstract an interface so much that whatever's using it doesn't once interact with whatever's behind it (in this case, the interface being your API and the thing behind it being the code of the game), that thing using it won't be affected by changes to whatever's behind the interface so long as the interface itself doesn't change.
[Mod - Modding interface] - [Internal code - Minecraft code]
If the modding interface doesn't change, the mod doesn't care about any changes to the internal code and hence will remain compatible. It's its own system and is not affected by anything else but what goes on in its own system. This is what I've been saying all along, backwards compatibility is possible if you abstract things enough to isolate the mod. If you practically reinvent a way a mod does something and just wire that way up to how Minecraft deals with it. It has been suggested countless times that Forge do this and the reply that the suggester receive is: no, Forge won't become it's own entity, it merely acts as a frame around the code of the game, it's not a separate pipe you interact with the game through. Your API may differ, you could design it like this and it could work, up to how you do it.
Could. And this is where I think we all misunderstood what I was saying. Back to the original point that started this, the OP only tells half the story. Now that I know you plan on doing what I've been saying all along, things have changed in terms of if backwards compatibility is possible.
In the OP you only describe a way of maintaining backwards compatibility through mitigating the damage caused by obfuscation, where you full intent is to use that system you described in the OP to both mitigate obfuscation damage and build a layer of abstraction; you just missed that last part. In the current state of the OP, your API doesn't support backwards compatibility. In the state of what you want to do it does. Do you see what I'm saying now?
To end this entire debate, I'll say this. You should maybe look at rewriting the post to convey your ideas entirely. Maybe before even writing it, open up a text document on your computer and dump everything you have planned for this in there to plan out what the post will look like before you begin writing it. As I said, you've only told half the story when the other half is so very crucial to what you want to achieve, people coming here and looking at the OP aren't getting the full picture, and that's what I've been saying.
As a tip for the formatting, how exactly is it breaking? Maybe use the preview function to work out what it will look like then tweak to avoid problems, I've noticed the editor can be a little wonky when editing an already posted comment, so it's better to catch a mistake through the preview function. If need be, start an entire new post, probably better to start afresh if you'd rather not have this in the comments.
I look forward to the progress you make, backwards compatibility for mods is something that may change the game, heck if you pull this off and maintain compatibility with Forge (I'm a bit iffy on this one) Quantum may end up becoming a de facto API alongside Forge. Good luck.
Like I said before, give it time. It's probably a decent idea to finish 1 half so to prevent issues while you work on the other half. If you start half 2 midway between your completion of half 1, it may start problems that are harder to find the sources of. Good points there, though.
Rollback Post to RevisionRollBack
Mining and crafting since 1.2.5, baby. I'm such a pro that---Okay who put my noob test results in my signature?!
The problem with most of the Minecraft community is that many who get on the mod development don't start as developer, they do it randomly, and not many usually get into Minecraft after being a developer (and make mods I mean). This is why the community is divided, and why they don't use proper paradigms.
For example, Forge should have deprecated all the non-json model stuff for items and blocks (by patching them in) instead of letting them stay removed, as the community had no idea what was going on, which broke the system. If it did this, and gave us time, I would have been happy. An API should never break the system without warning the developers a version or two beforehand, which is why Forge is a bad model. That is proper a API and if you don't do that, you are a bad developer (if I had someone like that on my team, especially for public source systems, I'd fire them on the spot, you don't do that, its horrible practice, and I'm pretty sure Mojang should have thought about that too) And don't tell me that is how semantic version works because semantic version also deprecates, which no one did.
Another thing about an API is a consistent system, that should follow semver. I don't care about much else, but if you don't follow semver properly (which few Minecraft systems do) you should be kicked out the project for being stupid.
Rollback Post to RevisionRollBack
I may be crazy, or maybe you're the crazy one, time will spill it soon enough click us, or we die
I've stated in other places not on here that this API is meant to be a formidable successor to Forge, but not meant to replace it; that's why the title says alternative. Just like D is a great successor to C++, but doesn't replace it.
Created an initial refactor finally. Quick note: This API uses only javassist, and minecraft. ASM is heavyweight and unnecessary: javassist is lightweight and satisfies my needs of modifying classes at pre-runtime with Java Agents.
Created an initial refactor finally. Quick note: This API uses only javassist, and minecraft. ASM is heavyweight and unnecessary: javassist is lightweight and satisfies my needs of modifying classes at pre-runtime with Java Agents.
Neat. Nice to see some dedication in projects like these.
Rollback Post to RevisionRollBack
Mining and crafting since 1.2.5, baby. I'm such a pro that---Okay who put my noob test results in my signature?!
I closed the poll just now because 50% of people think the API will fail possibly because they don't think this API practical or feasible, or some other coherent reason, and they think one 15 year old can't maintain such a large project by himself [feel free to post why you think this will not last; I have a rebuke for every reply ; also I take in the consideration of the community, so replies are greatly acknowledged and appreciated so that I may improve my API]. I leave this poll here so that in the following years, I may see this poll and laugh because they said it would never happen. Again, please post why you think this will not last. I will answer any questions you have on IRC at irc.esper.net on channel #quantumapi!
You've basically summed up what half of my API does: make an abstraction layer to account for obfuscation.
The other half you missed, you basically summed up as saying what my API will not do.
There are very fundamental things you have to do for certain things to do what they do. For instance, your problem you presented me with: a complete refactoring of the rendering system in minecraft.
What is the most basic thing you need to render an OpenGl standardized model? ...? ... ok I'll tell you. It's really easy. Get a load of this: rasterize the points onto a 2D plane and apply that wire mesh with texture(s). If for some reason the rendering system were to change to, oh I don't know, the world would be refactored to use only a single 3D plane to represent the World and the actual 3D screen location, rather than two 3D planes, one as perhaps a "box" that extends infinitely* in the z axis and one plane to represent the actual World. Say I have a previous method of render(Model, x1, y1, z1, x2, y2, z2) where the first coordinates represent the World location, and that changes to render(Model, x, y, z), but my abstracted method is render(ModelWrapper, x1, y1, z1, x2, y2, z2), I would change the contents of that method to render(modelWrapper, x1, y1, z1) and I would add a method called render(ModelWrapper, x, y, z) and deprecate the other method.
Just because you change an equation fundamentally to do the same thing it did before (just in a hopefully better way) doesn't mean you can't make the old one compatible with the new because you rearranged your variables, or compressed the function, etc.
Interesting, I'll just copy and paste everything as plain text into a document. I believe the problem is I set the font to "symbol" and I liked how smooth the text looks compared to others, so I'll probably change it to Times New Roman and see what happens.
Theoretically, yes you could, when I get Forge mods actually loading, and when I get legacy Forge compatibility and make it an actual thing.
Formatting still broken, but the post is much more clean so it'll be easier to know what is what and where. Changed to "helvetica" font family. It would appear this is a site glitch? and might I add it seems like every word I type is lagging because it's putting in bbcode for the document in the background on the fly? I shouldn't be getting this problem... really...
Except that's not what Mojang has done for redoing rendering. Prior to 1.8 you used to have IItemRenderer and ISimpleBlockRenderingHandler (ISBRH I believe was part of Forge, IItemRenderer may have been part of Forge too) and you could write some OpenGL code to render the model like how you described, instead using the old model system (where models were collections of cuboids). 1.8 changed this to instead make models use JSON files which eliminates dynamic rendering (having code render and piece together the model versus storing variants of a model, for a pipe for instance), which killed IItemRenderer and ISimpleBlockRenderingHandler. Buildcraft used code to condense pipes down to be as efficient as possible at the time; when you call the render method in the model class you would pass some values through and based on those values individual model components would or would not be rendered, everything was handled in-code, versus with the JSON system where there is literally no way to even port models over because there would be too many model variants for the system to handle (apparently there's a maximum of 65536 total models that can be registered, Buildcraft requires at least a hundred thousand considering factoring in pipe type, side connections, pipe wire x3 (red, green and blue pipe wire), facades for every registered block, pipe gates, etc, every single one of these has to be considered, and every variant has to be written in it's own unique JSON file, there's not enough "slots" to even fit a portion of the models required for Buildcraft, the alpha had to "hack" the old method back in).
If your mod is for 1.7.10, won't work, no matter if technically speaking both 1.7.10 and 1.8 do the same thing at the end of the day. Your 1.7.10 mod works completely differently to how 1.8 works; it'd be like saying that you can translate an Arabic essay to English perfectly because at the end of the day all languages do is convey meaning. Not possible. 1.7.10 works one way, 1.8 works another, you can't have a mod work for both 1.7.10 and 1.8 unless you abstract it to the point of having the API deal with this internally and mods use your own unique method of dealing with rendering, which your API does not do.
Mojang didn't rearrange variables or compress functions, they deleted the old code and rewrote new code that works entirely differently. No way to maintain compatibility across both with the way your API works currently.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
Disregard this. Forums dun messed up.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
Oh so that's the major change eh? is it really that hard to make a simple converter for this? A way to recursively send all your objects through a converter that generates JSON files? This is besides the point, but just saying.
You act like my API is very limited. You do realize I am the sole creator of this API, and I can do whatever I want with it? Making an abstract layer means defining, internally, a stable backend to make the frontend work, especially in this case. The goal isn't to solve obfuscation, it's to solve backwards compatibility; you are thinking too narrowly in terms of backwards compatibility.
For the modeling problem presented with the change from 1.7.10 to 1.8, the obvious fix is provided by a backend that of course abstracts it, the old modeling system from the new. From the way you described the new rendering system, this actually is a very big improvement and will make abstraction easy because now the whole system uses a common rendering system instead of defining your model to be rendered a certain way. The backend (defined in the Wrapper classes) would abstract these two rendering systems by using the new system to define the old one. You say ISimpleBlockRenderingHandler and IItemRenderer have all but disappeared, but it's quite the opposite: They've been combined into one seemless step! Look at it the way I see things: 1.8 "defines" a single "ISimpleBlockRenderingHandler" and "IItemRenderer" for all rendering operations. If you have defined your own ISimpleBlockRenderingHandlers and IItemRenderers, then could I not turn that into a BakedModel since they use the same information in code and in JSON? I think this to be true.
(I decided to go on greyminecraftcoder.blogspot.com.au to actually learn how the minecraft rendering system works between 1.7 and 1.8. I might go back on there when I need help with other stuff, and I'll be around on #minecraftforge on freenode)
jcm, instead of posting hate on this (I understand you are trying to help him a bit, but it stopped being constructive ages ago) how about you let him focus on the project. If it's wrong, it's wrong. If it's right, it's right. You can't always know the exact outcome until you try it. Yes, this is coding, but 1 line of code or thing that you overlooked could completely fix any issues. Not likely, but it's possible. Just give it time.
Mining and crafting since 1.2.5, baby. I'm such a pro that---Okay who put my noob test results in my signature?!
Why are you so fascinated with my description?
Time to upload to github and delete the gigantic untested heap of inefficient and not well-planned code that currently reside(d)s on there!
A better question is why even follow half the things Mojang is doing? A good question is why even bother with the json system as it currently is, which btw, doesn't let you create dynamic models, nor can it be used to build dynamic models off of, which ruins a like of 1.8 dynamic stuff (which we hack anyway). Why not improve Mojang's system? What I've use to question (silently) with everyone in the community is "Why the hell do we need to follow all of Mojang's standards for modding, I mean follow some of them for consistent interfaces, but why, for example, must we actually use, care, or follow the json system, which is incomplete, broken, and utterly unwanted. Why use something so broken? Why not wait for it to be complete first?"
Do you get my idea? Why do we need to follow a system which has not yet proven to work, to which its not only horrible, but brings about the exact opposite of its intended purpose?
Like seriously, why should we create mods and APIs based on horrible practices that were set by the original developers? The item, block, entity, and json model systems are all horrible, and break because they were rushed without prior thought.
I may be crazy, or maybe you're the crazy one, time will spill it soon enough
click us, or we die
I'm not posting hate on this, I'm trying to get link_the_programmer to see that their suggestion won't do anything to solve backwards compatibility. They suggested a method of abstracting the 1.8 rendering changes, but none of that is present in the OP.
They've come up with an idea that allows mods to not care about obfuscation, but haven't thought about how to isolate mods and protect them from any and all code changes Mojang presents. I know the outcome of this because I've read the OP, all the OP states is "here's a way to solve backwards compatibility by working around obfuscation". Obfuscation is the first step, the next step still has to be done and I see no information on that whatsoever for globally working on it. This won't solve backwards compatibility in it's current state, which the OP says it will just by fixing obfuscation changes. I'm not hating on the idea, if it works, fantastic! A backwards-compatible API! But that's the thing, it doesn't work, it won't work until link_the_programmer works out a way to protect every single mod using the API from any changes to the code Mojang makes. Whether it be to the Block class, Item class, Entity class, World class, rendering, chunk loading and chunk management, tile entities, particles, whatever, any code changes Mojang makes this API has to handle before it happens to be classed as a true backwards-compatible API. It doesn't handle it? Mods will break. And in it's current state, the API does not do this.
You don't seem to understand my point. I'm not saying backwards compatibility between 1.7 and 1.8 isn't possible. It's possible, all you need to do is abstract things enough that mods don't have to use the system Mojang provides and instead uses your own system and then you deal with everything internally; your API is the only thing hit by the update, mods are not. What I'm saying is your current idea doesn't solve backwards compatibility. All you're doing is mitigating damage caused by obfuscation changes, you're currently doing nothing to solve changes to code; you've solved one step in a two-step equation, now you need to solve the other step.
Until you solve the other step for everything that Mojang can change, which is a lot, this isn't backwards compatible. Mods will still break because they're still using code provided by Mojang through your own classes, until you introduce a method of abstracting the rest of the code so mods for your API don't interact with Minecraft's code, this is not backwards compatible.
Primarily because the community is so divided about what to do about this. Some mods literally cannot update to 1.8 or above because of the limitations it imposes with the JSON model system. Others are updating just fine. Some modders are hacking in older solutions using ASM. Others are just sticking to it. Some are working around the problem and using TESR's which (to my knowledge) still use the system they used in 1.7.10, but excessive use of tile entities can get taxing.
Someone asked Lex to reimplement the old system and hack around the new one to provide dynamic rendering functionality without forcing the use of TESR's (TileEntitySpecialRenderer's), Lex said no, he would rather just stick to the system Mojang implements. Whereas other modders are just fed up with it and hacked the old system back in. The community is divided on what they should do so one solution cannot be thought up to please the masses.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
"Until you solve the other step for everything that Mojang can change, which is a lot, this isn't backwards compatible."
I've already stated how I solve this problem: I change how the API works internally to be compatible with Minecraft code. I know what it takes to make something like this backwards compatible because it's very obvious to me. I'm not worried about obfuscation at all because MCP does that for me. What I do "worry" about is refactoring in Minecraft by Mojang. Any major change in the minecraft source code, I have to still compensate in my API to make the old method(s) for the previous version still compatible with the new version.
"Whether it be to the Block class, Item class, Entity class, World class, rendering, chunk loading and chunk management, tile entities, particles, whatever, any code changes Mojang makes this API has to handle before it happens to be classed as a true backwards-compatible API."
Over time, I will be making Minecraft more efficient, by providing my own obviously superior (and anyone else's) implementations of these things. Chunks? I'll make them cubic. Chunk Management? I'll put that in a separate thread to improve latency. Blocks? Static classes instead of Singletons. Entites? Same as blocks, and improve the Entity/World interaction system. World? I would improve ticking and client-to-server response times. Particles? They could easily be optimized. Explosions? I'll make those lagless. Everything else? Depends on what it is, otherwise, I'll worry about it later. Sorry if I sound rather naive and arrogant, but the optimization potential for minecraft is pretty obvious.
Except a lot of that is something an API shouldn't do. And some opportunities are frankly not possible. There's a reason why explosions lag; Mojang uses ray-tracing to track what blocks an explosion should or should not break to keep explosion damage dynamic. Chunk management is technically already threaded considering each dimension runs in it's own thread from 1.8 onwards. Singletons would arguably be the better method of dealing with blocks considering you're not creating many instances of a single block for every block of it's type in the world. Client-to-server response times can't just be improved just by saying it. Particles have been optimised already (from memory they did in one of the snapshots).
There's a reason why Forge denies changes that Mojang should really do, the point of an API is not to optimise the game for Mojang, optimising the game for Mojang is just wasting time and bulking up your own API. It's not Forge's job to swap chunks over to be cubic in nature or move chunk management over to be threaded, those are simply too big a task for an API to do. If there's small optimisations you can do; replacing a couple lines of messy code with cleaner, better code, you can fix it up with an API and Forge has been doing that since the start, but big tasks that require rewriting how the game works, it's not a task for an API to undertake.
You still seem to be missing the point. I've already explained it, so to save wasting space and time I won't write another block of text explaining it in depth, all I'll say is this; it doesn't matter if you want to fix later, it's not making the situation any better, in order for this to be a true backwards-compatible API you need to abstract every single thing mods work with and provide your own means of modding the game without referencing Minecraft's own code. Good luck writing wrapper classes for every single class mods interact with to actually modify the game, because that's what you're up against. All it takes is a single change to how blocks are registered or the setBlock() method and every single mod that uses it is broken.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
Hmm...I might need to agree with JCM, ideas like that are a little more than an API might be doing. On the bright side, if it's not an API it's a pretty innovative cross between an API and a modpack...hmm...sounds pretty interesting, actually. "The Quantum Machine: The future is here! New 'Super-Thingamajig'". I would totally get that. It's got the mod loading power of Forge, the compatibility power of Nova (I have no idea what Nova is
I'm assuming since you said it does all the things that you hope Quantum does, that includes such compatibility stuff), and the optimizations of Optifine. Pretty neat! Would be awesome to see if that's possible!
Mining and crafting since 1.2.5, baby. I'm such a pro that---Okay who put my noob test results in my signature?!
Why are you so fascinated with my description?
1)who cares about memory!? We care about latency! Memory comes next in optimization if at all!
a. Explosions shouldn't have to lag, nor use ray-tracing to track blocks to break for dynamic damage. All you need is a radius for which blocks are affected, get the blocks in the affected radius, and use a function of the distance from explosion epicenter to calculate damage done to the blocks. If more TNT increases the damage of the explosion, have the radius increase by getting the distance of the other TNT from the current TNT and add that onto the radius of the current TNT if the other TNT is at or in the radius of the current TNT.
2) Those optimizations will be loaded as (a) mod(s). Might I add you can enable and disable mods with this API.
a. Chunks are cubic by nature, but are treated as 2D chunks (16 cubic chunks stacked on top of each other to make one square chunk for a max height of 255). Making Chunks cubic wouldn't change anything except improve chunk processing because it's not processing 16 cubic chunks per square chunk.
b. Putting chunks in another Thread would greatly improve latency because the most obvious bottleneck in the whole game is the harddrive for writing chunks all the time, and chunk generation. Instead of generating 1 chunk per tick, you can have an arbitrary number of chunks load unconstrained by ticks in it's own thread on Thread.MIN_PRIORITY at it's own pace without affecting the game loop directly.
c. There's a difference between changing how the game works and refactoring the implementation to do produce the same output, but more efficiently.
3) Never has there ever been a case in which a change in 1.8.1 changed the same version 1.8.1. One major change in 1.8.1 results in 1.8.2, at which point I update my API to compensate for the change that may be getBlock() or how minecraft registers blocks. I don't mind doing that every time there is an update, no matter how big, and I don't mind Wrapping every necessary class (models, entities, BlockEntity [known canonically as TileEntity, but proof in the source of the file in an error string shows this to be the correct name], items,and world), because everything else I can control internally without wrapper classes and only exposing the methods by wrapping them (The JIT will optimize the wrapped methods by inlining the minecraft methods within the wrapped methods, so the performance will improve in terms of nanoseconds and might free up a millisecond or less). EDIT: Let me clarify for JIT optimization: the method called inside the wrapped method; instead of your mod calling the wrapped method, the JIT will optimize your mod to call the method inside the wrapped method is what I mean to say.
I will conclude with: the OP says "Article WIP", meaning everything I've mentioned thus far I haven't gotten to putting in the OP because it's formatting's broken for some reason...
Responses in bold.
I will conclude with this: this entire time I've been arguing that in the current state your API does not provide backwards compatibility. I never said it never will because that's impossible, if you abstract something enough to isolate an entity in it's own system nothing externally can affect it so long as the system remains stable, in English, if you abstract an interface so much that whatever's using it doesn't once interact with whatever's behind it (in this case, the interface being your API and the thing behind it being the code of the game), that thing using it won't be affected by changes to whatever's behind the interface so long as the interface itself doesn't change.
[Mod - Modding interface] - [Internal code - Minecraft code]
If the modding interface doesn't change, the mod doesn't care about any changes to the internal code and hence will remain compatible. It's its own system and is not affected by anything else but what goes on in its own system. This is what I've been saying all along, backwards compatibility is possible if you abstract things enough to isolate the mod. If you practically reinvent a way a mod does something and just wire that way up to how Minecraft deals with it. It has been suggested countless times that Forge do this and the reply that the suggester receive is: no, Forge won't become it's own entity, it merely acts as a frame around the code of the game, it's not a separate pipe you interact with the game through. Your API may differ, you could design it like this and it could work, up to how you do it.
Could. And this is where I think we all misunderstood what I was saying. Back to the original point that started this, the OP only tells half the story. Now that I know you plan on doing what I've been saying all along, things have changed in terms of if backwards compatibility is possible.
In the OP you only describe a way of maintaining backwards compatibility through mitigating the damage caused by obfuscation, where you full intent is to use that system you described in the OP to both mitigate obfuscation damage and build a layer of abstraction; you just missed that last part. In the current state of the OP, your API doesn't support backwards compatibility. In the state of what you want to do it does. Do you see what I'm saying now?
To end this entire debate, I'll say this. You should maybe look at rewriting the post to convey your ideas entirely. Maybe before even writing it, open up a text document on your computer and dump everything you have planned for this in there to plan out what the post will look like before you begin writing it. As I said, you've only told half the story when the other half is so very crucial to what you want to achieve, people coming here and looking at the OP aren't getting the full picture, and that's what I've been saying.
As a tip for the formatting, how exactly is it breaking? Maybe use the preview function to work out what it will look like then tweak to avoid problems, I've noticed the editor can be a little wonky when editing an already posted comment, so it's better to catch a mistake through the preview function. If need be, start an entire new post, probably better to start afresh if you'd rather not have this in the comments.
I look forward to the progress you make, backwards compatibility for mods is something that may change the game, heck if you pull this off and maintain compatibility with Forge (I'm a bit iffy on this one) Quantum may end up becoming a de facto API alongside Forge. Good luck.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
Like I said before, give it time. It's probably a decent idea to finish 1 half so to prevent issues while you work on the other half. If you start half 2 midway between your completion of half 1, it may start problems that are harder to find the sources of. Good points there, though.
Mining and crafting since 1.2.5, baby. I'm such a pro that---Okay who put my noob test results in my signature?!
Why are you so fascinated with my description?
The problem with most of the Minecraft community is that many who get on the mod development don't start as developer, they do it randomly, and not many usually get into Minecraft after being a developer (and make mods I mean). This is why the community is divided, and why they don't use proper paradigms.
For example, Forge should have deprecated all the non-json model stuff for items and blocks (by patching them in) instead of letting them stay removed, as the community had no idea what was going on, which broke the system. If it did this, and gave us time, I would have been happy. An API should never break the system without warning the developers a version or two beforehand, which is why Forge is a bad model. That is proper a API and if you don't do that, you are a bad developer (if I had someone like that on my team, especially for public source systems, I'd fire them on the spot, you don't do that, its horrible practice, and I'm pretty sure Mojang should have thought about that too) And don't tell me that is how semantic version works because semantic version also deprecates, which no one did.
Another thing about an API is a consistent system, that should follow semver. I don't care about much else, but if you don't follow semver properly (which few Minecraft systems do) you should be kicked out the project for being stupid.
I may be crazy, or maybe you're the crazy one, time will spill it soon enough
click us, or we die
I've stated in other places not on here that this API is meant to be a formidable successor to Forge, but not meant to replace it; that's why the title says alternative. Just like D is a great successor to C++, but doesn't replace it.
Created an initial refactor finally. Quick note: This API uses only javassist, and minecraft. ASM is heavyweight and unnecessary: javassist is lightweight and satisfies my needs of modifying classes at pre-runtime with Java Agents.
Neat. Nice to see some dedication in projects like these.
Mining and crafting since 1.2.5, baby. I'm such a pro that---Okay who put my noob test results in my signature?!
Why are you so fascinated with my description?
I closed the poll just now because 50% of people think the API will fail possibly because they don't think this API practical or feasible, or some other coherent reason, and they think one 15 year old can't maintain such a large project by himself [feel free to post why you think this will not last; I have a rebuke for every reply
; also I take in the consideration of the community, so replies are greatly acknowledged and appreciated so that I may improve my API]. I leave this poll here so that in the following years, I may see this poll and laugh because they said it would never happen. Again, please post why you think this will not last. I will answer any questions you have on IRC at irc.esper.net on channel #quantumapi!