Draco18s

I don't know, I just don't know. ..

In determining whether the use made of a work in any particular case is a fair use the factors to be considered shall include: 1) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes; 2) the nature of the copyrighted work; 3) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and 4) the effect of the use upon the potential market for or value of the copyrighted work. 1. Purpose and character of the use The first factor is regarding whether the use in question helps fulfill the intention of copyright law to stimulate creativity for the enrichment of the general public, or whether it aims to only "supersede the objects" of the original for reasons of personal profit. To justify the use as fair, one must demonstrate how it either advances knowledge or the progress of the arts through the addition of something new. A key consideration is the extent to which the use is interpreted as transformative, as opposed to merely derivative.

More or less single-threaded* In this case, yes, only one thread is involved. The way Minecraft is multithreaded right now is limited to chunk loading/unloading, although I believe I found another place recently involving sounds. All I know is that it is probably my code and that whatever it is causes a concurrent modification on the tickingSounds list.

PositionedSoundRecord(...) Dude, that's a 3D sound object.

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