Whello there everyone. I have recently been working with lag-optimisations a lot, and have even spent some time researching for a lag busting thread. Whilst doing so I found out some parts of EMC itself can be updated to improve on lag. Quite a lot of these are just suggestions to implement code made by someone else, mostly Gnembon and other SciCrafters, that improves on lag. All these can, to my knowledge, be used freely. Though I probably could, I did not go out of my way to check if these were already implemented, so some of these might already be in-use without me knowing, I honestly think most of them are, but I decided to write them all down here anyway, as I am not sure. 1: Optimise redstone dust using this code, proposed by Panda4994: Github: https://gist.github.com/Panda4994/70ed6d39c89396570e062e4404a8d518 This is a complete rewrite of the redstone code, which has been implimented in many "vanilla" mods, including the Carpet mod, which I am going to talk about more, as it includes a lot of lag optimalisations and testing tools, all made by the technical minecraft community. To my understanding this redstone rewrite: -Doesn’t break any old contraptions -Makes certain parts of the update order more logical/predictable. (currently, the update order depends on the hardware of the server, which makes testing in creative impossible. This just removes that randomness, of stuff that breaks all the time the server restarts anyway, to something that is predictable.) -Cuts the amount of block updates when turning redstone wire on in half, and off more than 50 times. Reducing the amount of lag created by redstone dust greatly. Carped mod already has an implementation of this optimisation working for 1.15.2, (and I am running it myself,) about which you can learn more here : https://youtu.be/Lt-ooRGpLz4?t=1588 In general: I don’t know why this would not be implemented. It cuts down a lot on lag, with very little, if any, other consequences. 2: Some smaller things that can help to decrease entity lag, which, in my experience, is really bad on EMC. (Like, way worse than the vanilla game) -Remove entity collisions to mobs that do not have their AI turned on (aka are far away), probably breaking a few things, but, in general, removing a lot of lag with little consequences. Entity collisions could also be turned off entirely, but that might break more than it heals. I don’t have the means to test what would happen myself, but I am throwing the ball in the air anyway. -Alternatively, it could also be possible to give a maximum value to the amount of entity collisions in a blockspace, as proposed in the same carpet mod as the redstone dust update: https://youtu.be/Lt-ooRGpLz4?t=1609 -Setting the MaxEntetyCramming to its default value again (or a higher non-0 value, like 100) would also improve on entity collision lag, which would probably cut down on general mob farm lag as well. Additionally, MaxEntetyCrammming was implemented to cut down on the lag created by having too many entities, and acts as a failsafe for certain types of mobfarms. Doing this together with the 1.16 update, or by pricking a date a few months in, so people have enough time to prepare, would probably not make anyone angry. - 3: Using Gnembon’s mob spawning optimisation. This is a proper optimisation, meaning it doesn’t change anything other than the amount of lag… You can find it here again: https://youtu.be/Lt-ooRGpLz4?t=1624 I honestly don’t have anything more to say about it. 4: allow xp-orbs to stack, just like items. Xp orbs, in my testing with an xp-farm, create quite a lot of lag, mostly when the maximum amount of xp per time is reached (A player can only pick up 1 xp-orb of any size every 2 gameticks) Using the same code as items to let them stack would decrease this lag drastically. Jet, as this would not be vanilla anymore (the maximum amount of xp that a player is able to take in would increase drastically,) I would like to suggest to give every xp-orb an additional value, separate from its size, which is the amount of cooldown it has. This cooldown would be 2 ticks for every spawned orb, but stacking them would add these up, such that effectively nothing would change. It is probably nessecairy to create a maximum value for a xp orb, as it otherwise might just go mad with farms that produce more than max-xp (I remember reading EMC already did something like this, but I couldn’t find it, so I wrote it here anyway) Now for a more controversial one: 5: increase randomtickspeed and decrease radomtickrage in town. The random tick range in vanilla is quite large, allowing for the huge farms and contraptions that create most of the lag on EMC. I would want to suggest to decrease the random tick rage on EMC such that whenever you are on a residence, the entire residence will still get random ticked, but as little as possible more than that, setting it to four chunks, which is the same distance at which entities would get activated in vanilla Minecraft with render distance 5 with the 1.15 chunk loading. (on which I, for the record, am farm from an expert. If I understand the 1.15 system directly, this change would tick 36 chunks less for every player compared to the current system, decreasing the amount of randomticks by, 32% whilst not really effecting normal gameplay. Aditionally, I would like to throw a wilder ball in the air: increase randomtickspeed. This might look like a wat to increase the amount of lag again, simply making it be caused by smaller farms, which is partially correct. If the previous change would be implemented, and the randomtickspeed would get highered to 4, the amount of randomticks in total would get only cut down by an insignificant amount. Jet, the amount of effort it takes to get a certain amount of crops would get multiplied by 0.8, decreasing the value of all farmables, and making it less profitable to make farms, and less lagy to make farms of a certain size when you just need a given output (like trading or bamboo smelting) I am unsure if this would actually cut down on lag, and it is quite a significant change, but I still think it should be discussed. Anyway, these are the ideas I have had in the last few days whilst redstoning. What do you think?
I am going to BUMP this thread. It almost feels like most of these suggestions should be done via PM to develeopers, but I am told this is the way. Some of these would require a dev to say what would and would not be possible, so a response from one of them first would probably be helpfull
Im assuming that these are mods? If this is true then devs dont like to use mods that they don't make them selfs cause of the author desiding to not update to the lastest version or not fixing a bug that's effecting users of the mods.
No, just no. Some of these are direct code changes to the game itself, not so much "mods" as "direct optimalisations to the game," as I quite clearly state. It are direct changes where you can replace some lines of code with some other lines of code. This is indeed also how a mod functions, the main difference being that this is mostly, apart from the redstone change, only talking about the modification of a few lines of code, that can have a lot of influence. The redstone change would indeed be more radical, and it could definetly be considered a mod in some definitions of the word, but then still the argument you attempt to make is a compleat non sequitur. Some others are small changes in the way the game behaves that change little in the way the game operates, but that make a lot of difference in server preformance, most of which are directly possible within the vanilla game, or require the adition/removal of only a few lines of code, which makes them fail to meet even the most generous defenition of the word "mod" as it is used in minecraft discourse.
I really like this thread, but... I believe that Minecraft's modern "spaghetti-code" would need a full overhaul to at least get some improvements from it, in vanilla... -- I think the fact that some servers have not left 1.12.x for the newer versions speaks much louder about Minecraft's code than I can.
The vanilla code is indeed an absolute mess. 1.15 is quite a lot better than 1.13 and 1.14 were, but it still is quite the problem. This, however, does not mean we cannot attempt to make it any better. I don't know the workflow of EMC development, but I do not think adding these changes (that I said are small for a reason) would take more than an hour or two to make happen, and probably require no work to update to from 1.15 ro 1.16. That is probably worth it for the few percent change they can make, especially code changes for enteties, which are even worse on EMC than in vanilla.
You could always message Chickeneer and see what he has to say. I believe he's the one who works on the EMC code directly? --- It's definitely worth a shot, but I'm not expecting many performance improvements from it. (Though I hope I'm wrong...)
