Vanilla Minecraft News Discussion

[FlowerChild]

Not sure if it's intentional, but trap chests allow for extremely effecient storage rooms: the trap and normal chests can be placed next to each other. You can effectively have a wall of chests.

That strikes me more as a very gamey exploit rather than an intended feature.

[Katalliaan]

Unfortunately, Dinnerbone says it's intended: https://twitter.com/Dinnerbone/status/2 ... 2464616448

[Sarudak]

Unfortunately, Dinnerbone says it's intended: https://twitter.com/Dinnerbone/status/2 ... 2464616448

Wow... Just wow... The crazies are running the asylum and return to home can't come soon enough!

[FlowerChild]

I suspect it's likely more just a bi-product of their inclusion that they decided was useful and thus are labeling as intended.

If that kind of storage organization was desired, they probably would have been better off with different colored chests based on wood-type. Requiring a trip wire just for that kind of functionality is rather out there.

If I move to forge and thus finally get access to extended blockIDs, I might throw that in there to provide a less gamey way of getting access to that functionality.

[Sarudak]

But it such a dramatic example of how little they care for any concept of design coherence. How little they care about metagame factors intruding on the game.

[FlowerChild]

But it such a dramatic example of how little they care for any concept of design coherence. How little they care about metagame factors intruding on the game.

Sure, but it would be a pain in the ass to resolve code-wise (the physical connection between chests of different types).

Hence why I think if they are to go that route, that providing a more legitimate way to access the same functionality would be the way to go.

Basically, establish the precedent that chests of different types don't connect, and thus can be placed next to each other, but do so in a fashion that introduces a less gamey way of doing so.

As it stands, they're requiring players to build something of a different purpose entirely in order to get access to functionality that can't be gained otherwise, which is where it starts crossing the line into meta-game territory. If you had the colored chests for example, then the trapped chest would just be yet another of a variety of such options, and it wouldn't feel out of place.

But yes, they obviously either don't give a damn, or just don't know any better design-wise (which I think is the more likely of the two).

[Sarudak]

Oh. I would just disallowed placing chests of different types next to each other at all. But then I wouldn't have allowed chest stacking either...

[FlowerChild]

Oh. I would just disallowed placing chests of different types next to each other at all. But then I wouldn't have allowed chest stacking either...

Keep in mind that the underlying problem is the chest behavior we've all become accustomed to in vanilla.

There's no good in-game reason why chests can't neighbor on each other. What it is instead is a problem with the auto-connect functionality not knowing which neighbor is the valid one for double-chests, so, we wind up with the weird rule that only two chests can neighbor each other, for which there's no good reason other than a metagame one.

Chests probably should have originally been designed either with a manual method of specifying the connecting neighbor OR, they should have only existed as double-blocks, much like doors (since who really uses single chests anyways?).

But regardless, we're stuck with them the way they are given that so many worlds are now dependent on the way they currently function.

Given that, I think there are multiple ways to resolve this problem in terms of functionality, without exasperating the metagame issue chests already represent. My personal approach to that would be the colored chest one I mentioned. I'm sure people would like the visual variety, we already have the multiple colors of wood, it doesn't have the same kind of gamey creation method that trapped chests do (having to use a trip wire to gain access to chests that can immediately neighbor each other), it's trivial to implement, and IMO, it doesn't make the double-chest problem worse than it already is.

IMO, the problem with using trapped chests to provide this functionality is that it just draws even more attention to an existing metagame issue by providing a metagame way for the player to resolve it.

[Sarudak]

Hm. Well i never really thought of the way double chest being unable to be placed next to each other as metagamey. I just always accepted it as being just the way minecraft is like how I accept that you can store over 3000 cubic meters of stone in a little 1x1x2m chest or how things don't happen when you're not nearby. Although what you're saying does make sense I've generally liked the restriction because it forces me to build larger storehouses and adds some design constraints to storehouse construction.

[FlowerChild]

Actually, nm, the underlying problem could be addressed on Mojang's end, even now. It would take a bit of work as it would likely mean a save-file conversion though.

What they could do is put data into chest blocks (either metadata if there's room left, or use the tile entity already associated with them) to create hard connections between chests. Then, convert existing saves so that neighboring chests generate those hard connections automatically. Since they can't neighbor each other otherwise now, that information is already inherent in their placement.

Then, remove the placement restrictions on chests, and when you place a new one next to a chest that doesn't already have a hard connection to another, they auto-connect.

Would eliminate an existing metagame problem, wouldn't mess up players worlds, and would avoid this kind of gamey nonsense like with the trapped chests entirely.

That's probably the most elegant solution here from Mojang's perspective. From a modder perspective, I think the colored chest thing is the way to go.

[FlowerChild]

I accept that you can store over 3000 cubic meters of stone in a little 1x1x2m chest or how things don't happen when you're not nearby.

Both of those are consistent with the game rules however, while the chest thing is not. There's just no justifying it in-game, nor is there any other precedent for it in terms of other blocks.

Even in terms of things not happening when you're nearby, I've always thought of that as Steve generating his own reality around him by his very presence (kinda like a dream), which even fits in somewhat with the dreamy nature of the end text (which I of course loathe).

I had been working that element into the backstory of the mod actually.

[Sarudak]

Ok I buy that explanation. I'm really curious now though. You say things only happening around Steve is consistent with Steve generating his own reality around him as in a dream. Does that imply that you plan to have things happen when you're not there in return to home that is supposed to be the 'real' world and not a dream? And if so how could this technical miracle be accomplished? :P

[MrLemon]

Even in terms of things not happening when you're nearby, I've always thought of that as Steve generating his own reality around him by his very presence (kinda like a dream), which even fits in somewhat with the dreamy nature of the end text (which I of course loathe).

That is also sort of supported by the fact that attempting to sleep in the nether causes an explosion, sort of seems like the 'fabric of reality' it in the nether is sort of weak or something, and without Steve's presence sort of causes the nether to start to violently break down around him.

[Ph1il93]

The changes to the Texture sheet seem to be reasonable, now i cross my fingers for the mod textures to convert automatically.

Edit: yes, reading might be good before posting -.-

[FlowerChild]

New Snapshot 13w02a:

Perhaps actually reading a bit of a thread before posting is a wise policy?

[FlowerChild]

Ok I buy that explanation. I'm really curious now though. You say things only happening around Steve is consistent with Steve generating his own reality around him as in a dream. Does that imply that you plan to have things happen when you're not there in return to home that is supposed to be the 'real' world and not a dream? And if so how could this technical miracle be accomplished? :P

Who says RTH is "reality"? :)

It's one of the reasons that chunk-loaders have always bothered me in other mods, as they violate what I consider to be one of the few in-game explanations for that behavior, thus introducing an additional metagame element. Granted, I have considered and designed internally consistent chunk-loaders using the above rationale, but that's another matter entirely ;)

As for the rest, it's been awhile and I could use some levity, so:

Spoiler

Show

[Sarudak]

Hum. I think the 'reality' bit was conjecture based on a comment about how reality in the current minecraft world was so messed up and steve wanted to escape it. Thus implying that home would be far more 'real'. As to the last bit I can't seem to figure out why you like that song so much... ;)

[FlowerChild]

Hum. I think the 'reality' bit was conjecture based on a comment about how reality in the current minecraft world was so messed up and steve wanted to escape it. Thus implying that home would be far more 'real'. As to the last bit I can't seem to figure out why you like that song so much... ;)

More real does not necessarily mean "reality" man.

Anyways...this is all off topic for this thread. Stop poking me for info :)

[Kazuya Mishima]

I've always thought of that as Steve generating his own reality around him by his very presence (kinda like a dream), which even fits in somewhat with the dreamy nature of the end text (which I of course loathe).

I had been working that element into the backstory of the mod actually.

Ahh is that the explanation for the phrase "Solipsism FTW" in the splash text?

[Gilberreke]

Ahh is that the explanation for the phrase "Solipsism FTW" in the splash text?

Nope (kinda?): viewtopic.php?p=27731#p27731

[ion]

correct me if i'm wrong (i know nothing about chest behavior or coding) but maybe the chest should have been coded like this. make a single block chest and when you want a double chest craft it in the table using two of them. when you destroy a double one you get a double chest. this way you don't need code for merging them

[warmist]

correct me if i'm wrong (i know nothing about chest behavior or coding) but maybe the chest should have been coded like this. make a single block chest and when you want a double chest craft it in the table using two of them. when you destroy a double one you get a double chest. this way you don't need code for merging them

Then getting the orientation gets tricky (both the direction and which tile of those two to place at pointer)

[ion]

correct me if i'm wrong (i know nothing about chest behavior or coding) but maybe the chest should have been coded like this. make a single block chest and when you want a double chest craft it in the table using two of them. when you destroy a double one you get a double chest. this way you don't need code for merging them

Then getting the orientation gets tricky (both the direction and which tile of those two to place at pointer)

true that. for orientation i guess it's easy. they should behave like normal chest. for the double one, let's say you need 2 blocks of air starting from the left. if FC was able to implement windmills that are more that one block wide, why mojang wasn't able from the start.

[Uristqwerty]

The width of a windmill is an odd number of blocks, so you are clearly placing it at the center. However, a double chest is an even width, so that doesn't quite work the same way from a user interface perspective (even if the code for it would be fairly simple). A closer comparison would be beds, but those are still one block wide from the orientation you are facing when you place them.

For a version that more people will naturally understand, check whether the player is looking more at the left half or the right half of the surface they clicked.

I think the main reason chests are the way they are probably was so that the renderer didn't need to check the tile entity back when chests occupied the full block, and nobody thought to fix that limitation once chests, now being animated, must. (4 directions + 3 states (single, left half, right half) fits into 4 bits of data)

[ExpHP]

Nobody has brought up yet one of the few features I'm actually glad to see: The activator rails and TNT Minecart. They're among the simplest and most vanilla-feeling features to be added in the snapshot, in contrast to the "make everything interface with everything whether it makes sense or not" approach they took with the Hopper and Comparator.

To be quite frank, when I saw Dinnerbone post this image, I feared he implemented a system to add arbitrary blocks to Minecarts. Luckily, it seems that Mojang is willing to practice at least a little discretion...