Ask a simple question, get a simple answer

[Drbretto]

I get what you're saying, but I hope you understand if the dev is more interested in making a product that *he* finds fun over a product that *you* find fun.
"There's no upside to that for anyone." --> I disagree with this. There's an upside for people like me who are interested in overcoming annoying logistical problems.

"If it remained tiered, you'd have all the reason in the world to make the other spikes leading eventually up to the full final product you're working for. " --> You'd have one reason: to use in a recipe, but rarely as a block. And those kinds of iterative recipes are kind of annoying to a lot of players

Just one quibble here, I am not speaking from a selfish position here. I am saying that the design choices for this mod are bad, not that I personally dislike them. There's a major difference here. I believe it is the wrong direction for the players, not for myself or any individual person. (I, personally, was always intending to use the mob grinding utils, I only made the spikes in the interim, so it hardly affects me at all. I simply am in strong disagreement of the general direction the mod has gone. I feel the developer has lost his way)

You'd have more than one reason. They do still do different things. All it means is that as you upgrade, you get to keep the functionality of the previous tiers where applicable. In the original, not only were they tiered like this, it was actually a bit of a hassle to overcome because they required a much harder to make magical wood for everything gold and up. You could conceivably use the gold while waiting to be able to handle the upgrade, or, if your main goal was just the xp and you're not worried about the player loot, you could choose to stick with the gold. The cost to upgrade was prohibitive enough.

I made use of all of the spikes except for wood. AND eventually worked my way up to the top tier that had everything I was looking for. It was already pretty much perfect as it was.

I will forever maintain this is the sophomore curse. The mere fact that he called is ExU2 instead of keeping the same name just sets it in further. I understand the effect only because I've lived it.

 

[Pyure]

Just one quibble here, I am not speaking from a selfish position here. I am saying that the design choices for this mod are bad, not that I personally dislike them. There's a major difference here. I believe it is the wrong direction for the players, not for myself or any individual person.

No worries. But I think you missed my point. I suspect the dev wanted a specific design where you couldn't have a single spike do everything, and possibly a design where players were encouraged to use spikes other than the top-tier. That's not a "bad" design choice in this case, its just a different one (and maybe an unpopular one).

His original implementation appears to be exactly as you described in your hypothetical: you'd use Gold until you could use Diamond. But I suspect that actual play-time evidence made it clear that the majority of players weren't doing that. They were just straight-up doing diamond, because everyone has all the diamonds.

This is all just speculation by the way. I'd prefer to know what the dev was up to. But for me personally, spikes as a game mechanic seem somewhat more interesting now that I have to make layout decisions.

 

[Drbretto]

I did not miss your point, I promise

I agree that he did exactly what you said. What I'm arguing is that it was the wrong choice. Right down to knowing exactly why he decided to redesign it in the first place, and it wasn't because it wasn't working.

 

[Pyure]

What I'm arguing is that it was the wrong choice.

Your reasoning for this has been primarily subjective however. For what its worth, I say "subjective" because it didn't apply to me and my preferences. Otherwise it would have been an objective statement.

Attacked from a different angle, I've been trying to think of a scenario where you could have a single spike that did both XP and Loot but still accomplished what the speculative design was supposed to accomplish, and I can't really think of one. I keep circling back to "just spend more resources to have a better spike", which after a few years of modded minecraft comes off a bit weak.

One solutuion which mathematically doesn't really do what you want: Make the spikes multiparts of sorts, so that you can put multiple spikes on a single block face. Say you can have 4 maximum. Then you can choose to do 2 diamond and 2 gold. Upon mob-death, you'd earn 50% player-loots, and 50% xp orbs. This isn't fundamentally different to the "multiple spikes" solution described earlier.

Another solution which is weirder but comes closer to what you want, notwithstanding that its a bit weird: Picture a mob grinding room. You put a gold spike in one spot, a diamond spike in another spot, and a third (Emerald?) spike in between those two. That spike has the property of magically taking on the properties of all adjacent spikes. And you route all mobs into the emerald one, which now functions as a Gold + Diamond. Now you have a single spike killing all mobs, with room-design implications and balanced use of the spike blocks.

 

[Drbretto]

Everything is subjective. I'm speaking of perspective. My perspective is not myopic, was my point. It's still opinion. My opinion is that it's a bad choice, and that's very different from saying that I don't like the choice, or that the choice doesn't fit my needs. It seems like a minor thing, but it's an important distinction. Both of our positions are opinions. There is nothing objective to any of this. I make this distinction because it's important to separate what I'm trying to say from some random whining.

I do like your idea of placing multiple spikes in the same block, though. That would be a great solution to all this. And it would be a bit more interesting that just building the next tier because you could very well split up all of the things so you can essentially build your own spike. Maybe make iron required for the kill, gold required for the xp, diamond for the player loot and hell, throw in emerald for enchantability. That's a great idea. But that's not what they did.

Mod Grinding Utils did, though, only they did it with a neat looking grinder that you can upgrade. That's functionally the same thing and it does exactly what you're talking about. It makes it more interesting. It makes it a progression. And above all, it doesn't prevent any functionality. It's simply a more interesting route to the desired goal, with some added complexity and customization. That's design done right.

The changes for ExU2 don't actually add anything of value here. Not just this one, either. The same can be said about the Angel Blocks and the thickened glass that I've criticized here as well (the "theoretical" quarry is its own special sin that doesn't apply here. That's its own thread). It'd be one thing if the functionality for all of these things was broken with the future versions and these were the best work-arounds he could work with. This is different. This is change just for the sake of it.

It's like, imagine you were a painter, and while you were learning to paint, you made some really nice, beautiful and creative art. But, as you learn more about painting techniques, you look back at your old work and all you see is the amateurity. So, you decide to repaint it, but for some reason, it just never comes out right again. And that's because it's simply not inspired the same way the original was. I very much think that's what's happened here. Intsead of redoing his masterpiece, he should have just painted something new. Leave this one as it was.

Edit: An example my my own personal experience is my mod for Final Fantasy Tactics. I developed most of it while learning how to use the tools, and I made something that I think was pretty special, if not derivative, but complimentary of a different mod. But, after that had some success, I decided I was more mature as a modder and went back in and redesigned things for what I totally thought was this great new vision. Some of it worked, some of it didn't. It wasn't a bad port at all. But, it lost the magic of the original. The balance was too balanced. It ruined some of what was so great about the original by basically trying to coax people into playing the game differently. That seemed like a good idea in my head, but ultimately was bad for the game.

 

[Pyure]

It's like, imagine you were a painter, and while you were learning to paint, you made some really nice, beautiful and creative art. But, as you learn more about painting techniques, you look back at your old work and all you see is the amateurity. So, you decide to repaint it, but for some reason, it just never comes out right again. And that's because it's simply not inspired the same way the original was. I very much think that's what's happened here. Intsead of redoing his masterpiece, he should have just painted something new. Leave this one as it was.

How about this analogy: Imagine you love beautiful pictures. You have a computer and a printer that makes it quick and efficient to print out beautiful pictures. But then I take those away from you and instead give you canvas, paintbrushes and paint.

What you actually want out of the mod determines whether you think the changes were fundamentally good. I'm still giving you the ability to produce a masterpiece, but now you have to paint an original one rather than reproduce the same one everyone else has. Ultimately: Do you love owning the pictures, or do you love making them? How you answer that may determine how you feel about changes above. (And there's no right answer to that: everyone has their own preferences)

Btw, just to be clear: from the few times I've tinkered with ExU2, I'm not a fan of it either. I dislike the power system in particular because I'm tired of seeing new power systems. I assume the lack of angel blocks is because he hasn't gotten around to them yet or some other constraint rather than a preferential design decision.

 

[Drbretto]

I'm not sure I follow your counteranalogy there. But that could well be on my end. I suspect we're talking about slightly different, but parallel things. This isn't just because the guy had to re-write the code (paint the masterpiece). It's because while re-writing the code, he tried to improve it with a different vision that breaks what made the original special, as if he misunderstood what that je ne sais quoi was in the first place.

The Angel Blocks are in the game, but they now require a pickaxe to break and no longer jump directly to your inventory. The latter could well be missing functionality from different minecraft versions making that part impossible, but the former was an intentional design choice. It appears to be a "fix" for the ability to snake angel blocks to get up high. This isn't an issue of him not getting around to it yet, it's a nonsensical design choice that ruins what made that block special.

 

[Pyure]

The Angel Blocks are in the game, but they now require a pickaxe to break and no longer jump directly to your inventory. The latter could well be missing functionality from different minecraft versions making that part impossible, but the former was an intentional design choice. It appears to be a "fix" for the ability to snake angel blocks to get up high. This isn't an issue of him not getting around to it yet, it's a nonsensical design choice that ruins what made that block special.

Can you clarify this? Are you sure it was a deliberate design choice? What do you mean by this "snake angel blocks to get up high" thing?

I ask because I agree that it sounds silly.

 

[Drbretto]

Can you clarify this? Are you sure it was a deliberate design choice? What do you mean by this "snake angel blocks to get up high" thing?

I ask because I agree that it sounds silly.

Sure can.

I absolutely ADORED the angel blocks in 1.7.10. I would celebrate every time I could add a couple more to my arsenal. One of the things I would use them for was to make scaffolding without the scaffolding, and I could snake them efficiently with as few as 4 blocks. Hop-place (there's a term for that already but it's escaping me) to a stack of three, then make one to the side at the same height, then delete the stack of three. hop-place two more to place another stack of three, etc etc. You can snake around to do what you gotta do up high.

In 1.10.2, they no longer automatically end up in your pocket when you break them. That part could possibly be because of the new tech, so I can forgive that. Worst case there, I just need to accept that I need more of them to be as effective and I might lose a few that drop in the wrong place. Sucks, but if it's a limitation, I could live with that.

But I know it's possible to make blocks that you can break by hand still. So now that you have to break the angel blocks with a pickaxe or they will simply be deleted (and it still is a quick break, I might add, so it'll be super easy to accidentally do and lose your stuff), this can't be a limitation. This was intentionally made to not be breakable by hand. The only reason I can imagine that is for is that it goes hand in hand with the previous paraqgraph to prevent players from using the blocks to do a jetpack's job, essentially. Because on top of the blocks falling to the ground, by requiring the pickaxe, you can't use it while holding the block to quickly drop another so you can fall in small increments safely. You could potentially put them in the off-hand slot, but if you're up there building, you might want to have the building block in the off-hand slot, you know?

So, basically that's proof of unnecessary design choices for no reason. Similarly, the reason why I liked the Thickened Glass from previous installments, besides the total transparency, was that you go through this extra effort to thicken them and that made it so they could also be broken by hand. They can no longer be broken by hand. They, too, will simply be deleted if you do so. Now they're just a clear glass. Which isn't a huge deal or anything, but it also is completely unnecessary. There's nothing to be gained from that and it's not like they were a problem before.

 

[Pyure]

Sure can.

I absolutely ADORED the angel blocks in 1.7.10. I would celebrate every time I could add a couple more to my arsenal. One of the things I would use them for was to make scaffolding without the scaffolding, and I could snake them efficiently with as few as 4 blocks. Hop-place (there's a term for that already but it's escaping me) to a stack of three, then make one to the side at the same height, then delete the stack of three. hop-place two more to place another stack of three, etc etc. You can snake around to do what you gotta do up high.

In 1.10.2, they no longer automatically end up in your pocket when you break them. That part could possibly be because of the new tech, so I can forgive that. Worst case there, I just need to accept that I need more of them to be as effective and I might lose a few that drop in the wrong place. Sucks, but if it's a limitation, I could live with that.

But I know it's possible to make blocks that you can break by hand still. So now that you have to break the angel blocks with a pickaxe or they will simply be deleted (and it still is a quick break, I might add, so it'll be super easy to accidentally do and lose your stuff), this can't be a limitation. This was intentionally made to not be breakable by hand. The only reason I can imagine that is for is that it goes hand in hand with the previous paraqgraph to prevent players from using the blocks to do a jetpack's job, essentially. Because on top of the blocks falling to the ground, by requiring the pickaxe, you can't use it while holding the block to quickly drop another so you can fall in small increments safely. You could potentially put them in the off-hand slot, but if you're up there building, you might want to have the building block in the off-hand slot, you know?

So, basically that's proof of unnecessary design choices for no reason. Similarly, the reason why I liked the Thickened Glass from previous installments, besides the total transparency, was that you go through this extra effort to thicken them and that made it so they could also be broken by hand. They can no longer be broken by hand. They, too, will simply be deleted if you do so. Now they're just a clear glass. Which isn't a huge deal or anything, but it also is completely unnecessary. There's nothing to be gained from that and it's not like they were a problem before.

That seems reasonable enough to me. I hadn't considered the possibility that you could tower-up with them. I only used them for weird mining expeditions in the End.

I'm still not super-ready to jump to the conclusion that it was a deliberate choice. I'd be more ready to believe it was, ahem, laziness. Notwithstanding that its improper to place expectations on the dev timewise.

 

[Pyure]

I just wanna add to what I said above: Sometimes as a Dev one comes across something that wouldn't be fun to implement. And instead of saying "I'm too bored or lazy to implement that" one provides a quasi-logical explanation for it being the way it is.

Subtext: Yes, I'm a developer, and yes this can sort of apply to me sometimes, although I like to think I'm usually honest enough to just say I have no interest in putting time into a thing One of my favorite mods (Gregtech) is pretty guilty of this.

 

[Drbretto]

It has to be an intentional choice. I may not know Java, but I have done quite a bit of coding, hacking and modding in my day. I can confidently say that picking between being breakable by hand vs requiring a pickaxe is nothing more than setting the value of a single variable. Maybe 2 if it's a separate value for type of tool followed by level of tool. If it was an accident, chances would be in favor of anything but the pickaxe (just by virtue of the possible options being more than one). I have a hard time believing that wasn't intentional. That could only be deliberate. Your explanation only works for the part where the block ends up in your inventory directly. It doesn't fly for the rest.

I am not placing any expectations on dev timeline. This isn't an issue of these features being unfinished. They have to be intentional changes because it would actually take more effort than just redoing it the same way. Plus the fact that he renamed it ExU2 rather than just porting the same thing.

Really think about it. This has been a really great conversation, BTW, and I appreciate you sifting through my garbled messes to find meaning, lol. But I promise you I'm right here. These are intentional design changes and they are for the worse. It's the only plausible scenario left.

 

[Pyure]

It has to be an intentional choice. I may not know Java, but I have done quite a bit of coding, hacking and modding in my day. I can confidently say that picking between being breakable by hand vs requiring a pickaxe is nothing more than setting the value of a single variable. Maybe 2 if it's a separate value for type of tool followed by level of tool. If it was an accident, chances would be in favor of anything but the pickaxe (just by virtue of the possible options being more than one). I have a hard time believing that wasn't intentional. That could only be deliberate. Your explanation only works for the part where the block ends up in your inventory directly. It doesn't fly for the rest.

This actually isn't valid in modded minecraft development. Or let me be more clear: Its not necessarily valid for every scenario that you figure should be simple. Entire methods that might have been available in 1.7.10 might be deprecated in 1.10.2.

And "hard time believing" doesn't mean "could only be deliberate"

From a developer standpoint, I genuinely think there are multiple extremely logical and plausible explanations here. I'll even give you, say, 85% likelihood on yours, but I don't declare a thing as virtually certain unless its way closer to 99.99%. And I've provided logical alternatives which haven't been (successfully) ruled out yet.

 

[Drbretto]

And I've provided logical alternatives which haven't been (successfully) ruled out yet.

The only thing required is the hand breaking vs pickaxe breaking part. This isn't special functionality. By definition every block in the game will have to have a value that determines how to break a block, and what it produces. Every single block must have this. You can see proof of that with WAILA. Every block you look at lists the tool required to break it. That value is required. There's no chance it's not like this. That this block requires the pickaxe is proof that it was done intentionally. It would not be any harder to make the block breakable without the pickaxe. It should be as simple as the difference between a 0 and, say, a 3.

 

[Pyure]

The only thing required is the hand breaking vs pickaxe breaking part. This isn't special functionality. By definition every block in the game will have to have a value that determines how to break a block, and what it produces. Every single block must have this. You can see proof of that with WAILA. Every block you look at lists the tool required to break it. That value is required. There's no chance it's not like this. That this block requires the pickaxe is proof that it was done intentionally. It would not be any harder to make the block breakable without the pickaxe. It should be as simple as the difference between a 0 and, say, a 3.

I'm going to argue this more for fun than anything, because its not really my main point: I've written applications (including games) where this was not true. Primarily done in C and C++, but C++ is virtually identical to Java so bear with me. In my case, a "slot" would be a pointer to a (possible) piece of equipment. The equipment, in turn, might have methods for things such as attacking or breaking. So just because the "block" (subject) has functionality, doesn't mean the equipment (actor/object) has the functionality, especially when the notion of "empty" is involved.

The "empty" slot might point to a "empty hand" equipment, but it could also just be a null pointer depending on how its implemented. (btw, inheritance *usually* takes care of this)

As a result, there's definitely a "chance" its like this

That said, all it takes is the Dev saying "shit, oversight on my part", and your theory of deliberate-decision is blown.

Once someone shows me a twitter or something of the Dev saying he did it on purpose though, I'm all on board

 

[Drbretto]

I'm going to argue this more for fun than anything, because its not really my main point: I've written applications (including games) where this was not true. Primarily done in C and C++, but C++ is virtually identical to Java so bear with me. In my case, a "slot" would be a pointer to a (possible) piece of equipment. The equipment, in turn, might have methods for things such as attacking or breaking. So just because the "block" (subject) has functionality, doesn't mean the equipment (actor/object) has the functionality, especially when the notion of "empty" is involved.

The "empty" slot might point to a "empty hand" equipment, but it could also just be a null pointer depending on how its implemented. (btw, inheritance *usually* takes care of this)

As a result, there's definitely a "chance" its like this

That said, all it takes is the Dev saying "shit, oversight on my part", and your theory of deliberate-decision is blown.

Once someone shows me a twitter or something of the Dev saying he did it on purpose though, I'm all on board

This is all in fun with me, too! I'm actually really enjoying this conversation so I hope I don't come off as argumentative, too!

I see what you're saying, but it's also kind of the same thing. It's still been placed into the pickaxe category, which would just be the inverse of what I said. Still a simple and deliberate act, especially considering that it's ostensibly made out of a material that should be on the pickaxe scale.

I can buy the idea that there's a small chance it was simply an oversight. However, given the general simplicity of the block itself (it's just a block, essentially, with three main properties and nothing else. Placeable in the air, check. Does drop, maybe a technical issue, can't check this off yet. Breakable by hand/pickaxe/ etc, check), I have a hard time seeing that being an oversight. That'd be pretty egregious and incredibly simple to fix.

So, I'll submit that it could well be *possible* that it's an accident. But given the above, plus the context of other questionable decisions (and I haven't even fully explored this whole thing yet), the author's own words about how he developed the original mod (ie, that he learned as he went along), and reflecting on my own experiences with modding, I'd give it a 98% chance that it was intentional, and I will concede 2% chance of an oops.

 

[Drbretto]

BTW, I absolutely love this place. You guys have conversations, you don't go into crazy argumentative mode when challenged. This is a RARE thing on the internet!

 

[Everlasting2]

Just stand on a 3 block high nerd pole with nothing above you, you can still hit them, they can't teleport to you and by not hiding under anything they won't teleport you to them.

the key part was being knocked back into a position that counted as hiding by the endermen not voluntary hiding

 

[Drbretto]

Couldn't you combine yellow dye with blue dye, or lapis, to make green before? I definitely could in infinity, but I just assumed that was a vanilla thing. It could be hard to find a desert on this map...

Edit: thus is the dumbest thing to fixate on though, lol. I'm just making and ender tank for XP and I wanted to make the color code green. For no actual reason. But I'm still considering dropping everything and finding a desert.

 

[Everlasting2]

Couldn't you combine yellow dye with blue dye, or lapis, to make green before? I definitely could in infinity, but I just assumed that was a vanilla thing. It could be hard to find a desert on this map...

Edit: thus is the dumbest thing to fixate on though, lol. I'm just making and ender tank for XP and I wanted to make the color code green. For no actual reason. But I'm still considering dropping everything and finding a desert.

ender io has a recipe chain for green dye