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
The original design intent behind the separate palette for the swamp overlay was that we didn't want to remove Mojang's swamp overlay for those who had developed their pack around it. If they had the swampgrass and swampfoliage palettes in their pack, it'd then be overridden. At this point I almost think it'd make more sense to just add a flag to color.properties that disables the hardcoded overlay there and allows you to use the main palettes normally for every biome. The only reason I don't think we should completely remove the hard-coded overlays at default is because some people may still wish to switch to the vanilla textures while patched for some maps.
1
Yes, it will use hard-coded blending as Mojang's currently does. Also this feature for tweaking the blend radius already exists as an end-user-adjustable setting in MCPatcher. (See the Blend radius option on the Options tab of any version of MCPatcher that supports CustomColors.) And see here for more discussion on the proposal.
0
Hence the reason for this thread and my statement about providing a template for the new format. The snow level varies based on a combination of 'relative height' (again for lack of a better term) and the biome's temperature. On that template I'll mark the levels of snowcover. It's not like this new palette will be changing Mojang's coding for this, it just changes how the 'line ranges' (See khanador's post.) are read from the resource file. If Mojang's amplified worlds do not break their palette color levels for snowfall, then neither will this new palette. All it does is take those 'line ranges' on their current palette and does the following:
- Orients them vertically for easier for easier gradient assignments
- Increases the range of colors that are blended over a larger range
- Separates and organizes every single biome into its own individual column to allow finer control of variety.
- Maintains a small filecount and filesize while still maintaining compatibility with the custom palettes of CustomColors.
Your issue of concern should not be affected in any way by the new palette format. It's just a different and more intuitive way of doing the same thing Mojang's already does.That's actually almost spot on to the calculations I made for the template I was planning. I've unfortunately had very little time to actually assemble any graphics lately due to my computer being somewhat broken, and the fact that I'm busy with renovations on my house to sell it, and preparations for a large move across the country. I'm glad someone beat me to posting some detailed info on that whole 'line range' thing they've got going on.
He's not suggesting making one big png which covers all biomes--I am. He's suggesting combining just Mojang's grass and foliage palettes into one file, but separating the biomes into 61 different files. And that is not viable because it doesn't account for MCPatcher's CustomColors palettes (which is what this new system will be implemented through). Even if it did combine all those, you still have 61 new palettes, plus 61 more for each and every custom palette created by the texture pack author. Given that the number of biomes is greater than the number of palettes in the average texture pack, it makes more sense to combine the biomes into single files instead of the other way around to reduce clutter.
Time is not a factor of biome palettes and probably shouldn't be for the sake of simplicity. This new palette idea's goal is just to allow finer control of existing features, not create new ones. Besides the sky color changing feature based on time would be more complicated to implement than you think given how sunrise and sunset are coded. HOWEVER, altitude will be able to be affected by custom sky color. Meaning you could have a mushroom biome sky that changes colors as you jump or climb or descend hills--or more practically, haze in forests that only kicks in at forest-level relative altitudes.
0
The file structure is already cluttered enough as it is with all the format revisions made by Mojang. The KISS principal must be pretty strictly adhered to when designing new features.
0
That's not really the best of both worlds, as it's lacking the huge key bonus of this new system. As it is, certain biomes share the same coordinates or clamped coordinates and cannot be currently split, and Mojang's concept of biome color schemes don't necessarily translate well to actual temperature/humidity graphs. For instance we could not have a custom Nether biome and a desert biome next to each other with drastically different appearances (remember, this will also affect custom colors skies/fog). The new palette format allows you to edit every single biome in the game, not just the coordinates several biomes happened to be grouped to. This greatly increases the amount of variety by a factor larger than 4x that could not be obtained with a temperature/humidity graph of any kind using Mojang's current values.
To my knowledge, biome altitude is what Mojang is using to calculate this. They just apply a noise filter calculated by the worldgen's seed so the snowfall layer on their altitude scale doesn't always land at the same block height--this prevents having "bowl cut" snow caps. Essentially it is a combination of biome altitude data with block height that determines snowfall and we'll likely just be using their system for this. 'Relative height' is just the term I'm using for the Y since it's what it'll most generally correspond to. If this works as expected, you should have no problem having dead grass under all naturally-occuring snowfall everywhere in the game.
4
-The new format should use the same 256x256 png file format with a customizable exception to vertical height.
-The X row of pixels should be for biome ID values (See here.)
-The Y column of pixels should be for relative height. (hence customizable pixel Y resolution.)
-The new palettes should be compatible replacements for both official Mojang biome palettes (grasscolor, foliagecolor) and custom MCPatcher-only palettes both created by texture pack artists and things like the sky biome coloring component of Custom Colors.
This is just in the experimental stage and may be scheduled for test implementation once the main, existing features of MCPatcher are once again fully operational. Note that all of this information is subject to change and realize that I'm posting this mainly for educational and feedback purposes.
This system is a bit more complex than Mojang's on paper, but allows for much finer control of every single aspect of biome-based block coloring and will logically make more sense on the artist's end to set up than on Mojang's current format. Basically all of the work will go into choosing your color gradients for each biome without having to worry about merging the height value all to a single point.
4
I mentioned this briefly on my texture pack's thread but I should probably mention it here. I've come up with a design for a new, efficient and highly customizable biome palette which I've proposed to Kahr for implementation into MCPatcher. This will be a custom format for MCPatcher which will override Mojang's method, but allow you to still use both methods safely in your pack. If all goes well, I'll be posting an updated template for Mojang's version along with the MCPatcher specific version. As a head's up to anyone interested in the mechanics of it, what I proposed works as such:
-The new format should use the same 256x256 png file format with a customizable exception to vertical height.
-The X row of pixels should be for biome ID values (See here.)
-The Y column of pixels should be for relative height. (hence customizable pixel Y resolution.)
-The new palettes should be compatible with both official Mojang biome palettes (grasscolor, foliagecolor) and custom MCPatcher-only palettes both created by texture pack artists and things like the sky biome coloring component of Custom Colors.
This is just in the experimental stage and may be scheduled for test implementation once the main, existing features of MCPatcher are once again fully operational. Note that all of this information is subject to change and realize that I'm posting this mainly for educational and feedback purposes.
This system is a bit more complex than Mojang's on paper, but allows for much finer control of every single aspect of biome-based block coloring and will logically make more sense on the artist's end to set up than on Mojang's current format. Basically all of the work will go into choosing your color gradients for each biome without having to worry about merging the height value all to a single point.
2
Though really my life would be a hell of a lot easier if everyone just bugged Mojang to do something similar to what they did for grass-free dirt and add a number to the metadata for naturally-spawned hardened clay and sandstone (as opposed to collected and player-placed hardened clay and sandstone). That way we could have naturally occurring versions of those blocks (Through CTM or otherwise) that don't mess up the design of these blocks when used as building materials. Even Mojang would benefit from this aesthetically with the default textures. I mean no one really thinks that their naturally-occurring sandstone looks natural and blends in well with sand, do they?
Anyway I apologize for the lack of presence on here lately. I've been way too busy with renovations to sell my house and packing preparation for a big move. So if you don't see me on much, it's probably because I'm really busy or just too drained from all the work I'm doing here.
5
If you're referring to the LBPhotorealism texture pack, I can confirm that it is using my mobs--not the other way around. Just look on their thread and you should see my name credited for the work they're using of mine. I've given permission to well over 500 people to use my work in their texture packs, and many more rip it off without permission. If my stuff looks familiar, now you know why. It has nothing to do with this work being copied from anything in any way. This right here is the original source of the 4 years worth of work that you see everywhere.
0
As far as parallax occlusion maps go, if you're still content with using my outdated shader maps, the 'bump' maps as you call them are actually two maps in one file: The RGB channel is for normal maps, and the alpha channel is for height maps--the latter of which should be perfectly usable data for parallax occlusion mapping. I have no idea what formatting the shader mod you're using requires, but the old GLSL shader mod allowed for displacement mapping to be read directly from the height maps in that combined file. If your mod requires individual height data files (which is horribly inefficient, by the way! :P) You can simply extract the alpha channel (Google it for whatever image editor you use) from my 'bump' map file and save it as a grayscale image of whatever naming scheme they use for height map data for displacement mapping which should be fully compatible with parallax occlusion (which is typically handled dynamically, shader-side).
In the texture pack navigate to assets\minecraft\mcpatcher\ctm\
In there, the files for the nether brick tops are '100.png' through '104.png.'
If you only want the top to use one texture, you can edit block112.properties in notepad and set the 'tiles=' value to whichever number file you want. IE:
will make sure that only 100.png is used.
0
What makes you think I have a copy of every single vers......Uh, that's pretty vague. What version of alpha do you pl......Okay, wait, stop! There never was a Misa100 to begin with. The texture pack was initially posted as "Misas_4x-res_Realistic.rar" and it underwent several name format changes until finally settling on the "MisaXXX.zip" In texture pack version 1.8.0. And if you'd played on my pack back when it first came out, you'd know it was originally called Misa's High Resolution Texture Overhaul. Anyway, all that aside, it'd be kinda pointless for me to keep up many older versions as texture packs for the most part have been additive in their updates.
The only times older versions needed to be retained was when there were major formatting changes to the way texture packs worked and when some blocks were replaced with others. The former I've catered to because they're the most relevant. It's common for people to still play versions of the game that are just slightly out of date. Given that Mojang has changed the overarching format of texture packs twice, you'll find two old versions of my pack on my main thread. The older versions didn't need this as much because the majority of changes to the game didn't require a new version of the texture pack.
The only instance I can think of where backwards compatibility was lost is when the the chests changed from blocks to models. And that was a very slow and gradual change for texture packs. All we had to do was add chest model art, and the terrain.png file could still have the old chest textures. Though much later on down the road, those textures on terrain.png got replaced with new textures. And by that point, no one really noticed because the game had updated so much since that even people on older versions weren't still running those ancient versions. Then cue the MCPatcher features I added...
Many of my old textures are no longer representative of the current look of my pack without things like CTM support. And being the perfectionist I am, if I were to post legacy versions of the pack, I'd feel they'd need to make use of these features to be worth the effort of posting. But even then I don't have much to gain from this... Alternatively I could just post every single other version as-is, but that'd also be a lot of time and effort that could be better spent on things that actually matter to the majority of my users. If these older versions become more popular and there is an actual demand for me to post legacy support, I'll consider it. But I need a few things from you. Namely confirmed lists of key versions of the game where backwards compatibility on texture packs was broken. Without this, I've no idea of where to even begin.
I'm not sure how you're seeing lightsabers... Both have pretty distinct shapes and colors. Design-wise the iron sword is based on realistic longsword designs while the diamond is more fantasy-themed and has two separate blades. Material-wise iron stuff is grey and less shiny, while the diamond stuff is more blue/teal and sparkles. If both look white to you, it sounds like your monitor's brightness/gamma may be too high. If this is not the case though and you feel you're seeing weapons that look too similar, please post a screenshot--it's technically possible that you've run into a bug of some sort.
As far as a post on how to make resource packs goes, there should already be quite a few of those out there. I imagine a quick google search will help you find some. As it is, there's so many components to making a texture pack that I wouldn't even know where to begin. Couple this with the fact that I have practically no free time with this move, and you'll see it's pretty impossible for me to write such a thing.
I can however provide detailed advice on specific things if you have questions that relate to a very specific aspect of texture design. I've also already made one post on texture design explaining how biome coloring works which can be found here: http://www.minecraftforum.net/topic/870780-
...Who shot who in the what now?
I'm not really sure how you want me to assist you. Could you please be more specific on what you want from me? This is a high resolution pack, not everyone will be able to run it on every single computer out there--that's just a fact. As with most modding communities, you shouldn't see them as a standard, required feature of a game so much as an optional PC gaming enthusiast's feature. If you don't have a machine that can run stuff not originally intended for the game, it's probably best to avoid mods in general--and that includes texture packs. The best I can do is point you to the first issue on my FAQ which has a performance improvement guide. Short of that, your questions regarding performance issues are best aimed at Mojang or Kahr.
I don't get it... What am I supposed to be looking at here exactly? I just see a dark, blurry image of my logo without any context.
What do you mean by brighter--lighter or more saturated? And are you referring to the ore or the block? As it is, my Lapis Lazuli is colored to be realistic to the actual real-life stone. I don't have too much wiggle room before I start straying out of realism and into the realm of fantasy materials. Real lapis lazuli is a deep, dusky indigo color. And if you compare my lapis lazuli texture to the default texture, it actually is lighter. Here are the average lightness and saturation values I obtained when I just now tested them:
██ Mine:
Saturation/Vibrancy: 100/255
██ Default:
Saturation/Vibrancy: 150/255
As you can see, my lapis is 20 points lighter and 50 points less saturated (which is common in realistic themes and consistent with the rest of my pack). As far as the Hue/Color goes, the average tone is identical. Was there any particular reason or in-game usage that sparked this desire for brighter lapis lazuli? Understanding your motivation for this suggestion may be helpful.
0
First off, not much has been happening that warranted my immediate response (apart from PM permission requests 'n' such which I still answer regularly.) Secondly there hasn't been much work done on Mojang's end of things for me to respond to with my work. But most importantly, the house I've been living in is currently up for sale and I haven't been able to get much work done as a result of showings and packing.
I could be moving out from anywhere between a month and sometime before the end of the year--it all depends on how long it takes someone to buy the house. It's also likely I'll be moving somewhere far out of state which will likely be a time-consuming process, and there's no way to estimate how long I'll be without computer/internet. I'll have a better idea once the house sells and I know exactly where I'll be moving. Most likely it'll be somewhere in the Southeast as it's much cheaper to live there. As a dry mountain/desert sort of person, I'm not all that enthusiastic about that choice for that and a few other more personal reasons.
I'd also like to take the opportunity again to thank those who have supported me by donating or clicking my ad links. At this point nearly all of the money has gone into fixing up the house to sell so I didn't end up with nothing and on the streets. Your support has basically saved me from homelessness and is greatly appreciated. This should ensure my ability to continue to update the texture pack in the future (Barring some unavoidable delays around the big move).
I was going to do a response post, but skimming over the last two pages, there isn't too much to respond to that I haven't responded to already. Also the normal post traffic seems to have died down since Mojang's updates seem to have slowed to a halt for awhile and most of the troubleshooting issues have been sorted out. If I missed something though or you have any questions or suggestions that you absolutely want me to respond to, please post them again. If there's enough things posted in the next couple days, I'll respond. However, after that I will be out of town until the 19th or so and will then try to get in a response before going back to work on everything required for the move.
0
You might wish to follow the installation instructions... I see on that video that your client hasn't been patched at all--more than half of my texture pack's features are actually missing. In this pack the text should never look like low resolution pixels, the tops and bottom of logs should have high resolution textures (jungle trees should have dynamic support for wider trunks), water should not be grey, the majority of ground textures shouldn't tile repeatedly, there should be HUNDREDS of different looking mobs, and the list goes on and on and on. Sufficed to say this pack should not be played without the client being patched by MCPatcher or you're missing out on what it's actually supposed to look like.
Er... Even after I added full CTM support to birch planks? After CTM support was added they're one of the most dynamic and versatile planks of the four. You are patching with CTM enabled, yeah? If you have, they should look like this:
Despite all the different textures and patterns, this was made
As far as the GUI's go this pack aims for relative closeness to vanilla. The pack is designed to be accessible to people who are familiar with the vanilla style of textures and want something a bit more realistic and versatile--it also allows people with this pack to play on servers with people using vanilla textures without too much variance in how things look. I know a lot of other packs like to theme their GUI's to look like different things, but to me it it just looks kinda sloppy to have a mishmash of different styles for the GUI. My GUI designs are minimalistc to cut down on visual clutter and are intended to be more clean, consistent and similar to the simple grey vanilla designs.
0
Armor's a whole 'nother beast. It's comprised of separate item icons and 2-4 player overlay skins. I'll be lucky if I can pull off something half-decent with the enchantment effects for them let alone worrying about degradation for them at the moment. Just thinking about getting even one of those systems working the way I'd like makes my brain hurt. So yeah, for now just tools and weapons get degradation based on the type of tool and material they're made of. (IE: shovels get dirty, swords get bloody etc.; and gold gets bent, wood splinters, etc.)
All you need to do is send me a PM asking for permission for my record-keeping purposes. Reason it needs to be a PM is so I'm able to easily reference everyone I've given permission to. Should a post containing some of my work get flagged and a moderator comes knocking to see if the post that was flagged has permission to do what they're doing, I need to be able to run a search on my PM's to see if they do or don't.
As a tip, for citations you need to typically provide a link to the source of the citation. A link to the wiki would not count for this purpose. You have to trace the links down to their direct source for the citation to have any independent verifiability.
That said, even if what Jeb said were true that doesn't change the fact that this mob is only attainable through third party tools. And while Jeb allegedly said that it would not be implemented in vanilla Survival mode, that does not preclude the possibility of the inclusion of the ability to obtain the mob or a way to spawn the mob in Creative mode or via slash commands. I simply do not have time to waste on complicated things (that'd require hours of work) that most people will not be able to make any use of and will likely allow to slip completely into obscurity over time (Giants anyone?).
This would be indicative of CTM not being installed (possibly MCPatcher) If you have patched the latest version of the game with the latest version of MCPatcher, please ensure that on the launcher you edit your profile and select the 1.6.2-mcpatcher version of the game.
When I checked up on this the first time, I looked at my working folder which does in fact have animation files for gold tools. However upon further inspection of the live zip file of the pack they seem to be missing. They'll be added in on the next update.
2
Mojang's developed a terribly unprofessional habit of sneaking in ninja updates to alleged "pre-releases" without any mention of these changes on their officially-posted changelogs. For 1.6 they separated pumpkin and melon stems at the last minute and most texture pack artists that released their pack on the same day as 1.6 were unaware of this change until after the fact. They also did this with log tops and packs that didn't have unique log tops to begin with through CTM were kinda screwed over--fortunately mine already did, so only the wood breaking particles are bugged in my pack. So yeah, the texture for the melon stem is missing and will have to be added by a later update to the pack. An easy fix for this though is just to go into the textures folder in the pack find the pumpkin stem art file, copy/duplicate it and change pumpkin to melon. For more detailed instructions, check the post made by Pellamisue.
CTM and Custom Colors--both of which are essentially required for the proper installation of the pack. Playing without them is essentially playing with a broken pack...
Not sure what this has to do with anything related to Minecraft or my Texture pack. Cube World isn't even remotely similar to Minecraft. It's just some low-content generic MMO third person hack and slash thing that has a voxel art style (Which Minecraft doesn't have). Though if you want to think they're copying Minecraft, you should probably realize that Minecraft is basically a copy of Infiniminer combined with Dwarf Fortress. Don't even get me started about it copying Diablo and WoW.. Diablo is a generic amalgam of a ton of PC and pen and paper RPG's that have long since pre-dated it in a simple point and click-style of gameplay, and WoW is basically a terribly watered-down copy of all the MMORPG's (Many of which were vastly superior) that pre-dated it. Pretty much all the games you're claiming it ripped off things from are unoriginal games that have ripped off many more things from other, more original titles... And again what does any of this have to do with my texture pack?
Could've sworn I've answered this at least two times on this thread already, and more times elsewhere. Please use the search feature for a detailed explanation of the situation and my plans for it.
The short answer is:
Mojang hasn't provided proper sound replacement support.
It was my favorite as well when I was working on it.
I mostly just use Jasc Paintshop Pro 9, and occasionally good old MSPaint from Windows 98 (mainly for pixel mask patterns).
I don't deny this is a bug, but it's not one that should be reported to me as there's nothing I can really do about it. I noticed this problem occurring on vanilla Minecraft in the early snapshots, so unless it's been fixed, it's something that needs to be reported to Mojang. If it has been fixed on Mojang's end then it's a bug that needs to be reported to the MCPatcher thread. But yeah, I'm pretty sure this is just a general game bug that neither myself or Kahr have any control over.
Apart from the things already suggested and the things listed on the first issue of my FAQ, I can't think of any other ways to improve this. Mojang changed some things about how textures are read/rendered and I did notice more and more client/server desynchronization since 1.6 at the expense of more consistent framerate. The hiccups you're experiencing I'm guessing are related to the latter and the increased memory usage required for high resolution textures. I hate to keep saying "Mojang's fault," but it really probably is... Of couse none of this would likely be an issue if we still had a single-player mode that didn't have server-client setup.
...And y'know, the added benefit that entities like boats and minecarts would move a hell of a lot more smoothly and realistically than they currently do. Or arrows that don't move to snap to an invisible grid once they've hit their mark. I swear, the atrocious multiplayer entity behavior is the main reason why I mostly played single-player for years. And then Mojang just had to be jerks and force the buggy multiplayer code onto single player too which basically ruined a massive chunk of the game for me. It annoys me that there isn't a huge outrage over this, because most of the people currently playing Minecraft are relatively new to the game or play mostly the buggy online version and have no idea how vastly superior the game physics were in single player a year ago (pre-1.3). But I guess I'm getting off-topic now.
And here I was thinking people would be asking about the zombie and skeleton horses first.
As I've stated repeatedly in the past, I prefer to not add support for unused content or things that are not legitimately obtainable in-game as things like this are often subject to future change/removal and can end up being a waste of time to support. (Anyone remember stuff like "Crying Obsidian?") You can rest assured though that if this stuff gets officially added to the game and is legitimately obtainable in survival or creative, it will be supported by the pack. Chainmail is a prime example of an unsupported texture that was later supported as soon chainmail became obtainable without requiring third party editors.
If you want me to texture this mob, bug Mojang to properly implement it into the game. Knowing how it's used and what its function is makes it a lot easier for me to even have an idea of how it should be textured. If I were to go in blind and provide a generic villager texture for this unsupported mob, just to have it later turn out that Mojang's decided to implement this art as a hunter or something, I'd then have to completely redesign the skin to reflect the new role and would've wasted a bunch of time and effort.
To save time and resources (and stick to the KISS principal) I'm pairing up comparable effects that differ among equipment types. So for example: Sharpness, Power, Protection, and Efficiency are all generalized object enhancements and thus have a generic 'shiny' animation. Another example would be to reuse the same fire effect for all things related to flame. As far as your suggestions go, many of these are already in my pack. Sharpness, power, and protection are the shiny effect, bane of arthropods has a squiggling 'mites' effect, and Knockback and punch already have a vibrating vortex effect. For silk touch I already thought of doing something similar to that suggestion. Armor of course is a whole 'nother ballgame, and some more thought will definitely be going into how I want to implement it.
Have you ensured in the Minecraft launcher that you have the mcpatcher version of the game selected in your profile?
Dunno if I'd use the word 'fan', but yeah, I enjoy the Zelda games fine enough--at least the ones I've played--Majora's Mask is my favorite, though Adventure of Link was pretty awesome too. Of course I also happen to not care much for Team Fortress 2, despite having TF2 cameos in my pack.
(Though it's usually more fun to be surprised by them.)
-Legend of Zelda (zombie, skeleton, and pigzombie, wither skeleton)
-Kid Icarus (skeleton)
-Doom (zombie)
-Duke Nukem (pigzombie)
-Half Life (zombie)
-Thief (skeleton) (My favorite game series of all time--though I think the reboot is probably going to suck...)
-Team Fortress 2 (skeleton, wither skeleton)
Golden tools are already animated, heh. Place one in an item frame and look at it more closely. It sparkles, just not as much as diamond for obvious reasons.
CTM for vines is on the to-do list, and for cacti, I'd need a good idea for how to do this properly. As it is, the top of my cactus tiles well with the sides, so I could only see myself adding something to the bottom if anything.
As far as the lava swimming screen effect goes, that's currently not possible as there is no full screen effect to edit in the vanilla game. They just turn up the fog and turn the screen red. And yeah, I can't change any of that with textures or properties files at the moment. Even if it were possible though, I probably wouldn't know what would be realistic other than pure black... Being submerged into molten rock would pretty much instantly blind you just before your face was melted.