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
0
1.There may be a brief purple transition from the sunset orange hues to the night time blue hues when around torches which give off a yellow-red range of light. This is not unnatural though. Most people just aren't used to seeing blue night skies in areas with no pollution. Many other games with a night sky that gives off blue light that have a day to night transition have a similar range of hues during the transition. If you're getting something that's strongly purple though for an extended period during sunset, please post a screenshot.
2. Fixed in the latest MCPatcher.
Also all permission requests need to be directed to PM for record-keeping purposes.
This appears to require two other mods to run. I'm not too keen on supporting mods that have dependencies on others. That doesn't mean I'll never support it. The idea of the mod I like (despite it being gameplay-changing). It might be best to resuggest it after the official Modding API goes live and all mods are using the new format that requires no dependencies on other mods.
You can pretty much blame Mojang for this one. My pack is in fact more optimized for size and resources than it's ever been. 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. The general performance drop is a known issue by Mojang and hopefully they'll be correcting it at some point. The only suggestions I can make right now would be to disable optional features like BetterSkies, and Custom compasses and clocks (Even though the custom clock is pretty mesmerising. :P). I'd also suggest ensuring that you've allocated some memory to Minecraft/java through MCPatcher or other means (Google is your friend.) I also noticed that setting smooth lighting to minimal helped on my end. If none of that helps, run through the entire list on the first issue of my FAQ, and then check out other posts here.
It sounds like the download of my pack you used was corrupted or something. Under no circumstances should you use the conversion tool on my latest pack as it's already converted. I'd suggest re-downloading the file (perhaps on link 3) Also be sure to grab the newer non-beta MCPatcher.
I'd actually planned to get some on Wednesday, but ended up having to update the pack instead. My time to work on the pack in general is pretty tight, which is why my screenshots are horribly outdated. That and I don't really have many good builds anymore to show off in the screens and I absolutely HATE those idiotic, bland texture display maps that just show every block arranged with no regard to context, or natural occurence... They're terrible for showing off the real amount of work that's gone into this pack. But I digress. I'll try to find some time to update my screenshots at some point, but I really can't make any promises on when.
See my response to Dataless_82 above for a more detailed explanation. Not all texture packs are created equally. Few make use of as many advanced features as mine always has, but I cannot be blamed for this performance drop. I did my damndest on my end to ensure this pack was less taxing than the old and Mojang still messed it up.
Added for next update.
1. I kinda thought it already was--guess I missed it. Added to the to-do list.
2.1 Already on the to-do list. Mobs take a lot of time.
2.2 I'm not familair with this game at all (I'm not sure if you even mentioned the name of it). Most of my video game cameo zombies are somewhat pop cultural in the gaming world (Doom, Zelda, Half-Life, Team Fortress 2, etc.). I try to avoid using obscure references unless I can fit it into the more generic-looking standard zombie roster of my pack.
3. I don't think this is even possible... The background on the GUI in-game is a black, transparent layer that cannot be edited or randomized, and the background on the menus is a small image that's tiled repeatedly and cannot be randomized.
4.Ghasts have been on the list for awhile, they're just obnoxious to design alts for around the current standard, blazes... I don't think so. They're an animated mob. Animations and mobs take up the most time possible. Doing animated randomobs is just entirely too much work for something you don't see often enough for it to matter. Besides I can't think of any good alts to make for blazes or magmacubes that wouldn't be so subtle as to not be worth it. As far as endermen go, I'm pretty sure I've stated in the past that they're a special case. If you're being slowly stalked by more than one enderman and they look the same, you really don't know for sure if it's one really clever one or more than one. By design, Endermen are best if they all look exactly the same. There are no individuals amongst the Endermen, they are one and all.
I'm pretty sure I've stated many times in the past why this is a bad idea and also impossible. This pack is already 256x256 and 512x512 in parts anyway--they're just spread out over multiple blocks as they should be.
This only seems to be an issue for some people and not others. My guess is the download got corrupted either on your end or on the filehost. I'd suggest trying one of the mirror links and redownloading the pack. I will be completely repacking the file on the next update to see if that fixes the problem for the few who have reported it.
wut.
I'm not sure how your response is a contradiction to my answer or what you're even trying to say.. Your own response contradicts itself, in one part you're saying "there (sic)is not natural quartz," and then in another you're mentioning quartz found in nature... I read this several times and still can't make any sense of it. I also don't recall in my last response saying anything about natural or unnatural quartz. All I said was that the quartz blocks have a pinkish hue to remain internally-consistent with their source material. I made Nether Quartz ore pinkish, therefore everything made with netherquartz is pink. What does this have to do with natural quartz colors? Netherquartz isn't even a real thing. It's a fantasy material with magical properties it could be purple with glowing green spots and still fit a realistic look. Again though, this has nothing to do with my previous response. I was only mentioning that internal consistency is important and that blocks crafted from baser resources need to reflect the look of said resources.
As far as the other stuff goes, again, stop speculating. Try it and see for yourself before commenting on how bad or scary something is by description alone.
See my other responses on the subject in this post.
I hate to break it to you, but in the eyes of Minecraft, your laptop is crap. Most specifically this part here:
i7 2.3 GHz
Minecraft unfortunately has no multi-core optimization of any kind. As I mentioned in a previous response thread, Minecraft only cares about the processing power for a single core of your multi-core processor. So you could have like 8 cores and if the individual core speed is less than a single core machine's core speed, the single core machine will be superior. And it's not as though it's impossible--Optifine has clearly demonstrated otherwise. Mojang is really just kinda incompetent (in more ways than one). Read my first response to performance issues on this post for ideas on how to hopefully alleviate the situation. I'd also suggest trying out saotomato's response. Other than that we can only hope Mojang will eventually fix the problem they caused.
0
Technically a single-core CPU with 3.8GHz will run the game faster than a 3.6GHz eight-core processor. Minecraft has no multi-core optimization.
I wouldn't not call it objectively better so much as different and maybe better from some design points. The design decision as a response to the issue of limited space makes sense, but the execution of the design is a bit more flawed than the old system--namely with how the restitching is handled. Until the rewrite of the render engine I pretty much am forced to withold any major judgments on whether or not the new system is truly an improvement over the old.
From a more personal standpoint, the new format is a bit more annoying to work with. I'm sorta wondering how difficult it'll be to spot new art files by glancing through jars as was done for previous updates. If they batch optimize their new graphical resources, modification dates will be removed and spotting new files will be more difficult. I already have a method for how to get around this, but it's a bit more obnoxious than it would've otherwise been on the old system. I do like how I was able to categorize my new CTM file structure though. I probably have Kahr to thank more for that than Mojang though.
Sometimes it helps to wait until something is out and you've tried it out first.
Not too much of a point to do this as you (or anyone) can easily do this for yourself with no graphics editing experience whatsoever. Simply open the texture pack and delete the files you don't want. This should be even easier than before with the new file format for textures and items.
I'm pretty sure I've posted the realism reasoning of behind the design of the lava texture before. Check the search feature. The only changes I've considered making to liquids would be to make them use the repeating CTM feature, though this has a lot of design drawbacks that require a good bit of planning. Their designs will likely have to be remade from scratch if I do end up doing this. And yes, you just change the file in the font folder. Note that any default.properties files are just as important as default.png. Also my old font will no longer be included in the new releases. More on that later.
Links. They need to be posted.
I'll add "CTM variance for logs" to the to-do list.
Pretty much...
Search feature--I've addressed this very issue already. A redesign is on the to-do list, though I will not be specifically adopting Mojang's artistic approach as it is pretty unrealistic. I did in this version at least change the color of the two slightly as a placeholder to differentiate them as they grow. That may have been one of the things I forgot to put on the changelog
Now for a general announcement:
Some of you may have noticed that I did not include alternates in this new version. Don't worry! I haven't forgotten about them. I just will no longer be including them in the main pack. I plan to make an alternates pack which can be updated independently from the main pack. This will save on filespace of the main pack and be less confusing to work with. Also if I come up with a bunch of new alternates, I don't have to update the pack to share them--that also works the other way around. Hopefully you'll agree that it's a much more practical way of handling things.
0
The texture pack's been updated 'n' such. Be sure to read the announcements before installing or you may run into problems.
0
MCPatcher's currently not officiallly updated yet, so yeah you'll likely have to use one of the beta versions to get it to even work.
0
This could negatively affect some builds and might be unrealistic in general. Grassy areas with an overhang shouldn't have snowfall on them. I played online with a friend who had just started Minecraft for good while whose first world was largely an ice desert. Not being able to grow grass indoors/underground or use wild grass to have an untouched field of grass on the surface would've made the place pretty depressing to spend as much time much time in as I did.
-I have been thinking about a CTM large texture animation for portals at some point in the future. Making some variety between the Nether and Overworld side of the portal may be interesting, but also may be pretty taxing on resources if both effects are combined. I'd have to think about it some more.
-The problem with adding snow to blocks is outlined in the response above. They may look good outside, but indoors or underground they make no sense.
-I wouldn't replace random textures for the sprite-like foliage blocks, and biomes currently have a lot of foliage diversity among them at default. I'd need some really good specific ideas for this.
-I do like the idea of a different kind of sand for beaches. I can't imagine the transition ruining many builds either, given the fact that it's nearly impossible to build stuff with sand. I probably wouldn't change the texture too much from the current though--maybe just add things like seashells and the like. My only concern would be tiling. I can't really do random texture assignment with sand as I do for grass as I'm already using a large texture for it.
-Dirt's another fairly safe block to mess with. I'll mess around with it and see if I can come up with anything worth using.
Yeah.. Bug fixes that make the game pointlessly render multiple copies of textures and change the class files that MCPatcher uses. This whole development cycle has really been pretty hellish behind the scenes. I just haven't been bitching publicly much about it lately because I've tried to stick more to the "If you can't say something nice..." mantra to avoid having to explain details of my gripes over and over to newcomers who aren't privy to the situation.
This would get very confusing for people looking to mine stone. Also exposed rock at the top of a mountain doesn't have a solid cutoff height in reality. And then there's the issue with creative builds that may use grass and dirt...
The response by Kexikus is correct. I'd however like to add that the resolution of a texture pack has absolutely no relation to your operating system's instruction set ('bits' for lack of a better term). 64x64 texture packs are not made for 64-bit operating systems, nor are 32x32 texture packs made for 32-bit operating systems. The 64x64 simply means that there are 64x64 (4096) pixels per texture per block. The number of bits associated with your OS deals more with what hardware your computer can make use of. This has little to no bearing on what texture packs you can run as opposed to your actual hardware setup.
That warning message on Minecraft about how 64-bit java is recommended for 'Far' render distance on 32 bit systems is a bit misleading and I'm sure probably contributes to some of the confusion.
As soon as I can figure out how to either clone myself or hack the space-time continuum to merge the work I've created in alternate universes to this one.
Mission accomplished.
How come you're posting here about bump mapping issues with SEUS in this thread when my texture pack hasn't had normal, height, or specular maps in since before SEUS even existed?
While I agree with the content and sentiment of the explanation part of the post, it seems a bit excessive to blatantly ask them if they're "that stupid." Being unaware of the work that goes into something like a texture pack doesn't make someone stupid. I don't want to breed an environment here where new users who comes to this thread feel like they're going to get attacked just for posting.
0
Not sure if you were referring to a rendering issue or a stray pixel. I have no stray pixels on the current development version of the pack. And there was a rendering issue with the edges of certain transparent blocks that was fixed not too long ago by MCPatcher.
You'd need to send me your files for me to have any idea what's wrong with your Better Glass. There's different rendering modes and I'm not sure which one you're using, and it also sounds like your CTM texture-replace assignment is a bit wonky if it's affecting other things. My best advice short of this would be to of course read the MCPatcher documentation on Better Glass.
Mission Accomplished.
Next time you might want to provide some explanation with links to source material for such claims. I spent hours trying to figure out what this post even meant by scouring twitter for posts from the devs that could be related and checking out the wiki for planned blocks to find absolutely nothing. Only to later did I find some tiny little obscure reference to hay block textures posted by some user on Reddit who found them in a .jar from another game entirely... So yeah, hours of racking my brain and stressing out over something I thought I completely missed on and needed to update for just to find something that's not even confirmed and could just be a red herring. :/
My current night sky from BetterSkies already has nebulae, the milky way, and different colors of stars as would be visible to the naked eye under our atmosphere in good lighting conditions. The last part of that is key. I own several high powered telescopes and have gone to high-altitude areas out here with practically no light pollution, and the stars still appear white to the human eye. In my pack's case, the stars are sort of a mix of false-color star imagery and what you'd see in reality with your eyes. So the fact is, my night sky is actually more colorful than the real thing. It's as much of a stretch as I'm willing to make for the sake of beauty while maintaining a semblance of realism. As a huge astronomy buff, many hours went into the thought and design behind my sky.
Here's an example of a magnified section of my skybox with the contrast and saturation increased to show that there is in fact color in the stars behind a blue tint from the atmosphere.
As far as comets 'n' such go, animations are currently possible, but also kinda difficult to optimize to still run on most machines that can handle BetterSkies (Many machines cannot--which is why it's an optional feature to begin with.). The skybox texture for the nighttime starscape is currently the largest file in my entire texture pack (3072x2048--you couldn't even fully display it on an HDTV without shrinking it), to animate it completely, I'd have to duplicate it as multiple frames in a single image. A simple 3-frame animation would be 3072x6144 This would pretty much overload the memory on many people's computers. So in order to have things like comets and other various satellites, I need a more simplistic, and optimized way to accomplish this with much smaller filesizes. Right now 1.5 compatibility is top priority for Kahr, so it may be awhile before such features are added.
fire bad
Technically that's an acronym and a word. Might wanna remove the space next time.
Man.. I just recently did a whole stupid skit in response to this too. I thought that'd be enough to address this for a good while--guess not. :/
All permission requests need to be directed to PM for record-keeping purposes.
<---Not a brony or pegasis or whatever they're called. I wouldn't even know where to begin with providing texture support for this. I imagine the dark, gritty, medieval look of my pack would probably clash too much with technicolor equines anyway for me to do such mod support any justice. You'd probably be happier with a texture pack specifically designed for that setting.
Because you know how often those are seen in the game. Also, how else do you expect to fit a ghast in there?
Many of the new blocks are already in the pack as previously stated. Here's a repost of some old screenshots of the quartz blocks I posted here awhile back:
Comparison of the vanilla and Misa version of the quartz blocks
A display of building blocks close to being white to show their differences.
Not yet. Hard to come up with new ideas with all the other work being done on the pack. I'm open to some good suggestions for how to make use of this feature.
I don't hate distribution of my textures--redistribution on the other hand has some rules, but I'm still not against that so long as rules are followed. Of course he was advertising my pack not distributing it, and I've no problem with that. Most of my popularity is through player advertising. I just don't run any official propaganda or ad campaigns myself. Considering I may be homeless around summer, it'd be stupid of me to turn down any support that could potentially be providing me my next meals.
I don't have much to say for general announcements on the pack's development. I just wish Mojang would hurry the hell up and release 1.5 already so I can get out a proper update and move on from this development purgatory that's lasted nearly two months. I'm still not sure we're even out of the woods yet. The last few bug fix patches have caused all sorts of other problems that Kahr and texture pack artists have had to work around. Apart from those hurdles, there's also been a lot of really, really stupid design decisions made on Mojang's part recently. I really wish Mojang had designers with actual design experience working there rather than just a bunch of programmers multi-functioning as developers, content designers, artists, etc.
0
As nice as it'd be to see MCPatcher's features properly incorporated into Minecraft vanilla, running MCPatcher isn't really all that much of a hassle as it is. It's a client mod which doesn't affect online play with people who don't have it installed and it's a small download which you only have to run once on major updates. Downloading and patching even on a slow connection takes maybe a minute tops.
I have no idea what new CTM better grass function you're referring to. Can you please post a link to or quote of the documentation for this feature? The screenshot you posted to later just looked like ordered CTM, and it looked like a poor implementation of it as ordered CTM makes no use of conditional dynamics the way better grass does.
It's the horizontal and vertical pixel count on the basic textures. In my pack it means that each block will have a pixel resolution of 64x64. However this does not mean that all of my textures are 64x64. In fact many of my textures are actually 256x256 and the ice texture is 512x512--they're just spread out over the blocks in a way that each still has 64x64 pixels. Texture resolution doesn't always mean everything though. The design is the most important aspect of a texture pack and depending on the style, certain resolutions will be meaningless beyond a certain point. So if you use it as a number to pick out packs, you should probably only use it as a gauge for what your hardware can handle and not how good or bad a pack is.
From personal experience, I've seen a lot of really great 16x and 32x packs designed by artists who have mastered pixel work, and a lot of really terrible 128x and 256x packs of hacks who just take stock photos and paste them into the texture pack format (I've even seen some with watermarked images!). That's not to say all low resolution packs are good and all high resolution packs are bad. Just always keep in mind that resolution is nowhere near as important as the design of the pack. I went with 64x because to me it's a high resolution pack that most people can run without too many performance issues, and it's a resolution that works well given the blocky nature of the models in this game without looking too pixelated or too much like photographs pasted onto cubes.
0
0
8
This is sorta apples and oranges. He technically probably could include backwards compatibility with the old format, but at several costs. Things like performance could go down for the coding required to adapt the old method to the new form of stitching--which could potentially defeat the purpose of the render engine optimizations. You could also have a situation where packs have to be physically converted and backed up which could double the size of any texture pack. Considering that none of the new features will be present in pre-1.5 versions of Minecraft, it simply makes more practical sense for artists to just host a final pre-1.5 version alongside their post-1.5 version and for MCPatcher to do the same.
Again, the actual formatting of texture packs is not at all an issue here. It may be arguably a worse format to work with, but Kahr has already created a conversion tool which should at least make updating fairly painless for most artists. And given that Mojang will be working with the new format for any newly-added textures, the problem of sticking to things like terrain.png becomes pretty apparent. If Kahr did design the patcher to use the old format, where on terrain.png do the new blocks go? It's better to just stick with the new format as a uniform standard than have a messy Frankenstein pack that can work with all versions but is full of organizational inconsistencies. When it comes to pretty much any form of design, the KISS principle is always your friend.
Check my last few posts. The pack is already pretty much fully up to date for 1.5 on my end. I'm just working out some kinks and throwing in extra features between now and 1.5's official release.
Hello crafters. Look at your snapshot version--now back to my thread title's snapshot version--now back to your snapshot--now back to my pack's. Sadly, your snapshot version isn't my pack's. But if you stopped using the latest snapshots and switched to the version this pack is made for, your Minecraft could look like mine.
Look down--back up--where are you? You're on a thread with the pack you could be using on an older snapshot. What's in your download history?--back at my thread. I host it. It's a texture pack which improves the general appearance of Minecraft--look again. The texture pack is only supporting [1.4.7]+[13w01b] and earlier. Anything makes sense when you're reading the contents of a thread before downloading. I'm on a computer.
1
I'd still have to redo all my ores from scratch likely if I were to add any variety to them. And yeah, ores are never a high priority. They're something that you typically mine on sight and don't really use for builds or anything.
Watch the videos from Minecon for the Mod API panel. What they plan to do with the client is outlined there.
For the record, I am somewhat of a perfectionist. This is partly why I don't like to keep up old versions of the pack. Any changes to old textures were made because I wasn't happy with the look of old textures--and wouldn't be proud to have them being representative of my work.
Anyway as far as clocks go, they're done--thanks in large part to Kahr's magic. Let's just say my new clock looks pretty badass, uses 6 layers, makes use of superficial animation, is way more functional than before, and is less than a thousandth of the filesize that it looks like should be--again thanks to Kahr.
I guess one could kinda/sorta/maybe make the argument that it's easier to use if you're someone who lacks any experience with graphics editing (...and is likely too lazy to just PLAY with an image editor and look up things when they get stuck to figure it all out). Given that Mojang's Minecraft team currently has no dedicated graphic designer, it's probably not much of a surprise they'd make as many boneheaded moves in that department as they have. I recommended that they at the very least consult with people in the modding community who have been working with this kind of thing for years, but I guess that fell on deaf ears. The format change isn't so much what I worry about as much as their plans for the modding API and what it means for the client mods that have made texture packs what they are today.
Anyway, just thought I'd give a little update on my progress. The pack with all of its features is currently fully up to date with the latest snapshot. However I still need to do some annoying optimization crap for the minimal-feature functionality of the pack. Basically I can't completely rely on all the optional features of MCPatcher if not everyone can run them. Also I'll probably put off an actual update until 1.5 comes out just to be sure everything won't be ruined by another snapshot. This also gives me some time to work on some special features of my own.
0
Well if you mean like proper CTM for ores, you still do have a ton of work to worry about with seams when making large clusters of ores that connect properly to each other. Random textures would be more practical, but still annoying if I had to animate them all the same way--let alone mimic the original look of my ores. Many of these ores were designed three years ago before my technique for making textures was as refined as it is today.
Actually after Kahr changed how CTM was formatted and I completely redid ALL of my CTM from scratch (took about 7 hours of non-stop work), I managed to decrease the size of the pack from the currently live version. Of course I still haven't redone the clock yet.. I imagine that'll be over a few hundred frames of animation to make it look half-decent--thanks, Mojang. :/
Anyway, releasing multiple versions of a texture pack would just be a lot more work to maintain and update and would slow down my ability to keep the pack as up to date as I currently can. Also CTM and Custom Colors have become such an ingrained component of my pack that I couldn't simply remove them. I'd have to redesign the pack to work without them before I'd be satisfied enough with it to consider releasing it. And given how much both of those add, I don't think that'd be very easy to accomplish.
If this is all about just Optifine support, there's a bit of a bigger picture here to observe. Optifine currently isn't even working with the 1.5 snapshots. Even if they do update by then, it's MCPatcher that's already defined things like the new format for CTM in texture packs so they'd still have to play some catch-up to even be usable with advanced packs on the new format. Mojang also plans to release a new launcher and re-write the game's rendering engine which could completely render any of the major performance-boosting features of Optifine pointless if everything works as they intend it to. If I were going to design an alternate version of the pack it would have to be for unmodified vanilla. But I don't foresee myself and many of the advanced texture pack authors being eager to drop all of these extra features just to conform to Mojang's primitive idea of high resolution texture support.
At this point, there's just too many ways things can go, that planning around every single possibility would waste valuable time that could be spent on ensuring that texture packs that currently work can continue to work at the launch of 1.5. The current plan right now is to have the current pack version remain up and release the 1.5 version of the pack alongside it. The 1.4 pack will be retained and not updated for those who are playing the game with the old texture pack format. This pack will also include the alternates.png which I have omitted from the 1.5 version. As far as future alternates go, I'll deal with that as the new alternates are made.
I appreciate the kind words.
By the looks of things, even if I gave you permission to do so, it would still be disqualified by Jinx. The only way any work could be submitted with my texture pack in it would be if I were to submit it myself as I'm not a third party.
Few people realize just how many hours of work went into that sun and all of it's light components for better skies.
Permission requests need to be redirected to PM for record-keeping purposes. Should a thread be flagged for possible theft of my work, I need to be able to easily look up all the people who have my permission should I need to defend them from moderator removal.
If you really want to know, animation was new at the time and I was desperate to find things to animate and having made iron ore sparkle I did the iron blocks too for consistency (plus it inflated the amount of textures that I could claim were animated in my pack, hur hur).
When CTM was made more accessable, and I had the option to add it to iron blocks, it just made a lot more sense to me from a design standpoint to do so at the cost of the sparkling animation which didn't seem all that necessary. Ideally they shouldn't even sparkle at all, they should shine or be reflective. But yeah, advanced shaders would be required to pull off half of the stuff I'd like to do with my pack.
Congratulations, you're still getting very playable FPS on a high resolution texture pack and higher FPS than most players in general. If you still feel you're at some sort of disadvantage, read the first issue of the FAQ for ways to further improve performance.
Inadequate memory resources to load the textures for Better Skies. Disabling Better Skies will correct the issue and should improve performance as well.
1
You're still looking at 48 animation files for standard CTM, and 16-64 (my ice is 512x512) animation files for large tiled CTM. The biggest hurdle of course is the fact that they all have to seamlessly tile with each other while still being animated. In the case of large tiled CTM this isn't too bad as it involves making a really high resolution animation and cutting it all up into separate animation files. Using the standard CTM method though... holy flipping sugartit. There's a reason that apart from glass there's only 4 things in my pack that use standard CTM. The work involved with seamless tiling is a bitch. This is why it's largely done with textures that just have framing. The jungle log tops were probably the most painful texture I've ever done. I was just happy that jungle logs were the only ones that actually needed that treatment.
That was just the quartz in a preliminary test phase. It's since been altered quite a bit and Kahr found a way to fix the columns. As far as it working with endstone goes. I wouldn't imagine they play together too well, but considering endstone is supposed to be pretty alien in origin, it's sort of expected. It shouldn't be much of an issue though. There's a lot more variety of quartz textures to work with than there is on vanilla so you shouldn't need to combine it with too many other blocks to get a nice varied, but consistent look on your builds. Here's a comparison of the variety provided in vanilla versus my pack:
And here's a more blunt comparison of the variety of whitish blocks that can be worked with on the texture pack:
As you can see, endstone never really was all that white to begin with. It only really looks white when contrasted with obsidian in a checkerboard or something. Also in regards to the tops of chiseled quartz blocks, the pattern is not random. It repeats so that the pattern alternates orientation every other tile as seen in the screen.
4
Granted, this is a very special case as pillars can be placed in 3 different orientations, but logs had the same problem when you could place them at different angles too. There are some more general bugs that still need to be ironed out as well as can be seen with the last snapshot and beta MCPatcher on all three single chest types:
But yeah, it's probably safe to say that all of the special features from MCPatcher will be returning. It's just a hell of a lot more work on the new format. Features like CTM now use individual tiles in folder as well to work with the new system. As a result, texture pack file sizes will probably go up as certain textures that were recycled multiple times now have to be physically duplicated. On the plus side, animated CTM is now way easier to pull off.
0
I'm not sure exactly what you're referring to. Can you please provide a screenshot of what you're talking about? I don't know if what you're describing is a bug or a feature and a screenshot would probably help clear it up a bit.
It varies a lot, due to Minecraft's lack of optimization and a lot of compatability issues, but I'd say that as long as you have three gigs of RAM, a 2.2GHz dual core CPU, and a non-integrated video card, you'll -probably- be fine...Technically something even as good as a 2.2GHz octa-core CPU would be inferior to a single-core 3.6GHz CPU as far as Minecraft is concerned. There is no multi-core optimization in Minecraft. (This is one of the main methods by which Optifine improves performance.) Also despite being able to make full usage of GPU's, Minecraft does for some reason seem to respond very well to non-integrated video cards. As far as hardware goes, a proper video card and a good amount of RAM are what make all the difference in performance for a lot of players I've provided tech support to in the past.
All that said, it's kinda hard to give a definitive set of hardware specs for this pack. The best thing to do would be to just try it out, and see how well it works for you. If you are having performance issues, a good resource to check out would be the performance guide on my FAQ. In that I provide a bunch of ways in which you can improve the performance (without immediately needing to resort to hardware upgrades) of the pack using the standard installation.
This isn't really a thread for general support of mods. There is always an inherent risk with installing more than one mod that your game will cease to function. If you're just trying to get this pack working, clean your game installation completely and install the pack using the installation instructions provided. If you still have any problems before you start adding mods, then we can help you. Otherwise your problem is better handled on another thread that deals directly with the mod or a mod compatibility thread.
See the performance guide on my FAQ, and if nothing there helps, as previously suggested, disable Better Skies in MCPatcher. Better Skies is a completely optional component which has significant resource-usage (Mostly memory). I've been meaning to add a list of optional components to disable to that guide for awhile now, but just haven't gotten around to it yet.
If it's not legitimately obtainable in the vanilla form of the game, I don't do textures for it. I did the same with chainmail before creative mode was added to the survival version of the game. The only exception to this rule would be command blocks which are an essential component of adventure maps. And as Dinnerbone has mentioned, they are technically obtainable legitimately in-game with slash commands as sort of a test for the type of person who would actually be able to make use of them. (Though personally, I think they should be in the creative menu regardless. Even people who know how to use these don't always feel like memorizing/looking-up block ID's)
As a general announcement, I've run into a bit of a design hurdle as far as dispensers and droppers go. Both can be placed to aim vertically now and their designs are similar in general but slightly different in regards to the 'holes stuff comes out of'. My creeper face design for the dispenser hole is really hard to work around when it comes to designing the dropper, but also it's really hard to have applied to the tops and bottoms while still looking good. So I may have to completely redesign both to be a bit more uniform and in-line with vanilla. This would include the loss of the cool animation for the creeper face though. Would anyone miss it too much? Coming up with a new design for the dropper that has a similar, matching animation is sorta out of the question as the process used would be painful if not impossible to replicate in the exact same fashion as I did before.