geforkt von Mirrors/Paper
Paper 1.21 V2 #14
Keine Reviewer
Label
Kein Label
Bug
Codeverbesserung
Einsteiger Freundlich
Idee
In Arbeit
Neues Feature
Prio A
Security Breach
Überprüfung notwendig
Verbesserung
Zu Beobachten
Kein Meilenstein
Kein Projekt
Niemand zuständig
2 Beteiligte
Nachrichten
Fällig am
Kein Fälligkeitsdatum gesetzt.
Abhängigkeiten
Keine Abhängigkeiten gesetzt.
Referenz: SteamWar/Paper#14
Laden…
In neuem Issue referenzieren
Einen Benutzer sperren
Keine Beschreibung angegeben.
Branch "1.21-2" löschen
Das Löschen eines Branches ist permanent. Obwohl der Branch für eine kurze Zeit weiter existieren könnte, kann diese Aktion in den meisten Fällen NICHT rückgängig gemacht werden. Fortfahren?
send-namespaced
is false (#9366) d928dda91dPlayerInteractEvent#getClickedBlock()
returning wrong block in adventure mode (#10019) bcbe5dcd78org.bukkit.craftbukkit.inventory
inMetaHandledTagsTest
f187fd696ahasFiredAsync
parameter whenAsyncPlayerSendCommandsEvent
is called (#10896) b3e072a625paper.disableOldApiSupport
andpaper.disablePluginRemapping
(#11108) 75af62b298@ -0,0 +128,4 @@
- SeedCommand.register(this.dispatcher, environment != Commands.CommandSelection.INTEGRATED);
- SetBlockCommand.register(this.dispatcher, commandRegistryAccess);
- SetSpawnCommand.register(this.dispatcher);
+ ListPlayersCommand.register(this.dispatcher); //LocateCommand.register(this.dispatcher, commandRegistryAccess);
Formatting, warum wird der ListPlayers-Command zugelassen (kann dank /glist und /list auf dem Bungee eh nicht erreicht werden?
@ -0,0 +195,4 @@
- SetPlayerIdleTimeoutCommand.register(this.dispatcher);
+ //SetPlayerIdleTimeoutCommand.register(this.dispatcher);
StopCommand.register(this.dispatcher);
TransferCommand.register(this.dispatcher);
Bitte deaktivieren.
@ -0,0 +214,4 @@
io.papermc.paper.util.ObfHelper.INSTANCE.getClass(); // Paper - load mappings for stacktrace deobf and etc.
// Paper start - initialize global and world-defaults configuration
+ try {
+ Main.paperConfig.get();
Warum ist das hier (noch) nötig?
@ -0,0 +269,4 @@
+ if(value.getFirst().equals(entries))
+ return (RTree<T>) value.getSecond();
+ }
+ //System.out.println("Entries " + entries.size() + " " + entries.hashCode());
Debug code
@ -0,0 +104,4 @@
io.papermc.paper.util.ObfHelper.INSTANCE.getClass(); // Paper - load mappings for stacktrace deobf and etc.
// Paper start - initialize global and world-defaults configuration
- try {
- Main.paperConfig.get();
Siehe Init Improvements 1...
@ -0,0 +114,4 @@
this.paperConfigurations.initializeWorldDefaultsConfiguration(this.registryAccess());
// Paper end - initialize global and world-defaults configuration
diff --git a/src/main/java/net/minecraft/util/datafix/fixes/BlockStateData.java b/src/main/java/net/minecraft/util/datafix/fixes/BlockStateData.java
index 6b1af6df2427a6c2f7954c89935bf33279d58204..51f32a847c954846fb0c18e802287a26d507ee9f 100644
Mir fehlt hier eine Änderung in der MinecraftServer.java, und zwar das Auskommentieren von CraftBlockData.reloadCache(). Wird das jetzt benötigt? Ist das keine langsame Operation mehr?
Im Profile taucht es nicht auf, also scheint es wohl nicht sehr relevant zu sein
@ -0,0 +9792,4 @@
.setValue(WEST_WALL, WallSide.NONE)
.setValue(WATERLOGGED, Boolean.valueOf(false))
);
- this.shapeByIndex = this.makeShapes(4.0F, 3.0F, 16.0F, 0.0F, 14.0F, 16.0F);
Ah, warum ist das jetzt aufgeteilt auf die beiden Änderungen? Wäre toll, wenn das alles in einem der Init improvements wäre. (ggf. auch mal die patches in mehrere sinnvolle Gruppierungen aufteilen. BlockStateData ist z.B. ein Kandidat für einen einzelnen Commit :D.
@ -0,0 +9828,4 @@
- builder.put(ImmutableMap.of(UP, boolean_, EAST_WALL, wallSide, WEST_WALL, wallSide3, NORTH_WALL, wallSide2, SOUTH_WALL, wallSide4, WATERLOGGED, Boolean.FALSE), voxelShape10);
- builder.put(ImmutableMap.of(UP, boolean_, EAST_WALL, wallSide, WEST_WALL, wallSide3, NORTH_WALL, wallSide2, SOUTH_WALL, wallSide4, WATERLOGGED, Boolean.TRUE), voxelShape10);
+ builder.put(hashWallState(wallSide, wallSide2, wallSide4, boolean_, Boolean.FALSE, wallSide3), voxelShape10);
+ builder.put(hashWallState(wallSide, wallSide2, wallSide4, boolean_, Boolean.TRUE , wallSide3), voxelShape10);
Bist du dir sicher, dass du dann alle möglichen Wall-States (in der gleichen Reihenfolge wie vanilla) generiert hast?
Macht es einen Unterschied, ob es "wie vanilla" ist?
Das ist ja ein Cache für den Server, deshalb meine ich nicht.
Und ich bin mir Ziemlich sicher, dass da alles drin ist, ist immerhin noch der selbe Code wie vorher
Wie vanilla kann hier schon relevant sein: Das sieht mir hier nach der BlockState-Generation aus, und wenn die nicht mehr stimmt, haben die plötzlich bei uns andere BlockState-IDs. Das wäre schlecht. Kannst du prüfen, indem du mit "vanilla"-Server mal Walls in vielen Kombinationen platzierst und dann im gepatchten Server nachschaust, ob die noch genauso aussehen.
Jain, es wird eine Map von den BlockStates auf die Hitbox gemacht. d.H. die BlockStates(IDs) sind bereits generiert, es werden nurnoch zu allen BlockStates ein Cache erstellt, wo die Hitbox der Wall zu dem BlockState gecached wird.
Das macht das mmn. so unproblematisch.
Habs auch schon laufen lassen, Welt von einem Vanilla Server auf den Gepachten, lief wie ne eins.
@ -0,0 +9880,4 @@
list.add(stateHolderx);
- stateHolder.populateNeighbours(table, table.put(immutableMap, stateHolder));
+ int index = table.put(reference2ObjectArrayMap, stateHolderx);
Auch hier: Aufgeteilt auf die beiden Patches... Why?
@ -0,0 +9885,4 @@
+ stateHolderx.populateNeighbours(table, index);
});
this.states = ImmutableList.copyOf(list);
Mir fehlt hier noch der ausgebaute vorgecachte CraftBlockData.stringDataCache. Gibts den nicht mehr?
Nachdem ich das gerade nicht ganz auf dem klassischen Wege hinbekomme:
Der Tick Freeze und TPS-Warp Patch sind nicht mehr nötig. Von Vanilla gibt es jetzt einen TickrateManager, mit welchem man das alles machen kann.
Die anderen Patches wurden auch schon von Paper umgesetzt, also auch keinen Grund die wieder rein zu mergen.
Pull-Request geschlossen