Support for mods/custom blocks?

[hqSparx]

Could you add support for it please?

[Fenixin]

Blocks/textures are more or less hardcoded textures.py. Although they are hardcoded, adding them is easier now than ever.

The problem I see with supporting non vanilla blocks is that there are hundred (if not thousands) of mods and customs blocks out there. Is there a right way to offer support for all this?

Maybe a good way to add support to mods/custom blocks is to add to textures.py the possibility to execute external texture files, write a guide on how to add blocks/custom blocks and expect the comunity of a mod to create/keep them updated.

I can write a guide (although my English is pretty bad), but I think I'm not going to add custom blocks. I don't play mods at the moment.

[agrif]

Maybe a good way to add support to mods/custom blocks is to add to textures.py the possibility to execute external texture files, write a guide on how to add blocks/custom blocks and expect the comunity of a mod to create/keep them updated.

A generic plugin system, with support for adding new block types (among other things) has been a personal goal of mine for a while. After the rewrite is 'done', the code will be in a good place to start working on that.

[d-st]

Just for consideration: I've hacked support for RedPower2 into an older copy of overviewer. Not the way it should be done, but it mostly worked. And I've noticed the following while doing so:

• Mods can and will have different block IDs on different installations, so you can't support them generically. The mod-plugin should read the mod's config file to determine the actually used IDs.
• The plugin renderer can probably simply return the processed Block Image ready for tiling.
• It will need access to the BlockID, metadata and TileEntity Data to determine the correct image.

I was thinking along the lines of a plugin-folder where you put a plugin into a directory. On startup, overviewer scans that directory for plugins and runs some initialization code in which the plugin can register it's block IDs, transparent blocks, solid blocks, weather the block needs biome colorization, etc. When an appropriate block ID is encountered, a method of the plugin is called, render_block(id, md, te_data), for example, returning the appropriate image for this block.

The TileEntity data is quite important for more advanced things like RedPower microblocks, RailCraft Rails and such things. For all non-TE blocks None can be passed.

The plugin would bring all the required information with it. The textures would either be stored in it's directory or read from the mod archive, each plugin could handle configuration in a way suited for the mods in question, like having it's own config file, reading the mod's config file, etc.

[DemmyDemon]

I'd wet myself over Spout support, but I see how that can be next to impossible to implement in a mapper seeing as SpoutPlugin blocks don't have extra/special IDs...

[dmon82]

The block textures, or more specifically the index/frame in the texture file, used by mods using the Minecraft Forge API is independent from the block's ID that is used ingame. it is determined in the java source code, passing a filename and index to a function, virtually supporting infinite amounts of textures.

So reading from the config files for block ID's will be of no use to a plugin for Overviewer and a generic plugin is impossible without some handywork.

BUT in either case I'd love to create custom "mappings" to allow Overviewer to find the right frame in the right texture file for the blockID being drawn :)

[pironic]

Im going to close this issue as this will be addressed with #854 once it is merged in. Thank you for your feature suggestion, and for contacting the Overviewer Development Team.