I compiled my mod and the textures don't work? They work in eclipse just fine!

I would assume because it can't find them? It needs to be inn the correct locations inn your zip folder.

 

If I recall it was:

Zip Folder Structure:

-src

-mods

|__ModName

      |___textures

            |____blocks

                      |____MyBlock.png

                      items

                      |____MyItem.png

I would assume because it can't find them? It needs to be inn the correct locations inn your zip folder.

 

If I recall it was:

Zip Folder Structure:

-src

-mods

|__ModName

      |___textures

            |____blocks

                      |____MyBlock.png

                      items

                      |____MyItem.png

 

Well, it wouldn't be the src folder, but rather the compiled mod's top-level package.  Typically "ModName" as well. "com" or "AuthorName" are also frequently used.  Depends on the hierarchical organization of the given author.  I don't use "com.whatever" because I don't have a domain name to use.

 

But essentially correct.

 

OP: you probably forgot to add the /mods/[textures] folder to the zip manually.  The compiler does NOT bring textures over.

What i have is

 

mods

    jerrymod

              textures

                      items

                      blocks

                      armor

 

 

 

The armor and blocks work.

The items dont!

 

 

 

bump!

I'm not sure what the problem is if blocks and armor is working, but not items.

 

:\

As for me, a have that as src/minecraft/mods/myMod/textures/items.

As for me, a have that as src/minecraft/mods/myMod/textures/items.

 

He's trying to put them in the zip file to distribute.

As for me, a have that as src/minecraft/mods/myMod/textures/items.

 

He's trying to put them in the zip file to distribute.

 

Yea that is for mcp  i have already compiled it.

this is what i have to find the texture

 

  }

public void updateIcons(IconRegister iconRegister)

{

itemIcon = iconRegister.registerIcon("jerrymod:SlimeTamer");

}

}

bump

Drag them into the .minecraft jar! Take your a folder that has: mods/jerrymod/textures/items/"youritemname.png". Then, open up your compiled .minecraft jar and drag the folder in!

Drag them into the .minecraft jar! Take your a folder that has: mods/jerrymod/textures/items/"youritemname.png". Then, open up your compiled .minecraft jar and drag the folder in!

 

No one should ever need to follow this advice.  I still have no idea why it keeps getting suggested.

If you're using Forge, no jar editing should be required, unless you've made base class edits.

same here. :\

 

EDIT : fixed it, my zip structure  :  [zip root]\mods\[mod name]\textures\items\item files

same here. :\

 

EDIT : fixed it, my zip structure  :  [zip root]\mods\[mod name]\textures\items\item files

 

So in otherwords....

 

Zip Folder Structure:

-src

-mods

|__ModName

      |___textures

            |____items

                      |____MyItem.png

 

Exactly what we told you.

Guys its not what folders i have or in what order its this. 

 

}

public void updateIcons(IconRegister iconRegister)

{

itemIcon = iconRegister.registerIcon("jerrymod:Olive");

}

}

 

Is this what you guys are using for your texture registering?

Also this isnt in mcp i have already compiled it.

Please don't tell me this is yet another Thread about missing @Overrides...

snipermine: Add @Override to all methods you want to override. updateIcons will most likely give you an error. Now think.

 

This tip probably should go to the FAQ (if it isn't there already )

 

To all the Java-Unsavy people out there: @Override *EVERY* method you create and remove the @Override if it creates an error ...

And this my friends, is me (former informatics-teacher) giving in to the ignorance of the ppl out there demanding to be able to put together mods, but not willing to learn any basic programming skills whatsoever ...

 

Learning Java/programming/software-architecture etc ... by programming a minecraft mod is like trying to learn how to operate a car by joining the WRC ...

To all the Java-Unsavy people out there: @Override *EVERY* method you create and remove the @Override if it creates an error ...

@Override only the methods you want to override. If it creates an error not just remove it. Think first.

honestly, if they would think first, this issues would solve themselves ... In general, if you choose to use a method name already exists in the current scope, the method will be overridden. The @Override is nothing more but a safety precaution if the original name changes (like now).

 

...

 

ok, my advice has been ambiguous, here's the corrected version:

 

@Override every method, if the @Override creates an error remove the @Override, not the method itself! This way every method that should be @Override-n will be and non is forgotten... If used like this the user don't need to know what he's doing and still doing it right

 

...

 

actually, reading my original post again, the advice has not been ambiguous at all I specifically mentioned to remove the @Override if it will create an error ...

 

And as you can see from my post, this is not an advice for the ppl out there able to create nice and well developed code ...

@Override only the methods you want to override.

 

and after reflecting a bit more about your statement, actually, it is not quite correct.

 

@Override every method that *is* overridden. If you want it or not is not the question. If you do not want to override a method choose another name ...

@Override giving an error means you probably want to override something, but you failed to do so. Removing @Override in that case will not fix anything.

 

you are of course correct if you presume you are dealing with somebody actually creating code. But here it is only a copy/paste of method profiles from the parent classes of from tutorials, thus I presume (I know, every presumption is the probability of errors ) the issues are not due to wrong method profiles (thus having wrong arguments), but original methods changing names and the overridden methods being orphaned...

the issues are not due to wrong method profiles (thus having wrong arguments), but original methods changing names and the overridden methods being orphaned...

Thats the exact usecase for @Override...

we do agree completely