Kabo

The explanation lies with the update order. The top sticky piston tries to retract before the bottom right-facing sticky piston, so the slime block connects to the bottom upward-facing sticky piston, and the movement is blocked by the extended arm of the bottom right-facing sticky piston.

This behaviour is unique to slime blocks, so normal blocks work the same. In order to get this device to work with slime blocks, simply remove the bottom right-facing sticky piston. 🙂

This one is actually a bug. The melon should not break.

This is the intended behaviour.

It may appear not to be logical at first glance, but I would say that Minecraft logic is often very different from real-world logic. After all, if you trigger a piston with 12 blocks in front, but no blocks behind, why doesn't the piston move backward?

So, keeping this weird kind of Minecraft logic in mind, we did think very carefully about it, but it's something we decided not to do since our design for the new feature was focused on allowing as much flexibility as possible with the new functionality while having one simple set of rules for slime blocks that affect existing functionality as little as possible (designs without slime blocks should actually have not changed at all).

I'll try to explain some of our primary reasons for implementing it the way we did:

1. Allowing non-slime blocks to move attached slime blocks is changing functionality on existing non-slime blocks. This one sounds a bit confusing at first, but maybe think of it this way - should a non-slime block or a normal piston think that it has any reason to move a neighbor that isn't in front of it along it's direction of motion? Looking at it this way can be considered a design decision, but we like to think of the new feature as something belonging only to moving slime blocks rather than applying a generalized idea of "stickiness".

2. Making slime blocks always "sticky" means we limit what we can do with slime block + non-slime block combinations. Once they're stuck together, there's no way to separate them by using pistons. We thought this would be more problematic than useful.

3. If slime blocks are always sticky, how should they behave in front of normal pistons? If they are supposed to always stick, this means normal pistons are effectively sticky pistons when they have a slime block in front. We have to deviate from the stickiness rules and create a special case for normal pistons if we don't want them to stick.

4. If we expand on this idea and say that sticky blocks in general should always be sticky, then the 'logical' extension of this idea is to also say that since sticky pistons are sticky, they should always be sticky. This is the extreme case and there is no way we could implement this ... it would just break too many things since it is a major change to existing behaviour. However, also consider the case if we had decided to implement slime blocks always being sticky, but not implement sticky pistons always being sticky just to avoid this problem - does that seem logical?

I think I've covered most of what we discussed when deciding to only implement it on the slime block - there may be some other things that I don't remember right now, but I hope this is helpful for explaining the reasoning we used.

The purpose of the bug tracker is to bring issues to their attention so that they can make this decision. If their decision is to be irresponsible like you are suggesting, that is, as I said their decision even if I disagree with it.

I made a sarcastic comment there to highlight the point that what the developers have been doing and saying seems to indicate that they have not made a clear decision on what is intended (e.g. Jeb doesn't want unlimited effects and enchantment commands and has implemented limits in the past, but he implements the give command to be able to provide unlimited enchantment levels; although this would be a different issue that the fishing one, that brings up the question of if this intended).

Ah... so it's a result of mixed signals coming from the developers. I see where our disagreement on whether or not this should be treated as a bug is coming from. Jeb was the one who implemented this, so I guess we should assume then that the fact that enchantment levels are not being limited by the give command is a bug that should be fixed before the 1.7 release? https://twitter.com/jeb_/status/374924741267951617 😉

That's just the thing... this is not the enchant command. It is the give command, and by using the give command it is possible to add an enchantment of a greater level. What you appear to be doing is just to making a claim that the enchant command's range, which is the survival range, dictates the range of other commands, which is clearly not the case here.

I have not seen Jeb making a statement that he won't fix bugs with levels outside the range available in survival, and I am inclined to believe this is not the case as there is precedent for fixing bugs outside the survival range. If he has made this statement somewhere, then that is their choice to make, of course, and there's no choice but to go along with it (even if I disagree with the approach), but if this is an assumption based on the approach that was taken with the enchant command, then we cannot dismiss the fact that this may be a bug and then there is also the implication that there should be another bug report saying that the give command can produce enchantment levels outside the range available in survival.

What is the rational for deciding that this is invalid because it is only possible because of a command? Not everyone plays survival and using /give is a method provided by Mojang which makes this easily possible in creative or adventure maps via command blocks. The assumption that a bug is invalid because you have to use a command is a poor assumption; there are many bugs with commands that have been corrected and many that still may need to corrected.

Also, as I mentioned before this issue is separate from the potion effects. Enchantments and potion effects are handled by completely separate game mechanics and this is not simply an issue of an effect not functioning it actually breaks a game mechanic. If you want to make an comparison to potion effects, then this particular bug is more appropriate: MC-10510 (this, by the way, was fixed by Mojang demonstrating a precedent for resolving issues like this).

Torabi - Yes. It is only reasonable to be concerned with it if they add a method to acquire values outside of the intended range; it is poor practice to ignore things that break game mechanics.

The problem here is that fishing is completely broken above level 8; this is unlike the potion effects, which may have limited levels of effect, interesting interactions with other effects, or which invert at level 128. In the case of Lure, it's not that the effect does not become stronger, it is not interacting with any other effects which slow down fishing, nor is it even slowing down fishing (as an inverted potion effect would) - it just completely breaks fishing.

So, the question we have to ask in this case is, "Is the design of the Lure enchantment such that fishing should no longer work after level 8?" If it is not designed this way, then we can say that this is a bug.

After that, we could argue about the approaches that could be taken to fix bugs that are caused by users doing things that were not intended, that is, whether they get corrected (and, if they are corrected, then how do they get corrected), whether they are treated as features (e.g. BUDs), or if the users are just prevented from doing the unintended action - but I think we can probably agree that just showing no concern and ignoring it is an approach that Mojang should not take.

Dustin, I'll agree with you on one point. We shouldn't have had to worry about a patch here. Any object that you plan to use later and is generated based on a random seed should be saved rather than leaving it up to chance that it doesn't break between versions; this is something that was a development oversight from the beginning and should have been fixed much sooner.

Concerning the method you are suggesting, the first issue comes from deciding which version to use. How do you know that the chunks being loaded were from 1.6? Without patching 1.6 to add a tag to each chunk telling it which version generated it you would have no idea since these data do not currently exist. this leave the same problem of having to walk around and load the chunks you want to keep.

Next, how many differences are you going to track? Would you copy the structure generation for every version where it changes or would you try to do it by line items in the code? Either way you're either duplicating the code for each version OR having to branch the generation at every line where a different random call or set of random calls is made. Neither is a desirable solution.

If you are concerned about forgetting to load a structure that you desire to keep, my suggestion for you, depending on how close to vanilla you want to play, is to make backups before you change to the new world and retry, wait for a mod that will load them for you, or (possibly the best option) generate the structures in a backed up 1.6 version that saves them, then copy the structure data for the particular structure in question over to the 1.7 version (this is extremely easy and I've already given an explanation on how to understand the structure data in a video).

It should work properly for lure levels 1 through 8. I have checked this by experimentation and by examining the code.

1.6.3 only saves structures for 1.6.3 generation. The implementation for saving structures, however, does allow for any properly formatted structure data to be loaded, so you can use a post-release mod for earlier versions to save their structures if you need to, and they will load into the 1.6.3 or later vanilla versions, OR if you know what you're doing, you can use an external tool to edit the structure data and create structures where you need them (many people would consider this cheating, but if you're trying to fix a structure it might be a different story).

It is not necessary to mark chunks as having generated structures. For several versions, there has already existed functionality to prevent generating structures in chunks that already have them. When they are loaded in, they should be associated with the chunk they are created by and no other structures of that type will try to appear.

My fix just uses the same method of saving to .dat files using NBT data used by the villages, but the data structure is actually handled differently and in my opinion a bit more carefully. I have indeed tested it, and did find it to be working; I did a couple of tests: the first involved completely disabling the regeneration call for structures and the second involved adding 1000000 to the seed for the random object used for nether fortress generation. In both cases, the previously generated nether fortress which I had saved was still generating it's mobs and was properly saved.

The village issue is actually related to something else; Tango and I have talked about it and the bug report does not exactly describe the reason that villages break. Another thing to note about villages is that they do not save data for the nether and the end - this is something that I discovered when writing my fix.

I see what you're saying about the discussion here, it can be hard to get a grasp on what is fact or fiction, especially since we have such limited interaction with Mojang with it actually comes down to the code.

Also, I, personally, have no problem if Mojang chooses to use a different, better solution from mine as long as it is functional, comprehensive, and planned for future development (I tried to make mine this way by saving all object details using NBTs so that they can be reloaded exactly as they were saved, but there's only so much you can do when you don't actually work for them.). I'd only be upset if they end up taking a half-serious approach.

I feel I should comment on this conversation.

The issue over whether or not this is "easy" is really a non-issue as it's easiness is really something to be determined by the Minecraft developers. What I mean is: even if my solution is "easy" in my mind, it might not fit well with the vision that the developers have for the way Minecraft is coded, thus, it may be difficult for them to implement especially if the have planned a huge reorganization of the code.

Also, since it seems like people are curious here, I'll also say a bit about the solution I developed - the idea is that structure data are saved exactly as they are in the game to a .dat file using the NBT classes in a similar way as the villages; this uses the existing methods that already exist in the code and tries to avoid as much as possible having to create something new just for saving structure data. When the data are loaded it creates objects for each structure, so ideally you could save and load a structure exactly as it was when it was first generated by the world. That was the idea when I developed it, anyway.

Also, as far as usage rights go, this is just my personal case, but I have no problem with Mojang using and distributing any or all parts of the code I developed for this solution without attribution (though, it would be nice of them if they did) and they are welcome to contact me if they need to go so far as to get something legally binding from me.

Edit: It looks like I might have misunderstood Torabi; it's good to make a point about efficiency, but in this case the saving and loading is quick and keeping the structures shouldn't put more load on the game than if the structures were loaded anyway (which isn't much ... they don't get ticked and only become an issue if you have so many structures loaded that they started needing too much RAM).