Posts by red51

Also 1 GB RAM ist generell nur ausreichend, wenn es sich um eine sehr kleine Welt mit wenigen Spielern handelt. Tatsächlich ist die Größe bzw. Komplexität der Welt sogar ausschlaggebender als die Spielerzahl. Wenn der Server etwas umfangreicher bebaut ist (also mehr als nur 2-3 Gebäude) ist 1 GB RAM u.U. nicht mehr ausreichend. Hier müssen dann schon eher 2-4 GB her, bei extrem umfangreich bebauten Servern auch durchaus mehr (wobei 6-8 GB in allen Lebenslagen eigentlich ausreichen sollte).

Du könntest die RAM-Auslastung prüfen, indem du ingame den Konsolenbefehl getserverinfo memory eingibst. Im Gegensatz zu nicht sehr aussagekräftigen RAM-Anzeigen außerhalb des Spiels ist hier genau sichtbar, wieviel RAM aktuell verwendet wird und wieviel reserviert ist. Es ist ggf. sinnvoll, den Befehl ruhig mehrmals einzugeben (und auch mal nach längerer Laufzeit), um etwaige Änderungen am RAM-Verbrauch festzustellen

Aber was genau bedeutet, dass der Server offline war? War er wirklich aus, d.h. er tauchte nicht mehr in der Liste auf und beim Versuch, dem Server zu joinen, gabs eine Fehlermeldung? Oder meinst du damit, dass das Laden bei 10% hängen blieb?

Well, the game requires a powerful CPU, since there are lots of computations going on - especially the world generation is quite demanding. Most of these things can't be done on the GPU. Certain things can be moved to the GPU, e.g. the player/npc animations, and that's actually planned (but this will not result in huge performance improvements). Apart from that, it's also possible to use OpenCL for computations, but since drivers (especially old drivers) of certain graphics card vendors have a pretty bad quality when it comes to OpenGL, I'm afraid these drivers probably also suffer from severe issues concerning OpenCL. Unfortunately lots of people are using outdated, broken drivers...
But this is anyway only suitable for certain things. Especially when it comes to the world generation, there needs to be a proper synchronisation between the CPU and GPU - some of the critical tasks can't be outsourced to the GPU.

But you also have to keep in mind that people with weaker graphics cards already experience around 100% GPU usage in some cases (depending on the graphics settings). And there are some features on the todo list which will have a noticeable impact on the rendering performance (i.e. the GPU), e.g. dynamic shadows, parallax mapping and tessellation. I'm afraid there isn't much room for optimizations if we also try to move too many computations (which were originally done by the CPU) to the GPU

Um welches Problem handelt es sich hierbei genau? Ursprünglich war das Problem ja, dass der Server nach einer gewissen Zeit abstürzt oder sich beendet. Besteht dieses Problem immernoch? Wegen der Problematik, dass der Ladebalken bei 10% hängen bleibt: Betrifft das nur einzelne Spieler, oder kann dann niemand auf den Server verbinden?

Die obige Warnung wegen der Query IP kann im Grunde ignoriert werden. Durch einen Bug in der Steam API ist es so, dass unter Linux-Servern der Steam Query Server automatisch an die erste öffentliche IP des Server bindet, anstatt an die zugewiesene IP. Als Folge tritt der Server nicht im Steam-Serverbrowser auf. Das Problem kann entweder nur Valve lösen (durch Behebung des Bugs), oder der Hoster (indem ein Server nur eine einzige IP hat). Da wir aber wieder auf unsere eigene Serverliste umgestiegen sind, ist das mittlerweile halb so wild und kann prinzipiell ignoriert werden.

Ansonsten ist in den Logs nichts auffälliges zu finden, bis auf einen Fehler durch den Command setplayerofflinegroup (hier muss die UID anstelle des Spielernamens verwendet werden), der aber mit dem hier geschilderten Problem nicht zusammenhängt.

Bei extrem vielen Areas kann es auch sein, dass das AreaProtection Script an seine Grenzen stößt und keine neuen Spieler mehr verbinden können. Das ist einer der Hauptgründe, warum wir auf die Plugin API gewechselt sind. Allerdings treten diese Probleme erst auf, wenn aktuell mehrere Spieler auf dem Server sind (häufig ab 5-20 Spielern, aber i.d.R. erst wenn sehr viele Areas gesetzt sind). Wenn du also auch bei 10% hängen bleibst, obwohl niemand auf dem Server ist, liegt es vermutlich nicht daran.

Prinzipiell kann es auch sein, dass irgendwelche Spielerdaten fehlerhaft sind. Hast du ggf. noch eine Version von der Weltdatenbank (nur die Haupt .db Datei im Worlds Ordner, ohne die Worldparts usw), bevor du die Spieler daraus gelöscht hast? Kannst du sie mir dann evtl. einmal zusenden, entweder per PN, oder via E-Mail an support@jiw-games.net?

Thanks for the error logs! Please download and install the latest graphics driver from the AMD homepage, that should do the trick (download "Radeon Software" for "Windows 10 - 64-Bit Edition"): https://www.amd.com/en/support…/a8-7600-radeon-r7-series

@PatrickBronke: Stimmt, tatsächlich hängt das Spiel kurz wenn viele Server geladen werden. Normalerweise sollte es eigentlich - sofern keine Eingaben während dieser Phase getätigt werden - danach normal weitergehen. Warum die Serverliste in deinem Fall wieder und wieder von vorne lädt, ist mir ein Rätsel Aber vll wird das Problem ja mit dem nächsten Update behoben sein (also im Zusammenhang damit, dass der Hänger entfernt wird).

Damit der Server in den Favoriten auftaucht, ist es wichtig, dass der Http-Port des Servers nicht blockiert ist (Serverport - 1). Du kannst testweise auch die IP + HttpPort in deinen Browser eingeben (angenommen die ServerIP lautet 127.0.0.1 und der ServerPort ist 4255, dann ist der HttpPort 4254 -> d.h. in den Browser kannst du als Adresse eingeben 127.0.0.1:4254, und als Resultat müsstest du einen JSON-String erhalten).
Ansonsten kannst du ServerIP+Port (in dem Fall der normale ServerPort) auch manuell in die server.favorites Datei im Spielverzeichnis eintragen.

Tatsächlich wurde mit dem letzten Forenupdate (vor wenigen Tagen) offenbar der [IMG] BB-Code automatisch deaktiviert, um im Einklang mit der neuen EU-Regelung zur Datenschutzgrundverordnung (DSGVO) zu stehen. Das betrifft nicht nur Signaturen, sondern sämtliche auf dem Wege eingebundene Bilder (also auch in News-Beiträgen).

Wir werden die rechtliche Situation genau prüfen müssen, aber bis die Regelung in Kraft tritt, habe ich das erstmal wieder aktiviert

//Edit: Wir werden den IMG BB-Code vorerst aktiv lassen Zwar bedeutet das Einbinden von externen Bildern über den IMG Tag, dass die IP Adresse des Users an einen Dritten weitergegeben wird (was unter personenbezogene Daten fällt), allerdings ist das nach Art. 6 Abs. 1 lit. f DSGVO weiterhin erlaubt (auch ohne vorherige Zustimmung des Nutzers und ohne Vertragsabschluss), wenn ein berechtigtes Interesse vorliegt. Tatsächlich ist das Einbinden von Grafiken ein wichtiger Bestandteil eines Forums, und ein Verbot würde in vielen Fällen wohl eine spürbare Einschränkung bedeuten. Und wenn man sich die Alternativen anschaut wird man feststellen, dass ansonsten nur zwei Möglichkeiten blieben: Entweder das Bild herunterladen und hier im Forum als Dateianhang hochladen, oder aber einfach nur den Link zu dem Bild posten. Beides allerdings zieht massive Nachteile mit sich; beim Herunterladen des Bildes und anschließendem Hochladen hier im Forum findet eindeutig ein Urheberrechtsverstoß statt (es sei denn, man besitzt die Urheberrechte an der Grafik, was aber in den meisten Fällen wohl nicht zutreffen dürfte). Auch das Posten des Links (sodass ein User ihn erst anklicken muss, um zum gewünschten Bild zu gelangen) ist in meinen Augen problematisch, da in den meisten Fällen nicht erkennbar ist, was sich tatsächlich hinter dem Link verbirgt. Hier könnte es sich möglicherweise um eine unseriöse Webseite handelt, über welche ggf. Schadsoftware verteilt wird. Dieser Gefahr ist der Anwender bei reiner Betrachtung des via IMG BB-Codes eingebundenen Bildes i.d.R. nicht ausgesetzt.

Zusammengefasst kann man also m.E. davon ausgehen, dass sowohl die Erhöhung der Nutzerfreundlichkeit und "Usability" des Forums, als auch die Abwehr möglicher Gefahren für den User durchaus berechtigte Interessen sind.

Es gehen tatsächlich beide Möglichkeit, also einmal die Version, auf das entsprechende Eingabe-Event zu hören (wie @Minotorious erwähnte), oder aber die direkte Abfrage des Texts mithilfe eines Callbacks (wie @Machete vorschlug)
Leider kann der Textinhalt nicht direkt abgefragt werden (also eine Funktion die einen unmittelbaren Rückgabewert hat), da der Inhalt des Textfeldes erst vom Client geholt werden muss, daher ist das Callback nötig (oder halt die Event-Lösung). Du kannst aber alternativ auch zur Platzersparnis mit Lambda-Ausdrücken arbeiten, dann muss nicht explizit eine neue Klasse für das Callback erstellt werden:

textField.getCurrentText(player, (String text) -> {
    player.sendTextMessage("Text: " + text);
});

Danke für die Infos! Tatsächlich wird das Event bei dem selben Schaf nicht erneut ausgelöst, egal, ob es abgebrochen wurde oder nicht... dummerweise wurde clientseitig ein Flag gesetzt, wodurch keine weitere Interaktion mit dem Schaf zugelassen wurde (um zu verhindern, dass ein Spieler mehrfach mit dem Schaf interagiert, falls der Server mal sehr langsam reagieren sollte oder so). Es ist also prinzipiell dasselbe Problem, warum die Interaktion mit geschorenen Schafen generell nicht möglich war^^ Das Problem wird auf jeden Fall mit dem nächsten Update behoben sein

Beim "setAttribute()" Problem habe ich leider noch keine Neuigkeiten, muss aber zugeben, dass das zwischenzeitlich ein wenig unter den Tisch gefallen ist Ich setze mich ran und versuche, das Problem reproduzieren zu können

Also die Größe der Spielerfiguren an sich wird sich vermutlich nicht sonderlich ändern. Prinzipiell passt die Größe, man muss lediglich bedenken, dass ein Block nicht exakt 50 cm groß ist, sondern geringfügig größer. Wir haben besonders darauf geachtet, dass Türen 4 Blöcke hoch sind (und das ungefähr einer realen Türgröße nahe kommt), aber auch, dass ein Spieler durch einen 3 Block hohen Durchgang durchlaufen kann. Denn (offenbar geprägt von den 2 Bloch hohen Türen in MC sowie auch dem selben Maßstab in einem diversen anderen Spiel) besonders in der Anfangsphase von RW hat sich herausgestellt, dass ein doch nicht unwesentlicher Teil der Spieler dazu tendiert, Durchgänge nur 3 Blöcke hoch zu gestalten. Wären Blöcke exakt 50 cm groß und der Spieler durchschnittliche 175 cm, würde der Spieler so gerade eben nicht durch einen 3 Block hohen Durchgang passen. Also sind wir davon ausgegangen, dass ein Block zwischen 50 und 60 cm groß ist, dann passt es mit der Spielergröße. Für die allermeisten Bauvorhaben sollte es aber dennoch möglich sein, mit einfachen 50 cm zu rechnen.
Das ist leider immer das Problem, wenn es eine beschränkende Größe in einem Spiel gibt (in dem Fall Blöcke). Gäbe es nur Planken und Balken, hätte man auf sowas natürlich keine Rücksicht nehmen müssen, aber dann wäre der Baupart vermutlich für viele Spieler auch zu kompliziert^^

Nichtsdestotrotz passen viele Möbel von ihrer Größe nicht so richtig. Das liegt auch teilweise an der alten Spielerfigur, die damals von ihrer Größe her generell etwas aus der Reihe tanzte. Das Problem ist, dass wir die Möbel nicht einfach so verkleinern können, ohne damit Probleme für alte Welten zu schaffen (plötzlich haben die Küchenelemente Lücken dazwischen und auch die Anordnung vieler Möbel passt so nicht mehr). Unser Ziel ist daher, irgendwann mal alle Möbel zu überarbeiten (und vor allem unbedingt neue Möbel reinzubringen), die bestehenden Möbel aber aus Kompatibilitätsgründen im Spiel zu lassen (Welten werden dann konvertiert und haben weiterhin die alten Möbel, diese können aber nicht mehr gecrafted werden, sondern da stehen dann die neuen Möbel zur Verfügung - dem Spieler ist es also selbst überlassen, ob er alle Möbel abreißen und durch neue ersetzen möchte, oder ob er einfach die alten Möbel beibehält).

Leider kann ich noch nicht genau sagen, wann es soweit sein wird. Da ja doch schon so einige Möbel im Spiel sind, braucht das ganze etwas Vorlaufzeit. Vorher wollen wir aber erst noch das Bauupdate rausbringen. Doch bevor wir uns dem Bauupdate widmen, möchten wir die aktuellen Themen erstmal vom Tisch kriegen, also die Reittiere, Züge, Fahrzeuge, NPCs, mehr Survival (wobei wir das Bauupdate hoffentlich irgendwo dazwischen schieben können)

Sorry für die späte Antwort! Bestehen die Probleme weiterhin? In dem Fall würde ich dich bitten, in Steam einmal die "testbranch2 - rendering fix" Beta (Rechtsklick auf RW in Steam -> Properties -> Betas) auszuwählen (kein Code benötigt), und wenn erneut ein Absturz auftritt, einen neuen Log hochzuladen

Freut mich, dass es jetzt - mehr oder weniger - wieder funktioniert Wenn der Fehler nochmal auftritt, würde ich dich bitten, erneut einen Serverlog (oder sogar mehrere Serverlogs, sofern vorhanden) hochzuladen. Laut dem letzten Log konnte die Welt erfolgreich geladen werden, allerdings war IP + Port bereits belegt. Vielleicht ist dieses Phänomen aber auch erst durch ein anderes Problem entstanden, worüber aber dann ein anderer Log Aufschluss geben würde

Leider ist der Fehler durch die Debug-Konsole ausgelöst Offenbar tritt das vor allem dann auf, wenn ins Multiplayer-Menü gewechselt wird. Das wird im nächsten Update behoben! Bis dahin ist es ggf. empfehlenswert, den "game_debug_console" Wert in der config.properties Datei auf false zu setzen

Thanks for the log! This crash is caused by the debug console It looks like this mainly happens in the multiplayer menu... this bug will be fixed with the next update In the meantime, I'd recommend to disable the debug console

This message indicates that the current graphics adapter has no OpenGL support. But since every graphics adapter nowadays supports OpenGL, it's most likely caused by the graphics driver. Please have a look if there is a file called "errorlog" in your game directory, if there is such a file, please upload it here

Quote from Smoka

SEVERE: Error while starting the server: java.net.BindException: Die Adresse wird bereits verwendet

Der Fehler gibt an, dass unter der IP + Port bereits ein anderer Server läuft (oder ggf. ein alter Serverprozess, der nicht richtig beendet wurde). Jedenfalls ist laut dem Log die IP + Port Kombination bereits belegt, es kann immer nur ein Prozess auf einen port binden. Wenn das ein Gameserver ist, du also keinen Rootzugriff darauf hast, kann nur der Hoster prüfen, was dort genau los ist

If you're looking for a certain topic or post, usually the best way is to use the Search. This way you can search for posts made by a certain author, for example.
I found this blueprint topic, is that the topic you were looking for? Arcane's Blueprints from Earth 2 LP

Bonjour If you own the game in Steam, you can find the dedicated server files in your Steam lib under "Tools" ("Rising World Dedicated Server").
However, when using SteamCMD, anonymous login is actually supported (so you don't need to own the game). The app id 339010 should be valid... Do you use Windows or Linux? Maybe these topics help you:
Dedicated Server Setup
Set up a server with SteamCMD

Yeah it's unfortunately still missing, but will be available with the next update

Das mit dem geschorenen Schaf stimmt tatsächlich, das wird mit dem nächsten Update behoben

Das mit dem Event konnte ich aber leider nicht reproduzieren Es ist in der Tat so gedacht, dass das setCancelled() nur auf dieses eine Event bezogen ist, d.h. andere Schafe sollten davon nicht betroffen sein. Ich habe testweise das Event bei einem bestimmten Schaf abgebrochen (und es wurde wie erwartet nicht geschoren), das Event wurde aber weiterhin aufgerufen bei anderen Schafen.
Im Zweifelsfall poste am besten einmal den Code hier. Achte auch auf die Debug-Konsole, ob evtl. irgendwelche Fehler ausgegeben werden.

Quote from uksharon

Please could someone explain how to install this, where do I put the files thank you

To install a lua script, download it and extract it into the "scripts" folder in your game/server directory (if this folder does not exist, create it). Make sure that every script has its own subfolder, i.e. in case of this script, it should look like this:

Game/Server directory
|___scripts
|   |___TMN_home
|       |___definition.xml
|       |___scriptDatabase.db
|       |___tmn_home.lua

However, this particular script isn't fully compatible with the game anymore. Since we got rid of our hive, player names are no longer unique (instead a new UID was introduced to identify a player). This is an old script, so unfortunately it doesn't take these changes into account.
Basically the script will still work, but if a player changes his name, he will lose his home point