Not necessarily. Though it would certainly compile, the code is in the required enclosing type already. There is an implied this. in front of every field not already from somewhere else.
OK, if I had to hazard a guess, I would say that Item.ItemLegitmus doesn't exist. That's what the nullpointerexception means: It's trying to access something, but it can't, because it doesn't exist. Specifically, It got the pointer to the thing, but the pointer was null: AKA, zero, means nothing at all.
Technical jargon aside, are you sure that you meant Item.ItemLegismus, and not legOre? Because Item.ItemLegismus means that you would have modified Item.java and put ItemLegismus into it.
A few other notes: you don't need to use Character.valueOf, you can just use the character itself, it will automatically be cast into it's required format. Also, I doubt that you need addRenderer, since it is empty and it's not abstract. Furthermore, it's probably good practice to have an actual version number rather than pi. Something like "dev build" or "0.00" if it's unreleased.
You're telling java "Take mod_MangMod.aliengrass (which is a Block), turn it into a byte, and make topBlock (which is supposed to be a block) into that".
The error is because it doesn't know how to turn a Block into a byte. Even if it did, there would be another error saying it doesn't know how to turn a byte back into a Block, because it has to take that and make topBlock be it.
The simple solution is to not cast mod_MangMod into a byte, so instead, your telling java to "Take mod_MangMod.aliengrass (which is a Block), and make topBlock (which is supposed to be a block) into that". Bam, less confusing for java, less confusing for you, 100% more compilable.
I would suggest going about it backwards-- Instead of having block X do something to itself when lava is near to it, have lava do something to block X when it's near to block X.
It would help if we could see your code. The way the error report works it "This is what broke java (java.lang.NullPointerException), and it happened in this specific location (the rest of the junk in the error message)". So we would have to see your mod_Legitmus code (specifically, your load() method) before we can help.
Well, I'm not entirely sure what's going on, but then again, I didn't give it more than a cursory look.
If you're using Eclipse, have you tried dropping a breakpoint in the generation code and then debugging it?
Or maybe you could System.out.println the coords of any trees as they generate?
That should help you determine if they're actually generating or not, and then you can from there. Program debugging is a messy experience.
Add a check to see if the player is at full health and a check to see if the player has any experience. If the player has full health or doesn't have any experience, then return right there and then.
ModLoader.addSpawn can be called with an an extra parameter-- throw in a BiomeGenBase[] (array of BiomeGenBases) at the end, and it will add them as spawns for those biomes. Thus, to add one for the nether, you would add an array of one element containing the Nether BiomeGenBase as the last parameter of addSpawn.
Give me a moment to figure this out, in the meantime (before I edit this post), try putting your code in [\CODE] tags. That should fix the spacing.
EDIT:
I'm not 100% sure this will work (I haven't tested it myself), but have you tried overriding ItemSword.hitEntity?
A sword that (might) set enemies on fire might look like:
public class ItemFireSword extends ItemSword {
public boolean hitEntity(ItemStack istack, EntityLiving target, EntityLiving wielder) {
super.hitEntity(istack, target, wielder);
target.setFire(6);
}
}
0
Disregard everything in my previous post. The correct code ought to be:
0
0
Technical jargon aside, are you sure that you meant Item.ItemLegismus, and not legOre? Because Item.ItemLegismus means that you would have modified Item.java and put ItemLegismus into it.
A few other notes: you don't need to use Character.valueOf, you can just use the character itself, it will automatically be cast into it's required format. Also, I doubt that you need addRenderer, since it is empty and it's not abstract. Furthermore, it's probably good practice to have an actual version number rather than pi. Something like "dev build" or "0.00" if it's unreleased.
0
When you say
You're telling java "Take mod_MangMod.aliengrass (which is a Block), turn it into a byte, and make topBlock (which is supposed to be a block) into that".
The error is because it doesn't know how to turn a Block into a byte. Even if it did, there would be another error saying it doesn't know how to turn a byte back into a Block, because it has to take that and make topBlock be it.
The simple solution is to not cast mod_MangMod into a byte, so instead, your telling java to "Take mod_MangMod.aliengrass (which is a Block), and make topBlock (which is supposed to be a block) into that". Bam, less confusing for java, less confusing for you, 100% more compilable.
the fixed code would look like
And then you would repeat that for fillerBlock.
0
0
0
If you're using Eclipse, have you tried dropping a breakpoint in the generation code and then debugging it?
Or maybe you could System.out.println the coords of any trees as they generate?
That should help you determine if they're actually generating or not, and then you can from there. Program debugging is a messy experience.
0
If it doesn't work, I would fiddle around with the conditions in those if statements until it does work.
0
As for walking to a position... It's something to do with getPath. Look around, see how it's used, and teach yourself to use it properly.
0
0
0
0
Chances are it won't make you "level down" properly though.
0
1
EDIT:
I'm not 100% sure this will work (I haven't tested it myself), but have you tried overriding ItemSword.hitEntity?
A sword that (might) set enemies on fire might look like: