By now we've all gotten used to the cycle of Mojang getting distracted from bugfixes to play with a shiny new toy, but they really raised the bar this time. What exactly was the thought process here?
From a business standpoint, twitch.tv obviously benefits, but what does Mojang get out of it? Is a little ad revenue worth tying their flagship game and their players to another company?
On the technical side, why make your game dependent on a third-party feature that 99% of players will never use? Some players can't even start the snapshots because the twitch library is missing or crashing. And the timing. They delay a much-needed 1.7.3 to cram in a major new third-party library dependency. One that by necessity must hook fairly deeply into the rendering code. Is it any surprise that we're already up to 13w47e?
Even the players who do want to stream won't necessarily want to be locked into one streaming service. And presumably the dedicated LPers will continue to post pre-recorded and edited videos, so again I ask, what is the point of this?
-
- Kahr
- Registered Member
-
Member for 13 years, 5 months, and 5 days
Last active Fri, Jun, 5 2015 09:57:53
- 13 Followers
- 355 Total Posts
- 1437 Thanks
3
See OP for full list of changes and download links. The main download may not update right away, so try the alternate link if you are still getting the 4.3.0 version.
2
A known problem with Zan's minimap and MCPatcher. There's a fix in 4.3.1-beta1 but it doesn't work with the forge version unfortunately. I should have both versions working in 4.3.1 final.
Should be fixed in 4.3.1-beta1. Could you confirm, in case I still need to look into this?
Well replace is inherently all-or-nothing, that's kind of what the word means. Maybe you want alpha blending?
Yes, Mojang retroactively changed the assets directory to assets/virtual/legacy, which confused a lot of things (font spacing, configuration, etc.). Oddly, it didn't break 1.7.3, which I have working in a dev version, but only 1.7.2 and earlier. Fixed for the next release.
Finally sat down and looked at this. The 1.4 to 1.5 conversion should work in the next release.
You probably already know this, but for the benefit of others, texture packs can be converted from the command line:
Fixed.
MCPatcher's mipmapping, AA, and aniso filtering implementation were tied together. When I removed one, I had to remove them all.
Disable Smooth biome colors and/or reduce the block blend radius in the Options tab under Custom Colors.
2
I think Java 8 is your problem here. Try using an official Java release instead of a beta.
Like it says, that's only a warning. The Minecraft version is newer than what was released when MCPatcher was built. It means you may experience problems, most likely mods being greyed out because some relevant bit of code changed.
I don't change the thread title until I've confirmed that the latest release works with the new snapshot/version. I also compare the patch log with a known good one (ignoring changes in the class mapping).
2
Gonna go with linked=true for this property. It is per-file, applies only to method=random, and defaults to false. For now it affects only double plants, plants (useful for reeds), and doors.
Both fixed.
No problems with that texture pack here. And unfortunately there's not much in that log to go on either.
This is a vanilla 1.7.2 bug that is fixed in the latest snapshots.
1
Fair point, and that's one of the reasons I wanted to do a beta before making it official. The old behavior (independent tops and bottoms) should probably be the default with an option to turn on the new behavior, just so no one is caught by surprise. I'm just not sure what to call it. useSameSeedForMultiblockObjects=true doesn't exactly roll off the tongue, does it?
More precisely, (ignoring the weights property for the moment)
T = number of top textures
B = number of bottom textures
- If T and B are relatively prime: Tops and bottoms are completely scrambled.
- If gcd(T,B) > 1: Somewhat scrambled, but certain pairings will never occur.
- If T is an exact multiple of B or vice versa: Each bottom has its own separate set of potential tops (or vice versa).
- If T = B: Tops and bottoms are always in sync.
- For weighted lists, just pretend that they're unweighted lists with the textures repeated: tiles=a b c weights=1 2 3 is equivalent to tiles=a b b c c c.
Yes I was a math major, why do you ask?You could possibly do it with the divisor trickery above. Or, assuming I make the new behavior optional, by chaining two random CTMs together:
dummy_top and dummy_bottom aren't real textures. Their only purpose is to get matched by the next set of rules:
I think this problem will have to wait until mcp is updated. There's more to Mojang's new transparency handling than I originally thought, but it's too complicated to figure out in obfuscated code.
2
Changes:
- Force consistent coloring and random CTM between top and bottom half of double_plant blocks.
- Fixed CTM problems with metadata 15.
- Fixed custom grass, foliage.png always using the vanilla format.
- Fixed beacon particle effects transparency.
- Support texture.* syntax in CIT type=enchantment.
- Added yOffset property to grid format colormap.
- Fixed Test Minecraft button with 13w47e.
- Fixed crash with zan's minimap.
- Fixed transparency issues with 13w47e.
- Fixed CIT ignoring weight property in some cases.
- Allow CIT matching of damage as a % of max in addition to an absolute value.
- Preserve Mojang's hard-coded biome colors for packs with no grass, foliage.png.
- Fix inconsistent water particle colors.
- Ignore neighbor's metadata when checking connect=material.
- New property enableColormap.3 to enable custom colormaps during render pass 3.
Enjoy!1
In general, connectedness requires that the two blocks have the same metadata value. I'm considering removing this restriction for connect=material but am unsure if there would be any negative side effects (like block A connecting to block B, but not vice versa).
Turns out the particle.color property wasn't being used at all since the new colormap system. I've fixed that problem and a few others, so water particles should be colored more consistently now.
Does blend.3=replace work now? Any of the Better Skies blending methods should be recognized.
I'll look into making colormaps more render pass-aware, which should address the second problem.
You're probably not doing anything wrong. There's currently a bug applying the grid format to grass and foliage. You can work around it by setting grid format globally (palette.format=grid in color.properties) or by naming the files something other than "grass" or "foliage".
I've changed random CTM so that the top and bottom halves of double plants use the same seed value. If you have the same number of tiles and weights, it should behave consistently.
double_plant_bottom.properties:
method=random
matchBlocks=double_plant:0-7
tiles=red_bottom green_bottom blue_bottom
double_plant_top.properties:
method=random
matchBlocks=double_plant:8-15
tiles=red_top green_top blue_top
This is exactly right. When the game requests a texture it has no way of knowing which pack it came from. All of that information is abstracted away.
I'm not sure what the correct behavior should be either. The current behavior works for a base pack + addon packs that are designed to go together. Like a base pack with just vanilla textures, another pack for mods, an MCPatcher addon pack with CTM, Random Mobs, etc., and possibly even additional packs with more CTM variants. But merging two base packs from two different authors is problematic no matter how you do it.
2
Fixed for next release.
3
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.
5
From a business standpoint, twitch.tv obviously benefits, but what does Mojang get out of it? Is a little ad revenue worth tying their flagship game and their players to another company?
On the technical side, why make your game dependent on a third-party feature that 99% of players will never use? Some players can't even start the snapshots because the twitch library is missing or crashing. And the timing. They delay a much-needed 1.7.3 to cram in a major new third-party library dependency. One that by necessity must hook fairly deeply into the rendering code. Is it any surprise that we're already up to 13w47e?
Even the players who do want to stream won't necessarily want to be locked into one streaming service. And presumably the dedicated LPers will continue to post pre-recorded and edited videos, so again I ask, what is the point of this?
1
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.
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.
1
The setup:
1.6.4:
1.7.2:
13w47c:
This is surprisingly complicated to fix, but I may have something that will work.
1
I found part of the problem at least. It turns out this syntax
doesn't work for enchantments. It should be fixed now, and it might explain why certain enchantments of yours just weren't working.
Well, which would you prefer? Flip the texture upside down, or mentally calculate 255 - y all the time?
I figured it could be useful for underground strata. But regardless, this feature is more accidental than anything. I could add a yOffset property to do what you suggest though.
Variance is applied directly to the block y coordinate, before anything else. In pseudocode,
y = block.y + variance * random(-1, 1) if (y < 0) y = 0 if (y > colormapHeight - 1) y = colormapHeight - 1 return map[biomeID][y](It's a bit more complicated. Calculation is done in floating point and linearly interpolates if it's between two integers.)
So in your example, blocks at 7 or higher would always use the bottom (y=3) pixel.
Unfortunately it's a limitation of the renderer. GL options like blending and culling have to apply to the whole render pass, and a block is either in a particular pass or it isn't. This limitation has always been there, but it wasn't an issue until there were suddenly 16 new kinds of glass blocks.
It's also why depth sorting is such a mess now. Mojang's "fix" for stained glass was simply to turn off writing to the z-buffer during render pass 1. To be fair, doing it right is vastly more complicated, but it still leaves me in a ditch.
Whoops. Silly double negatives. Fixed.
3
No, not yet.
I downloaded your pack and took out all the renderPass=2 lines from all 16 glass_*_pane.properties files. Is this how it should look?
3
Fixed.
Fixed.
Fixed.
Fixed.
Possibly fixed. I'm pretty sure this is the same as Leischii's problem.
Render pass 2 isn't supposed to support transparency. It only differs from render pass 0 in that it disables backface culling. Use render pass 1 instead.
Here are the render passes in the order they happen in-game:
0: On/off transparency, with backface culling (vanilla)
2: On/off transparency, without backface culling (added by Better Glass)
1: Transparent blocks with alpha blending and no depth sorting (vanilla)
3: Transparent blocks with customizable blending (added by Better Glass)
When you put renderPass=n in a ctm properties file, you are assigning the block a new render pass, either by replacing (0-2) or adding (3).
If I'm not mistaken there's no reason to use render pass 3 anymore unless you need finer control over the blending method.
Fixed. Related to the black/white stained clay bug it turns out.
Fixed.