FlameAtronach93

I had a similar issue. My semi-transparent block would flicker when you look around, falling and rising in light level. My issue could be resolved by setting the light level. The difference between your case and mine is that I was directly adding vertices to the tessellator. However, looking through the renderFace methods, it seems it does not automatically retrieve the light values for each individual block for each call. You'll have to set the light values manually. Have a look at lines 7032 - 7043 of the RenderBlocks class and you'll see what I mean. Several calls to Block.get(Mixed)BrightnessForBlock are used in other parts of the code to set the respective brightness properties of the class. In my case I could simply randomize the light values since it was a more complex block. It had more than 6 sides, so I got kind of lost as to how to calculate the brightness for each individual side...

You have weird method names similar to this one's: public boolean func_94041_b(int par1, ItemStack par2ItemStack) { return par1 == 2 ? false : (par1 == 1 ? isItemFuel(par2ItemStack) : true); } Neither the implemented interface IInventory nor the extended class TileEntity declare those, so where do you get these names from? Any reason they are in a pattern similar to the method reobfuscation one? I'd suggest, unless I overlooked something, that the exception might be exactly there. When re-obfuscating, one of the other properly named and overridden methods could be named like one of these... Punch your re-obfuscated TileEntityPortalSpawner.class file in here and review for duplicates, maybe my theory is right. P.S.: Don't download, just navigate to "Live Demo" and drag'n'drop.

What have you tried so far? Look into Block.getMixedBrightnessForBlock( IBlockAccess, int, int, int ). Maybe also check out net.minecraft.block.BlockFluid.getMixedBrightnessForBlock( IBlockAccess, int, int, int ). Either you'll need to make a coremod and use class transformers to expand upon Vanilla Minecraft algorithms of each and every block, or you simply create a new Block that you place next to the blocks you want colored darker, override that method and try to work around your problem like that. In either way, I don't touch lighting yet. It can be a very difficult rendering process.

Now look at your base class. My grandfather would like you. You're trying to teach common sense.

Have a look at those errors: These are the last two exceptions in your trace. I don't know which IDE you are using, but it seems you have an exact duplicate of a method, i.e. name and parameters are the exact same. Eclipse should warn you about that and actually not even compile. So either the error is there, or maybe something is going wrong during compilation. Please post the code of your TileEntityPortalSpawner, four eyes tend to see better than two.

Both aspects considered. I am excluding the entire coremod from class transforming. Edit: Wait, does that mean I'm not supposed to exclude my event from the transformers? That would explain everything. I'll try it out, thanks! Edit 2: Purfectly worked! Thanks a lot!

I'm back. I can't find out what I'm doing wrong. This is the class I'm using: There are a couple more nested classes like the one shown. The exception is: Which is ultimately caused by registering an event listener for these events. Now obviously Forge is trying to get the default constructor which I don't have. So I'm confused as to why forge events in general work since none of them provides a default constructor themselves except for the base Event class... Example: I don't think there is any event register. I could implement a default constructor that would assign dummy values to those finals, but if Forge doesn't have to, I'd like to know why... What am I missing? Sincerely, Flame SOLUTION Solution was as simple as this: do not exclude the event from the class transformers. In my case, it looked like this previously: @MCVersion("1.5.2") @TransformerExclusions({ "com.wod.crystalpower.coremod." }) public class CPCoreMod implements IFMLLoadingPlugin { // method overrides ... } Since my events are in package com.wod.crystalpower.coremod.events and Forge uses those strings as parameter of String.beginsWith, this would exclude my events from the net.minecraftforge.transformers.EventTransformer which is used to create the default constructor Forge uses when registering events. The relevant line of code now looks like: @TransformerExclusions({ "com.wod.crystalpower.coremod.CPCoreMod", "com.wod.crystalpower.coremod.asm." }); Credits for the solution of the problem go to LexManos. Thank you!

It doesn't matter. Java's infinite parameter feature is implemented to be backwards-compatible. In fact, when you have GameRegistry.addRecipe(ItemStack, Object...) You have nothing but GameRegistry.addRecipe(ItemStack, Object[]) Java simply does the conversion for you behind the scenes. This actually is quite a neat feature since it allows you to programmatically assemble your recipes and still turn them in to that method. Example: List<Object> myRecipe = new ArrayList<Object>(); myRecipe.add(new ItemStack(4, 1, 1)); myRecipe.addAll(new String[] { "aaa", "aaa", "aaa" }); myRecipe.add("a"); myRecipe.add(Block.blocksList[4]); GameRegistry.addRecipe(myRecipe.toArray(new Object[0])); Back to topic. Without further information I can only guess. The erroring line in the CraftingManager is: aitemstack[i1] = ((ItemStack)hashmap.get(Character.valueOf(c0))).copy(); The reason why this code fails is simple: if (par2ArrayOfObj[i + 1] instanceof Item) { itemstack1 = new ItemStack((Item)par2ArrayOfObj[i + 1]); } else if (par2ArrayOfObj[i + 1] instanceof Block) { itemstack1 = new ItemStack((Block)par2ArrayOfObj[i + 1], 1, 32767); } else if (par2ArrayOfObj[i + 1] instanceof ItemStack) { itemstack1 = (ItemStack)par2ArrayOfObj[i + 1]; } (lines 189-200 of the CraftingManager). This explicitly shows that you MUST pass in either an ItemStack, a Block, or an Item, but you are passing in an Integer. Change GameRegistry.addRecipe(new ItemStack(iredantblock), new Object[] { "aaa", "aaa", "aaa", Character.valueOf('a'), ItemIds.ITEMIREDANTCRYSTAL }); to GameRegistry.addRecipe(new ItemStack(iredantblock), new Object[] { "aaa", "aaa", "aaa", Character.valueOf('a'), Item.itemsList[itemIds.ITEMIREDENTCRYSTAL + 256] }); where 256 represents the shifted index which still hasn't been fixed to be 4096. This is also the reason why you still can't go above 256 blocks... You hit copy&paste, didn't you? Change new ItemStack(YourModItemsClass.iredantcrystal) to new ItemStack(ItemIds.IREDANTCRYSTAL) and you should be fine.

It is so difficult to teach people to post relevant information. Speaking from experience from StackOverflow...

You did misread what I said. I said the way you are reading information from the NBT is incorrect. You store the property of your TileEntity under a different tag name than the one you try to read it from. Since that tag name does not exist, Minecraft will return 0 for your timeLastWatering local long variable. I'd suggest that you skip the NBT part for the Bonemeal function completely and just use if( !world.isRemote && /* your other conditions */ ) { TileEntityApricornTree tileEntity = (TileEntityApricornTree)world.getBlockTileEntity(event.X, event.Y, event.Z); long currentTime = System.nanoTime(), timeLastWatered = tileEntity.timeLastWatered; if( (currentTime - timeLastWatered) > MILLISPERDELAY ) { tileEntity.timeLastWatered = currentTime; world.setBlockMetadataWithNotify( /* Blabla, can't read all your parameters. */ ); event.setResult(Event.ALLOW); } } Note that when writing to the NBT customly the way you do it in your original code, the changes won't be reflected the next time the item is used because the NBT is never read. TileEntity.readFromNBT is only called when the block is loaded, i.e. on chunk load. You could at the utter most try if( (currentTime - timeLastWatered) > MILLISPERDELAY ) { nbt.setLong("TimeLastWatered", currentTime); // tileEntityApricornTree.writeToNBT(nbt); // Don't do this. The NBT still has the old TileEntityApricornTree.timeLastWatered set, so you'll // end up overwriting the nbt.setLong("TimeLastWatered", currentTime); that you just used. tileEntityApricornTree.readFromNBT(nbt); // ... your other code here. } but I would still suggest you'd take the other approach since it is more straight-forward.

GameRegistry.registerBlock(fakeBlock, "Fake Block"); And just so you know: Every time it crashes, post the god damn error. It is impossible to solve a crash error without knowing what the error is. You're making my day, bud.

Any particular reason why you retrieve the NBT from a packet without ever sending it if you could just as well simply get the property of the TileEntity that you have retrieved nonetheless? In your TileEntity.writeToNBT, you use nbt.setLong("TimeLastWatered", timeLastWatered); while in your custom bonemeal function, you attempt to retrieve this value with nbt.getLong("TimeLastWatering"); which doesn't exist. Default return value for inexistent NBT sub long tags is 0. Current system time - 0 is always bigger than 10,000.

I may add that I recommend to use the reobfuscate_srg.(bat/sh), since then you don't have to worry about updating your mod every Minecraft bugfix update (like the 1.5.0 -> 1.5.1 -> 1.5.2 updates) Why, exactly? what do you mean with "why"? why I recommend this or why you don't have to worry about updating your mod during MC bugfix updates? I personally would be interested in the later part. How does the magic work, any leads? You heard of "runtime deobfuscation"? Forge converts the obfuscated code in Minecraft (the classes/methods/fields named a, bs, aab etc.) to deobfuscated "SRG names" (like func_34423 for methods etc.) while Minecraft runs. Those are indices which won't change unless there is an update which introduces new stuff or removes old stuff. That's why a mod reobfuscated with srg names won't break until a next "mod-breaking" update, like the 1.3 update was (introducing an internal server in singleplayer) or the 1.5 one (new texture system), basically a mod compiled in 1.5 will work with 1.5.2 (if written corectly, of course). If you don't, you most likely have to update to the next bugfix update. Yes, I indeed stumbled upon the word "runtime deobfuscation". In fact, I am checking whether FML detected a pre-de-obfuscated environment to set my "debug mode" flag. As far as I've understood, the reobfuscate_srg.bat/.sh file will only re-obfuscate necessary references that aren't de-obfuscated at runtime, did I get that right? Thanks for your explanation.

I didn't. Other items use it too, though, so it comes to the same solution. Just needed to point that out so he wouldn't try to assemble something by hacking his way through rendering unless really necessary...

Let's return to topic real quick! Despite you guys suggestions, Minecraft actually does offer such a feature already. I used it in my mod. The method's called Item.getColorFromItemStack( ItemStack, int ); and expects you to return an integer in the RGB format. Obviously then no semi-transparency. It's a little tricky though. I am simply coloring a white item, so coloring something brown or yellow might turn out unexpected. I think the brightness of the individual pixels is what matters. Also try not to use a colored item as creative tab icon. One of the succeeding tabs will have the same color...

... what are you developing your code with? Eclipse alike many other IDEs come with a debugger. You should use that. It helps a lot finding out why your code doesn't work at all anymore.

I may add that I recommend to use the reobfuscate_srg.(bat/sh), since then you don't have to worry about updating your mod every Minecraft bugfix update (like the 1.5.0 -> 1.5.1 -> 1.5.2 updates) Why, exactly? what do you mean with "why"? why I recommend this or why you don't have to worry about updating your mod during MC bugfix updates? I personally would be interested in the later part. How does the magic work, any leads?

try this: [EDIT oops forgot the link ] Took a look at the video and it turns out that my approach was quite similar. What I meant with "overhead" was that the entire directory structure of Minecraft would be created in your project. Forge would download the libraries, create log files and everything in the project root, etc. Other than that, my solution imported the Start class of Minecraft and simply redirected the invokation of the entry point to the Start class' one. I even set Minecraft as a dependency project, so it really only differs in the debugging configuration. Still like his new solution better, especially since all redundant dependencies and all that stuff would be hidden...

try this: [EDIT oops forgot the link ] No. All I was trying to do was make a core mod that did nothing, just so I could then build from there Oh, that explains it. I was searching these forums to find something by him. The search script aborted after 30 seconds. Anywho, check out the update of my previous post. I got something to work. It's loading up now, but crashing since I forgot to update some text references to classes... I'll look at Pahimar's way to set up the IDE and adapt this way to debug coremods where necessary. Cheers!

I'm quite new to these forums as you can deduce from my post counter, I'll look into his method and probably adapt to using it. I couldn't find any solution on the Internet when I searched for it, so I made my own. Edit: Couldn't find it... any leads since you pointed it out? I've been browsing the FML source for a while now and found that there are two relevant classes: cpw.mods.fml.common.Loader cpw.mods.fml.relauncher.RelaunchLibraryManager The first loads regular mods from either the MC class path or the mods directory in the MC root. The reason why it loads up from Eclipse is because it also supports loading MC from directories and in Eclipse, all sources are class files in directories. So it regards your mod as part of the MC classpath. The second is what we need to load a core mod. The method discoverCoreMods is called respectively. Exploring the code, one can find that it only accepts .jar files, not even .zip files, with a single obligation: it must have a Manifest File that has the key . Well, sucks, because this means it maybe is only possible to load it up from the IDE if we compile the sources into a jar and place it in the coremods directory there. Which actually is quite convenient with my workspace setup since every project comes with its own coremods directory... anywho! I'll try it out and give you feedback. About your coremod, does it dump any exceptions? o: Have you met all the requirements for a coremod? That's pretty much one of the reasons why I'm trying to load it up in the development environment... Final edit: I got it to work. This is how I've done it: [*]Create a class that implements "IFMLLoadingPlugin" [*]Create a MANIFEST.MF file with the following contents: Manifest-Version: 1.0 FMLCorePlugin: <class_you_just_created_including_namespace> The final blank line is required in order to recognize the last attribute. Without that attribute, FML will ignore the coremod. [*]Use File -> Export -> Java -> JAR file to create an unobfuscated .jar archive from your code and put it in your IDE's coremod directory. [*]Update JAR entry "META-INF/MANIFEST.MF" as Eclipse overrides it during compilation. Edit: It broke my markup!! O: Fixed it. Tell me if it works for you.

And that was exactly my point. I couldn't find any hints in the FML source code yet. Still searching for why it even loads mods from memory in the workspace, maybe I can find something relevant there... I managed to separate my code from the minecraft project into a new project, should anyone be interested. It creates the entire Minecraft directory structure in your new project though, but it's quite useful when developing several mods I think.

If you mean it's not loading in debug mode, then yes, it's not loading. Well, I like to develop and test my programs in the IDE. I haven't tried yet whether it even loads up in regular Minecraft. Sure I could do it that way too, but I'd like to know if it is possible to get it to run in the IDE, especially since it's much quicker and easier when resolving problems since I don't always have to log a lot of information, recompile, and re-obfuscate all the time. It's just about convenience at this point.

A little bit off-topic to enforce his paranoia: it is indeed possible to decompile Java classes back to Java code. So if you don't want people to leak your source code, you'll have to do what Mojang does: obfuscate. But it still doesn't fully protect your source code, as you as a developer can see yourself. So throw your paranoia into the corner. If somebody really wants your source code, they can get it...

Hello Minecraft Forge community! It is fairly easy to debug a regular mod in Eclipse. Just hit the Debug button and off you go. However, I couldn't quite figure out how to debug core mods... Also I couldn't find any tutorials on the topic, so I'm stuck with exploring FML's and other mods' source codes. I thought putting a MANIFEST.MF file in the META-INF directory in the project root would suffice my need, but it didn't recognize the mod. Any help / suggestions? Without this core mod, it would be pretty hard to further develop my experimental feature... The main reason why I even need to create a core mod is to inject some function calls / events into the RenderBlocks class. Would be cool if Forge included those anyways... right before and right after a block is rendered. In a nutshell, I am using it to overwrite the block textures of certain flagged sides of blocks. A nice little camouflage feature as I see it... would be a pity if I had to resort to workarounds like using an additional block. Sincerely, Flame