Glad to hear it works now 
Posts by red51
-
-
Thanks for the log! Nothing suspicious there though...
Was the LD_LIBRARY_PATH environment variable set? If you run the server through the "linux_startscript.sh" script (which is shipped with the server), the LD_LIBRARY_PATH variable is set automatically.
Also make sure the game ports (by default 4254 and 4255 TCP and UDP) are not blocked.
-
The new error indicates that the Steam API could not be initialized. This can have various reasons... Did you set the LD_LIBRARY_PATH environment variable? If you launch the server through the start scripts ("linux_startscript.sh" or "linux_screen.sh" [if "screen" is installed]) this is done automatically.
Usually the log contains more information about what went wrong exactly. You find the log files in the "Logs" subfolder in the server directory, please upload the latest log here (or alternatively send it via PM to me)
-
Which Linux distro do you use exactly? The error indicates that our native lib could not be loaded... possibly a dependency is missing or outdated. It could be glibc. IIRC glibc 2.18 or higher is required. Please have a look at your installed glibc version and if it's older than 2.18, please try to update it. If that doesn't solve the issue, please let me know
-
Die Logs sind leider vom 01.09
Besteht das Problem denn weiterhin? Falls ja, bitte schaue einmal ob evtl. ein neuerer errorlog vorhanden ist.Wir haben leider keinen Einfluss darauf, wenn die Startoptionen bei Steam verschwinden... sowas sollte eigentlich nicht passieren, aber dieser Teil wird komplett von Steam gehandhabt... neulich haben sich in meinem Steam Profil auch aus heiterem Himmel Einstellungen zurückgesetzt, d.h. sowas kann bei Steam also offenbar durchaus mal passieren
Die neue Version hat dieses Problem zumindest nicht, da sich das Spiel einfach mehr RAM nimmt wenn erforderlich. In Java hingegen muss leider direkt beim Start festgelegt werden, wieviel RAM insgesamt verwendet werden sollen.
-
That's weird
Does that mean you no longer run into timeouts after joining the test server once? If you still encounter this issue again, maybe send us a client log, or alternatively send a report (by typing "report" into console)
-
mookie If you want to download the server for the new version from the Steam client (under "Tools"), make sure to select the correct beta branch first. To do that, rightclick on the server in your Steam client -> Properties -> Betas -> select "unity" and close the window. If the Java version of the server was already installed, I'd recommend to uninstall it first, then select the beta branch and download the new server
This post contains more information about the dedicated server setup for the new version: Dedicated Server Setup [New Version]
-
Kommentare in der settings.properties ? geht doch?! So mach ich das bei meinen Plugins schon Jahrelang
Properties unterstützen durchaus Kommentare, aber ich glaube java.utils.Properties bietet keine API, um Kommentare auch zu setzen
Ich hatte es so verstanden, dass es PatrickOtt auch um diese Funktionalität geht 
-
Oh, thanks for bringing this to our attention!
This will be fixed with the next update 
-
Oh, jetzt verstehe ich
Also das Spiel verwendet für seine Einstellungen ein an Javas "Properties"-Dateien angelehntes Format. Also die "config.properties" und "server.properties" Datei. Die sind recht einfach aufgebaut und unterstützen auch Kommentare.JSON würde ich für eine config nicht unbedingt empfehlen. Das bietet sich nur an, wenn du zB auch mit JavaScript kommunizierst (zB wenn du ein Webinterface für deinen Server erstellst, welches auf die gleichen Dateien zugreifen soll und du diese nicht erst konvertieren möchtest).
Wenn du einfache Daten speichern möchtest, reicht grundsätzlich ein einfacher Aufbau wie unsere config Dateien aus (also pro Zeile ein Key und ein Wert, getrennt mit einem Gleichheitszeichen).
Das in die Plugin API zu integrieren wäre vielleicht gar nicht so verkehrt
Java bietet zwar direkt Möglichkeiten, Properties einzulesen und zu speichern, allerdings - wenn ich mich recht entsinne - keine Möglichkeit, Kommentare zu setzen. Wir müssen uns dazu mal Gedanken machen, ob wir dafür vll direkt was in der Plugin API anbieten -
Mir war es wichtig, dass ein Item, das im Inventar am 1. oder 2. Platz liegt, auch in der Slotleiste so sortiiert auftaucht, um ein Vorsortieren schon Inventar vorzunehmen, da
dieses ja größer ist, als die Slotleiste
Das ist ein kleines Missverständnis
Der erste Slot im Inventar ist in der Java Version dier hier (der rot umrandete):Das ist quasi der gleiche Slot wie auch der erste Slot im Inventar der neuen Version (wo auf deinem Bild weiter oben die Futterkrippe drin war). In der Java Version wird oberhalb der Inventar-Slots lediglich die Hotbar angezeigt (die gelben Slots), aus den zuvor beschriebenen Gründen. In der neuen Version befindet sich die Hotbar unten mittig, hier wäre es irritierend, wenn sie beim Öffnen des Inventars plötzlich oberhalb des Inventars platziert wäre...
Ich konnte blind drauflos bauen, das ist jetzt leider so nicht mehr möglich.
Viele andere Spiele machen das mit der Slotleiste eigentlich auch so
Die Java Version war da eher der Sonderfall, da die Slotleiste bzw. Hotbar oben rechts angezeigt wurde (und immer ausgeblendet war, außer beim Itemwechsel). Tatsächlich wurde von manchen Spielern in der Vergangenheit auch gewünscht, die Slotleiste unten mittig zu platzieren (weil es einfach der gewohnte Platz in vielen Spielen ist) Wäre es möglich für die Farbeingabe sich ein paar eigene Farb-Favoriten zu speichern?
Wie meinst du das? Meinst du den "edit" Befehl? Hier wäre es leider durchaus mit einigem Aufwand verbunden, wenn es dafür Presets gäbe... ich kann mehr dazu sagen, wenn wir eine grafische Lösung für den "edit" Befehl haben.
Es ist auch so, dass verschiedene Untergründe bzw. verschiedene Materialien eingefärbt eine andere Farbe annehmen. Leder sieht gefärbt anders aus, als Stein, Metall wieder anders, von daher wären Favoriten ganz praktisch.
Es war tatsächlich eine bewusste Entscheidung, dass die Grundtextur durch die Färbung hindurch sichtbar bleibt. Wäre das nicht so, würde unterm Strich jeder angemalte Block fast gleich aussehen (egal ob Stein, Holz oder Metall).
Wenn man momentan möchte, dass die Farbe möglichst invensiv zur Geltung kommt, sollte man am besten einen hellen Block (zB weißer Putz oder weiße Fliesen) mit möglichst wenig Struktur verwenden.
Wie ist es mit dem Überschreiben von Blocks. In der Java-Version war es bisher so, dass Blocks überschrieben wurden bzw. doppelte Blöcke einen einzelnen reduziert wurden. In der Unitiy-Version ist
das Übermalen bzw. Ziehen von Blöcken sehr einfach
Die neue Version verhält sich in dem Punkt wie die Java Version bzgl. Planken und Balken. Hier können prinzipiell so viele Bauteile auf ein und derselben Stelle platziert werden, wie man möchte.
Wir möchten das in Zukunft aber etwas einschränken, sodass Bauteile, die exakt gleich groß sind und die gleiche Drehung haben, nicht an exakt derselben Stelle platziert werden können (da dies in 99% aller Fälle ohnehin wohl nicht gewollt wäre).
Apropos Inventar red51 : Könnt ihr bitte einen Shortcut implementieren, mit dem man im Inventar bei gedrückt halten von Shift und einem Linksklick auf ein Item dieses vom Inventar direkt in die Slotleiste packen kann und umgekehrt? Diese Funktion gibt es z. B. in Minecraft und sie macht die Inventarverwaltung deutlich schneller
Das sollte dann auch analog mit Behältern <-> Inventar funktionieren.Das ist ein guter Hinweis, das werden wir ins nächste Update reinpacken
Die Texturskalierung bleibt für alle nachfolgenden Bauteile bestehen, allerdings ist ein Wechsel zwischen 2 Untergrunden oder 2 Bauteilen ohne, dass jedes Mal die Skalierung geändert werden muss, nicht möglich, sehr unpraktisch.
Momentan bleibt die eingestellte Textur-Skalierung tatsächlich bestehen, d.h. sie wird nicht pro Item oder pro Block eingestellt. Hier wäre die Frage, was sinnvoller ist? Die Textur-Skalierung pro Item speichern, oder - wie jetzt momentan - als globale Einstellung zu haben?
-
Wenn das Spiel abstürzt, poste am besten einen Fehlerlog hier (entweder errorlog oder hs_err_pid), dann kann man sehen, was genau passiert ist.
-
Hmm... does that mean you have to connect 6 times to a server to not get a timeout, or do the first 6 clients who connect to a server (or the first 6 incoming connections) always get a timeout? The new version solely uses UDP (which is a connection-less protocol), so if you get a timeout, this means that the server (or the client) did not receive any responses from the client (or the server) for a given amount of time. I just tried to join your server and I didn't got a timeout, but depending on when the timeouts happen exactly, this may not be representative
It would be interesting to know if this is a clientside issue (this would be the case if you get the timeout on other servers as well - e.g. when you try to connect to our test server), or a serverside issue (i.e. the first 6 incoming connections always get a timeout). Maybe you could send me a server log? And maybe a client log (or report) would also be helpful. So perhaps you could try to join your server (in order to get a timeout), send just type "report" into console, and maybe also send me a server log via PM (or upload it in this post)
-
Also grundsätzlich ist das Spiel in der Lage, bei Höhenunterschieden auch Zwischenwerte zuzulassen (dadurch ist das Terrain nicht mehr so stufig wie in der Java Version). Leider gibts momentan kein Tool, womit dieser Zustand ebenfalls erreicht werden kann (d.h. das Glätten-Werkzeug verhält sich quasi wie in der Java Version und kann auch nur blockweise Abstufungen im Terrain erzeugen). Das werden wir noch ändern, damit das Glätten-Werkzeug (und später auch die Harke) glattere Oberflächen bzw. weniger stufige Übergänge zustande bringt
Fürs Hinzufügen-/Abtragen-Werkzeug (F5 -> 1) hingegen wird das vermutlich nicht kommen... das würde kein schönes Resultat hervorbringen. Wir müssten damit mal ein wenig herumexperimentieren.
Ein richtiges "Anheben-/Absenken-Werkzeug" ist für den Creative-Mode aber auch geplant, hier wiederum wäre es durchaus sinnvoll, wenn diese Zwischenwerte genutzt werden können, sodass in feinen Schritten Terrain angehoben bzw. abgesenkt werden kann.
Das Befüllen von Behältnissen mit Terrain könnte aber möglicherweise trotzdem schwierig sein, da diese feineren Abstufungen nur in der Höhe bzw. Vertikalen gelten, nicht aber horizontal - hier ist das Terrain leider weiterhin an das Block-Raster gebunden
-
Ich hab mich nur gefragt, was denn dann in der neuen Version mit importierten Java-Blaupausen passiert, die Poster enthalten? Werden diese dann -- genau wie Objekte -- nicht in die neue Version übertragen? (Oder wurden Poster gar nicht von Blaupausen in der Java-Version erfasst? Hab das nie ausprobiert
)Wenn ich mich recht entsinne werden Poster an sich zwar gespeichert, allerdings nur die Referenzen auf die Bilder. Wenn der Bauplan dann in der selben Welt platziert wird, werden die Poster übernommen. Wird der Bauplan aber in einer anderen Welt platziert, fehlen die Bilder, denn die eigentlichen Bilddaten werden auf jeden Fall nicht im Bauplan mitgespeichert.
Daher wird man Poster leider nicht via Bauplan in die neue Version übertragen können
In der Java-Version ist der 2. Platz im Inventar, auch der 2. Platz in der Slotleiste. In der Unitiy-Version ist das leider nicht mehr der fall. Hat das einen bestimmten Grund
oder könnte man das wieder anpassen?
Wie Yarofey schon sagt, in der Java Version wurde die Slotleiste beim Öffnen des Inventars mit im Inventar angezeigt (als gelb hinterlegte Felder), da sie einerseits oben rechts in der Ecke (wo sie ja ansonsten standardmäßig auf dem HUD liegt) etwas umständlich zu erreichen ist (wenn du zB ein Item dorthin schieben oder rausziehen möchtest), andererseits wurde die Slotleiste in der Java Version immer ausgeblendet (außer beim Wechseln des Items).
In der neuen Version hingegen ist die Slotleiste da, wo sie immer ist - unten mittig. Diesen Ansatz haben ja viele Spiele so.
Würden wir die Slotleiste auch zusätzlich im Inventar anzeigen, müsste das ober- oder unterhalb der Inventarslots sein, und am besten nicht mehr Slots haben als eine Reihe im Inventar (also max. 6 Slots). Die Slotleiste ist aber dafür ausgelegt, bis zu 10 Slots zu haben.
Wir möchten aber die Slotleiste etwas größer machen (oder das evtl. auch einstellbar machen), damit die Sichtbarkeit davon etwas verbessert wird
Was das Layout angeht, könnte ich mir für die Zukunft auch vorstellen daß man sein eigenes Layout zb auf einem Server hat. Da gibt es bestimmt Möglichkeiten. So könnte eine Layout auch mittelalterlich, antik oder futuristisch aussehen. Oder auch wiedererkennbar zu dem Besitzer des Servers. Die ganzen Layouts sind letztlich ja auch nur Grafiken und sollten eben zb themenbasiert austauschbar sein.
Das wäre eine denkbare Option. Tatsächlich wird die UI beim Zurückkehren ins Hauptmenü bereits neu geladen, d.h. von der Seite wäre das also schonmal kein Problem, wenn irgendwelche Teile davon vom Server modifiziert werden. Wir behalten das auf jeden Fall mal im Hinterkopf
Vmtl. wird das aber erstmal nur über die PluginAPI einstellbar sein...
-
Das müsstest du etwas genauer erläutern
Wie genau meinst du das mit der "JSON-API"? Beziehst du dich auf die Permission-Dateien?Grundsätzlich kann Java von Haus aus bereits JSON lesen und schreiben ("JsonReader" und "JsonWriter" aus dem "javax.json" Package). Es gibt da draußen aber noch eine ganze Reihe anderer Libs, die sich darauf spezialisiert haben. Eine bessere API können wir dafür auch nicht anbieten
Damit kannst du an allen Stellen arbeiten, an denen die neue Version JSON verwendet (Rückgaben unserer Backend-API [zB Serverliste], Server Query Rückgaben, Permissions).Wenn es aber explizit um Permissions geht, dann wird die Plugin API natürlich auch einen direkteren Zugriff darauf bieten (dass du also einzelne Permission-Werte direkt setzen kannst), ohne, dass du mit den Roh-Dateien oder mit JSON arbeiten musst.
JSON kann übrigens leider keine Kommentare, d.h. wir können die JSON Rückgaben der o.g. Stellen leider nicht mit Kommentaren versehen, da dies dann kein valides JSON mehr wäre (und das dann kein gängiger JSON-Parser mehr lesen könnte)
Der einzige Grund, warum wir JSON für die Permissions verwenden, ist eigentlich auch nur gewesen, dass angedacht war, dass diese in erster Linie über das RCON Tool angepasst werden sollen -
Wäre es möglich dahingehend eine Warnung zu verfassen?
Könnten wir theoretisch machen, allerdings liegen die Blaupausen für die neue Version ja auch nicht im gleichen Ordner wie für die Java Version, d.h. man sollte am besten sowieso keine Blaupausen aus der neuen Version zur Java Version rüberkopieren
red51 Was mir einiges an Kopfzerbrechen macht, ist die Änderung der alten Java-Texturen auf die Texturen der Unitiy-Version. Ich selbst habe mittlerweile sehr viel eigene Texturen verwendet und ich werde im Nachhin wohl auch nicht mehr wissen. welche ich in der Java-Version, verwendet habe, um ähnliche Texturen in der neuen Version zu finden. Meine Gebäude leben mittlerweile von ihren Texturen, eine Änderung würde mir wie ein Schock vorkommen. Gäbe es vielleicht eine Möglichkeit eine Vorschau einzufügen?
Kannst du das mit der Vorschau etwas näher erläutern? Wo genau soll diese Vorschau erscheinen?
-
Da "Posters / Images" auf Scheduled gesetzt sind; kann man mit denen schon im Blaupausen-Update rechnen?
Schwer zu sagen
Wir werden in den nächsten Wochen auf jeden Fall ein paar Vorkehrungen für Poster treffen, aber ich weiß nicht, ob das passend für Blaupausen fertig wird. Im Survival-Bereich drückt der Schuh etwas, und die Spielerfraktion, die dem Bauen nicht ganz so viel abgewinnen kann, wird immer ungeduldiger - wir müssen daher unbedingt schauen, dass wir den Bereich möglichst schnell voranbringen können Die Texturskalierung bei ID 159 auf 4 von einer hochauflösenden Textur nur noch eine wischiwaschi Textur herauskommen, bzw. die Vergrößerung macht
die Textur extrem unscharf. Ich denke mal, dass die Unschärfe stärker hervortritt, je größer man die Textur heranzoomt bzw. größer skaliert. Es ist mir auch bei anderen Texturen aufgefallen, aber genaue Id's weiß ich nicht mehr.
Das ist leider zu erwarten: Die Textur wird ja nicht hochauflösender, wenn man sie größer skaliert. Wenn wir wollen, dass bei großer Skalierung die Texturen weiterhin scharf sind, müssten wir mindestens mit 8K Texturen arbeiten - das ist aber für ein Spiel wie RW aber heute noch ein bisschen zu viel des Guten. Zwar technisch nicht unmöglich, aber es würde den VRAM Verbrauch deutlich nach oben schrauben, viel Performance kosten, und auf der Festplatte würde RW wohl schnell Richtung 100 GB und mehr belegen.
Du kannst aber sicherstellen, dass du in den Grafikeinstellungen die Texturqualität für Bauelemente auf Maximum stellst.
-
Es ist tatsächlich gar nicht so einfach, eine Spirale zu bauen
Wir müssen uns das mal genauer anschauen. Eine Option, dass Pivots sich nicht um die Y-Achse drehen könnte hier evtl. helfen, das müssen wir einmal testen -
wie groß die jeweiligen Areale dann sein werden muss dann der Admin festlegen ? ( bei selbst erstellten Areale )
Das Spiel wird eine Standardgröße vorgeben, aber Admins können diesen Wert auf ihrem Server einstellen
