Networking #2
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
3 Beteiligte
Nachrichten
Fällig am
Kein Fälligkeitsdatum gesetzt.
Abhängig von
#1 Add CommandFramework (needs Message System for completion)?
SteamWar/CommonCore
Referenz: SteamWar/CommonCore#2
Laden…
In neuem Issue referenzieren
Einen Benutzer sperren
Keine Beschreibung angegeben.
Branch "network" 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?
Also, ich weiß jetzt noch nicht, warum das ganze auf dem CommandFramework aufbauen muss, das würde ich mir einmal auf Normalbranch, damit das einfach besser überprüfbar ist, wünschen.
Die Unterscheidung, in welche Richtung das Packet geht finde ich vollkommen überflüssig, das kann raus.
Ebenso bin ich noch nicht von den Handlern begeistert, da es ja eine Funktion geben muss, welche die Pakete deserialisiert (bzw. das aufruft) und dann einen Handler übergibt (also wahrscheinlich sich selbst)! Da fände ich es deutlich eleganter, wenn es einfach einen Handler gibt, welcher eine Map<Class<? extends Packet>, Consumer<? extends Packet>> hat. Du muss ja auch bedenken, dass auf Spigot-Seite nicht nur der SpigotCore Handler registriert, sondern z.B. auch das LobbySystem (FightInfoPacket). Das sehe ich mit deiner derzeitigen Architektur als nicht möglich an.
Das geht nicht so einfach, weil ich noch ein wenig für den CommonCore noch eingestellt habe, worauf chaos hier dependet d.h. CommandFramework erst mergen dann den hier.
Evtl. noch eine SteamWarCI für die Tests?
@ -0,0 +23,4 @@
import java.io.*;
@EqualsAndHashCode
Brauchts das ganze EqualsAndHashCode-Zeug tatsächlich?
wegen den Tests
@ -0,0 +32,4 @@
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(this);
oos.flush();
} catch (Exception e) {
Wären das nicht nur IOExceptions? Ansonsten gäbe es ja auch die ExceptionA | ExceptionB -Syntax.
@ -0,0 +47,4 @@
try {
ObjectInputStream ois = new ObjectInputStream(bais);
return (NetworkPacket) ois.readObject();
} catch (Exception e) {
siehe oben.
@ -0,0 +27,4 @@
@AllArgsConstructor
@EqualsAndHashCode(callSuper = true)
@Getter
public class InventoryCallbackPacket extends NetworkPacket {
Überlegung (nichts für diesen PR, aber potentiell etwas für einen NachfolgePR): CommonGUI?
Möglich, kann ich mich hiernach mal dran setzen
@ -0,0 +35,4 @@
private byte win;
private int blueSchem;
private int redSchem;
private List<Integer> bluePlayers;
Sind ArrayLists Serializable? Ansonsten müsste es auch mit int[] gehen...
ja
@ -0,0 +43,4 @@
private int redLeader;
private int blueSchem;
private int redSchem;
private List<Integer> bluePlayers;
Selbe Frage hier.
@ -0,0 +37,4 @@
private String title;
private int player;
private int size;
private Map<Integer, String> items;
Serializable?
Ja