Tile ticks of connected redstone components might be executed in the wrong order when unloading/reloading chunks
The bug
Sometimes repeater clocks may freeze due to the way tile ticks are saved and updated. Most cases of that already got fixed and it already got a lot better compared to when the issue was created. This happens when the repeaters are in different chunks.
How to reproduce
- Move to a location outside of the spawn chunks. The spawn chunks are close to the location you are when you type /kill without having a bed spawn. Move far away from there.
- Hit F3 + G to show chunk borders.
- Build a repeater clock in such a way that the repeaters are located in two different chunks.
- Now move away from the clock in such a way that the chunk of one repeater is closer than the other. Move away until you can't see either of the repeaters anymore and maybe a little further to be extra sure. You can lower your render distance if you want to make this happening faster.
- Now move closer to your clock again. The clock is likely to be stuck now.
Why this happens
That happens because when you move away the chunks unload and so do the tile ticks of the repeaters. When you move closer again and the repeater that is in the chunk that was closer to you has a tile tick scheduled for turning on while the other has scheduled a tile tick for turning off, the chunk with the repeater that wants to turn on gets loaded first, the tile tick counts down and gets executed while the other repeater was not loaded the entire time and thus didn't yet turn off. Now both repeaters are turned on and the clock is broken.
This is certainly not easy to fix. I think in order to fix this, tile ticks need to be overhauled in general. A system where tile ticks can be "connected" so that if one of them is loaded, the other gets loaded as well might be an option.
Linked Issues
is duplicated by25
MC-7708Buttons lag when used to issue a /tp commandDuplicateMC-8134frozen redstone clocksDuplicateMC-8137Stone button sticks/remains depressedDuplicateMC-8912Quiting and reopening world causes 1 clock to freezeDuplicateMC-9019/DuplicateMC-9711Redstone Current FlawsDuplicateMC-9812Repeater...DuplicateMC-10091Daylight Sensor fails to update on map close/openDuplicateMC-10509Redstone will stay activated when the redstone powers a Command Block that teleports you somewhere.DuplicateMC-10713Comparator 2-clock breaks when relodedDuplicateMC-11079Comparator clocks freezing after reloadDuplicateMC-12701Redstone bugDuplicateMC-13111Redstone Bug for 1.5.1DuplicateMC-13350Daylight sensor/ chunk reload errorDuplicateMC-116805Unexpected redstone / block update behavior when implemented in a timer+automatic farm designDuplicateMC-140007Pressure plates and buttons remained powered if used to teleport with commandsDuplicateMC-140588Botton don't restore when it activates a command block and teleport you to a far placeDuplicateMC-140669Buttons sticking when teleporting with command blocksDuplicateMC-141375Buttons keep getting stuck, and I have to keep replacing them.DuplicateMC-638Chunks unload via teleporting with command block before a button or pressure plates unpowersDuplicateMC-3284Redstone repeaters "freezes" and stop repeating the signalDuplicateMC-3812Redstone circuitry freezing in on/off state when chunk is unloadedDuplicateMC-4875When I walk away from my constructions that use Redstone clocks infinite, this clock goes off or gets a continuous stream.DuplicateMC-5019Command Block /tp CommandDuplicateMC-5196Pressure Plates not turning off!DuplicateAttachments26
- Unresolved
![[Mod] NeunEinser](../../../data/avatars/users/39263.png)
[Mod] NeunEinser
nick pomroy- 150
- 43
- Confirmed
Low- Platform
- Chunk loading Redstone
- chunk redstone reload scheduled-block-updates teleport
1.4.2 - 24w33a
1.4.2 1.4.5 1.4.6 1.4.7 13w03a 13w04a 13w05a 13w05b 13w09b 13w09c 13w10a 1.5 13w11a 1.5.1 1.5.2 1.6.1 1.6.2 1.7.4 14w02c 14w03a 14w03b 1.7.9 14w20b 14w21a 14w21b 1.8 1.8.1-pre3 1.8.1 1.8.2-pre1 1.9.4 1.10 1.10.2 1.11.2 17w06a 1.12.2 17w43a 17w43b 18w03b 18w16a 1.13-pre2 1.13-pre3 1.13-pre6 1.13-pre7 1.13-pre8 1.13 18w31a 1.13.1-pre1 1.13.1-pre2 1.13.1 1.14.4 19w37a 19w38b 1.15.2 20w06a 20w07a 20w20b 20w21a 1.16.1 1.16.2 1.16.3 1.16.4 20w49a 20w51a 1.17.1 1.18.1 1.19.3 23w03a 23w04a 1.20.4 24w12a 24w33a- 13w10b
Created Issue:
Redstone stays powered after teleporting
Using a combination of redstone, redstone repeaters, and a wooden pressure plate to power one or multiple command blocks to teleport players. When I step on the pressure plate it teleports the player fine however when you go back the redstone still appears to be powered on. I haven't tested to much further but this has happened multiple times with different setups of 1 - 4 teleports.
Environment
Windows 7
Attachments1
- Unresolved
- Open
- Public
- Unconfirmed
- Creative
- Command_Block Creative bug redstone
- 1.4.2
Using a combination of redstone, redstone repeaters, and a wooden pressure plate to power one or multiple command blocks to teleport players. When I step on the pressure plate it teleports the player fine however when you go back the redstone still appears to be powered on. I haven't tested to much further but this has happened multiple times with different setups of 1 - 4 teleports. I am teleporting a couple hundred blocks away.
Using a combination of redstone, redstone repeaters, and a wooden pressure plate to power one or multiple command blocks to teleport players. When I step on the pressure plate it teleportsthe player fine however whenyou goback the redstone stillappears to be powered on. I haven't tested to much further but this has happened multiple times with different setups of 1 - 4 teleports. I am teleporting a couple hundred blocks away.When teleporting using command blocks the redstone can remain permanently powered. Using a simple pulsar setup to power a single command block to tp the player far enough to unload the chunk reproduces the bug. The pulsar will be frozen every time with the repeaters unpowered even though they should be on. Originally came across this using a combination of redstone, redstone repeaters, and a wooden pressure plate to power one or multiple command blocks to teleport players. When I stepped on the pressure plate it teleported the player fine however when I went back the redstone was still powered on. This has happened multiple times with different setups of 1 - 4 teleports. I am teleporting a couple hundred blocks away (assuming to an unloaded chunk).
is duplicated by
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
is duplicated by
is duplicated by
is duplicated by
is duplicated by
another work around: teleport them from the pressure plate to 1,2, or 3 blocks above the pressure plate so that the pressure plate has time to reset, then you use the REAL, long distance command block!
Redstone stayspowered afterteleportingRedstone and components stay powered after unloading chunks
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
Manually initiated crash report verifying persistence of
MC-7111
is duplicated by
Gerrard Lukacs,
is duplicated by
is duplicated by
is duplicated by
is duplicated by
![[Mojang] Jeb (Jens Bergensten)](../../../data/assets/gravatar/jeb.jpeg){kind=small}
[Mojang] Jeb (Jens Bergensten)is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
Windows 7
is duplicated by
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
Is this still a concern in the latest Minecraft version 14w03b? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
is duplicated by
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
When teleporting using command blocks the redstone can remain permanently powered. Using a simple pulsar setup to power a single command block to tp the player far enough to unload the chunk reproduces the bug. The pulsar will be frozen every time with the repeaters unpowered even though they should be on. Originally came across this using a combination of redstone, redstone repeaters, and a wooden pressure plate to power one or multiple command blocks to teleport players. When I stepped on the pressure plate it teleported the player fine however when I went back the redstone was still powered on. This has happened multiple times with different setups of 1 - 4 teleports. I am teleporting a couple hundred blocks away (assuming to an unloaded chunk).
Sometimes repeater clocks may freeze due to the way tile ticks are saved and updated. Most cases of that already got fixed and it already got a lot better compared to when the issue was created.
I only manged to find one case were the problem still remains. That is, if you place an ordinary repeater clock with two repeaters in two different chunks.
Steps to reproduce:
- Move to a location outside of the spawn chunks. The spawn chunks are close to the location you are when you type /kill without having a bed spawn. Move far away from there.
- Hit F3+G to show chunk borders.
- Build a repeater clock in such a way that the repeaters are located in two different chunks.
- Now move away from the clock in such a way that the chunk of one repeater is closer than the other. Move away until you can't see either of the repeaters anymore and maybe a little further to be extra sure.
- Now move closer to your clock again. The clock is likely to be suck now.
Why this happens
That happens because when you move away the chunks unload and so do the tile ticks of the repeaters. When you move closer again and the repeater that is in the chunk that was closer to you has a tile tick scheduled for turning on while the other has scheduled a tile tick for turning off, the chunk with the repeater that wants to turn on gets loaded first, the tile tick counts down and gets executed while the other repeater was not loaded the entire time and thus didn't yet turn off. Now both repeaters are turned on and the clock is broken.This is certainly not easy to fix. I think in order to fix this, tile ticks need to be overhauled in general. A system where tile ticks can be "connected" so that if one of them is loaded, the other gets loaded as well might be an option.
Sometimes repeater clocks may freeze due to the way tile ticks are saved and updated. Most cases of that already got fixed and it already got a lot better compared to when the issue was created.
I only manged to find one case were the problem still remains. That is, if you place an ordinary repeater clock with two repeaters in two different chunks.
Steps to reproduce:
- Move to a location outside of the spawn chunks. The spawn chunks are close to the location you are when you type /kill without having a bed spawn. Move far away from there.
- Hit F3+G to show chunk borders.
- Build a repeater clock in such a way that the repeaters are located in two different chunks.
- Now move away from the clock in such a way that the chunk of one repeater is closer than the other. Move away until you can't see either of the repeaters anymore and maybe a little further to be extra sure.
- Now move closer to your clock again. The clock is likely to be stuck now.
Why this happens
That happens because when you move away the chunks unload and so do the tile ticks of the repeaters. When you move closer again and the repeater that is in the chunk that was closer to you has a tile tick scheduled for turning on while the other has scheduled a tile tick for turning off, the chunk with the repeater that wants to turn on gets loaded first, the tile tick counts down and gets executed while the other repeater was not loaded the entire time and thus didn't yet turn off. Now both repeaters are turned on and the clock is broken.This is certainly not easy to fix. I think in order to fix this, tile ticks need to be overhauled in general. A system where tile ticks can be "connected" so that if one of them is loaded, the other gets loaded as well might be an option.
Sometimes repeater clocks may freeze due to the way tile ticks are saved and updated. Most cases of that already got fixed and it already got a lot better compared to when the issue was created.
I only manged to find one case were the problem still remains. That is, if you place an ordinary repeater clock with two repeaters in two different chunks.
Steps to reproduce:
- Move to a location outside of the spawn chunks. The spawn chunks are close to the location you are when you type /kill without having a bed spawn. Move far away from there.
- Hit F3+G to show chunk borders.
- Build a repeater clock in such a way that the repeaters are located in two different chunks.
- Now move away from the clock in such a way that the chunk of one repeater is closer than the other. Move away until you can't see either of the repeaters anymore and maybe a little further to be extra sure.
- Now move closer to your clock again. The clock is likely to be stuck now.
Why this happens
That happens because when you move away the chunks unload and so do the tile ticks of the repeaters. When you move closer again and the repeater that is in the chunk that was closer to you has a tile tick scheduled for turning on while the other has scheduled a tile tick for turning off, the chunk with the repeater that wants to turn on gets loaded first, the tile tick counts down and gets executed while the other repeater was not loaded the entire time and thus didn't yet turn off. Now both repeaters are turned on and the clock is broken.This is certainly not easy to fix. I think in order to fix this, tile ticks need to be overhauled in general. A system where tile ticks can be "connected" so that if one of them is loaded, the other gets loaded as well might be an option.
The bug
Sometimes repeater clocks may freeze due to the way tile ticks are saved and updated. Most cases of that already got fixed and it already got a lot better compared to when the issue was created.
I only manged to find one case were the problem still remains. That is, if you place an ordinary repeater clock with two repeaters in two different chunks.
How to reproduce
- Move to a location outside of the spawn chunks. The spawn chunks are close to the location you are when you type /kill without having a bed spawn. Move far away from there.
- Hit F3 + G to show chunk borders.
- Build a repeater clock in such a way that the repeaters are located in two different chunks.
- Now move away from the clock in such a way that the chunk of one repeater is closer than the other. Move away until you can't see either of the repeaters anymore and maybe a little further to be extra sure.
- Now move closer to your clock again. The clock is likely to be stuck now.
Why this happens
That happens because when you move away the chunks unload and so do the tile ticks of the repeaters. When you move closer again and the repeater that is in the chunk that was closer to you has a tile tick scheduled for turning on while the other has scheduled a tile tick for turning off, the chunk with the repeater that wants to turn on gets loaded first, the tile tick counts down and gets executed while the other repeater was not loaded the entire time and thus didn't yet turn off. Now both repeaters are turned on and the clock is broken.
This is certainly not easy to fix. I think in order to fix this, tile ticks need to be overhauled in general. A system where tile ticks can be "connected" so that if one of them is loaded, the other gets loaded as well might be an option.
Redstoneandcomponentsstay powered after unloading chunksTile ticks of connected redstone componets might be executed in the wrong order when unloading/reloading chunks
The bug
Sometimes repeater clocks may freeze due to the way tile ticks are saved and updated. Most cases of that already got fixed and it already got a lot better compared to when the issue was created.
I only manged to find one case were the problem still remains. That is, if you place an ordinary repeater clock with two repeaters in two different chunks.
How to reproduce
- Move to a location outside of the spawn chunks. The spawn chunks are close to the location you are when you type /kill without having a bed spawn. Move far away from there.
- Hit F3 + G to show chunk borders.
- Build a repeater clock in such a way that the repeaters are located in two different chunks.
- Now move away from the clock in such a way that the chunk of one repeater is closer than the other. Move away until you can't see either of the repeaters anymore and maybe a little further to be extra sure.
- Now move closer to your clock again. The clock is likely to be stuck now.
Why this happens
That happens because when you move away the chunks unload and so do the tile ticks of the repeaters. When you move closer again and the repeater that is in the chunk that was closer to you has a tile tick scheduled for turning on while the other has scheduled a tile tick for turning off, the chunk with the repeater that wants to turn on gets loaded first, the tile tick counts down and gets executed while the other repeater was not loaded the entire time and thus didn't yet turn off. Now both repeaters are turned on and the clock is broken.
This is certainly not easy to fix. I think in order to fix this, tile ticks need to be overhauled in general. A system where tile ticks can be "connected" so that if one of them is loaded, the other gets loaded as well might be an option.
The bug
Sometimes repeater clocks may freeze due to the way tile ticks are saved and updated. Most cases of that already got fixed and it already got a lot better compared to when the issue was created. This happens when the repeaters are in different chunks.
How to reproduce
- Move to a location outside of the spawn chunks. The spawn chunks are close to the location you are when you type /kill without having a bed spawn. Move far away from there.
- Hit F3 + G to show chunk borders.
- Build a repeater clock in such a way that the repeaters are located in two different chunks.
- Now move away from the clock in such a way that the chunk of one repeater is closer than the other. Move away until you can't see either of the repeaters anymore and maybe a little further to be extra sure. You can lower your render distance if you want to make this happening faster.
- Now move closer to your clock again. The clock is likely to be stuck now.
Why this happens
That happens because when you move away the chunks unload and so do the tile ticks of the repeaters. When you move closer again and the repeater that is in the chunk that was closer to you has a tile tick scheduled for turning on while the other has scheduled a tile tick for turning off, the chunk with the repeater that wants to turn on gets loaded first, the tile tick counts down and gets executed while the other repeater was not loaded the entire time and thus didn't yet turn off. Now both repeaters are turned on and the clock is broken.
This is certainly not easy to fix. I think in order to fix this, tile ticks need to be overhauled in general. A system where tile ticks can be "connected" so that if one of them is loaded, the other gets loaded as well might be an option.
Tile ticks of connected redstone components might be executed in the wrong order when unloading/reloading chunks
![[Helper] Lord_Quadrato](../../../data/avatars/users/26105.png){kind=small}
Still able to reproduce for versions 18w11a, 18w14b, 18w15a and 18w16a
Confirmed for 1.13-pre2
is duplicated by
is duplicated by
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
[Mojang] Jeb (Jens Bergensten)![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
Low![[Mod] Greymagic27](../../../data/avatars/users/92875.png){kind=small}
![[Mod] Chandler](../../../data/assets/gravatar/triwonder81.png){kind=small}
![[Mod] Sonicwave](../../../data/avatars/users/94627.png){kind=small}
![[Helper] Johnibur](../../../data/avatars/users/28381.png){kind=small}
[Mod] Chandler wants to marry [Mod] LateLag
DrownedZombie wants to marry Fabian Röling
[~Awesoman3000] wants to marry [Mojang] Adrian Östergård
[Mod] markderickson wants to marry [Mod] Anthony Cicinelli
[Mod] violine1101 wants to marry Dmitry Konev
Galaxy_2Alex wants to marry bugsbugsbugs
[Mod] Avoma wants to marry SlicedBlock
[Mojang] slicedlime wants to marry [Mod] SPGoding
W_V wants to marry [Mod] EVGENSYPERPRO
[Mod] tryashtar wants to marry [Mod] Neko
[Helper] Jack McKalling wants to marry [Mod] redstonehelper
[Mod] Sonicwave wants to marry [Mod] Ezekiel (ezfe).
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
Duplicate of MC-711
Duplicate of MC-711 , please use the search function to see if your bug has already been submitted. Currently over 30% of tickets are being closed as duplicate.
This ticket has been marked as a duplicate of MC-711 , in favor of the better description/information provided.
Duplicate issue of MC-711.
Because the issue relates to redstone, it should be fixed in 1.5 (redstone update). The connected issue (MC-711) will be listed as fixed. If it still persists at that point, be sure to post a comment on the issue to notify that it still occurs. I hope this answers your question.
Duplicate of MC-711, please use the search function to see if your bug has already been submitted. Currently over 45% of tickets are being closed as duplicate.
Duplicate of MC-711, please use the search function to see if your bug has already been submitted. Currently over 45% of tickets are being closed as duplicate.
Duplicate of MC-711, please use the search function to see if your bug has already been submitted. Currently over 50% of tickets are being closed as duplicate.
Duplicate of MC-711.
Duplicate of MC-711, please use the search function to see if your bug has already been submitted. Currently over 51% of tickets are being closed as duplicate.
If you have a very long redstone wire to control power over your very long railway then I guess this report most likely dupes MC-711 or MC-3259 because it's what you are experiencing.
And please study english and stop using automatic translate engines for they are not designed to understand what you say and you are not fit to correct the outcomes of their magic over your input.
Duplicate of MC-711, please use the search function to see if your bug has already been submitted. Currently over 52% of tickets are being closed as duplicate.
Duplicate of MC-711, please use the search function to see if your bug has already been submitted. Currently over 53% of tickets are being closed as duplicate.
It looks like that by fixing MC-711 this bug was fixed as well. The problem does not appear in 13w10b for me anymore. Therefore, this ticket can be marked as resolved.
Part of the issue is that the chunk is getting unloaded.
Is this in SP or MP? If SP, please do not use Optifine, as it will result in the ticket being closed due to mods.
Sounds like a dupe of MC-711 (which is listed as fixed)
Many of the tags added do not relate to the issue.
Time between loading the game should NOT have any effect; it is not considered.
Confirmed for 14w03b using "MC-711 Redstone Bug Test.zip"
tp @p ~500000 ~ ~
(wait a few seconds)
tp @p ~-500000 ~ ~
Some of the circuits will stop working.
EDIT: Not sure how/if I'm able to update the affected versions...
Confirmed for 14w21b using "MC-711 Redstone Bug Test.zip"
tp @p ~500000 ~ ~
(wait a few seconds)
tp @p ~-500000 ~ ~
Some of the circuits will stop working.
*Added screenshot
Worked with a bit of lag, but ok in 1.10.0, now the game crashed. Happened twice in a row. There are about 10 standard "repeater, 2 redstone, repeater, 2 redstone"-clocks that got activated quickly after another, after about half of it the game crashed. Used this to test MC-711.
---- Minecraft Crash Report ---- // You're mean. Time: 22.06.16 17:35 Description: Server forgot to send required information to construct BlockEntity java.lang.RuntimeException: Missing BlockEntity at bqy.b(SourceFile:162) at bqu.a(SourceFile:100) at bqt.b(SourceFile:140) at boh.a(SourceFile:913) at bnz.a(SourceFile:1237) at bnz.b(SourceFile:1171) at bnz.a(SourceFile:1018) at bcx.av(SourceFile:991) at bcx.a(SourceFile:396) at net.minecraft.client.main.Main.main(SourceFile:124) A detailed walkthrough of the error, its code path and all known details is as follows: --------------------------------------------------------------------------------------- -- Head -- Thread: Client thread Stacktrace: at bqy.b(SourceFile:162) -- BlockEntity missing instance data -- Details: BlockState: minecraft:piston_extension[facing=up,type=sticky] Block coordinates: World: (-195,55,23), Chunk: (at 13,3,7 in -13,1; contains blocks -208,0,16 to -193,255,31), Region: (-1,0; contains chunks -32,0 to -1,31, blocks -512,0,0 to -1,255,511) Stacktrace: at bqy.b(SourceFile:162) at bqu.a(SourceFile:100) at bqt.b(SourceFile:140) at boh.a(SourceFile:913) at bnz.a(SourceFile:1237) at bnz.b(SourceFile:1171) -- Affected level -- Details: Level name: MpServer All players: 1 total; [bnn['FaRoGaming'/3, l='MpServer', x=-191,87, y=56,00, z=0,81]] Chunk stats: MultiplayerChunkCache: 81, 81 Level seed: 0 Level generator: ID 01 - flat, ver 0. Features enabled: false Level generator options: Level spawn location: World: (0,56,0), Chunk: (at 0,3,0 in 0,0; contains blocks 0,0,0 to 15,255,15), Region: (0,0; contains chunks 0,0 to 31,31, blocks 0,0,0 to 511,255,511) Level time: 844215 game time, 13000 day time Level dimension: 0 Level storage version: 0x00000 - Unknown? Level weather: Rain time: 0 (now: false), thunder time: 0 (now: false) Level game mode: Game mode: survival (ID 0). Hardcore: false. Cheats: false Forced entities: 8 total; [wk['Rabbit'/1, l='MpServer', x=-175,20, y=56,00, z=38,00], bnn['FaRoGaming'/3, l='MpServer', x=-191,87, y=56,00, z=0,81], aar['Minecart with chest'/5, l='MpServer', x=-229,50, y=56,06, z=2,50], sc['Experience Orb'/6, l='MpServer', x=-211,99, y=56,00, z=5,47], sc['Experience Orb'/7, l='MpServer', x=-208,27, y=56,00, z=3,33], sc['Experience Orb'/8, l='MpServer', x=-208,84, y=56,00, z=3,25], sc['Experience Orb'/9, l='MpServer', x=-210,30, y=56,00, z=4,73], wk['Rabbit'/10, l='MpServer', x=-201,72, y=56,00, z=-28,29]] Retry entities: 0 total; [] Server brand: vanilla Server type: Integrated singleplayer server Stacktrace: at bln.a(SourceFile:364) at bcx.b(SourceFile:2535) at bcx.a(SourceFile:405) at net.minecraft.client.main.Main.main(SourceFile:124) -- System Details -- Details: Minecraft Version: 1.10.1 Operating System: Windows 7 (amd64) version 6.1 Java Version: 1.8.0_25, Oracle Corporation Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation Memory: 99522872 bytes (94 MB) / 277344256 bytes (264 MB) up to 7502823424 bytes (7155 MB) JVM Flags: 6 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx7G -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:-UseAdaptiveSizePolicy -Xmn128M IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0 Launched Version: 1.10.1 LWJGL: 2.9.4 OpenGL: Intel(R) HD Graphics GL version 4.0.0 - Build 9.17.10.2963, Intel GL Caps: Using GL 1.3 multitexturing. Using GL 1.3 texture combiners. Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported. Shaders are available because OpenGL 2.1 is supported. VBOs are available because OpenGL 1.5 is supported. Using VBOs: Yes Is Modded: Probably not. Jar signature remains and client brand is untouched. Type: Client (map_client.txt) Resource Packs: FaRoPack Current Language: English (Australia) Profiler Position: N/A (disabled) CPU: 2x Intel(R) Pentium(R) CPU 2117U @ 1.80GHz
Ok, prepare for something... Could please a mod mark the versions for every bug I tell you here? That would be nice.
I have a world set up for fast bug testing. That means that going into each bug report and saying "Confirmed for 1.10.1" is way more work than actually testing it. So I want to confirm for 1.10.1 with this comment:
MC-4, MC-9, MC-14, MC-87, MC-112, MC-201, MC-212, MC-234, MC-258, MC-460, MC-577, MC-667, MC-679, MC-696, MC-697, MC-849, MC-868, MC-926, MC-957, MC-997, MC-1040, MC-1127, MC-1133, MC-1168, MC-1207, MC-1218, MC-1297, MC-1390, MC-1429, MC-1530, MC-1531, MC-1538, MC-1541, MC-1555, MC-1578, MC-1673, MC-1685, MC-1691, MC-1981 and MC-2023.
All of these are tested in 1.10.1. For some others I have additional information:
MC-711 not testable with my setup because of a crash that's new in 1.10.1.
MC-779: At least some appear outside, didn't test all. What's sure is that no general solution got introduced.
Confirmed MC-1511 for stone button, lever, torch, redstone dust, normal rail, end rod, tripwire hook, ladder and flower pot. Others are untested.
Confirmed MC-1874 for chest, brewing stand, enchanting table and flower pot. Others are untested. It's apparent that there isn't a general solution here either.
https://www.dropbox.com/sh/bwozca6muonl4c8/AAD6_hJemajzzE2S5a9uyiMba
It's a bug testing world sorted by bug number. Just walk to MC-711 and press the button #2. If there are already parts of the redstone active, press button #1 first. Button #3 is for testing MC-711, it's not relevant for this bug.
The bug
Chunks can save some scheduled block update of other chunks in their TileTicks list which are then, once the chunk is loaded, performed too resulting in updates performed twice.
Comments on MC-711 might partwise be describing this bug.
How to reproduce
- Create a superflat world with the following preset
minecraft:sandstone;minecraft:the_void;
- Set the render distance to 6
- Run the following commands
/setworldspawn 100000 0 0 /teleport 110.5 1.0 0.5 /setblock 111 1 0 command_block{Command:"/teleport @p 0 ~ 0 -90 0"} /setblock 110 1 0 stone_button[facing=west] /setblock 110 1 1 dispenser[facing=south]{Items:[{Slot:0b,id:"stone",Count:2b}]} - Press the button
- Move in positive x-direction until you reach the blocks you placed before
→
The dispenser shot out two items
You might have to repeat the reproduction steps multiple times in case the chunk did not unload fast enough.
Code analysis
Based on 1.12.2 decompiled using MCP 9.40
The method net.minecraft.world.WorldServer.getPendingBlockUpdates(Chunk, boolean) creates a bounding box which is extended 2 blocks in the negative x- and z-directions.
It is unclear so far why this was done.
In 19w46b: (Mojang name) net.minecraft.world.level.ServerTickList.fetchTicksInChunk(ChunkPos, boolean, boolean)
I was having a similar problem in an earlier snapshot with a teleporter I'd built. I had it set up so you had to stand on a pressure plate and hit a button simultaneously in order to trigger the command block, then when returning, sometimes either the button or the pressure plate were stuck in the 'on' position, making the teleporter behave incorrectly. This would only happen when teleporting to a location far enough away that the server would unload the chunk the teleporter was in, but it wouldn't happen every time, maybe about 30% of the time. I haven't had this problem since the 1.4 prerelease, but maybe I've just been lucky.
This is because the redstone unloads before it turns off again. A temporary work-around is to do multiple short jumps that still load the redstone, allowing it to turn off.
So instead of:
Teleporter A ===tp 42 chunks==> Place B
Do the following:
Teleporter A ===tp 10 chunks==> Teleporter C ===tp 10 chunks==> Teleporter D ===tp 10 chunks==> Teleporter E ===tp 10 chunks==> Teleporter F ===tp 2 chunks==> Place B
It's tedious, but you'll have to make do with it for now.
btw that work around is relative to the draw distance the server is set up for it can be low as 4 or high as 16chunks.
Which is why I used 10 as an example, as 10 is the default for vanilla servers. I don't think most servers would change it, let alone decrease it (increasing it makes more sense).
This bug will be fixed?
Can confirm this.
Here's my force-crash report.
Will hopefully be fixed soon!
(Crash report attached, see above.)
I have also reproduced this bug: https://mojang.atlassian.net/browse/MC-5019
In 13w02b, I have this problem, except when the chunks load for the first time when loading up the world, my redstone clocks would all stop, either on when it is a short clock, or off when it is a long clock (I use purely repeater and comparator clocks)...
I think this has to do with how the game freezes redstone when the chunk unloads, and it doesn't update when it reloads...
A temporary fix until then would probably be attaching a comparator from the newest snapshot to the area where it happens, since they give constant redstone updates to the block it's pointing at.
Duped it again at
MC-7708. For me, it "freezes" all button in the on position. A chunk update doesn't seem to help. Only thing I can do is remove the button and replace it. However, in some testcases it doesn't freeze, making this bug pretty random.I fixed this by using a comparator next to one of the redstone repeaters
Confirmed in 13w04a
Also confirmed the glitch/bug still exists in 13w04a. Issue occurs once in every ten uses of the command block with /tp command. Stone buttons in the chunk with the "stuck" stone button still operated normally. Crash report located above-
I feel sad now
@sam I tried that too but it didn't work. Probably because the comparator freezes too.
Ok I'm no pro at programming, and I do not know how minecraft works. But can't you just store where a redstone update should be when a chunk unloads. Just like what happens when you save and quit.
It's the TAG_List 'TileTicks' I believe.
@Jesper I think the problem is that the redstone isn't sending the information to update in time before it unloads, because you can walk out of render distance and it will still run fine when you come back, but just jumping out of render distance is the problem. A long-term solution for Mojang could be having redstone, repeaters, comparators, torchs, etc update whenever it's chunk is loaded, though it would cause lag when rendering redstone-heavy chunks, it would fix this problem.
Or cause a delay before unloading a chunk to, like Jesper said, store where the update should be, but, again, lag is an issue here with chunks with a lot of redstone, and having a lot of chunks loaded at one time.
I am not sure about any other bugs that would come because of these aforementioned possible fixes, because I know nothing about Java and the Minecraft coding, but who knows?
Here's some more information:
-It doesn't only happen when you teleport. Fly away from the redstone really far, then just quit to title, come back and then it is also broken.
-Apparently it does or doesn't occur depending on the position of the redstone, for example when I move a clock one block to the right, fly away, quit to title and come back it isn't broken, where it is broken if it is one block to the left.
Issue still persists in Snapshot 13w05a. Reproduced the glitch/bug this time by quitting the game while standing next to a normally functioning stone button beneath command block. Then restarted the game and the same stone button was stuck in the depressed position.
confirmed for 13w05b
Jesper the End,
you're saying that was fixed in 13w05b?
I saw nothing about this bug be fixed in the Mojang site.
And if it was fixed, I have a question, for example: I have a digital clock constructed into my server, it marks 18:27, I walk away 10 chunks him and stay there for 3 minutes, when back toward him, he will still be on 18:27 continuing operating normally, or scoring 18:30 already?
João: Jasper means that this issue is confirmed to still exist in 13w05b.
Oh yeah, thanks.
I have noticed this happen in vanilla servers (the "repeater freezing bug", which was supposedly fixed in 1.4.1, happens to me on vanilla servers occasionally when teleporting, but I have been unable to reproduce it in singleplayer. It seems the "fix" only drastically reduced the rate of this bug for repeaters (I don't know about other redstone components), as this used to happen a lot more frequently in both SMP and SSP before the "fix").
I should also mention that this bug seems to be tied to computer performance: The number of redstone components which freeze seems to vary; when my computer isn't under stress a repeater clock will usually not be effected at all. With a decent amount of stress (and it's hard to get the vanilla server to run without this being the case), there's a slight chance of the leading or trailing repeater in a loop becoming frozen, which can be observed by a repeater clock's pulse being shortened to a single active repeater or lengthened until the pulse is almost the size of the clock itself, respectively. When there's a lot of strain on my computer, a leading freeze becomes more likely, and it's possible to get both edges of the pulse to freeze (thus freezing the clock entirely).
I have a feeling the reason this seems performance-related is because the bug occurs when a tileTicks is not saved as a chunk is unloading. I'm not sure why, but it seems the game misses out on certain tileTicks it was meant to write, as though it's more in a hurry to unload the chunk than it is to make sure everything's written to it first.
And João, if you walk far away enough until the chunks are unloaded, then the clock cannot keep time because its chunks are unloaded and thus the redstone is not being processed. This is true both with and without this bug. With the existence of this bug, your clock is likely to eventually freeze and break down, requiring you to manually look over the redstone and find where the components have frozen (even uglier is the fact that this bug can cause major desynchronization, because it doesn't freeze all components all the time). If this bug is fixed, then yes, your clock would continue from 18:27 operating normally. If you want it to continue from 18:30, you would be forced to build the entire clock within the spawn chunk, which never gets unloaded: only then will it be constantly running and keeping time (incidentally, as it would never be unloaded, this glitch shouldn't ever effect it, unless it also happens during a server restart).
Gerrard Lukacs,
Thanks, but I understand this bug has not been fixed yet, why this is happening to you. And I have an idea to solve the problem: Minecraft could understand that chuncks that has redstone should never stops working, simple as that. What do you think?
That would be a very bad idea, as it would defeat the purpose of chunk loading on large redstone-heavy maps. Chunks are unloaded so your computer doesn't have to handle billions of blocks and thousands of entities at one time. If every chunk with redstone were loaded at all times, a map with a large amount of redstone would lag a lot, and consume excessive amounts of RAM. This also means a larger-than-normal amount of chunks must be loaded when starting up a map.
However, I think it would be nice for map makers and server operators to choose for a chunk to be persistent: that is, force the chunk to be treated like the spawn chunk, and thus be active at all times. There are many neat things you can do by sticking certain redstone mechanics in the spawn chunk as it is, but these do not work in singleplayer (as far as I know). Either way, letting ops and map makers make chunks persistent wouldn't be a fix to this bug, it would be a different feature altogether, and would only be a workaround to this bug.
Making persistence mandatory for redstone chunks, on the other hand, would indeed "fix" this bug, but it would only be a band-aid fix, and with horrible repercussions (also, chunks have to be unloaded when your server or world is stopped, so this bug could still occur when restarting your server or world).
Ah, so the solution would be the creator of the map to choose which chunks would be forced to carry, perhaps by block command, but instead of loading the entire chunk, only the redstone of the chunk would be forced to load. How about that?
I'm not sure "only the redstone of the chunk would be forced to load" makes sense in the context of how Minecraft works. The only way for the game to tell where redstone exists in a chunk is to look at the blocks in the chunk, which would require loading the chunk. The only reason the game can choose what chunks to load is because it knows where to find each chunk - unless you created an "index" of what blocks in a chunk are redstone, there'd be no way to "partially load" the chunk. And even if you did, this wouldn't cover special cases, such as pistons which can push ordinary blocks, which would in turn create their own block updates (consider an automatic cobblestone generator). I don't think it's possible to implement a "load only the redstone", as redstone's very interconnected with the rest of the world - you'd be bound to find dozens of bugs, which would be a major headache to fix.
I think, if they let map makers force certain chunks to be loaded, it should apply to the whole chunk. This would also allow things such as minecarts to run, entities to age, items to despawn, etc. Regardless, letting mapmakers force certain chunks to always be loaded is not a fix to this bug. It is only a workaround, only works for mapmakers and server ops, and it's still possible that this bug would effect such chunks when closing and reopening the world/server (can somebody confirm whether this bug applies to the spawn chunk of your server during a restart?). The only actual purpose of letting mapmakers force chunks to stay loaded is for specific things you might want to build, such as a clock that's always running - such a feature should never be considered a solution to this bug.
As far as actually fixing this bug, I think the proper move is to ensure that redstone devices always save their Tile Ticks when their chunk is unloaded. Tile Ticks tell the game when a block or redstone update is supposed to happen in the future (or should have happened in the past and is overdue) once a chunk has been loaded: they are meant to save activity in a chunk, so things such as flowing water don't freeze just because a chunk got unloaded before the water flowed all the way. This bug appears to be happening because redstone Tile Ticks aren't always saved - particularly during periods of lag. If that can be corrected, this bug should finally be fixed.
Chunk linking tool would be cool too. For instance, a special block: once chunk is loaded that block would ensure that one specific neigbor chunk is loaded as well. This would be useful for machinery that doesn't exactly need to be loaded all of the time, but is bigger than one chunk and needs to be loaded simultaniously in order to properly work.
I don't know too much about Java but, couldn't you just have it so that when a chunk has active redstone in it, it saves the on/off state of the redstone and then when the chunk reloads, it puts the redstone's on/off state back to what it was when it was unloaded?
@Cody:
It already does that. The problem is, it doesnt update the state when the chunks load. Like, it forgot that theres redstone that was working when the chunk unloaded and now it just stays on or off.
@Raphael
Couldn't it be done so that when the chunks reload, they update all the blocks in the chunk.
Yeah Cody! That would work! I think...
That would produce massive lag. Thats what the tileticks are for, when the chunk unloads the tile tick save what blocks need to be updated when the chunk reloads.
The problem is that if the pc/server is under heavy load (which is the case most time you play minecraft), many redstone tile ticks arent saved.
Read Gerrards comment above, he already explained it.
Yeah, forcing updates to all redstone elements in a chunk upon loading would be a bad idea. For one, Tile Ticks can be scheduled: e.g., a repeater with a delay isn't meant to cause a redstone update until after its delay time is up. If you sent redstone updates to everything at once, this would still desynchronize timing-sensitive systems upon chunk loading: even if redstone would no longer freeze, complicated machines would still be damaged.
Lag would also be an issue, as Raphael said: redstone updates actually propagate to about two blocks away from the block that's being updated - I'm not entirely sure, but if everything updated at once, several objects may be updated multiple times in the process, due to an overlap in that 5x5x5 update cube - whether this would have worse consequences than lag, I do not know. At any rate, it would certainly be wasteful; if you have a long line of active repeaters, the ones in the middle do not need any updating - only the ones at the ends do.
I don't think the tile ticks are saved wrongly or something, but I think the problem is that as soon as a chunk gets loaded, the tile ticks are loaded to, but they are not all loaded at the same time, so when you have a simple repeater clock, one repeater gets updated, powering the redstone it is pointing at. And one repeater gets updated too late, so the redstone behind him is already on. In the end all the redstone is powered.
Although this might not be the case, because I've also seen a clock that just was stuck. So a repeater had redstone in the on state behind him, but it didn't get powered.
Yeah, that can't be it, because sometimes components freeze altogether - they never get updated. Also, tile ticks are scheduled events - they have a timer indicating when they should be activated; not every tick is meant to activate the moment a chunk loads (slow things such as max-delay repeaters and flowing lava come to mind).
While your theory seems plausible in some cases, it doesn't match everything I've observed: I have seen a very large repeater loop, with a very large pulse (consuming almost the entire loop) get shortened to a two-repeater pulse, because the leading edge froze and the trailing edge went through the loop until it caused a redstone update to the leading edge. This is not simply a matter of asynchronous loading; the leading edge does not begin to move until it gets a redstone update from the trailing edge.
I think some blocks just won't have a tile tick, because if I move the block one block to the right it doesn't get stuck, so the position of a tile tick has something to do with it. So sometimes one repeater gets updated, but another (since it's on another position) doesn't get updated, causing the clock to be fully powered (or not). And if a clock just completely freezes (one half powered, one half not powered) That's because both tile tick's aren't saved.
Yeah, that's what I think too. I'm not entirely sure it's coordinate-related, but then again, it very well could be (my testing clocks had many different repeaters; I can't be sure whether any one did freeze on one test but didn't on another).
At any rate, it still seems performance related for me - What happens if you lag your computer by running several instances of Minecraft? Does it make the bug more likely for you too? What about the rate on a server compared to the rate in singleplayer?
I do know that lag will affect block updates, as my desktop that my sisters have in their room (don't ask, its mine), when they run minecraft with the dozens of other background programs they have (I seriously regret getting a TV in my room...), their framerate is less than 5-6 fps on low render, regular lighting, etc. (you get the idea) and fluids, gravity blocks and redstone won't update reliably, or not even at all.
(Sorry about the ranting... my sisters seriously messed up my desktop. They even admitted that they get the Blus Screen of Death (windows crash screen) every day)
this needs to be fixed or it will be the end of all adventure maps
I can confirm.
This still needs to be fixed, the problems that redstone is only saved in two ways On/Off so when a chunk is loaded the redstone which was on loads as on and off stays off and they stay that way (like mcediting water and lava nothing happens untill block update) anyway I found this happens for all type of redstone including detector rails and needs to be fixed before 1.5 update.
Seems to be a random occurrence for me, and unrelated to how much my computer is doing. Strange thing for me is that I have several clocks in various places on a test map, yet it's only one specific clock that freezes, no matter how many times I replace the components. As I'm sure is happening with others, if it occurs it completely breaks my adventure map, so hopefully a fix is in the works.
@jason That's exactly what I'm experiencing.
try moving the clock 1 block, that fixes it sometimes.
From what you're saying it seems like the redstone components are in-between chunk boundaries, which is known to cause problems.
I've just tested it on the latest snapshot and this seems to be it.
Here's a video showing the problem: http://www.youtube.com/watch?v=C5Zi6ErzdZ0
EDIT:
Note that the problem isn't that the repeater is crossing a chunk - the problem is that the left pulsar is sitting right on the boundary of 4 different chunks.
but why do all the repeaters inside the chunk get stuck too then? You'd expect them to all turn on/ all turn off
@GrygrFlzr, unfortunately I am unable to replicate. Although my previous clock did border a chunk, I then moved it completely inside a chunk and teleported to and from, and the new clock still froze, yet the one I had problems with previously did not...
Can somebody please update the version information? Mojang probably won't look at this if it's supposedly not in the current snapshots - and this is a very bad bug to have for the 1.5 (pre)release tommorow.
I can confirm this for a server on 13w09b, although it took a few tries. Yes, the server is vanilla.
EDIT: Also, can the title be changed? It's misleading. In 13w09b, I managed to get a repeater clock to fully depower from teleports.
I managed to reproduce it and then I managed to change stuff so I no longer was able to reproduce it... I don't know any other way to properly verify that the bug is gone, or that I haven't added new bugs =( Please re-open this in future snapshots if you're able to find it again.
thx Jeb!
Still occurring for me with 13w09c unfortunately
Unable to reproduce.
Edit: Neither in SSP nor in SMP.
Reopened.
Definitely still happening in 13w09c. Just walking far enough away from a chunk with a redstone clock in it can leave the clock broken.
Still occurring in 13w09c singleplayer survival. To reproduce I need to get far enough to unload my piston clock. After returning to the clock, a repeater is unpowered, although the redstone connected to it is. If you need any other info, comment and I shall provide it.
Confirmed not fixed.
Confirmed not fixed in 13w09c SMP.
This seems to be related to
MC-3259- the underlying problem looks pretty similar: Some redstone components (especially repeaters but also comparators) don't update properly once a chunk gets loaded. A showcase for that problem can be seen in this video: http://www.youtube.com/watch?v=e_MM97ifASwStill experiencing the same issue as described on my Feb 1 post using Snapshot 13w09c in single player mode. Experienced two stuck stone buttons in 22 uses.
I did some more experiments concerncing this issue. I managed to create a pretty simple showcase where you can get some redstone components to get "stuck" easily:
Create a setup like in "chunk-middle-problem-01-basic-setup-repeaters.png". (Note: Make sure to build everything inside a single chunk - marking the edges helps!) Set the command block on the very right to teleport you very far away (at least 10 chunks). Set all other command blocks to trigger "say" commands as shown on the screenshot. Edit: Make sure that the random chunk where you build this is very far away from the spawn as the chunks around the spawn will constantly stay loaded. The problem won't appear there! Teleporting 10000 blocks away from the spawn should bring you far away enough for this.
Stand inside the chunk and then push the button. You'll notice that even though you were teleported away (which means that the teleportation command block must have got fired), not all command blocks in the chunk got fired. Only the "say" command blocks 1-7 were fired (as you can see on the chat window).
When returning to the chunk, you'll see something like in chunk-middle-problem-02-repeaters-behavior.png. All repeaters "behind the chunk's middle" got stuck - which explains why the command blocks were not fired. (Side note: I had actually discovered this chunk middle problem in a different context before and reported it in
MC-8194. The teleportation issue is a new context and therefore another problem type though.)You can also build other kinds of signal transmission methods as shown in the following screenshots - with similar strange effects. (Only the "wire only" transmission method seems to work. The shuffled command block firing order you encounter there might not be considered a real bug because all redstone wire elements could be expected to get fired at the very same time - which makes the firing order undefined and therefore allows a random order.)
it said this was fixed in 13w09c, but it's not
happens on windows vista also
I can't reproduce this. Tried both SMP and SSP, building those examples with command blocks within a chunk. The order of the say commands is unpredictable, but that's because the order in which repeaters are triggered is undefined if they all get the power at the same tick.
Let's keep this open for the 10a snapshot.
Have you been able to try this on a computer under severe strain, or a fairly low-performance computer? I've noticed I only get the bug when I try to force my computer to its limits (to the point that "Server can't keep up! Did the system time change?" messages are being spammed) - I have yet to witness it when there was no lag. The problem is, it becomes more and more likely the more people are on my server (I'll try hosting Super Craft Brothers again in 1.5, as I've noticed it happen quite a bit there; the repeaters don't fully discharge at the end of a match before everyone dies, and they stay frozen active once we return to that map, breaking it).
My method for reproducing this: create a simple redstone repeater clock. A bunch of repeaters in a circle set to 4 ticks with a simple pulse injector to get them going should do the trick. Now leave the chunk (I usually see it by entering the nether and reentering the world in a different chunk). Go back and every now and then the clock will no longer be operating.
It doesn't always happen. On 13w09c, I'm seeing it only rarely.
Just in case it happens to help Jens, here's how I'm seeing it: http://i.cubeupload.com/HzZHSv.png (ignore the background, this is the only place I can reproduce). I think being able to reproduce it is relative to positioning or area, I just have no idea what the conditions are. The reason I think that is because I have several more clocks a couple of hundred blocks or so away (-30, 64, -7 should that matter), that have never ever broken. I've been able to place a clock within around a 50 block radius from the position shown on the screen, a few levels higher or lower too, and I've been able to break it everytime. In order to break I just teleport to and from unloaded chunks a few times and it eventually breaks. For example I'll teleport to -500 64 -500, then 500 64 500 then teleport back to the clocks. If they're not broken I then teleport to -600 64 -600 then 600 64 600, then return and repeat this process as necessary. Though I am able to break clocks in the general area of the screenshot every single time by doing this eventually, as I said before the clocks in the other position have never broken at all, despite the fact they're rather close.
Jason, you may want to upload a zip of your world for Jeb to test, in the event that it actually does turn out to be reproducible at specific coordinates.
couldnt triggering physics on chunk load essentially fix this?
@Aikar: Be very careful with that. Triggering physics on chunk load runs the real risk of breaking a lot of devices, since it would mean triggering block updates for no reason other than that the chunk loaded. A better solution would be to defer unloading a chunk until all redstone behavior is in a safe state.
Confirmed not fixed for 13w10a. Here's a (pretty long) video demonstrating the bug: https://youtu.be/95fuuajDQMc
(At the moment of posting this, the upload is still in progress. The video should be up at around 00:20 UTC+1.)After watching the video you can try to reproduce the bug in my test world which I attached to this ticket.
Video upload and (first stage) processing complete; you can watch the video here: https://youtu.be/95fuuajDQMc
I have a map with 100% reproduction rate. I saved next to the clock. Just cut and reconnect the redstone wire to the repeater in question. Then grab the nearby boat and go far enough to unload the entire clock. After returning a repeater is always stuck in unpowered.
https://www.dropbox.com/s/j3wahkk8l0nky1z/Copy%20of%20Jamen.zip?m
The.Modificator, you sir are a gentleman and a scholar. I can reproduce your behavior completely on my computer; I see I was wrong to figure it had anything to do with lag (perhaps the fact that I was using circular repeater/comparator clocks caused the apparently "random" behavior because the repeaters would only freeze at certain locations, and the fact that I was teleporting pretty much continuously back and forth meant the chunks did not always unload). Your world download has a 100% reproduction rate for me - this will almost certainly help Jeb fix the bug, as you've sequestered it and analyzed its mechanics.
I should note, however, that the pure redstone wire test does not trigger all command blocks, as you said it did - the fourteenth never triggered. Fortunately, this is the same for me as it is for you - the bug's consistent.
Thanks for the help. I was able to use The.Modificator's world and stop the random behavior. Problem turned out to be that when ticks are scheduled, they are thrown away if the neighboring chunks haven't been loaded yet. Removing this check fixed the problem, and I couldn't discover any new errors.
I'm marking this as resolved, please reopen it if the bug occurs again in the next snapshot.
No longer able to replicate the bug under 13w10b. My hero <3
Looks great!
It appears that
MC-3259was fixed as well by fixing this. Thanks, Jeb!@Gerrard Lukacs: You're right - I didn't notice that in my demonstration world the command block with "say 14" was never triggerd when using the wire-only setup. However, I just realized that the cable is just too long to actually reach it. So another mystery solved.
Also thanks a lot for your great feedback.
(again) thx Jeb!
I'm sorry to bother this thread but I'm using 1.5 and it still seems to be happening to me constantly. Well really what happens is I attached a button to a block of stone. Then I put a redstone wire coming out of the block of stone and 21 repeaters following the wire. If I use a pressure plate button or trip wire the repeaters randomly freeze around the 10-15th repeater it gets a bit annoyting. Just saying and I'll attach a screenshot
The repeaters still freeze in 1.5. for some strange reason. I read that it was fixed but it still doesn't seem to be fixed for me.
@Megan:
Without teleporting?
And what is your system? That screenshot has an unusual resolution.
Well I'm not exactly very good with computer so it took me a while to figure out how to use the clip board. so I went on word and I just pasted it onto word then I just copied it back to my clip board. I was in creative mode (so I forgot to mention that) My system? I have a Windows 7 if that's what you mean. I was just flying around and I wasn't teleporting.
Im unable to recreate that, but this also seems to be not related to this bug, because your repeaters stop while youre still there.
With system i meant, are you using a normal desktop pc with Windows 7?
@megan can you give us with the map?
@Jesper It's just a single player world but the seed is 764906023386979050 and the Coordinates are x:-1538 y:56 z:98 (although the coordinates may not help much. It was on a super flat world and I was messing around wiht redstone so it wasn't redstone lag but after I teleported to a new chunk it didn't occur as often. @Raphael My bad I always forget to put things, it's not a desktop it's a laptop that is Windows 7. Plus I did try to reproduce this bug and the redstone still froze but not very long. The repeater signal kind of just stood still and then went the signal was further away but I've fixed the problem a little.
sounds more like lagg then.
I just found a frozen comparator clock (as shown in screenshot "comparator-stuck.png) in a dedicated server world (version 1.5 for both client and server). I removed all chunks not related to the problem (with MCEdit) and uploaded a zipped version of the world as "comparator-stuck.zip". The frozen comparator is located at 54/58/-31
Unfortunatley I have absolutely no clue how to re-produce this. It used to occur a few times before but always happens seemingly randomly. With the comparator clock cable lying on a chunk border my guess would be that it has to do something with unloading and loading chunks - especially with multiple players moving around in the world.
I also have a feeling that this used to happen only when restarting the server. (And I also have a feeling that the chunks in which the comparator clock is located were not be loaded in the moment the server shut down.)
This problem already used to occur before the change in 13w10b. This version 1.5 occurence proves that the 13w10b change did not help in this case though.
The odd thing is that they never fixed it...
This bug has not been fixed. All of my redstone clocks keep freezing in 1.5.1. It doesn't happen as often. It used to happen every time a chunk was reloaded, but now it seems fairly random.
I've not seen this happen in 1.5.1 but I do get a lot of messages of people who can't play my map anymore because the clocks stopped
I should mention that this bug is not fixed in Bukkit, and many people like to play maps in Bukkit (one of the more appealing features, ahem, is preventing cheating).
Stephen, are you in Bukkit, a vanilla server, or singleplayer? If it's not Bukkit, it may be worth Mojang's (and everyone's) time for you to create a world download containing some of the redstone. You can prune a copy of your world down to the effected chunks in MCedit if you don't want to share your whole world - just be sure there is a sample of frozen redstone in there.
I finally came back to this thread but @Jesper I wasn't lagging at all my frames were better than usual but I stopped messing w/ redstone (because I accidentally deleted the world...). By the way is it possible for me to leave the thread that way I'm not emailed about this because my problem is "resolved" by not using redstone...
@Megan At the top-right, click "Stop watching this issue".
Can someone reopen this? this is still an issue in 1.5.1
@Gerrard Thanks
Sorry Gerrard for the late response. This has happened to me on single player maps and multiplayer maps, both of which were vanilla. It doesn't happen often, but I will attempt to upload a schematic the next time I encounter the issue.
Confirmed for 1.5.1 Vanilla Singleplayer - this bug is not actually fixed. I'll upload a demonstration world shortly, but I am unable to devise a pattern in the bug's occurrence - it seems more likely at chunk borders, but can occur anywhere within a chunk as well.
It's not as detailed as The.Modificator's test, but it shows the bug. Use the command block to teleport far away, and then back, and you'll find a seemingly random number of clocks have frozen. The clocks which freeze varies each time you try.
This time, all clocks freeze in powered state: there are no clocks which freeze to an unpowered state.
Confirmed with the attached world.
I'm glad that Mojang finally reopened this.
This is also a problem on Mac to.
MCedit indicates that the clocks are frozen once the chunks are unloaded, rather than upon reload: teleporting, and then saving and quitting, and opening the world in MCedit shows a sight identical to what you would see upon teleporting back.
It should be noted that tileticks do not get saved properly for the clocks which freeze. All healthy clocks have at least one tiletick per repeater - some, strangely, can have two tileticks on a single repeater. A clock with only a single repeater bearing tileticks, or none at all, will be frozen, and MCedit will already render all its redstone as active. My record appears to be five tileticks in a single clock (one repeater has two, the other has three), and this clock is healthy and runs a half-tick pulse.
Why so many tileticks are saved for some blocks, and none at all for others, I do not know. Apparently tiletick saving is asynchronous? Perhaps, when a chunk is to be unloaded, all activity in that chunk should stop before attempting to save any tileticks? I.e. does it stop processing ticks in the chunk altogether before attempting to save it to disk?
Someone please add Mac to the environment list.
Here's what happens to me:
When I make a redstone machine that repeats itself over and over it freezes wnhen the chunks are unloaded.It also happens on a mac.
Snapshot 13w10b did not fix this issue.
I'm haven't experienced this bug in the past month (or since 1.5.2). Is anyone else still experiencing this issue?
@John Stewart
I have
Jeb thinks he's fixed it. idk I haven't tested the dev versions.
Confirmed for 1.5.2; haven't tested on the snapshots.
Confirmed for 1.6.2; I'm starting to resort to abusing chunk loading bugs as a workaround to this issue.
Confirmed for 14w03b using "MC-711 Redstone Bug Test.zip"
tp @p ~500000 ~ ~
(wait a few seconds)
tp @p ~-500000 ~ ~
Some of the circuits will stop working.
EDIT: Not sure how/if I'm able to update the affected versions...
Is this still a concern in the latest Minecraft version 14w21b? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
I've not seen this bug in a long time, but I'm pretty sure it's not fixed. Though I can't confirm that.
Confirmed for 14w21b using "MC-711 Redstone Bug Test.zip"
tp @p ~500000 ~ ~
(wait a few seconds)
tp @p ~-500000 ~ ~
Some of the circuits will stop working.
*Added screenshot
Ahh yes, I have seen this bug in my 1.7.2 map.
Confirmed of 1.8.2-pre1.
Here's a bunch of stuff that might help the developers out.
1) Reloading the world doens't seem to cause any issues, redstone always continues.
2) Running away from the chunks, the walking back, causes all the 20Hz redstone clocks to stop. It will stop all redstone clocks if you unload at the right tick.
3) Teleporting away from the chunks, then teleporting back, causes a specific position of redstone clocks to stop. Every chunk seems to have some sort of binary yes/no value, that defines whether or not a redstone clock stops if unloaded in the correct tick when you teleport away. http://imgur.com/pqnreZg this is a visualisation of all chunks that stop. Wherever water spilled, clocks in that chunk stopped. The most bottomleft chunk is (-1,-1), going up X to the left and up Z upwards. Notice that wherever chunkPosX = chunkPosZ the clocks do not stop.
How to reproduce: Setup a 20hz fill clock. Put two command blocks on it. One sets a block to flowing water, somewhere up in the air. Surround the flowing water by glass on all corresponding Y positions to prevent it from spilling to the sides. The second command block sets the block below the flowing_water block to air. Whenever the fill clock stops running, the water spills everywhere.
Something else to note, according to the command block output, it seems that redstone updates process one tick after the chunk blocks unload. This causes all redstone activity to give a "can't access stuff outside the world" error, and so the clock stops. If the clock continues, the redstone is saved as a tiletick (like it should), but if it stops, the command blocks show the "can't access stuff outside the world error", and only the water gets saved as a tiletick. I've been digging in the decompiled code for a bit, but my java knowledge isn't good enough to really find out what's causing this behavior.
All of the powered ones stayed powered/
The ones that look off are running
The picture with two, they are both in two different chunks but the bottom one is oriented differently.
Also 2 of the failed clocks are setting on 0,0,0 of their respective chunk. I don't know if that is just a coincidence or if it really does have something to do with it all. I did the second one purpose and it stopped right away (after flying a long distance and tried one with tp far away)
Hope this is of some use.
@Mods I don't know if this has anything to do with it but if the redstone clock is on the edge of a chunk and takes up space in two chunks, this has a higher chance of happening. and in two of my experiments, two of the failed clocks were on chunk coords 0,0,0 of whatever chunk it was in. I was looking at chunks 150 and 149. I took pictures and attached them. I was unable to get this to replicate with hoppers though. Something cause them to either duplicate items randomly or with using unstackable items,, the item goes super fast that the comparator doesn't have time to react.
Why don't you have a main teleport station where you set the world spawnpoint by using /setworldspawn. That means that your teleport station will always be loaded, even if you are in another dimention. All the other teleport stations can use the /setblock command to place a redstone block at the main station, which can teleport the player and reset the station the player used.
I just thought if this still mattered to you, this can be a workaround.
Why doesn't Minecraft just summon an invisible entity for all the redstone components that can keep redstone running, even if the chunk is unloaded. That would be a help to everyone.
Dylan Beswick, not really. That would keep all chunks in large redstone maps loaded forever, which would result in massive lag. Chunks are unloaded for a reason.
That wouldn't be my approach. Best way to implement that would be to add a gamerule or a way to enable and disable that feature, if it were added.
Confirmed for 1.10.
Sorry if this was somewhere in the last 100+ comments already, but: Could it be location dependent? I reproduced this more than 50% of the time before, now I can't get it to ever happen, after I moved it.
I found through searching:
Nobody is sure? Is that still the case? I also wasn't able to find a code analysis.
I can confirm for 1.12.2 and I am very confident that I know when and why it happens.
To reproduce that bug, just set up an ordinary repeater clock. Make sure that the two repeaters are in different chunks
Now move away so that one chunk is closer to you than the other. When you are far enough away and you cannot see any of the repeaters, press esc to trigger chunk unloading. When you now move closer again, you have a chance that the repeater clock is now stuck. For me it actually happened every time I tested it.
The reason that happens is that the repeater in the chunk a little further away from you had a tick scheduled for turning off and the repeater that is closer to you for turning on. What happens is that the repeater with a tile tick scheduled for turning on loads and executes its tile tick while the other repeater is still unloaded and does not continue counting down it's tile tick until the first repeater turns of, causes block updates and thus load the unloaded chunk with the other repeater. The repeater will than not turn off since it is receiving power.
[Mod] NeunEinser: ticket is yours now. Please update it accordingly. Thanks!
Oh thank you!
I updated the description with what I found out.
I'm unable to reproduce, even though I think I've seen it recently. Does someone know a reliable way to reproduce it?
Is this still an issue in 1.14.4 or later?
Fabian Röling I can still reproduce the issue with the steps from above. Because of the aggressive unloading in 1.14, you don't even need to trigger an autosave
Another setup related to this bug is this:
The repeater on the left is placed towards the negative x, the other one to the positive x. The 2 repeaters on the left are on one tick, the one on the right on two ticks.
Usually the command block on the right will trigger first, because the tile tick of the 2-tick repeater scheduled first.
If you pause the game at the exact moment when the first 1-tick repeater is activated, but none of the others and then Save & Quit, the activation order will differ.
Can confirm for 1.16.1
Can confirm for 20w51a.
Can confirm in 1.17.1.
can confirm in 1.18.1
Can confirm in 1.19.3
Can confirm in 23w03a
Can confirm in 23w04a
Can confirm in 23w06a
Can confirm in 1.20.1