Yeaah, the fix is kind of ugly. Good for still water, yeah, but flowing water looks buggy with just the top part rendering. I liked how it was in 1.6.4 since the water flowing water texture helps give it the look that you're behind water and it's cascading around you. With 1.7.2 and the "fixed" version, it really doesn't look right at all. I guess it ~might~ look better if some sort of falloff was applied to the surface when the water's flowing, but I don't know if that'd be possible.
So is anyone else not happy with Mojang's "fix" for not being able to see the water surface from underwater? (See MC-34751)
Looks like quality work from our professional bandaiders over at Nojang.
Of course, I'm sure you know better than most people here just how messy the code is. I'm a java programmer myself, and even though I haven't actually looked at MC's source it's pretty obvious to me, just judging by the filenames they pick for the textures, they have no professional education on java programming. They seem to operate more like advanced amateurs. They seem to just do "eh whatever!" with no regard what so ever to any kind of organizational pattern, industry standard or their own.
I noticed in some old posts you stated that jukebox CTM does not work after 1.2.5. Does the server send NBT data about the music playing to the client? Perhaps using the way comparators detect it would work.
Of course, I'm sure you know better than most people here just how messy the code is. I'm a java programmer myself, and even though I haven't actually looked at MC's source it's pretty obvious to me, just judging by the filenames they pick for the textures, they have no professional education on java programming. They seem to operate more like advanced amateurs. They seem to just do "eh whatever!" with no regard what so ever to any kind of organizational pattern, industry standard or their own.
The code's messy in places for sure, but not horrible. I think you touched on a deeper problem though. It's a cycle. They sit down to fix bugs or do other grunt work, get distracted by some "cool" new feature -- this streaming thing being the latest example -- and the community fawns over it. The boring work of fixing/balancing the old stuff gets pushed to the background, piling onto the debt. No one at Mojang seems to be willing to crack the whip, so the backlog gets bigger and even easier to get distracted from next time.
What also bothers me is a little graphical glitch on my creative inventory tabs:
Strange. MCPatcher doesn't even modify the GUI classes, so it must be a side effect of something else. Do you happen to know which MCPatcher feature in particular causes it? I'll check myself later, but it will help me narrow the problem down.
I noticed in some old posts you stated that jukebox CTM does not work after 1.2.5. Does the server send NBT data about the music playing to the client? Perhaps using the way comparators detect it would work.
I haven't actually looked if anything changed, but the fact that comparators can detect it doesn't mean anything. Like all game logic, that's likely done on the server.
PSN:
Can't you read? I said I only play PC Minecraft
Member Details
Um, I really need some help. I'm trying to make a resource pack that uses the CIT feature, but the help page doesn't give me the information I need. I don't need all of that help, I need a format, or an example on how you type it.
Basically, I need a pre-made CIT file for renamed items. It doesn't matter what the item is, I just need a pre-made CIT file.
Um, I really need some help. I'm trying to make a resource pack that uses the CIT feature, but the help page doesn't give me the information I need. I don't need all of that help, I need a format, or an example on how you type it.
Basically, I need a pre-made CIT file for renamed items. It doesn't matter what the item is, I just need a pre-made CIT file.
CIT is super easy, actually.
1. make a \assets\minecraft\mcpatcher\cit folder in your pack. (you can add subfolders as well)
2. Whatever texture you want to use CIT on, put the CIT-version in the folder.
3. Make a same-name .properties file (IE: damaged_diamond_pickaxe.png and .properties)
4. Inside, the only line *required* is:
items=ItemID
But, most people won't be using CIT for just that.. if they were, why would they even bother?
Here's an example .properties file for a bat spawn egg in my pack, where the damage property stores the type of mob that spawns
items=383
damage=65
..and one from Misa's pack, thats an example of tool desegregation, any durability level between 626-1249 on item 279 (an axe) would use the texture misaaxd1.png
CIT causes this. Just patched 13w47e only with CIT checked in the patcher, the creative menu showed exactly the glitch seen on my screenshot above. Patched the snapshot again with everything except CIT checked, the glitch was gone. I'm currently not using any CIT stuff in my "Better than Default" pack. This info should help to narrow it down
I think they're doing something weird with the enchantment effects starting in 1.7. There's a few vanilla GUI bugs that are related to enchanted items. Text and icons related to active potion effects not always appearing in the inventory GUI, etc. I'll bet when Kahr finds out what's causing your issue he'll also find out what's causing my problem as well.
Umm hi I have an question, when I launch MCpatcher it won't let me pick things like extented HD or connected textures. How do I make these work?
What version of MCPatcher are you using, and what version of Minecraft are you using? We need more info than "it doesn't work".
If you're in the latest version of Minecraft, make sure you're using the latest MCPatcher as well. Re-download both if you need to to make sure that this is the case. If you're using an older Minecraft version, make sure you have the version of MCPatcher to match.
In the latest release of my texture pack, i've included 16 random skins per villager profession, with the idea that it will be easier to find that one villager you want to trade with if most of them look unique. A guy on reddit says that if the chunk with the mod unloads when the chunk is loaded again random mobs mod may assign a different skin to the mob. In my limited testing, as long as i don't modify the texture pack, the villagers keep the same appearance.
Who is right? I don't want to advertise something as a feature of my pack, if it really doesn't work.
Who is right? I don't want to advertise something as a feature of my pack, if it really doesn't work.
It depends on whether or not you're on a server, or in single player. In multiplayer he's right. In singleplayer, you're correct.
To keep mob skins consistent consistent, MCPatcher actually stores information within the mob entity to recall later. This works on single player since MCPatcher has access to the server. It doesn't work in multiplayer for the same reason: your client can't force the server to store extra information.
When I get rid of my "last resort" option, it seems to work normally. It also seems to be working normally for swords, axes, shovels, hoes, and pickaxes... but not for any sort of armor or other tools. This is true even for files like the ones that govern the Unbreaking enchantment in my pack, which are applied to anything with that enchantment regardless of its type.
Ok, at long last I think I figured this one out. Naturally the fix was a one-line change.
CIT causes this. Just patched 13w47e only with CIT checked in the patcher, the creative menu showed exactly the glitch seen on my screenshot above. Patched the snapshot again with everything except CIT checked, the glitch was gone.[/img]
Thanks, that helped. Mojang changed the transparency settings yet again. Fixed for next release.
Technical description: java.lang.IllegalAccessError: tried to access field bqh.a from class com.prupe.mcpatcher.TextureAPI
Both are fixed in the latest version (4.3.0). All the download links in the OP are up to date, but there may be some older links out there on other sites. Please use the OP to ensure you get the latest version.
I'd hazard a guess the 4.3.0 version of Mcpatcher is compatible with the latest snapshot, hence why the title indicates as such.
Yes, no changes were needed for this week's snapshots. It's been a while since I've been able to say that. There are a few minor glitches that I'm working on, so there will probably be a 4.3.0_01 at some point.
Yes, no changes were needed for this week's snapshots. It's been a while since I've been able to say that. There are a few minor glitches that I'm working on, so there will probably be a 4.3.0_01 at some point.
When using the default textures, the color of grass gets brighter.
...
This happens in the Canyon- and swamp-biome. In another one too, but I can't remember, which one. It is really annoying, because I love the colors of the normal grass-textures, but I don't want to unpatch my game everytime I play with default textures.
Order of resource pack different in MCPatcher <--> Vanilla
If I use another resource pack to fill in the missing textures of Misa's resource pack the order of some textures is different compared to vanilla.
For example with MCPatcher the ores are taken from the second order resource pack, vanilla takes those from the first order resource pack. Same with the regular glass panes.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThanks, that's good to know.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
The setup:
1.6.4:
1.7.2:
13w47c:
This is surprisingly complicated to fix, but I may have something that will work.
Looks like quality work from our professional bandaiders over at Nojang.
Of course, I'm sure you know better than most people here just how messy the code is. I'm a java programmer myself, and even though I haven't actually looked at MC's source it's pretty obvious to me, just judging by the filenames they pick for the textures, they have no professional education on java programming. They seem to operate more like advanced amateurs. They seem to just do "eh whatever!" with no regard what so ever to any kind of organizational pattern, industry standard or their own.
/rantoff
Is there any way to add support nbt.display.Name for blocks?
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe code's messy in places for sure, but not horrible. I think you touched on a deeper problem though. It's a cycle. They sit down to fix bugs or do other grunt work, get distracted by some "cool" new feature -- this streaming thing being the latest example -- and the community fawns over it. The boring work of fixing/balancing the old stuff gets pushed to the background, piling onto the debt. No one at Mojang seems to be willing to crack the whip, so the backlog gets bigger and even easier to get distracted from next time.
I added my two cents as well. Everyone please upvote this one if you want to see it fixed.
Strange. MCPatcher doesn't even modify the GUI classes, so it must be a side effect of something else. Do you happen to know which MCPatcher feature in particular causes it? I'll check myself later, but it will help me narrow the problem down.
I haven't actually looked if anything changed, but the fact that comparators can detect it doesn't mean anything. Like all game logic, that's likely done on the server.
Basically, I need a pre-made CIT file for renamed items. It doesn't matter what the item is, I just need a pre-made CIT file.
CIT is super easy, actually.
1. make a \assets\minecraft\mcpatcher\cit folder in your pack. (you can add subfolders as well)
2. Whatever texture you want to use CIT on, put the CIT-version in the folder.
3. Make a same-name .properties file (IE: damaged_diamond_pickaxe.png and .properties)
4. Inside, the only line *required* is:
But, most people won't be using CIT for just that.. if they were, why would they even bother?
Here's an example .properties file for a bat spawn egg in my pack, where the damage property stores the type of mob that spawns
..and one from Misa's pack, thats an example of tool desegregation, any durability level between 626-1249 on item 279 (an axe) would use the texture misaaxd1.png
misaaxd1.properties:
As for settings and tweaks, this should help get you going in the right direction:
https://bitbucket.org/prupe/mcpatcher/src/cd62a7644b4ed60849cc5ff0dc970b7e58f4149d/doc/cit.properties?at=3.x
(EDIT: Note that matchItems and Items are the same thing basically)
-
View User Profile
-
View Posts
-
Send Message
ModeratorWhat version of MCPatcher are you using, and what version of Minecraft are you using? We need more info than "it doesn't work".
If you're in the latest version of Minecraft, make sure you're using the latest MCPatcher as well. Re-download both if you need to to make sure that this is the case. If you're using an older Minecraft version, make sure you have the version of MCPatcher to match.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWho is right? I don't want to advertise something as a feature of my pack, if it really doesn't work.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
-
View User Profile
-
View Posts
-
Send Message
ModeratorTo keep mob skins consistent consistent, MCPatcher actually stores information within the mob entity to recall later. This works on single player since MCPatcher has access to the server. It doesn't work in multiplayer for the same reason: your client can't force the server to store extra information.
Does that explain it?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYup, thanks.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhere is the download link for the latest snapshot 13w47e (as the title indicates) .
Or am I missing something?
Ok, at long last I think I figured this one out. Naturally the fix was a one-line change.
Thanks, that helped. Mojang changed the transparency settings yet again. Fixed for next release.
Both are fixed in the latest version (4.3.0). All the download links in the OP are up to date, but there may be some older links out there on other sites. Please use the OP to ensure you get the latest version.
Yes, no changes were needed for this week's snapshots. It's been a while since I've been able to say that. There are a few minor glitches that I'm working on, so there will probably be a 4.3.0_01 at some point.
-
View User Profile
-
View Posts
-
Send Message
ModeratorThanks Kahr! I know you must be sick of hearing this, but you're the best!
Excellent. I'm looking forward to it!
Fixed for next release.
If I use another resource pack to fill in the missing textures of Misa's resource pack the order of some textures is different compared to vanilla.
For example with MCPatcher the ores are taken from the second order resource pack, vanilla takes those from the first order resource pack. Same with the regular glass panes.