Raekye

I didn't get the part about "overwriting the inventory gui" but as for "can I open the gui by pressing a keyboard key", see this http://www.minecraftforge.net/wiki/Upgrading_To_Forge_for_1.3.1#Key_Bindings. It's called "updating to 1.3.1" but it's the same for 1.4 and 1.5 The only part I felt not documented well is the @Override public EnumSet<TickType> ticks() { return EnumSet.of(TickType.CLIENT); Part. Basically, it's what ticks do you want to be notified about. Which is basically just client (your key handler only needs to listen on the client side). If you return null, you won't get any notifications (key presses).

I don't like his website (too awkward to use, prefer static pages) but the 1.4 entity tutorials have been working for me on 1.5 http://wuppy29.blogspot.nl/2012/10/forge-modding-142.html

When you reobfuscate/compile, non java files are not added automatically. You need to manually drop those files - like mcmod.info or textures into the jar/zip. So in your jar you will have three folders - meta-inf, your mod source root, and a folder called "mods" with your textures in it.

No (a reference is an address in memory, would be pointless to send the server the address of an entity on the server side ) - but you shouldn't need to. Both the client and server keep a "world". You just need to keep in mind that whatever you do has to occur on the server side. Your best bet is to send the entityId (believe the world object has a getEntityById like method). You could also look at data watchers (I'm told the wolf class is a good example)

I'm not very experienced but it sounds very possible. Just take a look at the current commands, and use Eclipse to trace through (control + h to search for references/accesses or occurences of a string or Java field/class/method, etc.). Off the top of my head, your only problem will be dealing with who "executes" a command and who can edit the command (eg: a new player shouldn't be able to run up to a block, change it to "ban X" and hit a button). You can make anything runnable but then you need to be careful who has access to these blocks. If it's the player that activates it with redstone, well - there's no way to detect who activates redstone (AFAIK, please let me know if it exists). Or maybe it's the player that places the block that "runs" the command - in that case you could save the username in metadata or in a tile entity

Oh awesome. I was kinda fishing for a response and got it I did some testing, and here are my comments: - Setting the mod meta data dynamically is less error prone (won't forget to move the mcmod.info file for example, although build scripts are the best) - the modid, mod version, and mod name are populated from the Mod annotation if you set autogenerated to false - You do need to set the description property! If you don't you will get a null pointer exception when someone tries to open your mod info page - If you have a mcmod.info file still, it will not work

Also try going to eclipse => run => run configurations => vm arguments and setting the ram there (something like -Xmx2048m -Xms2048m )

Yeah. In the preinit event you can actually call getEventMetaData() or something like that, which lets you set the mcmod info stuff dynamically. Although, it doesn't work unless you have a mcmod.info in the first place (it must have at least the mod id), so it's kinda pointless.

Yeah. In the preinit event you can actually call getEventMetaData() or something like that, which lets you set the mcmod info stuff dynamically. Although, it doesn't work unless you have a mcmod.info in the first place (it must have at least the mod id), so it's kinda pointless.

See this https://github.com/MinecraftForge/FML/wiki/FML-mod-information-file. You want the property logoFile. Make sure when you compile the mod that you put the mcmod.info file in the jar/zip root, and the picture in the proper path.

See this https://github.com/MinecraftForge/FML/wiki/FML-mod-information-file. You want the property logoFile. Make sure when you compile the mod that you put the mcmod.info file in the jar/zip root, and the picture in the proper path.

Ah, didn't know about that. Anyways, it seems to be working great! I've got a couple more questions if you don't mind... firstly, what can I do instead if they don't allow destroy block hooks? I would guess something to do with asm but I don't see how I could add a hook that way. Or were the rejections just a matter of bad implementation? Here are my steps in case anyone else stumbles on this... 1. git clone --recursive [email protected]:MinecraftForge/MinecraftForge.git forge 2. (The last argument above clones into a forge folder). I haven't tried not naming the root forge folder 'forge', I want to try later 3. Run terminal or command prompt in the forge folder, and do something like .\fml\python\python_fml.exe setup.py or python setup.py . This does the fml setup stuff too 4. The eclipse folder is in the forge root folder

Ah, didn't know about that. Anyways, it seems to be working great! I've got a couple more questions if you don't mind... firstly, what can I do instead if they don't allow destroy block hooks? I would guess something to do with asm but I don't see how I could add a hook that way. Or were the rejections just a matter of bad implementation? Here are my steps in case anyone else stumbles on this... 1. git clone --recursive [email protected]:MinecraftForge/MinecraftForge.git forge 2. (The last argument above clones into a forge folder). I haven't tried not naming the root forge folder 'forge', I want to try later 3. Run terminal or command prompt in the forge folder, and do something like .\fml\python\python_fml.exe setup.py or python setup.py . This does the fml setup stuff too 4. The eclipse folder is in the forge root folder

Thanks. Any idea why block destroy events are rejected? Do you know what's the alternative (how are we supposed to 'listen' to these events; it seems like a lot of people want it if it keeps getting brought up) Okay, so this is what I did 1. Clone MinecraftForge/MinecraftForge 2. Rename MinecraftForge to just 'forge', not sure why this is needed (everything should be accessible by relative paths... this is the root folder), but I haven't tried not naming it forge and I trust diesieben 3. Delete FML 4. Clone MinecraftForge/FML (rename to lowercase fml to be safe) into the forge root 5. To "initialize the FML submodule" I followed these steps: https://github.com/MinecraftForge/FML/wiki/If-you-want-to-contribute-to-FML 8. For fmlbuild.properties, I set the dev home to FML and the mcp home to {dev home}/mcp 9. Run ant setupenvironment 10. Run .\fml\python\python_fml setup.py 11. Got an eclipse folder under fml (set this as my eclipse workspace) 12. There are two projects - Clean and FML. I belive you don't touch clean (can someone confirm?). Inside FML, there is mc-client, fml-client, and fml-common. I also think mc-client is actually mc-client and "mc-server" (the distinction was removed in Forge 7.7) However, in all the minecraft files (Clean project => src, FML => mc-client) the class names and packages are there but all the variables and function names are still obfuscated (eg: func_71934_m (method), field_72995_K (instance var), p_71908_2_ (parameter), k1 (local var)). Any ideas how to fix this? Here's what I did first, think I got a better setup now so I hid it

Thanks. Any idea why block destroy events are rejected? Do you know what's the alternative (how are we supposed to 'listen' to these events; it seems like a lot of people want it if it keeps getting brought up) Okay, so this is what I did 1. Clone MinecraftForge/MinecraftForge 2. Rename MinecraftForge to just 'forge', not sure why this is needed (everything should be accessible by relative paths... this is the root folder), but I haven't tried not naming it forge and I trust diesieben 3. Delete FML 4. Clone MinecraftForge/FML (rename to lowercase fml to be safe) into the forge root 5. To "initialize the FML submodule" I followed these steps: https://github.com/MinecraftForge/FML/wiki/If-you-want-to-contribute-to-FML 8. For fmlbuild.properties, I set the dev home to FML and the mcp home to {dev home}/mcp 9. Run ant setupenvironment 10. Run .\fml\python\python_fml setup.py 11. Got an eclipse folder under fml (set this as my eclipse workspace) 12. There are two projects - Clean and FML. I belive you don't touch clean (can someone confirm?). Inside FML, there is mc-client, fml-client, and fml-common. I also think mc-client is actually mc-client and "mc-server" (the distinction was removed in Forge 7.7) However, in all the minecraft files (Clean project => src, FML => mc-client) the class names and packages are there but all the variables and function names are still obfuscated (eg: func_71934_m (method), field_72995_K (instance var), p_71908_2_ (parameter), k1 (local var)). Any ideas how to fix this? Here's what I did first, think I got a better setup now so I hid it