I might be wrong in saying this, but I'm pretty sure you have to have your mods in your net.minecraft.src folder. Not a seperate folder; unless this is a picture of them in the minecraft source folder.
Don't put your mods in that folder, even FML will log a warning if you do.
Yes you can work on multiple mods in same project and from looking at your error it looks like Forge can't tell which mod is which.
Do you have the instance annotation like this?
@Instance("ExampleMod")
public static ExampleMod instance;
Correct me if I'm wrong, but FMLInjectionData.data()[4] can be traced back to fml\common\fmlversion.properties, and it seems to be the mc version fml provides, not the jar itself..?
Yes, it refers to the properties file.
I see you found a way but I will put mine here as well. You can start the Usage Snooper Stats and get the property version.
What? Are you saying that my package declaration is too long?
You are missing the whole point lol. Package names are written in all lower case to avoid conflict with the names of classes or interfaces.
You called your package and class name DeveloperCapesAPI which is very confusing. Even MCF's code highlighter got confused, highlighted both of them purple.
So following Oracle's convention, this is what it means. DeveloperCapesAPI is a sub-class of DeveloperCapesAPI in the com.jadastudios.api package. That's why you make all packages lowercase, to point out which Class, Interface, or Enum it's referring to.
I belive the 2 = min to spawn per chunk, the first 4 = max to spawn per chunk and the last 4 = how often they will spwn, as in how often will that entity b called by minecraft to spawn it in world, the creeper would b high as it spawns alot. the higher the number the more often it will spawn
....Since my Entity is a Mech (The player will ride/control it, but needs to take damage/ have health). Do you think I should stick with extending to EntityMob or should I change to just Entity and work from there.
Well since it's not a Mob(unless you want it to be classified as one), I would just extend Entity. There you can have your health system. The method Entity.attackEntityFrom(DamageSource, int) will be called when attacked.
Also, in your post about fixing the invisible entities,
How do I do so that I will not have to edit base classes?
I was showing you how Forge and entity tracking works and not to use both methods. That's another issue I stated while back which isn't a problem anymore, I think. If you are using Forge's mod entity tracking methods, you're good.
@Init
public void load(FMLInitializationEvent event)
{
// steelBlock is null
gameRegisters();
languageRegisters();
// steelBlock is created
steelBlock = new BlockSteel(steelBlockID, Material.iron).setUnlocalizedName("TileSteelBlock");
}
Refine your Forge tutorial(s) and tell people what class to put it in, how t register it if its in a new class or not. i dont know where the hell im have to put the code man....
What else do you want me to show? I explained every sound event method, showed where to put them(EventHandler class), then on how to register it in the event bus in the preInit method of your mod. If it's too confusing then you shouldn't be making mods and learn coding basics. Don't know what else to say man.
0
You are getting this error because the method doesn't exist. Take a look at the return value,
The method returns EnumToolMaterial
Make sure that line of where you are using this method gets the correct return value.
0
0
Don't put your mods in that folder, even FML will log a warning if you do.
Yes you can work on multiple mods in same project and from looking at your error it looks like Forge can't tell which mod is which.
Do you have the instance annotation like this?
You should always put the mod id as an argument.
0
Yes, it refers to the properties file.
I see you found a way but I will put mine here as well. You can start the Usage Snooper Stats and get the property version.
0
You are missing the whole point lol.
Package names are written in all lower case to avoid conflict with the names of classes or interfaces.
You called your package and class name DeveloperCapesAPI which is very confusing. Even MCF's code highlighter got confused, highlighted both of them purple.
So following Oracle's convention, this is what it means. DeveloperCapesAPI is a sub-class of DeveloperCapesAPI in the com.jadastudios.api package. That's why you make all packages lowercase, to point out which Class, Interface, or Enum it's referring to.
0
http://docs.oracle.c...namingpkgs.html
That's why there are conventions
Think about it.
0
You do know this post is from 2011?
0
Well since it's not a Mob(unless you want it to be classified as one), I would just extend Entity. There you can have your health system. The method Entity.attackEntityFrom(DamageSource, int) will be called when attacked.
I was showing you how Forge and entity tracking works and not to use both methods. That's another issue I stated while back which isn't a problem anymore, I think. If you are using Forge's mod entity tracking methods, you're good.
this.modelMech.render(par1EntityMech, 0.0F, 0.0F, 0.0F, 0.0F, 0.0F, 0.0625F);
You may need to put the parametes instead of 0.0F. par2, par4, ...
0
You shouldn't call both methods
1
0
You're are saying that method is easier than putting your credentials in the run configuration arguments?
1
0
0
What else do you want me to show? I explained every sound event method, showed where to put them(EventHandler class), then on how to register it in the event bus in the preInit method of your mod. If it's too confusing then you shouldn't be making mods and learn coding basics. Don't know what else to say man.
0
What lol? I'm not going to go through this in another thread.