kbk
- kuubaku
- kuubaku
- Europe/Moscow
- Yes
- No
MC-8898
Low
When you try to combo some corner stairs in snakelike layouts for decorative purposes, some stairs tend to corner outwards (1/4 stair) when expected to corner inwards (3/4). This disallows to loop such layouts into some nice, simple and space-efficient cyclic designs.
Screenshots depict 2 expectable patterns of such layouts. When you try to corner such layouts to create a "star" around a 2x2 square, a smaller "star" or a "zipper", you will either be forced to choose between goals like "corner the layouts nice" and "keep it small" (pattern A) or experience a pretty much unexpected corner stair behaviour (pattern B). In the last shot greater "star" consists of cornered A-layouts, lesser "stars" - of mixed layouts.
Same thing also happens with upper stairs.
Terribly sorry if duplicate, I couldnt find anything similar.
Outward corner stairshave priority over inward onesCorner stairs can connect outward when inward connection was expected
When you try to combo some corner stairs in snakelike layouts for decorative purposes, some stairs tend to corner outwards (1/4 stair) when expected to corner inwards (3/4). This disallows to loop such layouts into some nice, simple and space-efficient cyclic designs.
Scre
enshots depict2 expectable patterns of such layouts. When you try to corner such layouts to create a "star" around a 2x2 square, a smaller "star" or a "zipper", you will either be forced to choose between goals like "corner the layouts nice" and "keepit small" (pattern A) or experience a pretty much unexpected corner stair behaviour (pattern B). In the last shot greater "star"consists of cornered A-layouts, lesser "stars" - of mixed layouts.Same thing also happen
swith upper stairs.Terribly sorry if duplicate, I couldnt find anything similar.
When you try to combo some corner stairs in snakelike layouts for decorative purposes, some stairs tend to corner outwards (1/4 stair) when expected to corner inwards (3/4). This disallows to loop such layouts into some nice, simple and space-efficient cyclic designs.
Screnshots below depict what happens when you try to build such designs. Shots depicting the root cause of this are also provided below: as you can see, if reconnection of wooden stair is considered legit, brick stair connection is definitely a failure
Same things also happen with upper stairs.
When you try to combo some corner stairs in snakelike layouts for decorative purposes, some stairs tend to corner outwards (1/4 stair) when expected to corner inwards (3/4). This disallows to loop such layouts into some nice, simple and space-efficient cyclic designs.
Screnshots below depict what happens when you try to build such designs. Shots depicting the root cause of this are also provided below: as you can see, if reconnection of wooden stair is considered legit, brick stair connection is definitely a failure and vice versa.
Same things also happen with upper stairs.
2013-10-27_13.05.57.png
Obviously, pick block action on
retracted piston heads creates no new blocks in your quickslots and doesn't turn active the slot preoccupied by piston, if any. This was expected because when used on either door blocks said action returns doors, and when used on other active redstone components it returns their inactive versions.Sorry if dupe, couldn't manage to find any similar report.
Obviously, pick block action on extended piston heads creates no new blocks in your quickslots and doesn't turn active the slot preoccupied by piston, if any. This was expected because when used on either door blocks said action returns doors, and when used on other active redstone components it returns their inactive versions.
I guess this report is quite about the same phenomenon as the
drowning in creativewas, in some sense.Have seen this behaviour long since 1.4.2 and have just confirmed this in 1.4.6 SSP. This happens in 1x1 laddershafts of any height when you apply a water bucket on any unoccupied wall of the shaft (not just only the opposite one). This also happens with other wall-mounted items like torches. This behaviour also applies to lava buckets as well (due to same mechanics i suppose).
Lava bucket proof and torch destruction proof
Torch destruction yields no item though, which is definitely not ok.
Ok, I just tried to recreate Sethbling's setup from a video. Here are the results of the test I've conducted :
1.4.6
13w04a
Either this report is not a concern in the current snapshot or I've just done something wrong (e.g. my build differs slightly from Sethbling's or needs some huge redstone updates from other loaded contraptions) and my test fails. Anyways I think this report could be resolved at least for now.
As for me, in this report we are using the MC-8328 bug as a method to test something bigger that could (at least in previous releases) manifest itself in a number of different ways (eg giant extender). Moreover MC-8328 is still reproducible but this bug seems kinda fixed. So I'd rather keep the relations and mark this report as "could not reproduce" or "fixed".
Affects 13w05a too
This does not seem to happen to me at all in 13w05a.
Is still an issue in 13w05a. But AFAIK in fact cobllestone texture is the one that is off pattern by a half of a block. The two surely do not blend together visually.
Can confirm in 13w05a. Speed II beacon overrides Speed I from potion when in beacon AoE and then Speed effect vanishes when you get away from beacon.
It does happen in 13w05a and it seems to be intentional.
Technical consistency, i suppose. Slanted rails are placed on two equipotent supporting blocks and one (the upper in this case) of them gets destroyed - thus the rail gets destroyed too.
As for me, I think the whole slanted rail thing is inconsistent because a rail should not be 1 block long and √2 block long at the same time at all and slanted rails should have some kind of mid-block support (in the real world such slanted rail would just bend and crack under a minecart without some decent support).
Affects 13w05b.
Could probably be related to
MC-2486I see the same effect on snapshot.
I also find it a bit odd that tripwire does not orient itself vertically aligned with hook - only the tripwire in hook block looks tensioned upon hooking. Might be some technical limitations or something...
Ladders also cannot be attached (while they do attach to iron or lapis lazuli blocks) while torches and vines do can.
Speaking of vines, its downgrowth can be blocked with buttons etc - a nice decorative feature IMO.
I don't think this being marked as WAI is a good decision either.
In this case stairs do not generate driples but just look penetrable by rain. Penetration stops at lower third level of the block, where raindrops just dissappear. Such penetration also does not occur with upper slabs, fences, closed fence gates and even leaves albeit they all are transparent. Moreover leaves do generate dripples but are not penetrable by raindrops.
Why? And what do you think is being expressed by this animation?
In creative player cannot take environmental damage and this animation does not occur to start when he steps into the fire block, as it does in survival. I'm sure the main purpose this animation holds is to express the fact that player entity is taking fire damage (so the player could understand why the hell he takes damage all of a sudden).
This animation is also supposed to 'scare' the user by partially obscuring its FoV (and thus lowering the ability to predict the in-game situation around himself) but I think it is much less necessary and more of annoyance when player entity is invincible.
Please reopen.
This report might be related to
MC-122.Please create a single report per issue after searching if such issue has not been reported already by someone else.
Pigs cannot be fed with wheat since a millenia ago, see wiki for reference.
Dog issue seemingly duplicates
MC-3845Sheep/cow issue duplicates
MC-2025Ladders, buttons, levers and hooks still cannot be attached to redstone blocks in 13w06a.
This report is 50% cooler with clocks and really needs a better explanation.
Firstly, this is more like a
visual glitch, and less like an unintended redstone component behaviour. Secondly, I cannot reproduce this when both pistons are oriened horizontally, but this happens to bottom piston regardless the direction of the upper (unless it is not downwards). And I also feel like this behaviour could probably be caused by recent fix ofMC-8198.So i guess the report should be called something like "When powering piston on piston wrong piston looks preparing for extension" to avoid confusion, amirite?
Sorry for fastediting.
Could not reproduce this in 13w06a, probably for the same reason.
Persists in 13w06a
Can confirm in 13w06a; relates to
MC-9341(similar visual effect); relates to or maybe even duplicatesMC-9336.I've been just sharing my findings on what I had understood in the description you wrote. Your latest comment makes things alot clearer, but for my opinion current mechanic is alot more expected because it does not show symptoms of well-known
piston quasiconnectivity bug. I will surely check this in 1.4.7 later...Aha, and I thought that pistons are meant to extend in this manner too, but they don't due to
MC-9341- that's why I said "cannot reproduce" earlier. Thanks for highlighting that.Can confirm in 13w06a. Could not recreate with vines and other attachable blocks - only ladders seem to behave that way.
Maybe the author kinda tries to say that repeater could forget to update itself to be off-state when powered off a weakened DLSensor at night? Going to test this. Hope he could explain himself in more proper english (or even proper russian I presume).
Nope, this ain't happening =)
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-3259because 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.
I've just built a small device which recreates this report in a little bit different manner and highlights its possible relation to
MC-1361(at least I think these two could be connected). In this device the piston is retracted by the signal from the detector rail. If the delay of this signal is not long enough, device locks itself like a latch, and then blocks around the quartz pillar block under the detector become able to detect block updates.Here's a schematic for snapshots, feel free to play around.
@Florian
Yes, but the goal I was trying to accomplish here is to show that while a detector rail is, technically, a two-block redstone device (it strongly powers itself and a block it's attached to when active), not only the rail's state is messed up in this case, the underlying block does not get/send its updates properly too. So that when you power the piston off a rail - you get yourself a clock, and when you do the same off the quartz pillar under the rail - you get a BUD-latch. I suppose the latter effect is the direct logical conclusion of the rail's awkward reaction to being pushed.
@Tails
Strongly disagree.Creative inventory actually has a 'Delete item' recycle bin quite long since 12w22a, and any item stored in inventory (except quickslots) can also be blackholed in creative just by dumping it off dialogue bounds. Since a decent way of cleaning the inventory is implemented, there is no real intent to use such a kludgeous item pickup rule anymore.This is not a feature suggestion either because it is a request to make an earlier fix more consistent with the current UI, and a feature request for this exact case should sound more like "We need a rule/option/whatever to let player decide if a he should pick up dropped loot in creative".
Please, this should be reopened until we see a word from Mojang employees on this.Thanks.Wait. /gamerule is supposed to be a serverside option, isn't it? If so, an unfair situation could occur when someone (e.g. op) is enjoying his time building something in creative on his SMP server while other players are wasting their time, resources and effort due to disabled doTileDrops. Is it supposed to be ok?
Are you sure you've returned to the overworld exactly where your nether portal was built initially?
Is reproducible in 13w07a. A possible WAI/Won't fix case, though.
Was unable to force a crash at welcome screen - loaded a testworld.
Glitch is persistent.
Updated everything to no avail.
Unfortunately, DX11 and OpenGL 4.0+ features are not supported by GTX280 and since I am technically limited to 3.3, there wasn't any point in updating video drivers to the latest ones. I think the ones supplied via Windows Update were quite enough.
I'm sorry, but I'd have to disagree on that. Since the second crashlog and sreenshot I made were actually created after I installed latest drivers (as I've already stated), this is more likely a hardware compatibility problem.
To prove myself I've done a little testing on different machines and here are some logs I've managed to obtain latest Java and latest possible non-beta video drivers:
1) Intel Extreme 2.log is from a behemoth Roverbook Navigator W200 (assembled in 2003) equipped with Intel Montara-GM+ 82855 GME chipset. It supports OpenGL 1.3 and generally sucks at fancy graphics - and of course at title screen it exhibits this unexpected rendering (like on my screenshots)
2) Next - Acer Aspire 4810T (assembled in 2009) with its energy saving Intel Express Chipset GMA 4500M. Chipset is capable of handling Aero and can support OpenGL 2.1 but shows the same awkward title screen render as above.
3) Same horse, different chipset - ATI Mobility HD 4300 (supports OpenGL 3.3) surprisingly handles title screen pretty well. This leads to a conclusion that what we experince here is a lot more likely to be either hardware- or vendor-specific and less likely - driver-dependant.
By the way, 13w09a is affected too. Please, consider reopening.
Affects 13w09a.
Don't think so because sl: shows the maximum possible skylight exposure level at the spot you are standing. For my thinking, rl: should instead change at night here. However, this has already been reported in
MC-911and some linked reports.Affects 13w09b.
Reproducible in 13w09b.
Affects 13w09b.
Built a device that draws power from every possible source of the setup (normal detector - block under the detector - pushed detector - block under pushed detector). Apparently, when active detector is pushed, the block that gets under the detector can act as a separate power source if the adjacent redstone receives a block update.
This affects 13w09b. Activator rails are affected as well.
Can't reproduce either.
Was able to recreate back in 13w06a, but now in 13w09b it looks fixed for me except for
thiscase.Not yet fixed in 13w09b.
This is still an issue as of 13w09b.
Can anybody reproduce this in 13w09b? Looks fixed.
Could not reproduce in 13w09b.
Affects 13w09b.
Hmmm. This looks too stable and consistent to be a BUD... at first glance.
I toggle the switch - torch goes off - piston retracts - redstone orientation changes - torch magically stays depowered. Then I toggle the switch again - torch magically regains power - piston extends - redstone reorientates to correct state. I get this 100% of the time, but when left alone for some time in this magic state, torch updates itself and piston performs a cycle. Such a funny device...
The pistonless setup on the first screenshot works as expected to me though.
Affects 13w09b.
Affects 13w09b.
Still happens in 13w09b but... can anybody provide a working design where redstone wire does not turn into a dot on connectivity change? I can't come up with any.
Still needs to be fixed as of 13w09b.
Sounds a lot
MC-9553'ishto me.Feels like you didn't search properly. Have you seen
MC-10415?While fixed for piston in 13w09c, this has not been fixed for doors, fence gates and noteblocks (those devices emit sounds), droppers and dispensers (those get triggered, but IMO the community probably won't be happy about these two getting fixed). Also checked that this setup doesn't work for hoppers, dunno if were affected.
This is still an issue as of 13w09c.
Affects 13w09c. Spawning poor guys off a 10 block tall wall is quite enough to make them "comfortably numb", slapping them afterwards - to stop acting like this (hence in creative mode).
You should not include versions you can't lay your fingers on yet as affected.
Additionally, this report duplicates MC-1794.
This report is closely related to
MC-3114(and even dupes a part of it). Hope that is going to be fixed as well.Yep, I can confirm this in 13w10a.
Still ain't fixed as of 13w10b. Bawwwww.
Doors, trapdoors, fence gates and note blocks still emit their respective sounds in 13w10b.
Still an issue as of 13w10b. Hitbox is also still rendered in inventory, which may be partially related to MC-2791.
@hfog
As for the setup I use, dispensers and droppers still react to 0-tick on low edge (when switch is pulled off) as they did snapshots ago. So it seems like the recent dispenser mechanic change had really nothing to do with this particular bug.
Nevertheless, these devices still fire properly off 1-tick clocks and I feel like
640 KB of RAM is enough1-tick is still pretty rapid for a dispenser.This has been described previosly in
MC-8581(and maybe elsewhere too).Can confirm in 13w10b. Not sure if not intended though.
Came up with this clock oscilliscope setup while testing this report. Everything described below is valid as of 1.5.2pre. Fun facts:
0) This seemingly orientation-independent device consists of a simple repeater clock and 8 oscilliscope lanes (3 test lanes and 1 for control purposes on each side).
1) Each test lane in this device oscillates (almost) as expected when its respective controlling repeater (which are on gold blocks) has a delay that is lower than the clock has.
2) When lane's controlling repeater has a delay greater than the clock has, it should oscillate only when one delay is divisible by another, otherwise the lane should become locked. However, this does not happen to 1st and 3rd test lanes (repeater->block->payload and repeater->payload) when clock is set to 2 and repeaters are set to 3. Instead these lanes output a stable 3/5 signal. When toggled manually from 2 to 3, these repeaters are likely to lock their lanes. When toggled again to 4 in this locked state, they don't unlock the lane (like it happens on the reporter's video).
3) When lane's controlling repeater is delayed as much as the clock is, 1st and/or 3rd test lanes may output a 3x/x pulse instead of expected x/x (for instance, 6/2 where 2/2 was expected). This depends largely on redstone wiring (e.g. which exact quartz block is used to support the wire which transports signal to the lanes).
4) When all delays are set to 1, every lane (including control lane) outputs either 1/1 or 3/1 pulse. This also depends on wiring. Generally, if 2-clock pulse passing over some exact quartz block does generate 6/2 strobes on 1st and 3rd lanes, then 1-clock pulse passing over that block will give a 3/1 strobe on every lane.
5) Set the clock delay to 1. If you swap your controlling repeaters for comparators, they will lock test lanes in low state. If instead you swap first receiving repeaters of each lane for comparators, you'll get to see that either all four lanes are down, or 1st and 3rd test lanes are locked up, or even all the test lanes are up. This, surprisingly, depends on timings: you have a chance to get each outcome out of these three after reconnecting the redstone through any quartz block you like in the exact wrong moment.
6) I have built two similar devices: one 2 chunks east and one east-oriented a dozen chunks southeast. They had to be wired through some other quartz blocks to output the same doughnutlike patterns as this device does without comparators.
Yes, there are some cases when you get 4.5 hearts instead of usual 2.5 for a 16 block fall (6.5 hearts w/o protection) with FF IV boots. However, these spikes happen with no regard to sprinting, but due to some randomness in armor protection formula. Anyways I can't hurt myself any more than 4 hearts for a fall, sprinting or not.
What is strange here is that spikes distribution is probably too far from what wiki implies. While it says 4% reduction per "EPF (18 in this case) .. multiplied by a random value between 50% and 100% .." (which leads to 36%..72% random reduction), I almost never get 3 and 3.5 hearts damage.
Can reproduce but not with jumping. To me this happens from time to time when I am too close to the block I am trying to put repeater in. How to reproduce:
1. Build a 3x2x2 wall of any material you like.
2. Extract a block in a center of this wall on your head level to form a niche.
3. Try placing a repeater in the niche while holding walk key against this niche or just standing too close to it.
This seems direction dependant. I can only experience this putting a repeater in east or west direction.
Yep, probably it's the same bug as
MC-8471describes. Its funny that I also couldn't recreate this today for a second time until I've done what reporter suggests - jumped in 2 meters high space trying to place repeaters under my feet.Now I've opened some doors, killed some zombies and shot myself a couple of times and I can't reproduce again. Such a wonderful heisenbug I'd say.
Yep, still can confirm in 13w11a.
13w11a: 36 fps main screen, 1500~1700 fps world selection screen, 180~200 fps pause menu, 40~110 fps ingame (SSP), 30~45 fps and slight movement lag ingame near
theseclocks (suferflat CSP), 5-10 fps and heavy movement lag when you move 10 chunks away from the said clock lanes' far end13w12~: 36 fps main screen, 1400~1600 fps world selection screen, 200~220 fps pause menu, 50~130 fps ingame (SSP), 55~70 fps and very slight movement lag ingame near clocks (CSP), game freezes completely when you move 10 chunks away from the said clock lanes' far end
13w12~ reupload: 36 fps main screen, 1500~1600 fps world selection screen, 210~220 fps pause menu, 70~140 fps ingame (SSP), 90~120 fps and still a very slight movement lag ingame near clocks (CSP), game still freezes when you move 10 chunks away from the clock (definitely should re-report this separately)
Environment: win7sp1 x64, java 1.7.0_17, Intel Q9300 @ 2,50 GHz, 4Gb RAM, Geforce GTX280 v.314.07 @ 1024x768
This is an old bug and does not actually relate to doors.
Occasionally lava source blocks do not fill buckets correctly (serverside) and minecraft restates the faulty bucket (clientside) in your inventory as empty when you happen to update its item. If the item is in your hand it restates immediately after you use it (right click) even if you actually use something else like a door. Because you cannot stack full buckets, they also appear full in your inventory when (pseudo)filled. In this case your bucket will be restated when you try to move it in inventory.
Guide to reproduce:
1. Take 10-20 empty buckets to the lava source.
2. Quickly use them to drain as much source blocks as you can reach.
3. Try to move your lava buckets within your inventory or use them in any way. There is a chance some of them would reappear empty. Repeat if necessary.
In 1.5.1 lamps alone (like in reporter's setup) are not affected by this issue. Contraptions with lamps powered off repeater clocks and/or through sets of repeaters are affected though, as are repeater/comparator oscilliscopes or light-emitting devices of similar complexity. Moreover, such contraptions can induce a lagging that is even more severe when player stands exactly 10 chunks away from said contraptions.
Just seen this happened in 1.5.1 pre while testing
MC-1692.@Piotr
FYI: According to this Oracle release note JDK6 development is already stopped.
Looks like a duplicate of
MC-9489.Funny that I cannot reproduce it. If both reports are made on unmodded vanilla (which is not certain yet due to both reporters have provided no crashlogs yet) this makes up for yet another heisenbug.
This is also valid for dirt (when transitioned to grass), firing dispensers and droppers, hoppers, daylight sensors, trapdoors (when arrow can't fall through), pistons (arrows in piston base are updated trice per on-off cycle) in 1.5.1.
Ok. Left to right: lesser "star" (4x4), "star" (6x6), "zipper" (2x3+, scalable).
Still can reproduce on all nVidia and Intel GPUs in my posession.
IMO it'd be a good solution to redstone block problem when redstone devices that have a "face" (namely droppers, dispensers, pistons and future similar blocks) would be unable to receive power diagonally through their "faces" (similar to repeaters/comparators). This has only been implemented with pistons and for the directly opposite strongly powered blocks only, which results in such redstone block (mis)behaviour. Such partial implementation doesn't include other blocks in 3x3x2 space in front of a device, allowing for undue diagonal and - in the case of device facing upwards - vertical powering.
@tavis
I hope you'll see that limitation should be extended when you reproduce this by simply putting a redstone onto a redstone block in front of a piston (direction doesn't matter).
@dirk
It is much likely to be considered not intended by Mojang, if I understand Dinnerbone's tweet on this matter correctly.
I think they've added vertical connectivity (and quasiconnectivity) to compensate for being unable to place redstone and attachable devices onto a piston, which is a transparent block (like stairs, fences and glass) due to the limitations of current rendering engine. The engine is being rewritten as Dinnerbone states, so I believe we may expect that pistons would possibly become opaque and attachable, and this weird way of powering would thus become unneeded.
Cauldron water is not transparent at all to me either.
Indeed it is.
What you say could possibly be the effect described in this comment inFurther testing shows this less likely to be related (though reproducible).MC-1018thread.Nope, it is likely to be a result of
MC-1403andMC-10077coinciding.1.5.2pre is still affected.
Still not fixed as of 1.5.2pre.
To clarify, if you place a torch adjacent to a t-rail, the t-rail actually can change direction when said torch is controlled by some signal. Placing and removing the torch, however, does not affect t-rail direction even when the circuit that provides that signal exists. In such case t-rail also disregards a zero-tick pulse created on torch placement when the circuit is on.
Affects 1.5.2pre as well as 1.5.1.
I agree, this could be tagged as fixed.
Looks like fixed or can't reproduce in 1.5.2pre. Any suggestions?
I have a GTX280 yet I can't reproduce this on 1.5.2pre. Is this still a concern?
@fibonatic
Glad you confirmed this. It also highly depends on how the signal is transported off the clock and - at higher delays - on how the payload (if any) is connected to a repeater.
This is, most likely, an intended case since horse saddles are removed in newer snapshot after their mechanics are adopted by piggie saddles. Chunks containing any references to nonexistent item id (entities and tile entities in case of horse saddle) are probably just considered corrupt by the game and thus are recreated on load. Hope you've saved a copy of your worlds before moving to snapshots.
Can confirm in 1.5.2 using lava buckets. Apparently, empty bucket or its removal is being treated as if you were swapping the fuel.
Still can reproduce in 1.5.2. I hope someone could consider reopening this so this can eventually be recognized and fixed.
Wrecking a boat should also be on the list of actions that produce drops in creative.
Also this report is still valid for 1.5.2.
Confirmed in 1.5.2
Can confirm for 1.5.2
@Marcus
Sorry, but I'd like to disagree since there actually is a technical possibility for this. We can pick huge mushroom blocks for mushrooms, for example.
@Yoann
Good job, thank you very much.
Daniel probably does. I also think that this bug is more likely to occur if held consumable replenishes alot (e.g. baked pork, steak) but leaves 1-2 points left to regen - and less likely if you try to eat something like cookies being barely alive.
Warren, why so?
While this is being fixed, I'd like to ask one more time why can not one obtain pistons (ID 29 or 33) via pick block from extended piston arms blocks (ID 34) yet, esp. in creative mode, as I wrote earlier
MC-15099(and was misunderstood, probably).@Jesper
Yes, as for today we can pick door blocks for doors, bed blocks for beds, glowing redstone ore blocks for redstone ore, huge mushroom blocks for corresponding mushrooms, and most redstone-related technical blocks give their stable counterparts on picking - with the exception of piston arms. The only other unpickable tech blocks can't be picked due to them being related to fluid or portal. We can even pick a command block, which grants an easier way to abuse CMP servers, yet we can't pick a piston arm for a piston.
@Torabi
I got you. That won't do given that, firstly, the community is generally much less interested in minor logical consistency and integrity related issues like this one than the devs are, secondly, I generally suck at writing posts in order to gain community's support, and thirdly, I actually don't like to spend time irritating this community. All I wanted to do was to ask Mojang "Are you surely sure?" - that's all for now.
Grum, can you (or anybody else) please provide any decent list of all the useful designs that will probably be mourned about if quasiconnectivity would ever be disabled?
Dear Alex and Keybounce. The invention of redstone block made BUD designs without quasiconnectivity possible. All those people above are trying to tell Grum that BUD ≠ quasiconnectivity and the latter is a pure bug, that deserves to get squashed. Yet you guys want Mojang to add not one block but 4 redstone devices with this illogical behavior. Why'd you want that?
13w39a confirmed to still have this.
Not really as bad as it was back then in 1.4, but still noticeable in 13w39a. I experience like -20 fps and laggy rendering when I turn on the clock similar to the setup on the second screenshot.
13w39a - confirmed.
13w39a - confirmed
13w39a - confirmed
Well... DLS does not produce strong signal. Sure you can power a lamp off a DLS yet you can't power anything off a lamp.
I guess this case should probably be reopened.
@Kumasasa
Does it solve the problem of the ticket?
The goal this ticket tries to achieve, I guess, is to bring some uniformity in how less-than-a-half-block-tall redstone-emitting devices (like, namely, pressure plates and detector rails) push their signal through blocks. I mean, if DLS really should weakly power any block (including lamp blocks) under it so you can't route signal off the latter (unless its not a block but a redstone beneath it, which automatically makes the signal "strong") then this case should rather be closed with "Works as Intended"/"Wont fix" instead, and not like this.
This is still valid indeed.
The piston hitbox can now sometimes be seen partially in front of it, offset by the width of piston head. Piston head hitbox can appear offset likewise, and it also may appear behind the piston.
Yes, it is as valid as has ever been.
No progress made here since back then, I guess.
Well, Kumasasa, your image shows that hitbox and colbox positions indeed are now aligned properly with the player model. But this report was mostly about the fact that boxes' very appearance in inventory makes no practical sense.
I'd be glad if this gets voted and reopened.
Since I've heard something about Mojang going to rework data values for blocks, I feel it'd be convenient to update this report. Here goes.
Valid for 14w17a
Still valid for 14w20b
Still valid for 14w20b
Still valid for 14w20b
I guess not. Additionally, my test sheep refused to pass junction in first setup.
So, what happens here:
1. I put a minecart on the south-facing track and provide the junction with two detector rails on southern and northern tracks. Junction assumed its natural south-western orientation.
2. I pull the cart. Cart passes the detector for the first time. Junction assumes innatural north-western orientation.
3. Cart passes the junction straight north (which is normal), returns back, presses the detector to the right and successfully goes west.
4. Cart approaches the junction. Southern (leftmost) detector activates, junction assumes innatural position due to this, then for some reason minecart bumps back west with all the momentum it previously had.
Apparently
a) for some reason it is definitely tested whether the minecart can pass the junction towards the active detector. I suppose such check happens at least twice: right before the detector activates when the junction is approached by minecart (true) and then again after it toggles the junction (false).
b) the detector that will become active first is chosen directionally (e.g. there is currently no way for junction to store and reuse some unrelated data like "last active signal source", "last known minecart direction" or "what does the sheep say" here)
And here, if we rotate our setup to the south, both detectors become active and the minecart can go to the right and back.
@Pokechu22
Aw come on, we now have daylight sensor, have some BUD designs made without quasiconnectivity, even have slimeblocks. They now have Searge and Mog, these brilliant minds, and it's been almost a year since Jeb and Grum closed this ticket (yet there was a huge lot of very productive discussion after that), and 1.8 is still not ready enough to be off beta allowing for huge mechanic changes - I feel like now is the perfect timing to get this at least reopened.
Still valid for 14w21b
@Christopher Martin
It has been like this all the way since 1.4
No, Tails' device still exploits this bug like it ever did.
Still valid for 14w27b.
Still valid for 14w27b
Still not fixed as of 14w27b
This can be exploited by mapmakers to create enormous self-powered tracks with but a pair of torches.
Kinda still not completely fixed as of 14w27b. Don't know if really deserves fixing though.
Sadly, it is, Ezekiel.
Probably fixed. Spent 4 stacks of buckets in survival to drain a small lake - no bucket was considered empty by the game.
Looks fixed to me.
14w33a - not fixed
14w33a - not fixed
14w33a - not fixed
Starting to sound like a broken record today, but this is still valid as of 14w33a
14w33a - still... uh-oh, probably deserves to be taken care of, probably...
Lighting is still a bit laggy in 14w33a.
Yes. Tails' device behaves just as in description.
Yes it is. Dispensers dispense, droppers drop, other devices commit visual/audial actions.
Cannot confirm too. Needs proof or details if true.
1.8.1 pre4 - valid.
Still an issue in 1.8.1 pre4.
This ticket is still valid for 1.8.1 pre4.
'Lamps' in last Isaac's statement and, probably, in description should be changed to 'redstone components', most of which have had their lighting disabled some time ago for the very reason this ticket exists. As for lamps, lighting is their essential function and obviously could not be disabled. I suppose when this gets fixed, wires and comparators should again become able to emit light as well.
Yes, easily reproducible in latest snapshot (15w49b). Seems to be endemic to ladders as vines, torches etc are placed for sure.
Reporter's device (see vid in description) easily reproduced on latest snapshot (15w49b).
Ah, response, yes.. Well, Jim, your setup is doing what it is supposed to do when a door is used instead of a piston. I mean, the door actually performs a noisy twitch in same setup. So, I guess this bug is still there.
Well, it still does. Please let me know if you gentlemen have difficulties understanding / reproducing this ticket so I can come up with a clearer description and / or new screenshots.
Let me elaborate on this with some new screenshots. I suppose birch ladder blocks probably should not connect (at least the way they do, that is).