Missing textures for some Oh The Biomes You'll Go blocks
IMBArator opened this issue · 13 comments
Hey there,
I found something strange. I'm trying to integrate Dynmap in a modpack for me and some friends.
But it seems Dynmap or Dynmapblockscan handles some of the blocks in "Oh The Biomes You'll Go" wrong.
There are missing Textures for a bunch of blocks ... but not all. I have already tried to fidle with renderdata/-definitions, but had no success.
In a simple test setup I could identify some specific examples:
- byg:mahogany_leaves
- byg:overgrown_stone
- byg:green_mushroom_block
- byg:white_mushroom_stem
I also could find a example leave block from "Oh The Biomes You'll Go" without any rendering problems:
- byg:ebony_leaves
Versions
For my test setup I installed the folowing Minecraft and mods on my client there is not need to run a stanalone server to reproduce this:
- Minecraft (1.18.2)
- Forge (40.1.73 or 40.1.80)
- Dynmap (3.4-828)
- Dymapblockscan (3.4-SNAPSHOT-229)
- "Oh The Biomes You'll Go" (1.4.4)
- Terrablender (1.2.0.126)
Configurations
All configs are default. Nothing needs to be changed to replicate.
How to Replicate
- Install Minecraft with the above versions
- Start Minecraft and Create a new world
- Search a "Oh The Biomes You'll Go"-Biome
- Some trees have no leaves but others do
- Overgrown blocks are rendered as black void
Screenshots
Rendered map with missing textures
Blocks with Problems
byg block with textures
any mod that doesn't adhere with the standard blockstates of minecraft vanilla, will get rendering errors I heard from the dev.
hmmm ... there is in deed one message in about blockstates in the Output of Dynmapblockscan:
...
[08:20:44] [Server thread/INFO] [DynmapBlockScan/]: [DynmapBlockScan] Start processing states
[08:20:45] [Server thread/INFO] [DynmapBlockScan/]: [DynmapBlockScan] byg:assets/byg/blockstates/potted_hydrangea_bush.json : Failed to open blockstate
[08:20:45] [Server thread/INFO] [DynmapBlockScan/]: [DynmapBlockScan] Loading models....
[08:20:46] [Server thread/INFO] [DynmapBlockScan/]: [DynmapBlockScan] Variant models loaded
[08:20:46] [Server thread/INFO] [DynmapBlockScan/]: [DynmapBlockScan] Parent models loaded and resolved
[08:20:46] [Server thread/INFO] [DynmapBlockScan/]: [DynmapBlockScan] Elements generated
[08:20:46] [Server thread/INFO] [DynmapBlockScan/]: [DynmapBlockScan] Published byg textures to Dynmap
[08:20:46] [Server thread/INFO] [DynmapBlockScan/]: [DynmapBlockScan] Published byg models to Dynmap
When searching for the log, however, I noticed the remaining Dynmap messages. I could not assign this to any mod. But now that my test setup only contains a mob, these messages must be from the models and textures of byg. I have truncated the log output. Dynmap criticizes all 12000 lines of the model file:
...
[08:20:47] [Server thread/FATAL] [Dynmap/]: [Dynmap] Invalid modellist FROM value (0 at line 3
[08:20:47] [Server thread/FATAL] [Dynmap/]: [Dynmap] Invalid modellist FROM value (0 at line 4
[08:20:47] [Server thread/FATAL] [Dynmap/]: [Dynmap] Invalid modellist FROM value (0 at line 5
[08:20:47] [Server thread/FATAL] [Dynmap/]: [Dynmap] Invalid modellist FROM value (0 at line 6
[08:20:47] [Server thread/FATAL] [Dynmap/]: [Dynmap] Invalid modellist FROM value (0 at line 7
[08:20:47] [Server thread/FATAL] [Dynmap/]: [Dynmap] Invalid modellist FROM value (0 at line 8
[08:20:47] [Server thread/FATAL] [Dynmap/]: [Dynmap] Invalid modellist FROM value (0 at line 9
[08:20:47] [Server thread/FATAL] [Dynmap/]: [Dynmap] Invalid modellist FROM value (0 at line 10
...
HA! .... got it working!
Problem is here:
My main gaming system runs with german locale. Dynmapblockscan generates its float values in the model files with , insteand of .. This can not be parsed by Dynmap because it splits every line with the seperator ,. see:
To fix this temporarily i hat to add the following java argument in the command line: -Duser.country=US
I think it would be a good idea to hardcode the float seperator to . in Dynmapblockscan.
@mikeprimm this sounds like a good idea, can you fit in time implement the locale-independent seperator?
I was able to fix the issue and test for Minecraft 1.18.2 with the changes from my fork: https://github.com/IMBArator/dynmap/tree/fix_locale_issue_ModelBlockModelImpl.getLine
Looking at contribution.md I did not create a pull request because I could not test against all versions.
diff --git a/DynmapCore/src/main/java/org/dynmap/modsupport/impl/ModelBlockModelImpl.java b/DynmapCore/src/main/java/org/dynmap/modsupport/impl/ModelBlockModelImpl.java
index aebee9b1..c80c372a 100644
--- a/DynmapCore/src/main/java/org/dynmap/modsupport/impl/ModelBlockModelImpl.java
+++ b/DynmapCore/src/main/java/org/dynmap/modsupport/impl/ModelBlockModelImpl.java
@@ -3,6 +3,7 @@ package org.dynmap.modsupport.impl;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.HashMap;
+import java.util.Locale;
import org.dynmap.modsupport.BlockSide;
import org.dynmap.modsupport.ModelBlockModel;
@@ -69,16 +70,16 @@ public class ModelBlockModelImpl extends BlockModelImpl implements ModelBlockMod
String line;
line = String.format("modellist:%s", ids);
for (ModelBlockImpl mb: boxes) {
- line += String.format(",box=%f/%f/%f", mb.from[0], mb.from[1], mb.from[2]);
+ line += String.format(Locale.US, ",box=%f/%f/%f", mb.from[0], mb.from[1], mb.from[2]);
if (!mb.shade) { // if shade=false
line += "/false";
}
- line += String.format(":%f/%f/%f", mb.to[0], mb.to[1], mb.to[2]);
+ line += String.format(Locale.US, ":%f/%f/%f", mb.to[0], mb.to[1], mb.to[2]);
if ((mb.xrot != 0) || (mb.yrot != 0) || (mb.zrot != 0)) { // If needed, add rotation
- line += String.format("/%f/%f/%f", mb.xrot, mb.yrot, mb.zrot);
+ line += String.format(Locale.US, "/%f/%f/%f", mb.xrot, mb.yrot, mb.zrot);
// If origin also defined, add it
if (mb.rotorigin != null) {
- line += String.format("/%f/%f/%f", mb.rotorigin[0], mb.rotorigin[1], mb.rotorigin[2]);
+ line += String.format(Locale.US, "/%f/%f/%f", mb.rotorigin[0], mb.rotorigin[1], mb.rotorigin[2]);
}
}
for (BlockSide bs : fromBlockSide.keySet()) {
@@ -101,7 +102,7 @@ public class ModelBlockModelImpl extends BlockModelImpl implements ModelBlockMod
break;
}
if (mside.uv != null) {
- line += String.format(":%s/%d/%f/%f/%f/%f", rval, mside.textureid, mside.uv[0], mside.uv[1], mside.uv[2], mside.uv[3]);
+ line += String.format(Locale.US, ":%s/%d/%f/%f/%f/%f", rval, mside.textureid, mside.uv[0], mside.uv[1], mside.uv[2], mside.uv[3]);
}
else {
line += String.format(":%s/%d", rval, mside.textureid);QED:
done ... PR is #3866
I personally don't think this issue requires a test on all supported minecraft versions, as both java 8 and up can provide that locale, you are free to create a pull request to submit the addition.
I am having this exact same issue but I am in the US and the server is in the US locale. Same exact mods, but I am using the fabric variants.
could be the fabric version of BYG uses different block names to the forge version, as there is no blockscan yet for fabric, I'd guess you are out of luck on this. anyways, the original problem got fixed so I am closing this issue
@JurgenKuyper Just so I understand (since I don't know what you mean by blockscan), is this an issue with Fabric API and not dynmap? Should I open an issue with fabric for this?
Thanks! :)
Blockscan is a mod for forge we have that generates the model files for dynmap to render not-standard blocks, for fabric there is no Such thing, this is not an issue with fabricapi, rather that the model names are not cohesive across versions
I'm running into a very similar looking issue right now. I'm running an All The Mods 8 server (specifically this version). I'm in the US, running the server on Ubuntu 20. As far as I know (and I don't know much about this stuff), the local of the server would be US.
I also figure that I'm probably using a version of Dynmap that already has the fix described above (which looks like it was merged via PR #3866 on November 29, 2022), since I'm using this version of Dynmap, which was published on July 8, 2023.
Would anyone be able to give me any guidance on how to debug this issue? I'm not really even sure what logs it would be useful to look at
