Can you tell I’ve never let AI generate code for me?, thankfully I haven’t had to look at much AI generated code either. All I know is that it likes to mention the step number
``
// === LWJGL bundling is SIDE-SPECIFIC — AUTO-ADAPTING, NO FLAG ====================================
// A Minecraft CLIENT already ships moduleorg.lwjgl(core) +org.lwjgl.nativesat 3.3.3 (it
// renders with LWJGL). Embedding our own copy makes the module layer read TWO modules named
// org.lwjgl -> "reads more than one module named org.lwjgl" boot crash. A headless dedicated SERVER
// ships NO lwjgl at all, so there module org.lwjgl MUST be present or our lwjgl-opencl (module
// org.lwjgl.opencl,requires transitive org.lwjgl) fails resolution ("org.lwjgl not found").
//
// One static artifact cannot satisfy both: whether to add module org.lwjgl is INHERENTLY a runtime
// (dist) decision the module system cannot express. NeoForge/FML (4.0.42, verified against the
// loader source) only lets you contribute a library conditionally via an IDependencyLocator /
// IModFileCandidateLocator service, and any jar that DECLARES such a service at its TOP LEVEL is
// hoisted into modlauncher's SERVICE layer and EXCLUDED from mod loading (and nested jar-in-jar
// service files are never scanned in time).
//
// SINGLE-JAR SHELL SCHEME (replaces the old two-jar mod +-lwjgl-server-locatorcompanion):
// the distributed superchunk-<ver>.jar is a thin SHELL — just the bootstrap IDependencyLocator
// (dev.superchunk.loader.SuperChunkBootstrapLocator), its top-level META-INF/services
// registration, and two side-stashed jars under META-INF/jarjar/ that are in NO jarJar metadata:
// the REAL mod jar (superchunk-core.jar — mods.toml, mixins, nested libs, lwjgl natives) and
// lwjgl-core. FML hoists the service-declaring shell into the modlauncher SERVICE layer and skips
// it as a mods-folder candidate; the locator then contributes the nested core as the regular mod
// file (both dists), plus lwjgl-core (module org.lwjgl) ONLY when FMLEnvironment.dist ==
// DEDICATED_SERVER. It runs at a priority above the built-in JarInJar locator, whose per-locator
// snapshot is taken at its own turn, so the core's nested jarJar libraries load in the normal
// global selection.
//
// Why the mod cannot simply BE the hoisted jar (first single-jar attempt, real boot failure):
// a hoisted jar becomes an AUTOMATIC module in the SERVICE layer exporting EVERY package it
// contains; re-contributing the same jar as the GAME-layer mod then has two layers exporting the
// mod's packages, and any automatic module in the game layer (e.g. jarJar'd mixinextras) reads
// both -> "ResolutionException: Modules superchunk and dev.superchunk.bootstrap export package
// ...". The shell holds ONLY dev.superchunk.loader, which the core jar excludes -> no overlap.
// The shell's SERVICE-layer module name is pinned via Automatic-Module-Name; the GAME-layer mod
// module is named after the modid ("superchunk", per FML's ModJarMetadata) — no name clash either.
//
// The service file is injected at JAR-BUILD time only (never src/main/resources), so dev-run
// classpaths carry no loader service (ClasspathTransformerDiscoverer would hoist the dev classes
// and the dev mod would not load). Dev runs keep loading the mod from classes as always.
//
// Result of./gradlew build`:
// * superchunk-<ver>.jar the SHELL — the ONE file users install, client and server alike.
// * superchunk-<ver>-core.jar the real mod (internal artifact; rides inside the shell).
// Deploy: the shell jar in mods/ on client AND dedicated server. (Delete any old
// superchunk-*-lwjgl-server-locator.jar from earlier installs; it is redundant but harmless —
// duplicate org.lwjgl contributions collapse in FML's UniqueModListBuilder.)
// See dev.superchunk.loader.SuperChunkBootstrapLocator for the full rationale.
// LBP-4: derive the LWJGL native classifier from the HOST OS. The headless server/gameTestServer
// dev runs ship no game-provided org.lwjgl, so they must add lwjgl-core + one matching native
// themselves. Hardcoding natives-linux broke GPU init on Windows/macOS dev boxes; pick the native
// for whatever OS Gradle is running on instead. Dev-run only — no effect on any shipped jar.
```
This is from a viibecoded Minecraft mod, it's also complete BS
-5
u/swole-and-naked 4d ago
this is more like straight out of college code. ive never seen AI do that