SteamWar/BungeeCore
Archiviert
13
2

Packet System + Bungee GUI #111

Manuell gemergt
YoyoNow hat 12 Commits von packet-system nach master 2020-09-26 09:21:46 +02:00 zusammengeführt
Besitzer

TODO: Add License + Remove Test Command + Remove Hardcoded Config
Closes: #64
Closes: #112

TODO: Add License + Remove Test Command + Remove Hardcoded Config Closes: #64 Closes: #112
Lixfel hat 2020-09-21 08:57:19 +02:00 Änderungen angefragt
@ -39,6 +41,7 @@ import net.md_5.bungee.api.plugin.Plugin;
import net.md_5.bungee.config.Configuration;
import net.md_5.bungee.config.ConfigurationProvider;
import net.md_5.bungee.config.YamlConfiguration;
import org.yaml.snakeyaml.error.YAMLException;
Besitzer

Woher kommen die neuen Imports? Ich sehe keine Codestelle, die diese Imports neuerdings benötigt :)

Woher kommen die neuen Imports? Ich sehe keine Codestelle, die diese Imports neuerdings benötigt :)
@ -234,2 +231,2 @@
subserver.stop();
break;
SWInventory inventory = new SWInventory(p, 9, "§eDelete Confirm");
inventory.addItem(1, new SWItem(1, "§cDecline", 1), click -> {
Besitzer

Noch sind wir nicht multilingual, und den Knopf "Abbrechen" bitte auf Position 9 packen, dass Abbrechen ganz rechts ist, und "Löschen" links ist.

Noch sind wir nicht multilingual, und den Knopf "Abbrechen" bitte auf Position 9 packen, dass Abbrechen ganz rechts ist, und "Löschen" links ist.
@ -0,0 +47,4 @@
}
public static void registerHandler(String name, SpigotHandler handler) {
handlerMap.put(name.hashCode(), handler);
Besitzer

Ich weiß nicht, ob ich die HashCode-Variante so viel besser finde, da könnte es zu Kollisionen kommt. Was spricht denn dagegen, jedem Pakettyp von Hand eine Zahl zuzuordnen?

Ich weiß nicht, ob ich die HashCode-Variante so viel besser finde, da könnte es zu Kollisionen kommt. Was spricht denn dagegen, jedem Pakettyp von Hand eine Zahl zuzuordnen?
@ -0,0 +33,4 @@
String title;
int player;
int size;
Besitzer

Die Drei Attribute könnten final sein.

Die Drei Attribute könnten final sein.
@ -0,0 +17,4 @@
along with this program. If not, see <https://www.gnu.org/licenses/>.
*/
package de.steamwar.bungeecore.comms.packets.inventory;
Besitzer

Jetzt werden die Paketverschachtelungen aber langsam wirklich deep. Evtl. einfach im Paket de.steamwar.bungeecore.inventory?

Jetzt werden die Paketverschachtelungen aber langsam wirklich deep. Evtl. einfach im Paket de.steamwar.bungeecore.inventory?
@ -0,0 +92,4 @@
public void handleClose() {
if(close != null)
close.clicked(null);
Besitzer

Danach müsstest du noch das Inventar aus der InventarMap löschen (ansonsten sammeln sich da nur die Inventare an).

Danach müsstest du noch das Inventar aus der InventarMap löschen (ansonsten sammeln sich da nur die Inventare an).
@ -0,0 +104,4 @@
}
public void close() {
new CloseInventoryPacket().setPlayer(player).send(player);
Besitzer

Auch hier müsste noch aufgeräumt werden

Auch hier müsste noch aufgeräumt werden
@ -109,1 +126,4 @@
public String getSchemItem() {
try {
ResultSet set = SQL.select("SELECT Item WHERE SchemID = ? AND SchemOwner = ?", schemID, schemOwner);
Besitzer

SchemID reicht, SchemOwner ist unnötig

SchemID reicht, SchemOwner ist unnötig
@ -110,0 +129,4 @@
ResultSet set = SQL.select("SELECT Item WHERE SchemID = ? AND SchemOwner = ?", schemID, schemOwner);
return set.getString("Item");
} catch (SQLException throwables) {
return "CAULDRON_ITEM";
Besitzer

Wenn hier eine Exception auftritt, solltest du die Exception loggen und nicht mit der normalen Codeexecution fortfahren (SecurityException werfen)

Wenn hier eine Exception auftritt, solltest du die Exception loggen und nicht mit der normalen Codeexecution fortfahren (SecurityException werfen)
Chaoscaot hat den Titel von WIP: Packet System + Bungee GUI zu Packet System + Bungee GUI 2020-09-22 18:31:15 +02:00 geändert
Lixfel hat 2020-09-24 10:50:01 +02:00 Änderungen angefragt
Lixfel hat einen Kommentar hinterlassen
Besitzer

Evtl. sollte man darüber nachdenken, die einzelnen Packets nicht als Objekte, sondern (static) Funktionen anzusehen, da sie eigentlich immer erstellt und sofort wieder verworfen werden. Klar ist das die saubere "Objektorientierte" Lösung, aber dafür freut das den Garbage Collector überhaupt nicht.

Evtl. sollte man darüber nachdenken, die einzelnen Packets nicht als Objekte, sondern (static) Funktionen anzusehen, da sie eigentlich immer erstellt und sofort wieder verworfen werden. Klar ist das die saubere "Objektorientierte" Lösung, aber dafür freut das den Garbage Collector überhaupt nicht.
@ -233,3 +231,1 @@
if (subserver.getType() == Servertype.BAUSERVER && ((Bauserver) subserver).getOwner().equals(p.getUniqueId())) {
subserver.stop();
break;
SWInventory inventory = new SWInventory(p, 9, "§e/Bau delete Bestätigen");
Besitzer

"Wirklich Welt löschen?" fände ich besser.

"Wirklich Welt löschen?" fände ich besser.
@ -234,2 +231,2 @@
subserver.stop();
break;
SWInventory inventory = new SWInventory(p, 9, "§e/Bau delete Bestätigen");
inventory.addItem(0, new SWItem(0, "§cAbbrechen", 1), click -> {
Besitzer

Bitte Abbrechen auf Position 8 und Löschen auf Position 1 (Das eine möchtest du machen, das andere ist optional). Löschen sollte grün sein und abbrechen rot oder alternativ Löschen rot und Abbrechen hellgrau. (Weiß nicht die Farbcodes auswendig, ob die so passend sind.

Bitte Abbrechen auf Position 8 und Löschen auf Position 1 (Das eine möchtest du machen, das andere ist optional). Löschen sollte grün sein und abbrechen rot oder alternativ Löschen rot und Abbrechen hellgrau. (Weiß nicht die Farbcodes auswendig, ob die so passend sind.
@ -252,3 +258,1 @@
del(directory);
});
}
File directory = new File(BungeeCore.WORLD_FOLDER + p.getUniqueId().toString());
Besitzer

Evtl. kann man hier den Code so refactoren, dass nur die Zeile hier 2* abgewandelt vorkommt und der Rest nur einmal ausgeführt wird. Dann haben wir weniger Codedopplung (ich weiß, ich habe den Code mit der Codedopplung so entwickelt, aber das sollte man ja nicht weiter fördern :).

Evtl. kann man hier den Code so refactoren, dass nur die Zeile hier 2* abgewandelt vorkommt und der Rest nur einmal ausgeführt wird. Dann haben wir weniger Codedopplung (ich weiß, ich habe den Code mit der Codedopplung so entwickelt, aber das sollte man ja nicht weiter fördern :).
@ -0,0 +45,4 @@
inventoryHashMap.get(owner.getId()).handleClose();
return;
}
inventoryHashMap.get(owner.getId()).setNext(true);
Besitzer

Was macht denn dieses Next?

Was macht denn dieses Next?
Autor
Besitzer

Dies ist weil aus irgendwelchen gründen beim öffnen des Inventares ein Close Packet geschiekt wird und mir das meine Hashmap zerhaut. Deshalb dieser flag, dass das Inventar erst beim zweiten aus der Map entfernt wird.

Dies ist weil aus irgendwelchen gründen beim öffnen des Inventares ein Close Packet geschiekt wird und mir das meine Hashmap zerhaut. Deshalb dieser flag, dass das Inventar erst beim zweiten aus der Map entfernt wird.
@ -0,0 +37,4 @@
final int size;
final HashMap<Integer, SWItem> items;
public InventoryPacket(int size, String title, ProxiedPlayer player) {
Besitzer

Wäre es nicht ggf. schlauer, das InventoryPacket mit einem SWInventory zu initialisieren, dann hättest du alle Parameter, auch die items für das senden und müsstest da nicht eine neue HashMap füllen.

Wäre es nicht ggf. schlauer, das InventoryPacket mit einem SWInventory zu initialisieren, dann hättest du alle Parameter, auch die items für das senden und müsstest da nicht eine neue HashMap füllen.
@ -107,6 +124,15 @@ public class Schematic {
return schemType;
}
public String getSchemItem() {
Besitzer

Das Item sollte man direkt in der Schematic mit abspeichern (es wird ja auch glaube ich mit SELECTed, zumindest in der Selection, die du hinzugefügt hast). Ansonsten steigert das die Anzahl der SQL-Requests doch erheblich. Also bitte in Schematic.item hinzufügen.

Das Item sollte man direkt in der Schematic mit abspeichern (es wird ja auch glaube ich mit SELECTed, zumindest in der Selection, die du hinzugefügt hast). Ansonsten steigert das die Anzahl der SQL-Requests doch erheblich. Also bitte in Schematic.item hinzufügen.
Lixfel hat die Änderungen 2020-09-25 09:23:52 +02:00 genehmigt
YoyoNow hat diesen Pull-Request 2020-09-26 09:21:46 +02:00 geschlossen
Lixfel löschte die Branch packet-system 2020-09-26 11:44:50 +02:00
Dieses Repo ist archiviert. Du kannst Pull-Requests nicht kommentieren.
Keine Beschreibung angegeben.