Me an my nephew we JUST reached Anvil (around Day 140).
Seems like we'll stop updating at R170, then. Sigh.
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?"
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">
<p>The document has moved <a href="https://minecraft-is-too-easy.com/public_servers/public_servers.txt">here</a>.</p>
<address>Apache Server at minecraft-is-too-easy.com Port 80</address>
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?
I agree. What happened to Avernite's R105's hope? Lol!
MITE 1.6.4 R105 is now available. This update reorganizes the mod and is not compatible with earlier releases. This is the first and hopefully the last time backwards compatibility will be broken.
Putting out violin, starting funeral song?
MITE 1.6.4 R172 has been completed. This will be a funded release (30 CAD).
- Experimental branch release (not compatible with previously generated worlds)
- Removed void particles
- Added two new kinds of permanent blocks: Mantle and Core
- Mantle blocks are found at the bottom of the Underworld
- Core blocks are found at the bottom of the Nether
- The bottom half of the Underworld now contains large, irregularly shaped plates of bedrock
- Worms will eat plant material and most food items when placed together with them in a chest (detailed information can be found in reference/item_composting.txt)
Wait, wait, wait...
Is this the SAME experimental branch, or a NEW one? We have 3 versions now???
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 👹
An unintended side effect by the sounds of it.
MITE 1.6.4 R170 is now available.
- Experimental branch release (compatible with R169)
- Fixed bug that sometimes caused player to appear in solid blocks when teleporting to world spawn via portal
- Removed code that was preventing zombie villagers from despawning
- All villages are now generated without villagers
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:
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!
So I just downloaded and started playing R169 and I can't help noticing that where before I was able to walk up to the zombies that had dropped into my trap just above my head and kill them with ease, I am now experiencing the unpleasant sensation of having them stomp me, apparently on top of my head.
I'm level 35 and wearing full iron armor so I can handle it (save for the wasted nuggets repairing my dented helmet!)
Can't say that anyone at level 4 and below and not wearing any armor is going to enjoy it much! Looks like you now have to locate yourself 1 block below their feet, or possibly 1/2 a block if you put down a slab near your mob drop point.
Updated the Mite Date Tool Spreadsheet to now highlight the upcoming Moon Dog Full Moon. This Full Moon occurs 8 days before each Blue Moon and it is alleged that if you go out on that night you can spot/find a Moon Dog.
Don't know what he looks like.... Don't know if you can tame them.... Don't know how you are supposed to wander around looking for him at night.....without getting killed.....
Download the Mite Date Tool Here.
All the optional files for MITE are located on this forum page.
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.
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:
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!
Quote from LynnNexus
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.
Quote 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.
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.
Quote from KooalaBear123
Coal block, redstone block.... Lapis Lazuli block?
Quote from shiney_ninja
I thought 1.6 was going to be the "mob update" I've seen more blocks then mobs introduced
Quote 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.
Quote from RoboMat
"Creating a infinite water source no longer needs a block underneath, but has to have a water source block."