Choonster

You can store the UUID of the player who placed the block in a TileEntity (and then retrieve the player with that UUID to send a message to them at some point), but there's no way to detect the player who activated with a redstone signal.

You've installed a client-only mod (AutoRun) on the server. It also looks like you've put some mods inside minecraft.jar, don't do this. Forge mods are designed to be loaded from their own JARs in the mods folder, putting them in minecraft.jar can break things. Read the installation instructions of your mods.

One of your coremods is adding a duplicate method (probably func_146977_a / drawSlot ) to the GuiContainer class using ASM. See if you can narrow down which mod (or combination of mods) is causing it and report it to the author(s). AE2 and ChickenBones' mods (CodeChickenLib, CodeChickenCore, NEI) seem to be the most likely causes based on the log. Make sure you're using the latest available version of every mod before reporting the issue. To narrow down the cause, you can perform a binary search: [*]Disable half your mods [*]If the problem persists, it's caused by an enabled mod; so disable half of the currently enabled mods [*]If the problem goes away, it's caused by a disabled mod; so disable the currently enabled mods and enable the other half [*]Repeat until you find the cause

Iterate through every x,y,z position in the desired radius around the player's position and use World#getTileEntity to get the TileEntity at each position (will be null if there isn't one).

The installer installs a regular client/server. To develop mods, you need the Mod Development Kit (MDK).

Forge doesn't provide support for MDX models. You can either write a loader for the format yourself (will be quite tricky unless you have a solid understanding of OpenGL and the model format) or find a program to convert the models to OBJ (1.7.10/1. or B3D (1.8 only). For examples of existing model loaders, look at AdvancedModelLoader in 1.7.10 or ModelLoaderRegistry in 1.7. I found this thread that links a MDX to OBJ converter. I haven't tried it myself, so I have no idea how well it works. Edit: Removed the unwanted smiley.

Which version of Forge are you using? The fluid model was added in 1.8-11.14.3.1464. The FML log should tell you what's going wrong. If you don't know what to make of it, upload it to Gist and link it here. Fluid textures are set from the Fluid(String, ResourceLocation, ResourceLocation) constructor (added at the same time as the fluid model). Your code is using the Fluid(String) constructor. The fluid code on Forge's GitHub repository works for me in 1.8-11.14.4.1571.

The Ore Dictionary is what allows multiple similar items to be used for recipes. Mods add items to the Ore Dictionary with specific ore names (e.g. oreCopper , ingotIron , blockGold ) and then use those names as ingredients in ore recipes. If you're developing a mod, look at the OreDictionary and Shaped/ShapelessOreRecipe classes. If you're just making a modpack, you'll want to use something like MineTweaker (tweaks recipes and Ore Dictionary entries) or Quadrum (adds simple items/blocks based on JSON files).

This is an error with Wireless Redstone Chicken Bones Edition. Make sure you're running the latest version and if the error persists, report it here. Keep in mind that Chicken Bones may or may not be maintaining the mod any more. It looks like you've put some mods inside minecraft.jar. Don't do this. Forge mods are designed to be loaded from their own JARS in the mods folder, putting them in minecraft.jar can screw things up. In future, please post the URL of your Gist instead of just the name. This will make it easier for people to help you.

Logs are saved in {MinecraftDirectory}\logs. {MinecraftDirectory} is the directory you've set as the value of minecraft.runDir in your build.gradle script, usually eclipse or run. fml-client-latest.log is the latest client log.

A mod (Mo' Furnaces Mod?) is trying to register an entity (Cobalt Katana) with an invalid ID (the maximum ID is 255). If you've set this ID in a config file, change it to a valid ID; otherwise report this to the author. You can also tell them that they shouldn't be using global entity IDs, especially if the entity doesn't need a spawn egg.

Upload your FML log (fml-client-latest.log) to Gist and link it here.

If you're trying to do something like placing a block in response to a keypress (or something Minecraft sees as a keypress), you need to send a packet to the server and run the action on the server side. Even in single-player, there's a server thread running in the background that's in charge of the game. If you only perform an action in the client thread, any changes you make will be overwritten by the server's values. diesieben07 has a tutorial on the Simple Network Implementation (used to send packets between the client and server) here.

EntityPlayer#addExperience , EntityPlayer#removeExperienceLevel and EntityPlayer#addExperienceLevel allow you to add and remove XP from the player.

If it crashes, upload the server log (fml-server-latest.log) to Gist or Pastebin and link it here.

Your code looks like it should work. Is it not working? Are you getting any errors in the log?

Use Item.getItemFromBlock to get the Item form of a Block when registering your models (or at any other time). If block.domain isn't your mod ID, GameRegistry.findItem(block.domain, block.name) will return null (because there's no item registered for that domain and name). Your current model registration code should work with this change.

I don't think there's any way to register blocks/items with a domain other than your mod ID, but there's nothing stopping you from using models/textures from some other domain. GameData#addPrefix is only called when registering blocks/items, it's not used for models/textures.

diesieben07 has a tutorial on the Simple Network Implementation here.

There's no built-in config syncing mechanism, but you can send a packet from the server with its configuration options when a client joins and then apply these on the client. You'll need to unregister the previous provider/dimension IDs and register the new ones. I'm not entirely sure what the problem is there. Do the ResourceLocation paths exactly match the paths on disk (including capitalisation)? Try removing the leading slash from the paths.

Where are you calling Dimension.registerWorldProvider and Dimension.registerDimensions from? Even if you used the stable_12 mappings, you'd still need to provide both the SRG and MCP names of any method/field you access via reflection. The only time you can use a single name is when the method/field has no MCP name (so it appears as func_2234_b / field_1212_a even in the development environment).

You can update your mappings like that, but a couple of names of widely-used methods/fields have changed since 1.7.10's default mappings versions; so you need to fix your code to use the new names. Most deobfuscated builds of 1.7.10 mods are built for the older mappings, so they won't work properly with the new mappings unless you recompile them yourself. One way around this is to use manually recompiled deobfuscated builds of CodeChickenLib and CodeChickenCore and obfuscated builds of all other mods, which CodeChickenCore will deobfuscate at runtime. If you reference a field/method directly in your code, ForgeGradle will automatically reobfuscate it for you when you build your mod. It's only when dealing with reflection that you need to use both names, since ForgeGradle can't reobfuscate reflection calls. Instead of using this: ReflectionHelper.getPrivateValue(RenderGlobal.class, renderGlobal, "starGLCallList") // Only MCP name Use this: ReflectionHelper.getPrivateValue(RenderGlobal.class, renderGlobal, "starGLCallList", "field_72772_v") // MCP and SRG names

Oh lovely -- I recently wrote a mod using that list-box interface in Forge build 1450, so it will need to change when I move to the next recommended build (which I can now see at 1563). Thanks for the warning. I thought it an odd dependency at the time, so I like the change. The change is only in 1.8.8, not newer versions of 1.8 like 1563.

The Lord of the Rings Mod isn't registering its items properly (the author should fix this), but I don't think that's the cause of the crash. Something is happening after dimension 101 starts loading that prevents the server from starting, but I can't see any indication in the log of what this is.

You're trying to access the RenderGlobal#starGLCallList field via reflection, but there's no field with that name in the obfuscated client; the field has an SRG name instead. You need to try both the MCP and SRG names of a field/method when using reflection. ReflectionHelper accounts for this by accepting multiple names for a field/method and trying each one until it finds one that works. You can find the SRG name of a field/method using the MCP mapping CSV files. The default 1.7.10 mappings can be found in ~/.gradle/caches/minecraft/net/minecraftforge/forge/<forge_version>/unpacked/conf, the default 1.8 mappings and any manually-specified mappings can be found in ~/.gradle/caches/minecraft/de/oceanlabs/mcp/<mappings_channel>/<mappings_version> (replace ~ with %USERPROFILE% on Windows). You can also download mappings from the MCPBot website.