With the implementation of the upcoming new stone-types I have decided to share this idea I have had for a very long time. It is essentially the idea of un-binding ore to a specific block and instead make ores generate as an "attribute" to pre-existing blocks in the world.
-The idea is to make ores instead of a separate block appear as an additional texture overlapping existing blocks, essentially enabling ores to generate in all the new types of stone without the texture being in the way, since it currently only matches with one of the existing stone-types, namely "stone".
By doing this the new stone-types wouldn't have to be bound to exist in the form of "dirt-type"-pockets due to unmatching textures, and instead maybe be biome-bound, meaning different stone-types for different biomes? This would flesh out the need for exploration a bit, and greatly favor greater mining-expeditions. We could then have full-scale Granite-caverns and the likes, without the ore-generation ruining the appearance.
And one wouldn't have to stop there. This could lead to Ores appearing inside dirt-pockets, gravel-beaches, even in the base of desserts, with proper balancing of course.
This could over time be a very worthwhile implementation if there exists a good way of implementing it. This is why I need feedback and comments, so we can figure out how or whether it is possible.
EDIT: I realize that I forgot to mention this, but a block containing ore could drop both the ore and the block itself, post below what you think?
EDIT2: Maybe we could have gravel get its own texture for when it contains flint? It shouldn't be able to appear in the inventory as it would cause separate stacking, but when you place a block of gravel instead of it having a random chance of dropping Flint instead have it a random chance to be placed with visible traces of Flint and a guaranteed drop if so. Tell me what you think below.
So basically, ores would be bound to specific blocks. It wouldn't really work for some blocks as there isn't enough data, forcing a tile entity to be used. However, it is a nice idea, I guess. Partial support!
This is how I would like it to be done too, and I would also like to see a change to how the new stone generates as well as more new stone types. I'd like to see the underground vary somewhat as opposed to just adding lots of small patches of new stone everywhere, and variation should involve changes in the stone generating there as well as structural changes. Having the ore being able to appear in multiple stone types would much improve the look of this.
Indeed. That would be the other recent source of inspiration to start this topic. If I remember correctly it was you who started the original topic regarding more consistency in how there should be various stone-types to begin with. Can't remember which one of us that came up with the idea of making this stone replace the original stone for specific biomes, but in the end that is what I hope will come of this suggestion. It would be a great and well needed face-lift for all of the underground, with regular shifts in stone-base as you approach new biomes.
But more on topic, another aspect of this worth mentioning is that it will break some of the current "rule-setters", like when you find a dirt-patch and just avoid it since you know that there can be no goodies inside of it. This would dispatch equal amounts of ore and reward all around the underground, as well as being more aesthetic and open-minded.
I guess I understand what this is trying to say? I don't think I'd like it dropping both ores and blocks like one of your edits suggests, and I'm not sure I want gravel in gravel or dirt as that would ruin some of that Minecraft feel. But otherwise it seems a good idea on how to put ores in things other than plain stone.
couldn't hurt. but if this takes away the "ore blocks", how will we get them in creative? ...what I suggest is when in creative, when right clicking any stone with ore, it will turn into that stone with the ore.
Maybe we could have gravel get its own texture for when it contains flint? It shouldn't be able to appear in the inventory as it would cause separate stacking, but when you place a block of gravel instead of it having a random chance of dropping Flint instead have it a random chance to be placed with visible traces of Flint and a guaranteed drop if so. Tell me what you think below.
I would rather have it as a percentage to get flint, because then I could keep placing and mining the gravel over an over again to get my flint. This way makes flint even rarer to get, more noticeable but rarer...
Hate to be devil's advocate here, but suggestions must also be paired with the down-to-earth common sense of hard reality.
And the harsh reality is that Mojand kind of painted itself into a corner with the way it handles the data for blocks at the very deepest level of the core code.
Mainly, MC defines blocks as simply a block ID, in 16x16x16 3D "matrix" arrays called sections, 16 sections high make a chunk and 32x32 chunks makes a region, save in a region file. This "lining up" as data all of the same size allows for some speed and efficiency in the otherwise super slow performing coding language that is Java.
Remember that a player has usually about a few thousand sections loaded in memory at any given time. 8 chunks typically suggested standard radius sight range means about 200 chunks, each each chunk usually loads many of it's sections - remember how you can often seem to "see underground" because a chunk further away loads first? Yeah exactly that - there id much "inefficiency" in loading sections that don't need to be loaded.
The game allows blocks to have extra NBT data, becoming "entities", but this comes at a cost: those blocks are then unmovable by pistons.
Sure, it COULD be fixed. The matrix could be split in two to account for "dense 3D matrix" blocks (everthing that is generated terrain and usually taking up most of the blocks in some volume) and "sparse 3D matrix" blocks (everything else), ideally with the cubic chunks idea for even better data storage and speed (on this forum). But it would require about as much work as, say, the making of the Mod API support which has been going on for years now.
This is not a "50 lines of code fix", but something that goes really deep into LOTS of places into the core code. If Mojang started doing such a major change into those parts of the coee you could expect the initial bugs to flood like stepping on a score of hornet's nests all at once.
Possible? Yes. But at the cost of MAJOR structural changes. Not only a new worldgenerator but a new everything. Not as whoppingly huge as an entire code rewrite, but still huge.
Desirable, Definitely. Minecraft has abysmal performance after all.
Probable? Given Mojangs' track record, I'd have to say "Maybe... But even then be ready to wait half an eternity first".
As many people have said, currently this would only work for certain blocks. But if I am understanding Dinnerbone's recent tweets he is doing away with the archaic metadata system so many ideas get roadblocked by.
Rollback Post to RevisionRollBack
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
As many people have said, currently this would only work for certain blocks. But if I am understanding Dinnerbone's recent tweets he is doing away with the archaic metadata system so many ideas get roadblocked by.
That would be an incredibly great news indeed, opening up so many possibilities. Maybe it is not as hard as I think it is after all.
Glad to see all the positive responses. I will keep the thread updated as we go, eventually I plan on adding pictures.
About the actual implementation though, I couldn't exactly figure out how it could be done either, adding them as you said, Ouatcheur, would make these blocks unmovable by pistons, a great issue indeed. Hopefully we are indeed looking forward towards the implementation of what BadprenupBadprenup was talking about, which in turn would also open the floodgates for a lot of other good suggestions.
Again, glad to see all the positive feedback. Should I add a poll?
The only problem I have with this is that it sounds like it turns Stone into a Tile Entity, and I just had a mod tell me in one of my threads that it would slow down the game if TNT were made into a Tile Entity (and placed in large numbers); I can only imagine what doing that to the game's most prevalent non-air block would do. It's not so much impossible as it is absurdly impractical.
That's a shame, because I really like the idea; it would make custom ores a breeze to add, possibly even through a worldgen menu like Superflat's customization menu. Hell, it could eliminate Monster Eggs by turning Silverfish into an "ore". While you're at it, if you want a to add a nasty/hilarious surprise, why not put in "Primed TNT Ore"?
No support until a way to actually implement it comes forward.
The only problem I have with this is that it sounds like it turns Stone into a Tile Entity, and I just had a mod tell me in one of my threads that it would slow down the game if TNT were made into a Tile Entity (and placed in large numbers); I can only imagine what doing that to the game's most prevalent non-air block would do. It's not so much impossible as it is absurdly impractical.
That's a shame, because I really like the idea; it would make custom ores a breeze to add, possibly even through a worldgen menu like Superflat's customization menu. Hell, it could eliminate Monster Eggs by turning Silverfish into an "ore". While you're at it, if you want a to add a nasty/hilarious surprise, why not put in "Primed TNT Ore"?
No support until a way to actually implement it comes forward.
Well, according to some of Dinnerbone's tweets (or at least what I gathered from it), the entire differentiation between Tile Entities and regular blocks would cease to exist. Each block would only have as many IDs and/or Data as is needed, and if I am reading it right it would remove the concept of metadata entirely.
Rollback Post to RevisionRollBack
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
Well, according to some of Dinnerbone's tweets (or at least what I gathered from it), the entire differentiation between Tile Entities and regular blocks would cease to exist. Each block would only have as many IDs and/or Data as is needed, and if I am reading it right it would remove the concept of metadata entirely.
...Wow. If that's really the case, it's kind of hard to not support this - it would free up a bunch of block IDs, which could be used for other things.
Rollback Post to RevisionRollBack
GENERATION 24: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
...Wow. If that's really the case, it's kind of hard to not support this - it would free up a bunch of block IDs, which could be used for other things.
Not exactly. There is a difference between the internal states a block can have and block IDs. What Dinnerbone is currently referring to is just the internal data, which is used to determine wool colors or bed directions. Block IDs would still exist, although he has converted them from a numeric system to a more logical naming system to avoid conflicts with mods. But other users have informed me that there is still a maximum number of fully unique Block IDs chained to the old numbering system. But odds are Dinnerbone wants to get rid of that too, as both systems are archaic in design and have long been replaced by more efficient methods in most games.
On a technically related note, the tiles and Pokemon used in older Pokemon games use a similar system tied to specific values. It allows for some really cool glitches that involve replacing or modifying these values.
Rollback Post to RevisionRollBack
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
On a technically related note, the tiles and Pokemon used in older Pokemon games use a similar system tied to specific values. It allows for some really cool glitches that involve replacing or modifying these values.
Oh, I'm more than familiar with Pokemon's Gen I glitch hilarities.
As to the rest of your message, I just hope the naming system allows things like CanDestroy to specify things like Blue Wool, Birch Wood, Red Stained Clay and Green Glass. As-is, it's a little too broad.
Also, I think I will support this suggestion now, since it does indeed appear to be possible.
Rollback Post to RevisionRollBack
GENERATION 24: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
-The idea is to make ores instead of a separate block appear as an additional texture overlapping existing blocks, essentially enabling ores to generate in all the new types of stone without the texture being in the way, since it currently only matches with one of the existing stone-types, namely "stone".
By doing this the new stone-types wouldn't have to be bound to exist in the form of "dirt-type"-pockets due to unmatching textures, and instead maybe be biome-bound, meaning different stone-types for different biomes? This would flesh out the need for exploration a bit, and greatly favor greater mining-expeditions. We could then have full-scale Granite-caverns and the likes, without the ore-generation ruining the appearance.
And one wouldn't have to stop there. This could lead to Ores appearing inside dirt-pockets, gravel-beaches, even in the base of desserts, with proper balancing of course.
This could over time be a very worthwhile implementation if there exists a good way of implementing it. This is why I need feedback and comments, so we can figure out how or whether it is possible.
EDIT: I realize that I forgot to mention this, but a block containing ore could drop both the ore and the block itself, post below what you think?
EDIT2: Maybe we could have gravel get its own texture for when it contains flint? It shouldn't be able to appear in the inventory as it would cause separate stacking, but when you place a block of gravel instead of it having a random chance of dropping Flint instead have it a random chance to be placed with visible traces of Flint and a guaranteed drop if so. Tell me what you think below.
Indeed. That would be the other recent source of inspiration to start this topic. If I remember correctly it was you who started the original topic regarding more consistency in how there should be various stone-types to begin with. Can't remember which one of us that came up with the idea of making this stone replace the original stone for specific biomes, but in the end that is what I hope will come of this suggestion. It would be a great and well needed face-lift for all of the underground, with regular shifts in stone-base as you approach new biomes.
But more on topic, another aspect of this worth mentioning is that it will break some of the current "rule-setters", like when you find a dirt-patch and just avoid it since you know that there can be no goodies inside of it. This would dispatch equal amounts of ore and reward all around the underground, as well as being more aesthetic and open-minded.
If you are planning to make a suggestion, please read this.
If you want to know more, you can read this.
For those who complain about post-Beta generation, you might want to see this.
Support!
I would rather have it as a percentage to get flint, because then I could keep placing and mining the gravel over an over again to get my flint. This way makes flint even rarer to get, more noticeable but rarer...
But I like the overlay idea, so support.
BA
**BUT**
Hate to be devil's advocate here, but suggestions must also be paired with the down-to-earth common sense of hard reality.
And the harsh reality is that Mojand kind of painted itself into a corner with the way it handles the data for blocks at the very deepest level of the core code.
Mainly, MC defines blocks as simply a block ID, in 16x16x16 3D "matrix" arrays called sections, 16 sections high make a chunk and 32x32 chunks makes a region, save in a region file. This "lining up" as data all of the same size allows for some speed and efficiency in the otherwise super slow performing coding language that is Java.
Remember that a player has usually about a few thousand sections loaded in memory at any given time. 8 chunks typically suggested standard radius sight range means about 200 chunks, each each chunk usually loads many of it's sections - remember how you can often seem to "see underground" because a chunk further away loads first? Yeah exactly that - there id much "inefficiency" in loading sections that don't need to be loaded.
The game allows blocks to have extra NBT data, becoming "entities", but this comes at a cost: those blocks are then unmovable by pistons.
Sure, it COULD be fixed. The matrix could be split in two to account for "dense 3D matrix" blocks (everthing that is generated terrain and usually taking up most of the blocks in some volume) and "sparse 3D matrix" blocks (everything else), ideally with the cubic chunks idea for even better data storage and speed (on this forum). But it would require about as much work as, say, the making of the Mod API support which has been going on for years now.
This is not a "50 lines of code fix", but something that goes really deep into LOTS of places into the core code. If Mojang started doing such a major change into those parts of the coee you could expect the initial bugs to flood like stepping on a score of hornet's nests all at once.
Possible? Yes. But at the cost of MAJOR structural changes. Not only a new worldgenerator but a new everything. Not as whoppingly huge as an entire code rewrite, but still huge.
Desirable, Definitely. Minecraft has abysmal performance after all.
Probable? Given Mojangs' track record, I'd have to say "Maybe... But even then be ready to wait half an eternity first".
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2775557-guidelines-for-the-suggestions-forum
That would be an incredibly great news indeed, opening up so many possibilities. Maybe it is not as hard as I think it is after all.
And yes, I am still the Master of Disaster.
About the actual implementation though, I couldn't exactly figure out how it could be done either, adding them as you said, Ouatcheur, would make these blocks unmovable by pistons, a great issue indeed. Hopefully we are indeed looking forward towards the implementation of what BadprenupBadprenup was talking about, which in turn would also open the floodgates for a lot of other good suggestions.
Again, glad to see all the positive feedback. Should I add a poll?
That's a shame, because I really like the idea; it would make custom ores a breeze to add, possibly even through a worldgen menu like Superflat's customization menu. Hell, it could eliminate Monster Eggs by turning Silverfish into an "ore". While you're at it, if you want a to add a nasty/hilarious surprise, why not put in "Primed TNT Ore"?
No support until a way to actually implement it comes forward.
GENERATION 24: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
Check out my Metroid Door and Custom Potions!
Well, according to some of Dinnerbone's tweets (or at least what I gathered from it), the entire differentiation between Tile Entities and regular blocks would cease to exist. Each block would only have as many IDs and/or Data as is needed, and if I am reading it right it would remove the concept of metadata entirely.
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2775557-guidelines-for-the-suggestions-forum
...Wow. If that's really the case, it's kind of hard to not support this - it would free up a bunch of block IDs, which could be used for other things.
GENERATION 24: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
Check out my Metroid Door and Custom Potions!
Not exactly. There is a difference between the internal states a block can have and block IDs. What Dinnerbone is currently referring to is just the internal data, which is used to determine wool colors or bed directions. Block IDs would still exist, although he has converted them from a numeric system to a more logical naming system to avoid conflicts with mods. But other users have informed me that there is still a maximum number of fully unique Block IDs chained to the old numbering system. But odds are Dinnerbone wants to get rid of that too, as both systems are archaic in design and have long been replaced by more efficient methods in most games.
On a technically related note, the tiles and Pokemon used in older Pokemon games use a similar system tied to specific values. It allows for some really cool glitches that involve replacing or modifying these values.
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2775557-guidelines-for-the-suggestions-forum
Oh, I'm more than familiar with Pokemon's Gen I glitch hilarities.
As to the rest of your message, I just hope the naming system allows things like CanDestroy to specify things like Blue Wool, Birch Wood, Red Stained Clay and Green Glass. As-is, it's a little too broad.
Also, I think I will support this suggestion now, since it does indeed appear to be possible.
GENERATION 24: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
Check out my Metroid Door and Custom Potions!
Ropes: Leads, just better -Deonyi