If you make it static the code means something entirely different, as explained by apiXz above(edit: on the previous page). Let me guess, the error you're getting is "Cannot make a static reference to a non-static method", "A non-static method cannot be referenced from a static context", or something similar?
That's exactly what I'm getting. In one of my java files I'm trying to get TexturePackList.selectedTexturePack but I've tried so many ways to grab it without setting it to static but all have failed. Any ideas?
When not injecting RenderEngine/ur.class into Minecraft.jar I get this:
Exception in thread "Minecraft main thread" java.lang.IncompatibleClassChangeError: Expected non-static field er.a
at ur.b(SourceFile:124)
at net.minecraft.client.Minecraft.x(SourceFile:352)
at net.minecraft.client.Minecraft.a(SourceFile:250)
at net.minecraft.client.Minecraft.run(SourceFile:629)
at java.lang.Thread.run(Unknown Source)
I changed selectedTexturePack in TexturePackList to static and that's what's causing it. Any idea?
Perhaps by modifying those classes you changed some of the RenderEngine function signatures, which means that one of your new texture class objects is incompatibile with the original ? And that's why after recompiling the RenderEngine did change, even if the text is the same.
It's just a wild guess though.
Edit: By that I mean maybe you changed one of the fields in the texture classes from int to double and RenderEngine uses that. On the text level it's the same, but on code level the change causes this binary mismatch ?
That was just an example.
Why would it automatically change code in RenderEngine.java just by me copy and pasting files in there? It's impossible for it to do that. I didn't even start up Eclipse.
Alright, which of the normal files did you modify?
GuiTexturePacks.java, GuiTexturePackSlot.java, TexturePackBase.java, TexturePackCustom.java, TexturePackBase.java. Then three new files: GuiTexturePackInfo.java, TexturePackUpdate.java, and ThreadDownloadTexturePack.java.
So basically, it fails without the Renderengine class?
Yes.
I just tried a fresh jar and everything and it still thought I modified RenderEngine.class.
I'm redownloading MCP and trying a new whole install of MCP to see if that works.
I get binary mismatch errors or something of the sort when I don't inject it in the .jar.
I'm attempting to re try it with a fresh jar as we speak, even though the one I was using was clean in the first place.
I haven't even opened it. Nor have I touched it. As soon as I edit/put in my modified class files and re-obfuscate it thinks I change RenderEngine too. I have not even OPENED it.
No matter how many times I retry, it always things I changed it.
I really want to get a release out for my mod, but I can't when it thinks I changed class files I didn't.
Thoughts?
Yeah, sorry I'm fighting a cold at the moment. It'll take me some time to figure how the mods should work together, but I'll try to take a look at it soon.
I'm currently working on a Texture Packs+ mod which currently just updates texture packs, but I have a lot more features in mind.
I'm able to push out my first WIP release as updating is complete and works, but I just realized my mod overwrites about two or three of HD Texture's class files. I attempted to look at the source code for this... but I really don't understand how I would implement HD Texture's code in my mod. I can't find it.
Mind helping a fellow out?
Hey, this is a pretty good idea. But it falls apart when the texture pack author makes a mistake. What if the author uploads a wrong or corrupted version of his pack? There should be a 'revert to previous version' option for that. That does mean that you eventually end up with two versions of every updated texture pack, but that shouldn't be that big of a problem, right?
For that matter, what happens if the update is something other than a .zip file? Someone might get the idea to redistribute someone else's texture pack with a modified version.txt which then downloads a malicious file to your computer when you want to update it. Automatically downloading a file from a source unknown to the player is extremely, extremely risky. You better have some security measures in place to prevent abuse.
Also, I don't know if many texture pack authors are prepared to put there texture packs on direct download links that anyone can just pull from the version.txt. Have you considered simply making the update button redirect to the appropriate hosting site, where the player downloads the new version himself? It'd be a lot safer than automatic downloading, although I'm not sure if your method of determining whether a pack is outdated will still work that way.
There are many measures put in place to make sure nothing malicious is downloaded. It must be a zip that is downloaded. It also makes sure all the links are valid and are .txt files, nothing else. It is literally impossible to download anything other than a zip with this. If the zip contains a malicious exe per say, the said exe would not under any circumstances be automatically ran. It's like downloading a texture pack regularly, if the zip contains an exe, report it to the appropriate moderator on the forums.
Second of all, if the texture pack creator messes up a release, all he has to do is upload a new zip for the user to download. If he messes up the .txt in the texture pack's zip, that's his fault. He needs to get his things together. I cannot prevent people from making mistakes. I can only try to be clear enough so they don't make them. I might add a button that will open up the user's browser to the texture pack's thread, in case the creator messed up the release, the user can manually re-download it. If the creator royally messes up the release, to the point where none of the information about the texture pack is correct, then that's his fault.
If the update button just redirects to a website to download the zip, it pretty much gets rid of the whole idea of an in game texture pack updater. The point is so that the user can very easily install/update his texture packs without having to go to an external website and open up his texture pack folder just to update his texture pack.
I could add a backups folder and can add a "revert to previous version" button on the info menu when that is implemented. That is very possible.
Also, if you saw the pictures of the change log, that has been removed temporarily until I can find out a way to do it better. The way I was doing it was absolutely silly and redonkulous.
0
It's not even a static one. It doesn't say anywhere that the method is static. It's inside the run() method from a Thread, is that static?
0
That's exactly what I'm getting. In one of my java files I'm trying to get TexturePackList.selectedTexturePack but I've tried so many ways to grab it without setting it to static but all have failed. Any ideas?
0
0
Thanks man! I'm having some issues currently but I'm trying to get them fixed.
0
0
I changed selectedTexturePack in TexturePackList to static and that's what's causing it. Any idea?
0
I have already tried with a completely new install of MCP and it still didn't work.
And yes, there is, it is my mod.
Why would it automatically change code in RenderEngine.java just by me copy and pasting files in there? It's impossible for it to do that. I didn't even start up Eclipse.
Look at my previous post. I stated them.
I have not touched updatenames.bat.
0
GuiTexturePacks.java, GuiTexturePackSlot.java, TexturePackBase.java, TexturePackCustom.java, TexturePackBase.java. Then three new files: GuiTexturePackInfo.java, TexturePackUpdate.java, and ThreadDownloadTexturePack.java.
0
0
Yes.
I just tried a fresh jar and everything and it still thought I modified RenderEngine.class.
I'm redownloading MCP and trying a new whole install of MCP to see if that works.
0
I'm attempting to re try it with a fresh jar as we speak, even though the one I was using was clean in the first place.
0
No matter how many times I retry, it always things I changed it.
I really want to get a release out for my mod, but I can't when it thinks I changed class files I didn't.
Thoughts?
0
Thanks man! I'll be watching this thread.
0
0
There are many measures put in place to make sure nothing malicious is downloaded. It must be a zip that is downloaded. It also makes sure all the links are valid and are .txt files, nothing else. It is literally impossible to download anything other than a zip with this. If the zip contains a malicious exe per say, the said exe would not under any circumstances be automatically ran. It's like downloading a texture pack regularly, if the zip contains an exe, report it to the appropriate moderator on the forums.
Second of all, if the texture pack creator messes up a release, all he has to do is upload a new zip for the user to download. If he messes up the .txt in the texture pack's zip, that's his fault. He needs to get his things together. I cannot prevent people from making mistakes. I can only try to be clear enough so they don't make them. I might add a button that will open up the user's browser to the texture pack's thread, in case the creator messed up the release, the user can manually re-download it. If the creator royally messes up the release, to the point where none of the information about the texture pack is correct, then that's his fault.
If the update button just redirects to a website to download the zip, it pretty much gets rid of the whole idea of an in game texture pack updater. The point is so that the user can very easily install/update his texture packs without having to go to an external website and open up his texture pack folder just to update his texture pack.
I could add a backups folder and can add a "revert to previous version" button on the info menu when that is implemented. That is very possible.
Also, if you saw the pictures of the change log, that has been removed temporarily until I can find out a way to do it better. The way I was doing it was absolutely silly and redonkulous.