ilmango
- ilmango
- ilmango
- Europe/Stockholm
- Yes
- No
MC-76349![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
Low![[Mojang] Jeb (Jens Bergensten)](../../../data/assets/gravatar/jeb.jpeg){kind=small}
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
MCD-29pistonsno longer retracts an extended piston when de-powered at the same time
Double piston extenders no longer retract both pistons at the same time, when they are depowered in the same game tick.
This behaviour was classified as "Works As Intended" inMC-9342. People were used to this behaviour and many redstone contraptions rely on the sharper timings such a behaviour enables. Removing this feature would in some cases require major adjustments to those.How to recreate:
This behaviour was always dependant on the update order. The piston in the back had to receive the update first. To influence the update order one way was to power the front piston with a comparator and the back piston with a repeater. This behaviour was also reliable with doublepiston extenders facing upwards, being powered by a torch or a hopper minecart powering a downwards facing double piston.
Double piston extenders no longer retract both pistons at the same time, when they are depowered in the same game tick.
This behaviour was classified as "Works As Intended" inMC-9342. People were used to this behaviour and many redstone contraptions rely on the sharper timings such a behaviour enables. Removing this feature would in some cases require major adjustments to those.How to recreate:
This behaviour was always dependant on the update order. The piston in the back had to receive the update first. To influence the update order one way was to power the front piston with a comparator and the back piston with a repeater. This behaviour was also reliable with doublepiston extenders facing upwards, being powered by a torch or ahopperminecart powering a downwards facing double piston.Double piston extenders no longer retract both pistons at the same time, when they are depowered in the same game tick.
This behaviour was classified as "Works As Intended" inMC-9342. People were used to this behaviour and many redstone contraptions rely on the sharper timings such a behaviour enables. Removing this feature would in some cases require major adjustments to those.How to recreate:
This behaviour was always dependant on the update order. The piston in the back had to receive the update first. To influence the update order one way was to power the front piston with a comparator and the back piston with a repeater. This behaviour was also reliable with doublepiston extenders facing upwards, being de-powered by a torch or a minecart powering a downwards facing double piston.
Double piston extenders no longer retract both pistons at the same time, when they are depowered in the same game tick.
This behaviour (retracting both pistons at the same time) was classified as "Works As Intended" inMC-9342. People were used to this behaviour and many redstone contraptions rely on the sharper timings such a behaviour enables. Removing this feature would in some cases require major adjustments to those.How to recreate:
This behaviour was always dependant on the update order. The piston in the back had to receive the update first. To influence the update order one way was to power the front piston with a comparator and the back piston with a repeater. This behaviour was also reliable with doublepiston extenders facing upwards, being de-powered by a torch or a minecart powering a downwards facing double piston.
Double piston extenders no longer retract both pistons at the same time, when they are depowered in the same game tick.
This behaviour (retracting both pistons at the same time) was classified as "Works As Intended" inMC-9342. People were used to this behaviour and many redstone contraptions rely on the sharper timings such a behaviour enables. Removing this feature would in some cases require major adjustments to those.How to recreate:
This behaviour was always dependant on the update order. The piston in the back had to receive the update first. To influence the update order one way was to power the front piston with a comparator and the back piston with a repeater. This behaviour was also reliable with doublepiston extenders facing upwards, being de-powered by a torch or a minecart powering a downwards facing double piston.Also the double retraction had to happen within the same block event.
confirmed for 1.9 pre4
this is a serious issue. After Dinnerbone announced to worked on client/server packages a few months ago, piston elevators/conveyor belts got more unreliable.
Using minecarts was the workaround by the community to have reliable methods of transportation.The suggestion by Jamie van den Berge is very good in my opinion.
How to recreate:
- place a dispenser facing into a water source
- fill it with glass bottles and activate the dispenser
sThis happens in contrast to buckets. I would expect bottles to behave like buckets.
I'm not entirely sure if I understand this right. If all hoppers would be running on a global timer now and only attempt to transfer items every 4 ticks, a huge amount of redstone contraptions would break, because they for example rely on getting a 7gt signal from the classic dropper-hopper monostable.
descriptionsays it all.Steps to reproduce:
Make an observer line over several thousand blocks and update the first one. The game crashes for me everytime
title says it all.
Steps to reproduce:
Make an observer line over several thousand blocks and update the first one. The game crashes for me everytime
Yeah, someones super important melon farm isn't working the way he expects it to. Let's screw everyone else backwards, by changing piston behaviour without consideration what else is affected. Sounds like a Mojang plan
no it's not an issue.
MC-5726has been marked as works as intended and this "bug" has received 1 upvote in 4 years. In fact fixing this bug would break countless contraptions.
was this really a bug? end gateways ok, but piston extensions? anyway, thanks for simple wither traps,
"If you need to drop the block, push a glazed_terracotta, you can only push the block and not pull it."
pretty much what oreo said. This is so much missing the point, that it hurts. It's in the league of suggesting to use normal pistons if we want to drop a block.
feature requests at: https://www.reddit.com/r/minecraftsuggestions/
Invisibility potions are supposed to reduce the detection range. This doesn't work with shulkers in case the shulker is directly above or below the player. Shulkers would shoot at the player despite being up to 16 blocks away.
How to recreate. Use shulker egg - drink invisibility potion - stand directly above or below shulker up to 16 blocks away - shulker will start shooting
Invisibility potions are supposed to reduce the detection range. This doesn't work with shulkers in case the shulker is directly above or below the player. Shulkers would shoot at the player despite being up to 16 blocks away.
How to recreate. Use shulker egg - drink invisibility potion - stand directly above or below shulker up to 16 blocks away - shulker will start shooting
crops etc. grow when the player is in specator mode
crops grow in spectator mode
ilmango: I haven't actually shown any numbers yet, have I? So how can you tell how hard it would be to see speed gains? I can tell you that it depends heavily on the mutation chance, since a mutation replaces a part of the stat with a brand new one, which is the way to get an increase. With a 10% mutation chance you get very good horses with some hundreds of breedings, with a 1% chance it takes thousands. Some examples how long it would take to reach good average stats with 10% mutation per gene (without having information about the genes):
0.50, 1 0.55, 3 0.60, 6 0.65, 11 0.70, 22 0.75, 32 0.80, 46 0.85, 84 0.90, 162 0.95, 345
A perfect score is still unattainable. For the record, this picture 
shows the same numbers for regular breeding.
P.S. Making breeding useless is a dumb way to encourage exploring.
Quoting ilmango:
This bug report and the nagging about mediocre horses affirms my perception, that 99% of the population can't deal with probabilities. At least an above average share of the people in this discussion, know what they are talking about.
Still way too few to enable productive discourse.
You're using linear percentages now, when we've almost exclusively used wild percentiles for comparison. 80% between min and max is around the 97th wild percentile as you even say yourself. That's already nigh on impossible to attain by breeding. I'm not sure why you bring 90% or the >99.5th wild percentile into it. It's too far-fetched to even suggest. Look at the values coming out of breeding.Breeding is on average 6 times slower, than finding a new horse, if the time to get a new horse is the same. That's a good thing in my opinion, because it encourages exploring. Right now the odds to find a spawned horse with a certain attribute, that is at least 80% of the maximum, is 1:27 and for 90 % 1:222.
That's alright, the difference between 80 and 90% isn't that big. If somebody really wants a very fast or high jumping horse, he has to work for it.
In my opinion, the system as it is, is almost perfect and resembles real life, where it is extremly unlikely, that a horse is a world class jumper and runner at the same time and the offspring of two very talented individuals, almost never exceeds their parents.
Those world-class horses were still born to parents. Maybe those parents were mediocre and their foal was a lucky accident. Well, that doesn't happen in Minecraft at all. No way to create them even though they are relatively abundant somehow.
Something else I should mention (hi nemesit, who just beat me to it!) is that the player is and should be overpowered in the game. The whole point of the game is to enable the player to change the world as they see fit. You can dig faster with your hands than you can with big machines in real life. You can carry over 2000 cubic meters of material in your pockets, and we still think they fill up too fast. There are only a few things that take an extreme amount of effort, but that are at least doable unlike real life, like building a diamond house. Why should a good horse, of all things, be even more expensive? Sure, make it hard. Just not this impossible and nonsensical grindfest.
ilmango: Could you please refrain from needlessly spamming the comments. The whole point of what is wrong with the formula is that breeding reduces variance, random parents or not.
ilmango: Horses can and will pass on their stats. Wild and bred horses aren't sampled with the same function but the results have matching mean and variance.
Here's how the stats are essentially generated (excluding scaling and offsetting):
U = random number from 0 to 1
Wildhorse = { speed = U + U + U, health = U + U, jump = U + U + U }
My suggestion is to remember these U values:
Parent_A = { speed = U + U + U, health = U + U + U, jump = U + U + U }
^
| Child gets always one of these randomly. 10% chance to get new value.
v
Parent_B = { speed = U + U + U, health = U + U + U, jump = U + U + U } //added third U to health because why not
I have tried your suggestion before and it won't work for reasons mentioned here, unless you give the uniform random part a multiplier so high it diminishes the parents almost completely. Here's how it would affect a random population: http://i.imgur.com/43Xn6v2.png (I believe the effect on the distribution of a random population is the only viable metric with which to measure how good the breeding is because the formula would have to explain how wild horses breed. Looking at what the player does is irrelevant because the player introduces all sorts of bias.)
P.S. Nice trick with the leaping potions.
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
ilmango As you know, Panda (the bugpost opener) is THE incarnation of exploiting bugs as "features", a nightmare come true for Minecraft developers.
And if a Minecraft Survival game mechanics expert like him who loves a buggy game (so he can exploit it) decides to see it as bug, as more harmful than useful, then I trust his evaluation.
It's futile to list all the bad and good this bug would mean if the stance of the developers is to fix all bugs at some point, and I don't ever want to have to face a rage even from big YouTubers I respect (the recent bugfix that led to a fix for test137E29's item elevator) that put pressure and caused despicable remarks towards the developers again.
And even more futile if different interests, some of them selfish, collide, which hardly can lead to an agreement of all parties.
For example those YouTubers who like to make videos about such bugs, sell them as "features", the crowd loves it, and as soon as it's fixed before the release version, let's guess who will get the hate?
The YouTuber who made a video in a buggy snapshot version, or the developers who "took away the cool feature"?
ilmango All bugs need to be fixed.
Panda and I "preach" it every time that one shall not rely on bugs as they might eventually be fixed.
The Devteam is highly understaffed, so if the bug does not get fixed rightaway, it's foreseeable, even more so with that buggy piston code which one cannot just simply fix quickly.
To use this as argument against them and call it ignorance is inappropriate.
One should rather try to work constructively with them and try to convince them of a replacement for what a bug caused.
If one attacks them it's rather unlikely they would.
ilmango There's a Redditpost on Mojira for further discussions.
But as you brought up QC and insist on it being WaI, I have to get this straight here before even more people blindly believe this and hold onto that hope forever:
I don't know how many times I already said this, but I will continue to do so:
Any bug - and that includes QC - can get fixed at any time, sometimes not even intentionally just as some "side effect" of fixing other bugs, so personally I wouldn't bet that QC stays in the game forever, at least not as bug, as they want to fix all bugs, and that includes also QC of course.
So even if they'd continue to declare QC as "WaI" (which was just a temporary thing from how I understood the discussants, Microsoft as well as Mojang) it might be that it gets fixed over time anyway automatically.
QC as a "clean" feature* is another thing, but given feature parity across all platforms doubtable.
I play this game since 6 years and Minecraft changed a lot throughout the versions. And no matter if I personally like some changes (and, no, some I don't like at all):
It is close to impossible for a vivid game like this to stay the same for so many years, even more so given the circumstances, new players, new owner, the other platforms and future plans.
My personal stance is: If I don't like 1.11 or 1.12, I'll just play in an older version (at least Survival; Creative is awesome).
So either adapt, or play an old version you like, or stop playing.
There'd be another thing one could do, but that'd afford a lot of time, maturity, flexibility, diplomacy, amicability, perseverance, and most people who don't like changes and close up completely against valid counter-arguments usually lack in some or all of them.
RG Studios, this video was was recorded in 1.11. This version was already confirmed as affected by two of creators of the farm from the video - ilmango and ragou42.
Is the most recent version (1.11.2) still affected?
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Items (such as emeralds, TNT or potions) don't despawn after some amount of time. This might be intentional, but it enables AFK farming, like shown in this video by ilmango.
![[Helper] pine1needle](../../../data/avatars/users/41329.png){kind=small}
A single piece of bonemeal can be used to obtain many moss blocks, which can then be composted to obtain more bonemeal than you started with. This can be fully automated using a stone generator and pistons (to break the moss into item form). ilmango demonstrates this in this YouTube video. This should probably be considered while deciding whether or not this behavior is intended.
It might be worth mentioning that ilmango seemed glad about mangrove roots conducting redstone signal. He said that it's the first water-loggable block that can be powered, and that it's also a spawn-proof powerable block.
Of course, usefulness alone does not imply anything about whether or not a behavior is intended, but this might be something that should be considered.
I've added a screenshot.
I think the problem is, that the hopper can't do 2 tasks at a time. Transfering the item to the brewing stand and grabing an item from above.
Also I should add, that the items are different. The brewing stand contains one sort of item, the hopper another, and the hopper minecart also another.
For example netherwart, sugar and redstone dust.
Doesn't make a difference. I've uploaded a video demonstrating the error:
https://www.youtube.com/watch?v=fsh1DlOzQRM
MC world with setup to demonstrate bug
confirmed for 1.8.2 pre1
This bug report and the nagging about mediocre horses affirms my perception, that 99% of the population can't deal with probabilities. At least an above average share of the people in this discussion, know what they are talking about.
Breeding is on average 6 times slower, than finding a new horse, if the time to get a new horse is the same. That's a good thing in my opinion, because it encourages exploring. Right now the odds to find a spawned horse with a certain attribute, that is at least 80% of the maximum, is 1:27 and for 90 % 1:222.
That's alright, the difference between 80 and 90% isn't that big. If somebody really wants a very fast or high jumping horse, he has to work for it.
In my opinion, the system as it is, is almost perfect and resembles real life, where it is extremly unlikely, that a horse is a world class jumper and runner at the same time and the offspring of two very talented individuals, almost never exceeds their parents.
@Kylie Langton
So whats your problem? You did all this work to differentiate yourself from the others, by having the best horse. If it would be easier to have a very good horse, you wouldn't be satisfied either, because everyone can have one. Nobody needs a horse, that is 10% faster, anyway. If someone really wants to put effort into breeding or searching for horses or building a friendly mob farm, why not? If you wanted a horse with at least 14.2 bps, you would have had to breed on average 4 times more horses, and for 14.5 600 times more horses. The effort you put into it, is only definied by your ambition, and the reward is not a straight line. That's exactly what I'm talking about, people have no clue about probabilities and are frustrated by it.
Although it is a game, there can only be one fastest horse on the server, and the owner is either extremely lucky or put the most effort into it.
btw: Gold is replenishable (Pigmen!) and speed progression doesn't need a mod to measure, if you're good with redstone. https://www.youtube.com/watch?v=7KUCvBg9-_M
@victor baker. it is not realistic to breed past 90% of a certain value. On average on the 1000th iteration you would pass that mark, if all improvements are recognized. So what? It's only a number. Why does that nag you? Because your urge for perfection can't be satisfied?
@Victor
It doesn't matter, which algorithm is used, you won't see improvements at a certain point, with reasonable effort.
But I think I understand your point a little better, by reading some of the other posts more carefully. The better strategy to get a good horse is definitely getting spawned horses right now. Shifting the ratio to breeding maybe isn't that bad. But I like the fact, that something encourages exploring in this game. On the other hand, I understand the desire of players to sit in their base and breed a good horse. I guess it's up to Mojang to decide.
I don't like Altti Tammi's suggestion, because people already complain, that it's to hard to see speed gains without mods. Successful breading largely relies on recognizing tiny improvements even with the current system.
That was unfortunate. I haven't updated the page. I was referring to your old suggestion.
@jonathan
Please explain why a 12bps horse, that is attainable by breeding with moderate effort, isn't a good horse? A 14 bps horse isn't much faster and isn't more OP. If you really think a 12 bps horse isn't a good horse you must be driven by your compulsive perfectionism and can't deal with it properly.
@jonathan
World class horses aren't born from average horses, just like in Minecraft. The current system resembles this.
@ Altti Tammi
Your explanation isn't totally correct. The resulting foal is a combination of three random values and two fixed values of the parents. Fixed because the player chooses the horses he breeds with. The graph you showed would be the result of two random horses, that breed a foal. That's not applicable in this case, because the player chooses the horses he breeds with. If the parents have influence on the foal, then the cumulative distribution function must be narrower than of a completely random horse. There's no way around that.
Wouldn't it be the easiest way to give bred horses an uninheritable 10% bonus, if you really want to make breeding more attractive?
Reducing variance is the whole point of breeding. The formula is fine, the way it is and the breeding system is not bugged. Please stop posting your overcomplicated suggestions and incorrect explanations. That doesn't belong here.
I haven't seen the mods post. It's kind of buried. didn't catch it while scanning through the comments. I have seen this discussion under a false aspect.
I can't read java and don't understand Altti's suggestion fully. But I don't think that using the same distribution function for wild and bred horses can be a solution either, because horses won't pass on their traits. The easiest way to broaden the variance when breeding, would be using less variables for the foal. Just use one variable instead of three for the third horse. For example speed: Instead (h1 + h2 + 1/4(0.45+ (0.3 x rnd + 0.3 x rnd +0,3 x rnd)))/3 use (h1 + h2 + 1/4(0.45 + 0,9 x rnd)/3. Even if you have two 90% horses (single category), you would have 10% chance of improving. Expected value after 100 times breeding, starting with average horses, would be 93%. I guess Altti suggests something similar, but more complicated.
That's not correct. You could use carpets to narrow it down to 0.0625 block margin, or use leaping potions for an even more accurate result.
https://www.youtube.com/watch?v=pfRZ670j8wI
Also I can't see any benefit to rounding as well.
This is no duplicate.
I should have made it clearer, that the game does the EXACT OPPOSITE of what Jeb saw as intended behaviour.
I don't know how I should make this any clearer. In
MC-9342people complained about both pistons retracting at the same time. Jeb decided that this (both pisotns retracting at the same time) is intended behaviour. Since 15w38a both pistons no longer retract at the same time. The behaviour got changed with the latest snapshot. People were used to this behaviour and a lot of redstone contraptions rely on it.Do people, that are responsible for bug reports, read those comments? Should I make a new bug report, that I've been misunderstood?
Please don't let me be misunderstood.
confirmed for 1.8.8
confirmed for 15w40b
awesome behaviour. works as intended if you ask me.
it makes sense. The mob sticks in the block and gets pulled by it.
I like this behaviour. It's very useful for a lot of technical applications. Sure it doesn't make sense from a real world perspective, but being able to push a block into an entity also doesn't make sense in the first place. I don't see a downside to it.
why was this fixed? By now this behaviour is documented on the wiki, can be used to determine the time in caves and I've used this behaviour in a redstone contraption.
yeah, whatever. It still works in 15w46 and I hope it stays this way. This beviour does no harm and after a few years this could be seen as a feature of the daylight sensor.
Completely agree with Dico. This is one of times, where a tiny "bug" gets fixed, without any concern what it breaks. Hardly anybody was missing the feature to disable a comparator with a redstone block from the side, some contraptions even work with the behaviour, that this wasn't possible.
Redstone as it is, is great. Toying around with it, in most cases does more harm than good.
Per se the changed redstone block mechanics are quite interesting. If it wouldn't break everything built so far with redstone blocks, that would be great. I think a good solution would be adding a new redstone block, that can power blocks. This would keep existing contraptions intact and offers more options to work with.
It would be so cool, if the "flower pots" wouldn't pop off.
Mr. Broes' (Grum) stance towards bugs was very clear: Bugs need to be fixed, and they will, at some point.
I agree, but somebody has to decide first, if it's a bug.
I'd like to see this as intended behaviour. Being able to push a block into a mob makes even less sense. But nobody would call it a bug. Apples growing on oak trees - working as intended. cobblestone can be made out of nothing - working as intended etc.
game play before realism. In the last year we did get very few new things to be creative with. If every new unintentional behaviour, that is different from the way it used to be, is condemned as a bug, this game will be only half as interesting.
This feature adds so many new fun possibilities, and there's almost no real downside. The only complaint I've heard so far is that mob crushers are broken. Folks just be creative! If the spiders are pulled along with the block, let them drop down into a seperate hole, after they're pulled - problem fixed. It even makes sense that a mob that is stuck in a block gets pulled with it, doesn't it? Being creative is what it's all about. Destroying this wonderful feature would be the wrong decision.
another "bug" fixed, that had no real downside, but some nice technical applications.
cool behaviour. needs to stay.
this is a seperate issue. snowballs don't affect mobs at all, they fly through mobs
confirmed for 1.9 pre2. snowballs fly through mobs now. It's worse than before.
confirmed for 1.9
further testing showed, that mobs aren't affected, that stand right in front of the dispenser, while those that are a few blocks away get hit. http://imgur.com/istJ6w6
maybe this picture makes it more clear: http://imgur.com/J3iELkP
If you reload the game, the naturally spawned skeletons will grow
skeletons, that are summoned by the natural spawn algorithm behave like skeletons, that were spawned with the /summon command. They're both shorter until they're reloaded. I checked it with a mob farm.
I also checked zombies, baby zombies, creepers and witches. Only skeletons seem to be affected.
if this bug gets fixed I hope the skeletons will keep their smaller size, which is also the 1.8 size and the size they currently spawn with. I don't see a reason to slightly change the height of skeletons. Changing the size would break contraptions, that work with the current skeleton size.
I thought it was intended. Mobs not spawning on redstone components is the best thing ever.
try this. the front piston sometimes loses its block and sometimes it doesn't, (It's random based, you might have to try a few times)
@Pepijn
I think hoppers are back to normal. There was always this little inconsitsency of hoppers, also in older versions. Depending on the locational update order it would either take 7 or 8 game ticks for an hopper to transfer the first item. For example if you have a pair of hoppers facing into each other, the clock cycle is always 15 game ticks, because one of the hoppers needs 7 gt to transfer the item and the other one 8gt. This was caused by the update order.
I'd like to see this fixed too, but don't know if there's a bug report yet.
Observers do give out 2gt pulses in most cases. The exceptions are observers that are updated by blocks events (block pushed in front of observers) or observers, that are activated by player inputs. This behaviour is similar to other redstone components (pistons). I don't see a reason to fix this, because it would require a rewrite of the order in which things are processed, which in turn would break countless things.
I also don't see a downside of observers giving 1gt signals in some cases. It's a useful tool, if used correctly and doesn't add confusion for people, that don't know about (see pistons, where exactly the same happens)
As long as redstone is unnecessarily laggy (see https://bugs.mojang.com/browse/MC-81098) I'll gladly replace every piece of redstone dust with observers. I've been working with redstone in the 1.11 snapshots and redstone dust won't be replaced 1 by 1 by the observer. There are still a lot of situations where you need RS dust.The observer is just one more tool, that finally helps us making our contraptions less laggy.
sad day. One of the most useful piston behaviours gets removed after being ignored for a whole year and two versions. It did more good than harm
It's open for interpretation what should be considered a bug. If I would make a bug report, that piston heads can penetrate entities, it would be marked as "Works as intended". But the behaviour is just as weird as being pulled through a piston or floating half a block over a fence block. All of those weird behaviours are useful for the gameplay.
doesn't relate to
MC-89030. powering a melon farm with short pulses never was a good idea. There are literally hundreds of working melon farm designs.this happened in 1.7.2: https://gfycat.com/OldfashionedZestyFly
As I said it was never a good idea to use short pulses to power a melon farm and I don't think this is even a bug. The melon item is created in the center of the broken block and the retracting piston arm catches it, before it has time to fly to the side. This is excactly what I would expect in a real life situation, where something magically appears out of nowhere and something else in front is moved back.
This is why everybody used sticky pistons with a block in front to break melon blocks. The item would glitch around in the solid block and fly to the front 95% of the time. Here's a simple 16w40 farm, using the observer block: https://gfycat.com/QuarterlySilverHackee
should I provide a world download? In 3rd picture the trapdoors are one block too high.
Steps to reproduce are: Make spawnable spaces. Put top trapdoors in the second block above the spawning space.
They don't power air blocks. They give out block updates. The repeater still powers the piston, but the piston doesn't receive the information anymore. Please try to understand the situation before commenting. You do this every time.
I don't see how this works as intended. Changing the mechanic doesn't contribute to consistency or less confusion at all. The only thing it achieves is breaking things.
@Panda. You're just nitpicking.
Let me do the same thing you just did:
I can also create an arbitrary axiom, that would be violated.
If I put a piston in front of the repeater, which updates the bottom piston, the conclusion would be that a piston does conduct power.
But you would only get this impression by disregarding how QC works.
Your arbitrary axioms are just an attempt to justify one specific issue in disregard of the WAI quasi-connectivity. Axiom 1 already conflicts with the WAI quasiconnectivity. Axiom 2 isn't even an axiom, but a design guideline. Axiom 3 conflicts with the way things work at the moment. The piston still gets powered, but doesn't receive the information.
The occasional disappearance of moving entities after chunk unloading probably also is related to that. Also sometimes moving entities get duplicated after chunks get unloaded/loaded
This is a duplicate of MC-107664.
The growth of 2x2 spruce trees also doesn't trigger block updates. see
MC-92630. All other trees are detected.This releates to
MC-109266, but is a duplicate of MC-107664. You were never able to detect the change of repeater/comparator on/off states.Proof done in 16w41a: https://gfycat.com/SnarlingKaleidoscopicCattle
It only seemed like this is possible in a line of repeaters/comparators, because the repeater updated the block in front of him. Since 16w43a repeaters/comparators only update solid-blocks, which another repeater/comparator isn't.
If you treat this is a seperate issue, you're missing the point.
confirmed for 16w44a.
I think everybody would like to see this fixed
The effect of the random ticks is almost negligible though. The effect is at least 100 times less than the predictable behaviour. I don't think it's worth keeping it, since the effect can't be observed anyway.
0 upvotes so far. Not an issue and never was.
I was talking about the players POV, which should be obvious. I didn't challenge anybody's authority.
confirmed for 1.11
@ziggurism OK. would be nice if somebody could make up their mind immediately when those changes are made or be a bit more careful.
if mobs should spawn on redstone dust, how am I supposed to make something like this spawn proof in the nether: http://imgur.com/a/vuqBw ?
(ofc there are workarounds, that require rebuilding)
the title is also misleading, since torches can be activated with 2 tick pulses: https://www.youtube.com/watch?v=VjzuJqWAPFQ
confirmed for 1.11
confirmed. I don't see a reason why a cactus should react differently to an end rod than to a glass pane
Ok I make a new bug report, because I can't put flower pots on glass blocks, which are also full surfaces
I doubt that's not worked as intended. Rockets are no blocks, therefore the build limit is irrevelant. You can also eat or shoot bows above BUILD limit
confirmed
worse than ever before in 1.11.2
I don't see why this is a bug or an issue. Portals have no collison box, therefore mobs can spawn inside of them. There are no exceptions to this rule. A large slime farm could also spawn 1 block next to portal and because of it's size immediately go through the portal. Or even 2 blocks next to the portal and randomly run into the portal. The result is the same.
There was a portal on the overworld side. We notice it all the time during normal gameplay. Somebody goes through a portal -> lag spike for 1-2 seconds.
confirmed for 1.11.2.
this breaks the entrace to my melon farm.
seems intended. Trying to change hoppers in a way, that this behaviour doesn't occur would very likely break countless contraptions. Hoppers transfer items every 8gt, but the first item is transferred after 7gt. This is a very important fact for countless contraptions, that rely on those timings, and the cause for this issue. Changing this behaviour, just so one redstone circuit behaves in a way somebody thinks it should, would be a bad decision. Furthermore you can make a workaround with redstone in order to avoid this issue.
why was it reverted?
ehm this is unrelated to random ticks. it's caused by faulty world generation and has been in the game for years. here's it happening in 1.12.2:
https://imgur.com/a/PNk9P
the transparent blocks are just a symptom. this doesn't deserve an own bug report
at least provide an intended alternative for this widely used behaviour without any downsides.
Previously frosted ice blocks that had fewer than 2 adjacent frosted ice blocks melted immediately.
yes. also an issue in 1.12 and very likely in the latest snapshots
I don't get why a shulker shouldn't be able to stay on top of slab, but staying on top of a double slab is fine. Recently the possibility to add torches at the side of stairs was added. Any chance the shulker behaviour will be reevaluated? In my opinion the surface should be the deciding factor. Shulkers shouldn't stay on iron bars but at least on slabs and upside down stairs.
i also think this was marked as duplicate incorrectly. The other issue was about something else
is this really WAI? fishes no longer enter boats. It was decided that dolphins sitting in boats isn't intended, which is contradictory. https://bugs.mojang.com/browse/MC-128241
not fixed.
not fixed for melon/pumpkin stems
fixed in 1.14
this is also very confusing for newer players
I added the system information in a text file
yes, I downloaded a program to track temperatures etc. Compared it directly with playing ARK on highest settings. Nothing seemed odd to me, but I'm not an expert.
My new PSU arrived today. Seems like my old one was causing the issues. Now it works fine. Sorry for reporting a bug. It was weird that it only happened in Minecraft Dungeons