Skip to content

Instantly share code, notes, and snippets.

@Jonathing
Last active November 20, 2024 17:01
Show Gist options
  • Save Jonathing/c3ad28b2a048ac839a7baba5417ee870 to your computer and use it in GitHub Desktop.
Save Jonathing/c3ad28b2a048ac839a7baba5417ee870 to your computer and use it in GitHub Desktop.
CoreMods 5.2 ChangeLog

CoreMods 5.2

After many, many long years, CoreMods has finally recieved a sizeable new update, including ECMAScript 6 support for reading your JavaScript files. Most of these new features are aimed at enhancing the usage of ASMAPI within the sandbox. Additionally, a handful of bugs, some which have been present for several years, have finally been fixed.

The goal of this update was to make writing CoreMods less cumbersome. While we will always encourage using the Forge APIs and writing applicable PRs when necessary, CoreMods are sometimes needed to be used as a suitable last-resort option. Hopefully, the extensive updates to ASMAPI will prove to be the extra sugar needed to make maintaining and writing CoreMods just a little bit more manageable.

Changelog

Below is the complete changelog of CoreMods since its 5.0 release.

New Features

  • Added ES6 language support! You can now use let, const, for..of, and various other ES6 features. (#64)
  • Updated ASM to 9.7.1 for Java 24 support. (#47)
  • Updated getMethodNode to use the latest API, Opcodes.ASM9. (#49)
  • Renamed appendMethodCall to injectMethodCall. The former still exists for compatibility, but will be removed in CoreMods 6.0. (#54)
  • Added MethodType.DYNAMIC. (#44)
  • Added NumberType, an enum which allows you to cast numbers into a specific type to be fed as values for LDC instruction nodes, field nodes, etc. (#51, #54)
    • Added castNumber, a method which casts a number into a number type.
    • Added buildNumberLdcInsnNode, a method which returns an LDC instruction node with a number value casted to a number type. Fixes #42.
  • Added a new insertInsnList method which accepts an AbstractInsnNode as opposed to the components of a MethodInsnNode. (#54)
    • This allows for you to use ASMAPI to insert instruction lists using ASMAPI's InsertMode, reducing the need to interface with the method node's instruction list directly.
  • Added InsnType, an enum which allows you to search for instructions of a specific instruction type. These types mirror those found in AbstractInsnNode. (#49)
    • Several helper methods such as findFirstInstruction have been given an additional version with an InsnType parameter. This can be especially useful for looking for specific instructions that do not use Opcodes (such as line number instructions).
  • Added insnToString, a method which turns an instruction node into a String representation. (#49)
  • Added insnListToString, a method which turns an instruction list into a String representation. (#49)
  • Added ldcInsnClassToString, a method which gets the object class of the LDC constant as a String representation. Fixes #30. (#51)
  • Added additional field tools. (#61)
    • Added buildFieldCall, a wrapper method which builds a FieldInsnNode.
    • Added findFirstFieldCall, a method which looks for the first field call in a method. Included sister methods findFirstFieldCallAfter and findFirstFieldCallBefore.
  • Added insertInsn, a method which acts as a sister to insertInsnList but accepts a single instruction. (#62)
  • Added additional instruction searching methods that allow you to search for a specific type rather than (or with) the opcode. (#59)
  • Added sister methods to getMethodNode which accept parameters similar to the MethodNode constructor. (#64)
  • Added getFieldNode, a method to create new FieldNodes. (#64)
  • Added findMethodNode, a method which searches a class for a specific method. (#64)
  • Added findFieldNode, a method which searches a class for a specific field. (#64)

Bug Fixes

  • ASMAPI is now coated in JavaDocs, addressing its former lack of documentation. (#48)
  • Fixed dependency issues when attempting to depend on CoreMods as a project. (#37)
  • Fixed getSystemPropertyFlag prepending "coremods." to the start of the requested property to check for. Fixes #31. (#41, #45)
    • For sake of backwards-compatibility, all bugged iterations of this method will continue to work.
      • Boolean.getBoolean(property)
      • Boolean.getBoolean("coremod." + property)
      • Boolean.getBoolean(System.getProperty("coremod." + property, "TRUE"))
  • Fixed findFirstInstructionBefore ignoring the start index. Fixes #35. (#50)
    • For sake of backwards-compatibility due to the nature of this bug being unfixed for years, the fix will not be applied on Minecraft versions 1.21.1 and older. There are sister methods that include a parameter boolean fixLogic to force the fix if you need it in those older versions. (#56)

What's Next?

Over the coming week, CoreMods 5.2.0 will be added into Minecraft Forge for versions 1.18.2 all the way until the latest version. Work is also being put in cleaning up Forge's existing CoreMod, method_redirector, to take advantage of the new ES6 features and be a better showcase of ASMAPI's capabilities. See MinecraftForge#10159 if you're interested.

Eventually, we plan on killing off the CoreMods project and opting to use another tool in its place. The details of this are still in discussion (i.e. whether we use Mixin, a different tool, or an in-house tool), but the long-term plan for CoreMods is to phase it out of Forge when the time comes. However, while this project continues to exist, we plan on enhancing its usage until we eventually phase it out of Forge. Here's what you can expect in some future updates

  • Type support and better linting for IDEs (see #55).
  • Better error handling (including crashing the game if a CoreMod fails to load).
  • Potential performance improvements when loading CoreMod script files.
    • This could be an opt-out system like how Mixin has require = 0.
  • For SecureModules or ModLauncher: full class dumping after transformation.
    • This is unrelated to the CoreMods project, but still worth bringing up since it can help debug CoreMods.

Special Thanks

I took up working on CoreMods for my own personal gain of improving the coremodding experience for a personal side project of mine. It ended up being a lot of fun diving into Java Bytecode even further than I already have, and I have already been able to take advantage of the new features I've proudly worked on.

I'd like to give some thanks to a few people:

  • Lex, for putting up with me getting elbow-deep into this project. It was effectively dead when I started working on it, but he never stopped me from improving it and I am ever grateful.
  • Paint_Ninja, for helping me learn and get adjusted to the Forge workspaces and the triaging process. We've worked on a handful of Forge projects together since I've joined the triage team, and they've been incredibly helpful in getting my grips on Forge as a whole.
  • IcyCaeli, for making Genesis, the modpack that I work on as my side project. It's the first time in years where I can honestly say that I've enjoyed modding, and playing, Minecraft. If it weren't for him, these CoreMods updates would never have happened.

And thank you, for reading this far. I've come to enjoy my time being on the Forge triage team and being the pseudo-maintainer for CoreMods. I hope you stick around and see you again soon.

- Jonathing, Forge Triage Team

@Jonathing
Copy link
Author

As of today, CoreMods 5.2 is now available in all major Minecraft versions from 1.19.2 to 1.21.3! Some additional work needs to be done before it can reach 1.18.2.

@Jonathing
Copy link
Author

As of just a few days ago, Minecraft Forge for 1.18.2 now contains CoreMods 5.2! As a result of fixing the build issue on TeamCity, it also contains a much-needed fix for an issue with our Jar-in-Jar system. See its changelog for more details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment