Posts by red51

Thanks for your suggestions

Quote from paulevs

1. Normal & Texture Blending for objects on natural terrain

We have been thinking about something like that in the past, but I don't think the performance impact is really worth the effort... We barely have natural elements like on the screenshot (i.e. elements where a large portion of them is covered by terrain), and on the few remaining elements where such a technique makes sense (e.g. rocks), the effect would be barely noticeable in RW I guess. In RW there are probably only very few situations where such an effect really pays off...

Quote from paulevs

2. Stochastic textures for natural terrain (and probably some materials)

While this is a great technique for natural looking materials, I'm not so sure if RW would really benefit that much from it... It has an impact on performance, especially when combined with triplanar mapping (which is used on our terrain). We're already using a distance-based tiling which reduces tiling on mountains, and while this is far from being perfect, it seems to be at least sufficient on naturally generated terrain. One still notices tiling on flat surfaces (like the current area surrounding the demo mountain for example), but after the world gen update, that area is covered by water anyway.

But this is something we may implement in the future

Quote from paulevs

3. No-intractable debris from object

Looks like right now "physical debris" from all objects can completely break player interaction with world, for example if you will use pickaxe in front of debris - it will destroy debris piece and not object behind it. I think this is a bit unbalanced behaviour as right now debris is a visual option. So, my suggestion is to make it ignorable by all raycasts and interactions so it will be more like 3D particles than real objects.

We could maybe introduce an option for this The original idea was to give the player a way to remove debris manually (considering it takes some time until it despawns automatically, depending on the settings), especially if it obstructs the view

Quote from paulevs

4. Mouse scroll enhancements.

Mouse wheel can change cells on the hotbar, but the problem is that it probably doesn't always behave as you expect from it. For example it will not switch hotbar cell if you will spin it too fast. And if it will change - it will change only one cell. My suggestion is to make it similar to other games (like Minecraft, for example) where you can smoothly change all hotbar cells with one spin instead of constantly pausing between them or moving wheel very slow.

I fully agree on this. Scrolling definitely needs a rework so it behaves like in the Java version

Quote from paulevs

5. Increase shadow bias (or make it configurable)

There are some cases of shadow bleeding of some surfaces. If shadow bias will be a bit larger - light will have less artifacts. It probably can be configurable inside graphic settings as different shadow resolution probably require different values.

Most of our lights have a unique bias setup... we could introduce a configurable global factor for this, but I'm not sure if there is a value that fits all situations...

Is there a specific light you where you've experienced any bleeding or artifacts, or could you maybe share a screenshot of a situation where this happens?

Quote from paulevs

Small bug at the end of list - shader distance will be reset on every game re-launch to default value. I didn't test other values but this bug can probably have same effect on other graphic settings.

Oh, thanks for letting us know, this is indeed a bug! We'll fix that with the next update

Wir könnten das theoretisch mal ausprobieren. Ich gebe zu, dass ein weiterer Weg, Bauteile zu verschieben, auf jeden Fall sinnvoll wäre Es könnte allerdings sein, dass das Radial-Menü zu sehr die Sicht versperren könnte

Danke für den Hinweis, das wird mit dem nächsten Update behoben

Quote from Deirdre

Möglicherweise habe ich noch Horrorvisionen von damals, als ich einen riesigen See vergrößert habe und danach überall Pflanzen in der Luft hlngen und es keine Möglichkeit zum Entfernen gab. Ich glaube ich habe bis zum heutigen Tag nicht alle entfernt.

Ja, das war damals tatsächlich ein großes (und auch nerviges) Problem... Dafür ist es in der neuen Version ja so, dass Pflanzen, die keinen Kontakt mehr zum Boden haben, *eigentlich* automatisch umfallen bzw. verschwinden sollten. Dafür muss in den Einstellungen unter Verschiedenes "Pflanzen von Schwerkraft beeinflussen" aktiviert sein (sollte standardmäßig aktiv sein).

Quote from Rüdi

Ich vermisse Schilder. Wann kann man damit rechnen dass diese ins Spiel kommen.

Ich kann leider noch keinen genauen Zeitpunkt dafür nennen... möglicherweise werden Schilder wohl erst nach dem Welt-Generierungs-Update kommen

Quote from Sandboxgamer

UnauthorizedAccessException - Access to the path "D:/Program Files/Rising World/RisingWorld-NewVersion/config.properties" is denied.

Hmm... das sieht auf dem ersten Blick so aus, als würde irgendwas das Spiel daran hindern, auf die config.properties Datei zuzugreifen Tritt das bei jedem Spielstart auf? Was für ein Antiviren-Programm verwendest du?

Erze als Bestandteil des Terrains, also als Terraintextur, werden noch kommen (das werden die Erze sein, die unterirdisch spawnen). Der jetzige Eisenerzbrocken ist davon unabhängig und ist eigentlich nur dafür gedacht, dass sowas an der Oberfläche schöner aussieht, als wenn dort am Boden einfach eine platte Erztextur wäre.

Die unterirdischen Erze werden zusätzlich dazu spawnen. Wenn Erz also unterirdisch spawnt, dann als Terrain Textur. Wenn es an der Oberfläche spawnt, dann als separater Felsbrocken.

Man wird Erze später auch ganz ausschalten können (quasi wie in der Java Version). Wir könnten auch eine Option einbauen, nur Erze an der Oberfläche zu deaktivieren... aber wenn die Erzbrocken stören, dann müssten eigentlich auch die normalen Felsbrocken stören?

Quote from Nightking

Despawn-zeit für weggeworfene Items gibt es ja bereits. Einfach eine weitere Option hinzufügen das Items liegen bleiben können. Dann könnten wir Fässer und Kisten mit sämtlichem Material füllen. Mir würde dieses Feature sehr gefallen. Für die Mittelalter-Baumeister hier im Game wäre die gewollte Unordnung an Baustellen sicherlich sehr authentisch

Naja, das wäre ein cooles Feature, aber wie gesagt, da hätte ich ein wenig Sorge vor den Auswirkungen auf die Performance Wenn Items immer liegenbleiben, dann wird sich im Laufe der Zeit wohl unweigerlich unendlich viel "Müll" ansammeln, und wenn dann Tausende oder gar Zehntausende (oder mehr) Items in der Welt rumliegen, dann wird das zu Performanceproblemen führen... im Multiplayer wäre das noch ein Vielfaches extremer, aber selbst im Singleplayer wird das problematisch... als Spieler würde man sich ja nichts negatives dabei denken, zB könnte man auf die Idee kommen, seinen Keller bis unter die Decke mit Items zu füllen, oder einen Geldspeicher à la Dagobert Duck zu bauen und zu befüllen Die schiere Menge an Items, die dort zustandekommt, würde wohl den besten Rechner in die Knie zwingen, was dann wieder zu Unmut beim Spieler führen könnte ("ich hab nur mein Holz im Keller gelagert und schon ruckelt es"). Items sind aufgrund ihrer Art wesentlich teurer zu rendern als bspw. Bauelemente.

Ich würde es erstmal bevorzugen, wenn man ein Feature hat, Items von Hand zu platzieren. Zwar kann man es hier natürlich auch "übertreiben", aber die Chance ist wohl deutlich geringer, wenn jedes Item bewusst platziert werden muss, als wenn ich einfach nur irgendwo stehe und Q spamme

Langfristig könnte man aber vll einmal damit herumexperimentieren, wie sich das verhalten würde, wenn weggeworfene Items dauerhaft liegen bleiben (zB als versteckte Option, die man explizit aktivieren muss).

Quote from Deirdre

Beim Arbeiten mit dem Terrainwerkzeug werden bei mir die Erze nicht entfernt, sondern ich muss diese manuell entfernen.

Wie Avanar schon erwähnt, werden Erze momentan über das Pflanzenwerkzeug entfernt. Ich gebe zu, dass das etwas befremdlich wirkt... tatsächlich werden natürlich spawnende Felsbrocken (wozu auch der jetzige Eisenerzbrocken zählt) vom Spiel wie eine Pflanze behandelt. Das hat einerseits Performancegründe (das Spiel muss eh für nahezu jeden Chunk Pflanzen generieren, daher können Felsen etc. direkt mit in diese Liste aufgenommen werden), andererseits müssen Faktoren wie zB der "Verschneitheitsgrad" für Felsen gleichermaßen gelten wie für Pflanzen (was bei normalen Objekten hingegen ja nicht zutrifft).

Wir werden aber das Lösch-Werkzeug anpassen, sodass Felsen dort zumindest nicht mehr als Pflanze betrachtet werden. Stellt sich nur die Frage, ob das wirklich ins Terrain-Werkzeug gehört (da dieses Erz ja nicht direkt Bestandteil des Terrains ist), oder ins Objekt-Lösch-Werkzeug?

Quote from Sandboxgamer

Hallo red51 , ist es normal, das man seine Leiche nicht entfernen kann?

Ja, das ist momentan leider noch nicht möglich

Quote from Sandboxgamer

Aber wie ich gerade bemerke, kann man weder in das Inventar des Toten sehen, noch die Leiche entfernen.

Leider ist auch das noch nicht möglich... das Inventar ist nicht zugänglich, weil Kisten generell noch nicht implementiert sind (und das Inventar des Toten ist quasi auch nur eine Kiste). Eine Option zum Entfernen der Leiche muss aber auf jeden Fall bald her.

Quote from Sandboxgamer

P.S. Dieses Account besitzt jetzt ein Rising World Standalone-Spiel, damit ich 1. einen 2. Spieler habe für die Spätere Plugin Entwicklung UND 2. um natürlich JIW-Games zu unterstützen.

Hehe, vielen Dank

Vielen Dank für den Report, der ist angekommen Irgendwas stimmt mit dem No-Clip Modus auf jeden Fall nicht, ich muss mir das einmal genauer unter die Lupe nehmen

Hehe, that would be a nice addition We have something similar planned for meat, so it definitely makes sense to have this for marshmallows too

Quote from yahwho

100%! I hope there will be a way in survival mode to do this in the future red51

We definitely need to think about this. We have to find a logical way of doing something like this in survival mode (i.e. what sort if item one would carry in his inventory in order to place a boulder etc)

Thanks for the permission files Galochka , I will take a closer look at why the colors don't get updated properly

Oh, I'm glad to hear it works now

Thanks for the feedback yahwho and james1bow , glad to hear it's still working

Quote from Galochka

Looks like I somewhere on the forum missed the information that the area works only for admins, and that the server somehow retains the old settings (but the server behaves this way).
I am inclined to believe that somewhere in the settings some kind of saving (copy) is enabled, which somehow works on the server. Is it possible?

Hmm... could you elaborate on that? If you refer to the area creative mode tool, this can be fully controlled via permissions, but it's recommended to make it only available to admins (otherwise players could abuse this feature).

What do you mean exactly with "saving"?

Quote from Galochka

I used the Admin group to create the Builder group and accordingly changed the color of the group to green, after deleting the Builder group (because it does not work, there is no protection for the area), the Admin group is green on the server, and in the permissions it is red (I’m not garbage inside the server I keep, all files that are not up-to-date are stored on a separate storage medium or deleted).

Was it only the color that was incorrect? Otherwise maybe you could send me the permission files in question, then I can take a closer look at it

Quote from Galochka

It may be that some type of "cloud" saving is enabled in the settings. Is it possible?

There is unfortunately no cloud saving available for the dedicated server

If you disable "Permissions_AdminsFullPermissions", you can only execute commands which are actually permitted in your current permission group. If you don't assign this player to a particular permission group, he is only affecetd by the default permission. Also make sure the permission file for that particular group is valid (if the server cannot parse it, the server starts anyway, but there is an error message in the log). You can also use this site to make sure there is no syntax error (just paste the content of the particular permission file there): https://jsonformatter.curiousconcept.com/

If you want to execute the "spg" command, but you don't have permission to do that, you could also type this command into the server console (if you have access to it).

Quote from james1bow

i had noticed in the last update if you closed the server and restarted it would take a few minutes to reconnect, i just dealt with it. the issue with players getting stuck at 5% had never happen before so i figured it was a new issue. thanks for all the hard work

Do you mean the last update (i.e. 0.4), or the latest hotfix that was just released an hour ago? If the server takes a few minutes to reconnect, it could be the port checker which halts the server until all ports are open (this was actually already implemented for TCP connections, but only the recent hotfix also takes UDP into account).

Do you have access to the server console? In this case there could be an indicator what's taking to long. If it's the port checker, you will see an ongoing output like "Checking ports...." (with lots of dots behind it if it takes long). If it's not the port checker, it could be Steam which takes a long time until it's connected (Steam is fully connected if you see this message in the log: "[STEAM] Server connected, public IP -> x.x.x.x").

How did you restart the server exactly? If you kill the process, it typically takes some times until the TCP connections (for the server query port) gets closed automatically on Windows. But if you shutdown the server gracefully (either by using the "restart" or "shutdown" command), the server should be able to restart immediately.

Quote from lenko

Hier frage ich mich wie du das meinst ? unterschiedliche Texturen oder extra Frarbe noch drauf

Das bezieht sich nur darauf, jede Seite eines Blocks unterschiedlich zu färben Unterschiedliche Texturen pro Seite zu haben ist etwas heikler, da sich hier auch Fragen zur Spiellogik ergeben (ein Steinblock mit Holztextur wäre zB weiterhin ein Steinblock, obwohl er nach Holz aussieht etc).

Quote from lenko

Ich denke das Sie das feine arbeiten meint. Und das war in der Java auch schon ein Problem. Wenn ich also nur kleine Ecken und Kanten weg haben möchte.

Achso, naja, das ist leider schwierig, da das Terrain nur 1 Wert pro Block vorsieht (und ein "Terrainblock" eine feste Größe hat)

Quote from lenko

Man kann ja nun in den Einstellungen die Dauer die der Schelzofen braucht einstellen, dies finde ich auch gut.

Nun versteh ich nicht warum in den Einstellungen mit Prozenten gearbeitet wird und für den Server mit einem Factor ?

Es wäre doch bei den Einstellungen, insoweit für SP & MP welche da sind, hier vom gleichen wert auszugehen.

Bei der eigentlichen Einstellung handelt es sich um einen Faktor (im mathematischen Sinne). In dem Fall entspricht also 1 genau 100% (bzw. Standarddauer), 0.5 entspricht 50%, 2 entspricht 200% usw. In der server.properties ist dieser Wert so angegeben und auch so beschrieben. Im Spiel hingegen ist das aber womöglich für Spieler irritierend, mit so einem Faktor zu arbeiten, daher wird das in Prozent umgerechnet und entsprechend etwas anders beschrieben (also 100%, 50% etc). Außerdem sehen Prozentzahlen (zB "75 %") meist schöner aus und sind für viele Spieler leichter verständlich als Faktoren ("0.75").

Wenn wir in der server.properties auch Prozentangaben (0-100) hätten, dann wäre das tatsächlich aber recht irritierend: Denn wenn da stünde OreSmeltingDurationFactor=50, dann wäre dabei nicht klar, was das denn bedeutet. Ich würde daraus wohl lesen "50x so schnell" oder sowas (was falsch ist). Wenn da aber steht OreSmeltingDurationFactor=0.5, dann finde ich, ist das Risiko für Missverständnisse schon deutlich kleiner (der "Faktor" für die "Dauer" beträgt nämlich 0.5, also "Dauer * 0.5 = halbe Dauer").

Generell hat die server.properties einen direkteren technischen Bezug.

Das Spiel macht das übrigens überall so (also alle Angaben, die im Spiel in Prozent sind, sind meist in der config Datei als Zahl zwischen 0 und 1 angegeben). Die Java Version hat das auch so gemacht (zB die Spawnraten für NPCs)

There is now an update available for Windows multiplayer servers specifically. It should fix the UDP issue mentioned above, at least we couldn't reproduce it anymore on our end. This version also performs a port scan (to find out if there is already a TCP or UDP listener on the server port), but this can be disabled by setting "Server_EnablePortCheck" to false in the server.properties.

This fix is not available for Linux currently because apparently Linux servers were not affected by this issue. However, if you still run into any connection issues (either on Windows or Linux) or any other server-related issues, please let us know

Quote from VoodooPanz

Das Terraforming Tool macht, zumindest bei mir, manchmal gar nichts, dann wieder malt es in der "Anheben/Absenken" Funktion Grass. Die "Glätten" Funktion kann ich gar nicht nutzen und der Texturenpinsel macht zwischendurch auch was er will. Vielleicht hilft es aber auch, wenn ich das ganze mal deinstalliere und neu aufspiele.

Das ist aber eigenartig Ich konnte das leider bisher noch nicht reproduzieren... muss ich mir aber nochmal genauer anschauen

Quote from VoodooPanz

Ich habe nicht mal so ein Fadenkreuz. Kann man das irgendwie über die Konsole an- und ausschalten?

Das kann in den Grafikeinstellungen unter "Ansicht Einstellungen" (also dieser Button relativ weit oben, unter VSync und sowas) eingestellt werden. Ganz unten kann darin das Aussehen des Fadenkreuzes gewählt werden.

Quote from Desmagu

Ich finde es auch viel sinnvoller doppelwandig zu bauen, weil es viel besser aussieht. Am Ende braucht man an den Innenseiten eines Fensters meistens eh zwei Texturen, siehe Beispielfoto. Ein weiterer Vorteil ist, dass wenn der Boden und die Decke jeweils einzeln gebaut werden, kann man die Fliesen oder das Laminat neu verlegen, ohne dass man Löcher im Haus hat (siehe zweites Bild).

Sollten zwei halbe Blöcke mit einer Textur weniger Daten zum Laden benötigen als ein ganzer Block mit individuellen Seiten, wäre es mir persönlich lieber, wenn es so bleiben würde wie es ist. Ansonsten habe ich nichts gesag

Ich denke es gibt durchaus viele Situationen, in denen individuell gefärbte Seiten keine doppelten Wände ersetzen können.

Aus Performancesicht ist es so, dass zwei separate Bauteile definitiv "teurer" sind als ein Bauteil mit individuell gefärbten Seiten. Es stellt sich dabei immer nur die Frage, wieviele der verbauten Bauteile man insgesamt anmalen würde (und in der jetzigen Situation deshalb doppelwandig baut). Bei individuell gefärbten Seiten müssen diese "Mehrkosten" für jeden Block bezahlt werden, auch wenn gar keine Farbe gesetzt ist. Wenn nur 20% aller Bauteile wirklich eingefärbt werden, kann ein Feature "individuell-gefärbte-Seiten" unterm Strich also teurer sein. Wenn aber eh die Mehrheit der verbauten Blöcke angemalt wird (und zwar so, dass man dann deshalb doppelwandig bauen muss), dann wären "individuell-gefärbte-Seiten" günstiger (vorausgesetzt, die doppelte Wand könnte man wirklich einsparen)

Die Frage bleibt also sowieso, wieviel doppelwandige Blöcke man wirklich einsparen würde, wenn es dieses Feature gäbe. Aus spielerischer Sicht ist es aber vll so oder so vorteilhaft, dass man Seiten individuell färben kann.

Wenn wir hier aber von "günstig" und "teuer" reden, dann muss man das auch immer relativ sehen Solange man mit seinem Computer nicht unbedingt an den Mindestanforderungen kratzt (vor allem was den RAM angeht), dann sehe ich da eigentlich kein großes Problem

Quote from Deirdre

Das Terrainwerkzeug ist noch nicht ganz ausgereift. Gras zu übermalen, fand ich schon in der Java nicht wirklich funktionabel. Der Gärtner braucht dringend ein paar Fortbildungskurse.

Also das einzige Problem, welches ich beim Malen mit Gras unmittelbar sehe, ist, dass der gesamte Bereich mit Gras bemalt wird und nicht nur die Oberfläche (man also bei großen Radien durchaus eine 5 oder 10 Meter tiefe "Grasschicht" hat)... da wäre es absolut wünschenswert, wenn sich das ändert. Oder hast du mit dem Malen noch ein anderes Problem entdeckt?

Quote from Deirdre

red51 Wie ist es mit den Holzteilen jetzt beim Ziehen? In der Java-Version wurde ein gezogenes Teil nur als ein Teil gerechnet, sofern ich mich nicht irre.

In der Java Version wurde dafür tatsächlich nur ein einziges Bauteil abgespeichert, während in der neuen Version dafür einzelne Bauteile platziert werden. An der Framerate ändert das nichts (in beiden Versionen werden sämtliche Bauteile in einem Chunk sowieso zu einem einzigen Bauteil heruntergerechnet), aber in der neuen Version wird dafür mehr Speicher verbraucht. Generell verbrauchen Bauteile jetzt mehr Speicher als noch in Java, da wir nun viele zusätzliche Informationen abspeichern (zB die ID des Spielers, der das Bauteil platziert hat, das Platzierdatum, die Farbe, und außerdem noch alle Daten für die zusätzlichen Einstellungen wie Oberflächenbearbeitung, Texturskalierung etc).

Aber das betrifft nur den RAM. Das hat keinen wirklichen Einfluss auf VRAM oder CPU-/GPU-Auslastung. Was den RAM angeht, da hat die neue Version ohnehin den Vorteil, dass wir den benötigten RAM nicht im Vorfeld zuweisen müssen (wie in der Java Version), sondern jederzeit so viel RAM nehmen können wie benötigt wird (natürlich nur sofern vorhanden). Die Java Version hat - wenn ich mich recht entsinne - standardmäßig maximal knapp über 7 GB RAM verbraucht (es sei denn, man hat mit Startparametern mehr RAM zugewiesen). Standardmäßig war es daher so, dass selbst wenn 64 GB RAM vorhanden waren, das Spiel bei maximal 7 GB aufhörte (und dann im Zweifelsfall crashte, wenn mehr benötigt wurde). Die neue Version hingegen würde in so einem Szenario einfach mehr RAM nehmen (und erst crashen, wenn das System wirklich keinen RAM mehr hergeben kann)

This is really strange So far this only seems to affect Windows servers, but I see no reason why that should happen (except something related to firewall etc, but it's weird that it was apparently working before)

How often do you restart your server? Do you use the built-in "restart" command (or the built-in scheduler), or do you actually kill the process and start a new one?

Could you maybe share the latest server logs (for the Logs folder)? Maybe you could send them via PM to me?

//Edit: After some investigation, it seems like the UDP port sometimes still stays active for a brief moment after shutting down the server. If the server gets restarted immediately (either by the built-in restart command, or by killing the process and restarting it manually), this results in the old UDP listener not getting closed. This only seems to happen when binding to all addresses (i.e. if no specific server ip is provided). Apparently this was already happening in 0.3 (the previous multiplayer update). We're looking for a solution and will provide a fix for this ASAP!

That's the issue: If Permissions_AdminsFullPermissions is set to True, the current permission group is ignored for actual server admins (i.e. admins which are in the server.properties file). Basically this setting was just meant for servers which are not using any permissions at all (so admins can at least use commands etc).

If you set Permissions_AdminsFullPermissions to False, the actual permission group of the player (probably a group permission called "admin") will be used (and if no clipping is set to true there, it should take effect).