Dynmap-Forge/Fabric

Dynmap-Forge/Fabric

888k Downloads

Dymap crashing on startup in custom modpack.

BonaireDreams opened this issue ยท 8 comments

commented

Issue Description: Any version of dynmap newer than the Dec 22 snapshot crashes when dynmap initializes right after the "preparing world". Tried renaming the old dynmap folder to allow the mod to create a fresh default install. Still fails. Going back to the old Dec 22 snapshot works. (dynmap-3.3-SNAPSHOT-forge-1.18 It could be a few days before dec 22, but that is the file creation date when I downloaded it) I can provide the exact build # but not certain where to find that.

  • Dynmap Version: dynmap-3.3-beta-4-forge-1.18, Also any newer dynmap snapshot 3.3
  • Server Version: forge 1.18 forge 39.0.10, was on 39.0.8 also failed
  • Pastebin of Configuration.txt: https://pastebin.com/t2F51RAZ
  • Server Host (if applicable): Personal dedicated linux server
  • **Pastebin of crashlogs https://pastebin.com/EGvw3cVh
  • Other Relevant Data/Screenshots: Using Spahx BDcraft 16x for vanilla textures only. no hi res textures added for the mods.

GOOD LOAD with the older snapshot See below for where the new one crashes
Server thread/INFO21:44:54
Time elapsed: 16586 ms
Done (16.930s)! For help, type "help"
21:44:55
Successfully initialized permission handler forge:default_handler
[Dynmap]: Added 20 custom biome mappings
[Dynmap]: Using ops.txt for access control
[Dynmap]: Register commands
Netty Epoll Server IO #1/INFO21:44:58
Disconnecting Player (server is still starting): Server is still starting! Please wait before reconnecting.
Server thread/INFO21:45:04
[Dynmap]: Mod Support processing completed <---- Crash happens before this is displayed in the console on the newer buils.
21:45:05
[Dynmap]: quark[3.0.0] models enabled
[Dynmap]: immersiveengineering[1.18.1] models enabled
Server thread/FATAL21:45:05
[Dynmap]: Invalid custommodel block name immersiveengineering:fake_light at line 463
Server thread/INFO21:45:05
[Dynmap]: waystones[9.0.1] models enabled
[Dynmap]: mysticalagriculture[5.0.1] models enabled
[Dynmap]: immersiveengineering[1.18.1] textures enabled
Server thread/WARN21:45:05
[Dynmap]: Invalid texture block name: immersiveengineering:fake_light
Server thread/INFO21:45:05
[Dynmap]: mysticalagriculture[5.0.1] textures enabled
[Dynmap]: waystones[9.0.1] textures enabled
[Dynmap]: quark[3.0.0] textures enabled
21:45:07
[Dynmap]: Loaded 27 shaders.
[Dynmap]: Loaded 82 perspectives.
[Dynmap]: Loaded 22 lightings.
[Dynmap]: Starting enter/exit processing
Dynmap Render Thread/INFO21:45:07
[Dynmap]: Finish marker initialization

[X] I have looked at all other issues and this is not a duplicate
[X] I have been able to replicate this

commented

I saw on discord you believe this is caused due to lightstates from other mods blocks and that you are looking at a bandaid (ignore the call) so it at least prevents the crash. Is there a way to determine from the crash log which mods (and or blocks) are causing this. I can report the issue to the mods author as well to see about a permanent fix.

commented

I can log the block state I caught the exception for as a warning

commented

OK found it with just the buildinggadgets mod (no other block additions):

[18:45:48] [Server thread/WARN]: [Dynmap] Exception while checking lighting data for block state: buildinggadgets:construction_block[ambient_occlusion=true,bright=true,neighbor_brightness=true]
[18:45:48] [Server thread/WARN]: [Dynmap] Exception while checking lighting data for block state: buildinggadgets:construction_block[ambient_occlusion=true,bright=true,neighbor_brightness=false]
[18:45:48] [Server thread/WARN]: [Dynmap] Exception while checking lighting data for block state: buildinggadgets:construction_block[ambient_occlusion=true,bright=false,neighbor_brightness=true]
[18:45:48] [Server thread/WARN]: [Dynmap] Exception while checking lighting data for block state: buildinggadgets:construction_block[ambient_occlusion=true,bright=false,neighbor_brightness=false]
[18:45:48] [Server thread/WARN]: [Dynmap] Exception while checking lighting data for block state: buildinggadgets:construction_block[ambient_occlusion=false,bright=true,neighbor_brightness=true]
[18:45:48] [Server thread/WARN]: [Dynmap] Exception while checking lighting data for block state: buildinggadgets:construction_block[ambient_occlusion=false,bright=true,neighbor_brightness=false]
[18:45:48] [Server thread/WARN]: [Dynmap] Exception while checking lighting data for block state: buildinggadgets:construction_block[ambient_occlusion=false,bright=false,neighbor_brightness=true]
[18:45:48] [Server thread/WARN]: [Dynmap] Exception while checking lighting data for block state: buildinggadgets:construction_block[ambient_occlusion=false,bright=false,neighbor_brightness=false]
[18:45:49] [Server thread/INFO]: [Dynmap] Extracted files upgraded

That tracks with the top location in your exception report.

commented

Interesting. I do have Building Gadgets in the pack. It places a ghost block and then replaces those with the actual block you are building with. (similar to construction wands) Although once complete all that is left are the actual vanilla blocks built with. I can open a report on Direwolf20's Building Gadgets Github. What is the best terminology to explain what his mod is doing to cause the crash in newer versions of Dynmap. As older versions of Dynmap work, I assume it has not prevalent enough yet to have been reported.

commented

Older version worked because I didn't look up lighting passthrough behavior before, because I hadn't needed to work around the fact the upgraded chunk lighting on 1.18 is completely FUBAR, and I got tired of all the complaints about broken lighting data :)

commented

All good. I have the latest 3.3 snapshot working and it does log the warnings. I also submitted a report to Building Gadgets github to see if they can fix the root cause.

commented

I know this is closed with the workaround. Building Gadgets just released a version that should address the root cause. Not sure if you need to make any changes to dynmap.
BG Commit

commented

Nah - my 'safety logic' is non-specific, so the fix will just improve things (I'll get the information I need for doing lighting when the MC lighting is FUBAR, which it is on upgrade a lot....). Thanks for the info, though!