mercrutio

Man, tell me about it. I haven't been programming for fun in a while, and when I saw Forge had just come out for 1.7.2 I was all, "Sweet!" Now the names have got my head spinning. I'm learning a lot about Minecraft and Forge though, and it's satisfying as heck when things work.

Ah, this is the same problem I was having. I hope they put the new release out soon, because I don't want to get hours into learning how to compile the git repo properly and then have them release it. Thanks for the heads up, Wierdo99.

Draco18s, I appreciate the input. The idea is sound, but it doesn't work correctly under 10.12.0.998, which is Forge-latest as of this writing. After obfuscating and updating to deal with Netty, I got this: public Packet func_145844_m() { NBTTagCompound nbtTag = new NBTTagCompound(); this.func_145841_b(nbtTag); return new S35PacketUpdateTileEntity(this.field_145851_c, this.field_145848_d, this.field_145849_e, 1, nbtTag); } public void onDataPacket(NetworkManager net, S35PacketUpdateTileEntity packet) { func_145839_a(packet.func_148857_g()); } which works as described in the OP. I can't be certain until I can test it, but I'm pretty sure it's exactly what EdgarAllen says. Anyway, thank you, I was really excited for a second there.

Looking at it, I think that could be the problem. Is there a way to get this commit into my build, or do I have to wait for the next Forge release? I assume the latter, but I've never messed with it. Thank you for pointing it out, either way!

Hey, I just found S35PacketUpdateTileEntity. Lemme guess, it has to do with that?

Hey, I'm having a heck of a time setting up a block that can hold items between sessions. It's obviously a problem with Server/Client syncing, but I don't know how to approach it. I feel like there should be a simple solution by extending and overriding the right classes/files, but I can't figure it out. Assume, for simplicity, that I just want to make a 'custom' Furnace. I have 1.) a Block implementing ITileEntityProvider, 2.) a TileEntity implementing IInventory, 3.) a Container, and 4.) a GuiContainer. I also have a GuiHandler class that points to the container/guiContainer as appropriate. I have registered the block and the tile entity with GameRegistry. I can get the gui to render just fine, and I can even interact with it as a simple storage. I haven't tried anything relating to burning. The problem is encountered when logging out and back in: any items placed in the tile entity go back to the player inventory. I'll post some code, but is there anything I'm obviously not doing? It seems that there aren't, in fact, any methods in place to handle the disparity between the Server and Client. I have written a custom packet to inform the server every time an item is placed into the inventory clientside, but now the client doesn't seem to get the data from the server. And it's a horribly messy way to be doing it. Solution: There was a bug in Forge 10.12.0.998 (and probably below). It was fixed in build 999, and syncing the TileEntity is just as you would think. If you're dealing with obfuscation, func_145844_m() is getDescriptionPacket(), and onDataPacket(NetworkManager net, S35PacketUpdateTileEntity packet) is legible. And yes, you do need to use S35PacketUpdateTileEntity. Thanks to the guys here and around who told me about the bug, and thanks x100 to the powers that be (cpw, I'm pretty sure) for fixing this promptly.

Hey, thank you. This is spot on.

Eeep, ninja'd. Well, I'm poking around a bit. What Forge build are you using? Sometime yesterday 997 went up, which is what I'm working with. entityID: I've never messed with entityIds, so I don't know what you're looking for. I found this. net.minecraft.entity.Entity: protected java.util.UUID entityUniqueID PlayerTracker: So the interface IPlayerTracker is gone. As far as I can tell, it's just gone. However, it seems that all the functions you could override in it have equivalent events in cpw.mods.fml.common.gameevent.PlayerEvent. For example, there's a PlayerChangedDimensionEvent and a PlayerLoggedInEvent. onLeftClickEntity: I didn't have any problem finding this one. Found it first in the javadoc, and then double checked to find it in Eclipse. net.minecraft.item.Item: public boolean onLeftClickEntity(ItemStack itemStack, EntityPlayer player, Entity entity) RenderLiving: I don't really know what you're looking for here, you'd have to be a bit more specific. Maybe pastebin your modified code and I can have a look? Mind you, on all of this, this is just me poking at Forge with a stick. I'm just guessing. Good luck, and let me know what does/doesn't work!

Hey, I had the same issue, and I think it's related to an issue that's been floating around. It has to do with being on a Mac, which causes gradle to reach for the '-nightly-131017' (or some date) build off of a server maintained by Mojang. I don't know enough to explain why, but apparently Mojang isn't maintaining that particular file correctly. The solution? After you've run gradle setupDecompWorkspace (or eclipse) there should be a file build/dev.json. In it is a listing of dependencies for gradle to gather. Three of them have to do with lwjgl and end in '-nightly-131017'. Just edit the file to remove the ending from those three, and then rerun gradle setupDecompWorkspace. I would recommend making a backup of he dev.json though, because it seems to get overridden with the -nightly-131017 stuff every time, and you have to get rid of it every time before you use any gradle command. Let me know how it goes!

Hey, I tried to put these up for MCPBot, but I was having a heck of a time with IRC. I'm going to keep trying for my own sake, but I thought you guys might want these. If someone gets a chance, feel free to feet them to MCPBot. (in reference to net.minecraft.util.ChatStyle) ChatStyle.func_150227_a(boolean) : setIsBold(boolean) ChatStyle.func_150217_b(boolean) : setIsItalic(boolean) ChatStyle.func_150225_c(boolean) : setIsStruckout(boolean) ChatStyle.func_150228_d(boolean) : setIsUnderlined(boolean)

Hey, I figured it out. The solution is simple, but surprising. In order to properly register a mod, you have to have the @Mod annotation, as such: @Mod(modid = MODID, name = NAME, version = VERSION) public class Lorecraft { public final static String MODID = "*********"; public final static String NAME = "*********"; public final static String VERSION = "*****"; Now, I'm used to storing important values, such as MODID, NAME, and VERSION, in a separate file and importing them. Apparently, if you do so, Forge 10.12 won't recognize your mod and reject it. Just a heads up, keep these values here. (I'm not sure if NAME needs to be here, but it's probably best to keep them together.) At any rate, can anyone confirm this?

The client's .json is fine, but the lwjgl issue is known (see http://www.minecraftforge.net/forum/index.php/topic,15140.msg76913.html#msg76913). I just did as they suggested. Here's the build.gradle, almost completely unedited: https://gist.github.com/mercrutio/8309333

coolboy4531, I appreciate the suggestion, but, FYI, it is normally called Terminal in OSX, but I have ported xterm from the GNU/Linux in, as my normal environment is Gentoo. It has better support for, amongst other things, terminal-based text editors such as nano (yes, I am not a fan of vi/vim). Moreover, .bat files will not function in a *NIX environment, which is why the bash file gradlew is included. I haven't actually owned or used a Microsoft product on any personal device in over a decade, but I do recall, with vague horror, the experience of editing .bat files; my heart goes out to you.

Hi, I'm having an issue building my code with the latest forge release. I've been stalking these forums for quite a while and solved my problems on my own (usually reading posts here) in the past , so I've gone over everything I can find. I'm working on OSX, and encountered the lwjgl issue on OSX that's been mentioned. My solution has been to delete the three occurrences of '-nightly-20131710' (or whatever that date is) from the dev.json file every time I go to use gradlew. I have successfully run gradlew setupDecompWorkspace and gradlew eclipse, and then pointed my Eclipse workspace at forgedir/eclipse. I have been experimenting with the changes in 1.7, as much as possible, and have written some very basic code creating a new block and item, and texturing them. This code works within the Eclipse environment. I have also been running a Forge 10.12.0.995 server successfully, without any installed mods. I have not tested the server with 996, but the client works with 996 (without mods). To try the mod code out, I first ran (after editing the dev.json file) gradlew build. It produced an output to build/lib/MYMOD.jar, which was not recognized in my mods folder. I get the error "[Client thread/WARN]: Zip file MYMOD.jar failed to read properly, it will be ignored" as seen in http://www.minecraftforge.net/forum/index.php/topic,15185.msg77325.html#msg77325. There we are linked to the [Tutorial] Compiling Mod post by PlatonCraft, which says to optionally edit the build.gradle file first. I did so, to no avail. I also was concerned that it may have been related to the lwjgl issue, and edited my .json file in the client appropriately. I have googled and searched this forum to the best of my ability. Here is my game log: https://gist.github.com/mercrutio/8308455 What have I missed?