All users will need to merge their Minecraft Forum account with a new or existing Twitch account starting October 23rd. You can merge your accounts by clicking here. Have questions? Learn more here.
  • 1

    posted a message on Minecraft Is Too Easy (MITE) Mod

    Dang, those blue phase spiders sure are bad -- cubed !

    Sure they are rare, but meeting them is more akin to guaranteed death than anything else. I met phase spiders twice, total. Died twice, too. Despite level 15 and reasonable armor.

    EVEN when the player is *perfectly* lined up with their path of attack, odds are good that they will teleport away instantly and thus the player will simply miss his own counterattack. Combined with needing to hit them several times, those guys simply become extremely dangerous!

    Would it be possible for their teleportation to take at least a fraction of a second to occur, instead of "instantly after they bite"? Like the spider mob flashes to indicate that it's going to teleport away, so you still get a small window of attack or something. Otherwise, it feels a bit similar to back when Silverfishes gave zero warning and just popped out of stone in order to attack the player instantly, which ended up being automatic damage to the player without capacity to counter in any way. IMHO, there should always be some kind of tactic that the player can use to face off every challenge, instead of "nothing you can do but take lots of damage or even just die".

    It's not as if there was some magic or tool that the player could equip that prevented their teleportation or something to turn these encounters more into a "challenge, find the proper way to fight those guys" rather than a straight punitive "there is next to nothing you can do but spam-click the sword and rely on luck" in order to beat these encounters.

    A teleporting mob means there is absolutely zero defense that the player can use, as they can just ignore all solid blocks. If the player ALSO can't attack them, except by relying on pure luck, then that mob is just a bad one.

    Please improve them somehow, for they still look (and are) kinda cool.

    Posted in: Minecraft Mods
  • 1

    posted a message on Minecraft 1.12 Update Opinion Thread

    Colors changes: all minor changes to me.

    New blocks: yay, always like having more decorative choices.

    Gameplay ergonomics: SIMPLY even more HORRIBLE than what they already were.

    The combat is more "balanced", true, but it simply not very simple & fun anymore. Basically, you have to constantly fall back when in battle. For a combat based game, ok, but for a mining & building game, it just detracts from the enjoyment. I'd have gone with slowing down a LOT the "swiping and then pulling back" movements for striking with sword or tools. Not having such a ridiculous "timer".

    But even worse are the boats. Instead of "being in control" and just targeting where YOU want to go, you have to actively "paddle" left and right. This would be similar to say playing say a puzzle game where instead of simply clicking the part of the screen with the item you want, you,d have to use arrow keys to slowly move the mouse to the item. Or an RPG where you have to alternate left and right to make your character walk. It is just very unwieldy, It just makes boats VERY imprecise to use, and the player,s attention moves away from "just being able to enjoy the scenery" and towards" click festival micromanagement.

    Carpal tunnel syndrome simply won the game. It seems Mojang doesn,t have an ergonomic gameplay user interface designer in there.

    I stopped playing the more recent versions because of this.

    Another example of bad User interface design:

    Vanilla: must double-tap then hold forward to sprint. Automatically stopping sprinting when you pass too close to anything or even sneeze.

    After only a couple hours playing, I usually get severe carpal tunnel syndrome pains in my wrist joint.

    MITE Minecraft Is Too Easy: sprint key is a TOGGLE. You want to sprint? You sprint. You want to walk? You walk. Simple enough. Must less strain in the

    Needing to micromanage EVERY movement your character must make = SIMULATION = BAD

    Simpler "Higher level" controls where the UI uses ther bare minimum to *GET" the *intention* of the player, and then works with that = GOOD.

    As another example, let's compare Parasite Eve controls vs Spiro the dragon controls:

    PE: left = rotate left, right = rotate right, forward = move forward. Can't move while turning. Can't move while shooting.

    Very annoying and the UI is always getting "in the way" of what thep layer actually really wants to do. Sudden camera switch and Eve is now near top of screen and you want to turn to shoot at a monster on the left orf the screen? Gah, remember then to press to the right to shoot towards the left of screen then !

    Spyro: just just pick a direction and the game will make thel ittle dragon brake, accelerate, turn, breath fire, whatever, and all at once, in order to reach the desired and specificed vector of action.

    Super simple even a 5 years old gets it intuitively, players's brain is 100% on the game itself, not on the interface.

    UI should be as simplified and unobstructive as possible, almost "invisible".

    Posted in: Recent Updates and Snapshots
  • 1

    posted a message on Minecraft Is Too Easy (MITE) Mod

    Thanks for fixing the server.

    But with zero animals around, starting can be a nightmare.

    A few ideas:

    - Current Day displayed along with the hour in the server selection screen.

    Because I logged in the morning but.. right during the storm day, right before a blood moon ! Can you say OUCH ?

    - Whenever a new player logs in for the first time, he enters not directly in the game, but in a kind of "waiting room" screen that is similar to the "death screen", but no red tint (or any other tint color for that matter). The player can wait there as long as he wants before actually logging in and starting playing. Player can turn the camera around, but not actually move (or even see himself). Basically, each player can be sure to start playing at a "right" time. Day 1 can be way too horrible otherwise. And it's way less boring to be able to look around a bit, than waiting for 6AM to come in the server select screen.

    - Whenever a new player actually start playing in the world for the first time (not the "waiting room" but actual play), but it is not the first player ever in that world, then a few animals will always immediately spawn near spawn, and maybe also a reasonable amount of tall grass will try to "grow back", no matter what time it is. Otherwise it's zero string + zero sinew = making the experimental branch TOO though to even be able to start properly!

    - Alternatively, if there are not enough animals around spawn anymore, then start player with a single Wooden Bowl.

    Posted in: Minecraft Mods
  • 5

    posted a message on Ambient Mobs

    For performance reasons, bugs should be rendered as mere tiny particles, not 3D models, and visible only when relatively close enough (same range as for seeing dropped items). They should be so tiny as to be just "generic bugs", not distinctive multi-pixels textures for all kinds of bugs from mosquitoes to bumblebees etc. Personally i have not much interest in adding such bugs. Birds and fishes seem much more interesting.

    Fireflies however seem very cool, but they pose another layer of complexity because they'd radiate light.

    They probably should work like this:

    - One pure-Air block becomes the "center", and that it the block emitting light.

    - The fireflies, maybe looking like yellow-white XP orbs, would roam about randomly in the 3x3x3 area that is centered on the light emitting central air block. The fireflies particles themselves just look bright, but don't actually radiate light. Sometimes the particles might roam a tiny bit further, but will quickly come back within the 3x3x3 area.

    - More rarely, the "lighted up center" block will move 1 block to another adjacent air block, and never more than 3 blocks away from the ground.

    - They could be slightly attracted to torches, tending to have their center stick right adjacent to a torch.

    - They disappear come morning.

    This would allow only a few simple particles to move reasonably without constant and numerous light levels updates.

    Posted in: Suggestions
  • 1

    posted a message on Minecraft Is Too Easy (MITE) Mod

    -How far apart do crops have to be to keep from getting blight? Is it the same for all crops? Even my precious pumpkins?

    Pumpkins are immune to blight so you can plant them as compact as you like, just make sure each stem has it's own '+' shaped area for where it's fruit will land, without overlapping, because the stem has chances to die at each attempt to grow the fruit: Planting in nice rows with 1 stem every 2 blocks would mean each stem has on average only 3/4 the normal odds of actually growing while the stems still die at the same rate. In other words, you'd lose 1/4.

    Blight has been changed a lot:

    - Blight has been reduced in both odds of "catching" and odds of "spreading" (about half of what it was before, I think);

    - Crops that are planted in a line grow faster;

    - Blight is not specific to each crop type anymore, and can spread to, and from, all types of crops (but still only wheat and the 3 veggies);

    - Crops remain blighted only a short time before actually dying;

    - Blood Moons will cause super-mega-blight, ruining almost your entire field.

    Basically, you should plant crops in rows, but put not make each row touch each other row. Yes, you will get SOME Blight, but it will remain a reasonable amount.

    Since the growth rate also gets the standard vanilla bonus for amount of "being surrounded by farmland", the ideal "farmlands" are like this:

    - Early farms: WHEAT: 3 wide and very long non-manured farmland field, plant only in the middle row. The other rows remain empty. If you are" super" early, and thus don't have lots of metal, you can convert only the central row to farmland at first, but your wheat will grow half as fast. Most important, check your farm often. FIRST FEW VEGGIES: 3 wide and very long, single row, same as wheat, but plant veggies completely isolated from each other (i.e. surrounded by empty farmland). Plant right after a blood moon and MANURE only the spots with the veggies. If you are right after a blood moon and the next special moon is a blue moon, or you are starting to have LOTS of veggies, then you can plant like wheat, in complete rows.

    - Later big farms: Find a nice really big and very shallow lake (only 1 deep ideally). Put down stripes of farmland fields: each 7 wide, as long as you can, with only 1 line of water in between each stripe. Put wooden slabs ABOVE the water, and around he stripes. Each stripe is good for 3 rows of wheat or veggies.

    -Does anyone have tips for a good mushroom farm?

    Brown mushrooms are easy: anywhere in any underground tunnels and caves. They grow even better than in vanilla for some reason.

    Red mushrooms need a lot more work but typically you'd need to have access to a forest or swamp biome.

    - Early red shrooms farm: plant 1 or 2 red shroom under each tree, always to the same '"side" of the trunk, let's say "north" or "away from shelter". You simply don't harvest those. When trees are in a compact bunch, you plant only 1, and when tres are more widely separated, you plant 2, on opposite sides of the trunk.

    - Later shrooms farm: terraform flatten a wide area. Plant trees every 5 blocks, keeping only normal trees and cutting down again giant trees (and their extraneous leaves) and replant sapling until you get a nice canopy. Plant 2 red shrooms under each tree on both sides of the trunk.

    If there aren't a lot of trees around, you'd have to get more creative. For example, build a huge roof of snow blocks with a hole every 4 blocks and a Leaves block placed in the hole. The important thing to know is that red shrooms will grow only in a very small range of light levels.

    -How big should chicken farms be these days? anything I should be on the look out for, other than making a glass ceiling?

    Well, I have a tiny chicken farm with 10 chickens in it and it already provides lots of eggs, but bigger is better. I all depends on what kind of food you want. A 20x20 farm sure is more than big enough to give enough eggs for 1 player to stop worrying about food.

    But with chickens the real trick is to start SUPER TINY AND SUPER EARLY and then expand later.

    - Securing chickens: find a spot with flowing water. You'll need to use blocks to be able to be able to turn on/off the water flow, then you dig a 2 deep hole, push a chicken in there, then put a slab on top of the chicken, then let the water flow above that. During blood moons, zombie go aggro even against chickens, so that water flow makes sure they won't dig to the chicken. The chicken WILL get sick, but that is easily fixed: just let it out and feed it enough seeds and water bowls.

    - Primitive "only until the next blood moon" chicken farm: place 4 slabs on ground 1 block apart from each other. Dig 2 deep the 5x5 area under the slabs. Plant a couple Tall Grass (obtained by breaking Grass blocks that are right Tall Grass) in order to speed up grass propagation. Add chickens.

    - Pre-pickaxe early chicken farm: Away from trees (because wood spiders). Find a tiny 2-deep pond. Put rows of slabs at ground level every 2 blocks to prevent spiders from getting in. If you're low on wood, pillar up gravel to be able to put slabs every 2 blocks instead (each slab completely floating isolated from the other slabs), that will double up as your gravel grinding. Square off the pond and use the dirt to make the center of the pond only 1 deep and fill up the rest in order to give the chickens some flat area on which grass will grow for them to feed. 6+ blocks away from the pond, fence it all off (square shape) and put enough torches around. Add 2+ chickens. Later, you can expand if you wish but remember always fence or wall off 6 blocks away from the animals enclosures, otherwise zombies will eat all your animals at next blood moon.

    -Do buckets place source blocks now, or are they still temporary flows? Is there another way to manage source blocks?

    Control + Right-click a Water or Lava Bucket + 100 XPs = place water/lava source block. Not sure but I think you must target a pure-air block.

    Otherwise the liquid flow is temporary. WAY simpler than before.

    Earlier I suggested two things:

    - This 100 XPs kind of thing turned into a bucket enchantment, because because able to place sources anywhere and anyway you want is a huge bonus.

    - Water spreading naturally if there are 3 sources blocks at the same level, even diagonally. Would allow Castle Moats and Water Roads, but always starting from existing water, without needing bajillions XPs.

    But that is only dreaming :-)

    -Is a swamp, once the trees are cleared out to cut down on wood spiders, a good biome for farming? Is there a better one? or do biomes not make a big difference in crop growth now?

    Biomes definitely make a big difference.

    Things grow super slow in Cold biomes.

    The wetter a biome is, the more blight it has, too, but that is much more secondary since blight was cut down during the moonth, but is beyind extreme at blood moon, so time to grow, and thus biome temperature, really is the only factor you should look at.

    - Very Cold: Taiga, Icy Plains,

    - Cold: Extreme Hills, and near Rivers, Ocean (including shores).

    - Temperate: Plains, Forests.

    - Hot: Swamps, Jungles.

    - Very Hot: Deserts.

    Swamps are an early farming nightmare for one very simple reason: Slimes ! These guys will destroy tons and tons of your crops. Basically, you're forced to properly wall off everything. Early on, that is a massive investment in resources, right at a time when you don't have many blocks or food or good tools to work with.

    IMHO the best biome for growing crops is desert. Hot = fast crops growth (not pumpkins though), and Dry = less blight. However, it can be lots of work to "import" all the needed dirt from elsewhere. However, desert lakes are often "perfectly" shallow, only 1 deep, so it's easier to make stripes of irrigated farmland. Bonus: it doesn't rain in deserts - rain is so annoying. Not much wood around, but you can use cactus to make "external walls".

    However, desert is more for when you set yourself up properly at a final spot (ideally, you take possession of an NPC village and wall it off), than for an early farm.

    So Plains is probably the best biome to start farming early. Tons of seeds around in order to grow wheat very easily.

    Posted in: Minecraft Mods
  • 1

    posted a message on Minecraft Is Too Easy (MITE) Mod

    I found an Endurance II magic book.

    What does that effect do ???


    Ok found it:

    - Added new torso armor enchantment: Endurance (20% hunger cost reduction per level for harvesting, block placing, attacking, throwing, tilling earth, and drawing bows)

    Basically, "hunger from doing any actual work" by opposition to "hunger from merely moving around" or "hunger from basal metabolism", right?

    Posted in: Minecraft Mods
  • 1

    posted a message on Minecraft Is Too Easy (MITE) Mod

    Avernite, the following UI improvement would be very simple to add and yet greatly appreciated:

    Whenever in-hand item slot gets emptied for any reason whatsoever (tool broke, ate last food item in stack, quaffed potion, thrown last snowball, placed last block in stack, etc.), then items cannot be picked up in that slot until the earliest of the following 2 conditions:

    #1 - Player switches to another "currently in hand hotbar item slot";

    #2 - The end of the "player can right-click to replace in-hand stack with similar item stack" delay timer is reached (even if player doesn't have any replacement stack available).

    This would be in addition to the normal "can't immediately pick up recently dropped items" rule.

    EXCEPTION: if the item is of the same type as what was in the slot, then it is immediately picked up (it is, after all, a "replacement stack" for that slot, so no need to wait in that specific case.)

    Also, a just picked-up item couldn't immediately be placed back in the environment. The delay would be the same as the delay for being unable to pick up a "just dropped" item.

    This would prevent placing blocks by mistake while the player is actually trying to do something else!

    For example, you just reached the iron age and you're trying to right-click on a horse to try to tame it and you happen to pick up a golden apple or a bow or an iron block that a friend is throwing at you at the same time, and instead of climbing the horse, you end up wasting the golden apple or shooting the horse or placing the iron block instead.

    Ok, that example is very, very rare and unlucky. What occurs all the time however is placing back a wooden log block that you just broke with the last durability of your Flint Axe, while you were trying to replace your Flint Axe with another one that you were carrying in inventory.


    Posted in: Minecraft Mods
  • 3

    posted a message on Little stone

    While I think having big-as-stone-button little individual cobblestones around could look nice, I think your approach, putting lots of them everywhere, would just make the world look way too cluttered.

    1/5 odds is a LOT. Think of a chessboard and put dimes on 13 of the 64 squares. No imagine the minecraft word looking everywhere like that. That's way too crowded!

    I suggest instead having occasionnal patches of stones here and there. A bit like pumpkin patches: maybe 2 to 4 times as common as pumpkin patches (and also both at the surface and in the underground), with each patch being from 1 to 16 individual stones, spread out over say a 12x12 area.

    This would make the world look a little bit more varied. While in vanilla the use would be severely limited (because anyone one can go from nothing to full stone tools in minutes), mods that put more emphasis on survival and a slower rate of progress would benefit greatly from these stones. Also, decorative uses.

    I'd make them small flat and square, to differentiate from the "pushable" redstone buttons.

    Support, except for the frequency. Should be relatively low odds of having a reasonably-sized patch of stones per chunk, with most chunks not having any, instead of dozens upon dozens of stones per each and every chunk.

    Posted in: Suggestions
  • 1

    posted a message on Increased Item Despawn Timer (and also disable-able)

    Well, yeah lol agreement here. So back on topic, I tend to agree with the original poster that the 5 minutes is way too short.

    First, the argument that "well you can always take your sweet sweet time to prepare while your stuff is in unloaded chunks before using up the 5 minutes to actually get it back" is actually an argument in favor of saying that a plain flat 5 minutes is not enough by itself, not the opposite.

    Second, and more importantly, the 5 minutes isn't only for when getting back stuff upon dying. It's for every item and every broken block.

    Suppose you are working on a big build. Maybe you are at it alone, or it's a multiplayer build but at the moment you are the only one working on that build.

    As you work on the higher parts of the build, despite your best efforts, sometimes blocks fall off to the ground or other parts of the structure below. You of course don't want to end up losing a good chunk of your resources, so you CONSTANTLY have to climb back down to get those, then climb back up to continue your work. Even if you are several players working, this would free up work productivity a LOT. Currently you be someone high up and say "I'll drop down those blocks I break and that you need near the chests below" without forcing the player that is charged with storing these blocks in chests (or to do something with those blocks) to nearly immediately drop whatever they are doing and get them, else they will despawn. It's a CONSTANT source of interruptions in the work flow.

    Heck, this applies not only to big builds, but in many other situations too.

    Let's say you are "taking care of" a single huge oak tree. Unless you reached very fast tools, that can easily take more than 5 minutes of work. Having to come back down and then come back up several times per each big tree *IS* a real hassle.

    Taking care of securing a ravine? Say adios to everything that falls down, as those stones will definitely have more than enough time to despawn well before you're not even half finished.

    Or you send a day shearing wool from your super-huge-all-colors-sheep-farm, and only have to worry about picking up the missed wool stack before nightfall, instead of constantly.

    Or night slowly catches up to you, and you end up losing everything by the VERY next day.

    So, excluding the "death" situation itself, the despawn delay boils down to "how much of wasted movement overhead are we willing to spend to get back at our materials." And also, more importantly, how FREQUENTLY are we willing to get "interrupted" to have to do so while we are already fully concentrating on building (or securing) something.

    Think of it this way: imagine you are are work and need to concentrate on some complicated Excel file problem. Every hour or so, somebody comes up to your office, breaks your workflow, asks you a quick question, then leaves only 1 minute later. then it takes you about 5 minutes to "rebuild your idea" and then go back to working on progressing on solving your big problem, and it then takes you another 5 minutes to "go fully up to cruising speed work capability" and become really productive. So it's a little bit annoying, but very acceptable: because you end up wasting no more than 15% of your workday on these interruptions, you still manage to do a lot of good productive work.

    Now imagine if instead people come to break your workflow EVERY DANG FRAKKING 10 MINUTES. The moment you get your idea rebuilt back in your head, you barely even started working on it that WHAM another 5 minutes interruption. You NEVER reach "cruising productivity speed". You just end almost unable to get any real work done. The overhead actually becomes something like "well over 50%"! You go back home frustrated instead of proud of your work.

    The few individuals that can easily multitask in their mind, or have such a good memory and brain that they can do a full context switching back and to some task in their head at the turn of a dime, without losing their train of thought, won't notice any difference, of course. But MOST people don't have MENSA brain levels and instead they would get very annoyed when faced with constant interruptions. It's all simply a matter of total overhead and frequency, which varies by individual of course.

    So similarly, a 5 minutes despawn delay can easily cause exactly that kind of problematic phenomenon for EVERY building project that doesn't have "trivial complexity".

    I find that having to interrupt myself several times each day is a majorly wasteful and mostly very annoying "useless overhead", but even more so, it is a total concentration breaker, as I can't allow myself to concentrate and think intensely about some specific complex "building problem" without constantly having to keep this "super short despawn timer" at the back of my head at all times, else the frustration of losing stuff is always there. My mind works like a playing cards castle: I'm trying to think about some nice build features, computing distances and block configurations so it looks nice, and other stuff, then wham, it is all brought coming down by some minor detail, and then I have to "redo" all my thinking again. And 90% of the time, it's that dang 5 minutes despawn timer which is the culprit!

    NEVER had any problems with the 5 minutes limit for getting back my stuff upon death in well explored environments.

    VERY RARELY had any problems with the 5 minutes limit for getting back my stuff upon death in maze-like or far from home environments.

    SOMETIMES had problems with the 5 minutes limit getting back my stuff upon death... when it happened in spawn chunks!

    And ALWAYS had problems with the 5 minutes limit breaking my workflow when I am on some big building project.

    Same for most people I played with. So to me this all says that, player-ergonomically speaking, the 5 minutes limit is simply put too short. Those insisting on the "5 minutes is more than enough to get back your stuff" argument is simply shooting at a mouse while ignoring the elephant in the room. The entire argument should revolve way, way more around item despawning for not-dying situations, basically the entire rest of most of the game.

    So I think that a MINIMUM of a full day-night cycle delay (20 minutes) for all item despawning would be MUCH more appropriate and allow players to fully concentrate on doing something without too much of it wasted on pure overhead or "rebuilding" your train of thoughts all the time. Players couldn't totally ignore things falling, but at least they could focus on one thing at a time, for more than a couple minutes at a time, without too much "in the back of your mind" worries. 5% wasted movement and time overhead, that's acceptable. Not 20+%!

    Ideally, I'd make the delay 30 minutes. so if you screw up one morning, you have until the next evening to fix it without actual item loss. On a big project, you also could gather some "construction material blocks" somewhere, even early in the morning, and the other players (or yourself) would have until the next evening to store it in chests (or make use of it) before it's "too late". so one player could just say "Bob, that spot near the birch tree is were I'll dump the red bricks" and Bob, instead of having to stop whatever he's doing ALMOST RIGHT NOW, could actually finish what he's doing, and have until the end of the next day to go get the stuff. Days in Minecraft are already super-duper-short enough as they are, there is no need to waste tons of time with such useless micro-management-overhead-mind-manure on top of that!

    Now, some would say "but there would be so many entities around, the game would lag/crash/etc".

    Err, not really, no? Floating items don't take much processing at all compared to, let's say, animals. Firstly, they show up only at relatively short range anyway. It wouldn't be a ridiculous idea to just make items processed round-robin in separated vector lists according to which players actually "see" them. i.e. if there are "too many" item stacks to process near some players, only THOSE player ends up getting "lagged out".

    In fact, Minecraft is currently deeply unoptimized on several of such aspects. For example, loading/unloading chunks should NOT actually allocate/deallocate actual memory space. Just use big preallocated vector block of chunks, then simply tag the "spaces" as free or not (I've done work on memory optimization: bypassing most alloc/free calls with a dedicated memory manager for a fixed-data-very-used structure so as to end up not even "touching" the memory stack and the memory heap, that is hundreds of times faster that the dumbishly-slow system alloc/free calls lol! You only allocate/free huge segments of RAM, very infrequently, to store a bucketload of those "lots-of-use" data structures all at once, instead of doing it constantly and all the time. Allocating a full "big memory page" of 16 MB doesn't really take much longer than allocating 4KB, after all. It sure takes way less time and overhead than allocating the same 16MB in 4096 separate 4KB-at-a-time function calls.

    Second, most floating item stacks don't really move at all: all their floating & bobbing high and low and their visible rotation item side viewed can be pretty much independently rendered from one player to the next. Who cares if 2 different players a few blocks from each other, and with a pumpkin exactly in between them, BOTH see the "pumpkin face side" showing towards them and not the other player? The item is constantly rotating and bobbing anyway, and sometimes you strike your sword and hit your friend, and he ends up dying a whopping 8 blocks away, and nobody is complaining too much about that. So the exact timing of rotation and current bobbing height of a floating item is extremely unimportant in comparison. Thus, exact rendering height and angle of the item able to be thrown 100% to the client's side = 0% processing weight on the server.

    Third, items already fuse as stacks, but this can easily be optimized way beyond that: multiple stacks only a few blocks from each other could count as a single entity i.e. still rendering each individual item stack separately on the client's side, but the game would treat all of these stacks as a single "object" that is centered on a specific integer XYZ coordinates. Amongst other advantages this means tile entities instead of full-on entities (wayyyy less processing involved). If near enough the stack group center, then the entire group of item stacks gets displayed, but the actual communication bandwidth between client and server, and also the per-tick-CPU-usage-per-stack, end up both getting greatly minimized. Players wouldn't even notice much difference.

    In fact, I personally hate this constant fusing of item stacks, as one it looks crummy, two it makes some times persist way longer that they sanely should (like eggs in chicken farms becoming basically almost eternal for hours, unless they reach full 64 eggs in a stack, as long as they get one new egg within 5 minutes. note tat I am talking only about immobile items here (which are by far the lion's share of floating items). For such "multistack" tile entities, each stack could be rendered at it's real floating point location. but without any extra server-side processing. Note that naturally moving items wouldn't move for longer, so that part would stay the same (they'd remain full entities), only the "once they stop moving" would they last longer, but that part actually takes next to nothing in processing compared to stuff that is moving around. So the only exception I'd make is that persistently MOVING item stacks would despawn after 5 minutes (heck 2 minutes is probably enough). Which is more than enough for "natural" items to drop from very high, and then get pushed by some water in a tunnel until they reach some final immobile destination. Thus, huge badly designed redstone contraptions that move tons and tons of items around for extended long periods of time wouldn't suddenly "use way too much CPU".

    Basically, not so much for the dying aspects, but for the building aspects I cited, I support the original suggestion. Longer, based on player game play ergonomics. Then some a few more "original and less conventional" memory management code optimizations added in.

    No support on disabling the timer entirely, too. That would definitely end up causing huge lag problem after only a few hours of server up time, if not sooner.

    Posted in: Suggestions
  • 2

    posted a message on Treat Spawn Chunks like Normal Chunks

    Currently, Spawn Chunks remain constantly loaded.

    This is, supposedly, to reduce load on servers whenever player log in because of sudden massive chunks loading at spawn.

    However, this is utter stupidity!

    First, this applies only to new players anyway, because players can log back in anywhere in a world.

    Second, loading the chunks around a player that is logging in doesn't really cause that much lag. Otherwise, you'd get noticeable lag on ALL servers, because players are already constantly logging in and out of servers and most of them do that away from spawn, so this aspect of "CPU savings on spawn chunks" is so negligible that it becomes flat out laughingstock material. This is like saying you'll keep your leather gloves in your house instead of in your car's gloves compartment, in order to save on gas... while still keeping all your heavy sports equipment on the backseat. Riiight.

    Third, keeping spawn chunks always loaded causes 2 very real game-play problems:

    - Players normally have 5 minutes of "chunk loaded time" to get back their stuff upon death, which means that the player can literally take whatever time he wants to prepare and THEN go get his stuff back, with then 5 minutes available in the "where death occurred" area. But at spawn, where new players are particularly at their MOST vulnerable, this becomes "5 minutes total" because the chunks simply never unload. While "5 minutes being more than long enough" can be subject to hot debates, what always remains true is that this creates some kind of unfairness / imbalance in the amount of time allocated to go get back your stuff, depending on where this occurred near spawn or not.

    - Players can plant a crops farm at spawn and they don't even need to be logged in for the crops to grow. Plant right at the end of your play session, log out, then go eat dinner or d your homework or something, then log back in afterwards and voilà, perfectly "all grown up" crops, for almost zero actual playtime investment, which can, by some fraction of players or servers, be seen as a form of "exploit". Replace "crops farm" with "iron grinder" and "logging out for a couple hours" for "a full real-life day" to see my point in full.

    Thus, simply put, Spawn chunks are "unfair" relative to the rest of the world's chunks. Wether what happens differently at spawn is a "good" or a "bad" thing, and whether these things count as cheating or not, are NOT my point here: the point is ONLY the fact that it works differently according to an arbitrary location, while a game's game-play should work in a consistent fashion everywhere.

    - - - - - - -

    So, I suggest the following changes:

    - Spawn chunks should load & unload the exact same way as any other chunk.

    - When any chunk would become "unloaded" (player logging out, or player moving out of area), the chunk doesn't unload immediately. Instead, it just gets bit-flagged as "inactive" ("sleeping"). Nothing occurs in there, no mob movement, no crops growth, not even video rendering! The chunk just remains in RAM, and that's it, and for all other intents and purposes it "acts" the same as if it was an unloaded chunk. Then, after a short and reasonable delay, let's say 30 seconds or 1 minute, the "sleeping" chunk gets unloaded (purged from memory) for real.

    In addition to fixing "spawn chunks unfairness", this would also avoid all the chunk loading/unloading occuring whenever a player gets momentarily disconnected from the server, or just decides to log out but only for a few seconds, which are things that happen a WHOLE LOT MORE than "new player joining a server for the first time.".

    It would also avoids all the "peripheral" chunk loading/unloading occurring from players constantly moving back 7 forth in an area, which is 90%+ of all movements in player bases/mines.

    AND it would even avoid the extra spawn chunks loading/unloading when there are tons of new players constantly streaming into a new "huge" server, which was the originally stated intention for the "keep spawn chunks always loaded". When there are not enough players around spawn, at least these chunks would not hog any CPU time. In other words: the server load would be as if there was approximately half a player less on the server.

    Yes, the overall RAM needed would increase a bit. Only increase "somewhat", though, not a lot, and the% increase would be the most visible only for really-low-player-count servers, and when players are mostly moving WITHOUT turning back such as when exploring around.

    Basically, you'd end up storing in RAM the equivalent distance worth of chunks of 30 seconds / 1 minute of running around, so yeah, about double the RAM for storing chunks. But note that this is ONLY for the RAM usage, not for the actual amount of chunk loading/unloading (more disk and CPU), which would remain the same. But even on such servers, the low player count means there is ample RAM room to spare anyway. So that wouldn't cause any performance hit, as the java cache cleanup is based much more on the rate at which memory blocks are allocated/cleared (actual chunk loading/unloading) than on the total amount. The overall reduction of chunks loading/unloading would in fact increase performance, not the other way around, not greatly but way more than the really currently totally negligible performance "boost" from keeping spawn chunks loaded at all times.

    Only REALLY low end "old junk PCs" servers would "suffer" (those that can't even allocate 2GB to Minecraft, that is). I guess for these guys, the "30 seconds to 1 minute unload delay" would just be ignored (determined directly at server start according to the available RAM for the game, a simple threshold), and all their chunks would just unload immediately, like they ALREADY do now for most players. Meaning: they wouldn't be penalized, they just would not get the performance increase the others more-RAM-allocated-for-the-game setups would get, that is all.

    But on high-player-count servers, the effect on RAM would be pretty negligible (applying only to those players currently doing long distance exploration, which is usually less than 5% of player activity), while the effect on the CPU/disk savings of chunk loading/unloading would be even more noticeable (as most of the time, chunks wouldn't get unloaded, then reloaded shortly afterwards, instead they'd just "go to sleep", stopping being active for a short period). So the overall CPU performance saved would be much more noticeable.

    Posted in: Suggestions
  • To post a comment, please or register a new account.