Have you ever felt Minecraft was missing.. boxes?
Don't village homes seem pretty darn empty?
Have you ever dreamed of smashing piles of crates while raiding a stronghold?
When you smash these containers, they drop random items(65 in total). They usually drop supplies, sometimes interesting trinkets or rare items and spawn in villages, strongholds, and mineshafts. It brings the true feeling of a rpg to MC.
Look at these villages, it's like everyone lives in a dog kennel. Where's all their stuff?
Here we go:
Even fun for the kids!
Here are more pictures of them:
The crates don't drop as an item themselves, you have to use silk touch to obtain them.
This is a new item, it's a pouch that can drop from the crates. When you put them in the crafting grid, you get 3 gold nuggets:
Big credits to cecilhowe for the idea and the textures!
Download: http://dl.dropbox.co...47/LootBlox.zip
Installation
1. Go to your mc folder (go to 'my computer' and enter %appdata%).
2. Open your minecraft.jar in the bin.
3. Open the LootBlox folder in the link using winrar or 7zip(or w/e else opens zip folder).
4. Drag the class files into the jar.
5. Go into the 'textures' folder in LootBlox, take the terrain.png and gui folder, make them into a zip file, and place them in the 'texturepacks' folder in the minecraft folder.
6. Select the zip folder you made for the files, or the texture pack you added the image files to, in the texture pack menu when playing minecraft.
Note: If you have a texture pack, open copy and paste the individual block skins and bag skin into the same spots as they are in the terrain.png and items.png(in gui folder).
- Link6654
- Registered Member
-
Member for 12 years, 8 months, and 9 days
Last active Tue, Nov, 13 2012 16:17:02
- 0 Followers
- 25 Total Posts
- 1 Thank
-
876
TechGuy543 posted a message on TechGuy's Modding TutorialsPosted in: Mapping and Modding TutorialsMinecraft Forge TutorialsHere are some Minecraft Forge tutorials. I thought it would be better to keep them separate from the ModLoader ones. I'll start off with the basics of Forge like Blocks and such. Ghosrec35 will be doing the advanced/important tutorials.
Main Registry
Your Forge registry class has almost nothing in common with your mod_ class from ModLoader except that it registers everything.
Firstly, just start with the package declaration as usual. You can use your own package but I will just use the default Minecraft source package for this example.
package net.minecraft.src;
Next we need to import a few Forge classes.
import cpw.mods.fml.common.network.NetworkMod; import cpw.mods.fml.common.Mod; import cpw.mods.fml.common.Mod.Init; import cpw.mods.fml.common.Mod.PostInit; import cpw.mods.fml.common.Mod.PreInit; import cpw.mods.fml.common.event.FMLInitializationEvent; import cpw.mods.fml.common.event.FMLPostInitializationEvent; import cpw.mods.fml.common.event.FMLPreInitializationEvent;
All annotations are well explained in ghosrec35's Mod Annotation Interfaces tutorial(below)
The first annotation we will use is the @Mod annotation. We will use it to declare some information about our mod.
@Mod( modid = "ExampleMod", name="ExampleModsName", version="ExampleModVersion")
As an example, I use this in Undead+:@Mod( modid = "UndeadPlus", name="Undead+", version="[1.4.7] v1.0.0")
After you have the @Mod annotation we need to add the @NetworkMod annotation. We use this as well as the @Mod annotation because Forge mods are "universal"(one version for both Client and Server).
@NetworkMod ( clientSideRequired = true, serverSideRequired = true, channels = {"example_mod"}, packetHandler = ExampleModPacketHandler.class )
NetworkMod is explained in ghosrec35's tutorial below. You also need to create a PacketHandler, one is below:
package net.minecraft.src; import java.io.ByteArrayInputStream; import java.io.DataInputStream; import java.io.IOException; import net.minecraft.src.EntityClientPlayerMP; import net.minecraft.src.EntityPlayerMP; import net.minecraft.src.Packet250CustomPayload; import cpw.mods.fml.common.FMLCommonHandler; import cpw.mods.fml.common.Side; import cpw.mods.fml.common.network.IPacketHandler; import cpw.mods.fml.common.network.Player; public class ExampleModPacketHandler implements IPacketHandler { @Override public void onPacketData(INetworkManager manager, Packet250CustomPayload packet, Player player) { if (packet.channel.equals("GenericRandom")) { handleRandom(packet); } } private void handleRandom(Packet250CustomPayload packet) { DataInputStream inputStream = new DataInputStream(new ByteArrayInputStream(packet.data)); int randomInt1; int randomInt2; try { randomInt1 = inputStream.readInt(); randomInt2 = inputStream.readInt(); } catch (IOException e) { e.printStackTrace(); return; } System.out.println(randomInt1 + " " + randomInt2); } }
After the @NetworkMod annotation you can declare the class. Note that with Forge, this class doesn't require a mod_ prefix or extend BaseMod.
public class ModUndeadMainRegistry {
We then need to add three methods. They are each called at specific times in the loading of the game. The methods can be called anything as long as they have the Forge annotation and parameter that is required. The first is preInit.
@PreInit public void preInit(FMLPreInitializationEvent event)
This method is called before the mods are loaded.
@Init public void init(FMLInitializationEvent event)
This method has the same function as the load() method is ModLoader. In here is where we will register all of our blocks, recipes, entities, etc.
@PostInit public void postInit(FMLPostInitializationEvent event)
This is the final method that is required in the Forge mod registry. Put stuff that you want to happen after the mods are loaded in here.
Final Code:
package net.minecraft.src; import cpw.mods.fml.common.network.NetworkMod; import cpw.mods.fml.common.Mod; import cpw.mods.fml.common.Mod.Init; import cpw.mods.fml.common.Mod.PostInit; import cpw.mods.fml.common.Mod.PreInit; import cpw.mods.fml.common.event.FMLInitializationEvent; import cpw.mods.fml.common.event.FMLPostInitializationEvent; import cpw.mods.fml.common.event.FMLPreInitializationEvent; @Mod( modid = "ExampleMod", name="ExampleModsName", version="ExampleModVersion") @NetworkMod ( clientSideRequired = true, serverSideRequired = true, channels = {"example_mod"}, packetHandler = ExampleModPacketHandler.class ) public class ExampleMod { @PreInit public void preInit(FMLPreInitializationEvent event) { } @Init public void init(FMLInitializationEvent event) { } @PostInit public void postInit(FMLPostInitializationEvent event) { } }
Mod Annotation InterfacesBy ghosrec35
package ghosrec35.mods.example.common; import cpw.mods.fml.common.Mod; import cpw.mods.fml.common.Mod.IMCCallback; import cpw.mods.fml.common.Mod.Init; import cpw.mods.fml.common.Mod.Instance; import cpw.mods.fml.common.Mod.PostInit; import cpw.mods.fml.common.Mod.PreInit; import cpw.mods.fml.common.Mod.ServerStarted; import cpw.mods.fml.common.Mod.ServerStarting; import cpw.mods.fml.common.Mod.ServerStopping; import cpw.mods.fml.common.SidedProxy; import cpw.mods.fml.common.event.FMLInitializationEvent; import cpw.mods.fml.common.event.FMLInterModComms; import cpw.mods.fml.common.event.FMLPostInitializationEvent; import cpw.mods.fml.common.event.FMLPreInitializationEvent; import cpw.mods.fml.common.event.FMLServerStartedEvent; import cpw.mods.fml.common.event.FMLServerStartingEvent; import cpw.mods.fml.common.event.FMLServerStoppingEvent; import cpw.mods.fml.common.network.NetworkMod; import cpw.mods.fml.common.network.NetworkMod.SidedPacketHandler; @Tutorial("Annotation Interfaces within Forge") @Mod(modid = "Ghosrec35_ExampleMod", name = "ExampleMod", version = "1.0.0.0", dependencies = "after:UniversalElectricity") @NetworkMod(clientSideRequired = true, serverSideRequired = false) public class ExampleMod { @SidedProxy(clientSide = "ghosrec35.mods.examplemod.client.ClientProxy", serverSide = "ghosrec35.mods.examplemod.common.CommonProxy") public static CommonProxy proxy; @Instance("Ghosrec35_ExampleMod") public ExampleMod instance; @PreInit public void loadPre(FMLPreInitializationEvent event) { } @Init public void load(FMLInitializationEvent event) { } @PostInit public void loadPost(FMLPostInitializationEvent event) { } @ServerStarting public void serverStarting(FMLServerStartingEvent event) { } @ServerStarted public void serverStarted(FMLServerStartedEvent event) { } @ServerStopping public void serverStopping(FMLServerStoppingEvent event) { } @IMCCallback public void interModComms(FMLInterModComms event) { } }
Understanding the CodeForge ModLoader and the MinecraftForge API include many different Annotation Interfaces that allow us to create methods within our main mod file that are able to be invoked from outside files without editing base classes. This is achieved by first Annotating the said mod file with the @Mod and @NetworkMod Annotation Interfaces which originally registers these certain files with Forge ModLoader.- The @Mod annotation requires three parameters, modid which must be equivalent to a String, name which must be equivalent to a String, and version which must be equivalent to a String. Now this main mod file is able to contain other Annotation Interfaces located within the Mod.java located in the cpw.mods.fml.common package.
- The First of these methods introduced by the Mod.java is the @Instance annotation. This Annotation Interface Targets ElementTypes of the type Field, and so we annotate a public field of the type our mod file. This Annotation contains a value() of type String which is to be equivalent to your mod file's modid. This Annotation is then used to populate the field of which it annotates with the instance of your Mod File.
- The rest of the Annotations derived from the Mod.java do not require such a level of complexity.
- The first of these methods is the @PreInit Annotation which must Annotate a method with a parmeter of the type FMLPreInitializationEvent. This allows Forge ModLoader to perform two checks (The first being that this is the method designated for Pre-Initialization and the second being that the method again is designated for Pre-Initialization, but also that when invoked the method is able to retrieve information and perform tasks available from the instance of the PreInitEvent which is passed to the method upon its invocation.)
- The next Annotation is the @Init annotation which must Annotate a method with a parameter of the type FMLInitializationEvent. This Annotation works in the same way as @PreInit, except the method is invoked after the Pre Initialization methods of all mods are invoked. This allows for such things as configuration files to be created and for settings to be loaded and saved before other processes begin within the Mod. (Of course, any fields created and initialized will actually be run before the PreInit method as this occurs upon the loading of the Class itself.) The @Init method is run at the normal time of Block Registration, Recipe Registration, etc, to occur within Minecraft.
- The next Annotation is the @PostInit annotation interface, which must annotate a method with a parameter of FMLPostInitializationEvent. This method is invoked after both the @PreInit and @Init Annotated methods are invoked for each and every mod being loaded. These methods allow for easy manipulation of Minecraft and the many Blocks/Items/ and other things that have been introduced by your mod. This method is commonly called modsLoaded, as it occurs after all the mods have been loaded.
- The next Annotation is the @ServerStarting Annotation. This Annotation yet again annotates a method, but this Annotation must annotate a method with a parameter of the type FMLServerStartingEvent. This method allows for the Manipulation of the server while the server is in the process of initializing all its files.
- The next Annotation is the @ServerStarted Annotation, which annotates a method with a parameter of the type FMLServerStartedEvent. This method allows for easy manipulation of the Server after the server has been started, and is currently running.
- The next Annotation interface us the @ServerStopping annotation which annotates must annotate a method with a parameter of the type FMLServerStoppingEvent. This Annotation allows for the invocation of this method to allow for manipulation of the server while the server is stopping.
- The final Annotation I will be discussing is the @IMCCallback Annotation. This Annotation annotates a method with a parameter of the type FMLInterModComms. This allows your mod to send messages to other mods by the use of the Mods' modid and a key-value pairing. The next step is to move on to the NetworkMod annotation interface which continues on with much of the more complicated annotations.
NetworkMod and Associated Annotation InterfacesBy ghosrec35
The first thing to note is that there are only two attributes that are required with the @NetworkMod annotation.
@NetworkMod(clientSideRequired = true, serverSideRequired = false)
Both attributes must equal boolean values. These values determine whether a player is allowed to join a server or not. clientSideRequired should almost always be true, and serverSideRequired should almost always be false. clientSideRequired determines whether the client side of the mod must be installed for a player to join a server with the mod installed, while serverSideRequired determines whether the server side must be installed for the client to be able to join it.
We set clientSideRequired to true almost always because there are very few occassions in which nothing client side would be required for a mod.
We set serverSideRequired to false almost always because we will still want users to be able to join their favorite servers even if the server does not have the mod installed.
There are other attributes that are available for usage. These are channels, packetHandler, tinyPacketHandler, and connectionHandler. There are two more, but I will wait to discuss these until finished with the first three.
The channels attribute must be equivalent to an Array of Strings. This array will contain the Channels that will be automatically registered for your mod.
For Example:
@NetworkMod ( clientSideRequired = true, serverSideRequired = false, channels = {"Channel"} )
DON'T register channels so generic as the one used in this tutorial. Always try to use channel names that are unique and original.
The packetHandler attribute must be equivalent to a class that implement IPacketHandler.
For Example:
@NetworkMod ( clientSideRequired = true, serverSideRequired = false, channels = {"Channel"}, packetHandler = PacketHandler.class )
Any Packets that are sent using the channels you registered in the channels attribute will be sent to this PacketHandler.
The connectionHandler attribute must be equivalent to a class that implements IConnectionHandler.
For Example:
@NetworkMod ( clientSideRequired = true, serverSideRequired = false, channels = {"Channel"}, packetHandler = PacketHandler.class, connectionHandler = ConnectionHandler.class )
The IConnectionHandler interface forces the ConnectionHandler class to override a few different methods that allow you to handle certain events with a player when they're connecting. Some more information on this in a future tutorial.
The tinyPacketHandler attribute must be equivalent to a class that implements ITinyPacketHandler. This works just like a regular PacketHandler, but for smaller packet sizes.
Final NetworkMod annotation so far:
@NetworkMod ( clientSideRequired = true, serverSideRequired = false, channels = {"Channel"}, packetHandler = PacketHandler.class, connectionHandler = ConnectionHandler.class, tinyPacketHandler = TinyPacketHandler.class )
Before we get to the final two attributes, it's important to note again that you only NEED the clientSideRequired and serverSideRequired attributes to run your mod. The rest are only required for things like SMP or Connection Handling.
The final two attributes are a little trickier than the rest. They are clientPacketHandlerSpec and serverPacketHandlerSpec.
These attributes allow you to define separate packet handling classes and channels for both the Server and Client Side. You may use these rather than defining the channels and packetHandler attributes.
Each must be equivalent to an @SidedPacketHandler annotation. We are then able to use the attributes of the @SidedPacketHandler Annotation to further define each. The two attributes are channels, and packetHandler. These attributes function the same as they do above, but when used in an @SidedPacketHandler annotation only register the information with one side of Minecraft.
For Example:
@NetworkMod ( clientSideRequired = true, serverSideRequired = false, connectionHandler = ConnectionHandler.class, clientPacketHandlerSpec = @SidedPacketHandler ( channels = {"ClientChannel1", "ClientChannel2"}, packetHandler = ClientPacketHandler.class ), serverPacketHandlerSpec = @SidedPacketHandler ( channels = {"ServerChannel1", "ServerChannel2"}, packetHandler = ServerPacketHandler.class ) )
The next NetworkMod related annotation is the @SidedProxy annotation. @SidedProxy has a Target of the ElementType FIELD, meaning it must annotate a field. For our example, we are going to create a field of the type CommonProxy.
@SidedProxy(clientSide = "ghosrec35.mods.examplemod.client.ClientProxy", serverSide = "ghosrec35.mods.examplemod.common.CommonProxy") public static CommonProxy proxy;
The two attributes of the @SidedProxy annotation are clientSide and serverSide. These two values are equivalent to String values and will contain the file path (including your package path) to your two separate proxies. More on this later.
You must create a file that will be your CommonProxy (Conventionally, this is usually called CommonProxy), and then you must create another file that will extend CommonProxy which will be your ClientProxy (Conventionally, this is usually called ClientProxy).
The @SidedProxy annotation requires the path to your ClientProxy and CommonProxy, as it automatically populates the proxy field of type CommonProxy with whichever proxy is designated for whichever side. This means that when invoking any methods, you must ensure that both the Client and Common Proxy contain the methods so that no exceptions occur during runtime on either the Server or Client. Proxys are used for such things as preloading textures, as you are able to register rendering information on only the client side by including the render methods in only the client proxy. The ClientProxy must extend the CommonProxy so that you are able to populate the field of the type CommonProxy with your ClientProxy as well.
The final @NetworkMod associated Annotation is the @SideOnly Annotation.
The @SideOnly annotation requires a value of the type Side, which is an enumeration containing the values CLIENT, SERVER, and BUKKIT. Annotating a field with @SideOnly ensures that the method is only run on the designated side. For instance, the vanilla Minecraft code has been edited throughout with@SideOnly(Side.CLIENT)
over certain methods that are used for Client only details such as Rendering or Sound.
Thank-youThank you to the following people who have really assisted me well with helping people while I am absent. There are many others who have helped but these are the main ones who keep returning and giving great help to countless amounts of people.- ghosrec35 - ghosrec35 has written the Forge tutorials.
- -Reaper-
- KoadMaster
- PhantomJedi759
- ZeroLevels
- StangeOne101
- Zildjian97
- NukeAndBeans
- Dragonphly77
-
2
koolgshizman posted a message on Ridin' The Rails? Well one block i think is one meter, so ride a rail 1000 blocks i guess.Posted in: Achievements & Stats -
1
MCFUser79067 posted a message on Ridin' The RailsDo it multiple times?Posted in: Achievements & Stats - To post a comment, please login.
1
1