Packet System + Bungee GUI #59
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
Niemand zuständig
2 Beteiligte
Fällig am
Kein Fälligkeitsdatum gesetzt.
Abhängigkeiten
Keine Abhängigkeiten gesetzt.
Referenz: SteamWar/SpigotCore#59
Laden…
In neuem Issue referenzieren
Einen Benutzer sperren
Keine Beschreibung angegeben.
Branch "packet-system" 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?
TODO: Add License
@ -0,0 +1,10 @@
package de.steamwar.coms.receiver;
Üblicherweise kürzt man comms mit doppel-m ab
@ -0,0 +2,4 @@
import com.google.common.io.ByteArrayDataInput;
public abstract class Handler {
Handler ist doch etwas arg generisch. Vllt. den Verwendungszweck des Handlers beschreiben.
@ -0,0 +1,33 @@
package de.steamwar.coms.receiver;
Ist das System so groß, dass es auch noch Untermodule benötigt?
@ -0,0 +11,4 @@
import java.util.HashMap;
import java.util.Map;
public class PacketHandler implements PluginMessageListener {
Auch PacketHandler zu generisch.
@ -0,0 +16,4 @@
private static Map<String, Handler> handlerMap = new HashMap<>();
public static void registerHandler(Handler handler) {
handlerMap.put(handler.getName(), handler);
So wie ich das sehe, ist das der einzige Fall, wo .getName() benötigt wird. Evtl. stattdessen eine Zahl als Identifier und Runnable hernehmen, dann müsste man nur eine Funktion übergeben und nicht (unbedingt) für jede Funktionalität eine neue Klasse aufmachen.
@ -0,0 +15,4 @@
@Override
public void handle(ByteArrayDataInput byteArrayDataInput) {
Player player = Bukkit.getPlayer(UUID.fromString(byteArrayDataInput.readUTF()));
Überlegung: Statt String für den Spieler die SteamWarUser-id?
@ -0,0 +28,4 @@
int length = byteArrayDataInput.readInt();
Map<Integer, SWItem> items = new HashMap<>();
for (int i = 0; i < length; i++) {
JsonObject object = new JsonParser().parse(byteArrayDataInput.readUTF()).getAsJsonObject();
Wenn wir hier schon JSON verwenden, könnte man nicht stattdessen das gesamte Paket als JSON übertragen? (Oder das ganze Protokoll als JSON aufbauen?). Dann sparst du dir length, weil das einfach eine JSON-Liste ist.
@ -0,0 +36,4 @@
}
if(object.has("enchanted"))
item.setEnchanted(true);
if(object.has("hideAttributes"))
Ich glaube, die Verzauberungen verstecken wir immer.
@ -0,0 +9,4 @@
import java.util.UUID;
public class PingHandler extends Handler {
Wozu ist das nötig?
Dass bei @Player ein kleiner Ton kommt.
@ -0,0 +5,4 @@
import java.io.Serializable;
public abstract class Packet implements Serializable {
Packet. Auch wieder sehr generisch.
@ -0,0 +7,4 @@
public class PacketSender {
public static void sendPacket(Packet packet, Player player) {
Die Funktion würde ich eher in Packet integrieren, dafür braucht es nicht eine extra Klasse.
@ -62,2 +63,4 @@
if(version >= 12)
ErrorLogger.init();
getServer().getMessenger().registerIncomingPluginChannel(this, "sw:bridge", new PacketHandler());
getServer().getMessenger().registerOutgoingPluginChannel(this, "sw:return");
Wozu braucht es den Channel?
@ -138,3 +140,3 @@
}
private void hideAttributes() {
public void hideAttributes() {
Üblicherweise hiden wir immer, daher kann das glaube ich private bleiben
@ -194,2 +196,4 @@
itemStack.setItemMeta(itemMeta);
}
public String parseToJson(int position) {
Ich glaube, wir müssen den Bungee nicht das ganze Objekt zurückschicken, er wird ja auch angeordnet haben, was da angezeigt werden soll.
WIP: Packet System + Bungee GUIzu Packet System + Bungee GUIAuch hier sehe ich (wie auch beim BungeeCore), dass die Paket-Objekte vom Typ "Fire-And-Forget" sind. Auch da wäre die Umsetzung als static-Methoden Garbage-Collector freundlicher (ist aber auch so vollkommen in Ordnung und Objektorientiert sauber, musst du entscheiden, ob du dass so lassen willst oder umarbeiten willst.
@ -0,0 +1,11 @@
package de.steamwar.comms;
Lizenzheader fehlt.
@ -0,0 +47,4 @@
JsonObject itemJson = array.get(i).getAsJsonObject();
SWItem item = null;
try {
item = new SWItem(Material.valueOf(itemJson.get("material").getAsString()), itemJson.get("title").getAsString());
Evtl. einfach einen neuen SWItem-Konstruktor erstellen, der als einziges Argument ein JsonObject nimmt und dann sich die Parameter aus dem JsonObject entnimmt? Das wäre meiner Meinung nach eine elegantere Lösung.
@ -0,0 +69,4 @@
item.setCallback(click -> {
new InventoryCallbackPacket().setPosition(itemJson.get("position").getAsInt()).setClick(click)
.setCallback(InventoryCallbackPacket.CallbackType.CLICK)
.setOwner(SteamwarUser.get(player).getId()).send(Bukkit.getPlayer(player));
Der Aufruf ist doch etwas aufwändig. Evtl. wäre es sinnvoller, auch da als Parameter einfach das itemJson im Konstruktor zu übergeben, oder das SWItem selbst (in Verbindung mit dem vorhergehenden Vorschlag)
@ -26,3 +25,4 @@
import java.sql.SQLException;
import java.time.Instant;
import javax.xml.bind.DatatypeConverter;
Nenene, keinen DatatypeConverter bitte mehr! (einfach mal bitte den neuen master reinmergen)
I changed my Mind: Lass die Packets bitte als Objekte, denn dann haben wir da eine einfachere Erweiterungsmöglichkeit in anderen Systemen.