Draco18s

Even if your mod is free, it does not qualify as fair use. Does not count as a copyright violation. There's some grounds if you manage to write the exact same code, but I wouldn't worry about it. You can always claim independent discovery. 4096 blocks, 32000 items. Not including metadata. This is a total number, vanilla + all mods.

Ah, yes. isRepairable. Glad you found what you needed. *salute*

I'm not entirely sure about this, its been a while since I messed with this function, but try: @Override public boolean getIsRepairable(ItemStack par1ItemStack, ItemStack par2ItemStack) { if(par1ItemStack.getItem() == par2ItemStack.getItem()) { return false; } } In your item class

Download the jar file and open it with JD-GUI

Then you should go look at how Lucky Blocks API works.

And then do texture registration as "mod:some/folder/foo"

That's a crappy method. #Use _ to represent spaces (no item) in recipes. S:"quarterstaff" < S S S S oreDict:itemStick >

First up: Anything you can do with IMC messages, do with IMC messages. You can get really far with this alone if you work hard enough. While an IMC message types only have 1 message that passes ItemStacks (and only a single stack), you can get more information across than that using the NBT method (as ItemStacks can be converted to NBT data and back again). That said, there may be more complex information that isn't encodable via messages, such as interfaces or recipe lookups. In order to do anything with your API you need to know what it is that you want from your API. My best advice would be that whatever your API does, use your own API in your own code. This is the best way to insuring that your API functions correctly. Secondly, if you ever need to change your API, mark the old methods as @deprecated and leave them in there, even if they do nothing. The worst thing you can do is have a mod use your API and go dormant (i.e. no longer getting updates for whatever reason) and then you change your API around and delete things or move things. Now that mod will crash trying to use your new API and people will complain to that mod's author, not you, which will make them very upset. Finally, take a look at some other mods' APIs. Here's one of mine, which I modeled on Mystcraft's approach, as I really liked that approach. Inside HardLibAPI are some static objects (set to null) which would be instanced by my mod when run. The interfaces give visibility to what methods are available (including documentation), without having to supply any actual code.

It may work, but still not the best idea. If we use rare character, then user will not be able to find it. If we use '_' for example, then if i replace it in every string of array, i may affect items that are named using this character. And it will be useless, when recipe is shapeless... Meanwhile, i use same translation code for another mod, whose recipes are configured via json, and json keeps spaces in strings... Thanks, anyways... 1) Use _, no one is going to be affected strangely. You just have to make sure to document the config file correctly. 2) Only do the replacement on the recipe portion. This is at most the first 3 strings. 3) Shapeless recipes won't matter, their construction is different, they only have inputs and a result. 4) Yes, json does preserve whitespace, the Forge config files were never meant to handle this sort of data.

Vanilla has no concept of gases, so most gaseous fluids (at least the ones from Thermal Foundation, IC2 and Railcraft) just use MaterialLiquid (which returns true from Material#isLiquid ). That's what I thought. Now that I have a chance to dig at my own code where I have my own gas... Ah here we go if(block instanceof IFluidBlock) { IFluidBlock fb = (IFluidBlock)block; Fluid fl = fb.getFluid(); boolean isGaseous = fl.isGaseous(); }

Just imagine two mods trying to do that at the same time.

Use a different character. Read from the cfg file and then replace '_' (or whatever) with ' '.

You can instanceof IFluidBlock too. The material check should be sufficient, but just look out for possible weirdnesses. I don't recall offhand if gaseous materials return true for isLiquid() or not.

That is, unfortunately, not how textures or rendering works.

Are you talking about the "star-shaped" particles? Those are for critical hits.

You should check that the block is an instanceof BlockLiquidBase, then cast and get the Fluid field and examine it for its liquid properties All mod added liquids should extend from that, but that includes gasses which you would want to treat as air (hence looking at the Fluid field's properties).

You will need a custom renderer as part of a client event handler. If you take a look at my post here you would do something similar. You'll want to start with the DrawBlockOutlineEvent (sp?), check for TNT in hand, if so, attempt to calculate which blocks need an overlay, then tessellate those cubes. Do keep in mind that blocks have an explosion resistance, so the radius in dirt is a lot bigger than in stone.

That, sir, is the definition of flexibility.

There are 4 major bugs in programming: Syntax errors Logic errors And off by 1 errors

http://www.minecraftforge.net/forum/index.php/topic,34201.msg180147.html

Is it vanilla or Forge that allows for custom sprite loaders? Want to report to the right people, for now I am assuming Forge inserts that as part of its patch (because why the hell would vanilla assume custom loaders!). The custom sprite load method is not passed a number of mipmap levels and TextureMap.mipmapLevels is a private field. This value is passed to loadSprite , albeit indirectly as the length of a buffered image array. This makes correctly instantiating the framesTextureData 2D arrays difficult: the sprite MUST assume the maximum number of mipmaps possible for its own size (for 16x16 default resources, this is 4) which could lead to problems if the number that the system goes to generate exceeds this value (unlikely, but possible) and under lower mipmap settings just wastes RAM. Or it forces the modder to use Reflection in order to get access to the private field. Either this method would need to include that integer value or TextureMap.mipmapLevels needs a getter method via IResourceManager .

You'd do #2 sort of, except that you would manually interface with the tessellator to draw your camera-facing quad. Take a look at how nametags are drawn.

4) You could declare new Random() but I would do it at the event handler class level, not inside the function.

Sorry, my mistake. I saw damage.getSourceOfDamage() instanceof EntityPlayer and it looked wrong, but I was away from Eclipse and on my tablet.