Skip to content

Instantly share code, notes, and snippets.

@PaintNinja

PaintNinja/wishlist.md Secret

Last active April 6, 2024 12:13
Show Gist options
  • Save PaintNinja/4d1a35c03b377e78a74c708184ce893e to your computer and use it in GitHub Desktop.
Save PaintNinja/4d1a35c03b377e78a74c708184ce893e to your computer and use it in GitHub Desktop.
Download ZIP
Forge 2024 wishlist/ideas braindump
Raw
wishlist.md

Forge wishlist/ideas braindump

A wishlist of anything I can think of for Forge. From this a subset prioritised todo list can be made, including some stuff others may want, too. This list may be updated overtime. All items are in no particular order.

Crossed off items are already done. Something not being crossed off doesn't necessarily mean it must be done, this is an ideas braindump rather than a "must do todolist" after all.

Table of contents

Forums

  • Update to PHP 8.1
  • Install the GMP extension for PHP
  • Update forum software to latest patch version
  • Double memory limit to 256MB in php.ini
  • Backup database then try migrating to InnoDB
  • Backup forum files then try updating to PHP 8.2, revert if it doesn't work

ForgeGradle

  • Support org.gradle.caching=true in gradle.properties ("FROM-CACHE" is different from "UP-TO-DATE" - see Gradle docs and this stackoverflow answer)
  • Use lazy task registration and configuration throughout
  • Move latest Forge over to the new ForgeGradle as a pilot, userdev and legacy later
  • Use UnionRelauncher in userdev to prevent build issues with some setups
  • Change AT and JarSplitter steps to use Gradle's incrmenetal transformer API to skip processing of classes that haven't changed

AccessTransformers

  • Benchmark new AT system against the old ANTLR one
  • Make latest Forge use the new system

ForgeSPI

  • Get rid of it next MC release, replace with a stupidly simple record system integrated into Forge itself
  • Allow language providers/mod locators/whatever to instantiate the records if they want and supply to Forge

Code style

  • Setup Spotless in Gradle to automatically format code rather than entirely relying on IDEs

CoreMods

  • Bump deps, enable ES6 JS features
  • Actually crash with a descriptive error when a coremod doesn't work rather than logging warnings or silently ignoring it
  • Setup Nashorn JS compilation caching, benchmark before/after

EventBus

  • Support for non-static event handlers in @EventBusSubscriber
  • Support records for events by having an interface instead of an abstract class, or at least as an option
    • Java has special optimisations for records (it always trusts its final backing fields), so this should be faster too
  • Consider preventing registering event handlers for abstract classes
    • Would stop people from doing stupid stuff like subscribing to TickEvent and then checking if (event instanceof TickEvent.PlayerTickEvent) in the handler (or worse... not checking at all), causing lag

Forge

  • Runtime MojMap
  • Update to new Mixin when available
  • Rewrite or remove extension point system
    • Make APIs such as ModLoadingContext.get().registerDisplayTest() the norm for common Forge stuff that used to be extension points
  • Event cleanup
    • Remove event-specific "phases" (e.g. TickEvent.Phase.START/END) and have separate event fires instead. No more if (event.phase == TickEvent.Phase.END) return; // don't run twice per tick crap that some devs forget to do, causing lag
  • Registry cleanup
    • Support registering menu screens with DeferredRegister(?)
    • Consider copying some of downstream's changes
    • Make registration parallel
  • Disallow @OnlyIn on mod classes
    • Some devs seem to think this prevents their mod from crashing when referencing a class marked with @OnlyIn on the wrong side, but it just crashes with a different error message. Better to just not allow it at all and crash on mod load in userdev
  • Consider supporting the unified mod loader tags proposal in 1.21. Could have it alongside forge: prefixed tags, or replace them entirely.
    • Supporting this would help multiplatform mod devs, which we should care about (if it's hard for a multiplatform dev to support Forge, they're less likely to do so)
  • Go through the whole codebase, apply trivial optimisations, new Java API usage and general cleanup
  • Cleanup the mess that is Forge's config system
    • Make mod config loading parallel
  • Support mod reloading and unloading, at least as an opt-in for basic mods (no coremods, no registering new blocks/items, etc)
  • Revive community translation efforts
  • Support connecting to Fabric servers
  • Fix 1.17.1 builds and checks so I can do backports to it and accept 1.16.5 PRs too
  • Rendering cleanup
  • Make a tiny set of super-stable abstraction APIs for the simplest of MC mods to use. Like a mini-Bukkit/Sponge.

ModLauncher

Don't know how to list this without it being step-by-step:

  1. Sync with downstream to get latest fixes
  2. Pick a subsystem to work on
  3. Rewrite it to be simpler and less enterprise-grade code mess
  4. Repeat for each subsystem until done

Early loading screen

  • Fix bugs, simplify code, optimise
  • Add config options for colours and whether to show cpu/ram usage
  • Fix weird alignment vs vanilla loading screen

Discord

  • Pin FAQ in #player-support
  • Make me an admin :P
  • Add a popular server raid protection bot then remove the restrictions for new users
    • The wait time for new users is causing some to leave immediately which is bad for growth
  • Allow moderators to opt-in to "community activity alerts" (e.g. moderators can get DM'ed when Discord thinks there's a raid going on)

WAIFU

  • Revive it, start using it to collect data on Forge API usage
  • Also track mod and version usage to let us see things such as "is adoption of new Forge versions increasing or decreasing over time?"
  • Use the data to make informed decisions about Forge's future
  • Possibly integrate into Forge itself as an opt-in(?)

Paste

  • Create an OpenEye-like system built-into Forge
  • Allow users to opt-in to automatically sending crash reports to it
  • Integrate with WAIFU to identify which mods are causing crashes so we can reach out to the devs and help them fix it (or identify missing APIs that Forge should add)

Documentation

  • Treat this more seriously. People giving grief because of a lack of understanding behind why things are the way they are is something that can be avoided. Would also avoid people using stuff incorrectly or resorting to coremod hacks because they don't know how to do something properly.
  • Put the technical spec docs on the documentation site, e.g. the AT spec
  • Create guides for common Forge API usage patterns
  • Add a dedicated section explaining the volatile nature of MC's internals and teach people how to deal with it (basic reverse-engineering guide)
  • Unify design with files site

MDK

  • Automated tests (basically avoid accidentally breaking the MDK and not noticing until someone reports it)
  • Consider two MDKs
    • One that is the current MDK with more examples for new devs
    • Another is the bare minimum to get started, no usage examples
  • Maybe a Spring Initializr-like system where you can select which APIs you want to use and it generates a project for you
    • Or at least something akin to Fabric's generator where you can tell it the package name and mod ID

Files site

  • Unify design with docs site, make it look more modern
  • Show custom warning text on a per-MC-version-basis. E.g. on the 1.20.3 Forge download page, show a warning at the top saying that it's abandoned and everyone considering it should use 1.20.4 instead.

Froge

  • Revive the idea of Froge
  • Use it as an easy way to share pre-release Forge versions with mod devs
  • Possibly integrate with WAIFU and Paste to automatically send crash reports and get stats
  • All versions suffixed with -alpha and named Froge instead of Forge to make it clear it's not stable

GitHub Actions

  • Move the rest of the repos over to GitHub Actions, make them use latest Gradle
  • Self-host a GH Actions runner on the Forge server to speed up builds
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment