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 1 day
Last active Fri, Jun, 5 2015 09:57:53
- 13 Followers
- 355 Total Posts
- 1437 Thanks
11
I see that forge has been updated for 1.8, but I still have work to do to make MCPatcher compatible with it again. Getting at least basic compatibility going again is likely next on my to-do list.
Small new bonus feature: colormap/underlava.png - does exactly what it says.
3
The main Windows download link may take a few hours to update, but the alternate link should take you to the new version.
9
Changes from 1.8.preview2:
Still TODO (not a complete list):
0
3
Use the matchBlocks= (or matchTiles=) property within the file instead of relying on the filename. Then it doesn't matter what the file is called. You can also use the weight= property to specify priority instead of relying on the default sorting. Although tile-based matches are always checked before block-based ones.
Fixed!
You may be mixing up two separate things here. symmetry=all means use the same random texture for all faces (n,s,e,w,u,d) of the same block. linked=true means use the same random seed for both parts of a multipart block so that the two halves are synchronized. The linked property is meaningful only for a handful of block types, double plants being one of them, while symmetry is more useful generally.
Before 1.8, "crossed square"-type models like flowers didn't really have faces as far as the game was concerned, so symmetry=all was automatic. I would recommend using the symmetry property explicitly now. It will fix your problem in 1.8 and won't affect the behavior in 1.7.
I hadn't noticed that, but it's possble there's a bug there. Could you turn Custom Colors logging to FINE (MCPatcher Options tab) once and see if it is applying the colormaps to the right blocks?
5
Thanks. Fixed some and added the rest to the todo list.
No, this is different actually. It's about block metadata rather than block names. You really shouldn't be using numeric block IDs anymore even in 1.7, by the way.
In 1.8 things have changed yet again, this time axing numeric metadata, the 0-15 values that differentiate variants of the same block. Mojang switched to a system of named properties and values. I was able to figure out how to convert numeric metadata to the new system in most cases, but it's not perfect and, like numeric block IDs, I can't promise support for it indefinitely.
For comparison
The last format is the one I recommend, especially for new work. And again, the MCPatcher output window will offer a potential conversion that works in most cases, but it's up to you to double-check and update your properties files.
MCP has certainly helped, although I'd gotten pretty knowledgeable of cln.class and its friends without it. Still pretty much limited to weekends for development. 1.8 is really difficult to work with and I just don't have enough time or energy after a day at work.
Gah, I was sure I fixed that. Ok, now it should really be fixed for next time.
MCPatcher doesn't touch that part of the code, so maybe it's just an artifact of the additional load CTM etc. put on the rendering. Tempting as it is, a proper optimization would require some fundamental rearchitecting of the 1.8 code. Things like having to allocate a new "BlockPosition" object every single time I want to look at a neighboring block simply can't be fixed at the bytecode level.
Oddly, your link didn't work for me until I quoted your post and looked at the raw BB code. Thanks, I'll take a look at it. I often make up test packs with dummy textures, but it always helps to have real-world test cases from the community.
20
Changes since last preview:
NOT working yet (partial TODO list):
The block:metadata conversion attempts to interpret old numerical metadata values as block state properties. When you have a block:metadata rule with no properties specified, MCPatcher makes its best guess at a proper 1.8 equivalent. Check the output log for messages like This means you should use (in your properties file) The conversion is not perfect, however, and may require manual tweaking, especially for multipart blocks like beds and double plants.
Here are the default rabbit egg spawn colors for color.properties:
The 1.8 update is still a struggle to work with, hence the slow progress. Understanding the code better hasn't really raised my opinion of it much. I still find it brittle and stubbornly resistant to every attempt to swap out textures dynamically, which is the heart of CTM and CIT. All for the sake of the frankly dubious optimization of baking custom model data into int arrays. Which is likely undone by having to allocate a new object for every replacement texture of every face of every model.
2
Hear, hear! While I can't say I'm thrilled about the MS deal, Minecraft has been so poorly managed since Notch left it that I'm willing to give it a shot. The lack of a proper API more than three years after new people were hired specifically to work on it and the completely scatterbrained approach to content development are symptoms of the same lack of adult supervision over at Mojang. Whatever else happens I hope MS will inject some sorely-needed professionalism into the project. Or for all we know, MS has been developing a voxel game in secret for two years now and just wanted the brand name so they could slap a "Minecraft 2" label on it.
10
First thing you'll notice is the Mods list is shorter. Custom Textures and Models (CTM, get it?) is intended to cover Connected Textures, Custom Item Textures, and the custom colormaps feature of Custom Colors. All of those things depend (or will depend in the case of CIT which isn't working yet) heavily on Mojang's model system in 1.8 so it was easier for me to combine them. I may break the features up again later, but for now this is what you'll see.
Featurewise, not much visible progress since my last post, as I was stuck on a severe performance problem for several days. Some change Mojang introduced in 1.8-pre2 interacted badly with custom colormaps and caused the game to stutter and slow to single digits if they were enabled. It was only yesterday that I was able to track the problem down.
tl;dr Download MCPatcher 3-2i, so complex it has imaginary parts! exe jar
For the record, I've never had any contact with anyone at Mojang. As far as I know, they are completely unaware of MCPatcher's existence, or still think its only purpose is to hi-res enable packs on old versions of the game.
That isn't my site or my program posted there. It's some other utility with the same name.
9
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.
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.
Thanks, should be working now. It must have gotten mangled by one of the forum software upgrades. I don't get many donations, so I just never noticed.
20
Here's the current (Sep 2) status:
An important change for texture pack artists:
The old 0-15 values for block metadata are no longer meaningful in 1.8. So there's a need for a new syntax for applying CTM and custom colormaps to subblocks. The new syntax is based on the block info shown on the F3 screen. Instead of
use
For compatibility, these can be combined into:
1.7 and earlier will ignore the variant=oak part and 1.8 will ignore the metadata values. Both multiple properties:
and values
are supported. Integer properties also support ranges (0-3 is the same as 0,1,2,3).
Oh, and if you are still using numerical block IDs anywhere, please use this as an opportunity to switch to names, as the text parser can only do so much.
With that out of the way, pardon me while I vent for a bit.
Warning: Programmer's rant ahead:
This has been by far the most difficult and frustrating update to work with. Notch's code was messy but fairly straightforward once you understood a few basic classes. This new design is so twisted up in endless abstractions and theoretical wankery that I can barely follow it, let alone modify it with any confidence. The number of temporary objects that get allocated and immediately thrown away in the game's critical rendering path is appalling. You can see for yourself on the F3 screen; the Java memory usage is a meaningless blur while the game mercilessly flogs the garbage collector every second. I can't tell you how many times I unironically, reflexively facepalmed upon encountering some new bit of code for the first time.
Several times during this update cycle I've come close to throwing up my hands and walking away from the project altogether, and I still make no guarantees that I won't. I know many artists depend on MCPatcher's features, and I would feel awful if all their hard work and creativity went to waste, but my patience and motivation are really being stretched thin by Mojang's inability to provide a stable platform to build on.
3
6
Based on a brief look at the recent snapshots, Mojang is still playing with the model.json stuff, the most likely reason for MCPatcher incompatibilities past 14w11. And there's talk of extending the system to items, so any work I did updating to 14w21b probably would have ended up getting tossed anyway. (Frankly, Mojang's characteristic inability to realistically scope anything is exactly why they have yet to produce a proper API after four years. But I digress.)
Anyway the computer I use for development is in storage, so it will likely be a few weeks still before I can fully catch up. Luckily there should still be a couple months before 1.8 is officially released.
4
1
It's definitely working here. Are you sure you're running the patched version? It should be called 1.6.4-Forge9.11.1.965-mcpatcher.
An accidental feature it seems. Prior to 1.8, "crossed squares" blocks didn't have faces, so both parts always got the same texture. Now in tallgrass.json, they have n, s, e, w faces, so ctm assigns different random textures to them.
Just add this to each properties file to force all faces to use the same texture: