Guys, relax. They are actively fixing the many bugs of 1.14, and they're actually surprisingly fast.
For me, the worst issue I've had in 1.14, was some minor rubber-banding and random lag, even though I am playing Single Player....lol.
Besides that, I keep getting blazes trying to shoot me through the walls. How they are able to track me through solid blocks is beyond me, but they do...
Anyway, I think at this point, Optifine should be getting ready for 1.14.3, because its around the corner.
In fact, some technical Minecrafters have revealed amazingly bad game design (not just buggy code, but stupid code) around raids that is causing havoc on SMP servers (and I can attest to these issues as I have both personally experienced them and received numerous end-user comments regarding them). For example, MethodZz from SciCraft published this video describing much of the 1.14 insanity: . MethodZz also pointed out other "showstopper" bugs around mob AI and other massive issues in his Showstopper series of videos. Over the last three months I have seen video after video from MethodZz and ilmango clearly demonstrating that the people cutting code for Java Minecraft, especially those implementing the new features for 1.14 (like Raids), do not know what they are doing and are making terrible design decisions.These are not minor bugs that can be fixed with a few changed lines of code; these are intrinsic flaws in the way these systems are being implemented. Many changes have been made to important underlying systems (like chunk loading and unloading, for example, and spawn chunks) and these changes have been made without a single comment in the patch notes. The changes to the spawn chunks have huge ramifications for server admins and end users, but I had to see the evidence in a video to explain what I and other users were experiencing because Mojang neglected to document a major systemic change without any community consultation and without telling anybody.
1.14.3 should address some of the piston/moving block client side lag but the reality is that Mojang has released 1.14 in a garbage state and are now scrambling to make it work. No release is ever perfect, but in my experience (spanning back to 1.5) I can't remember a release that has arrived in such an unusable state. Many of the mechanics needed significantly more testing as the changes were very broad and had knock-on effects. I remember when they were tinkering with minecart physics around 1.8 or 1.9 and they rolled those changes back because they were too much of a bear to wrestle and had too broad an impact. Any changes to villager AI has wide ranging direct and secondary impacts, and I have seen community estimates that per villager processing cost has increased by a factor of ten! If that increased cost had come with streamlined redstone wire (OMG, redstone wire processing lag... when will that garbage get addressed already?) then maybe the community could have absorbed the shock, but there were only very modest efficiency gains in 1.14 and a lot of new load (the increase in the spawn chunk count on it's own is a huge up-tick in load, especially if you
As someone who administers Minecraft servers I can say that 1.14 is a total nightmare. User complaints are through the roof and administrative workloads are radically higher than usual, even when compared with previous releases. The increased threading and new I/O system should have made 1.14 an amazing release for server admins, but instead it has been a total disaster. The "--forceUpgrade" and "--eraseCache" command line options should have made server admin's lives better, but they were snuck into the game and are still not documented anywhere. 1.14 is shambolic, and I am tired of Mojang's total disinterest in properly supporting their product.
Given the state that 1.14 has arrived in I am not surprised that the modding community is dragging its feet to embrace the new version.
There are strong indications that there are significant structural and design issues with 1.14 that were not adequately addressed during snapshotting, allowing a full release to arrive with issues that would normally have been squashed during early testing. Mojang seem to have been a little too willing to dismiss many tickets on bugs.minecraft.net as 'edge cases' and this has allowed a release to arrive with broken mechanics.
This goes beyond bugs. A bug is a malfunctioning piece of code, but I suspect 1.14 contains entirely flawed mechanics that will yield terrible results no matter how well it's coded, and then there are bugs in those terrible mechanics. I am increasingly worried that even if every bad piece of code was resolved tomorrow there would still remain fundamental mechanics that are hopelessly broken.
If a physical product was sold with sort of structural and design issues that 1.14 has it would be recalled, and I feel that we're approaching that point: Mojang need to honestly evaluate the situation and say "1.14 is not ready... we need to go back to the snapshot process and rework some of these mechanics. We'll see you in three months with version 1.15"
I have been playing since the 1.5 release. By 1.8 I was deeply interested in technical Minecraft and redstone machines, but the irony of the situation today is that you avoid redstone wherever possible. Need to send a signal? Use powered rail, it costs fewer clock cycles. Got a naked hopper? Cram a dropper on top to reduce its overhead. There are mob farm designs I built in 1.8 and 1.9 that I would never even consider on 1.14 because of the insane overhead they would generate.
I have found lately that I am using mob AI mechanics for mob farms as more dynamic and productive farms come with too much server lag (let alone needing Optifine near any water flushing farm).
SciCraft are sticking with 1.12 because 1.13 and 1.14 would annihilate their performance. Despite 1.14 having impressive levels of threading (compared to previous releases) it is the worst performing release. If I have to choose between new content and working redstone... well, redstone wins every time.
One light on the horizon are the very public issues Hermitcraft are experiencing with 1.14... With some front-line youtubers in direct contact with the devs we might finally see some real action from Mojang, rather than these frustrating half measures. I just wish that Mojang would pull their finger out and get around to actually communicating the scope of the issue with the community.
Thanks for the response. I didn't see it for some time!
Just ran the erasecache command line switch with forceupgrade and suddenly the lighting issues we've been struggling with are gone, though the server is grinding each time someone moves into chunk which needs re-lighting. Thankfully that seems to be a once off issue each chunk, so we can live with that. Now, if only we could get Mojang to take Panda's redstone wire fix serious consideration we might finally have a version of Minecraft that isn't a case of one step forward and two steps back in terms of performance, though I am happy with the efficiency gains with repeaters and moving blocks.
i dont know how people are having issues on 1.14 without optifine. i am running in the 100+FPS range
Depends on how you play the game. There are times I am hitting the frame cap I have set (150), but there are plenty of cases where 1.14 slows to a slideshow pace of 1 or 2 FPS. Lots of entities is a sure fire way to get the slide show, but there are other things, too. Flushing mob farms are always vastly improved by Optifine, but I am hoping to see some real work done on composters, which seem to have a massive impact on FPS.
I have a substantial 1.14 kelp farm that feeds into an array of 56 composters (that barely keep up with the farm output) and that murders my FPS, but I suspect that Optifine will help that in a big way.
We keep seeing cool new features added to the UI and then no command line options to trigger them for servers. Server admins need some love!
I built an AFT scute farm to test some new ideas for 1.14, and instead I built an inadvertent mob farm: the entire region around my scute farm is now pitch black and spawning mobs like crazy.
I play on a SMP server that is fairly redstone heavy. We put a lot of effort into minimising lag, but it's still an issue.
For a while we've been discussing a redstone serial communications infrastructure. There are machines located in distant locations we would like to be able to control from a central point, and we'd like to get data back from those machines so we know which ones are in use, and other diagnostic information.
Encoding/decoding is relatively easy. There are several designs out there, and we've settled on Kessle Run's rather clever piston-less design (). It's got a lot of restone dust so it might make a little lag itself (if you have any suggestions on improving his design I'd like to hear it), but it's silent as it uses redstone repeaters' latching function (a much underutilised feature, I must say!), and every other design I have looked at also tends to have a lot of redstone dust.
The problem is the communication lines between encoder and decoder. 15 blocks of redstone dust and a repeater has a couple of advantages: it's simple, cheap, and if the repeater is at the chunk border it spreads load out a little, but restone dust is lag-tastic, producing block updates, lighting updates and all sorts of lag-heavy side effects. We'll be covering 8000 blocks in a couple of instances so there will be a fair amount of server load created if we use redstone dust.
We've looked into insta-wire setups. ilmango has some cool lag-friendly insta-wire designs (). They are fairly resource intensive (not such an issue when you have an iron farm, pigman farm and witch farm) but the big issue is the transmission of encoded data: triggering these setups multiple times in subsequent ticks can induce huge issues, and while insta-wire is cool it's not actually needed as we can tolerate some latency.
So, we're looking for a wiring setup that works with encoders/decoders and that keeps lag to a minimum. Our priorities are:
1 (highest) - tick encoding - as we're using a single wire encoder/decoder (and not a setup that uses a separate timing/clock wire) we can't have pulses combine or extend
2 - Lag - we need to keep server load as low as possible
3 (lowest) - resources - if there is a way to get 1 and 2 and make it a little cheaper that's awesome, but not critical!
Lag is an issue, and much more so than latency: as long as it's faster by serial than physically traveling there we've achieved our goals so some latency is tolerable. If there is a way to spread lag/load out over time I'd certainly listen.
We've also considered using the Nether. You can send data from the Overworld to the Nether (and back again) using a binary encoder: each bit is represented by a certain block type. You fire one of each block type through a portal, and the blocks are collected on the far side, parsed through item filters to drive an encoder, and the rest goes on from there. This will reduce total load by a factor of 8 (because you need an eighth as much wire to connect point A to point B), but it's tricky. The timing is finicky, and the serial comms must be slowed to a snail's pace to ensure that packets don't run together, and item duplication can really stuff you up. And clearing bits is tricky, too. You need to assign an 9th block type to be the reset block, or have another 8 block types to be the off signals for each bit.
Digging tunnels for redstone comms is easy: ilmango again to the rescue with his Overworld () and Nether () tunnel boring designs. We already have tunnels in both the Nether and Overworld we could utilise for wiring.
So, the perfect solution to the problem is comms wire that has low lag (low server processing costs), has perfect pulse encoding (essential to the encoder/decoder design we'd like to use) and is as cheap as possible. But the world is rarely perfect.
There is a reason why high speed serial comms in the real world have more than one wire. While we'd prefer a single redstone line (each extra line is possibly a linear growth in server load and resources required) that may just not be practical. A second clock/synchronisation line maybe a better option, or having RTS/CTS signalling maybe better.
Does anyone have any suggestions? Has anyone here ever built a long range comms system in vanilla Minecraft? If we included a clock line we could have the data and clock lines interact at regular intervals to prevent pulse contraction/spreading. Could/should we build repeater stations along the line to recieve data, clean it up and re-transmit it, or is that just more server load for no good reason?
Any suggestions are appreciated! I am sure that people have done all this before!
Any chance we could get an update for this? ive been looking everywhere for a mod like this!
Yeah, I am staring an epic trim session in MCedit in the face, ahead of 1.8. We're on snapshot 14w28b now and are satisfied we're not rolling back to 1.7, so people want fresh terrain generating.
Would love an update! I know it's been 3 years, so the OP may have even moved on from the MC community
This is the change that may keep me from upgrading to 1.8. I help run a world with heavy use of rail for transport, but also hopper minecarts in machines. Every single minecart based machine is now either totally broken or completely unpredictable, and with a lot of testing it is looking such that, even if the derailing is fixed, many machines will still never work, as there is now an acceleration factor which will mean needing to mix powered and un-powered rails to get constant velocity. This is simply not practical in many machines, especially one using hoppers where redstone sources to power isolated powered rails may interfere with those hoppers.
I think this is the single most poorly thought out change I have seen in a snapshot yet. The implications effect nearly ALL players, as rails are so widely used: even redstone novices could lay track and use it effectively, but now it's all unpredictable, and unnecessary. I would have thought there would have been more community outreach prior to making a change with such universal impact, and as it's so rare to see a feature taken back out of a snapshot I am really worried my server may be stuck on 14W10C for ever, as there are other changes I do want, but there is no way I will roll our server forward if it's committing me to months of debugging machines that have been long since settled, let alone tens of thousands of blocks of rail connections and roller-coasters that now no longer work. In terms of scale of impact, it would be like increasing the redstone max signal strength to 31 from it's current 15: any comparitor machine would have to be debugged, at best, resigned at worst, or abandoned in some cases.
If they wanted to futz with the physics, they could have introduced an 'accelerator rail', and kept the powered rails for constant velocity applications. And what is all this for? Was there really such community outrage over the minecarts as they were? Or was this a change for change's sake?
0
Bug report for OptiFine 1.15.2 HD U G1 pre9
Platform: Arch Linux (Manjaro)
openjdk 13.0.2 2020-01-14
OpenJDK Runtime Environment (build 13.0.2+8)
OpenJDK 64-Bit Server VM (build 13.0.2+8, mixed mode)
There appears to be a problem with networking. Servers do not show their status on the Multiplayer screen, and if you try and join a server you get:
https://pasteboard.co/IYh0aWk.png
1.15.2 and other Mojang builds work fine. I am not running any other mods. Single player runs fine.
3
1.14.3 should address some of the piston/moving block client side lag but the reality is that Mojang has released 1.14 in a garbage state and are now scrambling to make it work. No release is ever perfect, but in my experience (spanning back to 1.5) I can't remember a release that has arrived in such an unusable state. Many of the mechanics needed significantly more testing as the changes were very broad and had knock-on effects. I remember when they were tinkering with minecart physics around 1.8 or 1.9 and they rolled those changes back because they were too much of a bear to wrestle and had too broad an impact. Any changes to villager AI has wide ranging direct and secondary impacts, and I have seen community estimates that per villager processing cost has increased by a factor of ten! If that increased cost had come with streamlined redstone wire (OMG, redstone wire processing lag... when will that garbage get addressed already?) then maybe the community could have absorbed the shock, but there were only very modest efficiency gains in 1.14 and a lot of new load (the increase in the spawn chunk count on it's own is a huge up-tick in load, especially if you
As someone who administers Minecraft servers I can say that 1.14 is a total nightmare. User complaints are through the roof and administrative workloads are radically higher than usual, even when compared with previous releases. The increased threading and new I/O system should have made 1.14 an amazing release for server admins, but instead it has been a total disaster. The "--forceUpgrade" and "--eraseCache" command line options should have made server admin's lives better, but they were snuck into the game and are still not documented anywhere. 1.14 is shambolic, and I am tired of Mojang's total disinterest in properly supporting their product.
3
Given the state that 1.14 has arrived in I am not surprised that the modding community is dragging its feet to embrace the new version.
There are strong indications that there are significant structural and design issues with 1.14 that were not adequately addressed during snapshotting, allowing a full release to arrive with issues that would normally have been squashed during early testing. Mojang seem to have been a little too willing to dismiss many tickets on bugs.minecraft.net as 'edge cases' and this has allowed a release to arrive with broken mechanics.
This goes beyond bugs. A bug is a malfunctioning piece of code, but I suspect 1.14 contains entirely flawed mechanics that will yield terrible results no matter how well it's coded, and then there are bugs in those terrible mechanics. I am increasingly worried that even if every bad piece of code was resolved tomorrow there would still remain fundamental mechanics that are hopelessly broken.
If a physical product was sold with sort of structural and design issues that 1.14 has it would be recalled, and I feel that we're approaching that point: Mojang need to honestly evaluate the situation and say "1.14 is not ready... we need to go back to the snapshot process and rework some of these mechanics. We'll see you in three months with version 1.15"
I have been playing since the 1.5 release. By 1.8 I was deeply interested in technical Minecraft and redstone machines, but the irony of the situation today is that you avoid redstone wherever possible. Need to send a signal? Use powered rail, it costs fewer clock cycles. Got a naked hopper? Cram a dropper on top to reduce its overhead. There are mob farm designs I built in 1.8 and 1.9 that I would never even consider on 1.14 because of the insane overhead they would generate.
I have found lately that I am using mob AI mechanics for mob farms as more dynamic and productive farms come with too much server lag (let alone needing Optifine near any water flushing farm).
SciCraft are sticking with 1.12 because 1.13 and 1.14 would annihilate their performance. Despite 1.14 having impressive levels of threading (compared to previous releases) it is the worst performing release. If I have to choose between new content and working redstone... well, redstone wins every time.
One light on the horizon are the very public issues Hermitcraft are experiencing with 1.14... With some front-line youtubers in direct contact with the devs we might finally see some real action from Mojang, rather than these frustrating half measures. I just wish that Mojang would pull their finger out and get around to actually communicating the scope of the issue with the community.
0
Thanks for the response. I didn't see it for some time!
Just ran the erasecache command line switch with forceupgrade and suddenly the lighting issues we've been struggling with are gone, though the server is grinding each time someone moves into chunk which needs re-lighting. Thankfully that seems to be a once off issue each chunk, so we can live with that. Now, if only we could get Mojang to take Panda's redstone wire fix serious consideration we might finally have a version of Minecraft that isn't a case of one step forward and two steps back in terms of performance, though I am happy with the efficiency gains with repeaters and moving blocks.
0
Depends on how you play the game. There are times I am hitting the frame cap I have set (150), but there are plenty of cases where 1.14 slows to a slideshow pace of 1 or 2 FPS. Lots of entities is a sure fire way to get the slide show, but there are other things, too. Flushing mob farms are always vastly improved by Optifine, but I am hoping to see some real work done on composters, which seem to have a massive impact on FPS.
I have a substantial 1.14 kelp farm that feeds into an array of 56 composters (that barely keep up with the farm output) and that murders my FPS, but I suspect that Optifine will help that in a big way.
0
OMG, this...
We keep seeing cool new features added to the UI and then no command line options to trigger them for servers. Server admins need some love!
I built an AFT scute farm to test some new ideas for 1.14, and instead I built an inadvertent mob farm: the entire region around my scute farm is now pitch black and spawning mobs like crazy.
0
Hello Minecrafters!
[Warning: massive post in-coming!]
I play on a SMP server that is fairly redstone heavy. We put a lot of effort into minimising lag, but it's still an issue.
For a while we've been discussing a redstone serial communications infrastructure. There are machines located in distant locations we would like to be able to control from a central point, and we'd like to get data back from those machines so we know which ones are in use, and other diagnostic information.
Encoding/decoding is relatively easy. There are several designs out there, and we've settled on Kessle Run's rather clever piston-less design (). It's got a lot of restone dust so it might make a little lag itself (if you have any suggestions on improving his design I'd like to hear it), but it's silent as it uses redstone repeaters' latching function (a much underutilised feature, I must say!), and every other design I have looked at also tends to have a lot of redstone dust.
The problem is the communication lines between encoder and decoder. 15 blocks of redstone dust and a repeater has a couple of advantages: it's simple, cheap, and if the repeater is at the chunk border it spreads load out a little, but restone dust is lag-tastic, producing block updates, lighting updates and all sorts of lag-heavy side effects. We'll be covering 8000 blocks in a couple of instances so there will be a fair amount of server load created if we use redstone dust.
We've looked into insta-wire setups. ilmango has some cool lag-friendly insta-wire designs (). They are fairly resource intensive (not such an issue when you have an iron farm, pigman farm and witch farm) but the big issue is the transmission of encoded data: triggering these setups multiple times in subsequent ticks can induce huge issues, and while insta-wire is cool it's not actually needed as we can tolerate some latency.
So, we're looking for a wiring setup that works with encoders/decoders and that keeps lag to a minimum. Our priorities are:
1 (highest) - tick encoding - as we're using a single wire encoder/decoder (and not a setup that uses a separate timing/clock wire) we can't have pulses combine or extend
2 - Lag - we need to keep server load as low as possible
3 (lowest) - resources - if there is a way to get 1 and 2 and make it a little cheaper that's awesome, but not critical!
Lag is an issue, and much more so than latency: as long as it's faster by serial than physically traveling there we've achieved our goals so some latency is tolerable. If there is a way to spread lag/load out over time I'd certainly listen.
We've also considered using the Nether. You can send data from the Overworld to the Nether (and back again) using a binary encoder: each bit is represented by a certain block type. You fire one of each block type through a portal, and the blocks are collected on the far side, parsed through item filters to drive an encoder, and the rest goes on from there. This will reduce total load by a factor of 8 (because you need an eighth as much wire to connect point A to point B), but it's tricky. The timing is finicky, and the serial comms must be slowed to a snail's pace to ensure that packets don't run together, and item duplication can really stuff you up. And clearing bits is tricky, too. You need to assign an 9th block type to be the reset block, or have another 8 block types to be the off signals for each bit.
Digging tunnels for redstone comms is easy: ilmango again to the rescue with his Overworld () and Nether () tunnel boring designs. We already have tunnels in both the Nether and Overworld we could utilise for wiring.
So, the perfect solution to the problem is comms wire that has low lag (low server processing costs), has perfect pulse encoding (essential to the encoder/decoder design we'd like to use) and is as cheap as possible. But the world is rarely perfect.
There is a reason why high speed serial comms in the real world have more than one wire. While we'd prefer a single redstone line (each extra line is possibly a linear growth in server load and resources required) that may just not be practical. A second clock/synchronisation line maybe a better option, or having RTS/CTS signalling maybe better.
Does anyone have any suggestions? Has anyone here ever built a long range comms system in vanilla Minecraft? If we included a clock line we could have the data and clock lines interact at regular intervals to prevent pulse contraction/spreading. Could/should we build repeater stations along the line to recieve data, clean it up and re-transmit it, or is that just more server load for no good reason?
Any suggestions are appreciated! I am sure that people have done all this before!
1
0
Yeah, I am staring an epic trim session in MCedit in the face, ahead of 1.8. We're on snapshot 14w28b now and are satisfied we're not rolling back to 1.7, so people want fresh terrain generating.
Would love an update! I know it's been 3 years, so the OP may have even moved on from the MC community
7
I think this is the single most poorly thought out change I have seen in a snapshot yet. The implications effect nearly ALL players, as rails are so widely used: even redstone novices could lay track and use it effectively, but now it's all unpredictable, and unnecessary. I would have thought there would have been more community outreach prior to making a change with such universal impact, and as it's so rare to see a feature taken back out of a snapshot I am really worried my server may be stuck on 14W10C for ever, as there are other changes I do want, but there is no way I will roll our server forward if it's committing me to months of debugging machines that have been long since settled, let alone tens of thousands of blocks of rail connections and roller-coasters that now no longer work. In terms of scale of impact, it would be like increasing the redstone max signal strength to 31 from it's current 15: any comparitor machine would have to be debugged, at best, resigned at worst, or abandoned in some cases.
If they wanted to futz with the physics, they could have introduced an 'accelerator rail', and kept the powered rails for constant velocity applications. And what is all this for? Was there really such community outrage over the minecarts as they were? Or was this a change for change's sake?
Stupid, stupid, stupid.