heaton84

Solution was to put the hook into MinecraftForge.EVENT_BUS into preInit. Forge doesn't throw an error in this case.

I just followed the tutorial at http://www.minecraftforum.net/topic/1854988-tutorial-162-changing-vanilla-without-editing-base-classes-coremods-and-events-very-advanced/ for the whole DummyModContainer thing.

@sequituri Chunk events are not passed on that event bus. For some reason, Forge 10 has multiple event busses... you have to use the right one. @TheGreyGhost The root problem seems to be that the LoadController is looking for the @Mod annotation, which is fine if you're making a normal mod. This is a coremod. Adding a @Mod annotation results in either 1) Forge crashing and burning if you use the same Mod ID, or 2) multiple mods being registered if you use a different ID. It seems really dumb to me that I'd have to maintain "two" mods when it's all the same function. Is ModDummyContainer deprecated, or somehow different in 1.7.x?

Wow, I am stabbing at the dark here. What's up with this error? It works despite it. DummyModContainer code: package kovukore.coloredlights.src.asm; import java.util.Arrays; import yamhaven.easycoloredlights.EasyColoredLights; import yamhaven.easycoloredlights.blocks.CLBlocksController; import net.minecraft.nbt.NBTTagCompound; import net.minecraft.world.chunk.Chunk; import net.minecraftforge.common.MinecraftForge; import net.minecraftforge.event.world.ChunkDataEvent; import com.google.common.eventbus.EventBus; import com.google.common.eventbus.Subscribe; import cpw.mods.fml.common.DummyModContainer; import cpw.mods.fml.common.FMLCommonHandler; import cpw.mods.fml.common.FMLLog; import cpw.mods.fml.common.LoadController; import cpw.mods.fml.common.Mod; import cpw.mods.fml.common.ModMetadata; import cpw.mods.fml.common.Mod.EventHandler; import cpw.mods.fml.common.event.FMLInitializationEvent; import cpw.mods.fml.common.event.FMLPreInitializationEvent; import cpw.mods.fml.common.eventhandler.SubscribeEvent; public class ColoredLightsCoreDummyContainer extends DummyModContainer { public ColoredLightsCoreDummyContainer() { super(new ModMetadata()); ModMetadata meta = getMetadata(); meta.modId = "coloredlightscore"; meta.name = "Colored Lights Core"; meta.version = "1.0.1"; meta.credits = ""; meta.authorList = Arrays.asList("AJWGeek", "Kovu", "CptSpaceToaster", "heaton84"); meta.description = "The coremod for Colored Lights"; } @Override public boolean registerBus(EventBus bus, LoadController controller) { bus.register(this); MinecraftForge.EVENT_BUS.register(this); return true; } @Subscribe public void preInit(FMLPreInitializationEvent evt) { FMLLog.info("EVENT_BUS.preInit"); } @SubscribeEvent public void LoadChunk(ChunkDataEvent event) { NBTTagCompound data = event.getData(); Chunk chunk = event.getChunk(); FMLLog.info("$$$ Load event (%s, %s)", chunk.xPosition, chunk.zPosition); } @SubscribeEvent public void SaveChunk(ChunkDataEvent event) { NBTTagCompound data = event.getData(); Chunk chunk = event.getChunk(); FMLLog.info("$$$ Save event (%s, %s)", chunk.xPosition, chunk.zPosition); } }

Ok, I halfway got it. Event code is: @SubscribeEvent public void LoadChunk(ChunkDataEvent event) { NBTTagCompound data = event.getData(); Chunk chunk = event.getChunk(); //TODO: Inject RGB nibble arrays //FMLLog.info("$$$ Load event (%s, %s)", chunk.xPosition, chunk.zPosition); } @SubscribeEvent public void SaveChunk(ChunkDataEvent event) { NBTTagCompound data = event.getData(); Chunk chunk = event.getChunk(); //FMLLog.info("$$$ Save event (%s, %s)", chunk.xPosition, chunk.zPosition); } The problem is, this ONLY works if the class has the @Mod annotation. This conflicts with the coremod style of the DummyModContainer. As a result, I have TWO mods listed (I must change the ModId in @Mod, otherwise Forge blows up with a duplicate mod error). Is there any way to get this to work inside DummyModContainer?

I'm trying to avoid that by using Forge events. I'm not afraid to revert to ASM if Forge can't do what I need to. Right now, I've added the following to my DummyModContainer and it isn't working: @Subscribe public void Load(ChunkDataEvent event) { NBTTagCompound data = event.getData(); Chunk chunk = event.getChunk(); FMLLog.info("$$$ Load event (%s, %s)", chunk.xPosition, chunk.zPosition); } @Subscribe public void Save(ChunkDataEvent event) { NBTTagCompound data = event.getData(); Chunk chunk = event.getChunk(); FMLLog.info("$$$ Save event (%s, %s)", chunk.xPosition, chunk.zPosition); } I've also tried @EventHandler in place of @Subscribe, still no go. Event documentation is pretty sketchy from what I can tell... the wiki says it's from Forge 6... there's no clear explanation to me on what descriptor an event handler should use, and how forge decides what event type to hook into.

I guess a more apt question is, how do I distinguish between a load and save ChunkDataEvent?

I'm working on a mod that adds 3 NibbleArrays to ExtendedBlockStorage. These arrays need to be saved with the chunk when it is unloaded. Looking at the events in the wiki (www.minecraftforge.net/wiki/Event_Reference), it's not immediately obvious to me if/how this is possible. Anyone have a bit more detail on how the world events can be used?

Overriding vanilla stairs. Fixed it by locating the tesselator code in RenderBlock (renderBlockAsItem for anyone looking for this in the future) and just copying into my instance of ISBRH. Note that just calling renderBlockAsItem didn't work.... the light level was too flat.

Ok, I figured out how to render it: renderer.renderBlockAsItem(block, metadata, modelId); (of course I'm swapping out modelId so I don't form a recursive loop of doom). Only problem now is that the block renders in completely flat light. Looks like all other blocks have a light source above them. Mine is now entirely bright and looks flat... see screenshot below... Anyone know how to get this shadow effect so it doesn't look like crap?

So I've used ISBRH to render my block. Is it possible to use a vanilla model of the stairs for my block for inventory rendering, or do I have to write the rendering code from scratch? Background: I'm overriding the rendering behavior of stairs to connect glass panes to them. In case it's not obvious, I'm not quite familiar with how minecraft renders inventory items.

Just wanted to post that this issue for me has been closed. I couldn't get MinecraftForgeClient.getRenderPass to work, and I found a more efficient method than hooking into canRenderInPass. I dynamically inserted a PUTSTATIC as the first line of WorldRenderer.preRenderBlocks. Now my static is only updated once per render pass, rather than once for each block.

Oh, so my class transformer is getting in before this. I'm trying to be too clever with my obfuscation detector. Mod is working now. Thanks!

Thanks GotoLink, unfortunately I seem to be having the same problem with the jars found there. Namely, the bytecode in one of those jars runs: ldc <Class net.minecraft.block.Block> To spin up a new Block instance... which of course throws a ClassNotFound exception, and kills the minecraft. Pretty sure this should be along the lines of: ldc <Class ahu> Now, in /build/libs I have: PaneInTheGlass-1.0.jar PaneInTheGlass-deobf-1.0.jar PaneInTheGlass-javadoc-1.0.jar PaneInTheGlass-src-1.0.jar I am assuming PaneInTheGlass-1.0.jar is the one I want to use. (For those curious, I'm grabbing the type of the Block class to see if I should use obfuscated names in my transform class. If I bypass this check and force my obfuscation flag to true, my mod still blows up later when my mod code tries to test against Block.air... I get a field not found exception. Therefore I can only conclude that my mod isn't being reobfuscated.) I feel like I'm missing a concept here. Edit: Added logs: http://pastebin.com/vgUWQpJG

I've successfully created and tested a mod with Gradle, but when it comes time to deploy I'm coming up stupid here. Everything I've read has vaguely referenced editing build.gradle... I've done that (http://pastebin.com/N5WcAx8m), and ran gradlew build. The problem I'm having is that the contents of bin are still accessing unobfuscated objects in Minecraft. I found a folder build\tmp\reobf that has jars named reobfed###########.jar, but those too are unobfuscated. What am I missing here?

Ok, I must be doing something wrong here. MinecraftForgeClient.getRenderPass is always returning -1. Here's what I'm doing now. I decided to implement a renderer via RenderingRegistry.registerBlockHandler. I pulled in a new render type via RenderingRegistry.getNextAvailableRenderId(), and stored that in a static. I then overwrote BlockStairs.getRenderType to return that static field... basically hijacking vanilla stair rendering with my renderer. I suppose it's *slightly* cleaner then also modifying RenderBlocks as well. For each pass through renderWorldBlock in my renderer, I'm dumping MinecraftForgeClient.getRenderPass via System.out.println, thus verifying it's always -1. Did I miss another hook?

Thanks Lex, I'll give that a go. Is that set before even the vanilla blocks are rendered? I'm overridding the rendering of stairs. If there's a glass pane on the step face, I'm rendering a quarter glass-pane so it seamlessly attaches to the stairs. Basically this: http://imgur.com/SwgO8O7 EDIT: I should have tested that before I posted, sorry. Looks like it is not set before vanilla objects get rendered, as my glass panes disappear when I use that method. Currently, I'm patching into Block.canRenderInPass (ala ASM framework and transformation... I know.... but it appears to be the only way) to push the render pass into a static variable in my mod before resuming execution.

I've checked mcp-notch.srg, mcp-srg.srg, notch-mcp.srg and packaged.srg, and cannot find a reference to net/minecraft/block/Block/canRenderInPass anywhere. I need this to publish my mod. That is, unless anyone has a better solution for getting the current renderpass that doesn't involve class transformation!

Sorry, I don't do IRC... would be great if we had an online database to work with. Here's my finding with BlockStairs: func_150147_e - Sets the bounds of the block for rendering. Defines bottom "slab" of stairs. func_150145_f - Sets the bounds of the back stair for rendering.

I'm currently working on a mod that will extend glass panes into staircase blocks. This mod involves tweaking some behavior of vanilla objects, and implementing a new render method for the hybrid block. The way I see it, I have two routes to an end here. The first approach is to use class transformation to surgically alter the methods of interest in the vanilla blocks. This is of course a coremod, which seems heavy-handed for such small behavioral changes. On the other end of the spectrum, I can create new blocks and inherit what I can from the vanilla objects (private and final modifiers are giving me headaches, of course). I can then try to replace the vanilla blocks in the registry with my new copy. I guess what I'm asking is, what's the preferred way of extending vanilla object behavior?