The red thing above red wool block in the topic's image seems does NOT seem to be a red mushroom.
In fact, it looks like... a ladybug!
Sweet!
EDIT: Danggit, it's just the Grum boss mob!
-
- Ouatcheur
- Registered Member
-
Member for 7 years, 6 months, and 22 days
Last active Wed, Oct, 30 2019 23:34:53
- 7 Followers
- 3,164 Total Posts
- 722 Thanks
-
May 2, 2013
Ouatcheur posted a message on Snapshot 13w18a Ready For Testing; 1.5.2 Now LivePosted in: NewsQuote from LynnNexus
Um...
There are skins for the two undead horses included in the snapshot but unused and they follow the same pattern as the released horses. It is not unreasonable to hope that not only the undead horses will be included from this information but that they may have horse related drops.
Or that since they imported a lot of the framework directly from Mo's Creatutre author, there was saome amount of coding magic cut n paste involved. Why take the time to remove an entire part with the risk of making the entire compiling of the coded module fall to it's knees, when you could just leave it like that and use a simple switch to avoid generating that part? This is just like in our real life bodies we have old genetic code in our DNA which has no usage anymore whatsoever, it's just there. *maybe* it will serve again one day. But it probably won't.
I think the undead horses "skins only" are exactly like that. They thought about adding the, chose otherwise, but did the logical thing: not waste programming time on fully removing it, after all ,who knows if it could serve one day, right? So they simply turned it off. Having worked as a coder, this is a very common coding practice. -
May 2, 2013
Ouatcheur posted a message on Snapshot 13w18a Ready For Testing; 1.5.2 Now LivePosted in: NewsQuote from TNT24X
Why can’t t Horses fight mobs.
Real Horses attack and bite things they don’t like and I happen to know that mules are used as guards for livestock, sheep farms use that to stop cougars and wild dogs.
I think it was Mojang chose deliberately, not something they forgot.
Horse stuff is by definition rarer: harder to find than normal animals, and uncraftable saddle & armor.
They are designed to be mounts, not guards.
Yes in real-life mules can serve as guard animals. BUT
1) That is usually not the case of horses.
2) since when does realism dictates what goes in Minecraft? Minecraft has definitely some realism (for example, the fact that you must eat some foodstuff to take care of your hunger, not eat pink bricks or something just as weird), but it also hads lots of unique and definitely non-realistic elements: eternal torche, infinite water, solid blocks that float without any kind of support, etc.
While realism can be a source of ideas, it definitely shoud not be THE source of ideas, and it is game design that should always take priority here, NOT realism. which leads me to:
3) Horses and donkeys are already more than powerful enough as they are without ALSO providing combat bonuses.
Anyway, if they fought while you were riding them, dang, you'd lose control over the horse and couldn't manage to do your own attacks yourself? That would be pretty bad. When you are on a horse, you're the one that should do all the fighting, not the horse.
And as guard animals, wolves being smaller are way more manoeuvrable and since animals don't need to eat unless it's for breeding (once per animal) or healing, it's not a big deal. In fact, a bigger pack means the hostile mob will probably die all much faster, meaning actually LESS healing to do afterwards (for those caring about that). With sufficiently big pack, you just forget about healing and just breed some more wolves every once in a while.
"But wolves avoid creepers..."
Yeah so would the horse too, or any other friendly mob designed to fight, except if it's a golem (stupid and single purpose minded by definition, and either a bit fragile and useless on it's own like a snow golem, or with enough hit points to withstand an explosion like an iron golem).
It's not what would be "realistic" that is important, it's what would be "logical'" and what is 'important", and making horses fight definitely wouldn'r be a logical thing to implement in Minecraft, and lots more things are way more important.Quote from LynnNexus
I really hope now that the saddles and armors aren't craftable that they will be a rare drop from the undead horses.
Note:
Mo's Creatures have Undead Horses.
While the new Minecraft horses come from Mo's Creatures collaborative work, they don't include undead horses.
There was already a Lapis Lazuli block been in the game for a long time. Unless you're trying to ask something else? -
May 2, 2013
Ouatcheur posted a message on Snapshot 13w18a Ready For Testing; 1.5.2 Now LivePosted in: NewsQuote from shiney_ninja
I thought 1.6 was going to be the "mob update" I've seen more blocks then mobs introduced
1.6 isn't finished yet. And yeah, if the only mob they add is horses, then their promise of "new mobs" will turn out to to be "new mob". Even of there are 10 kinds of horses, it's still only 1 type of mob. We need more variety! -
May 2, 2013
Ouatcheur posted a message on Snapshot 13w18a Ready For Testing; 1.5.2 Now LivePosted in: News
I guess the slimeball serves to kind of "hold" the lead's knot.
I'm fine with that recipe. -
Mar 20, 2013
Ouatcheur posted a message on Minecraft Realms: What Is It?Features that Minecraft Realms will need to become massively popular:Posted in: News
1- Capability for the host (i.e. the person paying for the service) to upload and download the world.
2- Mods support.
Without these, using WorldEdit (for example) or a mapper becomes impossible, and you're stuck with Vanilla.
3- Multiworlds support
Wether it is to connect your own worlds together, or connect your world to all others, having support for this through a standardized rules/access granting room interface would help a lot.
I'd find it crazy if for each world you pay the same. Some worlds are tiny, some huge, and having 2 connected worlds doesn't means you'll have twice as much players.
But I bet Realms will be popular even without these features. -
Jan 18, 2013
Ouatcheur posted a message on 13w03a Ready for TestingPosted in: NewsQuote from toatanu
Agreed. Nobody here (I hope) has a thing against caves, but most people with some sense have problems with the infinite spaghetti cave system (note the singular form) found in all Minecraft worlds, and the frequency of gigantic systems.
Hear, hear! I agree with you 200% -
Jan 18, 2013
Ouatcheur posted a message on 13w03a Ready for TestingPosted in: NewsQuote from RoboMat
"Creating a infinite water source no longer needs a block underneath, but has to have a water source block."
I personnally do not understand the actual meaning of that sentence!
Basically, in the sentence structure
"Doing A no longer needs B, but has to have C"
It should always be possible to split the sentence into 2 simpler ones.
Like in the following example:
"Bob is no longer a cop, but has children"
can be split into:
"Bob is no longer a cop"
and
"Bob has children",
which both make sense.
But when
"Creating an infinite water source no longer needs a block underneath, but has to have a water source block."
is split into
"Creating an infinite water source no longer needs a block underneath."
and
"Creating an infinite water source has to have a water source block."
The second sentence doesn't make any sense at all! It's bad syntax, plain and simple.
Just what thing exactly in the "Creating an infinite water source" thing, does the "has to have a water source block"?
Just what exactly "has to have" a water source block?
And how does it work exactly? And which water source block has to be had?
Does it mean that you have to provide a block of water source using a bucket? Or what?
Please explain a little bit better! -
Jan 11, 2013
Ouatcheur posted a message on Change Your Minecraft Name? Possibly In The Future>>> "Just ban the IP"Posted in: News
>>> Griefers would just change username and grief again!
Wow, brilliant ideas! I'm sarcastic here. All those who posted such should be banned from the forums forever lol. That'd raise the average IQ in here by a coupla points I guess lol.
If they'd taken the time to actually read more than the first page of posts, or just use Google or common sense, they'd of course have seen that:
The Ban IP idea for is stupid for so many reasons: a) Griefers can just use IP spoofers;
Or just cross the street from the Mcdonald to the public library or other public free wi-fi access; c) Innocent players could potentially get their account banned because of the actions of somebody else on the same LAN as them; d) Some countries use dynamic IP. Etc. In short, the idea that "1 user = 1 IP, always the same IP" is just plain stupid.
Griefers would just swap names: Gee, like somebody else said: Surely that is exactly what happens all the time in *ALL* those *_other_* games where players can change their user names! Of course not!
Thank god *most* posters provide real and valuable ideas and insights!
****** This is how I think changing the in game name could potentially be done :
Not by allowing X changes per month or interval, but by forcing a waiting period instead!
Procedure: Into his account, the player can make (or cancel) a request to change his "in game name" (ign). His profile will now show the remaining number of days before the requested new ign activates automatically (well, not while he's playing, or logged out, only at the moment that he actually logs into the game itself, AFTER the waiting period is over of course.
It doesn't have to be more complicated than that!
When the player connects to a multiplayer server, the server will get the list of names for his profile:
- unique uncheangeable account profile name identifier (always)
- current in game name (always), does not need to be unique.
- requested future name, if any
- last X recently used names, if any.
Each name in that short list has a "timestamp" for when it was used the first time.
Using that information, each server can make up its own rules as to how to let players login or not, how to ban, etc., and what kind of info is available to other players. - To post a comment, please login or register a new account.
0
NoooooooooooooooooooOOOOOOOOoooooooooooOOOOOOOOOoooooooooooooooo!
Me an my nephew we JUST reached Anvil (around Day 140).
Seems like we'll stop updating at R170, then. Sigh.
0
Avernite, my nephew made you a Fruit salad icon in Photoshop. Enjoy!
0
If we have a R170 Experimental Branch world, can we upgrade it to R172, or is it basically "Old Experimental branch is over, compatibility broken, start all over again with New Experimental branch?"
0
I deleted the entire content of folder, and it worked. Dunno what you did to fix it, or what was the exact problem, but thanks Avernite!
0
Weird bug in Multiplayer screen server list:
Since yesterday, whenever we start the game, me and my nephew get this on the Multiplayer screen:
(see attached image).
There are exactly 9 such "bad" servers listed, then the normal "added by hand" server list (those with an Edit instead of an Info button).
Setup: MITE R165 with all our Minecraft game and minecraft files in the normal respective C: paths for them.
I dug around a bit and found that something weird is happening in the /MITE/public_servers/ folder.
No matter if the public_servers.txt file exists, or whatever is in it, even if empty, the public_servers.txt file always get auto-created and auto-overwritten to this content:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://minecraft-is-too-easy.com/public_servers/public_servers.txt">here</a>.</p>
<hr>
<address>Apache Server at minecraft-is-too-easy.com Port 80</address>
</body></html>
For example, we had this instead for our private server:
server_address=***.***.***.***:25565|world_name=Alecazonia|start_date=Juin 2017|description=Ceci est notre serveur expérimental!/Des plaines et de la verdure qui/s'étendent à tout bout de champ et peuplées de morons/qui sont avec ou sans bottes couleur rouge jaunes oranges roses,/pis des cavernes à poulets qui se prennent pour des troglodytes viandeux pas à peu près!|website=Aucun, rien pantoute !|image_url=http://minecraft-is-too-easy.com/public_servers/Alecazonia.png|theme_color=F0E68C|backdrop_opacity=0.4
(in the above the IP values are actual numbers not ***)
Also tried putting image_url field directly to my local mage file, no behavior changed.
and also the 2nd attached image (which for some reason didn't get displayed as background image at all, but for some reason I hadn't got around to fix that properly yet).
I wonder what is doing that?
0
I agree. What happened to Avernite's R105's hope? Lol!
Putting out violin, starting funeral song?
0
Wait, wait, wait...
Is this the SAME experimental branch, or a NEW one? We have 3 versions now???
Confused.
0
Is there a way to make tool benches and furnaces have durability similar to anvils? it only makes sense to have them crumble and break eventually 👹
Why limit that logic only for those 2 types of block?
Logic, realism, and just making sense, dictate to go all the way with the idea!
Every furniture block!
- Beds, Brewing Stands, Enchant Tables, Chests, etc!
Every blocks that really it only makes sense that they'll wear out eventually!
- Pistons, Buttons, Levers, Doors, Ladders, Rails, Dispensers, Redstone Repeaters, etc!
Let's put those frakking super ugly "durability damage" anvil cracks on everything!
(clearly I am not a big fan of the idea lol)
Evil, Arma, you're EEEVVVIIILLL! lol! I'm putting worms inside your food chest! :-)
0
Phoenix, this specific exact way to die happened to me TOO MANY TIMES ALREADY.
That was spot on! Genius! Lol!
0
R170 Hidden Easter Eggs Super Experimental Branch:
- New block: Tumbleweeds. Randomly appear in NPC villages and randomly pushed along the wind (westward, same as the clouds).
- Players "hit" by Tumbleweed take 1 damage and some Knockback.
- Tumbleweed hit by lightning become Charged Tumbleweed.
- Players hit by Charged Tumbleweed are Knockbacked all the way back to Spawn and then take falling damage equal to the release number.
- To enable Easter Eggs Super Experimental branch features, just hit Up-Down-Left-Right-A-B-C-Start-Select on your joypad.
:-)
0
Nice tests results!
Were most of the blocks you tested "doing anything?", actually accessing their metadata? For example, to render a furnace, the block entity data (synonyms: tile entity data, metadata) is not really needed: the furnace and the lit furnaces are actually two completely different blocks and their direct block data is sufficient to fully render them. So yeah for those, the performance for such will be at, or relatively near, that of normal blocks. Because when they aren't burning anything, there is zero data manipulation going on with their metadata and only the chunk data is accessed.
Hoppers are similar: unless there is some redstone stuff going on, it's mostly inert. Enchant tables are similar. their GUI metadata isn't accessed unless a player is interacting with one, and there aren't magical letter particles unless there are bookcases nearby. Brewing Stands and Anvils are basically the same too. However, the common point of all of them is that unless some special activity is going on, the block entity data is not needed to render the actual block, only the block data.
I think I see now why Item Frames and Armor Stands drop the FPS so much more than the other tile entities: it's because they are NOT tile entities, but pure full-on entities instead! My bad, sorry, I shouldn't have put them in the same group as the other tile entities.
IMHO, a 25% FPS drop (from 20 FPS to 15 FPS) for having 10000 tile entities around, that could be acceptable for most players and servers.
But to compare Dual-Slabs performance, your closest safe bet would be to take your worst-case, the Brewing Stand, but test it with the stands all occupied brewing something (with if possible random intervals before each completion to avoid any spike). This would make the game access the Brewing Stand metadata for a quick tick-increase-and-check-completion for each of them, which is comparable to accessing Dual-Slab metadata for determining which type of material to use for the 2nd slab half that doesn't fit in the normal block data and need to be stored as block entity data. I really have zero idea if a tile entity that is busy doing something relatively simple counts a little more, or a lot more, than an inert one. While DualSlabs "look" inert, the constant need to go check what their other 2nd material is made of, would make of them "always on" block entities.
Alternatively, I *just* thought about this:
There are 4 bits of block data, meaning 16 possible combinations. There are currently 13 types of slabs materials (7 stones and 6 wooden). Let's leave room for say 3 more. We simply allocate 16 Block IDs to DualSlabs. The block ID determines the bottom half material. The block data then is used to determine one of 16 possible top-half material, and voilà, normal blocks! Thus full performance, all for a very reasonable number of block IDs "cost" !
But currently, all of the 256 available block IDs are already all taken up:
http://minecraft.gamepedia.com/Data_values#Block_IDs
However, it's still going to become possible to do it very soon, because Mojang has already started work on fully removing the 256 block IDs limit, even for the "in-house" blocks , giving the full 4096 block IDs range to the full game (instead of just for mods).
Well, anyway, thanks, that was very instructive!
0
Is that a deliberate but unlisted feature change, or an unwanted side-effect or something else?
0
So, if I understand correctly:
Each year:
- 8 days before each of the 3 blood moons, we have a yellow "harvest" moon.
- 8 days before the blue moon, we have a moon dog moon
Is that the "moon with a hazy circle halo ring" around it ? If not, what is that weird circled moon, then?
I thought the Moon Dog appeared ON the blue moon, not 8 days before???
Never actually heard or seen a moon dog, either. Maybe high-level, with mithril armor and a night-vision potion, one can try running around that night to try to find it.
I suppose you need to get 2 moon dogs to start breeding them, right ? Ouchie!
0
Go with the bit flag! Those "more intelligent and more permanent" zombies offer a completely different kind of challenge, after all.
It is a type of challenge that is a very annoying one when the player is merely tunneling, as suddenly he can't progress because of a single mob, but can't get rid of that mob because it's a permanent one AND it refuses to budge from where it is no matter what happens, and it won't even come after the player so he could simply whack it away!
But for a fixed-location village, where the player can go around it, and can decide to "attack" the village at his leisure, when he's ready, and with the living NPC Villagers already perceived as big funny morons anyway, then that mob behavior would work quite well!
Still, in addition to the bit flag, if you can find why they get stuck at a single block, that would be even better. Even when they have gone to "shelter" from light, they shouldn't stop trying to path to the player by moving along "shadowy/wet/rainy" areas tat they are allowed to be in. I think the problem lies in the pathing algorithm itself. "Village" Zombie Villagers should simply take the Club-Skeleton pathing (thus avoiding sunlight), without being stuck by blocks in the way, while "Non-Village" Zombie Villagers would use the classic zombie pathing (willing to burn to attack), again without being stuck by blocks in the way.
Also, the "avoid light" pathing itself (Club Skeletons) could be improved to let the mob "randomly" decide to jump out into the light, willing to take some damage, whenever the player is close enough that "suddenly" reaching out would mean there is a good chance that the player will be struck. Not always, just often enough to keep the player on it's toes ! Muhahaha! Basically a sudden switching between the "avoid light" pathing to the to "kill kill kill no matter what" pathing.
You're standing 10 lbocks away from a club skeleton under a lone tree. "Nee ner nee ner!", you say to him. then you process to cut down some other tree, feeling pretty confident the skeleton is "stuck" under it's tree. Suddenly, that skeleton decides it's had enough and, while you're not looking, comes rushing at you ! That could take into account distance to player, player's movement speed (not much point running after an already fleeing player), angle of vision of player (is he looking the other way? attack him in the back!), and the remaining mob hit points (I'm though enough to hurt him before the sun kills me?). it should not occur too rarely: no point adding a feature that most players will get to see only once or twice, . But not too often either: if most of the times a player can get away with standing near a "prisoner of sunlight"' mod, then thep layer will always be very surprised (and in trouble) when the mob decides otherwise. Muhahaha x 2 !
When a player starts whacking at a "prisoner of sunlight" mob, the pathing change should become much more common.
I never was a big fan of "super easy killing mobs from super safety". XPs should be deserved, and mobs feared. Not perceived as a wated source of candy lol so mobs should always try their very best to kill the player. I'd rather having less mobs, but each being much deadlier (and correspondingly requiring less XP to craft high quality, level up, or enchant) than having tons of mobs, but it's easy to kill them safely.
Inflating HP and DMG per ATK, that's seems very easy to do, but ultimately, it just means that the player has to whack a couple more times, still from a super safe spot. and 99% of mobs currently are killed from safety, not "real" battes. So doing that doesn't really add much challenge 99% of the time, just add some more mob-grind.
But giving improved AI, so that mobs don't look like morons, and surprise the player, that's quite hard to do!
Imagine if players had these capabilities (through hotkeys or whatever easy-to-apply input):
- Crawling: Player becomes prone (thus occupying only 1 block high and 2 blocks long instead of 2 tall and 1 wide). Player can cross horizontal 1x1 passages.
- Grabbing a cliff ledge, and either "Crawling" sideways along it (and even turn a corner), or slowly puling oneself up (thus, going up 2 blocks).
Then you define a set of penalties for when using a special movement, such as Boating, on a Ladder, Crawling or Hanging to a Ledge is occurring, for example:
-30% Player speed, -30% Crafting speed,
-66% Block breaking speed, -0.25 Block breaking Reach
-30% Attack Speed, -0.5 Attack Reach, Half Attack Damage
And then finally tweaking each special movement mode a little bit according to common sense. For example, using a ladder isn't THAT slow, but really ties up the hands (block breaking only 1/4 normal), while crawling usually means extra slow movement.
Now, imagine if a relatively common zombie variant (a super zombie?) (or any zombie during a blood moon) ALSO had all the same movement modes as the player. Including jumping diagonally over over holes. Including the fact that Sneaking lowers the reach and center of attack. Suddenly, no more whacking all night long super safely at zombies toes through a window while player is 2 blocks below. Especially on a Blood Moon. A few zombies WILL enter "Sneak" mode and thus manage to reach the player anyway (unless he's extra careful, which is the point - merely pushing against the wall and whacking away at the zombie above it would mean you're too near).
The thing is, the more dirty tricks the mob use (solitarily or collaboratively, imagine a creeper opening a way for zombies) then the less mobs are needed and the more jumpy the layers become when they see ONE monster.
Compare the 1979 Alien movie vs the 1986 Aliens movie vs StarShip troopers (1997). The first is pure horror. The second also has it's high fear moments, but a lot of it is also much more action-oriented. The third movie is mainly big action scenes. When you have a very low number of highly dangerous foes, the kind of adrenalin a player feels is more based on suspense and fear. You might die any second. You respect the threat. The foes exist to make your hair stand on your head, to keep you on your toes and stay vigilant, to be fled and to use you brain as much as possible in creative ways to level the paying field. Merely surviving by flight is a victory. Winning over one such enemy is an achievement in itself, cause for celebration. It's "Play as if you are in a war", avoiding useless battles that don,t achieve any real goal, and making sure that if you enter a battle, you have every advantage possible. In multiplayer, you cooperate to help your group survive and win.
However, when there is tons and tons of enemies that are dangerous but ca fall like flies, the kind of adrenalin a player feels is more of an action rush, and the "worry" you get is mainly "will I have enough ammo and health to last through that entire battle?". The foes themselves when seen as individuals, are reduced to mere speed bumps. Those foes exist only to be vanquished, and the only respect they get is in big numbers. It's "Play as if it is a sport", where you know you'll win anyway, it's just a matter of how well. In multiplayer, you compete with others in your group to see who got the most kills.
I think it's ultimately better to have very few very dangerous foes, than tons of "monster hunting / mob grinding".
Pure 100% Horror Stories usually have only a single unkillable monster. I'm not suggestion going to that extreme, but MITE would be wonderful with having "much more capable foes" that are less numerous but use cunning and dirty tactics, instead of upon waves upon waves of relatively easily dispatched (from almost total safety) quite stupid monsters.
0
I'm very curious about your test. How many actual tile entities were involved ? What's the setup? Desktop PC java version?
Check out from 2:00 to 2:12 --> "Dropping from 700 FPS down to only 30 FPS". That's with only 512 tile entities. Imagine what tens of thousands would do!
For that Youtube test, I'd have preferred it being done in a normal world (instead of in a "void" world), and at various client side sight ranges and various server size chunk load ranges. To see if the impact is more on the rendering size of things, and compare with the normal load of a normal world.
The video seems to show that the main performance hit is when the Tile entities actually come into view. I'd have also liked to compare Tile Entities performance hit in "in-sight" vs "out of sight but in loaded chunks" vs "completely unloaded / loading / unloading". Still, for the end user, it's the total FPS that really counts.
I agree item frames are definitely the worst offenders among the tile entities group, though, but still, check out the entire video if you want. But the other tiles entities, which are usually only at most 3 times "more CPU friendly" than Item Frames are, are still tons of times slower than normal blocks to process (with one exception).
A server typically loads 10 chunks radius around each player (160 blocks radius on the server side, even if player is set to Normal Sight Range on the client side). Assuming only the underground + ground sections have non-Air blocks, that's still 21x21 x 5 x 16x16x16 = 9 millions blocks loaded around each player. Not all are actually rendered, though, but they all get data-manipulated in the loaded chunks. Servers that up the distance to the full 16 chunks (to allow full "Extreme Sight Range") will increase that amount of loaded-chunks blocks to a whopping 23 millions blocks per player (assuming no two players are at the same place of course), but at a corresponding performance drop (approx 60% drop, basically 2.5 times more data means about 2.5 slower too - Yeah it's pretty linear for that).
That still doesn't compare that to having a mere 10 000 Tile Entities (when compared to those millions and millions of normal blocks) around and suddenly seeing the FPS go down the drain like a space rocket going full thrust downwards a bottomless pit.
Thus, Tile Entities are ok for "special"' blocks, but not ok for building blocks. For example we can easily see everybody on a server building a ton of nice houses for their "Spawn City" and suddenly jumping on the fact that they can now use only 1 block of thickness between the floors of their builds, yay! Placing up tens of thousands of these dual-slabs blocks in the process. Placing tile entities instead of simple blocks. Massively. Ho-ho.
In the video, there is one exception, for some weird reason, Anvils require a lot more of them around to "successfully" drop the FPS seriously. Still, each Anvil counts a lot more than a normal block, as you get a severe performance drop with "only" 16536 Anvils. But even if dual-slabs were somehow made to be some special Anvil Variant (somehow), Anvils aren't placed around in the thousands and thousands while building block such as dual slabs would definitely be, so yeah, lag would show up. A lot. Not on Day 1 of the server. But once Spawn City is built, yeah sure. A lot.
I agree that some people tend to greatly underestimate the strengths of computers.
But some people also tend to greatly overestimate the strength of computers, too, and that happens just as much at the first group.
That's just simple human nature.
I personally stand more or less on the fence. Despite 20 years of programming, for some stuff I still overestimate, while for other stuff I still underestimate. But I generally am good at calculating how much an an impact a code change might imply, even before the actual performance testers do their job. I eventually left programming because of the constant stress, not because I wasn't good at it lol.
Also, keep in mind, "called-a-lot" code in any game/program is the 1st part of the code to get optimization efforts put on it, and there comes a point of diminishing returns. In other words: those parts of the code of the Minecraft game, which has existed for years, are pretty well oiled already (unless you think Mojang staff have been complete morons for years - I sure don't). Maybe its not 100% perfect code, but it still surely is already much closer to the "max theoretical performance" than "low performance code".
You can take Fat Albert (newly drafted semi-junk code) and train him (optimize and tighten and clean up the code) to drastically increase his sprinting running performance, shaping him up a lot in the process. You can also take Usain Bolt (central core code that's been around for years and that has already been optimized a lot), and try to give him a special training (at this point, there is room only to either tweak something in the code, else you need to start over with completely different assumptions for everything, such as minimum hardware, etc. - basically not trying to improve your Usain Bolt anymore), but you'll end up probably improving his performance only by a fraction of a percent, at best. You might even make things worse than before.
Well, program code works a lot like that. Maybe "it's always possible to improve", but that doesn't mean each new improvement will be big. Au contraire. The first round of optimization is like reaching for the multiple big juicy and sugary red apples that are straight in your face on the lowest branch of the tree. The last round of optimization is more like reaching for the lone last apple in the tree, still tiny and green, and on the topmost flimsy branch at the very top of the super tall tree. And that not sweet at all too bitter apple has a couple worms in it, too. So, unless doing something radical, most of the time it's the opposite, past the few initial optimization cycles, applying more efforts to the same code usually just ends up wasting resources.
I've done enough "optimization work" on enough programs in my life to know that, once you "already cleaned up and fixed and optimized the code of the first "must send to the client ASAP" draft, even once, then most of the potential performance gains have been already been obtained. Clients are always happy to get their program ASAP. They are also happy when version 2 comes much speedier than version 1. And version 3 speedier than version 2. But around version 4 or 5, if it runs well enough, then they want more features, not more performance. So you rush the initial delivery, then cleanup and optimization comes later, but you are in no hurry to do all of it in version 2. Get paid three times to and make the client smile three times, instead of doing it right the first time, but have angry clients that complain of long delays and no boost in performance. Argh! Glad to have left all that behind me lol.
Anyway, then the next guy behind you does the same kind of work, but suddenly doesn't magically find a new way to make the code run another 8 times faster, like you did for version 2. In fact, the company already knows about the 8 fold performance increase in version 2 increase and limited the boost to only 2 times, so tha it's be easy to get more two-fold increase in versions 3 and 4. But no such luck in versions 5 and 6, the 5th and 6th guy in line will probably end up just saying "Any additionnal change we make now, can allow us to increase that thing you want by say 3%, but at the cost of losing 15% on everything else. Nothing is wrong with the code now, it works very well already, so let's not try to fix something that's not broken."
Personally, the only real valid future solution I can see for Dual-Slabs is upgrading the Chunk format a little bit:
http://minecraft.gamepedia.com/Chunk_format#NBT_structure
Per block:
ID [8 bits]
Add (basically extending available block IDs from 256 to 4096 possible values for mods/modders) [4 bits]
Data [4 bits] <-- Here is what is so limiting!
BlockLight [4 bits]
SkyLight [4 bits]
TOTAL = currently 24 bits per block cell.
I'd simply go to a 32 bits block cell size, making the Data field have 12 bits instead of 4.
A Dual-Slab would then have enough data bits to specify both the bottom and top half material types directly, as a simple straight up block, avoiding the Tile Entity issue entirely. In addition to making it very simple to add tons of other new types or variants of blocks quite efficiently.
Plus, perfectly lining up the data cell size to 32 bits instead of 24 would allow speedup RAM and cache access even more. A bit less bit fields manipulation.
However, going from 24 to 32 bits per XYZ block cell would increase the required RAM (and the CPU handling of that RAM by 33% (32 is 8 over 24, thus 33% more than 24). Yeah a 33% performance impact would be be VERY noticeable, and the added possibilities would go way beyond mere dual slabs., but still a lot of players would be very angry that their FPS suddenly drops by 33%. But after a while it would calm down. But going straight to 64 bits per data cell, however, the code and the hardware base just aren't ready for that yet. Multi-Core Minecraft with new top of the line 4.5GHz Octo-Core 16GB RAM and 1 TB PCIx4 M2 SDD PCs? Yes. Chaching! Single-core current version of Java MC with already in use PCs in homes? Unfortunately no reasonable hope there.
Saying "there is always a way to do it!" is a little bit too optimistic for my tastes. Showing how is much more realistic. One could say I'm a pessimist, but a real pessimist again says no it's impossible without showing why he says that, while I detailed at length. The more I analyze the way the code works, the more what I see is "Realistically speaking, there is a performance wall, right there, based on those data structures ad the way they are handled, and it's not a bad way, too. It's even brilliant, in some aspects. And that guy comes shooting nerf-balls at that wall. what I see is that the balls just won't go through, no matter the firing angles are."
So, yeah, I'm very curious to see your test!