1. MCP is REQUIRED to mod, else you would need to write out your own obfuscation tables and learn how to mod with everything named a, b, c, aa, ab, ac, etc.
2. Forge is required but its recommended as it makes the job so much easier, as you don't need to work out where to add what code in what class, and it increases compatibility, like it or not, when a mod adds an item, without an API, it must do so by adding code to the Item class, else the programmer would need to do some tricky reflection to add it in to the items list.
3. You don't know what you're talking about. Minecraft is coded in an Object-Oriented Language, Java, Forge is a derivative work of Minecraft, thus, it's coded in Java, mods are derivative works of both Forge and Minecraft, thus they're coded in Java.
Learn and think before you respond, else you'll start a flame war.
The fact that this happens, tells me that people need to stop relying on mods like MCP and Forge to write Minecraft mods. Please, modders, learn Java. If you just follow tutorials on how to use MCP or Forge, you're not really learning how to program, you're learning how to script.
If you actually learn the inner-workings of Java, you'll be able to make your own mods, and you'll be able to make your mods compatible with others without MCP or Forge.
I do agree that the universalization that these mods create is a good idea, but they limit the creativity of developers, and slow down the process.
P.S.- In order to make your mod compatible with other mods, you only need to make sure that you don't overwrite any classes, and you need to make sure that any common-altered classes are combined with each other so that none of the code is erased. You can still mod Minecraft without them!! (I know, hard to believe, right?)
what the above said but if you believe that all this is sooooo easy go on try it yourself!
us modders work our ass off for you guys give us some respect please
For those who this we JUST have to learn Java to make our mods it would be necessary to explain some things.
MCP give us a decompiled game code, this is easy to do, but it would be impossible to use because it is obfuscated, this means that this code is almost impossible to use because names don't mean a thing.
MCP tries to reconstruct some readable code that we can use, it a very difficult task to guess what means what and slowly rebuild a source code that can be used.
Then once modified it also has to be reobfuscated.
But then the problem is that in this way we modify the original game files and if two mods modify the same file it will not work.
So Forge gives us a solution by dynamically modifying the code using hooks, in this way the original game files are not edited and this ensure a far better compatibility between mods.
Making mods without using MCP and Forge is possible but it would be a real pain in the ass and we would no be able to use many mods at once.
For those who this we JUST have to learn Java to make our mods it would be necessary to explain some things.
MCP give us a decompiled game code, this is easy to do, but it would be impossible to use because it is obfuscated, this means that this code is almost impossible to use because names don't mean a thing.
MCP tries to reconstruct some readable code that we can use, it a very difficult task to guess what means what and slowly rebuild a source code that can be used.
Then once modified it also has to be reobfuscated.
But then the problem is that in this way we modify the original game files and if two mods modify the same file it will not work.
So Forge gives us a solution by dynamically modifying the code using hooks, in this way the original game files are not edited and this ensure a far better compatibility between mods.
Making mods without using MCP and Forge is possible but it would be a real pain in the ass and we would no be able to use many mods at once.
Please, modders, learn Java. If you just follow tutorials on how to use MCP or Forge, you're not really learning how to program, you're learning how to script.
I must admit I wholeheartedly agree with you on this point!
I'm studying programming and I try my best to make modders learn the fundamentals.
Sadly most don't bother learning which is why most mods never do anything original or clever.
That being said, most of the popular mods are made by people with programming education/experience.
If you actually learn the inner-workings of Java, you'll be able to make your own mods, and you'll be able to make your mods compatible with others without MCP or Forge.
I do agree that the universalization that these mods create is a good idea, but they limit the creativity of developers, and slow down the process.
I must however disagree with this part of your logic, the Forge framework is good.
It's of course fully possible to work without it, and you can easily make mods without doing base edits without using forge.
But that would usually require much much more time spent on re-inventing the wheel when forge & fml usually are out within 2-3 days of an update.
When it comes to MCP then I must say I can't imagine I'd bother spending weeks creating my own deobfuscation system, considering how many contributions are made to the tables mcp uses for name mapping I'd say it wouldn't be probable to assume one could get things done faster by not using MCP. Of course for simple mods I can surely see how you won't need MCP at all
To summarize:
I agree that one shouldn't even start modding without a SOLID understanding of programming.
I do not agree that one should do this without mcp, except for in some limited cases.
Forge is in my opinion great, but not using forge is fine. Avoiding the use of FML however is not something I would consider a smart move. I wouldn't see skipping MCP&Forge to help out in terms of time spent developing as you would spend less time on features more on your own framework which in turn every modder would make on their own, having a standard common one is simpler for the user and for the developer.
It's of course fully possible to work without it, and you can easily make mods without doing base edits without using forge.
Hmm...while this may be true, good luck doing anything substantial.
And...
When it comes to MCP then I must say I can't imagine I'd bother spending weeks creating my own deobfuscation system
Sorry, I meant ModLoader, that's my mistake. MCP is a very useful tool!
My only reasoning for saying to forget about Forge/ModLoader/any other modding API is that they limit what you can do substantially.
If you're only looking to add some blocks or maybe a new mob to the game, then sure! go ahead!
But if you're looking to make something like the shaders mod, or change the lighting engine, or anything like that...there's really no point.
Rollback Post to RevisionRollBack
If I helped you, return the favor by pressing the green arrow over there -------------->
Hmm...while this may be true, good luck doing anything substantial.
And...
Sorry, I meant ModLoader, that's my mistake. MCP is a very useful tool!
My only reasoning for saying to forget about Forge/ModLoader/any other modding API is that they limit what you can do substantially.
If you're only looking to add some blocks or maybe a new mob to the game, then sure! go ahead!
But if you're looking to make something like the shaders mod, or change the lighting engine, or anything like that...there's really no point.
You have a point in saying shaders mods and all that, but there are ways to make them in Forge, using the ASM libraries and the Reflection API, you could probably manage to inject calls to custom classes and replace code (I have yet to mess with ASM in Forge sooo yeah).
Really, I find that, depending on what you want to do, Forge actually offers you to do more than vanilla alone does. Forge includes so many utility classes that it isn't funny, it even gives you some optimisation of the code.
It really boils down to personal preference when choosing between using Forge, ML, or pure base edits. Base edits are pretty much dead, the new Minecraft tweaks system adds in the ability to hook into the loading of the game, in such a way you don't have to call back to a load method in the base classes.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
Actually the facts are that almost all modders use MCP at least and forge also, the proof is easy, just have a look and tell me how many mods do exist for 1.7...
I know there is TMI and maybe some others but everybody is waiting on MCP, not because they are lazy, but because when you got good tools you tend to use them.
As someone says, you can always reinvent the weehl everyday, but in this way there will still be no cars, maybe some wooden charriots pulled by buffalos.
This may be slightly off topic but I read this on the forge website:
Build 1.6.4-9.11.1.944:
cpw:
Updated FML:
MinecraftForge/FML@f4532410ec1dbf43ce15dfa78d07e5f7be408b08 Change a couple of warnings, as a prelude to 1.7- preinit is now required for all GameRegistry activity, and every item and block REQUIRES registration.
And was wondering if that means blocks and items will be separate instances, like entities. If they will be, it could help out a lot (No more annoying ItemStacks or TileEntities to work with) but it is just a guess. Does anybody know?
This may be slightly off topic but I read this on the forge website:
Build 1.6.4-9.11.1.944:
cpw:
Updated FML:
MinecraftForge/FML@f4532410ec1dbf43ce15dfa78d07e5f7be408b08 Change a couple of warnings, as a prelude to 1.7- preinit is now required for all GameRegistry activity, and every item and block REQUIRES registration.
And was wondering if that means blocks and items will be separate instances, like entities. If they will be, it could help out a lot (No more annoying ItemStacks or TileEntities to work with) but it is just a guess. Does anybody know?
What do you mean by no more ItemStacks or TileEntities? Those two are separate from Items and Blocks at a core level, an ItemStack is a stack in itself, regardless of the item in it (although it reflects certain information of the item it stores), and TileEntities are a form of enhanced block metadata, regardless of registration of items and blocks, these two will still exist.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
The line you indicate only means that you need to FULLY instantiate blocks and items during the PRE-INIT step.
A common way to do it has been to grab ID's in pre-init and instantiate the blocks & items during the init(load) step.
(No more annoying ItemStacks or TileEntities to work with)
Sure I can probably spend some time and write a core mod which removes the need for TileEntities but that would either mean you would ONLY have basic blocks or all blocks would essentially be Tile Entities in functionality which in turn would crash most computers lolz.
I'd suggest you dive into how and why TileEntities work. Then you will be able to appreciate them more and hopefully you won't find them annoying to work with anymore :=)
I was saying this because, if blocks and items were separate instances, like entities, their properties could be stored in the instance, like an entity stores it's motion. I like tileentities, but it is hard to make separate itemstacks have dynamicaly changing properties. All there is is the stacktagcompound, when I would rather have a separate int variable, like damage, which is written to NBT when saving, to store things like cooldown.
Well, looks like I need to get back to my workarounds then. How exactly are blocks stored when the game runs? In hash maps? How are they not separate instances?
Internally blocks are stored by ID's the BlockID. This will NOT change in 1.7 although we will not have to deal with it directly anymore.
However it will still be the underlying principle.
A Block is stored into an ExtendedBlockArray inside the chunk.
This array divides the Block's Integer value into two halfs (Bit shifting and so on) with the Least Significant Bit (LSB) and the Most Significant Bit (MSB) in their own arrays.
You can find this by diving into the call order of the World#GetBlockID(X,Y,Z) or World.SetBlock(x,y,z).
There only ever exists 1 instance of the Block.
However for every place in the world there also exists a 16bit lump of memory called Metadata, this is used to store small information such as orientation or state information (active/inactive) for things like the furnace.
In addition to this there is the option of having a TileEntity which can be instantiated at every block's location and can therefore contain unique data for it's specific location in the world.
It also contains methods for saving and loading the data to NBT as well as methods being called every tick.
MOST blocks in minecraft however does NOT need a TileEntity and does NOT use one, which is why the ones that do is the exception and not the rule. Minecraft takes a lot of power to run, there are a lot of blocks stored in RAM, imagine if it wasn't Integer(it's a Short actually but whatever) values but Objects instead, then the memory needed would be A LOT bigger.
I hope this clears up any confusion
Also I HIGHLY recommend reading this blog: greyminecraftcoder.blogspot.no/p/list-of-topics.html
Starting with this post which simply explains how Blocks work in minecraft, and all the I said above: http://greyminecraftcoder.blogspot.com.au/2013/07/blocks.html
Yes, i completely forgot bocks were just stored by their IDs. HOWEVER, every ItemStack is a separate instance, so would it do any harm to make Items be separate instances? Instead of having ItemStack objects, make your items objects. It would be the same thing I think, so why isn't it like that?
P.s. Is there any way to make a class that is an extension of ItemStack and make it have custom properties, and make your items use it?
i stumbled into here looking for a 1.7.2 forge src after seeing this https://twitter.com/minecraftcpw/status/411267309685047296
This does show that there is a version of forge for 1.7.2 (look at the picture in the linked image) however it appears at mo they are keeping it private...which is frustrating as i would like to see how much of the code changes break my mod and make a start fixing it
First of:
Keeping it private?
Where on earth did you get that notion?!
FML, Forge and ForgeGradle are all OpenSource, you can fork and play with the same files as CPW has anytime ya want!
Secondly that screenshot does not show anything about the Forge source.
Thats FML as you can read on the mods list to the right.
You can check the MinecraftForge repo to confirm that there are no 1.7.2 source yet!
Yes, i completely forgot bocks were just stored by their IDs. HOWEVER, every ItemStack is a separate instance, so would it do any harm to make Items be separate instances? Instead of having ItemStack objects, make your items objects. It would be the same thing I think, so why isn't it like that?
P.s. Is there any way to make a class that is an extension of ItemStack and make it have custom properties, and make your items use it?
Currently, each 'Item' is instantiated as a static object so that there is only one instance, to which we can refer by a simple integer ID and immediately retrieve all the basic information that loads at run-time. In this way, ItemStacks can store a lot of information with just a single integer, and NBT tags exist for those items that require additional information. If every item in the game were to be stored not as a single integer but instead as an entire object, then world saves would also experience a huge amount of bloat. Just think of your chests full of stuff, which currently require only a few bytes per itemstack (in general) to store, but would require substantially more otherwise.
Not to mention that having an instance for every single item would break ItemStacks as they are currently implemented in that each ItemStack would only ever be able to contain one Item, just like Items with NBT currently are. You would no longer be able to have a stack of 64 blocks of dirt, because each of those might contain different information; of course you could check for this when putting stacks together, but then you have to check all of the variables (name, hardness, blast resistance, etc. as well as handle the possibility of additional unknown variables added only to specific types of Items / Blocks) rather than simply checking if the ids match.
In short, it's possible, but not prudent or efficient in most cases. In the cases where it would be beneficial, such as Items that store lots of extra information already (i.e. NBT) or are already limited to stack sizes of one (e.g. tools), the problem is simply that that's not how Minecraft has been coded. Perhaps in 1.7 that will change, but I doubt it, the reason being that NBT is a really handy data structure format that already effectively stores individual Item data for a specific instance of an Item. All you have to do is add whatever data you want to it and it will save and load automatically, ready to retrieve whenever you need it. That's pretty slick, in my opinion.
Agreed
Also
what the above said but if you believe that all this is sooooo easy go on try it yourself!
us modders work our ass off for you guys give us some respect please
MCP give us a decompiled game code, this is easy to do, but it would be impossible to use because it is obfuscated, this means that this code is almost impossible to use because names don't mean a thing.
MCP tries to reconstruct some readable code that we can use, it a very difficult task to guess what means what and slowly rebuild a source code that can be used.
Then once modified it also has to be reobfuscated.
But then the problem is that in this way we modify the original game files and if two mods modify the same file it will not work.
So Forge gives us a solution by dynamically modifying the code using hooks, in this way the original game files are not edited and this ensure a far better compatibility between mods.
Making mods without using MCP and Forge is possible but it would be a real pain in the ass and we would no be able to use many mods at once.
Good point good point
I must admit I wholeheartedly agree with you on this point!
I'm studying programming and I try my best to make modders learn the fundamentals.
Sadly most don't bother learning which is why most mods never do anything original or clever.
That being said, most of the popular mods are made by people with programming education/experience.
I must however disagree with this part of your logic, the Forge framework is good.
It's of course fully possible to work without it, and you can easily make mods without doing base edits without using forge.
But that would usually require much much more time spent on re-inventing the wheel when forge & fml usually are out within 2-3 days of an update.
When it comes to MCP then I must say I can't imagine I'd bother spending weeks creating my own deobfuscation system, considering how many contributions are made to the tables mcp uses for name mapping I'd say it wouldn't be probable to assume one could get things done faster by not using MCP. Of course for simple mods I can surely see how you won't need MCP at all
To summarize:
I agree that one shouldn't even start modding without a SOLID understanding of programming.
I do not agree that one should do this without mcp, except for in some limited cases.
Forge is in my opinion great, but not using forge is fine. Avoiding the use of FML however is not something I would consider a smart move. I wouldn't see skipping MCP&Forge to help out in terms of time spent developing as you would spend less time on features more on your own framework which in turn every modder would make on their own, having a standard common one is simpler for the user and for the developer.
Hmm...while this may be true, good luck doing anything substantial.
And...
Sorry, I meant ModLoader, that's my mistake. MCP is a very useful tool!
My only reasoning for saying to forget about Forge/ModLoader/any other modding API is that they limit what you can do substantially.
If you're only looking to add some blocks or maybe a new mob to the game, then sure! go ahead!
But if you're looking to make something like the shaders mod, or change the lighting engine, or anything like that...there's really no point.
You have a point in saying shaders mods and all that, but there are ways to make them in Forge, using the ASM libraries and the Reflection API, you could probably manage to inject calls to custom classes and replace code (I have yet to mess with ASM in Forge sooo yeah).
Really, I find that, depending on what you want to do, Forge actually offers you to do more than vanilla alone does. Forge includes so many utility classes that it isn't funny, it even gives you some optimisation of the code.
It really boils down to personal preference when choosing between using Forge, ML, or pure base edits. Base edits are pretty much dead, the new Minecraft tweaks system adds in the ability to hook into the loading of the game, in such a way you don't have to call back to a load method in the base classes.
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!
I know there is TMI and maybe some others but everybody is waiting on MCP, not because they are lazy, but because when you got good tools you tend to use them.
As someone says, you can always reinvent the weehl everyday, but in this way there will still be no cars, maybe some wooden charriots pulled by buffalos.
Build 1.6.4-9.11.1.944:
cpw:
Updated FML:
MinecraftForge/FML@f4532410ec1dbf43ce15dfa78d07e5f7be408b08 Change a couple of warnings, as a prelude to 1.7- preinit is now required for all GameRegistry activity, and every item and block REQUIRES registration.
And was wondering if that means blocks and items will be separate instances, like entities. If they will be, it could help out a lot (No more annoying ItemStacks or TileEntities to work with) but it is just a guess. Does anybody know?
What do you mean by no more ItemStacks or TileEntities? Those two are separate from Items and Blocks at a core level, an ItemStack is a stack in itself, regardless of the item in it (although it reflects certain information of the item it stores), and TileEntities are a form of enhanced block metadata, regardless of registration of items and blocks, these two will still exist.
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!
A common way to do it has been to grab ID's in pre-init and instantiate the blocks & items during the init(load) step.
Sure I can probably spend some time and write a core mod which removes the need for TileEntities but that would either mean you would ONLY have basic blocks or all blocks would essentially be Tile Entities in functionality which in turn would crash most computers lolz.
I'd suggest you dive into how and why TileEntities work. Then you will be able to appreciate them more and hopefully you won't find them annoying to work with anymore :=)
However it will still be the underlying principle.
A Block is stored into an ExtendedBlockArray inside the chunk.
This array divides the Block's Integer value into two halfs (Bit shifting and so on) with the Least Significant Bit (LSB) and the Most Significant Bit (MSB) in their own arrays.
You can find this by diving into the call order of the World#GetBlockID(X,Y,Z) or World.SetBlock(x,y,z).
There only ever exists 1 instance of the Block.
However for every place in the world there also exists a 16bit lump of memory called Metadata, this is used to store small information such as orientation or state information (active/inactive) for things like the furnace.
In addition to this there is the option of having a TileEntity which can be instantiated at every block's location and can therefore contain unique data for it's specific location in the world.
It also contains methods for saving and loading the data to NBT as well as methods being called every tick.
MOST blocks in minecraft however does NOT need a TileEntity and does NOT use one, which is why the ones that do is the exception and not the rule. Minecraft takes a lot of power to run, there are a lot of blocks stored in RAM, imagine if it wasn't Integer(it's a Short actually but whatever) values but Objects instead, then the memory needed would be A LOT bigger.
I hope this clears up any confusion
Also I HIGHLY recommend reading this blog: greyminecraftcoder.blogspot.no/p/list-of-topics.html
Starting with this post which simply explains how Blocks work in minecraft, and all the I said above:
http://greyminecraftcoder.blogspot.com.au/2013/07/blocks.html
P.s. Is there any way to make a class that is an extension of ItemStack and make it have custom properties, and make your items use it?
First of:
Keeping it private?
Where on earth did you get that notion?!
FML, Forge and ForgeGradle are all OpenSource, you can fork and play with the same files as CPW has anytime ya want!
Secondly that screenshot does not show anything about the Forge source.
Thats FML as you can read on the mods list to the right.
You can check the MinecraftForge repo to confirm that there are no 1.7.2 source yet!
Currently, each 'Item' is instantiated as a static object so that there is only one instance, to which we can refer by a simple integer ID and immediately retrieve all the basic information that loads at run-time. In this way, ItemStacks can store a lot of information with just a single integer, and NBT tags exist for those items that require additional information. If every item in the game were to be stored not as a single integer but instead as an entire object, then world saves would also experience a huge amount of bloat. Just think of your chests full of stuff, which currently require only a few bytes per itemstack (in general) to store, but would require substantially more otherwise.
Not to mention that having an instance for every single item would break ItemStacks as they are currently implemented in that each ItemStack would only ever be able to contain one Item, just like Items with NBT currently are. You would no longer be able to have a stack of 64 blocks of dirt, because each of those might contain different information; of course you could check for this when putting stacks together, but then you have to check all of the variables (name, hardness, blast resistance, etc. as well as handle the possibility of additional unknown variables added only to specific types of Items / Blocks) rather than simply checking if the ids match.
In short, it's possible, but not prudent or efficient in most cases. In the cases where it would be beneficial, such as Items that store lots of extra information already (i.e. NBT) or are already limited to stack sizes of one (e.g. tools), the problem is simply that that's not how Minecraft has been coded. Perhaps in 1.7 that will change, but I doubt it, the reason being that NBT is a really handy data structure format that already effectively stores individual Item data for a specific instance of an Item. All you have to do is add whatever data you want to it and it will save and load automatically, ready to retrieve whenever you need it. That's pretty slick, in my opinion.