I don't know about Alpha but pretty much everything I know about modding 1.6.4 came from looking at how it was done in vanilla, ranging from adding new blocks/items to mobs/entities, biomes, world generation, rendering, etc; adding an new block (in 1.6.4) can be as simple as adding a new entry in the Block class:
public static final Block cobblestone = (new Block(4, Material.rock)).setHardness(2.0F).setResistance(10.0F).setStepSound(soundStoneFootstep).setUnlocalizedName("stonebrick").setCreativeTab(CreativeTabs.tabBlock).setTextureName("cobblestone");
More complex blocks have their own subclass which overrides methods to do something more than the default behaviors (e.g. wool overrides getIcon to return a different texture depending on its data value, some other things also need to be overridden as well and you may want to add a crafting recipe but all of this can be found by looking at examples in vanilla). You can also replace existing vanilla blocks and items by assigning your own classes to the existing fields, though it is important to note that they must extended and cast to the original classes if their fields aren't just types of "Block" and "Item" (I once had an issue with MCP reobfuscating classes that I hadn't modified at all and omitting these classes caused the game to crash unless they were no longer referenced, and I found it was due to changing references like "BlockGrass" to "Block"):
// Note that field is a generic "Block" type (both examples shown are the same as vanilla)
public static final Block planks = new BlockPlanks(BlockStates.planks);
// Note that field is of type "BlockLeaves", thus my custom class extends it even though all vanilla code
// was overridden
public static final BlockLeaves leaves = (BlockLeaves)(new BlockLeavesTMCW(BlockStates.leaves));
Obviously, adding entirely new features from scratch (no comparable vanilla features/code available) is a bit more difficult but at this point it basically comes down to programming knowledge in general (for example, how to add a zoom feature like Optifine's? Start with the observation that lowering the FOV appears to zoom in (and indeed, this is how "zoom" works) and find the code that deals with FOV (e.g. the "GameSettings" class has a field named "fovSetting"*, so search for "fovSetting" to find the code that actually uses it); then add in code that checks if a key is pressed (see how vanilla checks for keypresses) and if so apply a modifier to "fovSetting", and optionally, enable smooth camera).
*Any class/method/field names and code mentioned here may not be the same in Alpha; MCP has changed the names they used over time and some may be non-intuitive or even outright misleading, even in newer versions e.g. "Block.canBlockGrass" (what does that even mean? Only the smooth lighting code uses this so it has nothing to do with grass) should really be called "Block.isBlockTransparent", which I renamed it to; likewise, "Block.getBlocksMovement" gave me headaches for a while until I realized it actually meant the opposite, thus I renamed it to "Block.getAllowsMovement", or rather, added a new method that returns the original method to maintain compatibility with unmodified vanilla code. Some fields and methods also have names like "field_12345", which will require looking at the code that uses them to figure out what they are for; the majority of fields and methods do have sensible names and comments describing them though, at least in 1.6.4).
Ok thanks you soo much!:D, were i can find an entire guide o do that?
For modding have i to create new classes in mcp projects or in separate folders like in the modern minecraft modding?
I don't know of any guides for such old versions; it also seems like everybody uses Discord these days, which seems to requires an invitation or at least an account to even view anything (I've never used it but I've clicked on links to it and it told me to register), as opposed to public forums like these, which I think is quite unfortunate and it only worsens the issue of trying to find help unless you actually ask around (there is a link to Discord in the "Modification Station" spoiler in this thread which says it is mainly about modding Alpha and Beta versions; of course, I can't actually see the forum (or whatever Discord calls them) it links to).
That said, a lot of my modding involves simply modifying existing classes; for example, this shows how extensively I've modified the "World" class, which contains most of the logic used to run a world and access its data; this includes references to my own code in separate classes (in general I'll extend/completely replace vanilla classes if there are no direct references to them in unmodified vanilla code). I just add new classes to the "mcp\src\minecraft\net\minecraft\src" folder, where MCP places most of the vanilla source. I actually don't use an IDE; I use Notepad to edit the source and directly run "recompile.bat" to recompile them and "startclient.bat" to run the game, so just directly working within the MCP folder (if I need to find something I use a "grep" tool for Windows which integrates into the context menu that appears when you right-click a folder and is basically a more advanced version of Windows' file search. Having everything in a single "src" folder also makes it easier to find specific files; using consistent naming schemes for blocks/items/etc, e.g. "Block[Name]", "Item[Name]", "Entity[Name]" groups them together when sorted by name).
As mentioned before, looking at how something is done in vanilla is how I learned how to make my own mods; for example, this is my BlockBoneBlock class, which backports bone blocks to 1.6.4; it is basically a copy of the BlockLog class except there is only one variant (both extend "BlockRotatedPillar", which contains all the logic used to determine the direction logs face when placed and which sides have which textures based on its data value). For all I know, vanilla 1.10 uses the exact same code (probably not exactly, as 1.8 added "block states", not to be confused with my "BlockStates" which are int constants corresponding to block IDs and combined IDs/metadata):
To register it I added a new entry to the "Block" class, which contains a list of every block in the game:
public static final Block boneBlock = new BlockBoneBlock(BlockStates.boneBlock);
Then I added these lines to the "CraftingManger" class (or equivalent) to register recipes for crafting and uncrafting them:
par1CraftingManager.addRecipe(new ItemStack(Block.boneBlock, 1), new Object[] {"BBB", "BBB", "BBB", 'B', new ItemStack(Item.dyePowder, 1, ItemDye.BONEMEAL)});
par1CraftingManager.addRecipe(new ItemStack(Item.dyePowder, 9, ItemDye.BONEMEAL), new Object[] {"B", 'B', Block.boneBlock});
For a more complicated example, I added a red variant of clay blocks and clay items; in this case I completely replaced the original BlockClay class (I generally append "Fix" or "TMCW" to the end of the original name depending on why I changed it; "Fix" if I'm fixing vanilla bugs or making it compatible with changes I made elsewhere and "TMCW" if I've added new functionality):
// Original BlockClay class
package net.minecraft.src;
import java.util.Random;
public class BlockClay extends Block
{
public BlockClay(int par1)
{
super(par1, Material.clay);
this.setCreativeTab(CreativeTabs.tabBlock);
}
public int idDropped(int par1, Random par2Random, int par3)
{
return Item.clay.itemID;
}
public int quantityDropped(Random par1Random)
{
return 4;
}
}
// New class which completely replaces BlockClay (I could have extended it but the only method that wasn't
// changed was "quantityDropped"; I even deleted the original class to make the src folder cleaner)
package net.minecraft.src;
import java.util.Random;
import java.util.List;
public class BlockClayTMCW extends Block
{
// Added red clay variant
public static final int NORMAL = 0;
public static final int RED = 1;
public static final String[] VARIANTS = new String[] {"clay", "redClay"};
private Icon redClayIcon;
public BlockClayTMCW(int par1)
{
super(par1, Material.clay);
this.setHardness(0.6F);
this.setStepSound(soundGravelFootstep);
this.setUnlocalizedName("clay");
this.setTextureName("clay");
this.setCreativeTab(CreativeTabs.tabBlock);
}
// Used by items dropped without Silk Touch (returns clay item)
public int idDropped(int meta, Random par2Random, int fortune)
{
return (meta == RED ? ItemIDs.redClay : ItemIDs.clay);
}
public int damageDropped(int meta)
{
return 0;
}
public int quantityDropped(Random par1Random)
{
return 4;
}
// Used by items dropped with Silk Touch (returns the block itself)
protected ItemStack createStackedBlock(int meta)
{
return new ItemStack(this.blockID, 1, meta == RED ? RED : NORMAL);
}
// Used by pick-block
public int getDamageValue(World par1World, int posX, int posY, int posZ)
{
return par1World.getBlockMetadata(posX, posY, posZ) == RED ? RED : NORMAL;
}
public void registerIcons(IconRegister par1IconRegister)
{
this.blockIcon = par1IconRegister.registerIcon("clay");
this.redClayIcon = par1IconRegister.registerIcon("red_clay");
}
public Icon getIcon(int side, int meta)
{
return (meta == RED ? this.redClayIcon : this.blockIcon);
}
public void getSubBlocks(int par1, CreativeTabs par2CreativeTabs, List par3List)
{
par3List.add(new ItemStack(par1, 1, NORMAL));
par3List.add(new ItemStack(par1, 1, RED));
}
}
Instead of adding a new entry to the Block class I replaced the original entry; another difference from bone blocks is that I had to register an "ItemBlock" which supports metadata, otherwise it will be ignored (i.e. red clay is placed as normal clay):
// Vanilla
public static final Block blockClay = (new BlockClay(82)).setHardness(0.6F).setStepSound(soundGravelFootstep).setUnlocalizedName("clay").setTextureName("clay");
// TMCW
public static final Block blockClay = new BlockClayTMCW(BlockStates.blockClay);
// This is placed in a section near the bottom of the class, where there is a list of similar lines of code
// (vanilla uses "ItemMultiTextureTile" while I replaced "ItemBlock" with a single universal class which
// uses flags to set whether metadata is used):
Item.itemsList[blockClay.blockID] = new ItemBlockFix(blockClay, BlockClayTMCW.VARIANTS, ItemBlockFix.MULTITEXTURE);
Likewise, I replaced the recipe for vanilla clay to only accept one data value (recipes ignore data values by default), with new recipes for red clay and dying normal clay red added:
// Added red clay recipes and made original recipe only work with normal clay
par1CraftingManager.addRecipe(new ItemStack(Block.blockClay, 1, BlockClayTMCW.NORMAL), new Object[] {"##", "##", '#', Item.clay});
par1CraftingManager.addRecipe(new ItemStack(Block.blockClay, 1, BlockClayTMCW.RED), new Object[] {"##", "##", '#', Item.redClay});
par1CraftingManager.addShapelessRecipe(new ItemStack(Block.blockClay, 1, BlockClayTMCW.RED), new Object[] {new ItemStack(Block.blockClay, 1, BlockClayTMCW.NORMAL), new ItemStack(Item.dyePowder, 1, ItemDye.RED)});
I also added a new entry to the "Item" Class to register my red clay item, which is basically the same as for vanilla clay, just a different ID (as with blocks items with specifically functionality will use a subclass. You could also make an item that uses its "damage" value to determine its variant and replace the original clay item with it but it is simpler to just add a new item, as unlike blocks there are essentially unlimited item IDs (32000 vs 256):
// Entry for vanilla clay item
public static final Item clay = (new Item(ItemIDs.clay)).setUnlocalizedName("clay").setCreativeTab(CreativeTabs.tabMaterials).setTextureName("clay_ball");
// Entry for new red clay item
public static final Item redClay = (new Item(ItemIDs.redClay)).setUnlocalizedName("redClay").setCreativeTab(CreativeTabs.tabMaterials).setTextureName("red_clay_ball");
Also, I do know that there is a major difference between 1.6.4 and Alpha, or any version older than 1.5; instead of using separate icons which are individually named and stitched into a single atlas at run time the texture atlases were pre-compiled (e.g. blocks are in "terrain.png"); I don't know the details but I assume there is some means in the Alpha source to specify the texture coordinates within the atlas, with new textures added into unused spaces (shown as pink in this example, which appears to show the actual atlas).
Obviously, everything that I've shown is with MCP only, no mod loaders of any kind, which will have their own means of registering new blocks and items (this also generally means no modifying or replacing existing ones, as I've done extensively; obviously, modifying or replacing existing vanilla code is highly discouraged to maximize compatibility between mods but that is not a concern for me).
All the names used by MCP are either placeholders or were chosen by its developers; the original names used in the original source were all lost during the obfuscation process, so fields and methods all have names like "a", "b", "c", etc, much like the obfuscated class files. Generally, it has improved over time and most of the methods and fields that still use names like this in 1.6.4 are in newer classes or are less likely to be used by modders (for example, "EntityHorse" has a lot of such fields and methods, though even the much older "Block" class still has a single method like this, but it is only used to determine if scheduled block updates happen instantly during world generation, and BlockFire is the only class that overrides its default return value of true, so it is unlikely to be of interest to modders).
As for setting up MCP for older versions, I'm not even sure if MCP for 1.6.4 can still be installed without issues due to changes to the launcher and/or Mojang's online webservers, depending on where it gets the required libraries from (I've actually been using the same installation for nearly 8 years; I made a backup of the original sources so I can restore them if I need to and copied the entire MCP folder over when I changed computers), and versions older than 1.6 were designed with the original .minecraft directory structure in mind (when the Minecraft jar was stored in a bin folder along with its native libraries, which are now extracted to a temp directory when the game is run and deleted when it is closed. Note that only more recent versions of MCP, like for 1.6.4, automatically copy/download the required files). One thing that I do know is that you'll need to use an older version of the JDK as I've seen a lot of modders attempting to use the latest version and failing due to various errors (I still use JDK 7 as I never had any need to update it; JDK 9 and later seem to have the most issues).
There is also the issue of developing server-side mods with the lack of server jars for versions prior to 1.2.1 (https://mcversions.net/ includes downloads for the game jars hosted on Mojang's servers, with no server jars for anything before 1.2.1. Anything not hosted on Mojang's servers is not official and technically in violation of the EULA; that said, the Wiki contains downloads (example, in the infobox on the right) for older server jars/exes, although MCP requires a jar); if you are only developing client-side mods MCP will work without the server jar (it complains that it cant find it or the server sources but does (de)compile the client).
Sono riuscito a configurare una cartella MCP per la versione beta 1.4_1, se importo il progetto in Eclipse posso vedere il codice del gioco. Inoltre ho notato che molti campi come "field_121234" sono scomparsi.
Il problema è che Eclipse mi dà errori, dipendenze errate dimostrabili.
Potresti dirmi come fare? sto usando java 1.6 e java 1.6 jre.
Edit:
I was using the wrong jre, now the problem is on the Minecraft.java class
The error says "Could not found the main class: net.minecraft.client.minecraft"
Edit2:
The only error i can see is in the block.java file.
This 2 lines:
public static final Block pressurePlateStone;
public static final Block pressurePlatePlanks;
Hi, some one can explain me how to modify the minecraft alpha code?
For example, how can i add a block and an item?
Thanks in advice!
I don't know about Alpha but pretty much everything I know about modding 1.6.4 came from looking at how it was done in vanilla, ranging from adding new blocks/items to mobs/entities, biomes, world generation, rendering, etc; adding an new block (in 1.6.4) can be as simple as adding a new entry in the Block class:
More complex blocks have their own subclass which overrides methods to do something more than the default behaviors (e.g. wool overrides getIcon to return a different texture depending on its data value, some other things also need to be overridden as well and you may want to add a crafting recipe but all of this can be found by looking at examples in vanilla). You can also replace existing vanilla blocks and items by assigning your own classes to the existing fields, though it is important to note that they must extended and cast to the original classes if their fields aren't just types of "Block" and "Item" (I once had an issue with MCP reobfuscating classes that I hadn't modified at all and omitting these classes caused the game to crash unless they were no longer referenced, and I found it was due to changing references like "BlockGrass" to "Block"):
Obviously, adding entirely new features from scratch (no comparable vanilla features/code available) is a bit more difficult but at this point it basically comes down to programming knowledge in general (for example, how to add a zoom feature like Optifine's? Start with the observation that lowering the FOV appears to zoom in (and indeed, this is how "zoom" works) and find the code that deals with FOV (e.g. the "GameSettings" class has a field named "fovSetting"*, so search for "fovSetting" to find the code that actually uses it); then add in code that checks if a key is pressed (see how vanilla checks for keypresses) and if so apply a modifier to "fovSetting", and optionally, enable smooth camera).
*Any class/method/field names and code mentioned here may not be the same in Alpha; MCP has changed the names they used over time and some may be non-intuitive or even outright misleading, even in newer versions e.g. "Block.canBlockGrass" (what does that even mean? Only the smooth lighting code uses this so it has nothing to do with grass) should really be called "Block.isBlockTransparent", which I renamed it to; likewise, "Block.getBlocksMovement" gave me headaches for a while until I realized it actually meant the opposite, thus I renamed it to "Block.getAllowsMovement", or rather, added a new method that returns the original method to maintain compatibility with unmodified vanilla code. Some fields and methods also have names like "field_12345", which will require looking at the code that uses them to figure out what they are for; the majority of fields and methods do have sensible names and comments describing them though, at least in 1.6.4).
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?
Ok thanks you soo much!:D, were i can find an entire guide o do that?
For modding have i to create new classes in mcp projects or in separate folders like in the modern minecraft modding?
I don't know of any guides for such old versions; it also seems like everybody uses Discord these days, which seems to requires an invitation or at least an account to even view anything (I've never used it but I've clicked on links to it and it told me to register), as opposed to public forums like these, which I think is quite unfortunate and it only worsens the issue of trying to find help unless you actually ask around (there is a link to Discord in the "Modification Station" spoiler in this thread which says it is mainly about modding Alpha and Beta versions; of course, I can't actually see the forum (or whatever Discord calls them) it links to).
That said, a lot of my modding involves simply modifying existing classes; for example, this shows how extensively I've modified the "World" class, which contains most of the logic used to run a world and access its data; this includes references to my own code in separate classes (in general I'll extend/completely replace vanilla classes if there are no direct references to them in unmodified vanilla code). I just add new classes to the "mcp\src\minecraft\net\minecraft\src" folder, where MCP places most of the vanilla source. I actually don't use an IDE; I use Notepad to edit the source and directly run "recompile.bat" to recompile them and "startclient.bat" to run the game, so just directly working within the MCP folder (if I need to find something I use a "grep" tool for Windows which integrates into the context menu that appears when you right-click a folder and is basically a more advanced version of Windows' file search. Having everything in a single "src" folder also makes it easier to find specific files; using consistent naming schemes for blocks/items/etc, e.g. "Block[Name]", "Item[Name]", "Entity[Name]" groups them together when sorted by name).
As mentioned before, looking at how something is done in vanilla is how I learned how to make my own mods; for example, this is my BlockBoneBlock class, which backports bone blocks to 1.6.4; it is basically a copy of the BlockLog class except there is only one variant (both extend "BlockRotatedPillar", which contains all the logic used to determine the direction logs face when placed and which sides have which textures based on its data value). For all I know, vanilla 1.10 uses the exact same code (probably not exactly, as 1.8 added "block states", not to be confused with my "BlockStates" which are int constants corresponding to block IDs and combined IDs/metadata):
To register it I added a new entry to the "Block" class, which contains a list of every block in the game:
Then I added these lines to the "CraftingManger" class (or equivalent) to register recipes for crafting and uncrafting them:
For a more complicated example, I added a red variant of clay blocks and clay items; in this case I completely replaced the original BlockClay class (I generally append "Fix" or "TMCW" to the end of the original name depending on why I changed it; "Fix" if I'm fixing vanilla bugs or making it compatible with changes I made elsewhere and "TMCW" if I've added new functionality):
Instead of adding a new entry to the Block class I replaced the original entry; another difference from bone blocks is that I had to register an "ItemBlock" which supports metadata, otherwise it will be ignored (i.e. red clay is placed as normal clay):
Likewise, I replaced the recipe for vanilla clay to only accept one data value (recipes ignore data values by default), with new recipes for red clay and dying normal clay red added:
I also added a new entry to the "Item" Class to register my red clay item, which is basically the same as for vanilla clay, just a different ID (as with blocks items with specifically functionality will use a subclass. You could also make an item that uses its "damage" value to determine its variant and replace the original clay item with it but it is simpler to just add a new item, as unlike blocks there are essentially unlimited item IDs (32000 vs 256):
Also, I do know that there is a major difference between 1.6.4 and Alpha, or any version older than 1.5; instead of using separate icons which are individually named and stitched into a single atlas at run time the texture atlases were pre-compiled (e.g. blocks are in "terrain.png"); I don't know the details but I assume there is some means in the Alpha source to specify the texture coordinates within the atlas, with new textures added into unused spaces (shown as pink in this example, which appears to show the actual atlas).
Obviously, everything that I've shown is with MCP only, no mod loaders of any kind, which will have their own means of registering new blocks and items (this also generally means no modifying or replacing existing ones, as I've done extensively; obviously, modifying or replacing existing vanilla code is highly discouraged to maximize compatibility between mods but that is not a concern for me).
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?
thans you!
I will try!
sorry for the trouble,
but when did mojang stop creating functions called for example "field_123124"?
Also would you know how to set MCP for minecraft beta?
All the names used by MCP are either placeholders or were chosen by its developers; the original names used in the original source were all lost during the obfuscation process, so fields and methods all have names like "a", "b", "c", etc, much like the obfuscated class files. Generally, it has improved over time and most of the methods and fields that still use names like this in 1.6.4 are in newer classes or are less likely to be used by modders (for example, "EntityHorse" has a lot of such fields and methods, though even the much older "Block" class still has a single method like this, but it is only used to determine if scheduled block updates happen instantly during world generation, and BlockFire is the only class that overrides its default return value of true, so it is unlikely to be of interest to modders).
As for setting up MCP for older versions, I'm not even sure if MCP for 1.6.4 can still be installed without issues due to changes to the launcher and/or Mojang's online webservers, depending on where it gets the required libraries from (I've actually been using the same installation for nearly 8 years; I made a backup of the original sources so I can restore them if I need to and copied the entire MCP folder over when I changed computers), and versions older than 1.6 were designed with the original .minecraft directory structure in mind (when the Minecraft jar was stored in a bin folder along with its native libraries, which are now extracted to a temp directory when the game is run and deleted when it is closed. Note that only more recent versions of MCP, like for 1.6.4, automatically copy/download the required files). One thing that I do know is that you'll need to use an older version of the JDK as I've seen a lot of modders attempting to use the latest version and failing due to various errors (I still use JDK 7 as I never had any need to update it; JDK 9 and later seem to have the most issues).
There is also the issue of developing server-side mods with the lack of server jars for versions prior to 1.2.1 (https://mcversions.net/ includes downloads for the game jars hosted on Mojang's servers, with no server jars for anything before 1.2.1. Anything not hosted on Mojang's servers is not official and technically in violation of the EULA; that said, the Wiki contains downloads (example, in the infobox on the right) for older server jars/exes, although MCP requires a jar); if you are only developing client-side mods MCP will work without the server jar (it complains that it cant find it or the server sources but does (de)compile the client).
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?
Sono riuscito a configurare una cartella MCP per la versione beta 1.4_1, se importo il progetto in Eclipse posso vedere il codice del gioco. Inoltre ho notato che molti campi come "field_121234" sono scomparsi.
Il problema è che Eclipse mi dà errori, dipendenze errate dimostrabili.
Potresti dirmi come fare? sto usando java 1.6 e java 1.6 jre.
Edit:
I was using the wrong jre, now the problem is on the Minecraft.java class
The error says "Could not found the main class: net.minecraft.client.minecraft"
Edit2:
The only error i can see is in the block.java file.
This 2 lines: