Posts by red51

    Erstmal vielen Dank für das bisherige Feedback :) Offensichtlich ist das Thema keine ganz so einfache Angelegenheit, und beide Ansätzen haben definitiv ihre Vor- und Nachteile.


    Insgesamt schreit es hier auch nach der Möglichkeit der Speicherung von eigenen Formen, es wäre Recht mühsam sich die Daten dann immer über ein Menü für ein simples Dreieck. Solche speicherungen wären aber so oder so sehr positiv.

    Wenn der "Multiblock" Einzug halten sollte, dann wäre es durchaus sinnvoll, dass die zuletzt gewählte Form für einen Stack gespeichert bleibt - damit ich schnell (ohne in irgendwelchen Menüs rumzufummeln) bspw. zwischen Blöcken und Treppen wechseln kann (angenommen ich hätte einen Stack Blöcke und einen Stack Treppen im Inventar).


    So gesehen ist der Multiblock also sehr vergleichbar mit dem klassischen Ansatz (separate Items), lediglich die Herstellung unterscheidet sich.


    Ich denke das ein universelles Bauelement nur was für den creativ Modus wäre

    Im Creative-Modus macht sowas durchaus Sinn, aber mir gehts bei dieser Entscheidung tatsächlich in erster Linie um den Survival-Modus ^^ Wir möchten sicherstellen, dass man auch Survival-Modus tolle Bauwerke erstellen kann.


    Wie soll das den jeweils Schritt für Schritt aussehen ?

    Folgendes Szenario: Ich möchte eine Plattform (aus Blöcken) mit abgeschrägten Ecken bauen, benötige dafür als Blöcke, Rampen und äußere Rampeneckblöcke.


    Variante 1: Klassischer Ansatz wie in Java

    Ich gehe zur Blockbank, suche die gewünschte Textur aus, und crafte die benötigte Anzahl an Blöcken. Dann wähle ich an der Werkbank die Rampe aus, und crafte die benötigte Anzahl an Rampen. Zum Schluss suche ich noch die Rampenecke raus und crafte sie ebenfalls. Habe dann 3 Stacks und verbaue sie. Wenn mir auffällt, dass noch was fehlt, gehe ich wieder zurück zur Blockbank und crafte weitere Elemente


    Variante 2: Multiblock mit änderbarer Form

    Ich gehe zur Blockbank, suche die gewünschte Textur aus, und crafte die insgesamt benötigte Anzahl an Blöcken (wäre dann eher als "Bauelement" zu titulieren). Ich bekomme entsprechend meinen Stack an "Bauelementen". Ich gehe dann zurück zur Baustelle, verbaue die Blöcke, danach wechsel ich die Blöcke (über ein Menü) in Rampen und verbaue die Rampen, zum Schluss wechsel ich die Form in "Rampenecken" und verbaue die Eckstücke. Alternativ: Ich teile meinen Block-Stack anfangs auf 3 Stacks auf und verwandel den 2. Stack direkt in Rampen und den 3. in Rampenblöcke.


    Wie intuitiv wäre denn die eine einzige Version für neue Spieler? Wenn ich mir vorstelle, als absoluter Neuling anzufangen, noch keinen Plan von der Steuerung habe, und mir eine erste kleine Hütte bauen will? Wie leicht oder schwer wäre das dann für mich?

    Das ist etwas schwer zu sagen... möglicherweise werden manche Spieler die Möglichkeit übersehen. Wobei man natürlich dazu sagen muss, dass es auch Spieler gab, die in der Java Version übersehen haben, dass man die Blockform ändern konnte :thinking: Vermutlich nehmen sich da beide Ansätze nicht viel :D Allerdings hätte man bei der Multiblock-Variante eher die Möglichkeit, die Funktion zum Ändern der Form hervorzuheben (wohingegen sowas im Crafting-Menü schneller untergehen könnte).


    Das Ändern an sich hingegen (wenn man die Funktion gefunden hat) wäre allerdings sehr einfach von der Steuerung her.


    Ich habe extreme Probleme mit der Mausrad-Benutzung. Es gibt 2-Tasten Mäuse die das Rad gar nicht haben

    Ich würde da das Mausrad vermutlich nicht bei involvieren. Sinnvoll wäre hier ja eine separate Taste (und optional auch die Möglichkeit, das per Rechtsklick im Inventar zu erledigen) womit ein Radial-Menü oder ein sonstiges Menü (zB wie die Pflanzenauswahl im Creative-Mode der Java Version, wenn man I drückt) aufgeht.


    Ich kann mich auch daran erinnern, dass es Spiele gibt mit einer Inventar Liste wo sich das gewünschte Teil frei wählbar ist. Minecraft Tekkit glaube ich.

    Das müsste ich mir mal genauer ansehen :thinking:


    um formen zu erstellen die es in der Auswahl nicht gibt. Stell mir da so was vor wie ein Hammer oder Säge. wo ich zb ein Brett an einer Kante abschrägen Kann in den Winkel wie ich ihn brauch. und zusätzlich einen Stempel oder oder Stanze wo ich Blöcke mit einen Loch ( egal welche form und Größe) ausstanzen kann

    Also das wäre an sich unabhängig von der Frage, ob Blockformen separate Items sein sollen oder nicht. Die Möglichkeit, dass man eigene, individuelle Blockformen selbst erstellen kann, ist momentan leider erstmal noch nicht vorgesehen. Das wäre zwar ein wirklich tolles Feature, die Umsetzung jedoch mit erheblichem Aufwand verbunden.


    Aber auch wenn vorgesehen sein soll, dass bestehende Formen nachträglich verändert werden können (zB beliebige Teile ausgestanzt werden sollen), würde das einige Probleme nach sich ziehen: Es müssten pro Bauteil deutlich mehr Informationen gespeichert werden, und auch die Generierung von Chunks mit Gebäuden würde länger dauern - besonders angesichts der Tatsache, dass in RW ja schnell mal mehrere Tausend oder gar Hunderttausend Bauteile verbaut werden :wat:


    Wird es die Möglichkeit geben über die Konsole weiterhin seine Rampe, Stairs usw. zu bekommen? Grundform +/- last position) ?

    Ja, wie oben erwähnt, können wir so einen Command auf jeden Fall anbieten :)


    Es wird so viel Wert auf immersion gelegt, mit den ganzen werkbänken, Arbeitsschritten, usw und hier will man einfach im Inventar ohne Werkzeug oder Bank aus einem z. B. Quadratischen Beton block ein Dreieck machen. Ich bin, ehrlich gesagt etwas überrascht von diesem Ansatz. Das macht doch das bauen im survival etwas beliebig.

    Ich kann das Argument auf jeden Fall nachvollziehen, Immersion ist uns auch durchaus wichtig, allerdings möchten wir ja trotzdem manche Dinge nicht unnötig verkomplizieren. Beim Bausystem bin ich ohnehin etwas skeptisch, ob hier wirklich ein hoher Grad an Immersion erreicht wird (auch schon in der Java Version) :thinking: Streng genommen müssten wir ja dann auch verhindern, dass Blöcke skaliert werden können: Der User müsste die gewünschte Größe dann schon im Vorfeld an der Werkbank festlegen. Das wäre deutlich realistischer, aber vmtl. auch ein vielfaches frustrierender und umständlicher =O


    Tatsächlich aber können Blöcke ja jederzeit größer und kleiner skaliert werden - immerhin auch ohne Werkzeug. Ich kann einen Block also während des Bauens durchaus 3x so hoch und nur 5% so dick wie vorher machen. Warum kann ich ihn dann nicht auch abschrägen und zu einer Rampe machen?


    Es gibt aber auch ein weiteres Feature, an welchem wir arbeiten, was mit strikten Trennungen der Blockformen kollidiert: Die Möglichkeit, bei Blöcken bspw. die Oberseite unabhängig von der Unterseite zu bewegen oder zu skalieren. Ich will zu diesem Feature zwar noch nicht zu viel versprechen, aber ich habe von einem derart bearbeiteten Block mal zwei Bilder gemacht:


    Dieses Feature eröffnet völlig neue Baumöglichkeiten. Aber auch das müsste (genau wie die allgemeine Blockgröße) idealerweise jederzeit anpassbar sein, nicht nur an der Werkbank, sonst geht ein großer Teil des Nutzens wieder verloren. Spätestens mit diesem Feature müsste man sich ja berechtigterweise die Frage stellen, warum ich sowas machen könnte (was ja effektiv auch quasi die Form des Blockes ändert), aber nicht zu einer Rampe oder Zylinder wechseln kann :thinking:


    Man könnte vielleicht argumentieren, dass dieses Feature (sowie auch die Größenanpassungen von Blöcken) nur mit einem bestimmten Werkzeug möglich werden, aber dann befürchte ich, dass das ein nicht unwesentlicher Teil der Spieler niemals herausfinden wird und das Bausystem nur zu einem Bruchteil auskostet :(


    Die Sache ist also gar nicht so einfach :D


    ich würde es schön finden wenn die 2 formen auch den weg ins spiel finden würden
    eine kegel und ein halbe kegel

    Das kann ich auf jeden Fall auf die Todo-Liste packen :) Der große Vorteil ist, dass wir in der neuen Version jederzeit neue Blockformen hinzufügen können, ohne, dass alte Welten in Mitleidenschaft gezogen werden.

    Könnte man auch halb kreise machen die von innen leer sind und somit eine regenrinne ensteht, die eventuell auch wirklich funktioniert mit dem kommenden wasser update? and good job looks nice :thumbup:

    Wie Avanar schon sagt, leider wird das Wasser nicht diesen Detailgrad haben beim Fließen :silenced: Aus Performancesicht ist das technisch einfach nicht möglich, zumindest nicht im größeren Maßstab. Richtig physikalisches Wasser, bei welchem quasi jeder Tropfen simuliert wird, ist zwar heutzutage im kleinen Stil bereits möglich (wenn man bspw. ein kleines Becken oder so hat, oder als visueller Effekt beim Auskippen eines Eimers), aber wir müssen bei RW das System ja so auslegen, dass es auch funktioniert, wenn wir einen ganzen See oder komplexe Flüsse oder so haben. Hinzu kommt ja auch die Möglichkeit, dass sich unter einem See bspw. ein komplexes Höhlensystem befinden könnte, welches beim Umgraben des Sees geflutet wird.


    Das nächste Problem wäre hier auch der Multiplayer, denn das Wasser müsste ja korrekt synchronisiert werden (und unabhängig davon auch persistent in der Welt gespeichert werden). Selbst wenn wir relativ große Wassertropfen verwenden (zB mit einem Durchmesser von 5 cm, was für eine Regenrinne wohl schon fast zu groß wäre), würde ein größerer See locker aus Milliarden oder gar Billionen solcher Tropfen bestehen, was beim Synchronisieren und auch beim Abspeichern der Welt - trotz Kompression - schnell in den Terabyte-Bereiche gehen würde :dizzy:

    Wurden hier die Formkosten berücksichtigt? Denn beim universellen Ansatz wäre es ein wenig schade, wenn man einen ganzen Block verbraucht, obwohl man nur z. B. einen Kegel platziert hat. Theoretisch könnte man hier pro Form verschiedene "Kosten" haben, die dann vom Stack abgezogen werden, aber dann wäre eine Stackgröße nicht mehr im natürlichen, sondern im reelen Zahlenbereich.

    Schwierig... wir arbeiten bei den Stacks ja nur mit ganzen Zahlen, da wäre es kompliziert, bspw. nur einen halben Block abzuziehen wenn zB eine Rampe o.ä. platziert wird :thinking: Ich weiß auch nicht, ob es "schön" wäre, wenn Blockstacks alternativ als Kommazahl dargestellt werden: Man hätte zB 100.0 Blöcke in der Hand und nach dem Platzieren wären noch 99.25 Blöcke übrig :wat:


    Das Problem besteht aber mehr oder weniger unabhängig von der Entscheidung, ob es verschiedene Items oder ein universelles Item gibt, denn auch in der Java Version hatten die verschiedenen Blockformen (die ja als separate Items behandelt wurden) ja bereits die gleichen Resourcen gekostet wie der Standard-Block.


    Was man aber evtl. machen könnte wäre groß skalierte Blöcke teurer machen. Sprich wenn ich einen riesigen Block mit der Größe 4x4 platziere, dann würde er 16 Blöcke vom Stack abziehen. In der Java Version gab es da ja ebenfalls keine Berücksichtigung (eine Mini-Planke war genauso teuer wie eine große Planke), und tatsächlich ist die Sache nicht ganz so trivial, da es beim Platzieren für den User ja auch irgendwie ersichtlich sein müsste, wie teuer das ganze wird... wir müssen uns hier mal Gedanken machen :nerd:


    Verschiedene Formen in einem Item kenne ich aus diversen anderen Spielen. Ich habe das immer verflucht, da das Handling meistens sehr seltsam und extrem umständlich war. Raft, Empyrion, Conan glaube ich und gewisse Spiele bei denen irgendein Kreissegment herumgedreht werden muss, um eine Auswahl zu treffen. Sehr umständlich, meiner Meinung nach.

    Am intuitivsten wäre vmtl. tatsächlich ein Radial-Menü (quasi die selbe Art an Menü die wir auch für unsere Türen in der neuen Version verwenden). Optional könnten wir auch zusätzlich einen Command dafür anbieten. Wie gesagt, das Spiel könnte auch die letzte Blockform für den gewählten Stack abspeichern, sodass man es nur 1x ändern muss (pro Stack).


    Aber ist es denn unabhängig davon wirklich einfacher, im Crafting-Menü bis zur entsprechenden Blockform (waren ja zuvor die Pfeile links und rechts neben dem Block) durchzuklicken? Zumal sich manche Formen ja auch teilweise etwas ähneln.

    Und auch beim Einlagern werden die Kisten schnell voll: Ich habe anbei mal ein Bild aus der Java Version von einer Kiste angefügt, in welchem sich fast alle Blockformen in gerade mal 4 verschiedenen Texturen befinden. Obwohl es nur 4 versch. Texturen sind, ist die erste Seite schon voll :thinking: Und dabei fehlten in der Java Version ja noch jede Menge Formen...

    Ist das etwa eine Sternform, bei der man die Zacken (und deren Tiefe) einstellen kann?

    Hehe, naja, dieser Grad an Einstellmöglichkeiten ist momentan leider noch nicht drin :saint: Man kann Elemente zwar wie auch in der Java Version in alle Richtungen vergrößern oder verkleinern, aber nicht direkt ihre Struktur ändern (also bspw. nur einzelne Teile des Elements skalieren).

    Wie auf dem Bild zu sehen wird es ja bspw. auch "hohle Zylinder" (passend für Röhren) geben, aber es gibt leider noch keinen Weg, die Wandstärke zu ändern (das fällt quasi in die gleiche Kategorie wie die Tiefe der Zacken bei der Sternenform zu ändern).


    Vielleicht kommt diese Funktion aber noch rechtzeitig fürs kommende Update hinein.


    Nichtsdestotrotz werden beide Elemente trotzdem schonmal verfügbar sein (lieber haben als brauchen) ;) Die Sternenform könnte sich in der jetzigen Form vll für geriffelte Säulen anbieten (natürlich mit anderer Textur).


    Wir sind aber übrigens auch für alle möglichen Wünsche was neue Formen usw. angeht offen. Die neue Version hat - anders als die Java Version - quasi keine Beschränkungen mehr was die maximale Anzahl an Blockformen angeht. Und wir können auch jederzeit neue Formen hinzufügen, ohne, dass es für alte Welten Probleme gibt.


    Wo liegt denn genau der Unterschied? Soll das Update dann einfach ohne viel "Gerede drum herum" veröffentlicht werden?

    Ich denke, es ist in Ordnung, wenn nicht zu viel Energie in die Ankündigung gesteckt wird, man sollte einfach einen schnellen Überblick über die neuen Features bekommen.

    Nee also zum Update selber würde es schon eine normale Ankündigung geben (mit dem üblichen Gerede drumherum, also wie auch bei vergangenen Updates) :D Eigentlich wollten wir aber ursprünglich noch im Vorfeld ein Status-Update (also kein spielbares Update) posten und ein wenig die neuen Bauwerkzeuge beleuchten, aber natürlich geht für sowas immer etwas zusätzliche Zeit drauf :saint: Da der Abstand zwischen der "Vorschau-Ankündigung" und "Update-Ankündigung" nicht sonderlich groß wäre, denken wir darüber nach, uns evtl. lieber direkt auf das spielbare Update zu konzentrieren.

    Also ich habe jetzt mal für die universelle Bauelemte entschieden aber ich bin mir da jetzt nicht so sicher was damit gemeint ist. Also wird es so sein, dass man die Blöcke so verändert wie man sie möchte in jeder form oder täusch ich mich jetzt?

    Ja, also es bezieht sich auf die Blöcke die du im Inventar hast: In der Java Version hast du ja vorher an der Werkbank auswählen müssen, ob du einen Block oder eine Rampe oder einen Zylinder herstellen möchtest. Wenn du bspw. einen Zylinder hergestellt hast, konntest du damit entsprechend auch nur Zylinder platzieren. Heikel wurde es bei den ganzen verschiedenen Eckstücken (zB die Eck-Blöcke für Rampen), wenn hier gab es meist verschiedene Variationen (innere Ecke, äußere Ecke, halbe Ecke usw). Hier kam es manchmal vor, dass man versehentlich falsche Eckstücke hergestellt hat. Aber auch beim Einlagern wurde es manchmal schnell unübersichtlich (verschiedene Blockformen mit jeweils wiederum verschiedenen Texturen).


    Der neue Ansatz würde vorsehen, dass es nur noch ein universelles "Bauelement" gibt. Beim Platzieren kannst du dann über ein Menü jederzeit die Form davon ändern, also statt einen Block kannst du auch jederzeit einen Zylinder oder eine Rampe platzieren. Das Spiel würde dann nur noch anhand der Textur unterscheiden.

    Deutsche Version

    We had various block shapes in the Java version (blocks, slopes, cylinders and the according corner pieces). Every shape was considered a separate "Item" which needed to be crafted individually. Sometimes this resulted in crafting the wrong items (e.g. an "inner" corner piece was required, but an "outer" corner piece was crafted accidentally).


    Do you think it would be a good idea to reduce them to a single, universal building element, which enables you to change the shape at any time? The game could store the last selected shape per item stack, so you can still have different stacks of blocks with various shapes. Textures would still be bound to individual items.


    This approach wouldn't be as realistic as in the Java version, but it would be a bit less frustrating if the different shapes were no longer treated as separate items. What do you think about it? Feel free to leave any feedback :)

    English version

    In der Java Version gab es ja diverse Blockformen (Blöcke, Zylinder, Schrägen, und die ganzen jeweiligen Eck-Typen). Es waren verschiedene "Items" die unabhängig voneinander gecraftet werden mussten. Nachteil war, dass man evtl. manchmal falsche Items gecraftet hat (bspw. brauchte man ein inneres Eckstück, hat aber versehentlich ein äußeres Eckstück hergestellt).


    Wäre es in der neuen Version ggf. sinnvoller, evtl. nur noch ein einzelnes universelles Bauelement zu haben, von welchem man die Form jederzeit anpassen kann? Die ausgewählte Form könnte dann pro Stack gespeichert bleiben, sodass man problemlos mehrere Stacks mit verschiedenen Formen haben und schnell hin- und herwechseln kann. Texturen wären weiterhin an separate Items gebunden. Es wäre zwar kein ganz so realistischer Ansatz mehr, könnte aber vll zu weniger Frust führen wenn es nicht mehr unendlich viele (teilweise relativ ähnliche) Formen als separate Items gibt

    We have now updated our Trello-Roadmap, sorry for the long delay :dizzy: We're currently still working on construction elements - we've spent a lot of time optimizing them to make sure they have the lowest possible impact on performance. The first results look promising compared to the Java version. The actual building tools are mostly ready. What's still lacking is a good selection of proper textures.


    We also have a small question for our building experts. We appreciate any feedback: https://forum.rising-world.net/thread/11159


    Apart from the building tools, we're also working on Multiplayer and the dedicated server as well as the new RCON Tool. The MP will be ready shortly after the building update.


    I still don't know if we will write a new status update soon or if we focus on getting the actual update ready :thinking:

    Wir haben unsere Trello-Roadmap nun endlich aktualisiert, sorry, dass das so lange gedauert hat :dizzy: Wir arbeiten aktuell noch an den Bauelementen - wir haben hier viel Zeit in diverse Optimierungen gesteckt, damit auch viele Bauelemente möglichst wenig Einfluss auf die Performance haben. Im Vergleich zu der Java Version sieht das bis jetzt schon sehr vielversprechend aus. Die eigentlichen Bau-Tools sind größtenteils fertig. Große Baustelle sind momentan noch die verschiedenen Bautexturen.


    Wir haben dazu auch eine kleine Frage an unsere Bau-Experten. Gerne könnt ihr auch Feedback dazu schreiben: https://forum.rising-world.net/thread/11158


    Abgesehen vom Bauen arbeiten wir auch am Multiplayer und dem dedicated Server sowie RCON Tool. Der MP wird zwar erst nach dem Bau-Update kommen, wird sich aber dabei nicht all zu viel Zeit lassen ;)


    Ich weiß noch nicht, ob wir als nächstes noch eine richtige Ankündigung schreiben, oder direkt zum eigentlichen Update übergehen :thinking:

    Schwieriges Thema :thinking: Grundsätzlich gibt es ja i.d.R. keine strikte Unterscheidung zwischen Multiplayer und Singleplayer bei Plugins, sodass prinzipiell eigentlich jedes MP Plugin auch im SP läuft und umgekehrt. Natürlich gibt es einige Plugins, die im Singleplayer keinen wirklichen Sinn machen, zB diverse Admin Plugins. Hier wären vll generell diverse Plugin-Kategorien sinnvoll, leider gibts aber wohl noch nicht genügend Plugins, um die diversen Kategorien zu füllen :wat:


    Ein Tag oder Flag wie "Singleplayer", "Multiplayer" und "Singleplayer/Multiplayer" würde grundsätzlich funktionieren, ich habe nur ein bisschen Sorge davor, dass Plugin-Ersteller sich fälschlicherweise bei ihrem Plugin auf den MP fokussieren (bzw. als MP taggen), obwohl ihr Plugin im SP genausogut funktionieren würde :hushed:

    Die "Mit Freunden spielen" Option ist tatsächlich kein richtiger LAN-Modus, sondern verwendet Steams Relay Server - d.h. in diesem Fall muss man über die Steam Freundesliste dem Spiel beitreten ;)


    Um den klassischen LAN-Modus zu starten, muss neben dem "Mit Freunden spielen" Button dieser kleine Pfeil gedrückt werden - dann taucht der rote "LAN Server starten" Button auf (ist zugegebenermaßen ein bisschen versteckt). Damit wird dann ein reguläres LAN-Spiel gestartet, und im Normalfall sollte es dann möglich sein, über das Multiplayer-Menü -> "Zu IP verbinden" zur LAN-IP des Hosts zu verbinden.


    Aus Performance-Gründen ist der LAN-Modus auf jeden Fall immer vorzuziehen. Die "Mit Freunden spielen" Option ist etwas langsamer, da die Steam-Server dabei involviert sind (und es funktioniert auch nur mit Steam-Versionen des Spiels) - Vorteil dieser Option ist lediglich, dass auch übers Internet ohne Portfreigaben gespielt werden kann (was in diesem Fall ja irrelevant ist, da ihr im gleichen Haushalt seid).


    Fall es aber immernoch nicht funktionieren sollte, sag einfach Bescheid :)

    Ich habe das Anhangsbild mal entfernt, da es ein paar möglicherweise sensible Informationen enthält die besser nicht öffentlich zugänglich sein sollten ;)


    Das Bild war aber dennoch hilfreich, denn es sieht so aus, als wenn nur der Standardport 4255 freigegeben ist. Der Server benötigt aber neben Port 4255 zusätzlich noch die Ports 4256, 4257, 4258 und 4259 TCP und UDP, und grundsätzlich (wenn der Server in der Serverliste auftauchen soll) noch Port 4254 TCP. Also prinzipiell muss der Portbereich 4254 bis 4259 freigegeben werden.

    Liralen Yes and no: There is unfortunately no way to send gifts, but basically you can still give the serial number to someone else. However, the serial will be linked to your forum account - so if you give it to another user, his game will still use your forum avatar (only in the new version) and your forum name by default (although that can be changed ingame).


    There are no such limitations when purchasing a Steam key from our homepage: You can give it to a friend who can then activate the product in his Steam account.


    We're thinking about adding vouchers: You could purchase a voucher and give it to another user (he could then use it to purchase RW for free). Not a perfect solution, but maybe this would work ;)

    Wir können diese Funktionen auf jeden Fall in der neuen Version anbieten :) Ich muss allerdings dabei betonen, dass der Spielername ja jederzeit geändert werden kann und anhand dessen der Spieler nicht wirklich identifiziert werden kann. Voraussichtlich werden die beiden Funktionen dann Server.getLastKnownPlayerName(long uid) und Server.getLastKnownPlayerUID(String name) sein.

    Basically a player becomes invisible automatically when the client didn't receive any new sync packets for that particular player for a given amount of time. Player sync packets are sent via UDP, so this sounds like either the server or the client is dropping UDP packets. I guess you live in the same household? In this case it's unfortunately difficult to find out if it's caused by the server or if it's a local problem :| If it's caused by the client, it could be either the router, or a firewall or antivirus program which blocks these packets.

    Yeah that's definitely on our todo list ^^ Unfortunately there is no map implemented in the new version yet so I can't give an ETA when this will be available :|