Picked up playing again for the first time in years right around when 1.21 released. Going to do an update sometime in the near future - if anyone who cares about this pack still exists, let me know if you have any requests or ideas. Otherwise, I'll just do what I do.
I removed the changes to wheat and leaves, buttons now have bark sides, birch fences have a shifted texture to minimize black spots, petrified slabs are fixed, pressure plates are log slices, and saplings are normal sized by default, getting slightly larger when they try to grow.
Wheat changes are still there - asked a friend to get another opinion and they did not like either as I was kinda uncertain which way to go at this point, so yeah not gonna integrate that one.
Buttons look nicer that way. Birch fence is much better. The saplings are better and it makes more sense now - when I placed them before and saw them small I hadn't realized it was state-based at all, that's kinda useful if you're trying to figure out if something can//can't grow where you've put it.
Log pressure plates are a little more by-taste than buttons (which objectively are a bit silly in vanilla, one would never use multiple tiny bits of plank, lol). I do like them, but I wonder if people would be annoyed that they no longer blend in with planks or not. Torn whether bark edges are a good idea for the pressure plates, as it would look better that way in some cases but when placed directly on a log it probably would look nicer and more correct as-is.
The one thing that irks me about tweaking these things (button, now pressure plate) are that logs aren't in the recipes, but I don't think it's worth letting that kind of logic get in the way of nice aesthetics when it's that minor. If I were in control of the recipes I'd just make log buttons and log pressure plates be variants with their own recipes that make more at once but end up costing more since it's logs. Anyway I'm getting off on a tangent.
You could probably have a market of users for these tweaks if you package them individually so people can apply them one at a time to whatever pack.
Edit: Integrated the discussed changes into a 5.1 release, was easy enough to not include the wheat file.
Most of my pack was designed before they updated the textures and split the default into two packs, so the programmer art is the setting in which it was designed (and I use it).
Not a big fan of the leaves being not-square - while it may look cool from some angles, from others it looks weird as you can see straight through them too easily, and generally circles in Minecraft are kinda blasphemy (people rioted back in the day when Notch made the moon round once). Trying for realism has it's limits before it clashes with the aesthetic IMO (this is also why I don't like larger textures in general).
The fences are gorgeous (except birch, birch log texture maps one black spot onto each stick which is awkward), but I question whether it would mess with the way people use fences as wooden gates/windows when building in a negative way. It's too bad we can't let people build with both.
Buttons are a decided improvement, though anything that small with a larger texture mapped to it will always be awkward-looking no matter what we do. If we could make the sides of the button look like bark, so that it was like a slice of a branch or stick that would be cool, but with 2px visible on the sides of the buttons I'm not sure how doable that is.
The slab thing is very cool, since normal slabs would just look like a block and thus serve no purpose at present aesthetically. Did notice you missed the petrified oak, though that's not available in survival (yet?).
The wheat is cool though low-impact.. Since the block is still 1-high it'd be weird if someone had a wheat farm in a wall, the wheat would clip through the block above and appear to have no top. A quick google images search shows wheat often comes up halfway on a person so 1-high seems OK from a realism standpoint. This one I could go either way on, really.
I don't know why you made the saplings smaller, but I don't like it. xD
I'd lean toward including the fences, slabs, and buttons in the actual pack - with credit to you.
Dark oak and acacia aren't included as I didn't touch them, so it uses whatever pack is below mine in the list for that. If you remember the textures being different for those, then it's likely because the vanilla textures changed for them. For now the vanilla ones seem OK.
Version 5.0b Changes:
- Fixed stonecutter render bug.
- Iron door icon.
- Log tweaks.
- Stripped log variants match texture pack now.
- Fixed wet sponge appearance to match the old sponge texture that my pack uses.
- Unpowered repeater texture name fixed.
- Observer reskinned to match stone color of pack.
I know all the textures haven't changed, so I'll not point them all out (fish buckets contain silver buckets, etc) but something has broken the new lantern model.
Was playing 1.12.2 with mods, so I hadn't noticed. Thanks for pointing it out, all fixed in 5.0a.
It's been a while, took a long break from Minecraft and the resource pack format changed quite a bit. Had to convert it, then fix a billion filenames that were changed arbitrarily (nightmare!), then get to work on all the new stuff that had to be made to match. It's all good, though, and here's 5.0.
The changelog is too extensive to list, but it updates the pack from 13w03a in 2013 as the last tested version to 1.14.4 here in 2019.
I'd use this if it weren't for the shoehorned-in Dock mobs. I really like restoring old dropped/incomplete functionality and concepts, but personally I feel that those were never intended to stay in the game as more than a simple test - Beast Boy, really? The Steves could be said to fit, but the art style has changed since then and so I don't feel the models fit, either.
Could there be a configuration option to remove these mobs?
Could you provide an option to disable the recipe for "Weighted Pressure Plate (Light)" from aluminum brass? This can be exploited if Mariculture is installed to convert aluminum brass into gold..
Clay buckets turn into iron buckets when you pick up liquids that they don't support (BC oil is what we found it with). If this isn't easy to fix, please add a liquid ID blacklist so I can blacklist liquids that it doesn't support.
You basically need to mine copper, make a smeltry, and get lucky with chests to be able to make a pickaxe head mold (for gold or aluminium).You then make a copper pickaxe head, switch your old pickaxe head with the copper one, and you should be able to mine iron from there (and continue somewhat normally from there).
You make stone tool parts and use those to cast the molds. You should be able to mine iron with copper in the default settings, though. I've customized mine to be flint->copper->bronze->iron myself, though.
Read this thread, looked at the screenshots, went "THIS! This is appropriate for my mod pack - my personal pack (for my private server) that I put hours and hours of love and care into crafting and balancing... Oh... It's.. pulled... *depressed*"
What I'm saying is this looks damned good, tying more mods together that were very separate. I approve, and it hurts to know I can't have it. Can I just have the broken version for now? Plx? >_>
We could at least set up a storage system, and/or browse the recipes and get mats together..
Battle utilities = enchantments, potions, ender pearls, golden apples
If you have those and know how to use them, it shouldn't be a problem, let alone if you have other mods which add things like jetpacks and better equipment. Sorry but I struggle to figure out how it is a problem to kill the dragon if you have all those things xD
(there's one difficulty setting, but that one can only make the mod even harder)
We run Hunger Overhaul, which makes you incredibly weak and slow as you lose health or hunger, and you hardly regen health (slower and slower as you are lower on health). Dragon hits you one or two times and you're SOL. I'm thinking that maybe with regen potions and a jetpack it might be possible with a few people, but I can't even conceive of how you could do it without a jetpack - I guess you'd just have to be really damn good with ender pearls to not end up in the void.
I'll give it another try when I can round up some of the people who play on my server who want to do it..
Umm, learn the game I guess? Last time I played it with 2 friends, we did it with only Forge and HEE installed, using only vanilla equipment and battle utilities.
Oy, everything else in the modpack (my modpack) is finely tuned to the difficulty and we always play on hard. Vanilla ender dragon is a piece of cake that any of us can solo.
Changing the difficulty setting of the entire server for one mob would totally screw the balance of the pack, affecting the hunger system and such.. Obviously I considered this, I'm not a moron..
What is "Battle Utilities"? I was unable to find this anywhere.
Anyway there's no need to be mean about it, dunno who crapped in your coffee. Perhaps it's a combination of the hunger overhaul at its current settings and the difficulty of the dragon being geared toward vanilla Minecraft..? Don't wanna change that, though - if you don't intend to ever add configuration options to tweak the difficulty, I guess I'll have to try to find another end overhauling mod. :/
What in the .. the dragon is so damn hard that two people with mod gear (jetpack, swords that did +14, armor, etc.) got absolutely raped by him poking at us before we could even hit him. Lovely, but there's no difficulty settings.. I dunno if its mod interaction, but it's literally impossible at the moment and I like the rest of the mod quite a bit.. :/
I don't entirely blame you for this, as I'm a developer and I understand the possible interactions/etc., but could you add some difficulty options? If it's supposed to be this hard (we do play on hard), what are you supposed to do to beat him? He just shoves you off the map or pokes you to death incessantly..
Being a coder with asperger's who thinks very abstractly, I had an idea that maybe you haven't had..
To fix the ore color clashing horribly (which is the reason I don't use this mod - I do love everything about it that I've seen/read..), you can dynamically generate textures for everything in OreDictionary that has "Ore" in it by mapping the colors in the grayscale range used by clean stone to colors of each type of stone in the mod. This would exclude the upper and lower range to avoid messing with the "ore" parts of the texture, which may contain black or (more likely) white.
Edit: Also, you could make the assumption that all ores will base themselves on the vanilla stone texture, then check every pixel of the texture against the vanilla one and replace only the vanilla ones with those that match the stone of the area.
I could code a program that would do this, but I don't know Java so it'd have to be external or translated over or something.. (I mostly do C#)
Anyway, that solves the first problem - making textures for an infinite number of ores that may or may not be present now or in the future.
The second problem is getting those textures in the game without overtaxing the system. I can think of several approaches, but without in-depth knowledge of the Minecraft generator and renderer I can't tell you what'd be the performance hogs/etc.. Here are my ideas (no particular order):
- Create a generic "Ore" block whose name and appearance and function mimic those from a given mod, but your mod swaps these in for ores that it finds on one of its generation passes (or a better place to intercept, I dunno how this works remember) and reassigns the texture via metadata choice (different metadata value = different texture) to match the relevant type of stone. When mined, this would drop the regular form of the ore rather than itself (could provide a mechanism to convert back for anybody who'd care about it for decoration or something, maybe ore + stone type).
- Add some code to the rendering system (probably a bad idea?) that intercepts calls to draw OreDictionary "Ore" blocks, and draws the different texture depending on whatever conditions would be least intrusive. Depending on how MC implements its shader layer, you might be able to make this a shader pass which would be a lot less bad of an idea.
- Disable all ore generation and do your own, inserting blocks that already have the right variant.
Might be more options, or problems with these, but that's my two cents.
0
Picked up playing again for the first time in years right around when 1.21 released. Going to do an update sometime in the near future - if anyone who cares about this pack still exists, let me know if you have any requests or ideas. Otherwise, I'll just do what I do.
0
Wheat changes are still there - asked a friend to get another opinion and they did not like either as I was kinda uncertain which way to go at this point, so yeah not gonna integrate that one.
Buttons look nicer that way. Birch fence is much better. The saplings are better and it makes more sense now - when I placed them before and saw them small I hadn't realized it was state-based at all, that's kinda useful if you're trying to figure out if something can//can't grow where you've put it.
Log pressure plates are a little more by-taste than buttons (which objectively are a bit silly in vanilla, one would never use multiple tiny bits of plank, lol). I do like them, but I wonder if people would be annoyed that they no longer blend in with planks or not. Torn whether bark edges are a good idea for the pressure plates, as it would look better that way in some cases but when placed directly on a log it probably would look nicer and more correct as-is.
The one thing that irks me about tweaking these things (button, now pressure plate) are that logs aren't in the recipes, but I don't think it's worth letting that kind of logic get in the way of nice aesthetics when it's that minor. If I were in control of the recipes I'd just make log buttons and log pressure plates be variants with their own recipes that make more at once but end up costing more since it's logs. Anyway I'm getting off on a tangent.
You could probably have a market of users for these tweaks if you package them individually so people can apply them one at a time to whatever pack.
Edit: Integrated the discussed changes into a 5.1 release, was easy enough to not include the wheat file.
0
Most of my pack was designed before they updated the textures and split the default into two packs, so the programmer art is the setting in which it was designed (and I use it).
Not a big fan of the leaves being not-square - while it may look cool from some angles, from others it looks weird as you can see straight through them too easily, and generally circles in Minecraft are kinda blasphemy (people rioted back in the day when Notch made the moon round once). Trying for realism has it's limits before it clashes with the aesthetic IMO (this is also why I don't like larger textures in general).
The fences are gorgeous (except birch, birch log texture maps one black spot onto each stick which is awkward), but I question whether it would mess with the way people use fences as wooden gates/windows when building in a negative way. It's too bad we can't let people build with both.
Buttons are a decided improvement, though anything that small with a larger texture mapped to it will always be awkward-looking no matter what we do. If we could make the sides of the button look like bark, so that it was like a slice of a branch or stick that would be cool, but with 2px visible on the sides of the buttons I'm not sure how doable that is.
The slab thing is very cool, since normal slabs would just look like a block and thus serve no purpose at present aesthetically. Did notice you missed the petrified oak, though that's not available in survival (yet?).
The wheat is cool though low-impact.. Since the block is still 1-high it'd be weird if someone had a wheat farm in a wall, the wheat would clip through the block above and appear to have no top. A quick google images search shows wheat often comes up halfway on a person so 1-high seems OK from a realism standpoint. This one I could go either way on, really.
I don't know why you made the saplings smaller, but I don't like it. xD
I'd lean toward including the fences, slabs, and buttons in the actual pack - with credit to you.
0
Dark oak and acacia aren't included as I didn't touch them, so it uses whatever pack is below mine in the list for that. If you remember the textures being different for those, then it's likely because the vanilla textures changed for them. For now the vanilla ones seem OK.
Version 5.0b Changes:
- Fixed stonecutter render bug.
- Iron door icon.
- Log tweaks.
- Stripped log variants match texture pack now.
- Fixed wet sponge appearance to match the old sponge texture that my pack uses.
- Unpowered repeater texture name fixed.
- Observer reskinned to match stone color of pack.
0
Was playing 1.12.2 with mods, so I hadn't noticed. Thanks for pointing it out, all fixed in 5.0a.
0
It's been a while, took a long break from Minecraft and the resource pack format changed quite a bit. Had to convert it, then fix a billion filenames that were changed arbitrarily (nightmare!), then get to work on all the new stuff that had to be made to match. It's all good, though, and here's 5.0.
The changelog is too extensive to list, but it updates the pack from 13w03a in 2013 as the last tested version to 1.14.4 here in 2019.
0
I'd use this if it weren't for the shoehorned-in Dock mobs. I really like restoring old dropped/incomplete functionality and concepts, but personally I feel that those were never intended to stay in the game as more than a simple test - Beast Boy, really? The Steves could be said to fit, but the art style has changed since then and so I don't feel the models fit, either.
Could there be a configuration option to remove these mobs?
0
0
1
What I'm saying is this looks damned good, tying more mods together that were very separate. I approve, and it hurts to know I can't have it. Can I just have the broken version for now? Plx? >_>
We could at least set up a storage system, and/or browse the recipes and get mats together..
0
0
We run Hunger Overhaul, which makes you incredibly weak and slow as you lose health or hunger, and you hardly regen health (slower and slower as you are lower on health). Dragon hits you one or two times and you're SOL. I'm thinking that maybe with regen potions and a jetpack it might be possible with a few people, but I can't even conceive of how you could do it without a jetpack - I guess you'd just have to be really damn good with ender pearls to not end up in the void.
I'll give it another try when I can round up some of the people who play on my server who want to do it..
0
Oy, everything else in the modpack (my modpack) is finely tuned to the difficulty and we always play on hard. Vanilla ender dragon is a piece of cake that any of us can solo.
Changing the difficulty setting of the entire server for one mob would totally screw the balance of the pack, affecting the hunger system and such.. Obviously I considered this, I'm not a moron..
What is "Battle Utilities"? I was unable to find this anywhere.
Anyway there's no need to be mean about it, dunno who crapped in your coffee. Perhaps it's a combination of the hunger overhaul at its current settings and the difficulty of the dragon being geared toward vanilla Minecraft..? Don't wanna change that, though - if you don't intend to ever add configuration options to tweak the difficulty, I guess I'll have to try to find another end overhauling mod. :/
0
I don't entirely blame you for this, as I'm a developer and I understand the possible interactions/etc., but could you add some difficulty options? If it's supposed to be this hard (we do play on hard), what are you supposed to do to beat him? He just shoves you off the map or pokes you to death incessantly..
0
To fix the ore color clashing horribly (which is the reason I don't use this mod - I do love everything about it that I've seen/read..), you can dynamically generate textures for everything in OreDictionary that has "Ore" in it by mapping the colors in the grayscale range used by clean stone to colors of each type of stone in the mod. This would exclude the upper and lower range to avoid messing with the "ore" parts of the texture, which may contain black or (more likely) white.
Edit: Also, you could make the assumption that all ores will base themselves on the vanilla stone texture, then check every pixel of the texture against the vanilla one and replace only the vanilla ones with those that match the stone of the area.
I could code a program that would do this, but I don't know Java so it'd have to be external or translated over or something.. (I mostly do C#)
Anyway, that solves the first problem - making textures for an infinite number of ores that may or may not be present now or in the future.
The second problem is getting those textures in the game without overtaxing the system. I can think of several approaches, but without in-depth knowledge of the Minecraft generator and renderer I can't tell you what'd be the performance hogs/etc.. Here are my ideas (no particular order):
- Create a generic "Ore" block whose name and appearance and function mimic those from a given mod, but your mod swaps these in for ores that it finds on one of its generation passes (or a better place to intercept, I dunno how this works remember) and reassigns the texture via metadata choice (different metadata value = different texture) to match the relevant type of stone. When mined, this would drop the regular form of the ore rather than itself (could provide a mechanism to convert back for anybody who'd care about it for decoration or something, maybe ore + stone type).
- Add some code to the rendering system (probably a bad idea?) that intercepts calls to draw OreDictionary "Ore" blocks, and draws the different texture depending on whatever conditions would be least intrusive. Depending on how MC implements its shader layer, you might be able to make this a shader pass which would be a lot less bad of an idea.
- Disable all ore generation and do your own, inserting blocks that already have the right variant.
Might be more options, or problems with these, but that's my two cents.