Henrik Lindström
- henke9600
- henke9600
- Europe/Stockholm
- Yes
- No
MC-2340![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
![[Mojang] Jeb (Jens Bergensten)](../../../data/assets/gravatar/jeb.jpeg){kind=small}
This is a very annoying glitch that causes redstone torches to seem instant in some situations.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to activate.What actually happened was...:
The torch activated instantly as it got power.Steps to Reproduce:
Build the simple monostable in the attached picture.Press the button and notice how the left torch only is on for 1 redstonetick even though the wire powering it is off for 2 redstoneticks.
What's happening is that the torch is turing off instantly as it gets power again from the bottom repeater.
(Note that there are other cases where the torches will activate instantly or even both).
Here's a video i made before about this:
http://www.youtube.com/watch?v=DIB5iAhjeL8
Reason
The reason for this glitch is that torches doesn't do any checks before scheduling their blockupdate.
So, for example: If any neighboring blocks to the torch update and the torch gets power a redstonetick later it will immediatly turn off.Fix
There's a very simple fix to this that i did with adding 2 lines of code to the sourceThe torch should only schedule an update when it is: active and not powered and when it is: inactive and powered.
This is a very annoying glitch that causes redstone torches to seem instant in some situations.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to activate.What actually happened was...:
The torch activated instantly as it got power.Steps to Reproduce:
Build the simple monostable in the attached picture.Press the button and notice how the left torch only is on for 1 redstonetick even though the wire powering it is off for 2 redstoneticks.
What's happening is that the torch is turing off instantly as it gets power again from the bottom repeater.
(Note that there are other cases where the torches will activate instantly or even both).
Here's a video i made before about this:
http://www.youtube.com/watch?v=DIB5iAhjeL8
Reason
The reason for this glitch is that torches doesn't do any checks before scheduling their blockupdate.
So, for example: If any neighboring blocks to the torch update and the torch gets power a redstonetick later it will immediatly turn off.Fix
There's a very simple fix to this that i did with adding 2 lines of code to the sourceThe torch should only schedule an update when it is: active and not powered and when it is: inactive and powered.
This is a very annoying glitch that causes redstone torches to seem instant in some situations.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to activate.What actually happened was...:
The torch activated instantly as it got power.Steps to Reproduce:
Build the simple monostable in the attached picture.Press the button and notice how the left torch only is on for 1 redstonetick even though the wire powering it is off for 2 redstoneticks.
What's happening is that the torch is turing off instantly as it gets power again from the bottom repeater.
Here's a video i made before about some of this:
http://www.youtube.com/watch?v=DIB5iAhjeL8
(Note that there are other cases where the torches will activate instantly or even both).
Reason
The reason for this glitch is that torches doesn't do any checks before scheduling their blockupdate.
So, for example: If any neighboring blocks to the torch update and the torch gets power a redstonetick later it will immediatly turn off.Fix
There's a very simple fix to this that i did with adding 2 lines of code to the sourceThe torch should only schedule an update when it is: active and not powered and when it is: inactive and powered.
This is a very annoying glitch that causes redstone torches to seem instant in some situations.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to activate.What actually happened was...:
The torch activated instantly as itgot power.Steps to Reproduce:
Build the simple monostable in the attached picture.Press the button and notice how the left torch only is on for 1 redstonetick even though the wire powering it is off for 2 redstoneticks.
What's happening is that the torch is turing off instantly as it gets power again from the bottom repeater.
Here's a video i made before about some of this:
http://www.youtube.com/watch?v=DIB5iAhjeL8
(Note that there are other cases where the torches will activate instantly or even both).
Reason
The reason for this glitch is that torches doesn't do any checks before scheduling their blockupdate.
So, for example: If any neighboring blocks to the torch update and the torch gets power a redstonetick later it will immediatly turn off.Fix
There's a very simple fix to this that i did with adding 2 lines of code to the sourceThe torch should only schedule an update when it is: active and not powered and when it is: inactive and powered.
This is a very annoying glitch that causes redstone torches to seem instant in some situations.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as it lost power.Steps to Reproduce:
Build the simple monostable in the attached picture.Press the button and notice how the left torch only is on for 1 redstonetick even though the wire powering it is off for 2 redstoneticks.
What's happening is that the torch is turing off instantly as it gets power again from the bottom repeater.
Here's a video i made before about some of this:
http://www.youtube.com/watch?v=DIB5iAhjeL8
(Note that there are other cases where the torches will activate instantly or even both).
Reason
The reason for this glitch is that torches doesn't do any checks before scheduling their blockupdate.
So, for example: If any neighboring blocks to the torch update and the torch gets power a redstonetick later it will immediatly turn off.Fix
There's a very simple fix to this that i did with adding 2 lines of code to the sourceThe torch should only schedule an update when it is: active and not powered and when it is: inactive and powered.
This is a very annoying glitch that causes redstone torches to seem instant in some situations.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as it lost power.Steps to Reproduce:
Build the simple monostable in the attached picture.Press the button and notice how the left torch only is on for 1 redstonetick even though the wire powering it is off for 2 redstoneticks.
What's happening is that the torch is turing off instantly as it gets power again from the bottom repeater.
Here's a video i made before about some of this:
http://www.youtube.com/watch?v=DIB5iAhjeL8
(Note that there are other cases where the torches will activate instantly or even both).
Reason
The reason for this glitch is that torches doesn't do any checks before scheduling their blockupdate.
So, for example: If any neighboring blocks to the torch update and the torch gets power a redstonetick later it will immediatly turn off.Fix
There's a very simple fix to this that i did with adding 2 lines of code to the sourceThe torch should only schedule an update when it is: active and not powered and when it is: inactive and powered.
This is a
very annoyingglitch thatcauses redstone torches toseeminstant insome situations.What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as itlostpower.Steps to Reproduce:
Buildthe simple monostable in the attached picture.
Pressthebutton and notice how the left torch only is on for 1 redstonetick even though the wire powering it is off for 2 redstoneticks.
What's happening is that the torch isturingoff instantly as itgets poweragain from the bottom repeater.Here's a video i made before about some of this:
http://www.youtube.com/watch?v=DIB5iAhjeL8
(Note that there are other cases where the torches will activate instantly or even both).
Reason
The reason for this glitch is that torches doesn't do any checks before scheduling their blockupdate.
So, for example: If any neighboring blocks to the torch update and the torch gets power a redstonetick later it will immediatly turn off.Fix
There's a very simple fix to this that i did with adding 2 lines of code to the sourceThe torch should only schedule an update when it is: active and not powered and when it is: inactive and powered.
This is a glitch that allows redstone torches to turn off instantly in few cases.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as it was powered.Steps to Reproduce:
Build what is in the picture and notice how the torch only outputs a 1 tick long signal. (Instead of the expected 2 ticks).This happens when the torch is updated(in this case by the redstone wire) the same tick it turns on which have to be 1 tick before the torch gets power again.
The torch will then turn off instantly as it is powered.
This is a glitch that allows redstone torches to turn off instantly in few cases. It was nearly fixed in the 1.5 snapshot but it still exists.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as it was powered.Steps to Reproduce:
Build what is in the picture and notice how the torch only outputs a 1 tick long signal. (Instead of the expected 2 ticks).This happens when the torch is updated(in this case by the redstone wire) the same tick it turns on which have to be 1 tick before the torch gets power again.
The torch will then turn off instantly as it is powered.
This is a glitch that allows redstone torches to turn off instantly in few cases. It was nearly fixed in the 1.5 snapshot but it still exists.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as it was powered.Steps to Reproduce:
Build what is in the picture and notice how the torch only outputs a 1 tick long signal. (Instead of the expected 2 ticks).This happens when the torch is updated(in this case by the redstone wire) the same tick it turns on which have to be 1 tick before the torch gets power again.
The torch will then turn off instantly as it is powered.
Also, something that might be related to this is that pistons which recieves a pulse of 1 gametick dropp their block instantly.
This is a glitch that allows redstone torches to turn off instantly in few cases. It was nearly fixed in the 1.5 snapshot but it still exists.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as it was powered.Steps to Reproduce:
Build what is in the picture and notice how the torch only outputs a 1 tick long signal. (Instead of the expected 2 ticks).This happens when the torch is updated(in this case by the redstone wire) the same tick it turns on which have to be 1 tick before the torch gets power again.
The torch will then turn off instantly as it is powered.
Also, something that might be related to this is that pistons which recieves a pulse of 1 gametick drop
ptheir block instantly.This is a glitch that allows redstone torches to turn off instantly in few cases. It was nearly fixed in the 1.5 snapshot but it still exists.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as it was powered.Steps to Reproduce:
Build what is in the picture and notice how the torch only outputs a 1 tick long signal. (Instead of the expected 2 ticks).This happens when the torch is updated(in this case by the redstone wire) the same tick it turns on which have to be 1 tick before the torch gets power again.
The torch will then turn off instantly as it is powered.
Also, something that might be related to this is that pistons which recieves a pulse of 1 game tick drop their block instantly.
2012-11-04_18.50.56.png
This is a glitch that allows redstone torches to turn off instantly in few cases. It was nearly fixed in the 1.5 snapshot but it still exists.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as it was powered.Steps to Reproduce:
Build what is in the picture and notice how the torch only outputs a 1 tick long signal. (Instead of the expected 2 ticks).This happens when the torch is updated(in this case by the redstone wire) the same tick it turns on which have to be 1 tick before the torch gets power again.
The torch will then turn off instantly as it is powered.
Also, something that might be related to this is that pistons which recieves a pulse of 1 game tick drop
theirblock instantly.This is a glitch that allows redstone torches to turn off instantly in few cases. It was nearly fixed in the 1.5 snapshot but it still exists.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as it was powered.Steps to Reproduce:
Build what is in the picture and notice how the torch only outputs a 1 tick long signal. (Instead of the expected 2 ticks).This happens when the torch is updated(in this case by the redstone wire) the same tick it turns on which have to be 1 tick before the torch gets power again.
The torch will then turn off instantly as it is powered.
Also, something that might be related to this is that pistons which recieves a pulse of 1 game tick drop its block in just 1 game tick compared to the expected 3..
This is a glitch that allows redstone torches to turn off instantly in few cases. It was nearly fixed in the 1.5 snapshot but it still exists.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as it was powered.Steps to Reproduce:
Build what is in the picture and notice how the torch only outputs a 1 tick long signal. (Instead of the expected 2 ticks).This happens when the torch is updated(in this case by the redstone wire) the same tick it turns on which have to be 1 tick before the torch gets power again.
The torch will then turn off instantly as it is powered.
Also, something that might be related to this is that pistons which recieves a pulse of 1 game tick drop its block in
just 1 game tick compared to the expected 3..This is a glitch that allows redstone torches to turn off instantly in few cases. It was nearly fixed in the 1.5 snapshot but it still exists.
What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as it was powered.Steps to Reproduce:
Build what is in the picture and notice how the torch only outputs a 1 tick long signal. (Instead of the expected 2 ticks).This happens when the torch is updated(in this case by the redstone wire) the same tick it turns on which have to be 1 tick before the torch gets power again.
The torch will then turn off instantly as it is powered.
Also, something that might be related to this is that pistons which recieves a pulse of 1 game tick drop its block instantly .-.
Redstone torches- Weird timing issues, torches appear instant in somesituations!Redstone torches are instant in some cases.
This is a
glitch that allows redstone torches to turn off instantly in few cases. It was nearly fixed in the 1.5 snapshot but it still exists.What I expected to happen was...:
I excpected the torch to take 1 redstonetick to deactivate.What actually happened was...:
The torch deactivated instantly as it was powered.Steps to Reproduce:
Build what is in the picture and notice how the torch only outputs a 1 tick long signal. (Instead of the expected 2 ticks).
This happens when the torch isupdated(in this case by theredstone wire) the sametickit turns on which have to be 1 tick before the torch gets power again.
The torch will then turn off instantly as it is powered.
Also, something that might be related to this is that pistons which recieves a pulse of 1 game tick drop its block instantly .-.This is a bug that was nearly fixed for torches and completely exists for comparators.
The original bug which now affects comparators is that when updated, they will schedule an update even if they are in the right state.
So, if things have changed during the time they were waiting for that scheduled update, they will react to the change as soon as it "arrives".
Which can be sooner than 2 gameticks(The intended timing) after the actual change.In the first comparator picture, i'm updating the comparator with a redstone wire 2 gameticks(Repeater delay) before it gets power. This allows it to output power instantly as it gets power.(As you can see it's 2 gameticks too fast).
In the second picture i'm not updating the comparator before it receives power and as you see it works as expected.
Now, redstone torches are better but still have the problem.
If a torch is updated at the same time as it looses power and it's powered 2 gameticks after that. The torch will turn off instantly.
This is demonstrated in the torch monostable picture. The redstone wire going to the side updates the torch.
Basically, torches and definately comparators need to check if an updated actually should be scheduled before doing so
Redstone torches are instant in some cases.Redstone torches and comparators schedule updates when they should not. Causing unreliable timings.
This is a bug that was nearly fixed for torches and completely exists for comparators.
The original bug which now affects comparators is that when updated, they will schedule an update even if they are in the right state.
So, if things have changed during the time they were waiting for that scheduled update, they will react to the change as soon as it "arrives".
Which can be sooner than 2 gameticks(The intended timing) after the actual change.In the first comparator picture, i'm updating the comparator with a redstone wire 2 gameticks(Repeater delay) before it gets power. This allows it to output power instantly as it gets power.(As you can see it's 2 gameticks too fast).
In the second picture i'm not updating the comparator before it receives power and as you see it works as expected.
Now, redstone torches are better but still have the problem.
If a torch is updated at the same time as it looses power and it's powered 2 gameticks after that. The torch will turn off instantly.
This is demonstrated in the torch monostable picture. The redstone wire going to the side updates the torch.
Basically, torches and definately comparators need to check if an update
dactually should be scheduled before doing so
This is a bug that was nearly fixed for torches and completely exists for comparators.
The original bug which now affects comparators is that when updated, they will schedule an update even if they are in the right state.
So, if things have changed during the time they were waiting for that scheduled update, they will react to the change as soon as it "arrives".
Which can be sooner than 2 gameticks(The intended timing) after the actual change.In the first comparator picture, i'm updating the comparator with a redstone wire 2 gameticks(Repeater delay) before it gets power. This allows it to output power instantly as it gets power.(As you can see it's 2 gameticks too fast).
In the second picture i'm not updating the comparator before it receives power and as you see it works as expected.
Now, redstone torches are better but still have the problem.
If a torch is updated at the same time as it looses power and it's powered 2 gameticks after that. The torch will turn off instantly.
This is demonstrated in the torch monostable picture which will output a 2 gametick long pulse instead of the expected 4 long thanks to this. The redstone wire going to the side updates the torch.
Basically, torches and definately comparators need to check if an update actually should be scheduled before doing so
This is a bug that was nearly fixed for torches and completely exists for comparators.
The original bug which now affects comparators is that when updated, they will schedule an update even if they are in the right state.
So, if things have changed during the time they were waiting for that scheduled update, they will react to the change as soon as it "arrives".
Which can be sooner than 2 gameticks(The intended timing) after the actual change.In the first comparator picture, i'm updating the comparator with a redstone wire 2 gameticks(Repeater delay) before it gets power. This allows it to output power instantly as it gets power.(As you can see it's 2 gameticks too fast).
In the second picture i'm not updating the comparator before it receives power and as you see it works as expected.
Now, redstone torches are better but still have the problem.If a torch is updated at the same time as it looses power and it's powered 2 gameticks after that. The torch will turn off instantly.
This is demonstrated in the torch monostable picture which will output a 2 gametick long pulse instead of the expected 4 long thanks to this. The redstone wire going to the side updates the torch.
Basically, torches and defin
ately comparators need to check if an update actually should be scheduled before doing soThis is a bug that was nearly fixed for torches and completely exists for comparators.
The original bug which now affects comparators is that when updated, they will schedule an update even if they are in the right state.
So, if things have changed during the time they were waiting for that scheduled update, they will react to the change as soon as it "arrives".
Which can be sooner than 2 gameticks(The intended timing) after the actual change.In the first comparator picture, i'm updating the comparator with a redstone wire 2 gameticks(Repeater delay) before it gets power. This allows it to output power instantly as it gets power.(As you can see it's 2 gameticks too fast).
In the second picture i'm not updating the comparator before it receives power and as you see it works as expected.
Redstone torches are better but still have the problem.
If a torch is updated at the same time as it looses power and it's powered 2 gameticks after that. The torch will turn off instantly.
This is demonstrated in the torch monostable picture which will output a 2 gametick long pulse instead of the expected 4 long thanks to this. The redstone wire going to the side updates the torch.
Basically, torches and definetely comparators need to check if an update actually should be scheduled before doing so
This is a bug that was nearly fixed for torches and completely exists for comparators.
The original bug which now affects comparators is that when updated, they will schedule an update even if they are in the right state.
So, if things have changed during the time they were waiting for that scheduled update, they will react to the change as soon as
it "arrives".
Which can be sooner than 2 gameticks(The intended timing) after the actual change.In the first comparator picture, i'm updating the comparator with a redstone wire 2 gameticks(Repeater delay) before it gets power. This allows it to output power instantly as it gets power.(As you can see it's 2 gameticks too fast).
In the second picture i'm not updating the comparator before it receives power and as you see it works as expected.
Redstone torches are better but still have the problem.
If a torch is updated at the same time as it looses power and it's powered 2 gameticks after that. The torch will turn off instantly.
This is demonstrated in the torch monostable picture which will output a 2 gametick long pulse instead of the expected 4 long thanks to this. The redstone wire going to the side updates the torch.
Basically, torches and definetely comparators need to check if an update actually should be scheduled before doing so
This is a bug that was nearly fixed for torches and completely exists for comparators.
The original bug which now affects comparators is that when updated, they will schedule an update even if they are in the right state.
So, if things have changed during the time they were waiting for that scheduled update, they will react to the change as soon as that update arrives.
Which can be sooner than 2 gameticks(The intended timing) after the actual change.In the first comparator picture, i'm updating the comparator with a redstone wire 2 gameticks(Repeater delay) before it gets power. This allows it to output power instantly as it gets power.(As you can see it's 2 gameticks too fast).
In the second picture i'm not updating the comparator before it receives power and as you see it works as expected.
Redstone torches are better but still have the problem.
If a torch is updated at the same time as it looses power and it's powered 2 gameticks after that. The torch will turn off instantly.
This is demonstrated in the torch monostable picture which will output a 2 gametick long pulse instead of the expected 4 long thanks to this. The redstone wire going to the side updates the torch.
Basically, torches and definetely comparators need to check if an update actually should be scheduled before doing so
This is a bug that was nearly fixed for torches and completely exists for comparators.
The original bug which now affects comparators is that when updated, they will schedule an update even if they are in the right state.
So, if things have changed during the time they were waiting for that scheduled update, they will react to the change as soon as that update arrives.
Which can be sooner than 2 gameticks(The intended timing) after the actual change.In the first comparator picture, i'm updating the comparator with a redstone wire 2 gameticks(Repeater delay) before it gets power. This allows it to output power instantly as it gets power.(As you can see it's 2 gameticks too fast).
In the second picture i'm not updating the comparator before it receives power and as you see it works as expected.
Redstone torches are better but still have the problem.
If a torch is updated at the same time as it looses power and it's powered 2 gameticks after that. The torch will turn off instantly.
This is demonstrated in the torch monostable picture which will output a 2 gametick long pulse instead of the expected 4 long thanks to this. The redstone wire going to the side updates the torch.
Basically, torches and definetely comparators need to check if an update actually should be scheduled before doing soThis is a bug that was nearly fixed for torches but still exists in a few cases.
As far as i can tell it's now completely fixed for comparators.What is left of this bug is a bit weird. The way i'm now able to reproduce it is like this:
If a torch is updated at the same time as it loses power and it's powered 2 gameticks(1 "redstonetick") after that. The torch will turn off instantly as it recieves power.This is demonstrated in the torch monostable picture in which the torch will output a 2 gametick long pulse instead of the expected 4 long, thanks to this. The redstone wire going to the side updates the torch.
Redstone torchesand comparatorsschedule updates when they should not. Causing unreliable timings.
This is a bug that was nearly fixed for torches but still exists in a few cases.
As far as i can tell it's now completely fixed for comparators.What is left of this bug is a bit weird. The way i'm now able to reproduce it is like this:
If a torch is updated at the same time as it loses power and it's powered 2 gameticks(1 "redstonetick") after that. The torch will turn off instantly as it recieves power.This is demonstrated in the torch monostable picture in which the torch will output a 2 gametick long pulse instead of the expected 4 long, thanks to this. The redstone wire going to the side updates the torch.
This is a bug that was nearly fixed for torches but still exists in a few cases.
As far as i can tell it's now completely fixed for comparators.What is left of this bug is a bit weird. The way i'm now able to reproduce it is like this:
If a torch is updated at the same time as it loses power and is powered 2 gameticks(1 "redstonetick") after that. The torch will turn off instantly as it recieves power.This is demonstrated in the torch monostable picture in which the torch will output a 2 gametick long pulse instead of the expected 4 long
,thanks to this. The redstone wire going to the side updates the torch.
This is a bug that was nearly fixed for torches but still exists in a few cases.
As far as i can tell it's now completely fixed for comparators.What is left of this bug is a bit weird. The way i'm now able to reproduce it is like this:
If a torch is updated at the same time as itloses powerand is powered 2 gameticks(1"redstonetick") after that. The torch will turn off instantly as it recieves power.This is demonstrated in the torch monostable picture in which the torch will output a 2 gametick long pulse instead of the expected 4 long thanks to this. The redstone wire going to the side updates the torch.
This is a bug that was nearly fixed for torches but still exists in a few cases.
As far as i can tell it's now completely fixed for comparators.What is left of this bug is a bit weird. The way i'm now able to reproduce it is like this:
If a torch is updated at the same time as it turns on and is powered 2 game ticks(1 redstone tick) after that. The torch will turn off instantly as it recieves power.This is demonstrated in the torch monostable picture in which the torch will output a 2 game tick long pulse instead of the expected 4 game tick long thanks to this. The redstone wire going to the side updates the torch.
I think the cause is that
This is a bug that was nearly fixed for torches but still exists in a few cases.
As far as i can tell it's now completely fixed for comparators.What is left of this bug is a bit weird. The way i'm now able to reproduce it is like this:
If a torch is updated at the same time as it turns on and is powered 2 game ticks(1 redstone tick) after that. The torch will turn off instantly as it recieves power.This is demonstrated in the torch monostable picture in which the torch will output a 2 game tick long pulse instead of the expected 4 game tick long thanks to this. The redstone wire going to the side updates the torch.
I think the cause is thatThis is a bug that was nearly fixed for torches but still exists in a few cases.
As far as i can tell it's now completely fixed for comparators.What is left of this bug is a bit weird. The way i'm now able to reproduce it is like this:
If a torch is updated at the same time as it turns on and is powered 2 game ticks(1 redstone tick) after that. The torch will turn off instantly as it recieves power.This is demonstrated in the torch monostable picture in which the torch will output a 2 game tick long pulse instead of the expected 4 game tick long thanks to this. The redstone wire going to the side updates the torch.
The actual problem here
This is a bug that was nearly fixed for torches but still exists in a few cases.
As far as i can tell it's now completely fixed for comparators.What is left of this bug is a bit weird. The way i'm now able to reproduce it is like this:
If a torch is updated at the same time as it turns on and is powered 2 game ticks(1 redstone tick) after that. The torch will turn off instantly as it recieves power.This is demonstrated in the torch monostable picture in which the torch will output a 2 game tick long pulse instead of the expected 4 game tick long thanks to this. The redstone wire going to the side updates the torch.
The actual problem here
This is a bug that was nearly fixed for torches but still exists in a few cases.
As far as i can tell it's now completely fixed for comparators.What is left of this bug is a bit weird. The way i'm now able to reproduce it is like this:
If a torch is updated at the same time as it turns on and is powered 2 game ticks(1 redstone tick) after that. The torch will turn off instantly as it recieves power.This is demonstrated in the torch monostable picture in which the torch will output a 2 game tick long pulse instead of the expected 4 game tick long thanks to this. The redstone wire going to the side updates the torch.
The problem does have to do with that the game obviously updates things one after the other even when they are happening in the same tick.
I explained more in a comment..
This is a bug that was nearly fixed for torches but still exists in a few cases.
As far as i can tell it's now completely fixed for comparators.What is left of this bug is a bit weird. The way i'm now able to reproduce it is like this:
If a torch is updated at the same time as it turns on and is powered 2 game ticks(1 redstone tick) after that. The torch will turn off instantly as it recieves power.This is demonstrated in the torch monostable picture in which the torch will output a 2 game tick long pulse instead of the expected 4 game tick long thanks to this. The redstone wire going to the side updates the torch.
The problem
does haveto do with that the game obviously updates things one after the other even when they are happening in the same tick.
I explained more in a comment..This is a bug that was nearly fixed for torches but still exists in a few cases.
As far as i can tell it's now completely fixed for comparators.What is left of this bug is a bit weird. The way i'm now able to reproduce it is like this:
If a torch is updated at the same time as it turns on and is powered 2 game ticks(1 redstone tick) after that. The torch will turn off instantly as it recieves power.This is demonstrated in the torch monostable picture in which the torch will output a 2 game tick long pulse instead of the expected 4 game tick long thanks to this. The redstone wire going to the side updates the torch.
The actual problem has to do with that the game obviously updates things one after the other even when they are happening in the same tick.
I explained more in a comment..
This is a bug that was nearly fixed for torches but still exists in a few cases.
As far as i can tell it's now completely fixed for comparators.What is left of this bug is a bit weird. The way i'm now able to reproduce it is like this:
If a torch is updated at the same time as it turns on and is powered 2 game ticks(1 redstone tick) after that. The torch will turn off instantly as it recieves power.This is demonstrated in the torch monostable picture in which the torch will output a 2 game tick long pulse instead of the expected 4 game tick long thanks to this. The redstone wire going to the side updates the torch.
The actual problem has to do with that the game obviously updates things one after the other even when they are happening in the same tick.
I explained more in a comment below..
What I expected to happen was...:
I excpected the comparator to axtivate for 1 game tick as it got a 1 game tick long pulse.
What actually happened was...:
The comparator didn't react to the pulse at all.To reproduece:
Build what's in the pictureThe piston monostable will output a 1 game tick long pulse into the comparator.
What I expected to happen was...:
I expected the comparator to activate for 1 game tick as it got a 1 game tick long pulse.
What actually happened was...:
The comparator didn't react to the pulse at all.To reproduece:
Build what's in the pictureThe piston monostable will output a 1 game tick long pulse into the comparator.
What I expected to happen was...:
I expected the comparator to activate for 1 game tick as it got a 1 game tick long pulse.
What actually happened was...:
The comparator didn't react to the pulse at all.To reproduece:
Build what's in the pictureThe piston monostable will output a 1 game tick long pulse into the comparator.
What I expected to happen was...:
I expected the comparator to activate for 1 game tick as it got a 1 game
tick long pulse.What actually happened was...:
The comparator didn't react to the pulse at all.To reproduece:
Build what's in the pictureThe piston monostable will output a 1 game tick long pulse into the comparator.
Even when "idle", the comparators update things 2 blocks in front of it and 1 block behind it.
It seems to be doing it every gametick which can cause unecessary lag and problems because dispensers can fire on updates.If you flick the lever in the picture the piston will extend because its being updated by the comparator.
Even when "idle", the comparators update things 2 blocks in front of it and 1 block behind it.
It seems to be doing it every gametick which can cause unecessary lag and problems because dispensers can fire on updates etc.If you flick the lever in the picture the piston will extend because its being updated by the comparator.
Even when "idle", the comparators update things 2 blocks in front of it and 1 block behind it.
It seems to be doing it every gametick which can cause unecessary lag and problems because dispensers can fire on updates etc.If you flick the lever in the picture the piston will extend because its being updated by the comparator.
Ok, so i actually checked through the code.
Apparently, the comparator is updating itself. um, derp?
Even when "idle", the comparators update things 2 blocks in front of it and 1 block behind it.
It seems to be doing it every gametick which can cause unecessary lag and problems because dispensers can fire on updates etc.If you flick the lever in the picture the piston will extend because its being updated by the comparator.
Ok, so i actually checked through the code.
Apparently, the comparator is updating itself + the blocks infront/behind when it gets updated. um, derp?
Even when "idle", the comparators update things 2 blocks in front of it and 1 block behind it.
It seems to be doing it every redstone tick(i think) (2 gameticks) which can cause unecessary lag and problems because dispensers can fire on updates etc.If you flick the lever in the picture the piston will extend because its being updated by the comparator.
Ok, so i actually checked through the code.
Apparently, the comparator is updating itself + the blocks infront/behind when it gets updated. um, derp?
Even when "idle", the comparators update things 2 blocks in front of it and 1 block behind it.
It seems to be doing it every redstone tick(i think) (2 gameticks) which can cause unecessary lag and problems because dispensers can fire on updates etc.If you flick the lever in the picture the piston will extend because its being updated by the comparator.
Ok, so i actually checked through the code.
Apparently, the comparator is updating itself + the blocks infront/behind when it gets updated. um, derp?
Well that doesn't have with this glitch to do.
It's still not completely fixed in the 1.5 snapshot, if you have two output torches one of them will give a 1 tick pulse, the other a 2 tick one.
Updated the description
You're thinking of something different
I added that it updates blocks behind it aswell to the description
Edit:
Actually, this is the bug i was experiencing:
https://mojang.atlassian.net/browse/MC-8328
I had changing signal strength aswell, so got confused
Hi dico
A 0 tick pulse would be a signal that turns on and off in the same tick.
And as dico said, it depends on if the repeater or the torch updates first.
Very annoying though as it breaks alot of instant piston logic
This was not fixed in Snapshot 13w05a.
The actual bug that is causing this is: https://mojang.atlassian.net/browse/MC-2340
No, when i said "idle", i meant that nothing is changing around them and their state isn't chaning. They can be idle in their on state aswell.
This bug is back in snapshot 13w06a. Can a mod or someone reopen maybe?
Redownloaded it, bug is still there.
This is the same bug as: https://mojang.atlassian.net/browse/MC-2340
Seems like the comparator part of this issue is fixed again in Snapshot 13w09a
Edit:
It still exists in a few cases.. Il update the post when i have time..
Only the second video actually contains this bug. Repeater problems are because of something else.
And i quickly updated the post
I added the new versions.
Explanation to the leftover of this bug:
Also.. i completely edited this comment because i just thought about it, and the repeater bugs are caused by the same problem that causes torches to act weird. the only difference is that with torches it's about them checking if they shoyuld schedule an update for themselves and with repeaters it's about them checking if they are powered or not.
The actual problem in both cases is how the game updates things one at a time in some order.
This causes these weird behaviours.
Examples:
Bug with a torch(One RedStoneTick at a time):
RSTick 0: The torch's input changes causing it to schedule an update.
RSTick 1: In the same tick but before the scheduled update arrives we update the torch causing it to schedule another update. Then it gets updated from the last tick's schedule and changes state.
RSTick 2: The torch's input changes again(scheduling another update). The scheduled update from last tick arrives and the torch changes state.
RSTick 3: The scheduled update the torch is supposed to change state too arrives but the torch is already in the correct state so nothing happens.
This is what happens in the torch monostable picture.
Bug with a repeater:
The fact that repeater's input need to be off for 1 RSTick before it changes state causes problems here.
Shortly, the repeater's input turns off, one RSTick later IF the input is powered tick AND is updated before the repeater, the repeater will never turn off because it made the "1 RSTick off" check just after the input had already turned on again.
Sorry if i suck at explaining..
But the problem lies in that even though two things happen in the same tick, one of them will still happen before the other.
This is just how redstone stuff works so i wouldn't expect this to ever be fixed as that would probably require a big rewrite of the whole redstone code. (As far as i can tell).
Anyway, i feel pretty sure that this is the cause for both bugs though i could be wrong.
I might update the whole post to explain this so it would include your repeater bugs aswell..
But not feeling like it right now
Well, just edited my whole last comment.. xD
They are both from the same issue as i wrote now that i thought about it so staying merged is probably a good idea. I just have to update the main post...