Seite 1 von 1

PlayerList - Eine "bessere" List<Player>

BeitragVerfasst: Mo 4. Aug 2014, 12:56
von Jofkos
Ich denke mal, jeder von euch kennt das lästige Problem, dass man keine Player-Instanzen in einer Liste speichern sollte, und daher immer wieder Bukkit.getPlayer(String name) aufrufen muss.
Nun, ich fand das auch nicht praktisch, und habe mir daher eine kleine Klasse geschrieben, die das Problem behebt:
Es werden keine Spieler-Instanzen gespeichert, trotzdem kann man diese übergeben, und man kann die Spieler durchiterieren (for-each-Schleife)

Die Klasse gibt es hier:
- GitHub
- DropBox

Anwendungsbeispiele:
Code: Alles auswählen
  1.    public void example() {
  2.       PlayerList list = new PlayerList(); // neue Instanz
  3.       list.addAll(Bukkit.getOnlinePlayers()); // ein Spieler-Array/Liste hinzufügen
  4.       list.add(Bukkit.getPlayer("Random")); // einen einzelnen Spieler hinzufügen
  5.       
  6.       for (Player p : list) { // durch die Liste durchiterieren mithilfe eine for-each-Schleife
  7.          p.sendMessage("Dies ist eine Nachricht.");
  8.       }
  9.    }

Die Liste macht eigentlich nichts anderes, als das player.getName() und Bukkit.getPlayer(name) für euch zu übernehmen!
Ich hoffe der eine oder andere kann etwas mit dieser Liste Anfangen ;)
Falls ihr irgendwelche bugs findet, meldet sie mir.

Re: PlayerList - Eine "bessere" List<Player>

BeitragVerfasst: Mo 4. Aug 2014, 14:33
von PostCrafter
Ich werde sie vermutlich nicht wirklich brauchen, da ich etwas ähnliches selber habe, aber sie gefällt mir von Idee und Umsetzung sehr gut.

Du könntest die add- und remove-Methode noch insofern ausbauen, dass sie varargs-Argumente annehmen und außerdem jede Methode mit Validate.notNull ausstatten, um nutzerfreundlichere Fehlermeldungen auszugeben.

Re: PlayerList - Eine "bessere" List<Player>

BeitragVerfasst: So 10. Aug 2014, 23:26
von Howaner
Also so eine Klasse zu benutzen ist 1.000 mal schlechter als einfach das Player Object zu speichern.
Was soll daran schlimm sein?

Das einzige, dass man nicht vergessen darf, ist das Player Object aus der Map zu löschen, wenn der Spieler leftet.
Es braucht sogar weniger Ram, das Player Object zu speichern.
Wenn du C++ kennst, weißt du, dass in der Map die Koordinaten zum Platz im Arbeitsspeicher gespeichert werden. (Den Pointer)

Re: PlayerList - Eine "bessere" List<Player>

BeitragVerfasst: Mo 11. Aug 2014, 09:20
von IK_Raptor
Ich verstehe irgendwie nicht warum ein Player Objekt weniger RAM brauchen sollte als ein String...

Mit c++ kenne ich mich aber auch nicht aus. :(

Re: PlayerList - Eine "bessere" List<Player>

BeitragVerfasst: Mo 11. Aug 2014, 15:30
von Jofkos
Howaner hat geschrieben:Also so eine Klasse zu benutzen ist 1.000 mal schlechter als einfach das Player Object zu speichern.
Tut mir Leid, aber das stimmt nicht. Sie gibt dir die Spieler Instanz zu einem String zurück. Was ist daran "1'000 mal Schlechter"?
Howaner hat geschrieben:Was soll daran schlimm sein?
Du nimmst weiter unten bezug auf c++. Java ist nun mal nicht c++, und Java hat Probleme damit Instanzen (aus dem RAM) zu löschen, die Player-Instanzen speichern macht es nochmals ein Stück schwieriger.
Howaner hat geschrieben:Wenn du C++ kennst, weißt du, dass in der Map die Koordinaten zum Platz im Arbeitsspeicher gespeichert werden. (Den Pointer)
Dass hat nichts mit C++ zu tun, aber ja, dass hast du richtig erkannt, so funktioniert Random Access Memory.

Im Grunde hast du aber Recht, es ist zwar nicht "1000 mal Schlechter", aber es werden jedesmal alle Spieler durchgeloopt, um an die Instanz hinter dem Namen zu kommen.
Ich werden den Post nochmals umschreiben

IK_Raptor hat geschrieben:Ich verstehe irgendwie nicht warum ein Player Objekt weniger RAM brauchen sollte als ein String...

Mit c++ kenne ich mich aber auch nicht aus. :(
Er meint damit, dass das Player-Object sowieso schon gespeichert wird, und in der liste quasi nur der "link" zu dem PlayerObject gespeichert wird ;)

Re: PlayerList - Eine "bessere" List<Player>

BeitragVerfasst: Mo 1. Aug 2016, 13:39
von Flaflo
Howaner hat geschrieben:Also so eine Klasse zu benutzen ist 1.000 mal schlechter als einfach das Player Object zu speichern.
Was soll daran schlimm sein?

Das einzige, dass man nicht vergessen darf, ist das Player Object aus der Map zu löschen, wenn der Spieler leftet.
Es braucht sogar weniger Ram, das Player Object zu speichern.
Wenn du C++ kennst, weißt du, dass in der Map die Koordinaten zum Platz im Arbeitsspeicher gespeichert werden. (Den Pointer)


Vollkommen richtig, das hatte ich mir auch gedacht, als ich das las, denn jeder der sich ein bisschen mit java/c++ befasst hat weiß, das objektinstanzen die gleichem ursprung sind, gleich sind, da der pointer auf die selbe adresse im speicher zeigt also z.b.

final ArrayList<Player> playerArray = new ArrayList<>();
final Player player = Bukkit.getPlayer("Faggot");
playerArray.add(player);

final Player player2 = Bukkit.getPlayer("Faggot");
final Player arrayPlayer = playerArray.get(0);

hier ist dann player2 gleich der spieler arrayPlayer


Und da java eine tolle sprache ist, kann man eigentlich sehr viel darin schlampen, ohne das man einen sehr großen performance verlust macht (heil garbage collector)