Should we make increasiningly more small usecase blocks, or adopt SubstanceMatters (https://github.com/Terasology/SubstanceMatters) for blocks with only slightly different behavior, or perhaps a blend. In this usecase, the Soils library
as it currently exists, https://github.com/Terasology/Soils/tree/master/assets/blockTiles/auto ,
we have 3 types of soil with 3 conditions. Average, Poor, Rich; Wet, Damp, Dry. Which is indeed nice, and gives us the benifite of multiple soil types for varied farming and biomes, such as different textures, how ever, they lack depth, and in order to create truelly dynamic soil, we're either going to have to define soil types by the thousands, or adopt SubstanceMatters.
For example, we could fit every soil type we currently have in one block, with the properties of how wet it is,and its quality. But theres no reason to stop there. Have each of those go on a scale of 0 to 99, and thats 1,000,000 (100*100*100) different soil types, vs, 9 (3*3). But theres still no reason to stop there. Add in specifics, stuff like, carbon, nitrogen, beneficial bacteria, calcium, magnesium, phosphorus,lime, bone meal, Vermiculite, blood meal, compost, manur, coir, coffee grounds, compost tea, biosoilds ,hydroabsorbant polymers, sphagnum moss, peat, mass, densitiy, etc. and you have a very high level functioning system to build dynamic farming and ecology off of. adding those all together and thats, 100000000000000000000000000000000000000000000000000 soil types, that can adjust themselves as plants take in and put out nutrients . How ever, that is a lot of data (well, stored, we could put it in slightly less than 22 bytes, but it depends on how the module/java is storing these values)
So perhaps, the extream is not the best. After all, if we do this we only have one texture. So perhaps, we need to create atleast a decent amount of soilblocks, in order to offload some of the data, and to allow different textures. (having a 100 (or more) blocks defined for wetness seems like a good standard, but then a plant drawing water out of blocks would have to change its ID)
If water remains a blocks, this would perhaps also be a good system for defining water pressure/mass/density, temp, contamintents, etc.
Perhaps this will also help us sort out the soil library with clear cut guidelines.. I'm planning to add sands to it, but perhaps those belong in the mineral library, or their own.
as it currently exists, https://github.com/Terasology/Soils/tree/master/assets/blockTiles/auto ,
we have 3 types of soil with 3 conditions. Average, Poor, Rich; Wet, Damp, Dry. Which is indeed nice, and gives us the benifite of multiple soil types for varied farming and biomes, such as different textures, how ever, they lack depth, and in order to create truelly dynamic soil, we're either going to have to define soil types by the thousands, or adopt SubstanceMatters.
For example, we could fit every soil type we currently have in one block, with the properties of how wet it is,and its quality. But theres no reason to stop there. Have each of those go on a scale of 0 to 99, and thats 1,000,000 (100*100*100) different soil types, vs, 9 (3*3). But theres still no reason to stop there. Add in specifics, stuff like, carbon, nitrogen, beneficial bacteria, calcium, magnesium, phosphorus,lime, bone meal, Vermiculite, blood meal, compost, manur, coir, coffee grounds, compost tea, biosoilds ,hydroabsorbant polymers, sphagnum moss, peat, mass, densitiy, etc. and you have a very high level functioning system to build dynamic farming and ecology off of. adding those all together and thats, 100000000000000000000000000000000000000000000000000 soil types, that can adjust themselves as plants take in and put out nutrients . How ever, that is a lot of data (well, stored, we could put it in slightly less than 22 bytes, but it depends on how the module/java is storing these values)
So perhaps, the extream is not the best. After all, if we do this we only have one texture. So perhaps, we need to create atleast a decent amount of soilblocks, in order to offload some of the data, and to allow different textures. (having a 100 (or more) blocks defined for wetness seems like a good standard, but then a plant drawing water out of blocks would have to change its ID)
If water remains a blocks, this would perhaps also be a good system for defining water pressure/mass/density, temp, contamintents, etc.
Perhaps this will also help us sort out the soil library with clear cut guidelines.. I'm planning to add sands to it, but perhaps those belong in the mineral library, or their own.