Posts by red51

Quote from Deirdre

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...

Quote from Deirdre

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)

Quote from Deirdre

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.

Quote from Deirdre

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.

Quote from Deirdre

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).

Quote from Yaromid

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

Quote from Deirdre

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

Quote from Yaromid

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

Quote from Deirdre

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

Quote from lenko

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

Quote from Deirdre

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

Quote from Deirdre

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?

Quote from Yaromid

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

Quote from Deirdre

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

Quote from ebisgames

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

Most parts of the RCON tool are indeed already implemented, however, it's currently not accessible unfortunately. It wasn't ready in time for the multiplayer update, so we decided to release the RCON tool in a subsequent update.

Hmm... this may be related to the other issue that permissions are not applied correctly (which will be fixed with the next update). Did you set it in the "default" permission file? That should basically work. Or did you set it in a specific group permission?

Ich habe die Beiträge mal in einen eigenständigen Thread verschoben

Jedenfalls ist das mit dem Beanspruchen der Areas tatsächlich so: Wenn der Spieler das Objekt (bleiben wir mal beim Pfahl) irgendwo platziert, dann wird dort für ihn eine neue Area erstellt - dieser Spieler hat dort dann eine spezielle "Eigentümer" bzw. "Owner" Berechtigung (kann vom Admin eingestellt werden). Der Spieler kann - wenn er mit dem Pfahl interagiert - auch weitere Spieler seiner Area zufügen (und diese ebenfalls zu "Owner" machen). Fremde Spieler können in dieser Area nichts zerstören. Wenn der Spieler seinen Pfahl abbaut, wird die Area wieder entfernt.

Alternativ kann ein Serveradmin das freie Platzieren dieses Pfahls auch unterbinden - gleichzeitig kann der Admin dann selber Areas erstellen (mit dem Creative-Mode Tool [F9]) und diese als "beanspruchbar" markieren. Fortan dürfen Spieler ihren Pfahl in diesen Areas platzieren und bekommen dann darüber ihre "Owner" Berechtigung. Diese Areas können allerdings nicht vom Spieler erweitert werden. Beim Entfernen des Pfahls bleibt die Area bestehen (und kann dann wieder von einem anderen Spieler beansprucht werden). Das ist sinnvoll, wenn ein Admin selber freie Grundstücke definieren möchte (wichtig zB wenn eine Stadt entstehen soll, damit Spieler nicht kreuz und quer ihre Areas erstellen).

Es gibt verschiedene Level oder Stufen für den Pfahl. Ein höheres Level sorgt dafür, dass beim freien Platzieren eine größere Area beansprucht wird. Bei der 2. Variante (Admin definiert beanspruchbare Areas) hingegen kann der Admin festlegen, welches "Mindest-Level" der Pfahl eines Spielers haben muss, damit die Area beansprucht werden kann (Beispiel: Grundstücke in der Innenstadt sind teurer als irgendwo am Stadtrand und entsprechend kann dort ein Pfahl mit höherem Level [ergo ein "wertvollerer" Pfahl] gefordert werden).

Admins können auch festlegen, wieviele Pfahle ein Spieler insgesamt platzieren darf. Um seine Area also zu vergrößern (gilt nur fürs freie Platzieren) kann der Spieler entweder mehrere Pfahle platzieren (ein Überlappen mit eigenen Areas ist erlaubt), sofern vom Admin erlaubt, oder seinen Pfahl auf ein höheres Level aufwerten. Areas der 2. Variante hingegen können nicht vom Spieler vergrößert werden (nur vom Admin).

Außerdem können Admins einstellen, dass Areas automatisch aufgelöst werden (bzw. die Pfahle entfernt werden), wenn der Eigentümer längere Zeit nicht mehr online war.

Quote from sharkbitefischer

red51 I have run into a problem. The console command item pickaxe 1 will not work for any of my regular players. What is the permission setting to allow the item console command? Or is it strictly a full admin command?

You have to set "itemgive" (in "command" section) to true

Quote from Yaromid

Mal eine Frage zu P2P: Wenn ich eine meiner Welten in dem Modus starte, kann ja jeder RW-Spieler in meiner Steam-Freundesliste joinen, richtig? Ist es irgendwie möglich, die beitretenden Spieler zuerst auf meiner Seite "abzufragen", also z. B. mit einem Dialog:

"XY möchte beitreten [Zulassen] [Ablehnen]" ?

Ja genau, momentan kann jeder, der dich in der Freundesliste hat, dem Spiel beitreten, so wie in der Java Version. Einen Dialog dafür einzubauen (zumindest als optionale Lösung) wäre aber vielleicht gar nicht so schlecht. Ich packe das mal auf unsere Todo-Liste

Quote from lenko

Ein Password als Zugang wäre bestimmt leichter

Das wäre an sich auch eine naheliegende Lösung, das Problem ist leider nur, dass wir eine Passwortprüfung erst durchführen können, nachdem die Verbindung aufgebaut wurde. An sich wäre das nicht weiter problematisch (ist im normalen MP auch so - wenn das PW falsch ist, wird die Verbindung einfach wieder getrennt), aber bei Steam P2P ist es etwas problematisch, wenn eine Verbindung wieder getrennt wird: Es dauert manchmal einige Sekunden, bis Steam die Verbindung wirklich trennt und neue Verbindungen wieder zulässt. Wenn jmd. also versehentlich ein falsches Passwort eingibt, kann es sein, dass er danach erstmal einige Sekunden nicht mehr beitreten kann (was dann Verwirrung stiften kann)

Quote from sharkbitefischer

On another note we still have problems with using console commands inside a claim. We have to step outside the areas to use the console commands.

This will be likely fixed with the next update. There were quite a few issues regarding permissions in general, so I guess the commands issue is related to that. If you still experience these issues after the next update, please let me know

Schwer zu sagen Aber tatsächlich denke ich auch, dass das mit dem Permission-Bug zusammenhängt - das bringt nämlich einiges durcheinander. Das nächste Update sollte diese Probleme eigentlich aus der Welt schaffen (das wird leider kein separater Hotfix mehr, sondern Teil des nächsten regulären Updates). Wenn die Probleme danach weiterhin auftreten sollten, lass es uns bitte wissen

If "areatools" are set to true in the permission, the player has access to the creative mode area tools (F9), which means he gains full control over all areas - he can create, delete or modify areas. Actually the area tools (F9) were originally meant to be an admin-only tool. If you want a player to have access to creative mode (without the ability to change areas), make sure to set "areatools" to false, and just set the particular creative mode tools you want to allow (e.g. "terraintools", "removaltools" etc) to true. Also set "changegamemode" under "general" to true (so the player can actually use the "gm" command).

Self-claiming for areas isn't implemented yet unfortunately You can already set an area "claimable" though, but this has no effect currently. The idea is to have a specific item in the future which allows players to claim land. If areas are set up and set to "claimable", a player could place his "claim item" in this area to claim this area. This way you could set up pre-defined plots on the server (which may be helpful if you want to create a city, and want players only to be able to claim specific parts of land).

In addition to that, players will also be able (depending on server settings) to create new areas with this "claim item" (as long as these areas do not collide with existing areas). These areas are a bit different than regular areas (which were set up via area tools). Once a player removes his claim item, his self-claimed area will also be removed (this does not apply to claimable areas created by admins, as mentioned above)

There was no update for Rising World yesterday But according to SteamDB, Valve updated the Steam SDK package yesterday. This happens from time to time, we have no control over this, but it should not interfere with the game or the server.

Areas are stored in the "Areas.db" file in the World folder. If the file is corrupted, for example, there should be more information about that in the logs. Maybe you could upload the latest server log here (or send it via PM to me).

What do you mean about the moon being a mess? oO

Das ist tatsächlich momentan etwas problematisch Grundsätzlich ist vorgesehen, dass man ingame den Namen ändern kann (was dann unabhängig vom Steam-Namen ist), ähnlich wie in der Java Version... aber diese Einstellungen sind bisher leider noch nicht drin...

Momentan sind - wie in der Java Version - recht strenge Namensregeln festgelegt, aber ich weiß nicht, ob das überhaupt noch sinnvoll ist... dazu müssten wir uns mal Gedanken machen... vielleicht wäre es gut, alle Namen zuzulassen, nachteilig ist es allerdings aber für Admins, wenn sie den Spielernamen für Commands benötigen Vielleicht ändern wir das probeweise mal, um zu sehen, wie sich das verhält.

Vielleicht können wir unabhängig davon auch noch eine passende Schriftart bereitstellen, damit der Name ingame auch korrekt angezeigt wird