Utilize a wide array of over 600 colored blocks. From dirt, stone, and wood, to derived blocksets like sandstone and stone brick, to colored buttons and levers,
These new blocks come in 16 colors, corresponding to the dyes in vanilla, which can be used to dye any of the original blocks to produce the colored variants. The colored variants can also be re-dyed to new colors. These blocks behave in nearly every way like the originals, including uses in crafting recipes. They will also craft into colored variants where appropriate, such as smelting colored cobble into the same color smooth stone, which will drop the colored cobble when mined.
all dyes take 8 of the block to be dyed and 1 dye, and will yield 8 colored blocks. All other recipes correspond to vanilla recipes with colored variants.
Images and block list:
cobblestone, mossy cobblestone (with biome specific moss!), cobblestone slabs, cobblestone stairs, cobblestone fences, mossy cobblestone fences(also with biome specific moss), smooth stone, and stone slabs
stone bricks, chisled stone bricks, cracked stone bricks, mossy stone bricks(yes, they are biome dependant too), stone brick slabs, stone brick stairs
sand and gravel
coarse dirt, dirt, grass, and farmland
wood pressure plates, stone pressure plates, levers, stone buttons, wood buttons, and doors
Known Issues:
Grass does not spread between colored and non-colored dirt
plants will not stick on the colored dirt/farmland, though they can be placed and grown with bonemeal
crafting vine+colored cobble results in normal moss stone. 2 vines and 2 cobble can be used to make colored variants instead.
Vanilla gates do not adjust location for colored cobble walls. Vanilla cobble walls do not connect to colored cobble walls and gates.
the door textures are sometimes backwards
Known Compatibility
NEI compatible
should have general compatibility with forge mods Download:
Texture Pack Tools:
I have a gimp script which can easily make colored variations of a given texture. This can be used to easily extend texture packs to support my new blocks.
Open the texture you want to color in gimp, then select "generate color variations" at the bottom of the color menu
Fill in the desired block name(should correspond to the texture name I used), and the folder you want the images in
This will generate all 16 variants in the specified folder with ".color" appended to their name. If done right, this should be the correct name for most textures, but there are a couple that need to be renamed.
Of course, you certainly can build textures and models on the fly. However most of this is outside the scope of Minecraft modding, and more specific to Java/LWJGL coding. I've not done it myself but while researching the code (in 1.8 anyway) I can see how a runtime-built Bitmap object could be "converted" to an IIcon or a ResourceLocation (for IIcon, getting it into the block atlas post-init is a little involved - but for TESR's this is obviously irrelevant). For models I'm not so sure though since I've not coded any. Either way, it's a fairly advanced concept - but certainly plausible.
Take a look at Malasis Doors mod for example. It has a machine that lets you design doors by "combining" two other blocks together to create a blended texture for your door, all done in game. Yeah it's simple, but it's effectively "building a texture on the fly" - it probably doesn't actually make a new Bitmap, but I don't see anything stopping you from saving said Bitmap in World NBT as a byte array, and using some central registry in your mod to track and organize which bitmap belongs to what block. The great thing about Minecraft's low-res textures is that they're damn tiny
Another example is recent Galacticraft versions. Players can create their own faction flag with a full paint-style editor GUI (basic, but freeform pixel painting), and it will appear on your flags that you place in-game which other players can see.
But anyway... I'm ranting
Thanks.
Minecrafts low-res and blockyness makes what I am trying to do much easier. I couldn't pull it off with something that was trying to be realistic (at least not without years of R&D), but putting together boxes with basic textures should be easy enough to reach an acceptable quality.
I dont see any way to create ai that will generate a texture that snit plain(no major details) that looks plausible, if you create so it makes complex textures it will end up has modern art, try this:
Create pre made sprites for various parts of the mob that complement them self, them makes the code randomly select and render them in order, if you want it more random make so the code actually can select the major color and change it randomly (snit the most simple but can be done).
I actually done this a long time ago in GTA SA mod, so on that mod you didn't actually see the same person 2 times.
i guess my first suggestion would work for this, store the texture names in a xml sync them and simple load textures over, make so the mode calls from textures over metadata, that puts a limit on how many textures you can have on your plants and flowers so you would probably need more than onene
Let me worry about the details of generating the image itself. Its a challenge, but one I feel is within my abilities. the question is whether I can take this image I made on the fly and use it to texture things, or if the textures need to exist ahead of time
That depends if you need your dynamic content to persist or not. If you generate some funky blocks, mobs, and items somewhere and the player encounters them and then exits the game, when they re-load, are those blocks, mobs, and items expected to be the same as they were when the player left, or are you generating them dynamically yet again?
If you want them to persist, you are going to have performance issues as the number of your objects increases. As others have said, you can do a lot to make things dynamic by storing data in NBT.
Draco's Artifacts mod does just this to make millions of possible items with just one (I think) item class. Performance here is not as good as standard Items, but it's not going to be noticeably slower, either.
For blocks, you can use a TileEntity to have dynamic textures and other properties, but too many tile entities in the world has grave performance issues.
For mobs, you can do the same. As a project for a friend, I made a sample mod where you can click on an entity to change its model/texture within a certain set, and you could easily code your mobs to dynamically select a random model/texture when they spawn, as well as other attributes, which would then be saved with the rest of their data. No one will notice any performance issues from this.
As you can see, items and mobs are the best candidates for dynamic content, and many mods already do so on varying scales. Blocks, however, are likely to be problematic if you want the block class itself to be dynamic, but you could make and register several block classes and then just choose randomly which to use. I would avoid Tile Entities as much as I could.
I do need it to persist. Generating blocks is not as important, and items have enough data in them to meet my customization needs dynamically. I've already got the bulk of what I needed with blocks by generating 16 variants which I can switch between, but it was mainly things like grass and flowers and that I wanted more freedom with. Storing data in NBT for mobs was part of the plan if I couldn't do unique ids, and I really expected to have to do it.
Having a multi-mode mob should suit me just fine, but the question there is whether I can generate a new model/texture on the fly. I haven't gotten to the point of looking at how this works yet, and I could probably work around not being able to, but everything would be much simpler if I can just create it when I need it.
With Forge? Difficult, maybe even impossible (short of using ASM). Entities, blocks and items need to be registered on startup and require specific properties for Minecraft to accept them. You'd have to register a "proxy" aggregator class for each dynamic object type you wish to use register and implement some kind of dynamic loader/unloader for the vanilla block registery (and item registry, entity registry, etc).
Such a thing would certainly require core changes to Minecraft code.
That is what I was afraid of.
One thing is that I don't really need new stuff constantly, but in batches. Specifically, as part of generating a new dimension. Do you think it would be feasible to do a soft reset at such a time to reload everything, and hence create a chance to inject the new things?
For the mod I am hoping to make, I wanted to be able to create new mobs,items, and blocks on the fly. More specifically, I want to be able to generate a new dimension, and populate it with new mobs that did not exist before, and generate new plants unique to that world.
Assuming I am capable of generating the new content, how feasible is it to add it in on the fly? Looking at some forge tutorials, it seems like new blocks and such are added in the initialization of the mods. I can see why this would be important for blocks and items, if forge is trying to auto-assign non-conflicting IDs. I can get by with pre-generating a lot of content if I must, but I can do cooler things if I can create it as-needed.
For mobs, I could even work with a single mob class which shows a custom model/texture that is different from other mobs of that class if I can create new models and textures on the fly. Is this possible?
There are some possible approaches I have considered, but I am not sure how well they would actually work with the API. For instance, I could write out my own config files storing new blocks, items, etc that I read in and register so I can keep track of what I have generated between runs, but I don't know if this would create conflicts with mods loaded afterwards. Or is forge smart enough to figure out consistent IDs from the block name between runs, and so such additions would be fine?
My main issue at this stage is not knowing how forge and minecraft handles such things so I can figure out how to work with it cleanly.
Any thoughts, suggestions, or insight appreciated.
You guys seem to have the gist of it. In programming, a thread is a kind of like a sub-program that runs alongside everything else you are doing, but still has access to the rest of your program and can talk with it. The effect of this is you can have multiple things going on independently of each other, and the computer figures out how to run both at once. If you have a mutlicore proccessor, then different threads can run on different cores and literally run at the same time.
The reason Ryon is saying it makes him cry is that this is much more complex to manage than a normal program, and there are tons of fun and exciting errors that can occur, many of which are very hard to debug. Its a powerful thing, but makes things harder to code.
set the map type to flat, and put in your seed. Spawn, and see where slimes are spawning. Make a normal map with the same seed, and use the locations from the flat map to find slime spawning locations.
0
0
I have confirmed the issue and I'll release an update soon
0
0
0
0
The modID is "galactic" and the mod name is "Galactic Colored Blocks". What is W.A.I.L.A actually displaying?
0
Galactic Colored Blocks
Utilize a wide array of over 600 colored blocks. From dirt, stone, and wood, to derived blocksets like sandstone and stone brick, to colored buttons and levers,These new blocks come in 16 colors, corresponding to the dyes in vanilla, which can be used to dye any of the original blocks to produce the colored variants. The colored variants can also be re-dyed to new colors. These blocks behave in nearly every way like the originals, including uses in crafting recipes. They will also craft into colored variants where appropriate, such as smelting colored cobble into the same color smooth stone, which will drop the colored cobble when mined.
all dyes take 8 of the block to be dyed and 1 dye, and will yield 8 colored blocks. All other recipes correspond to vanilla recipes with colored variants.
Images and block list:
cobblestone, mossy cobblestone (with biome specific moss!), cobblestone slabs, cobblestone stairs, cobblestone fences, mossy cobblestone fences(also with biome specific moss), smooth stone, and stone slabs
Logs, Planks, fences, fence gates, plank slabs, plank stairs, trapdoors
sandstone, carved sandstone, sandstone slabs, smooth sandstone, sandstone bricks
stone bricks, chisled stone bricks, cracked stone bricks, mossy stone bricks(yes, they are biome dependant too), stone brick slabs, stone brick stairs
sand and gravel
coarse dirt, dirt, grass, and farmland
wood pressure plates, stone pressure plates, levers, stone buttons, wood buttons, and doors
plants will not stick on the colored dirt/farmland, though they can be placed and grown with bonemeal
crafting vine+colored cobble results in normal moss stone. 2 vines and 2 cobble can be used to make colored variants instead.
Vanilla gates do not adjust location for colored cobble walls. Vanilla cobble walls do not connect to colored cobble walls and gates.
the door textures are sometimes backwards
should have general compatibility with forge mods Download:
First, install gimp
Then, download the script(below) and install it
Open the texture you want to color in gimp, then select "generate color variations" at the bottom of the color menu
Fill in the desired block name(should correspond to the texture name I used), and the folder you want the images in
This will generate all 16 variants in the specified folder with ".color" appended to their name. If done right, this should be the correct name for most textures, but there are a couple that need to be renamed.
Download:
http://adf.ly/wW9jc
Changelog:
1.01 fix grass particles, fix stone brick crafting
1.0 - initial version
Download:
http://adf.ly/xVQtN
requires forge for 1.8
Like? Donations are appreciated
0
Thanks.
Minecrafts low-res and blockyness makes what I am trying to do much easier. I couldn't pull it off with something that was trying to be realistic (at least not without years of R&D), but putting together boxes with basic textures should be easy enough to reach an acceptable quality.
0
Let me worry about the details of generating the image itself. Its a challenge, but one I feel is within my abilities. the question is whether I can take this image I made on the fly and use it to texture things, or if the textures need to exist ahead of time
0
I do need it to persist. Generating blocks is not as important, and items have enough data in them to meet my customization needs dynamically. I've already got the bulk of what I needed with blocks by generating 16 variants which I can switch between, but it was mainly things like grass and flowers and that I wanted more freedom with. Storing data in NBT for mobs was part of the plan if I couldn't do unique ids, and I really expected to have to do it.
Having a multi-mode mob should suit me just fine, but the question there is whether I can generate a new model/texture on the fly. I haven't gotten to the point of looking at how this works yet, and I could probably work around not being able to, but everything would be much simpler if I can just create it when I need it.
0
That is what I was afraid of.
One thing is that I don't really need new stuff constantly, but in batches. Specifically, as part of generating a new dimension. Do you think it would be feasible to do a soft reset at such a time to reload everything, and hence create a chance to inject the new things?
0
Assuming I am capable of generating the new content, how feasible is it to add it in on the fly? Looking at some forge tutorials, it seems like new blocks and such are added in the initialization of the mods. I can see why this would be important for blocks and items, if forge is trying to auto-assign non-conflicting IDs. I can get by with pre-generating a lot of content if I must, but I can do cooler things if I can create it as-needed.
For mobs, I could even work with a single mob class which shows a custom model/texture that is different from other mobs of that class if I can create new models and textures on the fly. Is this possible?
There are some possible approaches I have considered, but I am not sure how well they would actually work with the API. For instance, I could write out my own config files storing new blocks, items, etc that I read in and register so I can keep track of what I have generated between runs, but I don't know if this would create conflicts with mods loaded afterwards. Or is forge smart enough to figure out consistent IDs from the block name between runs, and so such additions would be fine?
My main issue at this stage is not knowing how forge and minecraft handles such things so I can figure out how to work with it cleanly.
Any thoughts, suggestions, or insight appreciated.
2
The reason Ryon is saying it makes him cry is that this is much more complex to manage than a normal program, and there are tons of fun and exciting errors that can occur, many of which are very hard to debug. Its a powerful thing, but makes things harder to code.
0
0
set the map type to flat, and put in your seed. Spawn, and see where slimes are spawning. Make a normal map with the same seed, and use the locations from the flat map to find slime spawning locations.