Jump to content

Recommended Posts

Posted

I ran into this problem today:

-snip-
Caused by: java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on interfaces require ASM 5
-snip-

 

I don't use asm at all, it's actually Forge loading my classes that's failing. I understand that for this specific problem I can just move my static interface method, but that's going against the whole point of me updating to Java 1.8, and I'm sure similar problems will occur with other Java 1.8 things later anyway.

 

Is there any way I can get Forge to use asm 5? I could probably put it as a dependency in the build.gradle file, but would that make Forge use it?

 

If not - is there a specific reason as to why Forge is still using asm4 over asm5?

BEFORE ASKING FOR HELP READ THE EAQ!

 

I'll help if I can. Apologies if I do something obviously stupid. :D

 

If you don't know basic Java yet, go and follow these tutorials.

Posted

Okay, this is really weird.

 

It's obviously using asm 5 now but it's still throwing the same exception.

java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on interfaces require ASM 5
at org.objectweb.asm.MethodVisitor.visitMethodInsn(MethodVisitor.java:477) ~[asm-debug-all-5.0.3.jar:5.0.3]
at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1416) ~[asm-debug-all-5.0.3.jar:5.0.3]
at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1017) ~[asm-debug-all-5.0.3.jar:5.0.3]
at org.objectweb.asm.ClassReader.accept(ClassReader.java:693) ~[asm-debug-all-5.0.3.jar:5.0.3]
at org.objectweb.asm.ClassReader.accept(ClassReader.java:506) ~[asm-debug-all-5.0.3.jar:5.0.3]
at cpw.mods.fml.common.discovery.asm.ASMModParser.<init>(ASMModParser.java:53) [ASMModParser.class:?]
at cpw.mods.fml.common.discovery.DirectoryDiscoverer.exploreFileSystem(DirectoryDiscoverer.java:100) [DirectoryDiscoverer.class:?]
at cpw.mods.fml.common.discovery.DirectoryDiscoverer.exploreFileSystem(DirectoryDiscoverer.java:89) [DirectoryDiscoverer.class:?]
at cpw.mods.fml.common.discovery.DirectoryDiscoverer.exploreFileSystem(DirectoryDiscoverer.java:89) [DirectoryDiscoverer.class:?]
at cpw.mods.fml.common.discovery.DirectoryDiscoverer.exploreFileSystem(DirectoryDiscoverer.java:89) [DirectoryDiscoverer.class:?]
at cpw.mods.fml.common.discovery.DirectoryDiscoverer.exploreFileSystem(DirectoryDiscoverer.java:89) [DirectoryDiscoverer.class:?]
at cpw.mods.fml.common.discovery.DirectoryDiscoverer.discover(DirectoryDiscoverer.java:53) [DirectoryDiscoverer.class:?]
at cpw.mods.fml.common.discovery.ContainerType.findMods(ContainerType.java:42) [ContainerType.class:?]
at cpw.mods.fml.common.discovery.ModCandidate.explore(ModCandidate.java:71) [ModCandidate.class:?]
at cpw.mods.fml.common.discovery.ModDiscoverer.identifyMods(ModDiscoverer.java:127) [ModDiscoverer.class:?]
at cpw.mods.fml.common.Loader.identifyMods(Loader.java:347) [Loader.class:?]
at cpw.mods.fml.common.Loader.loadMods(Loader.java:468) [Loader.class:?]
at cpw.mods.fml.client.FMLClientHandler.beginMinecraftLoading(FMLClientHandler.java:204) [FMLClientHandler.class:?]
at net.minecraft.client.Minecraft.startGame(Minecraft.java:522) [Minecraft.class:?]
at net.minecraft.client.Minecraft.run(Minecraft.java:931) [Minecraft.class:?]
at net.minecraft.client.main.Main.main(Main.java:164) [Main.class:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_25]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_25]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_25]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_25]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.11.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.11.jar:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_25]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_25]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_25]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_25]
at GradleStart.bounce(GradleStart.java:107) [start/:?]
at GradleStart.startClient(GradleStart.java:100) [start/:?]
at GradleStart.main(GradleStart.java:55) [start/:?]

 

Edit: I'm using Forge 10.13.2.1232 (latest, I think), if that matters.

BEFORE ASKING FOR HELP READ THE EAQ!

 

I'll help if I can. Apologies if I do something obviously stupid. :D

 

If you don't know basic Java yet, go and follow these tutorials.

Posted

I've forked the repository and made this commit and everything seems to work fine, I just have to test it some more before making a pull request.

 

It doesn't seem like there's any extra support really needed, since all the accessing only occurs within the asm classes themselves, that do the appropriate api version checks.

 

 

BEFORE ASKING FOR HELP READ THE EAQ!

 

I'll help if I can. Apologies if I do something obviously stupid. :D

 

If you don't know basic Java yet, go and follow these tutorials.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • I can't figure out if you're looking for help trying to steal someone elses work, or cheat at the game....
    • Title: Why Is It So Hard to Rename and Restructure Mods Like Xray or AntiXray? 🤔 Post text: Hey everyone! I’ve been digging into Minecraft modding for a while and have one big question that I can’t figure out on my own. Maybe someone with more experience could help or give me some advice. Here’s the issue: When I take a “normal” Minecraft mod — for example, one that just adds some blocks or new items — I can easily change its structure, package names, or even rebrand it entirely. It’s straightforward. But as soon as I try this with cheat-type mods like XrayMod or AntiXray, everything falls apart. Even if I just rename the classes, refactor the packages, or hide its identity somehow, the mod either breaks or stops working properly. XrayMod in particular is proving to be a nightmare to modify without losing its core function. So my question is — why is this so much harder with cheat mods like Xray? Is there something fundamentally different about how they’re coded, loaded, or protected that prevents simple renaming or restructuring? And if so, how can I actually learn to understand someone else’s cheat mod enough to safely refactor it without breaking the core features? I’ve already been spending over two months trying to figure this out and haven’t gotten anywhere. It feels like there must be some trick or knowledge I’m missing. Would really appreciate any thoughts, tips, or references — maybe there are guides or techniques for understanding cheat-mod internals? Or if you’ve successfully “disguised” a cheat mod like Xray before, I’d love to hear how you did it. Thanks in advance for any help or discussion. ✌️
    • just started making cinamatic contect check it out on my channel or check out my facebook page    Humbug City Minecraft Youtube https://www.youtube.com/watch?v=v2N6OveKwno https://www.facebook.com/profile.php?id=61575866982337  
    • Where did you get the schematic? Source/Link? And do use an own modpack or a pre-configured from curseforge? If yes, which one On a later time, I can make some tests on my own - but I need the schematic and the modpack name
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.