Dass die Permission beim Verlassen der Area nicht aktualisiert wird ist merkwürdig, evtl. ist das aber auch bereits behoben 
Ansonsten am besten nach dem Update nochmal melden, falls das weiterhin auftreten sollte.
Das Problem mit Player.getCurrentArea() kann ich aber bestätigen, das sollte mit dem nächsten Update behoben sein 
Was zumindest geplant ist ist die Möglichkeit, Schnee über Feuer (in einem Topf o.ä) zu schmelzen, um Süßwasser zu erhalten. An die Tonnen habe ich hingegen noch gar nicht gedacht... hier wäre vll denkbar, dass ein Feuer in der Nähe stehen muss o.ä, damit Schnee/Eis darin auftaut. Ich packe das auf jeden Fall mal auf die Liste
Ja, das würde grundsätzlich auch gehen. Ich könnte einen weiteren Parameter zur Funktion hinzufügen, womit man dann angeben kann, ob nur freigeschaltete Items angezeigt werden sollen. Momentan hat das Spiel das Konzept des "Freischaltens" aber nur für Crafting-Rezepte, die Item-Auswahl hingegen beinhaltet ja alle Items (also auch die, die man nicht craften kann). Wahrscheinlich wäre es dann am konsistentesten, wenn solche Items nur als "freigeschaltet" gelten, wenn der Spieler so eines zuvor schonmal aufgehoben hat?
In Zukunft wäre vll auch denkbar, dass man selbst genau definieren kann, welches Item darin auftauchen würde. Anders als oben beschrieben würde ich vmtl. dann fürs Callback nicht einfach ein Item zurückgeben, sondern eine Art Datencontainer, zB "ItemData" oder "ItemInformation" o.ä (damit man dann später auch dasselbe Objekt als Parameter verwenden kann).
Es wäre auch allgemein sehr schön, wenn es auch eine Methode geben würde, wo man prüfen könnte, welches Item der Spieler freigeschalten hat.
Ja, das wäre sinnvoll Das würde dann eine neue Player.isRecipeUnlocked() Funktion sein (was den Rezept-Status prüft) bzw. alternativ auch Player.isItemUnlocked() (was dann wie bei der Item-Auswahl entweder das Rezept prüft, oder - wenn kein Rezept vorhanden - prüft, ob das Item schonmal aufgehoben wurde.
Sorry für die späte Antwort, aber das kann ich auf jeden Fall mit dem nächsten Update einbauen 
Man wird dann separat angeben können ob reguläre Items angezeigt werden sollen, und/oder Objekte und/oder Kleidungsstücke.
Für das Callback wäre vmtl. am einfachsten, wenn das Spiel eine temporäre "Item" Instanz übergibt. Daraus würde man dann alle notwendigen Infos auslesen können
Leider ist die Blockvorschau in der Tat nicht durch die Wasseroberfläche hindurch sichtbar 
Das Problem werden wir aber mit dem nächsten Update beheben
Das mit dem Löschen kann ich nachvollziehen (also dass die Berechtigung nicht mehr aktualisiert wird), das ist tatsächlich ein Bug, welcher aber mit dem nächsten Update endlich behoben sein dürfte 
Wenn die sich nach der Zuteilung ihrer Berechtigungen aus ihrer Area entfernen, wird keine Wildnis mehr angezeit und sie nehmen die Area Berechtigungen mit - bis sie sich aus und wieder einloggen.
Meinst du mit "entfernen" dass sie aus der Area rausgehen, oder meinst du dass sie sich selbst aus der Area löschen, also ihre Permission-Zuweisung darin?
Das meinte ich - wenn man eine Area mit F9 erstellt und sich innerhalb dieses Bereichs befindet, muss man erst raus gehen und wieder rein damit die Berechtigungen aktualisiert werden.
Hmm... sorry dass ich da nochmal nachhake, aber ich bin mir noch nicht ganz sicher, wie du das meinst. Das normale Verlassen einer Area sollte die Permission eigentlich wieder zurücksetzen (auf die eigentliche Standardpermission des Spielers)... oder meinst du dass wenn die Berechtigung einer Area geändert wird während ein Spieler in dieser Area ist, dass er dafür erst raus und wieder rein muss, damit diese Änderungen für ihn aktiv werden?
Vielleicht hab ich das ein-/zweimal benutzt. Aber ich denke, das kann man trotzdem ausschließen, da er ja tagelang in einer Tour gecrasht ist. Seit der Änderung im Plugin läuft er immer noch einwandfrei
Achso, also ich wollte nur sicherstellen, ob der Server auch crashte, wenn in der Session dieser Befehl nicht verwendet wurde. Das Nachladen von Plugins kann theoretisch für Crashes sorgen, aber nur innerhalb derselben Session (d.h. wenn es irgendwann nach einem Restart crasht, dann hängt das nicht miteinander zusammen). Freut mich aber, dass der Server soweit läuft (wobei ich schon gerne auch die eigentliche Crash-Ursache abstellen würde)
Das sollte tatsächlich sogar möglich sein, momentan leider aber etwas versteckt: Du kannst dafür den edit Konsolenbefehl benutzen, genaugenommen musst du das Lagerfeuer betrachten und dann einmal edit flag disablesmoke eingeben, um den Rauch zu deaktivieren und edit flag disableparticles um die Glutpartikel loszuwerden (vll ändern wir das aber sodass "disablesmoke" auch direkt die Glut ausschaltet). Das wird aber zB auch in Blaupausen gespeichert, d.h. du kannst danach eine Blaupause vom Feuer erstellen und musst dann nicht immer die Befehle eingeben
Also du kannst auch ein Passwort festlegen indem du die Einstellung Server_WebRequestAuthPassword (samt gewünschtem Passwort) der server.properties hinzufügst 
Bei Anfragen müsstest du das PW dann über den Header "Authorization" mitsenden. Bei Map-Tiles kannst du dann die Parameter x und z für die Koordinaten verwenden.
Du musst allerdings bedenken dass die Map-Tiles nicht als Bilder gesendet werden, sondern als komprimierte Rohdaten. Die Heightmap ("HMBytes") enthält für jeden "Pixel" bzw. jede Zelle die Terrain-Höhe als 32 Bit Float, während die Biomemap ("BMBytes") für jeden Pixel je 4 Bytes speichert (RGBA). Als Komprimierung wird LZ4 verwendet. Falls du das Thema weiter verfolgen möchtest kann ich gerne noch weitere Infos dazu geben Oder wenn du in diese Richtung konkrete Wünsche hast lass es mich einfach wissen^^
Was ist genau gemeint mit weniger Bauteilen? Gibts da ne Zahl? Bzw. ne Grenze, ab wann es für das Spiel relevant ist?
Nicht so direkt, kommt ein wenig darauf an. Der Fehler mit der Kollision kann ab ca. 40.000 bis 80.000 Bauteilen innerhalb eines Chunks auftreten (32x32 Größe, nach oben/unten unbegrenzt). Bei vielen komplexen Bauteilen (hohler Zylinder, Kugel usw) auch schon etwas eher. Meine Aussage mit weniger Bauteilen war aber mehr darauf bezogen wenn das auch in Bereichen mit deutlich weniger Blöcken auftritt (zB nur ein paar Blöcke oder ein paar hundert Blöcke oder so)
Und was ich hier nicht verstehe - muss man bei der Auswahl nicht auch die Höhe definieren?
Jein, also es ist immer eine Mindesthöhe definiert (wenige cm), und das Spiel löscht einfach alle Elemente, die innerhalb dieses Bereichs sind
Ich muss sagen je mehr Anzeigen auf dem normalen Spielfenster herumschwirren, umso unübersichtlicher wird es.
Ich mag dieses graue Fenster auf der linken Seite nicht, z.B. und wenn noch mehr informative Fenster erscheinen, desto unübersichtlicher wird es meiner Meinung nach. Klar hätte der eine oder andere Spieler mitunter gern eine solche Information, aber bitte zum Ausschalten für diejenigen die das nicht brauchen und die die zusätzlichen Fenster irritieren. F3 z.B bietet auch viel Informationen, aber ist nicht die ganze Zeit sichtbar.
Es gibt tatsächlich auch bereits eine Einstellung, um das Informationsfenster beim Bauen auszuschalten. Das kann unter "Verschiedenes" -> "Bauen" mit "Informationen anzeigen" ein- und ausgeschaltet werden Alternativ kann sonst auch die Transparenz des Hintergrunds geändert werden, damit es weniger sichtbar ist.
Sorry für meine späte Antwort! Aber beziehst du dich auf das Platzieren von Terrain (oder das Entfernen), d.h. vorher konntest du die Maustaste gedrückt halten und jetzt musst du sie jedes Mal einzeln drücken?
Tatsächlich hat das Spiel eine Einstellung für das "Durchgehende Bearbeiten"... ist leider etwas unscheinbar. Standardmäßig wird das mit STRG Rechts an- und ausgeschaltet. Wenn du die Taste drückst müsste eine Meldung erscheinen, ob der Modus nun aktiv ist oder nicht.
Aber ich gebe zu, dass das nicht sehr intuitiv ist und man schnell versehenlich den Modus deaktivieren kann... vll macht es Sinn, eine Anzeige auf dem HUD dafür zu haben
There had been some considerations for this before and it's still on my to-do list I will try to add this with one of the next updates
Den CORS Header können wir auf jeden Fall noch setzen Werde das mit dem nächsten Update einbauen. Vmtl. macht es Sinn, das auch standardmäßig auf * zu setzen, aber man wird es dann auf jeden Fall auch über die server.properties einstellen können.
Was SSL angeht, das ist leider etwas komplizierter: Grundsätzlich unterstützt der Webserver SSL und tatsächlich verwendet das auch die RCON-Implementation (auch wenn das RCON-Tool leider noch nicht verfügbar ist), aber für den normalen Serverquery würde das zusätzlichen Aufwand bedeuten, da das Spiel das entsprechend berücksichtigen müsste. Gleichzeitig wäre da aber auch eigentlich kein Sicherheitsgewinn, da mit dem Query ja ohnehin nur öffentlich zugängliche Daten abgerufen werden bzw keine sensiblen Daten ausgetauscht werden.
Die Routen unter /game sind übrigens tatsächlich schon implementiert und auch teilweise in Verwendung Das ist im Grunde eine Zwischenlösung, damit der Client größere Daten vom Server erhalten kann (zB Bilder, Plugin-Assets, Map Tiles usw). Für die Abfrage wird ein Passwort benötigt, welches der Server pro Neustart festlegt und allen Clients mitteilt.
Sorry für die späte Antwort, aber das ist tatsächlich merkwürdig Ich denke, dass das möglicherweise mit dem anderen Problem (fehlende Kollision) zusammenhängt... ich schaue mir das nochmal genauer an. Falls das Problem nach dem nächsten Update aber weiterhin auftaucht (oder auch bei Bauwerken mit weniger Bauteilen), sag bitte Bescheid
Es ist gut zu hören, dass es jetzt scheinbar funktioniert! Demnach ist offensichtlich der Server.getAllAreas() Aufruf Schuld an den Crashes... ich habe mir das nochmal intensiv angeschaut, kann aber leider bisher nichts erkennen, was in dieser Methode Probleme bereiten könnte 
allerdings glaube ich das ich weiss worauf du hinaus willst, wenn jemand eine area löscht während getAllAreas ausgeführt wird dann könnte es eine null ref geben. Das aber so oft zur gleichen Zeit erstellt und gelöscht wird ist eher unwahrscheinlich, also wird ein Methode wohl wirklich zu oft diesen call machen.
Ja genau. Ob das jetzt aber hier wirklich der Fall ist bleibt schwer zu sagen... ein zu häufiger Aufruf sollte hingegen *eigentlich* kein Problem darstellen, außer es wird wirklich exorbitant häufig aufgerufen (jeden Frame mehrmals o.ä)
SonoBionda nur um das auszuschließen, Sachen wie zB das Nachladen von Plugins (mit dem reloadplugins oder rp Befehl) hast du aber während der crashenden Sessions nicht verwendet, oder?
Ich hatte mit dem F9 Tool einige Server Areas erstellt und dabei nicht auf die Chunkborders geachtet. Das könnte vllt. den stellenweise Multirequest erklären. Ich werde die noch mal neu aufziehen und an den Chunkborders ausrichten.
Du meinst die Ausgabe "ChunkMultiRequest: Unable to create chunk!"? Dabei sollte es eigentlich keine große Rolle spielen, wie groß die Area ist. Die Ausgabe ist übrigens auch relativ harmlos (außer es wird dauerhaft gespammt). Im Grunde bedeutet das, dass ein Client Chunks angefordert hat, während der Server den angeforderten Chunk noch am generieren war. Das Spiel hat dafür einen Timeout drin und wenn es etwas zu lange dauert, dann kommt diese Ausgabe. Es hängt ein wenig von der Leistung des Servers ab (CPU, aber auch Festplattengeschwindigkeit usw).
In dem Fall wird der Chunk aber einfach erneut vom Client angefordert. D.h. es dauert lediglich etwas länger für den Client (vmtl. einige Sekunden), bis er seine Chunks bekommt, aber es geht dabei nichts kaputt. Sofern diese Meldung also nicht gespammt wird kann man sie weitgehend ignorieren
Was ich auch noch ansprechen möchte ist die falsche Handhabung der Permissions nach dem claimen red51 - egal ob mit Tool oder über das Plugin - die werden nicht aktualisiert wenn man sich dann aus dem geclaimten Bereich entfernt - erst nach einem erneuten Einloggen
Du meinst wenn man sich als Spieler aus der Area löscht (oder die Area löscht)? Oder wenn man einfach aus der Area herausgeht? Ich meine ich hätte Ersteres behoben (der Fix wäre dann mit dem nächsten Update verfügbar), aber ich schaue mir das auf jeden Fall nochmal genauer an
--------------------------------
Noch zu deiner vorherigen Frage wegen dem Speicher bzw. was "Cpp" bei der Ausgabe "serverinfo nativememory" bedeutet: Das ist der Speicher, der von C++ allocated wurde. Derzeit findet die Chunkgenerierung (also das Erstellen der eigentlichen Meshes) in C++ statt, dort kommt der Verbrauch her. Ein Verbrauch von 300 MB ist aber absolut im grünen Bereich. Alle obigen Werte die du gepostet hast sind völlig in Ordnung.
Die Ausgabe unter "serverinfo nativememory" ist im Grunde nur interessant, wenn zB der native Memoryverbrauch plötzlich sprunghaft steigt (wie du ja ursprünglich beim Wetter vermutet hattest). Da kann der Befehl dann helfen herauszufinden, wo das hinfließt
Danke für die Reports! Das Problem ist leider eine Limitierung in Unity bzw. genau genommen PhysX (der Physik-Engine): Wenn zu viele Bauteile auf kleinem Raum verbaut sind (also innerhalb eines Chunks), dann kann die Kollision nicht mehr korrekt generiert werden... ich werde dafür mit dem nächsten Update einen Workaround einbauen, womit das Problem eigentlich behoben sein sollte
Das ist leider eine (unschöne) technische Limitierung Nebel wird als globaler Effekt dargestellt, wodurch er automatisch überall sichtbar ist. Wenn wir ihn zB einfach reduzieren/ausschalten, wenn man in einem Gebäude ist, dann würde das automatisch auch die Landschaft draußen betreffen (was sichtbar wird, wenn man zB aus einem Fenster schaut)...
Ich habe schonmal an ein paar Lösungen dafür gearbeitet, aber hier stößt man schnell auf Performanceprobleme. Das Hauptproblem ist die Feststellung, ob ein Pixel innerhalb eines Gebäudes ist (anders als bei einer festen, vorgegebenen Spielwelt weiß das Spiel das grundsätzlich ja erstmal nicht). Das Spiel hat dafür zwar quasi bereits eine Lösung parat (der gleiche Mechanismus der zB Regen/Schnee von Innenräumen fernhält oder Gras durch Objekte verdeckt), aber bei Nebel kommen diese Ansätze schnell an ihre Grenzen (könnte zB beim Laufen zu wabbelndem Nebel an der Hauswand führen o.ä).
Es ist kein unlösbares Problem und ich habe es definitiv weiterhin auf dem Schirm, aber aufgrund der Komplexität dieses Problems kann ich leider nicht sagen, wann das behoben wird 
Der Crash wird möglicherweise durch den Aufruf Server.getAllAreas() durch das Plugin verursacht Schwer zu sagen, was hier tatsächlich das Problem ist... JNI ist leider sehr pingelig und gleichzeitig sehr schweigsam bei Fehlern oder Problemen.
Das hier ist die C#-seitige Implementation von Server.getAllAreas():
Sofern ich nichts übersehe könnte ich mir nur zwei Dinge vorstellen: Entweder die zur Area zugewiesene "javaArea" aus irgendeinem Grund nicht mehr valide ist. Die "javaArea" wird als globale Referenz gespeichert (damit sie nicht vom Java Garbage Collector erfasst wird).
Oder aber es steht der VM kein Speicher mehr zur Verfügung und das Erstellen des neuen Arrays schlägt fehl. Das Spiel prüft leider nicht, ob "env.NewObjectArray()" ein valides Array zurückgegeben hat (was nicht der Fall wäre, wenn zB kein Speicher mehr frei ist). Andererseits würde spätestens "env.SetObjectArrayElement()" darauf anschlagen, von daher weiß ich nicht, ob das überhaupt in Frage kommt... und innerhalb der Schleife gibt es auch keine neuen Allocations, daher sehe ich eigentlich keinen Bedarf für ein PopLocalFrame/PushLocalFrame o.ä 
Devidian Unter welchen Umständen wird denn in deinem Plugin "isAreaIntersecting()" aufgerufen? Gibt es evtl. Situationen, in denen das sehr häufig aufgerufen wird (zB mehrmals hintereinander oder jeden Frame)?
SonoBionda Kann es sein, dass im Moment des Crashes oder kurz zuvor zB eine Area erstellt oder gelöscht wurde? Können andere Spieler generell ihre Area löschen bzw. haben sie Zugriff auf die Creative-Modus Area Werkzeuge (F9)?
Du könntest sonst evtl. nochmal folgendes zur server.properties Datei hinzufügen:
Plugins_JNIXcheck=True
und
Plugins_JNIVerbose=True
Damit könnte die Log-Datei dann ggf. ein paar mehr Informationen enthalten im Falle eines Crashes. Wenn es dann wieder crasht, poste bitte einmal die Log-Datei bzw. zumindest das Ende der Log-Datei (oder sende mir den Log via PN) und vll auch die hs_err_pid
