Spigot "Bungee-Join-Schilder" - Wie?

[Sprax2013]

Hallo Leute!

Ich baue aktuell mit einem Team ein Minecraft-Netzwerk auf und wir haben nur 2 Devs (einer davon bin ich :c).

Jedenfall weiß ich Aktuell nicht, wie ich die JoinSchilder in der Lobby regeln soll. Wir haben nicht so viele Server wie Gomme. Heißt, wenn ein Server voll ist steht auf dem Schild "InGame" oder "Voll".

Ich wollte fragen ob ihr eine Idee habt, wie ich das regeln kann mit möglichst wenig (unnötigen) Traffic.
Ich muss von einem (z.B QSG-) Server Informationen holen wie z.B Status (Lobby, InGame, DeathMatch), Lebende Spieler und Maximale Spieler (Abhängig von der Map).

Ich hoffe ich finde hier ein paar Devs, die evtl. erfahrung mit so etwas haben oder zumindest eine Idee

LG Sprax2013

 

[Sceptix]

wenn ein server ingame / voll ist einfach nicht mehr abfragen
wenn nicht jede sekunden von jedem server nur die spieleranzahl, den rest (map, maximale spieler) schiebst du in eine variable
dann hast du noch einen listener für die lobby
ein server kann da ein stück information (server id) hinschicken und die lobby weiss das bei dem schild, wo normalerweise der server mit der serverid im packet ist, jetzt den status "Restarting" hat. wenn er fertig ist schickt er nochmals ein packet, wieder mit der server-id, und jetzt weiss die lobby, dass man da joinen kann

die serverid kannst du so implementieren:
jeder gameserver hat ein plugin was für das restarten, map resetten und spieler aufnehmen da ist. beim serverstart schaut es im config ordner nach einer id.txt, und darin steht halt die server id. zum beispiel 1.
das packt das plugin in eine variable, wenn es das packet schicken muss, fügt es die einfach hinzu.

 

[Sprax2013]

Danke schon ein mal für deine Antwort:
Das Konzept gefällt mir schon ein mal! Der Traffic wird auf das nötigste minimiert. Ich habe aber ein ForceMap Feature. Aber dann sende ich halt erneut Map+MaxPlayers.

Aber dann kommt jetzt mein Problem: Wie sende ich von Server (ID1 zur Lobby?
PluginMessangerChannel sind da denke ich weniger geeignet für, oder? Ich habe einen Root zur Verfügung, daher sollten sich ja bessere Möglichkeiten bieten.

LG Sprax2013

 

[Sceptix]

google mal java sockets

 

[lukas81298]

Am besten schreibst du dir ein standalone Programm (wenn du nur eine Proxy/Bungee Instanz hast geht auch ein Bungeecord Plugin) das einen Netty Server Socket startet mit dem sich deine SG und Lobby Server verbinden. Dann kannst du wenn sich auf dem SG Server irgendwas ändern (Spieler Zahl, Map, etc...) an diesen Service senden und dort cachen. Diese Daten werden dann an die Lobbies geforwarded und wenn eine neue Lobby startet an auch an diese gesendet. Das wäre so die effizienteste und skalierbarste Lösung.

 

[Sprax2013]

Am besten schreibst du dir ein standalone Programm (wenn du nur eine Proxy/Bungee Instanz hast geht auch ein Bungeecord Plugin) das einen Netty Server Socket startet mit dem sich deine SG und Lobby Server verbinden. Dann kannst du wenn sich auf dem SG Server irgendwas ändern (Spieler Zahl, Map, etc...) an diesen Service senden und dort cachen. Diese Daten werden dann an die Lobbies geforwarded und wenn eine neue Lobby startet an auch an diese gesendet. Das wäre so die effizienteste und skalierbarste Lösung.

Du bist nicht der erste der mit Netty empfiehlt. Und ich muss leider sagen, dass ich selbst nach ein paar Tutorials Netty nicht ganz verstehe... Abgesehen davon, dass ich zum erstenmal versuche Client <-> Server sachen zu schreiben.

Ich hatte vor einiger Zeit per Java-Sockets es so geregelt, das der z.B. QSG-Server an Lobby1 einen String gesendet hat (Immer war alles benötigte dabei nicht nur das neuste, dass sich geändert hatte). Einerseits ist das alles andere als effizient und anderer seits ist das ziehmlich umständlich bei (Aktuell) 3 Lobby-Servern.

Kennst du evtl. ein Tutorial (muss nicht Deutsch sein), dass Netty recht gut erklärt? Ich glaube ich muss nur in der Lage sein Strings an den Server zu senden und der Server muss dann an alle gemeldete Clients (Lobby etc.) den String verteilen. (Später will ich noch, dass Clients den Server anfragen können und unmittelbar eine Antwort erhalten. Aber dass ist optional)