PacketPlayInSettings PlayerJoinEvent

  • Moin,


    Arbeite aktuell an einer Bibliothek die mir auch Nachrichten in mehreren Sprachen basierend auf der Client sprache holen und ausgeben kann. Problem ist, dass das Paket welches die Clientsprache an den Server sendet, kommt erst nach dem JoinEvent. Aktuell habe ich deswegen folgendes:


    Ich mag das persönlich mit den ganzen consumern nicht, da das schnell in verschachtelung resultieren kann. Ich weiß aber nicht, wie ich das so umsetzen kann, dass das ganze System noch einfach als Bibliothek nutzbar ist. Somit möchte ich ungern auf das Player JoinEvent verzichten. Keine Ahnung ob man das irgendwie cool umsetzen kann, dass das PlayerJoinEvent verzögert wird, sobald die locale da ist oder so. Keine Ahnung wie man das am besten machen kann.

  • Also ich finde das jetzt nicht soo kritisch. Du musst eventuell ein bisschen auf Nebenläufigkeit achten (wenn du dabei noch Anstöße / Ideen brauchst, gerne nochmal nachfragen) aber ansonsten ist der Ansatz eigentlich ok.

    Was ich ändern würde: Benutz nicht den consumer als Key in einer Map. Speicher diese Callbacks lieber in einer Liste, das ist intuitiver und ist weniger Fehleranfällig.

  • Naja, ich möchte das ganze gerne synchron machen, gehen wir davon aus, dass ich ein Inventar mit Items erstellen möchte. Das endet ja in zig tausend consumern und sieht einfach nicht gut aus imo. Deswegen möchte ich gerne, dass das JoinEvent erst gecallt wird, wenn die richtige locale da ist.

  • Für einen eigenen Server und darauf zugeschnittene Software wäre das denkbar, dass du dass PlayerJoinEvent einfach verzögerst, aber du möchtest hier ja eine API schreiben.


    Ich muss sagen ich bin mir nicht mehr ganz sicher, wie wir dir weiter helfen können, wobei genau brauchst du Hilfe? Du hast ja schon eine Architektur entwickelt, die funktioniert. Wenn sie dir nicht gefällt, musst du dir eine neue Überlegen. Denkbar wäre bspw. eine Methode #getMesssage : String die einfach eine Exception erzeugt, wenn die Local noch nicht gesetzt ist. Dann muss der Anwender selber zu sehen, dass er keinen Mist baut.

  • Mir geht's prinzipiell darum, dass er im JoinEvent einfach alles machen kann was er will, zB Scoreboards erstellen, Nachrichten senden, Items mit Namen geben. Und nicht, dass er dafür ein neues Event nutzen muss, finde ich von der Usability nicht allzu geil. Aber naja, wenn es soweit kommt

  • Für bekannte Spieler kannst du die letzte Sprache ja einfach abspeichern, wenn du das nicht eh schon machst, und dann für die Zeit nach dem JoinEvent nutzen bis auf eine Änderung überprüft wurde.


    Bei neuen Spielern wäre es eine Möglichkeit nach dem Joinen einfach eine Standardsprache z.B. Englisch zu setzen und dann sobald die Clientsprache bekannt ist im Chat vom User bestätigen zu lassen, ob die Sprache auf Clientsprache gesetzt werden soll oder ob die Standardsprache behalten werden soll. Ich würde generell auch in Betracht ziehen, dass User evtl. manuell die Sprache ändern möchten.


    API-technisch würde ich das auch nicht mit nem Consumer stehen lassen, finde ich designtechnisch u.a. aus von dir bereits genannten Gründen nicht ansprechend.

    Du könntest einfach die getMessage Methode synchron gestalten und bei nicht vorhandener Sprache/nicht vorhandenem Key null returnen / es mit einem Optional lösen, bzw. auch eine getOrDefault Methode einführen die bei nicht vorhandener Sprache in Standardsprache übersetzt.

    Und wie gesagt die gesetzte Sprache in ner DB zwischenspeichern.

  • Noch eine Idee: was spricht denn dagegen, einfach ein neues Event einzuführen, das immer dann gefeuert wird, wenn das JoinEvent gefeuert wurde und die die Einstellungen übermittelt wurden? Davor ggf. noch wieder in den Main-Thread mit BukkitScheduler#runTask(...) eintreten, dann kann muss man sich auch um Parallelität keine Sorgen machen.

    In dem Event kann man dann alles ganz normal machen wie du es im JoinEvent machen willst. Das wäre so das idiomatischste, was mir einfällt.

    MfG


    00110101 00110001 00110101 00111000 00110100 00110110 00110011 00110001 00110101 00111001 00110101 00110111 00110100 00110110 00110011 00110000 00110110 00110001 00110101 00110111 00110100 01000100 00110011 01000100 8o