Support for architecturecraft
kotoroshinoto opened this issue · 5 comments
template is bold
sample data is italicized
Feature Description: Trying to support architecturecraft via pre-definitions in custom renderdata, assuming matching nbtdata for the various shapes and cladding and in-game block types that might be available in a given modpack was even possible to begin with (I have no idea if it is), would rapidly turn into a combinatorial explosion. It would be far better if dynmap was smart enough to read the block information about the blocks and cladding used to create the existing architecture block in the world, and look up the shape/textures to apply apropriately, provided those other things have assigned models/textures, etc.
For example, this is the minetweaker block info for one of my blocks on my roof:
- Additional context: https://github.com/TridentMC/ArchitectureCraft
we are not going to support a specific mod if it chooses to do something custom like ac does, it is too big of a dependency for it to be feasible, and the dev just doesn't have time to work on it. wish it was different but it isn't
the problem for this one in particular is that architecturecraft itself pulls the textures from the blocks in other mods used to make the components.
Since that works through an additional step internally, the blockscan tool can't figure out what to do with them. They're too complex for the straightforward approach.
These items don't actually HAVE their own textures.
They could in principle be paired with ANY block in the entire modpack that is a normal placeable block without entity information in it.
Some of the items also allow cladding, which overlays a different texture on specific parts of the model.
that is exactly what blockscan already does:
7) My dynmap doesn't show modded blocks!
Modded blocks aren't supported out of the box, here are two tools that can help!
-
Dynmap-BlockScan: This mod scans the block textures and model files for most mods and allows dynmap to render them. The most common use case is to render the definitions once, then place the files generated at dynmap/renderdata/modsupport into the dynmap/renderdata folder directly then remove the blockscan plugin. This speeds up server start times and should only need to be run once per server. Once you have done this, upload your files to the repo in #2
http://dynmap.us/builds/DynmapBlockScan/ -
Dynmap-BlockScanData Repo: I created a github repo for data generated by the dynmap blockscan mod. This repo gives instruction where to place the data and puts the definition files in a easy-to-find location and can be less work than running blockscan yourself. This repo is entirely community driven and needs your help to generate mod definition files for those that we don't have already. Most* definition files are version agnostic (1.12.2 files will work on 1.16 and vice versa) but you obviously won't get new textures added in later versions.
https://github.com/FedUpWith-Tech/DynmapBlockScan-Data
Powered by Caffeine•04/09/2021 17:29
If I thought that DynmapBlockScan would be able to handle this specific case gracefully I wouldn't have created this issue. Did you look into this at all or just dismiss it out of hand?