So first they try to make the site ridiculously family-friendly with strict swearing filters, now they force users to link accounts with an unrelated site that makes gratuitous use of streamers who swear for the entertainment of their viewers. Delicious irony.
Glad I avoided my invitation to the Curse summit all those years ago. Hate to think about potentially being part of the mess this has become.
-
- Misa
- Registered Member
-
Member for 13 years, 8 months, and 12 days
Last active Fri, Mar, 24 2023 00:25:26
- 28 Followers
- 828 Total Posts
- 1350 Thanks
1
Please learn to read the first post, usage instructions or readme file for anything you download:
If you use a dishwasher to wash your clothes, and the dishwasher breaks because clothing jammed it up, you can't call up the dishwasher company to file a complaint and expect to be taken seriously.
0
That's not an issue with my pack. It's either caused by MCPatcher or Mojang's latest snapshots (Which this pack does not fully support yet). Experiment to determine which and redirect your report to one them. The version this pack is designed for does not have this effect.
0
Yeah, uncompression errors are generally related to the headers - if they are improper 7zip will refuse to extract those files correctly stating "unsupported compression method". I guess because of these bad objects in the zip we could be having issues
Misa,
Would it be possible for you test the decompression of this file? You are probably the best person to reaffirm the integrity of this archive
Misa: because of all the zip file problems from other users and me (and the missing active detector rail image), would it be possible to upload another copy of the texture pack for 1.5.x (even if it only has images to that point of the game updates & not beyond), especially since 1.6.x (and its snapshots) is cutting any work on the current texture pack to near nil?
If you answer any* form of yes: thank you.
If you answer any* form of no: I understand (I remember what you said a while back)
*by any, I mean any that don't have stipulations that are major/severe. Those answers would require a specific reply, though likely still along the same lines as the general reply.
I've already addressed this, and others have posted fixes and workarounds. I've already announced that the pack will be repackaged by the next time I update, along with fixes to all the missing/bugged stuff that's been reported. Just be patient until then or use the search feature to see temporary workarounds posted on the subject.
I thought it'd be annoying to work with the new hardened clay texture too, but once again, CTM saved the day and I still got to maintain the realistic material-derivative consistency of my pack while having a valuable new building material to work with.
Adobe anyone?
I can do 3D too, and long ago I redesigned all of the game's mob models to be more realistic while retaining a blocky but anatomically-correct design that used coordinate re-mappings of the default game's texture maps as part of a proof-of-concept experiment. If the language/interface format for the modding API were easy enough for me to pick up without too much of a time investment in learning Java, I'd love to release a "Misa's Realistic Model Pack." Of course that also depends on if I'm still around by the time the API is released.
I cannot fix an isolated incident. You're the only one to report this issue and my tests cannot reproduce the problem you're experiencing. My guess is you have some mod conflicts or installed the pack improperly or over a dirty installation. Following the cleaning and installation instructions on my thread should fix the issue for you.
No, this texture pack does not work on an unmodified client. The majority of high resolution texture packs still require a client modifier despite Mojang's poor attempt to add support for high resolution texture packs. Their animation rendering method is pretty atrocious and doesn't support custom non-block animations. They also lack custom color support and CTM which this and many other packs (including low resolution packs) rely upon.
As far as the HD thing goes, HD is not the correct term. High definition typically deals only with full screen resolution (terms like "HD audio" are meaningless buzzwords) and is more of a television marketing gimmick than anything--Computer monitors and videos cards have had "HD" support as the standard since the early 90's.
To refer to texture resolution, typically the term "High resolution" is what's used. As far as Minecraft goes, anything above the default texture resolution of 16x16 is considered high resolution. In practice 256x256 is the highest practical resolution for Minecraft texture packs but requires a proper computer designed for gaming to make use of (Though there are several 512x512 and 1024x1024 packs out there as well). 64x64 is the best compromise I've found in performance and visuals for the majority of players with gaming and non-gaming computers. 32x32 is also good and probably more recommended for servers. I would never recommend 128x128 and above for enforced server texture packs and the performance variance among players will vary widely and be unplayable for many.
A bit of a myth to dispel is that higher resolution texture packs always look better than lower resolution texture packs. Art style, design consistency, and material recognizability have greater effects on how good a texture pack will look than the resolution it uses. There are styles that are best suited to 16x16 that would simply not work (or be a complete waste of pixel resource usage) on higher resolutions and the inverse would hold true for different styles. Ideally people shouldn't ever judge a texture pack based on its resolution but rather on how it looks to them in-game and how practical it is for the application they're using it for. For instance if you were using a texture pack for a vanilla minecraft server, you'd want to avoid specifically-themed and novelty texture packs that stray away from the vanilla concepts of blocks to avoid player confusion. Personally I'm against server-enforced/distributed texture packs. A server recommending an official pack and providing supplemental textures for said pack for unique server content is more ideal. I think people should ultimately have the option to use whatever texture pack works best for them though.
0
3
The model's what bugs me more than anything. The default textures have had poor and inconsistent designs for ages. This is part of the reason I started my texture pack in the first place. The whole "8-bit design" label also bugged the hell out of me since I first started playing the game. There is absolutely nothing 8-bit looking about the art style of this game. Typically, 8-bit art should have a very limited color palette for each tile (around 4 colors per). The art in this is just random, colorful, pixellated art with a disgusting overuse of a noise filter. Fortunately all of it can be avoided/corrected with texture packs--the inconsistent model designs on the other hand cannot.
I think I chose my words well ("may").
-Pretty sure more than one person has already given an example of how else they could've done it...
-Making it simpler wouldn't make it too ugly, and definitely not out of place compared to the designs of all the other standard mobs.
-Why on Earth would you want visual favoritism for a single type of mob just because it happens to be one (of several) that can be kept as a pet? For the sake of consistency would it not make infinitely more sense to update the look of all the other mobs to match?
-What about the Enderdragon? It's a climactic final boss mob and the only mob that spawns once per map. More importantly though it's physically massive compared to all the other mobs. You can get by with more polygons in your model when your model is many times the size of the average-sized models... It's really kinda pointless to compare the Enderdragon to the standard mobs.
Going by the sheer volume of popular Minecraft videos that are centered around the survival aspects of the game over the creative aspects as well as the fact that Minecraft was primarily inspired by a strategy game and a team PvP game, I believe you mostly speak for yourself. I'd personally like an actual game with gameplay that challenges me over a mere Lego sandbox. I wouldn't complain about game balance and system design issues in the first place if I didn't care for the RPG/survival aspect of the game (I actually wish they were much more emphasized and less half-assed).
If I wanted to just build stuff, there already are vastly superior tools out there made specifically for that sort of thing. My pack has always been designed around survival mode rather than creative mode (That's why I try to be consistent with visually matching materials to their recipes). Sure I wish there were a hell of a lot more construction options for creative builds, but I didn't even think about purchasing the game until I first saw snapshots of indev. I pretty much only play creative mode these days (when I do play), but it's more out of a complete lack of depth and balance in survival than anything.
White textures = insufficient memory to load texture. Better Skies is an optional mod that uses massive texture files--disable it to correct the problem, or read the FAQ to see if you can get it working on your computer through optimization of your installation.
Do you want me to stop updating it or something?
Anyway, like many people, I prefer to avoid starvation and homelessness. This texture pack unfortunately happens to be the closest thing I have to a job that's paying the bills and keeping me alive and off the streets right now. Also for as many problems as I have with what Minecraft's become under the current management, I still like working on my texture pack--much moreso than playing the game when I'm inspired. If I didn't care to update the pack anymore, I wouldn't be complaining about the hindrances to it in the first place. If I really didn't care, I'd simply announce my resignation and walk away.
Grab a tool like 7Zip, open the texture pack you're editing and simply drag and drop the char.png in the mob directory within that zip. Also if you've uploaded a skin to Minecraft.net, be sure to intentionally typo your username or password when logging in and play off-line, otherwise the game forces you to use the player skin you uploaded.
I've known about the GLSL shader mod for years--I was one of the ones who first popularized it. And then I dropped it when it failed to address any of the issues I had with it. Read the FAQ and use the search feature for more information.
0
I completely agree.
...altough with the head of the actual one.
If they are going to go with the current head ( the model of which contains more than seven boxes) they seriously need to update other mobs. Next to the current horse model, the cow bears practically no resemblance to its real life counterpart. Compared to the horse, the cow is now some squatty little pig-like creature with elephantitis in its legs, no tail, and a flat faced skull with no snout or neck.
Pretty much the exact opposite of what it should be when compared to a horse.
2
You do realize that that has absolutely nothing to do with any of the points I made, right?
Their design is the same, and they are made and coded by the same guy. Don't blame mojang for wanting to implement a cool idea to Minecraft directly from a mod which has a different design scheme, blame the mod creator for having a different design scheme. In fact, don't blame anyone at all...
Why on Earth not? Mojang made a conscious effort to implement this mod in the way they have. The way they have done so is horribly inconsistent design-wise without a retrofit of pre-existing mobs and something to address the the system balance issues it creates with mobs like pigs--which pretty much again have no unique utility as opposed to every single other mob. By saying no one is to blame here, you're pretty much saying that Mojang isn't responsible for the decisions made by Mojang. I could not disagree more.
...I think Minecraft needs a change-up in the design every once in a while.
I never said they didn't. Consistency is still a major element of good design though. When changing the design, retrofitting is required, and old problems should be addressed before adding the new design model which has the potential to compound existing problems. If you wanna talk about changing up the design, personally I think the whole damn thing should be remade from scratch.
Keep up the good work on the pack, bro!
I'll try, but I'm not a bro.
And remember to texture the armor and saddles when you have time...
And remember, I've been modding Minecraft since before half of the Minecraft design team at Mojang even first heard of the game. This isn't one of my first rodeos so to speak
3
Mojang's design consistency began to suffer around the time Notch stopped working on it, and has just been getting worse over time. They're making a lot of mistakes that even first-year design students would know to avoid. The game may be worked on by competent coders, but their design skills reek of incompetence in the areas of system design, content design, and graphic design. For every new feature they add, they ignore several broken ones and they take a new and inconsistent approach to the design without retrofitting pre-existing elements of the same system.
At this point it's so bad that I'm pretty much hoping (though without much faith) that Minecraft's success spawns a clone that's superior in enough ways that I can shift all of my efforts over to supporting it instead. For as little faith as I have in this happening, I have even less faith in Mojang correcting all of their design mistakes.
0
0
In regards to the pack, the alternates pack I was working on will be temporarily delayed (but with good reason). There's some new experimental features I'm investing all my time in which I don't want to give too much away on just yet. All I'll really put out for now is that they involve items and the current progress on them is proving to be quite sexy.
0
No need and no point to. There's already a bunch of fans out there who have created companion textures for my pack and various mods. Just Google around. I don't use any of those mods, so I wouldn't really be the best one to do their textures any justice. I also have so many things to do on the main pack that trying out new mods like these to get a good strong feel for them would just be counter-productive.
Read the last few pages.
And I'm curious to know where you got that texture on the right--because it certainly wasn't from my pack. It's clearly been edited to increase contrast and saturation. I made this pack in the first place because the bright colors on the default pack wore out my eyes after extended periods of play and the realistic setting lends itself well to this color scheme. You either edited it yourself and forgot, downloaded someone else's pack that used some of my textures with edits, or downloaded an illegal re-posting of my pack that had the saturation and contrast increased to above realistic levels. I have at no point edited the saturation or contrast of my lapis lazuli ore blocks.
Also "muddy,"--you keep using that word. I do not think it means what you think it means. Muddy textures refer to anything that causes textures to look like they're being viewed through a filthy lens. This is most often a result of low resolution textures that look really blurry or messy when bilinear/trilinear filtering is applied by the rendering engine. It can also apply to textures that have a lot of compression artifacts (as can be found in jpegs) The correct terms you're looking for are desaturated and low contrast--which is pretty much the intended color design for a realistic setting that doesn't make use of dynamic lighting or auto color correction.
Pro-tip: If you want my texture pack to look like the image on the right with little effort, go into your video card or monitor's settings and increase the contrast and saturation. With these simple adjustments you can make any texture pack as radioactively eye-raping as you want:
I replaced the far corner with slabs to illustrate the appearance of before I deleted the CTM file...
...with the issue I'm having with the zip file in general, I can't even make any of the changes I want to the pack. I've already got all the blocks changed (including Red Velvet Cake (and item), Blue Creeper Blanket Bed (excluding item), Moss Stone, Lapis Block, Wood Door, and a few others)... I just need to copy them into the zip folder (and because of the error I mentioned previously, I can't (simple "Not Implemented" error).)I'm not sure I agree that the solution you came up with looks better, but I'll play with them a bit and see if I can come up with something better. It does make sense to have the blocks different from the slabs for variance. I just have to consider the impact this could have on people's builds, and what design compromise would work well.
In the meantime you could always try using Google to find a fix for corrupt zip files--especially if you're on Mac or Linux. They typically seem to the only OS's that have been affected by this in the past. On my end, the downloaded zip file works perfectly fine so I'm sure there has to be a way to fix/recover the zip on your end until I can repack it and post another update.
Already been reported and already fixed for the next update.
Activated detector rail. (ie:textures/blocks/detectorRail_on.png)
I've already stated twice that it's Mojang's handling of the CTM files in my pack that's bogging down the performance. randomobs and animations aren't a huge performance hog, and there's no reason for me to delete these things if people can do this themselves if it helps them.
Erm... Did you even attempt to look for this beforehand? Like at the very first paragraph of the entire thread? Or y'know, the download section... The places you'd normally look for such a thing...
!!!Spoiler Alert!!!
1
All of their mob models are pretty terrible in regards to proportions. I actually designed a bunch of more anatomically-correct (but still blocky!) models for all the mobs a couple years ago which could still use the default texture format with just different mapping, it's a shame I can't really do much with them, else I'd probably have something like a "Misa's Realistic Mob Model Pack." The larger eye would've looked much better on that model:
(my old squid model without texture mapping)
This is also first and foremost a realistic pack, and it might break immersion to be running into cameos on commonly-encountered mobs. All of the mobs that have weird cameos also require you to be playing outside of peaceful mode, are typically encountered in dark conditions and usually have to be killed or ran away from if you're close enough to observe them. These mobs all tend to be things that are unrealistic to begin with--hence I can play around with their design more in a realistic setting.
Also the dynamics of randomobs can change with the roster count on maps and updates to how Randomobs is handled. Say I were to add a Milka cow to the roster and make it really rare. Someone could find one and capture it for their farm or breed one from two normal cows, and then say something changes with Randomobs or the map's data for it. They'd still have a cow, but its texture could change and they'd completely lose their extremely rare Milka cow. The solution to that would be to make it as common as other cows, but then you end up with the whole realism-breaking problem. People who didn't get the reference would just be confused. Milka for instance is pretty much completely unknown in the U.S.. The only reason I know of it is because I had a friend in Europe who clued me in on it. Hopefully now you have a better idea of where I'm coming from and the balances I have to strike for the sake of consistency.
Stalfos were actually the first thing considered for a cameo with skeletons in general.
Please try responding to the request next time instead of ragequitting the pack over a single block that's not even intended to be usable. I'm trying to help you here, but I can't help you if you don't help me first. As best as I can tell, this block you're referring to no longer exists (through no fault of my own). Block ID 43:7 as of v1.5 is now officially used by Mojang as the double quartz slab. The smooth double step block is simply gone from the 43:7 id slot. (There was even a petition to Jeb during the 1.5 snapshots about this.)
I disabled my pack and checked this block out on the default textures. It does not show up as a unique stone texture at all. It uses the standard quartz block texture on all faces and is 100% identical in appearance to block 155 (Quartz block). Every single up-to-date texture ID database on the Internet also shows this to be the case. So again I ask, how would you propose I fix this? As far as I can tell, what you're looking for no longer exists in 1.5 as 43:7 and would be physically impossible for ANY texture pack to pull off without simultaneously removing the side texture from quartz double slabs. I'd be happy to be proven wrong about this though.
You make the claim that "Other texturepacks have the distinct difference between the stone blocks and the quarts slabs." Please link me to one of these other packs so I can see what you're referring to for myself first-hand.
That's not a bug, and that's not an angry village particle. That's Mojang being stupid and thinking that growing crops needed a special particle for visual feedback (as if the crop visually advancing in stage wasn't enough), then them recycling the "level up" particle from NPC's for this. The anger villager particle on my pack is of Cross-popping veins. The "villager stock level up" icon that Mojang recycled for this is a jagged business graph arrow indicative of rising stock. If my texture pack was for personal use only, these NPC particles wouldn't even exist in it. But I know if I remove them, enough people will then report that I'm "missing" textures and need to update. Sometimes I just can't win.
Now I must try to sleep. It's like 4am here and I have stuff to do tomorrow/today. Insomnia's a bitch.
0
-I never played Soul Reaver for more than a few minutes. But yeah, they don't look too zombie-esque. If I do include vampires in my zombie randomobs, it'll likely just be the more iconic vampires like Count Dracula or Nosferatu.
-I guess I can do some minor variants for the magma cubes so long as I can find the resource files I created for them and remember the process I used.
-A powered down blaze wouldn't only really work in my mind if they randomly powered up or powered up when attacking. Being attacked by a powered-down blaze would look weird.
-Animations for ghasts are something I'm trying to avoid if possible--my pack is already close to approaching critical mass for some machines thanks to Mojang.
-I already have plans for other bats. Zubat won't work for this mob though for reasons which I'll outline below.
-Spongebob is a bit after my time.
Below is a list of the design themes I have for each mob type as far as randomobs is concerned:
Bats: Natural, real-life species only.
Cats: Natural, real-life breeds only.
Cave Spiders: Real-life species of mainly orb-weaving types of spiders only--species with higher abdomen to cephalothorax ratios.
Chickens: Natural, real life breeds only.
Cows: Natural, real life breeds only.
Creeper: Camouflage is the main theme here. Pop cultural cameos are to be avoided. Basically creepers should only be associated with patterns and disguises that may aid them in creeping. Some may take it too far to humorous effect (Christmas Tree Creeper in snow biomes), but they should be rare.
Enderman: No Randomobs. The enderman is one and all.
Blaze: No real plans for randomobs.
Ghasts: These are a bit tricky. I'll probably just stick to a unique alien-esque theme though and avoid pop cultural cameos. I may just do something with skin patterns on the base design in the end--I'm still not sure how I want to handle these. (Though I did always sorta want to somehow work a Cacodemon from Doom into the roster)
Magma cubes: I don't think I want to take them in the same silly direction I did with slimes. I think of them as one of the lesser sentient enemies and more as a force of nature. I don't see randomobs as being necessary for them.
Ocelot: A very specific species with a specific pattern, not much need for drastic Randomob variations.
Pigs: Natural, real-life breeds only.
Zombie Pigmen: As with my other undead mobs, cameos are welcome. The theme for these cameos should be pop cultural pig-related things only.
Mooshrooms: Designs currently based strictly on existing in-game mushrooms. If you want more Mooshroom alts, tell Mojang to add more mushroom types to the game. (Bio-luminescence as a source of colored lighting sound awesome to anyone else? :P)
Sheep: Natural, real-life breeds only.
Skeletons: Pop cultural cameos welcome. The cameo theme for these is famous archers or famous skeletons only.
Wither Skeletons: Pop cultural cameos welcome. The cameo theme for these is famous swordsmen or famous skeletons only.
Slime: These are a bit of a silly grab bag and intended to be one of the cuter designs. Their alts are mostly intended to be based around cute/silly accessories and hats. Some may also have faces that resemble popular characters with a similar body (wherein the head is also the body as is the case with Dopefish and Cool Spot).
Snow Golems: Faces should be pretty typical, cute snowman designs. Pumpkin is used as an accessory of some sort, but the overall body design is largely uniform.
Spiders: Real-life species of mainly hunting/jumping types of spiders only--species with relatively higher cephalothorax to abdomen ratios.
Squid: Realistic in design with color/pattern variants only.
Wither: No randomobs. Rare boss mob.
Wolves: Natural, real-life breeds only. Mainly looking for wild dog and wolf breeds, but some domesticated breeds are acceptable if they're close to wolves in appearance.
Zombie: The start of the whole silly cameo thing. Reasoning behind this is that the undead are silly enough in concept that they shouldn't be taken too seriously. Cameos should be limited to pop cultural things with strong ties to the undead or zombie culture. Some of the subtle generic zombie designs are of players. IE: There is a zombie version of myself along with a few friends who have helped me with the pack. They have a generic zombie design with a few identifying traits usually limited to clothing color, designs, and accessories.
Zombie Villagers: Based strictly on undead versions of existing villager skins. No real plans to do an undead version of every single villager skin made.
Villagers: Generic designs with no real cameos. Villagers of certain classes share the same outfit and headgear style in different colors and prints only. Facial and racial, and age variety is important to give each villager a unique character quality. Animation of their faces is on the to-do list.
Enderdragon: No randomobs. There's only one of these per map and the skin files are massive.
Refer to this design plan when coming up with suggestions and they'll be more likely to make it to the to-do list if they conform to it.
You haven't been following the development news much I take it. The modding API is not a rumor. A rumor requires that the account given is unverifiable and circulated through word of mouth interaction among those unrelated to an official source. The modding API was something that was talked about by Mojang for a long time but never really outlined and put on the development schedule--that is until recently. The last public panels Mojang did were for the and the . They have outlined many of the specifics of how the Modding API will work and many of the features in 1.5 (namely the texture pack changes) have been specifically made to make way for the format of the Modding API. Mojang plans to rewrite the game's render engine as well as create a new client launcher. The modding API will handle mods sort of like a free app store within the game's client. Mods will be uploaded to an official server and will be distributed through the game itself. The major rewrite we went through that combined the server and client for single player was one of the first steps towards making the game rely on a modular server-based system. The evidence at this point is overwhelmingly against the Modding API being simply a rumor.
No problem and I greatly appreciate the support. I'm amazed how many people have completely glossed over the posts about how much of a drastic improvement in performance disabling advanced GL is. Anyway don't worry, I'm not going anywhere. This pack is still fully up to date and fully compatible with 1.5 and will run fine on many machines. Really I just hope Mojang fixes the problem they've created with the unnecessary duplicate rendering of textures. While it's not recommended for visuals, disabling CTM should make the pack playable on even some of the weakest computers.
It's always nice to see appreciation for the amount of effort I put into the consistency, color design, and flow of my pack.
You apparently didn't read the post I directed you to in my response... Specifically this part here:
...Unfortunately there's this issue where the client can render like 2-3 copies of each texture used for absolutely no good reason at all. It basically makes texture packs without extra features run performance-wise as though they were texture packs with extra features (due to the resource duplication). Packs like mine with CTM files though are greatly blown up by this flaw. This was not the case pre-1.5...
It's Mojang's handling of CTM textures that's causing most of the problems. Performance is decreased on other packs, but it's negligible below a certain threshold. CTM is basically the straw that breaks the camel's back, and Mojang are the ones duplicating and multiplying the straw count for no good reason at all. I never said Better Skies was the cause of the problem, I just said it along with the custom compass and clock can be disabled to improve performance as they are considered optional features. There is a lot in my pack that relies on CTM which is why I don't consider it optional, but if you can enjoy the game with CTM disabled, go for it. I just personally can't recommend it because I'm a perfectionist who's spoiled on what my pack has become through CTM and can't really testify to the pack looking good enough to use without it.
Try the third mirror now. Rapidshare decided to change their layout and all uploads were set to private for some stupid reason. Birch planks have several different CTM rules applied to them, adding the random variance might be taxing. I'll consider it though. And yeah, I might need a screen to know exactly what you're looking for in regards to the second part of your request.
There aren't many more animations in this version than there were in the last version. As I stated before this pack's resources are actually more optimized than they were pre-1.5. The problem is with Mojang and how they're handling CTM. There have been many posts with multiple solutions to try to remedy the situation. I'd suggest reading them.
Er... That sounds like something is out of whack with your computer or installation. A texture pack shouldn't be in any way able to affect sounds Well unless you're like extremely low on memory, but then you'd sooner run into white textures than sound loss. So yeah, I'm guessing you've got the wrong thread, sorry.
It shouldn't have anything to do with MCPatcher.
MCPatcher only alters things related to graphical rendering.
How would you propose I fix this? I can't think of any change I could make to textures that'd correct this. And given that the block you're using isn't obtainable legitimately, I'm not sure it's really something that needs to be fixed by anyone.
Follow the installation instructions including the cleaning part since it sounds like your installation is borked. When running MCPatcher, disable Better Skies, since it sounds like you don't have enough memory to run them. If you then have performance issues, see the first issue in the FAQ or read the last couple pages of this thread--there's been a ton of suggestions for how to resolve performance issues.
Also, everyone, seriously, disable advanced GL. Even if it doesn't make the game playable for you, I've noticed drastic improvements to even previously playable FPS with it switched off. It can't hurt to try all of the posted suggestions on the last couple pages of this thread either as well as the performance guide on the first post of the FAQ. Reading is good.
0
I already said I'm not going to be including alts with the main pack from now on. Alts will be provided as a separate download available in the future. Dunno why anyone would think they'd need to redownload the same crappy old font file over and over every time the pack updates. If you downloaded it at least once, you should already have the file. Even if you don't, it's not as if I've taken down the link to the old pack.
0
I have smooth lighting set to minimum without any real discernible difference from maximum
I also have a mere 512mb of RAM allocated to Java heap size and direct memory through MCPatcher.
The only optional feature I had disabled as of this test was Better Skies.