mirror of
https://github.com/GTNewHorizons/ForgeMultipart.git
synced 2026-11-12 16:37:38 +00:00
Algent
fa976c2002
Kept in the TickScheduler$ shape: the companion holds the implementation because Forge registers that instance itself, and the plain class holds static forwarders. Both halves are load-bearing for different reasons -- guidenh resolves renderWorldBlock as a static first and falls back to MODULE$ -- and neither has a bytecode consumer, only reflective names. The emitted class list is unchanged. All five rendering callbacks keep their signatures, MODULE$ keeps its type and flags, and both classes keep class-level @SideOnly(CLIENT). Only three Scala forwarders for inherited TileEntitySpecialRenderer members and the companion clinit's ACC_PUBLIC differ. The render id is still claimed in the singleton's initialiser, matching the reference's first-access timing. The breaking-overlay branch moved to a private helper that checks the erased Tuple2 and the boxed index before unboxing, which is what the reference's pattern match compiled to. 125 plain-JVM tests and 22 Forge server tests pass, none changed by the port. This class needs a client, so it adds nothing to either suite and everything to the manual checklist.
ForgeMultipart
An API for dynamically handling different functional parts in the one block space.
Requirements:
- The latest version of CCL (files.minecraftforge.net/CodeChickenLib/)
- Forge
- A scala compatible IDE and project (For eclipse, download the scala eclipse plugin and right click on the project -> Add Scala Nature)
If you only want to use the API and not modify it:
- Download the latest dev version from files.minecraftforge.net/ForgeMultipart/
- Download the latest dev version of CCL.
- Place both mods in your /libs/ folder and link them as libraries in your IDE.
Implementation of all parts of the API should be clean and easy in Java. The minecraft multipart mod is implemented in java as a test case.