feat: single-jar Fabric support for 1.16.1–26.1.2#131
Open
Axionize wants to merge 34 commits into
Open
Conversation
Mirrors packetevents-public's Fabric restructure. Adds Minecraft 26.X
structural support alongside the existing 1.16.1→1.21.11 chain.
fabric-common/ pure-Java library (currently sparse — Grim's
Fabric code is almost entirely MC-typed; this
module exists for cross-variant abstractions that
emerge later).
fabric-intermediary/ existing chain-loading aggregator. All current
fabric/{src,mc1161,mc1171,mc1194,mc1205,mc12111}
moved here via git mv. The accesswidener,
mixins.json, and src layout are byte-identical to
the prior state.
fabric-official/ structural sibling for MC 26.X (Java 25 floor).
Uses fabric intermediary 0.0.0 mapping because
Mojang stopped publishing official mappings with
26.X and Yarn has no 26.X build. mc261 is a stub
— PE and :common are intentionally NOT pulled in
because their intermediary-namespaced
accessWideners can't be remapped against the empty
0.0.0 mapping. Both re-attach when usable 26.X
mappings land.
fabric/ top-level aggregator. JiJ-nests all three
siblings into the single grimac-fabric-<ver>.jar.
All path references in mc*/build.gradle.kts updated from `:fabric:mcXXXX`
to `:fabric-intermediary:mcXXXX`.
- Rename fabric-intermediary modid to grimac-fabric-intermediary. - Add `minecraft: ">=1.16.1 <26"` upper bound on intermediary. - Drop variant include() in top-level fabric aggregator; nest variant remapJars by file path only. - Fix archiveBaseName double-`fabric` prefix for variants.
Each mc11* subproject's fabric.mod.json declared an intermediary- namespaced accessWidener but no MC upper bound, so on a 26.X server Fabric Loader read the AW (loadClassTweakers runs before mod filtering) and crashed with: Namespace (intermediary) does not match current runtime namespace (official) Adding `<26` to each mcXXXX's minecraft constraint short-circuits the mod load before AW processing. Verified: fabric-26.1.2 boots clean with only fabric-official + mc261 loaded; fabric-1.21.11 still loads the full chain (mc1161 mc1171 mc1194 mc1205 mc12111) without regression. Note: mc12111's modid is `grimac-mc1215` (pre-existing typo from before this restructure — not touched here).
Mirror of packetevents-public fad3d33aa. Previously fabric-official shipped no source code, so fabric-loader saw a mod with no entrypoints. This wires a minimal chain-loader scaffold: * GrimACFabricOfficialEntryPoint is registered as preLaunch + main. It discovers grim26ChainLoad entrypoints, sorts them by descending protocol version, and logs the participant count. Full anticheat startup stays deferred because GrimACFabricLoaderPlugin transitively references CommandSourceStack / MinecraftServer / ServerLifecycleEvents which need a 26.X-mapped build to compile. * mc261 declares Grim26ChainEntrypoint as grim26ChainLoad, reporting ServerVersion.V_26_1. Currently a thin marker — grows into a full GrimACFabricLoaderPlugin equivalent once 26.X Mojang-named sources can be compiled. * Grim26ChainEntryPoint interface lives in fabric-official rather than shared with fabric-intermediary because intermediary's GrimACFabricLoaderPlugin carries MC type refs we can't pull. Both branches load mutually exclusively (depends.minecraft ranges <26 vs >=26.1) so the parallel package layout doesn't collide at runtime. * Source stays free of net.minecraft.* references; PE's pure-Java api jar is the only library compileOnly'd into fabric-official + mc261. Loom configures cleanly against intermediary:0.0.0:v2.
…provides
PE 2d8b75d21 hoists the fabric bridge surface into fabric-common with MC
types widened to Object — Grim's compile dep is unchanged (still uses
the PE public API which lives in :api), but the published `packetevents-
fabric` aggregator now also re-exports `packetevents-fabric-common` as a
transitive maven dep so this build picks up the moved FQNs.
GrimExtensionManager.getPlugin("GrimAC") looks the mod up by lowercased
modId via FabricLoader.getModContainer("grimac"). The earlier codex-driven
rename to `grimac-fabric-intermediary` (to differentiate from a future
`grimac-fabric-official`) broke that lookup at runtime — every per-version
GrimACFabricXXLoaderPlugin constructor failed in its supertype's
getPlugin("GrimAC") call. Declaring `provides: ["grimac"]` keeps the
explicit id distinct while restoring the "grimac" alias the extension
manager expects.
Verified by booting a fabric-1.21.11 server with these mods plus
fabric-api 0.141.4+1.21.11 — `Done (0.303s)! For help, type "help"`,
`You are using the latest version of GrimAC`. End-to-end login smoke
(handshake → LoginStart → LoginSuccess → LoginAck → CONFIGURATION
RegistryData reception) passes without PacketProcessException, the exact
path PR #9 broke on fabric.
…ting
Before: PE was JiJ'd inside grimac-fabric-intermediary via modImplementation.
The intermediary nested mod has depends.minecraft<26, so on a 26.1.2 server
fabric-loader skips loading it AND every PE jar nested inside it. The
result was that on 26.1.2, PE was silently absent even though
grimac-fabric-official loaded.
Fix: move the PE JiJ up one level, to the top-level fabric/ aggregator's
include() block. The aggregator's depends.minecraft is >=1.16.1 (no upper
bound), so PE is active across the full MC range covered by either nested
Grim variant. grimac-fabric-intermediary now only depends on PE at compile
time (compileOnly + the per-mcXXXX subproject's compileOnly via the
subprojects { ... } dependencies block).
End-to-end verified on the live test-server profiles with a single
distributable jar (no separate PE deploy):
* fabric-1.21.11: bot joins, full PLAY state, no PacketProcessException.
* fabric-1.19.4: bot joins, full PLAY state, no PacketProcessException.
* fabric-26.1.2: server boots in 0.262s with `grimac` + `packetevents`
mods loaded, chain participants mc261 (Grim) + mc261 (PE) active.
Also picks up the PE-side dedup work (PE published at 2.12.2+b99c4b91a):
shared deps JiJ'd once at PE aggregator level instead of inside each
fabric-intermediary/fabric-official wrapper jar. Grim's aggregator jar
size after both fixes: 12.5MB (was 16.6MB pre-cleanup).
Known residual duplication: PE-api still ends up bundled inside both the
PE aggregator JiJ and grimac-fabric-intermediary's nested JiJ, because
Grim's :common module declares api(libs.packetevents.api) (consumed by
spigot, fabric, etc.). Eliminating that final 4.2MB requires shifting
:common's PE dep to compileOnly and adding it explicitly per platform —
out of scope for this branch.
…eps)
The previous comment claimed the blocker was 'empty 0.0.0 intermediary
mapping → source must avoid net.minecraft.* refs'. That turned out to be
half-true — switching to net.fabricmc.fabric-loom (LoomNoRemap) cleanly
solves the source-compile-against-Mojang-names problem, as proven on the
PE side where fabric-official now ships real Mojang-named source.
The actual blocker for Grim is downstream: cloud-fabric,
fabric-permissions-api, and the fabric-api event modules Grim depends on
all ship intermediary-named bytecode. With LoomNoRemap there's no
runtime intermediary remap, so 'net.minecraft.class_1297' refs inside
those libraries fail to link at compile time:
cannot access class_1297
class file for net.minecraft.class_1297 not found
Three paths out, none in this branch's scope:
1. FabricMC publishes a real 26.X intermediary mapping (drops in
officialMojangMappings() and Grim builds normally).
2. cloud-fabric / fabric-permissions-api ship 26.X-native builds with
Mojang-named bytecode.
3. Grim writes Mojang-name shims for each missing dep — measured at
~6-8h of focused work the previous audit run.
Keep grimac-fabric-official as a scaffold mod: loads on 26.X without
crashing (verified end-to-end on the live fabric-26.1.2 profile), logs
chain participation, but the GrimAC anticheat engine itself is gated
until one of the three paths above resolves.
Codex review on cc89bee found 1 HIGH + 1 MED: * HIGH: common's api(libs.packetevents.api) propagated through fabric-intermediary's implementation(project(':common')) dep and got picked up by jij-conventions, nesting packetevents-api-*.jar inside grimac-fabric-intermediary AGAIN (a second copy beyond the one already inside the aggregator-level packetevents-fabric.jar). Switched common to compileOnly(libs.packetevents.api) — every platform now bundles PE through its own JiJ path, and the api-scope leak vanishes. * MED: fabric/build.gradle.kts's include(libs.packetevents.fabric) had no repo.grim.ac/snapshots in its repositories block, so the aggregator could only resolve PE when mavenLocalOverride=true. Added the repository so CI / fresh checkouts work too. Net size: grimac-fabric.jar 12.5MB -> 8.6MB after the dedup. Verified all three MC versions still boot + accept clients with the single 8.6MB Grim aggregator jar deployed (no separate PE).
Was living only at the agent harness's fallback path (/workspace/Grim/.test-scenarios/); pull it into the repo's preferred location so the flight-catch verification travels with the branch. Mirrors the existing flight-smoke-paper-1.19.4 shape — runs a wurst client through the standard chat-based Flight toggle and expects Grim to flag NoFall/Simulation/GroundSpoof/Vertical within 5s.
…nges Mirror of PE 1a09ba6c5. Codex r2 MED on PE flagged the same issue on Grim's aggregator: '>=1.16.1' unbounded would accept any post-1.21.11 MC where no nested variant activates. Declare the union of intermediary's '<26' and official's '>=26.1.2 <26.2' so fabric-loader rejects unsupported MC versions at range-check time.
Codex r2 MED. Even though Java 25 is the toolchain target, Gradle itself
needs to run on Java 25 because fabric-official's LoomNoRemap plugin
configures the MC 26.1.2 jar (Java 25 bytecode) during the Gradle
configuration phase, before toolchain selection kicks in. On the previous
Java 21 runner, configuring :fabric-official failed with:
java.lang.IllegalStateException: Minecraft 26.1.2 requires Java 25
but Gradle is using 21
This unblocks :fabric:remapJar and :fabric:publishMods on CI.
Two metadata fixes flagged by codex r3:
* `depends.minecraft` was unbounded (`>=26.1`) on both the
fabric-official wrapper and mc261's per-version chain participant,
contradicting the aggregator's `>=26.1.2 <26.2` range. Tightened both
to match so the nested metadata is self-consistent and won't claim
support for hypothetical 26.2+ snapshots.
* fabric-official's chain code references PacketEvents API types
(ServerVersion, etc.) but the mod metadata didn't declare a
`packetevents` dep. Loader could in principle init fabric-official
before PE was on the classpath, surfacing as NoClassDefFoundError.
Added `packetevents: "*"` to both depends blocks, matching the
pattern fabric-intermediary already follows.
Codex r3 flagged the `fabric-loom` + intermediary:0.0.0:v2 wiring as "not LoomNoRemap." Empirically true (the short plugin id resolves to LoomGradlePlugin, not LoomNoRemapGradlePlugin), but the effective behavior is identical here: the empty intermediary stub has zero entries, so the named→intermediary remap pass is a no-op. Mojang-named bytecode passes through remapJar untouched. Adding a comment to document that this is deliberate — not a mis-config. Switching to PE's actual LoomNoRemap pattern would require non-trivial plumbing (different jar task, no `namedElements` variant, different aggregator JiJ wiring) for no functional benefit while the scaffold has no MC-touching source. Worth revisiting if and when real 26.X anticheat code lands and uses intermediary-typed transitive deps (which is the real blocker, not the plugin choice).
The `>=1.16.1` predicate was over-claiming. fabric/build is a union of two ranges — intermediary variant `[1.16.1, 26)` and official variant `[26.1.2, 26.2)` — and the loader-side fabric.mod.json already encodes that union. mc-publish accepts multi-line YAML scalars as OR predicates (verified against Kir-Antipov/mc-publish@v3.3 README example), so the publish metadata can mirror the same shape. Filter behavior (game-version-filter default) is unchanged, so the published version list is a subset of what `>=1.16.1` produced plus 26.1.2 from the second predicate. Closes the last open codex r3 finding.
…ggregator)
The nested fabric-intermediary jar was declaring `provides: ["grimac"]`
while the top-level fabric aggregator already owns `id: "grimac"`.
Fabric loader resolved the duplicate by keeping the aggregator and
REJECTING the entire intermediary chain — so the JiJ tree showed
grimac + fabric-common + packetevents loading, but
grimac-fabric-intermediary / mc1161 / mc1171 / mc1194 / mc1205 / mc1215
were all silently dropped. Net effect on a fabric server: anticheat
engine never initialized.
Removing the provides alias lets fabric-intermediary register under
its real modid. `FabricLoader.getModContainer("grimac")` still resolves
to the aggregator, which has the same version, so the one consumer
(MetricsFabric.java:100) continues to work.
Verified: deploy to fabric-1.21.11 now responds to `/grim version`
with the new build's version string instead of "Unknown command."
- flight-smoke-fabric-1.19.4.json: mirror of the 1.21.11 Wurst Flight
scenario but pointed at the 1.19.4-wurst client. Validates Grim
catches movement cheats on the lower intermediary range.
- connect-smoke-fabric-26.1.2.json: real 26.1.2 Wurst client connects
to the fabric-official scaffold and the server reports the player
via /list. Doesn't fire Wurst hacks (anticheat engine is inactive
on the 26.X scaffold — documented in fabric-official source). The
test verifies PE + scaffold load cleanly on Mojang-named MC.
The prior comment hand-waved at "intermediary-bound deps" as the blocker. Replacing it with a per-category breakdown gathered by actually attempting the port (copy fabric-intermediary/src/main/java → fabric-official, pull :common, add compileOnly stubs for the missing deps, run :fabric-official:compileJava): 29 errors clustered into four buckets, each with a defined fix path. Keeping the file list in source so the next session that picks this up doesn't have to redo the same dig. State is unchanged — fabric-official still ships scaffold-only. The anticheat engine works on the intermediary chain (1.16.1-1.21.11); 26.X needs the four-category port described in the comment.
Adds category E (build/remap packaging — AW + mixin refmap + nested-jar viability under the empty intermediary stub) and re-sequences D first so compile targets exist before grinding source: D → E → A → B → C.
…(Phase D)
Source code is a port of fabric-intermediary/src/main/java/ac/ac/grim/grimac/platform/fabric/*
adapted to the 26.1.2 mojmap surface. Reuse-vs-duplication notes per the
plan you signed off on:
- :common is the engine + checks — pulled via `implementation(project(":common"))`,
same as fabric-intermediary. Today this means common's transitive deps
(adventure, cloud-core, GrimAPI, HikariCP, etc) get JiJ'd inside BOTH
fabric-intermediary and fabric-official, costing ~4MB of duplication
in the aggregator. Phase E follow-up: lift to aggregator-level JiJ.
- :fabric-common — unchanged, JiJ'd at the aggregator once. Erased-bridge.
- packetevents — already aggregator-JiJ'd, no change. PE's mc261 covers
the 26.X packet pipeline; this port just consumes PE's platform-agnostic API.
mc261 covers the full 26.1.X family. Verified empirically: 26.1 / 26.1.1 /
26.1.2 share an identical Java public/private signature surface (0 of 300
randomly sampled classes drift; 6 of 6 hand-picked critical classes — MS,
ServerPlayer, ServerLevel, CommandSourceStack, Player, Entity — bit-equal
javap -p -s). When 26.2 lands a real release a sibling breakpoint joins it.
What this commit does:
Phase A (strip intermediary-bound):
- Delete FabricPermissionRegistrationManager, FabricSenderFactory,
command/FabricPlayerSelectorParser, manager/FabricParserDescriptorFactory.
- GrimACFabricLoaderPlugin replaced with a fabric-official variant whose
getCommandService() returns no-op (matches the catch path the
intermediary chain takes when cloud-fabric is unavailable — your
design call, "Grim runs without commands"). getPermissionManager()
no-op; vanilla op-level perm check via CommandSourceStack.permissions()
.hasPermission(new Permission.HasCommandLevel(PermissionLevel.byId(2))).
- NoopFabricSenderFactory implements just enough of SenderFactory to
keep Sender wrapping alive.
Phase B (fabric-api events → mixin-driven):
- FabricServerEvents holds STARTING / STOPPING / END_TICK listener lists.
Phase C will wire a MinecraftServer mixin to fire them. Until then the
engine loads but doesn't actually tick.
- GrimACFabricEntryPoint registers Grim's start/stop/tick on
FabricServerEvents instead of ServerLifecycleEvents.SERVER_STARTING
etc. Scheduler classes likewise. Entry point listens on `grim26MainLoad`
(parallel to intermediary's `grimMainLoad`) for chain participants.
Phase C (26.X mojmap drift fixes — landed inline):
- ResourceKey.location() → .identifier()
- CommandSourceStack.hasPermission(int) → .permissions().hasPermission(...)
- MinecraftServer.getProfileCache().get(name) → .services().profileResolver().fetchByName(name)
- MinecraftServer.getOperatorUserPermissionLevel() → .operatorUserPermissions().level().id()
- Inventory.getSelected() → .getSelectedItem()
- Player.displayClientMessage(...) → .sendSystemMessage(...)
- GameProfile is now a Record: .getId() → .id(), .getName() → .name()
Phase D (compile targets):
- mc261 subproject: Fabric261LoaderPlugin (extends parent
GrimACFabricLoaderPlugin, registered under grim26MainLoad), plus
concrete Fabric261PlatformServer / Fabric261PlatformPlayer /
Fabric261PlatformInventory / Fabric261GrimEntity / Fabric261MessageUtil
/ Fabric261ConversionUtil.
Phase E (build wiring):
- grimac.accesswidener copied from intermediary; loom.accessWidenerPath
points at it so private MC fields used by :common resolve at compile.
- :common added to fabric-official compile classpath; subprojects get
it compileOnly + packetevents.api/fabric compileOnly.
Compile clean: :fabric:remapJar BUILD SUCCESSFUL on JAVA_HOME=jbrsdk-25.
Aggregator grows 8.6MB → 12.6MB; runtime hookup (the mixin) and JiJ
dedup are the remaining Phase E/F items before the engine actually
detects movement violations on a real 26.1.2 server.
…se B) Replaces fabric-api's intermediary-bound ServerLifecycleEvents/ServerTickEvents with a direct mixin into MinecraftServer that fires the FabricServerEvents listener lists from Phase D: @Inject HEAD runServer() → fireServerStarting @Inject HEAD stopServer() → fireServerStopping @Inject TAIL tickServer() → fireEndTick This unblocks the engine: Grim's start/stop/tick init paths now actually run on 26.X. Without this the platform plugin loaded but never advanced past static init. Also drops the dead scaffold: - GrimACFabricOfficialEntryPoint.java (the chain-discovery stub) - loader/Grim26ChainEntryPoint.java (the chain interface) both replaced by GrimACFabricEntryPoint registering listeners on FabricServerEvents directly; fabric.mod.json's main/preLaunch entries point at it. grimac.mixins.json registers the new MinecraftServerMixin alongside the carry-over Level/ServerPlayer/Piston mixins. End-to-end deploy + mineflayer fake-flight verification still to come.
… one
The grim-setup-side scenario schema landed `requires` + `when` predicates
(see /opt/grim-setup/docs/PHASE6.md). flight-smoke-fabric-{1.21.11,1.19.4}
and connect-smoke-fabric-26.1.2 are subsumed by the new
scripts/test-scenarios/flight-smoke-fabric.json (rw mirror commit dfaed96),
which resolves server/client via capability rather than hardcoded version.
- Fabric261ConversionUtil.fromFabricItemStack: replace the EMPTY stub with
the same STREAM_CODEC path the intermediary chain uses. PE's
PacketWrapper.createUniversalPacketWrapper round-trips the encoded
RegistryFriendlyByteBuf into the PE ItemStack the engine consumes.
Codex r6 flagged: stub-EMPTY would have broken CompensatedInventory
platform fallback + CheckManagerListener resync (elytra, powder snow,
Soul Speed, arrow checks would all see empty inventory).
- toNativeText: 26.X removed Component.Serializer.fromJson in favor of
ComponentSerialization.CODEC + DFU JsonOps. Switching to that needs
registry context for round-trip; not worth wiring just for console
alerts. Adventure→native via ComponentFlattener loses styling but is
correct for the engine's actual use sites.
- MinecraftServerMixin comment: codex caught the inversion. HEAD of
runServer() fires BEFORE initServer (initServer is the first
instruction inside it), which is where fabric-api's SERVER_STARTING
also fires. Comment now reflects that.
- fabric-official/build.gradle.kts: replaced the now-stale "concrete
remaining work" comment block (the work landed in 22343a1 +
1a309fd) with a brief description of the actual architecture.
…t + state fix)
Reverts the :common dedup attempt (190610703) which broke mixin interface
injection — PlatformWorld classes moved to a sibling mod boundary that the
Mixin system couldn't resolve at injection time.
PE changes in this build:
- PlayerListMixin: HEAD of placeNewPlayer wires setPlayer, TAIL fires
UserLoginEvent. Gives Grim the player-join callback on 26.X.
- ConnectionMixin: setupInboundProtocol/setupOutboundProtocol TAIL hooks
reinject PE's encoder/decoder after MC replaces the pipeline codecs at
each state transition (LOGIN → CONFIGURATION → PLAY).
- reinjectPipelineHandlers: detects CONFIGURATION → PLAY transition via
pipeline handler names and forces User.connectionState to PLAY so PE's
decoder processes PLAY-state movement packets.
- injectAtPipelineBuilder: skip User re-creation on subsequent
configureSerialization calls (preserves the named/UUID'd User that
PlayerDataManager keys on).
PE changes that enabled 26.X anticheat detection:
- ServerboundPacketType_26_1: correct ordinals from bytecode
instruction order (javap -c -p, getstatic sequence). Previous
extraction from constant pool missed cross-package packets
(common/cookie/ping) registered in PLAY state, shifting
PLAYER_POSITION from ordinal 30 to the wrong position.
- PlayerListMixin: fires UserLoginEvent + sets player object
- ConnectionMixin: reinject hooks, CONFIGURATION→PLAY state force
- injectAtPipelineBuilder: guard against User re-creation
- reinjectPipelineHandlers: state-only (no handler removal)
- IOOBE catches in handleServerBoundPacket + handleClientBoundPacket
Live-verified: Wurst Flight on fabric-26.1.2 produces
Grim » Offline failed Simulation (x1) 61.582505 /gl 2
Grim » Offline failed GroundSpoof (x1) claimed true
Two fixes for the 26.X pipeline: 1. CheckManagerListener.onPacketReceive: if GrimPlayer is null in PLAY state, force re-create via addUser. On 26.X the GrimPlayer vanishes from PlayerDataManager after the first few PLAY packets (root cause TBD — likely PE pipeline state issue during CONFIGURATION→PLAY transition). Without this, no check processing runs after packet #5. 2. NoopFabricSenderFactory.sendMessage: log alerts via SLF4J ("Grim" logger) so they appear in latest.log + tmux. sendSuccess on the console CommandSourceStack doesn't reliably route to the server log on 26.X. Removed temp diagnostic code from PacketPlayerJoinQuit and CheckManagerListener (was accidentally committed in prior iteration).
forcePut bypasses shouldCheck which fails on 26.X due to transient channel state during PE pipeline transitions. LogUtil.info used for all sendMessage calls so alerts appear in latest.log + tmux. Detection is confirmed working (Wurst Flight → Simulation + GroundSpoof flags verified in client-side chat). Console-side alert routing is the remaining issue — the alerts route to player chat but not to the server console output path. Likely because the console Sender's CommandSourceStack doesn't properly trigger server-side logging on 26.X.
- Remove duplicate "Grim » " prefix from NoopFabricSenderFactory — the Adventure Component already contains the prefix from %prefix%. - Remove packetDiagCounter and movement/alert diagnostic printlns from CheckManagerListener and AlertManagerImpl.
…er 0.19.2 Fabric Loader 0.19.2 resolves nested JiJ entrypoints even when their version constraints don't match. mc1140's `<1.19` caused ClassNotFoundException on MC >=1.19. Widened to `<26` to match parent intermediary module.
Polymer 0.16 (26.X) switched from nucleoid PacketTweaker's PacketContext.create(ServerPlayer) to fabric-api's networking v1 PacketContext via PacketContextProvider mixin on ServerPlayer. The hook now tries the new fabric-api path first, falling back to the old nucleoid path for pre-26.X servers. Both paths use reflection so neither requires compile-time dependencies.
- Trim block comments on GrimACFabricLoaderPlugin and NoopFabricSenderFactory to fit the "explain non-obvious WHY only" rule. - Bump PE to b9bc23cbf which drops the IOOBE try-catches and reverts unnecessary modifications to ServerboundPacketType_26_1.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
System.out.printlnthroughNoopFabricSenderFactory(verbose + normal paths)PolymerHookfor fabric-apiPacketContextAPI change on 26.XVerified
flight-smoke-fabricon fabric-26.1.2: PASSflight-smoke-fabric-1.21.11on fabric-1.21.11: PASSflight-smoke-fabric-1.19.4on fabric-1.19.4: PASSTest plan