forked from mirror/Folia
093b1e5394
The place/portal async function now track entities that have been removed from the world but have not teleported. When the server shuts down, these entities will have their passenger tree restored and re-added to the entity slices at the location they were teleporting to, or in the case of portals that did not run placeAsync yet, the location they entered the portal on. This should ensure that for regular teleports that the entity is placed at its correct target location, and for portalling to ensure that either the entity is placed at the portal entrace location (where they entered) or the portal destination. In any case, the entity is preserved in a location and will survive the shutdown. Additionally, move player saving until after the worlds save. This is to ensure that the save logic is performed only after all teleportations have completed. Fix some other misc issues as well: - Fix double nether portal creation by checking if a portal exists again before creating it, fixing a race condition where two entites would portal and neither would see that the other created a portal. - Make all remove ticket add an unknown ticket. In general this behavior is better since it means that unloads will only ever occur at the next tick, rather than during the tick logic. Thus, there will be no cases where a chunk is unloaded unexpectedly. - Do not use fastFloor for calculating chunk position from block position It is not going to return a good value outside of [-1024, 1024] - Always perform mid tick update for ticking regionised player chunk loader If no entities were loaded, no chunks were loaded, and nothing else - the logic would not have otherwise ran. This fixed some rare cases of chunks never loading for players after logging in. |
||
|---|---|---|
| .github/workflows | ||
| build-data | ||
| gradle/wrapper | ||
| patches | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| build.gradle.kts | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| jar.bat | ||
| patch.bat | ||
| rb.bat | ||
| README.md | ||
| regiontodo.txt | ||
| settings.gradle.kts | ||
ForkTest - A Paper fork, using paperweight
This is an example project, showcasing how to setup a fork of Paper (or any other fork using paperweight), using paperweight.
The files of most interest are
- build.gradle.kts
- settings.gradle.kts
- gradle.properties
Tasks
Paperweight tasks
-----------------
applyApiPatches
applyPatches
applyServerPatches
cleanCache - Delete the project setup cache and task outputs.
createMojmapBundlerJar - Build a runnable bundler jar
createMojmapPaperclipJar - Build a runnable paperclip jar
createReobfBundlerJar - Build a runnable bundler jar
createReobfPaperclipJar - Build a runnable paperclip jar
generateDevelopmentBundle
rebuildApiPatches
rebuildPatches
rebuildServerPatches
reobfJar - Re-obfuscate the built jar to obf mappings
runDev - Spin up a non-relocated Mojang-mapped test server
runReobf - Spin up a test server from the reobfJar output jar
runShadow - Spin up a test server from the shadowJar archiveFile
Branches
Each branch of this project represents an example:
mainis the standard examplesubmodulesshows how paperweight can be applied on a fork using the more traditional git submodule systemmojangapishows how a fork could patch arbitrary non-git directories (such asPaper-MojangAPI)submodules-mojangshows the same asmojangapi, but on the git submodules setup fromsubmodules