[DISCUSSION] 1.18 height limit

Discussion in 'Suggestion Box Archives' started by chickeneer, Nov 16, 2021.

  1. As 1.18 enters into the Pre-release cycle. We are confronted with needing to address new aspects of the update as it relates to EMC. This thread is on the topic of the world height limit change... The height is increasing from Y=1/256. To Y=-59/319. This is an over 40% increase in world height. I am not worried about just the existence of larger builds (only really hurts on loading/saving, my concern is with the possibility of a 40% increase in farms' scale. Despite what it may look, in general I am not against farms. But I am against lag inducing farms. Even farms designed with server load in mind would hurt the server to be 40% larger.

    I have my thoughts on what we could do. But I want to bring it to the community. What do you think we should do to mitigate new and expanded issues. Would a refined policy be enough to prevent issues? Are there any coded in limitations we could impose to prevent abuse? Or should we just wait and see what happens, put out the fires as they come? (Though, there is a political consequence to shutting down someone's work after they put in the work to build it)

    At the end of the day, if someone's build is causing the server to significantly drop TPS, we are going to explore if there are code solutions. If a code solution is not possible we Have to disable/remove it. Those are the only routes I can think of and why I am seeking feedback if anyone has an alternative suggestions. Thanks!

    Final Note... I have seen some toxicity when it comes to replying to suggestions recently. It is good to remember that responding to other's suggestions should be done from a position of kindness and helpfulness.
    There is never a reason to put down another person for suggesting what is on their mind. If you disagree, instead of just saying it is a bad idea - tell them WHY you don't think that suggestion would work for EMC or HOW you would make their suggestion better. Just saying an idea is Bad neither communicates a welcoming atmosphere for making server suggestions nor helps improve/refine the original suggestion.
    Also, generic positive statements as feedback, do accomplish kindness, but they are rarely helpful for giving beneficial feedback towards a suggestion. Consider adding in some minor tweak that you think would make the suggestion better, that the author may not have considered yet.
  2. We made it this long with the height we have. No reason to change it now. New biomes may need it but that's really all that is needed.

    EDIT: Just think how much work is needed to fix farms that break now. Then add 40% to that :p

    EDIT2: Any way to limit the height of redstone items being used at? This could still let people build higher (like flying courses or something) but keep the laagy items at normal.
    ItsMeWolffpack likes this.
  3. I would love to have the extra volume, both in town and in chunks generated in the future.

    I see the issue with farms (I am more looking forward to the possibility of building tall/enourmous passive buildings).

    I think a rule concerning size/TPS demand of a farm should be enough, but I have not enough experience around here to justify this gut feeling.
    ItsMeWolffpack likes this.
  4. I’m for waiting to see what might happen. Perhaps a warning to players that do want to put in the time and effort to build such an expansive farm. In the event that the farm does cause the tps to drop. The Senior Staff have the right to world edit the build away and leave the exact amount of materials used for the farm in locked chests for the farms builders to reclaim. That way should the server be unable to have such expanded farms, the players won’t lose the material they used. They’ll just not have anything to show for their time. Only then could we revise the rules to incorporate this issue.
  5. To be honest, I don't really see this being much of an issue given EMC's lower entity cap already. There is diminishing returns to building larger and larger mob farms. That being said, I do see the potential issue with a gigantic sorter system, or a giant melon and pumpkin farm or some such that doesnt have an entity limit. Honestly, it's not like we haven't had peoples builds get removed before. People are aware that if you put stress on the server you are liable to have your stuff world edited away, and if they want to take that risk it's on them, rather than imposing rules on everyone else that may not fit everyone due to some SMPs having more lag than others
  6. If you all can find a seamless way to integrate the new generation effectively to the Town world specifically, but also the Wilderness/Wastelands then I'd be all for it. However, if there did need to be some kind of drawback or perhaps a middle ground (not sure if this is even a good idea but it's a thought), is we would keep Town worlds the "Legacy" height of 1/255, and make the Wilderness/Waste the new -65/319. This (I think) would help speed up deployment of the update, since I am unsure of how exactly the world generation handles super flat conversions. But this would put a limit on farms to their all ready caps as they are now, and if they needed bigger, they would need to work/build in the Wilderness for deeper/larger farms. Which is significantly more work and should alleviate any farms just haphazardly thrown together with the addition of new height immediately after the update drops which is notorious for having TPS issues. However, that's just my thoughts. I personally would LOVE to have another 128 blocks to work with in the Wilderness (taller Pyramids :D) but if performance became an issue then perhaps I can deal with what I have always had.
  7. I definitely don’t think changing anything about the build height itself would be a solution: there are so many non-farm things people would want to do with that vertical space, not to mention how weird not having the same build height as other servers might be in a few years.

    I think that just generally talking about “farms” isn’t productive here: there are many different types of farms, and they might have different solutions based on each.

    I’m going to split them in two groups: farms that rely on entity spawning and farms that rely on random ticks. Yes, there are also contraptions that don’t use either, but they shouldn't be a concern here: I don't think anyone has jet come close to hitting the render distance with sorting systems, even with the current height.

    For spawning: I have always been for making the immediate despawn radius spherical rather than cylindrical. This would allow farms to be smaller and simpler with the same drop rate, since, with possible elimination of all possible spawning spaces outside the farm, the return to increase in size decreases more quickly.
    Additionally, it would make sure that farms that are based on mob spawning simply cannot be higher than limited by this rule, voiding the issue of increased build height.
    This doesn’t have to be strictly spherical, of course. It could also be done that first the x^2 + y^2 < 64^2 is checked, and then x^2 + y^2 + z^2 < 128^2, to have it be the intersection of the current cylinder with the vanilla sphere. I would personally really like this version, since it would allow for most of the same despawn stuff as in vanilla, with a simple addition of the 64 block cylinder as the old optimisation.

    For random ticks:
    The same thing, really. I’d just limit the size of random ticks around the player to include both vertical and horizontal Chebyshev distance of 5-8 subchunks around the player. (making it a ~ 200 x 200 x 200 cube.) I would personally favour the 5 rather than 8, since I cannot think of any valid reason to make a crop farm that is bigger than 10*10*10 chunks, but that might partially disable some farms that are currently in existence.

    I cannot think of another good solution, so this simple one would be my pick for now: just limit the stuff that makes farms work across vertical distance.
    Also, I should state that I haven't done technical stuff in Java for quite a while. The last time I have done serious thinking about mob spawning was in 1.15, the last time I felt like I fully knew the system was with 1.12. Lately, my minecraft time has been going towards Bedrock / Education Edition mapmaking, so I might be wrong about how some things work.

    --

    If EMC wants to get even a little bit of new players, I think it's obvious we should try to stay to vanilla stuff like this as closely as possible. Otherwise we're just going to repel them.

    For a builder like me, the height increase is actually amazing, as it allows for a lot more vertical space to be used. This doesn’t mean making a skyscraper to build limit (although I might do that,) it means making a plane fly over your buildings, or making an even taller magical tower, or make your floating islands float up so much higher. Vertical space doesn’t need to be filled up to be used.

    This would definitely be possible, but it would break about everything.

    Also, I don't think you understand what generally causes the lag: for farms that are moderately well-designed, it's entities, not redstone component activations. Additionally, I would much rather disable the reason people might want to make this much redstone up far away than just disable the redstone itself. The latter seems.. uhm… like a hack-fix.

    -

    Though, in theory, this sounds like a great idea, I would personally prefer preventive measures. We have seen *ahm* certain people *ahum* being completely delusional about how much lag their farms cause, as they don’t even understand what MSPT stands for, let alone the basics of lag prevention or testing. I think that, in practice, this would only breed discussion about how much lag something is *actually* causing, finger pointing, and other stuff like that.
    I’d much rather prevent people from doing excessive farming operations than stop them once they’re happening, though the latter can remain as a final option.

    The sentiment I do agree with here, is that we should not make something that also significantly hurts non-excessive farming operations, loosely defined as farms where everything that is farmed is efficiently and also close enough to being used. I definitely think that removing excessive farming operations rather than preventing them is a lesser evil than preventing reasonable farms in the crossfire.
    607, Fred_TWK and zafir247 like this.
  8. I am wondering how the change in town might affect builds that are already made at bedrock level. Is the bedrock to become dirt? No change? Change with an ss request?
    Grimm_Pantalones likes this.
  9. I read everybody's input thus far and see many good notions, but I also see this as a 2 part matter: town and frontier.

    Town: I foresee issues with those that've had SS dirt removal (and yes, I even know some that have bedrock removal like Fiery's DeathRace), many of those people would prob want the new dirt/bedrock that would be added removed to reflect their original feel. Some maybe not; so maybe a list of those that had DDTT redeem'd and giving them like 90days from rollout of 1.18 to decide, otherwise they'll be left with the dirt.

    Farms in Town: I definitely know some massive farms both on Utopia and 1-9, as well as some people who have truly massive arrays of chests/sorters. I don't know how to handle this other than maybe approaching those people with a warning about not exacerbating an already noticeable issue they cause when their res is loaded. For the future maybe added an additional question to the Tutorial, and maybe a short 'mini event' around 1.18 that has warnings about not abusing the additional vertical limit subtly put in it in a bunch of places.

    Frontier: I said this before with 1.16/1.17, I think that the Frontier/Waste setup for the End needs redesigning. I'm not sure what Chicken/Kry/Aikar & company are doing atm for this but I see that the Frontier End could be scaled back so its only maybe 25k block radius to world border, then expand Waste End to something like 25k as well, but put a regular scheduled burn/reset of it for like 1st weekend of every month. With shulk farms now established I don't foresee people exploring the end as much anymore So all the 'explored' Frontier end that was used for busting could prob be ID'd based on # of player blocks placed, anything under a reasonable number isn't a real base/build and give 60days for ppl to grab stuff then reduce the frontier world limit.

    Frontier Farms: I think Egeau is on to a decent approach. If the mob spawn and random tick algorithm is tweaked for a spherical approach covering at max maybe ~75% of world height that could work well. With it centered around the player sure they could modify their farm so 2 ppl stand at different heights to keep the farm active the full height of the world but those that'd be doing this often are prob already known for their large and bulky farms.
    For existing/new public farms (which many use) I could see establishing rules that also limit their size to something like a 16chunk sphere. Private farms could be less strictly governed (I'm IRL generally less regulation = always better) as more ppl use the public farms vs gathering materials to make their own atm: which is good as this could help delay the impact farms could have with a 1.18 rollout, knowing the % of new players that'll build sizeable farms has a timespan and it is probably something like 2-6months after the rollout for a decent number of new farms to pop-up.

    Misc: I'm a bit out of date but if mob spawning still looks at each height individually and then proceeds upwards, then perhaps a 'hedge' to future sky farms is to adjust the logic.
    You could look at the top&bottom 16 blocks (y-lvls), then proceed up/down by than much until you meet in the middle. this would make farms optimized by having them at either the world floor or ceiling, but less effective in the middle. A similar approach would be to go from middle y-lvl, then up&down 16blocks, proceeding from the center so farms would be optimized only if located in the middle.

    The best of these would be the prior though; since if implemented it would work well with some version of Egeau's approach to making spawning/RTs spherical and not cylindrical.
    Example: a farm built from world floor to ceiling where 2 players try to sit on 2x different perches so there is spawning/RTs the full world height. Well if the sphere had a 14chunk radius, even more overlapping it shouldn't cause too much more an issue since the center will be checked last, so the farm would be better if it didn't have a center (with regards to spawns, not RTs). Or something to that affect.

    Just my 2-bits on the matter.
    Nickblockmaster likes this.
  10. maybe limit redstone above a certain height? like make tics slower above normal height? have a rule about how many hoppers you can have up there etc
    Nickblockmaster likes this.

  11. This would also mess with new players trying to build their base in a flying castle.
    In general, I think this is an ultimatum I would set: no code limit made for lag improvement should also effect new players who are making simple redstone from a YouTube tutorial: All small-scale simple redstone should work exactly the same as vanilla.
    I think failing to meet this goal is generally a good way to deter new players, as it further increases the learning curve of this server, and makes it a lot less fun to do anything.

    That would be a nightmare to code, and it would break a lot of stuff you wouldn't expect to break. The easiest way I can think of doing this is adding a whole new set of blocks called "above 265 wire/diode/torch," wth different delays on the amount of ticks it takes untill it activates, to then trick the client into thinking it's the same block. I think you can see this would break everything.

    The spawning algorithm was overhauled for 1.18, but the basics (I think) are still the same: It overproduces spawns, and then checks for a lot of factors to see if it is a valid location or not. The overproduction of spawns /was/ actually dependent of y-level, which caused lower farms to be more efficient, but it currently is equally distributed. The reason it used to work is that when it overproduces on 16 levels, there is a higher chance that one of those is your spawning platform than when it overproduces at 128 levels, because you can fill all the 16, but usually not all the 128. You cannot make this into effect top to bottom, though, since it always needs to produce at every y-value since y=0 is always occupied.
    Once the entity is spawned, it continues doing checks to see if the entity should despawn. In vanilla, one of these is the 128 blocks sphere around the player, that, when the mob is outside of it, immediately despawn it. I think messing with that code would be a lot more productive. Not only does it seem to me that imposing a vertical limit where the vanilla game has a vertical limit is better “vanilla+,” it also seems like it is a more effective way of doing it, since most players wouldn’t know the ins and outs of the spawning algorithm anyway.

    --

    If it is indeed true that there are people who do have sorter arrays so big that they are currently being limited by residence size, I’m going to have to adjust my opinion on non-generative systems, and focus on plain redstone as well.
    I do actually quite like that idea, though I would probably extend it to “tile entities,” and then exclude droppers and composters from that list, as they are used to top hoppers.

    Once we update, in town, we would once count all the counted tile entities in every residence, and then a piece of code simply activates every time a tile entity is either broken or placed, to update that counter of the residence it happened to be in.
    Then, we could simply pose a limit, to make all block place attempts of a hopper fail once the counter reaches a certain number.
    There is one issue with this number, which is that giving an upper limit might make people think that anything below that limit is “okay.” So, instead, I would propose this system:
    More than 1000 hoppers on a residence: “Warning: this residence might cause TPS lag because of the amount of tile entities on it. Please unload it when the server TPS is below 20”
    More than 5000 hoppers: “Warning: your residence has an excessive amount of tile entities on it. Please unload your residence when the server has TPS issues. If your residence is loaded for long stretches of time and/or the use of tile entities isn’t strictly necessary or contributing to the server, SS will likely remove some structures from your residence to improve server performance.”
    More than 10000(!) hoppers: “You have exceeded the maximal amount of hoppers that can be placed on a residence.”

    I didn’t just guess those numbers: I have quite a few world downloads from other people’s redstone they asked me to check, as well as my own systems to base them on, and I think these numbers are really reasonable. I do not see any legitimate reason to exceed 10K hoppers, and only a few to go past 5K.
    My personal storage system, which, to be clear, I load only when I need to, and which is only spread out over two residences for aesthetics, has 4783 hoppers. 1070, Tom’s and mine bulk shop, which sells in absurdly large quantities, with most people buying at 1-10DC at a time and several customers each day, has 3049 hoppers. My draft of a Recycling centre, which has to be able to sort every single item in the game and store all of them in reasonable quantities, has 4864, so 5K seems reasonable on the personal project front.
    However, I have done some redstone for a megamall project for someone, who wanted not just every item sorted through, but also 5Dcs of storage for each item and a reasonable amount of bulk storage for those items that require that, has 7446, all on a single residence (in fact, all below y = 38)
    None of these residences have a significant amount of other tile entities that aren’t composters/droppers for hopper lag busting.
    This is how I ended up with a 5K “soft limit” of “we might remove stuff if you’re not helping anyone or have your farms poorly designed.” And the 10K "hard limit."

    The 1K warning is there because that seemed to me like reasonable enough. I think another warning is needed, because, at that point, you are using a large amount of hoppers for something, and you should be careful with loading that residence, as well as know what you’re doing a little, but there are plenty of reasonable things you can do with that amount, so no drastic action other than a warning should be taken. Also, it’s a great psychological device.

    For the Frontier, a simmilair system could be used, with a count per chunk, and a maximal amount of tile-entities in a chunk, based on the count of it and some amount of chunks around it.

    ---

    Re-reading Chicken’s post again, I don’t think updating the world height itself is the question being asked. I think the focus is solely lag improvement.
    However, if I would give my two cents on this: I would suggest for town to first copy the bedrock layer and paste it below, and then replace all y=0 bedrock with dirt, and set all blocks below it to dirt, too.
    DDTT would, with the increase in res size, now cost twice as much, and people who want only half of their res dirt removed, can do so at half price. (This would be both newer players looking to go down to y=0 and older players who already have an old dirt removal on the residence.)
    Grimm_Pantalones and 607 like this.
  12. afaik our redstone already isnt identical to vanilla i believe it was aikar who called our server rocky road vanilla. limiting redstone above a certain height wouldnt make it any more unvanilla than it already is if the conditions were right. maybe just limit a single chunk to (insert reasonable numbers here of repeaters, comparators etc) this doesnt even have to be coded in, just made in a rule. then if a machine is left on that violates this rule and is noticed it can be disabled manually. idk the numbers but i dont think this is as right-offable as you are making it. plenty of servers limit even normal height redstone and dont have trouble gaining new members. we have trouble gaining new members willing to go past the tutorial, if they can manage to overcome that obstacle then we can all talk about them making massive redstone machines that potentially violate said rule. as a fix i think this remains viable
    Nickblockmaster likes this.
  13. I still re-thinking about this. What are the issues you are thinking about? because in my ignorance I don't understand what's the issue with moving the bedrock layer down and add dirt layers where needed.

    Is the issue the DDTTs used in the past? road edits? bedrock removal? else?
  14. As with some here, I joined EMC when every server was full, quickly more servers 7,8 and 9 were added. That was a long time ago, and I know we allways said we would never reset the wild and thats been a good thing. However, since then the player numbers have dropped and if it would help reduce server resources would it be possible to reduce the number of servers; as in the number of unused residences and bunch players together. Again I know a ton of work, but would it make much diference,reducing the 9+ towns, still leaving the wild areas on servers 1-9 but having fewer wastelands and towns.

    If that makes sense, sorry bad head day
    Nickblockmaster likes this.
  15. It was more in my own ignorance of how super flat worlds transfer, since I've never looked into that. With so many builds being close to bedrock and/or placed on bedrock having the bottom suddenly switched *could* cause some issues. I am unsure if superflats seemlessly autoswap to the appropriate block to fill or if Mojang hard-coded the upgrade process to use Deepslate. I wouldn't think they would hardcode it but Mojang continues to surprise me with their spotty development/implementation. That's what I was going for.
  16. How will the new layers be added in below what is already there? Will the current bedrock become a dirt layer? If there's redstone (or carpet, or torches etc) on the bedrock now will that stay put or pop off? Will the new layers below be dirt or just air? If a DDTT was used in the past can those layers be removed?
    607 likes this.
  17. I feel a bit dumb. Isn't the terrain generation in town fully under your control? can't a command block be placed to force generated block to be dirt unless it is the last layer?
    OR
    can't the new height be applied and you use a world edit to guarantee that everything below y=0 is dirt except the bedrock layer? this could even be done offline during the update (if doable, of course)

    aside from this there are Linden's questions, but I think that the DDTT question is up to the admin team to answer.
  18. With the amount of custom coding that EMC does, it is definitely possible to change how the generation works. No datapacks or MCEdit needed.
    However, again, I don't think this is the point of this thread.
    607 likes this.
  19. I keep seeing stuff about limiting redstone. Don't forget, there when C&C is live, there will be "wireless" redstone. I believe a lot of creations could be further compacted and more efficient with this new mechanic. Also, due to this compactness (no redstone ladders), the creations will be bigger without any change in physical size.
  20. That's not till 1.19.
    Grimm_Pantalones and 607 like this.