Draco18s
-
Posts
16559 -
Joined
-
Last visited
-
Days Won
156
Posts posted by Draco18s
-
-
Ok, for one, you didn't implement getUnlocalizedName anywhere. It goes in the ItemBlock class. Instead you're using getItemStackDisplayName, which is supposed to return the localized name (and you're not using
StatCollector.translateToLocal
). You don't want that.
As for the block not getting registered, I don't know, you didn't include your main class!
-
@Override public String getUnlocalizedName(ItemStack itemStack) { return "item." + names[itemStack.getItemDamage()]; } -
You need an ItemBlock for that.
-
When the GUI first opens you should be able to get the reference from the player's held item (that is what opened the GUI...) and save that reference.
That said, good fucking luck making sure what you just described works.
-
Loader.isModLoaded ("MOD_ID")
Should be what you should do. If that's true, do stuff.
-
The NBT classes are just a unified way for Minecraft objects to serialize data. Serialized means that it can be written to disk. You can store all of the simple data types (integers, floats, strings) as well as NBT objects.
-
I didn't import anything yet actually, which is odd.
EDIT: I manually imported net.minecraftforge.common.config.Configuration and it's still using the javax one.
EDIT 2:turns out that I was importing the javax one before, I have no idea what I was using it for though.
You'd have to delete the old one too
If you absolutely need both classes, you have to full-path one of them when you use it.
-
Add this line anywhere the inventory changes:
if (worldObj != null) worldObj.markBlockForUpdate(xCoord, yCoord, zCoord);
That tells the server it needs to send the changes to the client.
-
It is implied that you must add the ".setHarvestLevel( [tool], [level])" method as part of the initialize Block event, but doing this produces an error.
Actually, it's just a convenience thing. You can totally do it inside the block's constructor (which is what I do, because then as many properties of that block that I can get away with are inside that block's class--liquids have things that are required elsewhere, etc. etc).
Also, "initialize Block event"? Are you using an event handler of some kind?
-
1
-
-
And it didn't run, ergo something was wrong with it.
-
And....read signature.
-
I would look at that loop definition again. You have a mistake, evidenced by the fact that it is not spamming the console.
-
i == 100, eh?
-
-
That means there's an error that will prevent the project from launching.
If its not in the source code, then there's an issue with the build path. Right click -> build path -> configure and look for more ! in that window.
-
Um. Yeah. Don't do this:
customRenderItem = new RenderItem()
Just because you created an instance of that class doesn't mean that all of its properties are set. The crash isn't happening in your code, it's happening inside RenderItem. And what's null there?
renderManager
. Because creating a new RenderItem doesn't magically make that property defined.
Seriously:
-
The itemstack, the player, the world, the x/y/z location that was clicked on, the side that was clicked, then the float version of the coordinates (x/y/z), which are not round integers (e.g. if you click the center of the top face of a block you'll get 123.5, 66.0, 432.5).
-
Override
onItemUse
-
In the code you have shared I do not see anything that would produce an NPE
-
Keep in mind that some Forge Liquids aren't liquids at all, but gasses.
-
= null will get you nowhere.
As you can see, it's referencing the public property of the TileEntity. Thus the value is handled by the TE thusly:
-
Ok yeah, I am not sure what the problem is, but here's one thing:
EntityItem ghostEntityItem = new EntityItem(tileAltar.getWorldObj());
Don't do that. You're creating a new entity every time the game renders the world. Make it once, save it.
-
First I searched on Google and found this tutorial on minecraftforge.net: http://www.minecraftforge.net/wiki/Developing_Addons_for_Existing_Mods
It's outdated.
What is out dated about it? You don't decompile the mod any more and instead include it in your build path.
Everything else is fine. You change the @mod annotation, just as it lists, and you add the compatibility layer as described.
Java scriptJava is not Javascript.
-
AFAIK, this is not possible with 1.8 yet.
[1.7.10] Tesselator opacity
in Modder Support
Posted
Well, you have two problems.
0) The tessellator doesn't give a shit about transparency, that's a GL thing.
1) You never tell it what blend function to use
2) Your UVs are fucked up.
Let me distill this down into the important information. Removing Y entirely. Making xOff and zOff equal to zero. Multiplying the UVs by ten to reduce textual chaos.
(0, 0) : (3, 1)
(0, 1) : (7, 1)
(1, 1) : (3, 1) //again
(1, 0) : (3, 1) //and a third time