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 
Posts by red51
-
-
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
-
Nein, das Wetter hat eigentlich keinen Einfluss auf den RAM (zumindest serverseitig)... du kannst aber den Native-Memory weiter aufbröseln indem du serverinfo nativememory in die Konsole eingibst - damit siehst du, welcher Bereich des Spiels wieviel nativen Speicher verbraucht. Der erste Wert ist hier ausschlaggebend (den "Total" Wert dahinter kannst du ignorieren). Mit BildAuf und BildAb kannst du dann in der Konsole hoch- und runterscrollen
-
As mentioned by james1bow , the query port cannot be changed (but it's actually port - 1, so the 1st server uses 4254 and the 2nd server uses 4255 in your case). It seems that the WindowsGSM server assumes that the query port is configurable...
Changing the "Island Paradise" server port to 4257, for example, should do the trick
-
Es gibt tatsächlich sowas wie einen Blutmond, aber der hat keine Auswirkungen und ist daher nie von sich aus aktiv.
Ursprünglich war der Gedanke, dass bei diesem Effekt dann Skelette und ggf. Ghouls spawnen. Das haben wir dann aber erstmal wieder verworfen und stattdessen die Skelette an eine Einstellung geknüpft (sodass sie bei aktiver Einstellung Nachts immer spawnen), und die Ghouls in die Hölle verbannt.
Man könnte aber überlegen, ob man das vll nochmal in Angriff nehmen möchte
Andere Events wären aber auch gut denkbar. Die Hauptschwierigkeit ist hier leider, dass es Multiplayer-kompatibel sein muss (was Abhängigkeiten vom Spielerfortschritt und seiner Ausrüstung erschwert)
-
Unfortunately the "owner" column isn't used atm (and maybe it will be changed or removed in the future)... but if you want to get the last used mount of a player, you can check the "lastusedmount" column in the player table
It contains the ID of the last used mount. I will also add a method to the API to get this ID from a player (without having to work with the database directly) btw. is there a way to change any existing radial menu? For example when i want to add something like "rename mount" so i dont need to set editnpc true. Or to stay in the current case "claim mount" and "release mount".
Unfortunately that's not possible yet
The API provides no way to modify existing radial menus... there is also no event that's fired when the player holds the interaction key on an npc (or when a radial menu shows up). This has been on our to-do list for quite some time, but unfortunately I have no ETA for it yet...But in theory it would be possible to disable interactions with the npc, then listen to key input and bring up your own, custom radial menu. Right now that doesn't fully work, because disabling interactions with npcs also suppresses the PlayerNpcInteractionEvent. It also seems that the event is not invoked for all npcs (e.g for mounts)... I will change that with the next update
-
Hmm... maybe restart the game after a crash (it's sufficient to just load the main menu), then open the console and type report. Maybe also add a brief description like "game crashed when someone joined" and send the report
