This is also true, and also why I want it to be a relatively unopinionated base engine. Unfortunately technical advancements came alongside opinionated content. 1.8 brought creative mode and fast/tintable skylight updates - and hunger and very griefy endermen and a bucnh of worldgen structures. 1.0 brought itemstack NBT - to support enchantments and potions - and gave a sandbox game an official end. 1.3 brought client/server unification allowing singleplayer commands, open to LAN, greater mod compatibility, latency in singleplayer (maybe not actually good) - and villagers and villager trading and emeralds. 1.4 brought command blocks - and local difficulty and armoured mobs and withers. 1.5 brought analog redstone - and hoppers. I think 1.7 was only upsides though - texture atlasing and a new less-broken terrain pattern. That's where I stopped.
All of those things seem like upsides to me!
And for what it's worth, I think I've visited The End once? What makes it a sandbox is that you can play however you want - let The End be your goal, if you'd like, or just mine and build big castles, or mess around in Creative mode. That's the brilliance of it.
When you're engaging in game design, you usually want to make a coherent sandbox. If the best way to produce electricity in your electricity mod is to enslave an army of witches to throw healing potions at each other, it's probably not your design intention. You probably wanted it to involve digging for coal, or solar panels.
In current Minecraft a lot of resources are renewable via villager trading. The best way to get many resources is to enslave some villagers and find a trading loop that nets a profit in emeralds on each cycle, then spend some of that profit on the thing you want. If you want the player to dig up coal to make electricity, they can make a trading hall or a wither skeleton farm instead. If you want the player to dig up iron to expand their factory they'll make an iron golem farm which produces it at a high rate for free. The section of the design space that you wanted to access is blocked off by the mechanics of the base game.
Or maybe they just wanted to mix fantasy and tech?
Or maybe it wasn't intentional, but emergent... sort of like, you know, playing in a sandbox?
Villager trading is another new(ish) mechanic I don't partake in. I know others who don't either. I don't think we're playing the game wrong.
And if a mod/pack developer doesn't want players to use vanilla mechanics, they can disable those, as many, many developers do.
It's not that simple in practice.
What isn't? Disabling Vanilla mechanics? Specifically which of those you mentioned aren't easily disabled with a data pack or simple mod?
One reason is that all the other mods you wanted to use were redesigned to match the vanilla mechanics, so even if you use another mod to disable the vanilla mechanics, you're still suffering their consequences. They may even be redesigned in ways that require the vanilla mechanics.
You can't just remove the fields for a mob's armour items because all the mods that interact with mobs are checking what armour they have, and you'll get a runtime linking error. Best you can do is remove the code that spawns mobs with random armour so they always spawn without armour. There may still be armoured mobs spawned by mods.
In automation mods there was a concept called "sided inventory" where a machine block presents a different part of its inventory depending on which side of the block you access it from. When hoppers were added to the base game, they copied this exactly, but changed which sides accessed which part of which blocks to make them compatible with hoppers, because hoppers can only take items out of the bottom and put items into the top and sides. This affected all automation mods which, instead of using a more intuitive side mapping, use a mapping that makes sense for hoppers. Also, all other mods that add machine blocks now specify side mappings that make sense for hoppers.
Of course in principle you can rewrite the game and all your mods from scratch to match whatever vision you have, but I hope it's obvious that nobody would actually do that.
Even removing a single block or item is nontrivial. You can't remove the field because you'll get runtime linking errors from mods. You can't make it null. Even mods that don't rely on that item may be checking if a player is using it for some feature (and you'd like that check to always be false). There's a good chance many of the mods you want use it in recipes because it's available. Best you can do is remove the ways to obtain/create the item, and add a bunch of recipe overrides so it's not used in recipes either. If you have the mod that shows you a list of every item in the game, it'll still show up there.
I do remember your microblocks mod.
Yeah, 1.7.10 is many modders' favorite, I know. If you did stop at 1.7.10, I guess you know about the GTNH people's crazy work in keeping that version running? For a while, you could 1.7.10 with a newer version of Java than the current latest version.
Yes and it is currently running on my computer and logged into a public server.