Crashing on loading or creating world

[Cmdpro]

Describe the bug Whenever i create or load a world with modonomicon and my mod (along with my mods dependencies), it crashes

To Reproduce Steps to reproduce the behavior:

1. Open or create world
2. Crash

Expected behavior For it to not crash

System (please complete the following information):

• Modonomicon Version: 1.63.0
• OS: Windows
• Minecraft Version: 1.20.1
• Modpack Link and Version, or list of mods: Geckolib, JEI, Modonomicon, Curios, Lodestone, and Runology (my mod)

latest.log

[SooarynAC]

Same here, after updating it started crashing.

[klikli-dev]

@Cmdpro can you reproduce this with just modonomicon? And then maybe with your mod setup but without loading your book (e.g. just moving it out of the folder for a moment) For me with just modo it all works on forge and fabric

The error you have "java.lang.NoSuchMethodError: 'char org.commonmark.internal.renderer.text.BulletListHolder.getMarker()" looks like something went wrong with loading the markdown library included with modonomicon, which .. I have no idea how to cause or fix as fabric does that.

@SooarynAC can you share your crashlog too?

[Cmdpro]

It seems to still happen even without the book being in the books folder, it didnt crash like this before updating so whatever caused the issue was done in the latest update, maybe you forgot to include something or whatever you changed is just causing this on its own

[klikli-dev]

@Cmdpro does it happen on your end if you just do a minimal setup on curseforge launcher with fabric + modonomicon?

Also it might be good to force a re-download of dependencies (./gradlew --refresh-dependencies might be sufficient, although I sometimes have to manually delete the cache and let it re-download).

One possibility is that something went wrong when building the jar file and the dependency was not included there, but I don't think fabric's gradle toolchain can even have such an error, hence the curseforge + redownload test scenario

[Cmdpro]

wait, im using forge? with what you are saying it seems like you think im on fabric

[klikli-dev]

I did indeed think you were using fabric - but the same applies to forge actually (dependency packing and loading is done by forge Jar In Jar )

[Cmdpro]

i dont use the curseforge launcher but it still crashes with prism latest.log

[KakashoLin]

Same issue here. It rererences an illgeal char.

Modonomiconcrash-2024-03-27_12.42.07-client.txt

[KakashoLin]

Based on the error, it is pointing to CoreComponentNodeRenderer.class under client >Book >Markdown of the mod.

And seems to be having an issue with this section maybe?

public void visit(BulletList bulletList) { this.context.setListHolder((ListHolder)new BulletListHolder(this.context.getListHolder(), bulletList)); visitChildren((Node)bulletList); if (this.context.getListHolder().getParent() != null) { this.context.setListHolder(this.context.getListHolder().getParent()); } else { this.context.setListHolder(null); } Block block = bulletList.getParent(); if (block instanceof ListItem) { ListItem item = (ListItem)block; if (item.getNext() instanceof ListItem) return; } this.context.finalizeCurrentComponent(); }

[GaeaKat]

I dont think it is a jar in jar. It is able to find BulletListHolder and ListHolder and all similar stuff, according to the crash log it bounces in and out of org.commonmark a lot before the crash

[TheRanker]

joining an exisiting or creating new,,, the latest version of modonomicon crashes for me as well. Suspected Mod: Modonomicon (modonomicon), Version: 1.63.0 Issue tracker URL: https://github.com/klikli-dev/modonomicon/issues at TRANSFORMER/modonomicon@1.63.0/com.klikli_dev.modonomicon.client.gui.book.markdown.CoreComponentNodeRenderer.visit(CoreComponentNodeRenderer.java:145)

[klikli-dev]

Thanks for all the investigation! It is really an odd error, this part of the code has not been touched in months on my end, and the actual missing method has not been changed in commonmark in years (plus, the dependency version is unchanged). I will experiment a bit on my end and try to get it to repro in dev, my working theory is still that something went wrong on compile/pack, but as Kat pointed out, JarInJar works to load, and it should not even be able to modify the bytecode to cause getMarker to go missing in commonmark

[GaeaKat]

said this in discord, will here so it is logged, diffing the two jar's has showed a possible cause:

diff -r modonomicon-1.20.1-forge-1.62.0/ modonomicon-1.20.1-forge-1.63.0/
diff -r modonomicon-1.20.1-forge-1.62.0/META-INF/MANIFEST.MF modonomicon-1.20.1-forge-1.63.0/META-INF/MANIFEST.MF
8,9c8,9
< Implementation-Timestamp: 2024-03-04T06:25:21+0000
< Timestamp: 1709533521182
---
> Implementation-Timestamp: 2024-03-27T14:42:18+0000
> Timestamp: 1711550538300
Only in modonomicon-1.20.1-forge-1.62.0/META-INF/jarjar: commonmark-0.21.0.jar
Only in modonomicon-1.20.1-forge-1.63.0/META-INF/jarjar: commonmark-0.22.0.jar
Only in modonomicon-1.20.1-forge-1.62.0/META-INF/jarjar: commonmark-ext-gfm-strikethrough-0.21.0.jar
Only in modonomicon-1.20.1-forge-1.63.0/META-INF/jarjar: commonmark-ext-gfm-strikethrough-0.22.0.jar
Only in modonomicon-1.20.1-forge-1.62.0/META-INF/jarjar: commonmark-ext-ins-0.21.0.jar
Only in modonomicon-1.20.1-forge-1.63.0/META-INF/jarjar: commonmark-ext-ins-0.22.0.jar
diff -r modonomicon-1.20.1-forge-1.62.0/META-INF/jarjar/metadata.json modonomicon-1.20.1-forge-1.63.0/META-INF/jarjar/metadata.json
10c10
<         "artifactVersion": "0.21.0"
---
>         "artifactVersion": "0.22.0"
12c12
<       "path": "META-INF/jarjar/commonmark-0.21.0.jar",
---
>       "path": "META-INF/jarjar/commonmark-0.22.0.jar",
22c22
<         "artifactVersion": "0.21.0"
---
>         "artifactVersion": "0.22.0"
24c24
<       "path": "META-INF/jarjar/commonmark-ext-gfm-strikethrough-0.21.0.jar",
---
>       "path": "META-INF/jarjar/commonmark-ext-gfm-strikethrough-0.22.0.jar",
34c34
<         "artifactVersion": "0.21.0"
---
>         "artifactVersion": "0.22.0"
36c36
<       "path": "META-INF/jarjar/commonmark-ext-ins-0.21.0.jar",
---
>       "path": "META-INF/jarjar/commonmark-ext-ins-0.22.0.jar",
diff -r modonomicon-1.20.1-forge-1.62.0/META-INF/mods.toml modonomicon-1.20.1-forge-1.63.0/META-INF/mods.toml
20c20
< version = "1.62.0" #mandatory
---

it looks like something changed the versions when the jar was made

[klikli-dev]

said this in discord, will here so it is logged, diffing the two jar's has showed a possible cause:

diff -r modonomicon-1.20.1-forge-1.62.0/ modonomicon-1.20.1-forge-1.63.0/
diff -r modonomicon-1.20.1-forge-1.62.0/META-INF/MANIFEST.MF modonomicon-1.20.1-forge-1.63.0/META-INF/MANIFEST.MF
8,9c8,9
< Implementation-Timestamp: 2024-03-04T06:25:21+0000
< Timestamp: 1709533521182
---
> Implementation-Timestamp: 2024-03-27T14:42:18+0000
> Timestamp: 1711550538300
Only in modonomicon-1.20.1-forge-1.62.0/META-INF/jarjar: commonmark-0.21.0.jar
Only in modonomicon-1.20.1-forge-1.63.0/META-INF/jarjar: commonmark-0.22.0.jar
Only in modonomicon-1.20.1-forge-1.62.0/META-INF/jarjar: commonmark-ext-gfm-strikethrough-0.21.0.jar
Only in modonomicon-1.20.1-forge-1.63.0/META-INF/jarjar: commonmark-ext-gfm-strikethrough-0.22.0.jar
Only in modonomicon-1.20.1-forge-1.62.0/META-INF/jarjar: commonmark-ext-ins-0.21.0.jar
Only in modonomicon-1.20.1-forge-1.63.0/META-INF/jarjar: commonmark-ext-ins-0.22.0.jar
diff -r modonomicon-1.20.1-forge-1.62.0/META-INF/jarjar/metadata.json modonomicon-1.20.1-forge-1.63.0/META-INF/jarjar/metadata.json
10c10
<         "artifactVersion": "0.21.0"
---
>         "artifactVersion": "0.22.0"
12c12
<       "path": "META-INF/jarjar/commonmark-0.21.0.jar",
---
>       "path": "META-INF/jarjar/commonmark-0.22.0.jar",
22c22
<         "artifactVersion": "0.21.0"
---
>         "artifactVersion": "0.22.0"
24c24
<       "path": "META-INF/jarjar/commonmark-ext-gfm-strikethrough-0.21.0.jar",
---
>       "path": "META-INF/jarjar/commonmark-ext-gfm-strikethrough-0.22.0.jar",
34c34
<         "artifactVersion": "0.21.0"
---
>         "artifactVersion": "0.22.0"
36c36
<       "path": "META-INF/jarjar/commonmark-ext-ins-0.21.0.jar",
---
>       "path": "META-INF/jarjar/commonmark-ext-ins-0.22.0.jar",
diff -r modonomicon-1.20.1-forge-1.62.0/META-INF/mods.toml modonomicon-1.20.1-forge-1.63.0/META-INF/mods.toml
20c20
< version = "1.62.0" #mandatory
---

it looks like something changed the versions when the jar was made

Omg thank you that was it. Somehow, despite requesting a specific, older version of commonmark the latest version is being included (not sure if that is an issue on commonmark's maven, or in gradle/forgegradle) and that probably really changed their API. Dear gods.

Now the fun part: On my end this does not happen because locally the correct old version is pulled. Seems the github build is the only affected one

[GaeaKat]

said this in discord, will here so it is logged, diffing the two jar's has showed a possible cause:

diff -r modonomicon-1.20.1-forge-1.62.0/ modonomicon-1.20.1-forge-1.63.0/
diff -r modonomicon-1.20.1-forge-1.62.0/META-INF/MANIFEST.MF modonomicon-1.20.1-forge-1.63.0/META-INF/MANIFEST.MF
8,9c8,9
< Implementation-Timestamp: 2024-03-04T06:25:21+0000
< Timestamp: 1709533521182
---
> Implementation-Timestamp: 2024-03-27T14:42:18+0000
> Timestamp: 1711550538300
Only in modonomicon-1.20.1-forge-1.62.0/META-INF/jarjar: commonmark-0.21.0.jar
Only in modonomicon-1.20.1-forge-1.63.0/META-INF/jarjar: commonmark-0.22.0.jar
Only in modonomicon-1.20.1-forge-1.62.0/META-INF/jarjar: commonmark-ext-gfm-strikethrough-0.21.0.jar
Only in modonomicon-1.20.1-forge-1.63.0/META-INF/jarjar: commonmark-ext-gfm-strikethrough-0.22.0.jar
Only in modonomicon-1.20.1-forge-1.62.0/META-INF/jarjar: commonmark-ext-ins-0.21.0.jar
Only in modonomicon-1.20.1-forge-1.63.0/META-INF/jarjar: commonmark-ext-ins-0.22.0.jar
diff -r modonomicon-1.20.1-forge-1.62.0/META-INF/jarjar/metadata.json modonomicon-1.20.1-forge-1.63.0/META-INF/jarjar/metadata.json
10c10
<         "artifactVersion": "0.21.0"
---
>         "artifactVersion": "0.22.0"
12c12
<       "path": "META-INF/jarjar/commonmark-0.21.0.jar",
---
>       "path": "META-INF/jarjar/commonmark-0.22.0.jar",
22c22
<         "artifactVersion": "0.21.0"
---
>         "artifactVersion": "0.22.0"
24c24
<       "path": "META-INF/jarjar/commonmark-ext-gfm-strikethrough-0.21.0.jar",
---
>       "path": "META-INF/jarjar/commonmark-ext-gfm-strikethrough-0.22.0.jar",
34c34
<         "artifactVersion": "0.21.0"
---
>         "artifactVersion": "0.22.0"
36c36
<       "path": "META-INF/jarjar/commonmark-ext-ins-0.21.0.jar",
---
>       "path": "META-INF/jarjar/commonmark-ext-ins-0.22.0.jar",
diff -r modonomicon-1.20.1-forge-1.62.0/META-INF/mods.toml modonomicon-1.20.1-forge-1.63.0/META-INF/mods.toml
20c20
< version = "1.62.0" #mandatory
---

it looks like something changed the versions when the jar was made

Omg thank you that was it. Somehow, despite requesting a specific, older version of commonmark the latest version is being included (not sure if that is an issue on commonmark's maven, or in gradle/forgegradle) and that probably really changed their API. Dear gods.

Now the fun part: On my end this does not happen because locally the correct old version is pulled. Seems the github build is the only affected one

sounds like a cache is broked somewhere, either their maven is broke and providing the wrong jar, and you have right cached, or github's cache is broke, as TBH It would make sense for github to use a proxy to cache outgoing maven requests

[klikli-dev]

It looks like this should be fixed. After a lot of experimenting and conjecture it seems what really fixed it was compiling again. Please report if .64 does not fix it for you