Unless they fix the ghastly nightmare that has become the rendering engine, I highly doubt the more content-heavy mods will move beyond 1.7 any time soon.
It's been a peeve/issue for me for about 15 years now, maybe more. And that's strictly "hobby" level of learning for me.@keybounce you are officially a color nerd. I actually DID understand that all, but holy crap.
We have yet to see a multiple vanilla version freeze for mods. I have a feeling 1.9 will drag enough people that 1.7 will die just like 1.2 > 1.4 and to a lesser degree 1.4 > 1.6. Maybe it will be 1.10 instead and we'll set a new record!
I say 1.7 is the best bet if we're going to stay on a version. I also think that instead of sitting there passively Forge should be completely refactoring MC codeI'd have been fine staying on 1.6.4 long-term to be honest. 1.7.2 started cramming in shaders that have never really been used for anything, and then Twitch support in 1.7.4 which is almost equally worthless to most people (even streamers), all of which required more complexity in the render pipeline. The vector pool was removed along the way which meant even more objects for the garbage collector to clean up. The networking change wasn't that drastic of an improvement since the old one was obviously still plenty versatile. The climate zones of the terrain gen have left the core game broken since you sometimes can't find a biome that you need without traveling thousands of blocks. The new biomes aren't really anything spectacular. The only thing I enjoy is not dealing with item and block IDs, but at the same time, not being able to use those internally is sometimes a pain, and the overcomplicated system that's come out of this has led to a lot of people ending up with mixed up blocks and screwed up worlds when adding/removing certain mods.
Then you have 1.8, where regardless of the Forge disaster you still have mobs that float around when hit, a complete rework of the engine to use blockstates and blockpos everywhere even when it's unnecessary complexity (making extra calls just to get the block or a coordinate), a rendering pipeline so convoluted that any benefits gained from generating models at load time are likely lost in the abstraction, hundreds of objects created and thrown into the wind from every direction for the GC, and a model system so poorly implemented where, for example, it can't have both a parent model and additional elements, because I guess that would make too much sense.
I like Mojang, but I don't know what happened to them. 1.6.4 is the last version that appears to be untouched by the madness of corporate deals and bloat.
I say 1.7 is the best bet if we're going to stay on a version. I also think that instead of sitting there passively Forge should be completely refactoring MC code
Pretty much my exact thoughtsYeah it's too late for 1.6.4. And I don't mean to make 1.7 sound terrible, just that it has its share of issues. But it still has a render engine that doesn't make you want to pull your hair out, so there's always that.
Yes please good sir take all my yes if you would please.I actually thought about requiring the player to use Sync to go between the nether and the overworld, playing by themselves to help themselves and win all by themselves. That would be my solution to singleplayer.
. .... Oh .-.Pretty sure that picture was in response to the spoiler immediately after it, not your post.
I bet they'll be really fast and have super durability but they won't drop blocks.What's this? Unstable Tinker's Construct tools? O.O
What's this? Unstable Tinker's Construct tools? O.O
Seriously agree on this one. Really difficult to have all my favorite dimension mods and BoP at once, run out of Biome IDs, so it's a case of working out which dimension biomes are allowed to spawn in overworld. Considering only a fraction of the biomes use the X+128 alternatives, this is a big waste.164 versus 1710?
New X+128 system? ... Geez, cut the biome space in half? You couldn't make biomes a 12 bit, or 16 bit number, just like you added 4 bits to block ID?
Fair warning. This (connecting RF machines to GT-EU infrastructure) is a bit of a beta from Blood Asp. GTeu->RF seems to work flawlessly (that's a GT cable) but I had less success with RF->GTEU during testing.