WorldsEnder

Stuff in your resource folder (assets) can be overridden by resourcepacks (old texturepacks). This is all done by minecraft, so it just works without you doing anything.

I think the problem is that you launch with java 8. You can't right now, set the project to java 7 (I don't know how to do that in Idea, working with eclipse).

I have no problems using eclipse only. You can setup multiple local repositories pretty easily (google "eclipse git local repository"). So you just set that repo to the same location as the forgeinstallation (the .git folder should be besides the src folder) and BAM there you go. Eclipse won't move any files whatsoever

Forge has a nice tutorial for this in their own code. Open up your favorite IDE and look for classes implementing cpw.mods.fml.client.IGuiFactory. You will most likely see FMLConfigGuiFactory and ForgeGuiFactory. ForgeGuiClass provides a great tutorial by itself when you can read and understand code. Try it

I guess in proxy.registerRenderers(); but I miss the source for this method call, too. Show us your ClientProxy class please (and any related code with #registerRenders())

You could make this mod server only mod but you have to keep track of the following (at least): The player changes to a disguise (some packet the disguising player sends): -> Server has to send a LogoffEvent? to all other players and not display the player on the serverlist anymore (so that the disguise is good) or despawn the EntityPlayer in the world. I can't tell you if it will be respawned but the disguised player should not be sent these Events -> Server has to spawn a new Entity in the world (the disguise) and keep it in synch with the actual player movement. If it is a block the server has to prevent movement. Player changes disguise: Pretty much the same as changing to a disguise Player changes to normal: Reverse the process With this implementation the server could be fully aware of the player without changing it's state internally but all sent updates have to be modified which can be extremely difficult to catch all of them (especially when other mods interfere). Also the player wouldn't know about his own state because HIS client never received any updates. How could he, he doesn't support a player being a block. To sum this all up: The mod should be clientside, too.

That is correct. The descriminator byte has to be the same on both sides if you register the packet on both sides.

With the SimpleNetworkWrapper implementation you have to `registerMessage(Class<? extends IMessageHandler>, Class<? extends IMessage>, byte, Side)` where you provide an IMessageHandler and an IMessage basically telling forge that the provided IMessageHandler handles Messages of type IMessage. Now I don't know what happens if you send a message which type hasn't been registered/has no handler. But if there is one for the type of message you sent it will be handled by the IMessageHandler you registered. Replies get sent on the channel they have been received so that is how forge knows that the answer belongs to your mod. Replies are nothing more than messages that get encode and sent and then get handled by the IMessageHandler you registered for the TYPE of IMessage that has been sent. So a messageflow may look like this (A and B are both IMessages): In MainClass: SimpleNetworkWrapper networkHandler = new SimpleNetworkWrapper("MHFC"); // "MHFC" is the channel's name In PreInitialization: networkHandler.registerMessage(AHandler.class, A.class, 0, Side.SERVER); // A is a message to the server networkHandler.registerMessage(BHandler.class, B.class, 0, Side.CLIENT); // B is a message to the client Normally you register both messagetypes on both sides (if needed) but here we have a simple bounceback Anywhere: A messageA = new A(someArgs); MainClass.networkHandler.sendToServer(messageA); Now the following happens: messageA -> encodedMessageA (by calling messageA.toBytes()) -> .... internet.... -> messageA (with messageA.fromBytes()) -> select handler (from registered handlers) -> handler.onMessage(messageA) -> messageReplyB -> encodeMessageB -> .... internet.... -> messageB -> select handler -> handler.onMessage(messageB) ->... Only the original messageA and the two handler.onMessage(message) calls happen outside of forge but give you full control. Now notice the ... at the end. This means that another answer package could be sent etc. Forgive my formatting, it's bad but w/e, follow the flow PS: Networkwise the messages aren't recognized by class but by the byte (third argument in registerMessage(...)). So make sure that you select a different byte for each message you register.

AFAIK a reply is just a normal message that is sent to the opposite side by forge which means that packet replies are only there for convenience and the reply can and must be handled exactly as a normal message. You could of course encode the original message in the reply so that you know to which message you got an answer to but that goes too deap into actual code (you already know?, if not feel free to say so)

Whenever I try to do gradlew build I get the following error: Now I know that it says java 7 there but it will hit a java 8 section of the code eventually. How can I fix this issue? PS: My JAVA_HOME path is set to a java8u5 jdk, so definitly no problem there. PPS: No, I can't switch to version 1.6

Hi, I work with eclipse and I didn't want to change the workspace every time I develop my mod. So I thought, import the project, no problem and it wasn't a problem, until I executed the Client.launch. The default working location is set to {workspace_loc} which isn't much of a problem normally but for me it spammed my other workspace with folders etc. It is easy to fix, just change the working location to {project_loc}/eclipse.

Are we able to register static EventListeners or does it have to be an specific instance you have to hand to the registry MinecraftForge.EVENT_BUS.register()?

As the title says: what are the difference between the two methods? As far as I know the two methods applyEntityAttributes and entityInit are pretty much equally when dealing with EntityLiving and difference is semantically that you assign data to the dataWatcher in entityInit() and entityAttributes in applyEntityAttributes. Is that correct? This leads to the question what the difference bewtween the DataWatcher and EntityAttributes is? - Which should I use when? - Do they both get updated automatically Server/Client? And a last question: How can I set a random variable at spawn that doesn't change but is the same on both Server and Client?

Sorry that I can't provide a solution but I can provide a quick tip: move the registration of your crafting recipes from the preInit-method to the init-method. It's nothing severe but more common to register advance stuff (things that require items or such already registered) in the init method.

The problem I have is that the player has a custom inventory but there should only and really ONLY (creative mode excluded) one item of my custom type (let's name this item ItemFoo) in this inventory. I have no problems registering the ExtendedProperties for the player neither with opening the GUI to display the items in his box and those in his inventory. As a quick reminder, in his box can be any count of this ItemFoo but in his inventory should be only one and also the item should not be found in the default Minecraft inventory afterwards (so don't drop it infront of him, etc.). I saw the method #canTakeStack(EntityPlayer) in slot in combination with #onPickupFromSlot(EntityPlayer, ItemStack) in the class Slot. How should I handle this issue that I can't differ between shift-pickup and normal pickup? Should I check if Shift is pressed? (could one change this keybinding? Where do I find the correct binding?), should I move the checking to the Container? (I might program more than one Container, copypasta no bueno) or do you have any other interesting ideas you think I should consider? Please give me your feedback about this issue, thanks. PS: Maybe a feature request??

I think the more appropriate way of copying data from one entity to another is by calling entityTarget.copyDataFrom(entitySrc, true). This is the way minecraft teleports entities etc. and some modders will use it more often than. At worst case this method does the same thing as write and reading from NBTTag so don't worry, you won't have to deal with that.

A Proxy is an object that gets injected by forge and is different on client and server side. So many modders may consider this as it is a "safe" way to distinguish server and client side. Things like renderers don't belong on the server side so the server-side proxy would just do nothing when the registration function for renderers is called. This way there is nothing messy in your code, the only thing that bothered me is that I don't like reflection (the way the proxy is injected).

Maybe I can enlighten a you a bit when it comes to blend functions. How it works: Before a face with an alpha value is rendered let there be already existing background on your screen. We'll call the screenplane which openGL paints on "destination pane" (normally you don't speak of a plane but of a framebuffer but you can think of it as a canvas). What happens now is that openGL doesn't directly paint ontop of the already existing stuff. Instead think about taking a new canvas and paint you face on this one. Let's call it "source pane". For the computer of course colors aren't colors. They are Integers and are represented in the "rgb"-colorscheme (red, green, blue). To add transparancy we need a forth number, the alpha-value. For every pixel on value is saved for red, green, blue and alpha (rgba). The effectiva range is [0...1] from "not there" to "all of it". But now you have two different planes! How does this get merged into one? This is where the blending-function blends in. You call GL11.glBlendFunc(sScale, dScale). The function takes two arguments of the exact same "type" (openGL-constants of a specific type, for you they appear as ints but openGL interprets them). When you look at the documentation ( https://www.opengl.org/sdk/docs/man4/xhtml/glBlendFunc.xml ) you see that you can actually pass any of GL_ZERO, GL_ONE, GL_SRC_COLOR, GL_ONE_MINUS_SRC_COLOR, GL_DST_COLOR, GL_ONE_MINUS_DST_COLOR, GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_DST_ALPHA, GL_ONE_MINUS_DST_ALPHA. GL_CONSTANT_COLOR, GL_ONE_MINUS_CONSTANT_COLOR, GL_CONSTANT_ALPHA, and GL_ONE_MINUS_CONSTANT_ALPHA What now happens is that the colors on the destination plane are mulitplied by a factor related to the GL-constant you passed, the dScale. For GL_ONE this factor is 1. For GL_ONE_MINUS_SRC_ALPHA this factor is (1-alphaOnSourcePlane) etc. This is done for the source-plane, too, but with the sScale parameter instead of dScale. Then the resulting source-values just get add ontop of the existing destination colors. Here you can see why GL_ONE is a bit worse than GL_ONE_MINUS_SRC_ALPHA but doesn't look bad after all: If you can reacall if you use GL_ONE the color after painting the plane would be something like dColor*1+sColor*sValue. This value will always be greater than before and the world "behind the glass/transparent whatever" would not get filtered any bit. With GL_ONE_MINUS_SRC_ALPHA the equation is about dColor*(1-sValue)+sColor*sValue meaning that the dColor (existing color) gets reduced by a little bit as much as the material you draw is NOT transparent. I hope this can help you figuring it out in your mind Keep up the modding, the pipes look awesome.

Never mind, it seems like it was a bug in bla.996 and is now fixed with 1003 thanks for your efforts it was just something that bothered me cause it worked before updating to 1.7.2.

I noticed that the Icons aren't displayed correctly (I register them with registerIcons(IIconRegister par1). The texture seams not to get loaded correctly. public void registerIcons(IIconRegister par1IconRegister) { WeaponLongsword.icon = par1IconRegister.registerIcon(MOD_INFO.modid + ":" + Strings.longswordIconName); } The texture is at assets.mhmu.textures.items.weapons.Longsword_IconBase.png and Strings.longswordIconName = "weapons/Longsword_IconBase".

But it's convenient anyways

That's not the problem, the problem is that I can't select any language INGAME. It is not a question of how to add other language mappings but I can't select any other language in the game menu. Also I noticed that the Icons aren't displayed correctly (I register them with registerIcons(IIconRegister par1). The texture seams not to be loaded correctly. EDIT: though the strange thing got fixed I still don't see any icon... I will make a new topic, look here: http://www.minecraftforge.net/forum/index.php/topic,15601.new.html

Ok thanks, I guess en_US is used if the mapping doesn't exist for the selected language, right? Also when will I be able to select languages like I can in normal minecraft? Antime soon? I just want to check if I didn't mistype something etc...

The error is at 2:15 in the video. You are no longer required to set your eclipse workspace. The way you do it now is the following. Install the GradleIDE plugin for eclipse via the marketplace. If you don't know what that is google "eclipse marketplace". Start eclipse and set the workspace to whatever you want. Then you rightclick on the package-view and click Import... You select "Existing project into worspace" Then you select the extracted forgefolder (the one with .gradle, .settings, build, eclipse, gradle, src, etc...) as root directory and hit "Select All" for projects. Whether or not you mark "Copy projects into workspace" is your decision, it doesn't really make much difference. Last step you hit finish and you should be done. Eclipse is now importing the project and you should see it showing up in the package view.

Is there a way how I could update my project to the latest version of forge with the new gradlew system? I don't want to redownload everything (how can I know if the assets are still the right ones?) but I don't see the possibility to do that. Let's put it this way: reimporting the project into Eclipse would be okay but needless redownloads aren't. If there isn't I would request this feature for future builds/downloads. If that is not possible, is there a way to clean the gradlew(-temporary) files? Some sort of "gradlew -clean"?