Posts by red51

This sounds like you're not running the RW server on your local machine, right? In this case you have to keep the server running of course (i.e. your dedicated server which runs the RW server), but there is no need to keep your PC online. You can use screen to detach the server process and keep it running in the background. If screen is installed on your server, you can just run the linux_screen.sh script

Quote from Bogus

Ja die Dockleiste verschwindet ja jetzt, aber das Problem ist die toolbar unten, die halt nicht ganz angezeigt wird.

Achso, oh sorry das habe ich gar nicht so richtig wahrgenommen Ist das denn erst durch die neue Grafikkarte passiert?
Ggf. kann das weiterhelfen: https://askubuntu.com/a/125582

Quote from lenko

Also ich bin mir jetzt etwas unsicher, einerseits möchte ich ja auch bauen und wenn ich jetzt meinen Weg mit Pflasterseinen einfach malen kann würde ich das wohl nicht so toll finden

Naja, zumindest so manche altertümliche Pfade lassen sich mit dem Bausystem teilweise nur schwer umsetzen - besonders wenn es bspw. eher in die Richtung geht, dass es ein einfacher, kurviger Pfad durch den Wald sein soll. Also wenn ich zB an sowas denke:
https://c8.alamy.com/comp/D3NA…mi-cobblestone-D3NA86.jpg
Oder gar an sowas: https://i.pinimg.com/736x/bb/f…amera-slr-tree-swings.jpg

Hier hätte eine passende Terrain-Textur zumindest durchaus eine Daseinsberechtigung. Ob es hingegen wirklich sinnvoll ist, sie reinzubringen, ist eine andere Frage...

Quote from lenko

Anders schaut das schon aus, wenn wir über andere Texturen, sagen wir mal einen Mix aus dem was da ist hätten um einen Weg oder Straße im Mittelalter oder Altertum zu malen

Wie meinst du das genau?

Quote from lenko

Insgesamt ist unsere Natur ja recht schön ABER viel zu sauber. Also ich meine damit das ja nichts rumliegt, keine Äste oder Blätter bezw Steine

Das ist leider wahr, aber das könnte über Texturen nur schwer gelöst werden... zumal größere Objekte (zB Äste) als Textur nicht gut aussehen würden, hier wären 3D Modelle sinnvoller. Tatsächlich ist das aber auf unserer ToDo-Liste, also dass generell vereinzelt Steine und Felsen sowie Äste in der Natur spawnen. Das würde nicht nur die Optik verbessern, sondern auch andere Spielelemente (man müsste nicht mehr mit einem Startwerkzeug spawnen, sondern könnte dieses durch das Sammeln von Ästen und Steinen erst craften usw)

Quote from Smoka

Also, dass eine neue Welt nur mit dem Stadard texturen erstellt wird und man hat dann die möglichkeit belibige texturen hinzuzufügen und zu verwenden. wie z.b. pflasterstein oder ein waldweg
Das denn genau so für Block Texturen.
Sozu sagen, es gibt Leere Slots für texturen, die erst nutzbar sind, wenn man eine textur auf den slot zugeordnet hat.

Das ist tatsächlich ein schwieriges Thema, auch wenn diese Lösung an sich wünschenswert wäre... Natürlich ist der größte limitierende Faktor der, dass wir immer nur eine begrenzte Menge an Texturen haben können. Jede zusätzliche Textur erhöht den Arbeitsspeicherverbrauch und schmälert die Performance. Das ist bei einer einzelnen Textur zwar halb so wild, aber es gibt bestimmte Grenzen, deren Überschreitung einen besonders starken Einfluss auf die Performance hätte. Bei Terrain-Texturen haben wir das fast erreicht, bei Block-Texturen ist noch ein kleines bisschen Luft. Aber wir versuchen uns da auch ein wenig Reserve zu lassen, für den Fall, dass wir später ohnehin noch bestimmte Texturen noch hinzufügen müssen.

Wir können natürlich theoretisch ein paar Slots als Platzhalter drin lassen die man dann durch eigene Texturen ersetzt, aber viel Spielraum hat man dadurch ja leider nicht. Besonders beim Terrain, wo fast alle "Standard-Texturen" ja sowieso von Natur aus irgendwo in der Welt verwendet werden (zB Schnee, Sand, Höllengestein usw).

Man könnte natürlich die Block-Texturen reduzieren, um zumindest hier etwas Platz zu schaffen, aber der Entfall von bestehenden Texturen ist ja auch mit einigen Problemen verbunden

Quote from Deirdre

Zu den Texturen - Schnee gibt es ja bereits, wäre schön, wenn das auch auf Dächern, Wegen, Holzplanken usw. also wie Sand nutzbar wäre.

Meinst du Schnee als Block-Textur, also dass du bspw. einen Block oder eine Planke etc. mit einer Schnee-Textur spawnen kannst?

Schwierig... also eine isDirty() Funktion können wir ggf. hinzufügen. Das Problem ist, dass es prinzipiell 3 Arten von Chunks gibt (einmal ein klassischer Chunk [x, y und z Koordinate], welcher die Terrain & Block Daten enthält, dann ein LOD Chunk [nur x und z Koordinate] welcher eine grobe Repräsentation des Terrains in Form einer Höhenmap enthält, und dann noch ein spezieller Chunk [auch nur x und z], welche alle Objekte, Pflanzen usw. enthält). Nach jetzigen Stand werden die Tiere gespawnt, wenn ein solcher Chunk geladen wird (und der Chunk unberührt bzw. ist bzw. "isDirty()" false zurückgeben würde). Allerdings gibt es in der API derzeit nur einen eher abstrakten Zugriff auf die Chunks, und auf letztgenannten Chunk-Typ noch gar keinen Zugriff

Auch eine reset() Funktion packe ich mal auf unsere Liste, da aber sowas nicht vorgesehen ist (und auch derzeit kein Mechanismus vorhanden ist, dass ein Client einen Chunk komplett neu lädt), bin ich mir nicht sicher, ob sowas rechtzeitig zum Update verfügbar sein wird...

Ein NPCSpawnEvent ist aber bereits in der API vorhanden: https://javadoc.rising-world.n…ts/npc/NpcSpawnEvent.html
Damit können jetzt schon die Spawns geändert bzw. festgelegt werden, was spawnen darf und was nicht

Quote from lenko

Wie schaut es eigendlich mit Ordner für die Bilder aus

Du kannst die Bilder durchaus in einem Unterordner im Serververzeichnis platzieren und dann einfach den Pfad so in der journal.xml angeben. Also zB: <image name="journal/images/ts3-icon.png" width="256" height="256" page="right" posx="0.5" posy="0.5" pivot="center"/> (wenn die Bilder in einem Unterordner "images" in einem Ordner "journal" im Serververzeichnis liegen würden).

Ich sehe aber gerade ganz nebenbei, dass offenbar der "pivot" nicht stimmt wenn man "center" angibt... das ist offenbar passiert, als die neuen Pivot-Positionen vor einiger Zeit in der API hinzukamen Das wird mit dem nächsten Update behoben, ich wollte dich nur vorwarnen, dass wenn du momentan als Pivot "center" verwendest, sich die Position des Elements mit dem nächsten Update etwas verschieben wird...

Es ist wichtig, dass das <image> Element nicht innerhalb eines anderen Textes (oder anderen Bildes o.ä) platziert ist. In dem Fall müsstest du Zeile 11 und 12 austauschen, damit <image> eigenständig wird. Oder du löschst das Text-Element (Zeile 9-12), da dort ja in dem Fall eh nichts drin steht

Wie @lenko schon sagt, ich denke dass im Februar oder spätestens Anfang März das Update fertig ist

Quote from Deirdre

Aber ein Update im Jahr ist wirklich zu wenig. Dann halt mal ein paar neue Pflanzen zwischendurch. Update hochladen, Steam neustarten. Wegen mir nur irgendein Mini-Update

Es ist schade, wenn das wirklich auf ein Update reduziert wird... aber wie @SonoBionda schon sagte, es waren tatsächlich 5 Updates, welche teilweise tiefgreifende Änderungen brachten (auch wenn die Updates vll nicht jedermanns Sache waren, waren es vom Aufwand her wesentlich umfangreichere Updates als manche Updates der Vergangenheit). Eigentlich waren es sogar 18 Updates, wenn man die Mini-Updates und Hotfixes dazuzählt (im Gegensatz zu anderen Entwicklern schreiben wir dafür aber i.d.R. keine neue Ankündigung, sondern ergänzen die vorherige, damit die News-Übersicht nicht komplett zugekleistert wird)

Dass das jetzige Update so lange dauert ist wirklich ärgerlich, das ist aber überwiegend durch die zerstörerischen Änderungen bei Steam im Oktober verursacht (der Ansatz, neuen Kunden tendenziell nur noch AAA Spiele und absolute Topseller zu präsentieren), wodurch unsere Verkäufe "über Nacht" stark eingebrochen sind. Unser Ziel ist es nicht, ein bestimmtes Update so schnell wie möglich zu veröffentlichen oder ein bestimmtes Feature so schnell wie möglich zu implementieren, sondern es geht uns um das Endresultat - nämlich die "finale Version" (wenn man das so bezeichnen kann) von Rising World in zumindest halbwegs absehbarer Zeit fertig zu bekommen. Die Änderungen bei Steam machen das auf dem klassischen Wege unmöglich (oder wir müssten uns irgendwie mit Nebenjobs und zusätzlichen Aufträgen irgendwie über Wasser halten, was aber die Entwicklung von RW noch viel mehr verlangsamen würde, was dann wirklich "ewiges Early Access" bedeuten würde). Und das Projekt über den Haufen werfen wäre logischerweise auch absolut inakzeptabel. Wir haben also die letzten Monate viel Zeit damit verbracht, einen "Plan B" für die Zukunft von RW auszuarbeiten und schonmal alle Weichen dafür zu stellen. Die gute Nachricht ist, dass wir eine Lösung habe, die langfristig sicherlich die absolute Mehrheit der Spieler zufriedenstellen wird. Die schlechte Nachricht ist, dass dadurch das Update zwischenzeitlich fast komplett auf der Strecke blieb, wodurch wir jetzt natürlich mit dieser langen Wartezeit konfrontiert sind...

Ein Mini-Update können wir aber leider nicht rausbringen. Einerseits wäre das taktisch unklug, denn viele Spieler wären dadurch sicherlich irritiert und würden (verständlicherweise) den Eindruck bekommen, wir hätten jetzt so viele Monate für "eine Handvoll neue Pflanzen oder Möbel" gebraucht. Andererseits ist das Spiel jetzt eher im Zustand "Baustelle" wo an vielen Stellen rumgeschraubt wird, d.h. NPCs funktionieren noch nicht so ganz usw. Es würde viel Arbeit bedeuten, hier den alten Zustand wiederherzustellen nur damit ein paar Kleinigkeiten für ein Mini-Update dazugepackt werden können

Quote from SonoBionda

An dieser Stelle würde ich gerne noch mal nachfragen, ob die Möglichkeit besteht, den kreativen Paintmodus mit mehr Texturen zu versehen (bspw. Pflasterstein)? Sowas würde mir als Miniupdate sehr große Freude bereiten

Also das Problem ist, dass das Terrain leider nur die "klassischen" Terrain-Texturen enthalten kann (also Gras, Sand, Stein, Erde etc). Die Blocktexturen können wir leider nicht auf dem Terrain darstellen... wir könnten vielleicht ein bisschen tricksen und ein oder zwei zusätzliche Terrain-Texturen hinzufügen, evtl. wäre Pflasterstein eine Überlegung wert (da sowas ja durchaus für Wege sinnvoll wäre). Allerdings muss so eine Änderung gut durchdacht sein, da wir die Textur hinterher nicht mehr so einfach entfernen können und evtl. den "Platz" für eine andere, wichtige Textur brauchen (ein neues Erz o.ä)... aber Pflasterstein wäre vll trotzdem nicht verkehrt. Vielleicht äußern sich ja noch ein paar andere Leute dazu, ob Pflasterstein hilfreich wäre oder nicht, ggf. können wirs dann ins nächste Update packen

Quote from Devidian

ich glaube wenn ich eine jar in plugins/ordner/jar.jar packe wird er im log meckern das die jar keine plugin.yml hat

Ja, das ist leider das Problem =/ Das Spiel würde denken, es handle sich um ein eigenständiges Plugin, und es wird eine Fehlermeldung geworfen (was an sich zwar kein großes Problem darstellt, aber dennoch unschön ist). Wenn sich die .jar aber in einem Unterordner befindet sollte das kein Problem mehr sein

Hmm... ich konnte das Problem leider nicht reproduzieren, da aber in den letzten Wochen einige Änderungen beim internen Handling von Modellen und Texturen vorgenommen wurde kann es sein, dass dieses Problem damit bereits automatisch behoben wurde. Falls das Problem also nach dem nächsten Update noch bestehen sollte, lass es mich bitte wissen

Quote from missvampy

I downloaded some blue prints and made a folder for them. But they won't show in the journal .please help.

Also make sure that you don't extract blueprint files after downloading them Some zip programs reconize the blueprint file as a zip archive, but extracting it destroys the blueprint. Just download the blueprint files and put them into the "Blueprints" folder (as mentioned by @Minotorious and @Lady_whynot) without opening the file.

It's unfortunately some unintended behaviour. When a player walks towards a wall, the camera near plane will be changed (to prevent the player from looking through walls). However, this greatly reduces the precision of the depth buffer, resulting in a lot of z fighting (the flickering you were experiencing)... we will fix this issue with the next update

Sorry for the late response! Unfortunately the log file you've attached to the first log does not contain the plugin error... maybe you can upload the correct server log, it will contain more information about which plugin caused this issue (and why this issue occurred)

Üblicherweise werden die Dependencies in den "lib" Ordner im Plugin-eigenen Unterordner gepackt (also tatsächlich zB "/plugins/PLUGIN/lib/externe.jar"). Du kannst bspw. auch irgendwo einen zentralen Ort für eine shared Lib festlegen (zB "/plugins/sharedLibs/externe.jar"), dafür musst du aber die Manifest Datei im Plugin selbst bearbeiten. Öffne dazu deine Plugin .jar mit einem Zip-Programm, gehe in den META-INF Ordner und öffne die "MANIFEST.MF" Datei. In der Zeile "Class-Path" wird normalerweise der Pfad zur Lib festgelegt, i.d.R. als relativer Pfad. Du kannst aber auch einen absoluten Pfad angeben, zB Class-Path: file:///C:/RisingWorld/shared/externe.jar

Absolute Pfade sind natürlich äußerst unpraktisch wenn du das Plugin ausliefern möchtest, also kannst du auch einen relativen Pfad angeben und auf ein Parent-Verzeichnis verweisen. Wenn deine Lib also zB in "/plugins/shared/lib/externe.jar" liegt, könnte der Classpath so aussehen: Class-Path: ../shared/libs/externe.jar

Da Änderungen an der Manifest-Datei aber jedesmal vorgenommen werden müsssen, wenn du das Plugin updatest, würde es sich hier anbieten, bpsw. direkt das build-Script in Netbeans (bzw. der IDE deiner Wahl) anzupassen

Mit der Grafikkarte hängt das Phänomen nicht zusammen, eher mit dem Betriebssystem... hast du denn evtl. mal die o.g. Einstellung in Ubuntu ausprobiert?

Also sowas wäre tatsächlich für die Plugin API prädestiniert... wir können zu diesem Zwecke gerne eine player.getIdleTime() Funktion mit dem nächsten Update hinzufügen

Das Problem, wenn das stattdessen Teil des Hauptspiels wird, wäre die extreme Unflexibilität... grundsätzlich ist ein Spieler ja nicht automatisch "AFK" nur wenn er das ESC Menü öffnet (kann ja sein, dass er dort nur die Permissions einsieht, die Einstellungen ändert, kurz auf den Desktop wechselt o.ä). Andererseits würden die Spieler, die wirklich AFK sind, aber nicht die ESC Taste drücken (was ja durchaus häufig vorkommt), nicht als "AFK" angezeigt werden

Andererseits ist ein Befehl m.E. auch nicht ganz passend, zumal das Hauptspiel sich von Chat-Commands ja generell distanziert (das soll exklusiv für Plugins und Scripts da sein, d.h. hier würde nur ein Konsolen-Befehl in Frage kommen, aber auch das passt ja nicht so ganz denke ich)...

It's a matter of a few weeks. I guess the update will be ready in February or early March. Sorry for all the delay!

Hmm... what sort of "server meltdown" or hickup did you experience exactly?
The log snippet indicates that there was some sort of desync going on, but usually just minor issues (according to the log) which could also be caused by a plugin... can you maybe send me the full log via PM?

Ursprünglich war mal geplant, dass eine Auswahl der Bilder ggf. auf der Storepage bei Steam oder so erscheint. Es hat sich alles leider ein wenig anders entwickelt. Natürlich kann man weiterhin Bilder dort posten, tatsächlich war der Thread ja zeitweise auch sehr belebt, aber vor dem Hintergrund der neulichen Änderungen bei Steam und einigen bevorstehenden Umkrempelungen bei RW, würden es die Bilder vmtl. nicht mehr auf die Storepage bei Steam schaffen

Quote from lenko

Das wäre super, wenn das geändert werden würde. Wäre dann ein glätten es Wassers auch möglich, die Stufen im Wasser sind ja recht hoch für die Boote, zumindestens Optisch

Zwar wird Wasser auch als "Textur" in den anderen Terrain-Tools verfügbar sein (also beim Hinzufügen/Löschen, Malen, sowie dem Erstellen/Löschen von Wasser in auswählbaren Areas), aber Glätten leider nicht. Damit würden sich die Stufen leider auch nicht verkleinern lassen, da dies leider durch die derzeitige "Auflösung" des Wassers bzw. den zugrundeliegenden Wasserinformationen in der Welt (blockweise) bedingt ist...

Quote from lenko

Systemvoraussetzung laut Steam [...] Wenn ich meiner Meinung nach, mit solch einem Rechner RW spielen möchte, sollte man von größeren Blaupausen und aufwendigen Projekten mit vielen Balken und Planken die Finger lassen

Tatsächlich handelt es sich dabei ja wirklich nur um die absoluten Minimalanforderungen, um das Spiel zu spielen. Spätestens wenn die Einstellungen (vor allem die Sichtweite) auf ein Minimum geschraubt wird, wird man mit solch einer Hardware i.d.R. auch auf allen Servern spielen können. Schön ist das natürlich nicht, aber dafür sind ja auch die "Empfohlenen Systemvoraussetzungen" da, an die man sich dann eher orientieren sollte.
Erfahrungsgemäß wird den Systemvoraussetzungen in den meisten Fällen aber eh nicht ganz so viel Beachtung geschenkt...

Quote from lenko

so das die Minimal Voraussetzung auch wirklich zum spielen ÜBERALL ausreicht

Das Problem ist aber auch, dass es beim Bauen keine Beschränkungen gibt, sodass man ab einem bestimmten Detailgrad irgendwann jede Hardware in die Knie zwingen kann... die einzige wirklich "sichere" Lösung hierfür wäre, das Bausystem zu beschneiden. Bei anderen Spielen gibts ja designbedingt immer eine Art "Obergrenze", wieviel überhaupt bzw. mit welchem Detailgrad gebaut werden kann (bei Minecraft oder 7dtd eine blockweise Ausrichtung, bei Rust oder Ark ein modulares Bausystem etc).

Andererseits spielen viele Spieler (tatsächlich sogar die Mehrheit, ganz zu meiner Verwunderung) eher nur im Singleplayer, bzw. kommen mit den Problemen bei extrem detailreich bebauten Gegenden tendenziell nur sehr wenig bis gar nicht in Berührung. Es wäre schade, wenn diese Spieler durch exorbitant hohe Mindestanforderungen möglicherweise abgeschreckt werden (zumal "detailreich bauen" ja nicht das einzige Feature im Spiel ist)

Quote from lenko

Bei den Servern wäre es gut wenn du mal eine realistische Empfehlung mit veröffentlichen würdest. Ich gehe mal davon aus das bei Mietservern vom Ram abgesehen die Hardware ok ist. Aber wieviel Ram sollte ein Server wirklich haben damit 10,20 oder 50 Spieler Serverseitig ohne Probleme spielen können.

Naja, prinzipiell gibt es eine grobe Aussage darüber hier: Dedicated Server Setup
Bei Servern wird es etwas schwierig, konkrete Aussagen über die Mindesthardware zu treffen. Zwar spielt der RAM eine große Rolle, ist aber nicht der einzige entscheidende Faktor. Bei RW sind auch weniger die maximalen Spieler ausschlaggebend, sondern eher, wieviel wirklich gebaut wird und inwieweit Bilder usw. verwendet werden. 20 Spieler, die sich eher ein kleines spartanisches Lager bauen werden den Server weniger auslasten als 2 Spieler, die ein gigantisches Bauwerk mit Millionen von Bauteilen planen...

Vor allem wenn es um "Gameserver" geht, haben wir leider schon einige schwarze Schafe entdeckt. Hier werden - aus (nachvollziehbaren) Gründen der Rentabilität - meist viele Gameserver auf einer Maschine gehosted. Problematisch wird es, wenn zu viele Instanzen auf derselben Maschine laufen und diese unterm Strich ständig ausgelastet (bzw. eher schon "überlastet") ist. Man kann hier nicht verallgemeinern, aber da in vielen Fällen der Fokus eher auf "Slots" und "RAM" liegt, ist es meist nicht möglich, Rückschlüsse auf die Hardware zu ziehen.

Effektiv wird ein Server mit 32 GB, aber grottig langsamer Festplatte wesentlich mehr Probleme bei RW bereiten als ein Server mit 2 GB RAM und guter Festplatte. Wir haben schonmal Tests mit einem 1-Kern vServer (1 GB RAM) durchgeführt, welcher preistechnisch irgendwo bei 2-3 EUR liegen würde. Hier konnte man immerhin zu dritt ganz vernünftig spielen (natürlich wären gigantische Bauwerke problematisch geworden). Andererseits führten manche Tests mit fertigen Gameservern, welche preislich eher bei 10 EUR liegen, schon mit 1 Spieler und ganz ohne irgendwelche Bauwerke (also ganz frische und unberührte Welt) teilweise bereits zu massiven Problemen, die in Richtung "unspielbar" tendierten

Quote from Deirdre

Gesetzte Lampen bleiben dunkel. Weder Chunkwechsel noch kompletter Relog hat etwas gebracht

Das ist eigenartig... die Beleuchtung wird separat in einem eigenen Thread berechnet, wird das Licht denn nach wenigen Sekunden dargestellt?