Where my leaves used to be see-through, they're now a weird green colour. So everything looks bad :3. Thanks!
(Attachment shows).
This is how Minecraft handles Fast Graphics now. It takes the "Fancy" leaf texture and just drops the alpha channel (transparency).
An easy way to fix this is to take your old fancy leaves texture and put it on a lower layer than your fast leaves, but make it only 1% opaque. Minecraft will totally ignore a 1% transparent pixel (it's below it's transparency threshold) but it will become visible once transparency is disregarded altogether.
Kahr, I made an account just to give you some encouragement. I've been following this thread for quite some time, but never posting, since I started using MCPatcher. I want you to know that your work is very much appreciated and that MCPatcher makes Minecraft 1000x more interesting and fun to play. Keep up the good work, I'm sure you can get through Mojang's mess of code, and I thank you profusely for doing this for us for free. Take it easy and take plenty of time for yourself. [:
Your replies are much appreciated, and changing it to Fancy did indeed help. I'm sitting here with a custom collection of textures that I pull from different packs for personal use (well, and a girlfriends) and the .png files for leaves are all transparent. I'm a bit at a loss as to what you want me to do.
Should I add an additional layer with a complete overlay of a 1% opacity colored layer - and re-save it as .png to make it show on "Fast", or what were you trying to tell me?
Sorry if I'm a bit slow.
No worries, though this is pretty severely off-topic in this thread. I suggest making a topic in Resource Pack Help for it. You can also send me a private message if you like, which may actually be better since I may need to see your leaf files (which you can't post on the forum proper if you didn't make them) to better advise you.
The API's been "just over the next hill" for a long time now, and yeah, I'm pretty pessimistic on it actually seeing the light of day too. I think Mojang thinks they're working toward the API, but I'm afraid that (1) all these architectural changes are driving away their experienced modders, and (2) assuming Mojang finishes it at all, their API will be so over-engineered as to be unapproachable to newcomers.
It's been promised for so long that I think it's safe to say that Mojang's own definition of what it will be has changed. It's obviously not going to be Bukkit. And with all of this work to abstract everything and give it identifiers, as well as all of the command block work, I'm more inclined to think that they're just going to invent a way to interact with the command block interface externally. Combine that with certain aspects of blocks being able to be designated with JSON now, and I think we have a potential recipe for a Java-less API. Which isn't a bad thing, it's just not as useful as what we have.
Thanks for posting that, I really enjoyed reading it! I have a similar process that also starts with a decompiled (no MCP, just JAD) version of the latest snapshot or release. But I don't bother getting it to compile as it's just a reference. After I figure out what an obfuscated class does and assign it a name, I write one or more signatures (bytecode-aware regular expressions, basically) to identify the same class in the later versions. That's how MCPatcher can often work on newer Minecraft versions than it was written for.
No problem, I'm glad you could appreciate it. And it's pretty interesting to hear your methods, too. I'm surprised to hear of someone still using JAD, actually. My experience with it, even with JADRetro added, is relatively poor. Though that's in regards to recompilation, not for your particular use. I've tried every other decompiler I can find and 99.9% of them crash with Minecraft. So far Fernflower has been the only one which brings me anywhere close to working code. I wrote a tool to automatically repair inner classes of enums before decompilation, which saves me some trouble in regards to manually fixing code. I still need to write one to try to search for exception throws, because otherwise I spend 20-30 minutes in Eclipse adding them. It's not hard, since Eclipse can do a lot of the work, it's just tedious. But there are still rare places where Fernflower doesn't decompile the code properly (mostly regarding loops), which results in the game just not working right in various ways, and it being near impossible to find. I honestly don't know how MCP managed to come up with their own patches to deal with that, especially now that the game is so much larger. I had to patch it once just to prevent it from exiting right before the title screen (the main loop wasn't looping), and then again so that the world would actually save (the file IO thread loop wasn't looping). Multiplayer is still broken though, for example. And who knows what else. But it runs!
I'm going to pass along a tool I found recently which has proven invaluable. It's called Java Bytecode Editor. It lets you view all the detailed information about classes you could ever want, including disassembled (not decompiled) code. I used it extensively for debugging the tools I wrote so far for working with and remapping Minecraft. Maybe it'll come in handy for you too.
Kahr, you take a big heaping pile of code that Mojang gives and tweak and manipulate the wired mess of weird to make a platform that us artists can create epic awesomeness. Your work is an excellent foundation for artists (and honestly I wonder why Mojang didn't actually hire you into the texture coding department. You could have a 'plugin api' done that would make their heads spin because you actually listen to the artists who make packs.) I have always been happy with the work you have done to ensure the Patcher's success. I truly appreciate your hard work and dedication. Your MCPatcher has been around almost as long as some of the longest running packs in this forum and PMC.
Do what you can and hopefully Mojang will simply keep their cool for the next few months aside from small bug fixes so all the coders can untangle the web of 'What the...' they have given us.
Thank you again for all the hard work man-SRD
Those words are so true and perfectly echo my own sentiments on the matter. Well said, mate!
In 1.8 Mojang might be giving us something to manipulate Minecraft in ways we've never been able to in the past, but it's not in a format that I can easily work with, and as far as I'm concerned, is directed more to those of us who are already familiar with writing code.
kahr, I hope you'll be able to somehow make sense of 1.8, so that dunderheads like me can still figure out how to edit blocks and models/entities. I can only speak for myself, but the way Mojang have gone about providing random blocks and models in vanilla MC is not very user-friendly in the least. Once nested brackets and other such arcane ways of writing simple instructions showed up in one of the 1.8 snapshots I knew I was on a slippery slope to confusion. If anyone finds this new system easy, all I can say is, "good for you" you're the future of Minecraft, some of us 'creative-types' (quite possibly only me!) who also enjoy manipulating the visual side of Minecraft find it extremely confusing. And yes, I'm aware of some very 'nifty' model editors and no doubt someone will probably make some editor that makes easier sense of writing instructions for block variants, but at the moment it's a confusing mess to me.
The thing I've always appreciated more than anything about your work with MCPatcher, is that you have made it possible for those of us with varying amounts of artistic flair, but absolutely no coding sense, the ability to make all kinds of visual improvements to our texture packs, using plain english instructions.
I've been around longer than most, so can remember how many years (yes years) that Mojang insisted they wouldn't support HD graphics or any of the other bits of visual wizardry you introduced. It still wrankles with me that, to my knowledge, they have given no credit whatosever in MCPatcher's direction and yet years later have adopted each and every improvement you introduced, but in ways that are more confusing to use...at least for the likes of me!
As thecrazydudesrd said, you actually listen to the artists who make packs and somehow seem to see things from their perspective and that they might not necessarily be ofay with code-like instructions...that's no mean feat. Against all the odds, amidst all the endless rewriting of obfuscated code that gets thrown out every update, you somehow manage to give us another MCPatcher tool that makes our worlds look beautiful again...even if it's only in our own eyes.
I understand your frustrations, kahr, and I would completely understand if you just threw your hands in the air and walked away from it all. As many have already said, take all the time you need (selfishly that would allow me more time to catch up with all the new textures. )
Can't thank you enough for keeping my interest in Minecraft going for so long.
This is how Minecraft handles Fast Graphics now. It takes the "Fancy" leaf texture and just drops the alpha channel (transparency).
An easy way to fix this is to take your old fancy leaves texture and put it on a lower layer than your fast leaves, but make it only 1% opaque. Minecraft will totally ignore a 1% transparent pixel (it's below it's transparency threshold) but it will become visible once transparency is disregarded altogether.
I hope that helps you.
Tumbleberry and I were fussing over the metallic gradient effect the new blending creates, but your tweak does the trick. Thank you very much! Very much appreciating your dedication to the technical end when Mojang doesn't seem concerned about supporting the community it benefits so greatly from. Enough complaining ... I'm just grateful there are devs out there like you.
I know that this would be a big change, but would you consider changing the standard CTM tile order? The order now is counter-intuitive and remnant of the old pre-1.5 system. I would recommend one of these two orders (both place similar tiles next to each other).
The first would organize based on connection weighting n first.
none
n
s
e
w
ns
ne
ne2
nw
nw1
se
se4
sw
sw3
ew
nse
nse2
nse4
nse24
nsw
nsw1
nsw3
nsw13
new
new1
new2
new12
sew
sew3
sew4
sew34
nsew
nsew1
nsew2
nsew3
nsew4
nsew12
nsew13
nsew14
nsew23
nsew24
nsew34
nsew123
nsew124
nsew134
nsew234
nsew1234
This second is alphabetical order in the file manager (with the exception of none).
The Meaning of Life, the Universe, and Everything.
Location:
Lincolnton
Join Date:
8/14/2012
Posts:
55
Member Details
I'm trying to make this work with LiteLoader, but not having any luck so far.
I'm using Minecraft Version 1.7.10, Liteloader 1.7.10 and MC Patcher 1.7.10.
I start with a fresh .Minecraft
I add in LiteLoader, start up Minecraft, create a new world, and have World Edit just like I'm supposed to. Yay so far!
I start up MC Patcher and look at versions...there is no LiteLoader version listed for me to patch
I only wanted MC Patcher for the connected textures, soI can use Glimmar's texture pack in all it's glory.
I tried Optifine, but it all got botched by changing the folder names. No idea how to use it without Forge. When I tried to do forge with all this, it creates a new version and I loose the LiteLoader. Ugh. Why did they have to make this so complicated? O.o I'm ending up with all these separate versions, none of them are together. Can you offer any suggestions as to why the list in the MC Patcher doesn't show the LiteLoader version in the drop down menu? Thanks!
McPatcher for 1.8 isn't finished yet. The author is still working on it as he/she said a few pages back. Minecraft 1.8's code is so hard to work with, it's becoming very hard for him/her to continue updates with it, so an update sounds like it might take a bit.
The Meaning of Life, the Universe, and Everything.
Join Date:
10/24/2010
Posts:
52
Member Details
Serious question, and I'm sure it's been asked elsewhere in this 550+ page thread, so apologies in advanced.
If MCPatcher has been able to incorporate textures and animation above 16x for years now, and Mojang is fully aware of this, why hasn't this code adjustment been worked into a version years ago? Is this a political push back against modifying the game? If so, why then include a resource pack function? I'm not trying to start a "***** fest", just to understand. Is it technical or political?
If MCPatcher has been able to incorporate textures and animation above 16x for years now, and Mojang is fully aware of this, why hasn't this code adjustment been worked into a version years ago?
Default, unmodified minecraft has been able to use HD textures and animation for at least a couple years now.
Default, unmodified minecraft has been able to use HD textures and animation for at least a couple years now.
Now, I could be incorrect in saying this, but from my understanding and knowledge eleazzaar is correct in saying minecraft can support HD textures and has been for years. McPatcher just improves and adds to this support to make it even better with things like better glass, better grass, connected textures and many other resource pack functions that the original game just doesn't do.
Hi, I'm having some issues with McPatcher. I don't know if i'm just not doing something correctly, or what, but here's my issue. First of all, every time I try to switch resource packs, my game crashes with this error: http://pastebin.com/7zqjiaMR
Second of all, the resource pack I'm using requires MCPatcher to fix some textures such as the birch wood and the transparency of regular glass and glass on doors. It doesn't matter how many times I patch, it doesn't fix the issue with the texture pack. What do I need to do?
I'm using 1.7.10.
EDIT: Nevermind. Made the mistake of using optifine with mcpatcher. It's fixed.
-snipaphrase-If Minecraft has been able to incorporate textures and animation above 16x for years now why is MCpatcher still needed? Is it technical or political? -snipaphrase-
It is a technical reason why it is needed, for a few reasons. TL;DR is "Mojang adds features, just not for the people that use the features"
HD textures are supported, but this is basic functionality, and if there are any issues related to HD compatibility, it seems Mojang claim it is not supported. See Grum's comment on MC-63485. Although this may just be Grum with this sort of attitude (He wasn't aware zombies and skeletons had hat layers, and then said if they do it wasn't intended, despite this functionality being added before he worked at Mojang).
Animations were added, but only on blocks and items. MCpatcher allows you to add animations to ANYTHING, and rather than animating the entire thing, you can animate a small patch that is placed on top of something else, which is not only easier, adds more options with timing and such.
Random mobs and classic/h+v/repeat CTM are not in vanilla. MCpatcher adds this.
Random textures are in vanilla as of 1.8, however, through an extremely complex and technical model system. Basic random textures on a set of faces and even randomly rotated textures(models, really) are possible in vanilla, but if you want all 6 faces to use a random textures, it gets exponentially more complex the more texture options you have. MCpatcher uses an "abstracted" system, meaning if you're using 2 texture options or 100, it's just as easy to set it to make each face random rather than each block.
Another reason is that the devs don't want to give us ANY control over how things are rendered, even something as simple as removing backface culling from glass, which will allow you to see the other side of glass (which allows you to know where it actually is, especially with large structures). Even when it comes to SAPLINGS, I got told by Grum I should be using an inverted cube, which I AM, and which causes Z-fighting when held in 3rd person, because it doesn't do backface culling even though the world, inventory, and 1st person views do. And then there's MCpatcher: which allows you to change if a block has backface culling or not (directly!), and which allows you to make blocks partially transparent which vanilla does not allow. Like partially transparent glass? Vanilla for some reason does not allow it.... but if rendering issues are gone/reduced, why can't regular glass have it? You know, the thing that generates in villages, the thing most people use? No, stained glass existing does not excuse regular glass being forced to be simple and ugly.
MCpatcher also allows changing individual textures for things that are hardcoded in vanilla, such as potions and mob spawn eggs (I for one made certain mob eggs use icons of mobs they spawn). Yes, both are still hardcoded in 1.8.
MCpatcher also has a more sane method of biome coloring, because Mojang doesn't seem to understand that humans make resource packs, not automated programs that de-obfuscate the JAR and analyze the game code to determine which specific points on the biome color map act as start and stop points for specific biomes, and what sections in a tilted line correlate to which height, and exactly how it decides to do variation based on the some 3-pixel wide line. TL;DR on this point, most artists who modify the vanilla biome colormap probably just paint something in and hope it looks good, or need to use Misa's guide (and still do something easier), rather than making it exactly how they'd like.
Also on biome coloring, MCpatcher allows you to add a color map to ANY block. Mojang decided some things like spruce or birch should use hardcoded colors, or that some biomes should use the color map but add a tint to it, while MCpatcher not only allows you to make a color map for spruce/birch, you could add a color map for STONE if you wanted to.
MCpatcher also allows to to use CTM based on biome or height if you wish. You could make grass appear different in the extreme hills biome, or a random sand texture in the desert biome, or foggy glass in the cold taiga biome, or stone when close to the void, etc etc.
MCpatcher also allows us to still edit the Mojang logo at the start of the game, while Mojang decided "yeah, you've been able to change that for the entirety of the game that supported packs, but we should remove that ability now, because why would people want to improve it or make it in a different style?"....
I think it could also be summarized as "Mojang devs don't even try to see things from our perspective". Apparently even asking for the ability to make glass look better or skeleton skull blocks render like they actually do on skeletons (OR EVEN THE ZOMBIE HEAD BLOCK!) is unreasonable. Many of the basic things that we've been asking for have only been granted in 1.8 because it aligned with the goals to progress to the plugin-API, a long-promised tool to the mod community.
So yeah, MCpatcher still exists because it still has a reason to exist. Kahr alone (I assume, at least) has granted many of the things that the resource packing community wants, things that Mojang has been unable/uncaring to grant. As long as that holds true, MCpatcher (and likely more projects!) will likely continue to exist, even if on the surface it seems like they're outmoded. (if the plugin API doesn't do much, Forge will likely still exist)
EDIT: After reading SRD's comment..... that is a good point, why DIDN'T they hire Kahr? I mean, they contracted Mog to fix a bug with LWJGL and he blasted the community there..... and they STILL hired him.... and he's still a loose cannon. Now I'm not sure if Kahr has any experience with LWJGL, but all of the stuff he has done with MCpatcher with de-obfuscated (in other words, not source) code, or sometimes even updating to OBFUSCATED code is impressive, IMO. I'm sure, based on what he's done, he at least knows a thing or two about rendering, if not more since he does stuff with lightmaps and RENDER PASSES.
If you see this Kahr: Do you know your way around LWJGL? Do you think you could have implemented GLSL shaders into Minecraft to a more complete and fuctional extent than Mog has? (which is basically just modifying screen output and nothing more, no "acid-world" type stuff)
My memory is a bit fuzzy on this, did they offer to hire you? Or did they ask to implement MCpatcher, or to buy it?
As for "suggestions" of what to do for updating, couldn't you tie in CTM ideals into the model system? In other words:
1. .properties files stay the same. You add a new "tool" that analyzes them, and creates model files and blockstates for them. This is most useful for those that want to make a large pool of random textures that have the possibility of being individually random for each face. I suppose you could build this into the game itself, OR possibly as a patcher tool (although that would likely create tons of model possibilities inside packs)
2. port repeat CTM to the model system. I'm not exactly sure how the random system works (is it a set seed based on options, or does it store in block data somehow?), could it be exploited by switching out the "random" component and setting it to use models that create the repeat pattern? Like in a top-down sense, it would call models 1a, 2a, 3a, 4a, and 1 block down it would call 1b, 2b, 3b, 4b, etc. etc. Would get more complex the larger the repeat pattern is. But on a fundamental level, a 2x2 repeat pattern, or any size repeat pattern just on the TOP of the blocks shouldn't be too complicated.
3. porting h+v connect and classic CTM would probably be the worst due to need of being dynamic, plus needing a ton of models for different outcomes. I mean, classic, wow, 47 options on EACH SIDE, you would need a model for EVERY outcome. Possibly MILLIONS of models, I suppose it could be less if you factored how each could be rotated instead, and it would probably not be as bad with a dynamic system that not only calculated which models were NEEDED, but could also CREATE those models. A dynamic system would probably be better for #2 anyways, before you implemented innerSeams, I've liked the idea of a dynamic repeat pattern. In other words, it would repeat where it could PERFECTLY repeat, and leave the edge blocks alone. Maybe something more ingenious than that....
Anyways, that's all I got, hoping it's a viable idea, but the only one I'm really iffy on is #3. The first two might be easier to accomplish than porting and patching your old code into 1.8...
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
-
View User Profile
-
View Posts
-
Send Message
ModeratorIn what context? What needs fixing?
-
View User Profile
-
View Posts
-
Send Message
ModeratorThis is how Minecraft handles Fast Graphics now. It takes the "Fancy" leaf texture and just drops the alpha channel (transparency).
An easy way to fix this is to take your old fancy leaves texture and put it on a lower layer than your fast leaves, but make it only 1% opaque. Minecraft will totally ignore a 1% transparent pixel (it's below it's transparency threshold) but it will become visible once transparency is disregarded altogether.
I hope that helps you.
-
View User Profile
-
View Posts
-
Send Message
ModeratorNo worries, though this is pretty severely off-topic in this thread. I suggest making a topic in Resource Pack Help for it. You can also send me a private message if you like, which may actually be better since I may need to see your leaf files (which you can't post on the forum proper if you didn't make them) to better advise you.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt's been promised for so long that I think it's safe to say that Mojang's own definition of what it will be has changed. It's obviously not going to be Bukkit. And with all of this work to abstract everything and give it identifiers, as well as all of the command block work, I'm more inclined to think that they're just going to invent a way to interact with the command block interface externally. Combine that with certain aspects of blocks being able to be designated with JSON now, and I think we have a potential recipe for a Java-less API. Which isn't a bad thing, it's just not as useful as what we have.
No problem, I'm glad you could appreciate it. And it's pretty interesting to hear your methods, too. I'm surprised to hear of someone still using JAD, actually. My experience with it, even with JADRetro added, is relatively poor. Though that's in regards to recompilation, not for your particular use. I've tried every other decompiler I can find and 99.9% of them crash with Minecraft. So far Fernflower has been the only one which brings me anywhere close to working code. I wrote a tool to automatically repair inner classes of enums before decompilation, which saves me some trouble in regards to manually fixing code. I still need to write one to try to search for exception throws, because otherwise I spend 20-30 minutes in Eclipse adding them. It's not hard, since Eclipse can do a lot of the work, it's just tedious. But there are still rare places where Fernflower doesn't decompile the code properly (mostly regarding loops), which results in the game just not working right in various ways, and it being near impossible to find. I honestly don't know how MCP managed to come up with their own patches to deal with that, especially now that the game is so much larger. I had to patch it once just to prevent it from exiting right before the title screen (the main loop wasn't looping), and then again so that the world would actually save (the file IO thread loop wasn't looping). Multiplayer is still broken though, for example. And who knows what else. But it runs!
I'm going to pass along a tool I found recently which has proven invaluable. It's called Java Bytecode Editor. It lets you view all the detailed information about classes you could ever want, including disassembled (not decompiled) code. I used it extensively for debugging the tools I wrote so far for working with and remapping Minecraft. Maybe it'll come in handy for you too.
WIP site for my mods / Intermediary / FMC / Redstone Paste / Hopper Ducts / Model Citizens / Simple Refinement / Endermanage / Fycraft / etc
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThose words are so true and perfectly echo my own sentiments on the matter. Well said, mate!
In 1.8 Mojang might be giving us something to manipulate Minecraft in ways we've never been able to in the past, but it's not in a format that I can easily work with, and as far as I'm concerned, is directed more to those of us who are already familiar with writing code.
kahr, I hope you'll be able to somehow make sense of 1.8, so that dunderheads like me can still figure out how to edit blocks and models/entities. I can only speak for myself, but the way Mojang have gone about providing random blocks and models in vanilla MC is not very user-friendly in the least. Once nested brackets and other such arcane ways of writing simple instructions showed up in one of the 1.8 snapshots I knew I was on a slippery slope to confusion. If anyone finds this new system easy, all I can say is, "good for you" you're the future of Minecraft, some of us 'creative-types' (quite possibly only me!) who also enjoy manipulating the visual side of Minecraft find it extremely confusing. And yes, I'm aware of some very 'nifty' model editors and no doubt someone will probably make some editor that makes easier sense of writing instructions for block variants, but at the moment it's a confusing mess to me.
The thing I've always appreciated more than anything about your work with MCPatcher, is that you have made it possible for those of us with varying amounts of artistic flair, but absolutely no coding sense, the ability to make all kinds of visual improvements to our texture packs, using plain english instructions.
I've been around longer than most, so can remember how many years (yes years) that Mojang insisted they wouldn't support HD graphics or any of the other bits of visual wizardry you introduced. It still wrankles with me that, to my knowledge, they have given no credit whatosever in MCPatcher's direction and yet years later have adopted each and every improvement you introduced, but in ways that are more confusing to use...at least for the likes of me!
As thecrazydudesrd said, you actually listen to the artists who make packs and somehow seem to see things from their perspective and that they might not necessarily be ofay with code-like instructions...that's no mean feat. Against all the odds, amidst all the endless rewriting of obfuscated code that gets thrown out every update, you somehow manage to give us another MCPatcher tool that makes our worlds look beautiful again...even if it's only in our own eyes.
I understand your frustrations, kahr, and I would completely understand if you just threw your hands in the air and walked away from it all. As many have already said, take all the time you need (selfishly that would allow me more time to catch up with all the new textures.
Can't thank you enough for keeping my interest in Minecraft going for so long.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumTumbleberry and I were fussing over the metallic gradient effect the new blending creates, but your tweak does the trick. Thank you very much! Very much appreciating your dedication to the technical end when Mojang doesn't seem concerned about supporting the community it benefits so greatly from. Enough complaining ... I'm just grateful there are devs out there like you.
So, thanks. ^^
I Started With A Clean Minecraft Then Installed Forge And LiteLoader(Linked To Forge) Then MCPatcher. All With MC Version 1.7.10.
Can You Help?
The first would organize based on connection weighting n first.
This second is alphabetical order in the file manager (with the exception of none).
Putting the CENDENT back in transcendent!
I'm using Minecraft Version 1.7.10, Liteloader 1.7.10 and MC Patcher 1.7.10.
I start with a fresh .Minecraft
I add in LiteLoader, start up Minecraft, create a new world, and have World Edit just like I'm supposed to. Yay so far!
I start up MC Patcher and look at versions...there is no LiteLoader version listed for me to patch
I only wanted MC Patcher for the connected textures, soI can use Glimmar's texture pack in all it's glory.
I tried Optifine, but it all got botched by changing the folder names. No idea how to use it without Forge. When I tried to do forge with all this, it creates a new version and I loose the LiteLoader. Ugh. Why did they have to make this so complicated? O.o I'm ending up with all these separate versions, none of them are together. Can you offer any suggestions as to why the list in the MC Patcher doesn't show the LiteLoader version in the drop down menu? Thanks!
Read the title
Embed Removed: https://www.minecraftforum.net/linkout?remoteUrl=http://7proxies.pw/i/2014/09/blades3.webm
If MCPatcher has been able to incorporate textures and animation above 16x for years now, and Mojang is fully aware of this, why hasn't this code adjustment been worked into a version years ago? Is this a political push back against modifying the game? If so, why then include a resource pack function? I'm not trying to start a "***** fest", just to understand. Is it technical or political?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDefault, unmodified minecraft has been able to use HD textures and animation for at least a couple years now.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
Now, I could be incorrect in saying this, but from my understanding and knowledge eleazzaar is correct in saying minecraft can support HD textures and has been for years. McPatcher just improves and adds to this support to make it even better with things like better glass, better grass, connected textures and many other resource pack functions that the original game just doesn't do.
Hope this helps. ^^
Second of all, the resource pack I'm using requires MCPatcher to fix some textures such as the birch wood and the transparency of regular glass and glass on doors. It doesn't matter how many times I patch, it doesn't fix the issue with the texture pack. What do I need to do?
I'm using 1.7.10.
EDIT: Nevermind. Made the mistake of using optifine with mcpatcher. It's fixed.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffIt is a technical reason why it is needed, for a few reasons. TL;DR is "Mojang adds features, just not for the people that use the features"
HD textures are supported, but this is basic functionality, and if there are any issues related to HD compatibility, it seems Mojang claim it is not supported. See Grum's comment on MC-63485. Although this may just be Grum with this sort of attitude (He wasn't aware zombies and skeletons had hat layers, and then said if they do it wasn't intended, despite this functionality being added before he worked at Mojang).
Animations were added, but only on blocks and items. MCpatcher allows you to add animations to ANYTHING, and rather than animating the entire thing, you can animate a small patch that is placed on top of something else, which is not only easier, adds more options with timing and such.
Random mobs and classic/h+v/repeat CTM are not in vanilla. MCpatcher adds this.
Random textures are in vanilla as of 1.8, however, through an extremely complex and technical model system. Basic random textures on a set of faces and even randomly rotated textures(models, really) are possible in vanilla, but if you want all 6 faces to use a random textures, it gets exponentially more complex the more texture options you have. MCpatcher uses an "abstracted" system, meaning if you're using 2 texture options or 100, it's just as easy to set it to make each face random rather than each block.
Another reason is that the devs don't want to give us ANY control over how things are rendered, even something as simple as removing backface culling from glass, which will allow you to see the other side of glass (which allows you to know where it actually is, especially with large structures). Even when it comes to SAPLINGS, I got told by Grum I should be using an inverted cube, which I AM, and which causes Z-fighting when held in 3rd person, because it doesn't do backface culling even though the world, inventory, and 1st person views do. And then there's MCpatcher: which allows you to change if a block has backface culling or not (directly!), and which allows you to make blocks partially transparent which vanilla does not allow. Like partially transparent glass? Vanilla for some reason does not allow it.... but if rendering issues are gone/reduced, why can't regular glass have it? You know, the thing that generates in villages, the thing most people use? No, stained glass existing does not excuse regular glass being forced to be simple and ugly.
MCpatcher also allows changing individual textures for things that are hardcoded in vanilla, such as potions and mob spawn eggs (I for one made certain mob eggs use icons of mobs they spawn). Yes, both are still hardcoded in 1.8.
MCpatcher also has a more sane method of biome coloring, because Mojang doesn't seem to understand that humans make resource packs, not automated programs that de-obfuscate the JAR and analyze the game code to determine which specific points on the biome color map act as start and stop points for specific biomes, and what sections in a tilted line correlate to which height, and exactly how it decides to do variation based on the some 3-pixel wide line. TL;DR on this point, most artists who modify the vanilla biome colormap probably just paint something in and hope it looks good, or need to use Misa's guide (and still do something easier), rather than making it exactly how they'd like.
Also on biome coloring, MCpatcher allows you to add a color map to ANY block. Mojang decided some things like spruce or birch should use hardcoded colors, or that some biomes should use the color map but add a tint to it, while MCpatcher not only allows you to make a color map for spruce/birch, you could add a color map for STONE if you wanted to.
MCpatcher also allows to to use CTM based on biome or height if you wish. You could make grass appear different in the extreme hills biome, or a random sand texture in the desert biome, or foggy glass in the cold taiga biome, or stone when close to the void, etc etc.
MCpatcher also allows us to still edit the Mojang logo at the start of the game, while Mojang decided "yeah, you've been able to change that for the entirety of the game that supported packs, but we should remove that ability now, because why would people want to improve it or make it in a different style?"....
I think it could also be summarized as "Mojang devs don't even try to see things from our perspective". Apparently even asking for the ability to make glass look better or skeleton skull blocks render like they actually do on skeletons (OR EVEN THE ZOMBIE HEAD BLOCK!) is unreasonable. Many of the basic things that we've been asking for have only been granted in 1.8 because it aligned with the goals to progress to the plugin-API, a long-promised tool to the mod community.
So yeah, MCpatcher still exists because it still has a reason to exist. Kahr alone (I assume, at least) has granted many of the things that the resource packing community wants, things that Mojang has been unable/uncaring to grant. As long as that holds true, MCpatcher (and likely more projects!) will likely continue to exist, even if on the surface it seems like they're outmoded. (if the plugin API doesn't do much, Forge will likely still exist)
EDIT: After reading SRD's comment..... that is a good point, why DIDN'T they hire Kahr? I mean, they contracted Mog to fix a bug with LWJGL and he blasted the community there..... and they STILL hired him.... and he's still a loose cannon. Now I'm not sure if Kahr has any experience with LWJGL, but all of the stuff he has done with MCpatcher with de-obfuscated (in other words, not source) code, or sometimes even updating to OBFUSCATED code is impressive, IMO. I'm sure, based on what he's done, he at least knows a thing or two about rendering, if not more since he does stuff with lightmaps and RENDER PASSES.
If you see this Kahr: Do you know your way around LWJGL? Do you think you could have implemented GLSL shaders into Minecraft to a more complete and fuctional extent than Mog has? (which is basically just modifying screen output and nothing more, no "acid-world" type stuff)
My memory is a bit fuzzy on this, did they offer to hire you? Or did they ask to implement MCpatcher, or to buy it?
As for "suggestions" of what to do for updating, couldn't you tie in CTM ideals into the model system? In other words:
1. .properties files stay the same. You add a new "tool" that analyzes them, and creates model files and blockstates for them. This is most useful for those that want to make a large pool of random textures that have the possibility of being individually random for each face. I suppose you could build this into the game itself, OR possibly as a patcher tool (although that would likely create tons of model possibilities inside packs)
2. port repeat CTM to the model system. I'm not exactly sure how the random system works (is it a set seed based on options, or does it store in block data somehow?), could it be exploited by switching out the "random" component and setting it to use models that create the repeat pattern? Like in a top-down sense, it would call models 1a, 2a, 3a, 4a, and 1 block down it would call 1b, 2b, 3b, 4b, etc. etc. Would get more complex the larger the repeat pattern is. But on a fundamental level, a 2x2 repeat pattern, or any size repeat pattern just on the TOP of the blocks shouldn't be too complicated.
3. porting h+v connect and classic CTM would probably be the worst due to need of being dynamic, plus needing a ton of models for different outcomes. I mean, classic, wow, 47 options on EACH SIDE, you would need a model for EVERY outcome. Possibly MILLIONS of models, I suppose it could be less if you factored how each could be rotated instead, and it would probably not be as bad with a dynamic system that not only calculated which models were NEEDED, but could also CREATE those models. A dynamic system would probably be better for #2 anyways, before you implemented innerSeams, I've liked the idea of a dynamic repeat pattern. In other words, it would repeat where it could PERFECTLY repeat, and leave the edge blocks alone. Maybe something more ingenious than that....
Anyways, that's all I got, hoping it's a viable idea, but the only one I'm really iffy on is #3. The first two might be easier to accomplish than porting and patching your old code into 1.8...
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin