(legacy TechHider); Besser in Zukunft zu TechHider wechseln
Zusammenfassung
Dieser PR ersetzt Netty-Paketfilter wo es geht durch Event-Handler. Überflüssiger Code wurde entfernt und dabei viele Bugs behoben:
SmartPlaceListener platziert Block bei (0,0,0)
Fehler in Slot-Index-Berechnung in NoClipCommand
Blöcke in NoClip Platzieren aktiviert für 1 Tick die Physik -> Man bleibt an Blöcken hängen
Floodfill vei SteamEditWand hat nicht richtig funktioniert
SteamEditWand funktioniert nur, wenn der Spieler bereits eine FAWE-Auswahl hat
SteamEditWand crasht bei FAWE-Kreisauswahl
Falsche Entity ID im TechHider
...
Race Conditions behoben in:
- [x] SmartPlaceListener
- [x] NoClipCommand
- [x] AntiNocom
- [x] CursorListener
- [x] SteamEditWand
- [x] TechHiderWrapper
- [ ] (legacy TechHider); Besser in Zukunft zu TechHider wechseln
# Zusammenfassung
Dieser PR ersetzt Netty-Paketfilter wo es geht durch Event-Handler. Überflüssiger Code wurde entfernt und dabei viele Bugs behoben:
- SmartPlaceListener platziert Block bei (0,0,0)
- Fehler in Slot-Index-Berechnung in NoClipCommand
- Blöcke in NoClip Platzieren aktiviert für 1 Tick die Physik -> Man bleibt an Blöcken hängen
- Floodfill vei SteamEditWand hat nicht richtig funktioniert
- SteamEditWand funktioniert nur, wenn der Spieler bereits eine FAWE-Auswahl hat
- SteamEditWand crasht bei FAWE-Kreisauswahl
- Falsche Entity ID im TechHider
- ...
Diese race condition wird nicht in #517 behoben. Siehe todo: // TODO will require entity tracking on the netty thread to prevent future race conditions
Diese race condition wird nicht in #517 behoben. Siehe todo:
`// TODO will require entity tracking on the netty thread to prevent future race conditions`
PaperMC hat bereits einen robusteren Fix: https://github.com/PaperMC/Paper/blob/4d854e66b80dad9898d71a0f0b1f83cd39b97119/paper-server/patches/sources/net/minecraft/server/network/ServerGamePacketListenerImpl.java.patch#L1155-L1160
Gefühlt würde ich das nochmal drin lassen, weil der Path in paper ist zwar von vor 8 Jahren aber trotzdem ist dieser Bug aufgekommen und war exploitable.
Gefühlt würde ich das nochmal drin lassen, weil der Path in paper ist zwar von vor 8 Jahren aber trotzdem ist dieser Bug aufgekommen und war exploitable.
MAX_CONNECTED_DEPTH ist der maximale Abstand in Blöcken vom Startpunkt. 265 sollte für die meisten Sachen reichen. Das begrenzt den Lag auf gefühlt ~500ms. Für viel größere Bereiche müsste man die Arbeit auf mehrere Ticks aufteilen.
MAX_CONNECTED_DEPTH ist der maximale Abstand in Blöcken vom Startpunkt. 265 sollte für die meisten Sachen reichen. Das begrenzt den Lag auf gefühlt ~500ms. Für viel größere Bereiche müsste man die Arbeit auf mehrere Ticks aufteilen.
500ms an Lag ist eher unangenehm und sollte vermieden werden. Generell versuche ich eigentlich das der Tick nicht länger als 1000/20 dauert also 50ms wobei ich meistens solchen Tool calls maximal 30-40ms pro Tick brauchen dürfen und es sonst auf mehrere Ticks aufgeteilt wird.
500ms an Lag ist eher unangenehm und sollte vermieden werden. Generell versuche ich eigentlich das der Tick nicht länger als 1000/20 dauert also 50ms wobei ich meistens solchen Tool calls maximal 30-40ms pro Tick brauchen dürfen und es sonst auf mehrere Ticks aufgeteilt wird.
Das hier war schon absichtlich so gebaut, sodass der Cursor snappier sich anfühlt. Paper Events sind nicht immer die schnellsten insbesondere beim Movement Packet
Das hier war schon absichtlich so gebaut, sodass der Cursor snappier sich anfühlt. Paper Events sind nicht immer die schnellsten insbesondere beim Movement Packet
Der Cursor wird doch bereits 20 Mal pro Sekunde aktualisiert. Ich habe beide Varianten (mit und ohne PacketFilter) direkt nacheinander getestet und konnte keinen Unterschied feststellen. Außerdem sollte man Cursor::render nicht von Netty aufrufen, weil es sehr rechenintensiv ist und auf die Welt zugreift (z.B. Raytracing).
Der Cursor wird doch bereits 20 Mal pro Sekunde aktualisiert. Ich habe beide Varianten (mit und ohne PacketFilter) direkt nacheinander getestet und konnte keinen Unterschied feststellen. Außerdem sollte man Cursor::render nicht von Netty aufrufen, weil es sehr rechenintensiv ist und auf die Welt zugreift (z.B. Raytracing).
ConnectedSearch.java ist von Claude und ungefähr 20x schneller als der alte Algorithmus: ~10ms für ein Warship. Würde auch ohne funktionieren aber dann ist die Nutzererfahrung deutlich schlechter.
ConnectedSearch.java ist von Claude und ungefähr 20x schneller als der alte Algorithmus: ~10ms für ein Warship. Würde auch ohne funktionieren aber dann ist die Nutzererfahrung deutlich schlechter.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Race Conditions behoben in:
Zusammenfassung
Dieser PR ersetzt Netty-Paketfilter wo es geht durch Event-Handler. Überflüssiger Code wurde entfernt und dabei viele Bugs behoben:
e1a75402actof92ff2177b9b4340895atodf52ed2f37Wie sieht es bei diesem PR aus? Der build failed noch in der pipeline?
Könntest du zudem auf main Rebasen, sodass hier die neuen Änderungen aus main drin sind/angepasst ist darauf.
Kleiner Tipp fürs nächste mal, mach aus solchen Refactors einzelne PRs, welche dadurch viel kleiner und einfacher zu durchblicken sind.
@@ -47,4 +47,4 @@import java.util.stream.Collectors;@Linkedpublic class SmartPlaceListener implements Listener {Den Diff der Klasse durchblicke ich aktuell noch nicht. Das muss ich mir glaube mal genauer anschauen.
Habe aus dem PacketFilter einen EventHandler gemacht und die Lookups (CONTAINERS + IGNORED) vereinfacht.
Alles klar ok.
@@ -98,9 +99,13 @@ public class Hull {return players.contains(player) && region.inRegion(location) && !visibility.get(new IntVector(location).toId(region));}public boolean isEntityHidden(Player player, int entityId) {Hier musst du dir mal den HullHider PR anschauen
Diese race condition wird nicht in #517 behoben. Siehe todo:
// TODO will require entity tracking on the netty thread to prevent future race conditions@@ -37,4 +0,0 @@import java.util.concurrent.ConcurrentHashMap;@Linkedpublic class AntiNocom implements Listener {Warum entfernst du diese Klasse?
PaperMC hat bereits einen robusteren Fix: https://github.com/PaperMC/Paper/blob/4d854e66b80dad9898d71a0f0b1f83cd39b97119/paper-server/patches/sources/net/minecraft/server/network/ServerGamePacketListenerImpl.java.patch#L1155-L1160
Gefühlt würde ich das nochmal drin lassen, weil der Path in paper ist zwar von vor 8 Jahren aber trotzdem ist dieser Bug aufgekommen und war exploitable.
@@ -75,3 +73,2 @@private boolean noWand(Player player) {return player.getInventory().getItemInMainHand().getType() != SteamEditWand.MATERIAL;private static final int MAX_CONNECTED_DEPTH = 256;Is that enough to select a whole (M)WG / WS / AS?
MAX_CONNECTED_DEPTH ist der maximale Abstand in Blöcken vom Startpunkt. 265 sollte für die meisten Sachen reichen. Das begrenzt den Lag auf gefühlt ~500ms. Für viel größere Bereiche müsste man die Arbeit auf mehrere Ticks aufteilen.
500ms an Lag ist eher unangenehm und sollte vermieden werden. Generell versuche ich eigentlich das der Tick nicht länger als 1000/20 dauert also 50ms wobei ich meistens solchen Tool calls maximal 30-40ms pro Tick brauchen dürfen und es sonst auf mehrere Ticks aufgeteilt wird.
@@ -26,10 +20,6 @@ public class CursorListener implements Listener {instance = this;}TinyProtocol.instance.addFilter(ServerboundMovePlayerPacket.Pos.class, this::updateCursorFromPacket);Das hier war schon absichtlich so gebaut, sodass der Cursor snappier sich anfühlt. Paper Events sind nicht immer die schnellsten insbesondere beim Movement Packet
Der Cursor wird doch bereits 20 Mal pro Sekunde aktualisiert. Ich habe beide Varianten (mit und ohne PacketFilter) direkt nacheinander getestet und konnte keinen Unterschied feststellen. Außerdem sollte man Cursor::render nicht von Netty aufrufen, weil es sehr rechenintensiv ist und auf die Welt zugreift (z.B. Raytracing).
@@ -203,3 +203,3 @@processors.put(ClientboundAnimatePacket.class, this.buildEntityPacketProcessor(ClientboundAnimatePacket::getId));// 7.1.35 Entity Event: entity id based signal.processors.put(ClientboundEntityEventPacket.class, this.buildEntityPacketProcessor(ClientboundEntityEventPacket::getEventId));processors.put(ClientboundEntityEventPacket.class, this.buildEntityPacketProcessor((ClientboundEntityEventPacket p) -> p.entityId));Den fix gibt es bald schon in main. Siehe HullHider PR
Diese PR ist trotzdem relevant.
1d88d3a8e0to17d56cd0b2Kannst du den PR bitte nochmal Rebasen auf den aktuellen main?
ConnectedSearch.java ist von Claude und ungefähr 20x schneller als der alte Algorithmus: ~10ms für ein Warship. Würde auch ohne funktionieren aber dann ist die Nutzererfahrung deutlich schlechter.
2dedff6442to63b9f4886f