i'd back up your minecraft and try it using a fresh install. once the client is installed and running properly. run the patcher. seems the error may be because the file is in use so the patcher can't read it, or when patching it it corrupted the jar. if the patcher runs and everything goes fine test it out if textures there then great , move onto installing any mods you have. if not then well you have your backup.
I really sorry guys, but not willing to look through 31 pages.
Can I run ORIGINAL 16x16 TEXTURES WITH THIS?
Like, can i install this, use 32x32 textures, and then immediately use a 16x16 right after?
No, but look above, I requested a feature that'd allow you to do that, and more.
I really sorry guys, but not willing to look through 31 pages.
Can I run ORIGINAL 16x16 TEXTURES WITH THIS?
Like, can i install this, use 32x32 textures, and then immediately use a 16x16 right after?
No. See comment below.
Quote from Vanadium »
Quote from xau »
Quote from horsetheking »
########## GL ERROR ##########
@ Pre render
1281: Invalid value
I think this happens when it's trying to use textures of a different size than it's patched for.
I am posting this here instead of on your issue tracker because I am not sure I understand what all your issues mean but do you intend to make it dynamically divine the intended texture size for each texture pack or do I actually have to go and blow up my 16x16 textures to 32x32 to have them work in the built-in texture chooser thing?
Also do you intend to load custom water from texture packs instead of hardwiring it into the .jar?
Xau said a future version would access the custom_x.png files from the pack.zips.
Perhaps the info is not all in the first post, but it's here in this thread.
This patch can only patch Minecraft to use ONE resolution! This is due to the changes to the code base and image files that are required.
Basically Notch's code looks for a specific offset in an image file and copies data from there, then it places a version of that data in another location in the image file ( not the actual file, but a copy in memory ). In order to change Minecraft to use differing textures on the fly all of the changes that occur when patching would have to be executed on each resolution change. Some of those changes are to graphic files and some of those changes are to class files. This is most likely unworkable in practice.
If all classes that are modified to look for a specific offsets in an image were modified to reference a ResolutionVariable for those offset calculations and that ResolutionVariable was modified when selecting a new resolution then on-the-fly code changes could be avoided. Code would have to be generated to determine the resolution of the current pack ( trivial ) and modify the ResolutionVariable. I don't know if that's possible or practical since I haven't reviewed the code. Maybe Xau can comment on that.
Regardless of that change, it would require generating copies of all default textures in each of the possible resolution so that when one of them is missing from a texture pack the code could access the appropriate one from the pre-generated XRES x YRES set. That should be doable.
I think it would be helpful and reduce the questions here if Xau were to write an in-depth analysis of the code he's modifying and explain to us all how it works internally. And maybe he could teach a class and sit idly by waiting to answer support calls 24/7, but I don't think that's going to happen.
Anyone that really wants to know what Notch's code is doing, and what can be done with it through modding can open it up and start the long slow march of learning. Just like Xau did. And that includes me.
I was kind of hoping it would be as easy as changing every absolute offset or size in the code to a fraction of the relevant image file. Oh, well.
It could be accomplished that way as well, but that is inefficient as the computation only needs to be performed once with a variable that's set at the rez change event, while you'd recalculate it repeatedly for every frame using your method. The same changes to the code would be required for either.
whenever i click on my minecraft.jar file it says "Error loading zip file" ive erased all my minecraft stuff, redownloaded it and erased the bin folder and everything and i cant get it to patch.
1.1.8 isn't doing it for me. Black screened after patching and launching, so I unchecked animations. Black screen again. Unchecked everything. Black screen once more.
This whole 'Minecraft not supporting anything other than 16x16' really sucks.
Can you make this so that it can simply output the modded classes, so that HD packs can be loaded with the in-game texture pack loader?
The "Mods" portion of the main screen text is referring to his official mod API when he implements it.
It will -not- load class files from the texture pack zips.
Quote from Dr. Zaius »
1.1.8 isn't doing it for me. Black screened after patching and launching, so I unchecked animations. Black screen again. Unchecked everything. Black screen once more.
This whole 'Minecraft not supporting anything other than 16x16' really sucks.
And this is what I get when I try to run minecraft:
[java, -cp, null/minecraft.jar;null/lwjgl.jar;null/lwjgl_util.jar;null/jinput.jar, -Djava.library.path=null/natives, -Xmx1024M, -Xms512M, net.minecraft.client.Minecraft]
java.lang.NoClassDefFoundError: net/minecraft/client/Minecraft
Caused by: java.lang.ClassNotFoundException: net.minecraft.client.Minecraft
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: net.minecraft.client.Minecraft. Program will exit.
Exception in thread "main"
It could be accomplished that way as well, but that is inefficient as the computation only needs to be performed once with a variable that's set at the rez change event, while you'd recalculate it repeatedly for every frame using your method. The same changes to the code would be required for either.
The computation of looking up a number in the already-loaded texture object sure is orders of magnitude slower than whatever you are suggesting, which is probably the same thing with a bunch of boring technical details carefully obsessed over.
Yes, I was a bit wordy, but my comment was sort of aimed at Xau.
What I was basically saying is that when you're at walt disney world and you park you car, it's best to remember that you're in Donald Duck - space 149 rather than remembering that you are 29% of the parking lot width west and 77% of the parking lot width north of the entrance gate.
When you're ready to go to your car you'd need to count the number spaces north and then count the number of spaces west and do some math. This is particularly more trouble if you plan on visiting your car several hundred times per second, all day long.
Guys I have the flu so I'm not really able to keep up right now. I turned off PMs - if you have trouble please post in the thread so others can help you. Please use the "search this thread" box first. Big thanks to you guys who have been helping out a lot (Jay, Redwuff, and Nurio off the top of my head).
re: dynamic sizes, this is something I'm working on for the next version but it's not nearly as simple as replacing every hardcoded 16 with a variable lookup/method call. If it was that easy it's what I would have done to begin with. All the animations have fixed-size buffers they draw in or are based on and the animations start going when Minecraft starts. They need to have their buffers reallocated and restart the animation, but there is no real 'event' when you switch texture packs. It just changes the object that hands out textures, so next time some piece of code asks for an image, it gets the one out of the texture pack instead. Also I'm sure there's a bunch of crap I don't remember or haven't even encountered yet.
Dang, thanks but still didn't work :< Here's a picture of my error...
http://farm2.static.flickr.com/1224/5168829848_fc59e98a21_b.jpg
No, but look above, I requested a feature that'd allow you to do that, and more.
See my post about a half dozen earlier, I was getting this error, and managed to get rid of it.
Redwuff
No. See comment below.
Xau said a future version would access the custom_x.png files from the pack.zips.
Perhaps the info is not all in the first post, but it's here in this thread.
This patch can only patch Minecraft to use ONE resolution! This is due to the changes to the code base and image files that are required.
Basically Notch's code looks for a specific offset in an image file and copies data from there, then it places a version of that data in another location in the image file ( not the actual file, but a copy in memory ). In order to change Minecraft to use differing textures on the fly all of the changes that occur when patching would have to be executed on each resolution change. Some of those changes are to graphic files and some of those changes are to class files. This is most likely unworkable in practice.
If all classes that are modified to look for a specific offsets in an image were modified to reference a ResolutionVariable for those offset calculations and that ResolutionVariable was modified when selecting a new resolution then on-the-fly code changes could be avoided. Code would have to be generated to determine the resolution of the current pack ( trivial ) and modify the ResolutionVariable. I don't know if that's possible or practical since I haven't reviewed the code. Maybe Xau can comment on that.
Regardless of that change, it would require generating copies of all default textures in each of the possible resolution so that when one of them is missing from a texture pack the code could access the appropriate one from the pre-generated XRES x YRES set. That should be doable.
I think it would be helpful and reduce the questions here if Xau were to write an in-depth analysis of the code he's modifying and explain to us all how it works internally. And maybe he could teach a class and sit idly by waiting to answer support calls 24/7, but I don't think that's going to happen.
Anyone that really wants to know what Notch's code is doing, and what can be done with it through modding can open it up and start the long slow march of learning. Just like Xau did. And that includes me.
It could be accomplished that way as well, but that is inefficient as the computation only needs to be performed once with a variable that's set at the rez change event, while you'd recalculate it repeatedly for every frame using your method. The same changes to the code would be required for either.
Yes, this works! Selecting the texture pack and I want to use IN-GAME and then using the HD texture fix resulted in a fix. Thank you.
This whole 'Minecraft not supporting anything other than 16x16' really sucks.
The "Mods" portion of the main screen text is referring to his official mod API when he implements it.
It will -not- load class files from the texture pack zips.
Disable custom liquids, not animated liquids.
Check it out, give me feedback.
And this is what I get when I try to run minecraft:
[java, -cp, null/minecraft.jar;null/lwjgl.jar;null/lwjgl_util.jar;null/jinput.jar, -Djava.library.path=null/natives, -Xmx1024M, -Xms512M, net.minecraft.client.Minecraft]
java.lang.NoClassDefFoundError: net/minecraft/client/Minecraft
Caused by: java.lang.ClassNotFoundException: net.minecraft.client.Minecraft
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: net.minecraft.client.Minecraft. Program will exit.
Exception in thread "main"
What should I do?
Yes, I was a bit wordy, but my comment was sort of aimed at Xau.
What I was basically saying is that when you're at walt disney world and you park you car, it's best to remember that you're in Donald Duck - space 149 rather than remembering that you are 29% of the parking lot width west and 77% of the parking lot width north of the entrance gate.
When you're ready to go to your car you'd need to count the number spaces north and then count the number of spaces west and do some math. This is particularly more trouble if you plan on visiting your car several hundred times per second, all day long.
;^)
re: dynamic sizes, this is something I'm working on for the next version but it's not nearly as simple as replacing every hardcoded 16 with a variable lookup/method call. If it was that easy it's what I would have done to begin with. All the animations have fixed-size buffers they draw in or are based on and the animations start going when Minecraft starts. They need to have their buffers reallocated and restart the animation, but there is no real 'event' when you switch texture packs. It just changes the object that hands out textures, so next time some piece of code asks for an image, it gets the one out of the texture pack instead. Also I'm sure there's a bunch of crap I don't remember or haven't even encountered yet.