Dynmap: DynmapModScraper not working with MC 1.10.2

[InsaneJ]

DynmapModScraper-2.0.0-forge-10.13.0 doesn't work with Minecraft 1.10.2 and Forge 12.18.1.2075. Which is probably obvious given that it's build for MC 1.7.10. The client log doesn't mention any errors. A quick search in the latest log only finds one line mentioning DynmapModScraper:

[08:31:45] [Client thread/INFO]: FML has found a non-mod file DynmapModScraper-2.0.0-forge-10.13.0.jar in your mods directory. It will now be injected into your classpath. This could severe stability issues, it should be removed if possible.
Full log here: http://paste2.org/zac9EY76

Any chance of an update? We've got a new map where Dynmap doesn't seem to be rendering a lot of Biomes O' Plenty blocks: http://ftb.happydiggers.net/

[mikeprimm]

The switch in 1.8 to customizable JSON based render models really broke the modscraper approach - a lot of the tricks modscraper used just don't work anymore. I really need to add support for the new models definitions, but haven't had time....

[TheBrain0110]

+1

Any updates for the New Year? I know there hasn't been much Dynmap development in general lately, but mod support for modern Minecraft versions would be really helpful :)

[mikeprimm]

Unfortunately no, but on the plus side, I actually got back to working on Dynmap this weekend (see new v2.4 release!). This one is something I need to put some research in to - supporting the post 1.8 JSON-based block model scheme is kinda huge, but also pretty darn valuable, so I do want to get to it. It'll probably phase in - first, with identifying the trivial models (e.g. solid blocks), and ultimately moving to fully parsing and producing render models from the span of what is allowed by the JSON format. There are some challenges, in general, as I need to avoid needing to call MC block code during rendering - it isn't thread safe, as a rule, and often the server side code lacks the APIs that are tied to rendering-related information, besides any performance concerns - and the 'Block State' abstraction (which 90% of the time is just an obfuscation of the old block metadata values, but other times translates to handling things like connectedness to neighbors (e.g. fences, walls, pipes in BuildCraft) and the dreaded Tile Entity data). Fact is, I already know that the JSON handling will not solve everything - but it'll help a lot, and reduce the problem of supporting additional custom blocks to reproducing the block state style logic when needed (and, of course, still handling blocks that do truly custom renderers - water, for example, doesn't fit the JSON model scheme, and nor do pipes in Buildcraft).

[TheBrain0110]

Good to see you're back!

Honestly, for mapping purposes, I'd be fine with just basic solid blocks being shown. It's just weird when looking at the overview map and seeing entire biomes blacked out because they're from Biomes o Plenty and using a non-vanilla block.

Or a house that's transparent because it's built with a slightly different colored wood.
The number of custom-rendered blocks that would actually show up on the map is tiny.

[mikeprimm]

Yep - solid blocks get you most of the way there, but it gets pretty messy trying to handle the non-solid ones without just making them clear (since you need the model data to have an idea which textures to put on the block, even if you are BSing it with a solid block).

[ditchfieldcaleb]

Any updates on this?

[Kailang]

Dynmap is already amazing with just vanilla blocks!
Dynmap will be even more amazing with mod support!

We understand that this is a huge amount of work.
Thanks for working on DynmapModScraper!

[wioxjk]

@Kailang
@ditchfieldcaleb
Don't forget to buy @mikeprimm a beer if he fixes this to show the dude some love

[jasonlang1980]

@mikeprimm what bransh are you working on the DynmapModScraper in? I wouldn't mind taking a crack at helping you out.

[mikeprimm]

I'm starting on a 'v3.0' branch on all the existing repos - and a
test/exploration mod called DynmapBlockScan (
https://github.com/webbukkit/DynmapBlockScan). The work is both
understanding BlockState -> model selection logic (when we're not using the
single-thread-not-safe-for-rendering code in the Block classes), coupled
with parsing and translating the JSON blockstate and model data from MC and
its mods to 'dynmap model and texture' format.

On Thu, May 4, 2017 at 10:55 PM, legracen [e-mail] wrote:

@mikeprimm https://github.com/mikeprimm what bransh are you working on
the DynmapModScraper in? I wouldn't mind taking a crack at helping you out.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/webbukkit/dynmap/issues/1995#issuecomment-299364238,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAn8lxxfT-pnYxIEhevFCcBrHW7wXcw5ks5r2p27gaJpZM4JxSYD
.

--
--Mike

[wioxjk]

@mikeprimm
You should fix up your site, mikeprimm.com.

Add a donate button too, so people can give you some love.