Mojang is solving issues that are preventing Mod API progress, such as the numeric ID system. This is why the development of the Mod API is slow.
The use of numeric IDs as opposed to the "new" system which references numeric IDs of blocks through an abstraction layer (numbers... indeed the same numbers are still being used internally with Minecraft) are not necessary for a functioning API. One does not necessarily follow the other and the API could have been released without it.
No doubt it will be useful, and in the bug tracker that Mojang uses for API suggestions, it was a major area of discussion and seen as essential in a proper API implementation. Don't buy into the notion though that it was required before an API could be released.
What's particularly annoying is that if they'd just fix the obfuscated names changing with every update, they'd have a functioning API in Forge. Not the best, sure, but functioning. Most of the Forge code patches could just be integrated into the source.
Dear God, I pray that this never happens. Forge has its use, and I hope that the Mojang developers intelligently review some of the ideas that have been incorporated into Forge, but for all that is good and wholesome Forge is the worst thing that could be adopted into the vanilla code base. Forge has its use, but it is also bloated and has a number of awful features too.
Besides, Jeb has flat out rejected the notion on numerous occasions for the reason I'm using as well here to reject this notion. As a base to review some commonly requested API features perhaps, but it is very unlikely to actually happen in this way. Besides, there will continue to be something called "Forge" even after the official API comes out, as some in the mod development community will still want to be pushing the API frontier and do things that the API doesn't yet permit. Even if it isn't called necessarily "Forge", it will still exist even in spirit.
The obfuscated name changing thing is seen as a legal requirement. I don't know what legal requirement and it seems incredibly silly to me as Mojang has been active in assisting the MCP team in deobfuscating the names (sort of defeating the point of the obfuscation) but none the less it is something that is unlikely to ever change until Mojang (read Notch in particular) decides to release Minecraft to the world under the GPL or a similar free software license.
Secondly, it's technically been in development at least back during 1.3, as the SMP SSP merge was a mandatory step for it all to happen. I highly doubt they would say it's in development if it's not actually in development, Mojang gains nothing nor has any reason to lie about it.
Also, there are a few people in the background that are working on it (Like Grum). So it's not only Dinnerbone.
I disagree. The second Mojang finishes that thing they are utterly outmoded by the plugin community. It wouldn't surprise me if the API is the very last official update from Mojang before closing shop on Minecraft.
Secondly, it's technically been in development at least back during 1.3, as the SMP SSP merge was a mandatory step for it all to happen. I highly doubt they would say it's in development if it's not actually in development, Mojang gains nothing nor has any reason to lie about it.
Also, there are a few people in the background that are working on it (Like Grum). So it's not only Dinnerbone.
I disagree. The second Mojang finishes that thing they are utterly outmoded by the plugin community. It wouldn't surprise me if the API is the very last official update from Mojang before closing shop on Minecraft.
I disagree. The second Mojang finishes that thing they are utterly outmoded by the plugin community. It wouldn't surprise me if the API is the very last official update from Mojang before closing shop on Minecraft.
If that is what actually happens, Mojang might as well not even bother as the 3rd party development community (aka the "mod developers") can and will come up with something better anyway.
The point of an official API library is to legitimize 3rd party plug-ins for people who are perhaps timid when thinking about doing stuff like opening the minecraft.jar file or doing other deep levels of modification of the game. Yes, I know that isn't needed any more, but my point is that a true plug-in is going to extend the life span of Minecraft and let it continue to be a cash cow for Mojang. If they are simply turning Minecraft loose in the public domain and moving on to the next cool project, the mod community can and will take over.
I would expect that a public domain/GPL'd version of Minecraft would simply be forked into a dozen different games (or more). There really wouldn't be a need for an API at that point beyond Forge/ModLoader/something else.
Dear God, I pray that this never happens. Forge has its use, and I hope that the Mojang developers intelligently review some of the ideas that have been incorporated into Forge, but for all that is good and wholesome Forge is the worst thing that could be adopted into the vanilla code base. Forge has its use, but it is also bloated and has a number of awful features too.
The obfuscated name changing thing is seen as a legal requirement. I don't know what legal requirement and it seems incredibly silly to me as Mojang has been active in assisting the MCP team in deobfuscating the names (sort of defeating the point of the obfuscation) but none the less it is something that is unlikely to ever change until Mojang (read Notch in particular) decides to release Minecraft to the world under the GPL or a similar free software license.
OK, I'm not getting how Forge is bloated. I mod, and I really don't see much in there that doesn't seem plausibly useful. Forge is bloaty in a sense in that there are a lot of different ways people want to mod and Forge tries to accommodate them all. But I see this as a good thing.
My only beef with Forge is how they use annotations for programming. It short-circuits all the type-safety and compile-checking that Java provides. I have literally spent hours trying to figure out why something isn't working when I've annotated improperly (most recently on an event screening call); if this had been done in a traditional OO manner with something like abstract classes I'd have gotten the whole thing right as soon as my type-ahead options popped up. But beef notwithstanding, I'd much rather struggle occasionally with annotation programming than wait another 2 years or whatever for a stable API. The base Minecraft code is hardly the exemplar of good OO programming either, even if its flaws run in an entirely different direction than Forge's do.
Mojang doesn't need to stop obfuscating their code, they just need to stop changing what each function obfuscates to. I can kind of see copyright reasons they might want to obfuscate for, but I really can't see any reason they have to change the obfuscation with some - but not all - revisions.
The plugin API, in my opinion, is going to be released as one of the last, if not the last, update that Mojang releases.
Eventually, Mojang is going to have to move on to other projects. It happens with every game, and will be necessary for them to survive as a company. There will come a point when there are so few people buying new copies of Minecraft that it will become seemingly useless to continue to release updates for it. This doesn't mean that the community is going anywhere, it will still be filled with millions of players who want to see new features, but as Mojang doesn't require payment for updates, the community won't be able to support the largest portion of Mojang's income.
I see the plugin API as a way for Mojang to step back. If it's made easier for the community to provide updates themselves, then Mojang will no longer need to spend time working on updates, freeing them up to develop more products and move on as a company.
The good folks at Forge are already making modding increasingly easier, but the plugin API will ultimately let the community take helm of the game's development. This may or may not make Forge and MCP completely useless, I for one hope it doesn't, they both do great work.
Mojang will never just 'forget' Minecraft though, after all, it is the game that started it all. They want to give it a proper send off, and what better way is there than to make all future updates 100% community developed.
My only beef with Forge is how they use annotations for programming. It short-circuits all the type-safety and compile-checking that Java provides. I have literally spent hours trying to figure out why something isn't working when I've annotated improperly (most recently on an event screening call); if this had been done in a traditional OO manner with something like abstract classes I'd have gotten the whole thing right as soon as my type-ahead options popped up.
I don't do any modding at all, but I find this argument of yours a little strange. I do agree with everything else in your post.
Type annotations are prime candidates for a pluggable system such that which is offered by Forge. Since Minecraft doesn't expose any of its classes, your only access to their code is through type annotations (once their classes names are deobfuscated and their general functionality understood).
Sure, you could abstract this away from the modders by creating a proper OO interface to the type annotations. Essentially, hide the Forge details from the modder and present instead a OO centric approach to modding. But I think the overhead would be too much for modders to be able to code all but the simplest of mods.
Because Minecraft doesn't expose any of its classes, type annotations are the most reliable and direct away to plug in to the code at runtime. And modders just have to learn to live with the difficulties of this programming paradigm.
I don't do any modding at all, but I find this argument of yours a little strange. I do agree with everything else in your post.
Type annotations are prime candidates for a pluggable system such that which is offered by Forge. Since Minecraft doesn't expose any of its classes, your only access to their code is through type annotations (once their classes names are deobfuscated and their general functionality understood).
Sure, you could abstract this away from the modders by creating a proper OO interface to the type annotations. Essentially, hide the Forge details from the modder and present instead a OO centric approach to modding. But I think the overhead would be too much for modders to be able to code all but the simplest of mods.
Because Minecraft doesn't expose any of its classes, type annotations are the most reliable and direct away to plug in to the code at runtime. And modders just have to learn to live with the difficulties of this programming paradigm.
The complexities of Forge modding turned me off from ever trying to mod with Forge, especially when you want to do the kind of stuff I do; for example, I posted a thread a while back on how to replace the vanilla cave generator using Forge (I'm guessing nobody knows how), and that was before all of my changes to terrain generation with a total of 17 base classes modified (22 for my own version as I removed torches from mineshafts and strongholds so a mapping utility I use doesn't show them when mapping underground areas).
Not like it causes any problems while playing either even though I use Forge for other mods and it refuses to run the game unless I tell it to ignore the changes I made (that said, I used the decompiled Forge source (exact same version, 9.10.0.842) for my own version of my mods so the changes that Forge refuses to apply to modified classes are present (lines like MinecraftForge.Event); the ones I provide for download are based on vanilla code).
I don't do any modding at all, but I find this argument of yours a little strange. I do agree with everything else in your post.
Type annotations are prime candidates for a pluggable system such that which is offered by Forge. Since Minecraft doesn't expose any of its classes, your only access to their code is through type annotations (once their classes names are deobfuscated and their general functionality understood).
Sure, you could abstract this away from the modders by creating a proper OO interface to the type annotations. Essentially, hide the Forge details from the modder and present instead a OO centric approach to modding. But I think the overhead would be too much for modders to be able to code all but the simplest of mods.
Because Minecraft doesn't expose any of its classes, type annotations are the most reliable and direct away to plug in to the code at runtime. And modders just have to learn to live with the difficulties of this programming paradigm.
I don't know if annotations can be used to get around hidden code; that would be a reasonable use; but that isn't what Forge uses it for. Minecraft doesn't hide the code in the sense that you can't look at it, but only in the sense that it obfuscates the names. MCP provides deobfuscation/obfuscation tools which let modder code in the normal names - when it's out, of course - we're still waiting for MCP for 1.7. Forge does nothing for the obfuscation.
What Forge uses annotations for is communication between the mod and Forge. So, for example, if you want to screen or modify an event generated outside of your mod, you write a modifier object and pass it to Forge. However, the code doing the pass has to be flagged with an annotation as well. And, if the types aren't all correct, it just fails silently. I can see some reason for this; they could be and probably are using the annotation parameters to determine what types of events your object should receive. But, I can think of at least two ways to do the same thing in a standard OO format so you'd have type safety and using the wrong object class would be caught at runtime.
To be quite honest we may never know it could be like any other "hidden" update that we have to wait and second how would everyone else uses this feature in Minecraft, but yet again that is my opinion, and we just have to be patient
I don't know if annotations can be used to get around hidden code
By "Minecraft doesn't expose any of its classes", I mean these are not public classes that can be accessed from external code. Expose is being used in the context of Java OO access levels.
I'm not sure what other methods you say exist that allow you to tap into package-private classes and that can be reliably and efficiently used for the development of a mod/plugin API. But I'd honestly like to know.
By "Minecraft doesn't expose any of its classes", I mean these are not public classes that can be accessed from external code. Expose is being used in the context of Java OO access levels.
I'm not sure what other methods you say exist that allow you to tap into package-private classes and that can be reliably and efficiently used for the development of a mod/plugin API. But I'd honestly like to know.
Got it. You're right, that is hidden, or it's *supposed* to be. But Java reflection allows you to get at private access fields and methods - one of the reasons Java is no longer considered "safe" for browser use.
Forge also uses a lot of code patches, where they change a compiled file prior to loading it. Also one of the reasons Java is no longer considered a secure system.
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
What's your method for tapping into Minecraft? You replace the whole class file with your own code?
Yes, and I even change how some of the classes are declared; for example, here is the vanilla MapGenCaves, which extends another class:
public class MapGenCaves extends MapGenBase
In my version:
public class MapGenCaves
So what I did was combine those two classes (I also modified MapGenBase to increase the range of chunks it checks to accommodate larger caves and ravines, but I also made it so that only the largest systems actually use a larger range for efficiency, plus I have six separate cave/ravine generators), as well as with MapGenRavine, so I now have a single class that contains the equivalent of three separate classes, so I only need to work with one file (this also requires modifying ChunkProviderGenerate to change the reference to MapGenCaves and remove MapGenRavine, though I modified it anyway to change terrain; MapGenBase is still used by some other classes but MapGenRavine becomes dead code when my mod is added).
Now, about what Forge does, when I look at the source with the Forge patches applied (note that Forge normally adds patches at runtime; the "Forge" jar is really a renamed vanilla jar with Forge added as a library), I see lines like this:
ChunkProviderEvent.ReplaceBiomeBlocks event = new ChunkProviderEvent.ReplaceBiomeBlocks(this, par1, par2, par3ArrayOfByte, par4ArrayOfBiomeGenBase);
MinecraftForge.EVENT_BUS.post(event);
if (event.getResult() == Result.DENY) return;
MapGenCaves also has some code added by Forge to allow caves to cut through custom biome surface blocks (other than dirt and grass, incidentally, this is why vanilla caves don't cut through deserts or mesas) although I removed it altogether as I made caves only cut through stone except for a special type, which makes the code cleaner and probably a bit faster (in-line code is faster than calling a method, as is only doing one comparison as opposed to three, similarly, I removed the code that checks for water in the path of a ravine (also changed by Forge and reverted to the vanilla code for caves), to avoid cutting across rivers, as they can't cut through the surface in any case, which also prevents malformed ravines).
This also means that while I used the Forge source to make my mod for myself, I can simply copy+paste most of MapGenCaves (except for the package name and imports, as Forge changes them) into my vanilla source-based version of my mods (which are also for 1.6.4, I use the 1.6.2 Forge source); other classes have lesser changes and can be easily changed by hand (and yes, I have a text file with a list of files and what to change).
Of note, I also add my mod to Forge as a library, as described here, so the actual jar isn't modified, which also makes it very easy to change without having to replace the jar.
Got it. You're right, that is hidden, or it's *supposed* to be. But Java reflection allows you to get at private access fields and methods - one of the reasons Java is no longer considered "safe" for browser use.
Reflection is extraordinarily expensive for non event driven applications. We are talking about a method of accessing external package-private classes that up until recently was an order of magnitude (10x) for method calls with lookup and 3x more expensive for method calls without lookup.
It simply isn't possible to create a performant plugin API like Forge based on reflection. And this is the reason why they didn't do it in the first place. I suppose it could have been done for some parts of the code that don't need to run on a frame-by-frame basis, but then you'd have a inconsistent API that forced you to mishmash several methods of programming. That is undesirable. And would still not answer the performance issues it could bring in to the game.
Forge also uses a lot of code patches, where they change a compiled file prior to loading it.
I suppose. Type Annotations (or Reflection, since we are also talking about this possibility) can't answer all the modding needs. Particularly when it comes to actual behavior changing of existing methods. But if you are implying the Forge API could be coded on this principle, you must consider that what this means is that Forge would in fact have to patch the whole Minecraft code base, which would essentially make it a complete Minecraft binary. No mod API is created on a patch principle for this reason. It's just not possible to patch the entire code base and expect this to become a reliable and efficient API.
Update: According to Dinnerbone's Twitter, yes, very much so. Go check it out!
I think you mean this twitter? Well, that's the type of stuff we have been hearing since 2010. How can such a laconic statement that ignores years of failed promises (as if this was the first time he or anyone else at Mojang promised the plugin API) can be made out to be a definite Yes?
I think some readers of this thread still didn't get it, maybe because they didn't read the whole thread yet. We have been promised the Plugin API with statements like those since 2010. Alright?
Rollback Post to RevisionRollBack
I was trying to think of a signature and this is what came up.
Your negativity astounds me, but if you've been waiting for nearly four years, I guess I shouldn't be surprised.
I'm not a modder (which I'm sure is no surprise) but I do like to create game-breaking modpacks for fun. It would be nice to more easily cram mods together, but I'm a vanilla player at heart. Probably why I'm not so concerned about the 'lies' Mojang are apparently guilty of telling.
I suppose. Type Annotations (or Reflection, since we are also talking about this possibility) can't answer all the modding needs. Particularly when it comes to actual behavior changing of existing methods. But if you are implying the Forge API could be coded on this principle, you must consider that what this means is that Forge would in fact have to patch the whole Minecraft code base, which would essentially make it a complete Minecraft binary. No mod API is created on a patch principle for this reason. It's just not possible to patch the entire code base and expect this to become a reliable and efficient API.
I think you have this image of Minecraft as being written in a "classic" OO format, with tightly encapsulated private classes implementing public interfaces that don't expose the data. It's not like that at all. It's more like what a C programmer writes when they're just learning C++ and object-oriented programming. There's not much of interfaces/ facades/ etc. for indirect access. If a routine or a field needs to be used outside of its package, it's public access. If only in its package, it's often package private; but if necessary MCP can compile mod code into an existing Minecraft package so that's accessible too. As a rule, though, Minecraft packages are organized around function rather than data access so most of what you want is already public.
Generally speaking if a modder wants access to a routine or piece of data, something outside of the class uses it in Minecraft and access is not an issue. In writing 2 medium-sized mods, I think I encountered 2 or 3 situations where access rights were a problem.
I haven't looked at a lot of Forge code, but generally they just access what they want, same as I do. Every time I've seen that they can't they use a code patch.
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
I think you have this image of Minecraft as being written in a "classic" OO format, with tightly encapsulated private classes implementing public interfaces that don't expose the data. It's not like that at all. It's more like what a C programmer writes when they're just learning C++ and object-oriented programming. There's not much of interfaces/ facades/ etc. for indirect access.
Well, indeed I was assuming Minecraft had either been built, or, after all this time, modified to implement proper encapsulation across the board. What you are telling me is a bit disappointing, but it does explain your criticism of Forge's adoption of type annotations.
I remember Jeb (or someone else?) criticizing a few years back the code for its lack of a more strict adherence to OO principles. It seems Notch was a bit sloppy about it. But until today it never occurred to me encapsulation at the class level was one of the problems.
Rollback Post to RevisionRollBack
I was trying to think of a signature and this is what came up.
The use of numeric IDs as opposed to the "new" system which references numeric IDs of blocks through an abstraction layer (numbers... indeed the same numbers are still being used internally with Minecraft) are not necessary for a functioning API. One does not necessarily follow the other and the API could have been released without it.
No doubt it will be useful, and in the bug tracker that Mojang uses for API suggestions, it was a major area of discussion and seen as essential in a proper API implementation. Don't buy into the notion though that it was required before an API could be released.
Dear God, I pray that this never happens. Forge has its use, and I hope that the Mojang developers intelligently review some of the ideas that have been incorporated into Forge, but for all that is good and wholesome Forge is the worst thing that could be adopted into the vanilla code base. Forge has its use, but it is also bloated and has a number of awful features too.
Besides, Jeb has flat out rejected the notion on numerous occasions for the reason I'm using as well here to reject this notion. As a base to review some commonly requested API features perhaps, but it is very unlikely to actually happen in this way. Besides, there will continue to be something called "Forge" even after the official API comes out, as some in the mod development community will still want to be pushing the API frontier and do things that the API doesn't yet permit. Even if it isn't called necessarily "Forge", it will still exist even in spirit.
The obfuscated name changing thing is seen as a legal requirement. I don't know what legal requirement and it seems incredibly silly to me as Mojang has been active in assisting the MCP team in deobfuscating the names (sort of defeating the point of the obfuscation) but none the less it is something that is unlikely to ever change until Mojang (read Notch in particular) decides to release Minecraft to the world under the GPL or a similar free software license.
Version 2.1 now updated for MC 1.6.2
I disagree. The second Mojang finishes that thing they are utterly outmoded by the plugin community. It wouldn't surprise me if the API is the very last official update from Mojang before closing shop on Minecraft.
I disagree. The second Mojang finishes that thing they are utterly outmoded by the plugin community. It wouldn't surprise me if the API is the very last official update from Mojang before closing shop on Minecraft.
If that is what actually happens, Mojang might as well not even bother as the 3rd party development community (aka the "mod developers") can and will come up with something better anyway.
The point of an official API library is to legitimize 3rd party plug-ins for people who are perhaps timid when thinking about doing stuff like opening the minecraft.jar file or doing other deep levels of modification of the game. Yes, I know that isn't needed any more, but my point is that a true plug-in is going to extend the life span of Minecraft and let it continue to be a cash cow for Mojang. If they are simply turning Minecraft loose in the public domain and moving on to the next cool project, the mod community can and will take over.
I would expect that a public domain/GPL'd version of Minecraft would simply be forked into a dozen different games (or more). There really wouldn't be a need for an API at that point beyond Forge/ModLoader/something else.
Version 2.1 now updated for MC 1.6.2
OK, I'm not getting how Forge is bloated. I mod, and I really don't see much in there that doesn't seem plausibly useful. Forge is bloaty in a sense in that there are a lot of different ways people want to mod and Forge tries to accommodate them all. But I see this as a good thing.
My only beef with Forge is how they use annotations for programming. It short-circuits all the type-safety and compile-checking that Java provides. I have literally spent hours trying to figure out why something isn't working when I've annotated improperly (most recently on an event screening call); if this had been done in a traditional OO manner with something like abstract classes I'd have gotten the whole thing right as soon as my type-ahead options popped up. But beef notwithstanding, I'd much rather struggle occasionally with annotation programming than wait another 2 years or whatever for a stable API. The base Minecraft code is hardly the exemplar of good OO programming either, even if its flaws run in an entirely different direction than Forge's do.
Mojang doesn't need to stop obfuscating their code, they just need to stop changing what each function obfuscates to. I can kind of see copyright reasons they might want to obfuscate for, but I really can't see any reason they have to change the obfuscation with some - but not all - revisions.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Eventually, Mojang is going to have to move on to other projects. It happens with every game, and will be necessary for them to survive as a company. There will come a point when there are so few people buying new copies of Minecraft that it will become seemingly useless to continue to release updates for it. This doesn't mean that the community is going anywhere, it will still be filled with millions of players who want to see new features, but as Mojang doesn't require payment for updates, the community won't be able to support the largest portion of Mojang's income.
I see the plugin API as a way for Mojang to step back. If it's made easier for the community to provide updates themselves, then Mojang will no longer need to spend time working on updates, freeing them up to develop more products and move on as a company.
The good folks at Forge are already making modding increasingly easier, but the plugin API will ultimately let the community take helm of the game's development. This may or may not make Forge and MCP completely useless, I for one hope it doesn't, they both do great work.
Mojang will never just 'forget' Minecraft though, after all, it is the game that started it all. They want to give it a proper send off, and what better way is there than to make all future updates 100% community developed.
I don't do any modding at all, but I find this argument of yours a little strange. I do agree with everything else in your post.
Type annotations are prime candidates for a pluggable system such that which is offered by Forge. Since Minecraft doesn't expose any of its classes, your only access to their code is through type annotations (once their classes names are deobfuscated and their general functionality understood).
Sure, you could abstract this away from the modders by creating a proper OO interface to the type annotations. Essentially, hide the Forge details from the modder and present instead a OO centric approach to modding. But I think the overhead would be too much for modders to be able to code all but the simplest of mods.
Because Minecraft doesn't expose any of its classes, type annotations are the most reliable and direct away to plug in to the code at runtime. And modders just have to learn to live with the difficulties of this programming paradigm.
The complexities of Forge modding turned me off from ever trying to mod with Forge, especially when you want to do the kind of stuff I do; for example, I posted a thread a while back on how to replace the vanilla cave generator using Forge (I'm guessing nobody knows how), and that was before all of my changes to terrain generation with a total of 17 base classes modified (22 for my own version as I removed torches from mineshafts and strongholds so a mapping utility I use doesn't show them when mapping underground areas).
Not like it causes any problems while playing either even though I use Forge for other mods and it refuses to run the game unless I tell it to ignore the changes I made (that said, I used the decompiled Forge source (exact same version, 9.10.0.842) for my own version of my mods so the changes that Forge refuses to apply to modified classes are present (lines like MinecraftForge.Event); the ones I provide for download are based on vanilla code).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
I don't know if annotations can be used to get around hidden code; that would be a reasonable use; but that isn't what Forge uses it for. Minecraft doesn't hide the code in the sense that you can't look at it, but only in the sense that it obfuscates the names. MCP provides deobfuscation/obfuscation tools which let modder code in the normal names - when it's out, of course - we're still waiting for MCP for 1.7. Forge does nothing for the obfuscation.
What Forge uses annotations for is communication between the mod and Forge. So, for example, if you want to screen or modify an event generated outside of your mod, you write a modifier object and pass it to Forge. However, the code doing the pass has to be flagged with an annotation as well. And, if the types aren't all correct, it just fails silently. I can see some reason for this; they could be and probably are using the annotation parameters to determine what types of events your object should receive. But, I can think of at least two ways to do the same thing in a standard OO format so you'd have type safety and using the wrong object class would be caught at runtime.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
By "Minecraft doesn't expose any of its classes", I mean these are not public classes that can be accessed from external code. Expose is being used in the context of Java OO access levels.
I'm not sure what other methods you say exist that allow you to tap into package-private classes and that can be reliably and efficiently used for the development of a mod/plugin API. But I'd honestly like to know.
Got it. You're right, that is hidden, or it's *supposed* to be. But Java reflection allows you to get at private access fields and methods - one of the reasons Java is no longer considered "safe" for browser use.
Forge also uses a lot of code patches, where they change a compiled file prior to loading it. Also one of the reasons Java is no longer considered a secure system.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Yes, and I even change how some of the classes are declared; for example, here is the vanilla MapGenCaves, which extends another class:
In my version:
So what I did was combine those two classes (I also modified MapGenBase to increase the range of chunks it checks to accommodate larger caves and ravines, but I also made it so that only the largest systems actually use a larger range for efficiency, plus I have six separate cave/ravine generators), as well as with MapGenRavine, so I now have a single class that contains the equivalent of three separate classes, so I only need to work with one file (this also requires modifying ChunkProviderGenerate to change the reference to MapGenCaves and remove MapGenRavine, though I modified it anyway to change terrain; MapGenBase is still used by some other classes but MapGenRavine becomes dead code when my mod is added).
Now, about what Forge does, when I look at the source with the Forge patches applied (note that Forge normally adds patches at runtime; the "Forge" jar is really a renamed vanilla jar with Forge added as a library), I see lines like this:
MapGenCaves also has some code added by Forge to allow caves to cut through custom biome surface blocks (other than dirt and grass, incidentally, this is why vanilla caves don't cut through deserts or mesas) although I removed it altogether as I made caves only cut through stone except for a special type, which makes the code cleaner and probably a bit faster (in-line code is faster than calling a method, as is only doing one comparison as opposed to three, similarly, I removed the code that checks for water in the path of a ravine (also changed by Forge and reverted to the vanilla code for caves), to avoid cutting across rivers, as they can't cut through the surface in any case, which also prevents malformed ravines).
This also means that while I used the Forge source to make my mod for myself, I can simply copy+paste most of MapGenCaves (except for the package name and imports, as Forge changes them) into my vanilla source-based version of my mods (which are also for 1.6.4, I use the 1.6.2 Forge source); other classes have lesser changes and can be easily changed by hand (and yes, I have a text file with a list of files and what to change).
Of note, I also add my mod to Forge as a library, as described here, so the actual jar isn't modified, which also makes it very easy to change without having to replace the jar.
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Reflection is extraordinarily expensive for non event driven applications. We are talking about a method of accessing external package-private classes that up until recently was an order of magnitude (10x) for method calls with lookup and 3x more expensive for method calls without lookup.
It simply isn't possible to create a performant plugin API like Forge based on reflection. And this is the reason why they didn't do it in the first place. I suppose it could have been done for some parts of the code that don't need to run on a frame-by-frame basis, but then you'd have a inconsistent API that forced you to mishmash several methods of programming. That is undesirable. And would still not answer the performance issues it could bring in to the game.
I suppose. Type Annotations (or Reflection, since we are also talking about this possibility) can't answer all the modding needs. Particularly when it comes to actual behavior changing of existing methods. But if you are implying the Forge API could be coded on this principle, you must consider that what this means is that Forge would in fact have to patch the whole Minecraft code base, which would essentially make it a complete Minecraft binary. No mod API is created on a patch principle for this reason. It's just not possible to patch the entire code base and expect this to become a reliable and efficient API.
I think you mean this twitter? Well, that's the type of stuff we have been hearing since 2010. How can such a laconic statement that ignores years of failed promises (as if this was the first time he or anyone else at Mojang promised the plugin API) can be made out to be a definite Yes?
I think some readers of this thread still didn't get it, maybe because they didn't read the whole thread yet. We have been promised the Plugin API with statements like those since 2010. Alright?
I'm not a modder (which I'm sure is no surprise) but I do like to create game-breaking modpacks for fun. It would be nice to more easily cram mods together, but I'm a vanilla player at heart. Probably why I'm not so concerned about the 'lies' Mojang are apparently guilty of telling.
I think you have this image of Minecraft as being written in a "classic" OO format, with tightly encapsulated private classes implementing public interfaces that don't expose the data. It's not like that at all. It's more like what a C programmer writes when they're just learning C++ and object-oriented programming. There's not much of interfaces/ facades/ etc. for indirect access. If a routine or a field needs to be used outside of its package, it's public access. If only in its package, it's often package private; but if necessary MCP can compile mod code into an existing Minecraft package so that's accessible too. As a rule, though, Minecraft packages are organized around function rather than data access so most of what you want is already public.
Generally speaking if a modder wants access to a routine or piece of data, something outside of the class uses it in Minecraft and access is not an issue. In writing 2 medium-sized mods, I think I encountered 2 or 3 situations where access rights were a problem.
I haven't looked at a lot of Forge code, but generally they just access what they want, same as I do. Every time I've seen that they can't they use a code patch.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Well, indeed I was assuming Minecraft had either been built, or, after all this time, modified to implement proper encapsulation across the board. What you are telling me is a bit disappointing, but it does explain your criticism of Forge's adoption of type annotations.
I remember Jeb (or someone else?) criticizing a few years back the code for its lack of a more strict adherence to OO principles. It seems Notch was a bit sloppy about it. But until today it never occurred to me encapsulation at the class level was one of the problems.