Michael V. Coppola
Comments
Set a 50 MB default ceiling if you wish, but this should really be a tunable/overridable limit for those who wish to utilize larger texture packs. So long as the pack itself is within Minecraft-supported parameters what is the functional need for such a small hard-coded file size limit?
If I am a server admin and I put my texture pack in CloudFront, Akamai, or any other CDN of my choosing it's not as if the texture pack will necessarily take a long time to download (which, to clarify, is burden of the client/server relationship anyway, and should be up to the admin of the server). If it becomes a problem for the client, they can simply choose to not use the advertized texture pack for that server, which is again the burden of the client/server relationship and not Minecraft.
Updating for current releases. Should also note that with the increase to texture pack sizes some sort of intelligent caching should be implemented to avoid repeated downloads of the same pack between play sessions.
I hadn't even heard of these utilities before, thanks for the explanation and modified pack!
Sounds good to me, I think those are some solid recommendations Zuriki.
Daniel, while I agree that this would more appropriately be filed as an "Improvement" in JIRA this was simply not an option when creating the issue initially. I just went back and double-checked to make sure I wasn't doing something wrong on my end, but the only option listed from what I can see is "Bug". To echo your comment, the functionality works as intended, however its design limitations are preventing it from being utilized across a broad set of scenarios.
To clarify, when I say "common scenario" I mean servers with additional blocks and items. Since I believe there are drastically more of these than vanilla servers out there, at least when it comes to public Internet-facing servers, this is a significant design limitation inherent to this feature.
Also, I appreciate you taking the time to understand where I am coming from with this request.
Perhaps not yet, but as I stated with more blocks and items added this will eventually wind up being a problem for vanilla servers as well as modded servers. I think we can agree that this is not an issue with mods, it's not an issue with modded texture packs, but that the file size limit is simply too small to support a common scenario with a supported 16x16 texture pack.
Regarding your comment on the dummy file, it is in fact a real argument to what Zuriki proposed as his comment implied this was not a problem with vanilla Minecraft due to the extra textures in my pack. I was providing a test to confirm this is not an issue with extra textures, that this is instead an issue with file size regardless of the content of the texture pack and this test confirms that.
I can also confirm when entering this same deathtrap and switching the lever in third-person you will exit in first-person. This is regardless of whether you are in creative or survival mode.
Another test you could perform Zuriki, take the official vanilla texture pack that comes with Minecraft and try the following:
1. Load in a single 10 MB dummy file to guarantee the size is greater than the 10 MB limit.
2. Rename and re-package the pack and publish it to an accessible web server (it can be local).
3. Configure this as the recommended texture pack in "server.properties".
4. Load Minecraft with the Java console open, connect to the server and read the output once you click "Yes" to "automagically" download the recommended texture pack.
You should see the same errors I posted above, even without any extra mods in the pack. It's a limitation of the file size, not the content of the texture pack.
I strongly disagree with your assumption Zuriki.
This isn't a bug regarding a specific texture pack or whether or not you can load it manually; this is a bug related to "automagic" texture packs downloaded as recommended packs on SMP servers. It does contain mod-related textures, but vanilla doesn't map these to anything as those blocks and items don't currently exist in vanilla builds. Any additional textures that are in the pack would simply be unused by a vanilla build of Minecraft.
But let's assume one day more blocks and items are added to vanilla Minecraft, as this has been the trend for the past several updates. These new blocks and items are causing texture packs to grow even for vanilla builds, which takes me to my main point:
Assuming vanilla Minecraft continues to grow and continues to get new blocks and items it becomes more and more likely that a 16x16 texture pack for even just the vanilla game would exceed 10 MB in size. This is a ceiling that needs to be adjusted, either with an override option made available to server administrators or adjusted within the code itself.
Furthermore, since you have stated you could open the pack without any issue manually (as can I) it only furthers my point that this is a limitation in the "automagic" downloader, as I have performed tests against both a modded server and a vanilla server above.
Hi Kumasasa, sorry I did not include this information in the original report. Please see the error message observed through the Java console below while on our primary server, as well as the corresponding HTTP 200 code from IIS. The maximum file size is denoted in bytes (10 MB = 10,000 KB = 10,000,000 B). The 10 MB limit was also confirmed when successfully downloading a texture pack weighing in just under 10 MB.
Java console output while on primary server:
2012-12-23 01:45:55 [INFO] [STDOUT] Deleting C:\Users\Public\Feed the Beast\FTBBETAA\minecraft\texturepacks-mp-cache\mc14_16x_isabella_ii.zip as it does not match what we currently have (14028561 vs our 0).
2012-12-23 01:45:55 [INFO] [STDERR] java.io.IOException: Filesize is bigger than maximum allowed (file is 3.0, limit is 10000000)
2012-12-23 01:45:55 [INFO] [STDERR] at jn.run(SourceFile:133)
2012-12-23 01:45:55 [INFO] [STDERR] at java.lang.Thread.run(Unknown Source)
IIS log output for the texture pack request:
2012-12-23 09:45:55 10.2.2.11 GET /ftb/mc14_16x_isabella_ii.zip - 80 - 50.46.243.53 Java/1.7.0_07 - 200 0 995 2197
I have also confirmed this is an issue with vanilla Minecraft by performing the same test against a vanilla server. Please see the error message observed through the Java console below while on a vanilla test server, as well as the corresponding HTTP 200 code from IIS.
Java console output while on vanilla test server:
Deleting C:\Users\mcoppola\AppData\Roaming\.minecraft\texturepacks-mp-cache\mc14_16x_isabella_ii.zip as it does not match what we currently have (14028561 vs our 0).
java.io.IOException: Filesize is bigger than maximum allowed (file is 3.0, limit is 10000000)
at jw.run(SourceFile:133)
at java.lang.Thread.run(Unknown Source)
IIS log output for the texture pack request:
2012-12-23 09:59:30 10.2.2.11 GET /ftb/mc14_16x_isabella_ii.zip - 80 - 50.46.243.53 Java/1.7.0_07 - 200 0 995 2220
Still an issue with 1.18.
My goal is to retain a viewable archive of our older worlds by forcing spectator mode, while preventing the generation of new chunks via disabling `spectatorsGenerateChunks`. This should not prevent spectators from loading existing chunks.