DvdKhl
- arokh
- arokh
- Europe/Stockholm
- Yes
- No
MC-2202
Win7 Pro 64bit
Java 1.5.0_05 64bitWin7 Pro 64bit
Java 1.7.0_05 64bit
In the attached screenshots I've build the following circuit four times:
First a pulser which produces a 3 tick pulse, which is then negated by feeding the signal into a block with a repeater on which a torch is attached.
The torch is used as the output.The inner two are exactly the same (block by block) except mirrored (which does not affect the behaviour).
The same is true for the outer two.The difference between the inner and outer is only by placing the negation part one block diagonally away.
If the pulsar is fed an on signal the following can be noticed:
1) Although the circuit logic is the same andthe repeater countis alsothe inner ones signal is a tick later than the outer ones
2) If I place a repeater near the torch the pulse length is changed by one tickIn the attached screenshots I've build the following circuit four times:
First a pulser which produces a 3 tick pulse, which is then negated by feeding the pulsar signal into a block with a repeater, on which a torch is attached.
The torch is used as the output.The inner two are exactly the same (block by block) except mirrored (which does not affect the behaviour).
The same is true for the outer two.The difference between the inner and outer is only by placing the negation part one block diagonally away.
If the pulsar is fed an on signal the following can be noticed:
1) Although the circuit logic is the same as is the repeater count, the inner ones signal is a tick later than the outer ones
2) If I place a repeater near the torch the pulse length is changed by one tick
Different redstone behaviour for the same circuitInconsistent pulse length/delay with torch and repeater combination
This is related to https://mojang.atlassian.net/browse/MC-2340 and https://mojang.atlassian.net/browse/MC-2202 but are too old and don't describe the problem concisely anymore, and they seem to get no attention because of this.
"One tick physics" seem to be broken or at least behave very unintuitive.
This issue was introduce around the "Redstone Update" and hasn't changed since.Some examples:
http://www.youtube.com/watch?v=Z0OsUjZXQVs :
A clock is connected to 12 circuits which are logically the same (except for placement) but have different outputhttp://www.youtube.com/watch?v=CgPIavyc4ig :
A (comparator) clock is connected to a repeater chain, only after 3 redstone dust beginning from the comparator the repeater receives the correct signal, before the repeater are always isactive mode.http://www.youtube.com/watch?v=Ac_IujHfXpw :
A clock is connected to 4 repeater chains in all directions.
Two of them get the correct signal the other two are wrong.And for me the most important
http://www.youtube.com/watch?v=JNTTuGOqJkg :
A locked repeater chain (used as a shift register) corrupts the signal stored after the lock is released.This is related to https://mojang.atlassian.net/browse/MC-2340 and https://mojang.atlassian.net/browse/MC-2202 but are too old and don't describe the problem concisely anymore, and they seem to get no attention because of this.
"One tick physics" seem to be broken or at least behave very unintuitive.
This issue was introduce around the "Redstone Update" and hasn't changed since.Some examples:
http://www.youtube.com/watch?v=Z0OsUjZXQVs :
A clock is connected to 12 circuits which are logically the same (except for placement) but have different outputhttp://www.youtube.com/watch?v=CgPIavyc4ig :
A (comparator) clock is connected to a repeater chain, only after 3 redstone dust beginning from the comparator the repeater receives the correct signal, before the repeaters are always in active mode.http://www.youtube.com/watch?v=Ac_IujHfXpw :
A clock is connected to 4 repeater chains in all directions.
Two of them get the correct signal the other two are wrong.And for me the most important
http://www.youtube.com/watch?v=JNTTuGOqJkg :
A locked repeater chain (used as a shift register) corrupts the signal stored after the lock is released.
Fixed in 13w01a
The bug reoccurred with the pre1.5 (or earlier, I only checked pre1.5 for now).
I had to increase the delays for the pulsars (repeater nearer to the clock) by one tick otherwise no pulses were generated.
By increasing it by one tick, pulses of two ticks are generated.
(Bug? Already reported?)
With that change described above, the two inner repeater paths show two ticks as exprected.
The other two repeater paths on the other hand show only one tick.
Can I somehow reopen the issue or should I clone it?
After some more investigation:
Faulty behavior as described in previous comment stays the same until 13w03a.
The following changes are visible:
Pulsars which produce one tick pulses work again.
Pulses with one tick work fine (one tick on all repeater paths)
Pulses with two ticks are shortened (by one tick) on the outer repeater paths
Pulses with three ticks work fine (three ticks on all repeater paths)
Please check
MC-2340which probably already describes your issue.Yes, that might be the case, I have no way to be sure though.
I guess I will report it again when that issue is fixed but this one is not.
So feel free to mark this one as a duplicate.
May be related:
Place two two repeaters next to each other (facing in opposite directions) each having a one tick delay.
Connect the repeaters. Creating a clock which produces a 1010101... tick pattern.
If you now attach a "line" of repeaters to it, instead of seeing the 10101... pattern you get 111011101110...
This breaks all my contraptions :/
Hi,
I don't really think that it is a duplicate (as my main problem are repeaters which its title does not mention),
but I'll respect your decision and post it there instead.
Cheers
Since this is still the ticket to go to for one tick issues here some videos which show the "one tick physics" issues present in redstone logic:
http://www.youtube.com/watch?v=JNTTuGOqJkg
http://www.youtube.com/watch?v=Z0OsUjZXQVs
http://www.youtube.com/watch?v=CgPIavyc4ig
http://www.youtube.com/watch?v=Ac_IujHfXpw
Well my issue report was marked as duplicate of this one.
So going by this, it looks like repeaters are affected by this bug mentioned here too.
Henrik Lindström: Could you add 1.7.4 and 14w03b for the affected versions?
Not sure if your reported issue is still present, but the issues pointed out in my videos are still there.
I did create a ticket which describe these problems ( https://mojang.atlassian.net/browse/MC-32296 ) but it got marked as duplicate and merged into this one.
So I basically share your opinion that this is a separate issue, but I don't want to annoy the mods creating yet another ticket for it.
It would be nice if a mod could clarify if this should stay merged as one ticket or if my reported issues warrant another ticket.
It is still happening:
http://youtu.be/jgwoGZUOEFY
Issues start at around 1:40
On second thought, is this really a bug?
Since the delays are not in alignment, it sounds more like an aliasing effect, which is also an issue in the real world.
I guess the repeaters which are supposedly "out of sync", are just doing their sampling (checking their input) at different points of time, resulting in a different output sequence.
Changing that behavior to something else would probably lead to a lot of other issues and is probably hard to code in a satisfying way.
Still an issue for 14w28b.
I've made a short video demonstrating various combinations where one-tick pulses are problematic:
https://www.youtube.com/watch?v=Ubq6DLk0wsA
I'm noticing the same problem more severely now with the current version (14w29b).
Probably due to the threading and the faster load of chunks (which is awesome btw).
The problem now is that GCs happen a lot more frequently.
At worst I had a GC every three seconds and the freeze + followed stuttering sometimes lasted more than a second.
Here is a video I took after standing still for ~5 minutes and then recording 30s of standing still: http://youtu.be/yAB4yME8Xtg
Please note that the actual increase rate is even faster when not recording.
Also happens in first person view: http://youtu.be/-ldlgk6V7z8
With 14w30b the issue is (in my case) a lot less prominent and sometimes even unnoticeable (i.e. the freeze/stutter duration after a GC is a lot shorter), the GC frequency itself is still quite high though.
Well it definitely doesn't cause any bigger freezes anymore.
Only the short freeze when GCing, but that one has always been there.
So you could call it a day and mark it fixed, but optimizing memory usage could pay off though (i.e. by pooling/reusing large arrays if that isn't already done).
So it is your call.
Some stats:
Settings: VBO On; distance 16; Fancy; FOV Normal; No VSync; Smooth Lightning: Max; Alt Blocks On; Windowed (1920x1178); Clouds Off; Particles All; -Xms3G -Xmx3G
Loading the world, doing 360° lookaround (waiting for chunks to be loaded), than just standing:
Memory: 500mb-1500mb; +200mb/s; 5s until GC
Same as above but in menu (Esc)
Memory: +10mb/s
Flying forward (for previously loaded and then unloaded chunks)
Memory: 900mb-1900mb; +500mb/s; 2s until GC
(Please keep in mind that I'm not the reporter and he/she might still have issues)
Still happening with 1.8 pre2
Still happening with 1.8
Not sure if I can speak for the reporter. But my bug report which was merged into this one still has issues (
MC-32296).All videos except the third (which seems fixed) still behave in the same (buggy) way.
The first and last video is probably the same issues as: MC-54711
Still happening in 1.8.1-pre3