Add ServerChunkEvents.CHUNK_LEVEL_TYPE_CHANGE #4541

DennisOchulor · 2025-03-28T09:14:41Z

Add a new event that fires when a chunk's level type changes. (Relates to #4507)

Changed the name from CHUNK_STATUS_CHANGE as to not confuse it with the ChunkStatus class which refers to chunk generation stages.

The event only provides a ChunkPos and not a WorldChunk. If really needed, a potentially null WorldChunk can be obtained via ChunkHolder#getLatest() but I do not think it's necessary.

The documentation of CHUNK_UNLOAD has also been updated to clarify server chunk unload timing.

…chunk unload timing.

2No2Name

Edit: I am probably wrong about the threads that the level changes take place, since I was confusing this with chunks actually becoming available to the world, including the difference of getChunk and getChunkNow.

I think implementing this without major changes is a bad idea due to the missing explanation of the meaning of the chunk level type changes.
I believe that if understood correctly, the chunk level type is NOT what you want to track, as the status that is being tracked here only describes whether the game aims to load a chunk, but not whether the chunk is actually being loaded or available to the general game logic.

In my mod, lithium, which tracks whether a chunk is accessible in the world, I had several issues tracking this status correctly. I managed to get all events fire on the server thread, to avoid threading issues. Furthermore, Lithium (almost correctly) tracks whether the chunk is accessible in the world, instead of whether the game tries to make it accessible (status set but chunk future not done yet). I believe that if the API just tracks the level/status, many authors will incorrectly assume that this information is sufficient to know that a chunk is available in the world.

Including the other load statuses, especially regarding entity ticking, adds another layer of complexity and unclear meanings, requiring even more clear documentation.

2No2Name · 2025-03-28T12:19:37Z

...ycle-events-v1/src/main/java/net/fabricmc/fabric/mixin/event/lifecycle/ChunkHolderMixin.java

+
+	@Inject(method = "increaseLevel", at = @At("TAIL"))
+	private void increaseLevel(ServerChunkLoadingManager chunkLoadingManager, CompletableFuture<OptionalChunk<WorldChunk>> chunkFuture, Executor executor, ChunkLevelType target, CallbackInfo ci) {
+		ServerChunkEvents.CHUNK_LEVEL_TYPE_CHANGE.invoker().onChunkLevelTypeChange((ServerWorld) world, this.pos, ChunkLevels.getType(this.lastTickLevel), target);


On which thread should this be called, and should this be ensured with a similar check as in
https://github.com/CaffeineMC/lithium/blob/ebcbdb134365ab1862461548f857cdecf96e4d31/common/src/main/java/net/caffeinemc/mods/lithium/common/world/chunk/ChunkStatusTracker.java#L48

I've done some testing and it does seem like the event is always consistently called on the main server thread.

2No2Name · 2025-03-28T12:24:57Z

...le-events-v1/src/main/java/net/fabricmc/fabric/api/event/lifecycle/v1/ServerChunkEvents.java

+	/**
+	 * Called when a chunk changes its {@link ChunkLevelType}.
+	 *
+	 * <p>When this event is called, the chunk's level type has already changed.


Which meaning does changing the chunk level type have?
There might be many misconceptions about this, leading to lots of incorrect implementations. The code comment is very minimal and doesn't indicate any potential issues.

For example, if a mod author believes the chunk status indicates one of the following, there will likely be major issues:

Whether the chunk is loaded, whether entities are ticking in that chunk, whether entities are loaded in that chunk, whether the chunk is ticking blocks in that chunk, etc.

I've updated the documentation of the event to reflect the changes.

...ycle-events-v1/src/main/java/net/fabricmc/fabric/mixin/event/lifecycle/ChunkHolderMixin.java

DennisOchulor · 2025-03-28T14:19:17Z

This is a side note but increaseLevel() and decreaseLevel() are named backwards.

increaseLevel() is called when the chunk level type changes from:

INACCESSIBLE(34+) to FULL(33)
FULL(33) to BLOCK_TICKING(32)
BLOCK_TICKING(32) to ENTITY_TICKING(31 and below)

These are all level decreases, and decreaseLevel() does the reverse of this (but potentially skips intermediate level types).

I don't think this changes the actual functionality of the event but just pointing it out.

2No2Name · 2025-03-28T15:40:41Z

Rewording my concerns:
When the chunk loading isn't done yet by the worker thread, the chunk level is already set to something accessible but the chunk actually isn't accessible. I would really like the API to not just track the chunk holder's chunk level type but the actual behavior of the chunk, but that is very complex and can include threading issues.

…hunk's future is actually completed.

DennisOchulor · 2025-03-29T04:47:47Z

The event is now called when the chunk future has actually completed, and is called on the main thread's executor. I added some rough logging tests to verify the chunk's behaviour aligns with the level type but I'm honestly not sure how to test such a thing correctly.

This has been implemented but there is a potential issue:

This method is only called once if a chunk changes from entity ticking to inaccessible in a single tick. This will make event users to only get a INACCESSIBLE when such transition happens. The event should be called for all intermediate states to avoid confusion.

If a chunk goes straight from ENTITY_TICKING to INACCESSIBLE, and all the intermediate level types are artificially called, then the calls for ENTITY_TICKING -> BLOCK_TICKING and BLOCK_TICKING -> FULL may make modders assume the chunk is still accessible when it really isn't.

…w levelTypes are actually sequential

…n't fire it.

modmuss50

Im not familar at all with the code this is targgeting, if one of my comments doesnt make senese please tell me.

...-v1/src/testmod/java/net/fabricmc/fabric/test/event/lifecycle/ServerChunkLifecycleTests.java

modmuss50 · 2025-04-04T16:23:42Z

...-v1/src/testmod/java/net/fabricmc/fabric/test/event/lifecycle/ServerChunkLifecycleTests.java

+
+			if (!levelTypes.isEmpty()) {
+				StringBuilder sb = new StringBuilder(world.getRegistryKey().getValue() + " ");
+				levelTypes.forEach((levelType, integer) -> sb.append(levelType).append(": ").append(integer).append(", "));


Its not immediately clear what we are logging here? Is it the number of level type changes in the last second?

Yes, it is the number of events fired for each ChunkLevelType, specifially only shows the newLevelType for brevity. I've added a comment there and named the lambda params a bit more descriptively.

modmuss50 · 2025-04-04T16:46:58Z

...ycle-events-v1/src/main/java/net/fabricmc/fabric/mixin/event/lifecycle/ChunkHolderMixin.java

+
+		chunkFuture.thenAccept(optionalChunk -> optionalChunk.ifPresent(worldChunk -> {
+			if (!server.isOnThread()) {
+				server.send(new ServerTask(server.getTicks()-10, runnable)); // ensure the server thread runs it within this tick


Whats the -10 for?

Basically it kinda tricks the server into thinking the task was sent 10 ticks ago. Since the server always executes any tasks sent over 3 ticks ago (even if the server is lagging), this should guarantee it executes within the same tick.

See MinecraftServer#canExecute

protected boolean canExecute(ServerTask serverTask) { return serverTask.getCreationTicks() + 3 < this.ticks || this.shouldKeepTicking(); }

Does this mean that mods using the API cannot rely on the event firing as soon as the chunk becomes available, otherwise risking that their datastructures might be inconsistent with the world for up to a almost an entire gametick?
Can you have a usecase that the API will be helpful for, because I don't understand it the way it is

Firing the event immediately would be ideal but I have no idea how it's possible to get the server thread to do that.

In 1.21.5 mojang mappings I suggest injecting at the end or close to the end of ChunkStatusTasks.full (the last part of the chunk loading futures, which actually adds block entities etc. to the world), allowing the event to fire on the server thread just before the future completes. In lithium I inject into setFullStatus, because I wanted the event before block entities are added

modmuss50 · 2025-04-04T16:49:08Z

...ycle-events-v1/src/main/java/net/fabricmc/fabric/mixin/event/lifecycle/ChunkHolderMixin.java

+		};
+
+		Runnable runnable = () -> {
+			if (this.getLevelType().isAfter(target)) { // If chunk level type got demoted before promotion event fires, then don't fire it. This almost never happens tho.


Is this hiding a bug? Is this a timing issue as you get the levelType in a later tick than when the task was created?

Sort of. This is to cater for the rare edge case where the chunk's level type gets demoted before a prior promotion event gets fired.

e.g.
Chunk goes from INACCESSIBLE -> FULL, promotion event is waiting to fire on server thread.
During the wait chunk goes back to INACCESSIBLE for whatever reasons, demotion event fires immediately.
Promotion event finally fires on server thread, so users get FULL as the final status, when the chunk is actually INACCESSIBLE now.

In practice from my testing, this never happened at all, but I still put this here just in case.

...ycle-events-v1/src/main/java/net/fabricmc/fabric/mixin/event/lifecycle/ChunkHolderMixin.java

2No2Name · 2025-04-05T16:36:54Z

Consider taking a look at Savva's chunk loading rant videos (https://www.youtube.com/@savva4424/videos), which document various chunk loading issues. I think avoiding all pitfalls with the API is not possible, so some tradeoffs have to be made

…off-thread

DennisOchulor · 2025-04-08T02:18:28Z

I've been making some progress on overhauling the current implementation but I've run into an issue.

In 1.21.5 mojang mappings I suggest injecting at the end or close to the end of ChunkStatusTasks.full (the last part of the chunk loading futures, which actually adds block entities etc. to the world), allowing the event to fire on the server thread just before the future completes. In lithium I inject into setFullStatus, because I wanted the event before block entities are added

My new implementation does this, but I realised that after the chunk future has completed, there is still one last callback that runs, which is the onChunkStatusChange() as seen below.

// mojmap: ChunkHolder.scheduleFullChunkPromotion
private void increaseLevel(ServerChunkLoadingManager chunkLoadingManager, CompletableFuture<OptionalChunk<WorldChunk>> chunkFuture, Executor executor, ChunkLevelType target) {
        this.levelIncreaseFuture.cancel(false);
        CompletableFuture<Void> completableFuture = new CompletableFuture();
        completableFuture.thenRunAsync(() -> chunkLoadingManager.onChunkStatusChange(this.pos, target), executor);
        this.levelIncreaseFuture = completableFuture;
        chunkFuture.thenAccept(optionalChunk -> optionalChunk.ifPresent(chunk -> completableFuture.complete(null)));
}

onChunkStatusChange() then calls ServerEntityManager.updateTrackingStatus() which updates the tracking statuses of entities for that chunk. So if the INACCESSIBLE->FULL event fires at the end of ChunkStatusTasks.full, then the chunk itself is accessible but the entities are technically still inaccessible for a bit. However if the event fires only after the tracking statuses have been updated, then the chunk would have been accessible for some time already.

So i'm not really sure what to do here.

ishland · 2025-04-08T02:33:41Z

There is no good way to fire right after the future is completed. I suggest to document this behavior and (probably) make another event that fires at ChunkStatusTasks.full and similar spots for block ticking and entity ticking.

On the side note, onChunkStatusChange is also buggy: there is a race condition that keeps the entity from unloading even if the chunk is already unloaded.

DennisOchulor · 2025-04-08T02:56:24Z

and (probably) make another event that fires at ChunkStatusTasks.full and similar spots for block ticking and entity ticking.

I'm not quite sure what you mean by this. I understood that ChunkStatusTasks.full can only be used to fire INACCESSIBLE->FULL right before the chunk future completes.

In the new implementation, FULL->BLOCK_TICKING is fired right when the tickingFuture completes, and the tickingFuture always runs on the server thread so that works out. Then BLOCK_TICKING->ENTITY_TICKING is fired when the entity tracking statuses have been updated (which may be some time after the entityTickingFuture completes), since only after that do entities actually start ticking.

ishland · 2025-04-08T03:24:04Z

and (probably) make another event that fires at ChunkStatusTasks.full and similar spots for block ticking and entity ticking.

I'm not quite sure what you mean by this. I understood that ChunkStatusTasks.full can only be used to fire INACCESSIBLE->FULL right before the chunk future completes.

In the new implementation, FULL->BLOCK_TICKING is fired right when the tickingFuture completes, and the tickingFuture always runs on the server thread so that works out. Then BLOCK_TICKING->ENTITY_TICKING is fired when the entity tracking statuses have been updated (which may be some time after the entityTickingFuture completes), since only after that do entities actually start ticking.

When your callback is fired, the future have already been completed for an undefined amount of time, even if the future is completed on the main thread. You can't prevent mods from doing silly stuff.
Firing some event right before the level type is reached can be useful for users to do setup work for such level type, and ensure things are 100% set up when the chunk reaches the said type.
There is a real use case for such event in lithium as mentioned in prior comments.

DennisOchulor · 2025-04-09T03:13:25Z

I've completed rewritten the entire implementation. Here's how it works now:

INACCESSIBLE->FULL fires similarly to how Lithium does it. I've tried to add extra checks to prevent duplicate fires but there's still duplicate events firing occasionally.

FULL->BLOCK_TICKING fires right after the tickingFuture is complete.

BLOCK_TICKING->ENTITY_TICKING fires after the FULL->BLOCK_TICKING event. At this point, entities are not actually ticking yet. I'm still not sure how I feel about this since the event might potentially fire a few gameticks before entities start ticking. From my understanding, entityTickingFuture loads in chunks around the chunk that's becoming ENTITY_TICKING, so I don't really see where I could hook into to fire the event besides the onChunkStatusChange callback.

The demotion events now only fire if a previous equivalent promotion event has actually fired. Some tests were also added to ensure all the events are fired in-sync and in a logical order.

DennisOchulor · 2025-04-15T15:21:09Z

I now realise that with the current implementation, for all promotion events (INACCESSIBLE->FULL, FULL->BLOCK_TICKING, BLOCK_TICKING -> ENTITY_TICKING) there is no hard guarantee that entities are actually accessible at all. Realistically there is no way to provide that guarantee unless the events are fired after onChunkStatusChange(). I'm wondering if there is a need to split the event into two, one that fires "before" and one "after", if that makes sense.

The after event would have to fire at the tail of the onChunkStatusChange() lambda, though it was noted that onChunkStatusChange() is buggy so it's not clear that will work well.

At this point, I think it's necessary to nail down the semantics of the API before making any further code changes.

2No2Name · 2025-04-15T16:29:22Z

For this I suggest finding out what the usecases for mod authors would be.

Seems like there are multiple places in the code, e.g. mojmap: LevelChunk.runPostLoad(), which is executed before the end of the chunk loading future and PersistentEntitySectionManager.processPendingLoads, which works on a queue that is filled by futures evaluated by the server thread (should confirm this using a breakpoint before assuming I am correct).

Some entities are also created during chunk generation (not as nbt), e.g. cats (or was it camels?) that are generated with villages. Maybe extra care is needed there.

(Players have their own code paths for adding them to entity sections)

DennisOchulor · 2025-04-16T08:49:34Z

I think the before event would be useful for most use cases. When the events are called entities are already loaded, just not accessible via the various ServerWorld.getEntity() methods.

I tried looking into how chunk level type changes actually affects the game's processes, and this is what I understood so far:

FULL -> BLOCK_TICKING

Block entities start ticking if the chunk is at least loaded (however tickingFuture may not have completed yet)
World tick scheduling only starts ticking when tickingFuture is complete

BLOCK_TICKING -> ENTITY_TICKING

Chunk ticks (e.g. random ticks) start ticking when tickingFuture (not entityTickingFuture) is complete
Entity ticking and mob spawning only start after entityTickingFuture completes and calls onChunkStatusChange()

This makes me think that we should keep INACCESSIBLE->FULL where it is now, and fire the other two promotion events after INACCESSIBLE->FULL regardless of whether the corresponding chunk future has completed. The documentation would have to clarify the entity accessibility issue and that the events are fired before the chunk's behaviour is 100% aligned with its level type.

This would allow mods to prepare for the new level type kinda like what ishland said here.

DennisOchulor · 2025-04-17T11:58:46Z

The implementation has been redone as per my previous comment. The event now also provides a non-null WorldChunk instead of just a ChunkPos. INACCESSIBLE->FULL also no longer accidentally fires duplicate events.

…ver stopped.

ishland

I don't see any immediate problems for the implementation of the API for now. The javadoc might need some clarification.

ishland · 2025-04-20T04:38:47Z

...le-events-v1/src/main/java/net/fabricmc/fabric/api/event/lifecycle/v1/ServerChunkEvents.java

+	/**
+	 * Called when a chunk changes its {@link ChunkLevelType}.
+	 *
+	 * <p>When this event is called, the chunk's {@link WorldChunk#getLevelType()} has already changed. However, the chunk's actual ticking behavior may not fully align with its level type yet.
+	 * Additionally, it is not guaranteed that entities from the chunk are immediately accessible when this event is called.
+	 */


The javadoc sound very vague.

I would document it as something like this:

Called when a chunk's actual ticking behavior is about to align with its {@link ChunkLevelType}.

And if you want to go further into the explanation: (I have added a few more points here)

When this event is being called: <ul> <li>The chunk's {@link WorldChunk#getLevelType()} has already changed. </li> <li>Entities within the chunk are not guaranteed to be accessible. </li> <li>The {@link CompletableFuture} corresponding to the level type is not guaranteed to be done. </li> <li>When transitioning from {@link ChunkLevelType.INACCESSIBLE} to {@link ChunkLevelType.FULL}, calling {@link ServerChunkManager#getChunk(int, int, ChunkStatus, boolean)} to fetch the current chunk at {@link ChunkStatus#FULL} status results in undefined behavior. </li> </ul>

Regarding the last point, doing that in the vanilla system is almost certain to cause a deadlock. But from the standpoint of an alternative chunk system implementation, I would prefer a more relaxed interpretation of this behavior. (For example instead of deadlocking, throwing an exception instead)

<li>The chunk's corresponding level type future in {@link ChunkHolder} is not guaranteed to be done.</li>

I think mentioning ChunkHolder is necessary since it's not clear to people unfarmiliar with the topic what future is being referred to.

For the last point, I understand the deadlock problem but I don't see any reason for event users to call that method since the WorldChunk is already provided by the event.

Note that neoforge does have a fix for it (by just providing the chunk object of the not yet finished future (ugh)), so some multi-platform mods may just try to access the chunk via the world anyway.

I think mentioning ChunkHolder is necessary since it's not clear to people unfarmiliar with the topic what future is being referred to.

Agreed.

For the last point, I understand the deadlock problem but I don't see any reason for event users to call that method since the WorldChunk is already provided by the event.

That's an easy mistake to make. So might just as well include it in the javadoc.
As a side note, NeoForge shouldn't even allow this kind of behavior in the first place. Such bandaid can have unintended side effects as it is presenting almost-full chunks as full chunks.

I've committed the javadoc changes. CHUNK_LOAD and CHUNK_UNLOAD javadocs have also been updated with some extra clarifications.

DennisOchulor · 2025-04-20T23:45:32Z

If there are no other issues, then this API should be ready to go.

...ycle-events-v1/src/main/java/net/fabricmc/fabric/mixin/event/lifecycle/ChunkHolderMixin.java

modmuss50

Im happy with this, I cannot really comment on the implimentation too much. Ill put this into last call, if there are any further concerns please make them be known!

@OverRide

* Add ServerChunkEvents.CHUNK_LEVEL_TYPE_CHANGE * Fix naming * Amend ServerChunkEvents#CHUNK_UNLOAD documentation to clarify server chunk unload timing. * License header and checkstyle * Call event for intermediate level type demotion and call event when chunk's future is actually completed. * Only fire the event async if not already on server thread * When the event fires to promote ChunkLevelType, ensure the old and new levelTypes are actually sequential * If chunk level type got demoted before promotion event fires, then don't fire it. * Update documentation for the event. * test cleanup and use for loop for decreaseLevel * more tests * it mostly works except BLOCK_TICKING->ENTITY_TICKING is still firing off-thread * BLOCK_TICJING -> ENTITY_TICKING now fires on server thread * checkstyle * some javadoc * BLOCK_TICKING->ENTITY_TICKING fires earlier now, and enhance tests * checkstyle * review comments * handle exception instead of letting completeablefuture swallow it * complete rewrite * improve tests and some doc edits * add test to verify all chunks in all worlds are INACCESSIBLE when server stopped. * javadoc changes from review * use @OverRide instead of @unique (cherry picked from commit 230071a)

@OverRide

* Add ServerChunkEvents.CHUNK_LEVEL_TYPE_CHANGE * Fix naming * Amend ServerChunkEvents#CHUNK_UNLOAD documentation to clarify server chunk unload timing. * License header and checkstyle * Call event for intermediate level type demotion and call event when chunk's future is actually completed. * Only fire the event async if not already on server thread * When the event fires to promote ChunkLevelType, ensure the old and new levelTypes are actually sequential * If chunk level type got demoted before promotion event fires, then don't fire it. * Update documentation for the event. * test cleanup and use for loop for decreaseLevel * more tests * it mostly works except BLOCK_TICKING->ENTITY_TICKING is still firing off-thread * BLOCK_TICJING -> ENTITY_TICKING now fires on server thread * checkstyle * some javadoc * BLOCK_TICKING->ENTITY_TICKING fires earlier now, and enhance tests * checkstyle * review comments * handle exception instead of letting completeablefuture swallow it * complete rewrite * improve tests and some doc edits * add test to verify all chunks in all worlds are INACCESSIBLE when server stopped. * javadoc changes from review * use @OverRide instead of @unique

@OverRide

* Add ServerChunkEvents.CHUNK_LEVEL_TYPE_CHANGE * Fix naming * Amend ServerChunkEvents#CHUNK_UNLOAD documentation to clarify server chunk unload timing. * License header and checkstyle * Call event for intermediate level type demotion and call event when chunk's future is actually completed. * Only fire the event async if not already on server thread * When the event fires to promote ChunkLevelType, ensure the old and new levelTypes are actually sequential * If chunk level type got demoted before promotion event fires, then don't fire it. * Update documentation for the event. * test cleanup and use for loop for decreaseLevel * more tests * it mostly works except BLOCK_TICKING->ENTITY_TICKING is still firing off-thread * BLOCK_TICJING -> ENTITY_TICKING now fires on server thread * checkstyle * some javadoc * BLOCK_TICKING->ENTITY_TICKING fires earlier now, and enhance tests * checkstyle * review comments * handle exception instead of letting completeablefuture swallow it * complete rewrite * improve tests and some doc edits * add test to verify all chunks in all worlds are INACCESSIBLE when server stopped. * javadoc changes from review * use @OverRide instead of @unique

Upstream has released updates that appear to apply and compile correctly Upstream Changes: 9d042bab fix: clear "broken" flag when unloaded but not removed 4f2326f7 fix: mitigate sodium bug in another way 7684ab5d new: add elapsed time to task dump bda4198f change: cleanup retry stacktraces f2707da4 Merge branch 'feature/fully-threaded-sched' into dev/1.21.5 7e571abb perf: track ticket size in a separate array 7870d4be fix: missed synchronization 86977bbf change: rename lowMemoryMode to !useLegacyScheduling 06c51bb8 perf: reduce background executor dispatch de8f6d7e change: enable lowMemoryMode by default c91858de perf: more faster 9207f963 perf: consolidate level update notifications eb9ff302 change: use inlined AtomicBoolean 47147991 fix: another fix for concurrency 44b2b53a perf: ever so slightly faster 90ea98f8 fix: small leak 38647703 perf: slightly more perf 7b58b1da fix: some performance issues 92a710f4 new: fully threaded scheduling 2324fe6c fix: never downsize global map 5e526126 build: 0.3.4+alpha.0 dbb3119f new: implements FabricMC/fabric#4541 3af69783 build: use jdk24 for builds 0432c593 new: preventEarlyClientMovementTicks 4c060875 fix: some more adjustment to fluid postprocessing filter 110b645b fix: oops moment 12b859b1 perf: filterFluidPostProcessing 606f5f58 fix: correct failfast behavior b945d666 chore: toString for some statuses

DennisOchulor added 4 commits March 28, 2025 15:18

Add ServerChunkEvents.CHUNK_LEVEL_TYPE_CHANGE

8bc310b

Fix naming

fb40e26

Amend ServerChunkEvents#CHUNK_UNLOAD documentation to clarify server …

d1afef0

…chunk unload timing.

License header and checkstyle

3a24cfb

modmuss50 added the enhancement New feature or request label Mar 28, 2025

2No2Name reviewed Mar 28, 2025

View reviewed changes

ishland reviewed Mar 28, 2025

View reviewed changes

...ycle-events-v1/src/main/java/net/fabricmc/fabric/mixin/event/lifecycle/ChunkHolderMixin.java Show resolved Hide resolved

Call event for intermediate level type demotion and call event when c…

964b2bf

…hunk's future is actually completed.

DennisOchulor added 4 commits March 30, 2025 10:16

Only fire the event async if not already on server thread

06d0bdd

When the event fires to promote ChunkLevelType, ensure the old and ne…

ca262d9

…w levelTypes are actually sequential

If chunk level type got demoted before promotion event fires, then do…

811e0ce

…n't fire it.

Update documentation for the event.

52ecf5f

modmuss50 reviewed Apr 4, 2025

View reviewed changes

test cleanup and use for loop for decreaseLevel

00ff21f

DennisOchulor added 4 commits April 6, 2025 13:12

more tests

26dbc40

it mostly works except BLOCK_TICKING->ENTITY_TICKING is still firing …

cd1a4bf

…off-thread

BLOCK_TICJING -> ENTITY_TICKING now fires on server thread

b1620d1

checkstyle

6229a5c

DennisOchulor added 2 commits April 9, 2025 08:02

some javadoc

fd8659d

BLOCK_TICKING->ENTITY_TICKING fires earlier now, and enhance tests

c3e8e4c

checkstyle

ca22d53

DennisOchulor added 2 commits April 17, 2025 13:21

complete rewrite

74b542b

improve tests and some doc edits

316127a

add test to verify all chunks in all worlds are INACCESSIBLE when ser…

94e4049

…ver stopped.

DennisOchulor requested a review from 2No2Name April 18, 2025 01:10

ishland reviewed Apr 20, 2025

View reviewed changes

javadoc changes from review

7c0cc95

DennisOchulor requested a review from modmuss50 April 22, 2025 14:34

modmuss50 reviewed Apr 22, 2025

View reviewed changes

...ycle-events-v1/src/main/java/net/fabricmc/fabric/mixin/event/lifecycle/ChunkHolderMixin.java Outdated Show resolved Hide resolved

use @OverRide instead of @unique

c814733

modmuss50 approved these changes Apr 24, 2025

View reviewed changes

modmuss50 added the status: last call If you care, make yourself heard right away! label Apr 24, 2025

2No2Name approved these changes Apr 24, 2025

View reviewed changes

ishland added a commit to RelativityMC/C2ME-fabric that referenced this pull request Apr 24, 2025

new: implements FabricMC/fabric#4541

0a04fdc

ishland mentioned this pull request Apr 25, 2025

Add Event#hasListener, remove unused junk #3889

Open

modmuss50 added the status: merge me please Pull requests that are ready to merge label May 2, 2025

modmuss50 merged commit 230071a into FabricMC:1.21.5 May 2, 2025
4 checks passed

ishland added a commit to RelativityMC/C2ME-fabric that referenced this pull request May 2, 2025

new: implements FabricMC/fabric#4541

8321b38

ishland added a commit to RelativityMC/C2ME-fabric that referenced this pull request May 2, 2025

new: implements FabricMC/fabric#4541

dbb3119

DennisOchulor mentioned this pull request May 2, 2025

Add ServerChunkEvents.CHUNK_STATUS_CHANGE #4507

Closed

DennisOchulor deleted the chunk-level-type-change branch May 4, 2025 02:17

DennisOchulor mentioned this pull request May 4, 2025

[1.21.1] Add ServerChunkEvents.CHUNK_LEVEL_TYPE_CHANGE #4610

Merged

Add ServerChunkEvents.CHUNK_LEVEL_TYPE_CHANGE #4541

Add ServerChunkEvents.CHUNK_LEVEL_TYPE_CHANGE #4541

Uh oh!

Conversation

DennisOchulor commented Mar 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

2No2Name left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

DennisOchulor commented Mar 28, 2025

Uh oh!

2No2Name commented Mar 28, 2025

Uh oh!

DennisOchulor commented Mar 29, 2025

Uh oh!

modmuss50 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

2No2Name Apr 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

2No2Name Apr 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

2No2Name commented Apr 5, 2025

Uh oh!

DennisOchulor commented Apr 8, 2025

Uh oh!

ishland commented Apr 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DennisOchulor commented Apr 8, 2025

Uh oh!

ishland commented Apr 8, 2025

Uh oh!

DennisOchulor commented Apr 9, 2025

Uh oh!

DennisOchulor commented Apr 15, 2025

Uh oh!

2No2Name commented Apr 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DennisOchulor commented Apr 16, 2025

Uh oh!

DennisOchulor commented Apr 17, 2025

Uh oh!

ishland left a comment

Choose a reason for hiding this comment

DennisOchulor commented Mar 28, 2025 •

edited

Loading

2No2Name left a comment •

edited

Loading

2No2Name Apr 5, 2025 •

edited

Loading

2No2Name Apr 5, 2025 •

edited

Loading

ishland commented Apr 8, 2025 •

edited

Loading

2No2Name commented Apr 15, 2025 •

edited

Loading